Reply by Keith Brafford December 27, 20032003-12-27
hamilton <hamilton@deminsional.com> wrote in message news:<3fedcfe1$1_2@omega.dimensional.com>...
> Keith Brafford wrote: > > "Keith Brafford" <kbrafford@NOSPAM.earthlink.net> wrote: > > > > > >>I'll throw some more fat onto the fire. Have y'all looked at the Analog > >>Devices Blackfin > >>531/532/533 family? > > I think you should mention that thsy ONLY come in BGA packages.
The 533 comes only in a BGA package, true, but the 300MHz flavors of the 531 and 532 are available in an LQFP package. --Keith
Reply by hamilton December 27, 20032003-12-27
Keith Brafford wrote:
> "Keith Brafford" <kbrafford@NOSPAM.earthlink.net> wrote: > > >>I'll throw some more fat onto the fire. Have y'all looked at the Analog >>Devices Blackfin >>531/532/533 family? > > > I forgot to mention that the dev kits for the BF533 are $99 because of > some special, so now's a good time to check them out, if one were > interested... > > --Keith > >
I think you should mention that thsy ONLY come in BGA packages.
Reply by Keith Brafford December 27, 20032003-12-27
"Keith Brafford" <kbrafford@NOSPAM.earthlink.net> wrote:

> I'll throw some more fat onto the fire. Have y'all looked at the Analog > Devices Blackfin > 531/532/533 family?
I forgot to mention that the dev kits for the BF533 are $99 because of some special, so now's a good time to check them out, if one were interested... --Keith
Reply by Keith Brafford December 27, 20032003-12-27
"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message
news:brsqbr02b5v@enews2.newsguy.com...
> Greetings: > Whadaya think?
I'll throw some more fat onto the fire. Have y'all looked at the Analog Devices Blackfin 531/532/533 family? 16-bit fixed point processing, 32-bit integer ops, very low power capabilities (dynamic core voltage and PLL settings), and a <$5 price point on the 531 make it a contender for a microcontroller. With core speeds up to 600MHz it can be a very beefy alternative. Plus, like the MSP430, the Blackfin's native assembly language is very well-suited to C compilation. --Keith
Reply by Keith Brafford December 27, 20032003-12-27
"Leon Heller" <aqzf13@dsl.pipex.com> wrote in message
news:3fe2a241$0$7013$cc9e4d1f@news.dial.pipex.com...
> I paid 7.75 GBP each (about $13) for 20 off LPC2106 from my distributor: > Silica/Avnet, here in the UK. The pound is strong against the dollar at > present, which helps.
I think the weak dollar would make it cheaper in the states. The Philips distributor I use quoted me in the $7.50 (USD) range for the 2106 at one point. Plus the FAEs are drooling over this part, therefore I have found them quick to respond and unsually knowledgeable about it... Here's their page: http://www.futureelectronics.com --Keith
Reply by David Brown December 22, 20032003-12-22
"John Devereux" <jd1@devereux.me.uk> wrote in message
news:87vfo9vwa2.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes: > > > "John Devereux" <jd1@devereux.me.uk> wrote in message > > news:87zndlw62v.fsf@cordelia.devereux.me.uk... > > > The text seemed to imply that the problem was more general than that, > > > but now I am not so sure! If it is just peripheral access that is > > > affected, then that in itself hardly stops the processor "supporting > > > strict C compliance" as the author stated. I read it to mean that > > > arbitrary structures in memory cannot be copied byte-by-byte. > > > > > > > I think it is just that C has no standard way of dealing with
specialised
> > access for peripherals. Even declaring things as volatile does not
force
> > the compiler into specific behaviour, nor does it force the compiler to
use
> > particular access widths. So all the manual is saying is that the > > peripherals in the msp430 cannot be accessed in a pure standard C way. > > Arbitrary data memory (ram and flash) can be accessed arbitrarily. > > Well that's no problem then, that makes the msp430 a very nice "C > friendly" micro. A big improvement over the AVR in that respect I would > say, with its awkward handling of flash data. >
And that would lead us back to my original point - for C programming, the msp430 feels more natural than the AVR. In assembly, both work well, and I find I write (or wrote - I use mostly C now on both chips) accurate code with a very low error rate on both chips. It's interesting to note how different compilers deal with the two chips - in particular, comparing gcc to commercial embedded compiler specialists like ImageCraft. On the avr, gcc has to go through a number of hoops (macros, attributes, etc.) to deal with flash-based data, while the msp430 port works smoothly as flash data is as accessible as any other data. ImageCraft (and others) has a big advantage on the avr, in that they can "cheat" and use keywords to give a smoother coding style (in this case, "const" data is in flash). There are other aspects of the msp430 that make it more C-friendly than the avr - it has SP+index addressing modes, which make access to local non-register data far smoother than the AVR (in which it is a PITA - ImageCraft gets around it by dedicating a pointer register as a data stack pointer). It can also use any register as a pointer - the AVR has far too few pointer-capable registers.
Reply by December 22, 20032003-12-22
"David Brown" <david@no.westcontrol.spam.com> writes:

> "John Devereux" <jd1@devereux.me.uk> wrote in message > news:87zndlw62v.fsf@cordelia.devereux.me.uk... > > The text seemed to imply that the problem was more general than that, > > but now I am not so sure! If it is just peripheral access that is > > affected, then that in itself hardly stops the processor "supporting > > strict C compliance" as the author stated. I read it to mean that > > arbitrary structures in memory cannot be copied byte-by-byte. > > > > I think it is just that C has no standard way of dealing with specialised > access for peripherals. Even declaring things as volatile does not force > the compiler into specific behaviour, nor does it force the compiler to use > particular access widths. So all the manual is saying is that the > peripherals in the msp430 cannot be accessed in a pure standard C way. > Arbitrary data memory (ram and flash) can be accessed arbitrarily.
Well that's no problem then, that makes the msp430 a very nice "C friendly" micro. A big improvement over the AVR in that respect I would say, with its awkward handling of flash data. -- John Devereux
Reply by David Brown December 22, 20032003-12-22
"John Devereux" <jd1@devereux.me.uk> wrote in message
news:87zndlw62v.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes: > > > "John Devereux" <jd1@devereux.me.uk> wrote in message > > news:8765gcy5tp.fsf@cordelia.devereux.me.uk... > > > Isn't there a problem with the MSP430 and word/byte accessing? See the > > > last paragraph of this link from the msp-gcc documentation: > > > > > > <http://mspgcc.sourceforge.net/manual/x213.html> > > > > > > Perhaps this is just a limitation of the msp-gcc port. > > > > > > > No, that's exactly the same as with every other 16-bit (or more) > > microcontroller - some peripherals need to be accessed as 8-bit and
others
> > as 16-bit to work correctly, while others are freely accessible as
either.
> > All you need to do is make sure the peripherals are declared properly
(i.e.,
> > volatile unsigned chars or volatile unsigned ints), and the compiler
fixes
> > things correctly. It applies to all compilers - it's just that the
msp-gcc
> > manual gives a lot of information about that sort of thing. > > > The text seemed to imply that the problem was more general than that, > but now I am not so sure! If it is just peripheral access that is > affected, then that in itself hardly stops the processor "supporting > strict C compliance" as the author stated. I read it to mean that > arbitrary structures in memory cannot be copied byte-by-byte. >
I think it is just that C has no standard way of dealing with specialised access for peripherals. Even declaring things as volatile does not force the compiler into specific behaviour, nor does it force the compiler to use particular access widths. So all the manual is saying is that the peripherals in the msp430 cannot be accessed in a pure standard C way. Arbitrary data memory (ram and flash) can be accessed arbitrarily.
Reply by December 22, 20032003-12-22
"David Brown" <david@no.westcontrol.spam.com> writes:

> "John Devereux" <jd1@devereux.me.uk> wrote in message > news:8765gcy5tp.fsf@cordelia.devereux.me.uk... > > Isn't there a problem with the MSP430 and word/byte accessing? See the > > last paragraph of this link from the msp-gcc documentation: > > > > <http://mspgcc.sourceforge.net/manual/x213.html> > > > > Perhaps this is just a limitation of the msp-gcc port. > > > > No, that's exactly the same as with every other 16-bit (or more) > microcontroller - some peripherals need to be accessed as 8-bit and others > as 16-bit to work correctly, while others are freely accessible as either. > All you need to do is make sure the peripherals are declared properly (i.e., > volatile unsigned chars or volatile unsigned ints), and the compiler fixes > things correctly. It applies to all compilers - it's just that the msp-gcc > manual gives a lot of information about that sort of thing.
The text seemed to imply that the problem was more general than that, but now I am not so sure! If it is just peripheral access that is affected, then that in itself hardly stops the processor "supporting strict C compliance" as the author stated. I read it to mean that arbitrary structures in memory cannot be copied byte-by-byte. -- John Devereux
Reply by David Brown December 21, 20032003-12-21
"John Devereux" <jd1@devereux.me.uk> wrote in message
news:8765gcy5tp.fsf@cordelia.devereux.me.uk...
> "David Brown" <david@no.westcontrol.spam.com> writes: > > > > > I've used both the AVR and the msp430, and I like both architectures -
but
> > the msp430 is definitely nicer to work with both in C and assembly. The
avr
> > is more elegant in some ways, resulting in code that runs very close to
one
> > instruction per clock. But the msp430 has a very flexible instruction
set
> > that has two big advantages over the avr, especially for C programing -
it
> > is 16-bit wide, and it has a single flat memory space. The avr's
Harvard
> > architecture may be faster, but the single memory space is vastly easier
to
> > deal with (no more complications with strings and data in flash). > > I agree about the problems with putting strings and data in flash! > While it's easy enough to do, it does make it difficult to write > general purpose, portable C that is not littered with special macros > and functions to specify flash or ram storage. > > Isn't there a problem with the MSP430 and word/byte accessing? See the > last paragraph of this link from the msp-gcc documentation: > > <http://mspgcc.sourceforge.net/manual/x213.html> > > Perhaps this is just a limitation of the msp-gcc port. >
No, that's exactly the same as with every other 16-bit (or more) microcontroller - some peripherals need to be accessed as 8-bit and others as 16-bit to work correctly, while others are freely accessible as either. All you need to do is make sure the peripherals are declared properly (i.e., volatile unsigned chars or volatile unsigned ints), and the compiler fixes things correctly. It applies to all compilers - it's just that the msp-gcc manual gives a lot of information about that sort of thing.