Learning to Play Nice with Interrupts
No visual update for this post, but rather some tidbits of advice. When programming in C for the MSP430, I’ve been very tempted to treat Interrupts as more like Events from Object Oriented Languages. Knowing that there is only 1 ‘thread’ of processing and the Interrupt function is executed at any point during the main code execution, I never fully appreciated this until I started this CMRI project.
I quickly found out that interrupt processing seriously messes up real time operations like PWM. For instance, I was attempting to simulate the slow pulsing of the red lights on a Cell Phone tower on the same MSP430 that I was running the CMRI serial IO code on. Every time a POLL was received from the computer, the PWM used for the red light would ‘hiccup’. The time it took the Serial code to write the 8 bytes (64 bits) to the serial wire was just too much to keep the PWM animation smooth.
The solution came to me in the middle of the night (go figure) and I believe has applications in many other aspects of coding on the MSP430. Instead of using your interrupt handler to do the ‘work’, in my case a Serial SEND, use it to set a flag and perform that work in the main loop of your application. For my example, the Serial code processes one Byte at a type on the RECV, and when the POLL command is recieved in full, a ‘TRANSMIT_REQUESTED’ flag is set to true. Each pass in the main loop checks this flag and, when its set to true, begins to send the GET packet, one byte at a time. This way, the main loop can update the PWM once every byte that is SENT or RECVd, rather than having to wait till all 8 bytes are SENT. This results in a very smooth pulsating light, all the while serial IO is happening in the ‘background’.
More on this in coming days. Cheers!