Pointers in C + Arduino Tutorial

[John Coloccia]

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.

Well, you're dealing with a professional here too, so I guess we're even. Let me tell you what the problem is, and why nonsense like this even comes up in the first place.

When you go to school and learn electronics, how do they teach it? Well, of course they start with high level concepts such as gates, and then they talk about building digital computers with the gates. Then, just before you graduate college, they introduce the concept of resistors, capacitors, transistors, etc....and they explain a little about voltage and current, and voila', you're an engineer.

Right?

No no no....completely wrong, it sounds crazy and it is crazy.  You start by learning about basic things, like resistors and caps, and you slowly build up into more complicated things. By the time you're ready to graduate, maybe you can't design a computer, for example, but you can at least see how you might get there from the basic building blocks.

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

[netwinder]

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.

Well, you're dealing with a professional here too, so I guess we're even. Let me tell you what the problem is, and why nonsense like this even comes up in the first place.

When you go to school and learn electronics, how do they teach it? Well, of course they start with high level concepts such as gates, and then they talk about building digital computers with the gates. Then, just before you graduate college, they introduce the concept of resistors, capacitors, transistors, etc....and they explain a little about voltage and current, and voila', you're an engineer.

Right?

No no no....completely wrong, it sounds crazy and it is crazy.  You start by learning about basic things, like resistors and caps, and you slowly build up into more complicated things. By the time you're ready to graduate, maybe you can't design a computer, for example, but you can at least see how you might get there from the basic building blocks.

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

[John Coloccia]

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

For what it's worth, my official training is also in software, with a MS in Software Engineering. I personally never really had any of these problems. It all just came very, very easily, for whatever reason, and the choice of language is no more a stumbling block than choosing a flat head screwdriver over a Phillips. I think a lot of pros feel the same way...the language is just a tool and irrelevant so long as it's an appropriate tool.

My opinion comes from years and years of tutoring and helping people. When someone is having trouble, the initial reaction is always "Simplify...hide even more details!!". This is 100% wrong and is based on the concept that the guy is stupid and incapable of understanding, so you strip away everything that requires thought and try to give him some simple rules he can blindly follow. Disaster is always close behind because you can't do any real learning like that. I've found that when someone's having trouble with pointers, the thing to do is spend a day doing nothing but talking about the basics of how a computer works....memory, program counters, stacks etc. Real nuts and bolts kinds of things. It doesn't matter that they don't remember it all. It's just setting the foundation so they have SOME idea what I'm talking about. Without that, when you say words like "memory" and "address" it's nothing but words. You could say "cat" and "dog", and it would make just as much (or as little) sense to them.

I'll tell you why this is so screwed up.  Computer Science typically grew out of the Math department of Universities. It's probably changed now as older guys have retired and new guys are entering the system, but if you go back to the late 80s/early 90s when I went to College/Graduate School and you look at the degrees of the professors, they all have PhDs in some field of Mathematics since there was no such thing as Computer Science when they went to school. Most Computer Science departments are still part of the Math department, and it SHOULD be part of the Engineering school instead. Again, this is just because all of the professors were traditionally all math professors, so I guess Comp. Sci. goes in the Math department.

And we teach programming the same way we teach mathematics. You don't start with Peano Axioms and work your way up. You start with basic arithmetic, and then you add in some algebra and some calculus. And then you add in a little Linear Algebra and maybe some differential equations, and at each step you never look at the guts. You have some nicely polished practical rules that are the result of the basic axioms, but you NEVER start at the bottom and work your way up. You always start in the middle somewhere. That just doesn't work well for software because you never have a solid foundation to work from. It's magic, and the poor student is the sorcerer's apprentice.

[dannyf]

"The beginner language should be some sort of assembly languag"

Not sure.

Programming is to solve problems. That means algorithm, data structure and float control, and scopping.

Assembly does s poor job at that, and is non transferrable.

Of the main stream languages, pascal would have my vote. C can be too loose, and too powerful for beginners

[madires]

I've started with Basic at home and in school. Yes, my school was an early CS adopter, had PETs and offered CS as elective subject. Later on they moved to C128s with Comal80 and Modula modules. I think, Basic and Pascal are good programming languages to start with. From there you would select the next languages based on your career path. For an EE dealing with MCUs this would be assembly and C/C++.

[netwinder]

As a programmer I have quite some insight to add to this. I first learned to program in C (and in general) it was rather frustrating. This was likely because I didn't know much about semantics, program structure, and what that weird for loop does (don't worry, I know what it does now  ). Eventually I found these wonderful things called textbooks and I was happily on my way practicing this new language.

Some Universities around me teach software the way you say, through starting at the bottom of the system and working their way up.
This book (there is a third edition, but no free PDF floating around) studies computers starting with some basic technical knowledge, however it starts from C, it then discusses the various levels involving a C program (this is only the preface) and then after that it's bottom up, for a while they do program in assembly to demonstrate a few concepts (see the table of contents, pdf page . I've read part of this book, and while my C programming skills haven't improved I am much more effective at debugging and fixing code, thinking about code at lower levels, and optimizing code for speed.
https://doc.lagout.org/programmation/Computer%20Systems%20-%20A%20Programmers%20Perspective.pdf

However not all schools have this approach, in my school the mind set is "JAVA IS KING!!! Who cares how the VM works" and this leads to a lot of rather interesting code.

I digress, learning to program in assembly is like learning carpentry (sorry for another analogy, I can tell we have had too many of them) without power tools and by only using hand tools. Sure you eventually could get to the same results, but there will be an extremely steep learning curve, and lots of error along the way. There are a lot of carpenters out there that believe in this. However they are experienced - they already know how hand tools work.

My point is while hand tools are fun and great, we need power tools to get the bulk of the work done.

For what it's worth, my official training is also in software, with a MS in Software Engineering. I personally never really had any of these problems. It all just came very, very easily, for whatever reason, and the choice of language is no more a stumbling block than choosing a flat head screwdriver over a Phillips. I think a lot of pros feel the same way...the language is just a tool and irrelevant so long as it's an appropriate tool.

My opinion comes from years and years of tutoring and helping people. When someone is having trouble, the initial reaction is always "Simplify...hide even more details!!". This is 100% wrong and is based on the concept that the guy is stupid and incapable of understanding, so you strip away everything that requires thought and try to give him some simple rules he can blindly follow. Disaster is always close behind because you can't do any real learning like that. I've found that when someone's having trouble with pointers, the thing to do is spend a day doing nothing but talking about the basics of how a computer works....memory, program counters, stacks etc. Real nuts and bolts kinds of things. It doesn't matter that they don't remember it all. It's just setting the foundation so they have SOME idea what I'm talking about. Without that, when you say words like "memory" and "address" it's nothing but words. You could say "cat" and "dog", and it would make just as much (or as little) sense to them.

I'll tell you why this is so screwed up.  Computer Science typically grew out of the Math department of Universities. It's probably changed now as older guys have retired and new guys are entering the system, but if you go back to the late 80s/early 90s when I went to College/Graduate School and you look at the degrees of the professors, they all have PhDs in some field of Mathematics since there was no such thing as Computer Science when they went to school. Most Computer Science departments are still part of the Math department, and it SHOULD be part of the Engineering school instead. Again, this is just because all of the professors were traditionally all math professors, so I guess Comp. Sci. goes in the Math department.

And we teach programming the same way we teach mathematics. You don't start with Peano Axioms and work your way up. You start with basic arithmetic, and then you add in some algebra and some calculus. And then you add in a little Linear Algebra and maybe some differential equations, and at each step you never look at the guts. You have some nicely polished practical rules that are the result of the basic axioms, but you NEVER start at the bottom and work your way up. You always start in the middle somewhere. That just doesn't work well for software because you never have a solid foundation to work from. It's magic, and the poor student is the sorcerer's apprentice.

Can't agree with you more on this. One thing I love about (some of) the computer science texts I have is that they go so far in depth. My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function"  and not to put the blame on the textbook but its a real limiting factor in mathematics for me. I end up with questions like "why does synthetic division work" etc. Usually ends with a frustrated math teacher, as they would want to go to higher levels of problems when I need the lower levels explained first.

I digress, When I used to help friends out when I got more experience with CS, I tried the oversimplification method and it went just as you describe. They would get through the example I was coaching them with, and then with the next example they were cranking out broken code. Along the lines of "teach a man to fish" analogy.

[LazyJack]

"The beginner language should be some sort of assembly languag"

Not sure.

Programming is to solve problems. That means algorithm, data structure and float control, and scopping.

Assembly does s poor job at that, and is non transferrable.

Of the main stream languages, pascal would have my vote. C can be too loose, and too powerful for beginners

I cannot agree more. You are absolutely right. I used to teach programming at a university to EE and CS students, and C is a big pain in the backside for teaching programming. Instead of learning how to think and create the algorithms they get all lost in the details of the language or try to show off by implementing the whole program between the parentheses of for(,,). With little success of course.
As much as I love C for real world projects, I would definitely use Pascal for entry into programming. Unfortunately, this cannot be done, as students expect the university to teach "useful in practice" stuff, not realizing that once you know how to think as a good programmer, you can learn any language in half a day (excluding Lisp of course ).
But it does not work the other way around.

[dannyf]

"My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function" "

That sounds like a great textbook.

" I end up with questions like "why does synthetic division work" etc"

Sounds like an easier class would have worked better for you.

[IanB]

The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

Agreed. And this, incidentally, is one aspect I remember when elementary computer science was being taught to classes of 14/15 year olds back in the 1970's. There were at least two simulated machines with a basic hypothetical instruction set that students could write and run programs in to get some idea of how computers worked.

[netwinder]

"My math textbooks on the otherhand are more along the lines of "Factor remainder theorem: p/q, go solve the zeroes of this polynomial function" "

That sounds like a great textbook.

" I end up with questions like "why does synthetic division work" etc"

Sounds like an easier class would have worked better for you.

Absolutely is a great(horrible) textbook? And an easier class wouldn't work better, I just want to know how things work. When I understand how something works it makes using the something a lot easier. It relates to programming as if you oversimplified and didn't go into how things worked at a lower level, you would end up with questions like "why is my sorting algorithm causing a buffer overflow". A class where the teacher went more in depth would be nice.

The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

Agreed. And this, incidentally, is one aspect I remember when elementary computer science was being taught to classes of 14/15 year olds back in the 1970's. There were at least two simulated machines with a basic hypothetical instruction set that students could write and run programs in to get some idea of how computers worked.

This would be a good solution provided they transitioned into a higher level language in a easy-to-follow way.

[helius]

But when we teach software, what do we do? We start with a so-called beginner language. Take you're pick....BASIC, Fortran, Pascal, Java, or even C and C++...whatever, they've all been used and more.  Bah. The beginner language should be some sort of assembly language. Maybe even a simplified assembly running on a simulated processor.  This is where you learn all of the nuts and bolts so when you then get to a real language, it all makes sense because you can visualize what's happening.

The key is to choose a set of abstractions that don't leak and are durable enough for whatever you need to do.

In your example of starting with "basic components like resistors and caps", who decided that these are the basic building blocks? A lot actually goes into making resistors and capacitors, they are not ideal, and they are not really even necessary to make circuits as shown by technologies like SLT hybrids. But in practice, for the kinds of things EEs usually do, it's generally adequate to regard them as fundamental even if they aren't. It's a compromise: by settling on a lumped element abstraction, we know that there are some things we can't do, but we don't usually need to do those things (except for transmission lines and so on). And the payoff is that modeling our circuits is easier.

In computer science, a similar tradeoff exists. While we could model programs as assembly code running on a concrete machine, in practice it's not necessary and doesn't give us any better insight into what is happening. Instead we choose a set of abstractions that hopefully do not leak—this is the major criteria that distinguishes good and bad language design. In a well-designed language, everything that happens in a valid program is explained by the language's semantics. We also want clear error messages that explain the reasons programs are not valid (it is possible to define a language where any possible input is valid [see Brainfuck and Befunge] but not especially useful). This is also a compromise where we know we can't do certain things (like debug hardware failures), but we gain tractable models at a single level of abstraction.

When learning computer design, a different level of abstraction is necessary that exposes the hardware, so assembly language is used. Should computer design be a prerequisite for learning programming? This sounds bizarre and it is. Without knowing programming, there is nothing to guide the requirements for computer hardware; it might as well be any other dumb widget.

[IanB]

In your example of starting with "basic components like resistors and caps", who decided that these are the basic building blocks? A lot actually goes into making resistors and capacitors, they are not ideal, and they are not really even necessary to make circuits as shown by technologies like SLT hybrids. But in practice, for the kinds of things EEs usually do, it's generally adequate to regard them as fundamental even if they aren't. It's a compromise: by settling on a lumped element abstraction, we know that there are some things we can't do, but we don't usually need to do those things (except for transmission lines and so on). And the payoff is that modeling our circuits is easier.

But resistance, capacitance and inductance are fundamental properties described by physics, which limit the realizable performance of any abstract component you try to construct. Therefore it is useful and important to understand such basic concepts so you can have an appreciation of the performance limits of the higher level building blocks you may be using. The "ideal" and "perfect" black box transistor, op amp or logic gate doesn't exist; it is an imperfect realization of an ideal with very definite limits to its performance. If you haven't learned some fundamental physics you will find it hard to recognize where these imperfections are and how they manifest.

In computer science, a similar tradeoff exists. While we could model programs as assembly code running on a concrete machine, in practice it's not necessary and doesn't give us any better insight into what is happening. Instead we choose a set of abstractions that hopefully do not leak—this is the major criteria that distinguishes good and bad language design. In a well-designed language, everything that happens in a valid program is explained by the language's semantics. We also want clear error messages that explain the reasons programs are not valid (it is possible to define a language where any possible input is valid [see Brainfuck and Befunge] but not especially useful). This is also a compromise where we know we can't do certain things (like debug hardware failures), but we gain tractable models at a single level of abstraction.

And the same thing occurs here. Not everything is explained by the language's semantics, and nor can it be. There are limitations imposed by the hardware, and some things are defined outside the language. For example, a language cannot usually define the exact behavior of floating point arithmetic at the limits, the rounding behavior, and the exception behavior. If you do not have an appreciation of how floating point hardware works at the binary level you will fall into some traps in your high level programming.

When learning computer design, a different level of abstraction is necessary that exposes the hardware, so assembly language is used. Should computer design be a prerequisite for learning programming? This sounds bizarre and it is. Without knowing programming, there is nothing to guide the requirements for computer hardware; it might as well be any other dumb widget.

Your argument seems to fall down at the first hurdle. Doesn't history tell us that the first stored program computers were designed before there was ever a fully developed theory of programming?

[John Coloccia]

Students are so ill prepared when they start learning about higher level concepts, like data structures for example, that all you ever get to is little toy structures....like little linked lists and things like that. And as they go along, they stumble and stumble and stumble because they don't actually understand the tools they're playing with. As I said before, it's a sorcerer's apprentice situation.

If they went in with a SOLID knowledge of how a computer actually works, the language is no longer important because it's easy to learn. And THEN you can have an in depth discussion of these higher level, and extremely important, concepts because you're not spending 90% of you're time trying to figure out a stupid program. The programming should be second nature and a non-issue by this point because it's no longer a mysterious black box, and the choice of language should be irrelevant. You just spend a day getting some basic concepts down, and then you sit down with your reference and use the tool. Doesn't work like this in school, does it? It should because it works like this when you're a pro in real life. At least it had better work like this or you're not going to have a very long career.

[helius]

But resistance, capacitance and inductance are fundamental properties described by physics, which limit the realizable performance of any abstract component you try to construct. Therefore it is useful and important to understand such basic concepts so you can have an appreciation of the performance limits of the higher level building blocks you may be using. The "ideal" and "perfect" black box transistor, op amp or logic gate doesn't exist; it is an imperfect realization of an ideal with very definite limits to its performance. If you haven't learned some fundamental physics you will find it hard to recognize where these imperfections are and how they manifest.

Resistance, capacitance, and inductance are not "fundamental" in the sense of fundamental particles and forces. They are collective effects that are observed under certain conditions. Don't mistake the lumped element abstraction for reality! It cannot predict behavior under some conditions, like when the circuit is moving in a magnetic field.

And the same thing occurs here. Not everything is explained by the language's semantics, and nor can it be. There are limitations imposed by the hardware, and some things are defined outside the language. For example, a language cannot usually define the exact behavior of floating point arithmetic at the limits, the rounding behavior, and the exception behavior. If you do not have an appreciation of how floating point hardware works at the binary level you will fall into some traps in your high level programming.

This is the leaky abstraction at work. Languages like C that punt basic semantics like arithmetic results to "implementation defined" behavior are badly designed for pedagogical purposes. It is completely unnecessary to rely on what the hardware does: whatever oddities in the floating point hardware are exactly like the Pentium F00F bug and just need to be rectified by the implementation.

Your argument seems to fall down at the first hurdle. Doesn't history tell us that the first stored program computers were designed before there was ever a fully developed theory of programming?

No, because Al-Khw?rizm?, Babbage, Lovelace, Boole, Frege, Church, and Turing had something of a headstart 
But even if they hadn't, it's a genetic fallacy to suggest "the first!" computer is in any way relevant.

[Mechatrommer]

Not everything is explained by the language's semantics

Languages like C that punt basic semantics like arithmetic..

i believe you people talking about "syntactic". a language doesnt define or explain semantics. language is a tool for building semantics and convey it to other medium for energy transfer or information sharing.

having said that, i dont tend the definition of a language as something inclusive to the "built in" or "standard" library or compiler/linker features that came with the language, which i believe why everybody debated here or in any other programming threads trolls that "this language" better than "that language", this language has better "managed language" that language is not. if C++ specification is extended to add this management libraries to the same magnitude as those other new fancy languages, C++ can be just as robust, without necessitating to block direct pointer access from programmer. then we can divide C++ programmer into 2 different classes, one is the hardcored pointer fans who care too much on code efficiency no matter how much time spent for the cause, and the other one is who are too afraid to use pointer and use C++ managed library extensively, production to delivery time is #1 priority.

i can understand if one argue this language is better than that language because of readability, but arguing about managed vs unmanaged and blaming on the "language"? duh this is just endlessly confusing ... btw C/C++ has been "managed" for this long with features such as throw and assert or even alloc/new etc, its just this "managed" buzz seemingly only taking place in those new and fancy languages for kids (no offense). actually semantics/error management (to some smaller extend than today) has took place long ago than what you have believed.

[John Coloccia]

i believe you people talking about "syntactic". a language doesnt define or explain semantics. language is a tool for building semantics and convey it to other medium for energy transfer or information sharing.

having said that, i dont tend the definition of a language as something inclusive to the "built in" or "standard" library or compiler/linker features that came with the language, which i believe why everybody debated here or in any other programming threads trolls that "this language" better than "that language", this language has better "managed language" that language is not. if C++ specification is extended to add this management libraries to the same magnitude as those other new fancy languages, C++ can be just as robust, without necessitating to block direct pointer access from programmer. then we can divide C++ programmer into 2 different classes, one is the hardcored pointer fans who care too much on code efficiency no matter how much time spent for the cause, and the other one is who are too afraid to use pointer and use C++ managed library extensively, production to delivery time is #1 priority.

i can understand if one argue this language is better than that language because of readability, but arguing about managed vs unmanaged and blaming on the "language"? duh this is just endlessly confusing ... btw C/C++ has been "managed" for this long with features such as throw and assert or even alloc/new etc, its just this "managed" buzz seemingly only taking place in those new and fancy languages for kids (no offense). actually semantics/error management (to some smaller extend than today) has took place long ago than what you have believed.

By "managed" in this context I believe they specifically mean running in the runtime virtual machine. You can get managed C++ with C++/CLI, which is an extension just as you suggested.

But I agree with you that I don't see a big deal with different languages concerning the quality of the end program. Pros, or at least competent pros, don't spend their days tracking down pointers flying off into space. While I'm sure it happens, it doesn't happen because of confusion or difficulty. It happens because of a logical error and it would have caused some other bug instead to be tracked down anyway.