Live data from Hacker News

Qualcomm to acquire Arduino

qualcomm.com

371–380 of 553 posts

Re: Qualcomm to acquire Arduino

#371

Additionally, they're launching their first joint product, the $44 Uno Q SBC, which has a Dragonwing SoC and STM32 microcontroller on an Uno form factor board[1]. It seems like Arduino will keep their brand, maintain their existing product lines, and continue building devices using other vendor's chips (besides Qualcomm), etc... but as with all acquisitions—I wonder how long that state of affairs will last. Alternati…

> Alternatives like the Pi RP2040/2350 and Espressif's vast selection of boards can fill the gaps, but Arduino was what got me and many people I know into microcontrollers, so I have a special fondness for them!

Exactly. For the people who did not follow a structured educational program on embedded programming, starting with an SMT microcontroller was very hard.

Arduino made this fun and easy with their language & IDE combo. Typing some code and seeing the lights on the board reacting is a hell of a drug.

Once you mastered the IDE, you could either program other microcontrollers in the same IDE, or at some point you hit the limits and started digging into the vendor-specific toolchains.

If I started again today, I would again start with an Arduino.

Re: Qualcomm to acquire Arduino

#373
post #259
post #225

Earlier quoted context omitted.

> while the Raspberry Pi was about the same price as an Arduino but way better performance If you are cross shopping a full single board computer (Pi) with a microcontroller (arduino/esp32 etc) for a project, it's almost always a sign you don't know what you are doing. With the exception of the recent Pi Pico, non of the raspberry pis are Arduino/microcontroller competitors - they are typically full blown linux compu…

Right but if you're a hobbyist, "cheap" isn't the priority. I mean, what's the harm of using a $40 SBC instead of a $10 one if you're going to be spending hundreds of dollars and dozens of man-hours on it? The bigger concern is the overhead of the Linux OS in terms of interacting with it vs just flashing a microcontroller... but linux lets you run an SSH and FTP servers and wifi and a debugger on the thing easily. So…

If you're a hobbyist making IoT stuff though, you might want 10 of them. And then the price per piece starts mattering.

Re: Qualcomm to acquire Arduino

#375
post #222

The problem is that there just isn't a whole lot of money to be made in providing hobby hardware for enthusiasts. Every time a big player gets involved, they think they can change this. A decade ago, Intel tried that back in the day with Galileo / Edison, and tellingly, they came up with the same "ideas": IoT / AI. If you're doing cheap IoT trinkets, you're never going to pay extra for a brand. You're going to buy th…

I wonder if even inside the hobbyist space, Arduino got obsoleted by the Raspberry Pi and its clones/compatible devices. Basically, if you already got the skills to work with "bare" microcontrollers, you won't need all the simplification and handholding that Arduino provides and you can just buy the individual chips and fully utilize the tiny form factor and low power requirements. If you want to learn programming mi…

Perspective: Former college robotics team member a while ago (2022) (IEEE SoutheastCon)

I definitely see niches for both. Even if you've got some experience an Arduino uno or mega is just an atMEGA with good software support and IO headers.

We'd usually use an RPI and Arduino - connect our 'out of the box' modules to the pi, pi to arduino via uart serial, and wire arduino to the meat and potatoes. The RPI's IO was generally not as good in terms of latency but also if the wrong wire gets crossed suddenly we'd have a dead Pi but the Arduino would shrug it off.

Re: Qualcomm to acquire Arduino

#376
post #16

Earlier quoted context omitted.

This board has onboard EMMC, wifi/ble and can run a full Linux. That is more of an rp 4/5 with an rp2xxx tagged on the side. It comes with their own arduino IDE installed too It is kinda disappointing but I can see why Qualcomm wants to use the brand.

I'm speaking in a broader sense, comparing the variety of other Arduino boards like the Uno R3/R4. That wasn't too clear in the OP, sorry! The concern I have with the $44 Q is it has 2GB of RAM and 16GB eMMC, and a processor that's probably between a Pi 3 and Pi 4 in terms of speed and IO (though 4nm, so probably much more efficient). For $45 I can buy a Pi 5 with it's own built-in GPIO, PCIe, and a much faster SoC,…

The GPU on the RPi is a _lot_ slower

Re: Qualcomm to acquire Arduino

#377

Earlier quoted context omitted.

20$ for a burrito? That is like some high-end, premium burrito right there! But hey, its your money, spend it however it makes you happy.

$13-17 plus tax. Closer to two than three, especially by TPIR rules. The $7 burrito era is long gone unless it's a frozen burrito or someplace that is extremely sus.

Taco Bell lists their burrito supreme as $5.59.

Re: Qualcomm to acquire Arduino

#378

Earlier quoted context omitted.

The pin mapping shenanigans are another annoying footgun with Arduino. Even in native development you're dealing with a physical pin number and the logical assignment (PA5, PA6, etc), but now Arduino maps that all again to an Arduino board pin number, and it's all shuffled to ensure the peripherals are in the right place to enable I2C, ADC, and PWM pins to function as expected.

Of course they did that. It's a HAL (hardware abstraction library). That also means that simple projects are abstracted from the hardware. Means I can go across a dozen different CPU arch and board/pin layouts, and I change nothing in my source. I only change my target and it just works. I did that when I went from a board operating at 16MHz/atmel to a STmicro running 50MHz. No change in my source. And that's really…

The problem is that a lot of this abstraction is done at runtime, not compile time. Your binaries become bloated, your application slow, and you end up using a microcontroller with three times the resources you actually need just to support all the dead weight.

Re: Qualcomm to acquire Arduino

#379

Earlier quoted context omitted.

There's still relevance in making it stupidly easy to make an LED blink and make basic apps on circuit boards. Education + weekend hardware hackers might look for something different in a framework than a professional. But certainly for pro use cases the hardware specific frameworks are way more powerful (but also complex). I wrote up a bit on Arduino vs ESP-IDF here https://bitclock.io/blog/esp-idf-vscode

The native AVR libraries are really good. It's not quite as idiomatic as Arduino, but it's really not all that different. Beginners can learn frameworks more complicated than Arduino and I think they should. Before Arduino, beginners were expected to write plain C or assembly, and the industry got along just fine. There were still countless hackers and weekend tinkerers. They just had to learn more, which is not a ba…

If by native AVR, you mean avr-libc, it's nothing at all like Arduino.

Instead of analogRead, you need to write your own busy loop watching certain bits in a register (or ISR), you need to twiddle bits in several registers to set up the ADC the way you want it, etc.

Serial.write? Nope, gotta read the docs, twiddle some bits again, and then you actually do get to use printf.

Those two right there are big hurdles to someone new to microcontrollers. In fact, they're a hurdle to me and I've read AVR datasheets for fun.

Re: Qualcomm to acquire Arduino

#380

Earlier quoted context omitted.

I feel like this has to be a toolchain issue, there's no reason the pin number -> register table couldn't be resolved at compile time, similar with conditionally compiling certain things based on the CPU features. I'm not saying it's not a real or an easy problem, just that I wonder if it truly is the reason Arduino is "bad"

It could and some cores do. Many do not and you get a runtime lookup unless you explicitly call digitalWriteFast which is also supposed to resolve to a single inline instruction. It usually does not and instead emits a function call in assembly. The gpio thing is really just my personal pet peeve. There are a lot of things like this though. For example, the arduino core will consume several milliseconds doing somethi…

I agree with you, with the caveat that the awful software that's written by an inexperienced programmer ends up getting used, and the perfect efficient well-tuned software I want to write never gets finished (or even started, usually). It's so much more work.
Post reply on HN