Due, M0 Pro, Edison GPIO speed

Hello all.

In a previous project, I needed <20 microsecond digital output response times to drive an ECU expecting a very repeatable crankshaft signal. That was a achieved using the C / PORTx trick on the forum and I ended up with a 4 microsecond resolution with an occasional 4 microsecond jitter, which worked well enough for my experiment to complete successfully.

In the interest of brevity, I have a new project in which I truly do need more speed than an Uno or Mega has available (and by speed, I mean how fast I can read and write to digital pins). I require a solid one microsecond accuracy in turning on outputs and would LIKE 1 microsecond analog reads but I understand that’s it’s own issue. If I need 1 micro, I’m shooting for hardware capable of tens of nano (10-25Mhz maybe).

I’m looking at the Due, M0 Pro, and the Edison. I don’t need many channels, just one or two in and out that I can depend on to the microsecond. Can these boards pull that off? Is there enough CPU there for maybe 20-100 lines of code to execute and not significantly influence IO timing? I was considering a Raspberry Pi using WiringPi which can achieve what I want, but I don’t really want the OS getting in the way with interrupts, etc.

Thanks for any suggestions.
Dylan

Edison and probably M0 use some tricks to simulate an Arduino in a higher-level operating system. The GHz on the processor is higher but you don't get reliable timing as a result.

I would look at doing this on a Teensy. The latest Teensy 3.6 and 3.5 have very high clock speeds and no operating system.

The arduino DUE is a powerful board clocked at 84 MHz. Therefore if you need to set or clear a PIO in a us time window, it will be very easy since this time equals to 84 clock cycles.

The real difficulty could be on the side of analog readings, i.e. :

For a single ADC channel reading, you can read 1 million samples/sec and output the data to SerialUSB. Note that there's only one ADC which is shared by 13 potential channels (A0 to A11 plus the builtin temperature sensor A15) so the effective sample rate is 1 million samples/sec for a single channel reading, 500 K samples for 2 channels readings and so on….

Assuming you would read 2 channels at a time, you will lose some accuracy, because internally the chip is having to switch between two different input signals 1 million times per second, and that won't be as good as tracking the same input all the time like a 1 channel reading. A typical workaround is to read a channel hoocked to Grnd between each "useful" channel reading but you will halve reading speed.

For allowing more processing time in the main loop, the biggest win comes through using a PDC DMA. The CPU utilization should be pretty minimal as the DMA is handled off core.

Edit: Extract from Sam3x datasheet:

43.2 Embedded Characteristics  12-bit Resolution  1 MHz Conversion Rate

Of course you need to code directly ADC registers !! (forget analogRead()) !!

For a single ADC channel reading, you can read 1 million samples/sec and output the data to SerialUSB.

Where are you getting his from?

Mark

MorganS:
I would look at doing this on a Teensy. The latest Teensy 3.6 and 3.5 have very high clock speeds and no operating system.

I had seen this name in passing but never explored these products. Thank you very much for the suggestion! I will look into it further but in general it looks promising.

I'm late to the thread, but there are benchmarks for I/O functions in this thread: http://forum.arduino.cc/index.php?topic=326944.0

MegaHertz level A/D conversions in the Arduino ecosystem (using AnalogRead()) are beyond the capability of any Arduino platform of which I'm aware. This is possible with some of the ARM core processors using continuous conversion modes. (e.g. http://www.stm32duino.com/viewtopic.php?f=19&t=107)

Thanks MrMark. I ordered a Teensy 3.6 and it arrived today. Your info and link will likely be very helpful when I start to poke around this project in the next few weeks.