Re: Purchase microcontroller dev. kit

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

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

Nico Coesel wrote:
Donald <donald@xxxxxxxxxxxxxxxx> wrote:

Nico Coesel wrote:

mrdarrett@xxxxxxxxx wrote:


Nico Coesel wrote:

ydoubleuz@xxxxxxxxx wrote:


Hi all,

I am new to this and i hope to purchase a development kit for dev.
microcontrollers. Due to the numerous varieties available in the
market, i am lost as where i should start and what stuffs to look out
for when purchasing these kits.

Whatever you buy, make sure the microcontroller has one addressing
space (no 8051, no AVR, no PIC) if you want to keep your code
portable. You wouldn't be the first developer who has found the
platform that looked so promising in the past turns out to be a
deadlock.


No 8051, no AVR, no PIC? What *would* you recommend, then? ;-)


Hitachi/Renesas H8 / H8S, Texas Instruments MSP430, Analog Devices
Blackfin DSP.


Oh crap, now you did IT !!!

The religous war about my CPU is better than your CPU is going to start.

No not at all. Look at the big picture here. Its not the CPU that
matters, its where you want to go in the future that matters!

A choice for a CPU should be driven by the question: "What if I want
to move to a different platform". With some platforms the answer to
this question is: "throw away everything you wrote and start over". So
a choice for a platform should be made with great care.

There is NO best processor, this is too small or too large, but you will
learn this for yourself.

That's exactly why I listed a general purpose microcontroller series,
a micropower series and a full blown 300+ MHz 32 bit DSP with MMU
capable of running a genuine OS like Linux. However, generic C code
written for one, can be moved to the other.

Gee that's stange, how on earth have I moved C code almost seamlessly
from a PIC to an AVR to a Rabbit then?

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.

Yes they can. If the compiler can do it then what's the problem? Speed
ain't the main requirement on a microcontroller platform, especially
for a beginner.

So you expect a beginner to spend a small fortune on a compiler?

You can't be serious suggesting that a beginner think about the "big
picture" and choose some oddball processor based on some perceived
future requirement, that is crazy.

Oddball?? I wouldn't call the MSP 430 series oddball (lots of people
are using these). You don't even need a programmer to program it! An
RS232 to TTL converter (or a USB to serial converter chip) is enough
to get going.

It's "oddball" enough for a beginner.

Look again I'd say. There is a very active user base for the MSP430.
For instance: http://www.geocities.com/leon_heller/msp430.html

Same goes for the Blackfin DSP:
http://blackfin.uclinux.org/projects/stamp

What about the "Hitachi/Renesas H8 / H8S and Analog Devices Blackfin
DSP you mentioned.
Show me all the beginner books, kits, code and support groups for any
of the ones you mentioned. PIC and AVR beat them 10-1.

Almost 2 decades ago I actually started with the Hitachi H8. I recall
later on the 8051 was much harder to understand than the H8. The H8
series is very straightforward and easy to use.

Besides, you make my point exactly: if you choose PIC, then you're
stuck with PIC examples. If you choose a processor for which any
generic C code can be compiled, you can use any piece of C code you
can get your hands on.

Umm, the PIC runs C just fine, thanks.
Every platform will have specific requirements with regards to memory
and other resources. It is easy to write C code that is "generic"
enough to almost seamlessly transport between platforms. Like I said, I

As I said before: any harvard CPU has issues with telling whether a C
pointer points to data or program memory. If you choose not to use
harvard based cpu's, you don't have to kludge around problems with
pointers and as a result your life will be much easier.

Besider, it turns out pointers are the most difficult concept for a
'programmer' to learn. Ask any teacher that has experience teaching a
programming language which uses pointers. Therefore recommending a
harvard CPU, which inherently has different kinds of pointers, to
begin with is IMHO not a good idea.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
.

Relevant Pages

  • Re: Purchase microcontroller dev. kit
    ... The religous war about my CPU is better than your CPU is going to start. ... to move to a different platform". ... That's exactly why I listed a general purpose microcontroller series, ... You can't be serious suggesting that a beginner think about the "big ...
    (sci.electronics.design)
  • Re: Purchase microcontroller dev. kit
    ... The religous war about my CPU is better than your CPU is going to start. ... to move to a different platform". ... That's exactly why I listed a general purpose microcontroller series, ... from a PIC to an AVR to a Rabbit then? ...
    (sci.electronics.design)
  • Re: Purchase microcontroller dev. kit
    ... I am new to this and i hope to purchase a development kit for dev. ... The religous war about my CPU is better than your CPU is going to start. ... to move to a different platform". ... That's exactly why I listed a general purpose microcontroller series, ...
    (sci.electronics.design)
  • Re: Hot plug vs. reliability
    ... >> the memory controller can be switched into a test mode, ... Probably it is platform dependent. ... for a 32 CPU "main frame". ...
    (Linux-Kernel)
  • Re: TCP/IP send, sendfile, RAW
    ... the platform is a netsilicon NS9360 witch include an 100MBit ethernet device. ... CPU load is 100% when running sender program. ... What you have to consider is processing required per packet. ... At the interrupt level you could use NAPI or interrupt coalescing etc. ...
    (Linux-Kernel)
Loading