1. Home
  2. Electronics Design
  3. Purchase microcontroller dev. kit
  4. Page 2

Purchase microcontroller dev. kit

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.

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.

So we should all be like lemmings? Even if the first one that jumps into the water drowns, the rest should follow?

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.

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

By the way: Olimex has some very nice MSP430 kits:

formatting link 

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

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.

It's "oddball" enough for a beginner. 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. We are talking about a *beginner* here!

Again, we are talking about a beginner here. It is a very smart move to go with a device that has the largest range of beginner resources. Blackfin DSP for a beginner? - give me a break.

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 had no problems going from AVR-PIC-Rabbit. Your point is, well, pointless.

Dave :)

Reply to
David L. Jones

[snip]
[snip]

gcc / avr-libc has no trouble whatsoever with that. It doesn't store strings, even const strings, in "different memory areas" unless you explicitly tell it to. If you do decide to store some data only in program space (flash) then avr-libc provides handy functions (like printf_P) which work directly with data in flash, and functions to copy data from flash to RAM. Doing that isn't directly portable, but it's entirely optional and it's not hard to port if you do do it.

If your compiler and libraries don't offer similar facilities, or make optimisations which break standard C, that's a problem with your choice of tools or the way you're using them. It is not a problem with the AVR architecture.

Tim

Reply to
Tim Auton

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

Look again I'd say. There is a very active user base for the MSP430. For instance:

formatting link

Same goes for the Blackfin DSP:

formatting link

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.

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
Reply to
Nico Coesel

I hope snipped-for-privacy@gmail.com has not given up on the "war" at hand.

If snipped-for-privacy@gmail.com is still listening, let us know what you have decided on.

Let us know how we may be able to help you get going.

donald

Reply to
Donald

tks for all the "war" ... haven't really decided what to begin with yet as all seems similar to me ... thinking of project navigator and modelsim but is that only for fpga and not pic?

However those xilinx products seem quite complicated due to previous attempts. Can i conclude that i can get any development starter kit and start developing and decide wat other expansions needed at a later stages? if so what kinds of expansions am i looking at ? ADC?

Moreover can i say that as long as i write my program in C, it is portable to any families of devices? I came across a dev. board from Z-world and that uses dynamic C... it contains more libraries than the standard C... so does the libraries of these dynamic C has any significance on portablities?

Lastly, the starter kit should include a dev. board (what should i look out for on these boards or are the a "standard" board?), RS 232, power supply, software with a compiler... did i miss out any thing or what should i take note of in these parts?

TKS AGAIN ywz

Reply to
ydoubleuz

Yes, FPGA are entirely different to microcontrollers.

Virtually all microcontroller families offer endless options like ADCs, you can't go wrong with whatever device you pick in this respect.

Yes. If you stick to ANSI C then you won't have a problem, once you start using the libraries that come with the packages then your program may become less portable.

Depends on what you want to do. If you want to just play around and learn then a board with I/O, LEDs, DIP switches, RS232, and other peripherals is probably best. If you have your own applications in mind, then a simple download cable is all you need which connects to your own design board or breadboard.

Dave :)

Reply to
David L. Jones

Quick note, Z-world is not ansi. Dynamic C is a horrible hack, but it does work ok. One good think about the Rabbit is its super quick to get going. Great for one off's but thats about it.

Reply to
The Real Andy

No, gcc is free.

Same for 8051, PIC and AVR, and most half decent micros.

Most hardware designers, unlike software programmers, are aware of the differences between data (sram) and code (flash). Perhaps that's the first lesson for a hardware want-to-be programmer.

So is learning ABC for a baby.

You can't blame hardware for the low student skills.

It's the qualification test.

Reply to
linnix

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.

Reply to
David Brown

Is it? All of my projects use printf (which usually comes in several grades to tailor memory requirements) to print status information, debug information and responses to commands send to a tiny command line interpreter (a little more than a string compare on a list with strings). And this is not even my idea.

Being able to have a sensible dialog with your hardware makes testing and debugging much easier. Having a command line interface is also very handy for field service. For instance: implement a command to have it print the version & build date, and presto, you know exactly which software is in the device.

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

Hi All, I advice Freescale HCS08 Series, there are lots of variety of this micro for different purposes. Some verisons are quite cheap. Codewarriod development enviroment is easy for begginners, auto code generation tool works perfectly.

16K C code compiler is free of charge. More over you can build your in circuit debbugger to program and debug your project.
Reply to
Saltuk A.

Any comments to these kits:

a) AVR micro-controller training kit (AVR-TRAIN) b)STK300, STK500 (by the way where does the difference lies btw these and (a)? ) c)E-blocks : EB343 d)C504 Starter Kit

Along this line of products, how do they compare against each other? Any other recommendations?

Tks again ywz

Reply to
ydoubleuz

Communication with your embedded system is an important aid to debugging, and a small CLI is often useful. But printf is not the way to go about it on a small microcontroller - the overhead is too big. It's frequently (though not always) a sign that the programmer is used to PC programming and PC "printf debugging", and has not thought about the costs. Look through any FAQ or mailing list for small microcontrollers - they are full of questions about why the code is so big, with the answer being either the use of printf, or the use of floating point. Of course, as with floating point, there are times when printf is the right choice, even on a small microcontroller - but it's a rarity, and not something to encourage in newbies.

Reply to
David Brown

The amount of program space used to be a problem and I did have my own printing routines, but in the end printf turned out to be more efficient to use. Most devices have plenty of flash nowadays. A decent (basic, non-floating point) printf implementation may cost around 1500 bytes of flash. Not really a problem anymore IMHO. It may become an issue in extremely cost sensitive products, then again, time to market is also an important factor.

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

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.