Not sure why that's contorting, a markov model is anything where you know the probability of going from state A to state B. The state can be anything. When it's text generation the state is previous text to text with an extra character, which is true for both LLMs and oldschool n-gram markov models.
Yes, technically you can frame an LLM as a Markov chain by defining the "state" as the entire sequence of previous tokens. But this is a vacuous observation under that definition, literally any deterministic or stochastic process becomes a Markov chain if you make the state space flexible enough. A chess game is a "Markov chain" if the state includes the full board position and move history. The weather is a "Markov chain" if the state includes all relevant atmospheric variables.
The problem is that this definition strips away what makes Markov models useful and interesting as a modeling framework. A “Markov text model” is a low-order Markov model (e.g., n-grams) with a fixed, tractable state and transitions based only on the last k tokens. LLMs aren’t that: they model using un-fixed long-range context (up to the window). For Markov chains, k is non-negotiable. It's a constant, not a variable. Once you make it a variable, near any process can be described as markovian, and the word is useless.
Sure many things can be modelled as Markov chains, which is why they're useful. But it's a mathematical model so there's no bound on how big the state is allowed to be. The only requirement is that all you need is the current state to determine the probabilities of the next state, which is exactly how LLMs work. They don't remember anything beyond the last thing they generated. They just have big context windows.
The etymology of the "markov property" is that the current state does not depend on history.
And in classes, the very first trick you learn to skirt around history is to add Boolean variables to your "memory state". Your systems now model, "did it rain The previous N days?" The issue obviously being that this is exponential if you're not careful. Maybe you can get clever by just making your state a "sliding window history", then it's linear in the number of days you remember. Maybe mix the both. Maybe add even more information .Tradeoffs, tradeoffs.
I don't think LLMs embody the markov property at all, even if you can make everything eventually follow the markov property by just "considering every single possible state". Of which there are (size of token set)^(length) states at minimum because of the KV cache.
The KV cache doesn't affect it because it's just an optimization. LLMs are stateless and don't take any other input than a fixed block of text. They don't have memory, which is the requirement for a Markov chain.
Have you ever actually worked with a basic markov problem?
The markov property states that your state is a transition of probabilities entirely from the previous state.
These states, inhabit a state space. The way you encode "memory" if you need it, e.g. say you need to remember if it rained the last 3 days, is by expanding said state space. In that case, you'd go from 1 state to 3 states, 2^3 states if you needed the precise binary information for each day. Being "clever", maybe you assume only the # of days it rained, in the past 3 days mattered, you can get a 'linear' amount of memory.
Sure, a LLM is a "markov chain" of state space size (# tokens)^(context length), at minimum. That's not a helpful abstraction and defeats the original purpose of the markov observation. The entire point of the markov observation is that you can represent a seemingly huge predictive model with just a couple of variables in a discrete state space, and ideally you're the clever programmer/researcher and can significantly collapse said space by being, well, clever.
>Sure many things can be modelled as Markov chains
Again, no they can't, unless you break the definition. K is not a variable. It's as simple as that. The state cannot be flexible.
1. The markov text model uses k tokens, not k tokens sometimes, n tokens other times and whatever you want it to be the rest of the time.
2. A markov model is explcitly described as 'assuming that future states depend only on the current state, not on the events that occurred before it'. Defining your 'state' such that every event imaginable can be captured inside it is a 'clever' workaround, but is ultimately describing something that is decidedly not a markov model.
It's not n sometimes, k tokens some other times. LLMs have fixed context windows, you just sometimes have less text so it's not full. They're pure functions from a fixed size block of text to a probability distribution of the next character, same as the classic lookup table n gram Markov chain model.
1. A context limit is not a Markov order.
An n-gram model’s defining constraint is: there exists a small constant k such that the next-token distribution depends only on the last k tokens, full stop. You can't use a k-trained markov model on anything but k tokens, and each token has the same relationship with each other regardless. An LLM’s defining behavior is the opposite: within its window it can condition on any earlier token, and which tokens matter can change drastically with the prompt (attention is content-dependent). “Window size = 8k/128k” is not “order k” in the Markov sense; it’s just a hard truncation boundary.
2. “Fixed-size block” is a padding detail, not a modeling assumption.
Yes, implementations batch/pad to a maximum length. But the model is fundamentally conditioned on a variable-length prefix (up to the cap), and it treats position 37 differently from position 3,700 because the computation explicitly uses positional information. That means the conditional distribution is not a simple stationary “transition table” the way the n-gram picture suggests.
3. “Same as a lookup table” is exactly the part that breaks.
A classic n-gram Markov model is literally a table (or smoothed table) from discrete contexts to next-token probabilities. A transformer is a learned function that computes a representation of the entire prefix and uses that to produce a distribution. Two contexts that were never seen verbatim in training can still yield sensible outputs because the model generalizes via shared parameters; that is categorically unlike n-gram lookup behavior.
I don't know how many times I have to spell this out for you. Calling LLMs markov chains is less than useless. They don't resemble them in any way unless you understand neither.
I think you're confusing Markov chains and "Markov chain text generators". A Markov chain is a mathematical structure where the probabilities of going to the next state only depend on the current state and not the previous path taken. That's it. It doesn't say anything about whether the probabilities are computed by a transformer or stored in a lookup table, it just exists. How the probabilities are determined in a program doesn't matter mathematically.
Just a heads-up: this is not the first time somebody has to explain Markov chains to famouswaffles on HN, and I'm pretty sure it won't be the last. Engaging further might not be worth it.
I did not even remember you and had to dig to find out what you were on about. Just a heads up, if you've had a previous argument and you want to bring that up later then just speak plainly. Why act like "somebody" is anyone but you?
My response to both of you is the same.
LLMs do depend on previous events, but you say they don't because you've redefined state to include previous events. It's a circular argument. In a Markov chain, state is well defined, not something you can insert any property you want to or redefine as you wish.
It's not my fault neither of you understand what the Markov property is.
By that definition n-gram Markov chain text generators also include previous state because you always put the last n grams. :) It's exactly the same situation as LLMs, just with higher, but still fixed n.
We've been through this. The context of a LLM is not fixed. Context windows =/ n gram orders.
They don't because n gram orders are too small and rigid to include the history in the general case.
I think srean's comment up the thread is spot on. This current situation where the state can be anything you want it to be just does not make a productive conversation.
'A Markov chain is a mathematical structure where the probabilities of going to the next state only depend on the current state and not the previous path taken.'
My point, which seems so hard to grasp for whatever reason is that In a Markov chain, state is a well defined thing. It's not a variable you can assign any property to.
LLMs do depend on the previous path taken. That's the entire reason they're so useful! And the only reason you say they don't is because you've redefined 'state' to include that previous path! It's nonsense. Can you not see the circular argument?
The state is required to be a fixed, well-defined element of a structured state space. Redefining the state as an arbitrarily large, continuously valued encoding of the entire history is a redefinition that trivializes the Markov property, which a Markov chain should satisfy. Under your definition, any sequential system can be called Markov, which means the term no longer distinguishes anything.
A GPT model would be modelled as an n-gram Markov model where n is the size of the context window. This is slightly useful for getting some crude bounds on the behaviour of GPT models in general, but is not a very efficient way to store a GPT model.
I'm not saying it's an n-gram Markov model or that you should store them as a lookup table. Markov models are just a mathematical concept that don't say anything about storage, just that the state change probabilities are a pure function of the current state.
TypeScript is a really decent language though, I wouldn't feel happier or more productive using Fortran or whatever. Its type system is actually really powerful which is what matters when it comes to avoiding bugs, and it's easy to write functional code with correct-by-construction data. If you need some super optimized code then sure that's what WASM is for but that's not the problem with most web apps, the usual problem is bad design, but then choice of language doesn't save you. Sure TS has some annoying legacy stuff from JS but every language has cruft, and with strict linting you can eliminate it.
It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
> Its type system is actually really powerful which is what matters when it comes to avoiding bugs
It is really powerful as compared to Javascript. It is even really powerful as compared to most other languages people normally use. But not very powerful as compared to languages that have 'proper' type systems. Typescript still relies on you writing tests for everything.
The type system is a huge boon for the developer experience, of course. It enables things like automatic refactoring that make development much more pleasant (although LLMs are getting better at filling that void in dynamically typed languages). But it doesn't save you from bugs in a way that the tests you have to write anyway won't also save you from. And those same tests would also catch the same bugs in Javascript, so you're in the same place either way with respect to that.
> It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
This argument is slightly backwards. This is essentially the argument used for "javascript in the backend" and "let's package the whole browser as application runtime so we can use javascript". The core of the argument is that javascript is ipso facto the best language/runtime to write any code in, including refactoring existing codebases. Bringing javascript out of the browser also means you have to write bindings for javascript and recreate the existing ecosystems anyway.
Even if you approach this from "single codebase across runtimes" angle, the conclusion to bridge the gap between browsers and languages with existing codebase, expertise and ecosystems is much more reasonable than rewrite everything in javascript.
The whole point of "agentic AI" is that you don't have to rigorously test every potential interaction, which means that even a temperature zero model may behave unexpectedly, which is bad for security.
Right, I'm using a perhaps loose definition of deterministic here, as in -- "With AI tools, you cannot 100% predict any output based on input, the way you can with most programming."
I've definitely had AIs thinking and producing good answers about specific things that have definitely not been asked before on the internet. I think the stochastic parrot argument is well and truly dead by now.
I've also experienced this, to an extent, but on qualitative topics the goodness of an answer - beyond basic requirements like being parseable and then plausible - is difficult to evaluate.
They can certainly produce good-sounding answers, but as to the goodness of the advice they contain, YMMV.
I've certainly got useful and verifiable answers. If you're not sure about something you can always ask it to justify it and then see if the arguments make sense.
The point being made here is about the data LLMs have been trained with. Sure that contains questions&answers but obviously not all of it is in that form. Just like an encyclopedie contains answers without the questions. So imo specifying this as 'no-one asked this before' is irrelevant.
More interesting: did OP get a sensible answer to a question about data which definitely was not in the training set? (and indeed, how was this 'definitely' established'). Not that if the answer is 'yes' that'll prove 'thinking', as opposed to calling it e.g. advanced autocompletion, but it's a much better starting point.
Because I gave them a unique problem I had and it came up with an answer it definitely didn't see in the training data.
Specifically I wanted to know how I could interface two electronic components, one of which is niche, recent, handmade and doesn't have any public documentation so there's no way it could have known about it before.
one of which is niche, recent, handmade and doesn't have any public documentation
I still see 2 possibilities: you asked it something similar enough that it came up with a fairly standard answer which just happened to be correct, or you gave it enough info.
- for example you created a new line of MCUs called FrobnicatorV2, and asked is 'how do I connect a power supply X to FrobnicatorV2' and it gave an answer like 'connect red wire to VCC and black to GND'. That's not exactly special.
- or, you did desribe that component in some way. And you did do that using standard electronics lingo so essentially in terms of other existing components which it definitely did know (unless you invented something completely new not using any currently know physics). As such it's irrelevant that your particular new component wasn't known because you gave away the answer by describing it? E.g. you aksed it 'how do I connect a power supply X to an MCU with power pins Y and Z'. Again nothing special.
If a human uses their general knowledge of electronics to answer a specific question they haven't seen before that's obviously thinking. I don't see why LLMs are held to a different standard. It's obviously not repeating an existing answer verbatim because that doesn't exist in my case.
You're saying it's nothing "special" but we're not discussing whether it's special, but whether it can be considered thinking.
it's obviously not repeating an existing answer verbatim
Not verbatim in the sense that the words are different doesn't make it thinking. Also when we say 'humans think' that means a lot more than only 'new question generates correct answer' or 'smart autocompletion'. See a lot of other comments here for details.
But again: I laid out 2 possibilities explaining why the question might in fact not be new, nor the data, so I'm curious which of the 2 (or another) explains the situation you're talking about.
You're saying it's nothing "special" but we're not discussing whether it's special, but whether it can be considered thinking.
Apologies, with 'special' I did in fact mean 'thinking'
Don't look at just the specs. You also need to look at the board design and programming environment. I've used the ESP32 native tools and they are a lot more complex than Arduino. But I'm an embedded firmware developer, so it's kind of what I expect. But I used an Arduino, with 5V tolerant outputs, to light up Halloween costumes for years. I do it in 1 page of code that's I write in their IDE. I don't have to set up an SDK. And the Arudino API hides all the details I don't care about. Especially if I'm really just slinging solder and wiring something up quick.
I plug the USB in and its the same as an Arudino, can even use Arduino IDE, but I prefer VS Code with the PlatformIo extension. You can even use the Arduino Library (#import <Arduino.h>
It is basically the same thing, don't understand either why it would harder.
The only thing is to add the ESP32 module on the addons since it doesn't come enabled by default. Arduino isn't good for projects with more than 5 source code files, it is an awful IDE beyond the basic things you can pack on a single source code file.
Always had so many difficulties handling the IDE defects, basically it can crash when starting and every now and then will just refuse to upload the firmware. The other part are libraries, really difficult to setup all the needed libraries for larger code bases.
On that sense, Visual Code with PlatformIO went far beyond. Just open the project there and the libraries are taken care. The connection to boards is more robust. I'm not so sure how to feel with this sale to Qualcomm, it just feels that it is going there to die.
Quite the difference from the early days where Arduino had such energy and the tools would bring almost anyone into microntrollers with such ease.
As a complete beginner to hardware stuff, I do find the Arduino Cloud thing to be pretty compelling. Being able to push out updates over the cloud is nice! Buuuut.. once I'm mostly done with a project, there's just no need at all for it anymore. The Arduino I'm using for a receipt printer is just sitting there and now the cloud bit doesn't do anything for me.
And the problem I have is that ESP32s aren't much more difficult to set up nowadays, are wildly cheaper, and I'm soso excited to start messing around with ESP-NOW which I don't think Arduino has? But having like 10 ESP32s for messing around freely is more valuable than the cloud thing for me. And there are some super fun projects for ESP32 also like the Cheap Yellow Display thing. I ordered what I thought was one display, except it was 3, and I thought I would have to provide my own ESP32s but nope, they come with them. And these three CYDs were cheaper than a single Arduino it's actually crazy.
Yeah, ESPnow is pretty good. I'm using it more than LoRa because all ESP32 come with it and is really cheap, whereas with LoRa is all the trouble with an additional module that costs 3x more than an ESP32.
That yellow display is pretty good. I've built a tiny operating system for it, it is an unbelievable hardware for the cost of the material.
agree. when arduino ide first came out it was great (for the times). and to be fair at that time vscode was not a thing. but it's a big ? why arduino did not just go all in on vscode once it was clear where the market leader in IDE was headed
VS Code has enough momentum by now that Microsoft couldn't kill it even if it wanted to. And a lot of the arduino-side work would involve creating/tweaking LSPs to their ideosyncrasies and making IDE-agnostic compilers... all of which is IDE agnostic and makes Arduino more useful to all users.
And, worst case, they could take it all to IntelliJ or other IDE vendors and quickly spin out an Arduino-branded IDE that isn't raw sewage.
I'm a java developer coming from a world where the IDE is tightly integrated with the language.
For me, VS code always felt like a "jack of all trades and master of none". C/C++ are strongly typed languages, they aren't different from Java in that regard and yet it is so time consuming to navigate code, see if the syntax is correct and so forth. Really annoying to only know if the code is compiling correctly after pressing the compile button and wait about 30 seconds.
These are things that in the Java world nobody really thinks about because the IDE does a lot of the heavy effort in the background, yet in VS code or C++ it really feels like going back to 2005. For Javascript gets even worse on VS code whenever one is not using NPM. Needs reload the browser to check the console and see if things are working as expected. Good luck trying to find functions somewhere in the codebase without manual text search.
It is not my intention to shade any of those languages nor IDE, I just honestly wish that the IDE for those languages was as powerful as the ones in Java and C#. Arduino had the opportunity to do that since they are tightly committed to C/C++ and control everything on the build process but their goal was always more focused on education level than a more professional development. Let's see if with Qualcomm this is now changing into a tighter IDE+language integration.
Also primarily java/intellij hser but for any non static languages like Js/Python or even simple text editor VS code is lovely. It's very simple to use, looks nice, full of features and the plugin system is beautiful anddd it just feels astonishingly lightweight.
Okay, that's cool for Java, but have you ever tried the absolute crap pyramid that is arduino's IDE? 2005 Eclipse would be a vast improvement in comparison. And Qualcomm never cares about anything that doesn't directly increase pforit margin, so "more money for better IDEs" with qualcomm in charge is just delusional.
Missing "some features" is an understatement. I really value what those folk are doing, but the lack of extensions such as the ones for C/C++ from Microsoft really just make it subpar.
I got introduced to microcontrollers through the original Arduino board. It took me only a year to switch to bare metal atmega/attiny (zero external components!), and to this day, those are my favourite micros despite all their shortcomings. Theyare extremely well documented, and them being 8-bit with a simple instruction set makes it very easy to learn assembly (or even opcodes). At the same time, they are compatible with 5V logic (and can be abused!) which makes them almost perfect for beginners.
Would I have been able to learn assembly with ESP32? Probably not. You couldn't even find proper manuals for ESP8266 back in the day because they either didn't exist, weren't in English or weren't released to the general public...
Well which board do you select then? ESP32 boardfiles do not come with the Arduino application per default.
Sure, to you and me this may seem trivial, you paste the URL into the prefs, but there are people who will get stumped by this and with an Arduino there is one less step you can forget, not know about or do wrong.
As someone who teaches those things at an University level I can assure you that does make a difference for at least 50% of my students if I let them try to do this unguided.
You must have done File -> Preferences... -> Additional board manager URL -> OK, and clicked Tools -> Board -> Board manager... -> esp32 by Espressif Systems -> Install.
And that's like, I think installing VSCode itself can be more scary, so...
(psa: Arduino IDE 1.x works flawlessly for tons of non-Arduino boards, including Pi Pico, ESP32 devkits, etc. Most Arduino users aren't even able to consider processor implementation specifics, never signed an NDA in life, and don't even know where generated binaries go, so those boards are almost "binary compatible" with each others, all in _very_ positive sense)
Programming an ESP32 using the arduino ide is no harder than programming an arduino using the arduino ide. The only difference is that you can find an ESP32 for much much cheaper.
Trouble is, this kind of trivial throwaway application is all that Arduino is really good for. Because the framework is designed to support thousands of chips, it supports none of them well. Any arduino code you write is easily 5x more terse than any of the native libraries, but it's also 10x slower. If you don't care, you don't care. But if you do care, Arduino is the least appropriate way to make a microcontroller go.
Besides that, IMO hiding hardware details from the developer is the worst thing about Arduino. The hardware details matter and it's far too easy to get footgunned by some implementation detail hidden from you.
But really, esp-IDF isn't that much more complex, nor are most of the other native frameworks. It's a bit more verbose, but esp-IDF provides helper libraries that replace almost everything Arduino provides, but in a way that is actually designed for the hardware and doesn't have to do things like lookup pin numbers in a giant table for each and every gpio call.
> Besides that, IMO hiding hardware details from the developer is the worst thing about Arduino. The hardware details matter and it's far too easy to get footgunned by some implementation detail hidden from you.
Wasn't Arduino not for developers, but for hobbyists? People who aren't super technical but want to do something neat with basic microcontroller functionality?
You're complaint kinda seems like saying "BASIC isn't great language, it's got a lot of problems when used for enterprise applications." It's not really meant for that.
IMO Mbed was just as easy for hobbyists but had a far better designed API that could support professional work as well. Arduino is just badly designed.
Unfortunately the Mbed guys stuck to their crap web-based IDE for waaaay too long, and when they finally realised it couldn't cut it, they pivoted to Yotto, which was a terrible Python based build too. When that failed they finally made Mbed Studio which was based on Theia (same as Arduino is now) but by then it was too late.
I think they also lacked an obvious "start with this" board like the Arduino Duo.
I think if they have blessed one of the Neutrino boards (which were incredibly cheap and powerful compared to Arduino) with their branding, and switched to Theia like 5 years earlier they might have had a chance.
Real shame because it really was a far superior software system.
I really think what killed Mbed is the C++. I don't want to poison my codebase with the C++ stuff(and now you have to write wrapper for C++ if you want to use them inside your C codebase).
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 valuable in rapid prototyping.
Once I settled in on a board and everything, I could do it the "right way" aka the old waterfall-gile embedded approach and get things tweaked and optimized.
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.
Same deal exactly for the various ESP32 boards. With the added wrinkle that some of them (like T-Display) have had pins swapped in the doc at various stages.
I would argue the RP2040/2350 fills that niche. Cheap, available, easy to program, flexible peripherals, fast enough for many projects, good documentation, and good community support.
RPi's toolchain situation is awful for beginners/hobbyists. CMake and non-manifest-versioned toolchains are a huge barrier to entry. I'd love to use the hardware but have given up multiple times because I'd rather spend my time writing code than wrestling with toolchain setup. And they won't support platformio which could make things massively easier for beginners to set up.
I've never used their toolchain, I use Rust on the RP2040 and it's a breeze to set up.
But yeah there's also CircuitPython where you literally drag and drop a firmware blob onto the volume that shows up when plugging in an RP2040 board, and then you're just editing a Python-esque script to do stuff. Not sure what could be easier when it comes to starting with embedded stuff. You can even use the Arduino IDE with RP2040 boards if you like.
I'm using the RP2040s with FreeRTOS for a hobby project. I think the Pico probe is a much better debugging story than buying a Blackmagic (or if you got the dough, a Segger), to debug the "modern" Arduinos. I have one of the Atmel programmers for the Uno R3/2560/Mega boards and that's nice.
But for people getting started, the ability to just plug in an Uno R3 and stack a motor controller shield on it, is pretty attractive. I like the Cytron break out boards for the Picos, but I still think the path from opening the box to working thing is still easiest with Arduino.
Once you know what you're doing, (and maybe that's when you realize you need a debugger), you move on to something else. And with the Pico I can spend the $800 on an O-scope instead of the Segger.
arduino was supposed to be learning opportunity and training grounds for people who wanted to work in the field in the future, there was small arduino boards (similar to pi pico) for integration with actual projects, but still arduino was for hobbyists and students in the first place
On the other hand, their competitors haven't been sleeping either.
Companies like Adafruit and Sparkfun sell dozens of tailor-made dev board variants, and their I2C module system allows you to mix & match a whole bunch of peripherals.
The code? A handful of lines of Python, which you can drag&drop onto it like it's a flash drive. Or use a browser-based IDE if you want one-click library install and serial logging.
Arduino's IDE was groundbreaking in 2010, but these days there are easier (and cheaper!) alternatives for beginning hobbyists, and better alternatives for power users.
Good on the Arduino folks for getting acquired, then. They still have a niche and a brand with name recognition, even if that niche might be stable at best, collapsing at worst.
Even if you like the Arduino programming environment (and I do), there seems to be little reason to use Arduino hardware unless it’s for compatibility with other hardware you have? For example, there is a very nice unofficial port of Arduino for the Raspberry Pi Pico. There are also many fine Arduino-compatible single-board computers from Adafruit. The Arduino board form factor seems big and clunky in comparison.
I don’t even use the Ardiuino IDE anymore; I've switched to VS Code using PlatformIO.
It’s great that all these microcontroller boards and peripheral breakout boards can be programmed using the same basic API’s, but I don’t think it helps Arduino the company very much.
There's a wealth of easy projects that a person can get started with using an Arduino.
Without any opportunities for getting bogged down in anything extra at all, they can follow a simple recipe and quickly begin to blink an LED at the rate of their choosing.
The Arduino was developed to be a teaching tool, and it allows for a person to take little baby steps.
(Whether this placement is good or bad for Arduino as a business entity isn't something that I find particularly important.)
Blinking an LED is what you do for "hello world" on every microcontroller board I've tried. The Arduino IDE supports boards from many different manufacturers.
> I've used the ESP32 native tools and they are a lot more complex than Arduino.
How so? All of that is abstracted away from the users just like it is for Arduinos. In fact you can use the Arduino IDE to develop for most ESP32 chips.
If anything Arduino is holding back everyone with their horrible IDE. Their Board and Library managers are painfully slow and having no way to store configuration with your sketch means that you're taking a screenshot of a drop down menu if you have to make any changes.
Eventually people want to write their own libraries to make their code more manageable and the Arduino IDE makes it difficult for someone who knows what they're doing.
> But I used an Arduino, with 5V tolerant outputs, to light up Halloween costumes for years.
I have yet to encounter a piece of hardware that doesn't respect 3.3v as signal high. All of the neopixel variant's data pins work off 3.3v and most people have moved on to 12v and even 24v for larger projects while still raw dogging 3.3v on the data pin without issue.
Arduino's insistence on 5v logic levels is for maintaining backward compatibility which is honestly unnecessary.
I'm an amateur with this stuff and honestly find the ESP experience significantly more pleasant than Arduino. I'm sure there are footguns I haven't encountered, but I get so much more bang for the buck out of random ESP builds + the incredible line of various bundled ESP devices that come with touchscreens, sensors, etc. for incredibly low prices.
I know a million people have replied to you, and while I don't want to be jumping on the dog pile, I just want to say that along with PlatformIO (which automates the setup of ESPIDF and/or Arduino for the ESP, (and it also does it for a ton of other micros)) and Expressif having their own Arduino Core for their chips with integrates into Arduino's IDE, Expressif have also released their own extensions for VSCode and Eclipse that greatly aid the end user in getting ESPIDF setup and configured.)
You no longer have to break your back going from zero to blinking an LED. I remember when I first got into espressif chips and it was a right pita back then. But no more!
Personally I'm a fan of PlatformIO because its not just because of the wide selection of platforms it supports and that it uses VSCode which is my IDE of choice.
I use arduino ide to build esp projects. I have not found it much different than the arduino as a beginner, except much cheaper and faster. I like not having to do all the shield stuff. But will admit, it was helpful to start on arduino as its built in pins helped me get going as I tried to avoid soldering and breadboarded everything. That only lasted a short time before I realized I had to solder some things if I wanted to grow the project. I still like the idea of breakout boards for specific things but I usually solder them in now.
You can make the argument that esp32 supports Arduino but you can quickly run into “here be dragons” which sends most people for a loop. Arduino has a fantastic reputation for a very good reason.
Not the OP, but have had some experience with the Arduino Opta around this time twelve months ago (Oct 24) through a professional development course I took at my local university on industrial control systems programming.
While it's nice to have exposure to PLC programming at an Arduino price point, the IDE, and PLC firmware was VERY rough around the edges. It took lots of resets and fiddling to even get the units connected over their USB serial, and you'd come back the next day and you'd have to repeat the process. Lots of "hold your tongue the right way while pressing this button". The IDE was also very buggy (though it may have improved in the last 12 months), but once you got things going, it did the job.
Doesn't look bad, but the Arduino name is a serious drawback. It's a brand focusing on DIY tinkering, how are you going to sell that to your boss who only finds a bunch of shady hobbyist stuff when he Googles it?
Besides, what's the market? The non-pro hardware is fine for prototypes, but you don't want a bowl of spaghetti in production, so porting it to the pro is pointless. If you want a generic compute board, why not a Raspberry Pi? If you want a PLC, why not go for a proper PLC?
There's perhaps a market for the shadow IT equivalent of electronics projects where an Arduino sketch is suddenly a load-bearing part of the company, but that's about it.
Deeply unserious. Arduino put little real thought into what features industrial users would actually find useful. I suspect the main market for their "professional" boards is hobbyists with money to burn.
ESP stuff is very cheap and works well, but the Arduino Uno is a great board/ecosystem for beginners and simple projects. Being 5V is more convenient for a lot of things, and having the pin headers already on the board that you can just start plugging things in with jumper wires is great.
The Arduino IDE is awesome for an extremely quick setup time. You can very easily download libraries and add them to your project, you don't have to create a blank source file, you just have to fill in setup() and loop(). The Arduino IDE makes it very easy to set up a new board and download code to it.
Much of this also applies to the Arduino IDE with and ESP32, but what I really appreciate about the whole Arduino ecosystem is if you want to do something really simple, like say, activate a servo when some sensor reaches a certain value, you literally only have to type 5-6 lines of code. You're not messing around with SDKs and Makefiles and git cloning repositories etc etc etc. You can get kits for $70 that have an Arduino clone, and a bunch of different sensors, servos, steppers, etc. It's absolutely fantastic for teaching basic programming and electronics.
With ESP you can do that without even coding, using ESPHome it can be done using YAML config, it can also be paired with Home Assitante, MQTT or many other thing without any coding
Various ESP dev boards, Arduino, Pi Pico -- any of these are good places to get started from on the road towards doing useful things with microcontrollers, I think.
Arduino is just a familiar name with a long (~20 year!) history. There's a plethora of pre-existing projects that a person with no prior programming or electronics experience can implement easily to get their feet wet.
Some manner of ESP32 (or STM or MSP or RP2...) may be a good choice for a project for someone with some experience, but if you put a reasonably-motivated person in a room with a computer and an Arduino starter kit then they'll successfully be building simple things in no time.
It remains a friendly place to start doing stuff, and that was always the primary intent.
Yes. That's one way. It works fine if a person knows enough to find that board on AliExpress and buy it and is able to gather the resources to get themselves started with it. (I, myself, typically use cheap no-name dev boards...but I've been around the block a few times.)
Another other way is a ~$100 Arduino starter kit. It includes a printed instruction book and enough useful parts to sit down and begin doing stuff immediately. Anyone with a sufficiently-large pocketbook can buy it for themselves (or for someone else).
One of these things is like buying individual Lego bricks, or maybe lumber and fasteners from the hardware store, with a specific goal in mind. It's creative by necessity, and for those who know how to get where they're going then it's really quite lovely to have marketplaces like AliExpress and Ace Hardware available to satisfy our whims.
The other is more like a buying a packaged Lego kit or Meccano or an erector set that includes instructions for building several different things using the included parts. If a person (including a child) doesn't yet have any idea how to get started, then this can help them get the clues they need to go further with building other things.
---
I could buy a Chinese D1 mini dev board and a bag of assorted resistors, LEDs, transistors, and a breadboard and put it all in a nice box and give it to a kid, but I expect that they'll have a hard time figuring out what comes next. ["Now just draw the rest of the owl."]
Or, I could buy an packaged Arduino starter kit for a kid and have a reasonable expectation that they'll soon be telling me all about the neat -- if simple -- stuff they've done with it. They might not even realize the things they've learned along the way, but it'll stick with them well-enough if they want it to. And then they can move on to using VS Code with PlatformIO and start hammering out RP2040 PIO assembler when that time comes. If that's something they choose to be interested in, then they'll have a good foundation for the independent projects that may come later.
The whole is sometimes greater than the sum of its parts.
Yeah I'm kind of puzzled by what Qualcomm is getting out of this.
Arduino has so little presence in production devices and is largely an enthusiast and hobbyist product. To be clear, this is good! Having well-supported high-quality enthusiast products is awesome.
But it just doesn't... seem to overlap with the bulk of Qualcomm's business, which is large-scale silicon sales to consumer and industrial clients.
The earlier up the product development stream you can place your product, the bigger share you'll have down the road. There's the saying about planning for 1 year, rice, 20 years, trees, 100 years schools. Windows is the leader because most kids grow up using windows in elementary school and blindly continue on. If you own arduino, maybe they start on ardunio, continue on to qualcomm products, and they're already trained in the qualcomm ecosystem before they've started engineering school. Adobe famously was very lax on closing Photoshop cracks in the early 2000s and trained up an entire generation on their product with great success.
I run a medialab at an university. ESP32 is great, but there are some downsides that are all not dealbreakers, but can in some cases lead me to recommend a classic Arduino-type device:
1. Lack of 5V tolerant pins. Beginners may or may not be aware of the possibility of destroying the device or the need to level-shift signals.
2. Tooling may not work out of the box. As of today the tooling step boils down to pasting a URL into a field in the preferences, but that is something you need to know. You need to select the right uploading options which are much more complex than with arduino type devices.
3. IMO less clear naming of different dev boards, thus also harder to find docs.
4. Examples may not work out of the box, simple Arduino examples may fail with hard to debug issues (for beginners) where they don't know whether it is a hardware issue, wrong board/uploader setup or a pinout issue (e.g. if the onboard LED pin differs).
These are all examples of issues students had when they used the ESP32 boards without my guidance, so not just my opinion or a theory. And as I said none of these are dealbreakers, but depending on the patience, stress levels, perceived skill etc. of the student this might make me recommend an Arduino over an ESP32.
I use it for learning and play with my kids. I load the program on the board then we wire the components together and get all excited about blinking LEDs or a LCD.
The lack of features (notably Wifi on our boards) and somewhat larger size are benefits for us.
The ATMega AVR devices are not cost effective for what they deliver. However, the new ATtiny 0/1/2-series devices are worthwhile for applications the Cortex-M devices aren't a good fit for. The Arduino ecosystem doesn't really acknowledge these parts.
It used to be that but since Arduino and Pi have both gone full commercial, it's not longer viable. I teach kids coding and have been looking at alternatives like ESP or other boards that are much more cost effective and friendly for beginners.
Exactly. I dunno why you’d ever use anything but an esp for “maker stuff” at this point. They are cheaper, more capable, and have the same DX (largely, setting aside 3.3v vs 5v).
It's not the hardware but the ecosystem, libraries and support which is available. Sure there are alternatives like platformio but when you're learning most of the stuff out there eg youtube use Arduino IDE and libs. And just try and get an LLM to produce code based on Espressif libraries not Arduino lols...
"Arduino" is more a framework than it is a specific piece of hardware. You can run "Arduino" the framework on an ESP32. Not that I would, I don't recommend it as ESP-IDF is way better, but you can run "Arduino" code on an ESP32.
reply