[Joe Johnson]

Last year we used an up/down counter (actually 2 8 bit counters cascaded into a 16 bit counter) plus a 16 bit parallel in/serial out latch to get the data in and out to an auxilary CPU then I sent the data via RS232 into the user CPU. It was pretty straight forward electronics 101 type project.

With this year's CPU we totally did away with the counter, etc. If you really want to keep them, I think I would drive the latch & serial in and out directly from the user CPU without the auxilary CPU.

BUT... ...I really question whether you need this at all. There are a lot of lackings in the CPU we are using but it DOES have some pretty useful features as well.

On very useful feature is that you can dynamically set the number of edges between interrupts. With this system you can basically keep your interrupt load constant over time. When the encoders are going slow, you can simply get interrupted every rising edge, then inc or dec your counter by 1 (based on the state of your other quadrature channel). If the time between interrupts is too short, you can then set the next interrupt to happen every 2 rising edges (you have to then inc or dec your counter by 2 each interrupt). Now you check the time between interrupts and see if you need to increase or decrease your scaling for the next interrupt. It is pretty straight forward. I think you can get a scale of up to 16 edges between interrupts. With this scaling and the speed of the CPU we have, I suppose you can handle the 4 encoders you want to handle at the speeds you want.

Do whatever you like, but as I jokingly say to the CS guys around here, "Software is free!"

Joe J.

P.S. Of course I know that software is NOT free, but it is a fairly famous idea round here that management often treats it as if it is.