Looking for Microcontroller Recommendations
in [Design]
|
From: Jan Panteltje on 17 Jan 2010 04:21 On a sunny day (Sat, 16 Jan 2010 22:43:57 -0700) it happened don <don> wrote in <M5CdnSYOtdADPs_WnZ2dnUVZ_tWdnZ2d(a)forethought.net>: >You have to remember, the PIC was designed to be cheap. > >To be cheap, internal decoding had to be limited. >So banking, instead of decoding a larger memory map. > >Like the 8042 so many years ago. > >Even with a "cheap" register set, a C compiler can be built to make >programming easier for us grunts in the field. > >I did not use PICs until the first C compiler came out. >Does not really matter how bad the code is, your programming in C and >not assembly. > >Any C compiler take a lot of the tediousness out of programming. C is OK for micros with a lot of memory. The small PICs like 12F... and 16F... I prefer to program in asm. The effort is the same, but in asm you know exactly what happens. When doing it in C you will have to look at the asm it generated many times... Once you did some in asm, then quickly you have collected a library of useful routines. Time critical requires asm anyways. Portability is not really an issue for those small things, often the hardware is unique, look at temp_pic for example: http://panteltje.com/panteltje/pic/temp_pic/index.html Or freq_pic: http://panteltje.com/panteltje/pic/freq_pic/index.html Pronounced freak PIC...
From: Spehro Pefhany on 17 Jan 2010 10:46 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. >If you >like your sanity, I wouldn't program those in assembly though (google >'MIPS one delay slot'). I haven't looked at the assembly code for MIPS. ARM assembly is pretty reasonable. 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. 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: Spehro Pefhany on 17 Jan 2010 11:16 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. 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 12:03 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. Porting code between them requires a lot of defines (think about types that include the bank number, interrupt service routines, pragma's, attributes, etc). And the architectural differences between PIC32 and previous PICs are too big to share code efficiently. I tried to keep some code portable between ARM (gcc) and PIC16 but that is a no go. ARM and MIPS processors really like pointers with offsets. PIC16 does not. On ARM/MIPS it is more efficient to pass a pointer to a struct (part of an array of structs). However on PIC it is more efficient to provide an index into the array of structs. So keeping data as local as possible won't fly with PIC. >>If you >>like your sanity, I wouldn't program those in assembly though (google >>'MIPS one delay slot'). > >I haven't looked at the assembly code for MIPS. ARM assembly is pretty >reasonable. > >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. Well, the assembler I used didn't re-order the instructions. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: krw on 17 Jan 2010 12:14
On Sun, 17 Jan 2010 09:34:28 +0100, Falk Willberg <Faweglassenlk(a)falk-willberg.de> wrote: >krw schrieb: >> On Sat, 16 Jan 2010 23:26:34 +0100, Falk Willberg >> <Faweglassenlk(a)falk-willberg.de> wrote: > >... > >>> The manual >>> of my car (Peugeot Diesel, 2000 model) recommends to start the engine >>> and immediatly drive at low RPM. Even the very simple engine of my >>> motorcycle[0] does not require any warm up. >> >> You probably believe you can go 10000 miles on an oil change too. > >No, it's about 12000 miles (20000km) maybe only 9000 (15000km). And I >use the cheapest oil I can get, that meets the specification. I never >had an engine breakdown in 25 yrs. You're a fool. >As this thread is OT now, EOD for me. Bye. |