Programming Tips for C/C++

shop deals on amazon
Wildman Rocketry
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
JohnCoker said:
All languages have plusses and minuses based on the historical period and goals of the developers. C is best thought of as "portable assembler" because it provides only trivial services and abstractions above the machine layer. Because of that, it's the simplest language to write a compiler for and provides the most scope for programmers to micro-optimize.

For large-scale software projects with multiple developers working over years C is a bad choice, but for tasks like this it is well-suited. It's quite easy to learn, although there are a few gotchas that bite people new to the language, mostly because it is so low-level.
Click to expand...

I've heard some folks call C "glorified assembler". I'm not sure I agree with that, but if the header files weren't written for you by the compiler, it wouldn't be too far off. At least compared to the new visual and OOP languages.
 
Cross posted from the "What did you do rocketwise today?" Thread:

I wrote my first 'real' program in ANSI C today. It is a basic rocket numerical simulation software. It is limited for now and the simulation is not accurate, but is a fun project to put my brand new C skills at use :)

I will work some more on it to make it a decent simulation (don't expect graphics here) and will share it on GitHub to get feedback and ideas for improvements. This should help me hone these newly acquired skills.
 
I just created this GitHub repo to contain the code of my Lawn Dart C program.

As stated there, it is still very basic but hey, it's my first C project!
 
morlock said:
I just created this GitHub repo to contain the code of my Lawn Dart C program.

As stated there, it is still very basic but hey, it's my first C project!
Click to expand...

A little note regarding one of the pitfalls of C that I noticed after taking a look. C is very literal regarding literals :eyeroll:. A number that looks like an integer will be considered an integer even if you intend to use it as a floating point number. Often, this will result in an automatic conversion and you can get away with it, but this this should not be relied on. To prevent this, you can use the proper floating point literals, to make sure the program behaves as intended.

Here are two examples from your code, where the compiler is automatically able to convert to the right data type.
Code: 
double max_altitude = 0;
// ...
if (counter % (int) (1 / delta_t) == 0) {
// ...

This way removes any ambiguity (note the appended ".0")
Code: 
double max_altitude = 0.0;
// ...
if (counter % (int) (1.0 / delta_t) == 0) {
// ...

Here are some examples that demonstrate the differences:
https://codepad.org/qLFFCJFV

The "extra wrong" example also demonstrates the low level nature of C. The compiler will accept this mismatch between format string and the provided data type. printf will interpret the data as told, which will result in undefined behavor, if for example a 4 Byte integer gets written to memory, but 8 Bytes get read and interpreted as floating point value.

Reinhard
 
Last edited:
Thanks for looking at the code and for the advice about the number types. I'm trying to be prudent about it but it helps to have specific examples.

The simulation is slowly getting better. Anyway, I'm having fun and that's what programming should be about :) Plus, it's a perfect project for my level and to learn more.

Next steps are parsing the parameters properly, using the motor files from www.thrustcurve.org and putting the info into arrays of structs with time and thrust values.
 
Last edited:
There's another common gotcha that you might run into: the difference between char* and char[]. Normally, the compiler will take care of this in the same file, but when using extern declarations it doesn't know. (An array is the memory location of the first value while a pointer is the memory location of the pointer itself.)

Actually, this is a really good example and once you understand the difference, you will be well on your way to understanding pointers, which is what C is all about.
 
I'm a C#.Net guy. Would go with C++. C sounds painful to me. I did a little bit at my first job. C++ in college 16 years ago.

Choosing between C and C++ for the arduino would depend on which had the most sample code I could use. If they were both equal, C++ - no contest.
 
cavecentral said:
I'm a C#.Net guy. Would go with C++. C sounds painful to me. I did a little bit at my first job. C++ in college 16 years ago.

Choosing between C and C++ for the arduino would depend on which had the most sample code I could use. If they were both equal, C++ - no contest.
Click to expand...

The other issue you have to consider, especially with embedded controllers is memory space. A program that will compile to <10Kb in C will probably be >100Kb in C++ because of all the extra OOP overhead C++ adds. I'm not familiar enough with the compiler controls available in C++ today to know if you can reduce the compiled size a lot now, but when C++ first came out, it was a no-go for the embedded apps guys because of the huge compiled file sizes. Of course in those days I was still programming 8 and 16 bit embedded controllers with PL/M and loading the programs into 8Kb & 16Kb EEPROMS. Some of the boards used ODD & EVEN interlaced memory with 2 slots each so we could get 64Kb of program stored.
 
Handeman said:
The other issue you have to consider, especially with embedded controllers is memory space. A program that will compile to <10Kb in C will probably be >100Kb in C++ because of all the extra OOP overhead C++ adds. I'm not familiar enough with the compiler controls available in C++ today to know if you can reduce the compiled size a lot now, but when C++ first came out, it was a no-go for the embedded apps guys because of the huge compiled file sizes. Of course in those days I was still programming 8 and 16 bit embedded controllers with PL/M and loading the programs into 8Kb & 16Kb EEPROMS. Some of the boards used ODD & EVEN interlaced memory with 2 slots each so we could get 64Kb of program stored.
Click to expand...

Yeah, I know there is limited resources. Didn't use C++/C enough for that level of knowledge to compare binaries. I know C++ is easier to work with if all else is the same.
 
Handeman said:
The other issue you have to consider, especially with embedded controllers is memory space. A program that will compile to <10Kb in C will probably be >100Kb in C++ because of all the extra OOP overhead C++ adds. I'm not familiar enough with the compiler controls available in C++ today to know if you can reduce the compiled size a lot now, but when C++ first came out, it was a no-go for the embedded apps guys because of the huge compiled file sizes. Of course in those days I was still programming 8 and 16 bit embedded controllers with PL/M and loading the programs into 8Kb & 16Kb EEPROMS. Some of the boards used ODD & EVEN interlaced memory with 2 slots each so we could get 64Kb of program stored.
Click to expand...
These days, a high quality C++ compiler can generate very compact and efficient code, if used properly (among other things, avoiding RTTI & exception handling). There are now embedded C++ standards that also help. I use it daily on a number of real-time embedded products. There are limits, of course. I wouldn't use it for an 8-bit CPU with 8K of RAM, but I wouldn't hesitate on a single-chip Cortex-M3 with 128K of RAM. Except in extreme cost sensitive applications, a current 32-bit ARM single-chip MPU can fit the cost, size, & power budgets of just about any small embedded project. As little as $1 for a 32-bit CPU!
 
You may want to consider the Parallax Propeller chip. It contains 8 32-bit processors that share 32K of RAM. Typically, the main program runs on 1 processor, and the other 7 are used for device drivers running protocols such as serial, SPI, I2C or PWM. I'm also working on a rocket with active stabilization. I'm using the HoverFly board that's a 9DOF board with 3D gyro, accelerometer and magnetic sensor chips.

The Parallax site is located at https://parallax.com . They have tutorials for learning C at https://learn.parallax.com and there is great forum support available at https://forums.parallax.com .
 
DaveHein said:
You may want to consider the Parallax Propeller chip. It contains 8 32-bit processors that share 32K of RAM. Typically, the main program runs on 1 processor, and the other 7 are used for device drivers running protocols such as serial, SPI, I2C or PWM. I'm also working on a rocket with active stabilization. I'm using the HoverFly board that's a 9DOF board with 3D gyro, accelerometer and magnetic sensor chips.

The Parallax site is located at https://parallax.com . They have tutorials for learning C at https://learn.parallax.com and there is great forum support available at https://forums.parallax.com .
Click to expand...

Thanks, I'll look into that.
 
dpower said:
These days, a high quality C++ compiler can generate very compact and efficient code, if used properly (among other things, avoiding RTTI & exception handling). There are now embedded C++ standards that also help. I use it daily on a number of real-time embedded products. There are limits, of course. I wouldn't use it for an 8-bit CPU with 8K of RAM, but I wouldn't hesitate on a single-chip Cortex-M3 with 128K of RAM. Except in extreme cost sensitive applications, a current 32-bit ARM single-chip MPU can fit the cost, size, & power budgets of just about any small embedded project. As little as $1 for a 32-bit CPU!
Click to expand...

I'm not surprised that C++ has gotten into the small embedded market. I haven't dealt with anything embedded in quite a while, but I do wonder how much of the OOP part of C++ is compromised when it's used for the smaller embedded apps? Of course, assembler is going to be the smallest and fastest code on any embedded machine, but I have a hard time imagining when that would actually be cost effective with today's chips.
 

Similar threads

NTP2
TVC, how hard actually?
2
Replies
51
Views
2K
NTP2
NTP2
Charles_McG
eggStation - an eggTimer ground station software build thread.
2 3 4
Replies
106
Views
6K
atestani
atestani
SolarYellow
Little John prototype fin flutter hypothesis
Replies
1
Views
413
PeterAlway
P
StreuB1
Open question to software/firmware developers; Assembly.....
Replies
15
Views
884
Dan Griffing
Dan Griffing
HyperSpeed
Building a Lap Timer using Garage Door Sensors
Replies
4
Views
561
tHoagland
T

Latest posts

Back
Top