next topic »

[Reply #30 on:]

My background is in systems engineering and embedded systems, where Direct Memory Access is the more common meaning (and has been for at least thirty years); I'd never seen dynamic memory allocation referred to as DMA.
Apologies.

Dontcha hate those overloaded acronyms! (Direct memory access is the first thing I'd think of too.)

[Reply #31 on:]

Is this a genuine development environment, or just a hobby playground? Is Arduino a trustworthy babysitter for my kiln?

It is a hobby playground. I absolutely would not rely on it to control a safety critical system without taking responsibility on myself to assess the potential failure modes for the system as a whole and the associated safety implications. For a potential fire hazard such as a kiln, in my mind this calls for a system design which does not have a single point of failure.

[Reply #32 on:]

I'll try an analogy:

In reality, it's not a very apt analogy because anyone with much experience working with memory restricted microprocessors knows that using dynamic memory allocation is just a bad idea, period.  Since Strings use dynamic memory allocation, nobody with much experience uses them, hence why the bug is receiving little attention.

If it was up to me personally, I'd just remove the String class entirely.  I'll never use it myself and I'll never recommend it to anyone else either.  In my view, its nothing more than a booby trap for novices.

[Reply #33 on:]

Amen.

[Reply #34 on:]

I find the overall experience puzzling, and worrying. There is a known serious bug right at the heart of the project, the dynamic memory allocation ...

I was hoping personally that the bug would be fixed in version 1.0.1. Apparently not. The developers who are in charge of changes (that's not me!) have a lot of things on their plate such as the various Arduinos, the Leonardo, the USB chips, the libraries, and keeping the forum running. No doubt they have their own set of priorities. Your bug report may help influence that.

I've added a note to the "read this before posting" sticky, with stronger wording about the dangers of using dynamic memory allocation.

[Reply #35 on:]

Microcontrolers control real things that can be dangerous, in my case a kiln. The doubts are surfacing ... Is this a genuine development environment, or just a hobby playground? Is Arduino a trustworthy babysitter for my kiln?

The primary design focus, as far as I can see, has been educational. Hence the presence of the String class at all. And some of the other "simplifying" aspects to the IDE.

However like any other open source system, the bugs are being detected and cleaned up.

I am using an Arduino as the security system for my front door. So far (over many months) it has not failed in any way. I use others for other purposes, also without problems.

I would suggest for something like a kiln, whether it is an Arduino or some other device, you not have a single point of failure. So for example, a thermostat or something as a secondary backup. For mission critical things I would be thinking "what if the power fails?". OK, battery backup. What if the battery fails too? What if the wiring gets corroded?

I think once you move away from the String class, things will become more reliable. Also keep in mind things that might go wrong later. Eg. when millis() wraps around after 50 days. That can be handled, easily. But you need to be aware of it.

[Reply #36 on:]

Anyway, as soon as I see the String class, I can see a very large potential problem. Especially here:

Code:

String listenForInstruction(){
  String inst;

Every time this function is called it makes a String, and then it returns one. So this is thrashing strings.

That is not always true. gcc will try to do the return value optimization permitted by the C++ standard. That means that no copying takes place and the actual object instance allocated on the stack inside the function is the instance returned to the caller. This is not a commonly known part of the standard. Try it and see!

[Reply #37 on:]

Ah yes, but it would make at least one (inst in this case), maybe it returned it without doing a copy. *

Andy, didn't you have a version of the library without the malloc/free bug? Pity it didn't make it into the main distribution.


* Besides, I stopped reading right there. Turned out with good reason.

[Reply #38 on:]

However like any other open source system, the bugs are being detected and cleaned up.

And I appreciate the incredible efforts - what an amazing concept. You gotta wonder about the priority system though. The only high priority one on the list last night was to give a more informative error message in some situation. In this case the system falls over. But it's not polite to quibble over a gift, so I wont.

I would suggest for something like a kiln, whether it is an Arduino or some other device, you not have a single point of failure. So for example, a thermostat or something as a secondary backup.

[/quote]

For a potential fire hazard such as a kiln, in my mind this calls for a system design which does not have a single point of failure.

Thanks for the reality check, guys. I'll try and find another thread for continuing this point.

it's not a very apt analogy

Analogies are like Strings: they break down sooner or later.

anyone with much experience working with memory restricted microprocessors knows that using dynamic memory allocation is just a bad idea, period.  Since Strings use dynamic memory allocation, nobody with much experience uses them, hence why the bug is receiving little attention.

You're obviously right, but the logic escapes me: it's a high impact problem that's been around a long time, everyone knows about it, so we're not in any rush to fix it.  I love it - like something out of Catch 22.

In my view, its nothing more than a booby trap for novices.

Here here. Who decides what goes on the Reference page of the Arduino site?? I'd like a word.

Thanks all for all your responses. I'm off to sanitize my programme. I may be some time.