Data acquisition microcontroller recommendation

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Evening all,

 

First post on this site, which seems about right, as I'm also very new to microcontrollers.

 

I'm currently prototyping a data acquisition product, which up until very recently, was going to rely on the underlying Embedded Linux OS for acquiring the data (in conjunction with processing, user input, GUI, storage, etc.). Through extensive testing, I've come to the conclusion that Linux really isn't suited to my particular application, so I'm turning my attention to microcontrollers.

 

The requirements of my device, which would need to be supported by the MCU are as follows:

 

  1. 32 analogue inputs, preferably 16-bit, capable of at least 1000 samples per second per channel.
  2. 32 digital inputs, capable of 1000 samples per second per channel, with hardware-driven, low latency interrupts
  3. As many CAN channels as possible
  4. As many SPI channels as possible

 

The analogue inputs are somewhat self explanatory. The digital inputs can be configured by the end user as either simple ON/OFF measurement, or pulse measurement (frequency, duty cycle, etc.). As such, discrete hardware interrupts on all 32 inputs are required. This is an area in which working with Linux was problematic, as userspace interrupts are essentially polls to the kernel, and carry significant latency between the interrupt occurring, and the handler being called by the scheduler. I'm hoping an MCU will provide much more efficient and fast interrupts for this purpose.

 

In terms of peripherals, as many CAN and SPI channels as possible would be ideal. Similarly, a high speed bus for transferring the captured data to my SoM is required. In my mind a parallel interface would probably make sense for this purpose, but I'm happy to be proven wrong if serial is preferred. In terms of storage, I haven't yet calculated the required memory size, so I'm open to some suggestion on that one (cost vs. benefit). Ideally I'd store x readings in a buffer, and routinely transfer the data to the SoM. I imagine a couple of MB would be suitable for this purpose?

 

As mentioned earlier, I'm completely new to microcontrollers, so don't even know where to start looking. I've developed for desktop and embedded ARM, but haven't even really played with an Arduino, so this is all very new to me.

 

Any guidance (product families, readings, blog posts, etc.) at this stage would be greatly appreciated!

 

EDIT: I forgot to mention above; the 32 analogue and 32 digital inputs don't have to be included in the MCU itself, I can't imagine there are too many options with that many ADCs available, I fully expect for the MCU to interface with external ADCs and IO expanders to facilitate the 64 inputs (via SPI, I2C, etc.).

Last Edited: Thu. Jun 7, 2018 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
I've developed for desktop and embedded ARM, but haven't even really played with an Arduino,
Your requirements sound too much for Arduino or any other 8  bit AVR. I'd be looking at some kind of cortex/ARM - which it sounds like you may be familiar with already.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Beaglebone might be a candidate. Runs linux and the chip has two 200MHz cpus for i/o grunt work along with a couple of can interfaces, a/d etc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
1. 32 analogue inputs, preferably 16-bit, capable of at least 1000 samples per second per channel.
XMEGA E5 has 16 12-bit ADC channels with oversample and decimate to 16b (300ksps / 256 = 1.17ksps), one ADC, DMA.

jars121 wrote:
2. 32 digital inputs, capable of 1000 samples per second per channel, with hardware-driven, low latency interrupts

...

4. As many SPI channels as possible

XMEGA A1U - 4 SPI or 8 USART, DMA, DMAC can read an 8-bit port into memory, 4 channel DMAC, a timer can generate the 1000sps event to the DMAC.

All but XMEGA D have DMA as an alternative to polling or interrupts.

XMEGA DMAC is "low" on channels; more recent MCU have a significantly greater number of DMA channels.

jars121 wrote:
As such, discrete hardware interrupts on all 32 inputs are required.
any somewhat recent AVR in larger packages

jars121 wrote:
This is an area in which working with Linux was problematic, as userspace interrupts are essentially polls to the kernel, and carry significant latency between the interrupt occurring, and the handler being called by the scheduler.
real-time variants of the Linux kernel one of which (20y ago?) controlled a magnetic bearing at about 10KHz.

jars121 wrote:
I'm hoping an MCU will provide much more efficient and fast interrupts for this purpose.
Some MCU manufacturers are combining an application processor and a MCU on one chip.

jars121 wrote:
I imagine a couple of MB would be suitable for this purpose?
XMEGA A1U has an EBI with control for SRAM or SDRAM.

Some 2MB MRAM (an SRAM interface) is automobile qualified to 125C (XMEGA A1U is to 105C though not automobile qualified)

 

P.S.

jars121 wrote:
Similarly, a high speed bus for transferring the captured data to my SoM is required.
fyi, Microchip recently announced an arm Cortex-A5 SoM with enough flash for an embedded Linux.

http://www.microchip.com/design-centers/32-bit-mpus/sip-and-som/system-on-module-(som)

http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d27Som1EKMainPage#Demo_archives

http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime

 


https://www.microchip.com/wwwproducts/en/ATxmega32E5

https://www.microchip.com/wwwproducts/en/ATxmega128A1U

https://www.everspin.com/family/mr4a08b?npath=258

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From your requirements PXI may be a good way to go.

 

PXI is an industrial version of the PCI bus, adopted for measurement equipment.

https://en.wikipedia.org/wiki/PCI_eXtensions_for_Instrumentation

 

PXI systems do tend to have a few disadvantages. They are pretty bulky and expensive ( USD10.000 for a complete system is no exception).

jars121 wrote:
Through extensive testing, I've come to the conclusion that Linux really isn't suited to my particular application, so I'm turning my attention to microcontrollers.
Have you tried linux versions with real-time extensions?

Machinekit is a Linux distribution & CNC application combined in a single package and runs on (among other things) on the Beaglebone Black. The CNC stuff is "just an application" but the integration of the real-time kernel in that linux distribution might be interesting for you.

 

jars121 wrote:
32 analogue inputs, preferably 16-bit, capable of at least 1000 samples per second per channel. 32 digital inputs, capable of 1000 samples per second per channel, with hardware-driven, low latency interrupts As many CAN channels as possible As many SPI channels as possible

Why would you need "many" of these? CAN is a shared bus and a lot of nodes can be connected.

With SPI you can share the same bus with many peripherals by multiplying the Chip seleclt line (A few 74HC138).

Take the ADS1118 (for example). It is a rather nice ADC:

- 860sps (slightly below your required 1k).

- 1x to 32 bit PGA.

- Build in Voltage reference.

- "only" 16 bit, but ENOB and INL seems to be a lot better than from a bunch of other ADC'.

 

The SPI bus on this chip can run up to 4MHz, so you can put a lot of these on the same bus before the bandwidht runs out.

 

Needed bandwith estimation:

32 * 16 * 1000 = 512kB/s

32 / 8 * 1000 = 4kB/s

 

I am confused by:

jars121 wrote:
In terms of peripherals, as many CAN and SPI channels as possible would be ideal.
Do you want 100's or thousand's of those busses? Or do you primarily need them for the analog / digital inputs already mentioned earlier?

 

While writing this I realize the total data rate is not very high and PXI is probably overikill.

What is the total data rate that your system needs to acquire?

You may want to have a look at PC104 (Still alive and kicking).

 

Another rather elegant option may be to use some (industrial) PC with a bunch of USB hubs and use a few handfulls of microcontrollers each connected with USB to the main PC. The Microcontrollers could do some extra work (Apply callibration data for the ADC's, filtering), and they could all be tied to for example a 1kHz clock line to synchronize them.

 

Systems lik Raspi's and Beaglebones have a bunch of SPI busses, Connect a handfull of Microcontrollers to each SPI bus and a bunch of ADC's to each uC.

Is this what you had in mind while posting?

 

I never had a need to look into uC's with High - speed USB (480Mbit/s), but a uC that can handle that amount of data is bound to have a whole lot of peripherals.

 

PC's such as the beaglebone are so cheap nowadays that you can easily afford to put a bunch of them in your system, and connect them all through Ethernet.

 

Have you tried usig a Linux board without a GUI as a data acquisition frontend?

The GUI is probably the squarest cog in the gearbox for real time performance.

A small application would only have to gather the data (do some processing) and send the data along over Ethernet to another node that runs the GUI.

 

Lots of idea's, but I hardly know what you want to build.

Hope it is usefull.

 

Edit:

Have you considered:

https://duckduckgo.com/html?q=be...

I do not know what it would take to get started this way, but you have the whole Sittara processor for your own application.

(And get way more processing power / bandwidth than you need).

 

A Decent Arm cortex is probably all you need Something like the stSAM or ST32F4xx series

 

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Thu. Jun 7, 2018 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
I never had a need to look into uC's with High - speed USB (480Mbit/s), but a uC that can handle that amount of data is bound to have a whole lot of peripherals.
An ARM9 with a USB3 controller, up to 512KB of local SRAM, and a bus for interfacing with CPLD, FPGA, image sensor, etc :

Cypress Semiconductor

CYUSB301X, CYUSB201X: EZ-USB® FX3: SuperSpeed USB Controller

http://www.cypress.com/documentation/datasheets/cyusb301x-cyusb201x-ez-usb-fx3-superspeed-usb-controller

via

Sysprogs

Turning the Cypress Super Speed Explorer Kit into a Continuous 200MS/s Logic Analyzer

https://sysprogs.com/w/turning-the-cypress-super-speed-explorer-kit-into-a-continuous-200mss-logic-analyzer/

A CPLD or FPGA can aggregate data that's DMA'd to the USB3 controller.

There might be CAN controller HDL though might be easier to attach as many CAN PIC or CAN megaAVR as is necessary.

 

P.S.

FOSS FPGA development software :

Icestorm

by joeymorin

https://www.avrfreaks.net/forum/icestorm

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
A small application would only have to gather the data (do some processing) and send the data along over Ethernet to another node that runs the GUI.
Some MCU have enough memory (local or external) and compute power to run a WebSocket server; a web browser is the operator's interface.

Real Time Logic

Embedded WebSocket Server

https://realtimelogic.com/products/sharkssl/minnow-server/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest having a look at the SAM E70. It's probably the most powerful micro controller that Atmel/Microchip offers right now (I consider ARM A devices to be micro processors, not controllers).

The E70 contains an ARM Cortex M7 core, running at up to 300 MHz, 384 KByte of RAM and 2 MByte flash. It's got 2 dedicated SPI controllers, 3 USART controllers which can also be used for SPI and 2 CAN interfaces. There are however only 24 ADC channels available, connected to two actual ADCs with 2 MSa/s each.

It also features a high speed USB interface, which is indeed capable of reaching more than 40 MByte/s. So connecting it to your SoM should be no problem. A vendor device class example for the USB library is available and it's easy to understand. I just used it in my bachelor's thesis.

And the best of it all: There's a development kit available with an on-board debugger, external RAM and Ethernet for somewhere around 40 USD.

STMicroelectronics offers a similar device: The STM32F723IE is also a Cortex M7 device with slightly lower specs on speed and memory, but with a bit better ADCs. The dev kit for that controller is also around 40 USD and is very interesting.

-Patrick

 

 

"Some people die at 25 and aren't buried until 75." -Benjamin Franklin

 

What is life's greatest illusion?"  "Innocence, my brother." -Skyrim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If there is a shortage of ADC pins, you can always consider using analog single pole n-throw switches (i.e. multiplexers).

For example: http://www.ti.com/product/TS3A5017

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you everyone for your considered, timely responses. I've tried to address each of your comments below.

 

clawson wrote:

jars121 wrote:
I've developed for desktop and embedded ARM, but haven't even really played with an Arduino,
Your requirements sound too much for Arduino or any other 8  bit AVR. I'd be looking at some kind of cortex/ARM - which it sounds like you may be familiar with already.

 

I've been looking into Cortex Mx options, so I think we're on the same page there.

 

Kartman wrote:
Beaglebone might be a candidate. Runs linux and the chip has two 200MHz cpus for i/o grunt work along with a couple of can interfaces, a/d etc

 

I've used the BBB previously, and agree it's quite a capable unit, but it doesn't fit the form factor requirements in this case unfortunately. The production SoM will be a Toradex iMX6/7 module installed in a custom carrier board; I'm thinking the custom carrier board will host the discrete MCU chip.

 

gchapman wrote:

jars121 wrote:
1. 32 analogue inputs, preferably 16-bit, capable of at least 1000 samples per second per channel.
XMEGA E5 has 16 12-bit ADC channels with oversample and decimate to 16b (300ksps / 256 = 1.17ksps), one ADC, DMA.

jars121 wrote:
2. 32 digital inputs, capable of 1000 samples per second per channel, with hardware-driven, low latency interrupts

...

4. As many SPI channels as possible

XMEGA A1U - 4 SPI or 8 USART, DMA, DMAC can read an 8-bit port into memory, 4 channel DMAC, a timer can generate the 1000sps event to the DMAC.

All but XMEGA D have DMA as an alternative to polling or interrupts.

XMEGA DMAC is "low" on channels; more recent MCU have a significantly greater number of DMA channels.

jars121 wrote:
As such, discrete hardware interrupts on all 32 inputs are required.
any somewhat recent AVR in larger packages

jars121 wrote:
This is an area in which working with Linux was problematic, as userspace interrupts are essentially polls to the kernel, and carry significant latency between the interrupt occurring, and the handler being called by the scheduler.
real-time variants of the Linux kernel one of which (20y ago?) controlled a magnetic bearing at about 10KHz.

jars121 wrote:
I'm hoping an MCU will provide much more efficient and fast interrupts for this purpose.
Some MCU manufacturers are combining an application processor and a MCU on one chip.

jars121 wrote:
I imagine a couple of MB would be suitable for this purpose?
XMEGA A1U has an EBI with control for SRAM or SDRAM.

Some 2MB MRAM (an SRAM interface) is automobile qualified to 125C (XMEGA A1U is to 105C though not automobile qualified)

 

P.S.

jars121 wrote:
Similarly, a high speed bus for transferring the captured data to my SoM is required.
fyi, Microchip recently announced an arm Cortex-A5 SoM with enough flash for an embedded Linux.

http://www.microchip.com/design-centers/32-bit-mpus/sip-and-som/system-on-module-(som)

http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d27Som1EKMainPage#Demo_archives

http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime

 


https://www.microchip.com/wwwproducts/en/ATxmega32E5

https://www.microchip.com/wwwproducts/en/ATxmega128A1U

https://www.everspin.com/family/mr4a08b?npath=258

 

 

Thanks gchapman, you've provided a fair bit for me to go through here. The SAM A5 module you linked looks particularly interesting; I was looking at the ATSAMV71Q21 (and related products) yesterday, as there's quite a nice development board available which would certainly make prototyping easier.

 

Paulvdh wrote:

From your requirements PXI may be a good way to go.

 

PXI is an industrial version of the PCI bus, adopted for measurement equipment.

https://en.wikipedia.org/wiki/PCI_eXtensions_for_Instrumentation

 

PXI systems do tend to have a few disadvantages. They are pretty bulky and expensive ( USD10.000 for a complete system is no exception).

jars121 wrote:
Through extensive testing, I've come to the conclusion that Linux really isn't suited to my particular application, so I'm turning my attention to microcontrollers.
Have you tried linux versions with real-time extensions?

Machinekit is a Linux distribution & CNC application combined in a single package and runs on (among other things) on the Beaglebone Black. The CNC stuff is "just an application" but the integration of the real-time kernel in that linux distribution might be interesting for you.

 

jars121 wrote:
32 analogue inputs, preferably 16-bit, capable of at least 1000 samples per second per channel. 32 digital inputs, capable of 1000 samples per second per channel, with hardware-driven, low latency interrupts As many CAN channels as possible As many SPI channels as possible

Why would you need "many" of these? CAN is a shared bus and a lot of nodes can be connected.

With SPI you can share the same bus with many peripherals by multiplying the Chip seleclt line (A few 74HC138).

Take the ADS1118 (for example). It is a rather nice ADC:

- 860sps (slightly below your required 1k).

- 1x to 32 bit PGA.

- Build in Voltage reference.

- "only" 16 bit, but ENOB and INL seems to be a lot better than from a bunch of other ADC'.

 

The SPI bus on this chip can run up to 4MHz, so you can put a lot of these on the same bus before the bandwidht runs out.

 

Needed bandwith estimation:

32 * 16 * 1000 = 512kB/s

32 / 8 * 1000 = 4kB/s

 

I am confused by:

jars121 wrote:
In terms of peripherals, as many CAN and SPI channels as possible would be ideal.
Do you want 100's or thousand's of those busses? Or do you primarily need them for the analog / digital inputs already mentioned earlier?

 

While writing this I realize the total data rate is not very high and PXI is probably overikill.

What is the total data rate that your system needs to acquire?

You may want to have a look at PC104 (Still alive and kicking).

 

Another rather elegant option may be to use some (industrial) PC with a bunch of USB hubs and use a few handfulls of microcontrollers each connected with USB to the main PC. The Microcontrollers could do some extra work (Apply callibration data for the ADC's, filtering), and they could all be tied to for example a 1kHz clock line to synchronize them.

 

Systems lik Raspi's and Beaglebones have a bunch of SPI busses, Connect a handfull of Microcontrollers to each SPI bus and a bunch of ADC's to each uC.

Is this what you had in mind while posting?

 

I never had a need to look into uC's with High - speed USB (480Mbit/s), but a uC that can handle that amount of data is bound to have a whole lot of peripherals.

 

PC's such as the beaglebone are so cheap nowadays that you can easily afford to put a bunch of them in your system, and connect them all through Ethernet.

 

Have you tried usig a Linux board without a GUI as a data acquisition frontend?

The GUI is probably the squarest cog in the gearbox for real time performance.

A small application would only have to gather the data (do some processing) and send the data along over Ethernet to another node that runs the GUI.

 

Lots of idea's, but I hardly know what you want to build.

Hope it is usefull.

 

Edit:

Have you considered:

https://duckduckgo.com/html?q=be...

I do not know what it would take to get started this way, but you have the whole Sittara processor for your own application.

(And get way more processing power / bandwidth than you need).

 

A Decent Arm cortex is probably all you need Something like the stSAM or ST32F4xx series

 

 

 

Thank you Paulvdh, you've provided a lot for me to consider here. I'm currently using an array of NI PCI DAQ cards, and had previously researched the PXI equivalents, so I'm no stranger to the capabilities of the PXI platform. As you mentioned in your post, the required bandwidth of my device is quite minimal, so a PXI-based solution would certainly be overkill. As mentioned in some of the other responses, I believe a standard USB interface between the MCU and my SoM would be sufficient for the bandwidth I require. As per my earlier response above, the RPi and Beaglebone options are solid, and I've used them in previous projects, but the form factor for this particular device disallows the use of multiple PCBs. I will have a single, custom PCB, in which a Toradex SoM module will be installed. All analogue, digital, CAN, etc. interfaces will terminate at connectors on this PCB.

 

As per above, the SAM family have already caught my attention, but I'll be sure to give the ST32F4xx series a thorough review this morning as well.

 

gchapman wrote:

Paulvdh wrote:
I never had a need to look into uC's with High - speed USB (480Mbit/s), but a uC that can handle that amount of data is bound to have a whole lot of peripherals.
An ARM9 with a USB3 controller, up to 512KB of local SRAM, and a bus for interfacing with CPLD, FPGA, image sensor, etc :

Cypress Semiconductor

CYUSB301X, CYUSB201X: EZ-USB® FX3: SuperSpeed USB Controller

http://www.cypress.com/documentation/datasheets/cyusb301x-cyusb201x-ez-usb-fx3-superspeed-usb-controller

via

Sysprogs

Turning the Cypress Super Speed Explorer Kit into a Continuous 200MS/s Logic Analyzer

https://sysprogs.com/w/turning-the-cypress-super-speed-explorer-kit-into-a-continuous-200mss-logic-analyzer/

A CPLD or FPGA can aggregate data that's DMA'd to the USB3 controller.

There might be CAN controller HDL though might be easier to attach as many CAN PIC or CAN megaAVR as is necessary.

 

P.S.

FOSS FPGA development software :

Icestorm

by joeymorin

https://www.avrfreaks.net/forum/icestorm

 

 

Thanks again gchapman. I'll give each of those links a thorough review.

 

gchapman wrote:

Paulvdh wrote:
A small application would only have to gather the data (do some processing) and send the data along over Ethernet to another node that runs the GUI.
Some MCU have enough memory (local or external) and compute power to run a WebSocket server; a web browser is the operator's interface.

Real Time Logic

Embedded WebSocket Server

https://realtimelogic.com/products/sharkssl/minnow-server/

 

 

The GUI is probably the least of my concerns at this point in time, and I should have provided more detail on this in the original post. My GUI is written in c/c++ using the Qt5 framework. As mentioned above, my production unit will be based on a Toradex iMX6/7 module, running a custom Linux OS (to be developed with Yocto). As such, the front-end of this device is more or less understood and planned, it's really only the data acquisition side of the equation which requires some further thought.

 

El Tangas wrote:

If there is a shortage of ADC pins, you can always consider using analog single pole n-throw switches (i.e. multiplexers).

For example: http://www.ti.com/product/TS3A5017

 

Thanks El Tangas. I've used multiplexers for this purposes previously, but would hope to be able to use SPI ADCs without multiplexing in the first instance. I'm planning on using the ADS1158, which is a 16-channel, 16-bit ADC with >100ksps capability. Two of these on an SPI bus would provide the required 32 analogue inputs at 1ksps per channel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pawi777 wrote:

I suggest having a look at the SAM E70. It's probably the most powerful micro controller that Atmel/Microchip offers right now (I consider ARM A devices to be micro processors, not controllers).

The E70 contains an ARM Cortex M7 core, running at up to 300 MHz, 384 KByte of RAM and 2 MByte flash. It's got 2 dedicated SPI controllers, 3 USART controllers which can also be used for SPI and 2 CAN interfaces. There are however only 24 ADC channels available, connected to two actual ADCs with 2 MSa/s each.

It also features a high speed USB interface, which is indeed capable of reaching more than 40 MByte/s. So connecting it to your SoM should be no problem. A vendor device class example for the USB library is available and it's easy to understand. I just used it in my bachelor's thesis.

And the best of it all: There's a development kit available with an on-board debugger, external RAM and Ethernet for somewhere around 40 USD.

STMicroelectronics offers a similar device: The STM32F723IE is also a Cortex M7 device with slightly lower specs on speed and memory, but with a bit better ADCs. The dev kit for that controller is also around 40 USD and is very interesting.

-Patrick

 

 

 

My apologies Patrick, I seem to have missed your comment in my previous response. Thanks for your input! You've touched on a particularly important consideration for me, which is the ability to prototype with a dev kit. I'll give each of your suggestions a thorough review. In terms of 24 ADC channels, I'm happy to use external ADCs via SPI anyway, so I'm not put off the E70 in any way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pawi777 wrote:
I suggest having a look at the SAM E70. It's probably the most powerful micro controller that Atmel/Microchip offers right now ...
Concur with its competition being PIC32MZ (has a MMU, can run LiteBSD)

https://github.com/sergev/LiteBSD

pawi777 wrote:
The dev kit for that controller is also around 40 USD and is very interesting.
fyi, it may have an Ada run-time :

https://github.com/AdaCore/bb-runtimes/tree/gpl-2017/arm/stm32/stm32f7x

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
I'll give each of your suggestions a thorough review

 

Should you decide to use one of those two or a related part and use the USB features, here are two additional inputs that hopefully will save you some of the trouble we had:

 

For the SAM E70: We discovered that USB does not work if the ASF code is compiled with -O3. It also appears to be malfunction if the caches are enabled. It's probably a timing issue during initialization, but we never took the time to investigate any further.

 

For the STM32F723: Be careful with the USB FIFOs. They need to be set up for each TX pipe and once for all RX pipes together(or maybe it was vice versa). You have a limited amount of dedicated memory available. If total of assigned FIFO memory is larger than what's actually available, there can be race conditions between sending an receiving data, resulting in sporadic CRC errors on the packet level of the USB protocol. This is very hard to find without a USB logic analyzer. So if anything seems unreliable with the USB connection, review your FIFO settings. Also: Check out the CubeMX code generator, it's very convenient for generating initialization code for the peripherals and pins.

 

-Patrick

 

 

"Some people die at 25 and aren't buried until 75." -Benjamin Franklin

 

What is life's greatest illusion?"  "Innocence, my brother." -Skyrim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
pawi777 wrote:
I suggest having a look at the SAM E70. It's probably the most powerful micro controller that Atmel/Microchip offers right now ...
Concur with its competition being PIC32MZ (has a MMU, can run LiteBSD)

 

That's a really nice chip! If I had known about that 10 weeks earlier...

As for performance, according to Wikipedia (https://en.wikipedia.org/wiki/Li...), a Cortex M7 reaches 2.14 DMIPS/MHz. So that's 642 DMIPS at 300 MHz. The PIC has "only" 415 DMIPS. So the SAM E70 seems to win by far.

I suppose that this performance is quite theoretical however. I'd LOVE to see a comparison with a selection of a few different real world applications!

I'm still a bit skeptical whether ARM is really always the way to go. Many MCU manufacturers seem to think so right now...

 

-Patrick

 

Edit: quote of a quote was broken

Edit 2: I broke it even harder cheeky

"Some people die at 25 and aren't buried until 75." -Benjamin Franklin

 

What is life's greatest illusion?"  "Innocence, my brother." -Skyrim

 

Last Edited: Thu. Jun 7, 2018 - 10:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

pawi777 wrote:
I suggest having a look at the SAM E70. It's probably the most powerful micro controller that Atmel/Microchip offers right now ...
Concur with its competition being PIC32MZ (has a MMU, can run LiteBSD)

https://github.com/sergev/LiteBSD

pawi777 wrote:
The dev kit for that controller is also around 40 USD and is very interesting.
fyi, it may have an Ada run-time :

https://github.com/AdaCore/bb-runtimes/tree/gpl-2017/arm/stm32/stm32f7x

 

 

Thanks gchapman, I'll give the PIC a good looking through as well.

 

pawi777 wrote:

jars121 wrote:
I'll give each of your suggestions a thorough review

 

Should you decide to use one of those two or a related part and use the USB features, here are two additional inputs that hopefully will save you some of the trouble we had:

 

For the SAM E70: We discovered that USB does not work if the ASF code is compiled with -O3. It also appears to be malfunction if the caches are enabled. It's probably a timing issue during initialization, but we never took the time to investigate any further.

 

For the STM32F723: Be careful with the USB FIFOs. They need to be set up for each TX pipe and once for all RX pipes together(or maybe it was vice versa). You have a limited amount of dedicated memory available. If total of assigned FIFO memory is larger than what's actually available, there can be race conditions between sending an receiving data, resulting in sporadic CRC errors on the packet level of the USB protocol. This is very hard to find without a USB logic analyzer. So if anything seems unreliable with the USB connection, review your FIFO settings. Also: Check out the CubeMX code generator, it's very convenient for generating initialization code for the peripherals and pins.

 

-Patrick

 

 

 

Thanks Patrick, I owe you big time! I'm reading through the SAME70 datasheet at the moment, and it appears to be (with the limited understanding I have of the device so far) a perfect fit. The development kit also looks like exactly what I'm after; I can't believe how inexpensive it is.

 

What I haven't been able to determine as of yet is how interrupts are handled on the E70s. Are you able to shed some light on this? I see there are a couple of IRQ pins, but I'm not sure how I'd setup interrupt handlers for multiple GPIOs. Speaking of which, if I were able to piece together 32 GPIOs through both dedicated GPIO pins and alternate function pins on the E70, can interrupts be established for each? If not, how would I approach this? Can I use a multiplexer and have interrupts handled for inputs coming through a multiplexer somehow?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pawi777 wrote:
So the SAM E70 seems to win by far.
SAM E70 got the design win for PICkit 4 :

https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=1#comment-2407426

pawi777 wrote:
I'm still a bit skeptical whether ARM is really always the way to go.
One competitor is Cadence Tensilica by Espressif Systems in ESP32 and its variants.

Wouldn't be surprised if the ones at Microchip want to partner in the MIPS design infrastructure (keep MIPS alive though MIPS is common in routers and set-top-boxes ... hope MIPS doesn't become a hot potato)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
I've used the BBB previously, and agree it's quite a capable unit, but it doesn't fit the form factor requirements in this case unfortunately.
BeagleBone in a package :

https://www.avrfreaks.net/forum/embedded-linux-modules?page=1#comment-2477406

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

jars121 wrote:
I've used the BBB previously, and agree it's quite a capable unit, but it doesn't fit the form factor requirements in this case unfortunately.
BeagleBone in a package :

https://www.avrfreaks.net/forum/embedded-linux-modules?page=1#comment-2477406

 

 

Ok now that is cool!

 

At this stage I'm probably going to pick up the SAME70 dev kit, as it appears to be well suited, but I'll keep this one in mind as well. Thanks!

 

In regards to my previous comment about GPIO interrupts, the following statement is on the second page of the E70 datasheet:

 

Quote:

Up to 114 I/O lines with external interrupt capability (edge- or level-sensitivity), debouncing, glitch

filtering and On-die Series Resistor Termination

 

I'll need to investigate further, but that sounds promising. Hopefully I can squeeze 32 GPIOs out of the 114 available, given the USB, etc. functionality I'll also need.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The requirement for 32x 16-bit ADCs with an effective per-channel sample rate of 1000Hz is challenging on several fronts.

 

First, I don't think that anyone makes a micro with 32 ADCs (of any resolution). The standard mechanism is to use a multiplexer with a single ADC (though there are a few with 2 or more ADCs out there). Using a mux now pushes you to an ADC with a 32KHz sample rate. This is not unheard of, by itself, but when you then couple that with 16-bit resolution, I'd bet that you are SOL, plain and simple. 

 

In fact, to get that kind of resolution inexpensively and at modest power levels, most semiconductor houses now use successive approximation ADCs. You can get that sample rate, but they are notoriously bad performers when multiplexed. 

 

IMHO, your best bet is to go with at least 4 external mux'd ADCs on a fast bus (say SPI or 8-bit parallel) that have the sample rate and resolution. Once you do this, it will free up your MCU selection, big time. It won't let you use an AVR, probably, but something in the 32-bit class (such as Cortex) should fly pretty well.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Systems lik Raspi's and Beaglebones have a bunch of SPI busses, ...
fyi, Raspberry Pi has an Ada run-time.

Could likewise do bare-board C.

 

https://github.com/AdaCore/bb-runtimes/tree/gpl-2017/arm/rpi2

https://github.com/AdaCore/bb-runtimes/tree/gpl-2017/aarch64/rpi3

FOSDEM 2017

64 bit Bare Metal Programming on RPI-3

by Tristan Gingold

https://archive.fosdem.org/2017/schedule/event/programming_rpi3/

via

The AdaCore Blog

AdaCore attends FOSDEM

Feb 22, 2017

https://blog.adacore.com/adacore-attends-fosdem

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

The requirement for 32x 16-bit ADCs with an effective per-channel sample rate of 1000Hz is challenging on several fronts.

 

First, I don't think that anyone makes a micro with 32 ADCs (of any resolution). The standard mechanism is to use a multiplexer with a single ADC (though there are a few with 2 or more ADCs out there). Using a mux now pushes you to an ADC with a 32KHz sample rate. This is not unheard of, by itself, but when you then couple that with 16-bit resolution, I'd bet that you are SOL, plain and simple. 

 

In fact, to get that kind of resolution inexpensively and at modest power levels, most semiconductor houses now use successive approximation ADCs. You can get that sample rate, but they are notoriously bad performers when multiplexed. 

 

IMHO, your best bet is to go with at least 4 external mux'd ADCs on a fast bus (say SPI or 8-bit parallel) that have the sample rate and resolution. Once you do this, it will free up your MCU selection, big time. It won't let you use an AVR, probably, but something in the 32-bit class (such as Cortex) should fly pretty well.

 

Jim

 

Jim,

 

Thank you for your input, it's very much appreciated. I had come to the same conclusion as you regarding ADC throughout and resolution on the MCU itself. As such, I'll be using 2 ADS1158's on an SPI bus. These ADCs offer 16-channels (8 differential/16 single ended) at 16-bit resolution, and can offer 20+ksps per channel (depending on the mode). This approach, while rather expensive (~AUD$15/ADC), should provide the speed and resolution I'm after.

 

To your latter point regarding Cortex vs. AVR; I'm firmly in the Cortex camp at this point. Per the above recommendations and discussions, I'm going to go with the SAME70Q21 MCU for the time being. I'm reading through the datasheet at the moment, but it's going to take a while to get through all 2212 pages!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
It won't let you use an AVR, probably, but something in the 32-bit class (such as Cortex) should fly pretty well.
16b MCU with 16b sigma-delta ADC :

https://www.microchip.com/wwwproducts/en/PIC24FJ128GC010

via http://www.microchip.com/maps/Microcontroller.aspx

Its competitor :

http://www.ti.com/product/MSP430FG6626/datasheet/specifications#SLAS874ec36856

 

MSP430TM advantages are it's in FSF GCC and its debugger software interface is zero price, multi-platform, and monolithic.

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/MSP430-Options.html

http://www.ti.com/tool/MSP430-GCC-OPENSOURCE

http://www.ti.com/tool/MSPDS

http://gnutoolchains.com/msp430/

https://visualgdb.com/w/tutorials/category/tutorials/embedded/msp430/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
Per the above recommendations and discussions, I'm going to go with the SAME70Q21 MCU for the time being.
https://github.com/atmelcorp/atmel-software-package/tree/master/target/samv71

if bare-board instead of an RTOS or event framework.

 


https://www.microchip.com/wwwproducts/en/ATSAME70Q21

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

jars121 wrote:
Per the above recommendations and discussions, I'm going to go with the SAME70Q21 MCU for the time being.
https://github.com/atmelcorp/atmel-software-package/tree/master/target/samv71

if bare-board instead of an RTOS or event framework.

 


https://www.microchip.com/wwwproducts/en/ATSAME70Q21

 

 

Great, thanks gchapman, I'll give that a good read as well :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

The requirement for 32x 16-bit ADCs with an effective per-channel sample rate of 1000Hz is challenging on several fronts.

 

First, I don't think that anyone makes a micro with 32 ADCs (of any resolution)..... 

 

Well, actually they do...   :)

 

Digikey finds  38 results, for ADCs of 45-77 channels (!) and all 16bit..., from NXP Kinetis series, K60 down to K10.  They seem to have CAN too ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Channels not the same as ADC modules.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Channels not the same as ADC modules.

 

Correct.

Those NXP parts have 2 ADC modules, capable of these conversion rates :

 

Crate ADC conversion rate 16-bit mode No ADC hardware averaging Continuous conversions enabled, subsequent conversion time  Min 37.037 — Max 461.467 Ksps 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jars121 wrote:
Thank you for your input, it's very much appreciated. I had come to the same conclusion as you regarding ADC throughout and resolution on the MCU itself. As such, I'll be using 2 ADS1158's on an SPI bus. These ADCs offer 16-channels (8 differential/16 single ended) at 16-bit resolution, and can offer 20+ksps per channel (depending on the mode). This approach, while rather expensive (~AUD$15/ADC), should provide the speed and resolution I'm after.

 

With that kind of money, you could almost buy the ADSP-CM408F, which comes with an ARM Cortex-M4 attached to the ADC.