Tag Archives: headache

It’s been a rough night

*pix not mine, scrounged from interwebs
*I do not take responsibility for this pix

The short story: I leapt before I looked. I tried to build the “motor library” all gungho like, only to my disappointment I had some serious design flaws. Last night I managed to successfully build and implement a simple motor library. It could not have been simpler. And yet I somehow turned working code into an epic 3 hour battle with anomalous compiler errors… Curses!

* * *

So at 1AM this morning, I resigned to revert back to simplistic, functional, sparse motor library code. It works, and that’s how I like it. It will be assimilated into a larger system that will receive and interpret the encoder interrupt signals, to somehow produce a PID look-a-like which will detect and handle “error conditions”, basically an advanced speed controller. But here’s the catch: I’m going to try to make it from scratch.

* * *

Good news: the whole Interrupt vs Serial Communication thing has been settled. I’ve been overthinking the problem, thinking the arduino microcontroller did some kind of threading/parallel processing, and that my interrupt code would blindly disrupt serial communication, or vice versa. I’ve done some digging. It appears, if I had just read the manual, my life would be easier.

[ see: gammon.com.au/interrupts ]

So, there is a priority with regards to Interrupts. And higher priority interrupts will be executed first… And, Serial communication does rely on interrupts as well. But if should any Serial communication get delayed by some other Interrupt code, the message gets buffered internally (at the hardware level I think) and Serial.available() is all I need to check if there’s anything in the buffer. It’s like checking voice-mail. So, for all conditions where the motor encoder interrupt is firing, and serial communication is happening, there’s no possibility for communication failure or missed counts. Or so I believe…. So at some point I have to provide test code to determine if it’s actually possible to miss a count on the encoder interrupt, or if it’s possible to disrupt in some way serial communication with really taxing interrupt code.

-david