A great video as always Andreas! I happened to have the C++ dev environment setup on the bench using a Raspberry Pi 4 and therefore was able to quickly measure the interrupt response time with my oscilloscope. This turned out to be 1.1us when built for debug and 1.0us for release. The release version seems to have some jitter of around 0.1us whereas the debug version doesn't which seems a bit unusual.
To add a bit more to my last comment, I did a some more investigation and it appears that the minimum execution time of a GPIO interrupt handler is 5 us (i.e. even if it does nothing) which seems like an awful lot of overhead. I searched the data sheet for the processor and the SDK documentation and source code but could find no explanation for this behaviour. Probably someone more familiar with the ARM processor architecture will know. Cheers!
Micropython seems to have a "hard = true" option when assigning an IRQ to a pin. Maybe this would also make it a bit faster. Maybe I might try this someday.... docs.micropython.org/en/latest/library/machine.Pin.html
greets from ukraine! u have very good english, easily understandable even for non english-speaken guys like me. doing electronics as hobby for 20 years, but still can get some new knowledge from any of your videos. so what we can say about newbies. its a heaven for them. keep it up, man
When you made this video, I was miles away from securing a job in engineering. No degree, no money, self-study. A year later, Mr. Spiess set me on a journey with the pico that allowed me to secure a job as an RF Technician (en route to engineering position) for municipal districts and emergency service radios. Thank you for all the immensely valuable information and education and it is not for granted!
@@AndreasSpiess Hello sir, I am trying to use PIO to measure the timing between two rising edges on two input pins, but have trouble getting the accurate measurement. Whats the best approach I should go with. I need it at least 400ns accuracy. Thanks
@@AndreasSpiess Reset buttons are also a danger. I've pressed them inadvertently too many times. You could pull the other end of the usb cable to spare the soldered on connector. (Great content and presentation by the way! And that's a cool cat :))
I got so annoyed with having to do this when working on MCU breakout boards, I made a small PCB pass-through board with a gang switch on it to break all USB connections. A small but very nice quality of life improvement.
You don't even need a button. Just connect a Wire from ground to the RUN pin, and you reser the device. I think you need to add that, so we Will stop this nonsens with pulling the USB-cable to reset the device. Just ground RUN pin on the device!
Quality content as always. - And not a mix-up of examples from the book, another unboxing, introduction etc. - He sets the bar high for other UA-camrs. Thank you!
As usual a great video with excellent resource links. The Getting started book is worth five pounds, whatever that is in dollars. Threads and interrupts were explained so that mere mortals can grasp it. Keep broadcasting!!
freeRTOS !! Yea, I just started reading the official docs last week. Half way through mastering freeRTOS already. Cool stuff in there. These topics will advance/enhance our lives 4 sure
Two comments. After I got my pico last month I did a lot of testing with multicore in Python. Globals do get updated across cores. But it’s non-blocking and (other than @ entry) takes about 1 ms so you should use a blocking mechanism if you’re counting on a variable getting updated. Locks, otoh, can be counted on to be updated in real time on both sides. They are probably using an interrupt to do this so you may take a small performance hit when using locks. About the connector: usb-micro connectors are rated for a minimum of 10,000 careful insertion cycles. Detach from the pico side, not from the computer side. It’s way easier to replace a $4 pico than a USB port on your laptop :) I really enjoy your videos, thanks!
I assume the firmware does the blocking. It has all information to do it. I did not measure how long the locks take. Concerning the USB: On those boards the weak point is never the connector. Always the soldering or even the PCB. Another viewer complained that he lost already a few of these boards because of this fact. I added a reset button ;-)
Andreas!!! Lovely video as *ALWAYS!!* After this video you TRIGGERED me to wish that you eventually make a C++ video for Raspberry Pico, please!!!!!!! Thank you for all your hard work.
I really like the quality of your explanations. Great visualization and you show the examples very detailed. Thanks for enlightening me so often. I am still pretty new to the topic, but I had lots of fun so far.
Great tip with the baton, I don't remember reading about it in the book. Thank you Andreas! I also had some issues with threading: it simply did not work when I used VS Code and rshell - but it started to work when I installed Thonny.
Hello from India Andreas... Thank you very much for all the interesting and easy to understand videos... Please make more videos using Pi-Pico and Python.
This is a great presentation. Lots of good information to use when I can get my hands on a supply of these boards. The only ones currently available in the US are from scalpers charging 3 times or more than companies taking back orders. Perhaps I'll just have to suck it up and wait until March 17 when legitimate orders are fulfilled at a reasonable price. I think there will be a version at some point with WIFI and Blue Tooth to compete with the Esp-32 if the price is comparable. I hope you have a great day.
@@AndreasSpiess I would settle for LoRa over wifi. It would be nice to read sensor data over a distance. In fact I think LoRa would be more useful anyway.
@@kosmasraptis8374 I saw that it was available, unfortunately they will only let you buy 1 and I want 10. I guess I can suck it up and buy just one. I just hate to pay huge shipping charges on something that cost 6 dollars..I already have a project in mind so I might as well buy the one before they are all gone. The device is technically bluetooth ready but it's not currently activated.
Great! I have just got an LPC55S69 which also has two cores. I am planning to make a quadcopter flight controller with the feature. Your video makes my idea clearer and more valid.
Very detailed and a lot covered - thanks Now... designers that don't believe in a reset button do need to have a serious head examination. I designed a PC modem in the 1990s - used a DSP single chip with a controller 8048. The DSP worked great - until it "fell over" - There was no "begin again" control line. The short term solution - power cycle. The fix - scrap the design and go with another DSP design. (One that did have a reset line.) Thanks for the video!
@@AndreasSpiess It is counter intuitive. It also works for accesing the mass storage mode without disconnecting the USB, assert RUN low, hold the button, release RUN. I don't feel like a lot of people know this, would you put a short video about it?
@@AndreasSpiess I did now, the whole thing resets. Edit: according to RP2040's datasheet: "The chip-level reset subsystem resets the whole chip, placing it in a default state. This happens at initial power-on, during a power supply brown-out event or when the chip’s RUN pin is taken low. "
Fantastic video again. You are a few steps ahead of me, I will get to the 1% soon :). I am testing using the PI Pico as a robotics motor controller with motor encoder monitoring. I could get it to track encoder pulses from an irq up to around 16KHz but was measuring encoder pulses per x amount of time (Using the Timer function in micropython so don't need to calculate time since last pulse), so the code I had in the irq callback was simpler, just a increment of count. Because I want to track two motors for a robotic platform the threading will be useful, hopefully I can run the irq callbacks on separate threads without them impacting the IRQ responsiveness.
Did you check your results with an oscilloscope? 1/50us is 20kHz. So your ISR probably takes most of the processing power... IC++ it is much faster, BTW.
@@AndreasSpiess - I used a function generator to generate the irq for the test. FYI: Video of the test is here ua-cam.com/video/TWYHvw0IuUQ/v-deo.html 10:53 in. The plan if the Pico can't keep up with two motors is to switch over to an ESP32 or Blackpill , worst case I will have to code in C (but am trying to avoid it)
A fine example of why someone needs to break this chicken/egg scenario regarding the Parallax P2. 16KHz is miserable 😁 The best way to use interrupts is _not_ to use them. Apart from the P2's eight parallel processors, its 64 identical "smart-pins" can be pretty much anything one might need. Any pair of pins can decocde/count a quadrature encoder.....even with all eight processors idling. How about a frequency of sysclock/2 ? I am not aware of any dedicated quadrature-counting device that can come close to this. Program in C, BASIC, SPIN, ASM or combine any/all of those languages. If nobody knows about the P2's existence then naturally, nobody will be using it. 😉
You can add your own reset button on the 'run' pin (pin #30 on the Pico). If that pin is connected to ground the Pico will reset. This will be even more needed once you start with C/C++ on the Pico, as updating the code will require a mount/upload/unmount cycle.
Come now... we can have a reset "button" by soldering a small jumper to one of the castellated grounds, and just tap the Reset pin. Bonus: If things get too boring, Dishka can start bopping the wire around. 😁 Thanks for the video! Glad to see uPython supports threads on the Pico, even if only in a limited fashion.
The weekend I was looking into C++ programming of the Pico and found your example interesting for quick testing a project. C++ is a total overkill for 99% of most projects. But industrial applications may be time critical.
This is super helpful. I might use C++ instead for my project if the SNES clock/latch pin is too fast for my project. I hope so, because then i might be able to get away with using 0 shift registers instead of 2 per emulated controller
Great as always Andreas. I do have to say I really dislike the use of interpreted languages(python) on embedded systems since it is such a waste of processing power compared to compiled languages(C/C++). It does however open up the world to people that would otherwise not be able use these products at all. I have worked with RTOSs for over 30 years and remember people getting fired for using blocking functions such as delay loops, sleep, pause, etc instead of interrupts/message queues. Nice to see you re-introducing this concept to the next generation.
We had this discussion in my video about MicroPython. I predict that high level languages will take over in the next few years for prototype projects where programmer's time is much more expensive than processing time. RTOS are still a very good thing and for me also a "higher level" language where the programmer does not control everything. And you are right: They allow a very different programming style.
Also, it's good for many hobbyists who just create fun trash stuff like me. In such projects, speed often doesn't matter, but the fun and convenient process of development does. I used to program Arduino a lot, but RP Pico is a lot more fun for me.
Thanks for your video! I'm also very interested in the PIO speed, but have no Pico to measure myself. I guess you could build a simple pin-> pin latency test the following way: - Set up a DMA channel to copy the same byte into the IO-space to change the pin (there are different bit manipulation functions at offsets, like set, reset, toggle) - use the PIO to kick the DMA - Maybe you need a second DMA channel or DMA channel chaining to keep the whole engine running
Jan, if you use PIO for example to drive GPIO pins to just generate a square wave the max frequency would be clk_sys/2 (62.5 MHz) since it would take 2 cycles to complete the code below: .wrap_target set pins 1 set pins 0 .wrap
To all who want a Reset-Button, I used this technique. I have a Pushbutton connected to the RPi-Pico Pins: PIN No. 30 (RUN) And PIN 28 (GND) -> Any GND will do It works like Charm, no plugin/-out. In Thonny You need only to Press the "STOP"-Button, to notify Thonny about a Reset.
You are right. I also added a 5mm button across the two pins. Concerning Thonny: Usually this works, but for the moment it does not work if you use the 2 core scenarios. and I assume when people start to use C++ and the Arduino IDE they will create some deadlocks...
Great! You've answered 2 of my main pressing questions which are the use of 2 cores and interrupt response time. Disappointed with Micropython slow interrupt response time. I think I'll will wait for the official Arduino IDE support. Hopefully the existing libraries will work as well. Planning to port my application to Pi Pico for more processing power. Currently running on Arduino Uno.
Now, to get a Pi Pico so I can officially be in the 99% group by experimenting with the information from this video. I am shocked I haven't picked up 5-10 of them already! Great video, well documented and explained. I will reference it when the Pi Pico arrives.
This implementation of the _thread module is specific for the RP2040. In the ESP32 it works differently. The second core is not used there. Then you assume that automatic memory locking is implemented between threads. However, the documentation states explicitly there is no GIL (Global Interpreter Lock) used. Which means that bad things can happen with shared access to objects. It is probably safe to read objects written by the other thread, but mutual writes, deletes etc might give surprises. For interrupts there may be restrictions too. Documentation is a bit sparse in that area. On ESP32 you typically use micropython.schedule() to get out of interrupt mode and continue processing in normal mode. Still need to check how they did this for the rp2 port.
What is the issue with the RESET? Since you're already connecting external components to it, you might as well add a tactile button between GND and pin 30 (confusingly called RUN) to reset the chip.
@@AndreasSpiess That wasn't quite clear from the video or I missed it. I can totally understand why they haven't added one; if you're a maker and hooking up external components on a breadboard anyway you might as well add a reset button (the pullup is already there) if you need it but if you're integrating the board on your own circuits you may not have a need for it or it could potentially be in the way if you don't want users to fool around with it (I certainly have removed reset buttons in the past). Either way I think it is fine as is and just wasn't sure whether you knew about the exposed NRST pad...
@@AndreasSpiess yes, I’ve got code working cleanly using uasyncio on the Pico. I’m now, after watching this video, very interested in adding in _threads and seeing how they all work together. Fun times! (PS: great video).
Excellent comparison. I guess I ordered my Pico's a little too soon. The reset button new release is defenately the next step ! Thnxs for this entertaining sunday morning !
Agreed, a reset button is important on any board that will go through many development cycles. It's not just about resetting when it locks up, but also about watching what happens when it is powered up. Yes, there are ways of doing it by button, but 5p extra for a reset button is something I'd happily pay. That said, leave the button off but put pads on the board for me to add it.
Hey, just as a head's up to people using the ESP-32 and Micropython, while many versions of the ESP-32 are dual core, Micropython only runs on one of them and reserves the other to perform peripheral tasks such as managing wifi without it interrupting the main micropython core. This is true even if you are creating multiple threads! So be aware that even though you're getting true preemptive multitasking in multiple threads, all of those threads still run on a single core. For evidence, look in the ports/esp32/mpthreadport.c and you'll see that all tasks/threads are bound to the same MP_TASK_COREID constant.
Thanks for the video, Andreas:) PIN30 RUN -> RUN is the RP2040 enable pin, and has an internal (on-chip) pull-up resistor to 3.3V of about ~50K Ohms. To reset RP2040, short this pin low. 2021, Raspberry Pi Pico Datasheet, page 7,8. ... RTFD!;)
Thanks for this, it's exactly what I happened to be looking for. I was trying to find something to do with the 5 Pico's I impulse purchased. Now with some Hall effect sensors and this new found task and interrupt info I think I'm off to the races. Cheers! Oh and the cat snoring at the end is just... awww.. :)
Thank you for alerting me to the Pi Pico. What a useful device for mains powered motor control. I can have one core monitor the mains and set some variables whilst the other one manages the amount of chop the motor gets. Also £4 for an MCU on a board is really cheap.
This is a great video. You make it sound so simple but I believe you did a lot of hard work to get it done to this level. On a side note, I think that its best we call release() function after accuire() just to release the batton. Just an idea.
Twist: now that we have watched the video as all pico users do, we are no more in the 99% club. Because Andreas educated *all* pico users. The 99% already know about interrupts, two cores etc 😎 Hurry up if you want to be in the 1%-range (for a second).
Andreas, I am confused about your example for ‘synchronising’ the two cores. It merely synchronises the stop and start of each core so that they never run together. How useful can that be? What’s the advantage compared to a single core that runs tasks one-by-one?Two tips for a next video: hardware debugging using picoprobe (C, C++) and programming the PIO! The PIO is what sets the RP2040 apart from the rest... and it is not too hard to write short programs for it. Correctly used, the PIO can dramatically increase the speed of the processor. The pin side set feature in fact effectively allows it to execute two instructions per cycle!
1. Using two cores creates a lot of hassle compared to only one core. Two cores are faster than one core of the same type. 2. I still wait for a useful application for the PIO. This is why I made the challenge. VGA or HDMI on a MCU with this small RAM is nothing for me 3. I will start with C++ when it is Arduino compatible. Right now it is too much a hassle for me :-(
@@AndreasSpiess Andreas: 1. If speed is the target than the easiest and most effective is certainly just use a faster clock. But this will not necessarily improve precision of timing, which is not rarely the reason why a controller (without os) in used instead of a microprocessor like e.g. the raspberry pi zero. The second core, and even more the second core attending the PIO, should excel in that! 2. I think the demo with the PIO producing HDMI signals is meant mainly as a demonstration of (1). Very impressive that this can be done with a non-specialised microcontroller of a few €, but if you really need HDMI, it is quite likely you also need/want an os and then you’re better off with a microprocessor. I see more applications for the PIO in accommodating serial io that is not supported (or not in enough numbers) in hardware (like eg CAN controller, Serial RGB Led) or when multiple fast precisely timed outputs are needed and for which otherwise a FPGA would be needed. I am thinking of multiple coordinated motor controls like eg. 3D printers, drones and the like. These work with low-power processors as well, but when precision and speed need to improve this won’t work anymore and a processor like the RP2040 is, in my opinion, a fantastic fit. 3. Here I fully agree! It is an incredible hassle to even setup a build and hardware debugging environment for now.
Como siempre, señor Andreas, un vídeo muy bueno y muy buena su explicación. Aún no he podido conseguir la placa Pico pero después de ver este vídeo, tengo aún más ganas!
on the pico pi , ctrl D will perform a soft reboot. and if you place a button between Ground and Run pin, it works to program like on the esp8266 and the 32.
Hey Andreas I love your videos, always with interesting information, and thanks for add spanish subtitles, It allows me to share your videos with my studends. Greetings from México
Clocking an ASYNC counter works best for the frequency counters. PIC's for example have nice async counters. I've created counters that handle hundreds of megahertz with pre counters and the async counters with no visible jitter. That was ages ago.
Did someone eventually make the pulse counter PIO? I want to read the LMT01 digital temperature sensor but the interrupts are too slow. I also hard-wired it to GP22 so that's a PWM-A pin. Otherwise I could have used it as a PWM clock input pin. My only hope is PIO at this point.
informative video but have to give 2 comments. 1. The absence of the reset button can be easily covert by a external button especially when you work on a breadboard. It may be needed during development but once you past that stage its no use any more. 2. Comparing interrupt service handling speed between python and c++ is like comparing the 0-100 km/h between a Volvo V70 and a muscle car. They both are cars with combustion engines but the V70, although might be more comfortable for most people, isn't up for that job. Phyton != Made for speed because it's interpreted . Try writing the same code with in the Pico C/C++ sdk and compare again. My guess is that they will be in the same range.
@@AndreasSpiess Looking at the video I tried to look at the comments but my phone didn't want to expand the comment section. Later I found out that it's was a double comment. Sorry for that 🤭
Where in the documentation did you found that multithreading is implemented using multicore ? The MicroPython documentation regarding threads is quite minimalist and point to the CPython page, which does not speak about cores... Beside MicroPython also run on single core platform... Thanks
Thank you Andreas, I have been looking for these topics on the Pi Pico and now you provided them in a excellent manner. This is great stuff! Now I only have to find out how to use the Pi Pico as an I2C slave device. I can easily find info on how to use it as master, but nothing on how to use it as a slave. Could you be persuaded to look into this, I think it will be highly appreciated by many people using the Pi Pico:-)
Your video on the ATTiny85 controlled array of ultrasonic sensors communicating over I2C was excellent, and I learned a great deal from it. And you made it look relatively easy, so I began to think that I was missing something since I couldn't find anything on the Pi Pico as an I2C slave device. Is it really that different from the usage as a master? From my perspective the main diffrence is that slave devices have to have an address assigned, the rest is "just" sending and receiving - but I've never made an I2C library, so of course I wouldn't know the gory details.
You can ground the reset pin, of course. This is what the reset button would do. Unplugging also helps, of course. But in the next video I added a simple reset button which is much more comfortable.
Yes, now in HD again :-) I think if you need to power off a micro USB plugged device, the most convenient way to do so is a cheap USB hub with switchable ports. At least i would not want to miss it. Cheers from Bulgaria
at least we have some innovative people here, I wish more engineers are like you and well done, problems can be solved easily with a bit of innovation instead of complaining
Question about the dual core threads and the baton - if each thread stops and waits to get the baton, then only one thread is running at any one time - what is the benefit of doing this? It seems that it would be faster to just run in one core and not have all the baton passing overhead to deal with.
That is all awesome but I would consider using a context manager for locks - because it ensures that the lock gets released no matter what happens inside the code so e.g. if there is an exception the lock will still get released e.g.: a_lock = _thread.allocate_lock() with a_lock: print("a_lock is locked while this executes")
@@AndreasSpiess oh, don't worry - it's just a small thing. One of the good features in python is the "with" statement. It allows you to free resources like open files or sockets or locks automatically. You don't have to remember to call the "release()" function for the lock because you know that when the program exits the "with" block then it will be automatically released. Normally you could say "so what - I can just call release myself and it's only 1 line?" But the good thing about a with statement is that it also works if there is an exception inside the block or even a return statement. So for files: e.g. def find_end(): with open("myfile.txt", "r") as f: for line in f: print(line) cleanline=line.rstrip() # remove LF if cleanline == "END": print("Found END") return elif cleanline == "MAJORERROR": raise Exception("There was a major error") print("Didn't find END") We don't need to call f.close() in this program even though there are several possible exit points because the "with" statement ensures that f.close() will be called even if there is an exception or if the function returns. With locks in Micropython it is the same: a_lock = _thread.allocate_lock() mydict = {"alice": 12, "bob", 12 } with a_lock: print("a_lock is locked while this executes") print(mydict["john"]) # Keyerror exception but the lock is still released. Sorry if my explanation is not good - there are better ones on the net.
In the meantime I tried it out and it worked. Indeed a nice addition. For the video, the lock commands were probably easier to understand. For as a programmer I definitively will use your proposal.
Looks like the RUN pin is actually the reset input. Use a push to make switch on this pin to ground to reset. Has an internal pull up. First time I've ever seen a reset pin called RUN.
One weakness of the ESP32 with Arduino C++ is it cannot be a slave_receiver/slave_sender in an I2c 'Wire'' communications setup. Does the Pico have that capability ?
A great video as always Andreas! I happened to have the C++ dev environment setup on the bench using a Raspberry Pi 4 and therefore was able to quickly measure the interrupt response time with my oscilloscope. This turned out to be 1.1us when built for debug and 1.0us for release. The release version seems to have some jitter of around 0.1us whereas the debug version doesn't which seems a bit unusual.
To add a bit more to my last comment, I did a some more investigation and it appears that the minimum execution time of a GPIO interrupt handler is 5 us (i.e. even if it does nothing) which seems like an awful lot of overhead. I searched the data sheet for the processor and the SDK documentation and source code but could find no explanation for this behaviour. Probably someone more familiar with the ARM processor architecture will know. Cheers!
Thank you for testing it. This seems to be ok. Of the 1.3 us of the STM32, about half was to set the pin (Arduino is not very fast in this discipline)
@@RocketManRC-Electronics How did you measure the execution time of the isr?
Micropython seems to have a "hard = true" option when assigning an IRQ to a pin. Maybe this would also make it a bit faster. Maybe I might try this someday....
docs.micropython.org/en/latest/library/machine.Pin.html
@@rianderous8761 python will always be slower as it needs an interpreter to run.
greets from ukraine!
u have very good english, easily understandable even for non english-speaken guys like me.
doing electronics as hobby for 20 years, but still can get some new knowledge from any of your videos.
so what we can say about newbies. its a heaven for them.
keep it up, man
Cool, thanks!
When you made this video, I was miles away from securing a job in engineering. No degree, no money, self-study. A year later, Mr. Spiess set me on a journey with the pico that allowed me to secure a job as an RF Technician (en route to engineering position) for municipal districts and emergency service radios. Thank you for all the immensely valuable information and education and it is not for granted!
Congratulations! I am always happy if I can be of help for somebody.
@@AndreasSpiess
Hello sir,
I am trying to use PIO to measure the timing between two rising edges on two input pins, but have trouble getting the accurate measurement. Whats the best approach I should go with. I need it at least 400ns accuracy.
Thanks
@@yeanic I never used the PIO functionality 😞
Nothing like your weekly dosage of your guy with the swiss accent. :)
:-)
shorting the pico's RUN pin to ground causes a hardware reset, it's a pity that there isn't a built in reset button, but adding one isn't too hard
You are right. I still think it should not be the task of the buyer...
@@AndreasSpiess Reset buttons are also a danger. I've pressed them inadvertently too many times. You could pull the other end of the usb cable to spare the soldered on connector.
(Great content and presentation by the way! And that's a cool cat :))
I got so annoyed with having to do this when working on MCU breakout boards, I made a small PCB pass-through board with a gang switch on it to break all USB connections. A small but very nice quality of life improvement.
I’m not entirely sure, but BenHeck I believe did some magic with the onboard button and a single wire to act as a reset.
You don't even need a button.
Just connect a Wire from ground to the RUN pin, and you reser the device.
I think you need to add that, so we Will stop this nonsens with pulling the USB-cable to reset the device.
Just ground RUN pin on the device!
The cat says: "no more interrupts".
:-))
Quality content as always. - And not a mix-up of examples from the book, another unboxing, introduction etc. - He sets the bar high for other UA-camrs. Thank you!
You are welcome!
As usual a great video with excellent resource links. The Getting started book is worth five pounds, whatever that is in dollars. Threads and interrupts were explained so that mere mortals can grasp it. Keep broadcasting!!
I agree. The foundation does a good job documenting their products.
freeRTOS !! Yea, I just started reading the official docs last week. Half way through mastering freeRTOS already. Cool stuff in there. These topics will advance/enhance our lives 4 sure
True! But we have to change our programming styles a little...
@@AndreasSpiess and changing programming style from Arduino are just fine, and Good.
Just received some picos yesterday and was interested in using both cores. Perfect timing discovering #372. Thank you!
Enjoy!
If you're afraid of wearing out the connector you can always try unplugging the other end of the cable ;-)
You are right. Theoretically. I used a Raspberry pi with an SSD Ethernet, HDMI, and a mouse. Not really convenient to unplug it there...
@@AndreasSpiess I would use one of those usb cord with an inline power switch in that case.
@@VisDeuxMany of those are power only, not data, Finding a data cable with a switch is hard
@@DinoFancellu make your own?
The easy answer is to use a simple usb extension and pull it there
you can reset the pico by connecting the "run" pin to ground.
You are right. This is what I do now.
Fastastic and practical info on the fundamentals of utilizing multiple cores! Your explanations are so clear and concise, thank you!
You're very welcome!
Two comments. After I got my pico last month I did a lot of testing with multicore in Python. Globals do get updated across cores. But it’s non-blocking and (other than @ entry) takes about 1 ms so you should use a blocking mechanism if you’re counting on a variable getting updated. Locks, otoh, can be counted on to be updated in real time on both sides. They are probably using an interrupt to do this so you may take a small performance hit when using locks. About the connector: usb-micro connectors are rated for a minimum of 10,000 careful insertion cycles. Detach from the pico side, not from the computer side. It’s way easier to replace a $4 pico than a USB port on your laptop :) I really enjoy your videos, thanks!
I assume the firmware does the blocking. It has all information to do it. I did not measure how long the locks take.
Concerning the USB: On those boards the weak point is never the connector. Always the soldering or even the PCB. Another viewer complained that he lost already a few of these boards because of this fact.
I added a reset button ;-)
Andreas!!! Lovely video as *ALWAYS!!* After this video you TRIGGERED me to wish that you eventually make a C++ video for Raspberry Pico, please!!!!!!! Thank you for all your hard work.
I wait till it is supported by the Arduino IDE.
I love your deep dives Andreas. I'm glad you exist to do them. I had a chuckle at the arduino c++ designation. Another great video.
Thank you. Glad you like the content.
Excellent!
Regarding the RP "reset", I grabbed an old powered USB hub with a switch and inserted it between the Pico and computer.
A good idea! As another possibility, in another video I just added a small button switch...
Awesome video!!! I put a button between ground and PIN run in pico.
Now I can connect and disconnect using it
I know and I did it. But on a beginners board in 2021?
I really like the quality of your explanations. Great visualization and you show the examples very detailed. Thanks for enlightening me so often. I am still pretty new to the topic, but I had lots of fun so far.
Glad it was helpful! And welcome aboard the channel!
Hi Andreas! I learned a lot from you. Thank you for elevating us to the top 1%!
Welcome in the club ;-)
Great tip with the baton, I don't remember reading about it in the book. Thank you Andreas! I also had some issues with threading: it simply did not work when I used VS Code and rshell - but it started to work when I installed Thonny.
I do not think that locks are covered in the book.
@@AndreasSpiess you are correct, they are not covered in the book
Andreas, thanks for this very comprehensive introductory tutorial. Your subject / explanation style is excellent.
Glad you enjoyed it!
Ok that's the most adorable snoring cat on the internet. I will become a Patreon now just so you can give her more treats.
Thank you! Indeed, she is very good in snoring!
I like the remark about the 5 cents :)
By the way, it's always a plaisure to learn something new with your videos.
Thanks! 😃
Hello from India Andreas... Thank you very much for all the interesting and easy to understand videos... Please make more videos using Pi-Pico and Python.
So far my viewers are not very much interested in the Pico as well as in MicroPython :-(
This is a great presentation. Lots of good information to use when I can get my hands on a supply of these boards. The only ones currently available in the US are from scalpers charging 3 times or more than companies taking back orders. Perhaps I'll just have to suck it up and wait until March 17 when legitimate orders are fulfilled at a reasonable price. I think there will be a version at some point with WIFI and Blue Tooth to compete with the Esp-32 if the price is comparable. I hope you have a great day.
We will see if they are able to add WiFi. This seems not so easy...
@@AndreasSpiess I would settle for LoRa over wifi. It would be nice to read sensor data over a distance. In fact I think LoRa would be more useful anyway.
Well, a WiFi version just came out 2 days ago, not sure if they will make a Bluetooth one too
@@kosmasraptis8374 I saw that it was available, unfortunately they will only let you buy 1 and I want 10. I guess I can suck it up and buy just one. I just hate to pay huge shipping charges on something that cost 6 dollars..I already have a project in mind so I might as well buy the one before they are all gone. The device is technically bluetooth ready but it's not currently activated.
@@rickhunt3183 Perhaps you can get a Bluetooth shield for that
Great! I have just got an LPC55S69 which also has two cores. I am planning to make a quadcopter flight controller with the feature. Your video makes my idea clearer and more valid.
Good luck with your project!
@@AndreasSpiess Thank you!
Thanks, very useful video. I especially like the footage of your sleepy lab assistant at the end
I will tell her ;-)
Very detailed and a lot covered - thanks
Now... designers that don't believe in a reset button do need to have a serious head examination. I designed a PC modem in the 1990s - used a DSP single chip with a controller 8048. The DSP worked great - until it "fell over" - There was no "begin again" control line.
The short term solution - power cycle.
The fix - scrap the design and go with another DSP design. (One that did have a reset line.)
Thanks for the video!
Thank you. In my age I do not forget a reset pin because, as I said, I am a mere mortal ;-)
@@AndreasSpiess ... and a few flashing LEDs!
There are few things that warms my heart like a peacefully snoring sleeping cat 💕
:-)
Thanks Andreas, very timely and very useful tutorial. Another reason to look forward to the weekend!
Glad you liked the video!
The reset pin is the pin 30, is labeled "run", pull it down for reset.
Thanks for the tip. I already have my reset pin. But a beginner?
@@AndreasSpiess It is counter intuitive.
It also works for accesing the mass storage mode without disconnecting the USB, assert RUN low, hold the button, release RUN. I don't feel like a lot of people know this, would you put a short video about it?
Did you try with two cores?
@@AndreasSpiess I did now, the whole thing resets.
Edit: according to RP2040's datasheet: "The chip-level reset subsystem resets the whole chip, placing it in a default state. This happens at initial power-on, during
a power supply brown-out event or when the chip’s RUN pin is taken low. "
I tried it too now. I did not see a difference if I pressed the reset together with the boot button or not. It always resets.
Fantastic video again. You are a few steps ahead of me, I will get to the 1% soon :). I am testing using the PI Pico as a robotics motor controller with motor encoder monitoring. I could get it to track encoder pulses from an irq up to around 16KHz but was measuring encoder pulses per x amount of time (Using the Timer function in micropython so don't need to calculate time since last pulse), so the code I had in the irq callback was simpler, just a increment of count. Because I want to track two motors for a robotic platform the threading will be useful, hopefully I can run the irq callbacks on separate threads without them impacting the IRQ responsiveness.
Did you check your results with an oscilloscope? 1/50us is 20kHz. So your ISR probably takes most of the processing power... IC++ it is much faster, BTW.
@@AndreasSpiess - I used a function generator to generate the irq for the test. FYI: Video of the test is here ua-cam.com/video/TWYHvw0IuUQ/v-deo.html 10:53 in. The plan if the Pico can't keep up with two motors is to switch over to an ESP32 or Blackpill , worst case I will have to code in C (but am trying to avoid it)
This is probably a little faster than my method. You still can use the second core for that task and use the first core for calculations...
A fine example of why someone needs to break this chicken/egg scenario regarding the Parallax P2. 16KHz is miserable 😁
The best way to use interrupts is _not_ to use them. Apart from the P2's eight parallel processors, its 64 identical "smart-pins" can be pretty much anything one might need. Any pair of pins can decocde/count a quadrature encoder.....even with all eight processors idling. How about a frequency of sysclock/2 ? I am not aware of any dedicated quadrature-counting device that can come close to this.
Program in C, BASIC, SPIN, ASM or combine any/all of those languages.
If nobody knows about the P2's existence then naturally, nobody will be using it. 😉
You can add your own reset button on the 'run' pin (pin #30 on the Pico). If that pin is connected to ground the Pico will reset. This will be even more needed once you start with C/C++ on the Pico, as updating the code will require a mount/upload/unmount cycle.
You are right. I solved the issue with a tiny button. I still think it should not be the task of the buyer...
@@AndreasSpiess Agreed, but a at least we have a workaround.
Come now... we can have a reset "button" by soldering a small jumper to one of the castellated grounds, and just tap the Reset pin. Bonus: If things get too boring, Dishka can start bopping the wire around. 😁 Thanks for the video! Glad to see uPython supports threads on the Pico, even if only in a limited fashion.
Of course I have my reset button now. But does a beginner has to solder in 2021?
@@AndreasSpiess Perhaps not, but they could short the pins... 🤷♂️
The weekend I was looking into C++ programming of the Pico and found your example interesting for quick testing a project. C++ is a total overkill for 99% of most projects. But industrial applications may be time critical.
I think, MicroPython is great for prototyping. Creating teh two core synchronization example in C++ is much harder, for example.
Such a nice, informative, and well-produced video. Thanks a lot.
Glad you liked it!
Grear and informative video, thank you!
I have just got my r-pico so I will reproduce the interrupt test you showed in both C++ and python :)
Check the pinned comment about the C++ reaction time...
This is super helpful. I might use C++ instead for my project if the SNES clock/latch pin is too fast for my project. I hope so, because then i might be able to get away with using 0 shift registers instead of 2 per emulated controller
Glad you found the content useful!
Thanks!
You are welcome!
Great as always Andreas. I do have to say I really dislike the use of interpreted languages(python) on embedded systems since it is such a waste of processing power compared to compiled languages(C/C++). It does however open up the world to people that would otherwise not be able use these products at all. I have worked with RTOSs for over 30 years and remember people getting fired for using blocking functions such as delay loops, sleep, pause, etc instead of interrupts/message queues. Nice to see you re-introducing this concept to the next generation.
We had this discussion in my video about MicroPython. I predict that high level languages will take over in the next few years for prototype projects where programmer's time is much more expensive than processing time.
RTOS are still a very good thing and for me also a "higher level" language where the programmer does not control everything. And you are right: They allow a very different programming style.
Also, it's good for many hobbyists who just create fun trash stuff like me. In such projects, speed often doesn't matter, but the fun and convenient process of development does. I used to program Arduino a lot, but RP Pico is a lot more fun for me.
Thanks for digging up all this info. Good prep video while waiting my first picos to arrive any day.
Glad the content is useful for you!
Thanks for your video!
I'm also very interested in the PIO speed, but have no Pico to measure myself.
I guess you could build a simple pin-> pin latency test the following way:
- Set up a DMA channel to copy the same byte into the IO-space to change the pin (there are different bit manipulation functions at offsets, like set, reset, toggle)
- use the PIO to kick the DMA
- Maybe you need a second DMA channel or DMA channel chaining to keep the whole engine running
I wait for the results of the challenge. If this PIO is simple to use I expected many contestants. So far I got none :-(
Jan, if you use PIO for example to drive GPIO pins to just generate a square wave the max frequency would be clk_sys/2 (62.5 MHz) since it would take 2 cycles to complete the code below:
.wrap_target
set pins 1
set pins 0
.wrap
i'm a subscriber of your channel for long time ago and i want you know: your content is always the best, regards from brazil
Thank you for your nice words!
Brilliant, just what I wanted to know but could not work out from the documentation or the Forum. Thank you.
Glad it helped
To all who want a Reset-Button, I used this technique.
I have a Pushbutton connected to the RPi-Pico Pins:
PIN No. 30 (RUN)
And PIN 28 (GND) -> Any GND will do
It works like Charm, no plugin/-out.
In Thonny You need only to Press the "STOP"-Button, to notify Thonny about a Reset.
You are right. I also added a 5mm button across the two pins. Concerning Thonny: Usually this works, but for the moment it does not work if you use the 2 core scenarios. and I assume when people start to use C++ and the Arduino IDE they will create some deadlocks...
Amazing as always! Thank you. Kisses to your cat from my cat!
You are welcome. I will tell her...
We all know who is the star of the show.
Great! You've answered 2 of my main pressing questions which are the use of 2 cores and interrupt response time. Disappointed with Micropython slow interrupt response time. I think I'll will wait for the official Arduino IDE support. Hopefully the existing libraries will work as well. Planning to port my application to Pi Pico for more processing power. Currently running on Arduino Uno.
I doubt that all libraries will work from day one on. It took quite a while to get them ready for the ESP8266 or ESP32.
Totally agree with you on the reset button lol. Ran in to that exact same issue when playing around with the cores.
I added now one myself ;-)
Now, to get a Pi Pico so I can officially be in the 99% group by experimenting with the information from this video. I am shocked I haven't picked up 5-10 of them already! Great video, well documented and explained. I will reference it when the Pi Pico arrives.
I hope it will help to get a quick start. Especially the variable thing took me quite some time to discover.
Yet Another Gem (YAG for short) thank you Andreas for this, I love the comparison in boards and language.
Glad you liked it. I tried to start with a typical viewer in mind...
waiting for your RTOS videos!
Coming soon!
This implementation of the _thread module is specific for the RP2040. In the ESP32 it works differently. The second core is not used there.
Then you assume that automatic memory locking is implemented between threads. However, the documentation states explicitly there is no GIL (Global Interpreter Lock) used. Which means that bad things can happen with shared access to objects. It is probably safe to read objects written by the other thread, but mutual writes, deletes etc might give surprises.
For interrupts there may be restrictions too. Documentation is a bit sparse in that area. On ESP32 you typically use micropython.schedule() to get out of interrupt mode and continue processing in normal mode. Still need to check how they did this for the rp2 port.
I also do not have more info, but assumed the Pi foundation knows what they are doing by using this example.
What is the issue with the RESET? Since you're already connecting external components to it, you might as well add a tactile button between GND and pin 30 (confusingly called RUN) to reset the chip.
I know and I did it, of course. But is this my job in 2021?
@@AndreasSpiess That wasn't quite clear from the video or I missed it. I can totally understand why they haven't added one; if you're a maker and hooking up external components on a breadboard anyway you might as well add a reset button (the pullup is already there) if you need it but if you're integrating the board on your own circuits you may not have a need for it or it could potentially be in the way if you don't want users to fool around with it (I certainly have removed reset buttons in the past). Either way I think it is fine as is and just wasn't sure whether you knew about the exposed NRST pad...
A video about uasyncio/asyncio for (single core) multitasking would also be useful to many users in my opinion.
Is it available on Micropython?
@@AndreasSpiess Yes. :-D Have a look at the uasyncio module.
@@AndreasSpiess yes, I’ve got code working cleanly using uasyncio on the Pico. I’m now, after watching this video, very interested in adding in _threads and seeing how they all work together. Fun times! (PS: great video).
I will have a look at it.
Excellent comparison. I guess I ordered my Pico's a little too soon. The reset button new release is defenately the next step ! Thnxs for this entertaining sunday morning !
I added a small one myself...
@@AndreasSpiess Indeed a valueble alternative!
Excellent video and loved to see you cat in the end!
Thank you very much!
Agreed, a reset button is important on any board that will go through many development cycles. It's not just about resetting when it locks up, but also about watching what happens when it is powered up. Yes, there are ways of doing it by button, but 5p extra for a reset button is something I'd happily pay. That said, leave the button off but put pads on the board for me to add it.
I agree. Pads would have been a good alternative. I solved the problem differently (in another video)
Hey, just as a head's up to people using the ESP-32 and Micropython, while many versions of the ESP-32 are dual core, Micropython only runs on one of them and reserves the other to perform peripheral tasks such as managing wifi without it interrupting the main micropython core. This is true even if you are creating multiple threads! So be aware that even though you're getting true preemptive multitasking in multiple threads, all of those threads still run on a single core. For evidence, look in the ports/esp32/mpthreadport.c and you'll see that all tasks/threads are bound to the same MP_TASK_COREID constant.
Thank you for the information!
Thanks for the video, Andreas:)
PIN30 RUN -> RUN is the RP2040 enable pin, and has an internal (on-chip) pull-up resistor to 3.3V of about ~50K Ohms. To reset
RP2040, short this pin low.
2021, Raspberry Pi Pico Datasheet, page 7,8. ... RTFD!;)
You are right. See my newest video
Thanks for this, it's exactly what I happened to be looking for. I was trying to find something to do with the 5 Pico's I impulse purchased. Now with some Hall effect sensors and this new found task and interrupt info I think I'm off to the races. Cheers! Oh and the cat snoring at the end is just... awww.. :)
Enjoy your project and the new "feeling" of programming MicroPython...
Excellent, very well explained. You have another subscriber.
Welcome aboard the channel!
Thank you for alerting me to the Pi Pico. What a useful device for mains powered motor control. I can have one core monitor the mains and set some variables whilst the other one manages the amount of chop the motor gets. Also £4 for an MCU on a board is really cheap.
You are welcome!
This is a great video. You make it sound so simple but I believe you did a lot of hard work to get it done to this level. On a side note, I think that its best we call release() function after accuire() just to release the batton. Just an idea.
Glad it was helpful! Indeed, most of my videos need some research!
Twist: now that we have watched the video as all pico users do, we are no more in the 99% club. Because Andreas educated *all* pico users. The 99% already know about interrupts, two cores etc 😎
Hurry up if you want to be in the 1%-range (for a second).
Interesting point of view. Maybe a topic for a PhD work for a a budding epidemiologist ;-)
Thank you for sharing this global variable 'trick'. That "local variable referenced before assignment" error almost drove me crazy :D
Me too ;-)
Andreas, I am confused about your example for ‘synchronising’ the two cores. It merely synchronises the stop and start of each core so that they never run together. How useful can that be? What’s the advantage compared to a single core that runs tasks one-by-one?Two tips for a next video: hardware debugging using picoprobe (C, C++) and programming the PIO! The PIO is what sets the RP2040 apart from the rest... and it is not too hard to write short programs for it. Correctly used, the PIO can dramatically increase the speed of the processor. The pin side set feature in fact effectively allows it to execute two instructions per cycle!
1. Using two cores creates a lot of hassle compared to only one core. Two cores are faster than one core of the same type.
2. I still wait for a useful application for the PIO. This is why I made the challenge. VGA or HDMI on a MCU with this small RAM is nothing for me
3. I will start with C++ when it is Arduino compatible. Right now it is too much a hassle for me :-(
@@AndreasSpiess Andreas:
1. If speed is the target than the easiest and most effective is certainly just use a faster clock. But this will not necessarily improve precision of timing, which is not rarely the reason why a controller (without os) in used instead of a microprocessor like e.g. the raspberry pi zero. The second core, and even more the second core attending the PIO, should excel in that!
2. I think the demo with the PIO producing HDMI signals is meant mainly as a demonstration of (1). Very impressive that this can be done with a non-specialised microcontroller of a few €, but if you really need HDMI, it is quite likely you also need/want an os and then you’re better off with a microprocessor.
I see more applications for the PIO in accommodating serial io that is not supported (or not in enough numbers) in hardware (like eg CAN controller, Serial RGB Led) or when multiple fast precisely timed outputs are needed and for which otherwise a FPGA would be needed. I am thinking of multiple coordinated motor controls like eg. 3D printers, drones and the like. These work with low-power processors as well, but when precision and speed need to improve this won’t work anymore and a processor like the RP2040 is, in my opinion, a fantastic fit.
3. Here I fully agree! It is an incredible hassle to even setup a build and hardware debugging environment for now.
Como siempre, señor Andreas, un vídeo muy bueno y muy buena su explicación. Aún no he podido conseguir la placa Pico pero después de ver este vídeo, tengo aún más ganas!
¡Estoy seguro de que recibirás uno pronto!
on the pico pi , ctrl D will perform a soft reboot. and if you place a button between Ground and Run pin, it works to program like on the esp8266 and the 32.
You are right. I added this button in one of ma next videos ;-)
Hey Andreas I love your videos, always with interesting information, and thanks for add spanish subtitles, It allows me to share your videos with my studends. Greetings from México
I do not add the Spanish CCs. It is Luciana, an Argentinean student. I only provide the small fee ;-)
Clocking an ASYNC counter works best for the frequency counters. PIC's for example have nice async counters. I've created counters that handle hundreds of megahertz with pre counters and the async counters with no visible jitter. That was ages ago.
You are right and I assume the Pico also has counters. I just needed a simple and understandable scenario for demonstration.
Great job with the video as always 👍
Thanks for sharing your knowledge to all of us 👍😊
My pleasure!
Did someone eventually make the pulse counter PIO? I want to read the LMT01 digital temperature sensor but the interrupts are too slow. I also hard-wired it to GP22 so that's a PWM-A pin. Otherwise I could have used it as a PWM clock input pin. My only hope is PIO at this point.
I do not know. Yes, 88kHz is probably quite fast for an interrupt. Should be possible with the PIO.
informative video but have to give 2 comments.
1. The absence of the reset button can be easily covert by a external button especially when you work on a breadboard. It may be needed during development but once you past that stage its no use any more.
2. Comparing interrupt service handling speed between python and c++ is like comparing the 0-100 km/h between a Volvo V70 and a muscle car. They both are cars with combustion engines but the V70, although might be more comfortable for most people, isn't up for that job. Phyton != Made for speed because it's interpreted
. Try writing the same code with in the Pico C/C++ sdk and compare again. My guess is that they will be in the same range.
You are right with c++. A commenter already did it.
@@AndreasSpiess Looking at the video I tried to look at the comments but my phone didn't want to expand the comment section. Later I found out that it's was a double comment. Sorry for that 🤭
No problem!
Where in the documentation did you found that multithreading is implemented using multicore ?
The MicroPython documentation regarding threads is quite minimalist and point to the CPython page, which does not speak about cores...
Beside MicroPython also run on single core platform...
Thanks
I do not remember where I read about it :-(
Great stuff!That cat is giving me a good idea though, sleeping sounds great!
Definitively we all can learn that from her ;-)
Thank you Andreas, I have been looking for these topics on the Pi Pico and now you provided them in a excellent manner.
This is great stuff!
Now I only have to find out how to use the Pi Pico as an I2C slave device. I can easily find info on how to use it as master, but nothing on how to use it as a slave.
Could you be persuaded to look into this, I think it will be highly appreciated by many people using the Pi Pico:-)
I2C slave is not easy and it tool a while till I found it out for the ATTiny back in the day. In addition, here we need it for Micropython...
Your video on the ATTiny85 controlled array of ultrasonic sensors communicating over I2C was excellent, and I learned a great deal from it. And you made it look relatively easy, so I began to think that I was missing something since I couldn't find anything on the Pi Pico as an I2C slave device.
Is it really that different from the usage as a master? From my perspective the main diffrence is that slave devices have to have an address assigned, the rest is "just" sending and receiving - but I've never made an I2C library, so of course I wouldn't know the gory details.
I do not know if it was difficult. Maybe somebody with the knowledge should create it.
reset/switch button on the usb cable it self - is the way forward, even if it's not the way we are used to
In the next video I showed how I solved the problem...
Nice ...you have the Rasta colors on your lights :)
:-)
12:53 Can't you just unplug the other end? Or short the reset pin to ground? Or short vcc?
You can ground the reset pin, of course. This is what the reset button would do. Unplugging also helps, of course. But in the next video I added a simple reset button which is much more comfortable.
Gratuitous comment to boost engagement.
Also, snoring cats are cute.
Thank you!
Can't wait for raspberry pi pico Wireless version
Keep an eye on the Arduino Nano RP2040 Connect.
I do not think if will appear soon. What we will see is a Pico and an ESP32 for WiFi from Arduino.
@@AndreasSpiess maybe an topic for the next video. Using an Esp01 as wifi addon for the Pico...
I wait for the code for the -C3...
Helpful information
Thank you!
Yes, now in HD again :-)
I think if you need to power off a micro USB plugged device, the most convenient way to do so is a cheap USB hub with switchable ports. At least i would not want to miss it.
Cheers from Bulgaria
30fps especially for you ;-)
You are right. I solved the issue with a tiny button. I still think it should not be the task of the buyer...
I made myself a cable with a reset button. Works for every mcu =)
at least we have some innovative people here, I wish more engineers are like you and well done, problems can be solved easily with a bit of innovation instead of complaining
I soldered a fitting button across the two pins. But is this my task in 2021?
@@AndreasSpiess A great innovative and engineering task accomplished, well
done : )
Nice video! Waiting for someone talks about PIO!
You find alredy people demonstrating some example from the Pi foundation. For the moment I have no example where I could use it.
Great video as always Andreas, you made this look quite simple! May I ask you to raise the volume of the audio a bit? Thanks!
I always use the standard for podcasting. But I do not know what UA-cam does with it.
Your accent does not sound swiss, but something undefined :D Thanks for this Video tho, subbed
Welcome aboard the channel!
Question about the dual core threads and the baton - if each thread stops and waits to get the baton, then only one thread is running at any one time - what is the benefit of doing this? It seems that it would be faster to just run in one core and not have all the baton passing overhead to deal with.
You are right. But if nobody has to wait, you have double the power.
Wow, this video is great, I'll check out your other ones.
Glad you liked it!
You can surely reset the pico by pulling the RUN pin LOW that reset the pico and its written in the manual
You are right. I solved the issue with a tiny button. I still think it should not be the task of the buyer...
@@AndreasSpiess yes you are right its shouldn't be our issue
and thnx for the replay
I love your videos
Grüße aus Deutschland
one important note, we can use the two cores OF PICO on arduinoIDE earlephilhower's board by simply calling void setup1() and void loop1() .
Thank you for the info!
Great video and you get a nice cat mindful moment as well😀
Thank you for watching till the end ;-)
Thanks! a lot has now become clear.
Great to hear!
Just fantastic again Andreas! Thank you!
You are welcome!
That is all awesome but I would consider using a context manager for locks - because it ensures that the lock gets released no matter what happens inside the code so e.g. if there is an exception the lock will still get released e.g.:
a_lock = _thread.allocate_lock()
with a_lock:
print("a_lock is locked while this executes")
I do not get your point :-(
@@AndreasSpiess oh, don't worry - it's just a small thing. One of the good features in python is the "with" statement. It allows you to free resources like open files or sockets or locks automatically. You don't have to remember to call the "release()" function for the lock because you know that when the program exits the "with" block then it will be automatically released. Normally you could say "so what - I can just call release myself and it's only 1 line?" But the good thing about a with statement is that it also works if there is an exception inside the block or even a return statement. So for files: e.g.
def find_end():
with open("myfile.txt", "r") as f:
for line in f:
print(line)
cleanline=line.rstrip() # remove LF
if cleanline == "END":
print("Found END")
return
elif cleanline == "MAJORERROR":
raise Exception("There was a major error")
print("Didn't find END")
We don't need to call f.close() in this program even though there are several possible exit points because the "with" statement ensures that f.close() will be called even if there is an exception or if the function returns.
With locks in Micropython it is the same:
a_lock = _thread.allocate_lock()
mydict = {"alice": 12, "bob", 12 }
with a_lock:
print("a_lock is locked while this executes")
print(mydict["john"]) # Keyerror exception but the lock is still released.
Sorry if my explanation is not good - there are better ones on the net.
In the meantime I tried it out and it worked. Indeed a nice addition. For the video, the lock commands were probably easier to understand. For as a programmer I definitively will use your proposal.
Looks like the RUN pin is actually the reset input. Use a push to make switch on this pin to ground to reset. Has an internal pull up. First time I've ever seen a reset pin called RUN.
You are right. I added a small switch across RUN and GND.
Great video sir!. Waiting the freeRTOS video!!!
Coming soon!
One weakness of the ESP32 with Arduino C++ is it cannot be a slave_receiver/slave_sender in an I2c 'Wire'' communications setup. Does the Pico have that capability ?
I do not know.
To reset you don't have to unplug the micro USB connector, but also the other side of the cable OR just use a micro usb cable with a switch.
I found an even simpler solution (in the next video)
Or just connect the RUN pin (30) to ground.