Really usefull toget anunderstanding of interrupts in PIO programming. The bit that takes a bit more explaination is around 18:25 , where individual interrupt handlers are setup for each state machine. David says 'here you can see that the interrupt handler is actually called based on the value of the relative interrupt index'. That is the handler that actions the interrupt is the one where the interrupt index matches the state machine number. So for example without the use of the rel() function, IRQ(0) will be handled by the handler assigned to machine 0, and similiarly IRQ(1) will be actioned by machine 1s handler. The rel() runction allows a program to be shared amongs machines so that each machine sees the interrupt in its own handler. However this pattern is limited in that each machine can only have one interrupt handled this way. Hence the further value in Davids polling examples. Thanks again David
Thanks for the further explanation. As you may have gathered, I'm not a big fan of restrictions that MicroPython puts on interrupts. I like C better, and I'm enjoying assembly (yes, they said I was a little weird when I was growing up...lol). Thanks for watching!
Hi David, nice series! PIO is awesome and thanks to you, I finally understand it. Could you maybe make some video about receiving/decoding some serial protocol? For example, WS2812B LED, Ethernet, whatever you have in your shack. Until now, you were mainly oriented on TX side, except of MIDI. Tnx.
Thanks for the comments and suggestion. I hope to publish a bare metal assembly video on UART communications in the next week or so, It's not PIO but close. Thanks for watching!
hi david! thanks for your great series about PIO! do you think it would be possible to read and decode a neopixel datastream connected to a pico with PIO? I'm looking for a way to make this work but am totally new to this bit banging stuff. All the best from Cologne! :-)
I haven't played with neopixels yet, but at a frequency of 800 KHz, I don't see why you couldn't. With PIO you can process 125 million instructions per second, much more than needed for an 800 KHz signal. Good luck, and thanks for watching!
@@LifewithDavid1 Hi David! Thanks for your reply! What I couldn't find anywhere here on TH-cam (nor elsewhere at all) is a video / an instruction about reading data of custom protocols (neopixel in my case) via PIO and processing them with the main core. Could it work like this: ? State machine 0's only job would be to sense the neopixels reset code of a PIN_LOW for more than 80 microseconds: Set an IRQ set the x register to a value that could be decremented to 0 within 80 microseconds. decrement it with every cycle as long as the inputpin is low. if the signal becomes high before x is zero we jump to the top. if it's at zero we clear the irq flag to trigger : State machine 4 waits for the IRQ flag to be cleared. Then sets the x register to 31 and decrements it with every clock cycle that the input pin is sensed to be high. The frequency of this state machine is set in a way that 31 full cycles take roughly 800 Nanoseconds to distinguish between bit 1 or 0 being 300 or 600 nanoseconds long. If the input pin goes low the value of x (as a representation of how much time has passe) is stored in a register (but which one?!) Somehow I would need to get the first 96 measured timings to the main core to interpret them as a 1 or 0 depending on a threshold and translate them into an array of 6 x 16 bit integers for further use. Does that make any sense? Since I'm totally new to handling bits and Micropython in general I'm not really confident in getting the syntax and structure right And since there is no easy way to debug things happening inside a PIO I'd love to finde someone, who is interested in giving some sort of support. The implementation of this function would open up many possibilities to the Neopixel community. So any hints would be highly appreciated :-)
Thank you. I found MicroPython very limiting when it came to Interrupts. I don't know how they would work for any UART application faster than 300 baud (OK, maybe that's a bit of a stretch, LOL). I have moved to assembly to handle interrupts and I'm very happy. It seems like both C/C++ and MicroPython impose time constraints on their interrupt handlers (probably because there is a lot more going on behind the scenes). However, with assembly, I can take my time; especially if that's the only interrupt in the system. Check out my Bare Metal troubleshooting video (th-cam.com/video/GyxlBpIZ28I/w-d-xo.html). Thanks for watching!
That's a great question. The only arithmetic function that PIO has is decrementing the X or Y register and that is in conjunction with a jump. So having PIO count the pulses directly is probably not in the cards. However, you could use PIO to monitor the encoder and have it trigger an interrupt when it sees a change in the encoder signal. The handler could update the motor position to a global variable that the main program could use as needed. Hope this helps. Good luck!
@@LifewithDavid1 silly though. If ill use dec function co count down the encoder. Since its 32 bit, its a lot of counts to be stored. What do you say?)
@@aleXelaMec PIO is not for everything. I'm not sure if you are using a single or two phase encoder, but PIO could do a little pre-processing, like de-bouncing or direction detection. If your main application is time critical, PIO could make the interrupt handler just a little faster. But for normal use, I would probably use regular GPIO interrupts.
@@LifewithDavid1 Got you. Program is not time consuming. it's an encoder counter on rp2040. my problem is that using mycropython sending data to display take more time than encoder readings, so I have to either move to C or try using two cores with a buffer. using regular interrupts now. But overall I like the idea of these modules even they are very limited. at least fun to play with ) Thanks
I've never seen code where you say it loops until the x register is zero and thought "Oh, yeah, that's obvious and intuitively readable". Maybe one of these days It'll click. Probably have to re-watch more videos.
Your pace suits me , I like the way you don't hurry through things 8-)
When you go fast; you make twice as many mistakes per minute :-)
great video- ive watched quite a few people looking for a good pio overview at this level, and you are way way better! cheers
Thank you so much!
Amazing video. Extremely clear and the first resource I found that explains the weird things in MicroPython and PIO :)
Thank you so much!
I'm glad you found it useful. Thanks for watching!
Thank-you for continuing this series!
You're welcome. Thanks for watching!
Really usefull toget anunderstanding of interrupts in PIO programming. The bit that takes a bit more explaination is around 18:25 , where individual interrupt handlers are setup for each state machine. David says 'here you can see that the interrupt handler is actually called based on the value of the relative interrupt index'. That is the handler that actions the interrupt is the one where the interrupt index matches the state machine number. So for example without the use of the rel() function, IRQ(0) will be handled by the handler assigned to machine 0, and similiarly IRQ(1) will be actioned by machine 1s handler. The rel() runction allows a program to be shared amongs machines so that each machine sees the interrupt in its own handler. However this pattern is limited in that each machine can only have one interrupt handled this way. Hence the further value in Davids polling examples. Thanks again David
Thanks for the further explanation. As you may have gathered, I'm not a big fan of restrictions that MicroPython puts on interrupts. I like C better, and I'm enjoying assembly (yes, they said I was a little weird when I was growing up...lol). Thanks for watching!
Thank you so much for this additional explanation. It’s really helpful.
Great series David. Well done!
Thank you. Thanks for watching!
Thank you sir. Was looking for exactly this topic.
Glad it was helpful! Thanks for watching!
Awesome video, very informative 👍🏾
Glad it was helpful!
Awesome irq deep dive.
Thank you!
Hi David, nice series! PIO is awesome and thanks to you, I finally understand it. Could you maybe make some video about receiving/decoding some serial protocol? For example, WS2812B LED, Ethernet, whatever you have in your shack. Until now, you were mainly oriented on TX side, except of MIDI. Tnx.
Thanks for the comments and suggestion. I hope to publish a bare metal assembly video on UART communications in the next week or so, It's not PIO but close. Thanks for watching!
hi david!
thanks for your great series about PIO!
do you think it would be possible to read and decode a neopixel datastream connected to a pico with PIO?
I'm looking for a way to make this work but am totally new to this bit banging stuff.
All the best from Cologne! :-)
I haven't played with neopixels yet, but at a frequency of 800 KHz, I don't see why you couldn't. With PIO you can process 125 million instructions per second, much more than needed for an 800 KHz signal. Good luck, and thanks for watching!
@@LifewithDavid1 Hi David!
Thanks for your reply!
What I couldn't find anywhere here on TH-cam (nor elsewhere at all) is a video / an instruction about reading data of custom protocols (neopixel in my case) via PIO and processing them with the main core.
Could it work like this: ?
State machine 0's only job would be to sense the neopixels reset code of a PIN_LOW for more than 80 microseconds:
Set an IRQ
set the x register to a value that could be decremented to 0 within 80 microseconds.
decrement it with every cycle as long as the inputpin is low.
if the signal becomes high before x is zero we jump to the top.
if it's at zero we clear the irq flag to trigger :
State machine 4 waits for the IRQ flag to be cleared.
Then sets the x register to 31 and decrements it with every clock cycle that the input pin is sensed to be high.
The frequency of this state machine is set in a way that 31 full cycles take roughly 800 Nanoseconds to distinguish between bit 1 or 0 being 300 or 600 nanoseconds long.
If the input pin goes low the value of x (as a representation of how much time has passe) is stored in a register (but which one?!)
Somehow I would need to get the first 96 measured timings to the main core to interpret them as a 1 or 0 depending on a threshold and translate them into an array of 6 x 16 bit integers for further use.
Does that make any sense?
Since I'm totally new to handling bits and Micropython in general I'm not really confident in getting the syntax and structure right
And since there is no easy way to debug things happening inside a PIO I'd love to finde someone, who is interested in giving some sort of support.
The implementation of this function would open up many possibilities to the Neopixel community.
So any hints would be highly appreciated :-)
very enlightening. Glad to find this tutorial. Can you please explain how to create interrupts for UART in micropython?
Thank you. I found MicroPython very limiting when it came to Interrupts. I don't know how they would work for any UART application faster than 300 baud (OK, maybe that's a bit of a stretch, LOL). I have moved to assembly to handle interrupts and I'm very happy. It seems like both C/C++ and MicroPython impose time constraints on their interrupt handlers (probably because there is a lot more going on behind the scenes). However, with assembly, I can take my time; especially if that's the only interrupt in the system. Check out my Bare Metal troubleshooting video (th-cam.com/video/GyxlBpIZ28I/w-d-xo.html). Thanks for watching!
thanks. I want to know ho to sample analoge signal with PIO.
See my other reply. Good luck!
Thanks for your videos. Mind me asking how can i make a counter from the encoder (counting steps motor made) using pio? Big thanks in advance
That's a great question. The only arithmetic function that PIO has is decrementing the X or Y register and that is in conjunction with a jump. So having PIO count the pulses directly is probably not in the cards. However, you could use PIO to monitor the encoder and have it trigger an interrupt when it sees a change in the encoder signal. The handler could update the motor position to a global variable that the main program could use as needed. Hope this helps. Good luck!
@@LifewithDavid1 thanks for an answer, but for this reason im using regular interrupt. What i will achieve using pio this way?
@@LifewithDavid1 silly though. If ill use dec function co count down the encoder. Since its 32 bit, its a lot of counts to be stored. What do you say?)
@@aleXelaMec PIO is not for everything. I'm not sure if you are using a single or two phase encoder, but PIO could do a little pre-processing, like de-bouncing or direction detection. If your main application is time critical, PIO could make the interrupt handler just a little faster. But for normal use, I would probably use regular GPIO interrupts.
@@LifewithDavid1 Got you. Program is not time consuming. it's an encoder counter on rp2040. my problem is that using mycropython sending data to display take more time than encoder readings, so I have to either move to C or try using two cores with a buffer. using regular interrupts now. But overall I like the idea of these modules even they are very limited. at least fun to play with )
Thanks
I've never seen code where you say it loops until the x register is zero and thought "Oh, yeah, that's obvious and intuitively readable". Maybe one of these days It'll click. Probably have to re-watch more videos.
... I guess the logic is, if it can't decrement, that line 'gets skipped'. I do hope to get a great grasp of the Pi Pico; it's a nice unit.
Marc, This video might help: th-cam.com/video/qegs8LGINww/w-d-xo.html