Instant Interrupts - Revisited

[LinkMTech]

Thanks for ending the misery Darrel.
I guess I was seeing too much into it. I still need to learn to juggle the events properly so they don't clash.
When I read the second post that says "Well, for one, this Blinky Light program will continue Blinking at the same rate, no matter what else you add to the Main: program loop. Try doing that with pauses.", it's true, but I made the mistake of assumming that the main program would go along like some absent minded fool without a bother in the world.


Thanks for all your contributions,

[Darrel Taylor]

Thanks for ending the misery Darrel.
I guess I was seeing too much into it.

Well don't end it there ...
It's probably that you're "not seeing enough into it".

Interrupts can definitely be used to make multiple things happen at the same time.
It's just that those things need to be happening in hardware.

If you want to send RS232 from an interrupt, then you should use the USART.
If you want to have an interrupt driven PAUSE, then use a Timer.

Jumping to the ISR and executing a software routine like serout(2) is not normally very productive, because the same routine could have been run from the main program without interrupts without much additional overhead. And since either way ... the program can't continue until the serout has completed, with or without interrupts makes little difference.

But if that interrupt uses the hardware USART, only a few instructions need to be executed to start the USART sending data, then it immediately returns from the interrupt and continues running the main program at the same time that the USART is sending the data.

There are several hardware peripherals on the various PIC's, and you might have 5 or 6 things all happening at the same time.

While software timed, bit-bang routines in your interrupts will occasionally be very useful ... avoid them at all cost.

Hardware and Interrupts make good companions.

hth,

[LinkMTech]

Well don't end it there ...

Alrighty then! Just when I was about to go with plan "B", add a PIC12F683 as a stand alone serial generator.
I just took a look at USART along with Mister E's PIC calculator and found that 7812 baud is configurable. A first glance some time ago gave me the impression that only common baud rates were available. I just recently discovered SEROUT2!
Is the USART hardware like the HPWM that can run continueously in the background?
If so, which commands will disrupt it or vice versa? I ran into some surprises when trying to use the HPWM while using the A/D in a WHILE:WEND. So went with PWM sprinkled through out the program along with a nice filter to hold my Vout.

The RS232 does not have to be interrupt started, just running all the time with the same 8x8 bytes of data. It will be processed and returned without any delay so I will have to act on it immediately.
Do you think this is still possible? Or go with plan "B"?

[Darrel Taylor]

7812 baud ... ECU / ALDL ??

Yes, the USART will continue sending data at the same time the main program is running. But you have to feed it bytes every now and then.

The TX_INT (USART Transmit Interrupt) makes it fairly easy.
When the transmit buffer is empty it generates a TX_INT, which jumps to a handler that sends the next byte.

That handler just needs to send one byte at a time, by keeping track of where it is in an array and incrementing/wrapping as needed. It only takes a few instructions for each byte, so the main program is hardly affected by it.

You can then very easily have it sending continuous RS232 data via the USART, while the main program continues what it's doing at the same time.

Typically, when you have data to send, you ENABLE TX_INT's, and when it's finished sending the available data, DISABLE TX_INT. And that handler won't be called again until there's more data.

I ran into some surprises when trying to use the HPWM while using the A/D in a WHILE:WEND. So went with PWM sprinkled through out the program along with a nice filter to hold my Vout.

The HPWM command doesn't like being updated continuously.
It resets the PWM cycles every time it executes.

If you limit the HPWM updates to only when the Duty value changes, it gives a better response.
You can also synchronise the updates with Timer2 to make it "glitch-free".

hth,

[LinkMTech]

Thanks for the direction Darrel. I did some research on the USART and like what I found now that I'm beginning to understand the use of your interrupt routine and how the information is presented in the data sheets. I think it makes more sense as the need increases.

7812 baud ... ECU / ALDL ??

The 7812 baud is on a motorcycle ECM alias ECU.

The HPWM command doesn't like being updated continuously.
It resets the PWM cycles every time it executes.

If you limit the HPWM updates to only when the Duty value changes, it gives a better response.
You can also synchronise the updates with Timer2 to make it "glitch-free".

Sorry, I wasn't clear on my attempt with the HPWM. I set it early in the program to run on its own and would get updated only when needed (when a rider shifts gear). But while using a 55ms timer controlled ADCIN inside a WHILE:WEND, I found it jumping out of the loop way before the timer overflowed because the HPWM triggered it somehow. So I'm sure I didn't account for other hardware commonalities.