TheBackShed.com

Forum Index : Microcontroller and PC projects : hardware timer that can fire an interrupt ?

Page 2 of 2

Author

Message

vincenthimpe
Regular Member

Joined: 14/10/2018
Location: United States
Posts: 82

Posted: 12:55pm 15 Sep 2025

Copy link to clipboard

Print this post

ah,ok. will try. i downloaded the version off Geoffs webpage. I'll go hunting for 6.01
I'll keep yo posted.

I got the MMBASIC interrupt going so MMBasic can decide when to fire the PIO.
Essentially MMbasic listens for the falling edge of the interrupt pin. the ISR is very short. The PIO's react to the rising edge

ISR:

- Set a dac
- if sendmarker=1 then
load T1 and T2 in Pio1
start pio1
load t3 in pio2
start pio2
- increment sweepcount

the main program (idle loop)
checks "sweepcount" and makes it roll over when it hits 5.
it also sets and clears the "Sendmarker" flag.

I've had this run overnight (without the actual PIO working. i was firing them but the I/O didn't work) at 1 millisecond. It didn't miss a single one. So timing-wise we're good. it will do the 4millisecond with time to spare.

vincenthimpe
Regular Member

Joined: 14/10/2018
Location: United States
Posts: 82

Posted: 12:28am 16 Sep 2025

Copy link to clipboard

Print this post

Now we are getting somewhere.

Is there a way to stop the pio machine from inside the PIO?
i've tricked it by using

.lab HALT
jmp HALT
[/code]

it works, but is it the right way ? Or is it needed at all? Since there are no further instructions it should stop.

vincenthimpe
Regular Member

Joined: 14/10/2018
Location: United States
Posts: 82

Posted: 01:25am 16 Sep 2025

Copy link to clipboard

Print this post

hmmm. There is a lot of jitter in the interrupt handler ( not the pio) and executing the I/O code is also jittery.

just doing

pin(gp0)=1
PIO start 1,0

creates jitter between the setting of the pin and launching the PIO. The delay is in the order of 25 to 30 microseconds...

Our "interrupt pulse is about 100 microseconds. MMBasic is too slow to complete what i need to complete in that timeframe

i can live with a fixed delay but the jitter is killing.
There's too many other things going on. (which are understandeable. this things services usb and a bunch of other things. But in my application none if it is necessary. It runs headless.

The pin interrupts are almost the lowest priority in MMbasic. There's too many other things running.

i need to look into cascading PIO. PIO can fire interrupts as well...
If i cascade PIO i can take some of the time critical stuff out of the software interrupt. (amongst which is the decision logic on which sweep to fire the PIO . this is the source of much of the delay and jitter)

THe bigger problem is the following:

I need to ponder a bit on how to do this. this is the problem when you have an "operating system" ( which is essentially what MMBASIC is ) in the way. There's too much household tasks in the background.

Rough sketch:
One pio listens to the hardware interrupt and endlessly counts from 0 to 5.
if the count value equals a loaded number ( the selected sweep number ) it fires a second PIO that is the marker generator. this is done using a hardware output looped back. The same hardware pin triggers a software interrupt that performs calculations and updates the DAC . But i use an external register. the DAC only truly "updates' on the sweep start bacuse the register latches at that point. It is being precalculated during the previous sweep but only updates at the sweep start. So the time consuming stuff is pushed into the"previous" 4mS and the tie critical stuff canhappen in the retract. The PIO regulate the flow. Essentially the PIO drive the software. not the other way around :)

Page 2 of 2

Print this page

To reply to this topic, you need to log in.