Worked on the firmware for the display board this past weekend while watching football. Nice part was that it went really well, and the first cut of it is completed. It has all of the functionality including an opening message when the the display controller starts.
The display controller works as follows:
First step is the bootloader which verifies the integrity of the application firmware. While not strictly needed on this project, I work on a lot of safety critical firmware and verifying the code integrity is required in those situations. (The code was used in one project to identify a bug in a Microchip processor that was not documented in the errata, but all the FAEs know about it. This is why I never use Microchip processors. If your chips have known bugs, put it in the errata!!).
Next step is to test if the processor should stay in the bootloader waiting for a code update. To force the code to the bootloader, boot the processor with the i2c SCL line low. This should never happen in an operational set of displays because the i2c bus requires pullups. Code updates through the bootloader can be done using a serial port. (Added a connector to the card to support this function) The bootloader also lights a new LED on the display card to indicate it is in boot.
If not staying in the bootloader, a test message is displayed on player scores 1-3, and the firmware version number is displayed on player score 4. The credits/match both display “88”. This message is displayed for 5 seconds.
Now the processor starts looking for valid strobe signals from the MPU. If a strobe is active for 200us and the BCD inputs are stable during that time, the BCD inputs are recorded. If any inputs change, the timer is restarted. The BCD digits are compared with what is currently being displayed, and if it is different a bit is marked to update that display digit. This processing occurs in the digital task. After the update bit is marked, the task waits for the strobe signal to be disabled.
At the same time, the i2c task looks to see if any displays need to be updated. If so, it clears the bit, and sends an i2c msg to update the pair of digits. The update pairs are abbacc when looking at the player scores. (If a player has 123456 for a score, and gets 30 more points, 86 is written to the last two digits since the processor always updates in pairs. The pairs are a little strange because the display board only has four digits, and there is an unused digit between them. In the above lettering, the display board only has bb and cc digits.)
That is all the code does. Not terribly exciting. The 200us filter should make sure that the board never acts on glitches.
The biggest thing was putting the standard code in the repository. I wrote the code about 15 years ago, and it used to live on a server running in my basement. My ISP told me they needed to start charging me for a static IP address, so I turned off the server. I’ve been meaning to put it back up on the web, so this has been a good kick to make me do that.
I threw up three different projects. Hexmerge is the utility that merges the bootloader with the application code, and adds the CRC to the application so that the application integrity can be insured. (It also spits out the CRC of the bootloader, application, and whole image which is nice to make sure that the code is reproducible) The bootloader lives in the HCS miniboot directory. (This is the standard bootloader I wrote for Motorola/Freescale years ago, and was originally coded for a Motorola 68HC11. I don’t know if you can even buy those processors anymore.) The last piece is the standard library which I wrote originally in 1996. I’ve ported it to three or four different types of processors/DSPs, and basically it is a template for the minimum functionality required of an embedded system and other utilities.
All the project is waiting for is Mark to finish approving the schematics, and off they go to China. Mark did verify the spacing of the mounting holes and the LCD digits so that part is completed. Each player score needs to move the bottom mounting standoffs since these boards are smaller than the originals. The master display needs to move all of it’s mounting standoffs since it is much, much smaller than the original.