Dear Simon,
In message CAPnjgZ1GzD3KJeaA1LLdYPQsoOLWJPxmX=FHFeUthkdPrUYt2g@mail.gmail.com you wrote:
I think outputting data to all "potential" console ports is a really bad thing, as you cannot know how your users are using the hardware. They may have attached hardware to the UARTs, and the data you send to the port causes a mis-function of the device. =A0I guess you don't add to your documentation a warning like: select one port as console, and leave allother ports unused, because we may send random date to all ports any time?
Only on a fatal error. Unfortunately this idea of 'fatal error' was lost in the conversion from board_panic_no_console() to
This "fatal error" might become a fatal accident in some cases if you send random data to some port that controls some kind of machinery or whatever. Never ever do that!
board_pre_console_putc(). I would be keen to move back to that original plan, so that the idea of a fatal error is captured. In a fatal error situation there is no prospect of the board working and the only hope is that we can alert the user.
Agreed. But you must not do this by performing random actions on random (potentially otherwise used [by the end user]) interfaces.
If you do not know which UART port to use, then the only consequence can be not to use any UART prt at all. Use a LED with blink codes or whatever your hardwar ehas, but do not mess with random ports.
I agres with the sentiment and this is a very ugly corner case, but in practice people want to know what happened, not just be presented with a brick.
Yes, I understand this. But please try to find another way to signal failure. Do not perform random actions on a device - you could as well always output all data on all UART ports because with this codeyou cannot use the other ports for any serious purpose anyway.
I also cannot understand why you think you must init() and drain() the UART for each character printed - ok, the latter is probably a consequence of re-initializing the port for each character. Eventually this will be not needed once you get rid of the re-init.
OK so how about moving to a puts()-type interface? Then I can remove this.
Sorry, but I don't have enough context - pts() interface where or for what?
Best regards,
Wolfgang Denk