The circuit board is the interface between the Module electronics and the wiring harness of the satellite. The wiring harness is connected to each Module and to the central Integrated Housekeeping Unit (IHU) and, if present, a backup IHU.

The Widget presents a 44-pin (2 rows, 2mm centers) interface to the Module electronics which, through permanent jumpers on the Widget, is configured to operate in one of four different bus organizations.

To the satellite wiring harness, the Widget presents a 15-pin DA15S connector. DC Battery power, a two-wire differential CAN bus, and a small number of discrete special signals (e.g., an Engineering Beacon) make up the wiring harness.

By having a fixed electrical interface to the rest of the satellite, system integration is greatly simplified.  Testing of the Module electronics via the 15-pin CAN/Power interface is moved into the hands of the Module developer much earlier in time than at final integration. Additionally, all of the modules have the same interface which greatly simplifies the wiring harness itself.  It is now very few wires and the module connections are all identical.

The processor on the Widget circuit board is an ATMEL T89C51CC01ca. It is based on an 80c51 core with on-board RAM, EEPROM, FLASH and built-in peripherals such as timer, watchdog, serial ports, ADCs, parallel ports, and a CAN controller.

The firmware is written entirely in 8051 Assembly Language. The purpose of the firmware is to drive the 44-pin interface based on messages received from the CAN interface and report the state of the inputs at the 44-pin connector back to the CAN interface as requested by messages received from the CAN interface. The complete set of CAN messages is specified in detail and the firmware is written to this specification in order to provide the intended behavior.

The firmware is capable of driving the 44-pin interface in any of four different bus structures.  It reads the configuration jumpers to determine which of these four (standard, multiplexed, byte-pipe, and {as-yet-undefined}) is to be used.  See the User's Guide for much more detail on these modes and the full CAN message specification for each mode.

Three main utilities have been found and adapted, or created for use on this project.  All are released under the GPL.

1. assembler/linker - as31
   We found an open-source assembler with the minimum capability need to produce this firmware.  We built it from source, tested it deeply and adjusted the lister output to our liking.
2. disassembler - d51
   Again, we found an open-source disassembler and both adjusted it to work in this context and used it to verify that our assembler was producing the correct object code.
3. flash utility - flasher
   The Widgets are capable of receiving new firmware via the CAN bus and recording the firmware to its onboard FLASH memory. The ATMEL parts have a permanent CAN Boot loader resident in a separate region within this FLASH memory. This utility is tasked with reading the firmware hex data from a file, adding checksums and Widget version information to the image and then transmitting this "wrapped" code via specialized CAN Messages to the Boot loader on the Widget which then writes it to the onboard FLASH memory. After the image has been completely sent to the Widget this utility then reads it back and compares it to the original image sent thus verifying that the new firmware has been accurately recorded within the Widget.

During Module development designers need a means by which they can exercise the Module under construction.  Instead of needing to create custom electronics, a developer now acquires simple interface parts, downloads free software, connects the parts all together, applies power and is ready to exercise the new Module Under Test (MUT ;-) using the UHU - User Housekeeping Unit software.

Generally, as the Module designer is about to begin, he is given a development package which minimally consists of an inexpensive serial to CAN interface for their PC, a CD-ROM containing the "free' UHU software and the Widget User's Guide in .pdf form.  With this in hand, all that remains is to build a simple CAN/Power cable to specifications contained in the User's Guide.

Once this is all set up and connected, the Module developer runs the UHU software which provides a graphical interface for controlling the Module Under Test. For all practical purposes the interface to the Module is simply a bundle of discrete digital input and output lines and analog input lines. The UHU software is responsible for providing control and display of all of these I/O lines. The UHU software embodies the CAN message specification, precisely. So the traffic over the CAN bus need not be any concern of the Module developer.

Exactly what is controlled via this UHU software and how the Module responds to this control is entirely defined by the Module developer. Ultimately, the final specification for controlling this new Module is sent to the IHU development team so it can be implemented in the IHU firmware.

For developers needing to test with two or more Widgets/Modules on their test harness a higher performing more advanced form of control software is available for the Windows® Platform. This software called CDNC - CAN-Do! Network Controller is capable of running a full satellites' complement of Widgets at full speed (our design maximum of 50Hz polling).

This software can read and send UHU recorded logs and save logs in UHU compatible format as well as it's own format. It offers full control of all aspects of a Widget in each of the three modes. Finally, it provides full decode of all internal Widget logs and status along with descriptive text informing as to what the status values mean.

This CDNC software is developed as our primary investigative control software which we use to learn how constellations of Widgets perform in general, if they are performing correctly and how they perform when run in the new proposed "ring" CAN Bus topology.  This software is general enough in it's ability to control Widgets configured in any of our supported modes that it compliments UHU nicely and now offers our module developers yet another means by which they can control their Module test bench.

CDNC is available as a free download from it's website: http://cdnc.moraco.us