which platform for data acquisition

[nazardo]

Hello
I have experience with all Microchip ranges, recently I use only pic24 and pic32. However, I did never use the most powerful families, like the Pic32 MZ EF, but now I need to develop a project with the following characteristics:
- 32bit uC
- clock between 100 and 250MHz
- TCP stack
- at least 512k RAM
- integrated flash
- low power
- no OS or eventually RTOS

what I want to do is a small data acq system (up to 4 ch 24bit streamed to udp, at the fastest data rate compatible with the device, in the range 5-10kS/s or higher)

I do not want to go to higher class controllers that come with linux because I need low level control for real time (and I need low power).

The easier solution would be to go with the PIC32MZ2048EFH100, but the problem is that Harmony really scares me. I have tried it once and I immediately went back to bare metal programming (setting registers).
Now, is there any microcontroller on the market with a decent demo without reinventing the wheel?
I investigated Renesas S7G2 but the documentation is not easy to understand.
Thank you

[rstofer]

Microchip has a very nice TCP/IP stack for the PIC32 that is related to their Ethernet Starter Kit.  I played with it a couple of years ago and rather liked it.  It supports wired or wireless.  It seems to me that the hard part of the job will be the TCP/IP stack so I would look for something that has a well documented stack.

You didn't say how you were going to grab the data from the ADC.  SPI?  Multiple SPI?

The mbed project (I use the LPC1768 version) has a port of the lwIP stack and, as a master, can easily handle 1 MHz SPI clock rates.  In fact, I have it working as a slave at 6 MHz where it packetizes SPI data (after crunching it mightly) and sends it out as TCP.  I can't say that I ever looked at the throughput.  For my application, total throughput didn't matter.

[krho]

You can look at stm32f429, which will probably come short with the required ram, but you can easily add an 8MiB SDRAM chip to it. Then you have a  nuttx with tcp/ip implementation stack.

[nazardo]

You didn't say how you were going to grab the data from the ADC.  SPI?  Multiple SPI?

I still have to choose the adc. 90% will be SPI

[nazardo]

You can look at stm32f429, which will probably come short with the required ram, but you can easily add an 8MiB SDRAM chip to it. Then you have a  nuttx with tcp/ip implementation stack.

will the external ram be accessible by DMA?

[krho]

Application note Page #17

[MosherIV]

App note does not say whether the external RAM can be DMAed.

I have not used the F429 for anything so I do not know (cannot remember) what the external RAM controller peripheral is called.
It is likely to be on the AHA or AHB bus - which can be DMAed.

I do not know if the external RAM controller has any interaction with the DMA engines, I would have thought it does.

[Marco]

Why not pick one of the STM32's with more memory? They have a Nucleo and Discovery board for it.

[hans]

To me the specs seem a bit excessive and/or written down like you're married to PIC32MZ.

I've built a DC power meter (basically 1-ch data acquisition) on a STM32F407 at 150MHz. It samples an 16-bit ADC at 550ksps and sends the raw data out over UDP. Unfortunately most TCP/IP stacks I found were right on the limit for this chip and bandwidth level, that I opted for UDP.  Because packet loss is inevitable for UDP (and I couldn't have that), I buffered each sent data frame in a circular buffer block system, on 4Mbit of external SRAM. This buffers data for a few tenths of a second, which is more than enough time for a python script or PC application to signal that a particular expected frame ID timed out. Each frame is ~1kiB.

I used DMA to transfer SPI data to the RAM buffers, while using a timer/external interrupt input. By using DMA straight on the UDP payload buffer I also avoided 1 memcpy. However, you do need to keep several UDP buffers, because in my case the ethernet was a separate OS task that needed to "pick up" these buffers at it's own rate.
All in all at 550ksps and DMA it only took 10-12% of CPU (measured from RTOS using an idle counter).

In a later stage I added 2 digital inputs as well. It started a DMA transfer from a GPIO port using the external ADC timebase, which it then parsed to put 8 digital samples into 1 byte (compression). I then packed this data at the end of each frame.
This addition was quite CPU heavy as you can imagine, however with a tightly written loop and local GCC O3 optimisation it only added 20% CPU usage. I suppose 30MIPS is fair to process 1.1MSPS of data, but not exceptional (27 cycles/sample).

Going back to your requirements:
10ksps on a 150MHz chip with 512KB of SRAM seems out of proportion. SRAM isn't even the biggest issue; badly written code is. Repetitive, real-time code needs to be fast and predictable. I first tried this project with interrupts but gave up because I was stuck at 250ksps. The delay from entering an interrupt, starting SPI transfer, bus delays, reading & saving the sample took way too long.

If you want to use 4 ADC's you may not be able to use DMA that easily because of bus collisions. But also think about reasserting chip-select on each transfer. In my case I used a trick in hardware to use the interrupt output of the ADC to chip-select itself. The STM32F407  couldn't generate chip select signals on a DMA stream, maybe newer chips have more options.

Also like I said 512K of SRAM is a pretty unique spec to PIC32MZ, which marries you to that chip. However you can achieve that or more RAM on any flag-ship ARM cortex chip though by adding external S(D)RAM, however that requires a load of wires on the PCB. You can use DMA transfer on external SRAM; STM32 has memory-to-memory transfers. On STM32 (and many other ARM chips; not sure about PIC32MZ without looking it up) the external SRAM integrates completely into the memory space.

The rest of your specs seem quite reasonable; although not sure what "low power" is. Remember that ethernet is pretty energy hungry because of termination on the ethernet wiring.

[Marco]

Also like I said 512K of SRAM is a pretty unique spec to PIC32MZ

He mentioned the Renesas already, but as I said there's STM32s with 512k RAM too.

[hans]

Ah yes my bad, not familiar with Renesas portfolio actually because I have never seen any of their tools/IDE's at all. I see the STM32F7 micro's are already at 512K of RAM. I was only familiarizing myself with the STM3F74x parts, that have 320K RAM or so.

Neat, that gives maybe a handful of options.
Still unsure if such a CPU is not overkill for this application, unless he needs to do some serious number crunching on the CPU itself I'm not aware of.

[JPortici]

Why it has to be STM?
I have to do a small data logger (Voltage/Current and other data from the attached device via a serial port) and i decided to do it with an ARM chip.
Programming STM32 makes me sick so i looked at the NXP offerings.
You have a choice of smaller packages, on average more ram than STM and very good prices too.
Then when it comes to the IDE you can download one single piece of software and you are good to go. It also looks like to be easier to write software with them

[nazardo]

..
If you want to use 4 ADC's you may not be able to use DMA that easily because of bus collisions.

...

I was considering using a 4-channel adc, for example AD7768. It also has parallel interface, but I do not think there is an advantage using it against SPI. Correct me if I am wrong.
Or, another candidate is AD1274.