Re: Purchase microcontroller dev. kit

Nico Coesel wrote:
"David L. Jones" <altzone@xxxxxxxxx> wrote:


try to compile the following on an AVR:
const char a[]={"hello world"}
char b[30];
char *p;

p=a;
strcpy(b,p);
strcat(b, "?");
printf("%s %s", a, b);

It won't work because the different memory areas will screw-up the
pointers. Some very smart and expensive compilers may be able to solve
these problems at the expense of speed.


That works perfectly well using avrgcc. Even on compilers which don't support it directly, the way to deal with code like that is clearly explained in user manuals and FAQs. You weren't suggesting that a beginner should just wade in without looking at the manuals?

Of course, no one doing embedded development on a small microcontroller would write code like that anyway - using printf is a sure sign you don't know what you are doing.

The two most sensible families of small microcontroller for beginners or general use are the AVR and the msp430. There are lots of
AVRs (and lots of development boards), and the peripherals are easy to use. The msp430 is a better fit for C development if you are doing more advanced programming. It also has some more powerful and flexible peripherals, but they are correspondingly more difficult to learn.

Other than that, the choice should be based on availability of local knowledge, books, cards, etc.

Don't worry about non-portability of code. Nothing you write now (as a newbie) will be reused significantly in the future, and all embedded code has at least some layers of non-portable code anyway.
.

Relevant Pages

  • Re: Moving from 8051 to AVR
    ... This applies to working with the AVR just ... Yes, that was the original argument - although it has now been slightly sidetracked by your claim as to *why* it is good, which was that it means any old PC programmer can then write good embedded code for the chip. ... IAR have plenty of knowledge of C compilers, but they have their own particular way of handling microcontroller functionality that has no place in standard C, such as handling flash memory spaces. ...
    (comp.arch.embedded)
  • Re: C programming on ARM
    ... You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code). ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are incompatible. ...
    (comp.arch.embedded)
  • Re: Beginning PICs
    ... Only reason you might would be bad hardware layout or bad hardware design. ... Messing with AVR fuses is trivial. ... Messing with PIC banking is a huge mess. ... The only free C compilers for the PIC are toys. ...
    (comp.arch.embedded)
  • Re: C programming on ARM
    ... But as you say C doesn't map onto these architectures, ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are ... There are indeed architectures which can't fully support standard C. ... work on standard C compilers. ...
    (comp.arch.embedded)
  • Re: need a tiny help with my SWIGd program
    ... void setitem(int i, char* value) { ... underscore followed by an uppercase letter is reserved to the ... implementation for use as a name in the global namespace." ... compilers are more forgiving than the stantards: ...
    (comp.lang.tcl)