I might have to check that out.
I have an nrf52840 micromod CPU, but I didn’t get very far in porting ProffieOS to it. Don’t remember at what point I stopped, but I was using the Mbed arduino core as described in the micromod documentation. Maybe zephyr is a better way to go.
Ive been working to make an MJPEG video player and was encountering the SD bitrate issues. The latest updates push the default SD SPI to 40mhz, which speeds things up. I know they can be pushed to 53mhz no problem. I have not tried SDMMC yet.
Ive got it doing 320x240 on an st7789. Most spi values are very conservative compared to actual capability.
Also, apparently you can just direct wire an sd, lol.
SDMMC is generally much faster than SPI. In our use case, the problem is often that we don’t actually read sequential data, so each read ends up having to actually fetch data from flash memory, which slows things down a lot.
The ESP32 problem isn’t a bitrate problem though. I think maybe it reads the whole directory when you try to find a file or something…
If you don’t need SDIO, an ESP32-S2 is worth a try. The S2 has an inbuilt DAC, whereas the S3 does not. The DAC can easily handle the 44100Hz. And it’s the same (sma footprint as the S3.
As an example: https://www.electromaker.io/project/view/pov-light-saber
He uses an ESP32, a MPU6050, a PAM8403 (Amp), a WS2812B strip and the rest belongs to the charging.
If you want to try the internal DAC, I recommend the following library:
https://github.com/WeekendWarrior1/XTronical_XT_DAC_Audio_Mirror
But there’s a “bug”. Since the API it was written for was 1.x, you need to add the line #include “soc/rtc_io_reg.h” to XT_DAC_Audio.cpp.
btw: I’d use APA102, if you want LED-Strips in the blades. Compared to WS2811 strips (and other WS28xx), they are flicker-free in POV thanks to higher PWM (20000 vs 400). And with the SPI interface it’s much faster and on top of that there is no critical timing required. And they need only 5V.
We need all the speed we can get from the SD card.
Even with the SDIO, freertos is kind of slow to read from the SD card.
I prefer I2S over DACs. It’s too easy to end up with lots of buzz and noise with analog signals.
APA102 are nice, but not an option for most people since it requires an extra pin.
I’ll make the bold assumption you’ve tested it:
How slow is “kind of slow” relative to a PB 2.2. or 3.9?
Here is what I wrote previously in this thread:
Ah, that’s my bad, I didn’t see that.
That’s… less than ideal.
I should try it again though.
I saw a commend that indicated that a fix was coming, so it’s possible that it works better now.
So, while thinking about TeensySaber V4 and the future of Proffieboards, I’m realizing that it’s getting pretty difficult to find modern MPUs that are 5v tolerant, and since we really need to be able to feed battery power into a neopixels, we really need proffieboards to be able to handle at least 4.2V without dying.
This makes me think that maybe the future of proffieboards is to use a main CPU that does all the calculations and plays sound. However, when it comes to actually output things, it would send the data over SPI or serial to another MCU, which is in charge of neopixel outputs, and would be 5v tolerant.
The question is; what would this secondary MCU be? It would need:
- 5v tolerant, or operate at 5 volts.
- good neopixel driving support
- enough RAM to hold neopixel data
- (optional) 6x12/14/16-bit PWM for driving the FETs.
- (optional) 3 5v tolerant inputs with pullup/pulldown for buttons
- Require very few external components
What about a attiny85 for just the Neopixels? You could use the main CPU to trigger the light effects.
I read up a bit on attiny85,and I don’t think it’s going to work.
In particular, it seems to fail this point:
attiny85 has 512 bytes, which just isn’t enough.
A few kilobytes is the minimum, and that assumes that we can drive neopixels without requiring one byte per bit. (Which many implementations do.)
Also, the neopixel output support seems very limited. (The chip is unable to do anything else while feeding out nepixel data.)
It’s been a hot minute since I tried running ProffieOS on an ESP32-S3 chip, and there seems to have been major improvements since then. Both the I2S and RMT devices have gained DMA-based buffering code, and the Arduino libraries now have the latest code from Espressif.
I’m doing some testing, and so far I have managed to get audio working properly, which was not possible last time I tried this. Now I just need to get everything else working too…
If it works out, maybe it’s actually time to make a Proffieboard SI ![]()
TIL how to run a debugger on an ESP32S3. The really nice part is that you don’t need any extra dongles or anything, because the chip contains all the parts needed already, and all the binaries are already downloaded when you download ESP32 support for Arduino. It’s possible that you can even debug directly from Arduino, but I have not figured out how to do that yet. Running the command line tools is easy enough and very similar to how I run a debugger for the Proffieboard CPUs.
Maybe we can finally have debugging for everyone!
(I will be SO happy if people can send be backtraces when something doesn’t work!)
Looks like the RMT device, which is the easiest way to feed out WS2811 data has also been updated to work well now.
That leaves one problem:
Opening files is still very slow. On a proffieboard it takes 2-3 ms to open a file depending on the length of the path. On my ESP32S6 dev board, it currently takes 9 ms, which is very very slow.
I can’t even stop my stopwatch at 9ms and I do have pretty good reflexes.
To be fair, 9ms is an eternity even by microcontroller standards. On a proffieboard that’s, what, 720 thousand CPU cycles? (More on the ESP32, fwiw)
Even if you can’t react to something in 9ms, you can definitely make out a disturbance that long. When humans can notice computers taking time, that’s how you know its long ![]()
9ms might not sound much, but for ProffieOS it is.
I got it down to 2ms though. The Arduino file API was doing something weird, but the layer underneath (which is POSIX-like with fopen/fclose/etc.) seems to behave and perform better.
Apart from an enormous amount of work, I’m not aware of anything preventing me from making a ESP32-based Proffieboard now.
There are so many Star Wars quotes that apply here.
I you have it in you sir, many people would benefit from that hard work!
I’ve been researching charging ICs.
The V3 board solution was designed to be small and simple.
However, I’ve noticed that there are some ICs that might be better, let me count the ways:
- Some have higher charging speed. Ideally, to follow the USB standard, we should only turn on higher charging speeds when the USB source supports it. Some chips can detect this, some cannot.
- Some can be controlled over I2C, this gives a lot of options for tweaking how the charging works, and it can allow you to set the charging speed and other parameters from the main CPU. In some cases it also means freeing up a pin or two as the charging chip can read battery voltage and USB voltage.
- Some have coulomb counters, which is sometimes called “fuel gauge”, which can keep track of how much power is being used with terrifying accuracy.
- Some use a booster circuit to charge the battery even if the input voltage is low. In some cases, the booster can also be used to provide a fixed voltage when the battery is low, which potentially means that the chip can replace the 3.3v regulator, the 5v booster (or maybe even both in some cases)
Now, so far this has been frustrating, a lot of these chips come with annoying drawbacks like:
- they require many many external components
- they have 30+ pins, nearly as much as the cpu
- they use BGA packaging which is hard to experiment with
- the data sheets are terrible and fail to describe how to use the chip
- they are expensive (8$ / chip in some cases)
- some chip use dumb designs, for instance, many chips just don’t expose the battery voltage through I2C
- a lot of chips are simply too weak to provide the power needed for a Proffieboard
If anybody have any tips, feel free to give me some ideas here.
If not, well, I’m just venting my frustrations. ![]()