>Original Message:
>-----------------
>From: derbaier
>>--- In l..., "subscriptions@..."
wrote:
>>>
>>>
>>>
>>>From: derbaier
>>>
>>>But the LPC2119 does toggle slave select every 8 bits, which indicates
>>>to me that it's internal state machine is resetting regardless of what
>>>the peripheral is doing?
>>
>> If that's the case it's broken. Don't use the automatic slave select.
If
>> it toggles every word it will work with only a small number of slave
>> devices.
>
>Isn't that what this thread is all about???

I didn't think so. I thought there was an injunction to check the chip
select early on. We seem to have wandered off into the weeds on it but I
thought the main thread had already dealt with it, as in chipselct was oon
and stayed on through the transaction.

Robert
--------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ . Start a New Thread

irafalovsky wrote:

> In our code, we make chipselect using a separate pin, LPC2119
> requires SPI SSEL pin to be high if MCU is in master mode, therefore
> we connected it to VDD, as per user manual.
>
> I will ask the engineer who used && operand there for his reasoning,
> I think it wasn't a typo...
>

"&&" is a logical AND, while "&" is a boolean AND.

TomW
>
> --- In lpc2000@yahoogroups .com ,
> "tirfec" wrote:
> >
> > Perhaps it was a typo but the line where you wait for the sensor
> to
> > signal that data is ready...
> >
> > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> >
> > has an extra & in the masking of IOPIN0. Don't you really mean...
> >
> > while(!(IOPIN0 & (1 << 22))){;;} // Wait for Data Ready
> >
> > The first line will only take the while() path once because
> (1<<22)
> > will always evaluate (and thus the ! of the whole statement will
> make
> > it leave the loop) to true and it won't ever matter what the read
> > of IOPIN0 is. This seems like it may be consistent with your
> failure
> > since the sensor is probably never ready when you start asking it
> for
> > the data (i.e doing you SPI reads).
> >
> > Try Alan's example code with this correction and maybe things will
> > start working..assuming you've configured the peripheral properly
> etc.
> >
> > Also, someone made the point about the SSEL1 toggling after every
> > byte. This may cause problems with the sensor which probably
> expects
> > the chip select to stay low through all 16 clocks for the data. So
> > unless you are manually controlling another GPIO for the chip
> > select...be aware of that behaviour on SSEL1.
> >
> > Hope this helps.
> >
> > Best regards,
> > Ryan.
> >
> > --- In lpc2000@yahoogroups .com ,
> "Alan Strickland"
> > wrote:
> > >
> > > To clear the SPIF bit in S1SPSR you have to access the S1SPSR
> then
> > > access the S1SPDR (ie read or write to it). You also have to
> shift
> > > out a byte to receive one, and wait for the SPI status to
> indicate
> > > SPIF before the received byte can be read.
> > >
> > > I use interrupts, so I can't speak to how well polling the SPI
> > status
> > > register works. This code is also ignoring any errors that the
> SPI
> > > may be setting as well.
> > >
> > > Try something along these lines:
> > >
> > > S1SPDR = 0x41; // Send Measure X command
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > temp = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > >
> > > S1SPDR = 0;.
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > MM3_HB = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > S1SPDR = 0;
> > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > MM3_LB = S1SPDR; // Clears SPIF in S1SPSR.
> > >
> > > wMM3_X = MM3_HB;
> > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> > >
> > > --- In lpc2000@yahoogroups .com
> , "irafalovsky" wrote:
> > > >
> > > > If we attempt to send 2 bytes after peripheral indicates
> > available
> > > > data, we simply get zeroes in return...
> > > >
> > > > Here's what code looks like:
> > > >
> > > > IOSET0 |= 1 << 23; // Set RESET HIGH, this is to reset the
> MM3
> > > > delay(10);
> > > > IOCLR0 |= 1 << 23; // Set RESET LOW, pulse formed
> > > > delay(10);
> > > > S1SPDR = 0x41; // Send Measure X command
> > > > while((S1SPSR & 0x80)!= 0x80){;;} // Wait for SPI status
> > > > while(!(IOPIN0 && (1 << 22))){;;} // Wait for Data Ready
> > > > S1SPDR = 0;
> > > > S1SPDR = 0;
> > > > MM3_HB = S1SPDR;
> > > > MM3_LB = S1SPDR;
> > > > wMM3_X = MM3_HB;
> > > > wMM3_X = (wMM3_X << 8) | MM3_LB;
> > > >
> > > >
> > > > >
> > > > > Do you send 2 bytes out from LPC2119 to allow the SPI clock
> to
> > go so
> > > > > you can get back the 2 bytes that you are expecting?
> > > > >
> > > > > We have an application with LPC2138 running in slave mode and
> > > > > receiving packets of 9 bits characters from an host
> processor
> > and
> > > > > responding with packets of 9 bits characters.
> > > > > Naturally, in order to be able to send back the answer the
> LPC
> > must
> > > > > receive the spi clock from the master so the host processor
> > must pump
> > > > > out dummy characters to allow the answer to come back.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Carlo Barbaro
> > > > >
> > > >
> > >
> >

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

I wanted to thank everybody for help and advice! We finally got
everything working well between the MicroMag3 and LPC2119 using
SPI0/SPI1. The problem was with the sensor itself and PNI Corp has
replaced it with working one.

As to the multiple byte transfers on SPI in LPC2119, it works as
expected and demonstrated in code samples in this thread.

--- In l..., wrote:
>
> I was never able to get the SPI engine to send 16 bits. I ended up
writing my own code to do it by GPIO.
> I don't believe the LPC SPI engines can do anything but 8 bit data
word size.
>
> Chris. Start a New Thread