On 14/10/15 00:40, Simon Clubley wrote:
> On 2015-10-13, David Brown <david.brown@hesbynett.no> wrote:
>> On 13/10/15 20:58, Terry Newton wrote:
>>> On Tue, 13 Oct 2015 09:07:38 +0200, David Brown wrote:
>>>
>>> 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.
>>
>> The AVR is a good deal faster than that, relative to the PIC - not only
>> are most instructions single-cycle or two cycle, but they do a good deal
>> more useful things than PIC instructions.  Pretty much everything on a
>> PIC needs to pass through W, while on the AVR you have 32 registers to
>> play with - that makes the AVR approximately twice as efficient.  And if
>> you need to use pointers, or data on a stack, you are in a different
>> world - the PIC takes ten times the instructions that the AVR needs.
>>
>
> In addition, don't forget that little lack of peripheral specific
> vectored interrupts on the PIC18 and that whole having to read down the
> various status registers to find out which peripheral needs attention.

I'd forgotten about that (or perhaps repressed it...).

>
>>>
>>> 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.
>>
>> SDCC is a totally separate project from GCC, and is in no way a port of
>> it.  AFAIK it uses the same sort of license (the compiler itself is
>> under the GPL, but all library bits and pieces have exceptions to allow
>> you to use the compiler with code of any licence - the GPL does not
>> affect the source code you write or the object code you compiler and link).
>>
>> It is the Arduino libraries that have licensing complications.
>>
>
> Actually Terry might be wrong about the SDCC origins, but he's absolutely
> right about the Microchip headers in the SDCC kits; they do have language
> about how you can only use them with Microchip devices. (Or at least they
> did with the SDCC versions from several years ago; I havn't checked the
> current SDCC versions to see what the current situation is.)

Sorry, I was referring to the compiler here.  I didn't mean to say or 
imply anything about the Microchip headers.  I haven't looked at the 
licenses for them, but I have no reason to doubt you.

>
> The same also applies to Microchip's public source code in general BTW.
> Not really a problem when it's only the 8-bit PICs, but it's a real
> problem with the PIC32; you can't use Microchip's public code (or at
> least the code I looked at) on other MIPS devices.


>
>>>
>>>> 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.
>>
>> The cheapest Cortex device I know of is $0.40, with 16 pins IIRC.  The
>> smallest is about $0.70, has 20 pins (balls), and is 2 x 1.6 mm -
>> perhaps not targeted at the hobby and prototype market!
>>
>
> I know you tend to dismiss them but don't underestimate the advantages
> of PDIP in some areas; you can walk into the Farnell trade counter and
> buy various PDIP devices over the counter while you wait. These things
> would not be stock inventory unless there was still a viable commercial
> demand for them.

These stores cater mainly for hobby users and very small professional 
use, so the bias as to which parts are popular is very skewed.  And I 
remain convinced that in many cases where someone is looking for a DIP 
part, they would be more successful in using a ready-made PCB with a 
non-DIP part combined with essential components (such as oscillator, a 
few caps, etc.) in a prototype-friendly format.

>
>> There are very few modern microcontrollers at 5V now.
>>
>
> 5V tolerant I/O is still a potentially important issue however.

True - I have had plenty of projects where it would be nice for the 3.3V 
microcontroller to have 5V tolerant inputs, and outputs that have high 
enough voltage guarantees to be safely usable to drive devices that 
expect 5V logic levels.  I was stating a fact here, rather than 
suggesting it is a good thing.

>
> Simon.
>

On 2015-10-13, Paul Rubin <no.email@nospam.invalid> wrote:
> Terry Newton <nbill@bellsouth.net> writes:
>> 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
>
> I have about the same impression (ARM vs AVR), that the ARM is a lot
> more complicated to deal with at the lowest level, and people have also
> said the hardware interfacing is harder or has fewer amenities (like
> 5V).  But I don't have experience with this and am mostly a software guy.

I've done both at bare metal level although my ARM bare metal
experience is currently more the traditional ARM architectures.

The AVR is easier to get started with (and I especially like the
interrupt on any I/O level change option (regardless of direction),
which is something a number of ARM MCUs do not offer).

The ARMs are more powerful however and the internal architecture
reflects that. Once you have learnt one core the knowledge tends
to transfer to other cores however. The major downside for ARM
however are the manufacturer specific peripheral interfaces which
isn't an issue for AVR given it's single manufacturer status.

The ARMs also come into their own when you need to start manipulating
data in units of greater than 8 bits.

BTW, I actually like the ARM ISA; it comes across as (reasonably)
elegant to me as does the AVR's.

I also think the people you have talked to are right in some
circumstances; the AVR does offer things at I/O level that some
traditional ARM MCUs do not. I get the feeling that this is getting
addressed in the Cortex M series however; how successfully I can't
honestly give you a truthful answer yet.

Simon.

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

On 2015-10-13, David Brown <david.brown@hesbynett.no> wrote:
> On 13/10/15 20:58, Terry Newton wrote:
>> On Tue, 13 Oct 2015 09:07:38 +0200, David Brown wrote:
>>
>> 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.
>
> The AVR is a good deal faster than that, relative to the PIC - not only 
> are most instructions single-cycle or two cycle, but they do a good deal 
> more useful things than PIC instructions.  Pretty much everything on a 
> PIC needs to pass through W, while on the AVR you have 32 registers to 
> play with - that makes the AVR approximately twice as efficient.  And if 
> you need to use pointers, or data on a stack, you are in a different 
> world - the PIC takes ten times the instructions that the AVR needs.
>

In addition, don't forget that little lack of peripheral specific
vectored interrupts on the PIC18 and that whole having to read down the
various status registers to find out which peripheral needs attention.

>>
>> 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.
>
> SDCC is a totally separate project from GCC, and is in no way a port of 
> it.  AFAIK it uses the same sort of license (the compiler itself is 
> under the GPL, but all library bits and pieces have exceptions to allow 
> you to use the compiler with code of any licence - the GPL does not 
> affect the source code you write or the object code you compiler and link).
>
> It is the Arduino libraries that have licensing complications.
>

Actually Terry might be wrong about the SDCC origins, but he's absolutely
right about the Microchip headers in the SDCC kits; they do have language
about how you can only use them with Microchip devices. (Or at least they
did with the SDCC versions from several years ago; I havn't checked the
current SDCC versions to see what the current situation is.)

The same also applies to Microchip's public source code in general BTW.
Not really a problem when it's only the 8-bit PICs, but it's a real
problem with the PIC32; you can't use Microchip's public code (or at
least the code I looked at) on other MIPS devices.

>>
>>> 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.
>
> The cheapest Cortex device I know of is $0.40, with 16 pins IIRC.  The 
> smallest is about $0.70, has 20 pins (balls), and is 2 x 1.6 mm - 
> perhaps not targeted at the hobby and prototype market!
>

I know you tend to dismiss them but don't underestimate the advantages
of PDIP in some areas; you can walk into the Farnell trade counter and
buy various PDIP devices over the counter while you wait. These things
would not be stock inventory unless there was still a viable commercial
demand for them.

> There are very few modern microcontrollers at 5V now.
>

5V tolerant I/O is still a potentially important issue however.

Simon.

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

On Tue, 13 Oct 2015 22:49:44 +0200, David Brown wrote:

> AVR's can be programmed by JTAG, or using SPI - they work in much the
> same way as an SPI flash chip, with a little extra toggling of reset and
> another pin to put the chip in SPI programming mode.  It's well
> documented [...]

Figured it was something like that... just didn't see it in
the datasheet I had in the heat of the moment. Looking again
I see something called DebugWIRE that looks to be a 1-pin interface
to control code execution and overwrite code, that's interesting.
1 pin is better than 3 and it's on the reset pin so don't have to
share it with other stuff.

>> 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.
> 
> SDCC is a totally separate project from GCC, and is in no way a port of
> it.  AFAIK it uses the same sort of license (the compiler itself is
> under the GPL, but all library bits and pieces have exceptions to allow
> you to use the compiler with code of any licence - the GPL does not
> affect the source code you write or the object code you compiler and
> link).

Thanks for the clarification... saw gcc credits in the docs but
looks like it's just the preprocessor that was used, compiler
itself is totally different.

>> Elaborate? What can I do with gcc that I can't do with SDCC?
>> Is it just better libs, or the core language itself?
> 
> SDCC supports much of C90, and a few bits of C99 - keeping up with
> modern C language support and features is not a priority of SDCC.  gcc,
> on the other hand, aims for full support - and while the latest C11
> doesn't have much extra of use for small embedded systems (though it has
> a few useful points), C99 is a significantly nicer language to work
> with.  And with gcc you also have the option of C++ - apart from
> exceptions and RTTI, which are not implemented as yet in the avr C++
> library, you get C++ all the way to C++14 on the latest avr-gcc.
> 
> For the AVR, gcc has support for multiple address spaces to handle data
> in flash, as well as a range of extension "attributes" for making it
> easy to write interrupt functions and other specialist code in normal C.
> 
> gcc is a highly optimising compiler.  While speed is not everything, it
> means you can wave a fond goodbye to the sort of nonsense of manual
> optimisation needed with weaker compilers and weaker processors, in
> order to generate efficient code.  Never again will you have to convert
> for loops to while loops to save cycles, or use pointers instead of
> arrays, or use shifts when you want to multiply.
> 
> Perhaps one of the biggest "selling" points of gcc is its extensive
> static error checking and warnings.  It can catch a great many potential
> errors at compile time, if you give it the right options.
> 
> gcc has the best inline assembly system of any compiler I have used.  It
> is not the easiest to use (far from it!), but it is very powerful and
> lets you fully integrate assembly and C code.  It also has a variety of
> builtin intrinsic functions to improve critical code.

Thanks for writing that up, very informative.

Yes it does seem like gcc is much nicer! I use gcc all the time
to compile Linux apps, but not being much of a C programmer it's
hard to spot the differences. I treat C like BASIC... if then else
for while until math and logic and stay away from pointers like
the plague. My uC apps almost never use interrupts other than
simple stuff like wake from sleep when a button is pressed.
But that's just me, I'm an old-school hardware guy, not a
software guy - I like 100% deterministic behavior with no
unknown variables that might bite me later. Using C is scary
enough as it is... I still wade through the assembly listing
to make sure it does what I think I told it to do.

Probably time to bow out on this thread and get back to
other stuff but here's my takeaway...

C on an AVR is looks to be much more efficient than on a PIC,
so if I need to code a big/fast app, AVR is probably better.

Cortex/ARM (esp M0) looks to be the future, huge selection
and cheap. Really need to learn that stuff.

For simple stuff that just needs to work, just use what's
already on the workbench and go with what ya know. But probably
not wise to use that as an excuse to avoid "new" things...

Cheers,
Terry

Terry Newton <nbill@bellsouth.net> writes:
> 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.

My understanding is SDCC is a completely different compiler that's much
more primitive than 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?

GCC is a far more serious optimizing compiler and it wouldn't surprise
me if the code it generates can be as much as 2x faster, smaller,
etc. than SDCC's.  GCC also implements the current ISO standard very
completely, has various language extensions, debugging features, etc.
And it can do C++ if you want that (or for that matter Ada).  On the
other hand, some people complain about its optimizations being too
aggressive, pushing the hairy edge of the standard, so it can make code
that's correct under the ISO spec, but different from what you expected
so your code can fail if you're not up on ISO's nuances.  You can turn
off some of those optimizations with command line options.

> But the 5V [Cortex-M] I see are lacking in EEPROM.. go up to 256
> bytes.. not that that's a huge deal, external ee's are cheap.

The TI MSP430FRxxxx series seem interesting to me, since you were also
concerned about write wear in the EEPROM.  The 430FR's have on-chip FRAM
that is basically non-volatile ram, good for many billions of write
cycles.  At the moment there is no ARM part with that.

> 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

I have about the same impression (ARM vs AVR), that the ARM is a lot
more complicated to deal with at the lowest level, and people have also
said the hardware interfacing is harder or has fewer amenities (like
5V).  But I don't have experience with this and am mostly a software guy.

On 13/10/15 20:58, Terry Newton wrote:
> 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.

AVR's can be programmed by JTAG, or using SPI - they work in much the 
same way as an SPI flash chip, with a little extra toggling of reset and 
another pin to put the chip in SPI programming mode.  It's well 
documented (I've made my own programmers on occasion, using FTDI USB 
devices), and there are open source programmers - though most people use 
Atmel's own tools.  It is also not hard to write a bootloader - you have 
easy access to writing to the flash from within a boot program.  But I 
agree that it takes time.  There are probably boot loaders available 
from different sources (maybe even from Atmel) with clearer and more 
usable licenses than the Arduino stuff.

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

The AVR is a good deal faster than that, relative to the PIC - not only 
are most instructions single-cycle or two cycle, but they do a good deal 
more useful things than PIC instructions.  Pretty much everything on a 
PIC needs to pass through W, while on the AVR you have 32 registers to 
play with - that makes the AVR approximately twice as efficient.  And if 
you need to use pointers, or data on a stack, you are in a different 
world - the PIC takes ten times the instructions that the AVR needs.

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

SDCC is a totally separate project from GCC, and is in no way a port of 
it.  AFAIK it uses the same sort of license (the compiler itself is 
under the GPL, but all library bits and pieces have exceptions to allow 
you to use the compiler with code of any licence - the GPL does not 
affect the source code you write or the object code you compiler and link).

It is the Arduino libraries that have licensing complications.

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

SDCC supports much of C90, and a few bits of C99 - keeping up with 
modern C language support and features is not a priority of SDCC.  gcc, 
on the other hand, aims for full support - and while the latest C11 
doesn't have much extra of use for small embedded systems (though it has 
a few useful points), C99 is a significantly nicer language to work 
with.  And with gcc you also have the option of C++ - apart from 
exceptions and RTTI, which are not implemented as yet in the avr C++ 
library, you get C++ all the way to C++14 on the latest avr-gcc.

For the AVR, gcc has support for multiple address spaces to handle data 
in flash, as well as a range of extension "attributes" for making it 
easy to write interrupt functions and other specialist code in normal C.

gcc is a highly optimising compiler.  While speed is not everything, it 
means you can wave a fond goodbye to the sort of nonsense of manual 
optimisation needed with weaker compilers and weaker processors, in 
order to generate efficient code.  Never again will you have to convert 
for loops to while loops to save cycles, or use pointers instead of 
arrays, or use shifts when you want to multiply.

Perhaps one of the biggest "selling" points of gcc is its extensive 
static error checking and warnings.  It can catch a great many potential 
errors at compile time, if you give it the right options.

gcc has the best inline assembly system of any compiler I have used.  It 
is not the easiest to use (far from it!), but it is very powerful and 
lets you fully integrate assembly and C code.  It also has a variety of 
builtin intrinsic functions to improve critical code.

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

The cheapest Cortex device I know of is $0.40, with 16 pins IIRC.  The 
smallest is about $0.70, has 20 pins (balls), and is 2 x 1.6 mm - 
perhaps not targeted at the hobby and prototype market!

There are very few modern microcontrollers at 5V now.

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

I fully agree there.

> Terry
>

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

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

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