|
Home > Archive > Electrical Engineering > March 2007 > Which uController to learn?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Which uController to learn?
|
|
| John E. 2007-03-15, 5:25 pm |
| PIC is king, I'm sure. But I'd like to hear from those who are using all
brands. Whichever you use, what do you like about it? What don't you like
about others? Suggestions re. learning?
I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
Thanks,
--
John English
| |
| Ian Bell 2007-03-15, 5:25 pm |
| John E. wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN;
> some BASIC; COBOL if forced to admit it), so no stranger to programming,
> per se.
>
> Thanks,
The answer is strongly application dependent.
Ian
| |
| Eeyore 2007-03-15, 5:25 pm |
|
"John E." wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it?
8051 family. You can't keep a good chip down. It's been going since 1981 IIRC.
NXP's (formerly Philips) variants do all sorts of useful stuff with the 8051 core
plus their RAM is static now so you can reduce the clock to zero to save power.
And the 8051 is multi-sourced !
> What don't you like about others?
PICs are indifferently documented so I've heard. I also heard something about
dodgy compilers.
Graham
| |
|
|
| martin griffith 2007-03-15, 5:25 pm |
| On Thu, 15 Mar 2007 13:52:06 -0700, in sci.electronics.design John E.
<incognito@yahoo.com> wrote:
>PIC is king, I'm sure. But I'd like to hear from those who are using all
>brands. Whichever you use, what do you like about it? What don't you like
>about others? Suggestions re. learning?
>
>I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
>BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
>Thanks,
I'd start with lurking the usergroups, such as 8052.com and avrfreaks,
dont't know about a group for the MSP430. See what they are doing,
then pic(k) one. Lots of cheap eval boards. Some of the ARM micros
look amazing, but beyond my comprehension
Comp.arch.embedded NG usually has a "my micro is better than your
micro" thread going.
Also checkout GCC compilers, Winavr etc. as you seem to be qualified
for the dreaded makefile.
And be sure to practice your soldering skills/ interfacing techniques,
this is very important compared with the Windoze World
martin
| |
| jetq88 2007-03-15, 5:25 pm |
| On Mar 15, 3:52 pm, John E. <incogn...@yahoo.com> wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
> Thanks,
> --
> John English
AVR, M68HC, PIC, pick either one, find a C compiler, go with it, some
chips have free compiler out there, like winavr for avr.
| |
| John E. 2007-03-15, 5:25 pm |
| Thanks for your comments, Martin.
> And be sure to practice your soldering skills/ interfacing techniques,
> this is very important compared with the Windoze World
That's really why I'm interested in getting into the u-controller world. To
interface hardware to the "real world".
Soldering iron warmed up and at the ready...
--
John English
| |
|
|
| Brendan Gillatt 2007-03-15, 5:25 pm |
| On Thu, 15 Mar 2007 13:52:06 -0700, John E. <incognito@yahoo.com>
wrote:
>PIC is king, I'm sure. But I'd like to hear from those who are using all
>brands. Whichever you use, what do you like about it? What don't you like
>about others? Suggestions re. learning?
>
>I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
>BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
>Thanks,
You can't really say what one is 'best' - it depends on what you
really want to do.
Even with PICs it's hard to say which is best - from tiny 8 pin
controllers to massive 44 pin processing beasts with hundreds in
between.
PIC assembly is tiresome at the least. The instruction set is tiny
which means that they take considerably more coding than, say, x86
assembly.
Atmel micros are becoming popular too - though I haven't had any
experience with them.
Depending on what you want, you may look at *gasp* Basic Stamps, made
by Parralax (sp?) if you know BASIC well - just don't count on amazing
performance.
| |
| martin griffith 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 15:11:02 -0700, in sci.electronics.design John E.
<incognito@yahoo.com> wrote:
>Thanks for your comments, Martin.
>
>
>That's really why I'm interested in getting into the u-controller world. To
>interface hardware to the "real world".
>
>Soldering iron warmed up and at the ready...
<sticking neck out>
checkout:
SPI interface, (realtime clocks, external eeproms etc.)
I2C, the uberversal philips interface, same as SPI, but different, and
pain in the neck IMHO
logic fets
H bridge
opto isolators
Reset and brownout detectors/ TL77xx etc from TI
and the universal "why doesn't my 2*8 LCD work"
Cos it takes many milliseconds to initialise, check the Fuckin* busy
flag
</sticking neck out>
and get a decent bench/lab power supply with adjustable current
limiting, and a scope
martin
| |
| John E. 2007-03-15, 8:25 pm |
| > and get a decent bench/lab power supply with adjustable current
> limiting, and a scope
Still looking into the former (many decent PS models coming out of Asia,
recently); got a couple of scopes.
Thanks,
--
John English
| |
| Anthony Fremont 2007-03-15, 8:25 pm |
| Eeyore wrote:
> "John E." wrote:
>
>
> 8051 family. You can't keep a good chip down. It's been going since
> 1981 IIRC. NXP's (formerly Philips) variants do all sorts of useful
> stuff with the 8051 core plus their RAM is static now so you can
> reduce the clock to zero to save power. And the 8051 is multi-sourced
> !
>
>
>
> PICs are indifferently documented so I've heard. I also heard
> something about dodgy compilers.
Oh gawd. The biggest problem I've seen with PIC documentation is that
people won't read it. Almost every quirk and pitfall now gets fancy shaded
background balloons complete with code examples.
The only "dodgy" compiler I ever dealt with was SDCC for the 8052, what a
POS. It may be better now, but a few years ago it sucked bad. Of course I
don't even bother trying to use C on a PIC, it's just not desiged for it.
The 18Fs are different though, they do C ok. FWICT, everyone seems happy
with Microchip's ever-lasting "trial" C compiler for the 18Fs.
Multisourced, that's another misrepresentation. For the most part, chips
from different vendors are just similar archetectures, not "compatible"
chips insofar as actually being able to drop one in place of another. Not
to mention how vastly incompatible the code internals are for anything but
the most basic peripherals.
But that's just my opinion. ;-)
| |
| petrus bitbyter 2007-03-15, 8:25 pm |
|
"John E." <incognito@yahoo.com> schreef in bericht
news:0001HW.C21F0006000A0C96F04886C8@news.sf.sbcglobal.net...
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN;
> some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per
> se.
>
> Thanks,
> --
> John English
>
I often point to
http://www.voti.nl/swp/n_index.html
for an intro in PIC micro's.
If you have experience in 68000 then AVR may suit you better.
petrus bitbyter
| |
| David L. Jones 2007-03-15, 8:25 pm |
| John E. wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
PIC and Atmel AVR battle it out for the top spot in the entry level
market, you will get tons of beginner support (hardware, software, and
sample code) for either platform, arguably more than any other
platfrom.
Which is the "best" is dependant upon your application. For example,
if you do *really* low power stuff then the MSP430 series is very
popular. If you want seamless migration from Flash to OTP to Mask ROM
then PIC might be the way to go. If you want fast processing with a
reasonable number of options then AVR might be the best bet. The list
is endless...
For starting out, stick with AVR or PIC, and use a high level language
like C. Both platforms have free C compiler suites, but IMHO the AVR
GNU compiler is a PITA to get up and running, and the worst problem
you can have when starting out is having to fight your tools. Also, I
think the AVR STK500 programmer is (or was) a complete dog, horrible
for a beginner. PICs have their quirks too, but I had a *lot* more
trouble when starting out with the AVR's. But no doubt the AVR crowd
will shoot me down in flames...
The PIC 18 series C compiler is essentially free from Microchip, and
that combined with an MPLAB compatible programmer would be a very good
and powerful starting platform if you don't want to play with the
kiddie kits. However there are tons of good PIC starter kits and demo
boards around, just look at the Farnell catalog or any of the
multitude of PIC supplier website for starters.
Dave.
| |
| David L. Jones 2007-03-15, 8:25 pm |
| On Mar 16, 8:51 am, "Anthony Fremont" <spam-...@nowhere.com> wrote:
> Eeyore wrote:
>
>
>
>
>
> Oh gawd. The biggest problem I've seen with PIC documentation is that
> people won't read it. Almost every quirk and pitfall now gets fancy shaded
> background balloons complete with code examples.
>
> The only "dodgy" compiler I ever dealt with was SDCC for the 8052, what a
> POS. It may be better now, but a few years ago it sucked bad. Of course I
> don't even bother trying to use C on a PIC, it's just not desiged for it.
If you use a good C compiler like HI-TECH PIC-C then it works just
fine on any 16series (or even smaller) PIC. You can do heaps with C on
only 1K memory devices with a good compiler.
> The 18Fs are different though, they do C ok. FWICT, everyone seems happy
> with Microchip's ever-lasting "trial" C compiler for the 18Fs.
Yeah, very few limitations by the looks of it. I don't know why they
don't just make it free and be done with it. It would put a lot of the
other tool companies noses out of joint though I guess...
Dave.
| |
| Spehro Pefhany 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 22:21:33 +0000, the renowned Brendan Gillatt
<brendan@brendanREMOVETHISgillatt.co.uk> wrote:
>On Thu, 15 Mar 2007 13:52:06 -0700, John E. <incognito@yahoo.com>
>wrote:
>
>
>You can't really say what one is 'best' - it depends on what you
>really want to do.
>
>Even with PICs it's hard to say which is best - from tiny 8 pin
>controllers to massive 44 pin processing beasts with hundreds in
>between.
Not to mention the 64, 68, 80 and 100-pin ones.
>
>PIC assembly is tiresome at the least. The instruction set is tiny
>which means that they take considerably more coding than, say, x86
>assembly.
There are several flavo[r]s to PIC assembly.
>Atmel micros are becoming popular too - though I haven't had any
>experience with them.
>
>Depending on what you want, you may look at *gasp* Basic Stamps, made
>by Parralax (sp?) if you know BASIC well - just don't count on amazing
>performance.
That thing is not 'a microcontroller'.
As to the original question.. it really depends on the application and
the peripherals you might need. If you need Ethernet and/or USB on
board, that's one thing (you'll almost certainly want something with a
decent C compiler and available protocol stack), if you just want to
diddle some bits fast, or do a relatively slow PID control that's
another. If you need 10, 12, or 24 bits of ADC, multiple PWMs,
quadrature input, direct display drive, etc. etc. that may play a
great role. The choice of core is only one consideration among many.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
| |
| Spehro Pefhany 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 23:41:18 +0100, the renowned martin griffith
<mart_in_medina@ya___.es> wrote:
>On Thu, 15 Mar 2007 15:11:02 -0700, in sci.electronics.design John E.
><incognito@yahoo.com> wrote:
>
>
><sticking neck out>
>checkout:
>SPI interface, (realtime clocks, external eeproms etc.)
>I2C, the uberversal philips interface, same as SPI, but different, and
>pain in the neck IMHO
>logic fets
>H bridge
>opto isolators
>Reset and brownout detectors/ TL77xx etc from TI
>
>and the universal "why doesn't my 2*8 LCD work"
>Cos it takes many milliseconds to initialise, check the Fuckin* busy
>flag
Or just put some proper (debugged) delays in there and it'll work
fine. And the second line of your 2 x 16 doesn't work because the
memory map has a big frick'n hole in it...
></sticking neck out>
>
>and get a decent bench/lab power supply with adjustable current
>limiting, and a scope
>
>
>martin
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
| |
| TT_Man 2007-03-15, 8:25 pm |
|
"John E." <incognito@yahoo.com> wrote in message
news:0001HW.C21F0006000A0C96F04886C8@news.sf.sbcglobal.net...
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN;
> some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per
> se.
>
> Thanks,
> --
> John English
>
For a no frills easy to understand and get going, I'd say 8051 series.
The Dallas 89c450 and Atmel 89c51ED2 both have hardware boot loaders so you
can get code into them very quickly and see whats going on with your code.
I hate C
| |
| Anthony Fremont 2007-03-15, 8:25 pm |
| martin griffith wrote:
> On Thu, 15 Mar 2007 15:11:02 -0700, in sci.electronics.design John E.
> <incognito@yahoo.com> wrote:
>
>
> <sticking neck out>
> checkout:
> SPI interface, (realtime clocks, external eeproms etc.)
> I2C, the uberversal philips interface, same as SPI, but different, and
> pain in the neck IMHO
> logic fets
> H bridge
> opto isolators
> Reset and brownout detectors/ TL77xx etc from TI
>
> and the universal "why doesn't my 2*8 LCD work"
> Cos it takes many milliseconds to initialise, check the Fuckin* busy
> flag
Ah grasshopper, but that's the whole problem. You can't check the busy flag
when your doing initialization. At least it used to be that way. Most
circuits I've seen hard-wire the R/W pin so that they can't even read the
busy flag, they just do the delays. So sad, cuz some displays really haul
XXX if you do the busy flag thing.
> </sticking neck out>
>
> and get a decent bench/lab power supply with adjustable current
> limiting, and a scope
Most definitely gots to have that scope. Speaking of which, I just got my
very first DSO today. Ahhhhhhhhh..... this is the coolest thing ever.
;-)
| |
| John E. 2007-03-15, 8:25 pm |
| > Which is the "best" is dependant upon your application.
Well, to be fair, I didn't ask for "best". That's always a dead-end (or
open-end) discussion.
I'm really interested in my options for assembly programming for interfacing
with sensors, switches, etc., and controlling relays, LEDs, maybe the odd
7-segment or serial display. I don't think I'll need networking, or such, nor
that I'll get back into learning a high-level language (never tackled 'C' - I
think that would be a show-stopper, re. getting started with u-controllers).
So, I guess I'm asking for the the product line with the most supporting
(good) documentation and examples and which has the potential for easing me
toward my goal (ie, my previous para.) with the least hair-pulling.
Thanks,
--
John English
| |
| Anthony Fremont 2007-03-15, 8:25 pm |
| David L. Jones wrote:
> On Mar 16, 8:51 am, "Anthony Fremont" <spam-...@nowhere.com> wrote:
>
> If you use a good C compiler like HI-TECH PIC-C then it works just
> fine on any 16series (or even smaller) PIC. You can do heaps with C on
> only 1K memory devices with a good compiler.
I've never used it, but I've heard good things about it. I always use
assembler on the PIC. I've used the Keil compiler on the 8052, sweet. It
really generates dense code. Never done anything with an 18F yet, but I
plan to whenever I need that much horsepower. I have to admit that there
have been times that I've longed to be writing something for the PIC in
other than assembler.
>
> Yeah, very few limitations by the looks of it. I don't know why they
> don't just make it free and be done with it. It would put a lot of the
> other tool companies noses out of joint though I guess...
I'll have to order some 18Fs and give it a try. I got my Rigol scope today.
Oh man this is just way too cool. :-)))
| |
| Eeyore 2007-03-15, 8:25 pm |
|
Anthony Fremont wrote:
> Eeyore wrote:
>
> Oh gawd. The biggest problem I've seen with PIC documentation is that
> people won't read it. Almost every quirk and pitfall now gets fancy shaded
> background balloons complete with code examples.
>
> The only "dodgy" compiler I ever dealt with was SDCC for the 8052, what a
> POS. It may be better now, but a few years ago it sucked bad. Of course I
> don't even bother trying to use C on a PIC, it's just not desiged for it.
> The 18Fs are different though, they do C ok. FWICT, everyone seems happy
> with Microchip's ever-lasting "trial" C compiler for the 18Fs.
>
> Multisourced, that's another misrepresentation. For the most part, chips
> from different vendors are just similar archetectures, not "compatible"
> chips insofar as actually being able to drop one in place of another. Not
> to mention how vastly incompatible the code internals are for anything but
> the most basic peripherals.
>
> But that's just my opinion. ;-)
Eh ?
The various 8051 clones from various manufacturers are completely compatible in
every respect. That's one of the joys of the part. Such changes as have been
made are backwardly compatible even with no code change too.
Graham
| |
| linnix 2007-03-15, 8:25 pm |
|
> if you do *really* low power stuff then the MSP430 series is very
> popular.
You can also clock an Avr slowly and runs on uW.
The butterfly runs in stand-by mode for months on a single button
cell.
> If you want seamless migration from Flash to OTP to Mask ROM
> then PIC might be the way to go. If you want fast processing with a
> reasonable number of options then AVR might be the best bet.
But I would not call an Avr fast, not comparing to an Arm.
I have a 20MHz(50 Mhz max) Arm talking to a 8Mhz(16MHz max) Avr.
The Arm is around 5 to 10 times faster than the Avr.
They are roughly the same size, cost and complexity.
| |
|
| On Mar 15, 3:52?pm, John E. <incogn...@yahoo.com> wrote:
Hey John.
We're an "8051" Shop mostly.
And almost everything we do is in Assembler.
Right now, we're using Atmel and Phillips (NXP or whatever they call
themselves now).
What I like about Atmel is:
A - They're very responsive when you need them (which isn't often
because their documentation is some of the best I've seen.)
B - For programming their newer devices, all you need is $25 for their
AT89ISP adapter (and a target board - which you can make yourself or
just butcher one of your production boards and dedicate it as your new
"bench programmer" - which is what we did. No more spending $1,000's
on EPROM burners!!
C - Their product mix is varied enough (i.e., A/D conversion, # of
ports, Serial, etc..) that you can make most designs work. And
"Yes." it is a fine line between "hobbist" and "serious volume
production" sometimes. Or so we would all wish.....!!
For Phillips - I like their smaller stuff. 89LPC90x series.
They're a little flaky to get programmed (due mostly to poor
documentation and IMHO too many hobbiest in the mix), but we do use
them in production volumes.
The Keil EPM900 board is a good development board for the above, and
runs about $200.
Plus the cost of many, many, many phone calls to Keil to get an order
placed.
(Note: This company THRIVES on Voice Mail.)
But good stuff once you get it, and get it working.
The EPM900 will come with a 4K code limited Assembler, C-Compiler and
Debugger (in addition to the hardware emulator). All in all, a pretty
good value.
I looked at PIC's a few times and didn't like them.
Hard to say exactly why, I guess. Their basic stamp stuff seemed
overpriced and underpowered.
And really, I think those are out there for experimenters and
hobbyist, not serious production.
(Now everyone will beat up on me for saying that..?)
But I hope this (and the comments of others) gives you something to
ponder while making your choices. COBOL, huh?! Good for you!
Eventually all the other COBOL programmers will die out and you can
name your price!!
-mpm
| |
| martin griffith 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 18:28:28 -0500, in sci.electronics.design "Anthony
Fremont" <spam-not@nowhere.com> wrote:
snip
>Ah grasshopper, but that's the whole problem. You can't check the busy flag
>when your doing initialization. At least it used to be that way. Most
>circuits I've seen hard-wire the R/W pin so that they can't even read the
>busy flag, they just do the delays. So sad, cuz some displays really haul
>XXX if you do the busy flag thing.
>
>
years ago I was given a few lines or so of C for an 8051, that has
never failed me. But then I'm not a real programmer, most of my crap
is just a few switch statements,
Boil a FET
Nuke a motor,
LCD Prompt" do you need fries with that" etc.
but good enuff for me, does the job.
Maybe I should go and have another look at it?
grasshopper,
over and out
martin
| |
| John E. 2007-03-15, 8:25 pm |
| > I got my Rigol scope today. Oh man this is just way too cool. :-)))
Just looked at their web site. Top of the line is only EUR1800 (how the heck
do I make a Euro symbol...?), US$2376. Not bad. FInally a DSO the average guy
can afford. Keep us informed...
--
John English
| |
|
|
| martin griffith 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 19:27:53 -0500, in sci.electronics.design Spehro
Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:
>On Thu, 15 Mar 2007 23:41:18 +0100, the renowned martin griffith
><mart_in_medina@ya___.es> wrote:
>
>
>Or just put some proper (debugged) delays in there and it'll work
>fine. And the second line of your 2 x 16 doesn't work because the
>memory map has a big frick'n hole in it...
>
>
>
>Best regards,
>Spehro Pefhany
Yep I agree, my system (that's a bit of an overstatement) would hang
if the LCD wasn't present. But if there was no LCD you coudln't use
the system, so the user was, well.....screwed.
so just put on another cup of coffee
martin
| |
| John Fields 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 21:00:07 +0000, Eeyore
<rabbitsfriendsandrelations@hotmail.com> wrote:
>
>
>"John E." wrote:
>
>
>8051 family. You can't keep a good chip down. It's been going since 1981 IIRC.
>NXP's (formerly Philips) variants do all sorts of useful stuff with the 8051 core
>plus their RAM is static now so you can reduce the clock to zero to save power.
>And the 8051 is multi-sourced !
>
>
>
>PICs are indifferently documented so I've heard. I also heard something about
>dodgy compilers.
---
Instead of writing about what you've heard, dumb XXX, why don't you
stick with what you know?
Oh, I get it now... If you did you wouldn't have a whole lot to
write about.
--
JF
| |
| zwsdotcom@gmail.com 2007-03-15, 8:25 pm |
| On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
> PIC is king, I'm sure.
Be wary of certitude. PIC's bizarre fscked architecture is abhorred by
right-thinking engineers (of course, there are no absolutes, but this
is quite close to one).
If you have experience as you have enumerated, you will have little
difficulty learning almost any architecture; the choice of which is
"useful" depends on the "use" to which you intend to apply this
knowledge.
| |
| Anthony Fremont 2007-03-15, 8:25 pm |
| John E. wrote:
>
> Just looked at their web site. Top of the line is only EUR1800 (how
> the heck do I make a Euro symbol...?), US$2376. Not bad. FInally a
> DSO the average guy can afford. Keep us informed...
Bought the DS1102C (100MHz/2-channel) for US$999. So far so good, I like
it. :-)
| |
| Anthony Fremont 2007-03-15, 8:25 pm |
| Eeyore wrote:
> Anthony Fremont wrote:
>
> Eh ?
>
> The various 8051 clones from various manufacturers are completely
> compatible in every respect. That's one of the joys of the part. Such
> changes as have been made are backwardly compatible even with no code
> change too.
Things must have changed then. Only the barest parts would be compatible.
As soon as you start adding extra peripherals (and these _are_ the chips
that get used in production, not the 8051 true clones) things change allot.
So it's true that you could probably get away with dropping an Atmel 89c52
in place of a vintage 8052, it likely wouldn't work the other way around
since the Atmel part has "extensions". As soon as people utilize the
extensions, compatibility disappears. no?
| |
| Eeyore 2007-03-15, 8:25 pm |
|
Anthony Fremont wrote:
> Eeyore wrote:
>
>
> Things must have changed then. Only the barest parts would be compatible.
> As soon as you start adding extra peripherals (and these _are_ the chips
> that get used in production, not the 8051 true clones)
I don't know about that. Some of the extra functions seem to be implemented both
by Philips and Atmel for example. Sure you can use an 89C51 with flash memory in
place of an 87C51 to take the simpler example.
> things change allot.
> So it's true that you could probably get away with dropping an Atmel 89c52
> in place of a vintage 8052, it likely wouldn't work the other way around
> since the Atmel part has "extensions". As soon as people utilize the
> extensions, compatibility disappears. no?
Manufacturers seem to have been careful about allocating the new SFRs. I've
never come across an example where a 'new' SFR didn't default to 'plain vanilla'
operation if left untouched.
Graham
| |
| Rich Grise 2007-03-15, 8:25 pm |
| On Thu, 15 Mar 2007 13:52:06 -0700, John E. wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
I'm prejudiced against the PIC because bank switching is Evil.
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
As a hobbyist: 6502, 6800/02/09, Z80; as a pro, 68HC11, Z80, 80186 ;-)
Cheers!
Rich
| |
| Anthony Fremont 2007-03-15, 9:25 pm |
| Eeyore wrote:
> Anthony Fremont wrote:
>
>
> I don't know about that. Some of the extra functions seem to be
> implemented both by Philips and Atmel for example. Sure you can use
> an 89C51 with flash memory in place of an 87C51 to take the simpler
> example.
>
>
>
> Manufacturers seem to have been careful about allocating the new
> SFRs. I've never come across an example where a 'new' SFR didn't
> default to 'plain vanilla' operation if left untouched.
That's true, but wasn't really my point. I'm saying that people use these
"special features" and then they narrow (or eliminate) their source options.
Where parts from different vendors do have similar extensions, they don't
usually implement the SFRs the same way. It's been a while since I looked
around, maybe vendors are getting on the same page now (why do I really
doubt that though ;-).
| |
|
| In article <0001HW.C21F0006000A0C96F04886C8@news.sf.sbcglobal.net>, incognito@yahoo.com says...
>
>PIC is king, I'm sure. But I'd like to hear from those who are using all
>brands. Whichever you use, what do you like about it? What don't you like
>about others? Suggestions re. learning?
In the early days, though I'm sure that has changed, the stack depth was way
too short for any reasonable level of subroutine coding, this also affected
the design of systems which needed multiple (flexiblely) prioritised
interrupt sources...
Since I had been using the 8051 and atmel variants which had far deeper
stacks and ease of changing returns and flexible control of interrupt
response I had never any need to revisit the PIC.
Oh and the code/data memoru separation I found to be irritating on odd
occasions,
>I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
>BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
From what I recall the 68000 series was the closest to a orthogonal instruction
set making for great compiler efficiencies, with the later generaton of PICS
there were, iirc, still many instruction exceptions which didnt allow compilers
to be as efficient could have been good for assembler writers but you really
dont want to stay in assembler as generally projects get more complex and we
do want to have a social life dont we ?
--
Regards
Mike
* VK/VL Commodore FuseRails that wont warp or melt with fuse failure indication
and now with auto 10-15 min timer for engine illumination option.
* VN, VP, VR Models with relay holder in progress.
* Twin Tyres to suit most sedans, trikes and motorcycle sidecars
http://niche.iinet.net.au
| |
| Eeyore 2007-03-16, 3:25 am |
|
Anthony Fremont wrote:
> Eeyore wrote:
>
> That's true, but wasn't really my point. I'm saying that people use these
> "special features" and then they narrow (or eliminate) their source options.
> Where parts from different vendors do have similar extensions, they don't
> usually implement the SFRs the same way. It's been a while since I looked
> around, maybe vendors are getting on the same page now (why do I really
> doubt that though ;-).
Well.... yes if you do use those very specific features you will be stuck with a
single source but you're still no worse off than you would be with a PIC.
Graham
| |
| John E. 2007-03-16, 3:25 am |
| > I'm prejudiced against the PIC because bank switching is Evil.
I'm beginning to hear a lot of that (c;
> As a hobbyist: 6502, 6800/02/09, Z80; as a pro, 68HC11, Z80, 80186 ;-)
I think I should clarify that my desire isn't to go in the direction of
microprocessors, but in the direction of microcontrollers. I distinguish
those that have data and memory bus pins from those that are self-sufficient,
memorywise. The latter may have I/O such as analog inputs and/or outputs, but
not necessarily; they may interface with outboard converters.
Thanks,
--
John English
| |
| Anthony Fremont 2007-03-16, 9:25 am |
| John E. wrote:
>
> I'm beginning to hear a lot of that (c;
Since you're starting, the 18F PICs may be more in line with what you want.
Not even any bank switching till you're ready for it. Plus Microchip has a
decent C compiler for them (I never used it, but that's what I keep hearing)
that has something like a 90 day trial. After the trial, uninstall and
reinstall.
www.picbook.com is a good treatise on the 18F PICs.
Don't let anyone fool you, all microcontrollers have their quirks and
problems. IMO, the 8052 is the pits.
>
>
> I think I should clarify that my desire isn't to go in the direction
> of microprocessors, but in the direction of microcontrollers. I
> distinguish those that have data and memory bus pins from those that
> are self-sufficient, memorywise. The latter may have I/O such as
> analog inputs and/or outputs, but not necessarily; they may interface
> with outboard converters.
You won't regret it.
| |
| Tim Wescott 2007-03-16, 1:25 pm |
| John E. wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
After you've selected your second or third new microprocessor and made
it work you'll realize that time spent learning the quirks of a new
processor is less than time spent working around the deficiencies of an
old one.
For each new application I look at what the application demands, which
usually boils down to processor speed, peripherals, the available pin
drive power, and the capabilities of the on-board EEPROM and flash.
Then if one of the micros that I'm already familiar with works I use it
-- otherwise I select a new one.
I will mention that for most microprocessors the verb is "use", but for
PIC it's "suck it up and use" -- Microchip does a sterling job with
peripherals, pin drive and features, but gawd I hate their architecture.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
| |
| John E. 2007-03-16, 1:25 pm |
| > I will mention that for most microprocessors the verb is "use", but for
> PIC it's "suck it up and use" -- Microchip does a sterling job with
> peripherals, pin drive and features, but gawd I hate their architecture.
There's a pattern developing in this thread...
--
John English
| |
| John E. 2007-03-16, 1:25 pm |
| > I will mention that for most microprocessors the verb is "use", but for
> PIC it's "suck it up and use" -- Microchip does a sterling job with
> peripherals, pin drive and features, but gawd I hate their architecture.
Which just *begs* the question: whose architecture do you consider to be the
antithesis of the PIC's? (ie, less obtuse, resulting in your being more
productive?)
--
John English
| |
| john jardine 2007-03-16, 1:25 pm |
|
"martin griffith" <mart_in_medina@ya___.es> wrote in message
news:h0ijv2h8vq2u0nd8s0ntp9npi9bbo2p60i@4ax.com...
> On Thu, 15 Mar 2007 15:11:02 -0700, in sci.electronics.design John E.
> <incognito@yahoo.com> wrote:
>
To[color=darkred]
>
> <sticking neck out>
> checkout:
> SPI interface, (realtime clocks, external eeproms etc.)
> I2C, the uberversal philips interface, same as SPI, but different, and
> pain in the neck IMHO
> logic fets
> H bridge
> opto isolators
> Reset and brownout detectors/ TL77xx etc from TI
>
> and the universal "why doesn't my 2*8 LCD work"
> Cos it takes many milliseconds to initialise, check the Fuckin* busy
> flag
>
> </sticking neck out>
>
> and get a decent bench/lab power supply with adjustable current
> limiting, and a scope
>
>
> martin
And the 1 by 16 LCD, is electrically still a 2 by 8.
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Tim Wescott 2007-03-16, 1:25 pm |
| John E. wrote:
>
>
> Which just *begs* the question: whose architecture do you consider to be the
> antithesis of the PIC's? (ie, less obtuse, resulting in your being more
> productive?)
Almost anything but an 8051?
Actually, just about anything that has a stack-oriented architecture, or
a register-oriented architecture with an orthogonal instruction set and
decent indexing. If I can, with confidence, slam a bunch of parameters
onto the stack or into some registers and call a function without worry,
then I'm happy.
The PIC (and the 8051, and some others) are so poor at stack usage and
pointer manipulation that unless one wants severely inefficient code one
pretty much has to define all the program data as a bunch of globals.
If you try to make your life more efficient by programming in C, you'll
find that the C compilers for the PIC and 8051 give you a choice between
something that isn't quite C, or C code that's _really_, _really_
inefficient. If you want to write assembly using C calling conventions
-- well, find another processor, because you can't.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
| |
| John E. 2007-03-16, 5:25 pm |
| > Actually, just about anything that has a stack-oriented architecture, or
> a register-oriented architecture with an orthogonal instruction set and
> decent indexing.
Being a beginner in all this, I have no experience / reference to be able to
put product names to these capabilities. Would you "name names" please? I'll
create a diversion to take all the flames while you do that... (c:
--
John English
| |
| Anthony Fremont 2007-03-16, 5:25 pm |
| John E. wrote:
>
> There's a pattern developing in this thread...
Yes there certainly is. You've discovered the pic haters, welcome to my
world. ;-) Once you learn to use several different archetectures, you'll
see that they all suck in one way or another. 8052's are dumb in how they
deal with internal/external storage and also their "output" vs "input"
methods suck too because they don't have true directional i/o pins. AVRs,
TI MSP430 and the rest all have their problems too whether it be an
inabillity to supply drive current to a part or some other deficiency. They
all have trade-offs. What you're seeing here is an unfair attack on PICs
that seems to be made mostly by people that have hardly (if ever) used one,
Tim excluded. As you said, PIC is king and it is for a reason, they work.
| |
| TT_Man 2007-03-16, 5:25 pm |
|
"John E." <incognito@yahoo.com> wrote in message
news:0001HW.C220350A0041BFCBF01826C8@news.sf.sbcglobal.net...
>
> Being a beginner in all this, I have no experience / reference to be able
> to
> put product names to these capabilities. Would you "name names" please?
> I'll
> create a diversion to take all the flames while you do that... (c:
> --
> John English
>
I thought 51's had a decent stack and register structure. I've used them
since 1976... (Intel 8731?) I found the instruction set entirely logical and
usable with an easy learning curve.
The OP is a beginner and needs something simple to get going with. The 51
does what it says on the tin. The Dallas 450 version ,you can get up and
running in an afternoon with a couple of support chips.
| |
| TT_Man 2007-03-16, 5:25 pm |
| > As you said, PIC is king and it is for a reason, they work.
>
Only if you can get to grips with the appalling op code set..... OK if you
can program in C , I suppose.I can't/won't
| |
| Anthony Fremont 2007-03-16, 5:25 pm |
| Tim Wescott wrote:
> John E. wrote:
>
>
> Almost anything but an 8051?
I heard that. That is truly the ugliest archetecture.
> Actually, just about anything that has a stack-oriented architecture,
> or a register-oriented architecture with an orthogonal instruction
> set and decent indexing. If I can, with confidence, slam a bunch of
> parameters onto the stack or into some registers and call a function
> without worry, then I'm happy.
But but but an 8052 has a stack and an available stack pointer. Don't you
like it?
> The PIC (and the 8051, and some others) are so poor at stack usage and
> pointer manipulation that unless one wants severely inefficient code
> one pretty much has to define all the program data as a bunch of
> globals. If you try to make your life more efficient by programming
> in C, you'll find that the C compilers for the PIC and 8051 give you
> a choice between something that isn't quite C, or C code that's
> _really_, _really_ inefficient. If you want to write assembly using
> C calling conventions -- well, find another processor, because you
> can't.
The Keil compiler generates nice dense code on the 8052, but it costs a
fortune too. At the other end of the spectrum you have SDCC, ha ha ha. I'd
rather have a sharp stick in the eye. ;-)
Have you looked at the 18F pics? They added some things that make it much
more friendly to C compilers. Tripple data pointers (FSRs), auto
increment/decrement, bigger stack, W is a real SFR, LAT registers to
eliminate RMW issues for people too lazy to use a shadow register, etc.
Nice chip, I'll have to try one sometime. ;-)
| |
| Anthony Fremont 2007-03-16, 5:25 pm |
| TT_Man wrote:
> Only if you can get to grips with the appalling op code set..... OK
> if you can program in C , I suppose.I can't/won't
I only do assembler on the PIC too. What's wrong with the op-code set?
It's RISC, it has 35 instructions, it's not supposed to be luxurious. It's
supposed to be functional and fast....it succeeds. ;-) Just for background
reference, I came from being a mainframe assembler programmer on a processor
with a 10 bit op-code.
I know it's tedious sometimes, but when you only have one working register
it's going to be that way no matter what.
| |
| Homer J Simpson 2007-03-16, 5:25 pm |
|
"Anthony Fremont" <spam-not@nowhere.com> wrote in message
news:12vlsaujevici3d@news.supernews.com...
> I only do assembler on the PIC too. What's wrong with the op-code set?
> It's RISC, it has 35 instructions, it's not supposed to be luxurious.
> It's supposed to be functional and fast....it succeeds. ;-) Just for
> background reference, I came from being a mainframe assembler programmer
> on a processor with a 10 bit op-code.
>
> I know it's tedious sometimes, but when you only have one working register
> it's going to be that way no matter what.
I don't think C is a great choice for small processors like the PIC. I
wonder if a version of Tiny Pascal might not work better.
| |
| John E. 2007-03-16, 5:25 pm |
| > What you're seeing here is an unfair attack on PICs
Let me ask that we not take an attack on a particular microcontroller as an
attack on one's person. Or one's child. (c: There are preferences, always
will be whether we're talking about cars, chips, or... well, tortilla chips.
Tell me what you like and don't, and why. I'm all ears.
--
John English
| |
| bungalow_steve@yahoo.com 2007-03-16, 5:25 pm |
| On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
> Thanks,
> --
> John English
32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).
About C, you have to realize that the majority of example code out
there is in C, I hate the language myself, but I use it because it is
so easy to pick up someone's elses C code and start working with that.
I bought an ARM development kit recently and was up and running in a
few hours (blinking LEDS, reading A/D's, and sending the data to the
PC via the UART), cause they had C examples of everything, converting
the A/D inputs, UART utilities, start up files etc.
You have to remember the actual number of C features actually needed
in a small embedded processor is very little... learn a couple while/
for loops, if statement, how to set/clear a bit and how to call a
routine and what else is there? not much
| |
| bungalow_steve@yahoo.com 2007-03-16, 8:25 pm |
| On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
> PIC is king, I'm sure. But I'd like to hear from those who are using all
> brands. Whichever you use, what do you like about it? What don't you like
> about others? Suggestions re. learning?
>
> I've programmed 68000 assembly and some higher-level languages (FORTRAN; some
> BASIC; COBOL if forced to admit it), so no stranger to programming, per se.
>
> Thanks,
> --
> John English
32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
huge floating point versions with 256K of RAM, the small ones are a
few bucks. They work very well with high level languages and the
assembly is easy, you spend more time doing stuff rather then
fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
switching, multi word math, accessing 16 bit hardware with double
reads that have to be done in a certain order, etc,etc,etc all that
weird goofy stuff goes away).
About C, you have to realize that the majority of example code out
there is in C, I hate the language myself, but I use it because it is
so easy to pick up someone's elses C code and start working with that.
I bought an ARM development kit recently and was up and running in a
few hours (blinking LEDS, reading A/D's, and sending the data to the
PC via the UART), cause they had C examples of everything, converting
the A/D inputs, UART utilities, start up files etc.
You have to remember the actual number of C features actually needed
in a small embedded processor is very little... learn a couple while/
for loops, if statement, how to set/clear a bit and how to call a
routine and what else is there? not much
| |
| John Barrett 2007-03-16, 8:25 pm |
|
<bungalow_steve@yahoo.com> wrote in message
news:1174083664.366440.223730@d57g2000hsg.googlegroups.com...
> On Mar 15, 4:52 pm, John E. <incogn...@yahoo.com> wrote:
>
> 32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
> huge floating point versions with 256K of RAM, the small ones are a
> few bucks. They work very well with high level languages and the
> assembly is easy, you spend more time doing stuff rather then
> fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
> switching, multi word math, accessing 16 bit hardware with double
> reads that have to be done in a certain order, etc,etc,etc all that
> weird goofy stuff goes away).
>
> About C, you have to realize that the majority of example code out
> there is in C, I hate the language myself, but I use it because it is
> so easy to pick up someone's elses C code and start working with that.
> I bought an ARM development kit recently and was up and running in a
> few hours (blinking LEDS, reading A/D's, and sending the data to the
> PC via the UART), cause they had C examples of everything, converting
> the A/D inputs, UART utilities, start up files etc.
>
> You have to remember the actual number of C features actually needed
> in a small embedded processor is very little... learn a couple while/
> for loops, if statement, how to set/clear a bit and how to call a
> routine and what else is there? not much
>
>
>
OK -- I'm a late entry on this one -- but WinAVR makes everything similarly
transparent for the 8 bit Atmel chips, and there is plenty of code out there
written in C for the AVRs, including math libs and such (used one to do a
software PID for servo motors -- worked well !!) -- best of all for me --
the compiler is free  And like the ARM, you can ramp up to 32 bit chips
with on-chip DSP and may other specialty features
I personally dont care WHICH chip I use as long as I have good development
tools I started on the 8047/8051/Z8 MANY moons ago, and I've done plenty
of PIC and AVR -- I prefer the AVR chips because the development tools and
community support I got were better than what I ran into for the PIC when I
was getting started. (and the only FREE dev tools I could find for the the
PIC were BASIC, which I put aside a coupla hundred years ago !!)
They are all good chips -- make sure you got good dev tools !!
| |
| Eeyore 2007-03-16, 8:25 pm |
|
"bungalow_steve@yahoo.com" wrote:
> 32 bit ARM's are nice, you can get them in small 4x5 mm packages up to
> huge floating point versions with 256K of RAM, the small ones are a
> few bucks. They work very well with high level languages and the
> assembly is easy, you spend more time doing stuff rather then
> fighting with the limitations of smaller PIC's, AVR's and 8051's (bank
> switching, multi word math, accessing 16 bit hardware with double
> reads that have to be done in a certain order, etc,etc,etc all that
> weird goofy stuff goes away).
PL/M51 handles all that goofy stuff for me.
I've only once ever come across a situation with an 8051 where I'd have liked a
long word btw and I use even words quite rarely.
Graham
| |
| bungalow_steve@yahoo.com 2007-03-17, 3:25 am |
| On Mar 16, 2:52 pm, "John Barrett" <ke5c...@verizon.net> wrote:
> <bungalow_st...@yahoo.com> wrote in message
>
> news:1174083664.366440.223730@d57g2000hsg.googlegroups.com...
>
>
>
>
>
>
>
>
>
> OK -- I'm a late entry on this one -- but WinAVR makes everything similarly
> transparent for the 8 bit Atmel chips, and there is plenty of code out there
> written in C for the AVRs, including math libs and such (used one to do a
> software PID for servo motors -- worked well !!) -- best of all for me --
> the compiler is free And like the ARM, you can ramp up to 32 bit chips
> with on-chip DSP and may other specialty features
>
> I personally dont care WHICH chip I use as long as I have good development
> tools I started on the 8047/8051/Z8 MANY moons ago, and I've done plenty
> of PIC and AVR -- I prefer the AVR chips because the development tools and
> community support I got were better than what I ran into for the PIC when I
> was getting started. (and the only FREE dev tools I could find for the the
> PIC were BASIC, which I put aside a coupla hundred years ago !!)
>
> They are all good chips -- make sure you got good dev tools !!- Hide quoted text -
>
> - Show quoted text -
There really is no upgrade path for the AVR, the AVR 32 is only the
same in name only, it's nothing like a 32 bit version of the AVR8, and
currently there is only one device in that family.
the AVR series hasen't increased in performance in years (speed, a/d
resolution, DMA, fifo buffers, divide instructions etc). Microchip has
been very good in this respect, even though I don't use any of their
PICS. I ended up using the Atmel SAM7's and Analog devices ARM chips,
although AVR's are still superior in battery power devices.
All the development tools are excellent now, in my opinion, but I'm
pretty easy to please....
| |
|
| In article <12vlrdv6b9apl72@news.supernews.com>, spam-not@nowhere.com
says...
> John E. wrote:
>
> Yes there certainly is. You've discovered the pic haters, welcome to my
> world. ;-) Once you learn to use several different archetectures, you'll
> see that they all suck in one way or another.
That's true of more than just UCs. ;-)
> 8052's are dumb in how they deal with internal/external storage
Each memory type has its reason. I've found 8051s (variants) quite
powerful because of the memory types and the wide variety of
peripherals that have been integrated into them.
> and also their "output" vs "input"
> methods suck too because they don't have true directional i/o pins.
Again, they're not all "true" bidirectional pins because they're used
for multiple purposes. They're not difficult to make into true I/O
pins though. With any flexibility you have to trade off some
complexity.
> AVRs,
> TI MSP430 and the rest all have their problems too whether it be an
> inabillity to supply drive current to a part or some other deficiency. They
> all have trade-offs. What you're seeing here is an unfair attack on PICs
> that seems to be made mostly by people that have hardly (if ever) used one,
> Tim excluded. As you said, PIC is king and it is for a reason, they work.
>
I've never used a PIC, though would like to do a job with one.
Picking (NPI) up a new processor isn't a big deal once you've seen a
few. ;-)
--
Keith
| |
| Anthony Fremont 2007-03-17, 1:25 pm |
| krw wrote:
> In article <12vlrdv6b9apl72@news.supernews.com>, spam-not@nowhere.com
> says...
>
> That's true of more than just UCs. ;-)
Yes, all computers suck in one way or another. The same applies to all
operating systems. Some more than others. ;-)
>
> Each memory type has its reason. I've found 8051s (variants) quite
> powerful because of the memory types and the wide variety of
> peripherals that have been integrated into them.
PICs pretty much have all the same peripherals that I've seen in them. I
just don't like the whole MOV MOVX thing. People whine about bank switching
on PICs, but the 8052 has some of the same thing. It's not that I hate
them, I just don't love them. I don't really love PICs either, but I can
live with them for now.
Before anyone gets the wrong idea, I'm not a one tool fits all kind person.
All micros have their place, some have more than others. ;-)
>
> Again, they're not all "true" bidirectional pins because they're used
> for multiple purposes. They're not difficult to make into true I/O
> pins though. With any flexibility you have to trade off some
> complexity.
That's my point. On allot of micros, you just set some kind of direction
flag and voila, no ambiguity.
> I've never used a PIC, though would like to do a job with one.
> Picking (NPI) up a new processor isn't a big deal once you've seen a
> few. ;-)
You should try them sometime, they're not as bad as people let on. They
shine in abusive environments and will deliver the current to external
devices (usually 20 to 25mA sink or source on most common parts). Hard to
kill for the most part and
I've played with a few different micros, but there are still plenty left
that I haven't. I do want to play with some of those tiny 32 bit ARMs that
have lots of memory and speed.
| |
|
| On Mar 16, 2:26?pm, "Anthony Fremont" <spam-...@nowhere.com> wrote:
> Tim Wescott wrote:
>
....Insert multiple "negative 8051" comments here..."
Look, if you're going to program in Assembler, the 8051 (and it's
many, many cousins) are fine.
All this talk about architectures and C-coding probably won't mean
that much to a beginner.
Except perhaps the drive levels discussions.
Here, generically, I think there is something worth discussing.
Ideally, you'd like 20mA sink on every pin. Some 8051's with Quasi-
bidirectional ports can handle that. But I've seen some that can
barely manage 4mA, or less..
8051's are very well supported having been around for decades.
And they're not going away anytime soon.
I don't think you can go "wrong" here.
-mpm
| |
|
| On Mar 15, 8:31?pm, "Anthony Fremont" <spam-...@nowhere.com> wrote:
> usually implement the SFRs the same way...
The differences are minor.
And if you code properly, its very easy to adjust any relocated SRF's
that affect program execution.
Ditto for the Interrupt vectors, which for the "Standard" interrupts
like T0, T1, etc... are usually at the expected addresses anyway.
Now, clock cycle / instruction cycle time is another story.
I think the original 8051 would execute 1 instruction every 12 clocks.
(?)
Newer ones can do it in 2. (in other words, a 6x improvement).
If yours happens to default to the faster "speed", then it may not be
a drop-in replacement.
-even if its 100% code compatible.
-mpm
| |
| Ken Smith 2007-03-17, 5:25 pm |
| In article <1174153886.787617.256830@e1g2000hsg.googlegroups.com>,
mpm <mpmillard@aol.com> wrote:
[...]
>Now, clock cycle / instruction cycle time is another story.
>I think the original 8051 would execute 1 instruction every 12 clocks.
>(?)
>Newer ones can do it in 2. (in other words, a 6x improvement).
The ones from Cygnal do it in one. Basically they are 50MPIS 8051s with
analog stuff on board.
--
--
kensmith@rahul.net forging knowledge
| |
|
| In article <1174153886.787617.256830@e1g2000hsg.googlegroups.com>,
mpmillard@aol.com says...
> On Mar 15, 8:31?pm, "Anthony Fremont" <spam-...@nowhere.com> wrote:
>
> The differences are minor.
> And if you code properly, its very easy to adjust any relocated SRF's
> that affect program execution.
Yes, I always wrote a module for each UC that had the names of all
SRFs for that model. This module was then included in the MAKE based
on version. Never, EVER, use absolute addresses for SRFs.
> Ditto for the Interrupt vectors, which for the "Standard" interrupts
> like T0, T1, etc... are usually at the expected addresses anyway.
Sure, I hard-coded these at each location, whether they were used or
not. The main source module would have a stub to each ISR.
> Now, clock cycle / instruction cycle time is another story.
> I think the original 8051 would execute 1 instruction every 12 clocks.
> (?)
> Newer ones can do it in 2. (in other words, a 6x improvement).
Yes, as I recently found out (duh!) the original 8051 has a bit-
serial ALU. BTW, MUL and DIV are 24 clocks per instruction.
>
> If yours happens to default to the faster "speed", then it may not be
> a drop-in replacement.
> -even if its 100% code compatible.
--
Keith
| |
| Spehro Pefhany 2007-03-17, 5:25 pm |
| On Sat, 17 Mar 2007 15:40:48 -0400, the renowned krw <krw@att.bizzzz>
wrote:
>In article <1174153886.787617.256830@e1g2000hsg.googlegroups.com>,
>mpmillard@aol.com says...
>
>Yes, I always wrote a module for each UC that had the names of all
>SRFs for that model. This module was then included in the MAKE based
>on version. Never, EVER, use absolute addresses for SRFs.
>
>
>Sure, I hard-coded these at each location, whether they were used or
>not. The main source module would have a stub to each ISR.
>
>
>Yes, as I recently found out (duh!) the original 8051 has a bit-
>serial ALU. BTW, MUL and DIV are 24 clocks per instruction.
How would do you do an 8 x 8 multiply with 24 clocks and a serial ALU?
Seems to me you'd need at least 64 clocks.
Anyway, MUL and DIV take 4 machine cycles (24 states, 48 oscillator
clocks in the original 8x51). Still not 64 unless you're using both
clock edges.
There is at least one 8-bit micro that is serial internally- the ST-6
(it's a feature they say, lower noise)-- but I am not convinced that
the 8051 is. Any cites?
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
| |
|
| In article <61sov29psuqj3t2jdcd7sdqanli46esjao@4ax.com>,
speffSNIP@interlogDOTyou.knowwhat says...
> On Sat, 17 Mar 2007 15:40:48 -0400, the renowned krw <krw@att.bizzzz>
> wrote:
>
>
> How would do you do an 8 x 8 multiply with 24 clocks and a serial ALU?
> Seems to me you'd need at least 64 clocks.
I don't have the microarchitecture of the original 8051, but you
don't need a clock for each bit. The diagonals should be enough.
> Anyway, MUL and DIV take 4 machine cycles (24 states, 48 oscillator
> clocks in the original 8x51). Still not 64 unless you're using both
> clock edges.
I thought it was six clocks per machine cycle and two (most) or four
(MUL/DIV) cycles per instruction. It's been a long time since I used
one though so may be misremembering the convoluted details.
>
> There is at least one 8-bit micro that is serial internally- the ST-6
> (it's a feature they say, lower noise)-- but I am not convinced that
> the 8051 is. Any cites?
It was brought up in AFC in the past week or so. I'll see if I can
find the reference.
--
Keith
| |
|
| In article <0001HW.C220350A0041BFCBF01826C8@news.sf.sbcglobal.net>, incognito@yahoo.com says...
>
>
>Being a beginner in all this, I have no experience / reference to be able to
>put product names to these capabilities. Would you "name names" please? I'll
>create a diversion to take all the flames while you do that... (c:
68000 series has pretty symmetric instruction set (orthoganol).
ie Moving from register to memory and vice versa is symmetric there are
minimal exceptions. There are microntroller variants of processors that
use 68000 instruction set.
Having a lot of registers is a bonus, 16 to 32 is ideal for the vast bulk
on microcontroller apps, can get away with 4 or even 2 if you are keen.
Basically, for a beginner, you'd want an instruction set that works 'both
ways' with registers, memory and IO ports, you dont want one with lots of
lumpy exceptions or stack size restrictions or memory address or io
restrictions - because if you are doing assembler you dont want to worry
about that many until you are proficient, which usually happens fairly soon
once you get stuck into it...
--
Regards
Mike
* VK/VL Commodore FuseRails that wont warp or melt with fuse failure indication
and now with auto 10-15 min timer for engine illumination option.
* VN, VP, VR Models with relay holder in progress.
* Twin Tyres to suit most sedans, trikes and motorcycle sidecars
http://niche.iinet.net.au
| |
| Lionel 2007-03-18, 3:25 am |
| On Thu, 15 Mar 2007 23:41:18 +0100, martin griffith
<mart_in_medina@ya___.es> wrote:
>On Thu, 15 Mar 2007 15:11:02 -0700, in sci.electronics.design John E.
><incognito@yahoo.com> wrote:
>
Good man, you'll go far. ;^)
[color=darkred]
>and the universal "why doesn't my 2*8 LCD work"
>Cos it takes many milliseconds to initialise, check the Fuckin* busy
>flag
ROTFL! Nicely put, martin. (AKA: RTFM, dimwit!)
>and get a decent bench/lab power supply with adjustable current
>limiting,
Or just make one, it's not hard.
> and a scope
Definitely.
It's also nice to have more than one multimeter, so you can monitor
multiple things at the same time. I have one fancy one, & a couple of
cheap ones, all with EZ hook clips of various sizes.
A solderless breadboard is handy, just watch out for the effects of
the extra capacitance between rows on high frequency signals, & for
meltdowns from hot components like voltage regulators or drive
transistors. (I wire up such subsections on stripboard & solder on
pin-headers so I can plug them into the breadboard.)
--
W "Some people are alive only because it is illegal to kill them."
. | ,. w ,
\|/ \|/ Perna condita delenda est
---^----^---------------------------------------------------------------
| |
| John Barrett 2007-03-18, 3:25 am |
|
"Mike" <erazmus@iinet.net.au> wrote in message
news:45fcb473$0$17581$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> In article <0001HW.C220350A0041BFCBF01826C8@news.sf.sbcglobal.net>,
> incognito@yahoo.com says...
>
> 68000 series has pretty symmetric instruction set (orthoganol).
>
> ie Moving from register to memory and vice versa is symmetric there are
> minimal exceptions. There are microntroller variants of processors that
> use 68000 instruction set.
>
> Having a lot of registers is a bonus, 16 to 32 is ideal for the vast bulk
> on microcontroller apps, can get away with 4 or even 2 if you are keen.
>
> Basically, for a beginner, you'd want an instruction set that works 'both
> ways' with registers, memory and IO ports, you dont want one with lots of
> lumpy exceptions or stack size restrictions or memory address or io
> restrictions - because if you are doing assembler you dont want to worry
> about that many until you are proficient, which usually happens fairly
> soon
> once you get stuck into it...
>
>
GEEEZ -- I gave up writing ASM for the 1st cut about 20 years ago -- the
compilers available even then were efficient enough that you only needed to
get down and dirty for the most critical timing dependent code.. there just
isnt a point in starting off with ASM considering that C maps almost 1-to-1
to most assembly languages for most of its internal features. And the WinAVR
C compiler makes it real easy to embed ASM right in the C code so I can do
it in C first, then convert just the parts that need it in place with a
perfectly working and tested "flow chart" right in front of me.
In addition.. for 99% of apps, you'll never bother with ASM because the
compiled code will work right off and nothing will need to be hand
optimized... you've gotta be right on the ragged edge of what the chip is
capable of before ASM is going to help you, and 99% of apps wont even come
close to that limit.
| |
| John E. 2007-03-18, 3:25 am |
| > ie Moving from register to memory and vice versa is symmetric there are
> minimal exceptions. There are microntroller variants of processors that
> use 68000 instruction set.
>
> Having a lot of registers is a bonus, 16 to 32 is ideal for the vast bulk
> on microcontroller apps, can get away with 4 or even 2 if you are keen.
>
> Basically, for a beginner, you'd want an instruction set that works 'both
> ways' with registers, memory and IO ports, you dont want one with lots of
> lumpy exceptions or stack size restrictions or memory address or io
> restrictions - because if you are doing assembler you dont want to worry
> about that many until you are proficient, which usually happens fairly soon
> once you get stuck into it...
Names! Names! Names! (please). I agree with what you say, but I need the
benefit of y'all's experience. Which controller "variants of processors that
use 68000 instruction set" and which don't do "lumpy exceptions or stack size
restrictions..." etc.
Just need to know what name to call these lovelies by.
--
John English
| |
|
| In article <12vo929610ckrbc@news.supernews.com>, spam-not@nowhere.com
says...
> krw wrote:
>
> Yes, all computers suck in one way or another. The same applies to all
> operating systems. Some more than others. ;-)
True, some OSs suck more than others. OTOH, some suck so much they
simply blow.
>
> PICs pretty much have all the same peripherals that I've seen in them.
I haven't looked closely in the past couple of years. 8051s had it
all over others several years back. I had plenty of 8051s (and the
environment) for my last project so I just used them. only needed
ten. ;-)
> I just don't like the whole MOV MOVX thing.
The 8051 is extreme Harvard. It makes sense once you break the von
Neuman mindset. A von Neuman controller is a waste.
> People whine about bank switching
> on PICs, but the 8052 has some of the same thing.
How so? ...at least until 64K no bank switching is needed. After
64K, well the 8051 was never intended to be a PeeCee. ;-)
> It's not that I hate
> them, I just don't love them. I don't really love PICs either, but I can
> live with them for now.
AFAIC, the 8051 is a good choice as a bit-banger, which was what it
was designed to do. As I've said, I've never used a PIC (or
seriously looked at it, even) so I can't compare the two. My
assumption is that the PIC architects aren't brain-dead (like
Dimbulb).
> Before anyone gets the wrong idea, I'm not a one tool fits all kind person.
> All micros have their place, some have more than others. ;-)
I'm not so sure they ALL do. ;-)
>
> That's my point. On allot of micros, you just set some kind of direction
> flag and voila, no ambiguity.
There really isn't any ambiguity with an 8051 either. Gazinta bit
and a gazouta bit and a couple of rules. Some tieups may be needed
for shared pins. Share pins and you'll have that.
>
>
> You should try them sometime, they're not as bad as people let on. They
> shine in abusive environments and will deliver the current to external
> devices (usually 20 to 25mA sink or source on most common parts). Hard to
> kill for the most part and
I'm certainly not afraid of them, just never had an opportunity.
Maybe I'll buy a kit and play.
> I've played with a few different micros, but there are still plenty left
> that I haven't. I do want to play with some of those tiny 32 bit ARMs that
> have lots of memory and speed.
ARMs don't thrill me much. Too much power. I'd likely have to
learn C. ;-)
--
Keith
| |
| linnix 2007-03-18, 5:25 pm |
| > > I've played with a few different micros, but there are still plenty left
>
> ARMs don't thrill me much. Too much power.
Too much for what? The one I am using draws 70mA typical.
Of course, you can run an AVR for less than 1mA.
In my case, I use an AVR to power control an ARM.
The ARM can do the job quicker so both can go back to sleep ASAP.
> I'd likely have to learn C. ;-)
Why? They work in assemblers too, even if I don't.
| |
| Terran Melconian 2007-03-18, 8:25 pm |
| On 2007-03-18, John Barrett <ke5crp1@verizon.net> wrote:
> optimized... you've gotta be right on the ragged edge of what the chip is
> capable of before ASM is going to help you, and 99% of apps wont even come
> close to that limit.
Some people would say that if you're *not* at the edge of what the
microcontroller can do, you're using one that's too expensive. ;)
| |
| linnix 2007-03-18, 8:25 pm |
| On Mar 18, 3:33 pm, Terran Melconian
<te_rem_ra_ove_an_fors...@consistent.org> wrote:
> On 2007-03-18, John Barrett <ke5c...@verizon.net> wrote:
>
>
> Some people would say that if you're *not* at the edge of what the
> microcontroller can do, you're using one that's too expensive. ;)
Same for PCs. How many people really need the 3GHz Dual core PC to
read this newsgroup?
| |
|
| In article <1174244224.891818.310760@e1g2000hsg.googlegroups.com>,
me@linnix.info-for.us says...
>
> Too much for what? The one I am using draws 70mA typical.
> Of course, you can run an AVR for less than 1mA.
> In my case, I use an AVR to power control an ARM.
> The ARM can do the job quicker so both can go back to sleep ASAP.
Power as in MIPS, not as in mA. If I want MIPS I'd go with a PPC of
some sort.
>
>
> Why? They work in assemblers too, even if I don't.
>
With the MIPS available one wouldn't likely be doing bit-banging,
which is where assembler excels.
--
Keith
| |
| linnix 2007-03-18, 8:25 pm |
| On Mar 18, 4:26 pm, krw <k...@att.bizzzz> wrote:
> In article <1174244224.891818.310...@e1g2000hsg.googlegroups.com>,
> m...@linnix.info-for.us says...
>
>
>
>
> Power as in MIPS, not as in mA.
Why would too much MIPS bother you?
You don't have to use pay per MIPS.
> If I want MIPS I'd go with a PPC of some sort.
I haven't seen any PPC in low pin count with internal memories yet.
The Arm I am using is 64K flash, 8K sram on chip in 48 pins QFP.
>
>
>
> With the MIPS available one wouldn't likely be doing bit-banging,
> which is where assembler excels.
>
> --
> Keith
| |
| bungalow_steve@yahoo.com 2007-03-18, 8:25 pm |
| On Mar 18, 8:44 pm, "linnix" <m...@linnix.info-for.us> wrote:
> On Mar 18, 4:26 pm, krw <k...@att.bizzzz> wrote:
>
>
>
>
>
>
> Why would too much MIPS bother you?
> You don't have to use pay per MIPS.
>
>
> I haven't seen any PPC in low pin count with internal memories yet.
> The Arm I am using is 64K flash, 8K sram on chip in 48 pins QFP.
And you are using a AVR to turn it on? I would think a small ARM like
that can be throttled down to run at about the same power as an AVR
( 1 mA), the AVR and Atmel ARM's have about the same W/hz, as an
example, but the AVR's have much better sleep modes
| |
|
| In article <1174265095.406744.259910@e65g2000hsc.googlegroups.com>,
me@linnix.info-for.us says...
> On Mar 18, 4:26 pm, krw <k...@att.bizzzz> wrote:
>
> Why would too much MIPS bother you?
> You don't have to use pay per MIPS.
Certainly you pay for MIPS. They don't give processors away free.
>
> I haven't seen any PPC in low pin count with internal memories yet.
> The Arm I am using is 64K flash, 8K sram on chip in 48 pins QFP.
More variables not stated in the parameters.
[color=darkred]
--
Keith
| |
|
| In article <1174262118.454781.116300@n76g2000hsh.googlegroups.com>,
me@linnix.info-for.us says...
> On Mar 18, 3:33 pm, Terran Melconian
> <te_rem_ra_ove_an_fors...@consistent.org> wrote:
>
> Same for PCs. How many people really need the 3GHz Dual core PC to
> read this newsgroup?
>
I don't need a pickup truck to go to the pub either but it comes in
handy at the dump. This dual 1.86GHz laptop is kinda nice too (once
I put enough memory on it).
--
Keith
| |
| linnix 2007-03-19, 3:25 am |
| On Mar 18, 5:11 pm, "bungalow_st...@yahoo.com"
<bungalow_st...@yahoo.com> wrote:
> On Mar 18, 8:44 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
> And you are using a AVR to turn it on? I would think a small ARM like
> that can be throttled down to run at about the same power as an AVR
> ( 1 mA), the AVR and Atmel ARM's have about the same W/hz, as an
> example, but the AVR's have much better sleep modes
Mainly with the clock. The Avr can run down to 32KHz, but the Arm
cannot go much below 1MHz (I believe).
| |
| linnix 2007-03-19, 3:25 am |
| On Mar 18, 5:34 pm, krw <k...@att.bizzzz> wrote:
> In article <1174265095.406744.259...@e65g2000hsc.googlegroups.com>,
> m...@linnix.info-for.us says...
>
>
>
>
>
>
>
>
>
> Certainly you pay for MIPS. They don't give processors away free.
The Arm and Avr are close to the same price, around $5 each.
>
>
>
> More variables not stated in the parameters.
Nothing wrong with PPC, but I would not call it a uC.
>
>
>
So, you don't like it because it's too good for you?
[color=darkred]
>
> --
> Keith
| |
|
|
| Tim Wescott 2007-03-19, 3:25 am |
| John E. wrote:
>
>
> Being a beginner in all this, I have no experience / reference to be able to
> put product names to these capabilities. Would you "name names" please? I'll
> create a diversion to take all the flames while you do that... (c:
68HC11, but it's old. I'll bet the 'HC12 and 'HC16 (do they still make
those?) are good.
AVR, if you don't mind wimpy pins.
The TI MSP430 -- the small ones at least have oodles of pin drive, they
appear to have a rational architecture, they're fast, and you can get a
complete development system from TI for $20.
ARM, if you don't mind wading through all the different versions that
are available to find what you want (check those pin drive capacities!).
The instruction set is rational, but only in a screwy, RISC sort of
way. The capabilities are HUGE, and so is the set of mistakes you can
make -- I wouldn't recommend it for a beginner.
PowerPC -- Freescale has embedded versions. Same snarky comment about
the instruction set as ARM, but still way better than a PIC.
Those are the ones that I'm familiar with.
Oh -- _not_ the Intersil/RCA 1802, unless you want to be an ace assembly
language programmer. It was the very first processor I ever worked
with, in 8th grade. I call it a NHISC -- Never Had an Instruction Set.
I don't know if it's still around, but for quite a while it was the
king of little space apps, because it had a huge geometry that could
absorb cosmic rays without even noticing that they were there.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
| |
|
| I recommend Microchip PIC, starting 18F series because it has build in
multiplier. =A3100 for complier package and =A3100 for ICD2 programmer/
debugger. MPLAB is free.
8052 and other processor is a consideration, but I started with PIC
becuase it supported with training package, available offshelve,
extensive range and easy to use. I developed successful project based
on PIC. I'm now working on 2191 Analog Device DSP processor.
Damn google no longer accept my email and change into more complex
emil, so I say goodbye to this discussion group.
| |
|
| |