Problema con SPI (serial pheripheral interface)

Salve a tutti, ho un piccolo problema con la comunicazione tra microcontroller e dispositivi tramite SPI.

Devo comunicare sia in TX che in RX tra un microcontroller e due dispositivi tramite SPI. Uno dei due dispositivi ha una sorta di CS (chip select) per SPI quindi posso abilitare o meno la ricezione e trasmissione dei dati e quindi costruire un bus SPI sul quale collegare più dispositivi.

L'altro chip non ha questa funzione e quindi pensavo di mettere dei buffer 3-state sulle linee della SPI verso questo dispositivo e abilitare i buffer solo quando voglio comunicare con tale dispositivo, mantenendo i buffer nello stato ad alta impedenza quando la comunicazione non è bilitata.

Pensate sia una buona idea o pensate ci siano problemi di capacità parassite, linee flottanti, ecc... quando i buffer sono nell stato ad alta Z?

Come fareste voi?

Grazie per l'aiuto.

Reply to
SBS
Loading thread data ...

SBS ha scritto:

Io proverei...

Ciao

d.

Reply to
drdlk

drdlk (drdlk snipped-for-privacy@tiscali.it) ha scritto:

::: Come fareste voi?

:: Io proverei...

Anziché andare alla cieca, preferisco sentire il parere di qualcuno che magari si è già imbattuto in una situazione analoga.

Reply to
SBS

Il giorno Sat, 2 Dec 2006 15:06:43 +0100, "SBS" ha scritto:

Il problema delle linee flottanti si può risolvere mettendo dei resistori di pullup o pull-down sulle linee dopo il buffer (un 74HC125 va bene).

Il problema principale che vedo in una soluzione del genere è dato dal fatto che bisogna essere sicuri di non muovere mai il segnale del CLK, altrimenti si rischia di perdere il frame e il dispositivo lavora con dati errati.

Oltretutto se il dispositivi non ha nemmeno un CS (cos'è?) non so come si possano riallineare i dati nel caso di un erroresul CLK.

I2C ;-)

-- ciao Stefano

Reply to
SB

"SBS" ha scritto nel messaggio news:457188ae$0$7629$ snipped-for-privacy@reader1.news.tin.it...

1) frequenza ? 2) ti interessano entrambe le line spi-rx e spi-tx per entrambi i dispositivi ? se la risposta è no ci possono essere metodi semplificati.
--
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)

zsimonez.zbernz@zliberoz.it (Rimuovere i caratteri di zorro per rispondere 
via mail)
Reply to
simone.bern

SB ( snipped-for-privacy@tin.it) ha scritto:

:: Oltretutto se il dispositivi non ha nemmeno un CS :: (cos'è?) non so come si possano riallineare i dati :: nel caso di un erroresul CLK.

::: Come fareste voi?

:: I2C ;-)

ST7540, puoi vedere il suo datasheet qui:

formatting link

Io non trovo alcun modo di disabilitare la comunicazione in SPI tramite una sorta di chip select.

Reply to
SBS

simone.bern ( snipped-for-privacy@zliberoz.it) ha scritto:

::: Salve a tutti, ::: ho un piccolo problema con la ::: comunicazione tra microcontroller e dispositivi ::: tramite SPI.

:: 1) frequenza ?

La frequenza la potrei adattare a quella del dispositivo più "lento", su questo non ho problemi. Comunque si parla di trasmissioni lente, nell'ordine dei kHz al max.

:: 2) ti interessano entrambe le line spi-rx e spi-tx per :: entrambi i dispositivi ?

Esatto.

Reply to
SBS

"SBS" ha scritto nel messaggio news:45718d3b$0$7643$ snipped-for-privacy@reader1.news.tin.it...

bah... se il tuo micro è sempre master, senza impazzire con buffer tristate, io metterei due (al limite tre) porte di trasmissione sulle linee SPI verso il chip privo di CS, per pilatarle con un pin dedicato (al limie il pin CS del primo chip negato).

--
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)

zsimonez.zbernz@zliberoz.it (Rimuovere i caratteri di zorro per rispondere 
via mail)
Reply to
simone.bern

simone.bern ( snipped-for-privacy@zliberoz.it) ha scritto:

:: bah... se il tuo micro è sempre master, senza impazzire :: con buffer tristate, io metterei due (al limite tre) porte di :: trasmissione sulle linee SPI verso il chip privo di CS, :: per pilatarle con un pin dedicato (al limie il pin CS del :: primo chip negato).

Mi sembra un'ottima idea, è quello che intendevo fare con i buffer tristate perché non so cosa sono le porte di trasmissione di cui parli. Mi potresti spiegare meglio cosa sono e/o indicarmi un circuito integrato che le realizza?

Reply to
SBS

Il giorno Sat, 2 Dec 2006 15:23:31 +0100, "SBS" ha scritto:

Non puoi, dal momento che sei tu lo slave. Difatti dice (pag.21): "In Synchronous Mode ST7540 is always the master of the communication"

Se hai una UART e non la usi, puoi usare il modo asincrono, altrimenti puoi sempre simulare un SPI via software magari usando un interrupt sul fronte di salita del CLK.

-- ciao Stefano

Reply to
SB

SB ( snipped-for-privacy@tin.it) ha scritto:

::: ST7540, puoi vedere il suo datasheet qui: :::

formatting link
::: ::: Io non trovo alcun modo di disabilitare la comunicazione ::: in SPI tramite una sorta di chip select. :: :: Non puoi, dal momento che sei tu lo slave. Difatti dice :: (pag.21): :: "In Synchronous Mode ST7540 is always the master of the :: communication"

Ti ringrazio molto per avermi segnalato questo particolare così importante, che mi era proprio sfuggito.

:: Se hai una UART e non la usi, puoi usare il modo asincrono, :: altrimenti puoi sempre simulare un SPI via software magari :: usando un interrupt sul fronte di salita del CLK.

Ho una USART a disposizione, che può essere usata anche come UART, ma mi serve per interagire col micro in fase di debug tramite RS-232 con il terminale del PC.

Magari potrei simulare una SPI come giustamente mi suggerisci di fare.

Nella mia applicazione devo attendere una richiesta di dati, che mi arriva dal ST7540, e poi devo rispondere con i dati richiesti.

Dopo che ST7540 mi ha richiesto i dati tramite SPI, potrei usare delle porte di trasmissione per inibire la SPI verso ST7540 e comunicare con l'altro chip.

Dopo aver interrogato l'altro chip e aver ottenuto i dati che mi occorrono, potrei di nuovo abilitare la trasmissione SPI con ST7540 (abilitando le porte di trasmissione) e inviare i dati chie mi aveva precedentemente richiesto.

E' fattibile questo procedimento, oppure il clock della SPI tra ST7540 e micro deve esser obbligatoriamente presente anche quando non vi è trasmissione dati tra i due dispositivi?

Reply to
SBS

"SBS" ha scritto nel messaggio news:45718ffe$0$7626$ snipped-for-privacy@reader1.news.tin.it...

roba tipo questa:

formatting link

non so se, dopo la nota di Stefano, l'idea vada riconsiderata.

--
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)

zsimonez.zbernz@zliberoz.it (Rimuovere i caratteri di zorro per rispondere 
via mail)
Reply to
simone.bern

Il giorno Sat, 2 Dec 2006 16:16:14 +0100, "SBS" ha scritto:

Allora non puoi usarla

No, non puoi, primo perchè sei lo slave, secondo perchè quella non è una SPI classica, ma un'altra cosa. Infatti se guardi la fig.8 a pag 21 ti fa vedere un segnale chiamato RxTx che influenza la direzione dei dati.

Questo significa che ti devi fare una gestione software della comunicazione e usare i pin Rxd e Txd insieme a RxTx e Clr_T.

Una SPI standard usa solo 3 pins MISO MOSI e SCK, quella del ST7540 difatti viene chiamata comunicazione sincrona, che significa con un segnale di clock o sincronismo, non una SPI standard.

No, devi fare come ti ho scritto sopra e soprattutto leggere attentamente il datasheet. Leggere la documentazione più volte finchè non ti è tutto chiaro può sembrare tempo perso, poi quando le cose non funzionano di tempo ne perdi molto di più per farle andare.

-- ciao Stefano

Reply to
SB

simone.bern ( snipped-for-privacy@zliberoz.it) ha scritto:

:: roba tipo questa: ::

formatting link

Grazie ;-)

:: non so se, dopo la nota di Stefano, l'idea vada riconsiderata.

Se si potesse fare un mix di entrambe le soluzioni sarebbe la scelta a mio avviso ottimale.

Reply to
SBS

SB ( snipped-for-privacy@tin.it) ha scritto:

::: Dopo che ST7540 mi ha richiesto i dati tramite SPI, potrei ::: usare delle porte di trasmissione per inibire la SPI verso ::: ST7540 e comunicare con l'altro chip.

:: No, non puoi, primo perchè sei lo slave, secondo perchè :: quella non è una SPI classica, ma un'altra cosa. :: Infatti se guardi la fig.8 a pag 21 ti fa vedere un segnale :: chiamato RxTx che influenza la direzione dei dati. :: :: Questo significa che ti devi fare una gestione software della :: comunicazione e usare i pin Rxd e Txd insieme a RxTx e :: Clr_T.

RxTx è semplicemente un segnale che dice al ST7540 se voglio trasmettere i dati sulla powerline o li voglio ricevere dalla stessa (vedi pag. 5).

Da quanto ho capito, la SPI offre una comunicazione full duplex poiché ha il clock e le due linee TX e RX. In questo caso non è possibile farlo poiché il canale di trasmissione (la linea elettrica) consente comunicazione half duplex. Ecco spiegata, a mio avviso, la presenza di quel ulteriore pin RxTx che va gestita dal micro.

In definitiva il ST7540 è master in maniera fittizia perché in realtà è il micro a decidere la direzione (Rx o Tx) della comunicazione, che ne pensi?

Magari possiamo dire che ST7540 è master perché scandisce il clock della trasmissione...

:: Una SPI standard usa solo 3 pins MISO MOSI e SCK, quella :: del ST7540 difatti viene chiamata comunicazione sincrona, :: che significa con un segnale di clock o sincronismo, non una :: SPI standard.

Se il segnale di clk in questo caso è CLR_T da dove ne deduco la frequenza (non la trovo sul datasheet)?

:: No, devi fare come ti ho scritto sopra e soprattutto leggere :: attentamente il datasheet. :: Leggere la documentazione più volte finchè non ti è tutto :: chiaro può sembrare tempo perso, poi quando le cose non :: funzionano di tempo ne perdi molto di più per farle andare.

Ti ringrazio per l'interessamento e per i consigli, sei stato molto chiaro nelle spiegazioni. Leggerò attentamente il datasheet più e più volte come mi hai consigliato.

L'applicazione che devo sviluppare prevede la ricezione di dati dalla linea tramite ST7540 verso il micro. Poi dalla linea elettrica si attende la risposta del micro e non vi è trasmissione ulteriore di dati. Il micro acquisisce i dati da altro dispositivo tramite SPI e li invia al ST7540.

Ecco perché mi serve poter comunicare in SPI con due dispositivi. L'altro dispositivo prevede l'inibizione della SPI tramite CS, quindi non mi da problemi.

Io uso un ATmega8 della atmel, pertanto dispongo di una USART e di una SPI: come ti ho detto l'USART mi serve per il debug e di SPI ne ho una sola.

Se una volta ricevuto il dato dal ST7540 tramite SPI, tengo il micro in modo ricezione RxTx = 1, posso in qualche modo usare la stessa SPI (magari con aggiunta di hardware esterno: porte o buffer 3state) per comunicare con l'altro dispositivo in SPI?

Reply to
SBS

Il giorno Sat, 2 Dec 2006 17:35:25 +0100, "SBS" ha scritto:

Si, ho visto, ma serve anche a leggere i dati con REG_DATA

Può essere una spiegazione.

Penso che la ST poteva anche usare una SPI in modo normale, invece di incasinare così le cose :=(

Infatti non capisco perchè lo debba scandire lui...

A pag.14 (mi tocca studiarmi anche questo datasheet, ma non è un male, magari un giorno mi servirà) dice:

CLR/T vs. REG_DATAor RxTx | see Figures 8, 9, 10, 11 12 | TB/4

Quindi dipende dal baud-rate...

Si, ma dal momento che sei lo slave non puoi usare la stessa porta salvo fare accrocchi con dei 3 state, una soluzione + pulita è usare dei fili solo per lui e gestire la SPI via software.

Farne una Sw non è difficile, leggi qui:

formatting link

formatting link

anche se questa è una SPI master, ci vuole poco per fare una slave.

Il Mega8 è un ottimo micro, ma è un pò carente riguardo agli strumenti di debug.

Ad esempio un Mega16 ha il supporto JTAG e con AvrStudio4 è un altro mondo.

Se devi debuggare un applicazione puoi vedere sul PC i registri, la ram, mettere dei breakpoint sui passi di programma e persino sui valori di ram con diverse opzioni ulteriori. Se usi il C puoi anche fare il single step delle istruzioni e mettere dei break sulle label. (con WinAvr e GCC)

Una cosa che ho già fatto è sviluppare il programma su un Mega32 per usare il JTAG e poi una volta che ha funzionato ho ricompilato per il Mega8, poi usato per la produzione.

Secondo me è meno complicato fare una SPI software, ma sei tu il progettista, quindi devi decidere tu la strada giusta.

-- ciao Stefano

Reply to
SB

SB ( snipped-for-privacy@tin.it) ha scritto:

:: Farne una Sw non è difficile, leggi qui: :: ::

formatting link
:: ::
formatting link
:: :: anche se questa è una SPI master, ci vuole poco per :: fare una slave.

Ti ringrazio, magari la prenderò in considerazione per la mia applicazione.

:: Il Mega8 è un ottimo micro, ma è un pò carente :: riguardo agli strumenti di debug. :: :: Ad esempio un Mega16 ha il supporto JTAG e :: con AvrStudio4 è un altro mondo.

Vorrei capire un po' di più su questa interfaccia JTAG che senso spesso menzionare.... Hai qualche riferimento sicuro su cui studiare, tu che già ci lavori?

:: Secondo me è meno complicato fare una SPI software, :: ma sei tu il progettista, quindi devi decidere tu la strada :: giusta.

Penso che potrei tenere la SPI del micro per interagire con ST7540 e fare una SPI software in master per interrogare il secondo integrato. Che ne pensi?

Reply to
SBS

Il giorno Sat, 2 Dec 2006 19:53:22 +0100, "SBS" ha scritto:

Qui dice qualcosa su un emulatore JTAG:

formatting link

Io uso questa:

formatting link

Ha la USB, con il vantaggio che quando devi caricare il prog di un Mega128 ci mette 2 secondi. Ce ne sono altre + econimiche, ad esempio questa della Olimex:

formatting link
che trovi sotto AVR >> EMULATORS

Tale interfaccia è anche possibile autocostruirsela: (non garantisco, mi sono solo segnato il link)

formatting link

AVRStudio4 lo trovi qui free:

formatting link

Per gli AVR si trova gratuitamente sia l'assembler che il compliatore C GNU-GCC con il debugger WinAVR.

formatting link

Poi se giri su

formatting link
trovi molte info e progetti già fatti, chi usa gli AVR non può ignorare quel sito.

E' una soluzione, ma può avere controindicazioni. Ad esempio se usi Ponyprog e la SPI per upgradare il software, il fatto che il CLK sia un uscita su lST7540 è un problema.

Ma cos'è che ti spaventa nella SPI software? Non è altro che uno shift di 8 bits in un registro, da fare in sincrono con il fronte di salita del CLK.

Esempio: (la scrivo adesso in 10 secondi, è una routine non provata solo per darti uno spunto)

RecByteSPI: Ldi R16,0x80 ; Ultimo bit a 1 Loop: Sbis PinD,Clk Rjmp Loop Clc Sbic PinD,Data Sec Rol R16 ;C>b7 b0>C Brcc Loop Ret

Sono 9 istruzioni compreso il Ret.

E' meglio usare l'interrupt invece che il poilling, ma deve fare solo questo.

-- ciao Stefano

Reply to
SB

SB ( snipped-for-privacy@tin.it) ha scritto:

:: Esempio: (la scrivo adesso in 10 secondi, è una routine :: non provata solo per darti uno spunto) :: :: RecByteSPI: :: Ldi R16,0x80 ; Ultimo bit a 1 :: Loop: Sbis PinD,Clk :: Rjmp Loop :: Clc :: Sbic PinD,Data :: Sec :: Rol R16 ;C>b7 b0>C :: Brcc Loop :: Ret :: :: Sono 9 istruzioni compreso il Ret.

Ti ringrazio molto anche se non conosco bene questo assembler. Ci guarderò meglio con più calma.

Reply to
SBS

Il giorno Thu, 7 Dec 2006 20:55:29 +0100, "SBS" ha scritto:

Se vuoi la posso scrivere in C, ma non viene di sicuro una cosa così corta e compatta, l'assembler in fondo ha un suo fascino.

-- ciao Stefano

Reply to
SB

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.