Looking for Microcontroller Recommendations
in [Design]
|
From: Spehro Pefhany on 17 Jan 2010 13:00 On Sun, 17 Jan 2010 17:03:36 GMT, the renowned nico(a)puntnl.niks (Nico Coesel) wrote: >Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: > >>On Sat, 16 Jan 2010 19:02:30 GMT, the renowned nico(a)puntnl.niks (Nico >>Coesel) wrote: >> >>>Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >>> >>>>On Sat, 16 Jan 2010 11:35:49 GMT, the renowned nico(a)puntnl.niks (Nico >>>>Coesel) wrote: >>>> >>>>>"RogerN" <regor(a)midwest.net> wrote: >>>>> >>>>>>Thanks for all the fantastic recommendations! It seems like for many of the >>>>>>microcontrollers it doesn't cost much to get going at a hobby level. I >>>>>>ordered a PIC18 something starter kit that comes with a PICkit2 >>>>>>programmer/debugger and I ordered a PICkit3 Debug Express. >>>>> >>>>>But be advised: as soon as you think 'I need 2 PICs for this project' >>>>>it is time to dump the PIC and learn to use a completely different >>>>>microcontroller. For more complicated projects using a PIC is like >>>>>eating soup with chopsticks. PIC gets you started real fast but it >>>>>also runs out of air real fast. >>>> >>>>What applications have you had to implement where a 40-80 MHz 32-bit >>>>MIPS processor with 512M of flash is so woefully inadequate? >>> >>>That is not a PIC. That is a PIC32! A whole different beast. >> >>Most of the same tools, the same vendor and distributor, the same IDE, >>and much of the same 'C' code should work though, so it is a path >>upward on larger projects. > >I doubt that. The PIC32 compiler is GCC, the compiler for the other >PICs is Hi-tech. Your doubts are misplaced. GCC is the basis of Microchip MPLAB C compilers for the PIC24 and PIC30/PIC33 (16-bit) architectures. And Hitech (now owned by Microchip) has a PIC32 compiler, so you are free to go both ways, as it were. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Jon Kirwan on 17 Jan 2010 14:13 On Sun, 17 Jan 2010 11:16:47 -0500, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Sat, 16 Jan 2010 19:53:31 -0500, the renowned Rich Webb ><bbew.ar(a)mapson.nozirev.ten> wrote: > >>On Sun, 17 Jan 2010 00:02:33 GMT, Jan Panteltje >><pNaonStpealmtje(a)yahoo.com> wrote: >> >> >>>Well, I sort of like the PIC16 - PIC12 instruction set, >>>although too many bank switching instructions make the asm bigger. >>>It is a good instruction set, and it works. >> >>But the register layout <shudder>. I wanted to like PICs, I really did. >>And I do see some places where they're the optimal choice. But, to try >>to squeeze everything through the one W register?! > >The architecture of the 12/14 bit instruction set PICs is undeniably >ugly. Beauty is in the eye... But uglier even than an 8051 core. I believe I've read something about the PIC dating back to the mid 1970's. Ah, heck, why say only that. Here it is: http://en.wikipedia.org/wiki/PIC_microcontroller The darned thing dates back to the mid-1970s! This is right in the middle of the transition from MSI to LSI in IC technology. 1kx1 dynamic ram chips were the rage of that day. The 8051 dates back to about 1980. Some 5 years later. Which was well into the LSI side of IC design and where it was much more realizable. Memory sizes were much larger, too: http://en.wikipedia.org/wiki/Intel_8051 Plus, the PIC was designed at the time merely to offload I/O tasks not for general purpose computing, while the 8051 was designed at the outset as the sole microcontroller in a system. (The 8048 would be closer, in my mind, to serving PIC's designed services and may be more comparable.) Those were all NMOS stuff at the time, too. .... I like to think of it as a naked cpu. For some, an unclothed body is the most beautiful of all! But now that I mention it, the PIC is 'ancient' and not so many ancient bodies are all that attractive, anymore. So... Yeah. It can be said to be ugly. For a given FAB process and yield, since the PIC was designed when every transmission gate and inverter meant something, it also means they can add a little more on the other end. Or so one would like to believe. Jon
From: Jon Kirwan on 17 Jan 2010 14:33 On Sun, 17 Jan 2010 10:46:42 -0500, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: ><snip> >Hmm.. the Wikipedia article says that the assembler will re-order the >instructions for you to handle the delay slots. Anyone know if this is >true for MIPS? Not usually the sort of thing you would expect or want >an assembler to be doing. Yes, it is true. I used the code reorganizer as part of the assembler chain back in the late 1980's when working on the R2000 chipset. It's not very hard to do, manually. You just look upwards in your code and find an instruction to move into the delay slot. The reorganizer would obviously leave it, then. But the Pretty basic and pretty simple. J. W. Davidson wrote a paper about the whole idea called, "A Retargetable Instruction Reorganizer." It was in the proceedings of ACM, in the 1986 SIGPLAN Symposium stuff. Jon
From: Spehro Pefhany on 17 Jan 2010 15:14 On Sun, 17 Jan 2010 11:13:53 -0800, the renowned Jon Kirwan <jonk(a)infinitefactors.org> wrote: >On Sun, 17 Jan 2010 11:16:47 -0500, Spehro Pefhany ><speffSNIP(a)interlogDOTyou.knowwhat> wrote: > >>On Sat, 16 Jan 2010 19:53:31 -0500, the renowned Rich Webb >><bbew.ar(a)mapson.nozirev.ten> wrote: >> >>>On Sun, 17 Jan 2010 00:02:33 GMT, Jan Panteltje >>><pNaonStpealmtje(a)yahoo.com> wrote: >>> >>> >>>>Well, I sort of like the PIC16 - PIC12 instruction set, >>>>although too many bank switching instructions make the asm bigger. >>>>It is a good instruction set, and it works. >>> >>>But the register layout <shudder>. I wanted to like PICs, I really did. >>>And I do see some places where they're the optimal choice. But, to try >>>to squeeze everything through the one W register?! >> >>The architecture of the 12/14 bit instruction set PICs is undeniably >>ugly. > >Beauty is in the eye... > >But uglier even than an 8051 core. > >I believe I've read something about the PIC dating back to >the mid 1970's. Ah, heck, why say only that. Here it is: > > http://en.wikipedia.org/wiki/PIC_microcontroller > >The darned thing dates back to the mid-1970s! This is right >in the middle of the transition from MSI to LSI in IC >technology. 1kx1 dynamic ram chips were the rage of that >day. > >The 8051 dates back to about 1980. Some 5 years later. Which >was well into the LSI side of IC design and where it was much >more realizable. Memory sizes were much larger, too: > > http://en.wikipedia.org/wiki/Intel_8051 > >Plus, the PIC was designed at the time merely to offload I/O >tasks not for general purpose computing, while the 8051 was >designed at the outset as the sole microcontroller in a >system. (The 8048 would be closer, in my mind, to serving >PIC's designed services and may be more comparable.) > >Those were all NMOS stuff at the time, too. > >... > >I like to think of it as a naked cpu. For some, an unclothed >body is the most beautiful of all! > >But now that I mention it, the PIC is 'ancient' and not so >many ancient bodies are all that attractive, anymore. So... Well, it's upwards of 245 years old in uC years.. >Yeah. It can be said to be ugly. Despite facelifts etc., one feels one must avert one's eyes. But it does work. Speaking of the 12/16 core here primarily. >For a given FAB process and yield, since the PIC was designed >when every transmission gate and inverter meant something, it >also means they can add a little more on the other end. Or >so one would like to believe. > >Jon They do the job, and Sanghi has done yeoman duty in making them consistently available (and well-marketed). In the end, that's all that matters. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff(a)interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Nico Coesel on 17 Jan 2010 17:08
Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Sat, 16 Jan 2010 16:06:28 GMT) it happened nico(a)puntnl.niks >(Nico Coesel) wrote in <4b51e214.584438953(a)news.planet.nl>: > >>>Here is a nice example of a project that uses 2 PICs for a start, >>> http://panteltje.com/panteltje/pic/swr_pic/index.html >>>And guess what, both are listening on the same RS232 line, >>>and one does the reply work and carries the help text. >> >>So you'll have to program 2 devices, > >Yes, but the reason was actually not code space related but I/O pins. > > >>keep 2 versions of software in >>sync, > >Now if that was the biggest problem, I have almost 1000 software versions out there, >this morning an other email about one with suggested code improvements. >Thats is how open source works, pfff 2 versions.... don't overwork yourself:-) > > >>place 2 devices, > >So, 18 extra pins, I wonder how many I/O pins that ARM solution of yours has. As many as you need. ARM devices go from 32pin packages to 100+ pin packages. Placing one package is cheaper than placing two. Programming one device is cheaper than two. >>use more boardspace > >Oh yes, that really is a worry if you have 1 cubic decimeter available...NOT. > > >>and have no way to move to >>a different platform > >Why move? PICs last as long as the FLASH last, so does your ARM. >>without rewriting from scratch if you have to. > >Product lifetime... think about it. Changing product requirements? Products getting obsolete? A lot of people don't realize it but for companies that do software development the software is the most valuable asset the company owns in terms of investment. Having to rewrite and retest known-good-code is a huge waste of money. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) -------------------------------------------------------------- |