That was a really useful intro to PIO. When I saw the Pico PIO was programmed in assembly I thought that would be too complicated to get into and looked no further. But now you have done the research I cant wait to have a play :-). I do like all this micropython code as well.
Thanks Ralph. Like you I've been playing with the Programable PIO and watched David's Tutorials on the programable PIO, I've managed to use a BME280 and a LCD display using I2C to display temperature etc, While the PIO output's parallel data On the PIO Pins, This is a lot different than programming Arduino and Stm32 Micro controllers. Keep up the good work.
Wow, "the only one" you say, Kevin. Well, I can't believe that's true but it's nice to know you understood my video. Thanks for the feedback, appreciated.
@@RalphBacon I would LOVE to see if you would make a detailed and I mean detailed video on how to write a device driver in C or MicroPython for the Pico. That would be so helpful. Device driver dev they say should use the PIO but I have no idea how to do such.
Take away? Ooh, nearly Saturday, definitely a take away. Oh. I guess you were not talking about your local Indian Restaurant then. But this PICO is fun too!
Thanks @Ralph S Bacon for the video. You have sparked my interest. I’ve known about PIO. The way you explain it was so easy I’ll go and play with it myself.
These 8 PIO state machines are game changing for hobbyists. I don't think many people understand how useful they are. Offloading of up to 8 custom peripheral processes, leaving the two main cores which can perform maths and logic totally free from having to interfere with their operation is such a simple idea, I can't think of why AVR didn't adopt this years ago. The fact these 8 state machines can also achieve timing accuracy not possible on the main cores that lose available clock cycles sometimes due to overheads, will make bit banging so much easier and more efficient. Thanks for this video .... it's good to see more people adopting micropython rather than whining about it because they're fixated on C/C++ due to psychological Arduino imprinting.
In my case it's not "Arduino imprinting". You talk about clock cycles and overheads. You won't like micro-python if you want low overheads. Even simple python instructions, to interpret and then execute and return back up the stack takes 100s of clock cycles. I mean things like a = b + c takes 100s of cycles. If you do something python-esk like append to filtered lists together that's going to take about 2 milliseconds per list entry. From python, I highly doubt you would be able to bit bang anything. It's probably the main driving reason for having hardware statemachines in the first place, if they were targetting MP. Look I use Python in my day job on "non-commodity" hardware. We are talking blade racks with 192 x 4Ghz Zeon cores and 4 terrabytes of RAM and python is still too slow. Using it on a MCU at 130Mhz is lunacy. It will work for "play school" style stuff where timing and performance are not a consideration and response times of milliseconds is acceptible. Once you move to hardware control, unless you hare using underlying native library code you will not be able to achieve the timing. Try bit banging a NeoPixel strip without using the NeoPixel native routines buried under the library, but just using the Python GPIO libs.
I think you'll find there are TWO groups of FOUR State machines (rather than eight - the grouping is critical), and each group has 32 WORDS (64 bytes) of memory.
Quite likely. But this was an academic exercise really. I wonder how many Real World uses these pins have found so far (especially with relatively inexperienced programmers of the PICO)?
@@RalphBacon There is so much bad/misguided information being published on the Pico. And few have the integrity to say: My video is quite likely wrong. I expect that when accurate tutorials become available, the inexperienced will have an opportunity to learn how to use the Pico
You could also use the Output Shift Register to output a repeating 0110 (or 1001) pattern to the two pins. This would also afford you the ability to use the 16.8 clock prescaler to have some control of the frequency. There's lots of tricks you can play with PIO. 😉
I'm going to have to re-read this a few times, Neil, and Google what you are telling me because I don't know how to do this (yes) - but I'm keen to know how to do this, so thanks for the heads up. 😉
This is probably discussed earlier but i just have to comment on this. With pico setup, the speaker cone will never go negative. Please check your reference points. You are measuring the 2 output pins separately, out to ground but what do the speaker see. You put 1 side of the peaker to one pin and the other side, of the speaker, to another pin. The speaker "see" the difference between the 2 output pins. There is nothing to pull the speaker negative.
There is no negative voltage, for sure, but the speaker cone could never be in a certain position if the poles were not reversed - thus _giving the effect_ of a negative voltage. As my video stated.
@@RalphBacon That is not right. You are not reversing anything and you don't need to. Like me, you might need to read up on simple electronics. You are simply moving you ground point, therefore bigger amplitude. "giving the effect of negative voltage" is nonsense.Put your scope across the speaker, check your ground level and watch how the signal goes negative -or not.
@@flemmingchristiansen2462 'giving the effect of negative voltage' does not mean there is negative voltage. If one was driving a speaker with +3v to -3v square wave what would you get. One could say this would "in effect" produce the same results as that of the video.
Right on! But it's _never_ too late to learn new stuff, even my mum learned how to use the Internet using a tablet in her 90s. If she can do it, anyone can!
Nicely done Ralph. Looking forward to a possible follow-up with that neopixel stick. I've used PIO on my Pico from a C++ program. Not recommended. I could not have worked out how to do it, and even after cutting and pasting all of the various header and helper (?) files, I still struggle to see what's going on!
Note that you could have done your two-pin output with two set pins (using .set()), or two side-set pins (using .side()). The side-set pins tend to be useful for control pins that you are setting to a known, constant value; and the input/output pins can transfer data to/from the microcontroller memory. For example, the side-set pins might be for handshaking, clock, data direction, etc. The set and output pins can be the same pin(s). That's handy when you need to mix constant and data-driven values on the same pin (like for NeoPixels...). The PIO support in MicroPython is pretty darn good. Documentation and examples could use a little fleshing out. Until then, it may help to take a look at the C/C++ documentation and examples. I was surprised how easy it was to come up with my own NeoPixel implementation via PIO.
If you got the NeoPixels up and running then you already are an expert regarding PIO capabilities, Mark! I shall look into what you said although at the moment you've just confused.com me!
@@RalphBacon I just pushed a couple of examples of things I was experimenting with up to GitHub: github.com/mday64/pio_experiments It's got a NeoPixel implementation (works differently from the official Raspberry Pi examples), and an 8-bit parallel output port with clock. Maybe it will help, or maybe it will just add to the confusion.
You've been busy, Mark! Given the comment from @Andrew Toogood above, I just wonder how many PICOlites will ever reach the standard of code you just published, or will they just download yours and say "Look what I did!" without understanding more than a line or two?
Spot on! Ironically, there was no reason for them to be on the 10x setting, I had just left them in that setting from another project. Anyway, I took the opportunity to calibrate both the probes, now very square indeed! You've earned a Gold Star!
On a slightly less joking note. Have you played anything with eTPU or the old TPU? It's remarkably similar in that you can precisely control pin toggling but it also has some additional branching and maths capabilities. Fun little marvels to play with :)
Your definition of "tolerable" is slightly different to mine! 🤣😂 Terrible, piercing sound and I've got too many in my workshop now (in finished projects). Seemed like a good idea at the time, of course...
Great video Ralph!!! thanks a lot, video well made and you have given so many information on the table that makes life with Pico easier. As for the Blinking NeoPixel board that project I would also be happy to see how it is done. if that is OK by you, Maybe next week :) - Keep it up and thank you so much.
Glad you enjoyed it! The NeoPixel code is available from the Raspberry Pi GitHub (link in the video description) but it's not simple - hence why I abandoned talking it through. But others have done it, see if anyone in these comments has posted something to GitHub.
By forming a bridge output then you and expect to get 4 x the power on the speaker. e.g 2.5V in to 10 ohms, power = V2/R (2.5)2 / 10 = 0.625W (5)2 / 10 = 2.5W 2.5W/0.625W = 4 Sp one extra pin and 4 times the power out.
Well, I'm not sure this is a true bridge output, as there is no actual negative voltage swing. And the correlation between power out and perceived volume is not linear; I can remember in my dim and distant younger days when I was a DJ (yes, really) being pretty disappointed at the increase in volume from a 100W amp from a 50W amp. To get double the volume (10dB) from the same set of speakers you need to increase power by ten! Yikes!
Nice video Ralph, are you thinking of using PIO with Interrupts for you fridge door project - would be very interested in a video describing how to enable the state machine from an interrupt request
"PIO with Interrupts for you fridge door project" - are you crazy, Stuart! Oh, you're being serious. I hadn't thought of that approach but now that you've mentioned it I will have to see what advantage that might bring.
Technically the PIO runs without intervention from the CPU core in the MCU. If you deal with other types of MCU you might find that your PIO isn't really special at all. Consider the approach taken on almost all MCUs today (if they have it available) for NeoPixel arrays.... DMA. You generate a bit pattern which creates the PWM square wave on the output pin.... call Transmit DMA and send the CPU to sleep. If the DMA is set to loop the buffer, you have nothing more to do and could potentially halt the CPU. Beyond DMA advanced MCUs like the STM32 et. al. have many, many concurrently running systems inside them, handling IO without the CPU intervention. I believe on something like the STM32F411 (Black Pill board), the MCU has about 16 different clocks, running 16 different parts of the MCU asynchronously on one of several buses. Usually those components are used for specific standard peripherals, like hardware UART, SPI, I2c etc, so the protocol aspects are very often taken care of entirely by the peripheral in hardware and the CPU is only "woken" up to process data that has arrived or when it's needed to make a decision. Stretched out to it's potential, you can have a DMA transfer reading audio off an SDCard triggering a DMA transfer to send that data over I2S for a DAC and the CPU would be asleep or maybe just waiting on UI button interupts to change track. Potentially even further with the FPU DSP extensions, as you can send floating point calculations to the FPU and off load that processing and receive an interrupt when it's done. So you could even potentially have an IIR filter or two running on the audio stream and the CPU would STILL be idle a lot of the time. Although, when you get that level of power you might find the CPU is entirely busy answering real time interrupts to orchestrate everything. The PIOs certainly sound interesting to play with and I'm sure some of the bus hardware in other MCUs could be used that way if you wanted to get down into the hardware control registers and start messing with their internal configs.
@@RalphBacon Having just done it with DMA->PWM on the STM and finding an even better way with SPI to try yet, I expect the greatest advantage of the PIO processors will be in converting the "bits" to sequences of 100 and 110 at 3 times the frequency. ;)
Hey Ralph, I can't unhear it anymore ... no, not the actual audio of it, but the name you gave it: the Pizza-electric buzzer ... I think the guy of that effect had his name pronounced like pee-a-tzo, no? Don't know whether he was somehow linked to that crooked tower or loved to eat some Italian circular bread with tomatoes smashed on top, but I don't think he deserves being turned into such a dish ... On a more useful note: I think you can add an additional command doing nothing (useful) with extra wait-states to get lower frequency. And I have a little worry: if you have a 4ohm speaker, is driving it directly from a gpio not risking over-current on that gpio (same for running between 2 gpio pins)?
You say tomayto, I say tomahto... Google says I should say pee-ay-zo which sounds very British English. I'm trying to say Peezo! I don't think it's a name: French physicists Jacques and Pierre Curie discovered piezoelectricity in 1880. And possibly the pizza too, with peperoni, of course.
@@RalphBacon Well, I would actually say "Tomaat" as I'm not a native English speaker, but since the term piezo is derived from (ancient) Greek, perhaps someone speaking Greek in your audience (there's bound to be someone, right?), could tell us how it would sound in Greek and enlighten us both ;-) They also have great tomatoes in Greece, right? So maybe we should also ask them to clear up the tomayto / tomahto mess ;-)
I haven't got plans to look at these; the question for me (and my viewers) is: what are the advantages of these chips that makes them more suitable than others that we already have?
@@RalphBacon Hello Ralph, you do not find on TH-cam too many video’s on how to program this chip’s. UDPI(One Pin Programming) seems to be the way Microchip / Atmel are going. Explained by you will be easy to understand 👍👌
My first experience with the Pico was managing to get a PicoW (hens teeth). I ran a very quick MQTT subscribe and it worked. Then I did "Blinky", couldn't be bothered to google the right delay function so did this instead. Fully expecting (having just come from STM32 world) for 1 million to not be enough iterations to produce a sensible blinky. In python I used this for delay: for( i in range(0,1000000)): pass The LED had about 1 Hz blink frequency. That's only 2 million iterations per second. On a 130Mhz core. Wow. I thought Arduino framework was wasteful. Circuit/Micro python is fiercely slow.
It's all down to interpreted vs compiled code, I guess. If Arduino had used μPython on the original Arduino it would never have found the success it has had, far too slow!
Interesting! I didn’t know pushing an pulling pins for a sounder made such a difference. I think you can do a live-set-able number of delay cycles (I’ve not checked this but I hope you get the idea) - this uses side set for both bits so the pins have to be adjacent. I’ve also missed out the wrap target and wrap labels because I think the assembler assumes these if they are the first and last instructions: @rp2.asm_pio(sideset_init = (rp2.PIO.OUT_HIGH, rp2.PIO.OUT_LOW)) def beep(): mov(x, y) label(“loop1”) jmp(x_dec, “loop1”) .side(0b01) mov(x, y) label(“loop2”) jmp(x_dec, “loop2”) .side(0b10) Delays are caused by looping round and decrementing X, and when X gets to zero the code drops through. The minimum delay is zero, so the the minimum clock cycles for the whole lot is 4, or up to 2^32+2 if you set Y as 0xFFFF. This should give you pretty good pitch control if you use a fast PIO clock! You would set the number of wait cycles by setting Y in your Python WHILE loop using: sm.put(number_of_wait_cycles) sm.exec(“pull()”) sm.exec(“mov(y, osr)”)
A nice example, Mr Weston, (I'll call you Nick) and shows how tight loops can be implemented in the PIO arena as well as passing values to the PIO code. Cool stuff.
Interesting approach to push/pull the speaker. I still can't figure out what the reference voltage would be. I mean normally you would see -3V +3V but thats only what the speaker sees. The MCU still sees 0-3V. I suppose what that is, is a differential pair and there is no static "reference". I hate analogue electronics :)
There's no magic, nor smoke and mirrors. It's still only VCC and GND. The "magic" (even though I said there was none) is in having the speaker cone move forward with the positive pulse in the normal way. BUT, when the polarity is _reversed_ it's still only VCC and GND but the speaker cone is now in a starting position that could only be achieved (normally) with a +VCC / -VCC and it moves the full distance backwards thus giving a much bigger sound wave than by normal means. 😲
RP2040: IOVDD is Power supply for digital GPIOs, nominal voltage 1.8V to 3.3V Let's say we have 3.3V from the Pico board here. In IO output Mode you can switch the RP2040 IO Port pins between physical IOVDD pin (digital High logic state.) and its physical GND pin. (digital Low logic state). Let's say you have two Ports in output Mode and call them A and B. if you switch A to IOVDD and B to GND and after a 2 second waiting time switch A to GND and B to IOVDD and after waiting two seconds repeat then a multimeter connected beween those two IOs will see it's probes are alternatiting connection between IOVDD and GND. because the switching transistors in the ports are told by the software to do that. So the Multimeter will show alternating between: 3V and -3V if you measure any port to GND when it is LOW the port itself is a GND, so you measure GND to GND which shows 0V if you measure any port to GND when it is High, you measure GND to IOVDD which should be around 3.3V GPIO Power supply voltage on the Pico board.
@@RalphBacon Thank You for the link. I have one on the way. 6x6 configuration is going to make the 8266 boards I bought a lot easier to work with. In a crazy world a sane man such as yourself is much missed. So glad you are back.
Errr....[blood boiling] TH-cam are saying 'Nobody clicks the bell anymore', well of course not, TH-cam stopped email notifications months ago so whats the point? Yeah, I know it works for some users of certain browsers and mobile devices but for the majority of youtube users, nah. I have to use a third party to inform me of any new uploads otherwise I'd miss everything. It doesn't work for 'live' events though and if there isn't a 'reminder' set by the creator then I miss those too. Just my small rant, sorry....great vid, thanks.[/blood boiling]
What did Elton John say? Don't Shoot Me I'm only the Piano Player great album! But seriously, I've never really understood the "subscribe but also do something else to get notifications" anyway.
Hmm, I seem to remember that Ticking was on Caribou not Don't Shoot Me, but as this was a gazillion years ago I could be wrong. I liked Teacher I Need You as I liked my Spanish Teacher of the time! Jeez, that's unsettling, she would be nearly 80 now... if she's still here. Thanks Norman, now I feel really depressed. 😢 And old.
@@RalphBacon So, I had to check and Ticking was indeed on Caribou. My mistke and as punishment, I will be listening to the album on repeat for at least a day! I always thought the Teacher... was a tad risque, even as a teenager, but then again, I know what you are saying! Yes, I'm old too. 61 back in April. Still, I'd hate to be a kid these days the way we humans are buggering everything up. Take care. Cheers, Norm.
Damn do I now have to buy more stuff, CPC have now posted the extra 2 picos :-) I guess this is for the fridge alarm, I guess I will have to buy a fridge as well:-)
This has been my favorite channel for a couple of years now, BUT I have to say I am losing interest, I can't think of anything I would use A Pico for that and Atmel or STM or ESP would not do better. And for me Micro python is pointless why learn a new language so my solutions can go slower and have less memory... Went to the end to see if you had an update in the bin sensor but alas :(
Hmm, I knew this would be a potential issue for my viewers, Andrew. After all, what _can_ the PICO do that the others cannot (and more quickly too)? I'm only covering the PICO because it's out there, in your face, inescapable, by virtue of being launched by Raspberry Pi. If another (much smaller) manufacturer had launched this it would not have had so much traction. I'm not sure MicroPython is pointless (harsh, Andrew, harsh) as beginners probably pick up the rudiments quite quickly (then get lost in spaghetti code). And no compilation stage leads to faster development time of that blinking LED, as you saw! But don't give up! And don't leave! My ATMega328P bin lid monitor is (slowly) coming along, talking using its nRF24L01 to a dumb receiver (at this stage), I have my fridge door alarm to complete albeit possibly with the PICO (maybe, I'm having doubts now) and I have my... oh, you'll just have to tune in and find out. (Remember, I'm an Arduinite at heart but don't tell anyone else).
Sorry, but I don't see how you get your claimed 'negative pulse'. A GPIO can only switch between OV and Vcc, so the maximum possible offset is surely only the same as The Vcc value, so with a Vcc of 3.3V its impossible to obtain the quoted 6.6V... In terms of Forward and Backward movement of a loudspeaker cone it makes sense but, as explained, it's incredibly misleading.
With this ‘trick’ you can double the voltage, but you need some kind of external reservoir. In this case the reservoir is a mechanical item. The coil movement is the double of the gnd-pin config. You can do the same with a little circuit with a capacitor as reservoir. The cap will charge to 2x the pin voltage. Handy if e.g. you want to use a led with a Vf greater than 3V on that output pin.
@@hopje01 No capacitors were used in the given example. As, I mentioned, I can see how the Forward and Reverse action of the loudspeaker cone provides double the volume but, at no point is there ' double the voltage', as stated in the video, for the setup shown. That's what will mislead anyone who doesn't understand what's going on and it's compounded by the dual trace oscilloscope display not having a common baseline.
Life with David is a brilliant channel... Very clever fella, and really enjoyed his series on the Pico. I lost a whole Sunday to it infact...
Thanks for sharing!
That was a really useful intro to PIO. When I saw the Pico PIO was programmed in assembly I thought that would be too complicated to get into and looked no further. But now you have done the research I cant wait to have a play :-). I do like all this micropython code as well.
Glad you liked it! As I said, "Easier than you think!"
Thanks Ralph. Like you I've been playing with the Programable PIO and watched David's Tutorials on the programable PIO, I've managed to use a BME280 and a LCD display using I2C to display temperature etc, While the PIO output's parallel data On the PIO Pins, This is a lot different than programming Arduino and Stm32 Micro controllers. Keep up the good work.
I'm pretty sure I could write much of what the PIO does on the PICO for the Arduino (using non-Arduino speak) but it would be much harder work.
You, Ralph, are the only one that made PIO understandable. Thank you.
Wow, "the only one" you say, Kevin. Well, I can't believe that's true but it's nice to know you understood my video. Thanks for the feedback, appreciated.
@@RalphBacon most welcome and thank you Ralph!
@@RalphBacon I would LOVE to see if you would make a detailed and I mean detailed video on how to write a device driver in C or MicroPython for the Pico. That would be so helpful. Device driver dev they say should use the PIO but I have no idea how to do such.
Hi Ralph, there are always useful take-aways from your episodes, thanks for that. Cheers.
Take away? Ooh, nearly Saturday, definitely a take away. Oh. I guess you were not talking about your local Indian Restaurant then. But this PICO is fun too!
Nice to see a comprehensible introduction into otherwise inscrutable features.
Glad it was helpful!
Thanks @Ralph S Bacon for the video. You have sparked my interest. I’ve known about PIO. The way you explain it was so easy I’ll go and play with it myself.
Go play! Plenty of examples on the official Raspberry Pi GitHub (link in my video description).
These 8 PIO state machines are game changing for hobbyists.
I don't think many people understand how useful they are.
Offloading of up to 8 custom peripheral processes, leaving the two main cores which can perform maths and logic totally free from having to interfere with their operation is such a simple idea, I can't think of why AVR didn't adopt this years ago. The fact these 8 state machines can also achieve timing accuracy not possible on the main cores that lose available clock cycles sometimes due to overheads, will make bit banging so much easier and more efficient.
Thanks for this video .... it's good to see more people adopting micropython rather than whining about it because they're fixated on C/C++ due to psychological Arduino imprinting.
Certainly powerful, that's for sure. MicroPython or C++, choose whatever works for you, is what I say!
In my case it's not "Arduino imprinting". You talk about clock cycles and overheads. You won't like micro-python if you want low overheads. Even simple python instructions, to interpret and then execute and return back up the stack takes 100s of clock cycles. I mean things like a = b + c takes 100s of cycles.
If you do something python-esk like append to filtered lists together that's going to take about 2 milliseconds per list entry.
From python, I highly doubt you would be able to bit bang anything. It's probably the main driving reason for having hardware statemachines in the first place, if they were targetting MP.
Look I use Python in my day job on "non-commodity" hardware. We are talking blade racks with 192 x 4Ghz Zeon cores and 4 terrabytes of RAM and python is still too slow.
Using it on a MCU at 130Mhz is lunacy. It will work for "play school" style stuff where timing and performance are not a consideration and response times of milliseconds is acceptible.
Once you move to hardware control, unless you hare using underlying native library code you will not be able to achieve the timing.
Try bit banging a NeoPixel strip without using the NeoPixel native routines buried under the library, but just using the Python GPIO libs.
I think you'll find there are TWO groups of FOUR State machines (rather than eight - the grouping is critical), and each group has 32 WORDS (64 bytes) of memory.
Quite likely. But this was an academic exercise really. I wonder how many Real World uses these pins have found so far (especially with relatively inexperienced programmers of the PICO)?
@@RalphBacon There is so much bad/misguided information being published on the Pico. And few have the integrity to say: My video is quite likely wrong.
I expect that when accurate tutorials become available, the inexperienced will have an opportunity to learn how to use the Pico
You could also use the Output Shift Register to output a repeating 0110 (or 1001) pattern to the two pins.
This would also afford you the ability to use the 16.8 clock prescaler to have some control of the frequency.
There's lots of tricks you can play with PIO. 😉
I'm going to have to re-read this a few times, Neil, and Google what you are telling me because I don't know how to do this (yes) - but I'm keen to know how to do this, so thanks for the heads up. 😉
This is probably discussed earlier but i just have to comment on this.
With pico setup, the speaker cone will never go negative. Please check your reference points.
You are measuring the 2 output pins separately, out to ground but what do the speaker see. You put 1 side of the peaker to one pin and the other side, of the speaker, to another pin. The speaker "see" the difference between the 2 output pins. There is nothing to pull the speaker negative.
There is no negative voltage, for sure, but the speaker cone could never be in a certain position if the poles were not reversed - thus _giving the effect_ of a negative voltage. As my video stated.
@@RalphBacon That is not right. You are not reversing anything and you don't need to. Like me, you might need to read up on simple electronics. You are simply moving you ground point, therefore bigger amplitude. "giving the effect of negative voltage" is nonsense.Put your scope across the speaker, check your ground level and watch how the signal goes negative -or not.
@@flemmingchristiansen2462 'giving the effect of negative voltage' does not mean there is negative voltage. If one was driving a speaker with +3v to -3v square wave what would you get. One could say this would "in effect" produce the same results as that of the video.
Thanks - I ask in your other comments and you delivered. (I can pretend that it was my comment and not the other few thousand who ask the same think!)
Definitely you, Edward!
Hi, A very useful presentation, thank you for the time spent on this. Duncan
Glad it was helpful!
Thank you Sir.
Yes I find your vids useful.
I should have learned mc’s When I was a lad.
Remember. “Those who can control time, Control”
God bless.
Right on! But it's _never_ too late to learn new stuff, even my mum learned how to use the Internet using a tablet in her 90s. If she can do it, anyone can!
@@RalphBacon Indeed, Time to me is determined by my capacity to love ❤️
I’m learning so much.
❤️ Hz 0101 ❤️ Hz
Be a Resistor.
🥂
Nicely done Ralph. Looking forward to a possible follow-up with that neopixel stick.
I've used PIO on my Pico from a C++ program. Not recommended. I could not have worked out how to do it, and even after cutting and pasting all of the various header and helper (?) files, I still struggle to see what's going on!
For now, I'm sticking to putting the PIO code into MicroPython!
Note that you could have done your two-pin output with two set pins (using .set()), or two side-set pins (using .side()). The side-set pins tend to be useful for control pins that you are setting to a known, constant value; and the input/output pins can transfer data to/from the microcontroller memory. For example, the side-set pins might be for handshaking, clock, data direction, etc.
The set and output pins can be the same pin(s). That's handy when you need to mix constant and data-driven values on the same pin (like for NeoPixels...).
The PIO support in MicroPython is pretty darn good. Documentation and examples could use a little fleshing out. Until then, it may help to take a look at the C/C++ documentation and examples. I was surprised how easy it was to come up with my own NeoPixel implementation via PIO.
If you got the NeoPixels up and running then you already are an expert regarding PIO capabilities, Mark! I shall look into what you said although at the moment you've just confused.com me!
@@RalphBacon I just pushed a couple of examples of things I was experimenting with up to GitHub:
github.com/mday64/pio_experiments
It's got a NeoPixel implementation (works differently from the official Raspberry Pi examples), and an 8-bit parallel output port with clock. Maybe it will help, or maybe it will just add to the confusion.
You've been busy, Mark!
Given the comment from @Andrew Toogood above, I just wonder how many PICOlites will ever reach the standard of code you just published, or will they just download yours and say "Look what I did!" without understanding more than a line or two?
I think that ‘not very square’ wave on your scope is because you are using x10 probe and you haven’t adjusted the trimmer!
Spot on! Ironically, there was no reason for them to be on the 10x setting, I had just left them in that setting from another project. Anyway, I took the opportunity to calibrate both the probes, now very square indeed! You've earned a Gold Star!
Welcome back! :)
Yay, thank you!
On a slightly less joking note. Have you played anything with eTPU or the old TPU?
It's remarkably similar in that you can precisely control pin toggling but it also has some additional branching and maths capabilities. Fun little marvels to play with :)
Tip: To make breadboard buzzers tolerable, remove the label and stick a bit of blue-tac or putty in the hole.
Your definition of "tolerable" is slightly different to mine! 🤣😂 Terrible, piercing sound and I've got too many in my workshop now (in finished projects). Seemed like a good idea at the time, of course...
Hi Ralph, keep going ! your beginning to peak my interest, I'm probally not alone either....cheers.
Squeak :-)
@@fredflintstone1 Squeak Freddy !
It is getting interesting, this PICO thing. Early days yet.
Great video Ralph!!! thanks a lot, video well made and you have given so many information on the table that makes life with Pico easier. As for the Blinking NeoPixel board that project I would also be happy to see how it is done. if that is OK by you, Maybe next week :) - Keep it up and thank you so much.
Glad you enjoyed it! The NeoPixel code is available from the Raspberry Pi GitHub (link in the video description) but it's not simple - hence why I abandoned talking it through. But others have done it, see if anyone in these comments has posted something to GitHub.
If you like the PR2040 PIOs, you might love the Parallax Propeller 2 "Smart Pins."
Here's a link for others to Part 1 of that series of articles:
www.elektormagazine.com/magazine/elektor-167/59256
By forming a bridge output then you and expect to get 4 x the power on the speaker. e.g 2.5V in to 10 ohms, power = V2/R (2.5)2 / 10 = 0.625W (5)2 / 10 = 2.5W 2.5W/0.625W = 4 Sp one extra pin and 4 times the power out.
Well, I'm not sure this is a true bridge output, as there is no actual negative voltage swing. And the correlation between power out and perceived volume is not linear; I can remember in my dim and distant younger days when I was a DJ (yes, really) being pretty disappointed at the increase in volume from a 100W amp from a 50W amp. To get double the volume (10dB) from the same set of speakers you need to increase power by ten! Yikes!
Very informative video Sir
Thanks and welcome!
I just got 2 of those in the mail to play with.
I hope you have fun playing with them.
Nice video Ralph, are you thinking of using PIO with Interrupts for you fridge door project - would be very interested in a video describing how to enable the state machine from an interrupt request
"PIO with Interrupts for you fridge door project" - are you crazy, Stuart! Oh, you're being serious. I hadn't thought of that approach but now that you've mentioned it I will have to see what advantage that might bring.
Technically the PIO runs without intervention from the CPU core in the MCU. If you deal with other types of MCU you might find that your PIO isn't really special at all. Consider the approach taken on almost all MCUs today (if they have it available) for NeoPixel arrays.... DMA. You generate a bit pattern which creates the PWM square wave on the output pin.... call Transmit DMA and send the CPU to sleep. If the DMA is set to loop the buffer, you have nothing more to do and could potentially halt the CPU.
Beyond DMA advanced MCUs like the STM32 et. al. have many, many concurrently running systems inside them, handling IO without the CPU intervention. I believe on something like the STM32F411 (Black Pill board), the MCU has about 16 different clocks, running 16 different parts of the MCU asynchronously on one of several buses.
Usually those components are used for specific standard peripherals, like hardware UART, SPI, I2c etc, so the protocol aspects are very often taken care of entirely by the peripheral in hardware and the CPU is only "woken" up to process data that has arrived or when it's needed to make a decision.
Stretched out to it's potential, you can have a DMA transfer reading audio off an SDCard triggering a DMA transfer to send that data over I2S for a DAC and the CPU would be asleep or maybe just waiting on UI button interupts to change track. Potentially even further with the FPU DSP extensions, as you can send floating point calculations to the FPU and off load that processing and receive an interrupt when it's done. So you could even potentially have an IIR filter or two running on the audio stream and the CPU would STILL be idle a lot of the time. Although, when you get that level of power you might find the CPU is entirely busy answering real time interrupts to orchestrate everything.
The PIOs certainly sound interesting to play with and I'm sure some of the bus hardware in other MCUs could be used that way if you wanted to get down into the hardware control registers and start messing with their internal configs.
Ideal for NeoPixels, for sure, with no CPU involvement. I bet someone has already done this!
@@RalphBacon Having just done it with DMA->PWM on the STM and finding an even better way with SPI to try yet, I expect the greatest advantage of the PIO processors will be in converting the "bits" to sequences of 100 and 110 at 3 times the frequency. ;)
That would allow you to write raw 24bit RGB/BGR data to the port.
I would love to see some PIO communication between Picos.
It seems an unlikely topic for me to cover but I'm sure others out there have already done it.
Hey Ralph, I can't unhear it anymore ... no, not the actual audio of it, but the name you gave it: the Pizza-electric buzzer ... I think the guy of that effect had his name pronounced like pee-a-tzo, no? Don't know whether he was somehow linked to that crooked tower or loved to eat some Italian circular bread with tomatoes smashed on top, but I don't think he deserves being turned into such a dish ...
On a more useful note: I think you can add an additional command doing nothing (useful) with extra wait-states to get lower frequency. And I have a little worry: if you have a 4ohm speaker, is driving it directly from a gpio not risking over-current on that gpio (same for running between 2 gpio pins)?
You say tomayto, I say tomahto... Google says I should say pee-ay-zo which sounds very British English. I'm trying to say Peezo! I don't think it's a name: French physicists Jacques and Pierre Curie discovered piezoelectricity in 1880. And possibly the pizza too, with peperoni, of course.
@@RalphBacon Well, I would actually say "Tomaat" as I'm not a native English speaker, but since the term piezo is derived from (ancient) Greek, perhaps someone speaking Greek in your audience (there's bound to be someone, right?), could tell us how it would sound in Greek and enlighten us both ;-) They also have great tomatoes in Greece, right? So maybe we should also ask them to clear up the tomayto / tomahto mess ;-)
😂 😁🤣 Good answer! I'll ask: Μιλάει κανείς εδώ ελληνικά;
Hello Ralph, any plans to make a video on the Attiny 202/402 ?
Thank you for making this nice an understandable videos 👍
Best Regards,
Didier
I haven't got plans to look at these; the question for me (and my viewers) is: what are the advantages of these chips that makes them more suitable than others that we already have?
@@RalphBacon Hello Ralph, you do not find on TH-cam too many video’s on how to program this chip’s.
UDPI(One Pin Programming) seems to be the way Microchip / Atmel are going. Explained by you will be easy to understand 👍👌
@@RalphBaconOne pin programming & debug, also has way better peripherals than legacy ATTINYs
My first experience with the Pico was managing to get a PicoW (hens teeth). I ran a very quick MQTT subscribe and it worked. Then I did "Blinky", couldn't be bothered to google the right delay function so did this instead. Fully expecting (having just come from STM32 world) for 1 million to not be enough iterations to produce a sensible blinky.
In python I used this for delay:
for( i in range(0,1000000)):
pass
The LED had about 1 Hz blink frequency. That's only 2 million iterations per second. On a 130Mhz core. Wow. I thought Arduino framework was wasteful.
Circuit/Micro python is fiercely slow.
It's all down to interpreted vs compiled code, I guess. If Arduino had used μPython on the original Arduino it would never have found the success it has had, far too slow!
Rapid Electronics have loads of PicoW.
Interesting! I didn’t know pushing an pulling pins for a sounder made such a difference.
I think you can do a live-set-able number of delay cycles (I’ve not checked this but I hope you get the idea) - this uses side set for both bits so the pins have to be adjacent. I’ve also missed out the wrap target and wrap labels because I think the assembler assumes these if they are the first and last instructions:
@rp2.asm_pio(sideset_init = (rp2.PIO.OUT_HIGH, rp2.PIO.OUT_LOW))
def beep():
mov(x, y)
label(“loop1”)
jmp(x_dec, “loop1”) .side(0b01)
mov(x, y)
label(“loop2”)
jmp(x_dec, “loop2”) .side(0b10)
Delays are caused by looping round and decrementing X, and when X gets to zero the code drops through. The minimum delay is zero, so the the minimum clock cycles for the whole lot is 4, or up to 2^32+2 if you set Y as 0xFFFF. This should give you pretty good pitch control if you use a fast PIO clock!
You would set the number of wait cycles by setting Y in your Python WHILE loop using:
sm.put(number_of_wait_cycles)
sm.exec(“pull()”)
sm.exec(“mov(y, osr)”)
A nice example, Mr Weston, (I'll call you Nick) and shows how tight loops can be implemented in the PIO arena as well as passing values to the PIO code. Cool stuff.
Interesting approach to push/pull the speaker. I still can't figure out what the reference voltage would be. I mean normally you would see -3V +3V but thats only what the speaker sees. The MCU still sees 0-3V. I suppose what that is, is a differential pair and there is no static "reference". I hate analogue electronics :)
There's no magic, nor smoke and mirrors. It's still only VCC and GND.
The "magic" (even though I said there was none) is in having the speaker cone move forward with the positive pulse in the normal way.
BUT, when the polarity is _reversed_ it's still only VCC and GND but the speaker cone is now in a starting position that could only be achieved (normally) with a +VCC / -VCC and it moves the full distance backwards thus giving a much bigger sound wave than by normal means. 😲
@@RalphBacon i wonder .... if using PIO could you bit bang a PWM fast enough to make a class D amp out of a GPIO pin!
Yeah... good luck with that one!
RP2040: IOVDD is Power supply for digital GPIOs, nominal voltage 1.8V to 3.3V
Let's say we have 3.3V from the Pico board here.
In IO output Mode you can switch the RP2040 IO Port pins between physical IOVDD pin (digital High logic state.) and its physical GND pin. (digital Low logic state).
Let's say you have two Ports in output Mode and call them A and B.
if you switch A to IOVDD and B to GND
and after a 2 second waiting time switch
A to GND and B to IOVDD
and after waiting two seconds repeat
then a multimeter connected beween those two IOs will see it's probes are alternatiting
connection between IOVDD and GND. because the switching transistors in the ports are told by the software to do that.
So the Multimeter will show alternating between: 3V and -3V
if you measure any port to GND when it is LOW the port itself is a GND, so you measure GND to GND which shows 0V
if you measure any port to GND when it is High, you measure GND to IOVDD which should be around 3.3V GPIO Power supply voltage on the Pico board.
Nice video, thanks :)
Glad you liked it!
That is an interesting breadboard.
Looks to be of higher quality than
the usual fare. Source?
It's this one (UK supplier):
coolcomponents.co.uk/products/ad-11-advanced-solderless-breadboard
@@RalphBacon Thank You for the link. I have
one on the way. 6x6 configuration is going to
make the 8266 boards I bought a lot easier to
work with. In a crazy world a sane man such as
yourself is much missed. So glad you are back.
Do Raspberry Pi Ltd have an ARM licence, or did they use a third party to design and manufacture the RP2040?
All home grown from what I hear, and yes, they have a fully licenced ARM set up.
Errr....[blood boiling] TH-cam are saying 'Nobody clicks the bell anymore', well of course not, TH-cam stopped email notifications months ago so whats the point? Yeah, I know it works for some users of certain browsers and mobile devices but for the majority of youtube users, nah. I have to use a third party to inform me of any new uploads otherwise I'd miss everything. It doesn't work for 'live' events though and if there isn't a 'reminder' set by the creator then I miss those too. Just my small rant, sorry....great vid, thanks.[/blood boiling]
What did Elton John say? Don't Shoot Me I'm only the Piano Player great album! But seriously, I've never really understood the "subscribe but also do something else to get notifications" anyway.
@@RalphBacon Indeed he did. (Ticking is the best track in my opinion, tells astory.)
Cheers,
Norm.
Hmm, I seem to remember that Ticking was on Caribou not Don't Shoot Me, but as this was a gazillion years ago I could be wrong. I liked Teacher I Need You as I liked my Spanish Teacher of the time! Jeez, that's unsettling, she would be nearly 80 now... if she's still here. Thanks Norman, now I feel really depressed. 😢 And old.
@@RalphBacon Sorry Ralph, you unkowingly lit the fuse and I kind of went off on one.
@@RalphBacon So, I had to check and Ticking was indeed on Caribou. My mistke and as punishment, I will be listening to the album on repeat for at least a day! I always thought the Teacher... was a tad risque, even as a teenager, but then again, I know what you are saying!
Yes, I'm old too. 61 back in April. Still, I'd hate to be a kid these days the way we humans are buggering everything up.
Take care.
Cheers,
Norm.
Damn do I now have to buy more stuff, CPC have now posted the extra 2 picos :-) I guess this is for the fridge alarm, I guess I will have to buy a fridge as well:-)
And beer to put in the fridge!
@@RalphBacon if only I could afford it instead of buying PICO's:-)
😁 🍺🍺🍺🍺
GPIO co-processor!
Well, a very limited coprocessor but, yes, I suppose it is!
👍
Cool!
This has been my favorite channel for a couple of years now, BUT I have to say I am losing interest, I can't think of anything I would use A Pico for that and Atmel or STM or ESP would not do better. And for me Micro python is pointless why learn a new language so my solutions can go slower and have less memory... Went to the end to see if you had an update in the bin sensor but alas :(
Hmm, I knew this would be a potential issue for my viewers, Andrew. After all, what _can_ the PICO do that the others cannot (and more quickly too)? I'm only covering the PICO because it's out there, in your face, inescapable, by virtue of being launched by Raspberry Pi. If another (much smaller) manufacturer had launched this it would not have had so much traction.
I'm not sure MicroPython is pointless (harsh, Andrew, harsh) as beginners probably pick up the rudiments quite quickly (then get lost in spaghetti code). And no compilation stage leads to faster development time of that blinking LED, as you saw!
But don't give up! And don't leave! My ATMega328P bin lid monitor is (slowly) coming along, talking using its nRF24L01 to a dumb receiver (at this stage), I have my fridge door alarm to complete albeit possibly with the PICO (maybe, I'm having doubts now) and I have my... oh, you'll just have to tune in and find out.
(Remember, I'm an Arduinite at heart but don't tell anyone else).
I feel the same way.
Sorry, but I don't see how you get your claimed 'negative pulse'.
A GPIO can only switch between OV and Vcc, so the maximum possible offset is surely only the same as The Vcc value, so with a Vcc of 3.3V its impossible to obtain the quoted 6.6V...
In terms of Forward and Backward movement of a loudspeaker cone it makes sense but, as explained, it's incredibly misleading.
With this ‘trick’ you can double the voltage, but you need some kind of external reservoir. In this case the reservoir is a mechanical item. The coil movement is the double of the gnd-pin config. You can do the same with a little circuit with a capacitor as reservoir. The cap will charge to 2x the pin voltage. Handy if e.g. you want to use a led with a Vf greater than 3V on that output pin.
@@hopje01 No capacitors were used in the given example.
As, I mentioned, I can see how the Forward and Reverse action of the loudspeaker cone provides double the volume but, at no point is there ' double the voltage', as stated in the video, for the setup shown. That's what will mislead anyone who doesn't understand what's going on and it's compounded by the dual trace oscilloscope display not having a common baseline.
100%
@@hopje01 there is a big difference between + and - 3V vs GND and 0 to 3V. That is why there is no 6V amplitude on Pico ;-)
@@zyghom Exactly...