Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: LPC2148 SPI and SSP behaviour

2006-05-01 by rtstofer

.
> > 
> > SPI speed:
> > I initialized the SPI module and to my surprise the clock was only 
> 7.5 
> > MHz even though the core was running 60MHz. Then I saw in the 
> datasheet 
> > that the SPI module only runs at 1/8 of the core speed. Can that 
> really 
> > be true and why is that? 7.5MHz at max is close to useless in these 
> days.

Why would you think that the User's Manual, which is quite explicit,
is wrong?  The same limitation on SPI speed occurs on multiple devices
such as the LPC2103, 2106 and 2148.

> > 
> > SSP interrupts:
> > In my design I have a DAC connected to the SSP module. The DAC 
> needs 24 
> > bits for each conversion. Therefore I need to pull the SS low then 
> send 
> > the 24bits and wait for the SSP modul to enter idle state (Checking 
> the 
> > busy flag) then raise the SS again. Now I want to get this process 
> to 
> > run automatically in interrupts. So I need to get an interrupt when 
> the 
> > SSP is done... But it doesn't seem to be possible, the only flag 
> > available is the timeout flag and that is issued 32 clocks after 
> the 
> > transmission ends. Which leaves me with a bit gab in the 
> transmission. 
> > Is the timeout flag my only friend in this situation?

There are FIFO flags that indicate when the buffer is half empty
(transmit) or half full (receive).

None of these may help where you want to specifically control the
conversion, presumably as a function of time.  So, how do you
determine when to send data to the DAC?

> > 
> > Interrupt problem:
> > I got timer vectored interrupts up and running just fine, however 
> the 
> > SSP just won't request any interrupts. Here is a snippet of my 
> code. 
> > Maybe it's very obvious what I'm doing wrong, but I can't see it.
> > As I said the other interrupts are working just fine, so I really 
> can't 
> > see why the SSP interrupts won't work.
> > I'm using the CrossWorks compiler.
> > 
> > static void SSP_isr(void) __attribute__ ((interrupt ("IRQ")));


I would think you would want to move SSP_isr away from the one and
only IRQ interrupt entry point by defining:

void SSP_isr(void) __attribute__ ((interrupt));



> > static void SSP_isr(void) {
> >   static uint8 ting;
> > 
> >   for(;;);
> > 
> >   VICVectAddr = 0;
> > }
> > 
> > void SSP_Init(void) {
> >   SSPCR0 = (0 << 8) | 0x47;  // Set phases and baud rate
> >   SSPCR1 = 0x02; // Enable SSP module
> >   SSPCPSR = 0x02; // Clock Prescale Register
> >   PINSEL1 |= 0x000002A8; // Map the SPI functionality to pins
> > 
> >   SSPIMSC = SSPIMSC_RORIM |SSPIMSC_RTIM | SSPIMSC_RXIM | 
> SSPIMSC_TXIM; 
> > // Enable the interrupts
> >  
> >   VICIntSelect &= ~0x00000800;   // Map SSP to "IRQ"
> >   VICIntEnable = 0x00000800;      // Enable the SSP interrupt in 
> the VIC
> >   VICVectCntl2 = 0x0000002B;     // Map SSP interrupt to VIC slot 2
> >   VICVectAddr2 = (unsigned int) SSP_isr; // Assign the interrupt 
> handler
> > }
> > 
> > And one last question... is it possible to shift between the ARM 
> and 
> > thumb mode realtime. Is it possible to make some of my functions in 
> > thumb mode and some in ARM mode? Any pragma to control the mode?
> > 
> > Thanks in advance! Hope that I have made some worthy questions!
> > 
> > Best regards
> >    Jan Thogersen
> >
> 
> Hi Jan,
> Many options on the SSP, but one I have used several times in a 
> similar situation is to trigger an interrupt using SS. You can 
> connect the SS signal to an external int pin. Not the most elegant 
> and it uses an extra pin, but it seperates the interrupt mechanism 
> from the SSP module (up to you to decide if that is a good thing in 
> your app.)   Also, if you are generating your SS signal from the LPC 
> timers you can use the timer interrupts.
> 
> Regards,
> Ian
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.