pins timing?

When I change several I-O pins in one command with a "let pins = %00011..." sort of command (on a picaxe 8 or 14 for example), it doesn't actually change them exactly at the same time, does it? (does it result in individual pic instructions to change a pin at a time for some chips??) So what is the maximum time one pin might have its old value while another have its new value? Is there an order it changes pins?

For example, if an external circuit expects one pin high and another low, but gets both high or both low for a while - how much of a problem might I have?


Senior Member
Though I haven't physically verified this with a scope (yet), I'm 99.99999% sure all pins change at exactly the same time, since the "let pins" command DOES NOT set each pin on its own; rather it writes the full state byte at once.

First off, absolutely nothing can do anything at exactly the same time. There will always be a delay of some nature even if it is only the difference in time it takes for one transistor to turn on compared to anaother 'identical' transistor.

Like womai, not confirmed but 99.999% confident that all pins switch simultaneously with a pins statement. Assuming that to be true, I would expect to see a difference in logic states of around 1 to 2 nano seconds for the technology used. Many devices only have a response time of 10nS so this should not be a problem.

Even if the outputs are switched sequencially such as code that does high 1, high 2 etc, it does not need to be problem. Feed the outputs into a latch and only propagate the inputs to the outputs after all inputs have had enough time to settle.

This sort of effect is only usually a problem when binary counters are being read by a micro input. Many counters are known as 'ripple' counters. That is because when the output needs to 'carry' to the next bit, it 'ripples' over. This is very quick, often only a few 10s of nano seconds but the micro reading it can read in all bits in only a few nano seconds so it is possible to be able to read the counter when it is in the middle of changing its outputs and get the wrong value. There are several solutions to such problems. Use a synchronous counter. Only read the outputs when the clock to the counter is in the not changing count phase, or use a counter which uses a special code to represent the binary value. The most common code used is call "gray code". The bits are coded such that only one bit will ever change at any one time thus avoiding the problem. Many position encoders use such a code for that very reason.
What about pwmout.
I have a project where I want to use pwmout on a picaxe18x using pin3 which is the pwm pin. I also want to set the other output pins to different states without disturbing the pwm pulse output.

pwmout 3,99,200 .... should generate a pulse output of frequency 10 khz and 50% duty cycle. This command runs in background.
and say I have a counter to count the pulses over a length of time. If some time during the counting the Picaxe sends the command pins = %11111111 or pins =%11001010 ie to set all the output pins to a particular state together, what will happen to pin3 the pwm. Will it miss pulses for the execution time of the pins command or will pwm stop and pwm need to be issued again or will the just be a glitch ????
Can I use the pins command and avoid talking to some pins. pins seem to need a byte value ie bits0 - bit7.
If I use highs and lows the pins will be set one after the other ?????.............



Technical Support
Staff member
Setting "pins=" will set all output pins at the same time, give or take a few nS, perhaps even pS as the I/O circuitry should be closely matched. In almost all circumstances this can be considered to be simultaneous.

The exception is the 14M where "pins=" controls pins which are on separate ports of the underlying PICmicro. There almost certainly is a few uS delay between those which change on GPIO/PORTA and those which change on PORTC.

You can only change some pins using "pins=" if the ones which do not require changing are inputs not outputs, or you have loaded the current output pin states, altered the ones to change and re-written the required value.

Pin changes should work without any adverse effect on background PWM, because PWM is driven entirely by hardware and there's no reason for "pins=" to go anywhere near any related hardware.

Setting or clearing the pin which is also used for PWMOUT should have no effect. The reason for that can be seen in the PICmicro datasheet; what drives the I/O line is routed via a multiplexor which selects the drive according to control register bits, when used for PWM, the pin's level bit is not routed through. I expect this is the same across the whole PICmicro family, but you'd have to check the individual datasheet.


Technical Support
Staff member
<i>For example, if an external circuit expects one pin high and another low, but gets both high or both low for a while - how much of a problem might I have? </i>

It can be a major problem. A typical mistake is trying to control a parallel LCD by setting the 'character required' bits and the 'clock data out' bit in one output write. The LCD may see the clock activated before the character bits have changed and use the wrong data.

The solution is to do any outputting in a way that ensures the bits which need to be stable when another pin changes are set before the clocking bits are changed -<code><pre><font size=2 face='Courier'> pins = %11010011 ' Clock = 1, Data = %1010011
pins = %01010011 ' Clock = 0, Data = same as before
pins = %11010011 ' Clock = 1, Data = same as before </font></pre></code> If you have control over the receiver, such as if it's a PICAXE, it's unlikely to be a problem because you will have checked the clock bit, seen it active, and by the time you come to read the data it will have become stable ( unless the sender has altered it again too quickly ). If trying to read all pins this can be a problem -<code><pre><font size=2 face='Courier'> ' Bad
b0 = pins
If bit7 = 0 Then
Gosub UseDataInBit0ToBit6
End If

' Good
If pin7 = 0 Then
b0 = pins
Gosub UseDataInBit0ToBit6
End If </font></pre></code> To save the sender having to wait some arbitrary time to ensure the receiver has seen the clock, and read the data, rather than strobe the clock line, it can simply be toggled on every output and the receiver can tell new data has arrived whenever the pin changes from what it previously was. The sender still must not send to quickly but normally 'other processing' will have ensured the receiver has had plenty of time to see and read the data sent to it.

Edited by - hippy on 31/08/2007 12:34:51