Pointers in C + Arduino Tutorial

[zapta]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

What's your point, scraping this pointer article?

[madires]

There are so many car accidents. Stop driving cars! It's dangerous! Maybe some education and good practices help more. Where I live you can't do without a pointer - I mean - a car.

[netwinder]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

What's your point, scraping this pointer article?

Hey now its not that bad 

There are so many car accidents. Stop driving cars! It's dangerous! Maybe some education and good practices help more. Where I live you can't do without a pointer - I mean - a car.

Exactly! Where I live people can go without "cars" during the summer, but when winter comes around there is clearly a superior transportation method. I like analogies

[Mechatrommer]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car, i'm not sure what it is but i guess it will be a super automatic car where we dont have to do nothing, just speak turn left turn right speed up brake brake hard brake 90% etc etc. the best we have though is automatic car where the freedom of choosing which gear we are at is taken away. but well, eventually many automatic car did crashed.

[nctnico]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

[netwinder]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

It could be said that in a race car, you would want to remove a lot these "safety" features as they add weight. A lot the safety features that are essential in race cars are usually very minimal and skimpy. Were talking the difference between a gigantic bloated (slow) family mini van versus an F1 Racer (uber fast).

[helius]

Here is my solution for an array for instance.
http://atl.codeplex.com/SourceControl/latest#Source/Code/ArduinoTemplateLibrary/Array.h

(You 'store' the size with the instance and you perform bounds checks)
I know it's not C but C++... I personally don't see any advantage in using C - unless that is the only compiler you have...

For one thing you can use an initializer expression when you define a C array (and the size can be inferred from it). I didn't see any ability to do that in your code. For 1-D arrays the STL vector templates work pretty well already.

[tszaboo]

Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

While I dont totally agree with this, I agree with the hatred for pointers.
Pointers should be last resort. If you run out of computing time, and you need that little extra processing power just to make it.
Program everything, like you dont know pointers. Is the application OK? Good, no pointers. It is not OK? Use qsort, memset, memcpy, math libraries... Still not OK? Maybe then pointers, last resort.

[Jeroen3]

You are brave bringing pointers to Arduino. Good article.

You can't not use pointer.
Examples of pointer:
- Any peripheral register write/read.
- DMA use.
- Device drivers.
- Pooled memory.
- The first thing the mcu does is following a pointer.

Not using pointers is the same as storing your "pointer" as address+x, which is still a pointer! And is still subject to implicit boundary errors.

I'd like to see nctnico write a TCP stack without pointers. People scared of pointers often don't even know how to use multiple files. Code looks awful, and is bloated with bugs and inefficiencies.
The only upside to not using pointers is that code doesn't bus/hardfault (reset for arduino) that easily.

 

[dannyf]

"Tell me what you think "

Nice work.

I would suggest adding a section on function pointers as an intermediate course. After that, some combination of pointers and const attributes in the MCU setting. Ie. A pointer to s const type or a const pointer, ....

[Mechatrommer]

There are so many car accidents. Stop driving cars! It's dangerous!

no. that is not his point, we still need the car. his point is, we have to use managed car,

At least a car with seat belts, anti-lock brakes and air-bags.

your analogy is not good enough. seat belt is something within our control, meaning we are still free to not use the seat belt, resulting no safety whatsoever, but we can take another measure to ensure safety such as drive slowly, we are still in freedom to use or to not use. otoh ALBS and air-bag are the "after effect" of a result of using a "feature", the main feature are brake pedal and steering/manuveribilty respectively, which in turn still in our full control. if we dont press brake pedal, no ALBS will take action, boom! steering wheel... if we direct the car to safe road, air bag wont blow. if we intentionally hit a brickwall, air bag will blow but the rest of the car, is not any good.

your after effect analogy in programming is more suited if we are still free to use the pointer or not to use, but in case we use it and disaster happened, say we tried to access out of bound area, then there will be "managed" after effect fail safe feature such as error throw etc. but i havent heard of a successfull fail-safe feature in case of pointer violation implemented at the same level of where the program is coded, except if one is to make a custom data-type class or on higher level (OS) the blue screen of death, one may think blue screen is a disaster, it is not, it is a failsafe feature, the nastiest one. but its actually to avoid further and more severe disaster. do you think air bag blowing is a bless? no, its a disaster, but only to avoid more severe disaster.

managed language otoh will encapsulate pointer beyond programmer reach, access only by indirect (type safe) manner where grant is given if the internal wisdom of the managed library says so. in case of your analogy, ALBS should encapsulate brake pedal too, so in order to brake, driver need to press something, a button maybe, and car computer will decide whether its wise to brake, or not, or brake with ALBS activated etc... through internal infinite wisdom, beyond user reach, control and desire.

[John Coloccia]

re: fast vs slow

Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. There are exceptions, of course, and it also pays to know something about the kinds of things compilers will and won't optimize depending how you write your code. Generally, though, the point of pointers is not to make code run faster.

It also helps if you use C++ as opposed to C, even if you're just mainly writing C code. C++ typing is much better than C, and especially if you turn on the right compiler options it will go a long way to keeping you out of trouble. Much trouble is created when programmers get lazy and instead of actually creating proper types and structures they simply cast everything away so it can be handled with some random pointer. If you have a lot of (void*) and other casts in your code, it's usually an indication that someone is rushing or inexperienced. That's not to say there aren't times you need to do stuff like this, but it's an antiquated way of doing things. Disk space is cheap....teletypes are non-existent. There's no reason to use this sort of old fashioned style anymore because you're not helping yourself, and in fact you're probably making it so the poor compiler can't carry out the best optimizations.

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come, so may as well make your peace with it and learn how to use it properly.

[netwinder]

You are brave bringing pointers to Arduino. Good article.

You can't not use pointer.
Examples of pointer:
- Any peripheral register write/read.
- DMA use.
- Device drivers.
- Pooled memory.
- The first thing the mcu does is following a pointer.

Not using pointers is the same as storing your "pointer" as address+x, which is still a pointer! And is still subject to implicit boundary errors.

I'd like to see nctnico write a TCP stack without pointers. People scared of pointers often don't even know how to use multiple files. Code looks awful, and is bloated with bugs and inefficiencies.
The only upside to not using pointers is that code doesn't bus/hardfault (reset for arduino) that easily.

 

Thank you, and I can't say enough how frustrating it has been (not with Arduino) making a peripheral work properly without pointers, when I didn't know how pointers worked (I had this stigma that they were this scary horrible thing that would ruin my life) I just avoided them as much as possible. Then I tried them, and after about 2 hours of debugging, googling, and bowing down to a portrait of Kernighan and Ritchie, I eventually got the peripheral working, I was using less resources on the processor side of things, AND the code was much more readable 

[hamster_nz]

Wow! I am amazed at how many people seem keen on using Java on a micro-controller with 32k of program memory and 2kB or RAM.

It is all about using the correct tool for the job, and running bare-metal on a small 8 bit microcontroller C or a subset of C++ is pretty much the correct tool in most use-cases. Even on a small 32 bit microcontroller C and a less limited subset of C++ is usually correct tool.

A firm grasp of pointers and address spaces are even more important when you have to deal with the likes of PROGMEM.

Anybody here have any idea how Java or another higher language would handle having a second address space, that is even more immutable than an immutable object? As far as I know that doesn't fit inside the paradigm....

[nctnico]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

[hamster_nz]

, and I can't say enough how frustrating it has been (not with Arduino) making a peripheral work properly without pointers, when I didn't know how pointers worked (I had this stigma that they were this scary horrible thing that would ruin my life) I just avoided them as much as possible. Then I tried them, and after about 2 hours of debugging, googling, and bowing down to a portrait of Kernighan and Ritchie, I eventually got the peripheral working, I was using less resources on the processor side of things, AND the code was much more readable 

One has to not use pointers to work out how to use pointers.

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

I don't think that the pool of technically adept people has grown at the same rate as the demand for technical people. So the average programmer is less capable that they used to be when programmers were a self-selected group of propeller-head nerds who felt the calling to flip bits.

It is no surprise that on average programmers are working at a higher level of abstraction, doing such things as coding business logic in SQL stored procedures or field validation in Javascript, but I also wouldn't be surprised if more lines of assembler are written this year then any previous year.

[netwinder]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

But people still code in assembly, it may not be as much as before - however in interrupt based programming alot of interrupt sequences are programmed as an assembly subroutine for maximum efficiency. (For example)

[madires]

I'm still using assembler if it's necessary or provides a proper benefit, sometimes as inline code. But we should focus on the MCUs and the firmware. 20 years ago a 68HC11 had 256 bytes RAM. Today it's 1 or 2kB for a cheap ATmega. With the flood of cheap ARMs we have 32 bit MCUs with a little bit more resources. Still the goal is to use the cheapest MCU possible to solve a problem, unless you design something for a very low volume production.

[dannyf]

"Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. "

I'm not so sure about that.

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

Size or execution speed isn't really that important, for the most part. Many institutions actually prohibit "fancy" obscure code. The reason is simple: bloat or slow code is much easier to deal with than buggy code.

[hamster_nz]

"Rule #1 is simply do the best job you can to not write bloated, crap code, and a good optimizing compiler will usually do a much better job than you making it run fast. "

I'm not so sure about that.

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

Size or execution speed isn't really that important, for the most part. Many institutions actually prohibit "fancy" obscure code. The reason is simple: bloat or slow code is much easier to deal with than buggy code.

Writing good code is such a multi-dimensional problem space that splitting it into "good and more-good" makes very little sense. Size might be important if it costs you on a high volume product, latency might be important if it is a VR tracking, speed might be important if it is a real time system.

Heck, I am sure that somebody could support the argument that code that doesn't work 100% correctly but is simple and maintainable is best (e.g. something along the "Close enough for Jazz" argument).

It is all about needs
- Needlessly slow is bad
- Needlessly complex is bad
- Needlessly bloated is bad
- Needlessly over-optimized is bad

The tough projects are the ones where everything is needed - "we need small, fast, highly maintainable code, to accurately solve a very complex problem"

[John Coloccia]

But C/C++ isn't going anywhere. I suspect it will be the go to choice for system and embedded code for many decades to come

Not so long ago people said/wrote the same about assembly and god forbid you mentioned C++ in a microcontroller context! Assembly would ever die? Blasphemy -tar and feathers-! The horror of using C++! See where we are now...

When was was that? 40 years ago before a good language like C was developed that allowed high level programming and low level access? The whole point of C was to have lightweight language that mapped easily to machine language and prevented you from having to drop to assembly for all but the most low level machine specific tasks. It was tailor made for this kind of work, which is why it's still close to the top in popular languages today, or maybe even is at the top again for all I know. You know what's loosing ground? Java, that's who, and everyone else are distant 3rds and 4ths. IMHO, Java was a terrible mistake that we're all paying for. I know a lot of people like it, but having used it my impression is not very favorable as a general programming language, though it's pretty good for tossing together little snippets of code that do small, well defined tasks.

Incidentally, there really IS a good reason to shun the C++ runtime library for embedded, because it's huge and ugly. There are ways to get around that, and sometimes the processor vendor even includes it's own libc++ that strips out all of the bloated craptastic stream, stdlib et. al. stuff and leaves you with a lean implementation.

C/C++ hasn't gone anywhere in 40 years, and has just gotten more popular and more entrenched, not less. The only reason it's not even more ubiquitous is because of C#, which is actually quite good IMHO, and the various environments that Apple and Android use for their apps. It's really unthinkable that C is on it's way out.

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

[John Coloccia]

If you are in the business of writing code, I tend to think writing reliable and maintenable code that works is priority 1.

I'm not sure we have the same definition of bloated, crappy code. LOL.

[zapta]

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

Using a non standard language has its own cost.

[John Coloccia]

All that said, if you want a treat, and can get a compiler for your platform, you should check out the D programming language. It's really an improvement over C++ in many ways (though nothing is perfect).

Using a non standard language has its own cost.

There are lots of hobbyists on the forum that don't care about that, but it's more popular and mature than you might think. Facebook has been using D for a good number of years, now. I personally think if anything has a chance to be the successor to C/C++/Java, D is it.

[Mechatrommer]

There are lots of hobbyists on the forum that don't care about that,

you are dealing with profesional here where they care you dont, where they dont you care. keep arguing like this is like pulling string indefinetely, pointless.