 |
Search Sci.Electronics.Basics |
|
|
|
|
|
|
 |
|
|
Sci.Electronics.Basics -> Which uController to learn?
There are 124 messages in this thread.
You are currently looking at messages 60 to 80.
|
Author: krwDate: 12:34 17-03-07
|
|
In article <12vlrdv6b9apl72@news.supernews.com>, spam-not@nowhere.com
says...
> John E. wrote:
> >> 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...
>
> 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
|
|
|
|
Author: Anthony FremontDate: 13:24 17-03-07
|
|
krw wrote:
> In article <12vlrdv6b9apl72@news.supernews.com>, spam-not@nowhere.com
> says...
>> John E. wrote:
>>>> 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...
>>
>> 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. ;-)
Yes, all computers suck in one way or another. The same applies to all
operating systems. Some more than others. ;-)
>> 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.
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. ;-)
>> 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.
That's my point. On allot of micros, you just set some kind of direction
flag and voila, no ambiguity.
>> 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. ;-)
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.
|
|
|
|
Author: mpmDate: 13:42 17-03-07
|
|
On Mar 16, 2:26?pm, "Anthony Fremont" <spam-...@nowhere.com> wrote:
> Tim Wescott wrote:
> > John E. 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
|
|
|
|
Author: mpmDate: 13:51 17-03-07
|
|
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
|
|
|
|
Author: Ken SmithDate: 15:06 17-03-07
|
|
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
|
|
|
|
Author: krwDate: 15:40 17-03-07
|
|
In article <1174153886.787617.256830@e1g2000hsg.googlegroups.com>,
mpmillard@aol.com says...
> 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.
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
|
|
|
|
Author: Spehro PefhanyDate: 19:23 17-03-07
|
|
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...
>> 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.
>
>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.
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
|
|
|
|
Author: krwDate: 21:14 17-03-07
|
|
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:
>
> >In article <1174153886.787617.256830@e1g2000hsg.googlegroups.com>,
> >mpmillard@aol.com says...
> >> 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.
> >
> >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.
>
> 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
|
|
|
|
Author: MikeDate: 23:39 17-03-07
|
|
In article <0001HW.C220350A0041BFCBF01826C8@news.sf.sbcglobal.net>,
incognito@yahoo.com says...
>
>> 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:
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
|
|
|
|
Author: LionelDate: 01:19 18-03-07
|
|
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:
>
>>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...
Good man, you'll go far. ;^)
>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
---^----^---------------------------------------------------------------
|
|
|
|
Author: John BarrettDate: 02:04 18-03-07
|
|
"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...
>>
>>> 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:
>
> 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.
|
|
|
|
Author: John E.Date: 03:03 18-03-07
|
|
> 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
|
|
|
|
Author: krwDate: 14:25 18-03-07
|
|
In article <12vo929610ckrbc@news.supernews.com>, spam-not@nowhere.com
says...
> krw wrote:
> > In article <12vlrdv6b9apl72@news.supernews.com>, spam-not@nowhere.com
> > says...
> >> John E. wrote:
> >>>> 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...
> >>
> >> 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. ;-)
>
> 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.
> >> 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.
>
> 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. ;-)
> >> 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.
>
> 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.
>
> >> 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. ;-)
>
> 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
|
|
|
|
Author: linnixDate: 14:57 18-03-07
|
|
> > 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.
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.
|
|
|
|
Author: Terran MelconianDate: 19:33 18-03-07
|
|
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. ;)
|
|
|
|
Author: linnixDate: 19:55 18-03-07
|
|
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:
>
> > 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. ;)
Same for PCs. How many people really need the 3GHz Dual core PC to
read this newsgroup?
|
|
|
|
Author: krwDate: 20:26 18-03-07
|
|
In article <1174244224.891818.310760@e1g2000hsg.googlegroups.com>,
me@linnix.info-for.us says...
> > > 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.
>
> 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.
>
> > I'd likely have to learn C. ;-)
>
> 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
|
|
|
|
Author: linnixDate: 20:44 18-03-07
|
|
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...
>
> > > > 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.
>
> > 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.
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.
>
> > > I'd likely have to learn C. ;-)
>
> > 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
|
|
|
|
Author: bungalow_steve@yahoo.comDate: 21:11 18-03-07
|
|
On Mar 18, 8:44 pm, "linnix" <m...@linnix.info-for.us> wrote:
> 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...
>
> > > > > 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.
>
> > > 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.
>
> 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.
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
|
|
|
|
Author: krwDate: 21:34 18-03-07
|
|
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:
> > In article <1174244224.891818.310...@e1g2000hsg.googlegroups.com>,
> > m...@linnix.info-for.us says...
> >
> > > > > 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.
> >
> > > 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.
>
> 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.
> > 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.
More variables not stated in the parameters.
> > > > I'd likely have to learn C. ;-)
> >
> > > 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
|
|
|
|
|
|
|
|
|
Contact | Electronic Portal
|
|
|
