Arduino project? Suppliers?

[newshound]

Thanks for the offer; I know what is wrong with it, but I need to teach myself how to get it right!

One side observation, on the basis of Amazon reviews I've just bought the Mike McGrath book C++ programming in easy steps (a fiver from ABE books). While it is beautifully laid out, and *might* be OK for someone wanting a generic reference for a conventional code development environment, I don't even find the examples easy to follow. His brain must be wired differently to mine.

[Bob Eager]

Exactly what I do. The Uno is part of a kit I was given long ago, with attached breadboard on a base. Final things are nanos, or even Micros (different power consumption, memory, pin functionality).

[John Rumm]

That can be a common problem with C++ books (and to be honest, with C++ in general). I always found Marshall Cline's C++ FAQ a good starting point because it tries to convey the bigger picture "why" type questions and not just the detailed "how" ones:

Remember on Arduino there is nothing stopping you using Vanilla ANSI C if that is what you know. You can ignore much of the OO stuff if you want while taking advantage of better type checking and linking, and a more modern string library.

Although Arduino is notionally "simple", it does present a combination of complicating factors. Not only do you need to get to grips with the C / C++ language issues, you also need to deal with the architectural issues particular to the AVR platform, most notably that it's memory architecture is Harvard and not a standard Von Neumann style one. So you very quickly need to deal with the complexities of how to use and address Program RAM, program Flash, and EEPROM with overlapping address spaces and different access methods. Lastly you are doing embedded real time programming, which brings its own challenges, and a new class of issues to worry about.

[newshound]

Thanks, I will have a browse.

But I don't even know C. The last proper coding I did was in Turbo Pascal. I did end up on a big Oracle project, but I was doing architecture and requirements stuff rather than coding. Anyway, it seems vaguely sensible to get more familiar with OOP because it opens up the chance to play with Visual Basic, Python, Java, etc.

I recognise that. In the dim and distant, I was doing fiddly stuff in hardware. TBH I am not really that likely to be worrying about addressing memory directly these days. My bit-twiddling days are over.

In the days before microprocessors, I tried to write a spreadsheet program in Fortran on a PDP-8. Of course I didn't know it was a spreadsheet program, this was with a line editor, command line compiler, with graphical output only on paper via an X-Y plotter. This was for a sort of multivariate analysis on data that was both sparse and noisy. It was a miserable failure, but at least I had the comfort of realising, nearly 10 years later, how useful it could have been. (I'm not claiming to be particularly unique, I am sure that lots of people have wanted to solve the same generalised array manipulation problem, there were no doubt many mainframe implementations).

[The Natural Philosopher]

C is a subset of C++. Code in C. Its easier and very pascal like Object oriented languages are by large academic bollocks

[John Rumm]

Yup sure, and its much easier to learn something new when you have a project to do that you have some vested interest in completing or owning.

From a pascal background (as indeed I am), one of the main pains of C is the fugly syntax and complete "style shock". Coming from Turbo Pascal is a bit easier since it too is a "kitchen sink" language that can do pretty much anything in the way that C can (although with far more elegance!).

If you were familiar with OO in turbo pascal, then much of that will carry forward, but there are enough differences to bite you from time to time.

The bits you will probably need to deal with are the extra hoops you need to jump through handling string constants and stuff like that. It's easy to end up with strings that are in effect held in RAM and initialised at startup, but that means it's very easy to run out of RAM if you have any number of strings.

So there are a bunch of Arduino specific things like the F macro to get it to store string constants in flash, or the PROGROM modifier.

A bit more detail here:

There is quite a good TED talk on youtube by Dan Bricklin on how the whole idea of Visicalc:

[Andrew]

Rubbish. C and C++ require an entirely separate mindset on how you code.

[Fredxx]

Quite, keep it simple and code in C.

[John Rumm]

True, but it is also true that C is still a subset of C++ - you can write pure ANSI C and compile it with a C++ compiler. (the first C++ compilers were just front ends for C compilers after all).

[John Rumm]

That does not necessarily keep it simple though - the OO implementation can actually be much simpler to read. Look at the complexity of handling dynamic strings in C compared to using the string classes for example.

(with the possible exception of small embedded systems like Arduino, it's a bit of a moot point anyway, since all the foundation class libraries and frameworks that you will *require* to do anything of substance on a modern platform are going to be OO to one extent or another anyway).

[newshound]

I was mainly working with TP3. By the time 4 came in the management were telling me playtime was over.

I recognise that problem. One reason I am sticking with only those C++ things that are useful for Arduino.

Point taken but I am a long way off needing that sort of thing.

Bookmarked for bed-time!

[Fredxx]

There was an element of tongue in cheek, intrigued at the replies.

String classes can be treated as an extension. What C++ does perhaps give you is uniformity of performing relatively simple tasks.

Of course you can always use 'structs' as a form of object orientation in C.