Unable to run madgwick/viz demo

[JoshMcguigan]

I am having some trouble running the madgwick example with the viz demo. I am attempting to use ITM over the USB port so I have uncommented the following in my .gdbinit:

monitor tpiu config internal itm.fifo uart off 64000000
monitor itm port 0 on

I have also added a jumper between PB3 and SWD. To test this setup, I did run the itm example, which does work as long as I change the 64000000 above to 8000000.

When I run itmdump -F -f /tmp/itm.fifo I either get nothing, which is surprising to me, or I get jumbled text, which I think would be expected given how the data is encoded?

But then when I run itmdump -F -f /tmp/itm.fifo | cargo run within the viz directory (I added a .cargo/config to target my machine in the viz directory so I can run this from within the f3 project), I either get the GUI showing up but the square just renders in the initial position and doesn't move at all, or I get an instant crash with the error end of file during packet.

I did try originally to set this up using a UART to USB adapter, but I ran into some trouble when trying to configure the adapter:

Joshs-MBP:viz josh$ stty -F /dev/tty.usbserial-AC01X6VL raw 2000000 -echo
stty: illegal option -- -F
usage: stty [-a|-e|-g] [-f file] [options]
Joshs-MBP:viz josh$ stty -f /dev/tty.usbserial-AC01X6VL raw 2000000 -echo
stty: tcsetattr: Invalid argument

I am on OSX, if that matters. Are there other requirements necessary to run this that I've missed?

[JoshMcguigan]

Based on this stackoverflow thread, it looks like there are some differences between stty on linux and mac.

https://stackoverflow.com/questions/34233066/change-the-baud-rate-stty-on-mac-terminal

I also determined that the invalid argument issue above when setting up the serial port is related to the speed. Running stty -f /dev/tty.usbserial-AC01X6VL raw 115200 -echo does not cause the invalid argument error, but as discussed in the thread linked above, the speed setting is not saved.

In hopes of avoiding this issue altogether, I tried to modify the speed to the default setting on my machine by changing let swo_freq = 9_600; and setting the following line in my .gdbinit monitor tpiu config external uart off 64000000 9600. When testing this, I did comment out the other two lines listed in my first post. With this configuration, running itmdump -f /dev/tty.usbserial-AC01X6VL | cargo run renders the green square in the initial position and it never moves.

[JoshMcguigan]

Using the configuration from my first post, I was able to import the iprintln! macro into the madgwick example and successfully print a string over ITM via USB, so that part I can validate is working. It seems like somehow the data is getting corrupted and causing itmdump to crash which I believe causes viz to close.

I've also noticed occasional panics from the example code, but I think those may be unrelated.

panicked at 'attempt to subtract with overflow', examples/madgwick.rs:224:24

[JoshMcguigan]

So I tweaked the viz example a bit to handle errors without crashing, and now I can see that it does seem to be getting data. I am just thinking perhaps the values are for some reason smaller than they should be?

(0.9966575, 0.04070263, -0.06756665, 0.021259157)

That is a typical value grabbed from within the render loop.

Sorry for all the posts, I just want to make sure if someone else has this issue in the future they know how it is resolved.

[JoshMcguigan]

I've resolved this by updating my installed version of itm cargo install itm --force, as suggested in rust-embedded/itm#14.

The attempt to subtract with overflow error still happens occasionally, but it is less frequent. I could see solving it by either changing the subtraction to saturated subtraction, or converting to f32 before the subtraction rather than after the subtraction (which is effectively what the magnetometer and accelerometer readings do).