Update loopback fw

[robamu]

Based on #226 .

Like expected, not exactly trivial, but definitely a good learning opportunity. Let's see if async can actually simplify the complexity here.

[cloudflare-workers-and-pages]

Deploying ferrous-systems-rust-exercises with    Cloudflare Pages

Latest commit:	61a6238
Status:	✅  Deploy successful!
Preview URL:	https://f96123f1.ferrous-systems-rust-exercises.pages.dev
Branch Preview URL:	https://update-loopback-fw.ferrous-systems-rust-exercises.pages.dev

View logs

[robamu]

Waiting for #226, but some notes:

• Introduce shared BSP
• Implementation did not become less complex, but some of the low-level details are hidden now
• USB ACM is currently a separate task. For the dongle, this is more or less pointless at it will always used as a USB device. But it's a a good thing when running on the DK: The USB ACM is now optional. However, a pipe between the USB ACM and radio task now is now required to send data from the radio task via ACM.
• I tried to make sleeping work when there is nothing to do using https://rtic.rs/2/book/en/by-example/app_idle.html.
  However, something is not working and the loopback does not work. Did not do any in-depth investigation into that yet.
• Simplified running on the dk board a bit

[robamu]

Unfortunately, this currently breaks the puzzle firmware because both loopback and puzzle firmware depend on the dongle firmware lib. I duplicated the old dongle lib so the puzzle firmware keeps working, to pacify the CI.

[jonathanpallant]

I think I'd rather see the puzzle-fw updated to use the new Dongle BSP in this PR, instead of having two copies of the Dongle BSP in the tree. I'm also not sure that it makes sense to starting pull parts of the BSPs into a shared library - it probably makes sense for a code maintainability point of view (only write things once) but it makes the code harder to read and understand (because now you have to look across multiple libraries). In this material I would prioritise readability over maintainability because we read it (or teach it) much much more often than we update it.

[robamu]

I ported the puzzle firmware now as well, and removed the shared BSP.

However, there is still some weird behavior for the puzzle firmware: When being connected to the serial terminal, the software is a lot more responsive and faster than when not being connected. I am not fully sure what the reason for this is, and this might just be due to my lack of knowledge about the behavior of USB CDC ACM devices.

For example, when connected via serial terminal, the puzzle solution takes 2-3 seconds. When not being connected
it takes a few seconds longer.

[robamu]

Alright. I just lowered the timeout on the packet write, and it seems to work now at comparable speed :)

[robamu]

ready for review now. I also kept the old board initialization function signature, makes this PR a little bit more focused on the port. It is a lot of unwraps but it could be argued that a double initialization will not happen very often and that a panic is okay for an error like this. What do you think (would be a separate PR though).

[robamu]

I did some experiments in https://github.com/ferrous-systems/rust-exercises/tree/sleep-experiments .

I essentially flashed the loopback firmware with sleep handling enabled onto the DK board and created a really simple radio packet sender for the dongle. The DK firmware seems to receive the radio packets, and I can see packets arriving in the serial monitor. So I am not sure what is going on. Why would this not work specifically for the dongle?

[robamu]

Unfortunately detected new issues: I think we seemingly lose data over the serial monitor:

Received 4 bytes (L
Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (L
Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (LQI=55)

Received 4 bytes (L

Update: Fixed. Classic mistake: using write instead of write_all

[jonathanpallant]

I think I've understood how these queues and pipes work. I propose some changes in https://github.com/ferrous-systems/rust-exercises/tree/update-loopback-fw-jp-updates to try and rename the types and variables to be consistent.

[robamu]

well at the very least i got some basic windows setup ready now so I can test this myself in the future. I found the bug. I mis-intepreted a generic (919497c).

[robamu]

there seems to be some github issue..

[jonathanpallant]

github had another outage. Try again now?

[robamu]

could aslo be a cloudclare issue

[jonathanpallant]

I kicked cloudflare.

[jonathanpallant]

My proposed changes branch was updated - feel free to merge it in if you like it.

[jonathanpallant]

Can confirm the dongle channel change now works on Windows, for both puzzle-fw and loopback-fw.

Unfortunately the loopback-fw's default radio channel is 20, but the application is expecting channel 25.

[jonathanpallant]

Unfortunately the loopback-fw's default radio channel is 20, but the application is expecting channel 25.

The application was wrong, and was fixed in v1.28.1.