I?m looking for just the right counter/timer module to perform a very specific task. I have a quadrature encoder turned by an engine crankshaft. The encoder has the usual A-phase, B-phase and Index outputs. With respect to the encoder?s Index pulse, the count of A-phase pulses defines various angles of the crankshaft. I need to generate signals where each transition is individually programmed to occur at a specific crankshaft angle. Two consecutive output transitions will always be far enough apart so that firmware can intervene to set up the next transition. This seems to call for the output compare function as supported by a number of microcontrollers. But I also want an automatic reset of the counter by the Index pulse. Which counter/timer devices have both and output compare function and an external counter reset function? The output compares in the Microchip family don?t seem to have the automatic reset function. I am open to both counter/timers as part of microcontrollers or independent devices such as the 9513 chip. (But I have examined all 24 operating modes of the 9513, and none of them will do the job.) The encoder pulses at their fastest are 2 usec. apart.
Can you just do it with a high-priority interrupt triggered off the index pulse? 2usec is a lot of time-- you may be able to skip some of the context save/restore overhead if you just want to get in there and reset the counter, clear the interrupt flag and get back to whatever else is going on.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
have you considered a Freescale-controller with a TPU? Even the old '332 will do quadrature up to about 750 kHz. The modern PPC-variants with their eTPU are even more flexible.
Andreas
--
Always wear protective clothing and approved helmet when using the
software. The software may contain small particles, so keep it out of
reach of children under age of five. The author don't assume any
responsibility for mental or social problems the software may cause.
(Pacemaker's legal)
Possibly TMS470R1Ax. It has the high-end timer which might do what you want.
Back in 1992, I've done the similar task with i8088, a bunch of 8253 timers and interrupt handler. Two separate timers were used to form even/odd cylinder interval. The system was designed for 8-, 10- and
As Andreas mentioned, a TPU equipped microcontroller would be ideal for this task. If you write a custom microcode function you can even configure multiple transitions in one go.
What other requirements do you have for the application?
AIUI, the Freescale (nee Motorola) TPU was developed to handle engine control applications which have similar timing requirements to this one. Obviously there is a cost premium and an associated learning curve.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
As others have mentioned, the TPU was designed with similar but perhaps even more complex such applications in mind. The '332 was my own first exposure to the TPU and it is ... a powerful tool for this. However, the learning curve takes some work. And obviously, you will have to consider the other factors for what's available with a TPU, such as number of pins, cost, power, other features, etc. And it is enough different from what you can find anywhere else that you will be closely tied to it -- though for practical purposes, perhaps no more tied to it than you would be with any other processor, so you have to judge that issue, too.
You didn't mention (or perhaps I missed it) what the A and B rates were, under faster turns. If I had to guess at it, I'd guess that the rpm should usually be less than 6000, or 100 rps. since I haven't used much of anything that safely goes above that. But how many A/B transitions are within a single revolution? And what really is the maximum rpm? Does the counter need to properly count up and count down? Or can we safely assume that the crankshaft always turns in only one direction?
There are chips designed to provide you with an externally accessible counter value (16-bit) that responds to very fast (relative to this application, I suspect) A/B signals and supports the index pulse. The HCTL-2020 (now from Agilent) comes to mind, though I think it is more expensive than it should be. Since you said you are open to external chips, there it is.
Another possibility would be also to consider the TI MSP430 chips, at least those with the B7 timer in them, because they provide you with quite a few (7, with the B7 timer) individually programmable 16-bit compare units attached to a single 16-bit counter. That would make the output part easier, if you can otherwise solve how the counter should count.
Thank you all for your suggestions. In response to the various questions, the application is an engine test stand. No, I don't need to track position through a direction reversal, so true quadrature decoding is not really necessary. The encoder is a 4096-line device and maximum speed is 6000 RPM. The engine test procedure involves pulses for gating data acquisition timed to various crank angles and pulse to simulate ignition as well. There are up to 24 general purpose programmable outputs that may all be active at once, which means I will need more than one micro running in parallel. Having lots of compare outputs tied to the one counter is real plus. Now please, no more answers! It will take me weeks to properly digest the answers I've already gotten :-)
You might want to try to do this with a trivial CPLD, if you can't find an off the shelf part and don't want to be forced into a specific microcontroller.
Alternatively, as another poster said, 2us is a long time. You could dedicate a small/cheap microcontroller to watching the pulses and use it as a peripheral to the main controller.
.. To give your brain more strain, this sounds like an ideal app for a CPLD.
You can use a range of options, from just taking the A-B and giving 4 clocks per full cycle, and feed that into a std uC UP counter, or you can split into two counter feeds, so both count UP, and SW compares the two. or, you can put the complete counter, and compare triggers, into a CPLD. If they can be compile-time setpoints, you could use a relatively small CPLD - a .T register can set/Clear/Rst at any of the 4096 steps, using just 3 product terms. Thus a 64 Macrocell device would do this easily. eg ATF1504ASL from Atmel.
If these can be defined at compile time ( and from the OPs description it sounds like they could be ? ), then you can save a lot of resource.
You do not need to do a >= compare, but can so a simple SET @ [CTvalue] and CLR@[AnotherCTValue], plus the Index RST, which hopefully is not in the middle of these compares... :)
Thus budget is one macrocell/OP, and 12 more for the U/D counter, and a handfull for Quad engines, and you are comfortable in a 64 MC device.
If you need run-time setpoints, then you need >= compare, and also storage for each setpoint [288 bits], which is heading for 'find another way', or a small FPGA.
I did eight quadrature inputs (2x8 pins) in software using a small ARM chip. Maximum input frequency is 10 kHz now, but it could be increased (expecially when only one quadrature input is needed).
I was thinking of using a FPGA chip, but the ARM was cheaper and easier and I needed an MCU anyway.
On Atmel AT91x4xxx series ARMs, the parallel port can be made to generate interrupts on pin state changes. This should enable the creation of several quadrature decoders with relatively little software overhead.
probably the best timer unit on an affordable microcontroller is the one on the Infineon XC164xx. The perfect timer machine is the TC1775 with an option to have 96 timers interact, slightly over the top ;-)
While I do prefer the ARM architecture over propriety ones, the timers on the Infineon devices are IMHO in a class on their own
I'm surprised no one mentioned the TMS320F2812 and related TI DSPs which have a quadrature decoder capability and a very fast CPU with many bit-bang IOs that could do this sort of thing.
You sound like you are doing engine combustion research. I work in Sandia's Engine Combustion research group, and we have a lot of staff from U of Michigan. Email me if you would like. We are also here:
formatting link
If you are doing anything like what we do, then the situation is complicated by the likelyhood of the need to "skip-fire" which means to have several engine cycles that have no output pulse on one channel, then output a pulse on another cycle or group of cycles.
Also, on a 4-stroke engine, the crank revolves twice per engine cycle (let "cycle" mean a complete set of 4 strokes), so you need to involve a signal to let you know which crank revolution you are on. A camshaft hall sensor is typical. This means that you actually will have 8192 counts per engine cycle. Your encoder is a bit finer than may be necessary (you state it is 4096 pulses/rev in a later post). Consider using an ancoder that gives a more easy to use fraction of a crank degree, like 1/4 degree (1440 pulses/rev) or 1/10 degree (3600 pulses/rev). It's almost never necessary to have better than 1/4 degree resolution for engine research.
So with the skip-firing, your waveform generation process needs to also count engine cycles, and index an array of compare values that vary with the engine cycle counter. The possibility of "no output" must also be available. An alternative would be to simply calculate the waveforms and fill a RAM with them, indexed by the degree counts but without rolling over for the number of skip-fire cycles. For example, a
10-cycle program with 2880 counts per cycle would need 28800 RAM locations, with as many bits/word as you need channels of output. The most sophisticated implementation would allow you to tweak the waveforms while it is running. This points toward the FPGA or powerful DSP again.
We have an MS-DOS (!) based system with some counter/timer and DIO boards from commercial data acquisition vendors like Data Translations doing this at present. I am looking to implement a new system based on an FPGA/uC combination. There are also often time-domain delays and pulse width generation capabilities needed which are triggered by the crank-angle domain events, to create fuel inject pulses, etc.
Thus, our setup has the "Shaft" controller triggering a bunch of SRS and BNC delay generators. By using an FPGA, I can consolidate some of these delays into the FPGA as well. Though some delays are for laser and camera gating, so need finer resolution than the FPGA can do.
Good luck with your work!
--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
How accessible is that uC family to a one-off designer?
-- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA snipped-for-privacy@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Hi Chris, I am a 1 off designer and it's quite accessable to me, although it was in short supply a few years ago due to the fab plant being hit by an earthquake. I used the flash version of that chip because like the op I also needed up/down resetable counter for a machine positioning system and wanted a 1 chip solution.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.