Where do I start if I want to learn larger architecthre "C" uC programming?

[DaveHardy]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.

A visit to the Microchip website is total chaos.  There's links everywhere and I don't think that half of the Microchip staff knows what the other half is doing.  I did a search for the Hi-Tec C compiler and it appears that Microchip absorbed them somehow.  Whatever happened to the Hi-Tec C kinda reminds me of the movie the blob.

Atmel confuses me too.  They have some sort of open source thing going on but I can't figure out how to get started.  I guess that I'm scared because Dave did a video saying that I need to be the Linux penguin to figure out how to set up the workspace properly.   Also, Atmel stuff is getting a lot more expensive.

What do you guys think of the mikroC free or starter compiler?  It looks like a good place to start and it appears straightforward enough. 

-Dave

[westfw]

Get an Arduino, ignore the extensive easy-to-use libraries and numerous examples of neat applications, and start writing away.  Arduino uses gcc (C and C++) "under it's hood", and you won't find an easier to download and install environment, or a cheaper development board.
Your choice of 8bit (Atmel AVR: Uno, MEGA, Leonardo), 16bit (MSP430 using "Energia"), or 32bit (Due, Teensy 3, Tiva Launchpad (using Energia), PIC32 (ChipKit - using MPIDE))
The editor is minimalist to the point of being primitive and annoying, but the "use external editor" preference works surprisingly well.
And you won't get a debugger or simulator.  When you get to the point where you need those, you can upgrade to the next level of tool.

[Kremmen]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.
[...]
Atmel confuses me too.  They have some sort of open source thing going on but I can't figure out how to get started.  I guess that I'm scared because Dave did a video saying that I need to be the Linux penguin to figure out how to set up the workspace properly.   Also, Atmel stuff is getting a lot more expensive.
[...]
-Dave

Linux penguin for Atmel? Naah. I do Atmel stuff all the time and while i have nothing against Linux and have several boxes around running stuff, i do all my Atmel development on Windoze. That includes the lowly Arduinos, a bunch of 8 bit and 16 bit stuff (the XMega), and Atmel's SAM series Cortex ARMs.
You just download the Atmel Studio 6.2 (free) and start hacking away. Mind you, you do need some way of downloading the binaries and eventually for debugging your brain children, but that applies for all environments. The JTAGICE 3 from Atmel is not terribly expensive, or you could go for the Segger J-link debugger. Works like a charm for the ARMs (not only Atmel's) and there is a more reasonably priced non-commercially licensed version of the thing. Those tools will get you a _long_ way; in fact all the way for Atmel chips.

[AndyC_772]

All you need to know about Microchip for now is this:

- the current, supported IDE is MPLABX. Download it here.

- the C compilers are XC8 for 8 bit devices, XC16 for 16 bit, and XC32 for 32 bit. Download the free versions of any of them here, and install after you've installed MPLABX.

- ignore everybody who bitches and whines that the free compilers don't optimise. So what? You're learning the language, not trying to squeeze every last bit of performance out of a device. I've only needed optimisation for one design out of a dozen or so I've done over the last few years.

- my current favourite range of devices is the PIC18FxxK22 family. All you need to get started is a breadboard with a PIC18F26K22, programming header (6 pin 0.1in), a decoupling capacitor and a pull-up resistor on MCLR.

- Once you've started a new project in MPLABX, go to Window > PIC Memory Views > Configuration bits. Here you can set all the configuration bits for the device from a series of drop-down menus, then click 'Generate source code to output'. Copy and paste this code into your project, and all the chip's configuration bits are done. (I always put this lot into a header file called config.h and then #include it).

Other things you need to do in your project are:

- #include <xc.h> at the start of your main.c file, and any others which refer to device registers

- Set OSCCON to specify the clock source and speed that you want the chip to run at

- Set the ANSEL and TRIS bits for any pins you want to use as digital I/O

- Read inputs from PORT registers, but write outputs to LAT registers.

- You can access individual bits in registers by name, rather than having to write the whole register at a time. So, for example, you can turn on an LED connected to pin RA6 by writing LATAbits.LATA6 = 1. This register naming convention is used throughout.

- READ THE ERRATA for any PIC you're considering using. There are some absolute howlers which you really, really do need to know about.

[Monkeh]

Get an Arduino, ignore the extensive easy-to-use libraries and numerous examples of neat applications, and start writing away.  Arduino uses gcc (C and C++) "under it's hood", and you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment.

And you won't get a debugger or simulator.  When you get to the point where you need those, you can upgrade to the next level of tool.

Start with the Launchpad and you get the debugger in the bargain!

[gocemk]

If you go with MPLABX, it has excellent templates for creating a new project. When you create new project, just go to Samples->Microchip Embedded, and there you will find templates for all PIC families + the Explorer and PICDEM boards. It will create all the necessary files like main.c, interrupts.c ... all with comments where to put the code and etc. It will also create "getting_started.txt" file in your project tree which will get you started step by step on how to set the config bits and etc... If you are using different chip from the one in the template (e.g the template is for PIC18F45K22 and you are using PIC18F4550), just right click on the project->Properties. Then in the upper right corner under "Device:" choose the PIC that you are using from the drop-down menu, click Apply or OK, and you are good to go.

Hope this helps getting you started with programming PIC's in C.

[hans]

I believe the mikroC compiler Free has a size limitation. That can get annoying, because suddenly you run out of luck.

Personally I would pick optimize constraints > size constraints - so I would pick the XC8/16/32 compiler. They work well and integrate into MPLAB X or MPLAB IDE. In that case you just need 1 IDE ranging from 8-pin PIC10s to 100 pin PIC32s.
Here are all the downloads grouped together : http://www.microchip.com/pagehandler/en-us/family/mplabx/
(Design Support -> MPLAB X -> Download)

As for a chip, the PIC18 K series are nice to start with.
If you're looking for a bit more C-optimized platform you could look at the PIC24 or PIC32 series (16/32-bit chips). If it matters; they have chips in DIP packages, but the biggest are only "only" 28-PDIP size. For example; PIC32MX1xx and PIC32MX2xx chips have some DIP versions, and the PIC24 has some DIP versions scattered around.

[dannyf]

For 32bit devices, I use coide: free and excellent wizard. Limited support for new chips. Other options are keil for its rte, or iar for its ui.

between avr or pic I would go with avr. Code blocks plus gcc avr is a great combination.

[AndyC_772]

If you want to learn an ARM based family - and that's certainly a good idea IMHO - then I'd also suggest Rowley CrossWorks for ARM, which is a commercial package but with a deeply discounted 'personal' licence option.

[nctnico]

IMHO the best way to learn C is to start programming simple stuff on a PC. Whether you use Eclipse or Visual Studio personal edition you'll have an excellent debugger to trace what your code is doing. I still write a lot of microcontroller code on the PC first just to be able to debug & test it quickly.

edit: typo

[Paul Price]

I used to use the legacy Microsoft Visual C+ Ver 6.0 for debugging pieces of code. Can be simple to use for this purpose.

[Lukas]

The STM32F4 series eval boards (STM32F4DISCOVERY and STM32F429I-DISCO) provide really good bang-per-buck. Full-featured debugger on board, very good support from the gnu toolchain (arm-none-eabi target)

[DaveHardy]

Wow, thanks for the help guys.  There's lots of stuff to digest here.  I'm going to get started now and report back.

[dannyf]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

[IanB]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

Can you elaborate? What kind of challenges does a 32 bit chip introduce?

In a historical context, the move from 8/16 bit processors to 32 bit processors removed many impediments and made programming much easier.

[true]

Depending on your knowledge of the chips and your approach, going from 8-bit to a 32-bit chip can be quite challenging for a new comer, and in my view, requires a different way to programming.

Can you elaborate? What kind of challenges does a 32 bit chip introduce?

In a historical context, the move from 8/16 bit processors to 32 bit processors removed many impediments and made programming much easier.

It's not so much 32-bitness of the chips, but rather the complexity and connectivity of the peripherals and setting up the core.

Compare setting up standard GPIOs on an attiny with setting up GPIOs on an STM32 using ST's libraries. Neither is hard, but ST is certainly more involved, though much more powerful. Get to more involved things, like setting up i2c or other peripherals, and it isn't necessarily "easier"

[westfw]

For example, on an 8-bit AVR, for a GPIO port you have the Data-direction register, the PIN register (for input), and the PORT register (for output.)
On a Tiva CortexM4 chip, you have about 40 registers for each GPIO port  :-) (Not counting the 256 addresses used to achieve bitwise access.  Which is separate than bit-banding, which does single-bit access.  Obviously!)

(no, that's not a fair comparison, because the 40 registers include things like alternate function select and interrupt control that are handled "differently" on the AVR.  But that's how it will feel.
A better comparison is probably that the Atmega1280 manual is about 500 pages, while the Tiva TMC123GH6PM is about 1500 pages (i'd rate the manuals as "comparable" as to completeness of content.))

(Oh, and don't forget that the TI GPIO ports are completely different from the ST GPIO ports!)

(And did I mention that you'll be encouraged to implement things through a series of library calls that are pretty good at preventing you from ever figuring out how things actually work.

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    MAP_GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_1);

(pretty much as bad as Arduino libraries, IMO. (only the names are worse!)))

(Not that this sort of "peripheral complexity" isn't slipping down into 8bit parts as well.)

[westfw]

   you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment. [and they come with debuggers!]

Well, I'll give you "cheaper", if you neglect Arduino clones (and you probably should.)  But I was one of the people who waiting months for my first launchpad :-) (yes, they've gotten better.)  And I'll stand by "easier download/install": the Tiva launchpad tutorial has you downloading and installing stuff from all over the place, with "Open your launchpad box" being somewhere around step 25. (http://software-dl.ti.com/trainingTTO/trainingTTO_public_sw/GSW-TM4C123G-LaunchPad/TM4C123G_LaunchPad_Workshop_Workbook.pdf )  (You can avoid this by using the Arduino-compatable Energia IDE instead, but you're back to no debugger.)

[janoc]

I'm interested in learning how to program 32 bit microcontrollers or perhaps a PIC18 if it is a better place to start.  I've programmed 8 bit microcontrollers in ASM for a while and feel that I'm ready to start learning the C language and bigger architectures.

If you have never programmed in C before, then, please, do yourself a big favour and forget the micros for a while. Go, get a book on C and a desktop compiler (Visual C++, gcc, mingw, what have you) and learn the language there first.

Learning C and debugging code on a microcontroller is way harder - e.g. if you mess up (and you will mess up, trust me) with pointers and overwrite stack, on the PC the application will most often simply crash, with the debugger pointing you to the place where the problem happened. A micro will happily overwrite its RAM and good luck trying to figure out what is going on there, even if you have debugger connected. Not to mention the various idiosyncrasies like linker scripts, memory layout and what not that you have on the microcontrollers.

Microcontrollers are not the best place to learn a new programming language.

[dannyf]

learn the language there first.

Agreed. It makes sense to have a good mastery of C if you want to program in it.

Not to mention the various idiosyncrasies like linker scripts, memory layout and what not that you have on the microcontrollers.

Mostly transparent for you. I wouldn't worry about any of them for now.

Microcontrollers are not the best place to learn a new programming language.

Agreed.

[nctnico]

I disagree. One of the major improvements of C++ is that you can pass variables by reference. This reduces the chance on making errors with pointers.

[Monkeh]

   you won't find an easier to download and install environment, or a cheaper development board.

Sure you will: A Launchpad is cheaper than a cloned Arduino, and arrives faster. Or a Cypress PSoC4 at the moment. [and they come with debuggers!]

Well, I'll give you "cheaper", if you neglect Arduino clones (and you probably should.)  But I was one of the people who waiting months for my first launchpad :-) (yes, they've gotten better.)

Well, a full size Uno clone is much the same price as a basic Launchpad, with so much less to offer (we'll ignore the wide range of badly designed 'shields') Once you look at the F5529 you never look back. Much nicer hardware documentation IMO, too.

And I'll stand by "easier download/install": the Tiva launchpad tutorial has you downloading and installing stuff from all over the place, with "Open your launchpad box" being somewhere around step 25. (http://software-dl.ti.com/trainingTTO/trainingTTO_public_sw/GSW-TM4C123G-LaunchPad/TM4C123G_LaunchPad_Workshop_Workbook.pdf )  (You can avoid this by using the Arduino-compatable Energia IDE instead, but you're back to no debugger.)

I'll give you that, installing and learning a real IDE is more involved than the click and go approach of the Wiring framework.

[Gall]

C first, C++ later.

Probably the best way to learn C is to learn C on a PC first. The uC is exactly the same, just smaller and without printf(). Usually no malloc() as well.

C++ is a good thing even for microcontrollers provided that you deeply inderstand templates and know how to avoid useless copies of variables. This is of course not in C++ 101. Learn C++ on a PC and go to uC later.

[nctnico]

C first, C++ later.

Probably the best way to learn C is to learn C on a PC first. The uC is exactly the same, just smaller and without printf(). Usually no malloc() as well.

You can have malloc if you need it. Just make sure you have proper memory bounds checks. And be smart: don't try to avoid printf otherwise you'll be writing your own string conversion and printing routines which are bulkier and worse than printf. If printf turns out to pull in too much extra junk just write a minimalist printf (google will show you how).

@Mojo-chan: pointers are a major source of erros in C code so it is better to avoid them if you can.

[bwat]

I've been writing C code since the mid to late 80s and they way we learned it back then still works today.

1) Get yourself a copy of [K&R] and a machine that boots a *nix variant. I say *nix and not Windows because the book sort of assumes you'll be compiling on *nix - if you've heard of the authors then you'll know why. Anyway, Linux or one of the BSDs, or even OSX will give you all the tools you need for pretty much free. You could do it with Windows but it's a little extra work at the beginning and, well, C and *nix go together like strawberries and cream. Once you've finished the book you'll be able get going with embedded platforms in no time at all.

2) Do not avoid pointers like someone suggested. People who have problems with pointers are people who haven't learned how to use them properly! You have an assembly background and as someone else pointed out, this'll give you an easier time learning about pointers.
 
[K&R] Brian W. Kerninghan, Dennis M. Ritchie, The C Programming Language, 2nd Edition. Prentice Hal, 1988.

[nctnico]

2) Do not avoid pointers like someone suggested.

I guess some people still drive around with the model-T Ford... Which is OK if you want to casually drive around but if you need something reliable for your daily commute there are better options. Same goes for pointers. They are an integral part of C but that doesn't mean using them is good coding practise. Properly written software validates a pointer before using it. Even experienced programmers shoot themselves in the foot with pointers every now and then.

[bwat]

Same goes for pointers. They are an integral part of C but that doesn't mean using them is good coding practise. ...
Even experienced programmers shoot themselves in the foot with pointers every now and then.

So experienced programmers are not employing your idea of "good coding practice"?

I can only speak as someone who has been a professional C programmer since 1996. Every single product I've worked on has been written in C which made heavy use of pointers.

Properly written software validates a pointer before using it.

This is demonstrably false. There are plenty of examples of perfectly good C which contradict your statement.

[dannyf]

-Every single product I've worked on has been written in C which made heavy use of pointers. -

the same here. A piece of c without pointers is almost unthinkable, unless you are an absolute newbie working on a blinky.

-this is demonstrably false. There are plenty of examples of perfectly good C which contradict your statement. -

she or he likely was using a unique definition of validation.

as to k&r, I think it's a must read but not sufficient. Good individual pieces of code may not work together seamlessly. This is where firms publish coding guidelines and use libraries to enforce coding standards. This is like industrilized code production vs. Mom and pop code production.

that trend towards stylized coding is more keen as you move to bigger and more powerful chips.

[bwat]

Good individual pieces of code may not work together seamlessly.

I think you've brought up an interesting topic. As far as I'm concerned, the biggest difference between a beginner and an experienced programmer is the ability to

1) get the small routines working together,
2) make this happen in as pleasant a way as possible (understandable, clean design).

You're right when you say that K&R wont teach this. I think it's too much to ask from a book. Instead you should probably be creating programs from scratch that end up in the >= 10KLOC range. That's what I reckon anyway.

[dannyf]

Agreed. I would add that as experience grows, your ability to divide a project into well defined modules that in the end will work together becomes far more valuable than your ability to code individual modules correctly and beautifully.

#2 is far easier to achieve than #1 above.

[mrflibble]

Getting that #2 clean design right is a big step towards that #1 where all your small routines work together correctly.

[nctnico]

They are an integral part of C but that doesn't mean using them is good coding practise.

Do you don't recommend using arrays in C? Or passing pointers to variables so functions can modify them?

I don't think you understand pointers, which is why you fear them.

Please play the ball not the man. I have a perfect understanding of pointers. But I also have a perfect understanding of their dangers which is why I recommend using C++ where you can pass variables by reference instead of a pointer.

Say you have this C function:
do_something(int in1, int *out1, int *out2)
If someone calls that with do_something(1, NULL, &a) that may break if do_something doesn't check the pointers.

In C++:
do_something(int in1, int &out1, int &out2)
If someone calls that with do_something(1, NULL, a) it won't compile.

See the difference? The second form is easier because you don't have to worry someone calling do_something with an invalid pointer (*). If a large piece of software consists of many modules there is always a chance someone tries to call a function in a way that has not been forseen.

(*) It is good coding practise to check boundaries of function parameters especially if a function is visible to other modules in a piece of software. It helps to compartmentalize the software and prevents errors from causing a cascade of weird behaviour.

[dannyf]

I have a perfect understanding of pointers.

"I am not drunk.... I...I...I am NOT...not drun...k...."

"I can still do it...."

"I am not a criminal!"

Lots of similarities here.

[bwat]

Please play the ball not the man. I have a perfect understanding of pointers. But I also have a perfect understanding of their dangers which is why I recommend using C++ where you can pass variables by reference instead of a pointer.

I'm not so sure you do understand pointers. A pointer is just an address. If I've got an 8-bit  register mapped at address 0x1234 then I want to be able to write

Code: [Select]

  char *reg;
  ...
  reg = 0x1234;
  ...
  data = *reg;
Wth your perfect understanding you may see danger. Me, I see no problems whatsoever. 

[dannyf]

I see no problems whatsoever. 

I am in the same camp, due to, I think, our less-than-perfect understanding of pointers.

[TimMcDonald]

The big issue isn't word size having larger words just makes things easier where the difficulty comes from is more advanced features such as peripherals with DMA and pipelining . I personally find programming AVR to be easier in assembly were I can see what every clock cycle and is doing and I understand how data types other than bytes are being implemented because I chose the implementation, these MCUs have very limited RAM and I like to know exactly how things are being done. By contrast programming a PIC32 in assembly is wizard level stuff and I would use a language like C and standard libraries to get stuff done. Programming in Arduino style C on any MCU should be only easier as the MCU's get more powerful on the on other hand if you want to leverage the feature sets of more advanced MCU's be prepared to do a lot of research that isn't necessarily going to transfer to other platforms.

[dannyf]

if you want to leverage the feature sets of more advanced MCU's be prepared to do a lot of research that isn't necessarily going to transfer to other platforms.

If you get into the weeds and want to take advantage of a particular feature of the peripherals on a mcu, yes, it is unlikely to be portable to another chip with a different feature set.

On the flip side, you can certainly install a layer that implements a common set of features across a wide range of chips. end of the day, a timer is a timer and a nvic is a nvic.

All in the approaches / implementation.

[nctnico]

I've seen this sort of thing countless times, and the function itself is always half baked. By hand-holding through these kinds of issues it just encourages sloppy programming and a lack of proper understanding.

That sounds rather elitist 
What happens when a deadline approaches quickly? Do you add pointer checking or work on code which finishes the project on time? By avoiding error prone constructs you don't need to add checks so you can have the project finished on time AND sleep well that night.

[bwat]

I've seen this sort of thing countless times, and the function itself is always half baked. By hand-holding through these kinds of issues it just encourages sloppy programming and a lack of proper understanding.

That sounds rather elitist 

It seems to me that Mojo-chan is promoting "proper understanding". Labelling those with higher standards than your own as "elitist" only means you would rather see people dragged down than lifted up.  I choose to work for proper understanding and embetterment for myself and for others where I can - it's the positive thing to do.

By avoiding error prone constructs you don't need to add checks so you can have the project finished on time AND sleep well that night.

Do you also avoid integer division?

[dannyf]

"proper understanding"

How can you have an understanding more proper than "perfect understanding"?

[andyturk]

Say you have this C function:
do_something(int in1, int *out1, int *out2)
If someone calls that with do_something(1, NULL, &a) that may break if do_something doesn't check the pointers.

This is a rather poor example. The real problem is a lack of checking in do_something(). If you can't even manage that, what are the chances that do_something() doesn't contain other issues?

I'd argue that nctnico's position (and his example) are reasonable. Given that with C++ you have the choice to use references or pointers to pass a arguments indirectly, which technique should you choose? I mean, what kind of thought process do you go through as an API designer?

IMO, if an argument is being passed indirectly but can *never* be NULL, then the argument should generally be passed by reference, not pointer. Doing this basically pushes the NULL-checking code that you'd write inside the function back out to the compiler. It also means you don't need to check for that particular error at runtime, proving a (small) savings of execution time and code space.

I've seen this sort of thing countless times, and the function itself is always half baked. By hand-holding through these kinds of issues it just encourages sloppy programming and a lack of proper understanding.

... grumble, grumble ... Get off my lawn!
 

[andyturk]

It seems to me that Mojo-chan is promoting "proper understanding". Labelling those with higher standards than your own as "elitist" only means you would rather see people dragged down than lifted up.  I choose to work for proper understanding and embetterment for myself and for others where I can - it's the positive thing to do.

[nctnico]

I've seen this sort of thing countless times, and the function itself is always half baked. By hand-holding through these kinds of issues it just encourages sloppy programming and a lack of proper understanding.

That sounds rather elitist 

It seems to me that Mojo-chan is promoting "proper understanding". Labelling those with higher standards than your own as "elitist" only means you would rather see people dragged down than lifted up.  I choose to work for proper understanding and embetterment for myself and for others where I can - it's the positive thing to do.

Maybe but throwing a novice into the deep doesn't help him/her or you. I like to keep my software simple and elegant so other people can maintain it. I often explain more complex constructs in the remarks. You can call that lowering the bar; I call it making sure I'm not stuck with my old projects forever. With less and less time spend on C/C++ on universities you can't expect to find a gifted C/C++ programmer around the corner or fresh from school.

By avoiding error prone constructs you don't need to add checks so you can have the project finished on time AND sleep well that night.

Do you also avoid integer division?

In most cases I do like to construct divisions in a way that avoids division by zero or have protection against division by 0.

[westfw]

you recommend avoiding pointers

I thought it was pretty clear from the first message on the sub-subject that he was talking about using pointers so that functions could (essentially) return multiple simple values; the traditional "swap(a, b);"
I don't know: having control of whether a function parameter can be modified by a called function be in control of the called function makes  me nervous (I rewrote 0 once, back in ForTran.)
OTOH, pointers to complex objects get passed around all the time, and it's "not unexpected" for functions to modify their contents.

It's not clear to me that a modern desktop C programming class will teach you C that is useful in embedded microcontrollers.  Too many dekstop programming classes focus on how to use the GUI libraries available, to create "normal looking" desktop applications.

[SirNick]

What happens when a deadline approaches quickly? Do you add pointer checking or work on code which finishes the project on time? By avoiding error prone constructs you don't need to add checks so you can have the project finished on time AND sleep well that night.

This reminds me of that time in 2005, when I was working on a project that slipped past its deadline for having to write:

Code: [Select]

if (param2 == NULL) return XXX;
If only we were using C++   

No.  I've heard pointless debates like this too many times.  Coding is a skilled task.  You're always running late, people always make mistakes, software always has bugs.

Code: [Select]

10  That is life.
20  Get over it.
If you avoid the unchecked-NULL-pointer bug, you get caught by overflowing integers or any of a million other unpreventable pitfalls caused by an imperfect human typing in instructions for an unintelligent computer to interpret.

You hear the same nonsense about avoiding goto at all costs, or using { braces } for one-line conditionals, or using constants first in comparisons.  Yes, certain practices will potentially help avoid certain problems, but nothing will save untested code written by someone momentarily asleep at their keyboard.  That is a sickness for which there is no cure.

Ugh.  I'm grumpy today.   

[bwat]

you recommend avoiding pointers

I thought it was pretty clear from the first message on the sub-subject that he was talking about using pointers so that functions could (essentially) return multiple simple values; the traditional "swap(a, b);"

This is part of the problem. Your mental model describes it in terms of returning multiple values. This model is wrong as at most one value is returned and the others are  stores to memory. Now, I know you this because you qualified your description with "(essentially)". Why do you explain it like that to yourself? We must stop trying to simplify the problem to suit our frame of reference and instead widen our frame of reference to suit the problem. Please don't think I'm attacking you. I catch myself doing things like this as well. I think we all do it. But we can't operate with inaccurate models in our heads and expect to write correct implementations of our designs.

I don't know: having control of whether a function parameter can be modified by a called function be in control of the called function makes  me nervous (I rewrote 0 once, back in ForTran.)

It's like the old Smalltalk joke of Processor := nil. Anyway, the parameter isn't being modified as you say. The parameter is an address. The contents of the address in memory is the thing being modified. But again you know this is what is actually happening because you go on to write:

OTOH, pointers to complex objects get passed around all the time, and it's "not unexpected" for functions to modify their contents.

Exactly!

It's not clear to me that a modern desktop C programming class will teach you C that is useful in embedded microcontrollers.  Too many dekstop programming classes focus on how to use the GUI libraries available, to create "normal looking" desktop applications.

I think it's a lack of a good grounding in assembly language. Many in my generation started with 8-bit assembly (6502 in my case), then 16-bit assembly (68000). By the time we had 16-bit machines we started to hear about this language C. Pointers aren't a problem for an assembly language programmer.

[Kjelt]

The real problem is a lack of checking in do_something(). If you can't even manage that, what are the chances that do_something() doesn't contain other issues?

Yeah in utopia you are right but we are not in utopia. Are you perhaps a 21st century programmer only used of having >32kB Rom sizes or what?
In real life, with real products with real companies we have embedded products with controllers having 4kB or 8kB ROM and sometimes as little as 128 bytes of RAM (in the past it was even worse but this is a product we did last year) just because the endproduct BOM has to be low (with a million products each dime saves you 100k).
In that real world we do not check all parameters of functions because we don't have that luxury.
Yes I know each book tells you should do it and also do boundary checking etc.  but if you don't have the room you don't   can't do it, period.
And this means testing, testing, testing and testing before shipping.

[Kjelt]

If you can't manage to debug such a small project and handle reading the comments before supplying a parameter as NULL (most IDEs will now display the comments along side the function prototype automatically) then you need to find a new job.

Who said that, not me. I just responded to your black/white theoretical statement that in a theoretically perfect world every parameter should be checked. We do not live in a perfect world, and I bet that if I would review your code for a constrained device it would also not be perfect so welcome to reality. Try to read a post first before you give a bs answer.

[mrflibble]

I have yet to find a compiler that throws up an error with this code, for example:

Code: [Select]

int* p() {
    return 0;
}
void x(int& y) {
  y = 1;
}
int main() {
   x(*p);
}

g++ must_resist_all_change_O_O.cpp
must_resist_all_change_O_O.cpp: In function ‘int main()’:
must_resist_all_change_O_O.cpp:10: error: invalid initialization of non-const reference of type ‘int&’ from a temporary of type ‘int* (*)()’
must_resist_all_change_O_O.cpp:6: error: in passing argument 1 of ‘void x(int&)’

gcc version 4.4.5. You're welcome.

More over I don't use C++ for embedded stuff anyway, there are just too many problems and it doesn't really offer any useful advantages.

Yes, you have voiced your opinion on C++ for embedded a few times. But luckily your experiences with C++ for embedded are not representative of the reality some of us encounter. You know, the reality where C++ is quite useful on embedded. But whatever, to each their own. You're happy with C, so stick with that. I'm happy with using C++ as well.

[dannyf]

gcc version 4.4.5. You're welcome.

Nice done to that "expertly" written piece of s...., I mean, code.

[BloodyCactus]

I used to be very anti c++ on embedded, like whoa dude c++ on embedded no way man, step off the bus!! then I found this arduino thing and this 8bit chip had like 1 byte ram and 4 bytes stack and 16kb rom for code... and arduino does it all in c++.. whoa.

everyone started churning out huge shitty c++ sketches on massively constrained shitty 8bit ateml chips. it opened my eyes really. I'm a C guy at heart, and no interest in doing c++ on my stuff at all.  To me, it certainly was an eye opener, but not a road I'll be going down.

I went from non believer to, wow, people can really use c++ on tiny tiny devices.

[baljemmett]

Interesting, I wonder when they fixed that. Last time I tried it was a couple of years ago.

No - if any of the various participants in this pointless willy-waving exercise had bothered reading the code and error message for comprehension, it would become apparent that you almost certainly simply forgot the () on the invocation of p.  It's failing to coerce a function pointer to int&, not demonstrating the problem you presumably had in mind given the context (that the returned pointer can be coerced into a reference even if it is NULL.)

[andyturk]

No - if any of the various participants in this pointless willy-waving exercise had bothered reading the code and error message for comprehension, it would become apparent that you almost certainly simply forgot the () on the invocation of p.  It's failing to coerce a function pointer to int&, not demonstrating the problem you presumably had in mind given the context (that the returned pointer can be coerced into a reference even if it is NULL.)

Ha! Good catch!

But I think mojo-chan won't ever find a C/C++ compiler that will flag an error for what he's trying to demonstrate. 0 is an acceptable value for any pointer type, so returning 0 from p() shouldn't ever generate an error at compile time. The bug here is the code in (the corrected) main(), which dereferences a pointer without knowing (or checking first) that it's not 0.

Code: [Select]

int main() {
   x(*p());
}