From the video, I couldn't tell how the device was being powered. I didn't see any dangling cables so presumably there is a battery behind the pcb. If it is indeed battery powered, then I guess you excluded the power circuitry to stay on the point at hand. Still, if you could share that part of the schematic and some observations on the power usage of the entire system that would be wonderful.
From what I recall, it was powered from 3 * AAA batteries, so technically 4.5 V and not 5 V. There was no other regulation or filtering beyond the decoupling caps in the schematics. The chips are OK down to 2.5 V or so.
Power usage is minimal. I think the active idle for the MCU is around 2 mA, and roughly 1 mA for the op-amp. SRAM has a standby current of a couple microamps. It's gonna spike during recording and playback, but this is very low-duty.
I am designing something along the lines of your project with a couple of modifications: (1) using a SD card instead of the sram (need non-volatile perm storage), (2) using a lipo with a charging/cut-off ic. Further, probably use some sort of mpeg codec chip (if these exist) instead of storing the raw waveform. I had built a version of this using the DFPlayer mini board (https://www.dfrobot.com/product-1121.html) and an arduino pro mini, which worked fairly well. But I think your approach would make things much cleaner and reduce the BoM.
Hey there! Appreciate your writings! One thing that I was hoping to find is how are you getting your C code compiled and flashed to the MCU? Ie what programmers are you using (off shelf or home-made) etc. Any chance you are planning to write a post on that topic?
In this particular example, I think it boils down to whether you have a soundcard on board or not. If you can shell out $50 for a Raspberry Pi with an audio plug and have the power budget to keep it running, then yeah, this particular project can be replaced with a small shell script.
If you don't, you're gonna be banging bits much the same way Linux or no Linux, except the task is more difficult when schedulers, garbage collectors, and other stuff gets in the way.
That said, I'm not really advocating ditching OS-based, "full computer" solutions altogether. It's just that there are interesting trade-offs, and folks often get it in their heads that it would be *nearly impossible* to do something like driving a graphics display or processing audio on an MCU.
In reality, they have options. The source code for the audio thing is ~180 lines of actual code, and it's not particularly esoteric or obtuse.
From the video, I couldn't tell how the device was being powered. I didn't see any dangling cables so presumably there is a battery behind the pcb. If it is indeed battery powered, then I guess you excluded the power circuitry to stay on the point at hand. Still, if you could share that part of the schematic and some observations on the power usage of the entire system that would be wonderful.
From what I recall, it was powered from 3 * AAA batteries, so technically 4.5 V and not 5 V. There was no other regulation or filtering beyond the decoupling caps in the schematics. The chips are OK down to 2.5 V or so.
Power usage is minimal. I think the active idle for the MCU is around 2 mA, and roughly 1 mA for the op-amp. SRAM has a standby current of a couple microamps. It's gonna spike during recording and playback, but this is very low-duty.
thank you. This is great.
I am designing something along the lines of your project with a couple of modifications: (1) using a SD card instead of the sram (need non-volatile perm storage), (2) using a lipo with a charging/cut-off ic. Further, probably use some sort of mpeg codec chip (if these exist) instead of storing the raw waveform. I had built a version of this using the DFPlayer mini board (https://www.dfrobot.com/product-1121.html) and an arduino pro mini, which worked fairly well. But I think your approach would make things much cleaner and reduce the BoM.
Hey there! Appreciate your writings! One thing that I was hoping to find is how are you getting your C code compiled and flashed to the MCU? Ie what programmers are you using (off shelf or home-made) etc. Any chance you are planning to write a post on that topic?
For a variant put together by a reader, check out: https://twitter.com/rgerganov/status/1623000100229328898
I believe it's based on an earlier revision that I shared on Twitter & Mastodon, but the fundamental approach is the same.
I've been reading the posts and while I appreciate the demystification part, I'm not sold on them being viable alternatives 😄
In other words, I have a new-found appreciation for everything that OS-based devices abstract away.
Anyway, thanks for writing these - you inspired me to learn more about this stuff
In this particular example, I think it boils down to whether you have a soundcard on board or not. If you can shell out $50 for a Raspberry Pi with an audio plug and have the power budget to keep it running, then yeah, this particular project can be replaced with a small shell script.
If you don't, you're gonna be banging bits much the same way Linux or no Linux, except the task is more difficult when schedulers, garbage collectors, and other stuff gets in the way.
That said, I'm not really advocating ditching OS-based, "full computer" solutions altogether. It's just that there are interesting trade-offs, and folks often get it in their heads that it would be *nearly impossible* to do something like driving a graphics display or processing audio on an MCU.
In reality, they have options. The source code for the audio thing is ~180 lines of actual code, and it's not particularly esoteric or obtuse.
One-part schematics here: https://lcamtuf.coredump.cx/soft/playback.pdf