Why Arduino users so agressive?

[001]

Why so many trolls here? Is Arduino a main framework for EE ? 

[techman-001]

in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.

You're two years before me on this, but I do remember a 256 byte OTP TTL fuse ROM costing about GBP50 in 1977, or about GBP300/USD370 a pop in today's money. It was the most expensive part of our design. We didn't have emulators, they cost about the same as a house. We grit our teeth and hoped we'd got the firmware right from hand-coded machine code.

Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.

I'm amazed you did that with Machine Code for fusible link ROMS ! I once designed, built and hand Machine Coded a dual 8085 industrial bottle filling machine but luckily I had 2716 Eproms by then. If I'd had to use fusible link ROMS I'd have blown my profits because of the zillions of mistakes I made while coding!
 Jump +1 going up vs jump -1 going down, or is it the other way around ? ;-)

R&D is expensive anyway, I can only imagine the cost of the National Semi PACE Development System and its Assembler. I do recall the CPU was $270 AUD, not bad for a 16 bitter that ran at up to 2Mhz.

I've been told, (and haven't verified it yet) that the Chief Design Engineer wrote a Forth for that PACE which would have reduced his development stress by magnitudes I think simply in the cost of non programmable ROMS.

The other engineers  told me at the time that it wasn't all that much earlier they had to solder diodes in matrices to make their own small ROMS before fusible link roms came along

[bd139]

Dang and I though waiting 30 minutes for a UV box was painful 

[Jan Audio]

I have bought a STM32 board that is arduino compatible for 20 euro.
It made me also agressive : the pin layout wont fit a breadboard or experiment board, it is not in the exact 2,54mm offset.
Anyone buy it from me for 10 ?

[techman-001]

Dang and I though waiting 30 minutes for a UV box was painful 

It was, but at least you *usually* got a nice erased Eprom back

I once made up a 48 gang 2732 eprom programmer. All the Eproms were in parallel and it was in continuous daily use.

Occasionally you could tell that someone had put a fresh Eprom in upside down by the scream of the tech collecting the latest batch of programmed units as he flipped them from the Ziff socket into his hand!

Of course that meant that the remaining 47 good ones had to go into the UV eraser ...

[Mr. Scram]

Why so many trolls here? Is Arduino a main framework for EE ? 

Well, why are you here?

[NorthGuy]

I want enjoyment, not labor.

One man's enjoyment is other man's labour. It's your hobby. You're enjoy doing something for free while other people may be forced to do the same things for living. Such people may hate the very same thing you enjoy.

[Howardlong]

Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.

The ROMS we used at that time were thankfully bipolar single voltage 5V jobs. The processor and its support chips, being PMOS, needed +5V and -12V, and supposedly needed sequencing, not that I remember particularly trying very hard to do so. I do remember the PMOS 1702(A), and particularly the early 27xx NMOS EPROMS, needing some challenging supplies.

Possibly one of the best learning experiences I ever had of that era was using a CRO to debug programs by probing the address and data buses, one signal at a time, with a pencil and paper. You had to be pretty inventive with your triggering, particularly if you didn't have a delayed timebase feature. And with no storage feature on the scope, you had to be pretty inventive at repetitively reproducing your signals.

It's not all that long ago, it wasn't unusual to do things in our heads that we all take for granted now, like serial decodes.

I feel that having to do things the hard way sometimes gives you a better grounding for understanding the higher level stuff, in that you're not just taking things for granted, you aren't afraid to question and consider possible aberrations under the hood.

The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that.

All too often we all give up on projects because we don't have the bandwidth to be able to deal with all of the details, many of which you won't be aware of until you actually get going on a project. However at some point, it is almost inevitable that you'll need to dig into the abstractions when they don't work the way you expect, or the way you want them to.

[SiliconWizard]

 

- Just a quick break. I don't know about Arduino users being specifically agressive, but debates about the Arduino ecosystem seem to always be pretty heated. It's a bit like debates about using C in embedded development. Many people from either side seem to have a hard time keeping calm while discussing those topics, so they may pass as agressive. -

There are both good reasons and bad reasons to use any kind of tool really, including using Arduino. So whatever you choose, try and make sure you do for mostly good reasons and not bad ones.

I personally find no use for Arduino for the following reasons:
- It would limit me to the supported MCUs only. I don't want to be limited.
- It's a bit the same as when people were using MFC to develop Windows applications. All they were interested in really were the libraries and the hand-holding, even when the tools were just meh. When or if they had to develop apps without MFC (either on Windows or other platforms), they suddenly realized they were completely lost. Those "frameworks" tend to lock you in.
- A corollary of that idea is whatever you personally think is worth investing your time in. Even if Arduino is relatively simple, you still need to invest significant time to be able to do anything useful with it (beyond blinking LEDs). Is that time investment worth it compared to investing it learning to use other tools and approaches? Your call.
- I've noticed that experienced engineers using Arduino often do that for quick prototyping. Again you have to ponder whether this is a wise investment of your time. It 100% depends on your requirements, skills, habits, available tools, whether this is a one-off thing or whether you want it to be reusable, etc. I personally have accumulated enough tools and reusable code over the years that quickly prototyping something on one of the numerous dev boards I have around is pretty quick, so I see no need for anything else. Of course your own situation may be completely different.
- Outside of purely prototyping stuff, I personally use practically NO third-party library whatsoever when developing on MCUs, and as few as possible for embedded development in general. So using some ecosystem the main interest of which are the available libraries makes no sense to me. *My* call, not a general truth.

[james_s]

Why would it limit you to supported MCUs? Arduinos are not the only platform I use, they are just the one I tend to reach for when I want to do a quick prototype or work with some specific bit of hardware that has a library. I don't have to limit myself to only one platform.

[rhb]

Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.

Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino)  MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.

Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers.  The ATMEGA line will. 

Check the AR448 thread where some fool is trying to port the code to an STMF103 and now thinks he has broken his 34401A GPIB port.  Possible I'm sure, but highly unlikely if he's been applying 3.6 V or less.

I'm building a calibration system to automate annual calibrations of my gear.  I'm using ATMEGA2560 R3s because they are cheap and do the job.  I'll use 3-4 as I have lots of relays to drive besides driving the GPIB bus.   At a minimum I'll have two ST6P Radiall 28 V SMA relays controlled by twelve 5 V relays for RF switching and 40 5 V relays for DC, low frequency AC and resistance switching.  I will *not* be using the Arduino IDE.  Just a plain Makefile.  And won't use the Arduino libraries either as I despise C++.

Most of the skilled trades use hammers specially made for the trade.  Blacksmiths generally only use a few hammers, but they do use a lot of tongs which they make as needed.

[rstofer]

It's a hobby, component costs are irrelevant.  Labor is the deciding factor.

If it's a hobby then labour is supposedly what you want.

I want the end result not the path.  As long as I get it done, and it works, I don't award points for minimum parts count.  Unless I run out of board space.  Then I might reconsider...

A couple of replies earlier on the writer was expounding on the increase in capability of the more modern chips as opposed to the older ATmega328.  Absolutely they are more capable.  They clearly have more peripherals and they are a LOT more complex and difficult to apply.

I like the STM32F chips and especially on the factory Nucleo or Discovery boards.  The fact that many of these boards are 'mbed compatible' means I don't have to install a dedicated toolchain.  I also like the ARM LPC21xx series because I have spent a lot of time with them but if I need a bit of horsepower I'll go for the mbed LPC1768 (60 MHz).  If I'm in a real hurry, I'll use my Blackfin board.  It's pretty fast (600 MHz) with uClinux.  I really like the old ATmega128 - it has a decent peripheral set and a large number of pins.  I like the AVR architecture and absolutely hate the mid-range PICs.  In fact, I REALLY like the AVR architecture.

I have played with the PSoC6 and its dual cores - it's a really interesting chip.  If I just had an application for BLE, I know which chip I would use.

I also play with FPGAs.  To the point that I have a working IBM1130 minicomputer that runs all of the factory software unchanged.  Yes, I can still write Fortran IV and do interesting math kinds of things.  And I can use the factory plotter library to come up with charts and graphs on my LaserJet compliments of an mbed LPC1768 converting the individual steps from the FPGA to HPGL sentences for the LaserJet.  SPI in, TCP/IP out...

So, yes, I get around.  But when I need to put on a quick 'show and tell' for my grandson, I reach for the Arduino.  It's a fast way to prototype and it is easy for him to replicate.  I like simple!

Want to study PID loops?  Try "Temperature Control Lab".  This little plug-on board uses an Arduino to interface between MATLAB or Python and a heater.  Read that again!  How powerful is it to be able to instrument an experiment with MATLAB?  Talk about interactive!  This is just the thing for that required "Control Systems" class.

http://apmonitor.com/pdc/index.php/Main/ArduinoTemperatureControl

Arduino is just one tool in the box.  It has pluses and minuses but no matter what you want to do, it has probably already been done with an Arduino and the project is on the Internet.  Even my reflow oven is controlled by an Arduino...

[NorthGuy]

An interesting citation from a different thread which 100% applies to the Arduino discussion:

Every culture on earth has good and bad and has done some good, some bad and some terrible things. But everybody seems to think their culture is special and better.

Having grown and lived in different cultures I get very tired of the ignorance about other cultures and the simplistic attacks. People who have lived and spent time in other cultures have much more nuanced views.

If there is one aspect of any culture that makes it bad it is to believe itself superior to others. That is bad and dangerous.

[rstofer]

in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.

You're two years before me on this, but I do remember a 256 byte OTP TTL fuse ROM costing about GBP50 in 1977, or about GBP300/USD370 a pop in today's money. It was the most expensive part of our design. We didn't have emulators, they cost about the same as a house. We grit our teeth and hoped we'd got the firmware right from hand-coded machine code.

Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.

On an earlier attempt to recreate the IBM1130 ('74?) I used these very devices to hold the microcode.  I built a programmer of dubious quality.   The 2102 RAM hadn't hit the hobby market so I had a CPU with no memory.  I moved to the Altair 8800 and put the 1130 project aside for 30 years.  FPGAs are the answer!

[rstofer]

I've been told, (and haven't verified it yet) that the Chief Design Engineer wrote a Forth for that PACE which would have reduced his development stress by magnitudes I think simply in the cost of non programmable ROMS.

The other engineers  told me at the time that it wasn't all that much earlier they had to solder diodes in matrices to make their own small ROMS before fusible link roms came along

I spent some time writing BIOS code in the early years of hard drives.  Sometimes for S100 bus machines and sometimes for the Apple II.  A bit later for the IBM PC.  The fun project was using the Z80 adapter that Microsoft built for the Apple II.

https://en.wikipedia.org/wiki/Z-80_SoftCard

One day I visited the manufacturer of the SCSI interface boards I was using.  ALL of their test programs were written in Forth simply because a new test could be implemented in a single statement.  All the lower level code was already known to work.  This pyramid approach to programming is quite powerful.  Type in a single statement and an entirely different test sequence is performed.  This wasn't a canned test, it was 'new' at the top level.

[langwadt]

Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.

Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino)  MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.

Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers.  The ATMEGA line will. 

VIh min for TTL is only about 2V, 3.3V will the drive TTL just fine

[KL27x]

Techman-001, you are 100% correct, except for one thing. You talk about learning from your past.

Yes, if you are educated and proficient with STM devices and dev tools and supply chain, I'm sure there is almost no reason to use any other microcontroller in a volume product. Today. The cost of these devices can be significantly cheaper, even, than other devices that are way inferior in most ways (other than maybe some electrical specifications in some cases).

But if you learn from your past, you know this is a temporary situation. In X years from now, STM32 is obsolete, too! Perhaps not even due to technological advancement. It might be some other whim of industry or business or some other butterfly effect.

Assuming (some) people will still want a simple way to interact with hardware in ways that don't need the latest cutting edge speeds and memory and floating point math, the Arduino platform may avoid this fate. Either the AVR from 1970 will not become obsolete, because Arduino community will continue to use it in enough volume that Microchip/Atmel will not phase it out. Or the community will adapt and incorporate better more modern microcontrollers to the Arduino platform in a way that the average user will not have to learn much to use the new greatest and latest Arduino Pikachu. (One day, maybe Arduino Techman is created, even... with an STM32 on the board?)

Arduino means you don't have to keep learning in order to do the same things you always did... and not get bent over when that part becomes obsolete and starts to cost 4-5x as much. You can use that hammer for a whole bunch of nails. And you can learn to use the latest greatest fancy biscuit jointer if and when you have to. After you do so, you might like it so much you make everything with it.. but one day it is also badly obsolete and overpriced unobtanium... When that happen, you might still have a trusty hammer, lying around, which is at least good enough to drive nails. And in the future, the latest Arduino has more speed and capabilities and less bugs than it has today, even. The Arduino platform is sustained and evolved by its user base. It is not chained to a particular micro. I kinda doubt it is ever going to deviate from AVR family, but who knows.

If you are a high school or university, do you get to take choose your classes to learn STM32 or modern AVR or modern PIC? Not usually. You would need to find the teachers that continually learn and teach the latest cuttest edge devices and completely change and update curriculum. They can offer classes using Arduino, because it's simpler and because you can bet it will still be relevant in 10-20 years.

[NorthGuy]

... Or the community will adapt and incorporate better more modern microcontrollers to the Arduino platform in a way that the average user will not have to learn much to use the new greatest and latest Arduino Pikachu ...

You speak as if learning is something bad which needs to be avoided at all costs.

[techman-001]

Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.

The ROMS we used at that time were thankfully bipolar single voltage 5V jobs. The processor and its support chips, being PMOS, needed +5V and -12V, and supposedly needed sequencing, not that I remember particularly trying very hard to do so. I do remember the PMOS 1702(A), and particularly the early 27xx NMOS EPROMS, needing some challenging supplies.

Possibly one of the best learning experiences I ever had of that era was using a CRO to debug programs by probing the address and data buses, one signal at a time, with a pencil and paper. You had to be pretty inventive with your triggering, particularly if you didn't have a delayed timebase feature. And with no storage feature on the scope, you had to be pretty inventive at repetitively reproducing your signals.

It's not all that long ago, it wasn't unusual to do things in our heads that we all take for granted now, like serial decodes.

I feel that having to do things the hard way sometimes gives you a better grounding for understanding the higher level stuff, in that you're not just taking things for granted, you aren't afraid to question and consider possible aberrations under the hood.

The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that.

All too often we all give up on projects because we don't have the bandwidth to be able to deal with all of the details, many of which you won't be aware of until you actually get going on a project. However at some point, it is almost inevitable that you'll need to dig into the abstractions when they don't work the way you expect, or the way you want them to.

Your trips down memory lane are very pleasant and bring back some great memories for me.

I'm not sure I agree with "The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that." because my solid grounding in embedded comes from those old days, from the old ways we had to do things and countless hours behind a scope catching fleeting waveforms and NOT being protected from anything by anyone.

For the 8085 bottle filling project I mentioned earlier I used a Intel SDK8085 board with a 7 seg LED display and hex keypad to write the program.

All testing was done out of RAM, but I didn't have a relocatable program to move code between RAM and Eprom, and vice versa so I wired up a large rotary switch to move all the address and data lines between them.

One position to run from from RAM, one to run from Eprom, one to program the Eprom from Ram.

Worked like a charm 

[techman-001]

I want enjoyment, not labor.

One man's enjoyment is other man's labour. It's your hobby. You're enjoy doing something for free while other people may be forced to do the same things for living. Such people may hate the very same thing you enjoy.

Wise words indeed!

Back in the old days of wire wrap I would have to wire up prototypes from a engineers schematics. It was ok, but not my favorite job because on a board with a thousand or so wraps I could never get 100% accuracy, there was always 2 or three mistakes. To me, wirewrapping was definitely "work".

We had a lady by the name of Joyce in the assembly department and Joyce loved wire wrapping, she also made zero errors board after board so we also loved Joyce's skills.

[KL27x]

You speak as if learning is something bad which needs to be avoided at all costs.

If you knew how to use STM32, and you could buy them for 45 cents, wouldn't you like to use it in many of your projects? Even if the project uses 1% of the memory and peripherals and can do the job clocked down to 1/100th of the max oscillator frequency and sleeping 99% of the time, it still costs half as much as the 8 bit PIC, right? All you have to do is learn, so what's stopping you? (I know clock speed and processor word size is not the end-all be-all regarding response/latency, but just go with it)*.

You have your own reasons. Mine? By the time I learn it, STM32 might no longer be in production, and I and everyone I know, today, might be long dead. Hell might have frozen over. I'm not gonna lie and say it's because I have not had the need, yet. If I had the need, I'd be in trouble. I would be knocking on Techman's door to see if he was available for hire, and if he wouldn't mind being horribly underpaid.

*Assembly, for instance, is great when you need it, and it is actually fairly practical on an 8 bit PIC, IMO. And I mention this because I use assembly, and I get the impression you do, as well. By using assembly, you can actually do a lot of low latency multitasking and get a lot out of said device. But as the number of and length/complexity of opcodes of a device increases, actually harvesting the benefits of this device core through assembly programming becomes exponentially more complicated and cumbersome and time consuming and prone to bugs. When there are 16 different simulaneous operands for every opcode, it becomes very complicated.  These new opcodes were intended to be useful to a compiler, from the start.

[NiHaoMike]

Writing embedded firmware from scratch can be enjoyable, but once it comes to implementing complex stuff like USB or Ethernet, using a library makes things a lot easier.

[NorthGuy]

By the time I learn it, STM32 might no longer be in production, and I and everyone I know, today, might be long dead. Hell might have frozen over.

You don't learn peculiarities of different systems. You learn general principles. Then you apply them to a particular system. Of course, you often need to know some peculiarities, but you don't memorize them. If you need to figure something out, you just consult the datasheet. You may inadvertently memorize something (such as register names etc.) along the way, but you may forget these things rather quickly when you move between architectures. That's Ok. The important thing is that the general principles are always with you and you can apply them to any situation.

If you're lacking general principles, you may do some stupid things, such as reading the datasheet from the first page to the last as you would read "War and Piece" thinking that you're learning something. Such activity only clutters your mind with inconsequential, and makes it more difficult for you to come up with a viable solution.

Don't get upset if something becomes obsolete and unusable. Just move on.

[techman-001]

- Just a quick break. I don't know about Arduino users being specifically agressive, but debates about the Arduino ecosystem seem to always be pretty heated. It's a bit like debates about using C in embedded development. Many people from either side seem to have a hard time keeping calm while discussing those topics, so they may pass as agressive. -

There are both good reasons and bad reasons to use any kind of tool really, including using Arduino. So whatever you choose, try and make sure you do for mostly good reasons and not bad ones.

I personally find no use for Arduino for the following reasons:
- It would limit me to the supported MCUs only. I don't want to be limited.
- It's a bit the same as when people were using MFC to develop Windows applications. All they were interested in really were the libraries and the hand-holding, even when the tools were just meh. When or if they had to develop apps without MFC (either on Windows or other platforms), they suddenly realized they were completely lost. Those "frameworks" tend to lock you in.
- A corollary of that idea is whatever you personally think is worth investing your time in. Even if Arduino is relatively simple, you still need to invest significant time to be able to do anything useful with it (beyond blinking LEDs). Is that time investment worth it compared to investing it learning to use other tools and approaches? Your call.
- I've noticed that experienced engineers using Arduino often do that for quick prototyping. Again you have to ponder whether this is a wise investment of your time. It 100% depends on your requirements, skills, habits, available tools, whether this is a one-off thing or whether you want it to be reusable, etc. I personally have accumulated enough tools and reusable code over the years that quickly prototyping something on one of the numerous dev boards I have around is pretty quick, so I see no need for anything else. Of course your own situation may be completely different.
- Outside of purely prototyping stuff, I personally use practically NO third-party library whatsoever when developing on MCUs, and as few as possible for embedded development in general. So using some ecosystem the main interest of which are the available libraries makes no sense to me. *My* call, not a general truth.

I usually disagree with a lot of your comments but after reading this well thought out post, I can't remember why 

[KL27x]

Don't get upset if something becomes obsolete and unusable. Just move on.

I notice you did not answer the question.
There's a cheaper and potentially faster solution out there, and you're not using it. And you're in good company.