next topic »

[Reply #15 on:]

Does anybody know of a link to an Arduino blink sketch for example, shown right next to a C program to do exactly the same function?

They are very similar. A "standard" C version would be something like this:

Code:

#include <avr/io.h>

void setup(void) {
//reset your chip here
}

void loop(void) {
//put your code here
}

int main(void) {
  setup();
  while (1) {
    loop();
  }
}
[/quote]

All the arduino ide does is to put your setup() and loop() into a canned main() and compile - you can check the temporary folder to see the recombined code.

For a successful career in embedded programming, you need two things:

1) a good understanding of C: structure and write bug-free code;
2) ability to read and understand datasheets: 90% of programming a mcu is to operate those registers.

The stock C-functions are not that helpful.

[Reply #16 on:]

A good toolchain to learn C on avr is the Code::Blocks + winavr combo.

[Reply #17 on:]

dhenry has skipped over a few things here.

The standard included libraries initialize the timers, and in particular sets up Timer 0 so that it "ticks" every 1.024 mS, which is then used by the millis(), micros() and delay() function calls.

So if you were to totally bypass the IDE you would have to do that yourself. The init() function in the Arduino library is the one that does that. The file (wiring.c) also includes an interrupt handler to count those ticks.

However the answers above are correct. The Arduino "sketch" is treated as a C++ program (after a bit of text munging), so anything you can do in C++ you can do on the Arduino. Some compiler options disable some things, however, such as exception handling.

You are free to create new "tabs" in the IDE, and name your files xxx.c or xxx.cpp, giving you the ability to code in "straight" C or C++. Again, within the constraints of what compiler options are enabled, and what the included libraries allow. For example, the standard library does not let you write to stdout, because such a concept doesn't really exist on the microprocessor.

[Reply #18 on:]

For example, the standard library does not let you write to stdout, because such a concept doesn't really exist on the microprocessor.

unless you do this... http://arduino.cc/forum/index.php/topic,120440.0.html

[Reply #19 on:]

Very nifty. However that's why I used the words "standard library". You can do all sorts of fancy things if you include the right libraries. That's one of its strengths.

[Reply #20 on:]

Right through from my childhood, my introductions & interests in engineering and concequently my education up until this point have all been in a mechanical discipline.

I'm in my final year of my Bachelors in an Automotive Mechanical degree right now actually - but over the last two and half years, my work has all been data & engine control engineering in motorsport with both a winning British GT team & BTCC team, and truthfully - my interests in a mechanical career are fading somewhat whilst an electronics career is looking ever more appealing.

I'm working as we speak on the hardware for a 2 cylinder ECU based around a 1284P, that supports dual wideband lambda, dual thermocouples, fly by wire throttle, extensive GP I/O, inductive & smart coil drive, saturated and peak & hold injector drive, USB - Serial etc... Most of the hardware knowledge has come from work, but as a personal project - I'm looking to first run a 2 cylinder generator as the test bed (by the time I get to the stage of working code I'll have left uni and won't have access to small dynos anymore) before running a 2 cylinder or twin engined kart with it, incorporating traction control, multi-mapping etc. Future hardware plans include comms protocols such as CAN etc.

Most of my work on clients vehicles has been with Pectel ECUs, second only to the likes of McLaren's TAG ECUs - so have extensive knowledge of how specific strategies are implemented for real world motorsport use, but am now incredibly interested in actually developing the code behind such strategies - as every now and then, would have liked the option of a somewhat different approach with a specific strategy, certainly for transient conditions.

Apologies for the life story, but hopefully it'll allow a better understanding of what I'm trying to learn for future use.

For a successful career in embedded programming, you need two things:

1) a good understanding of C: structure and write bug-free code;
2) ability to read and understand datasheets: 90% of programming a mcu is to operate those registers.

The stock C-functions are not that helpful.

When you say C: structure, are you referring to the structure of a typical C: drive on a PC? The colon makes me think so.

[Reply #21 on:]

I believe the Arduino language is a type of C++

No, it is C++.

OTOH the style of programming you do on the Arduino isn't the style of C++ programming you should use on desktop machines. On desktops you should be worrying about "RAII". On the Arduino most things are statically created/allocated - you're controlling a dozen output pins, not reading data into memory for processing.

[Reply #22 on:]

Fungus, I don't follow the logic of your post? I don't intend on programming C++ on a PC, all on MCUs?

Maybe it was my post about C: on PCs that misled you into thinking that? Dhenry had said one needed a good understanding of C: structure, and the colon made me thought he was referring to the structure of the C: directory of a PC, hence asking for clarification as I could not see how this was all so relevant.

[Reply #23 on:]

I took the colon to be a mistype for a semicolon, and the word "structure" was to be used as a verb.

[Reply #24 on:]

Ah.

I think the best plan of action from here - is probably to take some programs I've written in the Arduino IDE that I know work and do as I wish them to, and then rewrite them in plain C, get them to work. Then C++ without all the auto initialisation of the Arduino IDE.

[Reply #25 on:]

For a successful career in embedded programming

Here, dhenry has missed the key demographic, and the raison d'être of the Arduino community.

[Reply #26 on:]

Given that, as established earlier, the Arduino is programmed in C++ and that the transformation from a program using setup and loop to one using main is trivial, I think you're worrying too much. Any coding you do using the Arduino IDE is directly relevant to building your C++ experience - the functions you write would look the same whichever skeleton they use to get invoked. If you're going to be working with other platforms, you might want to get used to direct port access and bit twiddling, but even there, you can write your own wrapper functions (if they don't already exist) if they're fast enough.

In short, don't be so concerned about whether it's 'pure' C++ and get down to some coding instead 

[Reply #27 on:]

Fungus, I don't follow the logic of your post? I don't intend on programming C++ on a PC, all on MCUs?

You were thinking of "adding C++ to your portfolio"...

Using Arduino-style C++ on a desktop would be as disastrous as using desktop-style C++ on an Arduino. You might want to qualify it in your resume.

[Reply #28 on:]

Ah, Fungus - I see your point. Advertising oneself as being able to code C++ could lead to a rather awkward moment so to speak when sat down and asked to code a PC based C++ program, as opposed to a MCU program in C++.

I need to have a good look through now all the library functions that make up the digitalWrites, analogWrites, serial prints etc. Many thanks for all input thus far.

If you're going to be working with other platforms, you might want to get used to direct port access and bit twiddling, but even there, you can write your own wrapper functions (if they don't already exist) if they're fast enough.

This is what I want to achieve - to be able to program an AVR MCU using Atmel Studio for example, in the future - without any mention of Arduino. I almost feel bad saying that - given the platform introduced me so nicely 

[Reply #29 on:]

Any coding you do using the Arduino IDE is directly relevant to building your C++ experience - the functions you write would look the same whichever skeleton they use to get invoked

The way I view it, "writing a program" is really more like "writing a custom library so that main() is small and neat".