PIC versus AVR

On 2006-08-07, steve <bungalow_steve@yahoo.com> wrote:

> I assumed you are talking about the "super low power" 1.8V  H8/300's
> which are the only ones that I can see are competitive with the Atmel's
> AVR's and MSP430's (the super low power H8/300s are still twice as much
> power, but in the ballpark), but maybe I am wrong, are the 10K and 512K
> versions 1.8V/super low power?

No, I was talking about the "normal" 3.3V and 5V parts.  You're
probably right about parts available at 1.8V.

> I don't see any on their website, the low power versions
> seemed to max out 2K/60K (with 4K in development), but the web
> site is a maze to look thru, so I could of missed them!
>
> Soon as you get into the higher power higher voltage H8/300's,
> then obviously your out of the AVR/MSP430 territory and moving
> into the ARM arena

Agreed.  The low-end ARMs are probably what the 32-bit H8 parts
compete with.

>> > limited selection
>>
>> Don't think so.
>
> 1.8V versions , I think so

You're right.  I was including the whole line all the way up to
the 5V only parts.

>> You must be getting better prices from your distributor.  A few
>> months ago I got quotes and MSP430's came in at $1-$3 cheaper
>> than equivalent AVRs which were quoted at $7-$8.
>
> part numbers please?

I'd have to go look them up to get exact numbers, but off the
top of my head I was quoted around $7 for the Atmega1281 and
around $5-$6 for the MSP430F1491.  The 128K/4K H8/300H part I'm
currently using (3062) is just a hair under $4.

-- 
Grant Edwards                   grante             Yow!  Is something VIOLENT
                                  at               going to happen to a
                               visi.com            GARBAGE CAN?

mc <look@www.ai.uga.edu.for.address> wrote:
> Someone wrote:
> >>> You are probably saying that an 8 bit architecture is inherently
> >>> C-unfriendly.

> I think another idea lurking in the background here is that C expects a Von 
> Neumann architecture (same instructions to read from program memory as from 
> data memory) and most micros have Harvard architecture (reading from pgm. 
> and data memory are different kinds of operations).  

That idea had better not lurk in that background, because it's wrong.
C doesn't require von Neumann architecture.

> MSP430 have Von Neumann architecture; almost all larger computers do 
> (Pentium, VAX, etc.).

Except that the "modern" ones often are von-Neumann only on the
outside, whereas the core is actually Harvardian (separate
lowest-level Caches for code and data).  x86 has been like that since
about the Pentium II at least.

> This is the source of the C string storage problem (how to avoid
> filling up data memory with your string data).

This is a non-problem.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On Monday, in article <12df1jbhn5hrsc0@corp.supernews.com>
     grante@visi.com "Grant Edwards" wrote:

>On 2006-08-07, Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
>> grante@visi.com "Grant Edwards" wrote:
>>>On 2006-08-07, steve <bungalow_steve@yahoo.com> wrote:
>>>> Grant Edwards wrote:
>>>>
>>>>> Start at yet another end again: why pick an 8-bit architecture
>>>>> if you're using a language or writing an application that needs
>>>>> to do a lot of 16-bit operations?  Something like an MSP430
>>>>> (16-bit) or H8 (16/32 bit) is cheaper than an AVR, and makes
>>>>> life easier. I particularly like the H8/300 which provides
>>>>> atomic read/write of 32-bit variables (long integers and
>>>>> floats): that eliminates the requirements for a lot of mutexes.
>>>>
>>>> Well the H8/300's max out at 2K RAM (8K for AVR's)
>>>
>>>
>>>Odd, I'm using one with 4K, and I evaluated models with 10K.
>>
>> Well if you take the _strictest_ interpretation of H8/300 64k addressing
>> then MOST are limited to 2K of RAM,
>
>Ah.  You're right.  If Steve meant "H8/300" to exclude the "H"
>"S" etc. models, then those are strictly 16-bit address space
>parts.  I guess when I type "H8/300" I mean to include the
>whole family. 

That's the trouble with so much choice and trying to keep parts
available for a long time.

>> however most H8 users appear to be using H8/300H or H8/300S or
>> H8/300SX cores with 16M addressing and RAM largest I have seen
>> and evaluated is 32Kb (H8S/2329 and H8S/2378).
>>
>>>> 60K FLASH (256K AVR's)
>>>
>>>I'm using one with 128K, and evaluated models with 512K.
>
>That's one of the H8/300H varieties (H8/3062).

Close H8/3067, have considered changing to H8/3068 (F 384K, RAM 16k)
or H8/3069 (F 512k, RAM 16k). But as these are can be 5V or 3V parts for
3V I would choose H8S/2329 or H8S/2378 for the 32k RAM and faster execution
speed as well as MAC for some apps.

>> Yep currently using several with 128kB, have used one with 384Kb and will
>> be evaluating one with 512kB of Flash.
>
>>>> requires  50% more power, are physically bigger, have no EEPROM
>>>
>>>True.
>>>
>>>> limited selection
>>>
>>>Don't think so.
>>
>> I agree with that.
>
>I just wish some of the parts with CAN interfaces were cheaper.
>For some reason, the H8 parts with CAN and a decent amount of
>flash (128K+) are awfully expensive (in the $20 range).  What I
>really want is 128K of flash, 16-24K of RAM, and CAN -- but it
>costs about half as much to glue something together using a
>3062, 32K SRAM, and an external CAN controller. :(

With SRAM I find it easier to layout for one part that is new or
in development Jedec pinout, but able to fit the current device in
with lesser pins. The extra size and slight extra cost outweighs
the availabilty issues of anything that appears to be smaller than
1Mb these days. Easier production sometimes outweighs the reduced
board space and problems getting parts.

Mind you for 32kB SRAM I find it easier to use FRAM parts as the
availability and pricing is often easier, for 5V parts. Well it
is in my normally small quantities.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On 2006-08-07, Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:

>>Ah.  You're right.  If Steve meant "H8/300" to exclude the "H"
>>"S" etc. models, then those are strictly 16-bit address space
>>parts.  I guess when I type "H8/300" I mean to include the
>>whole family. 
>
> That's the trouble with so much choice and trying to keep parts
> available for a long time.
>
>>> however most H8 users appear to be using H8/300H or H8/300S or
>>> H8/300SX cores with 16M addressing and RAM largest I have seen
>>> and evaluated is 32Kb (H8S/2329 and H8S/2378).
>>>
>>>>> 60K FLASH (256K AVR's)
>>>>
>>>>I'm using one with 128K, and evaluated models with 512K.
>>
>>That's one of the H8/300H varieties (H8/3062).
>
> Close H8/3067,

Doh!  I stuck that in the wrong spot.  I meant to add that
after the line where I said _I_ was using a 128K part.

>>I just wish some of the parts with CAN interfaces were cheaper.
>>For some reason, the H8 parts with CAN and a decent amount of
>>flash (128K+) are awfully expensive (in the $20 range).  What I
>>really want is 128K of flash, 16-24K of RAM, and CAN -- but it
>>costs about half as much to glue something together using a
>>3062, 32K SRAM, and an external CAN controller. :(
>
> With SRAM I find it easier to layout for one part that is new
> or in development Jedec pinout, but able to fit the current
> device in with lesser pins. The extra size and slight extra
> cost outweighs the availabilty issues of anything that appears
> to be smaller than 1Mb these days. Easier production sometimes
> outweighs the reduced board space and problems getting parts.
>
> Mind you for 32kB SRAM I find it easier to use FRAM parts as
> the availability and pricing is often easier, for 5V parts.
> Well it is in my normally small quantities.

Yup. SRAM parts that small are getting pretty scarce. Switching
to FRAM provides a way to provide some cool new data logging
features as well.

-- 
Grant Edwards                   grante             Yow!  NOW do I get to blow
                                  at               out the CANLDES??
                               visi.com            

"mc" <look@www.ai.uga.edu.for.address> skrev i meddelandet 
news:raHBg.3066$qd.2007@bignews3.bellsouth.net...
> Someone wrote:
>>>> You are probably saying that an 8 bit architecture is inherently
>>>> C-unfriendly.
>
> I think another idea lurking in the background here is that C expects a 
> Von Neumann architecture (same instructions to read from program memory as 
> from data memory) and most micros have Harvard architecture (reading from 
> pgm. and data memory are different kinds of operations).  The AVR is like 
> the 8051, PIC, etc., in this respect.  Among microcontrollers, the 68HC11 
> and MSP430 have Von Neumann architecture; almost all larger computers do 
> (Pentium, VAX, etc.).
>
> This is the source of the C string storage problem (how to avoid filling 
> up data memory with your string data).
>

"Embedded C" supports multiple address spaces.

Harvard architecture increases performance a lot in a micro due to increased 
bandwidth
but makes programming more complex.

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

> I just wish some of the parts with CAN interfaces were cheaper.
> For some reason, the H8 parts with CAN and a decent amount of
> flash (128K+) are awfully expensive (in the $20 range).  What I
> really want is 128K of flash, 16-24K of RAM, and CAN -- but it
> costs about half as much to glue something together using a
> 3062, 32K SRAM, and an external CAN controller. :(
>
> -- 


Maybe you can get an ARM7 with this.
AT91SAM7A3 would fit but has 256 kB of flash.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Hans-Bernhard Broeker wrote:
> mc <look@www.ai.uga.edu.for.address> wrote:
>>MSP430 have Von Neumann architecture; almost all larger computers do 
>>(Pentium, VAX, etc.).
> 
> Except that the "modern" ones often are von-Neumann only on the
> outside, whereas the core is actually Harvardian (separate
> lowest-level Caches for code and data).  x86 has been like that since
> about the Pentium II at least.

Well ... at the data bus and cache level they are "harvard",
but not at the address space level. Both instructions and
data are accessed from the same address space, and it is
the two different address spaces that conflict with the
implicit assumptions of the standard C language and libraries.



-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

On 2006-08-08, Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:

>> I just wish some of the parts with CAN interfaces were
>> cheaper. For some reason, the H8 parts with CAN and a decent
>> amount of flash (128K+) are awfully expensive (in the $20
>> range).  What I really want is 128K of flash, 16-24K of RAM,
>> and CAN -- but it costs about half as much to glue something
>> together using a 3062, 32K SRAM, and an external CAN
>> controller. :(

> Maybe you can get an ARM7 with this.

It would need be $8 or less to make it cheaper than the current
3-chip solution.

> AT91SAM7A3 would fit but has 256 kB of flash.

I'll take a look.  More flash is never a problem.  :)

-- 
Grant Edwards                   grante             Yow!  A can of ASPARAGUS,
                                  at               73 pigeons, some LIVE ammo,
                               visi.com            and a FROZEN DAQUIRI!!

On Mon, 07 Aug 2006 21:46:51 -0400, Michael N. Moran wrote:

> Hans-Bernhard Broeker wrote:
>> mc <look@www.ai.uga.edu.for.address> wrote:
>>>MSP430 have Von Neumann architecture; almost all larger computers do 
>>>(Pentium, VAX, etc.).
>> 
>> Except that the "modern" ones often are von-Neumann only on the
>> outside, whereas the core is actually Harvardian (separate
>> lowest-level Caches for code and data).  x86 has been like that since
>> about the Pentium II at least.
> 
> Well ... at the data bus and cache level they are "harvard",
> but not at the address space level. Both instructions and
> data are accessed from the same address space, and it is
> the two different address spaces that conflict with the
> implicit assumptions of the standard C language and libraries.

It's not just C, it's the whole notion of general-purpose libraries that
are broken by multiple address spaces (even assembly language libraries).
They're a mistake that early architects made in order to get the obviously
advantageous multiple-bus arrangements a bit simpler.  Modern processors
(and some older ones) still have multiple busses, but they operate within
a single address space. That way you don't need 3^n different versions of
memcpy(), to fit n different address spaces.

Cheers,

-- 
Andrew

On Fri, 4 Aug 2006 17:14:12 -0400, "mc"
<look@www.ai.uga.edu.for.address> wrote:

>"steve" <bungalow_steve@yahoo.com> wrote in message 
>news:1154666721.211509.298520@i42g2000cwa.googlegroups.com...
>
>> A common core is not too helpful as modern high level languages already
>> makes all cores "psuedo common" (except for timing).
>>
>> I rather have common memory maps, peripheral interfaces, electrical
>> characteristics and common pinouts with different cores, this way I
>> could just recompile...
>
>It would have been nice if AVR and PIC 8-pin micros had had the same pinout, 
>so they could really fight it out in the marketplace!
>

Some of the AVRs are pin compatible with standard 40-pin 8051 devices.
I doubt that Atmel sees the PIC as their main competitor. It seems
that most PIC proponents uses it more from a religious reason than for
any technical reason. Reading arguments of PIC vs whatever, is very
similar to the religious discussions regarding Hi-Fi equipment. 

Regards
  Anton Erasmus