next topic »

[Reply #30 on:]

As for F() usage, I find it problematic:
A simple usage of:
String test = F("hello");
 does not compile: "error: conversion from '__FlashStringHelper*' to non-scalar type 'String' requested"

The String constructors do not support this data type, which is very unfortunate. Sure, I can go to that class and start making it work but it should be working out of the box;

It's really unclear to me why you would want to do this. People use the F() macro, and storing data in PROGMEM in general to save memory. The String class tends to throw memory out the window. So your claim that "it should support" this constructor really leads to the question: why?

I suggest that anyone who is at the stage of storing strings in program memory (and not RAM) would already have decided to not use the String class at all.

[Reply #31 on:]

As for F() usage, I find it problematic:
A simple usage of:
String test = F("hello");
 does not compile: "error: conversion from '__FlashStringHelper*' to non-scalar type 'String' requested"

The String constructors do not support this data type, which is very unfortunate. Sure, I can go to that class and start making it work but it should be working out of the box;

It's really unclear to me why you would want to do this. People use the F() macro, and storing data in PROGMEM in general to save memory. The String class tends to throw memory out the window. So your claim that "it should support" this constructor really leads to the question: why?

I suggest that anyone who is at the stage of storing strings in program memory (and not RAM) would already have decided to not use the String class at all.

You just proved my point. Why have a String class, if it is not meant to be used?
Arduino is inconsistent and confusing with its approach to string management:
Strings should be handled through one interface.

I Java and C# Strings are handled through one class - String. It is consistent and coherent. Arudino is exposing such a class but it should not really be used because "The String class tends to throw memory out the window"?!?
>> So it should be removed completely.
OR
>> It should be improved to provide a monotonic and efficient solution

[Reply #32 on:]

I don't think you are right. The String class used in the right way will work as it is. There is room for improvement, but you have to think before choosing a tool and more important you have to know your tools. The reference to Java and C# is great - I have to use some software at work based on these frameworks and usually when there is something more demanding you see that the programmers just used these tools without knowing better. In other words: the software is slow, memory demanding and struggling with the 2GB barrier of 32 bit systems because it is scaling badly.

"If all you have is a hammer, everything looks like a nail."

[Reply #33 on:]

Arduino is inconsistent and confusing with its approach to string management:
Strings should be handled through one interface.

That has nothing to do with 'Arduino'. The Arduino is programmed in C++, which is a superset of, not a replacement for, C. C has always supported null-terminated strings, as did most of the contemporary languages of it's time. C++ introduced the String class at a time when memory was considered less of a constraint.

Java, and the .net languages, are designed to abstract as much as possible away from the programmer (by necessity for Java and by design for .net). Visual C++, being less abstracted, does have support for c-style strings, and needs it because many of the underlying dlls still require c-style strings (or pointers to them) as parameters. I presume that the .net runtimes handle that conversion.

[Reply #34 on:]

I don't think you are right. The String class used in the right way will work as it is. There is room for improvement, but you have to think before choosing a tool and more important you have to know your tools. The reference to Java and C# is great - I have to use some software at work based on these frameworks and usually when there is something more demanding you see that the programmers just used these tools without knowing better. In other words: the software is slow, memory demanding and struggling with the 2GB barrier of 32 bit systems because it is scaling badly.

"If all you have is a hammer, everything looks like a nail."

If I wanted to use something which is lean and mean, I can use AVR and C directly. No need to use Arduino at all.
One of the good things about Arduino is its simplicity and friendliness, in particular for new people coming into the field of microcontrollers. Think about kids learning how to program for the first time.
The Arduino documentation and tutorials are showing String usage everywhere.

I wrote a firmware which is not that big - just by including a few libraries and some message strings (Defines) I quickly ran out of SRAM space. Not because of String class, but because static strings kill it.
In comparison, Arudino is a much bigger memory hog than C# or Java on a non-embedded system (desktop/server). I never ran out of memory there and it was never a consideration.
Ideally I shouldn't care if a string is kept in SRAM or PROGMEM. The compiler can make that decision, unless I really want to explicitly do specify memory management attributes. The complexities should be hidden behind an easy to use interface.
This allows the developer to focus on his goals, instead of goofing around and wasting time on the internals of the AVR compiler.

We can go on for ever. I'll reiterate my point - I believe that good programming models are monotonic.
Luckily, Arduino is Open Source!...

[Reply #35 on:]

I think you miss the point of the real hardware we are dealing with.

In comparison, Arudino is a much bigger memory hog than C# or Java on a non-embedded system (desktop/server). I never ran out of memory there and it was never a consideration.

Definitely it is not. Look at the memory usage of any C# or Java program you run. Every abstraction layer comes at the cost of system resources. Our resources are very limited hence you have to leave abstraction layers out when you are going out of resources.

[Reply #36 on:]

Arudino is a much bigger memory hog than C# or Java on a non-embedded system (desktop/server).

What does that mean? 'Arduino' isn't a non-embedded system. Show me a C# program (I still write C# occasionally, having done it solidly for a couple of years for my job) that will run in 2K of ram. Even the .net micro framework requires 64K.

[Reply #37 on:]

Nevermind... it's an avr-gcc bug.

Yes, and a highly annoying one too. I compiled it out of my copy of avr-gcc 4.5.1. With it in there I could not use my preferred flags of -Wall -Wextra -Werror because there's no specific command line flag to disable it and gcc as a policy does not use pragmas to control warnings.

[Reply #38 on:]

Our resources are very limited hence you have to leave abstraction layers out when you are going out of resources.

I agree. Arduino is an abstraction layer, therefore I could leave it out and revert to AVR and C.

But why am I going out of resources? Mainly because of poor string management support. Every freaking "TEXT" was eating up precious memory. OK, let's move to F() strings (Arduino abstraction layer, right? They do hide the complexities of PROGMEM attributes).
Great, more SRAM - Oh wait, now I have to change my code..    
See the problem? If Arduino is an abstraction layer, it should do its job - abstract. Otherwise I would rather code, hard core and raw C with string functions - at least then I know exactly what's going on (for the price of a steep learning curve and many more hours of coding and debugging). And I have no problem coding that way, and perhaps I should do it, but using an abstraction layer that doesn't abstract well makes little sense to me. Of course, making Arduino support these Flash strings properly instead of reverting to low level C seems like the better choice.

[Reply #39 on:]

Otherwise I would rather code, hard core and raw C with string functions

The keyword there being "I".
Remember the target audience for Arduino.

[Reply #40 on:]

Remember the target audience for Arduino.

What then is the target audience for Arduino? College students, amateurs, kids?
Professionals will surely not use Arduino - it makes sense for them to use AVR/C with full control and minimal overhead.

I just looked up in Google "Arduino Better String Class" and came up with this:
http://bleaklow.com/2012/02/29/why_im_ditching_the_arduino_software_platform.html

The guy is making very strong points.
Don't get me wrong - I really like Arduino. It was a fast and easy way for me to go forward.
But if it doesn't evolve, it will die. Strong and better platforms will quickly arise and replace it.
The IDE is poor, compared to Eclipse or Netbeans.
The only things that Arduino is really special are easy to use hardware and the software abstraction layer.
I love the Arduino hardware - fantastic wrapper to the AVR MCU.
The software abstraction layer needs to be improved.

Moderator edit: tags corrected to make quotation clearer.

[Reply #41 on:]

It's open source. Go ahead and make it better.

[Reply #42 on:]

Professionals will surely not use Arduino - it makes sense for them to use AVR/C with full control and minimal overhead.

You are wrong again. I came here not for my hobby but for my job. I stayed here because of curiosity. And I love the Arduino software (though the IDE is horrible; java, what shall I say *g*) because it has given me a very fast start at the abstraction layer I like. After that it is easy to experiment and decide how to continue. I do not want to read about the registers and other internals of the CPU in the first place. I got all information on my way and for some details I took the route to the hardware, for others I took the libs already there. That's what is great with open source and you always can try to contribute (but not always your ideas are accepted).

At the moment I'm just collectiong impressions to see what is possible and how to extend what I started at work - now I have to wait for the guy from the electronic dept. to get our custom board ready.

Please keep in mind that we are here using a Harvard architecture and no x86 clone and I still can do something like

Code:

String strComp((const char*)F("commandname"));

not that different from

Code:

String strComp(_T("commandname"));

and you can always define a _F() to shorten the first line.

[Reply #43 on:]

What then is the target audience for Arduino? College students, amateurs, kids?
Professionals will surely not use Arduino - it makes sense for them to use AVR/C with full control and minimal overhead.

I'm not sure what the word "professional" means here. You might argue that professionals are not even the target audience.

However as for minimal overhead, this sketch:

Code:

int main() {}

... compiles (under version 0022 of the IDE) thus:

Code:

Binary sketch size: 176 bytes (of a 32256 byte maximum)

Of that, 104 bytes are the interrupt vectors (you would need them anyway). 42 bytes are the code for initializing RAM from program memory - you would need something like that anyway. The generated code is other than initialization and vectors is:

Code:

int main();
int main() {}
  a6: 80 e0        ldi r24, 0x00 ; 0
  a8: 90 e0        ldi r25, 0x00 ; 0
  aa: 08 95        ret

000000ac <_exit>:
  ac: f8 94        cli

000000ae <__stop_program>:
  ae: ff cf        rjmp .-2      ; 0xae <__stop_program>

Looks like it threw in "exit()" even though I didn't use it. That's 4 bytes extra. The rest is, well, 6 bytes for my minimal program.

Actually I do use exit(). The compiler generated a call to main() - which returns, followed by a call to exit().

So it's hardly lots of overhead. And I don't see how using AVR/C would come out any better.

And that's why I use it. The IDE does not in fact clutter you up with junk. The String class, perhaps. And if we added in the extra stuff you suggest, more so.

But if it doesn't evolve, it will die. Strong and better platforms will quickly arise and replace it.

Actually I am afraid of it evolving. Like a lot of Microsoft stuff has over the years. You just get to learn how to use it and they change everything. You have a core processor which does certain stuff. That isn't going to change. Your tool is the g++ compiler which works well. You can extend it with your own libraries (easily) if you want to. It's all open source and documented. You do indeed have "full control".

And as for "better platforms" replacing it ... well we've been there. About 40 years ago microprocessors (like the Motorola M6800) existed with similar capabilities to the Atmega. And yes, faster processors evolved. That cost more, needed more power, more cooling, more space, and were harder to program. And now we are back at where we are. Simple, cheap, low-power, easy to use.

This platform is ideal for where it is designed to be used ... inside robots, water monitoring, burglar alarms, microwave ovens, washing machines, toys, you name it.

And quirky though it is in places, the IDE does not really stand in your way. Not only that, but it helps you get started, which is surely a good thing.

[Reply #44 on:]

And quirky though it is in places, the IDE does not really stand in your way. Not only that, but it helps you get started, which is surely a good thing.

Very well expressed, Nick.