One of my first projects when I joined Stevens was to develop a new data logger. The picture shows both the original enclosure (bottom) and the newer metal chassis (top). The most recent design was getting a little long in the tooth, and users (and sales) were clamoring for more capabilities. My boss found a small microcontroller board that met our requirements: - Extended temperature range. Our equipment was being used all over the world, from Arctic regions to equatorial deserts. This means basically -40 degrees to +60 degrees Celsius (-40 to +140 Fahrenheit).
- Minimal power consumption. Many locations are accessible only by extraordinary means: hiking, mule, airplane, etc. Most locations are not served by power lines. These sites must depend on batteries and perhaps solar panels. Arctic regions are particularly bad. Batteries do not do well in cold weather, and solar panels need sunlight, which is sometimes hard to find in Northern regions.
- A variety of inputs. We needed at least two serial ports, some digital I/O pins and some ADC's (analog to digital converters).
- Very reliable.
The I/O board was not too difficult. There was minimal active circuitry on it. It was mostly connectors for communications and all the various sensors. Once I had drawn the schematic, we turned it over a layout man, and then shipped the layout off to a board house to have some boards made.
We used a small plastic NEMA4 enclosure, and to keep things simple, we used the I/O board as the "front panel". The CPU board was mounted to the I/O board, and then this assembly was mounted in the lid of the box, so the CPU was hidden and all the I/O connectors were exposed. The body of the box was drilled to accept weather proof cable grommets, and the entire body of the box was used to hold the ends of the sensor cables and their connectors. The idea was that the box could be mounted to the wall of a gauge house and the cables routed to the their sensors. The connectors from the sensor cables would be plugged into the connectors on the I/O board that is mounted in the lid of the box, and then the lid would screwed down onto the body of the box, sealing all the electronics and cable connections inside a weather- and bug-proof container.
Firmware
The firmware was by far the bigger part of this project. As always, the more you can deliver, the more the customer wants. Once you have the basic structure operating, adding one more little feature does not take a whole lot of effort. Previous loggers had only recorded data on one or two channels. This logger started with 18 and eventually was increased to over 200 channels. The whole concept of what a data logger was and how it would be used had to be revised. This led to numerous adjustments to the user interface to accommodate the new capabilities while maintaining the same "flavor" as previous data loggers.
Evolution
This project was supposed to be a stop gap measure. It would allow us to get a new product on the market quickly, but given it's limitations in processor and RAM, it was not going to be long before it became obsolete. Fortunately the environmental market is rather slow moving and so even thought the CPU manufacturer has ended development in this product line, the DOT logger lives on.
Compiler Limitations
The compiler reached its' limits several years ago. It was specific to this vendor and it was fine, as far as it went. It had two modes for compiling: one was direct to the target board and the other was to a file. For development, direct-to-target worked fine, but when you were done with development and wanted to move to production, compiling to a file was what we wanted. At some point, this quit working. It may have been due to the size of the program but the compile-to-file option no long worked. Now we could have had manufacturing compile the source code for each board, it would not have added much time, but it did add a certain amount of complexity, not to mention being error prone. I had written some debug procedures to display a hex dump of memory, so I used these, along with file capture on the host to create a hex image of the code. I then wrote a simple program to convert this hex file into a binary image that could be loaded using the standard vendor supplied loader program. This allowed manufacturing to continue using the same procedure as they had been using on earlier versions of the firmware.
Field Updates
Since we had encountered so many requests for changes and features during the development of the firmware, we decided that it would be a good idea to provide some method for updating the firmware in the field, possibly even over a remote connection, like a phone line. The initial program is loaded into the CPU through a serial port using a vendor supplied loader program. In order to use this program, a jumper had to be set on the CPU board. Once the logger was assembled, this jumper was no longer easily accessible. To avoid having to gain physical access to the logger in order to update the firmware, I developed a download subsystem for the firmware that would perform this operation using standard Xmodem protocol, and without having to set the jumper.
This program was fairly straight forward, though there were a few critical places where the machine instruction sequence was absolutely critical. The CPU board has two 256 KB Flash memory chips. One was used for code, the other for recording sensor data. To perform a firmware update, the new code was downloaded onto the second chip. Then a special piece of code is copied to RAM, execution is transferred to this code in RAM. The RAM based code then copies the new firmware from the second chip to the first. We then execute a reset, and if all went well, the new code takes off and runs.
The major difficulty with this bit of code was in figuring out how to set the memory mapping registers. This is an eight bit processor with a 64 KB address space that is mapped into three windows into a one megabyte physical address space using a couple of memory mapping registers.
No comments:
Post a Comment