My idea of fully-portable C code

In message , Tomás Ó hÉilidhe writes

This is an INTERNATIONAL GROUP. English is the default language though we some times permit American and other languages have been used.

For many who post here English is their second language (third if you count C :-)

You have no idea what his country is. Sounds like a US name to me. Actually as his telephone number (on his web site) has no international dialling code :- (580) 336-7227 he probably is American.

Tomas where are you from?

I can see nothing wrong with his comment but then I have been on line for over 18 years. I am used to usenet.

I suggest you pause and think. You are blindly pissing off a LOT of people with your attitude. Perhaps it is you who needs to re-assess your attitude before you have to leave yet another job.

Fools rush in where angles fear to tread......

At this rate you will be kill filed by everyone if it weren't so entertaining.

Tomas, I assume you did not want to work in the embedded industry?

If you do change your name and attitude pronto.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H
Loading thread data ...

That will be fine. I had an arrangement similar to:

formatting link

in mind. That will handle multiple keypresses simultaneously but is more sensitive to resistor tolerances and does not scale to quite as many keys.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

A 74HC165 is also a possibility. It can be in the same chain as a couple of 74HC595's, allowing you to drive your LEDs and read the buttons through the same pins.

Reply to
Arlet Ottens

... snip ...

Followed by a stellar example of courteous behaviour.

Maybe you should re-examine your actions.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

The input impedance of most A/D's is not that high each switch is creating a voltage divider reducing the operating range for switch value.

With this arrangement is difficult to sense key rollover in software. (Multiple keypresses produce ambiguous results)

Regards,

-- Walter Banks Byte Craft Limited Tel. (519) 888-6911

formatting link
snipped-for-privacy@bytecraft.com

Reply to
Walter Banks

I'd use CHAR_BIT being 8 so that I could pick types for my array that allow good packing without crossing adjacent elements. When you know that CHAR_BIT is 8, you can be sure of the exact sizes of uint8_t and other such types.

No, the problem is that you don't understand what "portability" means in the real world, especially in comp.arch.embedded. "Portable code" means "works well on all relevant systems". Unless you are using specialised DSP chips, your can assume CHAR_BIT is 8 on all your systems. If your source code is big and ugly, or your generated code is big and slow, just so that you can compile without errors on a dinosaur mainframe then you have not written portable code.

For my work, "portable" means "works on an AVR, and MSP430 and a ColdFire".

See below.

Note that I've not implemented exactly the same algorithm as you have - by packing 5 3-bit chunks into 16-bit data I get much better code with almost as good packing efficiency.

I also removed the unnecessary "const" from your function declarations (it's irrelevant for non-pointer types, and is non-portable for real world non-standard compilers such as older ImageCraft compilers).

It is very rare that local macro definitions and undefs are appropriate within a function. It is particularly silly when these same macros are re-used without change.

With more modern compilers, it's often better to use static constants, enum types, and inline functions than macros.

That would only be relevant if you are using an incredibly bad compiler. Anything that would be sensible to use will generate exactly the same code for a local variable and an anonymous calculation result.

This is part of what I mean by writing bad code. You are making unwarranted assumptions about compiler behaviour and writing ugly workarounds for problems that don't exist.

Just indent the directives. I don't know about the details of the standards, but real compilers are perfectly happy with white space before the #. That way you get the indentation, and editors can do proper syntax highlighting on the directives.

// Stop shouting #define quantityChunks QUANTITY_CHUNKS #define bitsPerChunk BITS_PER_CHUNK

#include /* memset */ #include /* CHAR_BIT */

#if (CHAR_BIT != 8) #error This code assumes CHAR_BIT == 8 #endif

#if (bitsPerChunk > 8) #error This code assumes bitsPerChunk

Reply to
David Brown

Not with the encoding specified (0, 1, 3 doesn't pack well).

You got that right!

Reply to
Everett M. Greene

Well he means all systems that use strict ANSI C (1998) as opposed to ISO-C and don't have anything like nasty hardware extensions.

As far as I can tell his "extensive" embedded and portable C experience is one PIC and one PC...

For me 8051, ARM, coldfire or 68K and Z80

See above.. All you need to know about portable is in the obsolete US C spec: C89

Often banned in many coding standards.

As you say. Silly and usually banned in most coding standards.

I agree, It shows very limited experience and understanding. This is not a crime.

Having little knowledge is not in itself dangerous Not knowing that it is a little knowledge IS dangerous Telling the world you know what you are doing is always dangerous

Telling a group of experienced professionals you know what you are doing and they don't (especially when you don't know you have too little knowledge) is usually fatal as we are observing.

He's in that river in Egypt.

There is no "proper" indentation C is a free form language. There are, however, THREE commonly used forms of indention

I agree. He has a very strange style. Which in itself is not a problem. IT is a problem if he wants to work with anyone else. I have some slides I use in a presentation on coding standards which demonstrate this but will they are not transposable to plain text. :-(

From experience of many types of MCU over 30 years I can tell you that you can't program portably OR safely..

It is not "good code". It would not get you a job anywhere I know.

Though with your attitude I doubt you will get past the interview. Actually.... given the number of people how have seen you here and the other NG's you are on you are not likely to get to the interview.

As for me I am past redemption, run my own company, and becoming a dinosaur, so I can say what I like. Though in my case it gets me invitations to do the key note presentation at conferences. :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

This is really nice. I haven't posted here before so I don't know who the goodies and badies are in terms of politics. Actually I don't care. This is really nice. For the sake of the guy looking at my code 6 months later, I'd probably go with bitfields, maybe something like

typedef struct{ uint16 Led0:2; uint16 Led1:2; ... uint16 Led4:2; } led_states;

(I don't know if you can use arrays with bitfields, uint16 Led[5]:2 would be ever nicer)

but of course I'd be wasting the fourth state in each 2 bit member.

I was wondering since you pointed out the other day 3^5 = 253 how to do the base 3 arithmetic (never had to do it before) in a simple manner. Your post here is much simpler than I was expecting.

I wonder have you used it in production code (do I need to check if it really works?)

W4tch3r ?????

Reply to
W4tch3r ‹•¿•›

... snip ...

I trust you meant 243. You can also quickly multiply by 3 on very simple hardware, by shift and add twice.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

yes thanks! 243 W4tch3r ??¿??

Reply to
W4tch3r ‹•¿•›

I suspect Chris misunderstands Tomas's point: that macros defining numeric expressions should have surrounding parentheses in the macro definition so they aren't required where they are used. So

#define FOO (BAR+3) x = FOO+4;

rather than

#define FOO BAR+3 x = (FOO)*4;

Hans-Bernard's point, of being paranoid of externally-defined macros and surrounding those with parentheses is good, of course.

--
Thad
Reply to
Thad Smith

Can't you multiply by three by shifting and adding *once*?

Reply to
Eric Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.