Arduino mega(1280) hardware serial communication problem w/jpeg camera

Projects Networking, Protocols, and Devices
1

Hello,

I am using this camera(http://www.sparkfun.com/products/10061) with arduino(m328p) & arduino mega(1280). The arduino(m328p) works with this camera using software serial at 38400. I would like to achieve higher baud rates, so I hooked up the camera to the mega onto the Serial1 hardware interface. It appears to be sending the messages correctly, however I am having a problem reading the data back from the camera. There appears to be a latency issue. A message of 16 bytes is sent to the camera, then it sends back a response header(5bytes 7600320000) + data(32 bytes) + end data(5bytes 7600320000). I am only interested in the data, which are the image bytes. This is done in an iterative process, by incrementing the read address by amount read on each iteration. The library I am using is from sparkfun(found at the link for the camera above), it has a routine to capture this data, which is shown below. I am reading the data back onto the Arduino IDE serial monitor. I placed the output of the arduino(328p) and mega below to help resolve this issue.

The only change I have to Sparkfun library is switching from software serial to hardware serial 1. I suspect the problems lies in one of 3 things.

  1. There is an issue with latency on the mega serial ports, due to the serial library?
  2. There is a difference in the variables sent back from arduino vs. mega, uint16_t vs. uint8_t?
  3. There is a problem with address or read_size variable that is causing a problem in the send command, although I verified that it sends the correct command, seems to be working.

Can anybody help guide me to a solution?

Thanks,

-ren

//these variables are declared in the program as such
const int read_size=32; //constant amount of bytes to receive
int address=0; //value is incremented each time thru loop

int JPEGCamera::readData(char * response, int address){
int count=0;
Serial1.flush();
int i =0;
//Send the command to get read_size bytes of data from the current address
for(i; i<8; i++)Serial1.print(READ_DATA*);*
Serial1.write((uint8_t)(address>>8));
Serial1.write((uint8_t)address);
Serial1.write((uint8_t)0x00);
Serial1.write((uint8_t)0x00);
Serial1.write((uint8_t)(read_size>>8));
Serial1.write((uint8_t)read_size);
Serial1.write((uint8_t)0x00);
Serial1.write((uint8_t)0x0A);
//reads off header
for(int i=0; i<5; i++){while(!Serial1.available());Serial1.read();}
count=0;
while(count < read_size)
{
while(!Serial1.available());
*response++=Serial1.read();
count+=1;
}
return count;
}
38400 baud. Arduino software serial. Output back to serial monitor using PrintHex83. 2 iterations shown.
040509070705080b0a0b0b0b0a0b0a0c0e110f0c0d100d0a0b0f140f10121213
ffd8fffe00240c041098000000000000000000000000000000f00040010c0032
...
38400 baud. Arduino mega using hardare serial 1. Output back to serial monitor using PrintHex83. Notice how 7600320000 is drifting,eventually settles into set location, note lower bottom right. Multiple iterations shown.
ffd8fffe0024f30b5f20000000000000000000000000000000f00040010b0032
7600320000120b510451040000ffdb0084000302020202020302020203030303
76003200007600320000040408060605070a090a0a0a090a090b0c100d0b0c0f
0e0f1011127600320000760032000012120b0d13151311151011121101030303
0408110b0a0b1111111176003200007600320000111111111111111111111111
1111111111111111111111111111117600320000760032000011111111111111
1111fffe0005000000ffc000110800f001400301763200007600320000210002
ffc401a200000105010101010101000000000000003200007600320000030405
0b01000301010101010101010100000000000001023200007600320000060708
02010303020403050504040000017d0102030004113200007600320000314106
7114328191a1082342b1c11552d1f02433627282090000760032000018191a25
3435363738393a434445464748494a5354555657580000760032000063646566
7475767778797a838485868788898a929394959697000076003200009aa2a3a4
...
38400 baud. Communicating directly using serial monitor. Output back to serial monitor encoded as hex. Includes response header + data + end data. 2 iterations shown.
76 00 32 00 00 FF D8 FF FE 00 24 00 02 50 4B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 00 40 01 0D 00 32 76 00 32 00 00
76 00 32 00 00 12 0B 51 04 51 04 00 00 FF DB 00 84 00 03 02 02 02 02 02 03 02 02 02 03 03 03 03 04 07 04 04 04 76 00 32 00 00

2

Does your code really have smiley faces in it? If not, modify your post. Delete the code. Press the icon above with the # on it, and paste your code again. Save.

What version of the IDE are you using? The Serial1.flush() call is almost certainly not needed.

Does the Mega capture data correctly at 38400?

3

Paul,

I updated the post(turned smileys off).I am using Arduino 1.0. I had to update the sparkfun library to work with 1.0. Yes, I did an independent test at 38400 sending / receiving to the mega serial port, seemed to work fine.

What is particularly confusing is that I have run this same code with the 328p @ 38400 with software serial without problems. Only change is moving to mega and updating to hardware serial port. The mega should output the lines as the arduino with software serial, similar to lines below. Instead I am getting back the response header(7600320000) and end data(7600320000) in the output.

040509070705080b0a0b0b0b0a0b0a0c0e110f0c0d100d0a0b0f140f10121213
ffd8fffe00240c041098000000000000000000000000000000f00040010c0032

Thanks,

-ren

4

Paul,

I updated the post(turned smileys off).

That was not what I told you to do.

Does YOUR code really contain:

for(i; i<8; i++)Serial1.print(READ_DATA);

I am using Arduino 1.0.

So, you should be aware that Serial.flush() now blocks until the send buffer is empty. Is that something useful for your code to be doing?

Yes, I did an independent test at 38400 sending / receiving to the mega serial port, seemed to work fine.

This looks an awful lot like a clue, then.

5

It looks to me the Serial1.flush is not discarding the remaining 76 00 32 00 00.
You can try to just read off those extra bytes just like the for loop for skipping the header.

6

It looks to me the Serial1.flush is not discarding the remaining 76 00 32 00 00.

Well, of course it isn't, because OP said:

I am using Arduino 1.0.