Venting my Arduspleen

Firstly, why do so many Arduino projects put either Ardu- or -uino in their name? If you combine more than three of them in a sentence, you sound like you're speaking Pokemon.

I feel it's good to get my grumpy out before releasing major blocks of code. It's cleansing. And it's a warning to myself, of things I must avoid. Lest it be quoted back at my face...

And another thing!.. Why doesn't the community realize that it has almost fragmented itself by lack of tool unity? There isn't just one learning curve.. there are at least three, as you outgrow each sandbox level and have to throw away vast wodges of code written under the previous paradigms.

Here's an example. Using the provided functions like pinMode() and digitalWrite() and tone() functions leads to a dead end. Do you realize how much memory tone() consumes? Or how slow digitalWrite() is?

You can tell when coders graduate to Arduino Level II because they stop using them and start setting bits directly with "PORTB |= (1<<6)" style statements. Because while it looks ugly, it compiles down into an indirect single-bit test. Calling a function, by contrast, is easily twenty or thirty bytes of overhead, just for the function call. The definition is worse. It's slower by an order of magnitude.

But the assumption is "teach people the nice and friendly one first, and they'll learn about the harder version when they need to."

Only it doesn't work that way, because real code ends up filled with a mixture of both styles, and beginners and experts alike not only need to learn about both forms, but they also have to learn about the behind-the-scenes interactions when they are combined.

The result? Bad code. Everywhere I look. Just truly awful code.

Primarily that's the fault of the development tools. They don't connect the programmer to the device they are programming, they disconnect you. It's like the IDEs have an agenda.

The Arduino IDE has an agenda they got from Processing... a pedagogical approach to software development that's best summed up by the 'Examples' menu and the lack of line numbers in the source code editor.

The Atmel 6 IDE seems to be a sales tool for a product called "Visual Micro" to the extent it will joyfully install a new bootloader on your device that links it to trialware. Hmm.

It's got to the point where I use Eclipse for the bulk of my coding (since the Arduino IDE really isn't into editing it's own libraries, and most of my code is now in libraries) but flip back to the Arduino IDE for the compile/upload task.

I've yet to find a sensible reason to use Atmel Studio 6 since the one feature I really wanted - the Simulator for debugging without downloading - doesn't work with Leonardo-compatible "32U4" chips. Or very well at all. I tried tracking down my hardest and subtlest bug using Serial.print() statements and pure logical thought last night while simultaneously trying to configure and use the debugger for the same purpose. The first method won. I'm still yet to get a single line of code to run in the simulator.

Neither "official" tool seems able to bring up an assembly listing beside the source code, like I used to be able to do with the PIC microcontroller development tools. That's another crucial thing you need to see, but is hidden from you. (literally deleted as tempfiles, unless you set special options) No-one wants to write assembly, but being able to see what your code compiles into is a crucial part of optimizing it for size and speed.

Then there's the Arduino Playground. I don't want to be mean, so let's just say I'm looking for something a little more grown-up for programs that can't just be cut-and-pasted into a comments box.

Mostly, the Arduino community doesn't seem to realize, in it's enthusiasm, that it is ignoring lessons from the history of microcomputers as far back as the TRS-80. Mostly, that Reified Object Orientation is a luxury afforded by big memories and fast pointers. But also that bit-banging magic numbers is a path towards incomprehensible code. There are other ways, hard lessons learned by the Linux Kernel community that might apply, but once again the need to "simplify" the environment has excluded them.

I have been building my own tools, of course - micro operating systems for the Leonardo, with a command line that can read and write pins without having to reflash the whole damn chip. I just finished a module that can store a hundred 'mini files' in a journaled (or "log-structured") filesystem within the 1K eeprom. My masterpiece so far is a real-time robot control system with a joystick-based code editor and debugger. (An IDE on the Mega32U4!) A common thread with these is a willingness to dive into the messy details of the silicon, and not to abstract them into meaninglessness.

Even as my code becomes more advanced and optimal, I'm finding the provided tools less useful in helping me achieve that. I've fallen off the end of the learning curve again. All of them.

Creating "a new approach" would just add to the problems. What we need is a willingness to pull together all the existing IDEs and bootloaders plus a few base libraries and create a platform.

I could spin you a tale of literate programming editors that cloud-compile to all known targets, that reference compiler versions and branch tags instead of library dependency names so that old projects can always be recompiled byte-perfect. The messy, but important stuff that means you have more than a toy, even if it is part of one.