Is Arduino "crap"?

[nctnico]

The Arduino environment does not direct developers towards sound software engineering practices, and instead tries to hide some of the complexity by using its own preprocessor.  The code itself is C++, or C when using SDCC instead of GCC, for example for CH55x microcontrollers.

Using C++ could be a good thing. Less use of pointers. Recently I came across a piece of C code like this:

struct t_information *make_information(int parameter)
{
struct t_information *ret_val;
retval->data = parameter * 100;
return ret_val;
}

This is from a commercial product likely sold in 10k to 100k quantities a year. Maybe some people shouldn't do programming.

[Andy Chee]

Ok I'm a C dummy, so I don't actually know why that code snippet is "wrong".  And what does "proper" alternative code look like?

On the other hand, I consider myself relatively proficient in hardware, and regard the Arduino platform analogous to breadboarding prototypes.  I would not necessarily release a commercial product in breadboard format, even if transferred to one of these PCBs:

[pcprogrammer]

Using C++ could be a good thing. Less use of pointers. Recently I came across a piece of C code like this:

Code: [Select]

struct t_information *make_information(int parameter)
{
  struct t_information *ret_val;
  retval->data = parameter * 100;
  return ret_val;
}

This is from a commercial product likely sold in 10k to 100k quantities a year. Maybe some people shouldn't do programming.

Ok I'm a C dummy, so I don't actually know why that code snippet is "wrong".  And what does "proper" alternative code look like?

I'm neither a real expert on C but think it is simple. Using a structure to return a single value in itself is bad, but declaring it within your function and then return a pointer to it is very bad. Unless it is automatically marked by the compiler as static it won't exist any more after the return of the function.

Code: [Select]

int make_information(int parameter)
{
  int ret_val;
  retval = parameter * 100;
  return ret_val;
}

The above is what it should have been. Simply returning the input times 100.

A bit more optimized line wise.

Code: [Select]

int make_information(int parameter)
{
  return(parameter * 100);
}


On the other hand, I consider myself relatively proficient in hardware, and regard the Arduino platform analogous to breadboarding prototypes.  I would not necessarily release a commercial product in breadboard format, even if transferred to one of these PCBs:

I remember this one. A voltage reference product that was made on breadboard PCB. 

[SteveThackery]

Ok I'm a C dummy, so I don't actually know why that code snippet is "wrong".  And what does "proper" alternative code look like?

That's the very question I had!

[Brumby]

Ingredients:
 1x Bespoke request from a member who saw a previous project I showed here
 1x Generic 20 milligram electronic scale
 1x Arduino Nano compatible board (which just squeezes into the scale body)
 1x First attempt at writing interrupt driven software, which was written in the Arduino IDE

Result:


Got it working and produced 2 more.

There are dozens of choices I could have made differently and perhaps I should have.  I cringe at the crudity of it all - but it works well enough.



Does this qualify for this dicussion?

[SteveThackery]

Arduino's time should be passing, but nobody is stepping up to offer the next great alternative.

How about the Pi Pico?

Mind you, I would not want to program in Python - running an interpreted language on a microcontroller feels wrong, but I don't know how easy it would be to program the Pico in C or C++.

[PlainName]

Ok I'm a C dummy, so I don't actually know why that code snippet is "wrong".  And what does "proper" alternative code look like?

struct t_information *ret_val;

Creates a pointer to the struct, but there are two problems: first, there is no actual struct, only this pointer to one. So assigning a variable to the non-existent struct member is going to write to random memory. If you're lucky it will be address 0 and trigger an abort.

Second, suppose you realise the pointer wasn't meant here and you really wanted to do:

struct t_information ret_val;

At the end of the function a pointer to that is returned, which would be OK (and the way to do it) except that the struct is on the stack, so would be lost on function return.

[edit: missed word]

[pcprogrammer]

Ingredients:
 1x Bespoke request from a member who saw a previous project I showed here
 1x Generic 20 milligram electronic scale
 1x Arduino Nano compatible board (which just squeezes into the scale body)
 1x First attempt at writing interrupt driven software, which was written in the Arduino IDE

Got it working and produced 2 more.

There are dozens of choices I could have made differently and perhaps I should have.  I cringe at the crudity of it all - but it works well enough.

Does this qualify for this dicussion?

That is after market product update. Only when you seriously consider making a new product out of it the question is how you would approach that. 

[pcprogrammer]

Arduino's time should be passing, but nobody is stepping up to offer the next great alternative.

How about the Pi Pico?

Mind you, I would not want to program in Python - running an interpreted language on a microcontroller feels wrong, but I don't know how easy it would be to program the Pico in C or C++.

Just as hard as any of the other MCU boards you can find. It requires reading the datasheet and the reference manual and then it depends on your skill set.

[pcprogrammer]

Ok I'm a C dummy, so I don't actually know why that code snippet is "wrong".  And what does "proper" alternative code look like?

struct t_information *ret_val;

Creates a pointer to the struct, but there are two problems: first, there is no actual struct, only this pointer to one. So assigning a variable to the non-existent struct member is going to write to random memory. If you're lucky it will be address 0 and trigger an abort.

Second, suppose you realise the pointer wasn't meant here and you really wanted to do:

struct t_information ret_val;

At the end of the a pointer to that is returned, which would be OK (and the way to do it) except that the struct is on the stack, so would be lost on function return.

Damned missed the declared as a pointer. 

That indeed makes it even worse.

[Brumby]

Are we taking hardware here ... or software?

There are several ways to generate an executable (and the discussions on coding practice are, quite literally, boundless) but, as I see it, these don't represent the definition of Arduino.

[artag]

Using C++ could be a good thing. Less use of pointers. Recently I came across a piece of C code like this:

I don't think the right way to reduce bugs is to take all the useful features out of languages. You'll end up with BASIC. Which I guess has it's uses, but we've already got it so we don't need another one.

The whole problem of inexperienced programmers using languages they don't understand is a social / managerial problem, not a technical one. Don't try to fix it with a technical solution.

[nctnico]

Using C++ could be a good thing. Less use of pointers. Recently I came across a piece of C code like this:

Code: [Select]

struct t_information *make_information(int parameter)
{
  struct t_information *ret_val;
  retval->data = parameter * 100;
  return ret_val;
}


I'm neither a real expert on C but think it is simple. Using a structure to return a single value in itself is bad, but declaring it within your function and then return a pointer to it is very bad. Unless it is automatically marked by the compiler as static it won't exist any more after the return of the function.

You are getting tripped up by the simplification of the example. There are more fields returned. It is all about the non-initialised pointer which points to a random memory location. And this random piece of memory is then overwritten with the values. The problem with these kind of coding errors is that they can go unnoticed for a very long time and when they do cause issues, they are extremely hard to debug. The compiler threw a warning on this one so it was easy to spot when going through the warnings.

A simple fix is making retval a static variable for the function.

Code: [Select]

struct t_information *make_information(int parameter)
{
  static struct t_information ret_val;
  retval.data = parameter * 100;
  return &ret_val;
}

But this isn't thread safe. And still it would be better to declare  a variable with the t_information type and pass it to the function. In C++ you can pass variables by reference which is easier and less error prone compared to using pointers.

This piece of code comes from a project I inherited. Customer has too many problems with it so they demanded the source code so they have full control over fixing bugs. One of the issues is that the product the code is running on, is crashing every now and then. It also underlines why I'm so adamant on writing simple code and avoid using pointers in C because they are so poorly understood by many.

[PlainName]

A simple fix is making retval a static variable for the function.

Code: [Select]

struct t_information *make_information(int parameter)
{
  struct t_information ret_val;
  retval.data = parameter * 100;
  return &ret_val;
}


Hate to nitpick but that would fail too: it requires the 'static' keyword to be static, so this version would be on the stack (and dropped on return).

(It could be fixed in a couple of ways; offhand, without knowing anything about this code other than this, I would probably create the struct elsewhere and pass in a pointer to it. Reason being that this function just seems to be a struct manipulator but doesn't seem to do anything that would warrant being a struct creator - a creator should ensure all members are set appropriately, for instance. I appreciate that it's an example of bad code written by someone else; just commenting on it generally!)

[nctnico]

A simple fix is making retval a static variable for the function.

Code: [Select]

struct t_information *make_information(int parameter)
{
  struct t_information ret_val;
  retval.data = parameter * 100;
  return &ret_val;
}


Hate to nitpick but that would fail too: it requires the 'static' keyword to be static, so this version would be on the stack (and dropped on return).

I wasn't finished typing.. 

[Rerouter]

I'm probably coming from a weird angle

The IDE is simple enough to have an apprentice program a hundred devices without too much difficulty, (Using an ICSP device)
Its verbose enough to make clear that it worked or not.

With any device, you need to inspect the code it will be running and test it aswell as what your writing

I do have devices still out in the field that are based on an AVR chip running the arduino code, but usually never the bootloader
I will say the libraries are where you will find some of the weirder choices, I remade the 1-wire emulation code as the original wanted like 35KB of RAM
my own implementation was 200 Bytes,

ATtiny is still a favorite series of mine, but I've yet to play with the 1 wire programming style chips

[SteveThackery]

Arduino's time should be passing, but nobody is stepping up to offer the next great alternative.

How about the Pi Pico?

Mind you, I would not want to program in Python - running an interpreted language on a microcontroller feels wrong, but I don't know how easy it would be to program the Pico in C or C++.

Just as hard as any of the other MCU boards you can find. It requires reading the datasheet and the reference manual and then it depends on your skill set.

I've been reading the 'C' SDK user manual for the Pico. It describes a comprehensive set of libraries, and it looks like they are all written by the company, which helps me feel confident about their quality.  According to the documentation it shouldn't normally be necessary to manipulate registers, etc, directly, although you can do so.

[pcprogrammer]

Using C++ could be a good thing. Less use of pointers. Recently I came across a piece of C code like this:

Code: [Select]

struct t_information *make_information(int parameter)
{
  struct t_information *ret_val;
  retval->data = parameter * 100;
  return ret_val;
}


I'm neither a real expert on C but think it is simple. Using a structure to return a single value in itself is bad, but declaring it within your function and then return a pointer to it is very bad. Unless it is automatically marked by the compiler as static it won't exist any more after the return of the function.

You are getting tripped up by the simplification of the example. There are more fields returned. It is all about the non-initialised pointer which points to a random memory location. And this random piece of memory is then overwritten with the values. The problem with these kind of coding errors is that they can go unnoticed for a very long time and when they do cause issues, they are extremely hard to debug. The compiler threw a warning on this one so it was easy to spot when going through the warnings.

A simple fix is making retval a static variable for the function.

Code: [Select]

struct t_information *make_information(int parameter)
{
  static struct t_information ret_val;
  retval.data = parameter * 100;
  return &ret_val;
}

But this isn't thread safe. And still it would be better to declare  a variable with the t_information type and pass it to the function. In C++ you can pass variables by reference which is easier and less error prone compared to using pointers.

This piece of code comes from a project I inherited. Customer has too many problems with it so they demanded the source code so they have full control over fixing bugs. One of the issues is that the product the code is running on, is crashing every now and then. It also underlines why I'm so adamant on writing simple code and avoid using pointers in C because they are so poorly understood by many.

Without the definition of the structure there is no way of knowing what is being passed, but with the example you gave either it being a pointer or the actual structure (without the static) the other members of the structure will be random data. (Or set to zero)

And like PlainName pointed out it won't exist anymore after the function returns, unless it is marked static. The stack gets written over fairly fast. On the other hand with it being a pointer the data would still be somewhere in the memory but at an undefined location. Not necessarily at address zero if I'm not mistaken. There used to be a difference in this between release and debug builds.

Anyway we all agree on it being bad programming and can cause problems that are indeed very hard to find and debug.

That is why I liked writing in assembler in the good old days. You always knew where the data is placed and how it is handled.    With more modern assembly languages like ARM it is more of a pain though.

[pcprogrammer]

Arduino's time should be passing, but nobody is stepping up to offer the next great alternative.

How about the Pi Pico?

Mind you, I would not want to program in Python - running an interpreted language on a microcontroller feels wrong, but I don't know how easy it would be to program the Pico in C or C++.

Just as hard as any of the other MCU boards you can find. It requires reading the datasheet and the reference manual and then it depends on your skill set.

I've been reading the 'C' SDK user manual for the Pico. It describes a comprehensive set of libraries, and it looks like they are all written by the company, which helps me feel confident about their quality.  According to the documentation it shouldn't normally be necessary to manipulate registers, etc, directly, although you can do so.

Correct, but that is more what bare metal programming is about. Manipulating registers and peripherals. Sure you can use the manufacturers SDK, but for me the challenge is to do everything yourself. I know, I'm weird that way. But when shit hits the fan you can only blame yourself for f-ing it up.

Programming any MCU with basic C/C++ means starting at the reset vector. Within the manufactures SDK that often is taken care of with some assembly, but it can be done with pure C. I'm not a user of C++. Know a bit about it and have used it, but prefer C, and on embedded I often do without the extras. Just plain C, no libraries, not even the standard ones. Less room for errors. 

[SteveThackery]

Correct, but that is more what bare metal programming is about. Manipulating registers and peripherals. Sure you can use the manufacturers SDK, but for me the challenge is to do everything yourself. I know, I'm weird that way. But when shit hits the fan you can only blame yourself for f-ing it up.

Programming any MCU with basic C/C++ means starting at the reset vector. Within the manufactures SDK that often is taken care of with some assembly, but it can be done with pure C. I'm not a user of C++. Know a bit about it and have used it, but prefer C, and on embedded I often do without the extras. Just plain C, no libraries, not even the standard ones. Less room for errors. 

Thanks - a very thought-provoking reply. I don't object in principle to bare metal programming, but I do like to be able to use the libraries as well, so I can choose.

Also, like you, I prefer programming in C rather than C++. I'm not sure object oriented adds that much in the microcontroller world; in all my experience I've never needed to create more than one object of a particular class, so what's the point? The key principles of encapsulation can be done well enough in C.

I've just started a new thread exploring the "where next after Arduino?" question, because it is logically separate from this thread, which is about Arduino's suitability for real products.

[Nominal Animal]

(That is another reason I like Teensy microcontrollers (see 4.0, 4.1): the proprietary bootloader is on a separate chip, so the main MCU is completely under your own control, if you want to do bare metal programming.  So, you can do Arduino+Teensyduino development, or bare metal, whatever fancy hits you.  The only limitation is that attaching a debugger is not very feasible, as the JTAG/SWD pins directly connect to the bootloader chip.  The upside is that unless you damage the board (electrically or physically), you can always reprogram it with the Teensy Loader.  PJRC is even willing to sell you preprogrammed bootloader chips, if you want to do a DIY board compatible with Teensies; many have.)

[langwadt]

Programming any MCU with basic C/C++ means starting at the reset vector. Within the manufactures SDK that often is taken care of with some assembly, but it can be done with pure C.

on a Cortex-M you can, I don't think it is always possible

[Nominal Animal]

Programming any MCU with basic C/C++ means starting at the reset vector. Within the manufactures SDK that often is taken care of with some assembly, but it can be done with pure C.

on a Cortex-M you can, I don't think it is always possible

The amount of assembly needed is often only a few lines to a dozen lines or so, though: setting up the stack and such, nothing complicated or weird.  With GCC and Clang-based toolchain, you can even compile the assembly sources using the same frontend (gcc or clang) with same compiler options, because they invoke the toolchain assembler for .s files (preprocessed assembly sources) and .S files (assembly sources that need preprocessing via toolchain cpp).  Or you can invoke the assembler directly (typically as in these toolchains) in your build machinery; I use Makefiles, others prefer cmake.  Even IDEs tend to use one or the other "behind the scenes".  So, it's not an issue in real life, at least with these toolchains.

It's the black-box/magic register setup without comments, explanations, or any documentation, that one might see in an SDK that is annoying.  That stuff can easily be done in C after setting up the stack, especially if you know what and why it is being done.  (Others have told me that manufacturers' and vendors' SDKs don't have much of that nowadays, but I haven't checked.)

[pcprogrammer]

Programming any MCU with basic C/C++ means starting at the reset vector. Within the manufactures SDK that often is taken care of with some assembly, but it can be done with pure C.

on a Cortex-M you can, I don't think it is always possible

Depends on a couple of things. A way to setup a vector table holding the reset and interrupt information of the processor and the need for special actions in peripherals like memory management units. The latter  can be tricky and require dedicated assembly instructions to make it happen. But it is also possible to embed these in to your C code with the use of the "__asm__" statement. How to do this and with which statement depends on the compiler and conventions used in it.

Even if some assembly is needed, this makes it even more bare metal. 

[tooki]

On the other hand, I consider myself relatively proficient in hardware, and regard the Arduino platform analogous to breadboarding prototypes.  I would not necessarily release a commercial product in breadboard format, even if transferred to one of these PCBs:

Well that'd also be spectacularly expensive to do, given the large amount of labor needed to wire a circuit on protoboard. That is the whole point of a PCB, after all: the wiring is already done.