1. It's at cheap ebay/aliexpress prices but is a first party board supported by the chip manufacturer, not a third party clone.
2. The full raspberry pi ecosystem has a good range of hardware and software, the pico will hopefully see the same.
3. The internal architecture has some fun features. The DMA engine supports chaining DMA channels and one set of DMA operations can program and trigger another channel. Plus you can trigger transactions on when they're needed by the endpoint or on a timer. You can program in complex behaviours with this and just set it off and go without needing further CPU control.
More unique than the DMA is the PIO, 8 programmable state machines that have FIFOs and port access. This allows you to add support for protocols you don't have hardware for. This avoids bit banging and gives precise real-time control. You can do things like drive VGA and there's even an HDMI demo (possibly a bit too hacky to be used in production though).
I've just had one arrive today, going to spend the weekend seeing what I can do with just DMA and PIO whilst the CPU sits idle, maybe dealing with the occasional interrupt.
RPi foundation has done a great job at making it's product available to buy at the time of announcement in over 50 countries and I think that's underrated.
It shows 5 different websites for me to buy in India, which is not usually the case here for new hardware except few exceptions like Nvidia Jetson; if at all they ever make it to the country. Also RPi foundation/partners seems to be actively working with the Govt. to keep the prices competitive.
To give you a comparison, PinePhone costs >$200 (+tax) to get it here that is if at all it doesn't get blocked at the customs due to licensing requirements for telecommunication hardware, taxes for CBU(Completely Built Unit) smart phones, blockade on shipments from the country to the North. That's a tragedy considering huge number of Linux enthusiasts in the country and that alternate smartphone OS can indeed help Govt.'s self reliance goals.
P.S. That was not to diss on Pine64's efforts, but to show the state of enthusiast hardware availability in India.
OMG. I had forgotten. What a mess. Politics is a drag
There were educational launch videos out from the authorised Indian resellers on the day of launch, even.
This IS the other boards!
I think if you look here:
Scroll down and you'll see the RP2040 has been released on many boards simultaneously.
- Adafruit Feather RP 2040
- Adafruit ItsyBitsy RP 2040
- Arduino Nano RP2040 Connect
- Pimoroni PicoSystem
- Pimoroni Pico Explorer Base
- SparkFun Thing Plus – RP2040
- SparkFun MicroMod RP2040 Processor
- SparkFun Pro Micro – RP2040
The form-factor on the Pico is also a little nicer than and ESP32.
Pin duplicators are also available. This idea has a lot of potential, as it allows one to break out modules. It's much better than the Arduino shield for two reasons: 1. shields have quirky pin alignments, making it hard to create your own boards. 2. shields stack on top of the other, obscuring the layer below.
The Pico will be another stellar success from the Pi Foundation. I have no doubt.
I once worked around a very unfortunate hardware shortcoming in a DMA engine by doing exactly this. Each channel supported a list of descriptors, so I used the last descriptor to actually perform DMA operations on the configuration registers of the other channel.
The possibilities are endless with this kinda stuff
So is the time wasted when there are bugs in the docs :P Don't remember the exact chip, but it was on the first job I had and it took me weeks to find out why the thing didn't want to do what I told it to. Turned out some names of registers were swapped in the docs. But indeed, once I figured that out, it was really nice to work with and things like interleaving data from multiple ADCs just worked with basically no CPU interaction.
I am excited about the DMA and PIOs having used BeagleBoard PRUs, but what about the quality of the ADCs/DACs?
Isn't all the talk of hard real-time applications and so on somewhat moot if those aren't high quality enough?
(afraid I haven't had time to read the datasheet yet!)
> The RP2040 ADC does not have an on-board reference and therefore uses its own power supply as a reference. On Pico the ADC_AVDD pin (the ADC supply) is generated from the SMPS 3.3V by using an R-C filter (201 ohms into 2.2μF)
Which doesn't sound promising and I don't see a DAC in the RP2040 datasheet.
Less nice that the ADC scale will be affected by power supply offset, though that all depends upon how "good" the board 3V3 is. The bandgap and error amplifier on the DC-DC converter IC is good at least-- max +/- 1%.
It does have some examples and the Pico SDK has various PIO programs you can look at for inspiration. The getting started page links to a few projects including the HDMI/DVI: https://www.raspberrypi.org/documentation/pico/getting-start...
PHY level support, yes. But nothing higher than that. You would still need to implement the protocol in software for the most part. So at 133Mhz, it’s probably fast enough to toggle a CAN transceiver correctly, but would have very little comprehension of bus arbitration or CRC or what makes a message valid (RTR, IDE, DLC, etc).
It’s very cool, but the example they used of making a simple waveform for the serial driven LEDs is more what they were going for.
That example is pretty much already taken care of with an SPI or PWM that runs off DMA though. You can easily make a waveform for those LEDs. I’ve never understood why the enthusiasts use bit banging and special hardware.
The physical layer uses differential wired-AND scheme where any device can pull it into dominant state but recessive state is possible only if no device is driving the bus. In most cases CAN requires a dedicated HW transceiver, I would be pleasantly surprised if Pico can pull it off without external components.
The point is the PIO may be great at wiggling pins, but that doesn’t mean you can “support hardware protocols” you don’t have peripherals for. It means it gets you a pin wiggler, and the rest of the protocol would have to be software.
Perhaps you were thinking of RS-485, which actively drives both bus states and therefore can get away with unterminated buses at low bitrates / short runs.
You are forgetting that CAN can work at short distances without being a differential bus at all.
I mention this where I wrote “no transceiver AND no termination”.
You just lose out on the differential pair... but even that isn’t required when you look at fault tolerance CAN in single wire mode, or single wire CAN PHY transceiver options, as to the original point about termination, I can’t remember if Single Wire CAN is terminated in a loop or pulled up or down, but I promise it’s not 120ohm termination like differential CAN is.
Imo, safer to say that CAN is a protocol that can take many physical forms, and one of them is direct A to B modules with no termination.
Arduino “took off” because it was easy and standardized. You and I could probably lay hands on a 120R today, but fewer than 0.01% of the population could without ordering something (at which point you could just as well order an MCP2515 module).
It’s a “what’s in my hand right now?” hurdle not an “it’s technically advanced” hurdle that makes 0 external parts such a selling point.
- NMEA0183, which is electrically RS-422 (similar to the ubiquitous RS-232, but only sometimes)
- NMEA2000, which is basically CAN
- Seatalk, which looks like NMEA0183 but is electrically inverted (1 is 0 and vice versa) and also uses weird byte lengths (9-bit?)
- Seatalk-ng, which is basically NMEA2000 with a few more message types
A $4 device that can translate arbitrary weird PHY protocols into a bitstream on a USB port is awesome in this world.
This will get you wiggling output pins, not a replacement for dedicated protocol hardware or a actual programmable logic.
If we look at Cypress’s PSOC, that’s real FPGA fabric on their micros and it’s barely capable of making some hardware protocols. I’m pretty sure there isn’t enough there for CAN going back to that example.
Speaking of education, does anyone have a favorite mechanical device (toy car, robot, etc) that is compatible with a microcontroller that can be used for teaching little kids? (Month 10 of learning-from-home dragging on here...)
PIO is still pretty cool from an ease of use and cost perspective though.
EG, this one gives you a nice breakout board and a few sensors and switches. It also gives you an instruction book. You'll also need to buy the actual Micro:Bit too. This kit has a website for more projects here: https://tinkercademy.com/microbit/
You program the micro:bit in MakeCode in a webbrowser. That also has an emulated device so you can see what it's like without having the actual board.
And you can program the Micro:Bit with Python.
It looks spendy, and it is, but the colour-coding of the cables and the keyways of the sensor PCBs make it friendly for children.
There are lots of kits for micro:bit https://www.elecfreaks.com/micro-bit/kits.html
You may want to wait for Version 2 to be released. https://www.element14.com/community/docs/DOC-95670/l/introdu...
You can already buy it from Ali Express.
That was my take on it. I first saw it and thought of my adurino nanos. Then reading the specs, I wondered why not use an ESP32 with wireless etc. I think they are only $3 more. Standardization was all I was left with.
So it might be worse suited to battery-powered applications, unless you do some power managment.
Not that I know what you would necessarily do with more of that compute.
Wondering how much faster I can make this, or a Pico? Before I lose all the benefits of Linux.
I bought an Arduino starter pack a few years ago, and it was neat, but I never ended up doing much with it beyond the first week or so.
I guess this would maybe suffer the same fate.
What projects do people do with microcontrollers that don't just end up being silly gimmicks?
Some example: Temp monitoring Weight data collection Cheap wifi mesh :) And a bunch of thing with rfid and ble beacon
For dashboard we use thingsboard.io
Edit: There're many site mentioned that you shouldn't use arduino for manufacturing because it isn't hardened etc. Please study it first :)
I also built my own wifi speaker using a Raspberry Pi Zero W and an open source implementation of the AirPort protocol, but we've stopped using it because it was flaky and needed regular reboots. Bluetooth turned out to be (barely) less annoying.
One of them is an e-ink display outside my office door that either displays today's date, or a warning sign stating that I'm in a meeting.
The warning is triggered by a switch on another microcontroller that sits on my desk (an M5 Stack, so it has a nice enclosure & screen).
I've always wished I had taken a hardware course or two while in University. I can't seem to think of anything practical enough to keep my motivation while I deal with learning about all the actual hardware bits.
I mean, I've written code for microcontrollers before, but it's hard to beat something where all the building blocks are already done for you; leaving you only the job or assembling them in the product you want.
If you know "normal" programming (I do web dev), it's relatively easy to get an Arduino and start copy-and-pasting example code until you've got something cool. The syntax itself isn't too complex, and most of the really hard stuff already has a library built for it.
Arduino code can also be used on the ESP8266 / ESP32, which is an amazing, <$2 (shipped!) microcontroller that's Wifi-enabled.
They already did a peripheral chip for the RPi. Now they have their own microcontroller. I suspect in a few revisions they'll have their own host processor to replace the Broadcom one ...
It's a great achievement for a very small team.
Including me. I actually prefer this to the GPIO, though it adds one more component. An advantage is that I can move my hardware projects between RPi and other computers in the house including my nice comfy and fast desktop workstation. With a bit of care, my Python support software runs the same on RPi and Windows with no code changes.
Also, if you keep things within the Arduino ecosystem, it's easy to upgrade or downgrade your microcontroller as needed, with only minor changes to your embedded code. What I'd like to know is if the development environment for this board is as nice (or better, can always hope) than the Arduino environment.
Could be a nice mix for projects where the size of another PCB would be problematic. The target audience would probably be smaller and I doubt the RPi Foundation would be interested considering their focus on education, but I would probably buy one.
- STM32 "Blue Pill": cheap, uses common STM32 ARM parts, but generally available on places like ebay/alibaba
- ESP32: has wifi and bluetooth, less good documentation but great performance/$
- Raspberry Pico!
Truth couldn't be far from that. Its completely the opposite - ESP32 toolchain and docs are superb: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/
And there is ESP32.net: http://esp32.net/
1. Why didn't they use the same GPIO header as a full-sized Raspberry Pi? That would allow people to reuse some of the same headers. Seems like a missed opportunity there?
2. Since it has no WiFi and it costs more, this compares unfavorably with the good old ESP8266 in some important respects. Why would you pick the Pico?
EDIT: I'm being downvoted to hell. I'm sure that the new Pico will find buyers, in fact, I wouldn't be surprised if it sells out based on brand recognition alone. I'm just trying to ask some legitimate questions as to what this has to offer over the competition in the microcontroller space, which is a crowded market, and how it fits into the existing RPi ecosystem.
As for the ESP8266 (not ESP32), you can find them on eBay below $3 shipped. The ESP8266 is already quite fast and capable for a microcontroller (it's overkill for many applications). I agree that more IO pins could be a differentiating factor.
I'd guess that in a few versions/years they'll come out with an embedded Wifi onboard.
Though in the mean time running code on just one of the cores shouldn't take a lot of work.
NORMAL: You get to select what is clocked here, except for the CPU. CPU will turn off clocking of some of its components if you are running a sleep instruction like WFE/WFI.
SLEEP: If both processors are in a sleep state, and no active DMA requests are running it automatically switches to this mode. You can once again configure what components are clocked here. So you could leave say just RTC and PIO powered up. This is less of a true low power mode, and more of just a way to automatically switch to a different set of clocked components if the bus is idle, so as to further reduce power consumption.
DORMANT: Ring and crystal oscillators stopped, zero dynamic power used in default configurations. Only a pin or RTC interrupt can wake the system from this state. Note that any externally supplied clocks will continue to be routed, and PLLs will run if not powered down. Thus technically this mode can be used to fully stop the CPUs while letting other accessories run from an external clock. The nominal intended usage is to continue to let the real time clock run, but the PIO could be run too/instead.
This is the first thing I look at before deciding to invest in learning a new chip. I specifically look for something that is guaranteed to be available for a long time and not change.
> Are you planning to make RP2040 available to customers?
> We hope to make RP2040 broadly available in the second quarter of 2021.
I have been turned off from some Arduino projects in the past due to the C/C++ requirements, but MicroPython apparently runs on many microcontrollers and makes it pretty simple if you know basic Python.
Once you get a design working, if you need the efficiency and power gains from C, then you can drop down to that level. But with the Pico having a 133 MHz processor, the overhead for many projects isn't too bad, and it's still going to be a lot more efficient than running something equivalent on a Pi Zero.
I wanted to build a smart-lock, but all the boards either also have Wi-Fi on-board (that eats a lot of power) or don’t have anything at all.
I'd recommend the Adafruit NRF52840 Feather or if you want a smaller version (that doesn't include a LiPo battery charger) get the ItsyBitsy nRF52840 Express.
I haven't used the Arduino or CircuitPython programming environments, I've just been using Arm GCC and Nordic's SDK.