fine tune trade process

[securelyfitz]

right now it mostly works but has a few software delays hard coded for ease of debugging.

probably makes sense to break out 'transmit' and 'receive' into class member functions to make the trade logic a bit cleaner

also - once a trade happens, the card needs to be validated and both the card and handle need to be stored properly

[securelyfitz]

seems like tx/rx is reliable enough it's best to just do it once, plus then you don't get misaligned byte pairs also, seems like uart timeout is good enough if set low. still need to clean up code and remove print statements

also - clue validation happens in the game data structure

[securelyfitz]

fixed an annoying issue where if i sent too much data (~20 bytes) the rp2040 would hard crash a few seconds later. no errors. added a flush() after each byte write, while excessive , gets it one.

still need to clean up overlay geometry

[securelyfitz]

overlay and text cleaned up. annoying hard crash issue disappeared for small transactions, but is now blocking TX/RX. some details:

• ONLY happens with RX
• ONLY happens when RX receives some data - if nothing recieved, no crash
• Happens WHETHER OR NOT valid details recieved, but ALWAYS happens when valid details recieved
• Example: go to RX mode, point camera with IR rangefinder at badge - no valid chars received, but crash happens
• things still work UNTIL leaving the trade screen - shifing back to the previous screen
• doesn't matter what screen you shift back to
• crash happens on different lines of code at different times
• it's incredibly hard to debug because it's a hard python interpreter crash that kills the usb-serial
• only way back to functioning is full power cycle
• there's an irda phy that can have power enabled/disabled
• tx data is echoed back by the phy, so uart rx is flushed after EVERY SINGLE byte sent
• TX works fine, commenting out just the RX line clears the issue completely

theory:

• RP2040 hardware uart is recieving properly
• circuitpython reads the data and buffers it
• circuitpython has a memory issue where if's overfilling a buffer or something, corrupting other memory.

[securelyfitz]

More notes:

• i've isolated a minimum case of the failure. By instantiating fakeirda and immediately powering on the badge, then sending data, it will immediately hard crash (circuitpython crash to recovery mode)
• I've tried slowing down the transmission which didn't seem to have any improvment
• i'm trying transmissions starting at 1 byte at a time and incrementing my way up. Considering the doubling of bytes that happens:
  • Up to 18 bytes works fine. 20 bytes fails.
  • sometimes 20 bytes results in a nonsensical error in dpad.py
  • more than 20 always results in hard crash

[securelyfitz]

workaround is to use busio to create the UART interface with a large buffer. Have not isolated the missing bounds checking.

Solved two issues with TX/RX sync with a lead-in of carriage returns:

1. the first few bytes sent after power is enabled to the IRDA phy seem to be error prone. A lead-in of CR's gets some run time before transmitting the data. Received CR's are then trimmed as whitespace.
2. sometimes, the 2-byte symbols are misaligned. To fix, the fake_ira.readbyte member checks every byte coming in - if twice in a row, it receives a misaligned CR's, it reads and drops one more byte so that it's back in sync

With this, the majority of transmissions are flawless. There are still occasional bitflips, but crc/encryption should easily catch those.

Closing this for the badge - but will pursue the memory corruption issue elsewhere.