It makes then feel like they know something when they belittle others.
.
.
.

 

I have heard things about the Arduino forum though not been a participant so have no firsthand knowledge. I can say that from the threads I have read when researching this or that problem, I haven’t seen anything egregious. This isn’t to say that threads initiated by neophytes don’t get bad reactions. I think most if not all of what I encountered was more advanced folks talking amongst themselves.

This problem of using the criticisms of others to buoy one’s own self image is terribly common on the Internet, particularly in technical communities. This is one reason why I will never use the term “noob” or “newbie” when referring to a beginner.

Long ago I realized that it is not neutral, rather it has insulting connotations. My epiphany was when my (then) 5 year old very technically adept son came crying to me about treatment by an older brother. When I asked what had happened, he tearfully replied “he called me a noob!”.

At the time I was heavily involved in an open source programming community for a particular language. I was working on the community aspect and trying to work out how to remediate a toxic segment of it. So this language thing was on my mind. I decided to use the term neophyte which not only had no baggage but, to me, feels very hopeful. It is focused on future growth, inevitable if it is not crushed.

This is a discursive tangent from the thread so to bring it back to the topic I will say it seems there are problems with some part(s) of the Arduino community in dealing with neophytes and this is unfortunate.

But, fortunately, the value the Arduino ecosystem, on the whole, is still very high, and it is still an excellent milieu for the beginner looking to learn what they need to know to use microcontrollers to create new and useful things, and to realize their own creative vision, using the hitherto inaccessible world of embedded computing.

People ranging from expert scientists in non-engineering disciplines who need some unique experimental apparatus, artists who want to make their their art interact with the world using sensors and actuators, and young folks just learning about technology, potentially moving on to engineering—or not, perhaps just to being a person who uses technology.

The main point is, Arduino wasn’t necessary but is turned out to be what happened to make the world of microcontrollers accessible to just about anyone. And all the varying levels of engagement with it, and the various depths of learning about it, are good things each in their own context.

For me, the problems with some parts of what seems to be the “official” Arduino community do not taint the Arduino ecosystem which is far larger than Arduino itself and can be joined without ever using a single ”official” Arduino resource directly.

 

The "seductiveness" of Arduino, Mbed etc comes from those 'frameworks', just like java it started with jdk, then later j2ee, Spring, Hibernate, JPA, Struts, Swing, Javafx, GWT, Grails, Maven, Gradle, Dropwizard, and java itself becomes Kotlin, Scala, Groovy etc ad infinity. This 'disease' is starting to 'infect' the mcu scape.
Either way *duino and Mbed seemed to be moving closer together.
https://os.mbed.com/blog/entry/Mbed-and-Arduino-Low-code-development-fo/
and i think there are already quite a few 'rtos' around adding to the 'frameworks'

don't think the world need to go the *duinoish way. just as like there are many who dumped those Java frameworks (e.g. dumped Spring) and used the simple APIs e.g. servlets. it actually reduce the learning curve and makes codes cleaner - for small apps (and maybe even large apps).
the thing about 'frameworks' is there is no end to all that 'abstractions', there will be abstractions of abstractions, of abstractions and neverending 'frameworks'. we are not yet in a world of c++ templatess and all that 'abstractions' for microcontrollers (yet), hope not, but i think there is creep in those directions - templates of templates, of templates, everything lambda functions, abstractions of abstractions, of abstractions.
oh why 'templates' and not classes, the notion is templates are like 'macros' so 'no fixed code' - it need not contain the 'binary' , but rather abstractions of abstractions. would there be a single template that rule the whole universe of microcontrollers for every conceivable application? That is the disease

there is once i ran into someone in forum who dislike the ifdefs, i.e. sometimes u'd only need to write the app for the particular mcu and use case (hardcode if need be) and that's it, no if defs. things like *(0xfeabcde80) = 0x80 ? it happens, it works that's it

 

I wouldn't call it a disease, it's the natural progression of overlapping turf battles as system complexity increases. Managing total system complexity is the issue. It's more a function of properly indoctrinated (in today's version of the magic software solution) software programmers designing generalized systems using abstract hardware 'blocks' with hardware engineers designing physical interface systems using software 'blocks' to perform a dedicated function that often have non-virtual timing (not simply about speed) constraints on moving parts that obey physical laws. Hardware engineers tend to focus on the physical components of a computer systems while software engineers work with the virtual aspects that are at times boring to most hardware guys IMO. Low-level modular embedded specialized systems have typically been a domain where the academic programming faith of removing direct programming of underlying hardware by means of 'framework' abstractions was seen as not productive to the final product by the EE managers of X hardware projects. Many of these baroque academic software systems crumble under their own weight in this domain eventually leaving the indoctrinated software programmers to understand why simple C based minimal hardware based frameworks are still around for embedded systems running for years or decades in most cases.

 

I wouldn't call it a disease, it's the natural progression of overlapping turf battles as system complexity increases. Managing total system complexity is the issue. It's more a function of properly indoctrinated (in today's version of the magic software solution) software programmers designing generalized systems using abstract hardware 'blocks' with hardware engineers designing physical interface systems using software 'blocks' to perform a dedicated function that often have non-virtual timing (not simply about speed) constraints on moving parts that obey physical laws. Hardware engineers tend to focus on the physical components of a computer systems while software engineers work with the virtual aspects that are at times boring to most hardware guys IMO. Low-level modular embedded specialized systems have typically been a domain where the academic programming faith of removing direct programming of underlying hardware by means of 'framework' abstractions was seen as not productive to the final product by the EE managers of X hardware projects. Many of these baroque academic software systems crumble under their own weight in this domain eventually leaving the indoctrinated software programmers to understand why simple C based minimal hardware based frameworks are still around for embedded systems running for years or decades in most cases.

I agree that hardware using MCUs often involve time critical components which is a secondary aspect of the Arduino environment, or even an afterthought. The panacea of a state machine programming style doesn’t answer this, though it is implicitly offered as the solution.

There are some things that, superposed, have allowed the Arduino ecosystem to continue without collapsing. One is the increasing computing power of MCUs with multicore CPUs and higher clock rates. This has the effect of some brute force correction to the problem.

Another is the largest portion of Arduino users don’t actually have time critical needs that exceed the techniques common in the Arduino world. So it “works” for them. “Works” in the scare quotes because while the system can chug along doing what the user wants at the moment, it is not in a state that allows expansion without major refactoring.

Just as the desktop world had its applications expand to fill all the available RAM, storage, and CPU—without a linear increase in core functionality, rather an exponential increase in the sophistication of the UI and its presentation layer interfaces, the Arduino focus is not on what an experienced embedded programmer would choose but on larger libraries to make ease the use of hardware for the programmer.

But the typical Arduino programmer does more gluing than programming. This is not an inherently bad thing, it means more people have access to the power of MCUs to make computers interact with the world. Most people who use the Arduino ecosystem will never write a library or driver, or even learn the details of how those parts work relative ot the code they do write.

As I said before, though, this is not really a bad thing. As is always true, the “ideal” is a phantom. It comes down to optimizing given the constraints the real world presents. And, in the absence of the Arduino ecosystem, or something like it, so many wonderful things that non-programmer, non-engineer people have made wouldn’t exist.

The important bit is to understand what your tools. And just like if would be wrong to use a claw hammer with a cold chisel to cut iron, it would equally be wrong to drive nails with a two pound drilling hammer. In the same way, using Arduino for applications that call for control over time critical processes, or in cases where safety is an issue, or in commercial products produced in the tens of thousands, the proper tools for those things are effectively useless to the Arduino user because they are inaccessible.

And this is why I think it is plain wrong to discuss the Arduino ecosystem as if it were in the same class as professional embedded programming tools and techniques. I see no reason to look down on the Arduino, but I also see a reason to make sure if doesn’t find its way into inappropriate use cases because it was all someone knew.

It’s all about the right tools for the job at hand, and a tool can‘t be “better” if the person who needs it can’t lift it, or understand it. Conflating the two worlds makes no sense to me at all.

To be clear, though I am replying to @nsaspook I do not intend this to be a characterization of his attitude or approach to the Arduino ecosystem, rather I sort of elucidation of an aspect of what he was saying.

 

Hi,
It seems that every time we have an emerging technology, we see the self presumed experts start creating an intellectual stratification effect within the said technology.

On one Forum site I moderated for, the ‘experts’ were lobbying members to support the creation of an ‘elite’ Forum, that could only be posted to by the self-professed ‘experts’.

Fortunately, the hoi polloi members of the Forums were able to block this idea.

A reminder of the formation of Guilds in times gone by.

My opinion regarding microcontrollers, they are simply a ‘tool’ that enable an engineer to get a job done, whatever the type of microcontroller.

Regarding programming, some programmers have begun to consider programs as some type of art form and the program has to be written subject to some form of ritualistic procedure for it to considered ‘real’ programming.

Again, programming is simply a method by which an engineer writes instructions, that the microcontroller can read in order to carry a sequence of actions based on events.


E

 

I think everyone has a different definition of what "Arduino" means to themselves, and hence there are as many definitions as there are opinions. There are the "framework" worshippers, but not everyone who mess in some *duino codes bother about "frameworks", it so happens that certain common API are convenient. e.g. to blink a led, digitalWrite() easy, so use it.

lets take a look a some *duinoish* stuff, accordingly this is done in 'stm32duino'
https://www.stm32duino.com/

'Arduino' API? the app that runs on stm32 (duino) uses DMA, some call it 'transparent', if one likes such terms I prefer to call it 'opaque'. no not 'transparent', the DMA codes can be done by directly setting up the registers to run in a particular way though it keeps the 'SPI' API looking a little similar, nevertheless it is a fork and the API calls are deliberately different.

But if you (anyone) make this "simple" comparison, 'most' will choose to go with the faster performing app and mcu, especially if they cost about the same. never mind all that 'hard coding', 'lock in' etc. different microcontrollers are simply different for their own merits. some have DMA, many don't, there is nothing to limit anyone to use the best performing and cost effective one DMA and all even if it means accessing registers directly, who cares about '*duino'. note that this is not even the 'stm32duino' (there are several 'flavours' ) if you bother to visit the forum link presented. The present one tries to be more 'arduinoish' and is contributed by ST itself. it may not use all that 'features' as like DMA etc. i.e. to get what you see in the video, you'd need to make a (big) detour from the 'standard' implementation of ST's stm32duino (for now). maybe in a 'future' there could be 'abstractions of abstractions, of abstractions' where the most 'optimized' feature set get built, it don't exist for now.

 

I have included Arduino technology in many of my projects. It opened up many new possibilities for my electronic hobby. Some projects were quite complex and challenging, like my audio spectrum analyzer. Others were simple, like an ATMega328 chip driving an OLED frequency display in my audio oscillator.
While offering some help on this forum, my simple programming techniques have occasionally been criticized by the purists. I enjoy my hobby but have no wish to become a software guru. If there is no requirement for nanosecond accuracy, I will use the "delay" statement and I will not optimize my code if there really is no need.
The "Arduino" micocontroller is just another component , although quite a complex one, to add to our resources and use in whatever way we please.

 

What is Arduino?

The history of Arduino goes back to the creation of Atmel AVR .

AVR MCU began in 1997 at the Norwegian Institute of Technology with students working on a project who wanted to create a RISC based processor as opposed to a CISC based processor. Instead of designing the hardware, they created the CPU instruction set that would make for efficient compilation. Back then computer code had to be burned into ROM or EPROM. Other common methods of programming an MCU was via parallel or serial interfaces. These required a boot loader program to be present on chip. Atmel AVR MCUs used SPI interface for program loading.

Over time, parallel interfaces (LPT) on a PC were being phased out and eventually so would RS-232 serial COM ports all to be superseded with USB ports. Flash programming Atmel AVR chips became problematic since that required a serial port dongle that converted commands sent via serial COM or USB ports to be converted to SPI.

Again students came to the rescue. In 2005, students at Interaction Design Institute in Ivrea, Italy came up with the idea of pre-programming the Atmel AVR chip with a "boot loader program" which can then accept commands directly from a serial COM or USB port. They created a PCB for the Atmel AVR, primarily ATmega8 and ATmega328 and the Arduino was born.

Since then the board and pin layout has been standardized and adapted to other Atmel AVR MCUs as well as MCUs from other MCU manufacturers. Over the span of about 20 years Arduino has become an ecosystem of its own. Arduino is a collection of HW controller boards and HW add-ons "shields" from multiple sources and open-source libraries of software "sketches".

Every computer installation is a very complex integration of multiple fields in science and engineering, involving all aspects of physics, mathematics, electronics, computer science and programming. It would take years of study (minimum of 3 to 5 years) for any individual to acquire enough knowledge in order to create a working computer system on their own from scratch.

With the widespread collection and dissemination of this information via the internet the Arduino ecosystem allows a neophyte to embark on an embedded MCU project and to be able to have a working system in a matter of days without requiring any in-depth knowledge as to how the system works.

In summary, Arduino is fundamentally an Atmel ATmega328 (or other MCU) on a PCB that others have assembled with supporting HW and SW. It is an ecosystem that allows both beginners and professionals to embed an MCU into any project with little background knowledge.

 

I think people who are experienced in working with microcontrollers tend to forget how intimidating it is to get started on learning to use one. Writing C code (assuming that's what's needed) is actually the easy part of the process; the difficult parts are getting the processor installed and connected to whatever interface software it needs, and setting up some kind of programming hardware to load code. Then even if it's running, it's another task to find a way to interact with it while it's operating.

What's brilliant about the Arduino is that all these steps are made as simple as possible. You connect up a USB cable, you install a single piece of software on your computer (freely available for download) and you're ready to write code, compile and load it (hit control-U) and see it run. Then there's a monitor function built into the software which lets you receive data from the processor and send it simple commands. There's nothing to gain by pointing out how limited the Arduino is in what it can do: that may be true, but it's not intended as a high-powered device, just a device that's easy to use.

And if the alternative processor is a PIC, the user can get annoyed by knowing that there is no maximally efficient free compiler available. Whereas for the Arduino, there's no argument about which compiler to use--it comes with a pretty good one. It's popular because it deserves to be.

 

Hopefully as you gain hardware experience the easy to use part of the equation will become less important than better possible system functionality from X hardware platform. You can only get over the intimidation factor of stepping out of the perfumed garden by pushing the limits of what you can build using your own ideas.
As a beginners prototyping platform the Arduino is brilliant, for the non-beginner it quickly starts to be limiting to stay inside that prototyping platform set of programming abstractions and hardware compatible configurations.

I guess the point is start at the shallow end of the pool but don't stay there forever as you get better. It's also fun to take a deep dive.

 

I am right now in the middle of designing and building a drip irrigation timer.

This is a relatively straight forward embedded MCU application that requires an LCD module, 4x4 keypad, water valve, battery operation, low power sleep mode. I am applying an Atmel ATmega8 for this because I have ample quantities in stock. This would be a perfect project for an Arduino board and shields, which I would have to order.

Yes, if I were new to MCU programming and interfacing, Arduino would be a perfect solution. However I am way past the neophyte level and more than comfortable and happy to go DIY.

 

I am right now in the middle of designing and building a drip irrigation timer.

This is a relatively straight forward embedded MCU application that requires an LCD module, 4x4 keypad, water valve, battery operation, low power sleep mode. I am applying an Atmel ATmega8 for this because I have ample quantities in stock. This would be a perfect project for an Arduino board and shields, which I would have to order.

Yes, if I were new to MCU programming and interfacing, Arduino would be a perfect solution. However I am way past the neophyte level and more than comfortable and happy to go DIY.

Oddly I was contemplating something similar, but on researching it I found I could buy the basic functionality my gardener said I needed at a price that made it a no-brainer to buy rather than build; sometimes just because something can be done doesn't mean it should be!

However, for my garden I want a steampunk 'sculpture' that shows temperature, pressure and humidity on a 4 - 5ft dia dial. Can't buy one that size so I'm getting it made by a local company that normally makes gates n stuff, but the concentric dials will be driven by big servos and a wireless link from my weather-station (DIY). That will be an ESP32-based solution....

 

Oddly I was contemplating something similar, but on researching it I found I could buy the basic functionality my gardener said I needed at a price that made it a no-brainer to buy rather than build; sometimes just because something can be done doesn't mean it should be!

However, for my garden I want a steampunk 'sculpture' that shows temperature, pressure and humidity on a 4 - 5ft dia dial. Can't buy one that size so I'm getting it made by a local company that normally makes gates n stuff, but the concentric dials will be driven by big servos and a wireless link from my weather-station (DIY). That will be an ESP32-based solution....

Yes, that was another option, to go bluetooth and have the user input via a smartphone or tablet.
That will be the next version. I have already done a similar application hence this would be straight forward.

 

will companies start using "*duino" for multi-million dollar industrial PLC?
some companies are already selling the 'success stories'
https://www.industrialshields.com/case-study-automation-concrete-plant-gr
https://www.industrialshields.com/case-study-biogas-plant-automation-gr
in effect the "*duino*" tag is 'abused' at least in marketing terms for anything that use part of a wiring or arduino API.
it need not have anything to do with "*duino*' other than perhaps using part of the API. it isn't surprising after all.

the difference between a 'traditional' c/c++ implementation is that it mostly start in main(), the "*duino" or wiring api based implementation simply extends that further down to setup() run initially and loop(), which is nothing more than while(1) loop();

beyond the 'simplest' use, the 'framework' is 'extended' in infinite number of ways and hardware that do not conform to any sort of 'framework'.
it will not satisfy the 'framework' worshippers, neither will it satisfy the 'arduino' purists.
the tag may eventually lose meaning other than having an api that looked partly similar to the arduino or wiring api.
for 'marketing' purpose at least, 'arduino' is kind of 'popular' and more people 'heard' it these days compared to some propietary PLC.
it become a 'marketing' term to capitalize on the idea of a customizable PLC where the PLC is up to one's design and need not conform to anything.

We are living in 'quite different times' these days, gcodes once used to belong to running those heavy, bulky and expensive (e.g. > $10k eur/usd) industrial CNC machines. today gcodes runs all Reprap (based) 3d printers (some less than $200) and sub $200 'desktop cnc'.
we are in a world where microcontrollers and apps are now accessible as commodity parts and '*duino' plays a part in it.
one can easily change your washing machine wash cycle, wifi it etc where it is once more difficult without these parts and "*duino*".
to an extent one can 'iot' your coffee maker to 'control' how you make your coffee, possibly making different blends, style of coffee, these become kind of a 'fun' project where it is once 'can't be done' without commodity microcontrollers.

I'd guess even this isn't too difficult and achievable with mcus

These days Raspberry Pico, stm32 mcus say running stm32duino, esp32, esp8266 etc offers more capabilities and resources than the original Atmega328, it makes once 'less accessible' stuff (the commodity mcus) more readily available and many of them offer a "*duino" api.
But it would be a mistake to treat them as being 'the same'

 

for 'marketing' purpose at least, 'arduino' is kind of 'popular' and more people 'heard' it these days compared to some propietary PLC.
it become a 'marketing' term to capitalize on the idea of a customizable PLC where the PLC is up to one's design and need not conform to anything.

The main principle and intent behind the PLC was to create an electronic version of the electrical schematic ladder (boolean) diagram and control in order for shop floor personnel to very quickly and efficiently solve failures in assembly line equipment, at least this was GM's intention when it spawned the idea in '68 and Dick Morley took up the challenge.
As long as the system fulfills this main premise, then any means of control can be behind it.

 

The difference between a 'traditional' c/c++ implementation is that it mostly start in main(), the "*duino" or wiring api based implementation simply extends that further down to setup() run initially and loop(), which is nothing more than while(1) loop();

Actually you can put

while(1)
{
.
.
}

in your setup() routine, and never have a loop() at all. I've decided to switch to writing Arduino programs that way, because I sometimes want to use continue; statements and the compiler won't accept them unless there is an actual while() loop running.

Hey, in a program, oops I mean "sketch", that doesn't have a loop() routine, I just tried adding

#define main() setup()

and used void main() instead of void setup() and the compiler accepted it! Soon I'll hardly know I'm using an Arduino at all.

 

The main principle and intent behind the PLC was to create an electronic version of the electrical schematic ladder (boolean) diagram and control in order for shop floor personnel to very quickly and efficiently solve failures in assembly line equipment, at least this was GM's intention when it spawned the idea in '68 and Dick Morley took up the challenge.
As long as the system fulfills this main premise, then any means of control can be behind it.

I think the main value of a PLC over an arduino or similar is the easy-to-understand graphical representation, but was it always? Honest question, I wasn't around when the party started so I don't know. One opinion that I feel entitled to is that Statement List/Instruction List programming (as is so popular with European Siemens enthusiasts) completely defeats what I think you and I would agree to be the main reason for using a PLC. So I sought to find the origin story of Statement List and this is all I found. It seems to indicate that Statement List was the very first PLC programming language. Is that true? If so, when/how did the easy-to-understand graphical representation part come on the scene?

I wasn't able to find much on the early use of Statement List so I googled about Dick Morley and the internet had little to say other than he is the father of the PLC.

 

I remember when the first PLC's came out as at that time I welcomed them as I was just about to take on retro-fitting some assembly lines where the control originated in huge electrical cabinets full of relays, timers etc.
Not only did they make the job a breeze, the logic display, complete with the status shown of all I/O and logic functions made trouble shooting a breeze for the maintenance personnel.
Many came out with the ability to program in Statement List/Instruction List programming. but also gave the option of using simple ladder programming but they all still displayed in ladder format.
Dick Morley came up with the idea over a long week-end after being approached by GM to implement something. I only remember the ladder format as the only original option.
I eventually settled on Mitsubishi as my PLC of choice. Although practically all Industrial CNC M/C's had/have their own version, built in.
It also helped in ushering in low voltage DC control circuitry.

 

I think the main value of a PLC over an arduino or similar is the easy-to-understand graphical representation, but was it always? Honest question, I wasn't around when the party started so I don't know. One opinion that I feel entitled to is that Statement List/Instruction List programming (as is so popular with European Siemens enthusiasts) completely defeats what I think you and I would agree to be the main reason for using a PLC. So I sought to find the origin story of Statement List and this is all I found. It seems to indicate that Statement List was the very first PLC programming language. Is that true? If so, when/how did the easy-to-understand graphical representation part come on the scene?

I wasn't able to find much on the early use of Statement List so I googled about Dick Morley and the internet had little to say other than he is the father of the PLC.

Are you aware of the OpenPLC project?