Hacker News Reader

Comment by londons_explore | Hacker News Reader

I really like the arduino way of having a small amount of simple code that does something powerful on embedded hardware.

They do a good job of hiding complexity (their compiler supports all of C++20, yet it's really rare to see anything more than a few basic classes).

For projects where I just want to make a thing that works, this is amazing compared to other toolchains.

I really hope rust can offer the same. Even a mediocre coder should be able to start from a blank file and, within 10 minutes, make something that tweets when the sun comes up.

So far, rust on esp32 is far from that... But hopefully they can get there!

View on HN

A lot of people look down on the arduino ecosystem because "it's for beginners", but there is no benefit to complexity for complexities sake.

If your product needs to do X, Y, and Z, and that can be built in arduino in a few days, and built in some other "professional" toolchain in a few months, then you will save money by building your real product on arduino.

And when the thing you're doing is outside the scope of what arduinos library ecosystem can provide (eg. you need to drive some GPIO pin with cycle accurate latencies), you can still write your assembly to do it.... But you still get the benefits of simplicity for the rest of your functionality.

> And when the thing you're doing is outside the scope of what arduinos library ecosystem can provide (eg. you need to drive some GPIO pin with cycle accurate latencies), you can still write your assembly to do it.... But you still get the benefits of simplicity for the rest of your functionality.

In my experience, escaping the Arduino system isn't so simple. The Arduino framework pulls a lot of stuff into the global namespace when you include even just one of their headers, some of which is incompatible with standard C++. For example they `#define` all pin names, some of which can be common terms like `led`, `button`, `mosi` or `clk`. Any of those you then can't use a variable name. It's even worse because the pin names differ between boards, and there's no master list of defined terms.

All the defines for pin names are fully uppercase. Is it really such a hindrance not to be able to call your variable LED_BUILTIN or CLKPS1?

Not all pins have names that are so specific, and it's a common convention to uppercase e.g. enumerators.

> If your product needs to do X, Y, and Z, and that can be built in arduino in a few days, and built in some other "professional" toolchain in a few months, then you will save money by building your real product on arduino.

Not necessarily. This is only true if you only think about software. Your "real product" also consists of hardware, and if you can do X, Y, and Z on a certain chip with the Arduino environment, you can most likely do exactly the same on a smaller and cheaper chip without the Arduino environment. Simply replacing Arduino C++ by plain C code without useless abstractions can already give you a very noticeable performance improvement and code size reduction on small microcontrollers. Development time is essentially a one time investment, while the chip price is a fixed cost for every unit you build. It's purely a question of how many units you want to build in the end. And for the record, if you can build it in an Arduino environment within a few days, you can definitely build it in "some other 'professional' toolchain" in just a few more days at most.

> A lot of people look down on the arduino ecosystem because "it's for beginners", but there is no benefit to complexity for complexities sake.

It's possible to be beginner friendly and not badly designed. Unfortunately Arduino doesn't really achieve that. The Arduino API is pretty terrible, the "IDE" is awful (they did improve it a lot recently in fairness), and the boards are very expensive.

Mbed is better in pretty much every way except that they screwed around with several different rubbish build systems for years, which meant it was very difficult to set up and as a result very beginner unfriendly. But the actual APIs are a lot nicer than Arduino's.

They do finally have a good IDE (Mbed Studio, based on Theano). I would probably use that for new microcontroller projects.

I would recommend to anyone using the arduino framework to switch to PlatformIO. It’s just a plugin for VSCode so you have all the benefits that come with that ecosystem.

Arduino is great if you are happy with one single massive file for all your code (I know you can add additional files, but it’s not intuitive).

For large projects that needs to be split up and architected use platformio.

The whole point of the rust-embed ecosystem is to bring the ease of use found in something like Arduino to embedded development more generally. Upstreaming ESP support in LLVM (what the OP is about) is a key part of this.

Looking at my firmware code, 4 quadrant motor torque control in particular. It is plain C and at the level it is written I really doubt C++ / Rust would add any value. For all the horror safety stories: firmware runs on whole bunch of devices for close to 10 years already without single fault caused by whatever bug there might be.

Obviously not advocating plain C for business middleware servers. Those benefit greatly from C++ type of languages.

More and more firmware is using complex protocols like TCP/IP and TLS, which are risky to implement in a memory-unsafe language. Embedded Rust is very attractive for those applications.

It already exists for those willing to broaden their horizons to Python, Basic, Pascal, Java, TinyGo, Oberon-07 and .NET.

Naturally having Rust as well is a positive, the more the merrier.

This is exactly where I'm at. I'm a professional SDE and I'm pretty damn good at writing code and solving problems at all kinds of different levels of complexity and abstraction, although professionally I mostly write Java code and build web services and that kind of thing.

When I got into electronics and embedded development recently as a hobby, I started with Arduino. And for the vast majority of my projects, which are mostly simple smarthome IOT type things, or little toys for my kiddo, the Arduino framework is just fine and the ecosystem of libraries is great.

But when I recently started a project that was much lower-level (in fact, it was your example exactly -- driving pins with cycle-accurate timing), where I didn't need those libraries, I used ESP-IDF without Arduino.

I'm also just lazy, and just don't want to deal with more complexity than I have to.

How was your experience with ESP-IDF? I've only used Arduino so far (I've basically had exactly the same experience as you), and haven't needed anything more, but I've been thinking of using the IDF for my next project, since I can't use Rust yet.

>there is no benefit to complexity for complexities sake

Arduino is added complexity. In my limited hobbyist experience, going to the datasheets and using official toolchains has been very straightforward. It pays to build the understanding ahead of time rather than debugging some random person's Arduino library when your peripheral stops working.

Yep. You think you can get by without understanding what the Arduino libraries are doing under the hood, until you can't. Then you wasted all that time. I'm just as guilty as anyone spending just as much time avoiding learning something, than just taking the time to learn it.

It used to be that official tools chains were a huge money and time expense - Not to mention requiring substantial understanding before you even got to them. Even AVRs which had an open source tool-chain still required a $50-200 programmer to get started. The PICs were more popular, but proprietary tool-chain. And the communities associated with both were great at gatekeeping and dismissive of beginners who weren't doing things "the right way'.

Arduino's added complexity opened up the space to people who had little-to-no programming experience. People who had a computer with a USB port. People who had no familiarity with binary let alone hexadecimal to set a bitmask so they could turn an LED on. Let alone figure out which bits to flip to set a timer.

Arduino is added complexity to the benefit of accessibility. The complexity of the datasheets and toolschains make most products an unassailable wall. That said, the real gem of Arduino is its community that is welcoming and helpful to beginners.

I'd hazard a guess there is no software that would take "months" to build while it takes days on arduino, unless you count "developer learning C++ properly" in that month.

Most uC platforms provide enough SDK and code generation that you can hit the ground running with simple code and complex code won't be any easier in arduino

I agree with a sibling comment point that Arduino's main strength is that it simplifies the installation of tooling, not that the code is particularly easy. But, on the code side, I think that embedded-hal is excellent

https://docs.rs/embedded-hal/latest/embedded_hal/

Here are the supported boards

https://github.com/rust-embedded/awesome-embedded-rust#hal-i...

There's a book on rust on esp https://esp-rs.github.io/book/

Here's how to blink a led using esp-idf-hal, targetting espressif

https://github.com/esp-rs/esp-idf-hal/blob/master/examples/b...

    /! Blinks an LED
    //!
    //! This assumes that a LED is connected to GPIO4.
    //! Depending on your target and the board you are using you should change the pin.
    //! If your board doesn't have on-board LEDs don't forget to add an appropriate resistor.
    //!

    use esp_idf_hal::delay::FreeRtos;
    use esp_idf_hal::gpio::*;
    use esp_idf_hal::peripherals::Peripherals;

    fn main() -> anyhow::Result<()> {
        esp_idf_sys::link_patches();

        let peripherals = Peripherals::take().unwrap();
        let mut led = PinDriver::output(peripherals.pins.gpio4)?;

        loop {
            led.set_high()?;
            // we are sleeping here to make sure the watchdog isn't triggered
            FreeRtos::delay_ms(1000);

            led.set_low()?;
            FreeRtos::delay_ms(1000);
        }
    }

The real strength of the Arduino tooling is that they have hidden all the complexity in setting up the toolchain needed to produce a binary. You install the Arduino IDE. You edit code, you compile it, upload it to the device, it works. End of story. Well for the most part, but compared to the rest of the embedded software world, it is a pretty smooth ride.

It isn't so much that the programming model is less complicated. Sure that's an advantage if you are just noodling around. The Wiring framework has introduced a lot of developers to embedded development. But once you start to do projects that are a bit more than just a demo of something it actually is a bit easier to write software using, for instance ESP-IDF (FreeRTOS port for ESP32). You don't have to reinvent concurrency, for one. And it makes it easier to make use of more of what the ESP32 chips can offer.

The bane of embedded development is awful tooling and people who aren't very good programmers inventing abstractions that do more harm than good. Setting up the ESP-IDF toolchain correctly is much harder than it needs to be. If you haven't done it before, it is going to cost you a weekend to set up. You can probably make something work half-way in a few hours, but to get all the gremlins out...that can take a while. I recently spent on the order of 3 hours getting things to work properly again after upgrading to a newer version of ESP-IDF and it is slightly infuriating how bad the tooling is.

And as if the tooling wasn't bad in itself, the embedded world is in love with Python - which adds yet another dimension of problems. Python isn't a language that lends itself to producing software that behaves predictably on random computers. Please stop using it for tooling. Write tooling in a portable language that can produce proper binaries. Preferably statically linked binaries so that at least you do not have to waste time wondering why your tooling doesn't work. Write tooling in Rust or Go.

(And if you think ESP-IDF is a handful, good lord, pray that you never have to deal with Zephyr.)

I used to hope that Platformio (https://platformio.org/) would help solve problems, but it seems that none of the MCU vendors really give a shit about figuring out a good solution. Everyone wants to make their own mess. (Yeah, it is Python, but not at the amateur software engineer level as the nonsense you see in vendor toolchains)

Yeah, Arduino (or rather Wiring) is limiting. But the "professional" embedded world can sit down and shut up until they can demonstrate something that is even half way as reliable as the Arduino IDE.

I think the root cause is misaligned incentives for the involved parties.

IC vendors have a lot of incentive to lock you in their ecosystem. Embedded developers are paid to produce firmware for widgets- their priority is shipping a firmware binary to manufacturer.

Besides, I don't find Arduino IDE that reliable- I still have to figure out which board definition to use (is this a micro or nano? Perhaps nano pro? Why doesn't this blink code not work on RP2040 board? Oh right, I selected adafruit rp2040 board when I was using pico, which uses board pin numbers vs rp2040 gpio numbers)

I think it is more about inertia than trying to accomplish vendor lock-in. Software is much more important for embedded applications than it used to be. I regularly see people choose MCUs that are many times more expensive than what they might have chosen -- simply because they can't afford the software development costs on MUCs that have poor SDKs.

The industry is starting to understand this, but it takes time to fix. And the industry still needs to shed a lot of managers that lack a basic understanding of engineering software ecosystems and tooling.

Figuring out what board definition to use is a luxuriously simple problem to have. :-) Try to figure out how to configure a bunch of sensors hooked up to anything running Zephyr. It seems to have been put toghether under the motto "there is no problem so complex that we can't make it even more complex".

If you find Zephyr too complex, maybe give RIOT a try. It also supports all the ESP32 family members (with WiFi and BLE) and generally has a simpler API and build system.

e.g. you can build and flash any application and open a debug shell with

    make BOARD=esp32s3-devkit flash term

The ESP32 toolchain is installed with an easy to use script: https://doc.riot-os.org/group__cpu__esp32.html#esp32_local_t...

Well, for the two smallish projects where I did use zephyr, I didn't find it too bad. But I must have suffered enough fiddling with the real devicetree before :)

(not sure why you got downvoted. gave you an upvote to balance out unnecessary downvote)

> (And if you think ESP-IDF is a handful, good lord, pray that you never have to deal with Zephyr.)

Well, that's stings. Can you elaborate on your trouble with getting Zephyr working on ESP32? My memory is it's actually one of our simpler platforms, though it's true Zephyr isn't itself an IDE. It's an RTOS with a C API; you're expected to build at the command line with a wrapper tool (west), and to have downloaded and unpack an SDK tarball. But really there's not much more to it than that.

Not OP, but from a professional perspective I wouldn't say it's pain free. Your first issue is going to be figuring out whether your needs are even supported by the stack by going to [0]. I appreciate the difficulty of supporting hardware, but that much red would definitely have hurt it during RTOS selection for me. Second, what if the hardware people want to use the S3 because of availability concerns? There's no table I've ever found, you just have to troll through code and GitHub issues to figure it out.

One other frustration is how obtuse the error messages can be. If west encounters a situation it doesn't like, it will often dump stack traces rather than print an error message. If you have something in the wrong directory or a typo etc, the magic in the build system often just fails and prints a generic error message or nothing at all. Maybe you screwed up the DT, maybe you named something incorrectly, maybe it's in the wrong directory, or maybe you typo'd. All of these can produce the same error messages at build time, which gets annoying.

With that said, the zephyr experience is remarkably pain-free and Linux-like compared to some vendor toolchains and generally good enough that I advocate for it internally.

[0] https://www.espressif.com/en/news/Zephyr_updates

Some of that seems a little unfair. The desire in the first paragraph is for a fully-integrated, vendor-supplied SDK for a single board where everything works. The bit in the second is about doing configuration and integration work on new hardware.

I think both criticisms are reasonable but they aren't from the same perspective. In this case, yes, Espressif (who I'm not affiliated with and don't want to speak for, though I have worked on the ESP32 -- it was actually Zephyr's launch hardware for SMP, as it happens) doesn't quite have everything wired up yet. And that's unfortunate, but not so much a ding at Zephyr as with this particular integration (other chip vendors, Nordic especially, tend to be farther along).

And as for doing devicetree work... yeah, I don't like it either and try to stick to the kernel. But it's a ton cleaner than the kind of cut/paste you see with other solutions (and especially with whole-board IDE/SDKs!). In Zephyr, if you have a part that has an instance of some existing hardware integrated on another platform (a Synopsys DMA controller, some third-party I2C accelerometer, whatever), the configuration is usually/hopefully as simple as a three-line block of DTS with the addresses and interrupts filled in. For platform integrators, it's probably our single most attractive feature.

I don't use Zephyr on ESP32. I try to use it on the nRF91. And there is a lot more to it if you actually want to build a device that has a few sensors, does a bit of mobile networking AND you need to develop this over time and upgrade the SDK from time to time.

For a hobby project I’ve used Zephyr via the segger embedded studio for the nrf52. Coming from full stack web development and having dabbled with Arduino IDE, the learning curve was a lot steeper. But I totally understand why, the problem space of supporting all of the different chips and all of the different libraries is huge. It didn’t help that nordics was transitioning from their old stack to the zephyr based one and all the forums and documentation was incredibly confusing because of that. After learning the options menu where you select which parts of the stack to include in your binary things started making a bit of sense, but I still have no idea whether the softdevice is still a thing or not . If you ever want more user feedback feel free to reach out.

There are definitely amazing features in the ecosystem. E.g. the fact that you can run a live debugger on this tiny chip is mind blowing.

Python is the new BASIC, and given the choice I rather that they chose Python over JavaScript.

> The bane of embedded development is awful tooling and people who aren't very good programmers inventing abstractions that do more harm than good.

Use VSCode. It's not great, but it's SOOOO much better than everything else in the embedded space (that doesn't cost $100K+) that it's ridiculous.

As for programmers, any programmer of talent decamped from the embedded world to anything else. As long as semiconductor companies refuse to pay real salaries, this will continue.

> Write tooling in a portable language that can produce proper binaries. Preferably statically linked binaries so that at least you do not have to waste time wondering why your tooling doesn't work. Write tooling in Rust or Go.

No. Just no. Installing random crap in any language on my computer is where things fail.

Use a bloody container. To contain the mess, it's what I have to do anyway. For the love of all that is holy and unholy, distribute a container. This is the kind of scenario that containers were MADE for--lots of random tools that need to be version locked and only upgraded as a single unit.

I’m a decent programmer. The Arduino superset makes microcontroller programming so much more straightforward. It’s mostly things like setting up the bit masks, or enabling the right peripherals, but I’m really pleased it’s there.

Agreed, I've also somehow stuck with arduino's setup despite its occasional shortcomings since it's just so simple to configure different devices and whip up something quickly. No messing around with anything but the very core essentials.

The only thing that is sometimes faster from idea to deployment is micropython, since it's possible to just copy paste regular python with minor changes and it just works.

For ESPs I recently had quite some fun prototyping using MicroPython. REPL directly on the controller so I can try things out, a mechanism to "mount" a local directory on controller so larger things can be tested easily etc. and then support for many of the features (I2C, SPI, Wifi, BLE, ... all work, one can even send binary for the low energy core on the ESP32, while some things weirdly are missing, like support for the temperature sensor on the ESP32-C2)

Reply on news.ycombinator.com