CMUcam4

This is a mostly tested CMUcam4 interface library for the Arduino.

Right now, the library is not heavily commented. I will put a wiki page up about the library in the future after more testing and documentation. This library supports every feature the CMUcam4 has. Most of the functions in the library can be understood by just reading the CMUcam4 Command List and do not require documentation.

About this library:

It uses up a fair portion of the Arduino's memory. Make sure you are not using up all of your RAM for your application - see here for more details.

This library includes an Arduino wrapper object called CMUcom4. The CMUcom4 library is a wrapper for all Arduino specific functionality. This means that you only have to change the code in the CMUcom4.h and CMUcom4.cpp file to port this serial interface library to other microcontrollers. However, the following rules about C data types must be observed. For example the -mint8 avrgcc option will break the CMUcam4 interface library because the -mint8 option does not follow the above rules.

When the serial programming cable is plugged into the Arduino it will override the CMUcam4's ability to communicate to back to the Arduino. When this is the case the Arduino can talk to the CMUcam4 but the CMUcam4 cannot talk back to the Arduino. This causes the interface library to think the CMUcam4 is not attached to the Arduino because it does not get a response from the CMUcam4. The interface library will then send the reset command to the CMUcam4 multiple times in a row for each function in the interface library that is called until the CMUcam4 responds. When this is going on you will notice the red light on the CMUcam4 turning on and off as the CMUcam4 is being told to reset constantly by the Arduino.

To fix this problem - simply unplug the serial programming cable from your Arduino after loading your sketch onto your Arduino. This will then allow the CMUcam4 to talk back to the Arduino and everything will work.

Unfortunately, nothing can be done about the above problem. Because the regular Arduino only has one serial port you cannot share it between the serial programmer and the CMUcam4. But, there is a silver lining. Because the serial programming cable overrides the CMUcam4's ability to talk to the Arduino you can reprogram your Arduino attached to the CMUcam4 without having to unplug the CMUcam4 from your Arduino. You can use the softwareSerial library and an external LCD that accepts serial input to debug your code then.

When creating the CMUcam4 object you can pass it a serial port parameter to change which serial port it uses. For regular Arduinos this is not an option. For the Arduino Mega variants you can pass it 1, 2 or 3 to use serial ports 1, 2, or 3 instead of the default serial port. For example:

// Do...
CMUcam4 cam(2);

//Instead of...
CMUcam4 cam;

// To use serial port 2 on the Arduino Mega instead of the default serial port. You can also pass in 1 or 3 for serial ports 1 or 3 respectively. Any other value than 1, 2, or 3 uses the default serial port.

Last, but not least. You need to call the getType_DataPacket functions when in streaming mode. If you do not the serial buffer for the Arduino will fill up and start throwing away serial data. This will then cause the serial interface library to get confused because it will try to parse corrupted packets that are missing some bytes. For text packets this is not too much of a problem because there are certain sentinel characters that the interface library can look for when parsing data. These sentinel characters will help the CMUcam4 interface library get in sync with the serial data even if a few bytes were thrown away.

For binary data this is not the case. You must receive binary data on time, every time, when the CMUcam4 is sending it. For example, when in line mode the CMUcam4 sends binary data. If you do not call the getTypeFDataPacket function in time to receive the binary data the data packet will be corrupted. Not only that, but the interface library will then expect the missing bytes to be sent and will interpret any bytes sent from the CMUcam4 as binary data until it has the expected number of bytes for a Type F Data Packet. This can keep getting worse and worse until the only way to get back in sync with the CMUcam4 is to reset it. The idleCamera function may work also, but can get confused by binary data that looks like some of the sentinel characters.

Besides for the above the serial library is ready to be used. Try to avoid calling the listDirectory, sendFrame, and printRead functions. They have not been tested at all yet.

You'll find that the serial library is very good even considering all the above. As long as it is used properly it handles communicating with the CMUcam4 very nicely.

I will get the library tested and I will put up more information as I have time.

Thank you,