Reading a quadrature encoder reliably

Is it possible to reliably (ie. no lost counts) read a quadrature encoder generating 20000+ counts per revolution with the Imp? On a PIC or Atmel or any other micro I’d use an ISR, but Imps don’t support interrupts or an equivalent, correct?

From the Documentation page for hardware.pin.configure(DIGITAL_IN, function) :

“The callback isn’t a true interrupt: it doesn’t interrupt or pre-empt any Squirrel that’s already running. It’s more like an event handler. If some other Squirrel is running when the input changes state, the callback will be queued and will run when the imp is next idle.”

… which I read as potentially losing a lot of counts. The encoder will be coming from a BLDC servo and it’s to calculate the absolute linear position of a carriage on a track (after initial homing and zeroing), so lost counts would lead to positioning error pretty quick.

Since this is a one-off, I can afford to throw external ICs at the problem, offload the counting to a dedicated encoder counter IC and talk to it over SPI or I2C, or use a cheap 8-pin PIC for the job… But if the Imp can handle the it, I’d like to know. The motion control is simple enough, and I can talk to the servo amplifier board over the Imp’s serial connection, so the only reason I’d need another chip is for the encoder (ie. I don’t need to handle PID in this particular case)

Cheers,
Ken

I think it will work if the callback function is short enough. It all depends on the RPM. Disconnect Wifi? Try it!

As sbright says, it depends on the RPM. 20k counts per second might be hard. You could always, if power is no object, use the new multichannel ADC API (in release 27) but that’s a bit perverse really :slight_smile:

There is fairly direct hardware support for quadrature-encoder reading, but it’s not currently exposed to Squirrel. I’ll put a story in the backlog.

Peter

Thanks for the info, time to hit the bench :slight_smile:

Peter or Hugo, do you have any numbers on best/worst case timing for callback queueing, or is it just too variable? How deep is the callback queue?

K.

Well, the only thing that can block Squirrel running is other Squirrel. So the worst-case callback latency is going to depend on the longest-running event handler in the system.

The callback “queue”, if you can call it that, is just one entry deep per pin. It’s more like a binary semaphore than a queue.

Peter

Gotcha.

So same principles apply as with micros; keep the handlers short, set a flag or set a variable and get out, do everything else from a state machine in the main loop.

Cheers,
K.

Is that 20K pulses a requirement, or is it just the encoder you happened to have laying around?

I wonder if you can use a flip-flop or something to divide the counts by two. A hardware divide circuit that is fast enough to see every pulse. The imp would only see every other pulse (10K pulses per second).

Absence of Interrupts definitely are big negative point to the imp.
From automatics or measurements point of view.
Of course it is possible to make something around this, but non of the software tricks is the same as interrupt - as we no them in other micro-controllers.

I think it is important to remember what the Electric Imp platform is intended to do. It isn’t trying to be a new, wireless Arduino. The Electric Imp is a really easy way to add wireless connectivity to any device, in a really small and inexpensive package. It does also happen to be a really nice microcontroller when used with various breakouts, but I think it is important to compare apples to apples. The Arduino Yun is $90. If you buy an Imp for $25, and add $65 worth of components and breakout board, I daresay you could put the Yun to shame, and that, in my mind would be a more accurate comparison, No? Understand, I am not knocking Arduino. It is a fantastic platform, especially for learning, even though it comes with a decent price tag. I think that many times, devices like the Arduino, Electric Imp, and the Raspberry Pi tend to get lumped together, even though they are very, very different things. Anyway… just my two cents.

Agree with the above comment. I started working with the Imp when I was looking for a cheap wifi module for my Arduino. The Imp came in at under the cost of any wifi modules I could find, plus actually could do all the processing I needed, thus removing the need for the arduino itself.

20k pulses per rev is insane, far above anything I’ve seen in the hobbyist arena. I don’t know how much one of these would cost, but I bet it’s a lot, and you probably shouldn’t be bummed that a $20 module such as the Imp, with everything else it can do, can’t process these kinds of inputs.

Heh, my mistake… That should have read “20000+ counts per second” It’s actually 2k counts per rev (500 CPS quadrature, tips and tails) in an applications that caps out at 10 rotations per second. Not sure why I didn’t catch that error earlier.

@opb Not sure where you got the impression I was “bummed out” , thought I made it clear I had several alternatives I was willing to try should the Imp not handle it. I’m not even “bummed out” that I don’t have ISRs (but it would be sweet!)

K.

@mlseim I used a divider/prescaler, dirt cheap and worked great for what I needed.

Yeah, sorry @kcampbell I don’t think I was following the thread very well. Do you have a link to the encoder in question?

No problem, my fault for not noticing the 20K CPS error sooner.

No datasheet or link, @mlseim pegged me, they are indeed some encoders I had lying around (but nice ones, made by Dynamics Research, miniature ball bearings on the shaft, etched glass encoder wheel, sturdy aluminum enclosure, they look like they were expensive back in the day :wink: