3

I'm in the echopen association, our goal is to create a low cost, open source echographic probe. In order to do that, we use an arduino due for the first step. For doing acoustic imaging, we use ultrasonic transducer wich works at high frequency, typically 5 MHz. So, for our purpose we need to send and receive analogic signal at high frequencies. We want to connect a 80 Msps DAC and a 80 Msps ADC to the arduino due so we can generate and mesure analog signal up to 42 MHz. I have found here (http://www.instructables.com/id/Arduino-Timer-Interrupts/#step0) how to use arduino timer interrupts in order to send and receive data at 84 MHz. I haven't connect my converters for the moment, but I have preliminary questions. First, is the definition of the timer is the same for the arduino due (i.e. timer1 is a 16 bits timer) ? Morever, my ADC and DAC are 14 bits converters, can I tell to the arduino to sent only 14 bits digital signal ? Secondly, as we work at high frequencies we will have to send a lot of data from the microcontroller to a computer via the serial port. I have make a test and at 250000 bauds it takes nearly 0.5 second to transfer 4300*8 bits datas. It is to slow for our purpose, how can I do it faster ?

2

If I'm interpreting the datasheet correctly, you might be able to use the Static Memory Controller (SMC) capability of the Cortex M3 Sam3X to attach some 128K x 8 SRAM devices to your Due. If your ADC and DAC support tri-state outputs then they could be attached the same way as memories (but ignoring address lines as irrelevant), allowing memory-to-memory DMA transfers. Ie one could either input and store batches of ADC results at 42 MSPS, or could output batches of data to DAC at 42 MSPS, or could do simultaneous I/O at 21 MSPS. I haven't read the DMA section closely enough to verify that this will work with the M3.

See Figure 25-2 in Section 25.6.2 of the datasheet regarding memory controllers, and Section 26, “Peripheral DMA Controller (PDC)”, regarding DMA. Also see the eevblog.com page, “Looking for Cortex M3 or M4 with DMA to GPIO capability”.

1

I'm sorry, but by your description you are doomed to failure from the start.

The Arduino Due runs at 84MHz. That doesn't mean that it can communicate at 84MHz, only that it can process its instructions at around 84 million per second.

In order for you to transmit or receive 80 million samples per second you have to be able to a) transmit sample words (14 bits) 80 million times per second, and b) process the information between each sample.

That means you are going to require a processor that operates considerably faster than 84MHz.

For instance, assuming you are using high speed synchronous serial communication (say, SPI) to transfer the data. For 16 bits of data (you won't get it to do just 14 bits using hardware and software would be way too slow) would require a transmission clock of (80000000 * 16) 1.28GHz.

If you're using a 16-bit parallel interface then you would only need an 80MHz communication clock to move the data around, but receiving that data and storing it somewhere and also processing it would require many many more instructions between each clock. Far more than the Due could perform. Certainly it's way way outside the scope of a timer interrupt.

I would suggest instead investigating systems that run in the high hundreds of Megahertz or even Gigahertz range. Maybe one of the newer "version 2" Raspberry Pi embedded computers may be suitable.

  • I thought the arduino due can send digital data at each time clock... I have to find another way. Thank you for your answer – Dubois Jérôme Sep 1 '15 at 9:09
  • The Due uses an ARM core. The ARM core is RISC. To, for example, get a byte from memory and place it on a port register takes minimum 4 instructions (load address, load data from address, load address, write data to address) and each instruction (load or store instruction) takes 1 clock cycle. That's in assembly. In C it becomes more, and as soon as you start looping you get even longer - condition tests, branches, incrementing values, etc - it may take upwards of 10 instructions with maybe 15 clock cycles for each access of the port. That would make about 5.6MHz maximum output. – Majenko Sep 1 '15 at 9:36
  • DMA might be able to do a bit better than the ARM core, but still the design seems farfetched. This is territory for an FPGA, or a very, very carefully chosen MCU. The pi is probably not a fit - the core may be fast, but that does not mean there is necessarily a suitable fast I/O interface. – Chris Stratton Dec 1 '15 at 1:56
0

May I suggest you decorrelate the acoustic frequency with the sampling frequency ?

While you need the high frequencies to get spatial resolution, what you are interested in is only the signal return amplitude (not the exact waveform), which you could sample at a much lower rate using appropriate analog front end.

  • Right, it is possible to have lower sampling rate by using the envelope of the signal (few Msps is enougth). We are doing both actually, we sample only the envelope or the complete signal to compare. But we don't use an arduino anymore. – Dubois Jérôme Jan 17 '17 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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