Xmega or SAM4S?

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

Hello, I am building a data acquisition board with three ADC inputs (12 bit), one analog output and one digital output. The ADC rates are similar on the Xmega and SAM4S. Two ADC inputs (position and load) need fast update (initially 10K samples/sec), the third is temperature which can be slow.

Is there any advantage to going to the SAM4S over the Xmega? The current board uses USB to connect to the PC but I want to change to wireless. There are USB WiFi dongles which make the SAM4S preferable but if I go Bluetooth, there are modules that use serial input so the USB is not needed.

I have used MEGAs before and am familiar with them. The clocking is faster on the SAM4S but I am not sure the choke point will be the data transfer or the ADC. I have a SAM4S Xplained board that I can experiment with.

Thanks.

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

I guess I'd suggest you take about any micro you have and stick a Bluetooth module on it and see how fast you can send packetized data.

Then test it in your actual environment of interest.

 

RF links are very different from hardwired USB!

 

Some protocols may automatically try to resend the data, or only retry X number of times, etc.

Some protocols incorporate error detection, and or error detection and correction.

 

EMC in the environment can trash a data packet.

 

You haven't mentioned if every data element needs to be correctly received by the PC, or if an new and updated data value automatically supersedes an older data value?

 

If you have a working system with a hardwired link you should have a very good reason to change to wireless, (IMHO), before you go doing so.

 

Anyway, I suggest you work on how you are going to packetize your data, and test your RF link and supporting code.

That can likely be done with a canned data set and any micro.

 

Then move on.

 

JC

 

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

The data acquisition is for a dynamometer so dropping data would require curve fitting through missing points if it was not resent. It uses an electric motor but the motor is inside a grounded metal enclosure so the EMI might be minimal. The USB cable tends to break after a while from plugging/unplugging and bending which is the reason for looking into wireless.

I asked some questions on the IoT community forum to get information about wireless alternatives. Looking at the Mouser site, the 802.11 modules are cheapest. No useful information on how to interface with them though.

As far as using an Xmega or SAM4S, there is not a lot of processing for the acquisition. If the WiFi needs packets resent I need to know if that is on the uC side or the WiFi handles it. It appears that USB adds more complexity to the interface than SPI or UART.

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

 It appears that USB adds more complexity to the interface

If you use a micro with a built-in USB module, then the hardware interface is trivial, but it will require a little more work on the software side.

 

If you put a FTDI USB to Serial bridge chip on the board, then both the hardware and software side are trivial.

The SW is simply feeding your data to the micro's USART, and the USB chip handles everything else.

 

I do not have any experience using the little WiFi chips, (e.g. ESP...) as a serial link, so others can comment on that.

 

Data corruption in RF data transmission can be a real problem.

That's why I'd play with that aspect of the project first.

I've not done any back-of-the-napkin calculations for your data throughput, but you should!

 

Another option not yet mentioned is that if the PC is not doing real-time control of the dynamometer, then the micro device could in fact be a data logger with an SD card.

You could then store all of your real time data on the SD card, and upload it at your leisure, with an packet acknowledgement vs resend request for each data packet, etc.

The RF data error rate is then immaterial, and the upload could take place (start, anyways) during the data run, or totally after the fact.

The data collection will, I suspect, be driven by an interrupt and be dumping the previous samples into a ring buffer.  That task clearly has priority.  The upload is a time filler.

 

JC 

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

magno_grail wrote:
The USB cable tends to break after a while from plugging/unplugging and bending which is the reason for looking into wireless.
The USB cables may simply have inadequate strain relief, wires are too small a gauge, or braid is too fine.

Consider high-retention USB connectors that capture the cable.

USB can work well in industrial use cases; severe industrial by circular connectors where loading is through the backshell.

magno_grail wrote:
It appears that USB adds more complexity to the interface than SPI or UART.
True though USB is ubiquitous with virtual serial port speed that reaches its limit.

 


USB Cables - B+B SmartWorx

Products - USB - Kycon (second row, high retention force)

 

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

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

magno_grail wrote:
As far as using an Xmega or SAM4S, there is not a lot of processing for the acquisition.
If want to add processing, there's the XMEGA Over-sample and Decimate ADC application note that was recently updated (source code in Atmel START)

Can reach 16b resolution with adequate noise (natural or additional)

XMEGA E ADC have hardware to implement oversample-and-decimate though would have an external USB UART.

Might want to search the SAM portfolio's application notes for similar.

 

AN2777 AN2777: XMEGA ADC Oversampling | Application Notes | Microchip Technology Inc.

 

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

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

Thanks. The acquisition board is currently a Labjack U12. I have not determined if it is being used in stream or burst mode. In stream the data rate is 1200 samples/second and 8192 samples/second in burst mode for 1-4 channels. Only two channels would be read during a run so half those numbers but we want to increase the resolution.

Interestingly, the resolution is given as 12 bit but the Microchip uC ADC is 8 bit which appears more than possible with oversampling. 12 bit ADC of the Xmega or SAM4 would be sufficient.

 

Since the data is time varying, samples have to be taken over several revolutions to have enough data at each point to do averaging. I think it is preferable to send the raw data to the PC and work the data there. The data would have to be stored on the acquisition board if data error occurs. I have still not been able to determine whether the WiFi handles resending the data or the uC has to resend. Unfortunately, the datasheets on Mouser only state I/O pins and physical dimensions. Nothing about how to actually use them.

 

The board only sets the motor speed then makes the measurements so reading the ADC is the only input operation happening during a run. In burst mode the Labjack stores the data on board whilst reading. If we stream the data then the uC will have to send the data to the WiFi whilst reading the ADC. This might be where choosing an Xmega or SAM4S would come into play.

 

The box uses a panel mount USB-B connector. Retention force is not the problem, the cable is. Yes, a better quality cable is an alternative but they think wireless would be more marketable.

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

magno_grail wrote:
Interestingly, the resolution is given as 12 bit but the Microchip uC ADC is 8 bit which appears more than possible with oversampling.

...

I have still not been able to determine whether the WiFi handles resending the data or the uC has to resend. Unfortunately, the datasheets on Mouser only state I/O pins and physical dimensions. Nothing about how to actually use them.

IP TCP would handle resends.

Though an order of magnitude more expensive (my guess) than that module at Mouser, Lantronix device gateways tunnel a UART into an IP network and have an SDK for its MCU and RTOS (iow, by the SDK to extend functionality); can interface a SPI ADC to it instead of the ADC via a MCU (XMEGA, SAM)

 

xPico 200 Series | Lantronix

xPico 240/250 Series Embedded Wi-Fi IoT Gateways - Lantronix - New - Mouser

https://docs.lantronix.com/products/xpico-200/ig/functionaldescr/#general-purpose-io-pins

https://docs.lantronix.com/products/xpico-200/sdk/2.0/html/group__spi.html

 

edit: Mouser URL

 

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

Last Edited: Wed. Dec 19, 2018 - 05:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

magno_grail wrote:
Interestingly, the resolution is given as 12 bit but the Microchip uC ADC is 8 bit which appears more than possible with oversampling.
fyi for the follow-on to megaAVR in megaAVR 0-series :

AN2572 ADC Oversampling with tinyAVR 0- and 1-series, and megaAVR 0-series | Application Notes | Microchip Technology Inc.

XMEGA E adds DMA over megaAVR 0-series

XMEGA AU adds DMA and an order of magnitude faster ADC

A 5V megaAVR 0-series would have greater noise immunity than a 3V XMEGA though XMEGA are already excellent in that.

Interface a megaAVR 0-series by a USB UART

or Bluetooth Low Energy :

Secure AVR BLE IoT Node

or Wi-Fi :

AVR-IOT WG Development Board

ARDUINO UNO WiFi REV2

or etc (RS-485, LoRa, radio modem, ...)

 

Edit: Arduino

 

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

Last Edited: Wed. Dec 19, 2018 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Several years ago I wanted to look a bit into faster uC's than the good old Mega AVR's.

First natural thought were the Xmega's. Plenty of nice new toys inside to play with.

Then I compared some ARM datasheets.

Peripherals were pretty much comparable with the Xmega's.

 

Then I realized that going from Atmega to Xmega is probably quite a learning curve.

 

So I decided to go the ARM way.

Because of the very low Ali prices I could not resist buying a hand full of STM32F103C8T6 boards.

Not only because of the price of the boards, but also because of the price of the development Tools.

ST-Link V2 is all you need for programming & debugging and it also costs < USD 5.

STM32F103 is not the easiest of the ARM families to toy with, but for a hobbyist with a small budget and plenty of time it is a good fit.

Also because lot's of products from Ali use this chip such as the DPS5005 power supplies and the FX2N PLC boards.

Those are nice toys for hobbyists.

 

On a glance ARM seems to have a big plus over Xmega, because it seems to have become the standard. However:

Implementation of peripherals is "not standarized" among al those vendors, which makes it difficult to get familiar with chips from different vendors.

 

If the choice is based on a single project then there are too many similarities between them to make a clear choice. Either probably fits well.But when you consider (bigger) future projects ARM seems to be the winner. You can get 400MHz or more and Megabytes of Flash / RAM on those.

Very few of the Xmega's have more than 128kB flash.

The Microchip Table I'm staring at does not list CPU frequencies, but my guess is Xmega's fastest is somewhere between 50MHz and 100MHz.

If a project fits well in an Xmega, it will fit in a comparable ARM. The other way around is not so easy or simply impossible.

 

I'm getting noticably older, and getting to know a new uC architecture is quite a challenge for me.

Therefore I decided to stick to a limited amound of uC families. I use the Mega AVR's for 5V compatibility and simple projects.

I (am learning to) use STM32 for anything that needs more horses than an ATmega328P.

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

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

Paulvdh wrote:
... but my guess is Xmega's fastest is somewhere between 50MHz and 100MHz.
32MHz spec though Brad (AtomicZombie) demonstrated XMEGA384C3 at, IIRC, 50MHz and maybe up to 64MHz; don't recall what was non-functional at 50MHz (likely the NVMC, PDI has its clock and PDI goes to 30MHz)

Paulvdh wrote:
If a project fits well in an Xmega, it will fit in a comparable ARM.
A generalization; there are specific XMEGA capabilities that fit into niches circa '11 (now, arm is such a plethora that XMEGA niches may be covered by arm)

 


https://www.avrfreaks.net/search/site/XMEGA384C3?filter_by=9631&f%5B0%5D=is_uid%3A207227

ATxmega384C3 - 8-bit AVR Microcontrollers - Microcontrollers and Processors

 

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

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

Bluetooth 4.0 has a payload limit of 20 bytes (if my memory serves me correct) per packet using the serial emulation. This limits the actual data rate you can achieve.

You can get modules to add on wifi and bluetooth to your micro, or you get a micro with the wifi/bluetooth built in. Something like a Cc300 or esp32. If you want better analog performance, use an external adc/dac. Using an ESP32, you could have your app stored on the device that gets loaded and executed on the webbrowser. Wifi/tcp takes care of the low level details of getting the data across.

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

Kartman wrote:
Using an ESP32, you could have your app stored on the device that gets loaded and executed on the webbrowser.
A Single Page Application (SPA)

On ESP8266 :

Single Page Application and WebSockets For Secure Realtime Device Management - YouTube (2m15s)

 

ESP32 has TLS (not certain TLS is on ESP8266); therefore, a secure WebSocket to get data to and from the SPA.

ESP-TLS — ESP-IDF Programming Guide v3.3-beta1-136-g97eecfa documentation

https://warmcat.com/git/lws-esp32-factory/

via libwebsockets.org lightweight and flexible C networking library

 

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

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

For those that maybe contemplating such a project, i’ve had good success with mongoose webserver www.cesanta.com that takes care of the webserver, websockets and mqtt on an embedded system. I’ve been writing the code on a mac using xcode and running the code natively on a mac. This allows you to write and test the web/network stuff quickly before running it on an embedded platform. Needs to be livcensed for a commercial product, but the fees are chickenfeed compared to rolling your own.

Another recommendation is ArduinoJson. If you need to read/write json on an embedded system, this is the bomb. Well documented. The author also tells you what not to do. I was having some problems and sure enough, i was doing what i shouldn’t. Note - although called ArduinoJson, Arduino not required.

With the above two items, i was able to have a configuration webpage served up from an embedded device that used a RESTful interface to read/write config data and a websocket to push livedata across. All without too much work on the embedded side. I haven’t tried SSL yet. Supposedly mongoose does this for me as well.