Lpc2000

I'm trying to communicate with a AD converter through a SPI interface.
In the AD datasheet, it's said that I need to have DIN line (from AD) in
low level when it's transmitting. This means that I have to write 0x00
on MOSI line while i'm receiving the data. The problem is, there's just
one data register, can I do that? If I can't, can I change just the MOSI
pin to GPIO mode and put on low level while I'm receiving data?

 

Rodrigo Martins

Dpto. Projeto

Intermetric Instrumentos Ltda

That is usually the case. In order to read a byte from a slave register you
must transmit a "dummy" byte from the master. By putting 0x00 in the SPI
data register you will initiate the SPI cycle. Once the dummy byte has been
shifted out your SPI data register will hold the value from the slave.

Master controls the SPI transfer.. every time you send something from the
master by putting something in the data register you will get back something
from the slave. Sometimes that might be garbage that you disregard, and at
other times it is what you need. I assume that in your case you have to send
the control byte to start the AD conversion and then your result is waiting
for you in the register of the slave. 

If you change the MOSI to GPIO the SPI module will not generate the clock
signal, hence your AD converter is not going to shift anything out.

Hope this helps.

Cheers,

m.

PS: don't forget the famous SSEL that has to be pulled high if LPC210x is
your only master on the bus, by means of pull up resistor or by tying it to
VDD.

 

  _____  

From: Rodrigo [mailto:rodrigo@...] 
Sent: Monday, June 07, 2004 8:57 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] SPI

 

I'm trying to communicate with a AD converter through a SPI interface. In
the AD datasheet, it's said that I need to have DIN line (from AD) in low
level when it's transmitting. This means that I have to write 0x00 on MOSI
line while i'm receiving the data. The problem is, there's just one data
register, can I do that? If I can't, can I change just the MOSI pin to GPIO
mode and put on low level while I'm receiving data?

 

Rodrigo Martins

Dpto. Projeto

Intermetric Instrumentos Ltda

 






Yahoo! Groups Sponsor



ADVERTISEMENT
 
<http://rd.yahoo.com/SIG=129p4cgm7/M=298184.5022502.6152625.3001176/D=groups
/S=1706554205:HM/EXP=1086699357/A=2164331/R=0/SIG=11eaelai9/*http:/www.netfl
ix.com/Default?mqso=60183351> click here


 
<http://us.adserver.yahoo.com/l?M=298184.5022502.6152625.3001176/D=groups/S=
:HM/A=2164331/rand=566221722> 

 

  _____  

Yahoo! Groups Links

*	To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/
  
*	To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  
*	Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/>  Terms of Service.

On Jun 7, 2004, at 5:57 AM, Rodrigo wrote:

> I’m trying to communicate with a AD converter through a SPI interface. 
> In the AD datasheet, it’s said that I need to have DIN line (from AD) 
> in low level when it’s transmitting. This means that I have to write 
> 0x00 on MOSI line while i’m receiving the data. The problem is, 
> there’s just one data register, can I do that? If I can’t, can I 
> change just the MOSI pin to GPIO mode and put on low level while I’m 
> receiving data?

With SPI the transmit and receive register are the same - bits are 
shifted out on transmit as they are shifted in on receive.

So, to keep MOSI low while receiving (and to generate the clock needed 
to drive the whole process), simply write a 0 to the SPDR register. 
Wait for the transfer to complete (checking the SPSR register) and then 
read SPDR to get the received byte.

Shannon

Thanks for the help...My problem was that i didn't wait for SPIF 
while i'm receiving...so stupid!!! But now I'm stuck in the RDY 
signal. I'm supposed to use it as an ExtInt...I did the following 
setup sequence:

EXTMODE = SETBIT1;//Interrupção na borda de descida
PINSEL0 |= 0x000000C0;//P0.3 ajustado para EINT1
VICVectAddr0 =(unsigned long)ADISR; //redireciona vetor para função
VICVectCntl0 = 0x20 | 15; //Seta vetor de interrupção para INT1
VICIntEnable = SETBIT15; //Habilita interrupção INT1

And put the function prototipe:

void ADISR (void) __attribute__ ((interrupt));

I have the rdy signal periodically but the ISR is not called...Did I 
forget 
something?

--- In lpc2000@yahoogroups.com, Shannon Holland <holland@l...> wrote:
> 
> On Jun 7, 2004, at 5:57 AM, Rodrigo wrote:
> 
> > I'm trying to communicate with a AD converter through a SPI 
interface. 
> > In the AD datasheet, it's said that I need to have DIN line 
(from AD) 
> > in low level when it's transmitting. This means that I have
to 
write 
> > 0x00 on MOSI line while i'm receiving the data. The problem
is, 
> > there's just one data register, can I do that? If I
can't, can I 
> > change just the MOSI pin to GPIO mode and put on low level while 
I'm 
> > receiving data?
> 
> With SPI the transmit and receive register are the same - bits are 
> shifted out on transmit as they are shifted in on receive.
> 
> So, to keep MOSI low while receiving (and to generate the clock 
needed 
> to drive the whole process), simply write a 0 to the SPDR 
register. 
> Wait for the transfer to complete (checking the SPSR register) and 
then 

> read SPDR to get the received byte.
> 
> Shannon

At 05:02 PM 6/7/04 +0000, you wrote:
>signal. I'm supposed to use it as an ExtInt...I did the following
>setup sequence:
>
>EXTMODE = SETBIT1;//Interrupção na borda de descida
>PINSEL0 |= 0x000000C0;//P0.3 ajustado para EINT1
>VICVectAddr0 =(unsigned long)ADISR; //redireciona vetor para função
>VICVectCntl0 = 0x20 | 15; //Seta vetor de interrupção para INT1
>VICIntEnable = SETBIT15; //Habilita interrupção INT1
>
>And put the function prototipe:
>
>void ADISR (void) __attribute__ ((interrupt));
>
>I have the rdy signal periodically but the ISR is not called...Did I
>forget
>something?

It doesn't look like you set up the actual interrupt vector anywhere.  You 
have to set up the base level interrupt routine which reads the interrupt 
vector peripheral to get the actual vector.  I believe there is an example 
in the files section.

On a personal preference note, I don't trust compilers to get interrupt 
prologues and epilogues right (been there, been bit multiple times).  I 
always do my own in assembly and if the service routine is more than a few 
instructions I can use a more or less plan vanilla C function to do the 
heavy lifting.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

I'm using  the BlinkIRQ startup example. One line of the file is:

 LDR     PC, [PC, #-0x0FF0]     /* Vector from VicVectAddr */

this is the address 0x18...Well I think that, when a interrupt 
occurs, my program goes to address 0x18, which redirects to the 
address loaded in the VICVectAddr... In the Blink example just the 
VIC and TIMER0 register are adjusted...I'm a begginer with the ARM 
Arquitecture, and I don't have time now to learn ARM or THUMB 
Assembly, maybe after this project I can study more, now I need to 
solve all problems ACAP ( As C As Possible ) :-)

Do I need to change something in startup.s file?

There's an example with 2 interrupt sources in the internet? I need 
to know how to work with interrupt priorities...Not now but soon...



--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 05:02 PM 6/7/04 +0000, you wrote:
> >signal. I'm supposed to use it as an ExtInt...I did the following
> >setup sequence:
> >
> >EXTMODE = SETBIT1;//Interrupção na borda de descida
> >PINSEL0 |= 0x000000C0;//P0.3 ajustado para EINT1
> >VICVectAddr0 =(unsigned long)ADISR; //redireciona vetor para 
função
> >VICVectCntl0 = 0x20 | 15; //Seta vetor de interrupção para INT1
> >VICIntEnable = SETBIT15; //Habilita interrupção INT1
> >
> >And put the function prototipe:
> >
> >void ADISR (void) __attribute__ ((interrupt));
> >
> >I have the rdy signal periodically but the ISR is not 
called...Did I
> >forget
> >something?
> 
> It doesn't look like you set up the actual interrupt vector 
anywhere.  You 
> have to set up the base level interrupt routine which reads the 
interrupt 
> vector peripheral to get the actual vector.  I believe there is an 
example 
> in the files section.
> 
> On a personal preference note, I don't trust compilers to get 
interrupt 
> prologues and epilogues right (been there, been bit multiple 
times).  I 
> always do my own in assembly and if the service routine is more 
than a few 
> instructions I can use a more or less plan vanilla C function to 
do the 
> heavy lifting.
> 
> Robert
> 
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

At 06:17 PM 6/7/04 +0000, you wrote:
>I'm using  the BlinkIRQ startup example. One line of the file is:
>
>  LDR     PC, [PC, #-0x0FF0]     /* Vector from VicVectAddr */

That's what I was referring to.  I just want to verify.  Lets take a closer 
look.


>this is the address 0x18...Well I think that, when a interrupt
>occurs, my program goes to address 0x18, which redirects to the
>address loaded in the VICVectAddr... In the Blink example just the
>VIC and TIMER0 register are adjusted...I'm a begginer with the ARM
>Arquitecture, and I don't have time now to learn ARM or THUMB
>Assembly, maybe after this project I can study more, now I need to
>solve all problems ACAP ( As C As Possible ) :-)

Every time It's bitten me I've found I would have saved much more time 
simply learning a little of the MCU assembly language concerned.  I've 
stopped considering the compilers proprietary interrupt keywords helpful :)


--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
>wrote:
> > At 05:02 PM 6/7/04 +0000, you wrote:
> > >signal. I'm supposed to use it as an ExtInt...I did the following
> > >setup sequence:
> > >

I'm assuming you are using a 2104/5/6?

> > >EXTMODE = SETBIT1;//Interrupção na borda de descida

Two questions.  What's EXTMODE? and What's SETBIT1?

> > >PINSEL0 |= 0x000000C0;//P0.3 ajustado para EINT1

Shouldn't this be something more like

PINSEL0 |= 0x20000000;

I believe you've set P0.3 to a reserved state.

> > >VICVectAddr0 =(unsigned long)ADISR; //redireciona vetor para
>função
> > >VICVectCntl0 = 0x20 | 15; //Seta vetor de interrupção para INT1
> > >VICIntEnable = SETBIT15; //Habilita interrupção INT1

What is SETBIT15? (0x8000 maybe?)

I'd suspect the setting of PINSEL0.

More questions.  How do you know if the external interrupt was responded 
to?  And if it only responded once how likely are you to miss it?

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Sorry for the SETBITS....they are defines. SETBIT1=0x02 and 
SETBIT15=0x8000 (as you said) (try to remember what number have to 
be ORed with your register just to set your 26th bit and you'll see 
that this is very useful)...

I'm using LPC2129.

According to the User Manual bits 7:6 = 11 sets EINT1 for P0.3..so 
we have 0xC0.

EXTMODE is the External Mode Register... Selects if I'll have a 
level or edge sensitive interrupt ( I've set to have an edge 
sensitive).

Well how do I know that I'm receiving the RDY? An osciloscope...:-))

I'm running with a ULINK debugger and according to the simulator, 
the EINT1 bit from EXTINT register is set...this means that 
interrupt flag is set but the routine was not called...

About the assembly and compilers I completely agree with you...I've 
always had problems with PIC compilers ( especially CCS) and thanks 
to my knowledge on PIC assembly language I could solve problems, but 
in this case if I could work in a higher level, better, if not...

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 06:17 PM 6/7/04 +0000, you wrote:
> >I'm using  the BlinkIRQ startup example. One line of the file is:
> >
> >  LDR     PC, [PC, #-0x0FF0]     /* Vector from VicVectAddr */
> 
> That's what I was referring to.  I just want to verify.  Lets take 
a closer 
> look.
> 
> 
> >this is the address 0x18...Well I think that, when a interrupt
> >occurs, my program goes to address 0x18, which redirects to the
> >address loaded in the VICVectAddr... In the Blink example just the
> >VIC and TIMER0 register are adjusted...I'm a begginer with the ARM
> >Arquitecture, and I don't have time now to learn ARM or THUMB
> >Assembly, maybe after this project I can study more, now I need to
> >solve all problems ACAP ( As C As Possible ) :-)
> 
> Every time It's bitten me I've found I would have saved much more 
time 
> simply learning a little of the MCU assembly language concerned.  
I've 
> stopped considering the compilers proprietary interrupt keywords 
helpful :)
> 
> 
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...>
> >wrote:
> > > At 05:02 PM 6/7/04 +0000, you wrote:
> > > >signal. I'm supposed to use it as an ExtInt...I did the 
following
> > > >setup sequence:
> > > >
> 
> I'm assuming you are using a 2104/5/6?
> 
> > > >EXTMODE = SETBIT1;//Interrupção na borda de descida
> 
> Two questions.  What's EXTMODE? and What's SETBIT1?
> 
> > > >PINSEL0 |= 0x000000C0;//P0.3 ajustado para EINT1
> 
> Shouldn't this be something more like
> 
> PINSEL0 |= 0x20000000;
> 
> I believe you've set P0.3 to a reserved state.
> 
> > > >VICVectAddr0 =(unsigned long)ADISR; //redireciona vetor para
> >função
> > > >VICVectCntl0 = 0x20 | 15; //Seta vetor de interrupção para 
INT1
> > > >VICIntEnable = SETBIT15; //Habilita interrupção INT1
> 
> What is SETBIT15? (0x8000 maybe?)
> 
> I'd suspect the setting of PINSEL0.
> 
> More questions.  How do you know if the external interrupt was 
responded 
> to?  And if it only responded once how likely are you to miss it?
> 
> Robert
> 
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

At 07:50 PM 6/7/04 +0000, you wrote:
>Sorry for the SETBITS....they are defines. SETBIT1=0x02 and
>SETBIT15=0x8000 (as you said) (try to remember what number have to
>be ORed with your register just to set your 26th bit and you'll see
>that this is very useful)...

Unless, of course you have to go back to the definition to figure out if 
the bits are numbered starting at 0 or at 1 :)


>I'm using LPC2129.

OK, that explains the EXTMODE and PINSEL numbers.

>Well how do I know that I'm receiving the RDY? An osciloscope...:-))

Actually I was referring to the question of how do you know whether or not 
you have received the interrupt not whether the pin state was set.


>I'm running with a ULINK debugger and according to the simulator,
>the EINT1 bit from EXTINT register is set...this means that
>interrupt flag is set but the routine was not called...

ULINK uses JTAG?

There is a small possibility that an interrupt is occurring before your 
debugger gets control of the micro and it just isn't acknowledged 
correctly.  I'd add a pin toggle in your ISR to allow you to scope 
that.  It sounds more like the IRQs are disabled though.  Check your global 
IRQ flag (I've forgotten where it is on the ARM).


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 04:18 PM 6/7/04 -0400, you wrote:
>Check your global
>IRQ flag (I've forgotten where it is on the ARM).
Program Status register bit 7 (should be clear to enable interrupts), bit 6 
is for FIQs.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hi

Did you solve your problem with ext. ints?

Below is an extract of code which works (assuming defines are 
understood).

Application calls fnEnableOneShotInterrupt() to enable the interrupt 
on a port (LPC2106 example for INT 0).

One thing to note is that the interrupt is level sensitive and so if 
it is being used to detect a button press or something like this, 
the interrupt will keep coming as long as the button is pressed. For 
this reason the interrupt routine in this case sets the normal port 
function so that the interrupt doesn't arrive anymore.
 
Cheers

Mark Butcher
www.mjbc.ch


/**********************************************/

static void fnEnableOneShotInterrupt(void)
{
  __disable_interrupt();      
    LPC210xInitExternalInterrupt0(fnEint0Interrupt);            /* 
prepare interrupt on EINT0 - level sensitive only */
    EXTINT_bit.EINT0 = 1;                                       // 
Try to reset external interrupt flag.    
    LPC210xInitEINT0();                                         /* 
enable the interrupt */
  __enable_interrupt(); 
}




/* ext. sub routines and defines */

#define VIC_EINT0_bit  (1 << VIC_EINT0)


static void (*eint0_function)();

void LPC210xInitExternalInterrupt0(void(*eint0_func)())
{
  // Setup eint0 callback function.
  eint0_function = eint0_func;

  VICIntSelect &= ~VIC_EINT0_bit;  // IRQ on external int 0.
  VICVectAddr2 = (unsigned int)&ExternalInterrupt0;
  VICVectCntl2 = 0x20 | VIC_EINT0; // Enable vector interrupt for 
EINT 0.
  VICIntEnable = VIC_EINT0_bit;    // Enable EINT 0 interrupt.
}



void LPC210xInitEINT0()
{
  PINSEL1_bit.P0_16=0x1; // Set pin function to EINT0
}



/* interrupt routine */
/* when a level 0 is detected on INT 0 - P0.16 this routine is 
called */
/* we disable the interrupt after detection otherwise the routine is 
reentered until a 1 is detected (level sensitive) */
static void ExternalInterrupt0()
{
  PINSEL1_bit.P0_16=0;    // Set pin function to normal 
  (*eint0_function)();    // Call external interrupt callback 
function.
  EXTINT_bit.EINT0 = 1;   // Reset external interrupt flag.   
}

I've found it!!!it was the VICVectAddr...this should be cleared in 
the end of the ISR...I cleared it in after the all the setup code 
and it worked!!! Thanks so much!!! When I grow up I wanna be like 
you man!!!! :-))

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 04:18 PM 6/7/04 -0400, you wrote:
> >Check your global
> >IRQ flag (I've forgotten where it is on the ARM).
> Program Status register bit 7 (should be clear to enable 
interrupts), bit 6 
> is for FIQs.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

Hello,

I use LPC2294 and SPI bus. I'd like to use SSEL PIN as another 
function (EINT2) because all my SPI peripheral don't need SSEL signal.

It seems that i am obligate to select SSEL functionnality on a pin.

My question : is there a method to not use SSEL pin ?

Thanks