Architectures
mc
What do people think are the comparative merits of the AVR, PIC, and 8051
architectures?
Which one would you choose if you were teaching beginners, or helping
someone start from scratch?
Paul Burke
I'd choose something with a simple architecture and a simple orthogonal
instruction set. I don't know the AVR, don't like the PIC and the 8051
is a total mess (I use it a lot, and will consequently go to hell).
The 68000 is nice and simple, the 6809 even better but both are now
antediluvian and anyway aren't integrated like the PIC etc. (though
there is a 6809 SoC project on OpenCores). The MSP430 is fairly neat and
tidy, but some of the peripherals are complex enough to scare most
people off (try the FLL clock generator).
Paul Burke
Al Borowski
> At risk of starting a religious war...
>
> What do people think are the comparative merits of the AVR, PIC, and 8051
> architectures?
I started with PICs. I've used them for a while, but recently tried
AVRs. Ignoring price, speed, peripherals etc, I think the AVR core
leaves PIC for dead. I have not used an 8051.
The main thing I dislike about the PIC is having to funnel everything
through the W register. The AVR has 32 registers in comparision.
Banking and Paging are a pain on the low end PICs but not a big deal on
the PIC18.
Of course, if you are programming in C it doesn't really matter much.
>
> Which one would you choose if you were teaching beginners, or helping
> someone start from scratch?
PICs are weird - but one 'advantage' is that there are only about thirty
instructions to learn on the lower one. This is not really an advantage
of course, but might seem that way to a novice.
I'd use AVRs, simply because of the free AVR-GCC compiler. On the other
hand 8051's are everywhere. They won't go away in a hurry.
Al
>
>
www.FreeRTOS.org
"mc" <mc_no...@uga.edu> wrote in message
news:41dc14ef$1...@mustang.speedfactory.net...
Normally of coarse this would depend on your application. As it sounds like
this is for educational purposes I would suggest the AVR:
1) New, clean, simple architecture. Very low cost development (WinAVR,
AVRStudio, STK500). Large range to choose from. AVRFreaks forums. This is
the newest design and suited to programming in C.
2) PIC and 8051 both suffer from historical limitations (PIC register model,
8051 memory model, etc.). The new, faster, larger designs have the same
programming model (practically).
Of coarse the PIC and 8051 still have their uses, but they are not as easy
to learn.
Regards,
Richard.
Anton Erasmus
Both the PIC and 8051 are quuite old now with a LOT of app notes and
information on how to use them.
The AVR is a much more modern architecture with fewer oddities that
one has to work around. IMO the AVR is a "better" processor to teach
the basics on. It is also easier to write "good" high level code that
will compile to reasonable assembly code on the AVR as well as on
larger 32bit cpus. There is now enough documentation and other help
on the internet for beginners in every sense of the word to
succesfully get an AVR project going.
Regards
Anton Erasmus
Michael N. Moran
> Which one would you choose if you were teaching beginners, or helping
> someone start from scratch?
For regularity of architecture, GCC toolchain, GDB debugger/simulator,
I like the Renasas H8 series of micros. GCC does a good job with
the code because of the RISC-like architecture.
YMMV
--
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
Dave Hansen
<mnm...@bellsouth.net> wrote:
>mc wrote:
>> Which one would you choose if you were teaching beginners, or helping
>> someone start from scratch?
>
>For regularity of architecture, GCC toolchain, GDB debugger/simulator,
>I like the Renasas H8 series of micros. GCC does a good job with
>the code because of the RISC-like architecture.
Note that all of the above applies to the AVR as well...
Regards,
-=Dave
--
Change is inevitable, progress is not.
Grant Edwards
>> What do people think are the comparative merits of the AVR,
>> PIC, and 8051 architectures?
>>
>> Which one would you choose if you were teaching beginners, or
>> helping someone start from scratch?
>
> I'd choose something with a simple architecture and a simple
> orthogonal instruction set. I don't know the AVR,
I've used the 8051, but only studied the AVR and PIC. Of the
three, I'd say the AVR is the "best architecture" -- and there
is a gcc port, so professional-grade tools are free.
> don't like the PIC and the 8051 is a total mess (I use it a
> lot, and will consequently go to hell).
Your tense is wrong. You use the 8051 a lot, and consequently
are in hell.
> The 68000 is nice and simple,
The 68K is a very nice architecture. Not quite up to PDP-11
class, but close. Some of the 68K based SoC like the
Dragonball are pretty cool.
The 68HC12 isn't bad either, and some of the 16HC12 eval boards
are pretty cheap. [Both the 68K and the HC12 also have good
gcc ports.]
The Renesas (was Hitachi) H8 architecture is very simple and
orthogonal as well. There are both 16 bit and 32 bit versions
with all sorts of peripherals. And parts are CHEAP. You can
get a 32-bit, 25MHz processor with 128K of Flash, 4K of RAM,
two serial ports a bunch of timer/counters, etc. for $3.99 qty
1. [Good GCC port available as well.]
> the 6809 even better but both are now antediluvian and anyway
> aren't integrated like the PIC etc. (though there is a 6809
> SoC project on OpenCores). The MSP430 is fairly neat and tidy,
> but some of the peripherals are complex enough to scare most
> people off (try the FLL clock generator).
--
Grant Edwards grante Yow! I'm in a twist
at contest!! I'm in a
visi.com bathtub! It's on Mars!! I'm
in tip-top condition!
Brett Foster
*snip*
>
> The 68000 is nice and simple, the 6809 even better but both are now
> antediluvian and anyway aren't integrated like the PIC etc. (though
> there is a 6809 SoC project on OpenCores). The MSP430 is fairly neat and
> tidy, but some of the peripherals are complex enough to scare most
> people off (try the FLL clock generator).
I'll second the 68000. I know the University of Guelph and others still
use the 68000 for second year microcomputers course. The main problem is
the cost of the equipment and the age. It's expensive to maintain the
boards in working condition. I also like the AVR, which is certainly
cheaper. (I.e. avr butterfly.)
>
> Paul Burke
john.t...@gmail.com
Yes, but the H8 does *not* have the dual bus (data and code)
architecture that the AVR has. The AVR dual buses' can come back to
haunt you with respect to strings and constant data (lookup tables).
Also, there is excellent GCC support for C++ using the H8 cores. There
is also C++ support for the AVR, but since GCC puts all of the VTABLES
in RAM, there is not alot you can do with it.
I use both the H8 and the AVR extensively, and hands down the H8 cores
win with respect to CPU architecture.
la...@larwe.com
For small values of "excellent", I presume.
Seriously, although I'm aware this is at best a quasi-religious issue,
C++ support is not a deciding selection criterion in the 8-bit
microcontroller space. Reusable IP, app notes, etc are universally
written with the assumption of a mixed asm and C environment. And the
simple act of including a pointer to "this" in each
function^H^H^H^H^H^H^H^Hmethod call^H^H^H^Hinvocation is an Evil Thing
on a processor with a tiny stack space.
Georgi Beloev
Of the three listed I'd choose AVR -- clean new architecture that's easy
to learn. I'd also suggest ARM7 -- a classical 32-bit RISC architecture
that's suitable for much larger class of projects than the 8-bit uCs.
Regards,
-- Georgi
Ian Bell
Depends what you want to teach them. The AVR and PIC are both RISC devices
so if you want to teach a RISC architecture the pick one of these although
the PIC is rather arcane and I am not sure how orthogonal the instruction
set is. Also not sure if either is HArvard or Princeton style architecture.
The 8051 is a CISC part with a Harvard architecture and is probably worth
teaching simply because it is still the biggest selling 8 bit micro.
For a good modern micro with a highly orthogonal architecture I would go
with the Hitachi H8.
Ian
--
Ian Bell
Ian Bell
> mc wrote:
>> At risk of starting a religious war...
>>
>> What do people think are the comparative merits of the AVR, PIC, and 8051
>> architectures?
>
> I started with PICs. I've used them for a while, but recently tried
> AVRs. Ignoring price, speed, peripherals etc, I think the AVR core
> leaves PIC for dead. I have not used an 8051.
>
> The main thing I dislike about the PIC is having to funnel everything
> through the W register. The AVR has 32 registers in comparision.
>
> Banking and Paging are a pain on the low end PICs but not a big deal on
> the PIC18.
>
> Of course, if you are programming in C it doesn't really matter much.
LOL. Of course it matters. The compiler still produces assembly code so the
basic limitations of the processor are still there.
IAn
--
Ian Bell
Ian Bell
> mc wrote:
>> Which one would you choose if you were teaching beginners, or helping
>> someone start from scratch?
>
> For regularity of architecture, GCC toolchain, GDB debugger/simulator,
> I like the Renasas H8 series of micros. GCC does a good job with
> the code because of the RISC-like architecture.
>
> YMMV
>
>
Renesas?? Is that what Hitachi call themselves now??? I thought Infineon
was bad enough. How about a competition? Who can think of the most stupid
name for Intel to rebrand themselves?
Ian
Ian
Ian
--
Ian Bell
Tauno Voipio
>
> Depends what you want to teach them. The AVR and PIC are both RISC devices
> so if you want to teach a RISC architecture the pick one of these although
> the PIC is rather arcane and I am not sure how orthogonal the instruction
> set is. Also not sure if either is HArvard or Princeton style architecture.
>
The PIC is less than RISC, AISC (Antique Instruction Set Computer),
resembling the Honeywell DDP 312 and Digital PDP-8.
--
Tauno Voipio
tauno voipio (at) iki fi
Spehro Pefhany
Alluvium.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Grant Edwards
>> Also, there is excellent GCC support for C++ using the H8 cores.
>
> For small values of "excellent", I presume.
>
> Seriously, although I'm aware this is at best a
> quasi-religious issue, C++ support is not a deciding selection
> criterion in the 8-bit microcontroller space.
There are 32-bit versions of the H8 that can address 16MB of
memory. And they cost less than $4 each in small quantities.
> Reusable IP, app notes, etc are universally
> written with the assumption of a mixed asm and C environment. And the
> simple act of including a pointer to "this" in each
> function^H^H^H^H^H^H^H^Hmethod call^H^H^H^Hinvocation is an Evil Thing
> on a processor with a tiny stack space.
Who said the H8 had a tiny stack?
--
Grant Edwards grante Yow! .. If I cover this
at entire WALL with MAZOLA,
visi.com wdo I have to give my AGENT
ten per cent??
Grant Edwards
> Michael N. Moran wrote:
>
>> mc wrote:
>>> Which one would you choose if you were teaching beginners, or helping
>>> someone start from scratch?
>>
>> For regularity of architecture, GCC toolchain, GDB debugger/simulator,
>> I like the Renasas H8 series of micros. GCC does a good job with
>> the code because of the RISC-like architecture.
>>
>> YMMV
>>
> Renesas?? Is that what Hitachi call themselves now?
Hitachi and Mitsubishi merged their semiconductor divisions.
The result is Renesas. IOW the H8 and the M16 are now both
Renesas products.
--
Grant Edwards grante Yow! KARL MALDEN'S NOSE
at just won an ACADEMY AWARD!!
visi.com
la...@larwe.com
I think I must have my families confused, then. Does H8 overlap the low
end of the SuperH family?
la...@larwe.com
Infineon
Big rebranding moves in the recent past;
Hitachi -> Renesas
Motorola -> Freescale
(I think one other really big one that I can't remember right now).
It's all a marketing thing. Marketing says "Chips aren't selling so
well, let's spin off a separate brand to make it seem new and fresh,
and avoid diluting core perception of our brand". Five years from now,
Marketing will say "We should pull in these separate companies under
the mother brand so we can take advantage of goodwill invested in the
mother brandname"
>Who can think of the most stupid name for Intel to rebrand themselves?
I favor Letni.
john.t...@gmail.com
H8 Instr- Address GCC/H8
Series CPU uctions Space Registers Options
========= ====== ====== ======= ============= ==========
H8/300L 8-16Bit GP
H8/300SLP 8bit 57 64K 8Bit CCR/PSW <default>
H8/300 16Bit PC
H8/300HN 8-32Bit GP
H8/300Tiny 16bit 64 64K 8Bit CCR/PSW <default>*
16Bit PC
H8/300H 8-32Bit GP
H8/300HA 16bit 64 16M 8Bit CCR/PSW '-mh'
24Bit PC
H8/S 8-32Bit GP
H8/S2100 16bit 65 16M 8Bit CCR/PSW '-ms'
H8/S2200 8Bit EXR
H8/S2300 24Bit PC
H8/S2600 16bit 69 16M 8-32Bit GP '-ms2600'
8Bit CCR/PSW
8Bit EXR
24Bit PC
Grant Edwards
Pretty much.
At the low end, the H8/300 is a 16bit CPU (64K address space)
with an 8-bit external bus.
A step up from that is the 32-bit H8/300H, with a 32bit CPU and
a 16MB address range (8/16-bit external bus).
A step up from that is the H8S, higher clock speeds, a few more
instructions.
A step up from that is the Super-H
--
Grant Edwards grante Yow! Hmmm... a CRIPPLED
at ACCOUNTANT with a FALAFEL
visi.com sandwich is HIT by a
TROLLEY-CAR...
Al
>> lot, and will consequently go to hell).
> Your tense is wrong. You use the 8051 a lot, and consequently
> are in hell.
As am I :-(
8031/32/51/52/etc must be the worst architecture ever (I'm sure someone
will correct me though).
Oh, and the stack grows the wrong way ;-)
Al.
Grant Edwards
>>> 8051 is a total mess (I use it a
>>> lot, and will consequently go to hell).
>> Your tense is wrong. You use the 8051 a lot, and consequently
>> are in hell.
>
> As am I :-(
>
> 8031/32/51/52/etc must be the worst architecture ever (I'm sure someone
> will correct me though).
You never used the 8051's predecessor, the 8048. The program
counter was only 12 bits long, but the high bit was a bank
select, so code space was in two 2K banks. Conditional branch
instructions only affected the low 8 bits of the PC. Branches
weren't relative, so you couldn't branch across a 256 byte page
boundary. [IIRC, you could jmp or call/return across a 256
byte page boundary.]
Add some code at the low end of memory, and everything shifts.
Now you've got to go rearrange things to make sure none of the
conditional branches cross a 256 byte page boundary.
If you had a lookup tabel in ROM, it could only be accessed by
instructions in the same 256 byte page as the table. That
means that tables can't cross a page boundary, and the max size
of a table is 250 or so.
After working with the 8048, the 8051 was a dream.
> Oh, and the stack grows the wrong way ;-)
http://www.xs4all.nl/~sbp/sbasm/8048.htm
--
Grant Edwards grante Yow! I wish I was a
at sex-starved manicurist
visi.com found dead in the Bronx!!
Al Borowski
>>Of course, if you are programming in C it doesn't really matter much.
>
>
> LOL. Of course it matters. The compiler still produces assembly code so the
> basic limitations of the processor are still there.
Yes, but with a pure C app you don't have to see the output. All you
notice is the speed/size of your program. Then economics come into play
- perhaps brand X has larger code, but has tons of Flash for cheap. It's
too difficult to compare easily.
I am assuming the OP was asking in terms of ease of use for teaching
purposes.
Al
Nicholas O. Lindan
> What do people think are the comparative merits of the AVR, PIC, and 8051
> architectures?
PIC
Has to be the result of a die size optimization exercise.
Really horrid programming model. Microchip's programming
model is an abortion. Don't believe it when they say
they are all one cycle instructions: the native code is
composed of instruction primitives. Parallax has (had)
an assembler with multi-cycle instructions and an
8051-like syntax allowing "MOV MY_VAR, #3; MOV VAR_1, VAR_2;
DECJZ COUNT, LABEL" - this on a PIC is luxury.
Everything that was taught as Good and Holy in my
graduate level computer architecture & design
courses is violated. 8 special purpose registers,
awkward addressing modes, nothing is orthogonal,
one (count em, one) general purpose register -
like going through life with one hand and no legs.
Did I mention it has almost no RAM (like it starts
at 24(?) bytes and even then it is banked). Some
of the modern versions are vast improvements
on the original.
Low entrance costs. You can get a development kit
for $100 (IIRC) that will serve for most tasks.
In spite of its numerous shortcomings a PIC is a
remarkably useful tool for certain tasks.
But then, so is a sharp stick.
I would not start here. But then I didn't start
here. There are those who did and they will
disagree violently with what I have said.
8051
A refuge from a cash register. The quintessential
uController.
The instruction set makes good sense when using the
on chip-ram. Very efficient when programmed in PL/M-51.
Not so pretty in C.
128K+ address space: 64K ROM, 65K external RAM. External
ram has to go through a bottle-neck index register.
The processor has an INC index register but not a
DEC index register - go figure.
ABX (Accumulator, operand and index registers) style
machine. Four banks of general purpose registers with
fast context switching. A real stack. Limited
on-chip, easily addressable, ram. A good selection
of on-chip peripherals.
Although designed for small tasks it is often given very
large ones because of large address space and low cost.
Is very effective if the application can fit onto
the on-chip memory. Lots of new variants are available
with expanded on-chip resources and high (for a uC)
speed; I am not sure you can still get the original
flavor of 8051.
Think of it as the low-cost Chevy compact of the
microcontroller world. Development can be pricey:
no JTAG, you will need an ICE ~$5K, a prom blower
and UV eraser.
The 8051 IC can be cheaper than a PIC.
Nobody will fire you for designing in an 8051.
Not a bad place to start a uController education.
But you can do better.
AVR
Either a CISC masquerading as a RISC or a RISC masquerading
as a CISC.
The architecture and instruction set are Good and Holy.
Very orthogonal, loads and loads of addressing modes,
an instruction set to make an IBM 3090 mainframe blush
with shame. The general scheme is PDP-11 like which
makes it well suited to running C as C was designed to
run on an '11.
Since it is very well suited to high-level programming languages,
almost nobody uses the assembler. Which is good, because
with all those addressing modes and instruction variations
your head will spin. You want PUSH to increment or decrement
the stack - your choice - like you need it, right?
IMHO this, or something just like it, is the future.
A good place to start.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Nicholas O. Lindan
> The PIC is less than RISC, AISC (Antique Instruction Set Computer),
> resembling the Honeywell DDP 312 and Digital PDP-8.
"Oh, no. My mama can't be ugly so."
I can't believe anything went on the market with a worse
IS&A (Instruction Set and Architecture) than a PIC. But
I am sure I am wrong.
Nominations for the _worst_ computer IS&A:
o The original 16C51 12-bit PIC
Paul Carpenter
<1105032630.4...@z14g2000cwz.googlegroups.com>
la...@larwe.com wrote:
>> Also, there is excellent GCC support for C++ using the H8 cores.
>
>For small values of "excellent", I presume.
Well considering some of the real time video apps I have used them on to
analyse data and control the real time video paths, and some large data set
handling, the GCC support has proved very good.
>Seriously, although I'm aware this is at best a quasi-religious issue,
>C++ support is not a deciding selection criterion in the 8-bit
>microcontroller space. Reusable IP, app notes, etc are universally
All the H8's I have used are 16bit internal data paths with 32bit registers
and 16MB of memory, with minimum of 64KB of Flash, some I may be using soon
are 384KB/512KB of Flash and 32KB of RAM. Very useful on data manipulation
and arrays of interim results on large data sets.
>written with the assumption of a mixed asm and C environment. And the
>simple act of including a pointer to "this" in each
>function^H^H^H^H^H^H^H^Hmethod call^H^H^H^Hinvocation is an Evil Thing
>on a processor with a tiny stack space.
You must be confusing the product line with something else, I have never
had those sort of problems.
--
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
Paul Carpenter
ruffr...@yahoo.com "Ian Bell" wrote:
>Michael N. Moran wrote:
>
>> mc wrote:
>>> Which one would you choose if you were teaching beginners, or helping
>>> someone start from scratch?
>>
>> For regularity of architecture, GCC toolchain, GDB debugger/simulator,
>> I like the Renasas H8 series of micros. GCC does a good job with
>> the code because of the RISC-like architecture.
>>
>> YMMV
>>
>>
>Renesas?? Is that what Hitachi call themselves now??? I thought Infineon
After the merger of the semiconductor divisions of Hitachi and Mistubishi
yes (see web site in sig).
>was bad enough. How about a competition? Who can think of the most stupid
>name for Intel to rebrand themselves?
I don't know about stupid, but realistic "Microsoft Semiconductor"...
>Ian
Richard
news:cThDd.2576$W32...@newsread3.news.atl.earthlink.net:
> "Al Borowski" <al.bo...@EraseThis.gmail.com> wrote
>
>> What do people think are the comparative merits of the AVR, PIC, and
>> 8051 architectures?
>
<snip>
> 8051
<snip>
> Think of it as the low-cost Chevy compact of the
> microcontroller world. Development can be pricey:
> no JTAG, you will need an ICE ~$5K, a prom blower
> and UV eraser.
There are plenty of flash 8051 parts, we use them for development. If you
are going to exceed the internal code space of whatever 8051 you chose,
then you will have to deal with the external memory, but again, plenty of
options that do not involve a prom blower and a UV eraser.
<snip>
--
Richard
Jonathan Kirwan
>"Oh, no. My mama can't be ugly so."
>
>I can't believe anything went on the market with a worse
>IS&A (Instruction Set and Architecture) than a PIC. But
>I am sure I am wrong.
>
>Nominations for the _worst_ computer IS&A:
>
>o The original 16C51 12-bit PIC
I programmed on the C54-C57. I don't recall the C51, though.
In any case, they are great if you like to see how a CPU is designed. You get
the bare bones exposure to a very simple ALU. Using a PIC is like getting to
see the "transparent man" model -- all of the veins are nicely exposed.
So I like the PIC for "teaching computer architecture design to beginners." The
chips can do real work and the company also *does* support smaller companies
very well -- and that's worth something.
Jon
Ian Bell
> On Thursday, in article <crjv2u$ai1$5...@slavica.ukpost.com>
> ruffr...@yahoo.com "Ian Bell" wrote:
>
>>Michael N. Moran wrote:
>>
>>> mc wrote:
>>>> Which one would you choose if you were teaching beginners, or helping
>>>> someone start from scratch?
>>>
>>> For regularity of architecture, GCC toolchain, GDB debugger/simulator,
>>> I like the Renasas H8 series of micros. GCC does a good job with
>>> the code because of the RISC-like architecture.
>>>
>>> YMMV
>>>
>>>
>>Renesas?? Is that what Hitachi call themselves now??? I thought Infineon
>
> After the merger of the semiconductor divisions of Hitachi and Mistubishi
> yes (see web site in sig).
>
>>was bad enough. How about a competition? Who can think of the most
>>stupid name for Intel to rebrand themselves?
>
> I don't know about stupid, but realistic "Microsoft Semiconductor"...
>
>>Ian
>
Heaven forbid. Crashing software is bad enough, but hardware made by the
same outfit??? No thanks.
Ian
--
Ian Bell
Stef
Grant Edwards <gra...@visi.com> wrote:
>
>You never used the 8051's predecessor, the 8048. The program
>counter was only 12 bits long, but the high bit was a bank
>select, so code space was in two 2K banks. Conditional branch
>instructions only affected the low 8 bits of the PC. Branches
>weren't relative, so you couldn't branch across a 256 byte page
>boundary. [IIRC, you could jmp or call/return across a 256
>byte page boundary.]
>
>Add some code at the low end of memory, and everything shifts.
>Now you've got to go rearrange things to make sure none of the
>conditional branches cross a 256 byte page boundary.
>
>If you had a lookup tabel in ROM, it could only be accessed by
>instructions in the same 256 byte page as the table. That
>means that tables can't cross a page boundary, and the max size
>of a table is 250 or so.
>
The limititions sound awfully simular to my last PIC project
(16C508 iirc). Had to put in assembler directives to check
the sanity of jumbtables (they could only reside in the lower
256 bytes of a 512 byte program page) and implement 'long calls'
by using an intermediate location with a ljump instruction. Oh
and a solid 32 byte RAM spread over four banks.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
The world's great men have not commonly been great scholars, nor its great
scholars great men.
-- Oliver Wendell Holmes
Jim Granville
> At risk of starting a religious war...
>
> architectures?
and the Zilog Z8, and maybe HC08..
> Which one would you choose if you were teaching beginners, or helping
> someone start from scratch?
Depends what you want to teach them ?
Put large posters of all these on the wall - you can learn a lot
by comparing the design approach.
For 'hands on', look for a family with inbuilt debug.
If you also want to teach ADC/DAC peripherals, then the
Silicon Labs C8051F330 is a very nice device, and the
demo board for the C8051F064 is a great teaching product.
[C51 cores, 25MIPS]
The C8051F41x at 66MIPS will sample soon.
Zilog also have low cost Z8 development kits.
All uC cores have merits, and weaknesses, and all have
'code knees': resource points over which the code needed
suddenly grows.
eg an 80C51 is VERY good at Boolean handling, and has
direct memory opcodes up to 128 Bytes, but suffers on
large data tables. Since it was designed as a single chip
microcontroller, the designers did a good job in matching
the core to the task.
The 80C51 is very widely sourced, and that can be
vitally important in commercial systems.
The AVR works OK until you run out of registers, then
the lack of a register frame pointer/direct memory opcodes,
means you spend a LOT of code loading pointers - but since it was first
designed as a HDL core, that issue was not on the designers radar...
They needed a compact core that had low gate count.
The AVR is also single sourced - see recent threads on family
availability.... [for teaching/hobbyist purposes that may matter less]
The Z8 is a register core, but WAS designed as an
embedded controller, so has Boolean, Direct memory opcodes,
and a register page scheme. Zilog are now ramping the FLASH
versions of this, so it will be a good one to watch.
- ie the errata is getting tolerable.
PICs are actually many cores, not one, and as you move up thru
the opcode size, the non-page memory reach extends and the cores
get better for larger data sets. The tiniest SOT23 PIC is fine for
flashing a LED.
If you want a BIG core, look at the ARM7, set to be the
'new 80C51' for larger embedded projects. LOTS of companies
are now sampling ARM uC.
To know where the ARM7 is weak, look at the new Cortex core,
which is another design pass from ARM,
more optimised to the embedded control space.
-jg
Ian Bell
> "Tauno Voipio" <tauno....@iki.fi.NOSPAM.invalid> wrote>
>
>> The PIC is less than RISC, AISC (Antique Instruction Set Computer),
>> resembling the Honeywell DDP 312 and Digital PDP-8.
>
> "Oh, no. My mama can't be ugly so."
>
> I can't believe anything went on the market with a worse
> IS&A (Instruction Set and Architecture) than a PIC. But
> I am sure I am wrong.
>
> Nominations for the _worst_ computer IS&A:
>
> o The original 16C51 12-bit PIC
>
The 1802, the first CMOS 8 bitter.
Ian
--
Ian Bell
Ian Bell
Maybe that explains its arcane terminology.
Ian
--
Ian Bell
Andrew Reilly
> Paul Burke wrote:
>
> *snip*
>>
>> The 68000 is nice and simple, the 6809 even better but both are now
>> antediluvian and anyway aren't integrated like the PIC etc. (though
>> there is a 6809 SoC project on OpenCores). The MSP430 is fairly neat and
>> tidy, but some of the peripherals are complex enough to scare most
>> people off (try the FLL clock generator).
>
> I'll second the 68000. I know the University of Guelph and others still
> use the 68000 for second year microcomputers course. The main problem is
> the cost of the equipment and the age. It's expensive to maintain the
> boards in working condition. I also like the AVR, which is certainly
> cheaper. (I.e. avr butterfly.)
If you're a 68000 fan, then surely there must be ColdFire EVMs available
at reasonable prices? [Looks to be about 20 to choose from, on the
Freescale web site.]
I got to use both LSI-11 and 68000 boards in my OS and microcomputer
courses at Uni, (and I have a vague memory that the 6809 got a look in
there too, somewhere). Good fun for learning on systems like that: the
busses are nice and simple, and there's no pre-fetch or cache magic to
stop you from seeing what's going on. In a sense it's a shame that
technology has moved on to the point where it's hard for youngsters to
play with that sort of kit, now. Maybe the AVR and H8 processors can fill
that role?
Cheers,
--
Andrew
mc
<la...@larwe.com> wrote in message
news:1105038496.8...@c13g2000cwb.googlegroups.com...
>>Who can think of the most stupid name for Intel to rebrand themselves?
> I favor Letni.
Or Stupi(dity), the opposite of Intel(ligence)... ?
mc
> For regularity of architecture, GCC toolchain, GDB debugger/simulator,
> I like the Renasas H8 series of micros. GCC does a good job with
> the code because of the RISC-like architecture.
From the old days I recall Hitachi H8. Is this the same under another name?
mc
"www.FreeRTOS.org" <noe...@given.com> wrote in message
news:rq7Dd.54731$Z7.2...@fe2.news.blueyonder.co.uk...
>
> 2) PIC and 8051 both suffer from historical limitations (PIC register
> model,
> 8051 memory model, etc.). The new, faster, larger designs have the same
> programming model (practically).
Am I right in thinking that except for a few simple parameters, the AVRs are
all alike from small to large?
mc
"Al Borowski" <al.bo...@EraseThis.gmail.com> wrote in message
news:41dcfe5d$0$14286$5a62...@per-qv1-newsreader-01.iinet.net.au...
> PICs are weird - but one 'advantage' is that there are only about thirty
> instructions to learn on the lower one. This is not really an advantage of
> course, but might seem that way to a novice.
Understood, and of course I don't want to encourage that kind of thinking.
>
> I'd use AVRs, simply because of the free AVR-GCC compiler. On the other
> hand 8051's are everywhere. They won't go away in a hurry.
How good is AVR-GCC? I know GCC for UNIX is very reliable.
Paul Carpenter
<41dd5fdd$1...@mustang.speedfactory.net> mc_no...@uga.edu
"mc" wrote:
Yes after a merger of the semiconductor divisions in April 2003 of
Hitachi and Mitsubishi they formed a single company Renesas.
See also sig below.
Gary Kato
<snip>
> The architecture and instruction set are Good and Holy.
> Very orthogonal,
Not really. I seem to remember that there was an ADDI but not a SUBI. Also,
immediate addressing only works with half the registers (the upper half I
think).
CBFalconer
>
... snip ...
>
>> Who can think of the most stupid name for Intel to rebrand themselves?
>
> I favor Letni.
CIA ?
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nicholas O. Lindan
AVR
> The architecture and instruction set are Good and Holy.
> Very orthogonal, loads and loads of addressing modes,
> an instruction set to make an IBM 3090 mainframe blush
> with shame. The general scheme is PDP-11 like which
> makes it well suited to running C as C was designed to
> run on an '11.
I went a bit over the top there.
Like all (?) uControllers it does not deal with large (or
even small) amounts of memory. All operations are
register <-> register and an index register or the SP
is needed to access bulk RAM. Handling big data sets
on a uC is akin to the old frat stunt of pushing a piano
through an 11" hole and having it play when re-assembled
on the other side. (Upright piano, before someone
brings up Boesendorfer).
Real computers as the PDP-11/VAX/S360 etc. have direct
access to oogles of memory, disk and tape. Though you
could do a heck of a lot with very little in the old
days. I once had my very own (well, Gould's very own)
IBM 360/30. 16K core with a memory box with another 48K.
With this processor NY Bell did the billings for western
New York state. Now this much computing power is barely
suited to the running of a Walkman tape player.
For an IBM 360/30 home computer story, the classic:
http://homepages.kcbbs.gen.nz/nbree/saga.html
Jim Granville
They are more similar than PIC12/14/16/18, but are not binary compatible.
Aside from the expected SFR mappings, things to watch are:
Not all had the LPM instruction.
Not all have multiply opcodes
Interrupt vector spacing changes
AVRs that are register-only [no RAM at all, just 32 registers]
omit the ram-pointer opcodes
-jg
Neil Kurzman
You can still get 8051s (atmel)
There are some with JTAG and FLASH (Phillips, Analog Devices, Silicon Labs)
emulators start at $500 , limited JTAGs are cheaper.
Look at www.8052.com for Info
For AVR look at www.avrfreaks.net
Jim Granville
> In comp.arch.embedded,
> Grant Edwards <gra...@visi.com> wrote:
>
>>You never used the 8051's predecessor, the 8048. The program
>>counter was only 12 bits long, but the high bit was a bank
>>select, so code space was in two 2K banks. Conditional branch
>>instructions only affected the low 8 bits of the PC. Branches
>>weren't relative, so you couldn't branch across a 256 byte page
>>boundary. [IIRC, you could jmp or call/return across a 256
>>byte page boundary.]
>>
>>Add some code at the low end of memory, and everything shifts.
>>Now you've got to go rearrange things to make sure none of the
>>conditional branches cross a 256 byte page boundary.
>>
>>If you had a lookup tabel in ROM, it could only be accessed by
>>instructions in the same 256 byte page as the table. That
>>means that tables can't cross a page boundary, and the max size
>>of a table is 250 or so.
>>
>
> Are you sure you're not describing a PIC here? ;-)
>
> The limititions sound awfully simular to my last PIC project
> (16C508 iirc). Had to put in assembler directives to check
> the sanity of jumbtables (they could only reside in the lower
> 256 bytes of a 512 byte program page) and implement 'long calls'
> by using an intermediate location with a ljump instruction. Oh
> and a solid 32 byte RAM spread over four banks.
The PIC and 8048 started life about the same time, so it
is not surprising they have similar 'low ceilings'.
In the case of the 8048, the SJMPS simply replaced the lower
8 bits of the PC - there was no adder. This gave faster silicon,
and kept smaller code, but moved the pain/cost from the silicon,
to the programmer :)
The 8048 is still available, and could be usefull to teach
alongside an 80C51. - ie along the lines, of "what did the designers
add on Pass 2, and what did they retain for code compatability" ?
Dig up some N8748 windowed devices to show the students....
-jg
Mike Fields
somewhere if we are talking old stuff ...
"Jim Granville" <no....@designtools.co.nz> wrote in message
news:41de1424$1...@clear.net.nz...
David
To get SUBI, you just ADDI with a negative number. It's only when looking
at carries that there is a difference.
The restriction of only having immediate addressing on the upper registers
is non-orthogonal, and there are a few register-specific instructions like
LPM (although this is better on the megas). The really painful
limitation and non-orthogonality is in the pointers - the cpu would be
much more efficient (especially for C) if the X, Y, and Z pointers were
orthogonal, and especially if R24:25 were also a "W" pointer.
David
> mc wrote:
>> At risk of starting a religious war...
>>
>> What do people think are the comparative merits of the AVR, PIC, and 8051
>> architectures?
>>
>> Which one would you choose if you were teaching beginners, or helping
>> someone start from scratch?
>>
>>
>
> I'd choose something with a simple architecture and a simple orthogonal
> instruction set. I don't know the AVR, don't like the PIC and the 8051
> is a total mess (I use it a lot, and will consequently go to hell).
>
> The 68000 is nice and simple, the 6809 even better but both are now
> antediluvian and anyway aren't integrated like the PIC etc. (though
> there is a 6809 SoC project on OpenCores). The MSP430 is fairly neat and
> tidy, but some of the peripherals are complex enough to scare most
> people off (try the FLL clock generator).
>
> Paul Burke
The m68k architecture is very nice, and is still going strong under the
name ColdFire (which is basically a complete re-implementation of the same
programming model using more efficient and modern design techniques than
the original m68k), streching from small chips for under $10 up to 300+
MHz chips. Definitely a good choice if you want to look at powerful
32-bit architectures.
For smaller chips, you'd be hard pushed to find something better than the
msp430. Sure, some of the peripherals are a bit complex (the queued ADC
is very nice once you manage to figure it out), but it's the cpu you are
interested in. It is as orthogonal as they come (even the PC is just
another register), it is 16-bit, has a single address space, and every
register can be a pointer. Easy to work with in assembly, and very
C-friendly (as distinct from the AVR, which is merely IAR-C-friendly),
with good gcc support. You can choose from expensive high-end toolsets
like IAR, mid-level friendly toolsets like ImageCraft, or the solid (and
well-supported) gcc port, with jtag debuggers costing about $10 (IIRC)
from Olimex.
David
> On 2005-01-06, Al <alne...@hotmail.com> wrote:
>>>> 8051 is a total mess (I use it a
>>>> lot, and will consequently go to hell).
>>> Your tense is wrong. You use the 8051 a lot, and consequently
>>> are in hell.
>>
>> As am I :-(
>>
>> 8031/32/51/52/etc must be the worst architecture ever (I'm sure someone
>> will correct me though).
>
> You never used the 8051's predecessor, the 8048. The program
> counter was only 12 bits long, but the high bit was a bank
> select, so code space was in two 2K banks. Conditional branch
> instructions only affected the low 8 bits of the PC. Branches
> weren't relative, so you couldn't branch across a 256 byte page
> boundary. [IIRC, you could jmp or call/return across a 256
> byte page boundary.]
>
> Add some code at the low end of memory, and everything shifts.
> Now you've got to go rearrange things to make sure none of the
> conditional branches cross a 256 byte page boundary.
>
> If you had a lookup tabel in ROM, it could only be accessed by
> instructions in the same 256 byte page as the table. That
> means that tables can't cross a page boundary, and the max size
> of a table is 250 or so.
>
> After working with the 8048, the 8051 was a dream.
>
Sounds like the NS COP8 chips, which have the added joy of using 10
oscillator clocks per instruction cycle, and several (generally 3 or 4)
instruction cycles per instruction. Combining this with an appallingly
bad interrupt scheme, this chip has an interrupt overhead (including
simple context save and restore) of around 80us at 10 MHz.
>> Oh, and the stack grows the wrong way ;-)
>
> http://www.xs4all.nl/~sbp/sbasm/8048.htm
Ulf Samuelsson
news:41de...@clear.net.nz...
In addition, only the ATmega core has the SPM Store program memory to
support selfprogramming.
There is also a more advanced LPM instruction.
Typically , You tell the compiler which chip you use, and then you include a
header file.
Most of the changes are then hidden or disabled.
You can compile libraries without the extended intstructions.
I do not think there will be any new parts designed without SRAM,since this
was a real bad idea...
With the new parts coming, tiny25/45/85; tiny46/86 etc, I would be surprised
if there were any need for those currently arround, (which probably will be
obsoleted anyway)
--
Best Regards,
Ulf Samuelsson u...@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB
Ulf Samuelsson
news:41ddd9b0$1...@mustang.speedfactory.net...
Consultant company in Sweden (only one guy).
Among his accomplishments:
* Designed a laser printer in the early 1980's.
Patented a lot of technology.
Licensed the patents to Canon. (which delivered its engines to HP)
* Helped some friends form a startup because he needed some TCP/IP
equipment.
Got some stock options (quite a few) in return.
Company is known as Cisco.
* His private internet connection is 2,4 Gbit...
Guess he isn't STUPI(D)
Ulf Samuelsson
> limitation and non-orthogonality is in the pointers - the cpu would be
> much more efficient (especially for C) if the X, Y, and Z pointers were
> orthogonal, and especially if R24:25 were also a "W" pointer.
>
The fourth register is the SP.
Ulf Samuelsson
> oscillator clocks per instruction cycle, and several (generally 3 or 4)
> instruction cycles per instruction. Combining this with an appallingly
> bad interrupt scheme, this chip has an interrupt overhead (including
> simple context save and restore) of around 80us at 10 MHz.
The reason why the COP8 uses 10 clocks to do one instruction is
because it is internally bitserial, using a 1 bit ALU.
Also it is using "precharged" logic.
clock 1: Precharge all DFFs to 1
clock 2-9; Process an 8 bit instruction.
clock 10: Write
A precharged implememntation basically loses the upper part
of a CMOS implementation so the number of transistors
is half that of a nornal CMOS design.
Bit serial also reduces the size, so the COP core is may 1/3 of an 8051.
This is of couse not so important in 0,18u CMOS.
Jim Granville
Mike Fields wrote:
> Hmmm -- I still have several 1702 EPROMS downstairs
> somewhere if we are talking old stuff ...
Yes, get them in front of a class somewhere...
These venerable devices have die details you can
see under a normal microscope, and most have
goldplated packages - get some bling to get their
attention ! :)
-jg
David
>> LPM (although this is better on the megas). The really painful
>> limitation and non-orthogonality is in the pointers - the cpu would be
>> much more efficient (especially for C) if the X, Y, and Z pointers were
>> orthogonal, and especially if R24:25 were also a "W" pointer.
>>
>
> The fourth register is the SP.
That makes some sense. I would have much preferred the stack pointer to
be in the main register array (for example as R24:R25), and the lack of a
SP+offset address mode leads to a lot of inefficiency and complications
for C compilers (such as having seperate data and program stacks). Some
trade-offs are allways necessary - 16-bit instructions have their limits -
but I think there could have been better choices. Limiting the Y+q and
Z+q displacement modes to 0..31 instead of 0..63 would have freed space to
include X+q and SP+q modes as well.
David
>> Sounds like the NS COP8 chips, which have the added joy of using 10
>> oscillator clocks per instruction cycle, and several (generally 3 or 4)
>> instruction cycles per instruction. Combining this with an appallingly
>> bad interrupt scheme, this chip has an interrupt overhead (including
>> simple context save and restore) of around 80us at 10 MHz.
>
>
> The reason why the COP8 uses 10 clocks to do one instruction is
> because it is internally bitserial, using a 1 bit ALU.
> Also it is using "precharged" logic.
> clock 1: Precharge all DFFs to 1
> clock 2-9; Process an 8 bit instruction.
> clock 10: Write
>
> A precharged implememntation basically loses the upper part
> of a CMOS implementation so the number of transistors
> is half that of a nornal CMOS design.
>
> Bit serial also reduces the size, so the COP core is may 1/3 of an 8051.
> This is of couse not so important in 0,18u CMOS.
I knew that the internals of the COP8 were serial (although there was talk
of making a parallel COP8 chip, but the project was cancelled AFAIK), but
not about the pre-charge trick. There are plenty of nice features about
the COP8 - it is very robust, with low EMI, they have some very small
package devices, and it is easy to program in assembly (as long as you
don't need big tables), but it is painfully slow for some things.
Everett M. Greene
> "Al Borowski" <al.bo...@EraseThis.gmail.com> wrote
>
> > What do people think are the comparative merits of the AVR, PIC, and 8051
> > architectures?
> AVR
>
> Either a CISC masquerading as a RISC or a RISC masquerading
> as a CISC.
>
> The architecture and instruction set are Good and Holy.
> Very orthogonal,
You mean as in SUBI but no add immediate?
ADIW but no subtract? LDD/STD Rn,x+q where x can be Y or Z
but not X? Certain instructions that can use only the
upper 16 registers?
If you've ever tried to decode the instructions, you'd question
whether "orthogonal" was ever in the designers' vocabulary.
> loads and loads of addressing modes,
Two is a lot?!
> an instruction set to make an IBM 3090 mainframe blush
> with shame. The general scheme is PDP-11 like which
> makes it well suited to running C as C was designed to
> run on an '11.
>
> Since it is very well suited to high-level programming languages,
> almost nobody uses the assembler.
Oh!
> Which is good, because
> with all those addressing modes and instruction variations
> your head will spin. You want PUSH to increment or decrement
> the stack - your choice - like you need it, right?
Since the hardware stack isn't all that directly accessible,
you have to devise your own stack. Therefore, having the
option of going either way isn't bad although most people
will probably choose to use their own traditional direction
(whichever that may be).
> IMHO this, or something just like it, is the future.
>
> A good place to start.
68HC12 is a good place to start.
Charles Allen
>> Which one would you choose if you were teaching beginners, or helping
>> someone start from scratch?
Jim Granville:
> Depends what you want to teach them ?
Suppose the students were going to see a CPU at the end of a semester
digital electronics course. They should see the hardware side of
things: addresses on an external bus, etc. They'd only use the basic
stuff anyway, and it would be nice if they could walk away with a $50
hobbyist board to play with.
--
Charles Allen
Dave Hansen
[...]
>
>How good is AVR-GCC? I know GCC for UNIX is very reliable.
It's quite good, though as another poster said, you have to jump
through some hoops to accmodate the harvard architecture. For
example, to put a table of constants into flash, you do something like
#include <avr/pgmspace.h>
unsigned char flash_table[] PROGMEM = {3, 2, 1, 0};
Then to access that data you need to use a macro:
unsigned chat value;
value = pgm_read_byte(&flash_table[idx]);
For the code I write I find avr-gcc usually generates slightly smaller
code than the commercial compiler I use (one of my current projects
compiles to 7344 bytes of flash under avr-gcc, vs. 8264 for the
commercial compiler).
The commercial compiler handles the harvard archtecture much more
cleanly, but that's moot since I write the code to work with either
compiler.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Paul E. Bennett
I still have 8K worth of Ferrite Core Memory (Mullard) here. Until about 5
years ago I also had a Creed Teletype (Ahh, the joys of RTTY). I am
reducing the quantity of old stuff I have, gradually. ;>
--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Nicholas O. Lindan
> "Nicholas O. Lindan" <s...@sig.com> writes:
> > "Al Borowski" <al.bo...@EraseThis.gmail.com> wrote
> >
> > > What do people think are the comparative merits of the AVR, PIC, and 8051
> > > architectures?
> > AVR
> > The architecture and instruction set are Good and Holy.
> > Very orthogonal,
>
> You mean as in SUBI but no add immediate?
> ADIW but no subtract? LDD/STD Rn,x+q where x can be Y or Z
> but not X? Certain instructions that can use only the
> upper 16 registers?
OK, Ok, ok ... I'm not an AVR maven. I used it after one year
of nothing but PIC. It was such a relief after the
PIC I saw it with rose colored glasses.
> Two [adressing modes] is a lot?!
Compared to a PIC? Or an 8051? Yeah.
Hold on a minute, though. I count 6 addressing modes:
register
direct
immediate
indirect
indexed post-inc/pre-dec
indexed offset
What's missing? double-indirect indexed offset post decrement?
A uC isn't a big-iron mainframe.
> You want PUSH to increment or decrement
> the stack - your choice - like you need it, right?
>
> Since the hardware stack isn't all that directly accessible,
> you have to devise your own stack....
You are right. I only remember the good parts ...
> IMHO this, or something just like it, is the future.
> A good place to start.
> 68HC12 is a good place to start.
Wasn't on the list. Again: you are right. There are lots
better places to start. I take it though the LP (last poster)
uses a 68HC12?
If this is a _general_ microprocessor course then I would question
the use of a uController. Of the inner workings of a uP you
will learn nothing as there is nothing to see, might as well
use an emulator.
la...@larwe.com
> ADIW but no subtract?
> LDD/STD Rn,x+q where x can be Y or Z but not X?
> Certain instructions that can use only the upper 16 registers?
The last one of those really bit me when I was learning AVR. I guess
they ran out of bits in the opcode, and it was more useful to address
the top 16 registers since X,Y and Z lie there. I also have no argument
against the third point above. But on the SUBI and ADIW front, what
about using negative immediates?
mc
"David" <david....@westcontrol.removethis.com> wrote in message
news:pan.2005.01.07....@westcontrol.removethis.com...
> For smaller chips, you'd be hard pushed to find something better than the
> msp430.
Is there an MSP430 in the DIP package?
Ulf Samuelsson
> of making a parallel COP8 chip, but the project was cancelled AFAIK),
National normally cans most of their microcontroller projects
> not about the pre-charge trick. There are plenty of nice features about
> the COP8 - it is very robust, with low EMI, they have some very small
> package devices, and it is easy to program in assembly (as long as you
> don't need big tables), but it is painfully slow for some things.
>
Ulf Samuelsson
> Hold on a minute, though. I count 6 addressing modes:
>
> register
> direct
> immediate
> indirect
> indexed post-inc/pre-dec
> indexed offset
>
> What's missing? double-indirect indexed offset post decrement?
> A uC isn't a big-iron mainframe.
>
I happen to like the
cbitd 4711(17(sb))[r0:d], 17(4711(sp))[r1:w]
instruction implemented on the Series 32000 processors.
Fits in 23 bytes without any problem.
No post decrement though but a 1 Gbit bit addressing space would come in
handy any day.
Everett M. Greene
Yes, you add immediate by subtracting the complement, but
the discussion was about instruction set orthogonality.
It's a source of coding errors also (speaking from
experience).
Another factor not mentioned for teaching purposes is
documentation quality and availability. The MSP430
documentation is horrid and neither TI nor Atmel
provide hardcopies of their documents anymore.
Lewin A.R.W. Edwards
>> > ADIW but no subtract?
>>
>> about using negative immediates?
>
> Yes, you add immediate by subtracting the complement, but
> the discussion was about instruction set orthogonality.
I'm inclined to judge this particular non-orthogonality very leniently,
though - because it can be hidden entirely by the assembler (or a macro)
without changing program size or execution speed.
> documentation is horrid and neither TI nor Atmel
> provide hardcopies of their documents anymore.
I never once opened the databooks National sent me on the COP8. NEC sent
shelfloads of folders of (probably erroneous) info on the 78K0 tools.
Never opened them. Electronic documentation is more useful to me for the
search facility if nothing else.
--
Here, in a large house, formerly a house of state, lives Mr. Tulkinghorn. It
is let off in sets of chambers now, and in those shrunken fragments of its
greatness, lawyers lie like maggots in nuts.
Nicholas O. Lindan
> > > ADIW but no subtract?
Agreed, it's not orthogonal. However, the two instructions are
redundant. I hope the two instructions that take their place
are useful; one is _always_ running out of opcodes for instructions
that are never used.
I would think a one line macro would add ADDI and SUBIW
instructions. There is an assembler/processor combination
that does this though I can't remember which one.
> The MSP430 documentation is horrid and neither TI nor Atmel
> provide hardcopies of their documents anymore.
Strategic management decision: Problem - cost of documentation;
Solution - no more documentation;
Result - no more design-ins.
CBFalconer
>
... snip ...
>
>> documentation is horrid and neither TI nor Atmel
>> provide hardcopies of their documents anymore.
>
> I never once opened the databooks National sent me on the COP8. NEC
> sent shelfloads of folders of (probably erroneous) info on the 78K0
> tools. Never opened them. Electronic documentation is more useful
> to me for the search facility if nothing else.
Fundamental difference in attitude here. I really need hard copy
which I can then read while enthroned, taking a bath, going to
sleep, whatever. I can even add Postit notes to mark things, or
write in the margin, after Pascal. I am not about to wear out my
hardware printing a 400 page (or more) manual, and possibly getting
nothing but a large paper jam out of it.
Fineprint (and its booklet mode) is a partial savior.
I would always choose the hardware with printed documentation.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
la...@larwe.com
>> sent shelfloads of folders of (probably erroneous) info on the 78K0
>Fundamental difference in attitude here. I really need hard copy
>which I can then read while enthroned, taking a bath, going to
I think the engineering community is pretty evenly split on this issue.
I know electronic doc works much better for me. I like being able to
keep everything on my laptop (which, by the way, I can use while
enthroned, not to mention in bed ;) I also keep a lot of docs on my
PDA, which I regularly use in the bath.
The only time I print is when I'm drawing a CAD library symbol; I print
the package drawing and pinouts and cross things off as I put them in
the symbol.
Jonathan Kirwan
>> I never once opened the databooks National sent me on the COP8. NEC
>> sent shelfloads of folders of (probably erroneous) info on the 78K0
>> tools. Never opened them. Electronic documentation is more useful
>> to me for the search facility if nothing else.
>
>Fundamental difference in attitude here. I really need hard copy
>which I can then read while enthroned, taking a bath, going to
>sleep, whatever. I can even add Postit notes to mark things, or
>write in the margin, after Pascal. I am not about to wear out my
>hardware printing a 400 page (or more) manual, and possibly getting
>nothing but a large paper jam out of it.
Agreed, Chuck. I also want them so that I can read while on the train or light
rail or bus or as a passenger in a car; when I go places to just keep company of
sorts, but where my rather stilted conversational skills are not desired; etc.
I always want printed texts. I don't mind having the most up to date materials
in PDF form on my computer, too. But I want printed text. And sadly, I've been
pushed into becoming a print shop operator. I don't like it.
Jon
la...@larwe.com
materials
> in PDF form on my computer, too. But I want printed text. And
sadly, I've been
> pushed into becoming a print shop operator. I don't like it.
You can always use a service like Kinko's or another online DTP type
service to print the PDFs and FedEx them to you.
Personally I like the fact that anywhere I have Internet access, I have
access to the datasheets. I don't have to worry about losing copies.
And I can archive the full datasheets for every device I have ever
worked with inside one drawer of one filing cabinet (and that drawer
isn't full).
Jonathan Kirwan
>You can always use a service like Kinko's or another online DTP type
>service to print the PDFs and FedEx them to you.
True. And I can also pay for the binding I'd prefer, too, I suppose.
>Personally I like the fact that anywhere I have Internet access, I have
>access to the datasheets. I don't have to worry about losing copies.
>And I can archive the full datasheets for every device I have ever
>worked with inside one drawer of one filing cabinet (and that drawer
>isn't full).
I didn't say I don't want access to the more recent information, nor that I
don't want PDFs. I'm quite glad to have them about. But I would also like to
have the product manufacturers still printing the books and making them
available through distribution channels, as before. What is the harm in still
printing, but in allowing the PDF format to replace paper in those cases where
people like you are perfectly happy that way? Or where the information is being
scanned on the idea of *maybe* using the part, but before you really need to dig
in because you've decided to actually use it. Once I've committed myself to a
part, I want paper. Simple as that. The manufacturers obviously have reduced
the demand via PDFs. I think it would be a nice service to still offer paper in
those cases where a customer is actually committed to the part and has requested
a paper copy. I don't think there is a good excuse for failing to go that extra
mile -- except that they can get away with it.
Jon
Ulf Samuelsson
> which I can then read while enthroned, taking a bath, going to
> sleep, whatever. I can even add Postit notes to mark things, or
> write in the margin, after Pascal. I am not about to wear out my
> hardware printing a 400 page (or more) manual, and possibly getting
> nothing but a large paper jam out of it.
>
> Fineprint (and its booklet mode) is a partial savior.
>
> I would always choose the hardware with printed documentation.
>
There are two reasons behind abolishing databooks.
1) Cost of distribution
2) Time to obsolence of information.
If you do not want to wear out your hardware, there are plenty of
people out there that can print the document for you.
Is this going to cost you, yes.
The amount of money that you are prepared to pay to get it printed
defines your value of printed documentation.
Would be interesting to know how much this is.
Personally ; I like printed documentation as well, but I print it out when I
need it on two pages per sheet/double sided.
You need a good laser with this strategy.
Jonathan Kirwan
wrote:
>If you do not want to wear out your hardware, there are plenty of
>people out there that can print the document for you.
>Is this going to cost you, yes.
>The amount of money that you are prepared to pay to get it printed
>defines your value of printed documentation.
>Would be interesting to know how much this is.
>
>Personally ; I like printed documentation as well, but I print it out when I
>need it on two pages per sheet/double sided.
>You need a good laser with this strategy.
As you say, I personally know the value of the printed versions I get now
because I print it myself and do so exactly because it is worth the effect when
I get to that point.
However, as you also point out at the end here, it does require a good duplexing
printer and duplexing isn't a common standard feature, though it *is* an option
on some. In general, your price of print hardware goes up significantly when
you add duplexing, as it both reduces your selectable options as well as usually
adds either an expensive option that is difficult to readily locate in the
supply chain or else forces the purchase of an premium printer type where
duplexing is standard. Either way, you've "moved up" a noticeable step.
In my specific case, the ONLY reason I am currently in the market for a
duplexing laser printer is for printing these data sheets. Without that pushing
me, I'd be happy with my current printer arrangements (none of which support
duplexing as an option.) So again I am demonstrating the value of these printed
copies -- by not only making day-to-day investments in time and supply costs,
but now by making capital investments in extending my printing capabilities in
order to buy some of my time back, but driven by this sole reason of printing.
I don't think there is any question of the value of the printed documentation.
The point is that the burden has been quite clearly shifted, from larger
companies with some measure of control onto many smaller companies with no real
control. Simply because they could.
Jon
Andreas
Paul Carpenter
u...@atmel.nospam.com "Ulf Samuelsson" wrote:
>> Fundamental difference in attitude here. I really need hard copy
>> which I can then read while enthroned, taking a bath, going to
>> sleep, whatever. I can even add Postit notes to mark things, or
>> write in the margin, after Pascal. I am not about to wear out my
>> hardware printing a 400 page (or more) manual, and possibly getting
>> nothing but a large paper jam out of it.
>>
>> Fineprint (and its booklet mode) is a partial savior.
>>
>> I would always choose the hardware with printed documentation.
>>
>
>There are two reasons behind abolishing databooks.
>1) Cost of distribution
Assumes ALL manufacturers actually distribute the information
electronically. Sometimes if you have to maintain a device containing
an obsolete part to work out how to replace it paper documents are
easier to find, how often manuafacturers DELETE the electronic
information amazes me.
>2) Time to obsolence of information.
Considering *SOME* manufacturers, getting errata sheets or even PDFs
that actually match the parts is still the same as paper.
>If you do not want to wear out your hardware, there are plenty of
>people out there that can print the document for you.
>Is this going to cost you, yes.
>The amount of money that you are prepared to pay to get it printed
>defines your value of printed documentation.
>Would be interesting to know how much this is.
>
>Personally ; I like printed documentation as well, but I print it out when I
>need it on two pages per sheet/double sided.
>You need a good laser with this strategy.
The main advantages of paper documents:-
1/ Easier to read and use anywhere.
2/ Works even during a power cut (assuming during daylight hours),
or system failure. Just like pen and paper.
3/ Easier for meetings and the like
4/ Easier for interfacing designs and reviews, having MULTIPLE
different data sheets open to cross reference the information at
the same time as well as any notes or diagrams you have as well.
Physical desktop is still easier than 'virtual desktop'.
5/ There still lots of managers, end customers and the like who don't
believe something unless it is on a bit of paper.
Disadvantages of paper
1/ Harder to archive
2/ Harder to search especially when it is a printed version that is
supposed to be viewed electronically.
Disadvantages of PDF documents
Being electronic documents it should be easier to cross-referenece
all related parts of long documents. So that designers don't get caught
out by the this works if you follow the information in sections 3, 23
39 and 58, which are not always searchable as they describe the function
using different descriptions.
Some datasheets appear to be cobbled together blocks of standard
sub-sections without the internal interfacing quirks properly described.
Others appear as a collection of various peoples ramblings.
Examples of standard sub-sections are best shown by parts like I2C
devices where it is often obvious that the hardware and the I2C
control have been written by two different people and not properly
linked together.
--
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
Ed Beroset
>
> The main advantages of paper documents:-
>
> 1/ Easier to read and use anywhere.
True. There is still no display that does as well as a simple sheet of
paper.
> 2/ Works even during a power cut (assuming during daylight hours),
> or system failure. Just like pen and paper.
My laptop rides through power failures with no problem. My PDA does,
too, and both can display PDF docs.
> 3/ Easier for meetings and the like
It depends on what you're used to. I almost always bring a laptop to
meetings. If you want to share the document, a projector works very
well -- but it's not cheap!
> 4/ Easier for interfacing designs and reviews, having MULTIPLE
> different data sheets open to cross reference the information at
> the same time as well as any notes or diagrams you have as well.
> Physical desktop is still easier than 'virtual desktop'.
One thing I've done is to convert a project schematic into a jpg format
and then creating a web page out of it with hyperlinks from major parts
to datasheets using a rollover map. It sounds a lot harder than it
actually is. The effect is that you can look at the schematic, click on
a part and it automagically pulls up a datasheet. In some cases, the
hyperlink is to a web page which lists multiple datasheets. All of this
is within a subdirectory tree on my hard drive, so I don't have to worry
about manufacturer's web sites shuffling things around.
> 5/ There still lots of managers, end customers and the like who don't
> believe something unless it is on a bit of paper.
You can always make paper from PDF. Going the other way 'round is a
little harder.
Two other advantages of paper you omitted:
6/ Ten years from now, paper documents will still be readable because
the interfacing equipment (your eyeballs) will still be the same. I've
got some project documents in DisplayWriter format on 5.25" floppies
here somewhere...
7/ Twenty years from now, paper documents will still be readable because
the media will not have degraded significantly. CDs degrade over that
amount of time and start getting hard to read. Tapes and floppies
degrade even faster.
> Disadvantages of PDF documents
>
> Being electronic documents it should be easier to cross-referenece
> all related parts of long documents. So that designers don't get caught
> out by the this works if you follow the information in sections 3, 23
> 39 and 58, which are not always searchable as they describe the function
> using different descriptions.
> Some datasheets appear to be cobbled together blocks of standard
> sub-sections without the internal interfacing quirks properly described.
> Others appear as a collection of various peoples ramblings.
This is not unique to PDF documents. Poor writing is poor writing!
Ed
Ian Bell
snip
>
> There are two reasons behind abolishing databooks.
> 1) Cost of distribution
> 2) Time to obsolence of information.
Interesting. Until pdf versions became commonplace I found semi
manufacturers more than happy to supply data books. They were a sellng tool
that helped get their parts designed in. I can still flip thru a few books
faster than the same pdf files.
Also I daily use a MHS 8051 databook printed in 1980 because the core of the
8051 is the same now as then.
Ian
--
Ian Bell
CBFalconer
>
>> Fundamental difference in attitude here. I really need hard copy
>> which I can then read while enthroned, taking a bath, going to
>> sleep, whatever. I can even add Postit notes to mark things, or
>> write in the margin, after Pascal. I am not about to wear out my
>> hardware printing a 400 page (or more) manual, and possibly getting
>> nothing but a large paper jam out of it.
>>
>> Fineprint (and its booklet mode) is a partial savior.
>>
>> I would always choose the hardware with printed documentation.
>
> There are two reasons behind abolishing databooks.
> 1) Cost of distribution
> 2) Time to obsolence of information.
>
> If you do not want to wear out your hardware, there are plenty of
> people out there that can print the document for you.
> Is this going to cost you, yes.
> The amount of money that you are prepared to pay to get it printed
> defines your value of printed documentation.
> Would be interesting to know how much this is.
>
> Personally ; I like printed documentation as well, but I print it
> out when I need it on two pages per sheet/double sided.
> You need a good laser with this strategy.
You may notice I pointed out the fineprint utility. That gives me
four pages per sheet, and the results can be folded, punched and
filed in a 5.5 x 8.5 inch binder. I can also easily eliminate the
many blank pages, and some other useless (to me) stuff, such as
extensive licensing notices, lists of dealers, etc. See
<http://www.fineprint.com>
I am still willing to put up with obsolescence in order to avoid
the printing. The pain threshold is about 40 pages, with
feasability ending at about 120 pages. The cost of mass printing
is much lower than that using my laser, not to mention my time and
effort.
CBFalconer
> "Ulf Samuelsson" <u...@atmel.nospam.com> wrote:
>
>> If you do not want to wear out your hardware, there are plenty of
>> people out there that can print the document for you.
>
>
> However, as you also point out at the end here, it does require a
> good duplexing printer and duplexing isn't a common standard
> feature, though it *is* an option on some. In general, your price
> of print hardware goes up significantly when you add duplexing, as
> it both reduces your selectable options as well as usually adds
> either an expensive option that is difficult to readily locate in
> the supply chain or else forces the purchase of an premium printer
> type where duplexing is standard. Either way, you've "moved up" a
> noticeable step.
No, you can make do with a non-duplexing printer and suitable
software. The penalty is a two phase printing operation, and the
non-vanishing probability of a paper jam or multiple sheet pickup
on either pass. This still happens on a duplexing printer, so you
always have to stand by and watch it. For example, I have learned
that the second phase has to wait until the paper has cooled (with
my printer at least).
Spehro Pefhany
<cbfal...@yahoo.com> wrote:
>Jonathan Kirwan wrote:
>> "Ulf Samuelsson" <u...@atmel.nospam.com> wrote:
>>
>>> If you do not want to wear out your hardware, there are plenty of
>>> people out there that can print the document for you.
>>
>... snip ...
>>
>> However, as you also point out at the end here, it does require a
>> good duplexing printer and duplexing isn't a common standard
>> feature, though it *is* an option on some. In general, your price
>> of print hardware goes up significantly when you add duplexing, as
>> it both reduces your selectable options as well as usually adds
>> either an expensive option that is difficult to readily locate in
>> the supply chain or else forces the purchase of an premium printer
>> type where duplexing is standard. Either way, you've "moved up" a
>> noticeable step.
>
>No, you can make do with a non-duplexing printer and suitable
>software. The penalty is a two phase printing operation, and the
>non-vanishing probability of a paper jam or multiple sheet pickup
>on either pass. This still happens on a duplexing printer, so you
>always have to stand by and watch it. For example, I have learned
>that the second phase has to wait until the paper has cooled (with
>my printer at least).
I've found 22lb paper to be a little more double-feed resistant than
the cheaper 20lb paper. It's also more opaque.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Ulf Samuelsson
Question is what to print.
With 20-30 AVR datasheets, each 3-500 pages, you would get a fairly thick
book.
Personally , I am advocating printed users manual on the peripherals but not
the parts.
If you dont want the hassle of priting out, then
you could demand from your distributor that he should download and do print
on demand
or if you are a direct customer, then you ask Atmel directly.
I would have things printed for a few customers if the project depended on
that, but not very many.
I think a lot of people want printed databooks as in "free printed
databooks".
If you think about it there are no such things as free databooks you are
wrong.
Either you pay for the databook, or the price of the components go up.
The margins can of course go down, but noone likes that so pricing will
eventually reflect printing cost.
Printing datasheets is also a way to make large volume users subsidize low
volume users.
Ulf Samuelsson
duplexing
> printer and duplexing isn't a common standard feature, though it *is* an
option
> on some. In general, your price of print hardware goes up significantly
when
> you add duplexing, as it both reduces your selectable options as well as
usually
> adds either an expensive option that is difficult to readily locate in the
> supply chain or else forces the purchase of an premium printer type where
> duplexing is standard. Either way, you've "moved up" a noticeable step.
>
Just got myself a nice Laserjet 4050N for $150 on an Internet auction for
home. Same printer as in the office, so I do not even have to add a new
driver :-)
17 ppm + Ethernet, but the duplex unit was not there unfortunately, but I
hope to get one on eBay!
Ulf Samuelsson
printing.
Are you willing to put up with bugs, because you did not read the latest
datasheets?
Ulf Samuelsson
> No, you can make do with a non-duplexing printer and suitable
> software. The penalty is a two phase printing operation, and the
> non-vanishing probability of a paper jam or multiple sheet pickup
> on either pass. This still happens on a duplexing printer, so you
> always have to stand by and watch it. For example, I have learned
> that the second phase has to wait until the paper has cooled (with
> my printer at least).
>
That is trading your time for money.
The duplex unit is currently 47 Euro on Ebay...
Ulf Samuelsson
"Ian Bell" <ruffr...@yahoo.com> skrev i meddelandet
news:crrdnr$hh2$1...@slavica.ukpost.com...
> Ulf Samuelsson wrote:
>
> snip
>
> >
> > There are two reasons behind abolishing databooks.
> > 1) Cost of distribution
> > 2) Time to obsolence of information.
>
> Interesting. Until pdf versions became commonplace I found semi
> manufacturers more than happy to supply data books. They were a sellng
tool
> that helped get their parts designed in. I can still flip thru a few
books
> faster than the same pdf files.
>
Yes, but at that time there were no alternatives.
Noone likes carrying databooks around. But there were no better
alternatives.
What is important now is to make it easier to scan for info.
I do not consider it to be very practical to look for a part with a certain
function
by downloading all the datasheets for all parts.
I'd like to see an application where the computer periodically
downloads the short form for each datasheet (1-4 pages) + index
so that it is available on my computer.
It would allow me to search through a number of documents for a certain
feature.
mc
<la...@larwe.com> wrote in message
news:1105235944....@c13g2000cwb.googlegroups.com...
> Personally I like the fact that anywhere I have Internet access, I have
> access to the datasheets. I don't have to worry about losing copies.
I have quite a few semiconductors, and even some uPs, whose data sheets have
disappeared from the Web! When a product is discontinued, history gets
rewritten as if it had never existed.
mc
"CBFalconer" <cbfal...@yahoo.com> wrote in message
news:41E04499...@yahoo.com...
> Fundamental difference in attitude here. I really need hard copy
> which I can then read while enthroned, taking a bath, going to
> sleep, whatever. I can even add Postit notes to mark things, or
> write in the margin, after Pascal.
Or Fermat? "I have found a marvelous algorithm for this task which this
margin is too small to contain..."
I agree. I do not want to spend 100% of my waking hours staring at a
computer screen. I like to carry the manual into the library, sit down at a
big table, and write programs on paper.
> I am not about to wear out my
> hardware printing a 400 page (or more) manual, and possibly getting
> nothing but a large paper jam out of it.
Fortunately my employer has a good printer which will print 2-sided, and
also a comb binding machine.
> Fineprint (and its booklet mode) is a partial savior.
Maybe with *your* eyes :) I use fine print and booklet mode only for
things I don't actually plan to read, but which must be preserved on paper
for some reason.
mc
"Ulf Samuelsson" <u...@atmel.nospam.com> wrote in message
news:34cv86F...@individual.net...
> I think a lot of people want printed databooks as in "free printed
> databooks".
> If you think about it there are no such things as free databooks you are
> wrong.
> Either you pay for the databook, or the price of the components go up.
So true...and exactly like what I say whenever somebody says that something
around our university should be "free."
mc
keep breadboarding, now that the chips come only in dense surface-mount
packages. They also make some very nice prototype boards that contain the
support circuitry for a uP.
"Andreas" <some...@else.com> wrote in message
news:crr6fd$okd$05$1...@news.t-online.com...
Spehro Pefhany
<u...@atmel.nospam.com> wrote:
>> I am still willing to put up with obsolescence in order to avoid the
>printing.
>
>Are you willing to put up with bugs, because you did not read the latest
>datasheets?
What's really irritating is when you've got parts from a
year-and-a-half ago and you can't find the errata for the parts you
have because they are are two versions earlier than current
production.
Paul Carpenter
<N9aEd.1842$KJ2...@newsread3.news.atl.earthlink.net>
ber...@mindspring.com "Ed Beroset" wrote:
>Paul Carpenter wrote:
>>
>> The main advantages of paper documents:-
>>
>> 1/ Easier to read and use anywhere.
>
>True. There is still no display that does as well as a simple sheet of
>paper.
>
>> 2/ Works even during a power cut (assuming during daylight hours),
>> or system failure. Just like pen and paper.
>
>My laptop rides through power failures with no problem. My PDA does,
>too, and both can display PDF docs.
You forgot system failure, both FAIL if the building holding both is burnt
to the ground!
>> 3/ Easier for meetings and the like
>
>It depends on what you're used to. I almost always bring a laptop to
>meetings. If you want to share the document, a projector works very
>well -- but it's not cheap!
A lot of my customers are small outfits where you gather round a table
or workbench.
>> 4/ Easier for interfacing designs and reviews, having MULTIPLE
>> different data sheets open to cross reference the information at
>> the same time as well as any notes or diagrams you have as well.
>> Physical desktop is still easier than 'virtual desktop'.
>
>One thing I've done is to convert a project schematic into a jpg format
>and then creating a web page out of it with hyperlinks from major parts
>to datasheets using a rollover map. It sounds a lot harder than it
>actually is. The effect is that you can look at the schematic, click on
>a part and it automagically pulls up a datasheet. In some cases, the
>hyperlink is to a web page which lists multiple datasheets. All of this
>is within a subdirectory tree on my hard drive, so I don't have to worry
>about manufacturer's web sites shuffling things around.
No I mean being able to view all relevant documentation SIDE by SIDE.
...
>Two other advantages of paper you omitted:
>
>6/ Ten years from now, paper documents will still be readable because
>the interfacing equipment (your eyeballs) will still be the same. I've
>got some project documents in DisplayWriter format on 5.25" floppies
>here somewhere...
>
>7/ Twenty years from now, paper documents will still be readable because
> the media will not have degraded significantly. CDs degrade over that
>amount of time and start getting hard to read. Tapes and floppies
>degrade even faster.
This is true of ALL the documentation of a project.
Jonathan Kirwan
wrote:
>I think a lot of people want printed databooks as in "free printed
>databooks". If you think about it there are no such things as free
>databooks you are wrong.
Well, that's not how I think about it.
In some cases, distributors *did* hand out books like popcorn. But that wasn't
my fault. That is the fault of the arrangements between the manufacturer and
the distributors. In this day of ready PDF files, there is no need at all for
distributors to just give these away to everyone, even if they are only just
getting them to "have them." A manufacturer can simply trust their distributors
(and require them, by arrangement) to not distribute paper copies unless and
until a project commitment has been made to use a part contained in them. And,
if needed, the situation with the distributors can require that this be only on
the bases of a sufficient business expectation based on discussions between the
distributor and the customer and not a hobby thing.
It's not as you suggest.
Jon
Jonathan Kirwan
>No, you can make do with a non-duplexing printer and suitable
>software. The penalty is a two phase printing operation, and the
>non-vanishing probability of a paper jam or multiple sheet pickup
>on either pass. This still happens on a duplexing printer, so you
>always have to stand by and watch it. For example, I have learned
>that the second phase has to wait until the paper has cooled (with
>my printer at least).
Chuck, this is what I've been doing for so many years I can't remember when I
started. But it's not good. My HP laserjets (a II and a III) do jam up
sometimes at very inconvenient times on the second pass. The paper, having been
written once and heated, curls some. Allowing time between passes definitely
helps, as you say. As does some manual 'working' of the paper stack. But in
general all this takes labor, adds the risk of more time, and complicates the
second pass.
More, when I looked into the thick manuals from HP on paper handling, they
explicitly state that the printer is guaranteed to work only single sided and
they don't promise proper functioning the second go-around -- and I can see
their point, having tried to ignore their comments all these years.
So, yes, I'm in the market.
Jon
Jonathan Kirwan
wrote:
>Just got myself a nice Laserjet 4050N for $150 on an Internet auction for
>home. Same printer as in the office, so I do not even have to add a new
>driver :-)
>17 ppm + Ethernet, but the duplex unit was not there unfortunately, but I
>hope to get one on eBay!
Excellent! I'll have to watch for another.
Jon