Fred's firmware development diary comments thread

[jbelanger]

By definition, a char is 8 bits, a short is 16 bits and a long is 32 bits so there should not be any portability issue if you use these. Using int will create portability issues so using uint8_t ... just seems to me to be for people who want to see int without having to think about the underlying definition.

But my training dates from a while and I've never had "formal" embedded code training so this is a very personal and biased view. And one funny thing is that Freescale's CodeWarrior doesn't include those definitions, at least the free version I'm using on an 8-bit MCU. I think you have to define the project as c++ for it to accept it and this is not available on the free version. Of course, you can add the definition to your project but that already makes it a portability issue, at least it has already been one to me.

Jean

[Fred]

Thanks Jean! I was going to get EssEss to cut in here and give us his bit, but then I remembered that what you said about long isn't true.

http://en.wikipedia.org/wiki/C_syntax#Integral_types

char / short are fixed, though.

Maybe we should roll with uint32_t for long stuff and leave the rest as is? Though then it's not consistent across types...

Fred.

[EssEss]

Nah, I don't really have anything to say - It just removes a whole class of bugs for me .. when it's that explicit I don't have to refer to platform documentation. This is also a big benefit for those who are new to the game and don't understand the typical c gotcha's yet. I do it mostly for the next guy. I don't really lean any particular way when it comes to c stuff. I've been exploring perl lately, and I'm liking its liberal c-like style too

[jbelanger]

As far as I know, a long in ANSI c is a 32-bit integer and nothing else (or at least it was). I've never seen it mean 64 bits but that may be some later variation or some other standard.

Actually, I just checked and it seems ISO c does allow both (and maybe ANSI c too). I find this completely stupid and just goes to show that standard bodies are not there to make consistent standards but just to please the paying members. And since you can't rely on the standards anymore, someone just added the uint8_t and family.

Jean

[sry_not4sale]

PS, good to see you posting, Aaron! Will we see the tuner being bench devved against that board in the near future? I have a mate with a holden V6 that might be the next FreeEMS donk if we can tune it a little more effectively, and keep the tuner working as comms evolve.

Maybe, will have to see how much spare-time I have over the next few months

[EssEss]

The 'hard' facts to never forget are:

char is guaranteed to be 8-bits
short is guaranteed to be 16-bits
int is guaranteed to be AT LEAST 16-bits
long is guaranteed to be AT LEAST 32-bits
long long is guaranteed to be AT LEAST 64-bits

so it's still possible to write something portable if you live within the rules above .. all the intxx_t's are easier to deal with when you hop around to different platforms (which I do a lot). I think the real problem is that c never started from a standard .. so then the standard now has to support all those legacy assumptions in order to break the least amount of existing code. It's cheaper for the end company (which probably sits on the standards board, just like Jean mentioned).

[MotoFab]

Though folks have different reasons for liking or disliking it, it seems everyone agrees the intxx_t style typedef is the way to go for portability. Also, those that mention it say they like that it's exact and unambiguous.

[Fred]

It's exact and umambiguous on a given platform to use the char short long signed/unsigned descriptors too.

EssEss in your slightly earlier post you don't explicitly say which way you lean, just a lot of stuff about which ever way it is that you do lean. I assume you meant to say "uintXX_t just removes a whole class of bugs for me" rather than "using raw types just removes a whole class of bugs for me" or the ambiguous "It just removes a whole class of bugs for me" and friends?

In any case, I'm surprised JHarvey hasn't shouted "shed colour" (without the u) loudly already. It would be simple to go through and replace all "unsigned short" occurrances with uint16_t at a later date with a script. So right now, it's just wasted time to start changing it. I'm very interested in the discussion, though. So if you still have anything to say, go right ahead, everyone.

Aaron, here's hoping you do :-) Ditto Marcos! Ditto Dave! Imagine how mean and lean my shlt will be with 3 of you beating me up for every mistake and bad decision ;-)

Fred.

[jharvey]

In any case, I'm surprised JHarvey hasn't shouted "shed colour"

I'm not an expert on code, but I seem to recall this requires special mods that only work with the GNU compiler. So why care that much about portability??? Well here I go, SHED COLOR.

I'm actually glad to hear folks talking about programming details. It may be slow development, but at least it's development.

[nitrousnrg]

My opinion:
I prefer those types because
* they are easy to read, and highlights the importance of the variable size (its kind of critical in these systems). I find those types more embedd-ish.
* an embedded guru (yeh, he is freaking crazy) made me use it for everything related to a microcontroller (arguing about portability and code reuse, mostly). He codes for microchip families, arm (7,9,M3, etc), a bunch of motorolas, avr, PC. Really, he is the embedded version of chuck norris. Ah, C and assembler for all those archs. He probably learnt that from the aliens that brought him to this planet.