Lpc2000

May I reply that asynchronous serial comms has just the same problem and DTR
and CTS etc need not be used. Although asynch USARTs  have overclock per bit
space its all a matter of degree.
Why should there be an extra clock pulse ? Equally probable the framing
might be mistimed ?? Is framing error generated from SSELn ? It states
clearly SSELn is used as chip select.
In the deisgn Im implementing now the PLD collects the multitude of SPI
inputs from slaves and alligns them WRT the stop and start bits - and CRC if
needed. These framed bit streams are then just chugged out with SPI clk.
I just love the Altera Quartus dev system...it really fits in with the I/O
expansion philosophy for MCUs. Better than a mechano set.

So whether you are operating as a slave or not the spi clk edge of whatever
polarity you set up is when the first data bit moves to the master.
Whats the big deal guys ? If you send a sycnh char every so often or use
multibyte CRC you have belt and braces ... no ?

Maybe it depends how desperate you are Herbert.

Rgds
DonW

----- Original Message ----- 
From: "ian.scanlon" <scanlon.design@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, April 27, 2006 1:02 AM
Subject: [lpc2000] Re: SPI Slave / SSEL0 using as GPIO ?


> --- In lpc2000@yahoogroups.com, "Don Williams" <donw@...> wrote:
> >
> > Herbert,
> > Hi There,
> > I do not believe the last advice you received is correct. When SPI
> is set
> > for "Master" the table 108 in UM for LPC2138 states  clearly that
> SSEL0 can
> > be used as a GPIO pin. Also I read its OK to use the clock edges
> which start
> > during a master transfer when set for either polarity to determine
> start and
> > end of transfer. I'm using a MAXII pld and simply writing out to a
> decoder
> > function in the PLD and generating my own SSEL0 for slave select -
> which is
> > what I understand the SSEL0 line to be used for.
> >
> > However for us pin use concious scavengers the next question is why
> cant we
> > use the MISO as GPIO if we are only using MISI ??
> > Im not game to try that one.
> > This is design only - havent debugged that bit yet.
> >
> > So if anyone states the data is incorrect please inform........
> >
> > Rgds
> > DonW
> >
>
> I think the original question concerned ssel pin when the LPC part is
> used as a slave. I don't think it is an issue of using pins that are
> not required by the application but which pins are needed.  I guess
> it would be possible to send data without any framing but I wouldn't
> want to rely on it.  How do you recover from a lost or extra clock
> pulse?
>
> Regards,
> Ian
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>