Evaluate signal_generator_cli - #594
Conversation
…ample Add signal_generator_cli example with stable ASCII command protocol
…enerator-cli Add GPIO engine and CLI commands to signal_generator_cli example
…troller Add SPI CLI commands to signal-generator example and extend SpiController API
…upport examples: add UART CLI with secondary capability gating
…t-configurations docs: add serial protocol guidance and pyserial host harness
…ints-and-reset-command Harden signal-generator-cli: validate payloads/timing, cap active generators, safe reset/stop, and standardize ERR namespace
…ng-and-handling Add reusable signal-generator CLI parsing logic and unit tests
…-tests Add UART controller API with fake/test coverage and CLI integration
Cargo examples can be directories with multiple files inside them (documentation). I suggest using that to break up the example into reasonably-sized files.
On first glance, it's not clear to me that the decision has been made to introduce the new UART API (tock/tock#4827), but assuming that decision is made then yes this seems fine. I think it's okay for Console and UART to be conceptually different things -- but that's a decision to be made in tock/tock rather than here.
Yes, that would be good. IMO we (Tock, I mean) should decide on the kernel API first before we add the UART functionality into libtock-rs. It is fine to keep open a draft PR with the API to demonstrate it. |
|
@jrvanwhy thanks for the feedback. In a couple weeks I'll split this PR into the following PRs:
I'll also split tock/tock#4827 (comment) into multiple PRs and start the process to have the transmit capability added to the virtual UART. |
|
closing this pull request because I will resubmit signal_generator_cli using different api |
2 participants
@jrvanwhy this is the code referred to in #590 and I have been using it to test the PR tock/tock#4827 (comment) . Can you suggest an approach to organize the code files? I still need to do an extensive review of the AI code.