[SAM] [ADC] register conundrums

[ataradov]

Yes, this looks fine. I think in practice both those things should be 0b111.

[Simon]

Well yes they are, I just used 0x7 where it was practical for the bits in the lower 3 positions but could not be bothered to look up the hex of 0b111000, I suppose as I am shifting the value that I have constrained to 8 bits to the right I don't need to AND them with the mask but went belt and braces.

[ataradov]

No, I mean the calibration values would be 0b111. It doers not matter how you extract them.

[Simon]

Oh, but if the calibration values are just 111 then what is the point? the datasheet says to load these values and cautions against changing them but if they are just 111 anyway I could just load that.

[ataradov]

Because they might change in the future revisions of the device. It is a good idea to load them, or course. But it is also a good check that you are loading correct values at least for now.

[Simon]

OK, well luckily I have 40 characters of display I can put values on. I'll give that a go tomorrow.

[Simon]

Bits 2:0 are 0b101, bits 5:3 are 0b111

[ataradov]

Interesting. May be they actually have different values on some devices.

Can you read the same values for the ADC1? Or the whole 64-bit word will do as well.

[Simon]

I'll give it a go in the morning

[Simon]

The lower 16 bits read out as 0101 1111 1011 1110 so yes those values are the same in both ADC's

[Simon]

So I have 2 channels to measure alternately. I see that the ADC has a sequence option, this is handy as it takes an amount of coding out of doing it otherwise.

But there is only one result register, so an interrupt fires to say the conversion is done, but the next conversion has already started, is the result register OK to read before the second conversion is complete or will it be altered. Same applies for a continuous sampling of just one channel, if the new conversion starts as soon as the last one has completed presumably if the result register is read before the current conversion is complete it has a valid result.

[Siwastaja]

Usually you want to use sequences with DMA.

Using this pattern (note, I have not used Atmel SAM devices, but works on STM32, and the idea should work on any decent modern micro):

Code: [Select]

typedef struct __attribute__((packed))
{
   uint16_t voltage;
   int16_t current;
} adc_datapoint_t;

#define BUFLEN 1

volatile adc_datapoint_t adc_buf[BUFLEN];

void init_adc()
{
   DMA.memory_address = adc_buf;
   DMA.transfer_length = sizeof adc_buf / sizeof adc_buf[0]; // also known as number of elements
   DMA.transfer_size = 16 bits (in this case, because of 16-bit ADC)
   DMA.mode = continuous / wrap around / whatever it is called.

   Start DMA

   Configure ADC channel sequence to match that struct
   Configure ADC in DMA mode
   Etc.
   Start ADC
}


If you do this, you can just access the struct directly, getting latest measurements, whenever and wherever you want! No need to manage anything, except when you need to know that all values within the struct are from the same "round", converted in the same order, then you can use DMA completion interrupt, for example.

But in my projects, I have noticed that just having the latest value is often exactly what is needed.

[ataradov]

The result register is updated at the end of the conversion cycle. You have the full cycle to read the previous result.

[Simon]

The result register is updated at the end of the conversion cycle. You have the full cycle to read the previous result.

Goodho, that will do me. Thinking about it a bit I would still have to write the code to cycle through the channels. I either tell the ADC what to do next or have to work out what channel just converted. The former has less headaches I think and code overhead.

[Simon]

Usually you want to use sequences with DMA.

Using this pattern (note, I have not used Atmel SAM devices, but works on STM32, and the idea should work on any decent modern micro):

Code: [Select]

typedef struct __attribute__((packed))
{
   uint16_t voltage;
   int16_t current;
} adc_datapoint_t;

#define BUFLEN 1

volatile adc_datapoint_t adc_buf[BUFLEN];

void init_adc()
{
   DMA.memory_address = adc_buf;
   DMA.transfer_length = sizeof adc_buf / sizeof adc_buf[0]; // also known as number of elements
   DMA.transfer_size = 16 bits (in this case, because of 16-bit ADC)
   DMA.mode = continuous / wrap around / whatever it is called.

   Start DMA

   Configure ADC channel sequence to match that struct
   Configure ADC in DMA mode
   Etc.
   Start ADC
}


If you do this, you can just access the struct directly, getting latest measurements, whenever and wherever you want! No need to manage anything, except when you need to know that all values within the struct are from the same "round", converted in the same order, then you can use DMA completion interrupt, for example.

But in my projects, I have noticed that just having the latest value is often exactly what is needed.

Ah, yea, DMA, I'll get to that at some point . At the moment I don't need to squeeze for performance that hard.

[Siwastaja]

Ah, yea, DMA, I'll get to that at some point . At the moment I don't need to squeeze for performance that hard.

The point was, not for performance, but because it is easier! Once you set it up, you don't need to think about timing or write any ISR at all, latest conversions are accessible as normal variables.

[Simon]

Yes code complexity is my main concern but I don't have time to take on another peripheral right now. For the current purposes I can use code in an interrupt. After this project is done I can look at the DMA as I will also start to look at CAN bus.

Broadly to me: code != performance. If there is a feature that lets you do something without writing code for it it increases performance as it means it is one less thing the CPU is having to do, it just happens. For example on an AVR I wrote code to average several ADC readings, this required CPU intervention each time a result was ready. On the SAMC the ADC will take multiple readings and average them automatically into the result register and then fire the conversion complete interrupt. So I can now accumulate 1024 samples and the CPU only has to do something about it once rather than 1024 times.

I guess the (tiny) penalty of something like automatic sequencing is that you need to allocate RAM space for all of the channels whether they are used or not. With an AVR my first automatic sequencing code meant that I would just run for channel 0 to a "top" channel. I am now creating another array to store a "slot" allocation so that I can choose the sequence and which channels. The SAMC again does this for me but then without looking into it I am unsure how much memory I now need for the results, not that it is that important, I am not constrained by I avoid being wasteful. Would it need to be result x channels, probably not but I would likely need the DMA to do that, with interrupted code I'd be having to check which channel just returned which will take CPU time so DMA will be the way I guess when I get there.