ADC Samples per Packet

All technical discussions and projects around startKIT
Post Reply
Hagrid
Active Member
Posts: 44
Joined: Mon Jul 29, 2013 4:33 am

ADC Samples per Packet

Post by Hagrid »

I have an application where I would like to sample a "burst" of activity on an ADC channel, lasting approximately 8us so would like to achieve 8 x 1us samples.

Looking at the A8A datasheet and comparing with the startkit_adc module code, there is perhaps a means to do this efficiently, depending on how the "Samples per packet" field in the ADC General Control register works.

This field is 8-bits in size, implying that up to 255 samples might be packetised by the ADC tile. This sounds "too good to be true".

The startkit_adc module uses a value of 4 (with 16bit samples).

What are the actual practical limits on this?

What is the size of the FIFO here?

Can I enable just a single ADC channel, set the samples/packet field to 8 and just trigger the burst as required (with 8 pulses on the trigger pin, of course)?


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

This field is 8-bits in size, implying that up to 255 samples might be packetised by the ADC tile. This sounds "too good to be true".
The ADC hardware can do this (ie. wait for 255 samples before sending them in one block), but unfortunately there isn't enough buffering in the channel to support this.

What are the actual practical limits on this?
What is the size of the FIFO here?
There are minimum 5 long words worth of buffering between the ADC hardware and a listening channel end (in the case the tile used is closest to the ADC). So you can't send more than this in one hit without potentially backing up and blocking, unless you have a task doing nothing other than consuming at the other end (wastefull so not of practical use).

Can I enable just a single ADC channel, set the samples/packet field to 8 and just trigger the burst as required (with 8 pulses on the trigger pin, of course)?
Kind of, if you want to store say 8 x 16b samples (each taken with a toggle of the trigger pin) and only consume the 8 samples ( 4 x long word) packet when complete, you can do this.

Obviously you'd need to set sample size to 16b or less. Setting it to 32b is pretty pointless anyway, being a 12b converter and all of that!

Take a look at the startkit ADC example. https://github.com/xcore/sw_startkit_ex ... kit_adc.xc
The ADC is configured for 16b and packet size of 4. That transmits 4 x 16b samples after 4 conversions. The packet is received as 2 x 32b packets. The receiver gets an event (select case fires) when the first 32b packet arrives and then does an IN which will block until the next one arrives shortly afterwards.

However you could wait until you know all conversions are complete and only then consume them from the buffer then - I think this achieves what you want.
Hagrid
Active Member
Posts: 44
Joined: Mon Jul 29, 2013 4:33 am

Post by Hagrid »

Thanks for the details. Exploring the envelope boundaries a bit further...

In the case of the startKit, my code runs on Tile 1 whereas the ADC connects to Tile 0, right? Does this mean I have less than 5 long words available for buffering?

For clarification, a long word is 64-bit right? If so, then there may be room for as many as 20 x 16 bit samples?

If I probe the buffer by gradually increasing it for each sample burst, how would I know if I hit the limit? Is this what bit 24 in the ADC General Control indicates?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Thanks for the details.
No worries!
Exploring the envelope boundaries a bit further...

In the case of the startKit, my code runs on Tile 1 whereas the ADC connects to Tile 0, right? Does this mean I have less than 5 long words available for buffering?
Actually, you'll have more. The route will be:
ADC <-> Switch on tile 0 <-> Switch on tile 1-> receiving task. So you will definitely have a few more levels in there.
However, after speaking to colleagues to discuss this, the case of actually backing up should be avoided, because not only will you miss a sample, but any other communication with the analog/USB tile will be blocked (because this is a packetised communication so link is occupied until the end token). That could cause issues elsewhere in the system. So perhaps even add a safety margin and only ever assume 4 long words (assumes the read task has already emptied the channel).
For clarification, a long word is 64-bit right? If so, then there may be room for as many as 20 x 16 bit samples?
No - a long word is 32b as per long int in the compiler. Long long would be 64b. IN/OUTs are generally 32b (for ports and channels), although there are primatives for reading chars out of channels..
If I probe the buffer by gradually increasing it for each sample burst, how would I know if I hit the limit? Is this what bit 24 in the ADC General Control indicates?
Here be dragons! Don't hit the channel buffer limits for the reason above. You might be OK until another task tries to talk to the analog tile when things will get un predictable, which is desirable. That flag in the register does indeed show that the ADC was not able to put the long word into the channel, but by then things may have gone amiss, so use only for debug and not as part of your protocol. Ie - should never be set!
Post Reply