Is ARDUINO relevant in the electronics industry , or it is mainly a trtaining tool to new in embedded field ?
Thanks
Elico
I'd say that, since it is mainly a hobby/training platform, it is not directly relevant to the electronics industry.
For example, the IDE lacks professional features like a debugger. Also changes can be made which breaks old code (although professional development environments are also not fully immune to this).
A little of both - it's an amazing training tool, that's for sure (though I think Espruino is better to start with for someone with very little electronics experience - it's a more forgiving language (JS instead of C) but the real value is the live console - great for getting a feel for how electricity works in the context of digital electronics), though you may graduate to arduino quickly - or not, I know some very smart people who do all their embedded work on that - but I'm pretty sure it's all hobbyists)
However, a great many makers aspire to go into production and sell/distribute their creations (I do it, but I don't make much money - it's more a motivation to be practical and sane in my making), and like, they do it, and very frequently use the tools that they know in their products. I know of multiple commercial products programmed in Arduino, at least one of which is still a going concern, deploying thousands of units that, in my semi-professional assessment, probably cost close to $100 to manufacture (he complained about the $40 price tag of the good radio units he was using, the board was gigantic (also, had i been the one to design the hardware, it would have been cheaper and sidestepped multiple problems because I also know the chips very well)
What's really powerful about the Arduino environment (and the several alternate IDEs that use the same cores/libraries, ex, platformIO, which I hear very good things about, makefile builds, etc) is that you can use as much or as little of the Arduino "hand-holding" stuff as you want or need - the code I write now looks very different from the code someone new writes (I'm writing registers directly all over the place, sometimes I just straight up do direct port writes just because I know the ports off the top of my head, but have to pull up a pinout chart to find what the Arduino pin number is, that kind of thing - I'm getting to where I can get the jist of assembly without the reference book, I routinely use assembly listings "Huh, why did changing that make the size go up by 2 bytes, I didn't expect it to - dump the .lst and... "Oooooh! Of course!" or "Oh, the compiler is being kinda stupid"*). Sometimes I use setup and loop... (like, for 95+% of use cases, it's a great structure, and it gives you a very sensible starting point) sometimes I override main() and don't.
On the other hand, lots of schools use Arduino as people's first introduction to programming (and for that, more than anything else, I have mad respect for the arduino team - they made it easy enough that schools can give people's FIRST INTRODUCTION TO PROGRAMMING in EMBEDDED C[++]** - C is NOT a forgiving language by any stretch of imagination - and kids like it and learn from it and it's pretty good).
Another thing I would note is that while no large professional western company would use Arduino, it is much more commonly used by startups, entrepreneurs, and - as far as I can tell - in, say, China, it's a lot more relevant. I think the philosophy that guides companies there is "good enough is" rather than "do it the Right Way, by the book, and your team of tech writers documents it" attitude of western companies (for the record, I'm closer to the "good enough is" attitude - and IMO that's why they are so effective in the market - for the end users, good enough is!)
What I love about Arduino is that:
- The IDE itself is easy-peasy to use compared to almost any manufacturer's IDE. I recently tried to use Atmel Studio, and MPLAB. Waste of a day and a half, could not get anywhere. They are chock full of complex features that you don't need to understand or use to write useful, effective programs. But they're there, and they get in the way. With arduino, you can sit down, and write code. No faffing about with configuring the IDE and setting up every detail of your project at the get-go - you choose the board or chip*** from a dropdown menu, the defaults are intelligent, and so on.
- They provide easy solutions for common tasks. Sometimes not great solutions, but they get the job done, and if you later need to make it faster, or you run out of flash, you can go back and switch to more efficient implementations. Sure, I know how to do proper timekeeping without millis(), but I almost never do that (notable exception being when I'm debugging issues in my millis() implementations).
- Those solutions work the same way, regardless of what part you're programming, for the most part. I can take code written for the Uno, and (if they stuck to the Arduino API) run the same code on the ATtiny line, or the "modern AVRs" (unofficial term) with the new peripherals, or the SAM AVRs, and so on. millis() and delay() have the same API whether the timing is derived from the 8-bit timer0 on a classic AVR, the watch crystal on certain parts that support it, the TCB timers on the modern ones, and so on. Sure, you lose some of the benefits of the hardware that way, but that only matters when it matters.
- With the same tool, I can throw some halfassed test together in a couple of minutes, or write an intricate, carefully designed huge application. And quite often as I follow the results of those halfassed tests down the rabbit hole, I they turn into much more full-featured "sketches"
- They provide all sorts of opportunities for people to step up, make a useful library, make a useful hardware package that doesn't exist yet, or that did everything they could manage wrong and fix it... or you can just be a user and focus on your application code. (On a personal note, I find making the libraries and tooling that other people will use, and being the lord of that domain incredibly compelling - that's why I spend my life making cores and fixing jtag2updi instead of actually working on my own electronics projects. I've had things taken apart on my desk since before christmas, while I've pushed out half a dozen versions of megaTinyCore, worked over jtag2updi, and expect to release another core by the end of the month****
- Because everything has to be affordable to hobbyists, and thanks to cheap Chinese producers, all the programming tools, hardware you need, parts you might want - it's all dirt cheap! I have at least 10 USBAsps - they're like 3-4 bucks! I have dozens of serial adapters - they're $2 a pop!
Footnotes:
- looking at the code avr-gcc generates is just fascinating for how it can sometimes be incredibly clever, and other times do intensely stupid anti-optimizations. One anti-pattern, though, is trying to write code a certain way because you think it will make the compiler do it the way you think is more efficient, because it might be converting your pretty, clear code and ugly "optimized" code into the same thing, or your attempt at optimizing might be making matters worse in a non-obvious way - either read the .lst and know what the compiler is generating and see the effect of your changes - or just let it do it's damned job! (by the way, on my cores, "export compiled binary" also dumps an assembly listing - best feature ever if I do say so myself)
** Arduino is technically C++, but unless you're making your own classes/libraries, you're basically writing C.
*** I always write for chips, not boards (contrary to the Arduino paradigm of calling everything a "board", renumbering the pins, and I usually use Hansibull's or my third party hardware packages instead of the standard Arduino ones, even when programming a standard Arduino board. Among other things, these cores let you do PIN_PB3 for example, to refer to pin 3 in port B, as opposed to arduino pin numbers.
**** If I can stop writing essay-length posts like this one!!!
6v6gt:
I'd say that, since it is mainly a hobby/training platform, it is not directly relevant to the electronics industry.
For example, the IDE lacks professional features like a debugger. Also changes can be made which breaks old code (although professional development environments are also not fully immune to this).
I have never needed a debugger, and I can count on one hand the number of times I've though "oh, debugging this would be so much easier if I could set breakpoints or singlestep" - just add in a bit of code to record what you need, upload again - it's so fast and painless, you don't need it.
I feel you on the official cores (in particular) breaking stuff foolishly; the cores I mentioned above (mine, and Hans/MCUDude's) IMO take a more professional attitude to supporting families of parts, while keeping the advantages of Arduino. And when I break something, I fix it quickly, goddamnit!
@DrAzzy karma++ for the long dissertation and generally for your contribution to the Arduino eco system.
I see that my short contribution could have been a bit more balanced if I added that the Arduino platform is an excellent learning environment and very usable for projects with huge amounts of community produced libraries etc. available for handling peripherals etc. (All free, but of varying qualities and usually poorly documented).
As for the debugger, you have a point but Serial.print() can't be used in all contexts and here is a sample problem I was dealing with a few months ago:
. . .
byte i ;
// do something 8 times
for ( i = 7 ; i >= 0 ; i-- ) {
. . .
}
. . .
For a reason which was not obvious so late in the night, it did not behave as expected. A debugger would have highlighted it quite quickly.
Surely the compiler spotted the missing semicolon?
TheMemberFormerlyKnownAsAWOL:
Surely the compiler spotted the missing semicolon?
Oops. I'll correct that simple typo here. No that wasn't the issue in the original code.
6v6gt:
No that wasn't the issue in the original code.
BT, D T 
DrAzzy, I assume/hope that was a copy paste. +1