Fundamental C question about "if" statements

On 24/09/15 15:20, Luke A. Guest wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> 
>>> What target are you wanting?
>>>
>>
>> Currently PIC32 and ARM bare metal. If some things I am currently
>> doing with the PIC32 work out, then I am going to forget about the
>> PIC18 and drop it from the list of MCUs I am interested in.
> 
> Yeah not tried earlier PIC's, I'd be surprised if they're in GCC.
> 
> GCC does have MIPS now that Ingres have taken it over.
> 

gcc has supported MIPS since the dawn of time - it was one of the
earliest ports.

David Brown <david.brown@hesbynett.no> 
>> 
> 
> gcc has supported MIPS since the dawn of time - it was one of the
> earliest ports.

But not everything as microchip didn't give changes back to GCC as they had
their own tool chain.

On 24/09/15 16:44, Luke A. Guest wrote:
> David Brown <david.brown@hesbynett.no> 
>>>
>>
>> gcc has supported MIPS since the dawn of time - it was one of the
>> earliest ports.
> 
> But not everything as microchip didn't give changes back to GCC as they had
> their own tool chain.
> 

Ah, yes - gcc supported MIPS and MIPS cores, but Microchip took a
snapshot of gcc and did their own changes and made their own headers and
libraries.  And that has AFAIK never made it back to mainline -
Microchip doesn't really understand how open source works.

On 2015-09-24, David Brown <david.brown@hesbynett.no> wrote:
> On 24/09/15 16:44, Luke A. Guest wrote:
>> David Brown <david.brown@hesbynett.no> 
>>>>
>>>
>>> gcc has supported MIPS since the dawn of time - it was one of the
>>> earliest ports.
>> 
>> But not everything as microchip didn't give changes back to GCC as they had
>> their own tool chain.
>> 
>
> Ah, yes - gcc supported MIPS and MIPS cores, but Microchip took a
> snapshot of gcc and did their own changes and made their own headers and
> libraries.  And that has AFAIK never made it back to mainline -
> Microchip doesn't really understand how open source works.
>

And those headers/libraries are restricted by Microchip so even though
you can download the specific versions of the gcc/binutils toolchain
Microchip are using and build them, you are not allowed to use the
Microchip headers/libraries with your own toolchain.

I'm just using a generic toolchain from MIPS which builds and works
just fine for me. I'm using libraries I wrote myself and ported to
MIPS and I create my own headers from the public Microchip documentation
as I need them.

Simon.

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

On 2015-09-24, Luke A  Guest <laguest@archeia.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> 
>> Currently PIC32 and ARM bare metal. If some things I am currently
>> doing with the PIC32 work out, then I am going to forget about the
>> PIC18 and drop it from the list of MCUs I am interested in.
>
> Yeah not tried earlier PIC's, I'd be surprised if they're in GCC.
>

There's nothing gcc based for 8-bit PICs. The only open source compiler
that I am aware of is SDCC.

Microchip have their own one-off port of the gcc/binutils toolchain
for the PIC24 but have not added the changes back into the mainline
toolchain.

> GCC does have MIPS now that Ingres have taken it over.
>
>> 
>> The last time I looked at your work however, you were having real
>> problems with things being fragile or simply breaking from gcc version
>> to gcc version.
>>
>> I know about Brian's work with the MSP430 stuff and I've used AVR-Ada
>> in the past.
>
> My whole problem was that GNAT couldn't be built without hacking the
> configure scripts up and basically breaking;  this is his Brian does it. As
> of GCC 5 that is no longer the case, I've included the same patch in
> free-Ada.
>

Oh, now that's interesting. Thanks, Luke.

Simon.

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

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

> The PIC18 has one thing going for it and that is it's available in PDIP
> so it's easy to breadboard them.

They also practically never go away, design in MC parts and it keeps
the supply people happy.
 
> 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.

It's what you get used to, I've been using PIC's since '93.. and
I can still buy the part (PIC16C56) - the product can still be
made as-is 22 years later. I use PIC18F2525 processors a lot, for
both hobby and commercial stuff. Instead of messing around with
Microchip's compilers I use SDCC, works for me and it's open source
so if something goes wrong I have a fighting chance of fixing it
myself. But so far the only bug I've had was a failure to note
that the manual says to beware of --obanksel=2, known issue.

> BTW, does anyone actually use PIC18s for new production quality projects
> these days ?

Yes. It works, it's reliable, plentiful supply, and cheap enough.
I don't discount using other processors, but for anything that
needs <~3.9kb ram and <24kw code, just bangs bits and can get by
at 32mhz or less, it's almost guaranteed I can make it work on a
'2525. Also the PDIP option is a handy plus. Another plus is I've
never needed a crystal, PIC18's have a 1%-accurate internal clock.

The ATMEGA328 has similar capabilities (and also a PDIP option),
not quite as good but cheaper and probably fine for most apps
of this kind, the issue is I'd have to redo my tool chain,
learn new quirks, learn new compilers, etc. I see no reason
to do all that unless it was a high volume cost sensitive app
and I had the time to figure out all the new stuff. Learned
this the hard way - that shipping product with a PIC18 was
prototyped using an Arduino. Was going to go the '328 route
but got derailed when I realized that compiler converts
everything it makes to GPL, no time to find an alt compiler
and tools so just did it with a PIC/SDCC, done, shipped.

Terry

On 13/10/15 05:39, Terry Newton wrote:
> On Mon, 21 Sep 2015 11:06:02 +0000, Simon Clubley wrote:
> 
>> The PIC18 has one thing going for it and that is it's available in PDIP
>> so it's easy to breadboard them.
> 
> They also practically never go away, design in MC parts and it keeps
> the supply people happy.
>  
>> 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.
> 
> It's what you get used to, I've been using PIC's since '93.. and
> I can still buy the part (PIC16C56) - the product can still be
> made as-is 22 years later. I use PIC18F2525 processors a lot, for
> both hobby and commercial stuff. Instead of messing around with
> Microchip's compilers I use SDCC, works for me and it's open source
> so if something goes wrong I have a fighting chance of fixing it
> myself. But so far the only bug I've had was a failure to note
> that the manual says to beware of --obanksel=2, known issue.
> 
>> BTW, does anyone actually use PIC18s for new production quality projects
>> these days ?
> 
> Yes. It works, it's reliable, plentiful supply, and cheap enough.
> I don't discount using other processors, but for anything that
> needs <~3.9kb ram and <24kw code, just bangs bits and can get by
> at 32mhz or less, it's almost guaranteed I can make it work on a
> '2525. Also the PDIP option is a handy plus. Another plus is I've
> never needed a crystal, PIC18's have a 1%-accurate internal clock.
> 
> The ATMEGA328 has similar capabilities (and also a PDIP option),
> not quite as good but cheaper and probably fine for most apps
> of this kind, the issue is I'd have to redo my tool chain,
> learn new quirks, learn new compilers, etc. I see no reason
> to do all that unless it was a high volume cost sensitive app
> and I had the time to figure out all the new stuff. Learned
> this the hard way - that shipping product with a PIC18 was
> prototyped using an Arduino. Was going to go the '328 route
> but got derailed when I realized that compiler converts
> everything it makes to GPL, no time to find an alt compiler
> and tools so just did it with a PIC/SDCC, done, shipped.
> 

AVR's (like the ATMEGA) have their quirks, but they are almost
negligible in comparison to working with PIC devices.  The only hinder
to programming AVR's in "normal" C is access to data in flash - that is
slightly messy (though not nearly as bad as for PICs).  Other than that,
you get a solid cpu, albeit 8-bit, and a top-quality modern compiler and
well-written library.

The compiler used by Arduino is the AVR port of gcc - this is the
standard compiler for the AVR, and Atmel also distributes it as part of
their tools.  Although the compiler itself is under the GPL, it places
no restrictions on your own code - nor does the standard AVR library
(avrlibc).

The Arduino is a different matter - it is a hardware/software project
aimed at prototyping and hobby use, with an unpleasant and unclear mix
of licenses.  So when you are making software with Arduino and its
libraries, I am not convinced that there is /any/ license you can
legally use to distribute your software if you use all the parts of the
library - but there are certainly parts that require GPL or at least
require that you release your source code or linkable object files.

But if you stick to more normal embedded development styles, then the
AVR is absolutely fine.  And once you have moved to gcc, you will not
want to go back to SDCC (SDCC is a fine piece of work, but as a compiler
it is not in the same league as gcc).


However, if you are moving away from PIC's it does not really make sense
to take a small step to AVRs - take a bigger step to Cortex-M devices.
Much as I like variety and competition, the Cortex's are now dominant
and there are fewer and fewer reasons - other than legacy - to choose
anything else for a microcontroller.

In article <mviaft$psp$1@dont-email.me>, david.brown@hesbynett.no 
says...
.... 
> AVR's (like the ATMEGA) have their quirks, but they are almost
> negligible in comparison to working with PIC devices.  The only hinder
> to programming AVR's in "normal" C is access to data in flash - that is
> slightly messy (though not nearly as bad as for PICs).  Other than that,
> you get a solid cpu, albeit 8-bit, and a top-quality modern compiler and
> well-written library.

Yes the Harvard architecture and accessing strings or arrays of strings
in flash is 'quirky', but a good cheap breadboarding, proof of principle
or few off in house hardware/system test suite base.

Personally would only use ATMEGA (Arduino Mega), myself.
 
> The compiler used by Arduino is the AVR port of gcc - this is the
> standard compiler for the AVR, and Atmel also distributes it as part of
> their tools.  Although the compiler itself is under the GPL, it places
> no restrictions on your own code - nor does the standard AVR library
> (avrlibc).
> 
> The Arduino is a different matter - it is a hardware/software project
> aimed at prototyping and hobby use, with an unpleasant and unclear mix
> of licenses.  So when you are making software with Arduino and its
> libraries, I am not convinced that there is /any/ license you can
> legally use to distribute your software if you use all the parts of the
> library - but there are certainly parts that require GPL or at least
> require that you release your source code or linkable object files.

Good for start point quick and dirty, also their ARM offerings for
hardware platforms DUE etc are quite good, have some quirks.

> But if you stick to more normal embedded development styles, then the
> AVR is absolutely fine.  And once you have moved to gcc, you will not
> want to go back to SDCC (SDCC is a fine piece of work, but as a compiler
> it is not in the same league as gcc).

At least for proof of concept or small in house runs they are usable and 
with Due and like same IDE with gcc compiler for M3 part.
 
> However, if you are moving away from PIC's it does not really make sense
> to take a small step to AVRs - take a bigger step to Cortex-M devices.
> Much as I like variety and competition, the Cortex's are now dominant
> and there are fewer and fewer reasons - other than legacy - to choose
> anything else for a microcontroller.

Currently got a Arduibo Due setup Cortex M3, for some DMX (theatre 
lighting), using Arduino as proof of conecpt and a 18 year old student 
project for his A level in computing. Advantages of IDE and arduino 
libraries actually means he spends more time at higher levels rather
than building UART functions and some of the other complexities that 
take longer for a project they are doing alongside other subjects.

Dont want him lost in working out interrupts for M3 from scratch.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

On 13/10/15 13:12, Paul wrote:
> In article <mviaft$psp$1@dont-email.me>, david.brown@hesbynett.no 
> says...
> .... 
>> AVR's (like the ATMEGA) have their quirks, but they are almost
>> negligible in comparison to working with PIC devices.  The only hinder
>> to programming AVR's in "normal" C is access to data in flash - that is
>> slightly messy (though not nearly as bad as for PICs).  Other than that,
>> you get a solid cpu, albeit 8-bit, and a top-quality modern compiler and
>> well-written library.
> 
> Yes the Harvard architecture and accessing strings or arrays of strings
> in flash is 'quirky', but a good cheap breadboarding, proof of principle
> or few off in house hardware/system test suite base.
> 
> Personally would only use ATMEGA (Arduino Mega), myself.

The AVR is - IMHO - a thing of the past.  We used to use them a good
deal in my company, but there are /very/ few situations where you cannot
get a Cortex device that is cheaper, smaller, lower power, and has more
features and flexibility than an AVR.  We choose them only for legacy
uses (upgrades of old designs) or occasional very specialist uses.  The
same goes for other old favourites such as the msp430.  It is a dead-end
architecture - don't expect to see Atmel put much more effort into new
AVR devices (and the AVR32 line is already dead).

There are hundreds of small Cortex-M boards available - including
genuine Arduinos, if you like that platform, and boards that are
compatible with Arduino add-ons.  So why settle for "less quirky than a
PIC" when you can get a nice, clean 32-bit core with uniform memory access?

>  
>> The compiler used by Arduino is the AVR port of gcc - this is the
>> standard compiler for the AVR, and Atmel also distributes it as part of
>> their tools.  Although the compiler itself is under the GPL, it places
>> no restrictions on your own code - nor does the standard AVR library
>> (avrlibc).
>>
>> The Arduino is a different matter - it is a hardware/software project
>> aimed at prototyping and hobby use, with an unpleasant and unclear mix
>> of licenses.  So when you are making software with Arduino and its
>> libraries, I am not convinced that there is /any/ license you can
>> legally use to distribute your software if you use all the parts of the
>> library - but there are certainly parts that require GPL or at least
>> require that you release your source code or linkable object files.
> 
> Good for start point quick and dirty, also their ARM offerings for
> hardware platforms DUE etc are quite good, have some quirks.

(Note - all microcontrollers, and all tools, have their quirks - here I
can only talk about those of the core.  And the Cortex-M cores are about
as non-quirky as it is possible to get.)

Arduino ARM boards might be a good choice for quick prototypes.  But
Arduino is a poor base for most commercial projects - with the
questionable licensing being one of the reasons.  As long as that is not
a problem, and you work in a development environment where the boss
understands the difference between a prototype and version one of the
product, that's fine.  (And obviously it's fine for hobby, educational
and experimental purposes.)

> 
>> But if you stick to more normal embedded development styles, then the
>> AVR is absolutely fine.  And once you have moved to gcc, you will not
>> want to go back to SDCC (SDCC is a fine piece of work, but as a compiler
>> it is not in the same league as gcc).
> 
> At least for proof of concept or small in house runs they are usable and 
> with Due and like same IDE with gcc compiler for M3 part.
>  
>> However, if you are moving away from PIC's it does not really make sense
>> to take a small step to AVRs - take a bigger step to Cortex-M devices.
>> Much as I like variety and competition, the Cortex's are now dominant
>> and there are fewer and fewer reasons - other than legacy - to choose
>> anything else for a microcontroller.
> 
> Currently got a Arduibo Due setup Cortex M3, for some DMX (theatre 
> lighting), using Arduino as proof of conecpt and a 18 year old student 
> project for his A level in computing. Advantages of IDE and arduino 
> libraries actually means he spends more time at higher levels rather
> than building UART functions and some of the other complexities that 
> take longer for a project they are doing alongside other subjects.
> 
> Dont want him lost in working out interrupts for M3 from scratch.
> 

On Tue, 13 Oct 2015 09:07:38 +0200, David Brown wrote:

> AVR's (like the ATMEGA) have their quirks, but they are almost
> negligible in comparison to working with PIC devices.  The only hinder
> to programming AVR's in "normal" C is access to data in flash - that is
> slightly messy (though not nearly as bad as for PICs).

With a PIC I just copy the code from the datasheet. I'm sure it's
the same with the ATMEGA. The obstacle I ran into was I could find no
info in the datasheets about in-circuit programming (besides bootloader),
with the PIC I just had to run a few wires to a connector and add R's
to the other stuff those pins were connected to, then a PICKIT 2 or 3
can be connected to reflash the PIC. Maybe can do the same with ATMEGA
but all I saw was serial bootloaders, ATMEGA's with the Arduino
bootloader pre-flashed, but no clear license. Even if I did use
the plain gcc compiler. So was faced with the possibility of having
to write my own bootloader, and just didn't have time to do that,
or hunt down something I could use. I'm sure there is something
that would have worked fine, but came down to either get new tools
and figure out a bunch of new stuff with roadblocks due to the
hobby nature of the part, or port it to a PIC18F2525 which I
already knew would work just fine. Probably spent about the
same amount of time (a few days) porting to the PIC as I would
have spent porting to generic AVR gcc - in both cases replacing
the Arduino-specific libs/code with generic, but most of it was
writing code that emulated the Parallax LCD's positioning codes.
The majority of the app remained the same.

The difference was with the AVR route I had unknowns that could
have taken an unknown amount of time to solve (managers hate
that!), whereas with a PIC there was practically no time spent
on hardware design and programming hardware (already had it).
I did have to learn to use SDCC but that was easy - where I
wasted time was trying to make MC's compilers work. Actually
HiTech C did work but the working version of the compiler was
no longer available so moved it to SDCC to future-proof -
almost identical code.

>  Other than that,
> you get a solid cpu, albeit 8-bit, and a top-quality modern compiler and
> well-written library.

The ATMEGA328 doesn't impress me much, but the larger '644 and
'1284 chips sure look nice. Main thing that worries me is eeprom
endurance, rated 100K cycles whereas the PIC's are rated 1M.
For most apps this won't make any difference but for some it
can mean 10x longer lifetime or 10x more reliable depending
on how you look at it. One really nice thing about AVR is they're
1 cycle per instruction, PICs are 4 so a 20mhz ATMEGA is probably
2-3 times faster than a 32mhz PIC.

If I run into an app that needs that kind of power the ATMEGA
is definitely in the running. I know the PIC18F2525 and similar
but not the larger parts, so if it comes down to figuring out
a new chip it really makes no difference. But that's IF...
most of the embedded stuff I do is quite simple - ranging
from dumb (but vital) 8-pin apps that control power on/off
and blink an LED if the voltage gets low, to 28-pin apps for
testers that have to measure ohms, drive signal generators,
LCD's and stuff like that.

> The compiler used by Arduino is the AVR port of gcc - this is the
> standard compiler for the AVR, and Atmel also distributes it as part of
> their tools.  Although the compiler itself is under the GPL, it places
> no restrictions on your own code - nor does the standard AVR library
> (avrlibc).

Standard GCC exception. BTW SDCC is a port of GCC and has the
same license, only restriction is from the MC headers which
stipulate the code has to be used on genuine MC parts.. uh no prob.

> The Arduino is a different matter - it is a hardware/software project
> aimed at prototyping and hobby use, with an unpleasant and unclear mix
> of licenses.  So when you are making software with Arduino and its
> libraries, I am not convinced that there is /any/ license you can
> legally use to distribute your software if you use all the parts of the
> library - but there are certainly parts that require GPL or at least
> require that you release your source code or linkable object files.

The main thing the Arduino had going for it was I was able to
get one from Radio Shack (oh I miss them) along with a breadboard
and pile of parts, and have a working proof-of-concept in days.
Looked like hell but when our client plugged in their headset
and it correctly identified the speaker ohms, mic type and
simulated an aircraft intercomm they said go for it, exactly
what they needed. But they don't care one bit about CPU's
licenses and all that, they want a product they can sell. Now.
Would have been nice if I could have simply packaged what was
on the breadboard but the real world isn't so kind.
 
> But if you stick to more normal embedded development styles, then the
> AVR is absolutely fine.  And once you have moved to gcc, you will not
> want to go back to SDCC (SDCC is a fine piece of work, but as a compiler
> it is not in the same league as gcc).
 
Elaborate? What can I do with gcc that I can't do with SDCC?
Is it just better libs, or the core language itself?
 
> However, if you are moving away from PIC's it does not really make sense
> to take a small step to AVRs - take a bigger step to Cortex-M devices.
> Much as I like variety and competition, the Cortex's are now dominant
> and there are fewer and fewer reasons - other than legacy - to choose
> anything else for a microcontroller.

Agreed. At least for anything needing more computing power than
the simple bit-bang stuff I usually do. And in some cases that too,
there are 8-pin versions for less than $1. But the 5V ones I see
are lacking in EEPROM.. go up to 256 bytes.. not that that's a
huge deal, external ee's are cheap. Gotta have 5V though, that's
what all the stuff I'm controlling and reading runs at - sure I
can use level shifters etc but not if I don't have to.

Doesn't mean I'll be ditching PIC's any time soon... I d/l'd
a bunch of M0 docs to study, they do look nice and perhaps one day
I'll figure out what to do with them... vastly more complicated
which means many more things getting in the way at first. But
they can potentially do more.

The point of all this is it really doesn't matter what uC is
used so long as it meets the needs of the app. If starting
fresh with uC's then yea PIC's can be a pain. But I do think
the pain is exaggerated to a degree, and what someone is used
to counts more than philosophical preferences. Time to market
means a lot, I can code a PIC app in a day or three and know
it's gonna work and so long as MC doesn't fold (no evidence
of that) I know supply will be there. Other parts.. ????
definitely worth learning but it's gonna be awhile before I
can do the same stuff with them that I can do now with a PIC.
There's more to it than just this part is better than that.

Terry