Absolutely the gold standard for PIO documentation. I've been flailing about for days trying to find any kind of tutorial, but the most I found before this was just the basic list of instructions with no information on options or capabilities. "`PULL BLOCK`? Where did you define BLOCK, what address is that?" This video finally answered pretty much all of my questions at a level I am comfortable with, and I can't thank you enough.
Fair point! But the DMA in Pico is so flexible and has many cool features that I think I need to plan such a video it well. I'll think about it. Cheers for that.
It doesn't require DMA to operate but combining the two gives the real power. Shifting the data in or out of Pico using a custom protocol (PIO) and having it in memory ready without any processing power (DMA). That's what I'm thinking about - but didn't get the chance really play with DMA in any form before.
Your explanation of the PIO and its use with detailed coding examples is exemplary. I don't know the Pico that well, but I developed processor hardware in the 1980s and wrote plenty of 16 bit assembly language code back then. I understood everything that you described pretty much on the first pass. Many videos on the Pico take too many shortcuts, but for me, this was just perfect! The video and audio quality were also perfect in my view. Thank you. I shall now look at some of your other videos. The 80C188 with the Pico is fascinating.
@GodmanchesterGoblin - thank you VERY much for your comments. I'm aware that these kind of very detailed (and looong) videos might not be for everyone, but as you pointed out - there is plenty of videos making shortcuts and only briefly going through the list of PIO instructions with a few screens from the documentation put together. Yes, I know: I did exactly the same thing, but for me it was only an introduction. I make these detailed videos for people like me, who like to learn by example and with hope that if someone wants to do some PIO programming themselves, they could find them helpful. I would also thank you for your kind words about my explanation. My main concern when I was starting (and which still stands) was the fact that (obviously) English is my second language. It is a big relief to me that it is understandable (but just in case I always prepare the subtitles). Big THANK YOU again!
@Slador You're welcome. I realised that English was not your first language, but you have turned that to your advantage with your very careful pronunciation and good grammar. Honestly, I don't think it's a problem.
Wow… this is what happens when you got no experience and just skim over the manual….I didn’t know pi pico had this kind of stuff. I just so happened to have few of these with wifi laying around. While waiting for the 8088 to arrive will dive into this stuff. Love this channel! Learning something new on every video.
I wonder about having the IRQ clear after the long delay. If you clear IRQ before the delay, you can do that for "free" as part of the delay; the main processor tasks would have more time to rest the buffers, among their other tasks. But overall an excellent description of PIO, I finally understand a few things.
Apologies for late response. I assume you're referring to the last example. Please note that the interrupt flag in this programme is used only as a "busy" flag, which the main programme can check before sending new data to PIO over DMA to keep the required "reset" timeout of the LED. It does not stop the main programme from doing something else. In this programme this flag does not even raise a CPU interrupt. I used the while loop only to show how we can use PIO interrupt bits to synchronise the CPU programme with the PIO one. This is just a trivial example not meant to use in any "production" code. In real-life programme you could simply raise a CPU interrupt when the IRQ flag is set, which handler would send the data from RAM to PIO automatically. Then the main programme would write the required pattern data to the RAM and go on doing other stuff.
In a world of circuits and wires, The Pico Pio shines with its own fires. A small board with power to spare, It's a true delight for those who dare. With GPIO pins that are easy to use, The Pico Pio is quite the muse. From sensors to motors, it does it all, And programmers can have a ball. The possibilities are endless, From robotics to home automation, it's relentless. The Pico Pio is a gift to behold, With its power and capabilities untold. So let us all hail the Pico Pio, A true gem for programmers in the know. With its Raspberry Pi roots, It's a small board that bears lots of fruits.
Excellent video and great explanation. I had heard something special about the Pi Picos PIOs, but I had no idea. Just some feedback. I get the impression that code A thru D will all have slightly different waveforms(?), in that some of the instructions (in code A) take a single cycle and the PIO presumably holds its previous value. Later when you explain about the "side" feature this appears to be a way to change the PIO value while at the same time executing an instruction. I am unfamiliar with the waveforms needed by the LED device, so I am unclear as to whether each bit needs to be immediately back to back or whether there can be a pause of a few cycles.
Thank you! I'm planning more Pico videos including the DMA and PIO. Not only is it super interesting to me, but also I need the Pico in my Intel 80188 computer. So, more stuff is coming ;-)
Very informative. On first learning about the Pico, my thoughts were "just another microcontroller" but this shows it has a lot of power with the PIO than even the ESP32 might have. Using the Pico for the 8088 project might be considered cheating though. I also got very lost with the last several 8088 videos.
@Daniel Morin: Thank you! I'm really grateful for your comment regarding cheating. I honestly asked myself the same question a few months ago before I decided to use the Pico. Here is how I see it: If I wanted to build a IBM PC compatible, I would probably try to use as many original components as possible. Let's assume I was even able to do it and, for example used the original disk controller. And then what? What do I connect to it? It's not easy to find floppy disk drives (and floppies themselves) or even old IDE hard disks these days. I would then need to emulate those using modern electronics anyway and try to connect via the old protocol. Or, let's think about the keyboard. I could use the keyboard controller chip, but, again, what do I connect to it? It's not easy to find keyboards still "talking" PS/2. On the other hand, even the hard drive itself has a processor, so is it already cheating, because I use something having a CPU inside? The line is very thin - my approach is just to move it slightly. Instead of trying hard and finding expensive vintage chips and then trying hard and connecting a modern microcontroller emulating a drive to it - I'd rather use a microcontroller simply emulating the hard drive controller, but still talking to the main CPU on the data bus like the original disk controller would (using ISA). The only difference is that I won't use the 40pin IDE ribbon, but from the point of view of the software - there is no difference. My aim is to keep some software compatibility with the original BIOS, but I already resigned from some hardware compatibility using the built-in interrupt controller, DMA and timers inside the 80C188. Also, I would like to design this computer for others to be able to build is easily (no SMD if possible) and using chips relatively easy to buy. Fortunately 80C188s are still in good supply (in contrast to 80C88 for example). So, that's my justification for using the Pico as a I/O controller in this computer. I'm not expecting everyone to agree with me. Again - it depends on what you want to achieve. One more thing: I'm slightly worried about your last paragraph, that you got lost with several of my videos. Would you be so kind to elaborate on why do you think that would be? If you'd rather like sending me an email, please find it in the "about" section of this channel. Thank you again for your comment.
@@SladorSoft Thanks for taking the time and interest in my coment. I probably started getting lost when you started mixing C++ with assembly. I'm still figuring out in my head all the ins and outs with C++. My mind has done better with top-down programming of yesteryear and the thinking linearly than object-oriented programming and abstracts in general. I did design my EE undergrad senior design project using the 8088 on a breadboard (I still have that breadboard though wires have gotten corroded and fell out in places). The code part worked well, only had issues with the phone line interface where I was trying to read touch tones in hi-Z using an RS custom chip. Hi-z so I would not cause my circuit to cause an off-hook condition. I lost my documentation including schematic and code so I was thinking I might want to revive the project, at least the controller part, even see if the EPROM retained all the original bytes. Maybe someday I'll get a read of the 80MB MFM drive I still have and get the documentation back :) I didn't realize the 80c88 was so hard to get these days. I should have gotten it months ago. My skill level in this area probably can be explained in my following Ben Eater's projects, having bought all of the kits and expanded on the 8-bit processor/computer on a breadboard. None of his 4 bit opcode rubbish, mine is 8 bit opcode with 8 bit operand, 8 bit address line so 256 byte address space instead of his 16 bit RAM.
awesome explanation, thx! one question though... your code works for one LED, but for the next LED you have again two additional instructions on the top to pull in the next 32bits into the shift register and throw away 8 bits. so every 24bits sent out to the LEDs you would get additional 800us low signal - or did I miss something?
This is acctually a similar approach that has PSOC microcontrollers (previously "Cypress Semiconductors", meanwhile "Infineon") implemented for more than a decade. So called UDB, i.e. Universal Digital Blocks, that can be programmed using Verilog (or use the graphical interface to do so). Very helpfull for just such tiny problems, that would otherwise intensively occupy the CPU.
S U P E R interesting video. I'm getting my teeth in the PIO for a full duplex SPI interface, and this was a really good and detailed introduction. The only possible thing I would recommend in your future videos would be some sort of logic analyzer captures, that way we could've seen the flaws of the first design for instance. Thanks for sharing!
Thank you for your kind comment. I'm glad you found it useful in any way. I love your idea of using a logic analyser. I'll try to employ in future videos. Thank you!
Hi, thank you! Yes, there will be more videos about the PIO, because I need it for my Intel computer. I have plans for two more videos involving programming the PIO at the moment. Unfortunately I have no plans to use Python at all. I have no experience with (nor interest in) it.
You know you can remove two NOPs if you add delay to mov x, y on line 8, and irq clear 0 which you should also move from line 33 to line 24, because there is no reason the CPU has to wait until the reset is complete to load the new data right? Ah well, that is all academic I suppose.
@frozen_dude - fair point! I could probably make a few more improvements, but as you guessed, it was mainly for explanatory purpose rather than "production ready" code. I would only recommend it for people who would like to start tinkering as a "hello world" example, which they can take and play with. Thanks!
Yes, this and even more is possible. One PIO device has 4 state machines, each of them can run a separate programme and each of them has separate GPIO pin binding, clock divisors, etc. The only limitation is that all 4 state machines (programmes) share the same programme memory, which is only 32-instruction long. In other words, all (up to) four of your programmes need to fit together in this 32-instruction long space. On top of that, there are two completely independent PIOs on RP2040 chip, so you can theoretically run up to 8 short programmes. The example in the video was as simple as possible and was using only one state machine of one PIO. In one of the future videos I'll be showing an example of multiple programmes running on the same PIO.
@@SladorSoft Ohh, thanks. I'm very interested, but i cant find any easy tutorial. i'm trying to make my own PIO program for WS2812, only works one pixel, i think is a problem with timings, you know any way to send the data to others pixels?
very very nice overview of ways to program neopixel data as output. what do you think about the possibility of reading and decoding incoming neopixel data from a pixel strip? would that be possible somehow?
Hi thanks! Yes - this is definitely possible. It would be quite unusual though. Why would you want to do that? The only idea coming to my mind is to emulate these neopixels by the Pico. You can imagine an RGB led driven from the Pico via PWM and receiving data in the WS2812 format. So, yes, I guess just to prove the point you could do that :-)
@@SladorSoft My use case is a kinetic light installation made of hundreds of SK6812 pixels and I would love to use some pixels (distributed across the pixel data stream) to store position data in them like with a moving head fixture. the pico would need to get them and drive stepper motors based on the numbers. Another great thing of the neopixel format is that you just need two wires and if you take a nicely isolated coax cable 20m distances can easily be realised.
@@CineMuck84 That's interesting and very bespoke. The Pico is certainly able to receive this protocol and even relay the data on down the line as the neopixels do. Good luck with your idea!
25:17 Hmmm one question I have about this. The data sheet shows each bit to be 1250 ns for each bit. And a 1 is 800 ns high signal followed by 450 ns low signal. But dividing 1.25us / 3 gives 417 ns for each third of 1.25 us (or 1250 ns). So this is not in line with datasheet. So this 1/3 abstraction is allowed by the protocol even though it's outside of the protocol? Would it not be better to have a clock step of 50 ns per clock and modify the pio code to have wait sections in multiples of 50 ns clock steps? That way you can generate high/low pulses of 400, 800, 450, 850 ns? After reading the datasheet, looks like each if the 4 signals mentioned can vary ±150ns. So it appears the protocol is quite lax. Subbed btw. Thanks for this great explanation of PIO. I have a self-designed KB PCB coming in from china with the rp2040 and 68 x sk6812-mini-e per key RGB backlights. Since NeoPixel PIO already exists, it does something similar to this code, but has a smaller clock divider from looking at the source code and uses delays of varying length on all instructions. Don't think I will need to do any PIO in my case, but good to know for sure since it seems to be a big USP for rp2040. Will use KMK firmware for this board. Perhaps I can switch from CPU impl of the protocol to the PIO impl if I change KMK for the rp2040.... actually, they already did this in source code with conditional compilation based on RP2040 being used or not.
Hi there! Thanks for your comment (and for the sub). Yes, I tried to keep it simple just for the sake of this example. As you noticed I kept the timings well within the allowed tolerance. Please bear in mind it was a simple code explaining how PIO works rather than "the best neo pixel implementation in the world" ;-) You're right that making the clock tick 50ns would allow for more precise timing, but again... since it works and within allowed margin, why not? Good luck with your PCB - share your updates when it's ready. This seems like a good use of PIO, unless the CPU doesn't have much else to do and you take care of interrupts and other stuff going in the way of precise timing. Take care! Thank you
@@SladorSoft I have received my PCB at the start of this week. It looks great, so impressed with the look of it. Anyhow, I took time to verify from the wires of a cut and stripped USB cable, that the connections were arriving at the correct destinations on the PCB, then plugged it in and dropped my previously compiled CircuitPython bin on there and it all works. Put in some KMK in there and tweaked it for my mystery rotary encoder adaptation and now that works too. I do know that at least one of my sk6812-mini-e LEDs works "out of the box", as the CircuitPython firmware build is flashing the status LED different colours for certain situations. The kb matrix works at least for 1 key. And the Freq of the RP2040 is 125 Hz default. So with all of the types of hardware partially confirmed working, its going good so far. I did have a mistake that I made though. I got the ribbon connector pins for USB (+5 other unused pins for my implementation) mirror mismatched. But one quick cable replacement and it's good. Overall very happy with the enjoyable mix of hardware and software development to produce a functional item for myself. Learnt some new things along the way too. I expect to have a fully functional kb at the end of the week or mid next week.
@@SladorSoft I understand that most of your audience is not made by professionals, and keeping things simple helps them understanding and coming... But one important reason the PIO was created is to achieve precise and stable timings. Neglecting the timings, in general, defeats the whole purpose of the PIO, and might lead to, "wow! I've got it to work!", or in your case, "yes it's wrong, but it works!" - and it might work sometimes, under certain conditions. Might not work if conditions, or components are changed, and it will be a nightmare to troubleshoot such timing problems. That's on one hand. On the other hand, why teach people to be sloppy from the get-go?! Why not try to teach them to be thoughtful and apply the best practices and rules? Maybe even to read and obey the datasheet?! There is enough garbage (99,999%) on the internet to call for yet another one!
@@lukamarin9622 I think anybody getting this deep into Pico SDK already understands the importance of timings and can adjust stuff themselves or maybe they've already seen some other videos and one of those already explains it. This video does not exist in the vacuum and coming to this video I don't want someone explaining why timings are important - I want to learn how PIO works and I got what I wanted. Even then, if someone's way to live is to copy paste everything without a deeper thought, I'm bitter enough to just let them learn the hard way instead of being hand held every time.
Oh, thanks! I wasn't aware of his channel. But I cannot find anywhere where he programmes the PIO on the Pico? Anyway I need this for my Intel 8088 computer hence this video :-)
@Joshua McCunn: have you managed to do it yet? You can always use my source code from the video as a starting point and change a few things (like "LED_COUNT" and "WS2812_PIN" macros etc.)
Dear sir. Did you realized to write a Manchester coding interface using PIO? This code alows sendind data by ac Channel like Transformers, and allows pre equalizations, and filtering. Don't you?
Hi @JorgeSilva-em8pf! Yes, I saw someone implementing a Manchester code and built a working Ethernet controller. There is plenty of possibilities of using PIO for communication and if I wanted to try them out it would take hundreds of videos ;-) But in the next video I'm going to show how to programme the Pico W to talk to the Internet via Wi-Fi. I hope you find it interesting as well.
Great video. Most people use the pico to show novice level python. I like how you used c++ and op codes. Thank you. You are a professional programmer I suspect. I majored in search over 2 decades ago and graduated top of my class but never wanted to move away to work so I just started programming again about 4 years ago and noticed all these pseudocode-like languages dominating the sciences and it saddened me.
Yes, different (very) high-level languages dominated lots of areas, but fortunately, languages like C++ are still important and widely used. I've been working in C++ for over 20 years and, for example, don't know Python at all. So C/C++ was an obvious choice for me ;-) Thank you!
@@SladorSoftc++ should be the only language computer scientists learn in school. They may never use it again but they'll be better critical thinkers and problem solvers.
@Love made in Japan: Both PIO blocks are completely identical and can be swapped with one another easily. You should be able to do it by replacing any references to "pio0" pointer defined by the SDK to "pio1" and, if you use the interrupts raised by the PIO, you also need to replace "PIO0_IRQ_X" with "PIO1_IRQ_X".
Thank for the idea, but the channel is still quite small and I don't believe that there are many people wanting to support me that way. And also, I cannot promise them regular videos as this is my after-hours project which I (unfortunately) cannot spare too much time to. Cheers!
@@SladorSoft yes it’s small, but you may be surprised how many people would support you. Also, on Patreon you can use a model where subscribers only pay per video and not per month.
Very good video, detailed video. But we all know videos of this quality are rare to find. The authors of excellent content don't seem to keep then coming: However, the poor videos keep on coming.
Thank you very much for your kind words. I'm not going anywhere yet ;-) I may not have a lot of spare time to produce those, but I'm still going to do that. Thanks!
none of the programs looks right: (a) written as nothing else but mov pins takes any cycles (b) written as pull and out don't take cycles (c) written as pull and out after .wrap_target don't take cycles
Hi there. I'm assuming that by saying "does not look right" you mean that there will be an additional delay inserted in the data between the separate pixels introduced by the first two instructions (pull and out)? Yes - that's would be correct, but - as seen at the end of the video - perfectly acceptable in practice by the LEDs. Apparently, they accept even up to a few microseconds between pixels. Your first comment (a) is not right as in fact I strictly rely on the time taken by each instruction. Have a look at the programme "B" after the "next_bit" label, where all the timing is based on this. All of this aside, the video was meant as an introduction to the PIO, in which the neo-pixels were thought off only as a mere visual effect of a PIO programme. I never stated that there are instantaneous PIO instructions, so, hopefully the video may still serve as a good starting point in understanding and using the PIO for other viewers. Thank you for taking time to watch and comment.
@@SladorSoft well, the fact that neo-pixel tolerates such huge (especially for (a)) deviations is not a good justification regarding acceptance in practice - apparently your neo-pixel samples first intervals and adjusts expectations on the fly. However it's not in specs and can be different form different providers or even from different batch. to be continued
@@SladorSoft Comment (a) is completely right - you set cycle time to 1.25/3 us - every pixel will be delayed by 2 cycles (lines 4,5) with low level, then for every bit - additional low for 2 cycles (lines 8,9), after bit 1 one cycle (line 13), at the end of bit one cycle (line 20) - as I said, every additional instruction besides mov is adding out of specs delay. to be continued
@@SladorSoft And the same with (b) and (c) - you put cycle time in the way that you just can't fit anything between GPIO driving functions (mov or side) - "Have a look at the programme "B" after the "next_bit"" - yes, exactly - line 9 is not accounted for. the end (youtube doesn't allow me to post long comments for some reason 💩)
Hi. Thank you again for your thorough reply (I had never had any problems typing longer comments - maybe it's the mobile app issue?). You are right that I introduced a delay between pixels, but it is hugely insignificant to the 50us "reset" delay (I know it's not excuse). I'm not certain which line you mean by "line 9", because it looks like it is the "out x, 1" which execution time is crucial in timing during sending the bit. But this discussion is completely off-topic which I was trying to express in the last part of my original comment. The goal of the video was to introduce the PIO for beginners and my aim in these programmes was to show as much of the PIO assembler as possible in a short and easy to understand programme. The focus was on using different ways of GPIO manipulation, sideset, wait cycles and others. I could not show and explain these if I used for example the programme included in the Pico SDK documentation. It is a very short programme doing exactly that. But how many features can you show in a few-instructions-long programme? That's also the reason why I wrote four of them - just to show different features and approaches to programming the PIO. I too always stick to the specification and I would understand your concerns if it was production code. But it was only an example, in which the LEDs were mostly irrelevant. If it was a "How to drive neo-pixels" video, I'd be the first to point out the deficiencies of the code. Again, thanks for your comments and your thorough analyse. Cheers!
![ปฏิเสธไม่ไหว (Crush on you) - LIPTA feat. No One Else [TEASER MV]](http://i.ytimg.com/vi/VC689EgdSIw/mqdefault.jpg)
I don’t believe I could’ve wrapped my head around PIO better spending 50 minutes any other way. Thank you!
Thank you for your comment. I'm really glad that I could help!
Hands down the best PIO video I've seen on yt so far, this has inspired me to try PIO out. Just wish the algo had suggested this earlier 😂
Absolutely the gold standard for PIO documentation. I've been flailing about for days trying to find any kind of tutorial, but the most I found before this was just the basic list of instructions with no information on options or capabilities. "`PULL BLOCK`? Where did you define BLOCK, what address is that?" This video finally answered pretty much all of my questions at a level I am comfortable with, and I can't thank you enough.
This is a great video! Please keep up more on the Pico. And yeah, I would love to know more about DMA with the Pico. Thanks!
Yes, I think I would like to make a few more (not only about DMA, but other stuff as well) as I really enjoy playing with the Pico ;-)
Great Video and explanation. Since PIO depends on DMA please do video about it. Would be fantastic addition.
Fair point! But the DMA in Pico is so flexible and has many cool features that I think I need to plan such a video it well. I'll think about it. Cheers for that.
Since when depends PIO on DMA? Can you detail, please? Maybe with a quote from datasheet...
It doesn't require DMA to operate but combining the two gives the real power. Shifting the data in or out of Pico using a custom protocol (PIO) and having it in memory ready without any processing power (DMA). That's what I'm thinking about - but didn't get the chance really play with DMA in any form before.
This is an excellent introduction to the PIO, well done! I'll be trying to write my first PIO programs soon.
Your explanation of the PIO and its use with detailed coding examples is exemplary. I don't know the Pico that well, but I developed processor hardware in the 1980s and wrote plenty of 16 bit assembly language code back then. I understood everything that you described pretty much on the first pass. Many videos on the Pico take too many shortcuts, but for me, this was just perfect! The video and audio quality were also perfect in my view. Thank you. I shall now look at some of your other videos. The 80C188 with the Pico is fascinating.
@GodmanchesterGoblin - thank you VERY much for your comments. I'm aware that these kind of very detailed (and looong) videos might not be for everyone, but as you pointed out - there is plenty of videos making shortcuts and only briefly going through the list of PIO instructions with a few screens from the documentation put together. Yes, I know: I did exactly the same thing, but for me it was only an introduction. I make these detailed videos for people like me, who like to learn by example and with hope that if someone wants to do some PIO programming themselves, they could find them helpful.
I would also thank you for your kind words about my explanation. My main concern when I was starting (and which still stands) was the fact that (obviously) English is my second language. It is a big relief to me that it is understandable (but just in case I always prepare the subtitles). Big THANK YOU again!
@Slador You're welcome. I realised that English was not your first language, but you have turned that to your advantage with your very careful pronunciation and good grammar. Honestly, I don't think it's a problem.
@@GodmanchesterGoblinthe fact that english is you second language IS your strenght for sure: It is crystal clear for me (Brazilian).
Wow… this is what happens when you got no experience and just skim over the manual….I didn’t know pi pico had this kind of stuff. I just so happened to have few of these with wifi laying around. While waiting for the 8088 to arrive will dive into this stuff. Love this channel! Learning something new on every video.
I wonder about having the IRQ clear after the long delay. If you clear IRQ before the delay, you can do that for "free" as part of the delay; the main processor tasks would have more time to rest the buffers, among their other tasks. But overall an excellent description of PIO, I finally understand a few things.
Apologies for late response. I assume you're referring to the last example. Please note that the interrupt flag in this programme is used only as a "busy" flag, which the main programme can check before sending new data to PIO over DMA to keep the required "reset" timeout of the LED. It does not stop the main programme from doing something else. In this programme this flag does not even raise a CPU interrupt. I used the while loop only to show how we can use PIO interrupt bits to synchronise the CPU programme with the PIO one. This is just a trivial example not meant to use in any "production" code.
In real-life programme you could simply raise a CPU interrupt when the IRQ flag is set, which handler would send the data from RAM to PIO automatically. Then the main programme would write the required pattern data to the RAM and go on doing other stuff.
In a world of circuits and wires,
The Pico Pio shines with its own fires.
A small board with power to spare,
It's a true delight for those who dare.
With GPIO pins that are easy to use,
The Pico Pio is quite the muse.
From sensors to motors, it does it all,
And programmers can have a ball.
The possibilities are endless,
From robotics to home automation, it's relentless.
The Pico Pio is a gift to behold,
With its power and capabilities untold.
So let us all hail the Pico Pio,
A true gem for programmers in the know.
With its Raspberry Pi roots,
It's a small board that bears lots of fruits.
I would expect many different things in the comments under this kind of videos, but not THIS :-O That's a great poem. Thanks for sharing!
ChatGPT has entered the building
Excellent video and great explanation. I had heard something special about the Pi Picos PIOs, but I had no idea.
Just some feedback. I get the impression that code A thru D will all have slightly different waveforms(?), in that some of the instructions (in code A) take a single cycle and the PIO presumably holds its previous value. Later when you explain about the "side" feature this appears to be a way to change the PIO value while at the same time executing an instruction. I am unfamiliar with the waveforms needed by the LED device, so I am unclear as to whether each bit needs to be immediately back to back or whether there can be a pause of a few cycles.
Super special, very intense - keep up with this interesting work, and yes I would also like to hear about DMA
Thank you! I'm planning more Pico videos including the DMA and PIO. Not only is it super interesting to me, but also I need the Pico in my Intel 80188 computer. So, more stuff is coming ;-)
Very informative. On first learning about the Pico, my thoughts were "just another microcontroller" but this shows it has a lot of power with the PIO than even the ESP32 might have.
Using the Pico for the 8088 project might be considered cheating though.
I also got very lost with the last several 8088 videos.
@Daniel Morin: Thank you! I'm really grateful for your comment regarding cheating.
I honestly asked myself the same question a few months ago before I decided to use the Pico.
Here is how I see it:
If I wanted to build a IBM PC compatible, I would probably try to use as many original components as possible. Let's assume I was even able to do it and, for example used the original disk controller. And then what? What do I connect to it? It's not easy to find floppy disk drives (and floppies themselves) or even old IDE hard disks these days. I would then need to emulate those using modern electronics anyway and try to connect via the old protocol. Or, let's think about the keyboard. I could use the keyboard controller chip, but, again, what do I connect to it? It's not easy to find keyboards still "talking" PS/2. On the other hand, even the hard drive itself has a processor, so is it already cheating, because I use something having a CPU inside?
The line is very thin - my approach is just to move it slightly. Instead of trying hard and finding expensive vintage chips and then trying hard and connecting a modern microcontroller emulating a drive to it - I'd rather use a microcontroller simply emulating the hard drive controller, but still talking to the main CPU on the data bus like the original disk controller would (using ISA). The only difference is that I won't use the 40pin IDE ribbon, but from the point of view of the software - there is no difference. My aim is to keep some software compatibility with the original BIOS, but I already resigned from some hardware compatibility using the built-in interrupt controller, DMA and timers inside the 80C188. Also, I would like to design this computer for others to be able to build is easily (no SMD if possible) and using chips relatively easy to buy. Fortunately 80C188s are still in good supply (in contrast to 80C88 for example).
So, that's my justification for using the Pico as a I/O controller in this computer. I'm not expecting everyone to agree with me. Again - it depends on what you want to achieve.
One more thing: I'm slightly worried about your last paragraph, that you got lost with several of my videos. Would you be so kind to elaborate on why do you think that would be? If you'd rather like sending me an email, please find it in the "about" section of this channel.
Thank you again for your comment.
@@SladorSoft Thanks for taking the time and interest in my coment.
I probably started getting lost when you started mixing C++ with assembly. I'm still figuring out in my head all the ins and outs with C++. My mind has done better with top-down programming of yesteryear and the thinking linearly than object-oriented programming and abstracts in general.
I did design my EE undergrad senior design project using the 8088 on a breadboard (I still have that breadboard though wires have gotten corroded and fell out in places). The code part worked well, only had issues with the phone line interface where I was trying to read touch tones in hi-Z using an RS custom chip. Hi-z so I would not cause my circuit to cause an off-hook condition. I lost my documentation including schematic and code so I was thinking I might want to revive the project, at least the controller part, even see if the EPROM retained all the original bytes.
Maybe someday I'll get a read of the 80MB MFM drive I still have and get the documentation back :)
I didn't realize the 80c88 was so hard to get these days. I should have gotten it months ago.
My skill level in this area probably can be explained in my following Ben Eater's projects, having bought all of the kits and expanded on the 8-bit processor/computer on a breadboard. None of his 4 bit opcode rubbish, mine is 8 bit opcode with 8 bit operand, 8 bit address line so 256 byte address space instead of his 16 bit RAM.
Thanks for the informative video! Your explanation and demo of the side effect of side-set at the end was helpfull. Thanks again.
awesome explanation, thx!
one question though... your code works for one LED, but for the next LED you have again two additional instructions on the top to pull in the next 32bits into the shift register and throw away 8 bits. so every 24bits sent out to the LEDs you would get additional 800us low signal - or did I miss something?
This is acctually a similar approach that has PSOC microcontrollers (previously "Cypress Semiconductors", meanwhile "Infineon") implemented for more than a decade. So called UDB, i.e. Universal Digital Blocks, that can be programmed using Verilog (or use the graphical interface to do so). Very helpfull for just such tiny problems, that would otherwise intensively occupy the CPU.
In this video shown processor kind of programming, not FPGA kind. FPGA kind can be more powerful.
That you, that was awesome 👍👍
S U P E R interesting video. I'm getting my teeth in the PIO for a full duplex SPI interface, and this was a really good and detailed introduction. The only possible thing I would recommend in your future videos would be some sort of logic analyzer captures, that way we could've seen the flaws of the first design for instance.
Thanks for sharing!
Thank you for your kind comment. I'm glad you found it useful in any way. I love your idea of using a logic analyser. I'll try to employ in future videos. Thank you!
Excelent! u can do more videos, of use of the PIO assembler instructions? like micropython sintax?
Hi, thank you! Yes, there will be more videos about the PIO, because I need it for my Intel computer. I have plans for two more videos involving programming the PIO at the moment.
Unfortunately I have no plans to use Python at all. I have no experience with (nor interest in) it.
You know you can remove two NOPs if you add delay to mov x, y on line 8, and irq clear 0 which you should also move from line 33 to line 24, because there is no reason the CPU has to wait until the reset is complete to load the new data right?
Ah well, that is all academic I suppose.
@frozen_dude - fair point! I could probably make a few more improvements, but as you guessed, it was mainly for explanatory purpose rather than "production ready" code. I would only recommend it for people who would like to start tinkering as a "hello world" example, which they can take and play with. Thanks!
Excellent flic. Thank you for sharing.
Hello, is possible use two diffrent PIO programs? For example RGB and tone generator.
Yes, this and even more is possible. One PIO device has 4 state machines, each of them can run a separate programme and each of them has separate GPIO pin binding, clock divisors, etc. The only limitation is that all 4 state machines (programmes) share the same programme memory, which is only 32-instruction long. In other words, all (up to) four of your programmes need to fit together in this 32-instruction long space.
On top of that, there are two completely independent PIOs on RP2040 chip, so you can theoretically run up to 8 short programmes. The example in the video was as simple as possible and was using only one state machine of one PIO. In one of the future videos I'll be showing an example of multiple programmes running on the same PIO.
@@SladorSoft Ohh, thanks. I'm very interested, but i cant find any easy tutorial. i'm trying to make my own PIO program for WS2812, only works one pixel, i think is a problem with timings, you know any way to send the data to others pixels?
Sorry for my english, i speak spanish.
very very nice overview of ways to program neopixel data as output.
what do you think about the possibility of reading and decoding incoming neopixel data from a pixel strip? would that be possible somehow?
Hi thanks! Yes - this is definitely possible. It would be quite unusual though. Why would you want to do that? The only idea coming to my mind is to emulate these neopixels by the Pico. You can imagine an RGB led driven from the Pico via PWM and receiving data in the WS2812 format. So, yes, I guess just to prove the point you could do that :-)
@@SladorSoft My use case is a kinetic light installation made of hundreds of SK6812 pixels and I would love to use some pixels (distributed across the pixel data stream) to store position data in them like with a moving head fixture. the pico would need to get them and drive stepper motors based on the numbers.
Another great thing of the neopixel format is that you just need two wires and if you take a nicely isolated coax cable 20m distances can easily be realised.
@@CineMuck84 That's interesting and very bespoke. The Pico is certainly able to receive this protocol and even relay the data on down the line as the neopixels do. Good luck with your idea!
25:17 Hmmm one question I have about this. The data sheet shows each bit to be 1250 ns for each bit. And a 1 is 800 ns high signal followed by 450 ns low signal. But dividing 1.25us / 3 gives 417 ns for each third of 1.25 us (or 1250 ns). So this is not in line with datasheet. So this 1/3 abstraction is allowed by the protocol even though it's outside of the protocol? Would it not be better to have a clock step of 50 ns per clock and modify the pio code to have wait sections in multiples of 50 ns clock steps? That way you can generate high/low pulses of 400, 800, 450, 850 ns? After reading the datasheet, looks like each if the 4 signals mentioned can vary ±150ns. So it appears the protocol is quite lax.
Subbed btw. Thanks for this great explanation of PIO.
I have a self-designed KB PCB coming in from china with the rp2040 and 68 x sk6812-mini-e per key RGB backlights. Since NeoPixel PIO already exists, it does something similar to this code, but has a smaller clock divider from looking at the source code and uses delays of varying length on all instructions. Don't think I will need to do any PIO in my case, but good to know for sure since it seems to be a big USP for rp2040. Will use KMK firmware for this board. Perhaps I can switch from CPU impl of the protocol to the PIO impl if I change KMK for the rp2040.... actually, they already did this in source code with conditional compilation based on RP2040 being used or not.
Hi there! Thanks for your comment (and for the sub). Yes, I tried to keep it simple just for the sake of this example. As you noticed I kept the timings well within the allowed tolerance. Please bear in mind it was a simple code explaining how PIO works rather than "the best neo pixel implementation in the world" ;-) You're right that making the clock tick 50ns would allow for more precise timing, but again... since it works and within allowed margin, why not?
Good luck with your PCB - share your updates when it's ready. This seems like a good use of PIO, unless the CPU doesn't have much else to do and you take care of interrupts and other stuff going in the way of precise timing.
Take care! Thank you
@@SladorSoft I have received my PCB at the start of this week. It looks great, so impressed with the look of it. Anyhow, I took time to verify from the wires of a cut and stripped USB cable, that the connections were arriving at the correct destinations on the PCB, then plugged it in and dropped my previously compiled CircuitPython bin on there and it all works. Put in some KMK in there and tweaked it for my mystery rotary encoder adaptation and now that works too. I do know that at least one of my sk6812-mini-e LEDs works "out of the box", as the CircuitPython firmware build is flashing the status LED different colours for certain situations. The kb matrix works at least for 1 key. And the Freq of the RP2040 is 125 Hz default. So with all of the types of hardware partially confirmed working, its going good so far. I did have a mistake that I made though. I got the ribbon connector pins for USB (+5 other unused pins for my implementation) mirror mismatched. But one quick cable replacement and it's good. Overall very happy with the enjoyable mix of hardware and software development to produce a functional item for myself. Learnt some new things along the way too. I expect to have a fully functional kb at the end of the week or mid next week.
@@SladorSoft I understand that most of your audience is not made by professionals, and keeping things simple helps them understanding and coming... But one important reason the PIO was created is to achieve precise and stable timings. Neglecting the timings, in general, defeats the whole purpose of the PIO, and might lead to, "wow! I've got it to work!", or in your case, "yes it's wrong, but it works!" - and it might work sometimes, under certain conditions. Might not work if conditions, or components are changed, and it will be a nightmare to troubleshoot such timing problems. That's on one hand. On the other hand, why teach people to be sloppy from the get-go?! Why not try to teach them to be thoughtful and apply the best practices and rules? Maybe even to read and obey the datasheet?! There is enough garbage (99,999%) on the internet to call for yet another one!
@@lukamarin9622 I think anybody getting this deep into Pico SDK already understands the importance of timings and can adjust stuff themselves or maybe they've already seen some other videos and one of those already explains it. This video does not exist in the vacuum and coming to this video I don't want someone explaining why timings are important - I want to learn how PIO works and I got what I wanted. Even then, if someone's way to live is to copy paste everything without a deeper thought, I'm bitter enough to just let them learn the hard way instead of being hand held every time.
The beaglebone had something similar.
Oh, thanks! I wasn't aware of his channel. But I cannot find anywhere where he programmes the PIO on the Pico? Anyway I need this for my Intel 8088 computer hence this video :-)
@@SladorSoft the beaglebone is a SBC that had something called PRUs that are basically advanced PIOs.
@Starbuck and Boomer got it! Thanks!
Thank you for this video. I'm trying to animate a 24 LED ring.
@Joshua McCunn: have you managed to do it yet? You can always use my source code from the video as a starting point and change a few things (like "LED_COUNT" and "WS2812_PIN" macros etc.)
Dear sir. Did you realized to write a Manchester coding interface using PIO? This code alows sendind data by ac Channel like Transformers, and allows pre equalizations, and filtering. Don't you?
Hi @JorgeSilva-em8pf! Yes, I saw someone implementing a Manchester code and built a working Ethernet controller. There is plenty of possibilities of using PIO for communication and if I wanted to try them out it would take hundreds of videos ;-) But in the next video I'm going to show how to programme the Pico W to talk to the Internet via Wi-Fi. I hope you find it interesting as well.
Great video. Most people use the pico to show novice level python. I like how you used c++ and op codes. Thank you. You are a professional programmer I suspect. I majored in search over 2 decades ago and graduated top of my class but never wanted to move away to work so I just started programming again about 4 years ago and noticed all these pseudocode-like languages dominating the sciences and it saddened me.
Yes, different (very) high-level languages dominated lots of areas, but fortunately, languages like C++ are still important and widely used. I've been working in C++ for over 20 years and, for example, don't know Python at all. So C/C++ was an obvious choice for me ;-) Thank you!
@@SladorSoftc++ is the backbone of the world even though it's not as popular but I attribute that to the comp Sci being a joke at most universities.
@@SladorSoftc++ should be the only language computer scientists learn in school. They may never use it again but they'll be better critical thinkers and problem solvers.
Very nice video, THX.
The tone library is using PIO-0. How can you modify its code to use PIO-1 instead? I have 2 libraries conflicting, that both use PIO-0.
@Love made in Japan: Both PIO blocks are completely identical and can be swapped with one another easily. You should be able to do it by replacing any references to "pio0" pointer defined by the SDK to "pio1" and, if you use the interrupts raised by the PIO, you also need to replace "PIO0_IRQ_X" with "PIO1_IRQ_X".
@@SladorSoft Thanks, found out it wan't using PIO, but I made a coding mistake...
Great!
Reminds me of Amiga Copperlists.
Thanks
Start a Patreon!
Thank for the idea, but the channel is still quite small and I don't believe that there are many people wanting to support me that way. And also, I cannot promise them regular videos as this is my after-hours project which I (unfortunately) cannot spare too much time to. Cheers!
@@SladorSoft yes it’s small, but you may be surprised how many people would support you. Also, on Patreon you can use a model where subscribers only pay per video and not per month.
Very good video, detailed video. But we all know videos of this quality are rare to find. The authors of excellent content don't seem to keep then coming: However, the poor videos keep on coming.
Thank you very much for your kind words. I'm not going anywhere yet ;-) I may not have a lot of spare time to produce those, but I'm still going to do that. Thanks!
none of the programs looks right:
(a) written as nothing else but mov pins takes any cycles
(b) written as pull and out don't take cycles
(c) written as pull and out after .wrap_target don't take cycles
Hi there. I'm assuming that by saying "does not look right" you mean that there will be an additional delay inserted in the data between the separate pixels introduced by the first two instructions (pull and out)? Yes - that's would be correct, but - as seen at the end of the video - perfectly acceptable in practice by the LEDs. Apparently, they accept even up to a few microseconds between pixels. Your first comment (a) is not right as in fact I strictly rely on the time taken by each instruction. Have a look at the programme "B" after the "next_bit" label, where all the timing is based on this.
All of this aside, the video was meant as an introduction to the PIO, in which the neo-pixels were thought off only as a mere visual effect of a PIO programme. I never stated that there are instantaneous PIO instructions, so, hopefully the video may still serve as a good starting point in understanding and using the PIO for other viewers.
Thank you for taking time to watch and comment.
@@SladorSoft well, the fact that neo-pixel tolerates such huge (especially for (a)) deviations is not a good justification regarding acceptance in practice - apparently your neo-pixel samples first intervals and adjusts expectations on the fly. However it's not in specs and can be different form different providers or even from different batch.
to be continued
@@SladorSoft Comment (a) is completely right - you set cycle time to 1.25/3 us - every pixel will be delayed by 2 cycles (lines 4,5) with low level, then for every bit - additional low for 2 cycles (lines 8,9), after bit 1 one cycle (line 13), at the end of bit one cycle (line 20) - as I said, every additional instruction besides mov is adding out of specs delay.
to be continued
@@SladorSoft And the same with (b) and (c) - you put cycle time in the way that you just can't fit anything between GPIO driving functions (mov or side) - "Have a look at the programme "B" after the "next_bit"" - yes, exactly - line 9 is not accounted for.
the end (youtube doesn't allow me to post long comments for some reason 💩)
Hi. Thank you again for your thorough reply (I had never had any problems typing longer comments - maybe it's the mobile app issue?).
You are right that I introduced a delay between pixels, but it is hugely insignificant to the 50us "reset" delay (I know it's not excuse). I'm not certain which line you mean by "line 9", because it looks like it is the "out x, 1" which execution time is crucial in timing during sending the bit.
But this discussion is completely off-topic which I was trying to express in the last part of my original comment. The goal of the video was to introduce the PIO for beginners and my aim in these programmes was to show as much of the PIO assembler as possible in a short and easy to understand programme. The focus was on using different ways of GPIO manipulation, sideset, wait cycles and others. I could not show and explain these if I used for example the programme included in the Pico SDK documentation. It is a very short programme doing exactly that. But how many features can you show in a few-instructions-long programme? That's also the reason why I wrote four of them - just to show different features and approaches to programming the PIO.
I too always stick to the specification and I would understand your concerns if it was production code. But it was only an example, in which the LEDs were mostly irrelevant. If it was a "How to drive neo-pixels" video, I'd be the first to point out the deficiencies of the code.
Again, thanks for your comments and your thorough analyse. Cheers!