Logical overview
Selecting I2C peripheral components greatly simplifies the hardware and software implementation of the device. Most modern MCUs have facilities for I2C built in to their hardware which removes a fairly sizeable firmware overhead.
Chassis layout
With the majority of components selected, it is possible to begin hashing out a layout for the chassis for the rover.
After sketching out major components and their possible configurations, models were acquired or built for the various parts and arranged in SolidWorks. The sheet metal chassis was then constrained, in context, against the other components.
With the basic layout completed, additional holes were added to the chassis part for cable ties. Next sheet metal press fasteners (nuts, inserts and studs) were added to make for an easy assembly job. "Penn Engineering's PEM Fasteners":http://www.pemnet.com/fastening_products/pem-self-clinching-fastener_new.html (FSH and so on) covered all the required bases and made for an easy fit with the 2mm aluminium sheet that the design targets.
Electrical and electronic design
With a large portion of the mechanical design completed it was possible to start pulling the electrical and electronic parts of the system.
With the power source already defined (NiMh battery packs) and their physical location set in the chassis it was important to find a sensible way of actually attaching the power packs to the rover's drive and logic systems. With PCB mountable JST connectors to mate with the battery packs no where to be found, a simple screw down terminal block would have to suffice.
The MD25 control board comes complete with a 5v 300mA regulator to drive its on board MCU and other logic as well as a number of power/data connectors which provide access to the logic drive 5v and the I2C bus. 300mA is more than enough to run the logic board, some LEDs and the I2C sensors. The bus cable feeds power "back" to the main logic board which in turn communicates with I2C peripherals via the MD25 board.
MCU requirements for this project in the first instance were actually fairly straightforward.
- Hardware I2C support (2 I/O pins)
- Simple programming/debugging interface
- 8 GPIO lines for motors and LEDs and indicators and so forth
Within the constraints of the project, there are (at time of writing) 66 MCUs in the 16F series which are readily available through standard channels. Eliminating devices with insufficient I/O ports and those lacking an internal MSSP peripheral (the device onboard the PIC which handles I2C communications in hardware) brings the countdown to 12 devices. Removing the 40 pin devices (which are just too big!) leaves six chips to choose from.
From the remaining six devices the PIC 16F1936 has the largest size EEPROM, RAM and program memory (per unit cost) as well as an internal oscillator (negating the need for additional clock generating components) which would make it an obvious choice. However, careful review of the device specification reveals that the ISCP feature on this newer MCU only functions with newer programming and debugging equipment – which – I do not have access too.
For these reasons, the PIC 16F876/873 MCU was chosen as the base for this project. A well understood and documented part supported by many debugging tools; it fulfils all the stated requirements. Past experience developing with 16F877 make writing code for these smaller units relatively straightforward.
Detailed hardware/software considerations
While the ports on a PIC MCU are easy to map to different functions, the locations of certain internal peripherals are fixed (relative to their output pins) and so it makes some sense to logically separate the different functions the MCU must perform and arrange the connected hardware appropriately.
- No analogue functions are being used on the MCU so PORT A is available as a contiguous block. Status indication LEDs are connected to PORT A
- PORT B is reserved for ISCP – not all of PORT B is involved in ISCP but the other peripherals located there are not being used and GPIO can be done elsewhere on the device
- The MSSP and UART are connected to PORT C and so the I2C bus should be connected here. As the MSSP and UART use different pins, it will be possible to add other serial devices to the design at a later stage if required
- PORT C is also connected to the PIC’s CCP units which are responsible for PWM output. Connecting the fan motor here will allow for hardware based speed control of the extinguisher device.
Having a whole 8-bit port dedicated to status LEDs may seem excessive; they are useful for a number of things. In the first instance, they provide a quick visual clue as to what and how the rover is currently doing. The I2C peripherals provide a variety of additional information about themselves which can be useful to know at a glance – battery voltages and error states for example. Access to a contiguous 8-bit port also provides a great debugging tool – it is super easy to write values to a port and thus “see” a particular variable or number change inside the device without having to have the ISCP dongle attached.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.