Feature/usb terminal #54
Conversation
| } | ||
| } | ||
|
|
||
| #[task(priority = 2, schedule = [channel_monitor], resources=[channels, leds])] | ||
| #[task(priority = 3, schedule = [channel_monitor], resources=[channels, leds])] |
There was a problem hiding this comment.
Correct. This should stay the highest priority task. If its duration causes problems with latency spikes on the other tasks, then we need to tweak it.
There was a problem hiding this comment.
The only reason I'm changing the priorities here is because the mqtt_client will block when attempting to connect the TCP port - when we're using that resource, the interrupt priority threshold is raised to that of the task with the highest priority that also uses the mqtt_client. Right now, that task is only telemtry. USB has been put at a slightly higher priority than telemetry just to ensure that MQTT client locking does not unintentionally block the USB interface, which would make it pretty unresponsive.
|
Here's a capture of what the terminal console looks like: |
Co-authored-by: Robert Jördens <[email protected]>
…o feature/usb-terminal
| match self.usb_serial.read(&mut buffer) { | ||
| Ok(count) => { | ||
| // Echo the data back. | ||
| self.write(&buffer[..count]); |
There was a problem hiding this comment.
We should probably have a CommandLine proxy to manage arrow keys, backspace, and other characters to make the terminal nicer to work with. Something like an embedded-readline
There was a problem hiding this comment.
Yes if it reduces the amount of code. But the command line doesn't need to be extensive.
There was a problem hiding this comment.
Any sort of support for arrow keys, backspacing, or other character detection would only really increase complexity at this point, so if we're going for MVP, I would recommend we leave it as-is.
There was a problem hiding this comment.
Any sort of support for arrow keys, backspacing, or other character detection would only really increase complexity at this point, so if we're going for MVP, I would recommend we leave it as-is.
Works for me. I plan to have very minimal interactions with this interface so simple is good (in contrast to the old firmware which had lots of bells and whistles that didn't help me, but also lots of bugs)
This PR adds a basic USB serial terminal for configuring the broker and booster IP addresses as well as resetting the device. It also adds a placeholder
BoosterSettingsstructure for containing device-wide configuration parameters.This closes #9
Currently, the USB functionality relies on the changes in rust-embedded-community/usb-device#41 to implement a stable usb serial port, so forks have been set up for
usb-device,usbd-serial,synopsys-otg-usb, andstm32f4xx-halto use the forkedusb-devicecrate. Once changes are merged, we should integrate them into our dependencies and update as necessary.Settings are not yet persisted to flash, so configuration is not maintained upon reset.
TODO: