Forums

SPI : Freescale vs Microchip compatibility ?

Started by Unknown March 7, 2007
Hi guys,

I would like to know if the SPI ports are fully
compatible between Freescale and Microchip  ?

I understand that SPI has become a "de facto" standard
in the industry. The serial signals goes up to 10 Mbps,
which is enough for my app, and saves data/control buses.
Am I wrong to assume that SPI is always implemented
the same way, and fully compatible between any chip ?

I think of a Freescale HC12 MCU (MC9S12DP256) with a
Microchip ENC28J60 Ethernet controller that has a SPI port.
That would be nice if I could link those chips together thru
their SPI, but are the SPI signals really fully compatible ?

The question here is not about signal levels ( voltage, etc, that
could be fixed easily ) but about the SI, SO, SCK, ... signals.

please reply to newsgroup
T.I.A

5.d@free.fr wrote:
> Hi guys, > > I would like to know if the SPI ports are fully > compatible between Freescale and Microchip ? > > I understand that SPI has become a "de facto" standard > in the industry. The serial signals goes up to 10 Mbps, > which is enough for my app, and saves data/control buses. > Am I wrong to assume that SPI is always implemented > the same way, and fully compatible between any chip ? > > I think of a Freescale HC12 MCU (MC9S12DP256) with a > Microchip ENC28J60 Ethernet controller that has a SPI port. > That would be nice if I could link those chips together thru > their SPI, but are the SPI signals really fully compatible ? > > The question here is not about signal levels ( voltage, etc, that > could be fixed easily ) but about the SI, SO, SCK, ... signals.
I'm no expert, but AFAIK the PIC SPI module has enough configurability to mate to any other SPI type device. IIRC, they give you all four combinations of clock polarity and clock edge.
> I understand that SPI has become a "de facto" standard > in the industry. The serial signals goes up to 10 Mbps, > which is enough for my app, and saves data/control buses. > Am I wrong to assume that SPI is always implemented > the same way, and fully compatible between any chip ?
Sometimes you can have settings that are not available on all chip. For example, the clock configuration, some chip does not support a configuration like: data transmit on rising edges/reading on falling edges AND default clock level to high. So be sure, that you can have compatible settings (if your settings are not too exotic it will be ok in most cases). Main settings are often : - clock levels/edges (up to four different configurations) - MSB position - baudrate - default output level - etc. Check that you can configure your SPI in the right modes. I think that Freescale SPI have the most common settings available and I do not think that your Microchip ethernet controller SPI port has an exotic configuration. -- Guillaume Chevillot
On Wed, 7 Mar 2007 07:29:18 -0600, the renowned "Anthony Fremont"
<spam-not@nowhere.com> wrote:

>5.d@free.fr wrote: >> Hi guys, >> >> I would like to know if the SPI ports are fully >> compatible between Freescale and Microchip ? >> >> I understand that SPI has become a "de facto" standard >> in the industry. The serial signals goes up to 10 Mbps, >> which is enough for my app, and saves data/control buses. >> Am I wrong to assume that SPI is always implemented >> the same way, and fully compatible between any chip ? >> >> I think of a Freescale HC12 MCU (MC9S12DP256) with a >> Microchip ENC28J60 Ethernet controller that has a SPI port. >> That would be nice if I could link those chips together thru >> their SPI, but are the SPI signals really fully compatible ? >> >> The question here is not about signal levels ( voltage, etc, that >> could be fixed easily ) but about the SI, SO, SCK, ... signals. > >I'm no expert, but AFAIK the PIC SPI module has enough configurability to >mate to any other SPI type device. IIRC, they give you all four >combinations of clock polarity and clock edge.
Slave mode on the PIC may not be so compatible. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Spehro Pefhany wrote:
> On Wed, 7 Mar 2007 07:29:18 -0600, the renowned "Anthony Fremont" > <spam-not@nowhere.com> wrote: > >> 5.d@free.fr wrote: >>> Hi guys, >>> >>> I would like to know if the SPI ports are fully >>> compatible between Freescale and Microchip ? >>> >>> I understand that SPI has become a "de facto" standard >>> in the industry. The serial signals goes up to 10 Mbps, >>> which is enough for my app, and saves data/control buses. >>> Am I wrong to assume that SPI is always implemented >>> the same way, and fully compatible between any chip ? >>> >>> I think of a Freescale HC12 MCU (MC9S12DP256) with a >>> Microchip ENC28J60 Ethernet controller that has a SPI port. >>> That would be nice if I could link those chips together thru >>> their SPI, but are the SPI signals really fully compatible ? >>> >>> The question here is not about signal levels ( voltage, etc, that >>> could be fixed easily ) but about the SI, SO, SCK, ... signals. >> >> I'm no expert, but AFAIK the PIC SPI module has enough >> configurability to mate to any other SPI type device. IIRC, they >> give you all four combinations of clock polarity and clock edge. > > Slave mode on the PIC may not be so compatible.
Thanks, I didn't know that. Now that I've reread the original post, I see that he wasn't even talking about PICs, oops. :-)
>Slave mode on the PIC may not be so compatible.
Slave mode on ANY microcontroller is generally a pain. That is especially true if you want to have the starting byte(s) determine the format of the remainder of the message as so many hardware based SPI devices do. If the clock rates are slow, it's no problem. But generally, most SPI clock rates are high enough to make slave implementation a pain. Lou
On 3=D4=C27=C8=D5, =CF=C2=CE=E78=CA=B130=B7=D6, 5...@free.fr wrote:
> Hi guys, > > I would like to know if the SPI ports are fully > compatible between Freescale and Microchip ? > > I understand that SPI has become a "de facto" standard > in the industry. The serial signals goes up to 10 Mbps, > which is enough for my app, and saves data/control buses. > Am I wrong to assume that SPI is always implemented > the same way, and fully compatible between any chip ? > > I think of a Freescale HC12 MCU (MC9S12DP256) with a > Microchip ENC28J60 Ethernet controller that has a SPI port. > That would be nice if I could link those chips together thru > their SPI, but are the SPI signals really fully compatible ? > > The question here is not about signal levels ( voltage, etc, that > could be fixed easily ) but about the SI, SO, SCK, ... signals. > > please reply to newsgroup > T.I.A
there are some way set the port. in PIC,it has SI,SO,SCK,SI is date in. SO is date out, SCK is clock signal. but in same other chip the call the ports MISO,MOSI,SCK. the MISO port is data in if it do master work and data out when be the slave one. MOSI data out when master and date in when slave.SCK is clock signal too. so when you use SPI ,you should look the datasheet and connect them correct.
5.d@free.fr wrote:

> Hi guys, > > I would like to know if the SPI ports are fully > compatible between Freescale and Microchip ? > > I understand that SPI has become a "de facto" standard > in the industry. The serial signals goes up to 10 Mbps, > which is enough for my app, and saves data/control buses. > Am I wrong to assume that SPI is always implemented > the same way, and fully compatible between any chip ? > > I think of a Freescale HC12 MCU (MC9S12DP256) with a > Microchip ENC28J60 Ethernet controller that has a SPI port. > That would be nice if I could link those chips together thru > their SPI, but are the SPI signals really fully compatible ? > > The question here is not about signal levels ( voltage, etc, that > could be fixed easily ) but about the SI, SO, SCK, ... signals. >
The problem with SPI may be the missing buffers on slave devices. At full speed, meaning clock div 1, there are just 8 clockcycles for a new byte. This usually means there cannot be another interrupt. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net