24bit Parallel Absolute Encoder Test Box

[carl]

Hi All,

OK I need your advice on a new project. It is for a 24bit Parallel Absolute Encoder Test Box.

The main idea is too take a 'snapshot' of the 24 input lines from parallel encoders, assess if the count is good (Compare the previous value against the current value, and if it is +/- 1 count then its good, if not then raise an alarm) and then output the count.

The main important question that is paramount is 'the amount of time available to perform the task'. The encoder will be running at max 20Khz - so each rising edge would take 1/20Khz = 50uS. Assuming I use a 40Mhz pic (10Mhz clock - so each instruction takes 0.1uS) do you think I would have enough time to do the following:

1) Wait for a pin/port change (from the LSB up - as these will always be changing).
2) Then take a 'snap-shot' of all 24input pins.
3) Then assess the current count against previous count.
4) If good then make make the previous count = current count. If bad raise alarm.
5) Write the value to the output. (spi would be good).
6) Wait for next pin/port change.

And all of the above in 50uS?????
Do you think this approach is feasable????

Any feedback would be much appreciated.
Carl

[SherpaDoug]

At 500 instructions per reading it should be possible if you are careful and avoid interrupts. I would poll the LS byte for a change, when it does read the full 3 bytes and subtract. You may need to put in a delay to avoid race conditions among the 24 bits.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[carl]

Thanks Sherpa.

So polling (using something like kbd_init) would be quicker than using a pin or port interrupt??

This project will take a lot of effort, so I want to be sure of all the possible options first.

Does anyone else have an opinion on the liklihood of this plan working. Taking into consideration the time it takes to write to the ouput (likely to be through the uart between 2 pics, or maybe spi (although i think this would take a lot longer than 50us) - what is the quickest way to communicate??

Thanks
Carl

[asmboy]

if i had to do such a wacky thing with a pic - i would probably do it with a set of THREE 74HC574 or AC574 chips - with the outputs paralleled to port D
of a 40 mhz clocked 18F part - with common latch but individual enables to allow them to be read one at a time

in operation - i would latch the three chips
and then ENABLE the outputs INDIVIDUALLY to read into said D port

to register a CHANGE - you could with a minimum of clocks -

* latch all 3
* read only LSB

and get a fair idea of state changes
before reading the other 2 latch outputs to get the full value captured

this implies polling

a bit more external circuitry could allow auto capture based on a PIC timer
as well

[carl]

Thanks ASM,

sounds interesting!! so this would speed up the process time by only reading portD, rather than reading three ports at the same time??

and could you eleborate on your point of 'auto capture' - what would the purpose of this be??

It is very similar to another plan I had of using three pics - one for each byte, and communicating betweeen them - would this be even quicker??

Anyone else have any other suggestions??

Thanks to all
Carl

[asmboy]

[carl]

Thanks ASM,

I will definitely consider your ideas.
But what about the difference in speed between your idea and mime??

Also if more than one pic is used in any application - is it standard practice for each pic to have its own 40Mhz clock - or do you share one clock between more than one pic??

Carl

[temtronic]

You could just use 1 PIC with 3, 8 bit ports having Port B as the lowest one, like ASM says.. That would be the simplest, fastest way to interface the encoder to ????? the project is.

As far as multiPICs, one crystal. yes you can use 1 crystal.If you're needing a USB port,the newer FTDI USB<->ttl modules have an onboard clock you can use,might be an option depending on the project requirements. Saves 3 components...some board space...few pennies..

[carl]

[temtronic]

Sorry, other way around.

One PIC ,use ports D,C,B as digital inputs from encoder bits, using Port B as the lowest byte of the encoder,use the Interrupt on change ISR of PortB.

This all depends on what PIC you choose of course, but most new ones should be able to do the task.
Once the PortB ISR is triggered, withing the ISR capture the PORTD , PortC and PortB data(simple reads) then exit back to Main to carry on with whatevere you need to do....

Hope that clears up the confusion...been fighting PCs all week...lost 108,000 files 'somewhere'....

[asmboy]

caution:
using multiple pic ports will NOT reliably capture a fast changing 24 bit word in the way that multiple latches externally will -
and will increase your effective sample window time in a detrimental way.

to catch all 24 bits CLEAN - with ext latches
the isr needs only TOGGLE the ext clock line
with 2 instructions MAXIMUM for a SYNCHRONOUS capture of the 24 bits
( note that is said HC574 not 573 ;-))
multiple port reads can never be synchronous

also by using port C -you just lost your primary rs232 hardware

price the 74AC574 - let hardware be your friend.

[carl]

Both very good answers.
I would need the rs232 port - so good point ASM.

If there are no speed drawbacks to using the latch's (only one port used) in comparison with using all three ports (no latch's), then I think the latch idea sounds the best so far.

If expense and parts were taken out of the equation though as concerns, both of you seem to be steering me away from using three pic's for the same job?? as soon as I have a 'good' reason as to why this is not the best idea 'in your opinion' then I do not want to discard it yet. Surely three pics would be faster to use??

Carl

[asmboy]

3 pics require time coordination.

there is STILL the issue of synchronous capture made worse by more pics
not better.

the 574 FREEZES the 24 count on the rising edge of the clock - for you to READ at your leisure

i am not aware of a safer, faster or or more efficient way to get that data - and all using a single pic.

ideally you would add a 2 bit to 4 bit data decoder -
to select which latch to read so that the DEFAULT is to enable the LSB into port d - so that after a toggle of the latch - you juts read port_D to get the LSB - thats just 2 bits - say from port a


about 4 clocks of the pic to do that
8 -10 more clocks and you have all 24 bits

also if using a timer to poll -
there is no or read on PORT B with a 28 pin part either

[SherpaDoug]

I am not sure you will have time to use interrupts. I would not count on using the port B interrupt-on-change.

I would poll the least significant byte. When I see a change I would wait some debounce interval, and then read all 3 bytes. Hardware latches would be fastest. Then I would subtract and stuff the serial buffer. Latter bytes could be stuffed into the buffer during the LSByte polling.

If you get a higher order byte change without a LSByte change when you are expecting only single count changes, then you have a MAJOR encoder failure. I suppose you could poll for that occasionally.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[dorinm]

there's a simple solution (after many trial/err.s, it works 100%) ...POOL!
that's all, you can pool the pic ports for any change and compare with the previous port(s) state ; given that you have 50us between ANY individual bit changes then (simple mathematics) you have more than enough time (<50us) to know (and compute) if any bit on any port changed and do whatever you want... ...i do that for some parallel sensors on a 8 bit port *changes states on every 5-10us* and I have no problem ...yet...

if by any means your computation would take more than 50us yet you don't have to have a feedback in realtime:
you may "save" your changes from a fixed timer int. routine (say every ~<40us) into a "history buffer", then your app would only process the data from the buffer, given the probability that your buffer won't owerflow too soon ...