12:09 you can avoid the hard-wired numbers for the JMP instructions used by pio_encode_jmp() by using PUBLIC labels in the PIO program. The syntax is ‘PUBLIC .daveslbl’. It‘s like a PIO .define directive with PUBLIC, for which a macro is #define’d that you can use in the C program (see sections 3.3.2 and 3.3.6 of the SDK doc). Then you can write pio_encode_jmp(offset + daveslbl) in the C code. (The macro name may have the PIO program name as a prefix, as in ‘davespio_daveslbl’, see section 3.3.2 for the difference between global and program symbols). That saves you the trouble of working out the numeric JMP offset, which is easy to get wrong and has to be changed whenever you change the PIO code, whereas the macro-ified label will always get it right.
That is so cool! I thought there might be a way of doing that; but I hadn't gotten there yet. Thank you so much for the info; I'll try it out soon. :-)
I'm sorry to bother you; but I appear to have a mental block. In my example, I've added "public led1_entry:" just before the "led1:" label in the PIO program (named "ep10demo"). Do I also add a "#define ep10demo_led1_entry" at the beginning of my C program and then use "pio_sm_exec(pio, sm, pio_encode_jmp(ep10demo_led1_entry + offset));" to jump to that label? I've tried many different combinations of program names, locations, and punctuation and I keep getting errors. C is not my native language and I'm getting a little confused. Any guidance would be helpful; thank you so much!
@@LifewithDavid1 I expressed a couple of things incorrectly in the first comment. The syntax is 'PUBLIC daveslbl:' (no dot, and with a colon on the end like a regular label). 'PUBLIC' apparently doesn't have to be capitalized (I thought that was required). So it's just like a regular label, except preceded by 'PUBLIC'. And in my example, the macro name has the PIO program prefix and '_offset_', so it comes out like 'davespio_offset_daveslbl'. Good luck and Merry Christmas!
@@LifewithDavid1 almost forgot, in answer to your question, *you* don't add a #define, pioasm generates it for you as a result of using PUBLIC. If you're still getting errors, you can use the comment section in the gitlab snippet to post the error messages.
You are brilliant! Thank you so much! I used ..."jmp(ep10demo_offset_led1_entry+offset))" and it worked immediately. Thanks again and have a Merry Christmas.
Glad you like them! There are some concepts that are hard to wrap one's mind around. Over time, I think it breaks down the mental barriers and all of a sudden it makes sense. I put these videos out over almost a year so it had time for it to sink in. Trying to get up to speed in a couple days is too hard for my brain. lol
Thanks for these videos, I'm getting a much better understanding of the pio. You explain the steps very well I look forward to when you sort out how to generate video.
I've got a few videos that explore DMA. The main one is Episode 9 ( ruclips.net/video/-Wh3SIAl0Ic/видео.html ) as well as Episodes 12, 14, 15, and 16. Good luck and thanks for watching!
2 года назад
Very good instructive video! Thanks and happy holidays! Perhaps we get a little bit of white christmas here, too.
Thanks for the kind words. I love a white Christmas; but there is no snow here in Ohio for the foreseeable future; I had to pull out some video of my back yard from last year to make the final scene.
That's a good question. I thought I had seen where somebody suggested where it could be done. I'll find out. Sounds like another job for "Captain Pico"!
I have a few questions: I realize this is mainly to demonstrate a concept,, but is using this approach to bink the LEDS in the set patterns any faster than controlling the LEDs in pure C, no PIO? I suppose one advantage is to free up the CPU for other things, but in this case you're using a lot of C code to control the PIO. At the end you sleep the C program a fixed amount of time. Is there a way to have C know when the FIFO is empty and resume when it is? I wonder if this hybrid concept may be useful for my transpose issue I have for the neopixel project I've been mulling over. Speaking of which, the examples has an example of parallel driving of two neopixel strands. I believe the industry name for neopixels is ws2812b but I keep forgetting the numbers.
PIO can be much faster than C alone. PIO can take care of all the handshaking and timing; the main core can do something else at the same time. And it can do it at 125 mHz. More time can be saved with serial output compared to parallel output since serial output would consume more bit banging processor time that parallel output would. Not only can you use interrupts to let the C program know that the FIFO is empty, but you can use DMA coupled with PIO to automatically transfer data out without any core time after it is started. I cover interrupts in Episodes 19 and 20 of "The PIO Chronicles". 8 PIO state machines can do a lot.
@@LifewithDavid1 if you're using DMA; sure. But I am referring to this particular demonstration where the CPU is granularity controlling the PIO operation
@LifewithDavid1 At first I thought you contradicted yourself saying serial was faster than parallel but then say serial required more CPU. What I think you meant to say is serial can benefit more using PIO than by CPU. Sure, as long as you automate enough away from the CPU. Actually PIO can do parallel rather well. Just have it out more bits during an instruction and the bits outed will be placed on consecutive GPIO pins. Out pin 8 for example will place the bits of the byte on GPIO pins 0-7 if you set the base pin to 0.
@@danman32 PIO does do parallel well. Check out Episode 3 of The PIO Chronicles. Using the side set option allows efficient use of GPIO pins for flow control.
12:09 you can avoid the hard-wired numbers for the JMP instructions used by pio_encode_jmp() by using PUBLIC labels in the PIO program. The syntax is ‘PUBLIC .daveslbl’. It‘s like a PIO .define directive with PUBLIC, for which a macro is #define’d that you can use in the C program (see sections 3.3.2 and 3.3.6 of the SDK doc). Then you can write pio_encode_jmp(offset + daveslbl) in the C code. (The macro name may have the PIO program name as a prefix, as in ‘davespio_daveslbl’, see section 3.3.2 for the difference between global and program symbols). That saves you the trouble of working out the numeric JMP offset, which is easy to get wrong and has to be changed whenever you change the PIO code, whereas the macro-ified label will always get it right.
That is so cool! I thought there might be a way of doing that; but I hadn't gotten there yet. Thank you so much for the info; I'll try it out soon. :-)
I'm sorry to bother you; but I appear to have a mental block. In my example, I've added "public led1_entry:" just before the "led1:" label in the PIO program (named "ep10demo"). Do I also add a "#define ep10demo_led1_entry" at the beginning of my C program and then use "pio_sm_exec(pio, sm, pio_encode_jmp(ep10demo_led1_entry + offset));" to jump to that label? I've tried many different combinations of program names, locations, and punctuation and I keep getting errors. C is not my native language and I'm getting a little confused. Any guidance would be helpful; thank you so much!
@@LifewithDavid1 I expressed a couple of things incorrectly in the first comment. The syntax is 'PUBLIC daveslbl:' (no dot, and with a colon on the end like a regular label). 'PUBLIC' apparently doesn't have to be capitalized (I thought that was required). So it's just like a regular label, except preceded by 'PUBLIC'. And in my example, the macro name has the PIO program prefix and '_offset_', so it comes out like 'davespio_offset_daveslbl'. Good luck and Merry Christmas!
@@LifewithDavid1 almost forgot, in answer to your question, *you* don't add a #define, pioasm generates it for you as a result of using PUBLIC. If you're still getting errors, you can use the comment section in the gitlab snippet to post the error messages.
You are brilliant! Thank you so much! I used ..."jmp(ep10demo_offset_led1_entry+offset))" and it worked immediately. Thanks again and have a Merry Christmas.
Your series of videos on the pi pico (all applicable to the rp2040 by itself) are great.
Many thanks for all the work. It's a great help!
Glad you like them! Thanks for watching.
Very good and clever examples, thank you!
Glad you enjoyed it!
Somehow this was easier to understand than the last couple of episodes. Thanks, all your videos are gold dust.
Glad you like them! There are some concepts that are hard to wrap one's mind around. Over time, I think it breaks down the mental barriers and all of a sudden it makes sense. I put these videos out over almost a year so it had time for it to sink in. Trying to get up to speed in a couple days is too hard for my brain. lol
Thanks for these videos, I'm getting a much better understanding of the pio. You explain the steps very well I look forward to when you sort out how to generate video.
Thank you so much for watching. I've found that the best way to learn something is to try to teach it to others. This is my way of learning PIO.
Very nice! I'm also struggling with DMA 🙂
I've got a few videos that explore DMA. The main one is
Episode 9 ( ruclips.net/video/-Wh3SIAl0Ic/видео.html ) as well as Episodes 12, 14, 15, and 16. Good luck and thanks for watching!
Very good instructive video! Thanks and happy holidays! Perhaps we get a little bit of white christmas here, too.
Thanks for the kind words. I love a white Christmas; but there is no snow here in Ohio for the foreseeable future; I had to pull out some video of my back yard from last year to make the final scene.
Great series on the PICO. Thank you.
Can MicroPython be used instead of C to accomplish "Forced and Exec PIO Instructions"?
That's a good question. I thought I had seen where somebody suggested where it could be done. I'll find out. Sounds like another job for "Captain Pico"!
I have a few questions:
I realize this is mainly to demonstrate a concept,, but is using this approach to bink the LEDS in the set patterns any faster than controlling the LEDs in pure C, no PIO?
I suppose one advantage is to free up the CPU for other things, but in this case you're using a lot of C code to control the PIO.
At the end you sleep the C program a fixed amount of time. Is there a way to have C know when the FIFO is empty and resume when it is?
I wonder if this hybrid concept may be useful for my transpose issue I have for the neopixel project I've been mulling over.
Speaking of which, the examples has an example of parallel driving of two neopixel strands.
I believe the industry name for neopixels is ws2812b but I keep forgetting the numbers.
PIO can be much faster than C alone. PIO can take care of all the handshaking and timing; the main core can do something else at the same time. And it can do it at 125 mHz. More time can be saved with serial output compared to parallel output since serial output would consume more bit banging processor time that parallel output would.
Not only can you use interrupts to let the C program know that the FIFO is empty, but you can use DMA coupled with PIO to automatically transfer data out without any core time after it is started. I cover interrupts in Episodes 19 and 20 of "The PIO Chronicles". 8 PIO state machines can do a lot.
@@LifewithDavid1 if you're using DMA; sure. But I am referring to this particular demonstration where the CPU is granularity controlling the PIO operation
@LifewithDavid1 At first I thought you contradicted yourself saying serial was faster than parallel but then say serial required more CPU.
What I think you meant to say is serial can benefit more using PIO than by CPU. Sure, as long as you automate enough away from the CPU.
Actually PIO can do parallel rather well. Just have it out more bits during an instruction and the bits outed will be placed on consecutive GPIO pins.
Out pin 8 for example will place the bits of the byte on GPIO pins 0-7 if you set the base pin to 0.
@@danman32 PIO does do parallel well. Check out Episode 3 of The PIO Chronicles. Using the side set option allows efficient use of GPIO pins for flow control.