PIC versus AVR
mc
give me their impressions of the relative advantages of PIC vs AVR? Assume
that I will be using both, to some extent, for some time, and want to know
what their relative advantages are. Throw in MSP430 too if you'd like.
I'm mostly using PICs right now but am stuck on the fact that MPLAB requires
you to have write permissions in C:\Program Files (which we can't allow in a
big student lab with roaming profiles), and also, if you follow the
simplest, default path toward creating an ASM project, you run into a
62-character length limit on the full path to the file. Does AVR Studio
cooperate fully with normal Windows security practices, or does it, too,
require you to loosen security on the computer in order to run it?
larwe
mc wrote:
> I don't want to start a religious war, but could a few knowledgeable people
> give me their impressions of the relative advantages of PIC vs AVR? Assume
> that I will be using both, to some extent, for some time, and want to know
> what their relative advantages are. Throw in MSP430 too if you'd like.
Well, gee, I only just finished writing several thousand words on the
topic... here's the dime version:
PIC - Broad range of functionality and some special-purpose devices.
Can be inexpensive. Architecture is baroque and horrific. My
recommendation: only for small projects implemented entirely in
assembly language by confirmed masochists.
AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
broad range of devices. Much closer compatibility in the family than
amongst the different PIC flavors.
MSP430 - 16-bit, high performance, low power, von Neumann architecture.
VERY easy to work with. Code compatibility between parts is superb.
However, relatively expensive and not many devices in the family.
All three - Proprietary single-source architectures.
steve
mc wrote:
> I don't want to start a religious war, but could a few knowledgeable people
> give me their impressions of the relative advantages of PIC vs AVR? Assume
> that I will be using both, to some extent, for some time, and want to know
> what their relative advantages are. Throw in MSP430 too if you'd like.
>
MSP430), the one I choose for a particular project is the one has the
necessary amount of peripherals in the smallest package size, all
things being equal I will choose the MSP430 over a AVR, and the AVR
over the PIC.
MSP430 is 16 bits, has the highest performance analog I/O (and not
surprisingly is the most expensive and biggest in physical size). I
prefer the AVR architecture over the PIC, but the PIC is cheaper and
has better availability and more choices.
The application chooses the chip for me, though
steve
larwe wrote:
> All three - Proprietary single-source architectures.
there are multi-source architectures?
Spehro Pefhany
<bungalo...@yahoo.com> wrote:
8051 & ARM, for example.
mc
> topic... here's the dime version:
Previous postings here, or something else? I'd be glad to read it if you've
made a web site or something...
> PIC - Broad range of functionality and some special-purpose devices.
> Can be inexpensive. Architecture is baroque and horrific. My
> recommendation: only for small projects implemented entirely in
> assembly language by confirmed masochists.
*chuckle* That's me :)
> AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
> broad range of devices. Much closer compatibility in the family than
> amongst the different PIC flavors.
So I had noticed. It may be a bigger instruction set, but there are fewer
flavors of it...
> MSP430 - 16-bit, high performance, low power, von Neumann architecture.
> VERY easy to work with. Code compatibility between parts is superb.
> However, relatively expensive and not many devices in the family.
Ah! Didn't realize it was Von Neumann. Hmmm... A lot of what I do is
precision timing of one kind or another, and the ability to count to 65535
might be useful.
mc
That's as it should be, of course. A wise engineer knows the relative
merits of many different tools and will choose the one that is the best for
the job.
David Kelly
"mc" <lo...@www.ai.uga.edu.for.address> wrote:
> Does AVR Studio
> cooperate fully with normal Windows security practices, or does it, too,
> require you to loosen security on the computer in order to run it?
I stay as far away from Windows as I can, so I can't say that I've
looked deep enough at AVR Studio to answer your question. But I can say
that the Atmel team appears to be trying harder than the Microchip folks
at providing development tools. And unlike Microchip its actually
practical to code and debug an AVR without Windows.
AVR-gcc is a very good compiler. The packager of WinAVR (avr-gcc for
Windows) is now an Atmel employee. See above about "trying harder."
I realize in an academic environment at least one stage of the learning
process one stays limited to assembler. Once students get used to
assembler it can be enlightening for them to study the output of a C
compiler. I looked a lot at the output of avr-gcc. It never wrote
assembly that I could improve enough to justify the effort to rewrite in
assembly. Once or twice I changed a C expression for better assembly
output.
larwe
David Kelly wrote:
> compiler. I looked a lot at the output of avr-gcc. It never wrote
> assembly that I could improve enough to justify the effort to rewrite in
> assembly. Once or twice I changed a C expression for better assembly
Mmm, maybe. I'm currently evaluating avrgcc (with which I have a lot of
experience) against IAR and Rowley (with which I have relatively little
experience on AVR targets). There _are_ differences.
Jim Granville
Oh yes : 80C51, ARMx, MIPs, C166, x86.....
-jg
Jim Granville
Are you forced to install in C:\Program Files, or do you mean, you must
have write permissions to the EXE host directory ?
( which is slack of them, if true )
-jg
Grant Edwards
Except they aren't really multi-source. For example, you're
using an ARM single-chip solution from vendor A. It's not like
there's a drop-in replacement part from Vendor B: the
peripherals are all different from one source to th next.
Since all the work is in dealing with the peripherals, I find
almost zero benefit in switching to a second source with the
same core but a different set of peripherals.
--
Grant Edwards grante Yow! Are you still an
at ALCOHOLIC?
visi.com
steve
By multi-source I mean drop in replacement, pin-for-pin electrically
compatible, no code changes, I don't believe there are any modern
multi-source micro's. Silabs,Analog Devices, Atmel all make 8051's but
they make no attempt to standarized memory maps, modules interfaces,
pinouts, or even the most basic electrical characteristics etc, they
are all unique customized micro's.
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. Yes not a true multi-source part, but it does
allow me a "chance" of just replacing the old chip with the new one
without redesigning my board (assuming all the timing/emi etc look ok).
But obviously the amount of cooperation between companies to do this
would be mind boggling.
steve
Yvan BOURNE
You have the FREESCALE famillies too :
8 bits :
====
68HC908
9S08
16 bits :
=====
9S12
9S12X
The IDE CodeWarrior is free up to 16Ko of C code on 8 bits famillies and 32
Ko of C code on 16 bits famillies.
Yvan
"mc" <lo...@www.ai.uga.edu.for.address> a écrit dans le message de news:
WMxAg.42352$Nt.3...@bignews8.bellsouth.net...
Jim Granville
> Jim Granville wrote:
>
>>steve wrote:
>>
>>>larwe wrote:
>>>
>>>
>>>
>>>>All three - Proprietary single-source architectures.
>>>
>>>
>>>there are multi-source architectures?
>>
>>Oh yes : 80C51, ARMx, MIPs, C166, x86.....
>>
>>-jg
>
>
> By multi-source I mean drop in replacement, pin-for-pin electrically
> compatible, no code changes,
Then perhaps you should have said that, and not 'architectures' ? ;)
> I don't believe there are any modern
> multi-source micro's. Silabs,Analog Devices, Atmel all make 8051's but
> they make no attempt to standarized memory maps, modules interfaces,
> pinouts, or even the most basic electrical characteristics etc, they
> are all unique customized micro's.
At the 40/44 pin package point, there are truckloads of
socket-compatible 80C51's
Over a broader package range, 80C51's tend to have common
Timer0/Timer1/Timer2/PCA/UART/Interrupts, and P0..P3 are a common
denominator.
Remember tho, that one of the reasons the peripherals are different, is
to target different applications.
Clearly, every 80C51 variant should not have 24 bit ADCs, for example ?
> 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. Yes not a true multi-source part, but it does
> allow me a "chance" of just replacing the old chip with the new one
> without redesigning my board (assuming all the timing/emi etc look ok).
> But obviously the amount of cooperation between companies to do this
> would be mind boggling.
Yes, there is an argument for this approach - watch for what freescale
is doing with their RS08 and Coldfire V1 push.
It has the merit you mention, that "just recompile" is the holy grail.
The downside is, if the peripherals were sub-standard on the 8 bit one,
then you have the same rusty bucket of bolts on the 32 bit one! - and
the only reason to move is the core.
The commercial danger is, one part will merely cannibalize the market
of the other.
-jg
FreeRTOS.org
> using an ARM single-chip solution from vendor A. It's not like
> there's a drop-in replacement part from Vendor B: the
> peripherals are all different from one source to th next.
> Since all the work is in dealing with the peripherals, I find
> almost zero benefit in switching to a second source with the
> same core but a different set of peripherals.
This will change with the ARM Cortex-M3. Standard peripherals and standard
memory may. Of coarse a vendor can choose to ignore the standard if they so
wish.
Regards,
Richard.
http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
FreeRTOS.org
One big difference:
AVRGCC - single stack, does something odd when making function calls.
IAR, Rowley, ImageCraft - separate call and data stacks to prevent the
necessity for the above odd thing.
FreeRTOS.org
> have write permissions to the EXE host directory ?
> ( which is slack of them, if true )
I have both MPLAB and AVRStudio installed in c:\devtools.
Jim Granville
>>Except they aren't really multi-source. For example, you're
>>using an ARM single-chip solution from vendor A. It's not like
>>there's a drop-in replacement part from Vendor B: the
>>peripherals are all different from one source to th next.
>>Since all the work is in dealing with the peripherals, I find
>>almost zero benefit in switching to a second source with the
>>same core but a different set of peripherals.
>
> This will change with the ARM Cortex-M3. Standard peripherals and standard
> memory map. Of course a vendor can choose to ignore the standard if they so
> wish.
... and they may wish to do that, as the Cortex peripherals are rather
'ordinary/below par' for a new 32 bit core offering :
No Up/Down or quadrature modes, and only 16 bit capture ?
PWM edge resolution is only = Core clk speed, 4Mhz spi speed... ?
They don't look like they were designed by a perpipheral expert.
Will be interesting to see how the Freescale Coldfire V1 peripherals
match against that. Freescale has a lot more experience at peripheral
design.
-jg
Grant Edwards
>> Except they aren't really multi-source. For example, you're
>> using an ARM single-chip solution from vendor A. It's not like
>> there's a drop-in replacement part from Vendor B: the
>> peripherals are all different from one source to th next.
>> Since all the work is in dealing with the peripherals, I find
>> almost zero benefit in switching to a second source with the
>> same core but a different set of peripherals.
>
> This will change with the ARM Cortex-M3. Standard peripherals and standard
> memory may. Of coarse a vendor can choose to ignore the standard if they so
> wish.
And they most certainly will. Since the vendor of an ARM part
can't differentiate their product based on the core
architecture, they'll try to differentiate it based on
peripherals. Nobody really _wants_ to be a second source.
--
Grant Edwards grante Yow! Where's th' DAFFY
at DUCK EXHIBIT??
visi.com
Grant Edwards
>>
>>
>>> compiler. I looked a lot at the output of avr-gcc. It never wrote
>>> assembly that I could improve enough to justify the effort to rewrite in
>>> assembly. Once or twice I changed a C expression for better assembly
>>
>> Mmm, maybe. I'm currently evaluating avrgcc (with which I have a lot of
>> experience) against IAR and Rowley (with which I have relatively little
>> experience on AVR targets). There _are_ differences.
>
> One big difference:
>
> AVRGCC - single stack, does something odd when making function calls.
>
> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the
> necessity for the above odd thing.
And yet people claim the AVR was designed to be C-friendly.
I've looked at AVR code generaged by GCC and IAR. The AVR is
not C-friendly. It may not be actively hostile like the 8051
or PIC, but it's not C friendly.
Any processor that falls over when you attempt to do any
pointer manipulation isn't C-friendly.
--
Grant Edwards grante Yow! Yow! Maybe I should
at have asked for my Neutron
visi.com Bomb in PAISLEY--
larwe
mc wrote:
> > Well, gee, I only just finished writing several thousand words on the
> > topic... here's the dime version:
>
> Previous postings here, or something else? I'd be glad to read it if you've
> made a web site or something...
Both. There was a long thread in this NG recently, I think the title
was something like "about the MSP430", and we got into pros and cons of
these three architectures. Some very detailed stuff in there, IIRC from
Senor Kirwan.
> > AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>
> So I had noticed. It may be a bigger instruction set, but there are fewer
> flavors of it...
I have a strong pro-AVR bias. I've had ongoing good luck with all my
AVR-based projects; things have "just worked". With the MSP430 there
are so many switchable options that I have trouble working out why
things don't work right.
> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
> > VERY easy to work with. Code compatibility between parts is superb.
> > However, relatively expensive and not many devices in the family.
>
> Ah! Didn't realize it was Von Neumann. Hmmm... A lot of what I do is
It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
isn't EEPROM) area is mapped straight into the normal memory map, not
the usual address/data registers found in other parts. It's very easy
to use.
> precision timing of one kind or another, and the ability to count to 65535
> might be useful.
The MSP430 is quite rich in timer and capture/compare goodies. If you
want to play with it, invest in the $20 ez430 demo/development kit;
this is a full debugger with a small target board (2K flash). The
debugger only works with the most recent chips, since it uses TI's new
2-wire protocol. For older chips you'll need a flash emulation tool
[JTAG debugger]; Olimex sells those for US$20 in a parallel port
version, more for the USB version.
The 2K target is inside the 4K limit of the free C compiler provided
with the kit, so you can work in asm or C (or even C++) according to
your particular fetish.
larwe
> And yet people claim the AVR was designed to be C-friendly.
That was explicitly the design intent; it's not a claim, but a
published fact.
Note that the explicit design intent of the observation platform atop
the Empire State Building was for (dis)embarkation of lighter-than-air
aircraft.
Paul Carpenter
no....@designtools.co.nz "Jim Granville" wrote:
Unfortuntely most of the vendor apps are written by PC applications
programmers, who assume everybody is on a STANDALONE PC! Programmes that
force storing of project details into the installed programme directory
are the NORM not the exception. Very few have network deployment methods.
I would not surprised if the apps want to write all sorts of files in their
installed directory and not into a project directory.
As the original poster was talking about a univerity type lab which would be
on a university network, with all sorts of restrictions such as users cannot
install programmes and their work is over the network so their "My Documents"
is actually on a server, along with the user portion of registry. Often in
these situations the user has no write access directly to local drives! Nor
would I wnt to is some eductaion establishments.
Come acros this problem often as the other half (SWMBO) runs a school network
with some 7 servers and over 250 workstations around the school. Scanners,
and digital cameras can be the worst culprits for wanting to create their
wonderful 'albums' and catalogues in the program directory. Then you can
get printers that want to create their own print spooler and need a directory
for it, usually under the program directory and you cannot change it.
--
Paul Carpenter | pa...@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
FreeRTOS.org
This is a private school then, right?
Grant Edwards
> Grant Edwards wrote:
>
>> And yet people claim the AVR was designed to be C-friendly.
>
> That was explicitly the design intent; it's not a claim, but a
> published fact.
Touché.
I should have been whinging about the claim that the AVR _is_
C-friendly. :)
> Note that the explicit design intent of the observation platform atop
> the Empire State Building was for (dis)embarkation of lighter-than-air
> aircraft.
That sure would have been something worth seeing.
--
Grant Edwards grante Yow! Now I'm concentrating
at on a specific tank battle
visi.com toward the end of World
War II!
Jonathan Kirwan
>mc wrote:
>> > Well, gee, I only just finished writing several thousand words on the
>> > topic... here's the dime version:
>>
>> Previous postings here, or something else? I'd be glad to read it if you've
>> made a web site or something...
>
>Both. There was a long thread in this NG recently, I think the title
>was something like "about the MSP430", and we got into pros and cons of
>these three architectures. Some very detailed stuff in there, IIRC from
>Senor Kirwan.
;)
>> > AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>>
>> So I had noticed. It may be a bigger instruction set, but there are fewer
>> flavors of it...
>
>I have a strong pro-AVR bias. I've had ongoing good luck with all my
>AVR-based projects; things have "just worked". With the MSP430 there
>are so many switchable options that I have trouble working out why
>things don't work right.
>
>> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> > VERY easy to work with. Code compatibility between parts is superb.
>> > However, relatively expensive and not many devices in the family.
>>
>> Ah! Didn't realize it was Von Neumann. Hmmm... A lot of what I do is
>
>It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
>isn't EEPROM) area is mapped straight into the normal memory map, not
>the usual address/data registers found in other parts. It's very easy
>to use.
>
>> precision timing of one kind or another, and the ability to count to 65535
>> might be useful.
>
>The MSP430 is quite rich in timer and capture/compare goodies.
This is a serious strength of the MSP430. If there is one thing and
only one thing permitted to be said about the MSP430 peripherals, it
would have to be the timers. The B7 section available on some parts
has 7 capture/compares on it. Unusual and... at times... very useful.
Jon
Wilco Dijkstra
"Jim Granville" <no....@designtools.co.nz> wrote in message
news:44d309c7$1...@clear.net.nz...
> FreeRTOS.org wrote:
>
>>>Except they aren't really multi-source. For example, you're
>>>using an ARM single-chip solution from vendor A. It's not like
>>>there's a drop-in replacement part from Vendor B: the
>>>peripherals are all different from one source to th next.
>>>Since all the work is in dealing with the peripherals, I find
>>>almost zero benefit in switching to a second source with the
>>>same core but a different set of peripherals.
>>
>> This will change with the ARM Cortex-M3. Standard peripherals and
>> standard memory map. Of course a vendor can choose to ignore the
>> standard if they so wish.
No, the standard M3 peripherals such as the interrupt controller/
timer/profiler/breakpoint unit are defined by ARM and cannot be
changed. Neither can the memory map. Due to this there is almost
no need in porting RTOSes, debuggers etc when moving between
different devices.
Other peripherals like UARTs are not standardised. The major MCU
manufacturers already have their own, so there is little chance of
standardisation.
> ... and they may wish to do that, as the Cortex peripherals are rather
> 'ordinary/below par' for a new 32 bit core offering :
>
> No Up/Down or quadrature modes, and only 16 bit capture ?
> PWM edge resolution is only = Core clk speed, 4Mhz spi speed... ?
These are Luminary peripherals. The Cortex-M3 peripherals are
described in the TRM. You can add more peripherals but you
can't change/remove the standard ones.
Wilco
Paul Carpenter
<R1KAg.111634$wl.2...@text.news.blueyonder.co.uk>
nos...@thanks.com "FreeRTOS.org" wrote:
>> with some 7 servers and over 250 workstations around the school. Scanners,
>
>This is a private school then, right?
Yes, but state schools are not that dissimilar as this includes administartion
and staff systems as well.
larwe
Paul Carpenter wrote:
> Come acros this problem often as the other half (SWMBO) runs a school network
> with some 7 servers and over 250 workstations around the school. Scanners,
> and digital cameras can be the worst culprits for wanting to create their
> wonderful 'albums' and catalogues in the program directory. Then you can
> get printers that want to create their own print spooler and need a directory
> for it, usually under the program directory and you cannot change it.
At least the diags tools are better now. I used to be the lead
programmer on a product called pcLockout (the company is now defunct).
The school version of this product, which worked on DOS, Win3.x and
Win95/98, had as one of its major features the ability to write-protect
the hard disk at the int 21h, int 13h and int 26h levels. (I also wrote
a VxD that hooked the file I/O functions to do the file-level
protection in Win9x without compromising 32BFA).
The software those people used wanted all sorts of things to be
writable; it was a REAL bear to get even CD-ROM software working.
Before I came to the company, the schools would send us copies of the
malfunctioning applications and the support guy would sit down and
figure out what it was trying to write, then we'd tell the school what
filespecs to put in the wildcard list.
The best thing I ever did was to build some slightly clever code that
would log file write accesses to a text file (this is nontrivial in
DOS, because int 21h is not reentrant, and TSRs on top of it usually
aren't either!). Another programmer later wrote a program that parsed
the log file and automatically made some best guesses at which files
needed to be put in the exception (always-writable) list.
Since you can't write-protect the registry in Win9x, we did some exotic
backup and restore stuff on those files.
Oh, those were the good old days, to be sure.
mc
> looked deep enough at AVR Studio to answer your question. But I can say
> that the Atmel team appears to be trying harder than the Microchip folks
> at providing development tools. And unlike Microchip its actually
> practical to code and debug an AVR without Windows.
That's good; that means they're aware of PC operating systems. If they
support two, they'll probably support *both* of them better than if they had
only supported one, because every OS opens your eyes to important
characteristics of other OSes.
> AVR-gcc is a very good compiler. The packager of WinAVR (avr-gcc for
> Windows) is now an Atmel employee. See above about "trying harder."
That also sounds like a very good move. gcc of course has a long reputation
for high reliability.
> I realize in an academic environment at least one stage of the learning
> process one stays limited to assembler. Once students get used to
> assembler it can be enlightening for them to study the output of a C
> compiler. I looked a lot at the output of avr-gcc. It never wrote
> assembly that I could improve enough to justify the effort to rewrite in
> assembly. Once or twice I changed a C expression for better assembly
> output.
Yes... this is how you learn what a compiler does.
mc
>> cooperate fully with normal Windows security practices, or does it, too,
>> require you to loosen security on the computer in order to run it?
>
> Are you forced to install in C:\Program Files, or do you mean, you must
> have write permissions to the EXE host directory ?
> ( which is slack of them, if true )
The latter. Microchip MPLAB requires you to have write permissions in
something under C:\Program Files, presumably its own directory. I don't
know what it writes there, or whether different users of the same computer
will disrupt each other. In order to use MPLAB we have to loosen security
on our computers by letting all users write in that directory.
mc
news:1154701706.3...@p79g2000cwp.googlegroups.com...
>> > MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> > VERY easy to work with. Code compatibility between parts is superb.
>> > However, relatively expensive and not many devices in the family.
>>
>> Ah! Didn't realize it was Von Neumann. Hmmm... A lot of what I do is
>
> It's very von Neumann. Even the in-program-rewritable "EEPROM" (it
> isn't EEPROM) area is mapped straight into the normal memory map, not
> the usual address/data registers found in other parts. It's very easy
> to use.
Easy for a COMPILER to use, in particular, I'll bet!
>> precision timing of one kind or another, and the ability to count to
>> 65535
>> might be useful.
>
> The MSP430 is quite rich in timer and capture/compare goodies. If you
> want to play with it, invest in the $20 ez430 demo/development kit;
> this is a full debugger with a small target board (2K flash).
Right -- we were just talking about how to hack the ez430 to also program
DIP versions of the chip. Small matter of finding a connector with the pins
0.05 inch apart...
> The 2K target is inside the 4K limit of the free C compiler provided
> with the kit, so you can work in asm or C (or even C++) according to
> your particular fetish.
C++? Now what I'd like to see is a microcontroller subset of C#... clearly
the whole C# language is not appropriate, but it ought to be able to extract
a Pascal-like subset for expressing algorithms on small CPUs.
mc
news:1154666721.2...@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!
mc
>>have write permissions to the EXE host directory ?
>>( which is slack of them, if true )
>
> Unfortuntely most of the vendor apps are written by PC applications
> programmers, who assume everybody is on a STANDALONE PC! Programmes that
> force storing of project details into the installed programme directory
> are the NORM not the exception. Very few have network deployment methods.
>
> I would not surprised if the apps want to write all sorts of files in
> their
> installed directory and not into a project directory.
And I call that inept application programming. Microsoft has been
recommending against it for, what, 6 years or more?
> As the original poster was talking about a univerity type lab which would
> be
> on a university network, with all sorts of restrictions such as users
> cannot
> install programmes and their work is over the network so their "My
> Documents"
> is actually on a server, along with the user portion of registry. Often in
> these situations the user has no write access directly to local drives!
> Nor
> would I wnt to is some eductaion establishments.
Exactly! In ours, the user can make a directory of his own on C: and write
in it, but if he does, his files will not roam with him to the next computer
he logs in on. If we were more fastidious we'd disallow writing on C:
altogether, except for the area containing the user's copied profile.
The thing is, UNIX programmers have known for nearly 30 years that ordinary
users aren't supposed to write in directories other than /home/username (or
what have you).
mc
>> > topic... here's the dime version:
>>
>> Previous postings here, or something else? I'd be glad to read it if
>> you've
>> made a web site or something...
>
> Both. There was a long thread in this NG recently, I think the title
> was something like "about the MSP430", and we got into pros and cons of
> these three architectures. Some very detailed stuff in there, IIRC from
> Senor Kirwan.
Thanks. I just found your web site and realized who you are. I read your
shoestring book quickly a while back and enjoyed it. I'm a book author
myself (www.covingtoninnovations.com/books.html) but not in this exact
field. (Yet! :)
All this is very useful. Thanks for posting it.
Jim Granville
Just to clarify, what you call standard peripherals, is then the
interrupt controller/timer/profiler/breakpoint unit
[Rather like the MDI potion of the ARM7TMDI standard ? ]
( and timer here is part of profiler, not a generic timer ? )
- what most uC users would call peripherals, like
ADC/UART/CaptureCompare/UpDnCounters/PWM,
are all "not standardised" ?
I'm not sure how you can make different sizes of RAM and CODE, and
NOT change the memory map, but perhaps you meant 'base addresses' or
similar ?
-jg
Paul Carpenter
<1154718657.2...@b28g2000cwb.googlegroups.com>
zwsd...@gmail.com "larwe" wrote:
>Paul Carpenter wrote:
>
>> Come acros this problem often as the other half (SWMBO) runs a school network
>> with some 7 servers and over 250 workstations around the school. Scanners,
>> and digital cameras can be the worst culprits for wanting to create their
>> wonderful 'albums' and catalogues in the program directory. Then you can
>> get printers that want to create their own print spooler and need a directory
>> for it, usually under the program directory and you cannot change it.
>
>At least the diags tools are better now. I used to be the lead
>programmer on a product called pcLockout (the company is now defunct).
>The school version of this product, which worked on DOS, Win3.x and
>Win95/98, had as one of its major features the ability to write-protect
>the hard disk at the int 21h, int 13h and int 26h levels. (I also wrote
>a VxD that hooked the file I/O functions to do the file-level
>protection in Win9x without compromising 32BFA).
>
>The software those people used wanted all sorts of things to be
>writable; it was a REAL bear to get even CD-ROM software working.
There is a lot of stuff written for/by supposedly big and reputable companies
that is a pile of crock.
>Before I came to the company, the schools would send us copies of the
>malfunctioning applications and the support guy would sit down and
>figure out what it was trying to write, then we'd tell the school what
>filespecs to put in the wildcard list.
Seen a similar thing on Fortress 101, used to lock down a PC running
Win9x at a hotel so that the night staff did not visit websites and
install all sorts of things. It looks like at another of the hotels
in the group I may have to do the same thing as they have problems
with itchy fingers and download anything staff, especially at night.
>The best thing I ever did was to build some slightly clever code that
>would log file write accesses to a text file (this is nontrivial in
>DOS, because int 21h is not reentrant, and TSRs on top of it usually
>aren't either!). Another programmer later wrote a program that parsed
>the log file and automatically made some best guesses at which files
>needed to be put in the exception (always-writable) list.
>
>Since you can't write-protect the registry in Win9x, we did some exotic
>backup and restore stuff on those files.
>
>Oh, those were the good old days, to be sure.
Personally if more systems had lock downs on them, there would be LESS
problems and in a lot of organisations, it would not be buy it and sort
problems out later, over time most people would get to learn that it has
to be tested to ensure it will work OK.
By lockdowns I do not mean the poor attempt on Windows to have workstation
user/permissions, that is nearly always circumvented as all users have
to have LOCAL administrator rights for the crap applications to run.
Jim Granville
Have you raised this with microchip ? - it is by no means a unique
problem, and they do need to clean up their act, so point all this out
to them.
If they realise MPLAB is being _removed_ from educational classes
because of simply slack SW design, I'm sure they'll move very fast to
remedy it. [ well, they should; if they can't be bothered, then they
deserve the consequence ]
Would having the project directory on a FLASH drive be a security risk
? - I see they are getting ever cheaper.
-jg
mc
>> something under C:\Program Files, presumably its own directory. I don't
>> know what it writes there, or whether different users of the same
>> computer will disrupt each other. In order to use MPLAB we have to
>> loosen security on our computers by letting all users write in that
>> directory.
>
> Have you raised this with microchip ? - it is by no means a unique
> problem, and they do need to clean up their act, so point all this out to
> them.
Yes, I've been corresponding with them about this. I'm also pressing them
to make the old 62-character path length limit go away, because it is now
very common for paths on a Windows system to be that long or longer
(C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm).
The limit is actually in the .COD file format, which they don't control.
You can work around it by first adding a linker script to your project (so
the linker will run, rather than assembling directly to HEX) and then
turning off COD file generation. I argue that this should actually be the
default, since there are more people who need long paths than people who
need COD files.
> If they realise MPLAB is being _removed_ from educational classes because
> of simply slack SW design, I'm sure they'll move very fast to remedy it.
> [ well, they should; if they can't be bothered, then they deserve the
> consequence ]
>
> Would having the project directory on a FLASH drive be a security risk
> ? - I see they are getting ever cheaper.
Actually, that's how we did a lot of our projects last year! Flash drive
reliability isn't perfect and I urge people to make hard-disk copies often.
mc
> user/permissions, that is nearly always circumvented as all users have
> to have LOCAL administrator rights for the crap applications to run.
The Windows permission system works fine except for -- as you say -- the
ineptly written applications that require the user to have more rights than
a user is supposed to have.
I am a strong believer in blacklisting such software: "THIS SOFTWARE
ENDANGERS THE SECURITY OF THE COMPUTER ON WHICH IT IS INSTALLED."
CBFalconer
Please do not strip attribution lines (Joe said) for material you
quote. For example, "who you are" is meaningless without the
attributions.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!
mc
"CBFalconer" <cbfal...@yahoo.com> wrote in message
news:44D402FD...@yahoo.com...
> mc wrote:
>>
larwe wrote:
>>>>> Well, gee, I only just finished writing several thousand words
>>>>> on the topic... here's the dime version:
>>>>
mc wrote:
>>>> Previous postings here, or something else? I'd be glad to read
>>>> it if you've made a web site or something...
>>>
larwe wrote:
>>> Both. There was a long thread in this NG recently, I think the
>>> title was something like "about the MSP430", and we got into pros
>>> and cons of these three architectures. Some very detailed stuff
>>> in there, IIRC from Senor Kirwan.
>>
mc wrote:
>> Thanks. I just found your web site and realized who you are. I
>> read your shoestring book quickly a while back and enjoyed it.
>> I'm a book author myself (www.covingtoninnovations.com/books.html)
>> but not in this exact field. (Yet! :)
>>
>> All this is very useful. Thanks for posting it.
>
> Please do not strip attribution lines (Joe said) for material you
> quote. For example, "who you are" is meaningless without the
> attributions.
Sorry, my oversight. Missing data restored above.
Mike Harrison
>> I stay as far away from Windows as I can, so I can't say that I've
>> looked deep enough at AVR Studio to answer your question. But I can say
>> that the Atmel team appears to be trying harder than the Microchip folks
>> at providing development tools. And unlike Microchip its actually
>> practical to code and debug an AVR without Windows.
>
>That's good; that means they're aware of PC operating systems. If they
>support two, they'll probably support *both* of them better than if they had
>only supported one, because every OS opens your eyes to important
>characteristics of other OSes.
I have used both AVR Studio and MPLAB extensively (On Win2000) and AVR Studio has been consistently
significantly more flaky and problematic than MPLAB over many years. AVR Studio's editor still
doesn't work properly in debug mode FFS!
Aly
"mc" <lo...@www.ai.uga.edu.for.address> wrote in message
news:TDTAg.46058$Nt.4...@bignews8.bellsouth.net...
>
> Yes, I've been corresponding with them about this. I'm also pressing them
> to make the old 62-character path length limit go away, because it is now
> very common for paths on a Windows system to be that long or longer
> (C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm).
> The limit is actually in the .COD file format, which they don't control.
>
There is a partial solution, SUBST. All of my dev work and directories are
on drive G:
Subst allows a directory to be mapped as a drive, it's an old DOS command.
Also still shipped with XP too. :) It's partner is JOIN.
SUBST G: D:\Program Files\Microchip\MPASM Suite
Wilco Dijkstra
> Wilco Dijkstra wrote:
>> These are Luminary peripherals. The Cortex-M3 peripherals are
>> described in the TRM. You can add more peripherals but you
>> can't change/remove the standard ones.
>
> Just to clarify, what you call standard peripherals, is then the
> interrupt controller/timer/profiler/breakpoint unit
> [Rather like the MDI potion of the ARM7TMDI standard ? ]
> ( and timer here is part of profiler, not a generic timer ? )
Yes, you could think of it as core and debug oriented peripherals,
but it's not at all like the ARM7tdmi (which doesn't have any of this
apart from JTAG based break points and watch points).
There is a 24-bit timer in the NVIC which can be used as software
watchdog, OS tick or a general timer. The 32-bit counter in the
DWT is used for performance monitoring and profiling.
> - what most uC users would call peripherals, like
> ADC/UART/CaptureCompare/UpDnCounters/PWM,
> are all "not standardised" ?
Correct.
> I'm not sure how you can make different sizes of RAM and CODE, and
> NOT change the memory map, but perhaps you meant 'base addresses' or
> similar ?
Yes, the standard memory map defines where flash/RAM/perhiperhal
space is, which areas support bit banding etc. The actual memory size
is device specific of course.
Wilco
mc
news:b4GdnYEHTPX...@bt.com...
>
> "mc" <lo...@www.ai.uga.edu.for.address> wrote in message
> news:TDTAg.46058$Nt.4...@bignews8.bellsouth.net...
>>
>> Yes, I've been corresponding with them about this. I'm also pressing
>> them
>> to make the old 62-character path length limit go away, because it is now
>> very common for paths on a Windows system to be that long or longer
>> (C:\Documents and Settings\blahblah\My Documents\PIC
>> projects\myprog.asm).
>> The limit is actually in the .COD file format, which they don't control.
>
> Subst allows a directory to be mapped as a drive, it's an old DOS command.
> Also still shipped with XP too. :) It's partner is JOIN.
> SUBST G: D:\Program Files\Microchip\MPASM Suite
Yes, I know, but end users in 2006 ought not to have to do kluges like this
to run the current version of software.
Aly
"mc" <lo...@www.ai.uga.edu.for.address> wrote in message
>
> Yes, I know, but end users in 2006 ought not to have to do kluges like
this
> to run the current version of software.
>
>
Ideally in 2006 we wouldn't be needing electricity generated from burning
prehistoric animals that died a million years ago.
You wanted a solution, I gave it to you.
ku7485
memory, functionality (I'm not really sure about the third one
though).The fastest dsPIC in DIP package goes 30MIPS (10MIPS faster
than the AVR). The fastest dsPIC goes 40MIPS, has 144kilobytes of flash
and has 8192bytes of SRAM.
mc
I already knew several workarounds. My point is that the manufacturer
should fix the product so it doesn't require workarounds in order to run
today's software under today's operating systems. Windows has had long
filenames for 11 years. DOS isn't coming back. The future is entirely in
the future.
David Kelly
"mc" <lo...@www.ai.uga.edu.for.address> wrote:
> Yes, I've been corresponding with them about this. I'm also pressing them
> to make the old 62-character path length limit go away, because it is now
> very common for paths on a Windows system to be that long or longer
> (C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm).
> The limit is actually in the .COD file format, which they don't control.
Microchip MPLAB writes an intermediary file format that is not of their
own design?
> You can work around it by first adding a linker script to your project (so
> the linker will run, rather than assembling directly to HEX) and then
> turning off COD file generation. I argue that this should actually be the
> default, since there are more people who need long paths than people who
> need COD files.
Is MPLAB still a 16-bit application?
One of my biggest gripes last time I used it (IIRC 5.x) was how projects
could not be moved from their original path. The whole path, rather than
relative path, was stored in the binary project file. Was a royal pain
to surf all the menus and submenus looking to correct filename paths.
mc
"David Kelly" <n4...@yahoo.com> wrote in message
news:n4hhe-0DC73B....@ispnews.usenetserver.com...
> In article <TDTAg.46058$Nt.4...@bignews8.bellsouth.net>,
> "mc" <lo...@www.ai.uga.edu.for.address> wrote:
>
>> Yes, I've been corresponding with them about this. I'm also pressing
>> them
>> to make the old 62-character path length limit go away, because it is now
>> very common for paths on a Windows system to be that long or longer
>> (C:\Documents and Settings\blahblah\My Documents\PIC
>> projects\myprog.asm).
>> The limit is actually in the .COD file format, which they don't control.
>
> Microchip MPLAB writes an intermediary file format that is not of their
> own design?
That's what they tell me!
>
>> You can work around it by first adding a linker script to your project
>> (so
>> the linker will run, rather than assembling directly to HEX) and then
>> turning off COD file generation. I argue that this should actually be
>> the
>> default, since there are more people who need long paths than people who
>> need COD files.
>
> Is MPLAB still a 16-bit application?
Not as far as I can tell, but I don't have utilities handy that will tell me
for sure.
> One of my biggest gripes last time I used it (IIRC 5.x) was how projects
> could not be moved from their original path. The whole path, rather than
> relative path, was stored in the binary project file. Was a royal pain
> to surf all the menus and submenus looking to correct filename paths.
I don't *think* it still has that limitation.
Ulf Samuelsson
>
>> AVR - Designed specifically to be C-friendly. Easy to learn. _Fairly_
>> broad range of devices. Much closer compatibility in the family than
>> amongst the different PIC flavors.
>
> So I had noticed. It may be a bigger instruction set, but there are fewer
> flavors of it...
>
>> MSP430 - 16-bit, high performance, low power, von Neumann architecture.
>> VERY easy to work with. Code compatibility between parts is superb.
>> However, relatively expensive and not many devices in the family.
>
> Ah! Didn't realize it was Von Neumann. Hmmm... A lot of what I do is
> might be useful.
>
>
With the right compiler you are in luck.
The IAR AVR C compiler allows you to do
#define MHz 12
#define delay_us(x) __delay_cycles(x * MHz)
Which means you get an exact delay in C.
Probably available for some other compilers/architectures as well,but it is
nice to know
you can have it at all...
The register intensive AVR architecture makes it easy for the compiler to do
16/32 bit math.
--
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
Ulf Samuelsson
>>
>> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the
>> necessity for the above odd thing.
>
> And yet people claim the AVR was designed to be C-friendly.
> I've looked at AVR code generaged by GCC and IAR. The AVR is
> not C-friendly. It may not be actively hostile like the 8051
> or PIC, but it's not C friendly.
>
> Any processor that falls over when you attempt to do any
> pointer manipulation isn't C-friendly.
>
> --
You are probably saying that an 8 bit architecture is inherently
C-unfriendly.
If you start in the other end: How do you make an 8 bit architecture which
is C-friendly
you may come to a different conclusion.
From this viewpoint it is "C-friendly" to use 2 instructions for 16 bit
operations
and 4 instructions to do 32 bit operations.
Grant Edwards
>>> AVRGCC - single stack, does something odd when making function calls.
>>>
>>> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the
>>> necessity for the above odd thing.
>>
>> And yet people claim the AVR was designed to be C-friendly.
>> I've looked at AVR code generaged by GCC and IAR. The AVR is
>> not C-friendly. It may not be actively hostile like the 8051
>> or PIC, but it's not C friendly.
>>
>> Any processor that falls over when you attempt to do any
>> pointer manipulation isn't C-friendly.
> You are probably saying that an 8 bit architecture is inherently
> C-unfriendly.
The big problem I see with the AVR is that only one (or is it
two) register pairs can be used as a pointer. A good
C-friendly architecture would be able to handle more than one
pointer at a time.
> If you start in the other end: How do you make an 8 bit
> architecture which is C-friendly you may come to a different
> conclusion.
Allow any register pair to be used for pointers, mainly.
> From this viewpoint it is "C-friendly" to use 2 instructions
> for 16 bit operations and 4 instructions to do 32 bit
> operations.
That's fine -- the problem I've seen is that code that has to
use multiple pointers thrashes because the AVR can only deal
with 1-2 pointers at a time.
--
Grant Edwards grante Yow! My polyvinyl cowboy
at wallet was made in Hong
visi.com Kong by Montgomery Clift!
Grant Edwards
>>>
>>> IAR, Rowley, ImageCraft - separate call and data stacks to prevent the
>>> necessity for the above odd thing.
>>
>> And yet people claim the AVR was designed to be C-friendly.
>> I've looked at AVR code generaged by GCC and IAR. The AVR is
>> not C-friendly. It may not be actively hostile like the 8051
>> or PIC, but it's not C friendly.
>>
>> Any processor that falls over when you attempt to do any
>> pointer manipulation isn't C-friendly.
>>
>> --
>
> You are probably saying that an 8 bit architecture is inherently
> C-unfriendly.
> If you start in the other end: How do you make an 8 bit architecture which
> is C-friendly
> you may come to a different conclusion.
>
> From this viewpoint it is "C-friendly" to use 2 instructions for 16 bit
> operations
> and 4 instructions to do 32 bit operations.
>
>
--
Grant Edwards grante Yow! BRILL CREAM is
at CREAM O' WHEAT in another
visi.com DIMENSION...
Grant Edwards
>> Any processor that falls over when you attempt to do any
>> pointer manipulation isn't C-friendly.
> You are probably saying that an 8 bit architecture is
> inherently C-unfriendly.
After thinking more about the question, yes, an 8-bit
architecture is inherently more C-unfriendly than one which
supports "pointer-length" operations.
> If you start in the other end: How do you make an 8 bit
> architecture which is C-friendly you may come to a different
> conclusion.
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.
> From this viewpoint it is "C-friendly" to use 2 instructions
> for 16 bit operations and 4 instructions to do 32 bit
> operations.
Not as C-friendly as using 1. :)
--
Grant Edwards grante Yow! MY income is ALL
at disposable!
visi.com
Mikael Ejberg Pedersen
wrote:
>The big problem I see with the AVR is that only one (or is it
>two) register pairs can be used as a pointer.
It's actually three register pairs.
Though only one of them is able to address the program memory, but
I've never had the need to point to more than one place in program
memory at a time.
And I just love the AVR instruction that addresses indirectly with
displacement. That is really useful for pointers to structs. And that
is a C friendly instruction if I ever saw one.
Best regards,
Mikael
--
Mikael Ejberg Pedersen
http://www.ejberg.dk
Grant Edwards
> On Sun, 06 Aug 2006 14:58:02 -0000, Grant Edwards <gra...@visi.com>
> wrote:
>
>>The big problem I see with the AVR is that only one (or is it
>>two) register pairs can be used as a pointer.
>
> It's actually three register pairs.
That's not as bad as I remembered.
> Though only one of them is able to address the program memory, but
> I've never had the need to point to more than one place in program
> memory at a time.
That would be pretty rare.
--
Grant Edwards grante Yow! ... I'm IMAGINING a
at sensuous GIRAFFE, CAVORTING
visi.com in the BACK ROOMof a KOSHER
DELI --
steve
> 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) 60K FLASH (256K
AVR's), requires 50% more power, are physically bigger, have no
EEPROM, limited selection, there is a price to pay in die size when you
move up to a 16 bit processor which can make your life harder it other
aspects, I also seem to remember doing a H8/300 16 bit multiply was
slower then a AVR's 16 bit multiply and generally slower in all
instructions, so it's not so cut and dry as you imply if you dig into
the details. The MSP430's are not cheaper then the AVR's.
Ulf Samuelsson
>> C-unfriendly.
>
> The big problem I see with the AVR is that only one (or is it
> two) register pairs can be used as a pointer. A good
> C-friendly architecture would be able to handle more than one
> pointer at a time.
>
X,Y,Z,SP can be used as pointers.
Y is of course occupied as a stackpointer in some compilers.
>> If you start in the other end: How do you make an 8 bit
>> architecture which is C-friendly you may come to a different
>> conclusion.
>
> Allow any register pair to be used for pointers, mainly.
> That's fine -- the problem I've seen is that code that has to
> use multiple pointers thrashes because the AVR can only deal
> with 1-2 pointers at a time.
The new MOVW instruction helps somewhat.
Ulf Samuelsson
>> architecture which is C-friendly you may come to a different
>> conclusion.
>
> 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?
It all depends on the relations between the amount of 8 and 16 bit
operations.
> Something like an MSP430
> (16-bit) or H8 (16/32 bit) is cheaper than an AVR,
Depends on who is asking and who is asked, I guess.
>> From this viewpoint it is "C-friendly" to use 2 instructions
>> for 16 bit operations and 4 instructions to do 32 bit operations.
>
> Not as C-friendly as using 1. :)
The ability to support high end features often come at a cost in code space.
When those high end features are used, then the architecture with native
support excels.
Ulf Samuelsson
"steve" <bungalo...@yahoo.com> skrev i meddelandet
news:1154925894.3...@n13g2000cwa.googlegroups.com...
In the end, I think C friendly means that you rather use a C compiler
than assembler to get the job done on the MCU, even for cost critical
designs.
I find regularily that when I get my hands on customers assembly code to fix
problems,
I can do a better job with the C compiler.
mc
>>> 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).
Grant Edwards
> 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.
> 60K FLASH (256K AVR's)
I'm using one with 128K, and evaluated models with 512K.
> requires 50% more power, are physically bigger, have no EEPROM
True.
> limited selection
Don't think so.
> there is a price to pay in die size when you move up to a 16
> bit processor which can make your life harder it other
> aspects, I also seem to remember doing a H8/300 16 bit
> multiply was slower then a AVR's 16 bit multiply and generally
> slower in all instructions, so it's not so cut and dry as you
> imply if you dig into the details. The MSP430's are not
> cheaper then the AVR's.
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.
--
Grant Edwards grante Yow! If I am elected no
at one will ever have to do
visi.com their laundry again!
Grant Edwards
>>> If you start in the other end: How do you make an 8 bit
>>> architecture which is C-friendly you may come to a different
>>> conclusion.
>>
>> 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?
>
> It all depends on the relations between the amount of 8 and 16 bit
> operations.
True. In an application that does any floating point at all,
the ability to do 32-bit operations is a huge advantage.
--
Grant Edwards grante Yow! -- I love KATRINKA
at because she drives a
visi.com PONTIAC. We're going
awaynow. I fed the cat.
Grant Edwards
>> there is a price to pay in die size when you move up to a 16
>> bit processor which can make your life harder it other
>> aspects, I also seem to remember doing a H8/300 16 bit
>> multiply was slower then a AVR's 16 bit multiply and generally
>> slower in all instructions, so it's not so cut and dry as you
>> imply if you dig into the details. The MSP430's are not
>> cheaper then the AVR's.
>
> 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.
BTW, the 128K/4K H8 that I'm using now is under $4 in 1K
quantities. I couldn't find anything comparable in the AVR
product line for less than $7.
--
Grant Edwards grante Yow! You should all JUMP
at UP AND DOWN for TWO HOURS
visi.com while I decide on a NEW
CAREER!!
Paul Carpenter
gra...@visi.com "Grant Edwards" wrote:
>On 2006-08-07, steve <bungalo...@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, 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.
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.
...
--
Paul Carpenter | pa...@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
Grant Edwards
> gra...@visi.com "Grant Edwards" wrote:
>>On 2006-08-07, steve <bungalo...@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.
> 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).
> 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. :(
--
Grant Edwards grante Yow! I just bought
at FLATBUSH from MICKEY
visi.com MANTLE!
steve
> On 2006-08-07, steve <bungalo...@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.
>
> > 60K FLASH (256K AVR's)
>
> I'm using one with 128K, and evaluated models with 512K.
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
>
> > requires 50% more power, are physically bigger, have no EEPROM
>
> True.
>
> > limited selection
>
> Don't think so.
1.8V versions , I think so
>
> > there is a price to pay in die size when you move up to a 16
> > bit processor which can make your life harder it other
> > aspects, I also seem to remember doing a H8/300 16 bit
> > multiply was slower then a AVR's 16 bit multiply and generally
> > slower in all instructions, so it's not so cut and dry as you
> > imply if you dig into the details. The MSP430's are not
> > cheaper then the AVR's.
>
> 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?
Grant Edwards
> 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?
Hans-Bernhard Broeker
> 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 (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Paul Carpenter
gra...@visi.com "Grant Edwards" wrote:
>On 2006-08-07, Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
>> gra...@visi.com "Grant Edwards" wrote:
>>>On 2006-08-07, steve <bungalo...@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.
Grant Edwards
>>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
Ulf Samuelsson
news:raHBg.3066$qd....@bignews3.bellsouth.net...
"Embedded C" supports multiple address spaces.
Harvard architecture increases performance a lot in a micro due to increased
bandwidth
but makes programming more complex.
Ulf Samuelsson
> 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.
Michael N. Moran
> mc <lo...@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
Grant Edwards
>> 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!!
Andrew Reilly
> Hans-Bernhard Broeker wrote:
>> mc <lo...@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
Anton Erasmus
<lo...@www.ai.uga.edu.for.address> wrote:
>"steve" <bungalo...@yahoo.com> wrote in message
>news:1154666721.2...@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
Grant Edwards
> Reading arguments of PIC vs whatever, is very similar to the
> religious discussions regarding Hi-Fi equipment.
PIC: The vacuum-tube of microcontrollers.
You can quote me on that...
--
Grant Edwards grante Yow! YOW!! Everybody out
at of the GENETIC POOL!
visi.com
mc
news:dodgd25jfhv52fumc...@4ax.com...
Hmmm... I use PICs a lot but do not feel any "religious" loyalty to them.
They're quirky but handy. I will gladly use others too.
Walter Banks
w..
mc wrote:
> >> The latter. Microchip MPLAB requires you to have write permissions in
> >> something under C:\Program Files, presumably its own directory. I don't
> >> know what it writes there, or whether different users of the same
> >> computer will disrupt each other. In order to use MPLAB we have to
> >> loosen security on our computers by letting all users write in that
> >> directory.
> >
> > Have you raised this with microchip ? - it is by no means a unique
> > problem, and they do need to clean up their act, so point all this out to
> > them.
>
> Yes, I've been corresponding with them about this. I'm also pressing them
> to make the old 62-character path length limit go away, because it is now
> very common for paths on a Windows system to be that long or longer
> (C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm).
> The limit is actually in the .COD file format, which they don't control.
> You can work around it by first adding a linker script to your project (so
> the linker will run, rather than assembling directly to HEX) and then
> turning off COD file generation. I argue that this should actually be the
> default, since there are more people who need long paths than people who
> need COD files.
>
> > If they realise MPLAB is being _removed_ from educational classes because
> > of simply slack SW design, I'm sure they'll move very fast to remedy it.
> > [ well, they should; if they can't be bothered, then they deserve the
> > consequence ]
> >
> > Would having the project directory on a FLASH drive be a security risk
> > ? - I see they are getting ever cheaper.
>
> Actually, that's how we did a lot of our projects last year! Flash drive
> reliability isn't perfect and I urge people to make hard-disk copies often.
Arcady
> 8051, PIC, etc., in this respect. Among microcontrollers, the 68HC11 and
> MSP430 have Von Neumann architecture; almost all larger computers do
> (Pentium, VAX, etc.).
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).
Grant Edwards
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
mc
news:12djnsl...@corp.supernews.com...
> 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.
Precisely what I was thinking about. Thanks for elaborating it...
Ulf Samuelsson
news:12djnsl...@corp.supernews.com...
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
Jonathan Kirwan
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
Grant Edwards
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!!
Walter Banks
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..
Hans-Bernhard Broeker
> The problem isn't separate I/D space, it's the need for
> non-volatile, read-only data.
Suffice it to say that const exists.
> On Harvard architecture uC's usually the only way that can be
> accomplished is to put the "const" data into the "code" address
> space.
But it's not actually the only way, and it's not necessarily the best
way, either. I.e. this usual choice is dubious.
> 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.
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.
Jonathan Kirwan
wrote:
>On 2006-08-09, Jonathan Kirwan <jki...@easystreet.com> wrote:
>> On Wed, 09 Aug 2006 06:25:34 GMT, Arcady <aba...@hotmail.com> wrote:
>>
>>>mc wrote:
>>>
>>>> 8051, PIC, etc., in this respect. Among microcontrollers, the 68HC11 and
>>>> MSP430 have Von Neumann architecture; almost all larger computers do
>>>> (Pentium, VAX, etc.).
>>>
>>>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).
>>
>> 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?
>
>IIRC, early ones didn't. Later ones did.
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.
>Unix on the 80268 worked pretty much the same way: a 64K data
>segment and a 64K text segment.
Well, that is a horse of a different color.
Jon
Jonathan Kirwan
<wal...@bytecraft.com> wrote:
>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.
That's approximately my recollection. I specifically mentioned the
PDP-11/20 because that is the one I recall as being "earliest." My
memory could have been wrong on that point, and you have clarifed the
details some in my own mind. Thanks.
>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.
I personally paid about $300 each for 4k dynamic ram cards from MITS
that didn't even work right because they were designed wrong. That
was my first, and forced, serious foray into the wonderful world of
electronic design. I fixed them. But it took a month of learning and
doing. That was... I think end of 1975, maybe early 1976. Not quite
$1/byte, but not cheap and it came out of my meager (very meager)
pocketbook.
Jon
Grant Edwards
Actually it was almost identical to the PDP-11 that I used for
a couple years (from a user point of view). Each process saw a
64-bit text space and a 64-bit data space. When the scheduler
switch processes, both spaces were swapped for those of the new
processes. As long as everything fit in physical RAM, then all
that was changed were the segment control registers: it went
quite smoothly. As soon as you stared swapping to disk, things
got very slow.
--
Grant Edwards grante Yow! My DIGITAL WATCH
at has an automatic SNOOZE
visi.com FEATURE!!
Jonathan Kirwan
wrote:
>On 2006-08-09, Jonathan Kirwan <jki...@easystreet.com> wrote:
>
>>>Unix on the 80268 worked pretty much the same way: a 64K data
>>>segment and a 64K text segment.
>>
>> Well, that is a horse of a different color.
>
>Actually it was almost identical to the PDP-11 that I used for
>a couple years (from a user point of view).
No, I meant that the 286 (I assumed you meant the 80286, when saying
80268) includes a protection scheme that has quite another purpose to
it. Code space that can be set to execute-only, which begins to look
a little like a separate memory but without the benefits of separate
address and data buses.
I've worked with the x86 series for many years of course, including
chipset register programming, MTRRs and MSRs, etc., and in multi-cpu
systems using APIC. And never did I feel anything similar as when I
was programming PDP-11's. The differences are manifest.
>Each process saw a
>64-bit text space and a 64-bit data space. When the scheduler
>switch processes, both spaces were swapped for those of the new
>processes. As long as everything fit in physical RAM, then all
>that was changed were the segment control registers: it went
>quite smoothly. As soon as you stared swapping to disk, things
>got very slow.
Let's just agree to disagree. How a scheduler handled things isn't
what I was thinking about, I guess.
Jon
Arcady
>>
>>IIRC, early ones didn't. Later ones did.
>
>
> 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.
I pretty much believe that you understand timing incorrectly. From now few years
separating the early PDP-11 where C has been developed (and those where with the MMU
indeed) and later models where separate I/D spaces have been introduced definitely looks
like "the same time" - unfortunately for me it is :( As I remember - C compiler did work
on the common I/D but even lint - did not... So, no lint on 11/34!
>
> 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.
11/70 is later one with 22 bit of physical address, earlier ones had only 18 bits. And
unix did not work w/o the MMU so there where the MMUs at the time when unix and C have
been introduced (essential for unix but not for C). And separate I/D spaces where to
extend the VIRTUAL address - limited to 16 bits no matter what the amount of memory we had.
I took Grant's notice about the constants - but my words weren't about the micros - it was
about the harvard arch in generic - so no limitations for preloaded data in the Data space!
> I am just not at all sure what arcady was trying to say.
You think I do?
Thanks,
Arcady
Arcady
> 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.
If we look back to the PDP-11 years - I do not remember that there was any programmatic
way for the user program to read the I space - only execute commands from it. So with the
"proper" Harvard arch (PDP-11 wasn't the HA - just for clarification) there is no way for
program to implement such "smart pointers" - only if arch provides you with some tricks -
definitely not the case for big (big? man, look around!) machines and vital stuff for
micros. Even the PIC's retlw trick will do (oh, then there WAS a way - pretty expensive
though - to read at least some data from the I space of the PDP-11!)
Hans-Bernhard Broeker
> Hans-Bernhard Broeker wrote:
> > 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.
> If we look back to the PDP-11 years - I do not remember that there
> was any programmatic way for the user program to read the I space -
> only execute commands from it.
On such a pure Harvard architecture, the need for an abstraction
between C pointers and hardware address doesn't arise in the first
place. If consts can never be in code space, C only needs pointers
into data space, so the "one kind of pointer fits all" approach just
works.
The problem discussed in this subthread arises only if
a) the micro is Harvard, yet offers read-only access to code memory
for storing constants
b) it does this by using different *instructions*, rather than e.g. a
special 'magic' bit in the address or more generally by using a
non-uniform memory mapping
c) the C compiler offers support for using this, but
d) its maker decided to do it by introducing non-standard pointer
types, such as a 'int __code_memory__ MyConstant;'
The decision between portability and efficiency only happens in step
d). A C pointer can always be implemented to store the extra bit of
information ('this is in code memory') in the pointer's
representation, at the cost of rendering any access through such an
expanded pointer more costly than if it were just an address. Not
surprisingly, such an architecture will expose quite a few bugs in
code that's sloppy about the rules of pointer usage in C.
mc
news:4k1fb5F...@news.dfncis.de...
> The problem discussed in this subthread arises only if
>
> a) the micro is Harvard, yet offers read-only access to code memory
> for storing constants
>
> b) it does this by using different *instructions*, rather than e.g. a
> special 'magic' bit in the address or more generally by using a
> non-uniform memory mapping
I don't think I'd consider a computer to have a Harvard architecture if its
code and data memories differed only in what their addresses were.