Don't get me wrong I am not complaining about a lack of functionality in sprintf what I am getting at is that I don't know how to find out what the IDE will and will not do.

Well whatever C++ functions and features are not available in the arduino platform is most likely not a restriction from the IDE, but rather with the open source tool chain used, the AVR-gcc implementation of the compiler and library in particular. As I recall from some of the guru software comments on this issue a lot of the 'restrictions' are just from the reality of using a microcontroller that only has 2K or SRAM space (8K for a mega board) in which to operate in. Also the microcontroller being based on the classic Harvard computer architecture is probably another 'restriction'?

That all sounds perfectly reasonable and I am well aware of the physical limitations.

AVR-gcc implementation of the compiler and library ? It sounds as though I should know what that is and I suspect that it is only the tip of the iceberg.

Clearly the terminology I used isn't correct, what I need to know is what is available in a standard Arduino IDE, irrespective of how it got there, that comes later.I am sure that if I went looking for C++ solutions on Google I would find loads of solutions many of which don't work/arn't implemented in the Arduino IDE.

I am more than happy to do the research and reading but I don't know what to look for to get me started.In fact I am far more concerned about asking silly questions that I could have answered by doing a bit of reading.

sprintf ... in other places, I was a little confused I think I have used it in php

Thanks for the link and the pointer to look into libs, that will be easier now I have an idea where to lookI am really green at this, I only just discovered that I can look at a library file in the IDE, they don't format well in notepad ... Oops

CheersAl

If I knew where the box was I would probably still want to think outside it!

Also the microcontroller being based on the classic Harvard computer architecture is probably another 'restriction'?

Wouldn't think so. About the only place this would show up would be the fact that pointers to functions are in a different address space as pretty much all other pointers (PROGMEM would be in the program address space as well). Even so, I don't see this added twist make pointers much worse than they already are.

Note, it depends on what compiler you are using. For example, on Linux (Fedora) if I install the arduino software via the yum repository, compiler is fairly new (4.6-ish), while if I use the compiler that is supplied with the Arduino 1.0.1 tarball, it is rather old (4.3.2) which is several years old, and 4 major revisions out of date. A lot has changed in the C++ world since 2008.

I am using Arduino 1.0.1 in windows 7 (64) but I think I am a long way from attempting to get to grips with a different OS or compiler variant.

It has been suggested that I might be better with Eclips with the Arduino plugin but I am concerned about stepping too far outside the norm until I have a more than a rudimentary understanding of what I am trying to work with.

I have managed, with a great deal of help from board members, to build a my first simple library but I have a long way to go.

If I knew where the box was I would probably still want to think outside it!

One thing you should probably understand is what is even meant by IDE, mainly because the only part of the Arduino IDE that's actually 'Arduino' is the editor. The underlying library is AVR Libc, which you've been introduced to, the compiler is gcc, an open source compiler with an AVR compatible implementation, and avrdude is the program used to download the compiled binaries to the microcontroller.

If your real goal is to become proficient at programming, your best avenue honestly is to focus on learning C++ on the PC. Remove the microcontroller from the equation. Once you are proficient with C++ on it's own, it'll be far easier to make the transition to programming in the AVR environment. There are far more resources for learning C++ than there are for learning AVR programming. And honestly, a high percentage of the 'tutorials' out there for AVR programming are real good examples of how not to do things.

sprintf atoi, print, getc (from stdio) sin(), random() and anything that requires you to include a ".h" file (in plain c/c++) are NOT part of the language .

They are lib's supplied with language, they may be defined in the standards but they are still just add ons .

If you look at the language the syntax does not say ant thing about them.

Mark

Wrong. The C standard defines two levels, hosted and freestanding. The freestanding environment does not include a library, but the hosted level does include a full library definition. I was on the original C standards body (X3J11) from its inception through the first C standard (the 1989 ANSI standard for the US, and the 1990 ISO standard for the whole world). The C99 standard defines some 250 pages of text describing the libraries.

I believe the C++ standard is similar, in that it provides a full library. Now in environments like the Arduino, you get a subset of the full library, but the standard does specify the library.

jraskell,that sounds like a great plan, in fact it is probably the only truly sensible plan but unfortunately it just isn't going to cut it.

I have systems that need new automation due to changes and additions.Fortunately the tasks are not that onerous and I will get away with clunky programming if I have to.I defiantly don't have clunky as a goal or even a long term acceptable solution but if needs must it will do for now.

I just bought a couple of Nanos so I can build some simple modules, PWM charging control for the PV's being the most pressing.Having a couple of boards to hand will allow me to keep experimenting and learning whilst one of them gets on with something important.Measuring a voltage and a few currents whilst driving a few FET's isn't going to be taxing but I don't want to be messing with a live system that has the fate of my batteries in its grasp.

If I knew where the box was I would probably still want to think outside it!