On May 13, 12:11=A0am, linnix <m...@linnix.info-for.us> wrote:
> > > Most of these people also took the opportunity to
> > > attack me personally instead of focusing on the discussion.
>
> Nothing personal, just institional.


Do you mean "institutional"? (I looked up institional in the
dictionary but didn't find an entry)


> > That's the whole point of the newsgroups: proving that your opponent is
> > an idiot. The more technical you are, the more damage you are making :)
>
> He claims to be the cream of the crop in his country/college.


Chapter and verse please. You can have my car... actually you can have
my first born too if you tell me when and where I posted that.


> I really question the educational system over there, wherever it is.


Be more specific. Tell me what I'm so crap at so that I may learn and
be better at it.

=2E..unless of course you're just making blind one-way unsubstantial
statements?

On May 13, 10:47 am, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> On May 13, 12:11 am, linnix <m...@linnix.info-for.us> wrote:
>
> > > > Most of these people also took the opportunity to
> > > > attack me personally instead of focusing on the discussion.
>
> > Nothing personal, just institional.
>
> Do you mean "institutional"? (I looked up institional in the
> dictionary but didn't find an entry)

Yes, you are right.  You are better at spellings than me.

>
> > > That's the whole point of the newsgroups: proving that your opponent i=
s
> > > an idiot. The more technical you are, the more damage you are making :=
)
>
> > He claims to be the cream of the crop in his country/college.
>
> Chapter and verse please. You can have my car... actually you can have
> my first born too if you tell me when and where I posted that.
>
> > I really question the educational system over there, wherever it is.
>
> Be more specific. Tell me what I'm so crap at so that I may learn and
> be better at it.
>
> ...unless of course you're just making blind one-way unsubstantial
> statements?

I am not the only one saying that your ideas are misguided.  You are
picking the smallest uC and trying to show what you can do with it.
In the real world, people just move on to the next size for a few more
pennies.   You are not really considering other posters opinion, just
arguing for the hack of it.

On May 13, 8:10=A0am, 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.


>=A0You 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.


>=A0Then 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. =A0If 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.


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

Of course, if you like, you can replace those preprocessor with fully-
fledged variables, e.g.:

    uint_fast8_t bits_in_current_byte =3D ... ;

But seeing as how my code would be running on a microcontroller I
wanted to minimise the amount of variables used.

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.

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.

On May 13, 6:14=A0pm, linnix <m...@linnix.info-for.us> wrote:

> Even if the code is perfect, it's lots of overhead to save a few
> bytes. =A0All these discussions of saving a few pins and bytes are just
> meaningless


Please point out the overhead, and also show how you'd remove that
overhead by making non-portable assumptions (e.g. that CHAR_BIT =3D=3D 8).

linnix:

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


If you have 12 pins and you need to perform 14 different functions,
then surely it's not "meaningless" to try to save pins.

If your data memory has been exceed by 3 bytes, then surely it's not
"meaningless" to try to save a few bytes.

On May 13, 6:56=A0pm, linnix <m...@linnix.info-for.us> wrote:

> I am not the only one saying that your ideas are misguided. =A0You are
> picking the smallest uC and trying to show what you can do with it.


I'm picking the PIC16F684 because it's the only one I'm familiar with,
it's the one I've been using in my college course.

Of course I could get a chip with more pins, more data memory, more
code memory, faster clock cycle, but I'm finding it enjoyable and
educational to "work with the scraps I'm given".


> In the real world, people just move on to the next size for a few more
> pennies. =A0 You are not really considering other posters opinion, just
> arguing for the hack of it.


Well you do make a good point about picking a better microcontroller,
but then again if I wanted to mass-produce 17 million devices, I'd
probably like to pick a cheaper micrcontroller if it can do the job
just as well as the more expensive microcontroller.

And don't forget the enjoyment and educational value I'm getting from
working with limited resources.

On May 13, 11:05=A0am, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> linnix:
>
> > Even if the code is perfect, it's lots of overhead to save a few
> > bytes. =A0All these discussions of saving a few pins and bytes
> > are just meaningless.
>
> If you have 12 pins and you need to perform 14 different functions,
> then surely it's not "meaningless" to try to save pins.
>
> If your data memory has been exceed by 3 bytes, then surely it's not
> "meaningless" to try to save a few bytes.

It's meaningless when you can just pick the 20 pins package with 18 I/
Os instead of the 14 pins package with 12 I/Os.  How difficult for you
to handle the 20 pins DIP?  I am not even asking you to deal with
TQFP, MLF and BGA.

On May 13, 7:15=A0pm, linnix <m...@linnix.info-for.us> wrote:

> > If you have 12 pins and you need to perform 14 different functions,
> > then surely it's not "meaningless" to try to save pins.
>
> > If your data memory has been exceed by 3 bytes, then surely it's not
> > "meaningless" to try to save a few bytes.
>
> It's meaningless when you can just pick the 20 pins package with 18 I/
> Os instead of the 14 pins package with 12 I/Os.


But surely you'd have the same problem when you want 18 pins to
perform 22 functions?

Anyway look this exchange is going nowwhere. I acknowledge what you're
saying about just picking a uC that has more I/O pins, but at the
moment I'm just playing around with a patchboard, a few LED's, some
wires and a snips. I find it interesting to use one sole pin in
conjunction with an A-to-D in order to take input from 7 different
push buttons.

So yes, you're right to a certain extent, we can just pick better
uC's, but I'm liking the discussions pertaining to being "clever" with
pins.

On May 13, 11:20=A0am, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> On May 13, 7:15=A0pm, linnix <m...@linnix.info-for.us> wrote:
>
> > > If you have 12 pins and you need to perform 14 different functions,
> > > then surely it's not "meaningless" to try to save pins.
>
> > > If your data memory has been exceed by 3 bytes, then surely it's not
> > > "meaningless" to try to save a few bytes.
>
> > It's meaningless when you can just pick the 20 pins package with 18 I/
> > Os instead of the 14 pins package with 12 I/Os.
>
> But surely you'd have the same problem when you want 18 pins to
> perform 22 functions?

40 pins DIP are available.  Real apps use 64 pins or 100 pins QFP/MLF
anyway.

>
> Anyway look this exchange is going nowwhere. I acknowledge what you're
> saying about just picking a uC that has more I/O pins, but at the
> moment I'm just playing around with a patchboard, a few LED's, some
> wires and a snips. I find it interesting to use one sole pin in
> conjunction with an A-to-D in order to take input from 7 different
> push buttons.

You can read 1024 levels with build-in A2D converters, but that's not
the typical way to handle buttons either.

>
> So yes, you're right to a certain extent, we can just pick better
> uC's, but I'm liking the discussions pertaining to being "clever" with
> pins.

And you are using additional logic chips to do it.  You think PCB
areas are free?

On May 13, 7:29=A0pm, linnix <m...@linnix.info-for.us> wrote:

> > I find it interesting to use one sole pin in
> > conjunction with an A-to-D in order to take input from 7 different
> > push buttons.
>
> You can read 1024 levels with build-in A2D converters, but that's not
> the typical way to handle buttons either.


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.

Anyway someone suggested to me about using the A2D converter so that I
only needed _one_ input pin. Do you think this is a good way of going
about it? The uC I'm using, the PIC16F684, has a 10-Bit A2D.


> > So yes, you're right to a certain extent, we can just pick better
> > uC's, but I'm liking the discussions pertaining to being "clever" with
> > pins.
>
> And you are using additional logic chips to do it. =A0You think PCB
> areas are free?


For some of the tricks, I am using additional logic chips. For
instance I'm using a shift register for the display multiplexer. For
other tricks, such as using the A2D for the push buttons, I'm actually
getting rid of chips I don't need.

Of course though there's a trade off. I mean if I were to discard the
shift register, then I'd need 84 I/O pins on my uC for the display,
and maybe it's cheaper to instead get a shift register and a uC with
12 I/O pins.