ADC DMA example, I cannot decode it

[jupithunder2222]

20220831_165740.png (73.06 KiB) Viewed 2768 times

about 'result', i cannot guess it's true identity.
is it array or dynamic array or suddenly adc_digi_output_data_t * type?

please help me

[Craige Hales]

line 3: result is an array of TIMES elements, each is uint8_t. All elements are initialized to 0. Then all elements are set to xCC. The values are from 0 to 255 after the call to adc_digi_read_bytes. Since it is not declared static, and is inside a function, it is on the local stack for the duration of the function call. As long as TIMES is small enough, probably less than 1000, it will fit on the stack.

At the end, the odd looking cast doesn't change the data bits, just their interpretation.

Code: Select all

&result[i]

gets the address of the uint8_t bytes, one at a time, and says (void *) ... forget this is a uint8_t pointer and just make it a pointer to void. that void pointer is then assigned to a pointer with type (adc_digi_output_data_t *). That does not change the binary bits of the data or the pointer. It just says "this pointer points to data of this type".
ADC_RESULT_BYTE might be 1 or some other value, but determines how many uint8_t are skipped to get to the next pointer that will be cast to adc_digi_output_data_t.
Without seeing the h file for adc_digi_output_data_t it is hard to know exactly what p->type1.channel and p->type1.data really are. they might be bits within a byte or they might be consecutive bytes.

You'll see this pattern a lot in c code to connect subsystems written by different people where the data doesn't need to be rewritten, just interpreted. Not great for understanding, but very fast.

[jupithunder2222]

hidiousdata.png (38.16 KiB) Viewed 2686 times

this is the structure and i don't know what the numbers are supposed to be...

please give me a lesson, sir

[Craige Hales]

The number after the : is the number of bits in a bit field. https://www.tutorialspoint.com/cprogram ... fields.htm for example.
That structure tells me there are ADC_RESULT_BYTE==4 bytes per sample. The first 12 bits of the first 2 bytes are data, and the compiler will generate the code needed to extract those 12 bits and make them appear to be a uint32_t.
The same two bytes contain 1 reserved bit and 3 channel bits. Channel can be a value from 0 to 7.
The next two bytes have a 1 bit unit and 15 reserved bits.
You've found the definition for type2 in that picture. Your original code is using type1. ADC_RESULT_BYTE is likely different, 2 perhaps, and the type1 structure probably lays out the bits differently.

The struct is inside a union. The union overlays the uint32_t val on top of the 32-bit type2. The compiler accesses val with a single instruction. The union lets you see the data in two different ways. The underlying 32 bits are the same.

Most experienced c coders avoid bit fields unless they are needed to unpack data like this. The compiler probably generates 2 or 3 instructions to read a bit field and 4 or 5 to write a bit field, so there is a time-space trade-off, as well as a hard-to-understand issue.