PIC versus AVR

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

1.8V versions , I think so

part numbers please?

Reply to
steve
Loading thread data ...

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

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

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

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?
Reply to
Grant Edwards

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

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 a non-problem.

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

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

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.

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
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

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.

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
Reply to
Grant Edwards

"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
Reply to
Ulf Samuelsson

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
Reply to
Ulf Samuelsson

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
Reply to
Michael N. Moran

It would need be $8 or less to make it cheaper than the current

3-chip solution.

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!!
Reply to
Grant Edwards

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
Reply to
Andrew Reilly

The .cod file format supports path lengths beyond 62 characters and other changes as it and teh operating systems it will run on evolved beyond MS DOS.

w..

mc wrote:

Reply to
Walter Banks

Even from the beginning of the C on the PDP-11 it pretty well worked with separate I/D spaces (and that is exactly how the Harvard architecture is visible for the programmer).

Reply to
Arcady

The problem isn't separate I/D space, it's the need for non-volatile, read-only data. On Harvard architecture uC's usually the only way that can be accomplished is to put the "const" data into the "code" address space. Once you've done that, you've got the whole mess of dealing two different flavors of pointers, two different flavors of memcpy, four flavors of memcmp, etc.

--
Grant Edwards                   grante             Yow!  I'll take ROAST BEEF
                                  at               if you're out of LAMB!!
                               visi.com
Reply to
Grant Edwards

Precisely what I was thinking about. Thanks for elaborating it...

Reply to
mc

Or you adopt the practice of copying the const data to the stack before use. Takes a little extra time, but usually works quite ok and conserves RAM resource.

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

> Grant Edwards                   grante             Yow!  I'll take ROAST 
> BEEF
>                                  at               if you're out of LAMB!!
>                               visi.com
Reply to
Ulf Samuelsson

separate I/D

programmer).

As I understand the history, C was being developed before the PDP-11 was actually a product. Am I reading you correctly as suggesting that early PDP-11s (such as the PDP-11/20) had/have separate instruction and data memory spaces?

Jon

Reply to
Jonathan Kirwan

separate I/D

programmer).

IIRC, early ones didn't. Later ones did.

Unix on the 80268 worked pretty much the same way: a 64K data segment and a 64K text segment.

--
Grant Edwards                   grante             Yow!  I think I am an
                                  at               overnight sensation right
                               visi.com            now!!
Reply to
Grant Edwards

The first released PDP-11's mostly shipped to research centers. My lab at U of Waterloo had serial numbers 186 and 216 that were labelled PDP-11's By serial number 500 or so they were labelled PDP-11/20's same computer. These computers had a linear address space with 56K bytes RAM max and 8K of I/O space.

For nostalgia folks out there. I bought core memory for these computers at the then unheard of price of a $1 / Byte. This would be sometime in the early 70's . Yep the memory card that comes with your camera would have been worth millions.

w..

J> >

separate I/D

programmer).

Reply to
Walter Banks

Suffice it to say that const exists.

But it's not actually the only way, and it's not necessarily the best way, either. I.e. this usual choice is dubious.

Only if the compiler vendor didn't actually implement C, but only a limited subset of it. Because if he did, he must have put in a layer abstraction between a C pointer and what the CPU treats as an address.

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

separate I/D

programmer).

Yes, but arcady was saying "even from the beginning of" in regards to C and the PDP-11. This doesn't mean later PDP-11's, given the timing of events as I understand them.

Also, I happen to have a manual set for the PDP-11/70 (a somewhat later PDP-11 with memory management) and the purpose of the memory extensions was as much to just extend the physical memory on the system as anything else. It is mostly about "mapping" and constructing a virtual address space for programs, and not (as far as I can see) about separate code and data spaces. What I see is read only and read/write controls, for example.

I am just not at all sure what arcady was trying to say.

Well, that is a horse of a different color.

Jon

Reply to
Jonathan Kirwan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.