tician
Member
Been quite a while since I've been active on any forums, but nice to see KurtE is still going strong.
Not really urgent in any sense and not exclusive to any Arduino variant and not sure how many more projects I'll be using the T4 for, but it would be nice if the -O0 option were available inside the Arduino settings by default instead of having to modify the settings every time I update the boards/core. gcc is generally pretty nice, but I have had several instances on multiple platforms where essential bits of code end up being completely optimized out with any option other than -O0 and sending me bashing my head against a wall.
Three particular instances come to mind of gcc optimizations breaking things and causing so much annoyance tracking it down:
1) some initialization/callback issue in the Robotis DARwIn-OP motion system on x86-64
2) some timer initialization code on the Adafruit ItsyBitsy-M0 and/or Feather-M4 where it eliminated a register initialization line that meant the timer would start at random value and take forever to loop around
3) yesterday's irritation: a convenience pointer to a 512 byte array for USB output that gets data values loaded out of a pair of DMAMEM buffers/arrays fed from the ADCs
versus
producing very different behaviors when used in this bit of code:
Basically going for a ~1Msps 12-bit 2-channel ADC streaming data as fast as possible over the high-speed USB interface (4~5 Mbyte/sec). When using the char* version, it works exactly as expected. Use the const uint8_t* version, and it will manage to build and send the 512-byte blocks over USB exactly as expected (incrementing header values and pulling data from the DMAMEM buffers pointed to by pbuffer0 and pbuffer1), but it goes pear shaped somewhere in actually extracting new data from the ADC+DMA. The DMA thinks it is transferring data since the data transfer loop is dependent on AnalogBufferDMA interrupts being reactivated by the DMA hardware and debug prints show AnalogBufferDMA's internal _interrupt_count getting incremented properly. But the data stored in the DMAMEM arrays never actually change after the first ADC collection run and it seems like the ADC gets borked somehow since the loop gets completely stalled if the ADC input pins get pulled above 1.2V and resumes after dropping back below ~1.1V.
So, yeah. That took a full day to track down and really made me wish I had not been so lazy in performing the -O0 modification again.
Not really urgent in any sense and not exclusive to any Arduino variant and not sure how many more projects I'll be using the T4 for, but it would be nice if the -O0 option were available inside the Arduino settings by default instead of having to modify the settings every time I update the boards/core. gcc is generally pretty nice, but I have had several instances on multiple platforms where essential bits of code end up being completely optimized out with any option other than -O0 and sending me bashing my head against a wall.
Three particular instances come to mind of gcc optimizations breaking things and causing so much annoyance tracking it down:
1) some initialization/callback issue in the Robotis DARwIn-OP motion system on x86-64
2) some timer initialization code on the Adafruit ItsyBitsy-M0 and/or Feather-M4 where it eliminated a register initialization line that meant the timer would start at random value and take forever to loop around
3) yesterday's irritation: a convenience pointer to a 512 byte array for USB output that gets data values loaded out of a pair of DMAMEM buffers/arrays fed from the ADCs
Code:
volatile uint32_t usbhs_write_buffy[128] = {};
char *usbhs_write_buffy_pointer = (char *) usbhs_write_buffy;
Code:
volatile uint32_t usbhs_write_buffy[128] = {};
const uint8_t *usbhs_write_buffy_pointer = (const uint8_t *) usbhs_write_buffy;
producing very different behaviors when used in this bit of code:
Code:
usbhs_write_buffy[2] = (blocktotal<<16) | (++blockiter);
for (uint32_t iter=0; iter<samples_per_block; iter++)
{
usbhs_write_buffy[3+iter] = (uint32_t) (pbuffer0[(jter*samples_per_block)+iter]<<16) | (pbuffer1[(jter*samples_per_block)+iter]);
}
// Write out the 512 byte packet
Serial.write(usbhs_write_buffy_pointer, 512);
Basically going for a ~1Msps 12-bit 2-channel ADC streaming data as fast as possible over the high-speed USB interface (4~5 Mbyte/sec). When using the char* version, it works exactly as expected. Use the const uint8_t* version, and it will manage to build and send the 512-byte blocks over USB exactly as expected (incrementing header values and pulling data from the DMAMEM buffers pointed to by pbuffer0 and pbuffer1), but it goes pear shaped somewhere in actually extracting new data from the ADC+DMA. The DMA thinks it is transferring data since the data transfer loop is dependent on AnalogBufferDMA interrupts being reactivated by the DMA hardware and debug prints show AnalogBufferDMA's internal _interrupt_count getting incremented properly. But the data stored in the DMAMEM arrays never actually change after the first ADC collection run and it seems like the ADC gets borked somehow since the loop gets completely stalled if the ADC input pins get pulled above 1.2V and resumes after dropping back below ~1.1V.
So, yeah. That took a full day to track down and really made me wish I had not been so lazy in performing the -O0 modification again.