Hello everyone, I would really appreciate your help with resolving a problem.
We used our particle tracker board with an e-paper display. The template data for the display are stored in AWS. We can send a command from either a mobile app or a webpage requesting a particular display template, stored on AWS, to be projected on the e-paper display screen. The process is often completed as intended.
To minimize data usage, we decided to store a copy of the display template on the particle tracker board using a POSIX-style file system. The intended purpose is two-fold
1.The board will save the display template currently being projected on the screen.
2.During a power circle, the prior template should be flashed on the display after the board is powered on.
The problem we are facing is that both 1 and 2 above failed to occur.
What normally happens is that after the board is powered on, the display template that was projecting on the screen failed to flash, and instead, the information on the screen is scrambled together.
We are willing to pay for a solution. A code is attached below
Thanks
// ===============
// Step 1 - loading saved data if it exists
// ===============
struct stat st;
stat("/plate.dat", &st);
long size = st.st_size;
if (size!=310200) // Check that file has a correct size
{
Serial.printlnf("%s: Error: can not load save data, file size = %d", __func__, size);
return;
}
// .....
int rFd = open("/plate.dat", O_RDONLY);
if (rFd==-1)
{
Serial.printlnf("%s: Error Open file! ", __func__);
return;
}
for (int i=0; i<MAX_X*MAX_Y/8/100; i++ )
{
read(rFd, buff, SRAM_BUFF_LEN);
// ...
}
close(rFd);
// ===============
// Step 2 - save data to file
// ===============
int rFd = open("/plate.dat", O_RDWR | O_CREAT | O_TRUNC);
if (rFd == -1)
{
Serial.printlnf("%s: Error Can not open file!", __func__);
}
for (int i=0; i<MAX_X*MAX_Y/8/100; i++ )
{
// ...
write(rFd, buff, SRAM_BUFF_LEN);
}
fsync(rFd);
close(rFd);
// And theck the file size right after it close:
struct stat st;
stat("/plate.dat", &st);
long size = st.st_size;
Serial.printlnf("%s: Save to file %d bytes", __func__, size);
Happy New Year. Hope you had a good one? It seems our current problem is a bit out of range of the knowledge-based of the community. Not even a single response from anyone.
Particle can help with your development. Take a look at our professional services here https://www.particle.io/particle-studios/
First, I recommend prepending “/usr” to your file path. There may be future versions of device OS that may be sensitive to directories containing user files.
I also recommend adding a check on stat() return values. There may be a problem with the path or file.
auto ret = stat("/usr/plate.dat", &st);
if (ret)
{
Serial.printlnf("%s: Error: can not stat file, code %d", __func__, errno);
// Either fill default data or handle error
}
// check sizes, format, etc.
Thanks for your suggestion. I have spoken with two of your representatives regarding your particle studio. I think the cost estimate they quoted me was the problem. I really would like to work with particle to improve our development since we planned to use the particle board during our production. I will pass the code you’ve shared across to our team.
You might want to check the return value of fsync. Try to run some tests with smaller and know data (may be generated in place).
Also noticed that your data is 310kB long (as per your stat size check (although it sounds more it should be 310k bits)), and considering how much RAM is available you shouldn’t be able to write that much data in one shot, so it’s possible that something is wrong in a different place.
Unfortunately no. But you should be able to find plenty of resources between here and StackOverflow
One more thing, if you are using a e-paper display, as long you skip the display init sequence after each reboot, you should probably be able to keep the previous “screen” active, right?
Thanks for the update. I’m not the technical guy, could you shed more light on your suggestion, “as long as you skip the display init sequence after each reboot, you should probably be able to keep the previous “screen” active.” Yes, we used e-paper display.
e-paper displays don’t require power to keep the screen as is. So even if the power goes off you should still be able to keep whatever was there.
However, it possible that every time you reset your boron, you are calling the library that handles your display and it might be the case that during the init process you are erasing the display. If you skip this during the init you will keep your last frame.
