[Tinyos-devel] MSP430 SPI1

[David Moss]

FYI.

 

 

-----Original Message-----
From: Mark Hays [mailto:mhh at rincon.com] 
Sent: Tuesday, November 06, 2007 3:52 PM
To: David Moss
Cc: mhh
Subject: Re: MSP430 SPI1

 

The DMA problem is that usart/Msp430SpiDmaP.nc is USART0-specific -- the
trigger conditions named "DMA_TRIGGER_USART{TX,RX}" in dma/Msp430Dma.h
(which itself only exists because mspgcc doesn't provide sufficient DMA
definitions in its own headers, FWIW -- seems to be better in the newer
gcc)... anyway, these would be better named as ...U{TX,RX}IFG0 meaning
"TX/RX trigger on USART0" -- they don't apply to USART1 at all.

USART1 has accurately-named ...U{TX,RX}IFG1 consts in Msp430Dma.h. The 1xx
family data sheet gives a table of all the trigger sources -- and confirms
the above comments.

 

In other words, Msp430SpiDmaP.nc is hard-wired to **only** trigger on
USART0, even though that isn't its intent. It's also hard-wired to reference
the USART0-related bits in IFG1 -- another nail in the coffin: if you look
at the f1611 data sheet, you'll see that the bit positions used for

USART1 aren't the same as you need for USART0, so the TX/RX flag logic can't
*possibly* work on

USART1 (plus IFG2 applies to USART1, not IFG1).

Not to mention the several magic numbers whose purpose is clear but whose
function is not.

 

Fixing it would amount to adding a *pile* of parameters to this generic,
getting rid of the magic numbers, etc.

Just instantiate this new comp in Msp430SpiDma{0,1}P.nc and it *should* work
once Msp430Spi{0,1}C.nc is adjusted to use these new DMA comps. Not that bad
really. I'd fix it today if it helped me today, but it doesn't :-)

 

Feel free to pass this assessment along to the dev-list if you like;
hopefully, what I said above is correct -- but it's always worth a
double-check!

 

--M

 

 

  _____  

From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of David
Moss
Sent: Tuesday, November 06, 2007 2:46 PM
To: tinyos-devel at Millennium.Berkeley.EDU; 'TinyOS Core WG'
Cc: gustavo.litovsky at student.utdallas.edu; 'Mark Hays'; 'Rob Muir'
Subject: [Tinyos-devel] MSP430 SPI1

 

The MSP430 SPI1 driver is broken.  I believe the code was copied from SPI0,
and as such, there is some residual SPI0 stuff left over.  On top of that,
I've heard from other engineers (without investigating myself) that the DMA
controller is SPI0 specific.  Nobody can use SPI1+DMA without some changes
to the architecture or implementation.

 

There haven't been many platforms in the past that even had access to SPI1,
but within the past month or so I have been made aware of at least 2 new
platforms with radios and other peripherals connected to MSP430 SPI1.  In
fact, it makes sense to put the radio on its own SPI bus: in TDMA-based
protocols, there would be no other SPI peripheral for the radio to contend
with. 

 

I personally don't have time to look into these issues right now, so I'm
simply letting everyone know that these issues exist and they're becoming
more problematic now that new platforms are being developed.  If anybody has
time to fix the issues with the MSP430 SPI1 driver, I think you'd be
considered a small hero to the community at large.

 

-David

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20071107/d81a9f1b/attachment.html