Hacker News Reader

Comment by geerlingguy | Hacker News Reader

I got some hands-on time with the Pico and made a video for it [1], with a tiny project I decided to try out with MicroPython.

It was the first time I'd ever tried MicroPython, and I have to say I'm a huge fan. As a dev who came from PHP/Javascript into Java and Python (heh, not quite the same thing but that's how life was), I find MicroPython a lot more intuitive than the Arduino language or raw C.

I also learned that Adafruit maintains their own flavor, CircuitPython [2].

Definitely worth trying out if you haven't, and know any Python!

[1] https://www.youtube.com/watch?v=dUCgYXF01Do

[2] https://circuitpython.org

View on HN

Personally I really like the following boards for general projects:

- FeatherS2 (runs CircuitPython): https://unexpectedmaker.com/shop/feathers2-esp32-s2

- TinyPICO (runs MicroPython): https://www.tinypico.com/

They're both designed by the same dude. I'm not affiliated with them, I've just tried dozens of microcontroller boards and these two are easily the winners in my book for versatility in hobby projects.

These boards are absolutely jam-packed with features (capacitive touch sensing, RGB indicator LED, Li-Po battery management, ...) but moreover support Bluetooth and Wi-Fi. That's a major problem with the Pi Pico. You'll end up with a mess easily 2-3 times the physical size of the Pico to get Wi-Fi on it in the form of HAT-like boards, whereas the above microcontrollers have everything on-board.

By the way, CircuitPython is for the most part a real pleasure to use. If you slap an Adafruit display on them, with about 4 lines of code you can have the Python interpreter's STDOUT go straight to the display. The boards also emulate a USB drive that exposes all the Python code so you can program them with literally zero additional software.

I've only just got started in electronics, and I have to say I find the range of options to be bewildering - what do you think of the Adafruit Feather, Teensy, or Arduino Nano?

(I think they're all comparable products ... apologies if not)

As stated elsewhere, all are great. If you just want to get going with CircuitPython on some hardware, I really recommend Adafruit’s CircuitPlayground series[1]. They have things like LEDs, temp sensor, speaker, mic, gyro, buttons, switches, and touch-capacitive pads all in a tiny form factor which means you don’t have to get into breadboarding, soldering, or wiring anything up to do an amazing variety of things and get your feet wet.

[1] https://www.adafruit.com/index.php?main_page=category&cPath=...

Nope, these are all pretty comparable. And from the beginner point of view, they're all similar. They can all be programmed using the Arduino IDE and language, and all except the Nano can also be loaded up with Circuit Python and programmed in scripts rather than binary.

They're all pretty simple to use, with good documentation. I would probably add an M5StickC to this list, as they come as a nice modular package, with case and screen and a bunch of fun things for experimenting.

Since they can all be programmed using Arduino IDE, which has good documentation and forum support, you don't have to deal with a bunch of external toolchains and whatnot (though I would suggest VSCode with the PlatformIO plugin as soon as you're comfortable with the programming side of things.)

Ordered most to least simple: Nano Feather M5StickC Teensy

Ordered by most to least powerful: Teensy M5STICKC Feather Nano

Ordered by most to least peripherals: M5STICKC Teensy Feather Nano

Ordered by most to least reliable: Nano Teensy Feather M5STICKC

I haven't used all of these products. I have used several generations of Teensy for projects. I'm a big fan! They're powerful, well thought out, and inexpensive. Paul Stoffregen (creator of the Teensy products), is amazingly responsive to users. The only downsides (for some) is that you have to know C to program them. You can use the Arduino libraries if you want, which provides you with a lot of functionality with very little effort. If you have a specific project you'll be manufacturing, you won't want to use something like this. You'll want to design your own board that only has what you need. But for prototypes, small run, or one-off projects, it's hard to beat the power of a Teensy 4.

FYI there are already new Feather and Nano versions in the works that will have the RP2040 chip!

What do you think of Wemos D1 in comparison? They also seem to have onboard WiFi and Bluetooth, and support micropython.

I don't know too much about its battery management, though. The microusb port seems like a good thing?

The D1 Mini is my favorite ESP8266 board right now. It has built-in WiFi of course. It is physically smaller than a NodeMCU, but still exposes enough GPIO pins to allow interesting peripherals. The built-in micro-USB connector and USB-Serial chip means that programming it is easy, it doesn't need a separate programmer like the ESP-01. Unlike the ESP-01, the D1 Mini exposes the GPIO16 pin (aka D0) which is required to wake the board from DEEP SLEEP. The ESP-01 requires a soldering hack to enable DEEP SLEEP.

The LDO voltage regulator on the D1 Mini is so good that in DEEP SLEEP mode, it consumes only about 200 microamps, so I use it directly in battery-operated applications. In comparison, the ESP-01 goes down to 40 microamps in DEEP SLEEP, so the overhead of the voltage regulator is only about 160 microamps. (Edit: Both of those numbers include the DHT-22 temperature sensor).

My outdoor temperature sensor uses a D1 Mini with 3 x AA NiMH batteries feeding the voltage regulator, and it lasts 4 months. It wakes up for 5 seconds, every 15 minutes, reads the temperature and battery voltage, then transmits the info to an MQTT server. In theory, the ESP-01 (w/ soldering hack) would last 6 months on those batteries, but the difference isn't worth the extra hassle of an ESP-01 for me.

My biggest gripe about the NodeMCU honestly is that it's almost impossible to find one without the headers pre-soldered. The D1 Mini and the other microcontrollers I recommended all can be bought without headers soldered.

Headers pre-soldered is a big dealbreaker for me. I almost exclusively use JST-EH connectors for personal projects in place of headers. They are 2.5mm spaced so they fit in 0.1" spaced pins, and are much more secure than headers and won't easily get pulled out and jumbled up.

I used a Wemos D1 ESP8266 in this project [0]. Plenty good for the project at hand. I heard they have an ESP32 version now?

For one-off personal projects I'd probably still reach for a TinyPICO or FeatherS2 though because of the additional features they have, and that they have a Discord server you can ask questions to, but if you're deploying a dozen of them in your garden and want to save money then yeah, the Wemos would probably be a good bet. Support and documentation is a little sparse though, in comparison.

[0] https://github.com/dheera/shadow-clock

A great thing about the ESP32 in my experience is the 5v out. 3.3v can often power things that claim to need 5v, but bad things happen, like reboots. Some claim to have had damage too, but that hadn’t been my experience.

Oh wow, the TinyPICO is awesome! Back when I was hacking on the ESP32, this form-factor was uncommon and very expensive (a single guy on Tindie sold them). How is the antenna performance? I'm suspicious of anything that doesn't have one of those Proant thingies.

EDIT it even has 4MB PSRAM! Very, very nice.

EDIT2 ok it does have a Proant antenna, and its 20$, so not that cheap. But ok for what you get I suppose.

I haven't had any major issues with the antenna, although I've only really used it around my home Wi-Fi. It occasionally blips and I have some reconnection logic for that but overall it's been fine for indoor use. I have a DIY smart lock and DIY smart thermostat (that literally sit over the real lock and real thermostat -- I rent my apartment so I can't change those out) running off a TinyPICO each and they've been doing fine as far as the Wi-Fi connection goes. They just run a HTTP server on my LAN and I can set the lock and thermostat states with a simple REST API. (I can't stand the complexities around interfacing with Google Home and Alexa ...)

I also used a TinyPICO's BLE interface to connect a phone with a motor driver for a mini telepresence robot [0] though a TinyPICO was probably overkill for this use case. My thinking was really just future-proofing it in case I wanted to add more stuff to the robot.

BTW the Wi-Fi only seems to support 2.4 GHz. No 5Ghz.

[0] http://github.com/dheera/robot-tethys

Yeah still waiting for a new chip that has at least as much SRAM, number of cores and clock frequency as the original ESP32, but with integrated USB and 5Ghz WiFi. What Espressif have released so far are just cost-optimized variations.

One alternative with both 2.4/5GHz wifi+BLE is the RTL8720DN. More here: https://www.cnx-software.com/2020/01/17/realtek-rtl8720dn-du...

Until recently, the only devkit you could find was the Seeedstudio Wio Terminal. Just came across a devboard on AliExpress for < $6. Looks interesting.

I have briefly experimented with Mediatek and RTL wifi SoCs, but found SDK and documentation severely lacking / buggy. What’s your experience?

Is 5GHz matter for IoT use case?

Yeah, the TinyPICO has everything you'd want for building your own IoT device (e.g. a smart switch) but at $20 you might as well buy a pre-made device for the same price. If they could get the price down a bit more it could hit a real sweet spot. Still an awesome board though, kudos to them.

MicroPython is also a lot slower than Arduino style C++. Like, a LOT. So much slower that I am sort of amazed that MicroPython has any traction at all.

An 80MHz microcontroller running C can go about as fast as a 800MHz microcontroller running MicroPython, if the benchmarks a friend showed me are accurate.

An 80Mhz microcontroller is a lot cheaper than an 800 MHz microcontroller, though the difference is getting smaller.

The maker landscape is insanely wide these days, MicroPython has traction because someone with little prior experience can look at the script, say "I understand some of that" and get hacking.

I see it as the gateway drug of embedded development, you get pulled in by how easy it looks and then you move one to a more performant language when you need it.

Totally agree here - IMO MicroPython is great for simplifying embedded development for beginners and broadening the group of people who are interested in taking the plunge. Arduino had/has the same impact (both the hardware simplicity and C SDKs in the IDE). It's intimidating jumping into embedded if step 1 is "use the vendor-supplied startup code to enter into `main()`, then start writing baremetal C with so-so (and in some cases no) C lib support owing to being on a resource constrained platform." MicroPython doesn't offer a full Python standard lib implementation, but the standard Python syntax is definitely more accessible to a broader group of developers who may not be familiar with C or Rust.

OpenMV has used MicroPython to great effect. It's really impressive what they've done, especially in the realm of porting vision algorithms to constrained platforms like Cortex-M's.

...or not and realise that professional development is not only possible in MicroPython but can significantly reduce development time - and costs - to your client.

(I work for a company that makes medical devices that use MicroPython.)

Did not want my comment to come across as discrediting people legitimately using MicroPython. It was more of a comment on how embedded dev was a wide field that encompasses a lot of use cases.

I'm not particularly surprised. Many hobbyists just need their microcontroller to periodically poll some sensor data, or actuate a servo when a button is pressed, etc., and the convenience of programming in Python trumps a 10x speed improvement.

It may not always trumps a 10x shorter battery lifespan, though.

The difference in real-world use isn't nearly so pronounced in my experience. MicroPython is written in C, so whenever you're using modules implemented natively then you're only paying for a small boundary crossing.

For example, all of the machine API is typically very fast. I'd be surprised if you'd notice a significant improvement sending SPI buffers directly from C. But it's way more convenient from MicroPython - especially considering you can do it live at a REPL.

If you're spending a lot of time processing in MicroPython then yes, you'll notice a perf hit. But, if that's the case, carve out the perf-sensitive code and create a C module in MicroPython; it's straightforward.

It's akin to the way that CPython is considered slow but by using libraries like numpy or pandas the real-world performance is decent.

I think hardware cost is secondary for hobby projects compared to learning curve cost. C is very intimidating (and annoying sometimes) compared to Micropython. It definitely promotes bad coding hygiene but I don’t really care if I just want something quick and dirty for my own small project.

C is intimidating mostly for memory and strings handling, but on a microcontroller you wont use those, leaving only straightforward parts.

This is my experience as well. You're almost always printing strings if you're working with strings at all.

I'm not surprised. I don't doubt you one bit about the performance difference, but, given how much fun I've had toying with MicroPython the BBC micro:bit (16MHz ARM Cortex-M0), I just don't care. I'm comfortable with C, and have had plenty of fun with Arduino, and I would happily switch to it if my performance needs required it. But, insofar as MicroPython lets me get from idea to working thing much more quickly, and insofar as my ideas are never something that require much performance, MicroPython boards have become the thing I reach for first when I'm looking to have some fun after dinner.

Memory is also gonna be far smaller as well.

x10 slower is better than I expected.

I did some micropython for a video series I made [1], and I have to say, it took me right back to the days of owning a ZX Spectrum - accecssing a REPL directly over a USB serial connection was very much like these machines, although I know it's not something that everyone thinks is a good idea...

I like the idea that the main interface to the device is to program it in some way or another, and I'm sure that was what led my generation to be as computer-literate as they are.

I'm going to order a Pico today!

[1] - https://realpython.com/courses/getting-started-micropython/

> it took me right back to the days of owning a ZX Spectrum

Is there any kit that includes a screen (with a case) and a small keyboard, and a manual for (say) less than $100?

It would be great if there was a self-contained kit that you could give to a child, so that it can have that same "home computer" experience as in the old days.

I.e., something like this, but with a modern form factor:

https://en.wikipedia.org/wiki/TRS-80#/media/File:TRS-80_Mode...

Raspberry Pi 400 is almost that- more like a Commodore 64 in that it doesn't include a monitor.

Yes, it should be sub $100, and include a monitor.

Buy a Raspberry Pi and take a look at your local recycling center. You can find some quite decent monitors (even HDMI), keyboards, and mice in their electronic scrap bin for free.

@amelius: there's a bunch of RPi-based laptops, but at those price points you might as well go with a T60.

https://magpi.raspberrypi.org/articles/the-best-raspberry-pi...

A 7" display + case + mini Bluetooth keyboard could be a good middle ground, too.

I think the one thing RE: used laptops that always has to be accounted for is it requires a fair bit of technical knowledge and some learned experience of what a good used device should have. I'm related to a few teachers and used laptops were always an issue because they couldn't afford to take the punt of getting used ones so they had to pay a premium from established resellers instead at which point you're approaching budget new laptop price territory.

Pi 400 really should have some obvious clear low cost screen upgrade option though. Possibly even just an app that it could stream to out of the box? Obviously wouldn't be perfect but if you assume there's a not unreasaonable chance they already have some Android device it could suffice.

I want to give something that is easy to move around and doesn't have lots of cables.

An old laptop locked down to run a BASIC REPL in kiosk mode?

While it’s double your budget, perhaps the Clockwork Pi DevTerm is worth a look?

https://www.clockworkpi.com/

Not OP but this looks amazing. I'm very excited that this product exists.

I'm pretty pleased with the Lilygo products. Here one with a an ESP32, case, screen, and keyboard for $45:

https://www.tindie.com/products/ttgo/lilygor-ttgo-t-watch-ke...

https://shop.pocketchip.co/

Great video. And thank you so much for your continuing work measuring power consumption!

So, this board takes 90mA in full-speed run mode. That's not better than Raspberry Pi Zero (despite pico having 2000 times less RAM, and 10-20 times slower CPU). So why would one use this over Zero? Am I missing something?

I think the major difference is that a microcontroller can rapidly enter and leave sleep mode, and will likely spend most of its time sleeping. The other Pi products do not support sleeping at all to my knowledge, which makes them an awful fit for battery powered devices.

A microcontroller like this should be able to sleep for microseconds at a time or possibly even less (but you can obviously sleep for long periods of time too), letting you spend the majority of every second asleep, just waking up for brief instants throughout the second (possibly thousands of times) to do work. This enables huge power savings over something like the Pi Zero.

You can also run the microcontroller at a lower clock speed to save more power, if you don't need to run at maximum speed to get things done.

I would be curious what process node this microcontroller is built on, because I completely understand why these numbers would be discouraging when the microcontroller is running at full tilt.

It's built on 40nm by Sony.

Generally, if you can get away without using a full Linux SoC then it’s better to use a microcontroller platform like this.

Microcontrollers allow much lower system complexity, more predictable timing and real-time response times, and nearly instant boot times.

Virtually every USB port can supply at least 100mA, so for most applications there’s no difference between using 9mA or 90mA. That said, if you’re making a battery project you’ll almost certainly be able to stretch the microcontroller further. Micros generally have fantastic support for low power sleep modes.

These are some really great points for when it can be better to use microcontrollers over microprocessors/applications processors. Agree that generally simpler is better, and microcontrollers are simpler than Linux SoCs for many things (maybe not in getting from zero to main(), but after that).

I would add that it really depends on the problem you're trying to solve, though. Microcontrollers are disadvantaged compared to Linux SoCs for many workloads other than low power and low latency (i.e. hard and soft realtime).

> 90mA in full-speed run mode.

Keep in mind that's at maybe 2 volts rather than 5 volts. Still, it's 360uA per MHz, counting the two 125MHz M0+ cores as 250MHz total. That's pretty power hungry compared to other Cortex M0+ products which tend to be in the 100uA/MHz range. I think the real product here is the RP2040 SOC and the Pico board is described as a breakout board for it. I like to think the RP2040 will find its way onto future RPi Linux boards, to give them some analog and realtime capabilities.

It's 5V micro-USB mode according to "3.1.1 Popcorn" section in https://datasheets.raspberrypi.org/pico/pico_datasheet.pdf this datasheet.

It's apples and oranges a bit: instead of linux you're going to need a bare metal or RTOS like FreeRTOS. Linux is not always the right platform.

That said, your point about power is well taken. I haven't looked at the Pico. What is the power draw in sleep mode?

Watch the video

0.006W from memory. But do not trust me. Watch the video.

Costs of development/maintenance of the use case as well as the unit itself.

Probably because of smaller size and better integration. Also, while I am not sure, I suspect the price is better, only if by 10%.

What many miss nowadays, is that most modern microcontrollers are more powerful than 8 bit home micros.

Python seems to be growing into the new BASIC.

If anyone wants to play with MicroPython, check out Wasp-OS for the PineTime and the Colmi P8 smart watches (~$20). I've learned a lot about embedded development since I got them.

Whaat, I can get a <100 USD usable out-of-the-box that I can program in Python? Quite interesting!

The ESP32 and ESP8266 can use micropython. They are very inexpensive and are often sub US$5.

https://docs.micropython.org/en/latest/esp32/tutorial/intro....

https://docs.micropython.org/en/latest/esp8266/tutorial/intr...

Thanks for your video. This no doubt foreshadows the Raspberry Foundation eventually moving away from the Broadcom SoCs to their own custom SoC for future Raspberry Pi iterations as well.

This makes a ton of sense. The GPU IP will be the tricky part. Will they build or buy?

If they're sticking with ARM I would bet on them using an ARM Mali GPU, since they would almost certainly be licensing the microarchitecture from ARM anyway.

I guess mRuby missed the train again.

Hi Jeff, Can a thermocouple be used with the built-in temperature sensor of RP2040?

I didn't down-vote you, but I suspect you've been down-voted because your question doesn't make much sense. A thermocouple is a temperature sensor, in that it transforms a temperature difference into a potential difference (voltage). You might be able to use the built-in ADC to digitize that voltage, but you likely need a sensitive low-noise, low-offset amplifier. For high temperatures (high temperature differences) and low accuracy requirements, you might use the built-in semiconductor temperature sensor as (not quite so) cold-junction reference. Does that answer your question?

It does, thanks.

I wanted to know if the temperature sensor could function like MAX6675 by connecting k-type thermocouple to a terminal; Should have checked the datasheet prior or made the question clearer.

You dont connect thermocouples to "temperature sensors", you connect them to ADCs after appropriate amplification.

MAX6675 has build in opamp, adc and full microprocessor under the hood doing signal conditioning, digitization, linearization, translation, and cold joint temperature compensation. TLDR: No, you wont be able to connect thermocouple directly to the Pico. You will have to design/copy frontend for it.

I assumed/misunderstood RP2040 also had -

> build in opamp, adc and full microprocessor under the hood doing signal conditioning, digitization, linearization, translation, and cold joint temperature compensation.

I stand corrected, thank you.

Reply on news.ycombinator.com