If the cables are not disconnected in between basked the game is put into a weird stagd

Implement messages that allow any module to request audio be played back from a module with an sd card and audio module.

It appears that the can peripheral is not causing interrupts to wake the application out of DOZE.

This isn't a real issue for the main application as the clock is waking it every 0.5ms anyway, but for the flasher it stops it doing anything as there are no other triggers to wake from DOZE.

The sleep() line is commented out in the flasher.

Game modules need to be able to be disabled and enabled, create two more callbacks for each state transition.

Each module then needs code for making everything idle/off.

All modules currently init the LCD screen regardless of if they use it. This should be changed so that they only init it in the module's specific *_initialise() code. Remove lcd_default() from everywhere. This is the first step to the new main board respin with a custom module PCB for driving the LCD.

The current implementation of "over-the-air" firmware updates is relativly naive. The KTANE firmware is limited to 63kb, this is under half of the 128kb that the PIC18F57Q84 has.

The memory layout is as follows:

• 0x000000 - 0x00FBFF (Firmware Main)
• 0x00FC00 - 0x01F7FF (Firmware Staging)
• 0x01F800 - 0x01FFFF (Flasher)

When the firmware detects that new firmware is available it wipes the staging area, and then proceeds to pull firmware from the remote module and place it in the firmware staging area.

If it then passes the CRC32 the program jumps to the flasher, the flasher disables all interrupts, DMAs, etc and copies the firmware from the staging environment to the main space, then issues RESET().

This is how firmwaring works at current, it was simple to implement and has been reliable. However this means that 63kb of ROM space is unavailable to the module, and space is now becoming an issue.

A better way of handling this would be to move to a bootloader, firmware and CAN aware flasher combination. This would look like the following:

• 0x000000 - 0x0000FF (Bootloader)
• 0x000100 - 0x01EFFF (Firmware)
• 0x01F000 - 0x01FFFF (CAN Flasher)

The PIC18 would init to the bootloader, based upon a flag in the EEPROM of the PIC18 it would chose to jump to the firmware or the CAN flasher. Under normal operation the bootloader would immediately jump to the firmware.

The firmware would operate as normal, but not participate in actively retrieving firmware (though would have code to distribute firmware). If the firmware detected there was new firmware, then it would store its CAN id, the remote CAN id of the firmware, the new firmware version, new firmware CRC in the EEPROM, as well as activate the flag to jump to the CAN flasher, it would then issue RESET().

The bootloader would then jump to the CAN flasher, which would init the CAN stack, and begin retrieving firmware pages via CAN, writing them directly over the existing firmware. Once the transfer was complete the CRC32 would be verified, assuming it was valid the EEPROM would be reset back to jump into normal firmware, wiping out the existing CAN details for the flasher.

If the CAN flasher failed to verify the CRC32, then it would increase an attempt count and RESET(), attempting the process again. This would be retried for a specific number of attempts.

This new approach would give us just under 124kb of ROM, almost double the current program space.

When using the Operator module after successfully completing the module the module returned to the default state as if not completed but was counted as a completed module

At current the SPI HAL is limited to X number of devices/commands, there isn't actually a need for devices to register with SPI first.

Instead migrate spi_device_t to be a ptr on spi_command_t. Further, add a spi_command_t *next ptr. This means that SPI would just need to keep a single ptr to the head of the queue.

This removes the need for modules/opts to track the device id, and any limits on registering and queuing.

Known Issues

• OVER never migrates back to IDLE.
• Module isn't set to UNREADY after OVER.

Migrate ARGB to use SPI - this allows multiplexing SPI1.

Now we have FAT in KTANE we need to be able to read files from the SD card by indexes.

Issues

The current A01 revision has the following issues:

1. I2C is not available on any output port.
2. SPI is only available on bomb ports B and C.
3. DAC is only on port A, though this is unfixable without an analogue switch.
4. It runs at 5V, could it run at 3.3V.
5. ICSP interface is unreliable, LCD and ICSP share pin.
6. LCD connectors are wasted on 75% of modules, 10 pins.
7. We are unhappy with the 3.5mm TRRS connectors, can we move to RJ45 and a hub/edgework board.

Minor fixes.

1. Need to migrate to magnetic buzzer.
2. ICSP is labeled incorrectly as ISCP.
3. Bomb ports being A-C is confusing with PIC ports being A-F. Could rename bomb ports to 0-2.

Approaches

One

We need I2C for the power supply module, the least effort approach is to scrap the dedicate LCD ports. This solves points 5 and 6. It can be replaced with another bomb port (D) which is supplied by PIC port C, which has I2C and SPI.

The LCD interface can be moved to a plug in module with a shift register, which can run in any bomb port with SPI. This also addresses point 2, as SPI would also now be available via bomb port D.

This is relatively light touch, although it does mean respinning all 10 bomb module control boards.

Two

We don't actually need a fourth bomb port, only Controller, Combination and Simon Says use two ports as it is. If we convert the LCD to a module then it will use the third bomb port on the Controller, other LCD modules would still have one free port. Edgework which would likely have an edgework IO module, audio module and SPI module, which would fill it - that seems reasonable.

There are 4 +5V and 4 GND pins on every bomb port, this is unneeded and was only done to make use of the pins. We could take SPI and I2C from PIC port C, and expose them on the lower row of pins, so rather than:

|VCC|VCC|VCC|VCC|GND|GND|GND|GND|

We could replace it with.

|VCC|I2C SCLK|I2C DAT|SPI CLK|SPI COPI|SPI CIPO||GND|

However this breaks compatibility with all of our plug in modules, some would be modifiable by cutting traces, but some like the SPI and Power boards would need larger rework.

If we introduce 3.3V and are respinning all boards, then:

|VBUS|V3,3|GND|I2C SCLK|I2C DAT|SPI CLK|SPI COPI|SPI CIPO|

ARGB can then move to the SPI peripheral properly, though we will need to switch the ARGB CLK pin with a chip select line if they are commoned (mosfet).

At the moment peripherals like ARGB, LCD, keymatrix all have statically allocated RAM. The RAM should be moved into the modules mode_data_t union structure, that way RAM isn't being wasted when the LCD (4 * 20 * 3) or ARGB (40 * 3).

This isn't a problem at current, but maybe once sectors from the SD card are being buffered for DAC output.

As in title, it only updates the screen, it shouldn't need to run at that frequency.

To avoid confusion migrate all abstractions into a specifically named HAL.

Add the following functionality:

• Requesting resources such as UART and PWM by port.
• I2C HAL, similar to SPI.