Professional Engineers' Perspective?

I watched an interesting video by Massimo Banzi on Arduino/Android development. At one point Mr. Banzi remarked that professional engineers were using Arduino but many were doing so secretly, meanwhile pretending they’re actually doing 32-bit assembler programming. Unfortunately, this sounds plausible and I’m sure there are some engineers doing just that, but I know there are many professional engineers out there that are more forthcoming.

I’ve been doing embedded development for a long time going back to when assembly programming was the norm and what you had was what you wrote. I’ve coded my share of large-scale applications using nothing but assembler and bank switched program memory. I don’t look back fondly on those days. Since those times, there have been numerous improvements in the way embedded systems are designed and programmed.

I see Arduino as a significant step forward, and although obviously not a universal solution, one that has many applications, especially for rapid prototyping and fast proof-of-concept development. And, as one of Arduino’s objectives is to make the technology accessible to artists and designers, it’s a huge benefit to have a good grasp of the technology when taking on a project already brought to prototype by designers using the Arduino platform.

I’ve seen quite a few caustic tirades on the web written by engineers who just don’t like the Arduino concept. From my perspective, there’s a lot to like, and things are getting even more interesting now that other processor architectures are coming into the mix. Of course, there are limitations, but there to numerous ways to work around them.

I’m interested to hear from professional engineers that have used Arduino and to hear of their experiences, both good and bad, but minus the vitriol.

1 Like

I've not used the Arduino for a professional product, I may be tempted depending on the product but in general it will be cheaper/better to roll your own PCB.

Also I'd look real close at any libraries you use, IIRC there are many instances of it not being industrial strength, things like non-atomic access to volatile ints etc. Don't ask me where, just seem to recall that's the case.


I also haven't yet come upon the right project for Arduino, although I've been involved in several since I became interested in the technology. Oftentimes, packaging is everything and that's been the case for me with specialized form factor requirements. I agree that in many cases, a full custom design will likely be the less expensive solution but depending on volume and design requirements, I can see where a purchased board may be less expensive for certain applications.

I also looked at a number of embedded boards that run the .NET Micro Framework. I thought this might have some promise based on limited experience with .NET PC development, but the boards I looked at have a long way to do before they're anywhere near ready for production work; they’re way off in terms of features, stability, and reliability. I followed some of the discussions on the manufacturers’ forums and people trying to deploy products using this technology are having all sorts of issues that simply can’t be resolved. Although the Micro Framework is open source, there are pragmatic obstacles to making changes to the run time, especially when targeting single-chip controllers. This is one reason I really appreciate the fully-open Arduino architecture and straightforward programming model, where if something isn't quite right you can go in and change whatever you feel needs changing.


jdybowski: that professional engineers were using Arduino but many were doing so secretly, meanwhile pretending they’re actually doing 32-bit assembler programming.

I think it is important to remember that few professionally-produced projects will ship with an actual Arduino. However, it is entirely true that professional engineers are using Arduino for development. Their end-product may in fact contain an ATmega328. It may not. Instead, they may implement the final design with a different microprocessor. The Arduino is, after all, really a prototyping platform.

15 years ago a manager told me, "we can't use Linux for our web server. It isn't a professional product." It was the same kind of story. There was a perception about this "toy" that means it has no place in the corporate environment. Fast forward to 15 years and I'd venture to say most mid-to-large companies have at least one server running this once "toy" operating system.

jdybowski: I’ve seen quite a few caustic tirades on the web written by engineers who just don’t like the Arduino concept.

Do you mean to tell me there is a web site / forum on the Internet where people have differing opinions?! Tell me it isn't so! :)

Like most things (computers, software, food, cars, pets) people tend to form opinions. Usually they are uninformed. A skill many people lack is the ability to look at things from another's point of view. Instead they take the stance, "If I can't/won't use it, why on earth would anyone else?"

Arduino is a fine example of this attitude. Keep in mind that the people who love implementing their project with Arduino spent most of their time talking about how cool their project turned out. Not how stupid Arduino is. Food for thought.

If a solution works for you, who cares what others think. In my experience I have found those who complain (loudly) about a solution generally lack the initiative to have done anything similar in the first place. I guess this is the geek-world's equivalent of armchair quarterbacking.

jdybowski: I’m interested to hear from professional engineers that have used Arduino and to hear of their experiences, both good and bad, but minus the vitriol.

Engineers don't take a solution and look for a problem. Instead they take a problem and look for the most appropriate solution. Sometimes this solution might be an Arduino. Sometimes it might be a PIC. Sometimes it might be a handful of 555 timers. At the end of the day, you are only as good as your tools. Personally, I believe if you limit yourself to a specific tool (or limit which tools you accept) that limits your ability to implement a great solution.

1 Like

Some engineers (like me 10 yrs ago) did hard-core programming in assembly and worried about bytes and micro-seconds and saving every penny. Those days are gone, thankfully. Instead, I can quickly put together a hardware/software solution 10x faster, without the learning curve, without mastering the bit-level and compiler. There is so much community support and libraries too.

I was going to use an ARM7 from scratch for an in-house project. The old-school engineering approach I have done many times. Then I saw the MCU alone has an 1,100+ page datasheet! The software development tools were also buggy, layered and complicated. Do I have time to dig into this, and do PCB layout and coding/debugging with my boss's scheduling and deadlines in my face? I decided to go Arduino and have some fun instead- wasting a few bytes and clock cycles. My Arduino projects are a total success. I just let go of perfection.

But I would not use the Arduino (hardware) in commercial products as they're a bit expensive, the shields (physically) are silly awkward and most Arduino's have limitations that are deal breakers- like my need for them to work at -40C, be micropower run off batteries/solar, something you can bolt down etc. I find them a bit hobby/generic.

My only negatives about the Arduino are the poor documentation for the language and routines. My peers at work did not freak out when they saw the Arduinos on my desk (instead of me "rolling my own" from scratch) so my manliness did not take a hit. I will keep using the Arduino a lot for in-house, development, hobby stuff.

1 Like

Hey, that sounds like me. I used to know everything about a few processors and I extracted a lot of performance while watching microseconds, bits, and bytes. Working in assembler, you had to have such a deep understanding of architecture, instruction set, timing, etc. Now I use a lot of different processors and I guess I know enough. Like you, I balk at the bulk of today's data sheets; even "simple" 8-bit controllers have 500+ page data sheets. And, even at 500 pages, there are often many unanswered questions. Two parts of embedded development are making the board work, and making it do what it has to do.

Arduino greatly accelerates making the board work, leaving more time for making it do what it has to do. I had a project a while back where I had two candidate processors, one an ARM the other MIPS. The MIPS part was a better fit for the design and cheaper, but I had a problem getting one of the on-chip peripherals to work. This was actually straightforward stuff but the answer didn't come so easy. It took three weeks to get a solution from the factory, which came about one week after I shipped the ARM prototype. This was an unusual case but I think we've all experienced such black holes from time to time.

I agree that for production there are usually considerations that prevent the use of stock Arduino boards. I'm constantly cranking out projects but haven't had the right fit for Arduino yet. But, what a great prototyping tool!

What makes things interesting is that there are now other architectures coming under the Arduino umbrella, including 32-bit designs. Now, the abstraction becomes even more compelling since you don't have to give up your a 500-page data sheet for one that runs 1,100 pages to get the added features and performance you need.

1 Like

I too have used all sorts of processors from Z8/Z80/6805 et al (even bit-slice processors) to current AVRs. I miss the hard core programming in a way but have to admit it's nice to just get something going.

I now find myself looking at the LPC chips because a project I have in mind is too much for a 328 and the 1284 is too expensive. Ironically this is a peripheral dongle to plug onto an Arduino that just does some IO, a bit strange using a 50MHz 32-bit processor as a peripheral to a Mega328, but that's the modern world I suppose. So I've been absorbing the LPC122x 442-page data sheet, which when you consider the 328 data sheet is 448 pages is not that bad.

I think the small LPCs are a viable option to use in place of AVRs, the LCPXpresso toolchain is free and seems to work and the dev boards are $30. The forum is OK but nothing like this and the support ticket I raised maybe 3 weeks ago with NXP is still unanswered, so if I have trouble I'll be largely on my own. Just like the old days :)


When I was first starting out, I was using the 8085 in embedded products and developing on an 8080 S100 box. The embedded processor was actually higher performance than the one in the development system! Luckily, this was short-lived and I move on to better things - or so I thought at the time. I can say objectively that, although some of the early microcontroller weren't that bad at all, the development tools - both hardware and software - absolutely sucked. Good thing I didn't realize it at the time.

With microprocessors, it seems documentation and support are getting worse, although they’ve never been so hot. I remember sitting in on brainstorming sessions with fellow engineers and we weren't trying to come up with a new design approach or some slick implementation; we were speculating as to what the data sheet was really trying to say. These lengthy sessions often yielded no definitive conclusions and we had to resort to fooling around with the parts until we knew what was going on. This is a bad way of doing things, and worse as complexity escalates.

It's great to be able to do simple things easily such as setting up I/O, pullups, ADC, PWM, and peripherals like I2C, SPI, UART, etc. Coming from a traditional engineering background it's almost shocking to write a few lines of code on an unfamiliar platform and have things just work. And that’s before you get to the high-level libraries.