What stops your Arduino project?

 I typically find that power has been an issue for me in projects I’ve been trying to implement. Circuit design and Pin assignments would also be nice topics for videos.

dougw said:

The next biggest issue is programming in C/C++ - just about my least favorite language. (LISP and APL are worse)

I feel your pain.  It often seems people go out of their way to write C/C++ code in the most obscure way possible.  When I first came across LISP my first thought was WTAF quickly followed by why would you??

I usually muddle through, but I think some good points are made below.  A useful guide for Arduino programming would be a comprehensive approach to minimising code size and memory management techniques in general.

For me, I still find Arduino is THE go-to option for almost all my prototype projects as I've almost always found an Arduino open source library for the sensors I need to use - even the obscure ones.

In business, MS Excel or Google Sheets, for example, tends to be the first thing one uses to analyse data, develop a model and produce reports with charts to show trends etc. I've always seen Arduino as the hardware version of the spreadsheet - as it allows you to quickly create projects to measure real-world data with sensors and transmit this data remotely if required.

Having been schooled in the traditional (i.e. many moons ago) methods of programming during my engineering degree, I grew up totally dependent on a debugger to help me develop firmware. Discovering that Arduino did not have a debugger was initially a stumbling block, but I soon found that by changing how I think, prepare and develop a project using the serial monitor and data logging I can still achieve the same outcome. In fact, over time I have found, when switching to other IDE's and platforms, that I rely less and less on the debugger and with BLE, for example, and probably other real-time event driven modules, you cannot use a debugger and have to use other "sniffing" tools.

As such, I think video tutorials on alternative development approaches, without using debuggers and also using sniffing tools, may be helpful.

So what else stops me?

Well for me it's searching for the right components to use, whether it's MOSFETS, pressure sensors or RF modules, for example. All too often I make mistakes based on the assumptions I've made based on what I read on Newark/AVNET/Farnell/Mouser/DIgikey/etc. But, TBH, this is mostly caused by my lack of familiarity with what I am trying to achieve.

Python has some of the debugger stuff baked-in : )
Someone should do a write-up/video (if it doesn't already exist) showing how to do it - e.g. how to edit variables on-the-fly and run code, it's very interactive since it is all interpreted and has a nice 'shell'. Not related to Arduino though : (

I too have (slowly, without realizing it) changed my coding practice to work around the lack of debugger (mbed and others don't have a step in/step over capability, memory viewer, etc either, and I don't ever remember using GDB with it either - perhaps I have but can't recall), to the extent that I no longer miss it... this only kind-of works when the C run-time and the libraries and the compiler are reasonably stable of course. Whereas in the past, pre-GNU and early GNU compilers, none of that was very certain.

Agree there should be videos on the alternative approaches, e.g. using console output (maybe also input), how to insert debug statements into code and easily switch it on or off, and where to insert it for reducing intrusiveness to real-time behavior, how to detect if memory is being trampled, what types of things to be considerate of to reduce run-time errors.
Also how to do (where feasible) some stuff in Linux first, where GDB is available (usually a last resort thing, since there's plenty of higher-level debug options for algorithms anyway), to sort out algorithms etc without spending time building and pushing to the real target platform repeatedly, stub code, #ifdef etc. 

I agree with you, the debugger is something that you'll miss if you were already used to working that way.

But code debugging in embedded systems is quite complicated. I have seen bad code many times that when you compiled the code without the debug lines the program stopped meeting the timing specifications. Especially in communication problems with many protocols.

"Step, breakpoint, and watch variables are a good start" to a big mess ;)  I remember that a few years ago when I was debugging a program for a card payment countertop POS in that way, I stopped the program to see some variables of a GPRS communications task that was running in the background when printing the purchase receipt. I was not very lucky I stopped the program when the thermal head of the thermal printer was on... me looking at the debugger on my computer screen while the POS caught fire.

OUCH! 

I chuckled at the predicament you described. I had a similar experience with a maker project containing a  28BYJ48. I stopped the program to work on some code not realizing 5V was applied to all coil windings. I scorched my fingers when I tried to remove the motor it was so hot.

Programs are the majordomo of the system. Interrupt them from the task, have insufficient safety protocols or none at all and bad things can happen.

In the eighties, I maintained a dish tracking system for weather balloons. The electronics were tubes. The servo's in that beast could whip the disk antenna around in less than seconds. The safety protocols recommended insertion of the 2inch diameter steel pins in the gear mechanism when performing any maintenance. The pins prevented movement. I respected that recommendation after seeing the mangled trash can the instructor displayed that tried stopping the beast. My spindly legs and arms would be no match for it.

I hear both of you :) - but can also compare with dev kits from TI, ST, Renesas, NXP, Silicon Labs, Infineon, ... that have a debugger, on board and in the IDE.

I am thinking of my little son of 10 years, this year he has gone from programming in Scratch to start programming with Arduino. In scratch he already had a good level, conditionals, loops, passing messages between objects, variables and use of semaphores, understanding races and critical sections.

With Arduino and that "sketch" mini-skeleton it hasn't cost him anything to start. With a more complex template or or force to define function prototypes first I think he would have been scared and given up.

I remember my beginnings with BASIC and the ZX81, with the GOTOs and the GOSUBs, reading the code was a pain but in return it was easy to switch to the assembly language of the Z80. I don't take Arduino programming seriously, I see it more as a diversion to do inelegant and fast things. I am still looking forward to how PRO boards can evolve and what response they have in the industry.

I think it's a great platform to introduce younger and not so young people to embedded systems.

A debugger in the Arduino IDE is long overdue. They have had a debugger in their Beta IDE for some time now - don’t know why it is takng so long to get it stable. I recently tested the Würth Sensor FeatherWing which uses Visual Studio Code and Arduino libraries. It has a debugger and worked well in my limited testing.