New project on the Horizon (read "They want it last week and for $0 budget")... Hydraulic press for
sandwiching big SCR pucks between 2 heatsinks. 3 Different clamping pressures required.. Last time we
did something like this it cost $90,000... fancy pressure control valve ($8000)... PLC and HMI all way too fancy.
New concept has to cost 1/10th of the original. Basically it is a very precise timer and datalogger. in theory we can hit a pressure almost perfectly by precisely timing when to turn the hydraulic pump motor off...
Keeping and eye on the hydraulic system is a 4-20ma pressure transducer hooked up to a 16bit, 860Hz DAC (i2c connection) and one of the Due's analogue inputs (12 bits but running at 10KHz or more)....
Theory is run ADC(on die) in free running mode and pop a T/C interrupt at 10Khz to read it out store results. then everytime you hit a event on the 16-bit ADC you(tick) and write out the buffer this is output
as a packet with all the values enclosed (12 12-bit ADC words and the one 16-bit word)...
Question being that the USBSerial is not a regular bit-by-bit interface, in theory there should be a best way to pack data for it so we don't waste cycles writing out when we should be trying to maintain optmial sensor checking speeds.
I don't understand the 12-bit ADC with the 16-bit ADC.....
Anyway, since you want 10 KHz ADC conversions, you want to avoid free running mode. Instead, pace your conversions at a precise frequency (10 KHz) with e.g. a Timer Counter.
If you store ADC conversions in a Buffer with a PDC DMA, and you do double buffering, you can output the already filled buffer with UART, while, in parallel, the DMA fills the other buffer.
You have numerous example sketches of this in the DUE sub forum. One of them here, at reply #9:
If you Serial.Write() to a PC (Serial.Write() sends data faster than Serial.print()) selecting 250000 bauds, there should be no issue.
SerialUSB is much faster though. There is also the resource of an UART DMA like in the example sketch here, reply #4:
Thanks for pointing that out... looks like the idea is have a T/C trigger a ADC conversion at a regular rate then have an ISR save that to a double buffered back end.
I started to read the DMA section in the datasheet and my eyes begun to glaze over... I believe some of my brain may have even leaked out my ear... been a VERY LONG time since I used DMA double buffers (last time was on an Atari 520ST to give you an idea).
We're so spoiled today with the features on these microcontrollers. con is... takes a lot more time to learn their cool tricks.
The other ADC is external, connected over I2C, it's a lot slower but has better precision.
Thanks for the examples, They look quite relevant to what I need, I'm going to spend some time reading over them.