When reading a port for a 8 bit serial input, in general, how am I suppose to tell how much time I need to allow for switching other than experimentation? Is it a function of time or is it a function of how many clock cycles I need to let pass before I read the port? Is the limiting factor the device I need to read the data from?

Do I just need to use a oscilliscope to see how many us it takes for a switch?

 

The switching time is not relevant. For asynchronous serial, you wait for a start bit and then wait 1½ times the bit length, thus ensuring you are reading in the middle of the bit. For synchronous, you read the bits on the falling edge of the clock signal, the transmitter changes the bit on the rising edge thus ensuring the data is stable when the falling edge happens.

If the above doesn't work then you are trying to communicate too fast. The things that affect the max transmission rate are line capacitance, output impedance, input impedance and a few other things I've no doubt forgotten.

Have a look at the USART section in one of the Pic datasheets.

Mike.

 

As suggested, it depends if it's syncronous or asyncronous, my PIC tutorials give details for asyncronous (the most common type) 9600 baud.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

I'm not sure if what im doing is asyncronous or syncronous (sorry, im a newbie), but here is basically what im talking about:

If im manually clocking a device using the pic and on the device transmits data on the falling edge of the clock, when I clock it low, if I tried to shift in the data from the port on the next instruction it doesnt read properly. However, if I put in some NOP instructions before I shift in the bit, it does read it properly. The amount of NOPs I need changes from pic to pic, so I'm wondering what determines how fast I can read the signal, the pic I'm guessing.

The problem is, I dont even know what this "charateristic" im experiencing is called, so I dont even know what to google for. BTW, I looked up USART in my pic datasheet and came up with nothing (pic16f57).

 

What are you trying to connect to?.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

Playstation 2 controller.

 

As far as I'm aware the Playstation 2 controller uses a strange format?, there are a number of threads about it on these forums - try searching for PS2 - which a lot of people incorrectly call it (as PS2 is an old IBM PC, which modern mice and keyboards still use the connector from).

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

Well, I dont really need info on how to do it, I already have all the data I need, I just need to know (in general, not just with this project) about delays in reading bits on devices and what the general rules on this are (other than trial and error).

 

Actually, nigel, the old IBM PC (and mouse/keyboard ports) are called PS/2
http://en.wikipedia.org/wiki/PS/2

so I don't think there's technically any name conflict with the playstation 2. Of course, using PS2 instead of PS/2 for the old PC or ports would probably be interpreted exactly the same as long as it's used in context.

as far as the original post is concerned... Well, we can't make blanket statements that apply to any serial system... if it's synchronous (ie- uses a clock line) then often the data is simply assumed valid on the clock edge opposite the one it changes on. If it's asynchronous, then typically you put in timing such that the microcontroller is sampling the bit close to its middle, where it is less likely to be in transition for whatever reason. If you want more specific information, perhaps you should post some information about the particular protocol; usually when working with a new serial protocol it's best to get a diagram of an example data packet, showing the action on the clock and data (and any other appropriate) lines.

__________________
EEgeek.net