View previous topic :: View next topic |
Author |
Message |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
24bit Parallel Absolute Encoder Test Box |
Posted: Thu Feb 16, 2012 2:58 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Thu Feb 16, 2012 7:35 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
|
Posted: Thu Feb 16, 2012 9:14 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Thu Feb 16, 2012 9:57 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
|
Posted: Fri Feb 17, 2012 7:05 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Feb 17, 2012 7:38 am |
|
|
two approaches:
1 - using one of the pic's internal timers for a cyclical snapshot
or
2-use the async clock line that encoders have -tied so that that changes of state are detected for each new absolute data update.
for low enough rotation rates - this can trigger a port B bipolar "interrupt on change" w/o saturating your pic
to make USE of the data - i would suggest a damned fast serial output - say 460800 baud or so
either way would trigger the latch and read routine
i described.
![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
|
Posted: Fri Feb 17, 2012 8:44 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Fri Feb 17, 2012 9:01 am |
|
|
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.. |
|
![](templates/subSilver/images/spacer.gif) |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
|
Posted: Fri Feb 17, 2012 9:35 am |
|
|
Quote: | 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.
|
Hi Temtronic.
Sorry I dont understand your answer - are you syaing that using three pics would be faster then using one?
Thanks
Carl |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Fri Feb 17, 2012 9:54 am |
|
|
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'.... |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Feb 17, 2012 10:15 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
carl
Joined: 06 Feb 2008 Posts: 240 Location: Chester
|
|
Posted: Fri Feb 17, 2012 10:24 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Feb 17, 2012 10:58 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Fri Feb 17, 2012 4:07 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
dorinm
Joined: 07 Jan 2006 Posts: 38
|
|
Posted: Fri Feb 17, 2012 7:08 pm |
|
|
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 ... |
|
![](templates/subSilver/images/spacer.gif) |
|