Different speed for different ports

[RBuilder]

[RF_Developer]

What exactly are you expecting from this? Are you expecting too much? I ask this as you observed this when trying to write a software solution to serial interfacing, which is essentially a hardware problem, and for which most PICs have dedicated and quite versatile hardware.

No output from a processor running code will ever be as precise as a hardware designed solution. All sort of things can interfere with the timing. So even us accurate timing is unlikely to be acheived with a software based solution, and few serious engineers will entertain any notion that is may ever be so.

If there is a timing difference from IO bit to IO bit then I don't even expect that to be the same from example to example of the same PIC let alone different PICs, even in the same family. There's going to be some variation: with voltage, load current, temperature, load capacitance, even track geometry.

All in all, on PICs if a IO bit changes in the us you expect then you're doing OK. Not well I grant you, but OK. When it changes in relation to the internal four phase clock (or two phase for 24s and up) is not specified, and thus I can never rely on it being a) what I want, or b) being the same under a sufficiently wide range of conditions. If that's important I'll use discrete logic or more likely an FPGA.

RF Developer

[Ttelmah]

Seriously, have just tested this, and the times are _identical_. Less than 5nSec difference on my DSS.

As said before, I would expect it when using a variable to access the bit, but not when hard coded bit numbers are used. For me, on four separate chips, there is no difference.

Tried with a hardware clock source, feeding a timer, and operating the pin inside the timer ISR, then measured the time between the clock edge, and the pin changing. All varied between 3.3uSec, and 3.4uSec after the clock edge, as the incoming asynchronous clock beat with the instruction clock of the CPU (remember interrupts are serviced on the next T1 state after the event), but the timings were the same whatever port pin was used.

I think you are seeing an artefact caused by something else in your code.

Best Wishes

[Mike Walne]

[asmboy]

[asmboy]

I should add - in order to get good crisp transition times - I was reading the port via a series divider from the pins under test, to ground, such that we are operating at appx 2 ma with a 2.4k resistor in series with a 100 ohm resistor to ground. And of course reading the port transitions across the 100 ohm part of the divider. Hopefully this should need no further explanation, right ?

[Ttelmah]

Glad to have it confirmed.

I was expanding the test, using an external clock to feed a timer input, and triggering the pin change inside the timer interrupt, which then adds up to one instruction cycle of jitter as the external clock beats with the internal clock timing (interrupt is serviced at the next instruction's 'first cycle' after it happens). Hence the 0.1uSec of jitter on the results (at 40MHz). However the minimum time, and maximum times, were identical whatever pin I used. Had to sample quite slowly to store a complete cycle of the timer, hence sampled at 200MHz, so 5nSec 'best case' resolution.

Best Wishes