Which uController to learn?
in [Design]
|
Prev: 1000V high side gate drive
Next: Micpre of Graham
From: Anthony Fremont on 17 Mar 2007 13:24 krw wrote: > In article <12vlrdv6b9apl72(a)news.supernews.com>, spam-not(a)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.
From: mpm on 17 Mar 2007 13:42 On Mar 16, 2:26?pm, "Anthony Fremont" <spam-...(a)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
From: mpm on 17 Mar 2007 13:51 On Mar 15, 8:31?pm, "Anthony Fremont" <spam-...(a)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
From: Ken Smith on 17 Mar 2007 15:06 In article <1174153886.787617.256830(a)e1g2000hsg.googlegroups.com>, mpm <mpmillard(a)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(a)rahul.net forging knowledge
From: krw on 17 Mar 2007 15:40
In article <1174153886.787617.256830(a)e1g2000hsg.googlegroups.com>, mpmillard(a)aol.com says... > On Mar 15, 8:31?pm, "Anthony Fremont" <spam-...(a)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 |