0

Apologies if the title is not very well worded. I'm new to electronics and trying to learn more about embedded systems too. I have a small project that requires recording an analog audio input at 8-bit at 40kHz and saving it every second in a SD card.

Although I know that I can do that with an ATmega328P chipset, I'm not sure if the processing power of ATmega328P will be good enough for further extension of the project.

Ideally I would like to be able to record two sound sources at the same time at around 40kHz -- 16 or 24-bit would be perfect, and capture two sensory data also every second.

This device should be able to run on a reasonably sized battery for at least two hours, but ideally up to eight hours.

I do like the idea of working on a AT91SAM3X8E chipset, but I'm afraid this might be an overkill for such a small project and the current draw of a Cortext-M3 series might be too much for this project too.

My question therefore is would a ATmega328P or ATmega2560 be suitable for such requirements -- in terms of processing power, or do I have to upgrade to something like the AT91SAM3X8E?

1 Answer 1

2

My question therefore is would a ATmega328P or ATmega2560 be suitable for such requirements

No. Not in the slightest.

Your primary requirement of sampling audio at, basically, CD quality (or better) requires the use of a proper CODEC chip - and to drive that you require a microcontroller that has I2S. None of the 8-bit AVR chips have that.

On top of that you will need a LOT of memory. Far far more than an 8 bit Arduino has. Two channels of 16 bit audio at 44100Hz (CD quality) requires 176400 bytes per second.

You will need double that.

To both continuously record and save the data you will require DMA to do the recording. The DMA reads the incoming data from I2S and stores it in one buffer. When that buffer is full you generate an interrupt and switch to a second buffer. You can then save the first buffer to SD - assuming that it can be done in under a second. Note that SD cards, when controlled by SPI as they generally are on microcontrollers, are generally quite slow.

So with all that in mind:

I do like the idea of working on a AT91SAM3X8E chipset, but I'm afraid this might be an overkill for such a small project

Overkill? No. Not suitable since it is not up to the task. Yes, it has I2S. Yes, it has DMA. But it doesn't have anywhere near enough memory. You need for the audio alone 350 kilobytes (the SAM3X8E has up to 100 kilobytes) - not to mention memory required by the SD card's buffers.

So you're looking for a microcontroller that has full I2S support, DMA, and around half a megabyte of memory. And those aren't small and cheap like the Arduino's 8-bit AVRs.

5
  • Great, thanks a lot! Do you think there is a way to write down the samples at the time of interrupt -- say every 20us, in a temporary fast but small RAM and then write that down to the SD card every second. This way the microcontroller itself wouldn't need to have the extra memory embedded inside.
    – Mahdi
    Commented Aug 30, 2019 at 13:31
  • Also the whole idea of buffering the data is to not have the SD card on all the time, just to lower the power consumption. If we ignore that for now, do you think a mega328 can write real-time data to a (high quality, fast) SD card without any delays?
    – Mahdi
    Commented Aug 30, 2019 at 13:33
  • As for the temporary cache, maybe some fast EEPROM would work?
    – Mahdi
    Commented Aug 30, 2019 at 13:34
  • 1
    No, and no. You need a more powerful MCU.
    – Majenko
    Commented Aug 30, 2019 at 13:35
  • 1
    "write real-time data to a (high quality, fast) SD card without any delays?" The possible speed of the SD card is not important as long as you use SPI. To reach the high data speeds, you need to use the parallel data interface. And even with that most like the microcontroller (assuming you have one, that is up to the task in general) will be the bottleneck. So the possible speed of the SD card doesn't really matter
    – chrisl
    Commented Aug 30, 2019 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.