The "wfi" opcode/instruction, because systick is a function of the ARM CPU and by default wfi causes the CPU clock to stop. So the systick counter will never reach its threshold and trigger the interrupt, unless the extra code has configured the...
One other thing about wfi that I forgot to mention: by default it stops the systick counter, which means the value returned by millis() will not increase while the CPU is waiting.
I think it would be better to leave timerISR empty. yield() already gets called whenever loop() finishes (so it would be getting called twice each time the timer interrupts) and it's a bad idea to call it from an interrupt handler.
asm volatile("wfi"); will put the CPU to sleep until an interrupt occurs. Just be aware if an unmasked interrupt never arrives, the CPU will never wake...
It doesn't look like the IMXRTfuseWrite function is allowed to touch the GP3 fuses:
void IMXRTfuseWrite(volatile uint32_t *fuses, uint32_t value)
{
(...)
uint32_t addr = ((uint32_t)fuses - (uint32_t)&HW_OCOTP_LOCK) >> 4;
if (addr > 0x2F)...
Unless LTO is used the compiler can't "unroll" loop() into the equivalent of a while() or do() construct; it's still going to be a general function. So it has to assume global variables may be modified (by other code) between each time it gets...
Are you sure if you look very closely, there isn't a tiny join between them? That is the default design and it would not be possible to power the board via USB otherwise.
You can pass uint8_t* to a function that expects const uint8_t*; that's just a guarantee that the function won't modify the data.
It's still undefined to modify the memory pointed to by a const pointer. So this isn't a compiler bug, it's a...
Well... the const uint8_t* version looks wrong because the buffer it points to is not const. So there's undefined behaviour, since anything that gets passed that pointer can assume its contents never change. Maybe you meant to use "uint8_t*...
In ye olde days (before USB PD was a thing), charging cables or the chargers themselves were meant to short the device's data pins together. There were even some devices that would refuse to charge if that wasn't the case (early ipod shuffles for...
Replying to myself here: I have (very painfully) discovered how this reordering can be a problem!
In my USB host code, I use this very specific sequence to add new transfers to a queue head:
usb_transfer* p = dummy.release(); // copy dummy ptr...
The SPI TCR register also has a prescale field that lets you divide the clock differently (up to 128) per transaction. So you can use different speeds for different devices on the same bus...
It seems like the eDMA hardware was inherited from the earlier Freescale chips and some of this code was copy-pasted from Teensy3. The earlier gen doesn't support 64-bit transfers, but it does support 16 byte bursts instead.
SHIFTCTL contains SMOD which sets the shifter's operating mode. Setting the mode to anything other than "disabled" makes it active. This isn't a gotcha, you are expected to configure it before you take the brakes off...
Not sure where the 30MHz information comes from but on page 1025 of the IMXRT1060 reference manual, the System Clock Frequency Values table shows a max of 132 MHz for LPSPI.
From memory, the PD chip is only meant to power the second USB-C port (not the board) and it only does that if you bridge the middle pad (which is connected to the second USB-C port's V+ lines) to the PD's output. If you want the USB-C port to...
If you accidentally compile without a setup() and/or loop() function present (or the function signature is different, e.g. c++ instead of c binding) Blink.cc will end up being included in the compiled cores.a archive. Then if you fix the problem...
Why is Blink.cc included in the core files? It doesn't contain any interface-related code and can permanently break compilation of a project when using the Arduino IDE (fixable only by clearing out the temporary/cached files).
The sync signals could be moved to other FlexIO pins but the BGRI pins have to be sequential, I don't have the Teensy pinout on hand to check if there are other possibilities.
I never coded any scrolling, that was wwatson's additions. But if you split the DMA operation that writes pixels into the FlexIO registers into two separate operations, scrolling would be practically free.
It's not part of the CPU, it's one of the modules that NXP included in the microprocessor. As previously mentioned it is activated by the default startup code with a panic temperature setting of 90C.
It's more likely to be a case of one interrupt blocking others - what is the loadDMABuffer function doing? You really need to post a complete sample if you expect people to offer insight.
SDRAM just means you can have spare render buffers besides the active one, it doesn't really enable more resolutions or bitdepths because the USB bandwidth is still the limiting factor.
If you wanted to integrate something like this on a board...
16bpp is possible at 640x480 but compression is required which can degrade the quality.
The limit is the USB bandwidth which maxes out at roughly 30MB/s. 60 frames a second of 640x480 using 16bpp = 60*640*480*2 = ~37MB/s. That's why these...