Re: What micros do you actually like to work with?




Mike Silva wrote:
Or, to put it another way, which micros cause you the least grief? And
what about those makes them favorites?

I ask because I'm always interested in trying new families, especially
ones that come well recommended.

I really like ARM chips. Their architecture is fairly clean and simple
to understand. One thing I really like about them is the fact that they
have conditional instruction execution. It can make assembly code
easier to read and the compiler writers job a bit easier. These would
be my 32-bit MCU of choice. I also like the 68K architecture which IMHO
was one of the best CISC archs.

For 16-bit/8-bit arena, I am not too sure. I have played with the PIC,
8051 and the MSP430. It is very difficult to decide. Another big player
is the AVR, which I personally have not played with. The PIC was
alright to program simple applications in assembly and the like (low
current too, I was measuring it at ~1 or 2mA full speed 4Mhz 16F628 @
5V). But I wanted to try my hand at HLL programming on an MCU. Now, I
had a firm enough knowledge of the underlying mechanics and the ways C
compilers typically implement certain constructs to know that it would
not map on to the architecture to well and would make the sometimes
necessary task of assembly level debugging a real pain. The 8051 fared
better w.r.t C code, but the chip needs quite a bit of power and
external support components and needs a large crystal for decent
performance (of course, you can get single cycle cores).

The MSP430 on the other hand has a GNU compiler collection compiler
readily available. An added plus is that writing startup code is
unnecessary. Just write your C code and you are ready to go. It also
makes for easy and readable assembly code (quite simple to understand).
I haven't really done anything practical with the MSP430 yet, so I
can't give you an idea of how the chip worked for me. Also the MSP430
and the ARM have JTAG debug support, for which you only need very low
cost debug hardware (a 'WIGGLER' in the ARM case). The 8051 and the PIC
on the other hand, will need the use of simulators (or external ICE's).




Other mentions: MAXQ, Freescale's HC(S)08/12 (Freescale makes reputable
chips as well)

-Isaac

.



Relevant Pages

  • Re: for your languages
    ... mind then he is able to know exactly what assembly code will be generated ... compiler for a different architecture. ...
    (comp.lang.c)
  • Re: In-circuit emulation and debugging for PIC
    ... They are hard coded keywords in the compiler, ... and easily retargetted at other chips within a family. ... >separate device control from higher level decision making. ... >If you're not firm on PICs, AVR is worth considering. ...
    (sci.electronics.design)
  • Re: Datatype misalignment exception....
    ... the compiler generates 4 access in memory that read one byte ... and r3) so the access doesn't rise exception because it is byte aligned. ... Bruce.Eitman AT Eurotech DOT com ... the BYTE array is the same...so you said that the assembly code generated ...
    (microsoft.public.windowsce.platbuilder)
  • Re: In-circuit emulation and debugging for PIC
    ... They are hard coded keywords in the compiler, ... and easily retargetted at other chips within a family. ... The "great" software emulator sounds very ... cost isn't a significant issue, you can be quite happy with either. ...
    (sci.electronics.design)
  • Re: What is Forth?
    ... the target, and then tell me why those aren't advantages for seaForth. ... we're no longer at the point where your seaForth chips are just ... would be affected by CPU's being used up by the compiler? ...
    (comp.lang.forth)