Hacker News Reader

Comment by JoeCortopassi | Hacker News Reader

If you are a hobbyist reading all this, and trying to compare it to arduino or raspberry pi, do yourself a favor and buy one of these: https://www.adafruit.com/product/5325

$12, fantastic documentation and tutorials, and you can literally just plug it in via usb and edit the python code as if it's just a text file on a thumb drive. No programmers, special IDE's, or specialty equipment

Microcontrollers are fun again

View on HN

I'll plug ESP32 more broadly, which are half the cost of the Adafruit user friendly chip, which is only single core. If you're familiar with Arduino, the regular dual core ESP32 are fully compatible with cross-platform Arduino C code. You can get ESP32 for $5 each from US resellers or even cheaper in bulk on Aliexpress from China.

If you really need to get cheap, the ESP8266 is also fully Arduino compatible and less than $2. Still way overpowered for a wireless temperature sensor sending packets to homeassistant or whatever.

If it solves your problem for a price that is acceptable, it isn't "overpowered". This isn't using an i5 to blink an LED territory.

Unless you are shaving pennies for mass production, I'd stay away from any of the Tensilica LX6 LX7 based ESP32 parts. Toolchain and library support will be much better with the RISC-V based parts.

The ESP8685 is the current budget RISC-V based MCU. 384K of user SRAM, 4MB of Flash, 160Mhz RISC-V core. $1.50 qty 1.

https://www.espressif.com/sites/default/files/documentation/...

Are the toolchains and libraries already much better or will that be in the future? Note that the CPU architecture is the least important thing of a microcontroller; as long as you have a decent compiler for a higher level language you don't care what instruction set it uses. And I can see the toolchain getting more love if it's a more widely used CPU architectue (and Tensilica is rather niche), but I don't see why library support would be any better.

The LX6 wasn't supported by LLVM for the longest time, only GCC.

RISC-V is nearly identical to MIPS or Arm, so anything to add Arm support to library, would also make it RV compatible (before inline asm).

Build breakages on LX6 or LX7 are 100% on you.

Forgot to mention, that as these MCU and crossover parts get more capable, the expectation that you can basically run a linux distro and then also communicate with many RT control-loop mcus. At some point, embedded control applications will have a Js toplevel.

I have an open source fetish for RISC-V, but to be honest, the LX6 and LX7 toolchains are perfectly fine in terms of functionality for what most people need a low-cost chip to do. ESP-IDF and FreeRTOS are pretty mature at this point. Really cool things could happen with RISC-V. But when I need a chip to read/write some GPIO pins, drive a display, and do some networking, it doesn't really matter.

I think I bought about 5 ESP32-WROOM-32D, 25 ESP8266, 10 Arduino Mini clones, 10 Arduino Nano clones during the pandemic. They're coming out of my ears.

To me that is a very different experience from actual 'fun' MCU programming. I do not know if the ATMega community is so keen to program python. I remember sitting in front of a scope to carefully insert nops to get timings correctly or spending hours fixing bugs in the sdcc code generation before resorting to assembler again. Nothing against esp32 and python...

> I do not know if the ATMega community is so keen to program python.

Not sure that it's the ATMega community being keen to program Python, or Python people keen to program on ATMegas.

The hobbyists I know who prefer ATMega are certainly not using Python. They take the extra step of reflashing the chips, if needed, to get rid of it.

Yep. Atmel/Microchip AVRs popularized by megaAVR ATMega328 toolchain favors their restricted C/C++ subset.

There are a couple of alternative languages that don't require a computer host to drive them:

Visual programming language: https://xod.io

There was Céu: https://github.com/ceu-lang/ceu-arduino

And one can always try AVR assembly if they're really curious.

Thank you for highlighting this — I hadn’t realized how far the lower end of the price range had advanced since the days of cheap Pro Micro clones. 240MHz, 2MB ram, 4MB flash, circuit python —- this is incredible for $12, and from Adafruit no less!

the lower end of the price range has advanced by almost three orders of magnitude since 12 dollars: https://jlcpcb.com/partdetail/NyquestTech-NY8A051H/C5143390

those are 1.6¢

Then take a look at the RPi Pico. All of the above at an even lower price point: I think I bought 3 for $12. Only thing missing is wireless, which you can get in the Pico-W.

The only thing the Pico-W beats the ESP32 on is power consumption. ESP32 costs the same as Pico non-wireless. ESP32 has double the clock speed, ram, and flash, plus wifi and Bluetooth, at the same price.

Plus ESP32 has a huge ecosystem of software and hardware, the same way the original big Raspberry Pis are much easier to develop on. Pico ecosystem isn't nearly as big.

The PIO units can be a killer feature in some specialized cases. And not all the ESP32 variants have native USB, which can be a requirement. But generally I agree that ESP32 is the winner, for now.

the RP2040 can be overclocked like crazy, has dual cores, a considerable amount of ram and the amazing PIO devices which allow the RP2040 to bitbang DVI. The PIOs are amazing.

https://rp2040pio-docs.readthedocs.io/en/latest/

An ideal board would have an RP2040 as the USB terminator (where it can be a usb mass storage device for dragging and dropping firmware) and the ESP32 can handle the radio.

ESP32 is on the order of 1.05-2$ each and the RP2040 is 0.70

+1! the Picos have been an absolute joy to work with, and take me back to my C coding start from.. gosh.. 38 years ago. :)

Mix in some I2C components and a few jumper wires, and you basically have my whole childhood distilled down and reborn -- legos and code.

If you're limited to Python and aren't an EE/CS, sure. Developer support is one of the key points for hobbyist- and industry-useful MCUs/SBCs.

There are other interesting boards out there:

--- ESP32-C6-DevKitC-1 ---

C and Python in the box

https://docs.espressif.com/projects/espressif-esp-dev-kits/e...

$9 gets you

- 32-bit RISC-V

- WiFi 6 2.4 GHz

- BLE 5.3

- Zigbee 3.0

- Thread 1.3

- ARGB LED

--- ESP32 RISC-V Rust board ---

$19.80

https://www.espressif.com/en/dev-board/esp32-c3-devkit-rust-...

- Temp and humidity sensor

- Inertial measurement unit

- Li-ion charger

- USB-C

--- Orange Pi 5 Pro ---

$141

http://www.orangepi.org/html/hardWare/computerAndMicrocontro...

- Rockchip RK3588S

- 16 GiB LPDDR5

- GPU 10x faster than an RPi 5's

- NVMe without a hat

- WiFi 5, BT+BLE 5.2

- H.265 8K@30fps encoding and 8K@60fps decoding

- AI accelerator built-in

Once upon a time™, c. 2000 for hobbyists, there was primarily BASIC Stamp (with BASIC obviously) and PICs with their own assembly ISA. Yep, we had to walk 100 miles barefoot to school in the snow back then. ;)

> and you can literally just plug it in via usb and edit the python code as if it's just a text file on a thumb drive.

The original mbed featured that but implemented using a separate micro. You copied the file and pressed the reset button to load it.

I often wonder how you do that : the usb mass storage let you use blocks, not files (if you want files use the MTP/PTP usb protocol), so how will the target "know" that I'm uploading a file to write to the flash wihtout writing and reading a full FAT on the device flash ?

This blog article gives a rundown of all of the ways this has been implemented. https://makecode.com/blog/one-chip-to-flash-them-all

Nice! So what this means is that you put all info for flashing a part of flash in a 512 byte sector so you don't need filesystem info (place within file, even order) since it's all written as a bunch of self contained 512 bytes commands in the data itself. Clever!

The flash on the mbed was a real 2MB FAT disk that you could upload one or more random files to, not just mbed binaries. I assume they built a dual ported flash driver that arbitrates access between the loader and the USB storage driver. I should also mention it looked for .bin files and checked the mtimes to load the newest .bin file in the disk's root. So it was using a real FAT file system on both ends.

Call me old fashioned, but I wouldn't waste 100s, if not 1000s of bytes of program space to program them in python when literally 5-10 bytes of register programming would suffice. But, of course, this requires a bigger commitment of time to study and understand the reference manual.

Realistically its "wasted" whether or not you fill that address space with instructions or 0's. The memory is there whether or not you choose to use it. If you don't, nothing is going to use it at all.

I'd also argue that "old fashioned" would include the era of the venerable 6502 (yes, not an MCU, but hobby electronics programming isn't all MCUs) which was often programmed by hobbyists in BASIC, another interpreted language, so it's hardly a new thing to "waste" those bytes.

Oh no … there goes my “no more money on unnecessary projects” resolution.

Reply on news.ycombinator.com