Fundamental C question about "if" statements

On 21/09/15 14:47, Les Cargill wrote:
> David Brown wrote:
>> On 20/09/15 23:39, Les Cargill wrote:
>>> David Brown wrote:
>>>> On 20/09/15 19:40, Les Cargill wrote:
>>>>> Oltimer wrote:
>>>>>>
>>>>>> Learning some embedded C using Microchip's C18 Lite.
>>>>
>>>> I hadn't noticed that the OP was using a PIC18.  Of course, if you are
>>>> interested in learning about C, programming embedded systems, or simply
>>>> using a half-decent compiler, then pick any microcontroller except a
>>>> Microchip PIC.  PICs (and 8051's) should be banned from any
>>>> beginners on
>>>> the grounds that they cause more harm than good.
>>>>
>>>> Get a chip with a Cortex M core, or at least an AVR or msp430.  Then
>>>> you
>>>> can use proper development tools and program in normal C.
>>>>
>>>>>
>>>>> This book:
>>>>>
>>>>> http://www.amazon.com/The-Programming-Language-Brian-Kernighan/dp/0131103628
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> will save you hours of grief.
>>>>
>>>> It will also cause you hours of grief - because although it is a fairly
>>>> complete guide to C, it is not the best tutorial out there, it is for a
>>>> seriously outdated version of C (C11 is the current standard, though
>>>> there are few practical changes from C99.  But C99 is a significantly
>>>> better programming language than ANSI C for most uses), and it
>>>> concentrates on C for big systems - not for embedded systems.
>>>>
>>>> I don't know what the best choice of tutorial is for learning modern
>>>> embedded C, but the oldest known C book is not it.
>>>>
>>>>
>>>>
>>>
>>>
>>> It still works. It's nearly universal. Learning every detailed corner of
>>> the language will take even more time. If you
>>> constrain yourself to mainly K&R plus a couple simple extensions
>>> you will produce more readable code than in any other way.
>>>
>>> Firs learn K&R, then learn the heresies that came later. You
>>> will then know why the heresies are good things.
>>>
>>
>> I don't expect to change your opinion at all, but I have not the
>> slightest doubt that C99 lets you write clearer, simpler, more
>> efficient, more readable and more logical code than ANSI C, just like
>> ANSI C was a big step up from K&R C.
> 
> No doubt. But still - I think it's somehow important to understand
> the evolution of the language.
> 

That's fair enough.  But the ideal book for learning modern C would
cover C99 as the main text, encouraging things like bool, <stdint.h>
types, mixing declarations and statements (to get minimal scope), and so
on.  A discussion of the limitations of C90 should be a single chapter,
also including examples of the horrors that were pre-C90 K&R C, while a
discussion of C11 might be two or three chapters.  (C11 won't take more
than that, because there are not many changes.)

It is good to understand the history of any subject we try to learn, but
we don't need to study a whole book before getting to the current
material of interest.  Someone really interested in C, rather than just
wanting to get something done with the language, should definitely read
The C Programming Language at some point - but it should not be part of
a main "learn to program in C" course.

>> The first edition of The C
>> Programming Language
> 
> I would not use the first edition.
> 
>> was about K&R C - this should never, ever be
>> taught.
> 
> I would not think so; no. 1989 is now 36 years ago. I would
> agree that that is far back enough.
> 
> The idiom:
> 
> void x(y)
> int y;
> {
> }
> 
> is clunky enough to die right 20 years ago. I probably didn't even
> spell that right.

I am not sure K&R C had "void" - but I believe you've got it at least
roughly correct.  There were no prototypes, no checking, no automatic
type conversions - but then, at the beginning at least, the only types
were "int" and a floating point type.

> 
>> The second edition is from 1988, and covers most of what was
>> just becoming ANSI C (the differences between ANSI C, C89 and C90 are
>> minor).  That's better, but the world has moved on from 1988.
>>
> 
> To clarify I do mean the second edition or better.
> 
> I do not care for the belief that there needs to be one way to
> teach something for "newbies" and another for the advanced class.
> 

It is reasonable to say that all students of C should start in a similar
place - what distinguishes "newbies" from "advanced" is the amount they
have learned, and the experience they have.  But having both groups
start "at the beginning" does not mean starting at the historical beginning.

> Besides, the K&R book is a signal example of technical writing.

I agree on that - but it is irrelevant to someone merely trying to learn
a bit of embedded C programming.  It makes the book worth adding to the
bookshelf, but it does not make it useful for teaching modern C
programming in embedded systems, because it does not cover modern C
programming /or/ embedded systems.

If someone is learning to write technical documents with LibreOffice or
FrameMaker, the TeXBook and the LaTeX Document Preparation System are
not an obvious choice for learning material.  Once the student gets more
knowledgeable and experienced in the subject, those two books are worth
reading - both for their examples of technical writing, and for the
typesetting knowledge within.  But they are not books the students
should start with.

> 
>> For students of computing history, it is interesting to look at K&R C to
>> see why modern C is better.  But for people wanting to learn C for real
>> use, it's about as much use as teaching medical students about
>> blood-letting and prayers to Isis and Osiris before discussing
>> antibiotics.
>>
> 
> :)
> 
>> (Okay, that last comparison was a bit exaggerated, but I hope you get my
>> point.)
>>
>>
> 
> I might have actually have used that *to teach* medical students,
> partly to make a point about people using appeals to bad statistical
> analysis as if they were prayers to Osiris.

I was explaining this to one of my kids recently (since he'd read an
article about ancient Egyptian medicine in a history magazine), which is
why I thought of the example.  There is definitely worth in showing such
things as examples of how not to do medicine - my point is merely that
you can do that in a book chapter or a single class, rather than making
the first term's study about learning those prayers and incantations
before then throwing them out for something more useful.

> 
> We do see a fair amount of despair-inducing examples
> of this in real life.
> 

On 2015-09-20, David Brown <david.brown@hesbynett.no> wrote:
> On 20/09/15 13:22, Oltimer wrote:
>>
>> Learning some embedded C using Microchip's C18 Lite.
>>
>> I tried the following and it misbehaved:
>>
>> if( 10 < my_variable < 20 )
>>      { //do this......}

I would suggest that the OP might want to learn C first in a hosted
environment rather than an embedded one.

[...]

>> Is it normal that C cannot handle complexities such as "a < b < c" ?

It's not a a problem with "complexity".  The problem is that the C
language grammar defines exactly what (a < b < c) means.  It means
((a < b) < c).

>> I would have thought a compiler could easily work out what was
>> intended.

Compilers do not generate code that does what you intend.  They
generate code that does what you write.

> No, compilers cannot work out something like "a < b < c"
>  - it is interpreted as though it were "(a < b) < c", where "(a < b)"
>    is either 0 or 1.

Yep, that's what the express (a < b < c) means in C.  Some languages
(e.g. Python) allow chained comparison operators, and in Python
(a < b < c) means ((a < b) && (b < c)).

-- 
Grant Edwards               grant.b.edwards        Yow! I'm a nuclear
                                  at               submarine under the
                              gmail.com            polar ice cap and I need
                                                   a Kleenex!

On 09/21/2015 08:16 AM, David Brown wrote:
> On 21/09/15 14:47, Les Cargill wrote:
>>
>> The idiom:
>>
>> void x(y)
>> int y;
>> {
>> }
>>
>> is clunky enough to die right 20 years ago. I probably didn't even
>> spell that right.
>
> I am not sure K&R C had "void" - but I believe you've got it at least
> roughly correct.  There were no prototypes, no checking, no automatic
> type conversions - but then, at the beginning at least, the only types
> were "int" and a floating point type.
>
I was writing a lot of Pascal back in the day and the C programmers were 
proud of the fact there were no prototypes or type checking - such 
things were for wimps. I found it humorous that these were required in 
C++.

On Mon, 21 Sep 2015 09:57:11 +0200, David Brown wrote:

> On 21/09/15 00:01, Tim Wescott wrote:
>> On Sun, 20 Sep 2015 20:42:10 +0200, David Brown wrote:
>> 
>>> On 20/09/15 19:40, Les Cargill wrote:
>>>> Oltimer wrote:
>>>>>
>>>>> Learning some embedded C using Microchip's C18 Lite.
>>>
>>> I hadn't noticed that the OP was using a PIC18.  Of course, if you are
>>> interested in learning about C, programming embedded systems, or
>>> simply using a half-decent compiler, then pick any microcontroller
>>> except a Microchip PIC.  PICs (and 8051's) should be banned from any
>>> beginners on the grounds that they cause more harm than good.
>> 
>> I agree with your two outer statements, but a PIC isn't a bad processor
>> if you stick to assembly (and projects small enough that assembly is
>> reasonable).
>> 
>> 
> The PIC chips have some good points - they are extraordinarily robust.
> I have worked with a customer's card that had a 85C qualified PIC, and
> they were looking for ways to push it beyond the 160C or so where it
> currently stopped working.  And once Microchip starts delivering a PIC
> device, they never seem to obsolete them - you can still buy devices
> that are 15 years old or more.
> 
> But they are a horrible CPU to work with - in C or in assembly.  At
> least with assembly you know you are working with something
> device-specific, so it is less of a surprise.

Back when I wrote software for boards that other people designed, I was 
absolutely positively anti-PIC.

Then, a few projects came up where I needed to design the whole board, 
and I started looking at things like flexibility of peripherals, current 
drive capability, and delivery history.

Then, I became moderately PIC-tolerant.

But I still like Cortex-M0 parts better.

-- 
www.wescottdesign.com

On 2015-09-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> BTW, does anyone actually use PIC18s for new production quality projects
> these days ?

Yes.

> In this discussion, I'm treating the PIC24 as an extension of the PIC18

The PIC24 is a completely new-from-scratch core that has nothing
whatsoever do with the PIC18.

> but also as something that comes across as an evolutionary dead-end.
> The PIC24 is even more poorly supported than the PIC18 for open source
> or hobbyist work; at least the PIC18 has SDCC available for it.]

Microchip has free compilers for all of their parts.  The PIC24
compiler is based on gcc.

On Mon, 21 Sep 2015 20:04:24 +0800, Oltimer wrote:

> On 21-Sep-15 7:06 PM, Simon Clubley wrote:
>> On 2015-09-20, Tim Wescott <tim@seemywebsite.com> wrote:
> 
> 
> <snip>
> 
> 
>> The reason I am mentioning this is to suggest to the OP that they
>> rethink the choice of PIC18, even for hobbyist use, in 2015.
>>
>> BTW, does anyone actually use PIC18s for new production quality
>> projects these days ?
>>
>>
> 
> I've seen PIC18's in commercially made medical/dental chairs
> (controlling tilt/angle etc) and in some small speed controllers.
> 
> I guess "quality" is in the eye of the designer!  ;)

I've seen a lot of monumentally stupid design decisions embodied in 
various products -- so just because something gets used someplace, that 
doesn't mean it's the best.  And just because it was the best yesterday, 
that doesn't mean it's the best today.

Having said that, the PIC18 isn't _bad_ -- it's just not the best for 
lots of applications, and now that the Cortex M0 parts are getting cheap, 
it's best for less and less as time goes on.

-- 
www.wescottdesign.com

On Mon, 21 Sep 2015 11:06:02 +0000, Simon Clubley wrote:

> On 2015-09-20, Tim Wescott <tim@seemywebsite.com> wrote:
>>
>> Any C compiler that targets an 8-bit PIC is not the best for learning
>> --
>> at least not for learning C.  The PIC architecture is a very bad fit to
>> the C virtual machine, and as such a compiler writer is forced to
>> choose between making a compiler that is not compliant to the
>> standards, or making a compiler that generates hugely inefficient code.
>>
>>
> It's also very resource limited by today's standards.
> 
>> I can't speak to the XC8 compiler, but the C18 not only wasn't
>> compatible, it pretty much required you to do Really Bad Things in
>> order to get the most efficient code (this, by the way, is the same
>> problem exhibited by the 8051 -- it's a totally different architecture
>> from the PIC, but it misses the C virtual machine by a similar-sized
>> mile).
>>
>> Given that you can get ARM Cortex-M0 parts that are nearly as small as
>> the smallest 8-bit parts, and are nearly as cheap (I think they get
>> down to $0.75 or less in onsies from DigiKey), I don't see any reason
>> not to use a part that's a better fit to the language.
>>
>>
> The PIC18 has one thing going for it and that is it's available in PDIP
> so it's easy to breadboard them.
> 
> Until the PIC32 came along, it was also the only MCU range to have a USB
> device capability in a PDIP format so that made it of natural interest
> for some people wanting to do USB work.
> 
> I've played with the PIC18 in the past and I _really_ disliked it, but
> it was the only viable option for PDIP based USB device MCUs at the time
> so I stuck with learning it instead of tossing it on the scrap heap
> where it belongs.
> 
> I designed a library at the time which was designed to be portable but
> needed to include the PIC18, so I made some decisions I wasn't happy
> about even at the time and which made the code more cumbersome than it
> needed to be. This was mainly due to the limited resources on the PIC18.
> 
> The irony is that I never even got the library actually ported to the
> PIC18 due to other things coming up. :-)
> 
> I'm now revisiting that work for another reason and it didn't take me
> long to decide to dump the PIC18 style API for that library and to redo
> the API on the assumption that more resource rich MCUs are available
> instead.
> 
> The reason I am mentioning this is to suggest to the OP that they
> rethink the choice of PIC18, even for hobbyist use, in 2015.
> 
> BTW, does anyone actually use PIC18s for new production quality projects
> these days ?
> 
> [In this discussion, I'm treating the PIC24 as an extension of the PIC18
> but also as something that comes across as an evolutionary dead-end.
> The PIC24 is even more poorly supported than the PIC18 for open source
> or hobbyist work; at least the PIC18 has SDCC available for it.]

There are some Cortex-M0 parts showing up in PDIP, and there are Cortex-M0 
parts with USB.  I don't know if the two sets intersect, however.

With the exception of packages that have pads underneath (damn, what's 
the name?), hand-soldering surface-mount assemblies just takes a steady 
hand and a decent microscope.  And, I suspect one could make a good-
enough microscope with the right web-cam and a 'puter.  So I don't see 
why surface-mount and hobbyist should be mutually exclusive.

-- 
www.wescottdesign.com

On Mon, 21 Sep 2015 10:06:47 +0200, David Brown wrote:

> On 20/09/15 23:39, Les Cargill wrote:
>> David Brown wrote:
>>> On 20/09/15 19:40, Les Cargill wrote:
>>>> Oltimer wrote:
>>>>>
>>>>> Learning some embedded C using Microchip's C18 Lite.
>>>
>>> I hadn't noticed that the OP was using a PIC18.  Of course, if you are
>>> interested in learning about C, programming embedded systems, or
>>> simply using a half-decent compiler, then pick any microcontroller
>>> except a Microchip PIC.  PICs (and 8051's) should be banned from any
>>> beginners on the grounds that they cause more harm than good.
>>>
>>> Get a chip with a Cortex M core, or at least an AVR or msp430.  Then
>>> you can use proper development tools and program in normal C.
>>>
>>>
>>>> This book:
>>>>
>>>> http://www.amazon.com/The-Programming-Language-Brian-Kernighan/
dp/0131103628
>>>>
>>>>
>>>>
>>>> will save you hours of grief.
>>>
>>> It will also cause you hours of grief - because although it is a
>>> fairly complete guide to C, it is not the best tutorial out there, it
>>> is for a seriously outdated version of C (C11 is the current standard,
>>> though there are few practical changes from C99.  But C99 is a
>>> significantly better programming language than ANSI C for most uses),
>>> and it concentrates on C for big systems - not for embedded systems.
>>>
>>> I don't know what the best choice of tutorial is for learning modern
>>> embedded C, but the oldest known C book is not it.
>>>
>>>
>>>
>>>
>> 
>> It still works. It's nearly universal. Learning every detailed corner
>> of the language will take even more time. If you constrain yourself to
>> mainly K&R plus a couple simple extensions you will produce more
>> readable code than in any other way.
>> 
>> Firs learn K&R, then learn the heresies that came later. You will then
>> know why the heresies are good things.
>> 
>> 
> I don't expect to change your opinion at all, but I have not the
> slightest doubt that C99 lets you write clearer, simpler, more
> efficient, more readable and more logical code than ANSI C, just like
> ANSI C was a big step up from K&R C.  The first edition of The C
> Programming Language was about K&R C - this should never, ever be
> taught.  The second edition is from 1988, and covers most of what was
> just becoming ANSI C (the differences between ANSI C, C89 and C90 are
> minor).  That's better, but the world has moved on from 1988.
> 
> For students of computing history, it is interesting to look at K&R C to
> see why modern C is better.  But for people wanting to learn C for real
> use, it's about as much use as teaching medical students about
> blood-letting and prayers to Isis and Osiris before discussing
> antibiotics.
> 
> (Okay, that last comparison was a bit exaggerated, but I hope you get my
> point.)

But it is a point -- who IS the Egyptian god of computing?

-- 
www.wescottdesign.com

On 20/09/2015 7:29 PM, Tim Wescott wrote:
 >
 >>> This is spelled out very well in "C, A Reference Manual" by
 >>> Harbison and Steele.  There are other books out there (K & R
 >>> comes to mind), and Harbison and Steele may not even be the best
 >>> -- but I find that Harbison and Steele is a very good book for my
 >>> purposes.
 >>
 >> I am looking at the C standards here (C11, document N1570).
 >>

A few posts ago you mentioned "C, A Reference Manual" by Harbison
and Steele. This is a very good "readable" reference on C that has been
periodically updated. The authors are remarkably approachable and the
book is high on my short list of essential references.


w..

On 2015-09-21, John Temples <usenet@xargs-spam.com> wrote:
> On 2015-09-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> BTW, does anyone actually use PIC18s for new production quality projects
>> these days ?
>
> Yes.
>

Interesting; thanks.

>> In this discussion, I'm treating the PIC24 as an extension of the PIC18
>
> The PIC24 is a completely new-from-scratch core that has nothing
> whatsoever do with the PIC18.
>

Yes, it has a new instruction set, etc, but it was advertised by Microchip
as effectively an extension of the PIC18.

>> but also as something that comes across as an evolutionary dead-end.
>> The PIC24 is even more poorly supported than the PIC18 for open source
>> or hobbyist work; at least the PIC18 has SDCC available for it.]
>
> Microchip has free compilers for all of their parts.  The PIC24
> compiler is based on gcc.
>

The PIC24 gcc port is not part of mainline gcc/binutils; you are stuck
with the one-off port done by Microchip. With the PIC32 however, I am
using the generic MIPS gcc/binutils toolchain which I obtained from the
MIPS website and which works just fine with the PIC32MX.

You still have to create the PIC32 headers, linker scripts and startup
code but that's not a major exercise if you know what you are doing.

BTW, Microchip have traditionally been very hostile to open source in
that they are willing to take from the community but are willing to
only give back the bare minimum that they are required to by the GPL
so the above was true for the PIC24 as well the last time I checked.

It's an attitude I don't understand BTW. If Microchip behaved more like
Atmel (for example), they would have a much more positive image.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world