8- to 16-bit Embedded System Upgrade

Hi Karl

Check out the MSP430 from Texas. Haven't used it myself yet but I am going to since this series looks very promising. You can even obtain them with a HW multiplier in there if things become math-heavy. Prices are in the 8051 ballpark but you get 16 bits.

Regards, Joerg

snipped-for-privacy@yahoo.com (karlbkeller) wrote in news: snipped-for-privacy@posting.google.com:

Funny, I never wrote more than few lines of 8051 assembler. All my 8051 projects were in C.

I love the MSP430 from TI. Go JTAG debug! For USB, I thought the Cypress

8051s were nice though.

--
- Mark ->
--

I'd look at the top end 8051's first (there is a LOT of life in this yet!), and then look at the 32 bit ARM Microcontrollers, and skip 16 bits/Sole sourced cores entirely.

For an example of what is currently at the top-end in 80C51, see

This $25 PCB includes a on-Chip DEBUG with USB Link, and USB data link, so is an impressive development platform.

SiLabs single cycle 80C51s come in 25/50/100MHz/(60MHz soon)

and for examples of ARM uC, see

as well as AnalogDevice, Atmel (FLASH soon), STm, Motorola, TI, OxfordSemi ...

if you need really FAST USB, look at

(this also has a 80C51 core...) besides Cypress, others that have USB+80C51 in one chip, are TI, SiLabs, STm.

-jg

-jg

If you go with the MSP430, do get the IAR compiler for it. It is the best microcontroller development environment i've ever come across. And it's very stable too.

Mike

Though MSPGCC works well, and is a bit cheaper.

Paul Burke

If it doesn't have an external bus, the Phillips XAG49 would be a more-or-less drop-in replacement. For some reason best known to themselves, they didn't keep it compatible if you expand it- thus deliberately ignoring whole chunks of potential market. Raisonance do a good compiler.

Or as other people have said, MSP430 is a good processor within its limitations- you'll have to rejig the whole caboodle for 3.3V supply. The mix of peripherals varies from very good to excellent.

Paul Burke

Depends on so many variables like cost, power, tools, etc., but I'd consider an ARM7 based chip. There are many choices from many chip vendors with all kinds of peripheral options and plenty of tools.

--
Scott
ExoTech R&D, Inc.

Hi Mike,

As far as I know the compiler that comes with TI's eval kits is the IAR compiler. However, I believe that version is capped at 4k for C or something around that, so if things become larger it would be necessary to buy the full version.

Regards, Joerg

Joerg wrote in news:pWeMc.469$ snipped-for-privacy@newssvr27.news.prodigy.com:

Correct, 4kB is the limit. At the time we used it we need 8kB so it cost us $800, when we later moved to the unlimited version we were credited the $800 towards the unlimited license. I just wish they'd use FlexLM instead of dongles.

--
- Mark ->
--

You have obviously not been in this business long....

You're telling me that gdb (pref with a GUI; Insight?) works now?

IAR is a pretty good tool, but I do find the FET annoying, it loses sync too often. That's not IAR's problem of course; probably the serial programmer tool is a better option as it can generate the required JTAG timing with certainty.

I like the MSP's also, but do you think TI will ever come out with one that has more (or external) RAM? Perhaps these versions wouldn't have the very low power consumption though... Some jobs just need more, and I'd prefer not to have to switch to another family for those.

Clifford Heath.

They have done a lot of work on it. I don't use it, I've always used serial download and printf probes for debugging, bit of a primitive really.

They have 20k RAM versions now, but no plans AFAIK for external bus, which I would really like.

Paul Burke

It's worked fine for me for a good while now - and if you aren't fond of Insight, you can use other gui's like gvd, ddd, or eclipse (haven't tried eclipse myself, though).

There are also other alternatives like ImageCraft. I'm not saying there is anything particularly wrong with IAR (it has quirks that I find annoying, but maybe that's just me), and I've heard that it can generate slightly tighter code than other compilers, but it's a great deal of money for not much more than gcc (which is the best value for money, although not necessarily the easiest for timid newbies) or ImageCraft (which might be called "the happy medium"), and perhaps other choices as well that I don't know of.

There are new chips with more internal ram, but I very much doubt that TI will come out with an external databus version - the costs in money and pin space are just too high for the market for these chips. They are also very unlikely to go beyond the 64k barrier for the address space (flash + ram + peripherals) - doing so would make a mess of the very neat architecture (for comparison, do a google search on problems and questions regarding the AVR Meag128 - the majority are concerned with accessing 128k from 16-bit pointers).

Which MSP430 "development environment" offers the better GUI then?

So why does

list GDB support as still needing to be implemented? Is it currently only implemented on the GDB simulator? If so, I'm not interested, I have to test with real hardware attached. I'm also not interested in running a gdbproxy implementation inside the 4K flash - I don't have room. It needs to support JTAG.

Clifford Heath.

tried

Because no one has updated that page for a while, I suppose.

You are thinking of a "gdb stub", not gdbproxy. Stubs run on the target, and communicate with a gdb over a serial link (or ethernet, or whatever the target has available). I don't know if anyone has written one for the msp430 - stubs are normally used on "big" processors that have resources to spare, and that have introspection capabilities (like trace modes and software breakpoints).

gdbproxy runs on the pc, and translates between gdb (normally on the same pc, but it can be different - I've run gdb at home connected to gdbproxy on my work machine...) and the FET parallel port jtag debugger. It works fine - there are the occasional hiccups, but no more so than I've had using IAR's kickstart, and there are regular updates to support newer chips, improve speed, etc. There are also stand-alone programs available for programming the flash using the FET, which are true open source (gdbproxy is not entirely open source - the original version is available under the BSD license, but the msp430-specific modifications are binary-only since TI wants to keep the jtag commands secret. There are binaries available for windows and linux).

Correct, sorry for the mistake. I was going to implement a gdbproxy in my DL11 68HC11 debugger. I used a talker that fitted in the 256 bytes of RAM (or used 11 bytes once it was loaded into (E)EPROM), so a gdb stub wouldn't have been viable there.

That's great news! I have my weekend's work cut out now, porting my app across from IAR :-). I haven't made any progress on it since refusing to install Windows on my new 'puter :-), though I was considering trying IAR from within VMWare (which I don't think would have worked well).

Clifford Heath.

It's probably worth joining the gccmsp mailing list - it covers gdb as well. I don't remember off-hand what the status of the Insight gui is, as I use gdb mostly from the command-line or using gvd as a gui (since it runs natively in windows, and can connect to gdb's for any target - I use several). I did get ddd working with msp430 gdb, but it was not exactly "fast" (running under windows/cygwinX)...

IMHO the GUI is the _least_ important part of the toolset. All of the tool vendors that it has been my misfortune to have to use tent to try and foist their favourite GUI/editor on to the poor developer. I develop for the ARM (who force a version of codewarrior on you), DSP563XX (Tasking tools include CodeWright) and the MSP430 (the IAR IDE). The best way to use these tools, if you can, is to have your own favourite editor/GUI and invoke the tools from here.

The more important questions are the quality of the code that the toolset produces and the quality of the support that you get for your money.

On the first point IAR has in the past been the benchmark to which the other vendors have aspired. I believe that the 3 major (commercial) competitors to IAR are now producing code of a similar or in some cases better efficiency.

On the second, historically IAR support for the 430 has been pretty awful but it seems to be better now. I have been highly impressed by the degree of support offered by the other 3 through the MSP430 newsgroup.

The three other suppliers that I have had contact with are: Rowley associates

Quadravox Imagecraft

S-V