This is not really a LPC question, but didn't know where to post it.
Many here are using SPI and I was wondering if anyone has had any
issues with standard protocol with SPI peripherals? In other words, I
am using 3 SPI peripherals on my design, and it appears 2 work the
same, and the other has a few quirks that require me to have different
SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
protocol is not standard and it's according to how the chip
manufacturer wants to receive commands and deliver data. So, I'm also
guessing that it is proper to write different SPI routines if code
space is not a problem. Can someone confirm this? Thanks.
Sutton
SPI protocols - LPC2148
Started by ●September 19, 2007
Reply by ●September 19, 20072007-09-19
Thanks for that answer. Just as I suspected. I do use I2C when
possible, but some peripherals only have a SPI interface.
Sutton
--- In l..., "jcwren" wrote:
>
> Indeed, I've run into a similar problem, although not on LPC buts, but
> PICs (gag...) This is why I despise SPI and much prefer I2C.
>
> My PIC solution is basically the same as you're suggesting. I
> assigned device numbers to each device, and the differing send and
> receive code was called depending on the device number. I had 9
> devices on the bus, 2 of which were different. Devices 0..7 (memory)
> used one SPI send/recv function, devices 8..9 (ADCs) used the other.
>
> SPI is annoying with the having to worry about things like phase and
> polarity. I2C just *works* (well, with the very occasional issue of
> addressing collisions. Happened once when I ran out of port expander
> addresses).
>
> So yes, your problem is not unusual, and your solution is good. And
> with 500K of space, a couple 100 word routines hopefully shouldn't be
> a space problem :)
>
> --jc
>
> --- In l..., "Sutton Mehaffey" wrote:
> >
> > This is not really a LPC question, but didn't know where to post it.
> > Many here are using SPI and I was wondering if anyone has had any
> > issues with standard protocol with SPI peripherals? In other words, I
> > am using 3 SPI peripherals on my design, and it appears 2 work the
> > same, and the other has a few quirks that require me to have different
> > SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> > protocol is not standard and it's according to how the chip
> > manufacturer wants to receive commands and deliver data. So, I'm also
> > guessing that it is proper to write different SPI routines if code
> > space is not a problem. Can someone confirm this? Thanks.
> >
> > Sutton
>
possible, but some peripherals only have a SPI interface.
Sutton
--- In l..., "jcwren" wrote:
>
> Indeed, I've run into a similar problem, although not on LPC buts, but
> PICs (gag...) This is why I despise SPI and much prefer I2C.
>
> My PIC solution is basically the same as you're suggesting. I
> assigned device numbers to each device, and the differing send and
> receive code was called depending on the device number. I had 9
> devices on the bus, 2 of which were different. Devices 0..7 (memory)
> used one SPI send/recv function, devices 8..9 (ADCs) used the other.
>
> SPI is annoying with the having to worry about things like phase and
> polarity. I2C just *works* (well, with the very occasional issue of
> addressing collisions. Happened once when I ran out of port expander
> addresses).
>
> So yes, your problem is not unusual, and your solution is good. And
> with 500K of space, a couple 100 word routines hopefully shouldn't be
> a space problem :)
>
> --jc
>
> --- In l..., "Sutton Mehaffey" wrote:
> >
> > This is not really a LPC question, but didn't know where to post it.
> > Many here are using SPI and I was wondering if anyone has had any
> > issues with standard protocol with SPI peripherals? In other words, I
> > am using 3 SPI peripherals on my design, and it appears 2 work the
> > same, and the other has a few quirks that require me to have different
> > SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> > protocol is not standard and it's according to how the chip
> > manufacturer wants to receive commands and deliver data. So, I'm also
> > guessing that it is proper to write different SPI routines if code
> > space is not a problem. Can someone confirm this? Thanks.
> >
> > Sutton
>
Reply by ●September 19, 20072007-09-19
Indeed, I've run into a similar problem, although not on LPC buts, but
PICs (gag...) This is why I despise SPI and much prefer I2C.
My PIC solution is basically the same as you're suggesting. I
assigned device numbers to each device, and the differing send and
receive code was called depending on the device number. I had 9
devices on the bus, 2 of which were different. Devices 0..7 (memory)
used one SPI send/recv function, devices 8..9 (ADCs) used the other.
SPI is annoying with the having to worry about things like phase and
polarity. I2C just *works* (well, with the very occasional issue of
addressing collisions. Happened once when I ran out of port expander
addresses).
So yes, your problem is not unusual, and your solution is good. And
with 500K of space, a couple 100 word routines hopefully shouldn't be
a space problem :)
--jc
--- In l..., "Sutton Mehaffey" wrote:
>
> This is not really a LPC question, but didn't know where to post it.
> Many here are using SPI and I was wondering if anyone has had any
> issues with standard protocol with SPI peripherals? In other words, I
> am using 3 SPI peripherals on my design, and it appears 2 work the
> same, and the other has a few quirks that require me to have different
> SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> protocol is not standard and it's according to how the chip
> manufacturer wants to receive commands and deliver data. So, I'm also
> guessing that it is proper to write different SPI routines if code
> space is not a problem. Can someone confirm this? Thanks.
>
> Sutton
>
PICs (gag...) This is why I despise SPI and much prefer I2C.
My PIC solution is basically the same as you're suggesting. I
assigned device numbers to each device, and the differing send and
receive code was called depending on the device number. I had 9
devices on the bus, 2 of which were different. Devices 0..7 (memory)
used one SPI send/recv function, devices 8..9 (ADCs) used the other.
SPI is annoying with the having to worry about things like phase and
polarity. I2C just *works* (well, with the very occasional issue of
addressing collisions. Happened once when I ran out of port expander
addresses).
So yes, your problem is not unusual, and your solution is good. And
with 500K of space, a couple 100 word routines hopefully shouldn't be
a space problem :)
--jc
--- In l..., "Sutton Mehaffey" wrote:
>
> This is not really a LPC question, but didn't know where to post it.
> Many here are using SPI and I was wondering if anyone has had any
> issues with standard protocol with SPI peripherals? In other words, I
> am using 3 SPI peripherals on my design, and it appears 2 work the
> same, and the other has a few quirks that require me to have different
> SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> protocol is not standard and it's according to how the chip
> manufacturer wants to receive commands and deliver data. So, I'm also
> guessing that it is proper to write different SPI routines if code
> space is not a problem. Can someone confirm this? Thanks.
>
> Sutton
>
Reply by ●September 19, 20072007-09-19
I2C has a very limited speed (400KHz), some SPIs devices like Atmels
Dataflash may run upto 20Mhz.
--- In l..., "Sutton Mehaffey" wrote:
>
> Thanks for that answer. Just as I suspected. I do use I2C when
> possible, but some peripherals only have a SPI interface.
>
> Sutton
>
> --- In l..., "jcwren" wrote:
> >
> > Indeed, I've run into a similar problem, although not on LPC buts, but
> > PICs (gag...) This is why I despise SPI and much prefer I2C.
> >
> > My PIC solution is basically the same as you're suggesting. I
> > assigned device numbers to each device, and the differing send and
> > receive code was called depending on the device number. I had 9
> > devices on the bus, 2 of which were different. Devices 0..7 (memory)
> > used one SPI send/recv function, devices 8..9 (ADCs) used the other.
> >
> > SPI is annoying with the having to worry about things like phase and
> > polarity. I2C just *works* (well, with the very occasional issue of
> > addressing collisions. Happened once when I ran out of port expander
> > addresses).
> >
> > So yes, your problem is not unusual, and your solution is good. And
> > with 500K of space, a couple 100 word routines hopefully shouldn't be
> > a space problem :)
> >
> > --jc
> >
> > --- In l..., "Sutton Mehaffey" wrote:
> > >
> > > This is not really a LPC question, but didn't know where to post
it.
> > > Many here are using SPI and I was wondering if anyone has had any
> > > issues with standard protocol with SPI peripherals? In other
words, I
> > > am using 3 SPI peripherals on my design, and it appears 2 work the
> > > same, and the other has a few quirks that require me to have
different
> > > SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> > > protocol is not standard and it's according to how the chip
> > > manufacturer wants to receive commands and deliver data. So,
I'm also
> > > guessing that it is proper to write different SPI routines if code
> > > space is not a problem. Can someone confirm this? Thanks.
> > >
> > > Sutton
> > >
>
Dataflash may run upto 20Mhz.
--- In l..., "Sutton Mehaffey" wrote:
>
> Thanks for that answer. Just as I suspected. I do use I2C when
> possible, but some peripherals only have a SPI interface.
>
> Sutton
>
> --- In l..., "jcwren" wrote:
> >
> > Indeed, I've run into a similar problem, although not on LPC buts, but
> > PICs (gag...) This is why I despise SPI and much prefer I2C.
> >
> > My PIC solution is basically the same as you're suggesting. I
> > assigned device numbers to each device, and the differing send and
> > receive code was called depending on the device number. I had 9
> > devices on the bus, 2 of which were different. Devices 0..7 (memory)
> > used one SPI send/recv function, devices 8..9 (ADCs) used the other.
> >
> > SPI is annoying with the having to worry about things like phase and
> > polarity. I2C just *works* (well, with the very occasional issue of
> > addressing collisions. Happened once when I ran out of port expander
> > addresses).
> >
> > So yes, your problem is not unusual, and your solution is good. And
> > with 500K of space, a couple 100 word routines hopefully shouldn't be
> > a space problem :)
> >
> > --jc
> >
> > --- In l..., "Sutton Mehaffey" wrote:
> > >
> > > This is not really a LPC question, but didn't know where to post
it.
> > > Many here are using SPI and I was wondering if anyone has had any
> > > issues with standard protocol with SPI peripherals? In other
words, I
> > > am using 3 SPI peripherals on my design, and it appears 2 work the
> > > same, and the other has a few quirks that require me to have
different
> > > SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
> > > protocol is not standard and it's according to how the chip
> > > manufacturer wants to receive commands and deliver data. So,
I'm also
> > > guessing that it is proper to write different SPI routines if code
> > > space is not a problem. Can someone confirm this? Thanks.
> > >
> > > Sutton
> > >
>
Reply by ●September 19, 20072007-09-19
On 9/19/07, Sutton Mehaffey wrote:
> I'm guessing from this that the SPI
> protocol is not standard and it's according to how the chip
> manufacturer wants to receive commands and deliver data. So, I'm also
> guessing that it is proper to write different SPI routines if code
> space is not a problem. Can someone confirm this? Thanks.
>
SPI is not a real standard. Some MCU vendors even use different
names and say it is SPI compatible.
We use SPI for the communicatation between ARM7 and
24bit sigma-delta ADCs and/or 16bit DACs. The ADC and DAC
SPI routines are quite different. Then we have SPI between ARM7
and an ASIC, which is again different.
Xiaofan
> I'm guessing from this that the SPI
> protocol is not standard and it's according to how the chip
> manufacturer wants to receive commands and deliver data. So, I'm also
> guessing that it is proper to write different SPI routines if code
> space is not a problem. Can someone confirm this? Thanks.
>
SPI is not a real standard. Some MCU vendors even use different
names and say it is SPI compatible.
We use SPI for the communicatation between ARM7 and
24bit sigma-delta ADCs and/or 16bit DACs. The ADC and DAC
SPI routines are quite different. Then we have SPI between ARM7
and an ASIC, which is again different.
Xiaofan
Reply by ●September 19, 20072007-09-19
At 02:04 PM 9/19/2007 +0000, Sutton Mehaffey wrote:
>This is not really a LPC question, but didn't know where to post it.
>Many here are using SPI and I was wondering if anyone has had any
>issues with standard protocol with SPI peripherals? In other words, I
>am using 3 SPI peripherals on my design, and it appears 2 work the
>same, and the other has a few quirks that require me to have different
>SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
>protocol is not standard and it's according to how the chip
>manufacturer wants to receive commands and deliver data. So, I'm also
>guessing that it is proper to write different SPI routines if code
>space is not a problem. Can someone confirm this? Thanks.
Hmm, my experience is that send and receive routines have a lot of
similarity. You do have to make provision for different line
characteristics but that's not much of a step beyond making provision for
separate chip selects.
Mind you there is no standardization but one of SPIs biggest advantages is
its dead bang simplicity.
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
>This is not really a LPC question, but didn't know where to post it.
>Many here are using SPI and I was wondering if anyone has had any
>issues with standard protocol with SPI peripherals? In other words, I
>am using 3 SPI peripherals on my design, and it appears 2 work the
>same, and the other has a few quirks that require me to have different
>SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
>protocol is not standard and it's according to how the chip
>manufacturer wants to receive commands and deliver data. So, I'm also
>guessing that it is proper to write different SPI routines if code
>space is not a problem. Can someone confirm this? Thanks.
Hmm, my experience is that send and receive routines have a lot of
similarity. You do have to make provision for different line
characteristics but that's not much of a step beyond making provision for
separate chip selects.
Mind you there is no standardization but one of SPIs biggest advantages is
its dead bang simplicity.
Robert
Another sign of the end of civilization, our technical magazines are
getting chatty
From an EETimes product descriptions 2006/08/09
".... systems that can sample gobs of inputs simultaneously"
Now just what is the technical definition for gobs again?
http://www.aeolusdevelopment.com/
Reply by ●September 20, 20072007-09-20
Hello,
My SPI code usually has a "port config" call that I pass info on how I
want the port to behave. Things like lsb/msb, CPHA/CPOL and baud rate. I am
using the Crossworks OS so my latest code has a "Open" and "Close" call. On
"Open" call I pass the the info as a struct.
I hope this helps
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Sutton Mehaffey
Sent: Wednesday, September 19, 2007 9:04 AM
To: l...
Subject: [lpc2000] SPI protocols - LPC2148
This is not really a LPC question, but didn't know where to post it.
Many here are using SPI and I was wondering if anyone has had any
issues with standard protocol with SPI peripherals? In other words, I
am using 3 SPI peripherals on my design, and it appears 2 work the
same, and the other has a few quirks that require me to have different
SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
protocol is not standard and it's according to how the chip
manufacturer wants to receive commands and deliver data. So, I'm also
guessing that it is proper to write different SPI routines if code
space is not a problem. Can someone confirm this? Thanks.
Sutton
My SPI code usually has a "port config" call that I pass info on how I
want the port to behave. Things like lsb/msb, CPHA/CPOL and baud rate. I am
using the Crossworks OS so my latest code has a "Open" and "Close" call. On
"Open" call I pass the the info as a struct.
I hope this helps
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Sutton Mehaffey
Sent: Wednesday, September 19, 2007 9:04 AM
To: l...
Subject: [lpc2000] SPI protocols - LPC2148
This is not really a LPC question, but didn't know where to post it.
Many here are using SPI and I was wondering if anyone has had any
issues with standard protocol with SPI peripherals? In other words, I
am using 3 SPI peripherals on my design, and it appears 2 work the
same, and the other has a few quirks that require me to have different
SPI_Send and SPI_Rcv code. I'm guessing from this that the SPI
protocol is not standard and it's according to how the chip
manufacturer wants to receive commands and deliver data. So, I'm also
guessing that it is proper to write different SPI routines if code
space is not a problem. Can someone confirm this? Thanks.
Sutton
