MooMFMoo
Registered: 05/10/09
Posts: 3
|
|
|
Reply with quote | #1 |
Hi,
anyone attempted to use a FPGA development board to grab frames from the uCAM?
I'm having troubles getting the uCAM to acknowledge the commands sent to it from the FPGA.
I know thats the board is transmitting the correct commans in hex because I've tested it by connecting it to the computer and used Matlab to act as the uCAM.
The development board I am using is the "LiveDesign Evaluation Board" with the Spartan 3 XC3S1000-4FG456 chip.
So what I've been trying to do is actually sync the camera with AA 0E 00 00 00 00h.
Either the uCAM doesn't recognise the command or the board is transmitting gibberish which should'nt be the the case because I've used Matlab to obtain an image.
Anyone know if its a serial communications protocol problem? or if its uCAM problem?
Thanks.
|
| | meldavia
Moderator
Registered: 18/03/07
Posts: 268
|
|
|
Reply with quote | #2 |
In order to initialize the cam, you must send the SYNC sequence
0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
up to 60 times. Once the cam is initialized, you will receive the sync ack
0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00
here is part of a 4DGL code example that may help.
#DATA
byte sync 0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
byte ack 0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00
#END
func main()
var retry;
retry := 60;
while(--retry)
if (command(sync, ack, 3)) break; // send sync, expect ack, timeout = 3 msec
wend
// cam is now initialized if retry is non zero
endfunc
Notice with all the cam commands, the ACK packet returned has 0Eh as the second byte, and the second byte that was sent becomes the third byte received. This makes it fairly easy to re-organize the packet sent into a template for the expected ACK.
Here is some other useful commands and the expected ACK' s
byte take_snap 0xAA, 0x05, 0x01, 0x00, 0x00, 0x00 // uncompressed snapshot
byte take_snap_ack 0xAA, 0x0E, 0x05, 0x00, 0x00, 0x00
byte get_pic 0xAA, 0x04, 0x01, 0x00, 0x00, 0x00 // Snapshot pic
byte get_pic_ack 0xAA, 0x0E, 0x04, 0x00, 0x00, 0x00
byte sync 0xAA, 0x0D, 0x00, 0x00, 0x00, 0x00
byte ack 0xAA, 0x0E, 0x0D, 0x00, 0x00, 0x00
//Baud rate = 14.7456MHz / 2 x (2nd Divider + 1) / 2 x (1st Divider + 1)
byte set614kb 0xAA, 0x07, 0x02, 0x01, 0x00, 0x00
byte set115kb 0xAA, 0x07, 0x0F, 0x01, 0x00, 0x00
byte get_baud_ack 0xAA, 0x0E, 0x07, 0x00, 0x00, 0x00
// init for different sizes
word displayMode init80x60,init128x96,init128x128,init160x120
byte init80x60 0xAA, 0x01, 0x00, 0x06, 0x01, 0x00, 80, 60 // 16 bit raw, 80x60
byte init128x96 0xAA, 0x01, 0x00, 0x06, 0x0B, 0x00, 128, 96 // 16 bit raw, 128x96
byte init128x128 0xAA, 0x01, 0x00, 0x06, 0x09, 0x00, 128, 128 // 16 bit raw, 128x128
byte init160x120 0xAA, 0x01, 0x00, 0x06, 0x03, 0x00, 160, 120 // 16 bit raw, 160x120
byte init_ack 0xAA, 0x0E, 0x01, 0x00, 0x00, 0x00
__________________
Regards,
Dave |
| | MooMFMoo
Registered: 05/10/09
Posts: 3
|
|
|
Reply with quote | #3 |
Thanks for the quick response.
Yeah I've done pretty much the same thing. In Matlab it occasionally takes 2~3 Minz to pick it up and sync but at least once it is in sync i can communicate with it.
In my code for the FPGA, I've also pretty much done the same thing as well. But no matter how long I left it to keep trying, the uCAM never picks up on the sync command from the board. I'm certain that the command the board is sending to uCAM is correct, uCAM seems like it just ignores the repeated messages.
I've even double checked that the board's transmission to the camera had the correct voltages.
Any other suggested problems are welcome. There maybe things that I have overlooked.
Thanks heaps.
|
| | meldavia
Moderator
Registered: 18/03/07
Posts: 268
|
|
|
Reply with quote | #4 |
unless its a typo, you were saying that you were trying to sync with the sequence "AA 0E 00 00 00 00" - this may be an oversight, or it could be your problem ??
__________________
Regards,
Dave |
| | ESPsupport
Moderator
Registered: 27/01/09
Posts: 100
|
|
|
Reply with quote | #5 |
The uCam generaly responds to Sync on the first go after a power up.
If you have previously communicated with it and have 'abandoned' it in the middle of a command or command sequence, it can be very difficult to get it to respond to Sync. In this situation a 'Full' Reset will often get you control back, but not always.
|
| | MooMFMoo
Registered: 05/10/09
Posts: 3
|
|
|
Reply with quote | #6 |
I double check with the guide before I send the command.
I've tried turning off the camera then powering it up again. I'm pretty sure I've also tried the full reset but I'll try that again through Matlab. Once its full reset, I'll reconnect it to the board and attampt to sync it again.
I know there area people trying to use the camera while programming PICs, but I haven't come across a user with this problem where the camera is ignoring the board/pic.
|
| |
|
