StefanoSperetta
commented
4 years ago Lots of possible ideas... not sure about them...
First of all, printf: current implementation is ANNOYING (weird syntax, limited capabilities). I checked: the stdlib complete printf implementation is very easy to add (https://github.com/bluehash/MSP432Launchpad) but it costs 7.5 kB of code and ~300 bytes of RAM. The reduced version (without size specifiers and floats, https://github.com/samvrlewis/MSP432-printf) costs ~700 bytes...
Second: speed: switching to 115kbs seems a logic idea
Third: enabling / disabling log. Log can be disabled with a function call (to speed-up code) but it might not be very convenient for late debugging. It can also be detected if a serial port is connected by using GPIO_getInputPinValue on the RXD pin. If the pin is 0, no RS232 driver is connected, while if it is 1, the RS232 driver is IDLE (a pull-down for safety would be a good idea). This was tested with the JLINK and it works fine. This way the debug console can be disabled automatically by simply unplugging the serial cable. Minimal overhead (just a check per every printf) and in case of failure, the printf is always printing...
CasperBroekhuizen
Currently, the serial console is under DWire and this was done for convenience a long time ago. This brings a dependency of DelfiPQCore on DWire which is not very nice at this stage.
Personally, I would create a better serial console object (maybe with static methods for coding convenience).
Currently, the console is running at 9600 bps again because of convenience long time ago. This at the moment also slows operations down: ping and getTelemetry response time is in the order of 50ms mainly also due to the logging. What shall we do?
I would like to make the systems a little more responsive (also to make tests shorter) but I do not want to give up on a logging system. We might disable the log in release mode, but it might not be the best... We could also simply make the console faster (like 115kbps) or turn it into an interrupt-based system and the print function simply queues data to be printed. This might also open the case for queue overrun.
Any opinion, @CasperBroekhuizen @MFvandenBos ?