A discussion on the code structure

[george-cosma]

As work for the rust port of tockloader begins, I believe we should start thinking about how the structure of the project will look. I'd like to start this discussion by breaking down how the python version is currently structured.

• main.py - The main bulk of command line interpretation is done here.
• tockloader.py - Here we can find the logic to create an instance of an interface between the board and the PC. This is also where the CLI command given to tockloader are resolved through calls to methods attached to the aforementioned interface.
• board_interface.py - Defines a generic class (BoardInterface) that acts as an intermediary between the board and the PC. In code, this is mostly used to define some constants and methods which do not vary between communication method. This class is inherited by the following:
  • BootloaderSerial (bootloader_serial.py) - Communication is done directly through serial.
  • OpenOCD (openocd.py)
  • JLinkExe (jlinkexe.py)
  • FlashFile (flash_file.py) - Not as relevant for us at this point

The rest of the files contain either helper functions, or logic related to applications.

The first thing that I would like to tackle is the topic of inheritance - I believe most if not all of the BoardInterface class can be broken down into constants and traits ( some with default implementation ). The rest of the child classes can be structs that implement these traits.

The second thing I'd like to bring to discussion is testing. Tockloader is a tool that is used on various platforms, and with various pieces of hardware. There are bound to be compatibility problems at one point or another, and I believe a robust testing system should be put in place.

One of my first ideas was, after splitting up BoardInterface, to create a mock interface that can be used in tests. Two simple functions that imitates writing & reading from the serial port using buffers would suffice for most tests. I would also suggest that the mock interface be able to read it's mock data from a file - this being potentially useful in edge cases.

---

Right now, it's hard to say how the project will look in the future, but I think we should still establish a basic outline now and adapt as we go. I'd like to hear what other people think about this topic.

[hudson-ayers]

+1 for BoardInterface becoming a trait that gets implemented a few times.

I don't have strong feelings on a test interface for now. I might recommend setting up a basic CI workflow to run rustfmt / 'cargo test' / clippy on PRs so that you you have unified formatting from the start and can easily add tests as you go.