Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC16F84A Baud Rates with CMUcam2

Status
Not open for further replies.

scottk26

New Member
I was wondering I am building a project using a PIC16F84A and a CMUcam2 to do object detection and tracking. I wrote the code in PICBAsic and define the oscillator at 16MHz. I have everything connected and when I power the camera on and the driving circuit it seems that the code cycles through but the camera does nothing. The camera is connected using the TTL port to the PIC. I was basically wondering if I should reduce the Baud Rate of the camera due to the fact that the PIC cannot handle the speed. I have the camera currently selected at 115,200 but I do have the option to change it. I am wnating to know what I should do. I think that the camera is not syncing well with the PIC. Please if anyone has any suggestion I woul greatly entertain them..
I am using the PICBasic Pro Compiler.

Thanks
Scott
 
scottk26 said:
I was wondering I am building a project using a PIC16F84A and a CMUcam2 to do object detection and tracking. I wrote the code in PICBAsic and define the oscillator at 16MHz. I have everything connected and when I power the camera on and the driving circuit it seems that the code cycles through but the camera does nothing. The camera is connected using the TTL port to the PIC. I was basically wondering if I should reduce the Baud Rate of the camera due to the fact that the PIC cannot handle the speed. I have the camera currently selected at 115,200 but I do have the option to change it. I am wnating to know what I should do. I think that the camera is not syncing well with the PIC. Please if anyone has any suggestion I woul greatly entertain them..
I am using the PICBasic Pro Compiler.

Thanks
Scott
Can you post us your code and scheme? So that we can help you...
 
scottk26 said:
I was wondering I am building a project using a PIC16F84A and a CMUcam2 to do object detection and tracking. I wrote the code in PICBAsic and define the oscillator at 16MHz. I have everything connected and when I power the camera on and the driving circuit it seems that the code cycles through but the camera does nothing. The camera is connected using the TTL port to the PIC. I was basically wondering if I should reduce the Baud Rate of the camera due to the fact that the PIC cannot handle the speed. I have the camera currently selected at 115,200 but I do have the option to change it. I am wnating to know what I should do. I think that the camera is not syncing well with the PIC. Please if anyone has any suggestion I woul greatly entertain them..
I am using the PICBasic Pro Compiler.

Does your compiler support 115,200 baud?, also does it support it with a 16MHz clock? - the BASIC STAMP (which most PIC BASIC's tend to copy to some extent) only supported 2400 baud.

Also, assuming it's able to receive data that fast, where are you going to store it in the PIC?.
 
I checked the CMUCAM2 documentation and I found that you can control the baud rate through jumpers in your CMUCAM.

https://www.electro-tech-online.com/custompdfs/2005/06/CMUcam2_manual.pdf <the manual> Page 17 <jumper port> Page 22 <configuration jumper>

I believe 5000 Baud Rate is the maximum for your Pic through its serial port connection. "You need to use the serial port instead of the TTL port" Make sure you set the jumpers correctly.

Also, make sure the oscillator jumper is on.
TK
 
I want to add one more thing, the microprocessor in the CMUCam works on an oscillator higher than 50. That will not cause any trouble in its commuincation with the Pic , assuming it works on 20Mhz.
 
nalrawahi said:
I want to add one more thing, the microprocessor in the CMUCam works on an oscillator higher than 50. That will not cause any trouble in its commuincation with the Pic , assuming it works on 20Mhz.

Sorry?, I don't see any relevence at all between the clock in the PIC and any oscillator in the CMUCam.
 
Sorry I should have explained more. Well, I was actaully saying that because I heard some people get confused when two microcontrollers get communicated with each other. Some people say, you have to make both microcontrollers to have the same oscillator if you want both of them to get communicated through TTL (I2C). But that's not true all the time..you can actually have two microcontroller with two different oscillators but you need only to change that to serial connection and control the baud rate.
 
nalrawahi said:
Some people say, you have to make both microcontrollers to have the same oscillator if you want both of them to get communicated through TTL (I2C). But that's not true all the time.

It's not true ANY of the time - unless you deliberately wrote it to be that way! - which would be rather stupid, and I've not seen anything done that way?.

Basically you can use either syncronous or asyncronous connections, with asyncronous (like RS232) the clock speed is inherent in the data stream, it's sent as a fixed known rate, with start and stop bits, which allows easy syncronisation. So the speed is dependent on the serial transfer speed, and both ends simply employ that - irrespective of clock rates.

With syncronous transfer you have seperate clock and data lines, with one of the devices generating the clock that controls the transfer of data. In this case there's no need for a fixed speed, and speed can vary from byte to byte, even bit to bit, I2C is an example of this type of transfer.

There are obviously other ways, but those are really the main two, both independent of processor speed.

A similar way (rather like a bit of both systems?) is Manchester coding, this is an asyncronous system (just a data line), but the data is coded in such a way that you can easily recover the clock from the data stream, and use it to receive the data - quite clever really?.
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top