In message 
<9...@56g2000hsm.googlegroups.com>, 
Tomás Ó hÉilidhe <t...@lavabit.com> writes
>On May 14, 4:20 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
>wrote:
>
>> I let Thomas O'Edison (or whatever is his name) elaborate the
>> portability issues.
>
>
>Awfully strange how such a comment should come from someone posting on
>an English-speaking group with a name like "Vladimir Vassilevsky".

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 :-)

>I
>mean there's nothing wrong with your name, I'm sure it's perfectly
>normal in your own country,

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?

> but I just find it awfully strange that
>such a comment should come from _you_. I'd say "that's rich coming
>from you", but then I still think the comment would be worthy of shame
>if came from a "John Smith".

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

>And this is exactly the kind of rude attitude I'm talking about. I've
>set out being nothing but courteous to people and yet they respond
>rudely.

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.

>Vladimir, slowly but surely, post by post, you're confirming that
>you're just a rude, hostile, prick. If this attitude of yours is
>permanent then I'd appreciate you adding me to your killfile.

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 2008-05-14, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
> On May 14, 10:45 am, Andrew Smallshaw <andr...@sdf.lonestar.org>
> wrote:
>
>> Seven push buttons is pushing things a bit much.  I assume that
>> you are connecting them such that a button press shorts out a
>> resistor, and the resistors are valued in a 1R, 2R, 4R... arrangement.
>> 2^7 is 128, in other words the value of the smallest resistor is
>> less than 1% of the resistance of the entire network.  
>
>
> Here's the idea I have so far:
>
> http://users.imagine.ie/toe/a2dbuttons.jpg

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

http://andrews.freeshell.org/news/20080514.cae.pdf

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
a...@sdf.lonestar.org

Tomás Ó hÉilidhe wrote:

> I've got 7 push buttons. My old design was that I fed these into a
> 74HCT148 encoder which had 3 output pins, and so my uC needed 3 input
> pins available in order to see if a button was pressed. (The buttons
> in my Connect4 game appear under the columns of LED's. If you press
> the button under Column 3 then a chip will fall into that column.

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.

Tomás Ó hÉilidhe wrote:
> 
... snip ...
> 

> I've set out being nothing but courteous to people and yet they
> respond rudely.

Followed by a stellar example of courteous behaviour.

> 
> Vladimir, slowly but surely, post by post, you're confirming that
> you're just a rude, hostile, prick. If this attitude of yours is
> permanent then I'd appreciate you adding me to your killfile.

Maybe you should re-examine your actions.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.


** Posted from http://www.teranews.com **

Tomás Ó hÉilidhe wrote:

> On May 14, 10:45 am, Andrew Smallshaw <andr...@sdf.lonestar.org>
> wrote:
>
> > Seven push buttons is pushing things a bit much.  I assume that
> > you are connecting them such that a button press shorts out a
> > resistor, and the resistors are valued in a 1R, 2R, 4R... arrangement.
> > 2^7 is 128, in other words the value of the smallest resistor is
> > less than 1% of the resistance of the entire network.
>
> Here's the idea I have so far:
>
> http://users.imagine.ie/toe/a2dbuttons.jpg
>

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
http://www.bytecraft.com
w...@bytecraft.com

Tomás Ó hÉilidhe wrote:
> On May 13, 8:10 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
> 
>> Thus the correct *portable* way to write this code is to assume that
>> CHAR_BIT is 8.
> 
> 
> OK then what would you change in the code if CHAR_BIT were 8?
> 
> Please be _very_ specific because I'm the one who wrote the original
> code and I can't see anywhere I can take advantage of CHAR_BIT being 8
> that will lead to cleaner, more simple code.
> 

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.

> 
>>  You have a little #if and #error at the start to check
>> that assumption.
> 
> 
> You're blatantly throwing portability out the window for the sake of
> throwing portability out the window. Blatantly. Unless of course you
> can provide me with an example of where it can be beneficial to assume
> that CHAR_BIT is 8.. ? I'm not being sarcastic or derisory either, I'd
> actually like to see what you'd do.
> 

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".


> 
>>  Then your code is much smaller, much clearer, and
>> probably much more efficient in its generated object code, as it cuts
>> out much of the junk.  If you have to use this same module on a target
>> with other CHAR_BIT values, you can write a modified version then.
> 
> 
> Again I'd like to see how you'd change the code to make it neater,
> shorter, faster, simpler.
> 

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).


> 
>> I think my claim was:
>>
>> "I haven't seem much indication from your posts that you can write
>> legible C code at all, never mind "fully portable" code (to the extent
>> that such a thing really exists)."
> 
> 
> Yes, that it was.
> 
> 
>> Given that monstrosity of unnecessary preprocessor gymnastics (and it
>> certainly doesn't help that you miswrite your directives by separating
>> the # from the keyword), I stand by that claim.
> 
> 
> My "preprocessor gymnastics" as you call it, actually make the code
> much much easier to understand, for example the constant of
> "bits_in_current_byte" is far more descriptive than a few arithmetic
> operations.
> 

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.

> Of course, if you like, you can replace those preprocessor with fully-
> fledged variables, e.g.:
> 
>     uint_fast8_t bits_in_current_byte = ... ;
> 
> But seeing as how my code would be running on a microcontroller I
> wanted to minimise the amount of variables used.
> 

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.

> Also you'll have to be specific about how I "miswrite" the
> preprocessor directives by "separating the # from the keyword". I did
> so because there's no other way of achieving proper indentation (the
> preprocessor only processes lines that begin with a #). And regarding
> the way in which I achieve indentation by "separating the # from the
> keyword", I find that the left-justified hash symbol does no harm
> whatsoever.
> 

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.

> Given that you've actually seen my code now, you're in more of a
> position to form an opinion about it. If you think I can't program
> portably, then you're just plain wrong, and I think the original post
> in this thread is a testament to your wrongness. If you think my code
> is "illegible", then that's entirely up to you, but I myself am proud
> of it and will stand by it.






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

#include <string.h>   /* memset */
#include <limits.h>   /* CHAR_BIT */

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

#if (bitsPerChunk > 8)
	#error This code assumes bitsPerChunk <= 8
#endif

/*
	We'll put the chunks into an array of slices.  Different choices of
	slice size will be more effective for different uses - larger sizes
	will be more effecient, but smaller sizes will be faster on small cpus.
*/


#if ((8 % bitsPerChunk) == 0)
	#define sliceType uint8_t				// No need for anything bigger
	#define bitsPerSlice 8
#elif (bitsPerChunk == 6)
	#define sliceType uint32_t
	#define bitsPerSlice 32
#else
	#define sliceType uint16_t				// Good enough padding for 3, 5 and 7 bits
	#define bitsPerSlice 16
#endif

#define chunksPerSlice (bitsPerSlice / bitsPerChunk)
#define totalSlices ((quantityChunks + (chunksPerSlice - 1)) / 
chunksPerSlice)


/* It's useful to note that this is:
	b_p_c	b_p_s	c_p_s	efficiency
	1		8		8		100%
	2		16		4		100%
	3		16		5		93.75%
	4		8		2		100%
	5		16		3		93.75%
	6		32		5		93.75%
	7		16		2		87.5%
	8		8		1		100%
*/

#define bitMask ((sliceType) ((1u << bitsPerChunk) - 1))

static sliceType data[totalSlices];

typedef struct chunkAddress_t {
     uint_fast16_t a;
     uint_fast8_t offset;
} chunkAddress_t;
static chunkAddress_t ca;

static void GetChunkAddress(uint_fast16_t i) {
	ca.a = i / chunksPerSlice;
	ca.offset = (i - ca.a * chunksPerSlice);
}

void SetChunk(uint_fast16_t i, uint_fast8_t state) {
	GetChunkAddress(i);
	data[ca.a] = (data[ca.a] & ~(bitMask << ca.offset)) | (((sliceType) 
state) << ca.offset);
}

uint_fast8_t GetChunk(uint_fast16_t i) {
	GetChunkAddress(i);
	return (data[ca.a] >> ca.offset) & bitMask;
}


void SetEntireDataAllOnes(void) { memset(data, 0xff, sizeof(data)); }
void SetEntireDataAllZeroes(void) { memset(data, 0x00, sizeof(data)); }

linnix <m...@linnix.info-for.us> writes:
> Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote:
> > Everett M. Greene wrote:
> > > Vladimir Vassilevsky <antispam_bo...@hotmail.com> writes:
> > >>Tom=3DE1s =3DD3 h=3DC9ilidhe wrote:
> >
> > >>>In my most recent embedded project, there was a severe memory
> > >>>restriction. I had to store in memory the state of 42 individual
> > >>>LED's. Each LED could have one of three states.
> >
> > >>Hence there is a minimum of 67 bits. But this will require heavy weight
> > >>arithmetics.
> >
> > >>>To use the least
> > >>>amount of memory possible for each LED, I thought I'd go with the
> > >>>following strategy:
> >
> > >>>* Use three bits per LED. 00 =3D Off. 01 =3D Red. 10 =3D Unused. 11 =3D=
> 
> > >>>Green.
> >
> > >>:))))
> >
> > >>Combine the state of five leds into one byte. That totals to eight bytes=
> 
> > >>plus four bits for the remaining two leds =3D 68 bits.
> > >>[...]
> >
> > > Somebody is using strange arithmetic. =A0At a minimum, using the
> > > state encoding prescribed, you need two bits per LED.
> >
> > 3^5 =3D 243. Hence the state of five LEDs can be packed into one byte.

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

> > > =A0Assuming
> > > 8-bit bytes, four LED's states can be packed in one byte. =A0The
> > > states for 42 LEDs can then be packed in 11 bytes or 88 bits.
> >
> > But this is very dull.
> 
> Even if the code is perfect, it's lots of overhead to save a few
> bytes.  All these discussions of saving a few pins and bytes are just
> meaningless.

You got that right!

In message <482afdf5$0$2664$8...@news.wineasy.se>, David Brown 
<d...@westcontrol.removethisbit.com> writes
>Tomás Ó hÉilidhe wrote:
>> On May 13, 8:10 am, David Brown <da...@westcontrol.removethisbit.com>
>> wrote:
>>>  You have a little #if and #error at the start to check
>>> that assumption.
>>   You're blatantly throwing portability out the window for the sake 
>>of
>> throwing portability out the window. Blatantly. Unless of course you
>> can provide me with an example of where it can be beneficial to assume
>> that CHAR_BIT is 8.. ? I'm not being sarcastic or derisory either, I'd
>> actually like to see what you'd do.
>>
>
>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".

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 my work, "portable" means "works on an AVR, and MSP430 and a 
>ColdFire".

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

>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).

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

>>> Given that monstrosity of unnecessary preprocessor gymnastics (and 
>>>
>>> certainly doesn't help that you miswrite your directives by separating
>>> the # from the keyword), I stand by that claim.
>>   My "preprocessor gymnastics" as you call it, actually make the code
>> much much easier to understand, for example the constant of
>> "bits_in_current_byte" is far more descriptive than a few arithmetic
>> operations.
>
>It is very rare that local macro definitions and undefs are appropriate 
>within a function.

Often banned in many coding standards.

>It is particularly silly when these same macros are re-used without 
>change.

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


>> Of course, if you like, you can replace those preprocessor with fully-
>> fledged variables, e.g.:
>>      uint_fast8_t bits_in_current_byte = ... ;
>>  But seeing as how my code would be running on a microcontroller I
>> wanted to minimise the amount of variables used.
>
>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.

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.

>> Also you'll have to be specific about how I "miswrite" the
>> preprocessor directives by "separating the # from the keyword". I did
>> so because there's no other way of achieving proper indentation

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

>>(the
>> preprocessor only processes lines that begin with a #). And regarding
>> the way in which I achieve indentation by "separating the # from the
>> keyword", I find that the left-justified hash symbol does no harm
>> whatsoever.
>>
>
>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.

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. :-(

>> Given that you've actually seen my code now, you're in more of a
>> position to form an opinion about it. If you think I can't program
>> portably, then you're just plain wrong,

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

>> and I think the original post
>> in this thread is a testament to your wrongness. If you think my code
>> is "illegible", then that's entirely up to you, but

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

>> I myself am proud
>> of it and will stand by it.

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Vladimir Vassilevsky wrote:
> 
> Dead simple and no overhead at all:
> 
> static u8 led_state = 0;
> 
> // Position = 0...4
> // State of each led = 0,1,2
> 
> void set_led_state(u8 position, u8 state)
> {
> u8 b = 1;
> while(position--) b *= 3;
> led_state += (state - led_state%(3*b)/b)*b;
> }
> 
> u8 get_led_state(u8 position)
> {
> u8 b = 1;
> while(position--) b *= 3;
> return led_state%(3*b)/b;
> }
> 
> This code makes perfect sense for microcontrollers with MUL and DIV.
> I let Thomas O'Edison (or whatever is his name) elaborate the 
> portability issues.
> 
> 
>>  All these discussions of saving a few pins and bytes are just
>> meaningless.
> 
> Yes, of course. This is a hack just for fun.
> 
> 

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 ‹•?•›

W4tch3r ‹•¿•› wrote:
> 
... snip ...
> 
> 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 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]: <http://cbfalconer.home.att.net>;
            Try the download section.


** Posted from http://www.teranews.com **