Which uController to learn?
in [Design]
|
Prev: 1000V high side gate drive
Next: Micpre of Graham
From: Rich Grise on 15 Mar 2007 21:02 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
From: Anthony Fremont on 15 Mar 2007 21:31 Eeyore wrote: > Anthony Fremont wrote: > >> Eeyore wrote: >>> Anthony Fremont wrote: >> >>>> 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. >> >> 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. 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 ;-).
From: Mike on 16 Mar 2007 00:02 In article <0001HW.C21F0006000A0C96F04886C8(a)news.sf.sbcglobal.net>, incognito(a)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
From: Eeyore on 16 Mar 2007 03:24 Anthony Fremont wrote: > Eeyore wrote: > > Anthony Fremont wrote: > >> Eeyore wrote: > >>> Anthony Fremont wrote: > >> > >>>> 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. > >> > >> 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. > > 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
From: John E. on 16 Mar 2007 04:19
> 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 |