Technical Design

There were three main hardware components to our robotic project: The oopic, the receipt printer, and the light sensor. Then the hardware interconnects and microcontroller software made up the software side.

Hardware:

Oopic: http://www.oopic.com

The oopic is a small microcontroller that runs an interpreted language similar to basic. To program it, it is connected by a serial port to a PC and compiled code is sent to it. The Oo-pic has an abundance of I/O options such as digital I/O lines, pulse width modulation output lines, 12-bit analog to digital input lines, I2C networking, RS-232 communications, and so on.

In our project, we used quite a few digital output lines, and an analog input for the photo-sensor. The aspect in which we really pushed the chip was in memory storage, storing over 4K of poem text in the EEPROM. Loading text required some interesting procedures which are discussed in the software section.

Receipt printer:

For the printer, we used an Epson TM-300 receipt printer. This printer uses 3” roll paper and can print 40 characters per line in dot matrix text. It uses a 36-pin parallel connector, but does not communicate like a normal PC printer. It uses a simpler protocol with some control codes. For our purposes, none of the hardware of the printer needed to be modified, except that we painted the exterior. The 36-pin printer cable and power supply cable were cut and lengthened so that they could go through the pole.

Light Sensor:

This was a very simple circuit and only used one A2D line on the oopic. A photo resistor was placed in a simple voltage divider circuit, and the oopic measured the voltage between the ground and the photo resistor node. This voltage was sampled at certain parts of the program and converted into an 8 bit value which was then compared with a calibrated threshold.
Hardware interconnects:

For connecting the printer we used 8 digital I/O lines for the parallel data bus, one line for the data strobe, and several other protocol lines such as prime, acknowledge, etc. In the end we only needed the data bus and strobe line, since instead of negotiating data transfer timing, we simply wrote in a delay of 200ms after every line feed.

For the analog light sensor, we wired the oopic Vcc and GND lines to the circuit, as well as one of the A2D lines.
All the printer lines, including grounds and other signal lines, had to make it through the pole to the top, so there were a lot of wires and solder points.

Software:

The software to make all these disparate parts function together was not trivial. Except perhaps the light sensor; the oopic libraries for using the A2D are very useful and straightforward. The oopic automatically polled the line and ran the A2D conversion every time we used the value in the program.

The printer was somewhat more difficult. Printers run on parallel bus interconnects, which means that the printer receives more than 1 bit at a time – in this case, it receives bytes at a time, or 8 bits. Since the 8 bits being sent can’t reliably change all at the same instant, there is also another line called the strobe. The strobe is there to tell the printer when to poll the 8 data lines, once the PC or oopic has gotten the 8 data lines to the next state for the next transmitted byte.

Fortunately, there was a datastrobe object included in the oopic libraries. It was written with LCD screens in mind, and so the documentation dealt more with 4-bit parallel transmission. We did successfully implement the oopic datastrobe object and get it to communicate with the printer.

Once we had the printer communicating and printing, we used string objects to store text in the program body. These seemed to work fine, however, they were unfeasible when trying to store significant quantities of text.

Apparently, due to the interpreted nature of the oopic basic code, string objects become unexpectedly large. Every 40 character line we had in the program code took up over 120 bytes of EEPROM. Inspecting the byte code revealed that each character was padded by two byte long op-codes. Since we had 5K of text and 8K of total storage space on the oopic, clearly this wouldn’t do. We had to come up with a solution that would allow strings to be stored in a normal space, where each character took up only one byte.

The oEEPROM object in oopic’s language was what made this possible. This object gives direct, read / write access to the full contents of the EEPROM. So, as one can imagine, it must be used very carefully, since it would be easy to accidentally overwrite code sections, or even possibly overwrite the interpreter code, serial transfer code, and other things that could render the oopic chip temporarily or permanently inoperable.

The oEEPROM Data() method places the EEPROM pointer after all program code, after all used data memory and at the first available empty memory for program data. Raw data can then be written to the oopic EEPROM. This alone wouldn’t solve the problem, since once the text had been written to the rom, there was no organization and no way to retrieve it. So, while the text was being written to the ROM, an array of pointers was being generated, which would point to the locations of each stanza in the poem.

Once the pointer array and ROM writing were complete, later in the program the text could be accessed by re-pointing the oEEPROM object and reading out raw data.
Using this method, we were able to store 5K of data, and still have plenty of room for program code.