Arduino Goes Pro at CES 2020
blog.arduino.cc
blog.arduino.cc
I work as an embedded software engineer who's tasked with ripping all the terrible arduino code out of a fairly large codebase where I work and the arduino core libraries are the lowest quality code I've ever had the displeasure of working with.
It's full of awful decisions everywhere in the arduino core libraries such as defining min and max macros when they're writing C++ code which in turn results in STL includes blowing up if you attempt to use something simple and safe as std::array.
I could go on for days about all the terrible decisions that reeks to high heavens of always taking the path of least resistance... </rant>
32-bit ones also support Micropython and I think there have been ports of Node.js, but I haven't looked into those.
I've enjoyed doing a few small projects with PyCom [0] products and have found them good enough for what I was after, however I can stake no claim on it being any better and have always been curious.
If it wasn't for arduino, many project would never take off.
At university I was taught to program microchip pic16 and oh boy was it painfull. Their software was low quality, errors were incomprehensible, etc.
I think Arduino is Javascript of embedded development: many people use it because it's easier, there is a library for everything and half of them don't work right.
Their i2C has had the same issue for like 8 years and last time i checked it still isn't fixed.
At small volume with assured availability right now you can plug together off the shelf microcontrollers and ethernet modules for $3-5 per node. That's 5% of the Portenta price.
What Arduino originally did right was USB flashing + cross platform IDE + library management + examples + media noise. The fact nobody else has bested them is a sad comment on industry.
Source? I'm looking for that right now and can't find any cheap microcontrollers that include an ethernet jack. The price I find make a Raspberry Pi a viable solution... which is quite sad.
I wouldn't say nobody has bested them.
The real professional Arduino is the Mbed, run by ARM.
It's for professionals, by professionals, and it shows in good quality.
But, you pay for the abstraction - it's inefficient with hardware resources.
Another alternative is modm.io.
It's a modern take on the hardware abstraction layer, claimed to be very efficient.
It may just be that with it's combination of high efficiency and portability, you would get the cheapest mcu for your project.
I'm not sure the mbed is intended for products with a deep focus on price.
So less hardware selection might fit.
But modm.io does have support for some low end devices.
Has it, really? I have difficulty finding projects that went from Arduino to major success.
The only thing which (I think) has an Arduino that actually became a "success" is the Formlabs 3D SLS resin printer.
(I'm an electrical engineer at Formlabs, and was around through the Form 1+ product cycle)
I'm not even sure to what to attribute arduino's success. I think they just made the simple things (GPIO and loading code to the device) simpler than anyone else. And even that is not done terribly well on an absolute scale. Think about how often new users encountered FTDI driver issues over time...
Once you're used to the development environment, you "take off the training wheels" and start to program in ATMega328pb directly. Or in this case, use an STM32 ARM 480MHz chip.
If they could have a kid...
Arduino:
- crappy software environment, and no networking. (designed by hardware guys?)
+ wonderful hardware.
+ The pins are female and don't accidentally short on things.
+ There are a variety of devices available with the number of pins you need.
+ Powering the device is simple and straightforward.
+ Driving different types of hardware is easy.
Raspberry Pi:
- terrible hardware. (designed by software guys?)
- hard to power. Must be 5v, power supply must be carefully chosen, lots of limits.
- pins are male. who does this?
- hardware arbitrarily (capricously?) changed from release to relase (moved LEDs, etc..)
- hard to drive different hardware
+ software is wonderful.
+ you can run a variety of operating systems.
+ you can run really high level software (python, GUI, machine learning, compiler, web server, ... so much more)
+ networking (all the kinds)
For amateurs, this is all fine. You don't care if the code is good, because you're just making a $60 555 timer. And you want your sketch to work when Adafruit sends you a new MCU in your monthly hacking box or whatever. So Arduino does very well there, because that's what users want.
Over in the real world, you pick a board and use that for the lifetime of your project. Going through 8 abstraction layers so you can run your code developed against an ARM M4 on an ATMEGA32U4 is not something anyone cares about.
What people do care about is developer productivity, and the Arudino toolchain is just terrible. I'm not talking about the IDE, which is what it is, but the actual mechanics of building and flashing devices. I have a Windows workstation, and the % chance of being able to successfully flash a sketch is about 50%. Sometimes the device switches ports and this confuses the IDE greatly. Sometimes the device just doesn't show up properly. Maybe this is all Windows' fault, I don't know, but I have the exact same problems on Linux. Meanwhile, the same board in UF2 mode works perfectly every time. I can edit Python code against a file sitting on the device, or run "tinygo flash" with a 100% success rate. What am I even getting from Arduino if I can't edit or try my code efficiently? I don't know where it all went wrong, but the arduino-cli manages to be just as flaky, so I think it's just systemic. You glue together an abstraction layer and 1000 flaky vendor-provided tools... and the result is flaky.
I think hobbyists tolerate it because they are told that hardware is "hard" (it's right there in the name), so they are perfectly happy to chant magic incantations because they don't know right from wrong. But if you've written software before, you know this is wrong. All the toolchain needs to do is translate C++ to machine code, which I know from writing C++ that can all work quite well. Then the toolchain needs to copy that machine code into Flash memory on the device, and tell the MCU to restart. I know this works quite well too because I've used UF2 programmers and it works every time. Finally, you need to make a virtual serial port to support debugging. My tinygo programs successfully send serial output to my computer 100% of the time. Arduino IDE? 50% on a very lucky day. Mostly I click around hopelessly, crawl around on the floor trying to plug and replug USB devices, press the reset button on the MCU 700 times... and then 30 minutes later I can see my debugging output. What was I working on again? I forget.
Anyway, I suppose that none of this is unique to Arduino. I've used Atmel Studio, I've used Nordic's NRF52 dev kit, I've used avr-gcc and teensy-cli... all are bad in their own way, but they do consistently work and don't get in my way. Arduino consistently gets in my way by not doing the basics right consistently. All so my code can run on devices that I don't have. It's not worth it. I am not sure how this appeals to pros. They should hire some actual software engineers and check back in in a year. I'd be happy to try Arduino again.
I am new to this space, and have only heard of Rasberry Pi, MicroPython and Arduino.
A Raspberry Pi or Arduino is fine for early prototyping and hobbyists, but if you’re going to make a million of something then you aren’t going to stuff a Raspberry Pi in your product unless the ecosystem is one of your selling points. Otherwise, using a Raspberry Pi means that you’re paying for USB ports, Ethernet ports, WiFi, Bluetooth, led lights, header pins, and every other component on the board and your produce probably doesn’t need them all. Including a bunch of components that you aren’t using is just leaving profit on the table.
I am not interested in the Electron-based IDE, but they seem to be using the Clang language server, which is perfect for integrating with Emacs. I have been sitting here for months ready to hack on this stuff and make it work perfectly, but all I have to work with is the raw source files contained in the Electron bundle with no license, so I've basically given up. Once again, the Arduino team is doing Weird Stuff with software, and this whole Pro thing feels like "the joys of working with Broadcom, but we stick random Open Source logos on thing without actually being Open Source".
I have a lot of microcontroller projects I want to do, but without modern development tools, it's not worth it. They are so close... just let me hack on your source code, please. I'll do it for free and you can do whatever you want with the code. But they don't seem to want to play ball.
(Recently I have been playing with Tinygo, but I am still not motivated because "go doc", my favorite go tool, and gopls don't work... and I'm not quite sure that it's worth the effort to make work yet. My toy tinygo projects have gone pretty well, though, so maybe it is worth making their IDE support work, and forgetting Arduino ever existed. I feel like Circuit Python / Micropython is the path of least resistance right now.)
STM HAL isn't exactly great either, but Arduino is best placed IMO as entry level novice stuff, or blasting out something working in five minutes.
Unfortunately I don't see how this is a significant improvement otherwise for industrial uses, where the biggest barrier for custom components is certifications (FCC, UL, CE, ATEX, etc).
But I've also just spent the past year programming an automated mobile restaurant. We use a traditional PLC for everything safety or time-sensitive, but everything else is JavaScript.
We're planning to use even more JS on the next-gen system. Details are in my profile if you want to help, or if you want to convince me otherwise.
If industrial equipment malfunctions, people can be killed or horribly maimed. Industrial equipment needs to do exactly what it was designed to do 24/7 for years or decades in horrible (EMI, temperature, etc) environments.
I recently had a chance to wander around one of the bigger EMS factories in the Bay Area, rubbernecking at everybody else's products in various stages of assembly. It's safe to say not many naysaying HN'ers have done that recently, or they would be saying something very different.
One of the RasPi-based devices I saw being assembled was actually some kind of medical device that will presumably have to be FDA-certified. It was going into a very nice enclosure, with top-grade plastics and other materials, and they were building a (literal) ton of them. In principle I'm sure that can be done successfully, but I have to wonder if it'll really save the company that much time or money.
In what way does C vs. python or javascript have any impact on this? If anything, C has way more ability to shoot yourself in the foot than python or javascript. Hell, what about a non memory-managed language like rust?
Like somebody else says, this feels more like a cultural issue than an actual technical issue.
To the larger point of coding for these kinds of applications, keep in mind that there are entire classes of bugs that are common in traditional microcontroller languages like C which literally do not exist in Python or Javascript.
As far as I've seen as an outsider to the embedded world the main barriers to adoption of higher level languages have not been based upon concerns of reliability, but instead memory usage and timing constraints, the former of which is less and less of a real problem outside of extremely cost constrained applications.
To address the sibling comment, we don't use much TypeScript yet, but I'm open to it. I'm also looking at ReasonML because I'm cautious about half-measures when it comes to type safety.
Much of our complexity stems from race conditions between PLC and the JS server, so the next system is likely to use node.js on linux boards instead of a PLC. We currently have a supervisory safety system with all safety-rated hardware and controls, and will almost certainly continue using this approach as we replace the PLC.
https://todbot.com/blog/2006/09/25/arduino-the-basic-stamp-k...
> Getting to the “Hello World” of microcontroller projects, the blinking LED, on Arduino costs $32 compared to the $119 for a Basic Stamp. This is perhaps a little unfair because the Basic Stamp board contains a full bread-boarding space. A similar setup for Arduino would cost about $60, still a 2x savings (and can made cheaper if you want).
[snip]
> The standard Atmel AVR ATmega8 chip used on the Arduino board can be obtained for less than $4. The Basic Stamp must be obtained from Parallax and costs $50.
It just seems insane to me to use a language with such bizarre semantics.
Heck, the ESP32 runs circles around the Amstrad that I used to play Defender of the Crown on.
I believe this is the reason 3D printers and other CNC machines still use a seperate dedicated controller such as original arduino rather than just using the GPIO on a newer arm board running a full stack.
If it's two totally independent cores with totally independent sets of devices, how do you manage the pinmux? Are there independent pinmuxes?
And finally is the M4 core capable of detecting single-faults in the cache, memory, flash registers, and instruction pipeline? Such as might be caused by cosmic rays?
These are some things I would look for if I was specifying a processor pair for use in a safety-critical system.
As far as I can see they have mostly separate memory busses, and a lot of the peripherals can only be accessed directly by either the M7 or the M4. Though there is some cross-bus access and how that works I have no idea.
They specify that all the SRAM memory and Flash uses ECC, but no mention of the registers that I could spot.
By no means a simple chip to wrap ones head around, but certainly looks interesting. Pricing of the Arduino though... not for me, at that price I'd rather take the RPi plus some extension board.
Factory automation applications written in BASIC have been a thing for decades. Javascript & Python are improvements in many ways.
Like everything else in engineering, you have to know what you're doing, what you and your tools are capable of, and what performance is needed. Not everything has a 1ms deadline and the vast majority of so-called "industrial" applications will work perfectly fine on a 1-second loop.
As far as engineering goes I would expect most engineers would feel more comfortable putting their seal on something that was over-engineered than just good enough. This is similar to why when designing a circuit it is common practice to double the power dissapation or wattage of components.
I see no reason Java or Python languages wouldn't work or any other language for that matter, as long as they were running on a stable system, I'm just not convinced that arm processors offer that stability but again I may be wrong.
MicroPython/CircuitPython is the funnest thing ever. And you can do all the serious things you need. There is nothing you can't do in MicroPython. And if you need to do stuff fast, writing C libraries is quite easy.
It's totally fair to not like it and for sure it has strengths and weaknesses, problems where its a good fit and problems where it is a bad fit - but don't dismiss it. It's simply to good for that.
My favorite example of that is the system that a contractor wrote for us using bitwise logic and dual-nested loops that worked perfectly for function but each time we needed to make a change we needed at least 3 days to re-read the code for understanding. It passed all of our system-level and integration-level testing but if you put any one of us on the spot about how it actually worked we would have been screwed.
ARM M7 at 480MHz and ARM M4 at 240MHz
2MB SDRAM
16MB Flash
USB, host and device
WiFi
Bluetooth
10/100 Ethernet
MIPI DSI lcd panel
DisplayPort over USB-C (graphics out)
Integrated Li-Po charger
3x ADC 16 bit
2x DAC 12 bit, 1MHz
4x UART
22x Timers
2.95µA in standby mode
That's obviously way too much to come out of the Arduino style pins. There are two 80 pin high density connectors on the back which have everything on them.
That being said, do you have any examples of other entries in this category that are suitable for industrial / automotive use?
Does anyone else remember when a Keil C 8051 at 20MHz devkit would cost you several hundred dollars for the hardware, and then several hundred dollars for the compiler?
I remember... it was like... what? 10 years ago? Not actually very long ago...
Why would anybody use an Arduino versus a five dollar Raspberry Pi Zero?
Cost is another - sure the dev boards are expensive as compared, but the chips used are easier to integrate with your own designs than building an rPi into them.
Just different use cases, in essence.
Though I'm sure many `purests` will say this is not bare metal and it's impossible upon modern CPU's due to the ISA microcode.........
Very nice to be able to ssh to my Pi and get dropped immediately into an IEX repl (no auth, no command prompt, it's just IEX over SSH)
The genuine Arduinos are expensive. The clones are cheap.
Downtime of a machine can quickly rack up huge costs, so you want to spend extra on hardware that can resist greater temperature ranges, vibration, radiation, magnetism, moisture, etc.
But is the quality of the Arduino software/libraries good enough ?
So calling this "the Arduino goes pro" seems like "marketing".
I don't see any purpose of Arduino outside education for kids. Makers should use cheaper products/knockoffs at worse.
That said, it does come with a lot of SRAM and the wifi/bt connectivity is obviously great.
There are actually hacky ways to work around that using DMA but yeah. Software PWM sucks.
Either way, the ESP's are an incredible value (I use both).
Can your Rasp. Pi Zero sleep at micro-amp currents, and self-wakeup 5 hours from now to perform some task, and go back to sleep? The specs here for this Arduino are downright ridiculous for low-power applications. We're talking about using 3x AA batteries for MONTHS. (3x NiMH AA will be 3.6V with 2000 mA-hrs. Using 3uA is 600,000 hours of battery, or 25,000 days of charge. You'll "only" last months because NiMH AAs will self-discharge before your Arduino actually uses all the charge).
And the Arduino here has all of the analog circuitry you need. 12-bit DAC means you have 4096-levels of output... a 3.3V signal can be varied in 0.8-millivolt increments. That's 0.0008Vs per increment.
The 16-bit ADC means that the Arduino can sense 0.05mV differences (probably at very low frequencies, but its an option with the right tradeoffs). Without any supporting chips. Alternatively, you have a 1MHz ADC (at some unspecified lower resolution. Probably 1MHz best-case 1-bit ADC), which means you can perform a million measurements in a second, to measure "rate of change" of your sensor.
The "1MHz" spec is useful for motors and other higher-speed equipment. If a Motor is rotating at 12,000 RPM, 10kHz ADC (1/100th of the max rate 1MHz, or 7-bits of precision per sample) will still be 500 samples per rotation, more than enough to get a good estimate on the motor's velocity.
---------
Application: 3xAA batteries, remote sensor that sends a WiFi packet every hour for temperature (or any other sensor that can be represented by voltage between 0V to 3.3Vs. Or even a sensor that needs to "sample" over a few milliseconds to get a value, such as determining the speed of a motor)
Stick a cheap 5V solar panel + some simple charge circuitry to trickle-charge the AA NiMH batteries, and you probably can run the rig indefinitely. (Really, you just need to ensure that the AA batteries don't leak current through the solar panel. So maybe a 0.7V diode to prevent backwards current, and you're set. 5V solar panel minus 0.7V diode outputs 4.3V nominal, but then becomes current-limited (probaly??) as it drops down to the 3.6V the batteries are set at. As long as you're only pushing milliamps, you're in NiMH trickle-charge mode which NiMHs are really, really good at).
-------
EDIT: I didn't even notice the integrated Li-Po charger. NiMHs are cool because they're bloody simple to use in trickle-charge mode. But if you've got a Li-Po charger built into the damn thing, you might as well use Lithium-Polymer cells instead.
There's a ton of complexity involved in safely charging, and discharging Lithium-Polymer batteries. But hell, if its built into the Arduino, might as well use it. In this circumstance, the 5V solar panel is plugged into the Arduino somehow, and the Arduino charge-circuitry will then safely handle the decisions involved in charging / discharging the Li-Po battery (also hooked up to the Arduino).
----------
EDIT2: I guess a "normal" Arduino can do this at low power consumption too. The reason to get "Arduino Pro" is for integrated Wifi + 480MHz processor. So you'd want some "difficult calculation" associated with the sensor reading... maybe a local GUI with a screen + Javascript to simplify the GUI-design.
The Arduino can sleep most of the time, but if a user comes up to maintain the device, they can click a button, bring the Arduino out of sleep mode. It boots up to a Javascript web-GUI for maintenance, and then sleeps back down to 3uA sleep mode once the user is done with local maintenance.
----------
100 Mbit Ethernet can have PoE, so any Ethernet Wire could transmit power instead (to a Rasp. Pi Zero). The Arduino's niche would be some kind of wireless, remote-power situation that requires very, very low power consumption on the scale of weeks.
I wonder if the newer low-self-discharge batteries might get you even more lengthy usage times. Something like a gen 2 Eneloop lite can hold onto 60% of its capacity after five years[1], which is just plain insane.
Longevity is important in this application because replacing batteries is very labor-intensive.
They exist at different positions on the price/performance scale. It's as simple as that.
Using Mercedes vs Hyundai implies that there's a difference in quality, whereas my intent was to say that they are basically the same but with qualitative differences that only matter depending on the actual circumstances.
I find that the typical answer to questions like this (e.g., the ones already given) tend to confuse the questioner even more by tossing out technical jargon out that isn't helpful.
In the end, the choice of one computing/control platform vs. another is really just which one happens to be a more suitable choice for the problem it's being thrown at.
Ultimately they're both computing platforms used for control purposes. In some cases, the predictable I/O performance of the Arduino is an advantage over the Pi. In others it's not. In some cases, the built-in network access, CPU speed, UI capability of the Pi is an advantage, in others it's not.
If Bezos actually does drive an Accord (with an entourage of security around him I imagine) then all that tells me is that for his "application," it's sufficient. It doesn't say anything about the merits of other cars.
No one needs an S-Class, it's merely a nice-to-have. Is that the same statement that no one needs this new Arduino? That they should only buy it if they have extra money to spend and want a luxury item?
You are at the mercy of the OS on a Pi.
For somethings that doesn't matter at all, for others it really, really does.
They still need an SD card to function. So, that price is going to double at a minimum.
Raspberry Pis aren't great when working with analog signals. I don't think they even come with analog->digital converters, and PWM can be janky
SD cards suck, when it comes to reliability. You can mitigate this by making the filesystem read-only, but your SD card will still crap out more quickly than built-in flash memory would.
Supply used to be an issue with the Zero, but I don't know if that's still true.
Looks like this has a integrated Li-Po charger which should mean you can have a UPS like battery backup.
Folks may use this as a development platform that eventually gets a custom PCB made for the end product. ( it's open hardware so it has all the schematics https://content.arduino.cc/assets/Arduino-PortentaH7-schemat... )
It's really just different features for different needs.
1. The $5 Raspberry Pi Zero isn't really $5.
2. The fact that the $5 advertised price isn't the real price, and the inventory games they play raises ethical problems for some people.
3. You can get an Arduino clone for less than $2 (for real, and in bulk).
4. The Pi and other SBCs have higher power requirements, so they can't reliably run off AA batteries.
5. The Pi also requires an SD card, increasing the cost.
6. The Arduino comes in many form factors which are considerably smaller than SBCs.
7. The two aren't drop in replacements, the Pi runs a "real" opperating system that does a lot of things in the background. So communicating with other devices which have specific timing requirements is significantly more difficult on the Pi.
8. The market for Arduino "shields" is much more competitive than the Pi "hats".
9. There are just a lot more shields and sensors available designed to interface with the Arduino
10. The Pi's IO pins are 3.3v, where the Arduino's are (on most boards) 5v. So using sensors/boards designed for the Arduino requires a level shifter
And to what unethical inventory games are you referring? That seems like a pretty serious accusation you’re making.
The main thing to look out for is that it doesn't have HDMI out, only two headers for composite out. I imagine most people plan to run them headless anyway, but unless you have something that can display composite video, it can be a pain to set up at first.
Another option is that when you buy from Adafruit, you can buy one of each version. One Zero, one Zero W, and one Zero WH, for $29 plus shipping. You can then buy a USB WiFi adapter off E-Bay for about $1 shipped, and as many USB OTG adapters as you need for less than $1 each. Depending on shipping, that puts you in the $11-$12 per board range.
Microcenter often has the Zero W also discounted to $5 for a single and then $15 for every one after that. Right now, they have them discounted to $10 for 1 and $20 for every one after that. https://www.microcenter.com/product/486575/raspberry-pi-zero...
Forum post from a member of the Raspberry Pi team: "They will never be available in bulk amounts at the $5 and $10 price points, it's not cost effective to sell at that price. But they ARE available for bulk buys - i.e. demand no longer outstrips supply.
But we can sell individual items at that prices, for educational needs - i.e. those who cannot afford the higher price of the Pi3. Call it an educational discount." https://www.raspberrypi.org/forums/viewtopic.php?t=201916#p1...
From the above, I agree with the other poster who claimed that $5 is not the real price for the Zero, but rather a limited quantity specially discounted price.
It is a real price. For the Zero W. I bought one a year ago. Ordered it, then headed to the store a bit later. https://i.imgur.com/ajeH8PQ.png
They've since changed the price to $10.
IMO, if I can't buy 10 of something for $50 or 100 for $500, the "real price" isn't $5/unit. Microcenter would pretty consistently sell $5 for 1 and then $15 or $20 for each additional unit.
1.) Pin control simplicity - Arduino's bread & butter is basic logic statements wrapped around pin signals (e.g. if pin #1 receives an inbound burst of electricity, tell pin #2 to send an outbound burst of electricity). Since most commercial processes are loops of very specific routines, this is all that's needed (not to mention it's easily scalable to massive operations).
2.) Battery backup - Raspberry Pi wasn't really designed to be powered by batteries, and voltage fluctuations lead to crashes. Also, since Raspberry Pi requires more power (than Arduino) to operate, it would eat battery life much faster.
3.) Startup consistency - When Arduino is powered on, it has a consistent startup that quickly loads your sketch. The restart behavior is predictable and downtime is minimal. With Raspberry Pi, you're dealing with an operating system starting up. This makes it much more cumbersome to get back to where it was prior to loss of power.
Understanding how communication protocols are supposed to work, knowing how to read a data sheet, and using those skills to set registers on an IC directly should be in everyone's toolbox. Otherwise, you're limited to whatever chips someone's wrote an Arduino library for.
Plus, debugging is much more difficult if you can't analyze a stream of data with a scope or logic analyzer, and actually understand what you're looking at.
I was going to pick a few cheap books on Arduino as I thought that was the way to go.
I am a hobbyist, but I want to try to build some viable products.
Beyond the hardware, I'd love to get some more details on the software tool chain and their plans to sell/support turning the prototypes into production modules.
If there's no second source of boards, I can't consider that production ready for anything. It was and still is a COTS module that can be modified for a single purpose application but there's no way I would resell this as a commercial unit.
Same for RPi and all the others. Spin it yourself or take your chances.
Now, if you really care about supply chain security, that might be a problem, but for everyone else...
Looks like the STM32H7 supports one MIPI CSI-2 peripheral (and/or one MIPI DSI).
Another comment on this thread mentioned on the back of this module are two long flat board-to-board style connectors.
Here's an article on writing C targeting bare-metal Raspberry Pi.
http://www.valvers.com/open-software/raspberry-pi/step01-bar...
Gave up after a minute. What a shame using those dark patterns (and sad because I wanted to read it)
"Here, now you can buy hardware that enables you to hire bootcamp-level devs to do your professional industrial work. That way you can pay non-professional wages for professional-level work!"
Stop normalizing putting bloated, heavy languages on embedded platforms.
Last time I checked, PICBasic was a thing, and spawned a generation of programmers.
Comodore 64 Basic, and TI-83 Basic were also simplified programming environments. (TI-83 implemented jumps as a O(n) lookup throughout your code... jumping to later functions was more costly than jumping to earlier functions...).
Its the simple programming environments that spawn new generations of programmers. Today, "Basic" is no longer the starting point, today's beginner programmers use Javascript or Python.
But there always were "beginner" languages, no matter how slow computers were in the past.
Some of the biggest successes are because beginner-friendly kits were delivered to universities. Linux and Unix are a great example of this: students taught in Linux / Unix environments (even using "toy" languages like Python) end up growing into professionals who... still use Linux.
One of the most important business moves for a "platform" is to figure out how to get beginner-level students comfortable with your platform. Linux somewhat did this accidentally, but today we need to purposefully create that environment.
--------
Besides, even on the same project... not everyone needs to be an expert embedded engineer. By allowing Javascript onto the platform, you can hire a Web GUI-developer who probably knows a lot more about UI-design than you.
The Web GUI master can work their Javascript into your application, and run code side-by-side with your tightly optimized C code. No, it won't be efficient. But that's what a 480MHz processor is for, to help you run less efficient code at speeds that are acceptable.
This isn't even hypothetical: with WiFi 802.11 n support, this Arduino could very well be running Web-applications served from some centralized location (distributed wirelessly over standard LAMP / HTTP stacks). It will be up to the C System programmers to ensure that a locked-up GUI thread won't wreak the system (or break realtime promises)... but there would be major benefits to distributing applications over standard internet mechanisms.
Sorry but, if you have to ask this question, it's pretty clear that you have no idea what many industrial settings require.
There are ruggedness requirements, stability requirements, longevity requirements...
I work in an industry where our products are used for LITERAL decades. There's no way that anything even remotely marketed as "beginner friendly" could begin to work for anything we do.
You can't just throw more hardware at a problem and use that as an excuse for shitty software, come on. This incredibly flawed logic is why the minimum requirements for a chat program include 32GB of RAM.
Beginner friendly doesn't mean that the other requirements disappear.
The Arduino can run Javascript. Sure, you don't have to make it use Javascript, but it can be done. Just because Arduino runs Javascript doesn't change its -40C to +85C operating temperature.
Arduino can be BOTH beginner friendly, AND rugged enough to operate at sub-zero temperatures indefinitely. And if you really want to "remove Javascript" from your stack, then you're 100% welcome to do that.
Universities on the other hand, have other requirements. Beginner friendly is absolutely a necessity for students. You have to hook students with something easy if you want the students to be interested in projects. Having a SINGLE platform scale from beginner usage, all the way up to professional usage, is extremely important for the general ecosystem.
And I still argue that opening up Javascript developers onto the platform is a good thing. UI design is complicated, and someone who fully focuses on the user-experience, culture, and presentation is useful. (Even if a GUI designer is ignorant of embedded issues, they can remain helpful in other ways).
Beginner friendly includes price. If you have the other requirements, it's going to cost much more. Doesn't matter if it's beginner friendly if a development board costs $5k.
The actual device here looks quite rugged, comes with a variety of useful specs. The Arduino Pro IS the beginner friendly development board, the beginner-friendly introduction to STM32.
A "real" product would strip off all the unnecessary parts and only use the $17 STM32H7 chip alone.
For example, it is impossible to control how V8 converts its internal integers to floats and how. One Math.* method may output a Number which is a float behind the scene, another one int, and another one int double.
GC on MCU is completely unpredictable too. If it fires when you need to poll latency sensitive peripheral, things hang.
But I suspect there are enough niches it fills it will be successful.
Their codebase would improve immensely if they used a more powerful chip to run Linux and Python instead.
If newer hardware makes it cheaper and easier to make cool shit while maintaining the price point and power budgets of previous generations, who gives a shit?
This new stuff makes tinkering with hardware way more accessible than before and that is a good thing for everybody.
Arduino is excellent for what it was originally designed for - an easy, accessible platform for artists and non-engineers to experiment and prototype. Arduino are now reaching well beyond that market and targeting more serious applications, so we are entirely right to question whether a) Arduino's design trade-offs are acceptable in mass-market products and b) whether we really want to lower barriers to entry in this area.
Personally, I think the answers are a) no and b) absolutely not. If you need the hand-holding that Arduino offers, you have absolutely no right to ask a user to plug your widget into their network. Engineers are in a position of trust and we have a moral obligation to treat that position with absolute seriousness.
If you're going to use something that's basically a late-90s desktop and develop on the basis that you can afford to burn cycles, you might as well use a proper RTOS and enjoy all the affordances that come with it.
Arudino however is great as an experimentation platform, where having access to things like a Python or JS REPL can make experimentation a pleasure, being able to rapidly update and prototype is much easier when you don't have to reflash and reboot every time.
I recently bought a door access control pad, plugged it into an ESP32 and messed with it using MicroPython to better understand how it'd produce outputs. The datasheet it came with was lacking to say the least, but this was a big savior.