[stillsut]

Can you specify what SO MUCH HORROR amounts to in the arduino community?

From reviewing these posts, it seems like EE spend most of their day frustrated trying to get the device to simply boot or do the simple thing. If there's a tool for beginners that snaps together and avoids these headaches, that seems valuable in itself, almost anti-HORROR.

[fake-name]

My issue with the arduino community basically comes down to:

1. The HORRIBLE code quality in the entire arduino codebase.

2. The prevalence of straight up factual errors everywhere in their stuff.

3. Their shitty, SHITTY schematics.

To be clear, getting a AVR to run a "flash the LED" program is trivial. There is really not much /to/ an arduino (it's an overglorified atmel eval board).

When you refer to `trying to get the device to simply boot or do the simple thing`, what you're normally talking about is trying to get a fully integrated complicated system to power up and function to the point that it can then be debugged further. This is a COMPLETELY different ball-of-wax, and requires a much more broad toolset, because you have to be able to diagnose why it's not working. Sure, with arduino things, you can plug the bits together, and it'll MAYBE work (assuming non-buggy libraries, which is very much not usually true). OTOH, if it doesn't work, ¯\_(ツ)_/¯. You're going to need a logic analyser, or an oscilloscope (or both!) to figure out why. I can pretty much guarantee the person who initially wrote the library for each of your "snap together" module components did have to go though all that.

Basically, arduino stuff is the PHP-equivalent of the hardware world. The general quality is low, there is little push for improvement, and everyone is sticking buggy crap on the internet.

For example, the "Arduino Mega" (call it a goddamn ATmega2560, dammit) has multiple hardware serial ports (4 of them). For a long time (possibly until today), even if you weren't using the ports, it allocated two 64 or 32 byte buffers for each port statically. This is on a platform with 8KB of RAM total.

Would it be trivial to fix this? Yep. Did they? Not the last time I checked.

These are also the same people who decided malloc() on a platform with 2 KB of ram was a good idea (it's not).

[stillsut]

Thanks for the reply, I'm just seeing this. I'd agree with you that anyone who knows what they're doing and is looking to deliver a professional product will find the Arduino, it's price, it's libraries, unsuitable.

Think of it like physics problem sets though. You don't get to Physics 503 by just reading the first three text books, you have to actually do the problem sets and struggle with them. In our first problem here, assume there is no friction, even though any experimental physicists will tell you that's crazy, that never happens. Once you've mastered the exercises, then you criticize their clunkiness and move into a framework with more realistic assumptions.

And for me, the refusal to fix sub-optimal design is pretty appreciated as it doesn't subtly break some aspect of already written books, tutorials, shields, etc. Beginners will often look to copy very literally an already known solution, which may be on someone's blog from 2011. Little changes, which happen often with RasPi, result in hundreds of comments like 'This doesn't work, please help!'