EmbeddedRelated.com
Forums

Assembler BIS instruction and register indirect as destination - can't assemble this line of code

Started by David Feldman August 7, 2012
I agree with you on the DSP front. I hate Ti DSP's, I've tried several,
from the early 320C30, through the 24xx parts, and several of the newer
parts. And to may they simply don't compare to the old ADSP21xx parts. I
once crammed a 2400bps codec into a 2105 and even had a little room to
spare. And algebraic programming for DSP functions seems a no brainer.
The only thing I wasn't a big fan of was the complex header files
(compared to some other DSP's). Of course it sucked current like a
toothless parrot, but it was still a great machine I felt. I was a huge
fan of Microchip for many years, from the pre-microchip era, when I used
lots of little PICs as individual axis controllers for a FAB robot,
until the mid to late 90's when I was caught by 2 year delays in the
release of some parts, and ended up switching to the MSP after trying
AVR and a couple of others.

As you say the timers are one of the best peripherals around, and
compared to Microchip and AVR there is never a shortage of them on most
parts. The clock system has varied heaps over the years, but mostly has
become better each time, even the comm peripherals, though not truly
spectacular, are simple and quite powerful. I am able to get excellent
communication at 460800baud, for example, just using the pre-calibrated
DCO at 16MHz with a regulated voltage and across a decent temperature
range. More importantly it takes very few lines of code to implement
either a UART or an SPI control. Perhaps the worst peripheral though is
the DMA, since it isn't a 'true' independent module, but steals CPU
cycles. There are times when using the DMA is actually slower than
running your own code.

Al

On 9/08/2012 3:32 PM, Jon Kirwan wrote:
> On Thu, 09 Aug 2012 05:50:48 +0930, you wrote:
>
>> Perhaps I'm too engrossed in some of the mythology regarding the MSP430
>> origins, but my understanding was that it was designed by Ti's analog
>> group in Germany, primarily to meet a need for new ex eastern european
>> nations, now moving into the EEC, to meter energy usage, which had
>> previously been free. If that is really the case then could they have
>> been expected to be well versed in instruction set design, or to really
>> care?
> I don't think that pure analog designers decided to suddenly
> become instruction set designers and wear all hats in this
> design, for several reasons. But I would guess they didn't
> look too hard when finding someone to do that task. Perhaps
> you are right -- they didn't care.
>
> Still, when taking this to a general embedded engineering
> public there remains no real excuse in not cleaning this up.
> They had already done all the hard work on low power and it
> would decidedly NOT have been a yeoman's work to tidy things
> up a bit. I've done a complete CPU design before (not low
> power of course about which I greatly respect the talent
> involved), built and tested it, and looking over what went
> wrong here it would not have been a difficult challenge, nor
> expensive (in a cash sense.)
>
>> At this time Ti were very DSPcentric, within Ti DSP was king,
> Their 320C30 and 320C40 were terrible in their day. Used
> them, didn't like the parts. And I really disliked the fact
> that TI could NOT figure out, after many weeks of
> consultations with "their supposed best team at corporate" on
> the phone, by email, and otherwise, could not explain why
> their parts didn't do what their documentation said they
> would do and had no noticeably interest in actually caring,
> either. They actually just said that they didn't know why,
> agreed it was a mystery, and spent NO MORE TIME on it once
> they admitted the problem. They didn't even change the docs
> to let others know what I found. And it was important.
>
> By comparison, Analog Devices were saints. When I uncovered a
> CPU bug in their ADSP2111 chip, they worked VERY HARD and
> showed great concern. They asked me for my test code, used
> it, and tracked the problem down to their FAB. They changed
> FABs for the parts and it fixed the problems and I had good
> parts coming in about 6 months later. And given that they
> changed FABs, and given my experience IN a FAB, I know they
> had to work their ass off to do that.
>
> TI doesn't fix things, doesn't care to. But they do make a
> lot of good stuff, just the same. So it's a mixed bag. If I
> use their parts and they test out okay, then I'm fine. If I
> use their parts and they don't test out okay, I waste little
> time going elsewhere. I'll write a note and send it on. But I
> won't hold my breath. I just go find something else.
>
> A problem is in investment of personal time and in cash
> related to all the tools one buys. This is time and money.
> Microchip has $500 tools. They add up. But I also know that I
> get support, too. Both for their chips (which they fix if I
> run into a serious problem, and they have on several
> occasions so I am not talking through my hat -- I've had a
> silicon fix in my hands in about 2 months from them) and
> their tool support, which they support long after they no
> longer sell them anymore. In fact, they still support the
> oldest tool I own of theirs and it is more than 20 years old.
>
> On the other hand, I love the MSP430's hardware, those parts
> of it I've used a lot anyway. Who can beat a B7 timer unit?
> Or the incredible clocking systems? And the price is
> certainly right for someone wanting to get started with them.
>
>> at times it
>> seemed that Ti corporate in the US actually hated the poor little MSP430
>> when it first came out, certainly they made no real effort to support it
>> until well after it had taken off and gained popularity with a sizable
>> group of engineers. yes it isn't pretty, but at the time I liked it a
>> lot better than Microchip, AVR, Motorola and 80xx stuff, and still
>> mostly do.
> Well, that may explain a lot. It's success was perhaps a
> pleasant, but unexpected surprise.
>
> Jon
>

Beginning Microcontrollers with the MSP430