Well, I figured out one thing: The weird sdtest results are caused by buffering in the file object on esp32. Setting the buffer to 512 bytes makes it behave more reasonably. Still lots of underflows though… 
1 Like
Opening files is really really slow on ESP32 though: 18+ ms per file.
(For comparison, I ran sdtest on a plain proffieboard, and got ~1.7ms.)
Wonder if they have the same crazy file buffering for directories?
Also, I found this: Implements seekDir and getNextFileName on FS Lib to improve performan… · espressif/arduino-esp32@04693c6 · GitHub
Not sure if that means that open() will be any faster though.
Would it be feasible to add some ram to the board so that files only have to be loaded once per boot, and just live in memory thereafter?
No.
ESP32 does support adding ram, but I don’t know if it’s possible to add enough to keep a whole font in memory. Also, doing so uses up a at least 5 GPIO pins, and the ESP32 is already critically low on those.
The good news is that all of this stuff is solvable.
ESP32 is an open-source platform, so it’s just a matter of finding the problem and fixing it. It’s not like Windows, where you are stuck with what you get. It sure would be easier if it just worked though…
Do lots of reads degrade the life of the SD card to an appreciable amount?
I think so.
Reads do wear on the SD card, but I don’t know how much compared to writes.
Also, afaik, nobody publishes TBW values for sd cards.
I think I’m going to have to put the ESP32 on hold for a while.
Besides work, there are currently three known hurdles to making an ESP32 proffieboard:
- Opening files on the SD card is slow.
- the I2S code doesn’t work well over 16000 Hz sampling rate
- the WS2811 code produces 12500 interrupts per second and is unstable if other interrupts end up taking too much time.
At least two of these (1 and 3) seems to be already solved, but the solutions are not available for Arduino yet. Waiting a little bit might make that better. For the I2S problem, the solution might be to stop using their library and go directly to hardware, but I’m not sure how easy that is to do yet.
How are things going with the SMT-chip that was originally supposed to be used for the Proffie V3? I heard the chip shortage situation is improving now. Perhaps sticking to the original plan isn’t that bad if availability has improved, considering the hardships to port everything to a new CPU.
Not sure.
Things are improving, but st-micro doesn’t seem interested in making these chips anymore. Instead they are trying to push people to use the STM32G* series, which from my perspective would mean starting over from scratch with a new design.
Ah, so that’s what been going on. And there’s no guarantee that STM won’t pull such a stunt again in the future (and mess up plans for a potential Proffie V4 or V5)…
How much work would be to start over from scratch with that STM32 vs. porting to ESP32? And will this all affect future Proffie V2 production?
Did you read this thread?
It very much tells the story of how much work it is.
1 Like
I read it a while a back, though I didn’t realize just how intensive such a task would be. I apologize if my question came across as ignorant 
And it’s not done yet. There is still months of work left to do to make an ESP32 board.
That’s a huge amount of work for sure. Hopefully, it won’t lead to a dead end after all that work. I’m not very knowledgeable about writing such complicated codes and making chip designs, so I have nothing but respect to those who can do all that.
A lot of it is not really that difficult (at least when you know how) but it is a surprising amount of work. Good thing I like doing it. 
1 Like
That makes that amount of work a lot more bearable haha.
Esp32 would be easier to add video to. I have an stm32 based video player, but it requires a very modified library for the display.
The options available are endless for a wide variety of props for esp32 based proffieboard.
Could board to board communication occur for interactive effects?
We use esp32 modules for our smart home products. The esp-idf code seems much more stable than the Arduino side of things. Quite a bit of sample code also. As it is using FreeRTOS, thread priorities could be adjusted. You can also use wroom for duo core processing. But I find solo (single core) is quite capable already.
Sam
The arduino code is built on top of esp-idf, so all the esp-idf stuff is also available in arduino. The Arduino code is currently built on the previous version of the esp-idf though, so some of the new stuff isn’t available yet.
I agree that the esp-idf code is fairly nice, but it still has some major flaws (at least in the version that Arduino is built upon):
- I2S doesn’t work well with frequencies over 16000Hz (ProffieOS needs 44100Hz.)
- SD card access is slow (takes nearly 10x longer to open a file compared to a proffieboard.)
- WS2811 driving causes too many interrupts. (But I think this is fixed in the newest version of esp-idf)
Eventually I’ll go see if I can work around these issues. My hope is that the esp-idf will solve some of these issues for me so I won’t need so much custom code though.
Another platform is Nordic nrf52/53 running zephyr. Sd and i2s seems to be ok there. Lots of improvement on the OS. Actually too fast for my liking…