Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

C Programming: pointers

Status
Not open for further replies.
Programming is not about "how easy it is to write". It is about structure, abstraction, modularity, managing big projects, working in teams and passing the work to the next guy to continue. Without these things you can't build "big" things.
Well I agree in part.. However I have always been a lone programmer, so the rules of programming do not apply to me. I would bet that the majority of programmers here are also embedded engineers who do the same style of programming,

The whole reason behind C++ was for those reasons... C can be just a general programming tool.
 
Well I agree in part.. However I have always been a lone programmer, so the rules of programming do not apply to me. I would bet that the majority of programmers here are also embedded engineers who do the same style of programming,

The whole reason behind C++ was for those reasons... C can be just a general programming tool.

I program alone also, but I can see myself as a team where I play the part of everybody. I can look at 10 year old C code written for AVR and use those modules for ARM project, or a Linux project.. no problem. I can look at my embedded C code and copy data structures etc. almost as is to C# for my PC interface application. When I learn C, I'm actually learning tens of other languages at the same time.

C language was developed by ASM programmers, because they needed more powerful tool to accomplish smarter things more efficiently. C++, java etc. is just a continuation to that.
 
Last edited:
C is an abstraction layer. It abstracts you from the hardware, processor, OS etc. It gives you a very flexible control of data structures, so that you can organize your data into chains, lists, queues, trees (or whatever) consisting of polymorphic data. It doesn't care about such things as endianness. And it works. The programs written 20 years ago can be compiled and run without modifications on my Android phone. Absolutely fascinating!

However, when it comes to MCUs, things get different. Your primary task is to control hardware in real time. A lot of processing is done by built-in hardware modules which run in parallel and use DMA and interrupts. Your need to organize them and make sure all interrupts are handled and everything is taken care off. You need to be acutely aware of how fast your code runs or you risk blocking interrupts for too long and loose some of them.

In this situation, you do not want to abstract from hardware (and there's no OS to do that for you), you want to be as close to it as possible. You cannot use complex data structures because with only 4K of memory your heap is going to fragment very quickly. So, C gets stripped from its abilities, and simply becomes a different method to write things.

This is a matter of personal preference. If you wish, you write in C. If you wish, you write in Assembler. Writting in C doesn't make you more advanced or more productive.

I don't know why it is related to the choice of language, but "big" program will simply won't fit MCU memory (and if you really want to fit more for some strange reason, it's easier done with Assembler). It is therefore no need for team work and big project management. Also, there's no need to pass it to the next guy because when the next guy comes the hardware becomes obsolete and everything will have to be re-developed with new hardware. Perhaps MCUs will run Linux by then ... It may be a totally different story.

Tools need to be chosen for the task. You do not hummer nails with oscilloscope simply because it is more advanced than a hummer.
 
Last edited:
You are not very familiar with C nor very good at it, are you. You have just this "idea" what C is. But you don't really know.

C does not abstract away from OS. C tries to stay away from machine dependent details, but it does not abstract away from hardware. You have full control of register, memories, interrupts etc. using C. The compiler does not know how to set up timers, or use DMA. You always need to know your hardware. And you have full, and only, control of it using C.

Interrupts are the only complicated thing when using C with uC, because there is no standard how to handle them. You need to know your compiler. I have written naked interrupt routines and used inline ASM to write my own entry and exit code.. no problem. Usually the compiler is very smart optimizing those things, but sometimes you need to do it yourself.

Complex data structure is equally complex with asm.. what would change that. It is in your hands to design the datastructure you need. Data is data.. Using C does not mean you are automatically using heap memory and fragmenting everything. I rarely use heap memory. And C does not allocate heap memory. It is up to the programmer how he uses memory.

Writing C and ASM makes me more advanced and more productive than just ignoring C and sticking to ASM no matter what.

"Big" programming does not mean you need "big" memory. It means you are doing "big" things. Complex things. Things that makes your head spin fast unless you choose the right tool for the job.. write modular code, get organized. Writing ASM does not mean that the code size is small either. If the problem at hand requires lots of code then ASM is not going to help you. Choosing ASM might even be your biggest mistake at that point. If the program does not fit your memory, you have chosen the wrong uC.

C is not far from asm really. It is just more productive way to code it. I would even bet that most C compilers produce better ASM than average hobby asm coder.
 
Last edited:
However, when it comes to MCUs, things get different. Your primary task is to control hardware in real time. A lot of processing is done by built-in hardware modules which run in parallel and use DMA and interrupts. Your need to organize them and make sure all interrupts are handled and everything is taken care off. You need to be acutely aware of how fast your code runs or you risk blocking interrupts for too long and loose some of them.

This is just device brickwork not applications programming. Yes, brickwork must be precise and done right but it's craftsmanship not architecture. Once you get past the computer brickwork step 'flow' takes center front stage in even a small MCU coding project. How does asynchronous external I/O flow from these modules to functions, what 'Control flow' functions are needed to operate on that data and how does data flow back to modules for external I/O. Functions with simple logic and data interactions will be small in C or ASM code but functions with (they don't have to be large memory footprint problems) complex data and logic interactions might actually be larger in an human written ASM version because it's much easier to create an 'abstract' world for your problem in a HLL that at first might be slower and larger than a working ASM version of a solution but will usually be much easier to optimize (yielding better computer generated ASM code) given the same resources of time and effort.
 
C does not abstract away from OS. C tries to stay away from machine dependent details, but it does not abstract away from hardware. You have full control of register, memories, interrupts etc. using C. The compiler does not know how to set up timers, or use DMA. You always need to know your hardware. And you have full, and only, control of it using C.

It does abstract on big computers. It used to be a lot of different processors that UNIX could run on. You write a single program on C and you can compile it for any of them. And now you can compile it and run on my phone, even though the phone, and ARM processors, didn't even exist when the program was written. Or on Windows. Or a future system that doesn't even exist now. That's what it was created for.

Now, like you said, it doesn't really matter on MCU because you hard-code your register, memories, interrupts, DMA into your code. Once you do that, it is no longer portable.

Complex data structure is equally complex with asm.. what would change that. It is in your hands to design the datastructure you need. Data is data.. Using C does not mean you are automatically using heap memory and fragmenting everything. I rarely use heap memory. And C does not allocate heap memory. It is up to the programmer how he uses memory.

Right. C is very good with complex data structures. You can allocate structures, interlink them, walk through them. But, to allocate them you need a heap. For example, you need to build a binary tree with elements of varying size. You cannot do that without a heap. It is not practical on MCU, so you don't use it. Another advantage of C is lost.

No wonder people have problems with pointers. Without a heap, they don't have anything for the pointers to point to.

"Big" programming does not mean you need "big" memory. It means you are doing "big" things. Complex things. Things that makes your head spin fast unless you choose the right tool for the job.. write modular code, get organized.

"Big" things that make you head spin do not really depend on the choice of language. You design it, then you break it in pieces, then you code them. I don't really like coding per se. After the design is done, it becomes a chore.

Sounds like you think that the Assembler code is inherently disorganized. That is not true. It depends on programming habits. One can write a very messy code in C, or one can write beatiful code in Assembler. These are just different ways to write programs. There are also compilers for Pascal, or for Basic.

MCU resources are limited, so whatever language you choose to use will not be a limitation (as it would be the case if I wanted to write an Assembler program for Windows). You choose what you feel is the best. I feel that for me, for writing a program for 16-bit PICs, Assembler is the best choice. That is not because I want to spend more time programming in Assembler, but because I want to do it as quickly and painlessly as possible. If MCUs get more powerful then the situation may change.

"C is not far from asm really. It is just more productive way to code it. I would even bet that most C compilers produce better ASM than average hobby asm coder.

Not far at all. It is just a different way to write the same thing. It is a good thing that there's a variety of languages to use.
 
Last edited:
Now, like you said, it doesn't really matter on MCU because you hard-code your register, memories, interrupts, DMA into your code. Once you do that, it is no longer portable.
That is only very small part of the code that is not portable (and asm has the same problem). I write my code in well defined modules.. and I have lots of them. They are ansi-c and therefore very portable. I have modules that do data-analysis, work with datastreams like message parsers etc. Then I have modules for different kind of sensors, motor controllers, PID controllers, Fixed Point math. Every module is usually one pair of .c and .h files. Even a small project is usually 20 files or so. Usually my main.c file is very short. I call the main-file, or the main-function, "The Composition Root". That is where everything is initialized and set to run.

C is very good with complex data structures. You can allocate structures, interlink them, walk through them. But, to allocate them you need a heap. For example, you need to build a binary tree with elements of varying size. You cannot do that without a heap. It is not practical on MCU, so you don't use it. Another advantage of C is lost.
I don't use heap to allocate memory for data-structures(or anything else). If I need a linked list, then I reserve an array of list elements according to "how many elements I need at most". That is much safer than allocating dynamically from heap. It is true that heap is not very practical on uC, but you don't need to use it. But, also, using heap with asm is just the same as using it in C. Absolutely no difference. So you can't say "Another advantage of C is lost".

No wonder people have problems with pointers. Without a heap, they don't have anything for the pointers to point to.
Another thing that shows how ignorant you are. That is just not true.

One can write a very messy code in C, or one can write beatiful code in Assembler.
True (also vice versa).
 
Last edited:
I think this debate has run it's course... We are talking about two separate items and trying to differentiate between them..

Of course we can't use a heap on little micro's... The last pic I used was a pic16f1828... 256bytes of data memory... Dynamic allocation is really only useful with RTOS's, where several tasks need to run... We can keep this going all year and get absolutely nowhere... If you want to program in C!! Good for you. If you want to program in C++! Well good for you too. If your project works go for it.... I don't care if you use pointers, placemats, binary indices, or whatever.

All I know is the name calling has started.... So If someone doesn't program the way you do, it doesn't make them ignorant!! If you want to use a shovel to knock nails in... Go for it...
 
I think this debate has run it's course... We are talking about two separate items and trying to differentiate between them..

Of course we can't use a heap on little micro's... The last pic I used was a pic16f1828... 256bytes of data memory... Dynamic allocation is really only useful with RTOS's, where several tasks need to run... We can keep this going all year and get absolutely nowhere... If you want to program in C!! Good for you. If you want to program in C++! Well good for you too. If your project works go for it.... I don't care if you use pointers, placemats, binary indices, or whatever.

All I know is the name calling has started.... So If someone doesn't program the way you do, it doesn't make them ignorant!! If you want to use a shovel to knock nails in... Go for it...

Talk about attacking forum members. Calm down. I enjoyed the debate. I know this same topic repeats itself twice a year, but still. Saying that somebody is ignorant is not "calling him names". I meant that he does not know what he is talking about. That's all. No need to be so aggressive.
 
I think this debate has run it's course... We are talking about two separate items and trying to differentiate between them..

Of course we can't use a heap on little micro's... The last pic I used was a pic16f1828... 256bytes of data memory... Dynamic allocation is really only useful with RTOS's, where several tasks need to run... We can keep this going all year and get absolutely nowhere... If you want to program in C!! Good for you. If you want to program in C++! Well good for you too. If your project works go for it.... I don't care if you use pointers, placemats, binary indices, or whatever.

All I know is the name calling has started.... So If someone doesn't program the way you do, it doesn't make them ignorant!! If you want to use a shovel to knock nails in... Go for it...

Actually I've been following this for sometime and hoping I would gleen some info out of it. I have often wondered the difference, this discussing could last for hrs and I would still enjoy it, feelings aside I'm learning something.

Thank you, Ian. You just never know what is actually taking place and it's better to step in before members go at it.

"misterT, would have to clear this up, if I'm completely wrong. But, maybe it's the way Finland, Norway, or Denmark handle discussions. I'm told they are very open minded, and I think this is way light compared to our understanding and there understanding of a discussion.

Talk about attacking forum members. Calm down. I enjoyed the debate. I know this same topic repeats itself twice a year, but still. Saying that somebody is ignorant is not "calling him names". I meant that he does not know what he is talking about. That's all. No need to be so aggressive.

I hope your not offended and will continue. I'm learning a lot, and will most likely re-read this several times.

Thank you, misterT and NorthGuy.
 
I hope your not offended and will continue. I'm learning a lot, and will most likely re-read this several times.

I'm not offended. Just wondering why Ian so aggressively is against this debate. The forum has been so boring for many months. Why can't we have fun here. Debates usually go on and on because the subjects are chosen that way, but a good debate is interesting. There is no point debating about something that is crystal clear and everybody agrees with each other. I could also debate what kind of meat-blend makes the best burgers.. maybe pointless, but maybe I would learn how to make very good burgers.
 
I would go further too. We almost reached the logical conclusion that the important thing is to follow good programming practices and think about what you're doing regardless of the langauage you program in, but because of MisterT's temperament we had to stop. Now there's no other resort for him than to go to the nearest ABC store and start buying different sorts of meat for buger testing ;)
 
I would go further too. We almost reached the logical conclusion that the important thing is to follow good programming practices and think about what you're doing regardless of the langauage you program in, but because of MisterT's temperament we had to stop. Now there's no other resort for him than to go to the nearest ABC store and start buying different sorts of meat for buger testing ;)

I didn't get upset or anything. It's just 3 am here in Finland.. have to sleep sometimes. I would like to here how asm programs are structured if done properly. I don't think I've seen any really well written asm programs here in the forum. Well, usually they are just code snippets.
 
I'm not offended. Just wondering why Ian so aggressively is against this debate.

I didn't see it, but "Ian" as mod, should stop things. Especially, something like the word "Ignorant" here in the U.S. especially in the South, it maybe taken you are "calling" someone stupid or dumb (Offensive)

In the past I can see this appearing aggressive to other people in my life, most people never understood me or my family. I have crossed the line without knowing before in my life.

Statements Like "Your Ignorant" In my family we are not a normal family we call each other stupid or dumb, we go past the line saying it. I don't even defend it if someone were to call one of them stupid, I might join them in saying it. We just laugh at each other though, it's not meant to be offensive it's just my way of getting through to them.

It happened this week between me and my brother. I said this and he said that and we carried on until I showed him what it really was and he didn't admit it, but with a grin didn't say anything more about it.

I see this "Statement" (Your Ignorant aren't you) interpreted as……...

You really don't know do you or You haven't the slightest clue? It's all in the way someone would take it.

I just want good burgers personally:p
 
I would like to here how asm programs are structured if done properly. I don't think I've seen any really well written asm programs here in the forum. Well, usually they are just code snippets.

Sounds like the start of a good "Thread"
 
Especially, something like the word "Ignorant" here in the U.S. especially in the South, it maybe taken you are "calling" someone stupid or dumb (Offensive)

Maybe in south yes. Because they are so ignorant they don't even know what the word means.

**broken link removed** ignorant
A term used by certain minorites to describe anyone who is pissing them off. Ironically, ask them what it means, and they won't have a clue. All you'll get as an answer is a clenched fist to the head (for being ignorant of course).

**broken link removed** ignorant
Adjective
Having the lack of knowledge, or background/factual information of a particular thing in general. However, the effect in which this person will be proceeding with their "unproven knowledge" imbedded in their mind as if factual information, they, in turn, will plan on using it in the future to make false and incorrect statements based on what they didn't know about the particular thing, or may have heard as a majority of votes for.

And being ignorant does not mean stupid. There's a big difference between the two words.
 
I didn't get upset or anything. It's just 3 am here in Finland.. have to sleep sometimes. I would like to here how asm programs are structured if done properly. I don't think I've seen any really well written asm programs here in the forum. Well, usually they are just code snippets.

Holy hell, don't you sleep? I would be a zombie without it.
 
I would like to here how asm programs are structured if done properly.

If Ian doesn't mind I will post an example. I don't really want to open a new thread for this.

Besides, MisterT expressedly said that he wants it here. :)
 
If Ian doesn't mind I will post an example. I don't really want to open a new thread for this.

Besides, MisterT expressedly said that he wants it here. :)

Haha.. yes. I think this thread is all over the place all ready. Maybe you can get the topic back to programming.
 
Status
Not open for further replies.

Latest threads

Back
Top