The Pico UART stdio does in fact drive the UART directly with no interrupts and no buffering other than the 16-deep FIFO in the UART itself. If you choose to use USB stdio, that does of course have buffering.
I normally run my stdio UARTs at 2Mbaud so that I can still printf() with abandon and not have a significant effect on performance. I also quite often enable both UART and USB stdio, as if I have the Pico's USB port connected already for other reasons it saves faffing with a UART cable, but the UART is there to catch dying gasp messages if it all crashes.
There's only one stdio channel - ie. you get printf() to the chosen UART/USB, but you cant have fprintf(other_channel,...) to drive the second UART, you have to use it with the functions from the hardware_uart library (uart_init(), uart_putc() etc), which again is not interrupt driven by default, though it's not hard to wrap it in an interrupt handler if you need to. (I dare say you could re-use the SDK stdio code to give a 2nd channel, but it's certainly not there as a published facility).
That should get you the error messages from asserts, but there are also exceptions and various things in the SDK (including those asserts after they've printed the message) which invoke a breakpoint instruction - the assumption seems to be that you will use a debugger to see what's going on.
Since I don't usually use a debugger, I find it helpful to have an exception handler installed. Mine looks like this, though I've seem much more sophisticated ones posted on the forums in the past:
And then to install it:
I normally run my stdio UARTs at 2Mbaud so that I can still printf() with abandon and not have a significant effect on performance. I also quite often enable both UART and USB stdio, as if I have the Pico's USB port connected already for other reasons it saves faffing with a UART cable, but the UART is there to catch dying gasp messages if it all crashes.
There's only one stdio channel - ie. you get printf() to the chosen UART/USB, but you cant have fprintf(other_channel,...) to drive the second UART, you have to use it with the functions from the hardware_uart library (uart_init(), uart_putc() etc), which again is not interrupt driven by default, though it's not hard to wrap it in an interrupt handler if you need to. (I dare say you could re-use the SDK stdio code to give a 2nd channel, but it's certainly not there as a published facility).
That should get you the error messages from asserts, but there are also exceptions and various things in the SDK (including those asserts after they've printed the message) which invoke a breakpoint instruction - the assumption seems to be that you will use a debugger to see what's going on.
Since I don't usually use a debugger, I find it helpful to have an exception handler installed. Mine looks like this, though I've seem much more sophisticated ones posted on the forums in the past:
Code:
void hard_fault_handler(void){// This is an all-asm function that prevents the compiler emitting// any prologue and so adjusting the stack before we save it.// LR on entry to an exception handler is magic (mostly 0xff),// bit 2 indicates whether the system or process stack was in use// before the exception (and hence which stack the context got pushed onto).__asm( "mrs r0, msp\n" // Assume for now it's always msp "b FaultHandler_c\n");}voidFaultHandler_c(uint32_t *stack){ // It would be nice to poke out some bytes without using any stack, // to avoid double-faulting on corrupt SP. However, that would // require an assembler veneer as the function prologue has already // used the stack before we get here. For now, just printf() with abandon. printf("SCB_ICSR %08x\n", (unsigned)scb_hw->icsr); // Get the code address that caused this fault - at SP+0x18 // (see 2.3.6 in the CortexM0 ref manual for stack in exception handlers) printf("PC %08lx\n", stack[6]); printf("SP %p\n\n", (void*)stack);// Force a reboot hw_set_bits(&watchdog_hw->ctrl, WATCHDOG_CTRL_TRIGGER_BITS); for (;;) ;}Code:
exception_set_exclusive_handler(HARDFAULT_EXCEPTION, hard_fault_handler);Statistics: Posted by arg001 — Wed Sep 25, 2024 8:10 am