Comms Serial in micro PIC

[Buriedcode]

Salve,

Ho cercato il consiglio ma non riesco a trovare una risposta a questa domanda,.E spiace se la sua nel forum sbagliato, ma è 'microcontrollori':

Può la periferica SPI di un micro PIC inviare frame di dati retrospettivi 'to back'.Con questo voglio dire che il PIC è in costante scambio di dati, in modo (supponendo che il PIC è il padrone) il SCK funziona continuamente.O deve essere il 'periodo di riposo' tra i bytes?

Il motivo che mi sto chiedendo, è che voglio inviare circa 3 MB / s di Manchester dati codificati attraverso un collegamento RF.Io sto usando un CPLD, ma un micro PIC (o qualsiasi uC per quella materia) è più interessante poiché ha tante altre funzioni, e la memoria.Attualmente sto cercando di utilizzare la USART, correndo al massimo baud inviando pacchetti back to back con il Manchester byte codificati (4 bit di dati = 8 bits di Manchester), ma, ahimè, il suo solo non è abbastanza veloce.

Ovviamente facendo tutto nel software (sbattendo bit) è praticamente impossibile, a questa velocità, ma con le periferiche microcontrollori offerta, che mi permette di mettere un solo byte in un registro, e l'hardware si prende cura di inviarlo.E poiché SPI è Comms lo scambio di dati, ho potuto leggere i dati da qualche altra parte, allo stesso tempo, come l'invio di esso.

Io non utilizzerà il SCK, voglio solo un modo per inviare i bit seriale ad alta velocità, e sembra che SPI è la mia unica opzione.

Thankyou, e, come sempre, ogni idea, io sono tutto orecchi.

BuriedCode.

 

[bobcat1]

SalveIl registro a scorrimento SPI è limite di dimensione per esempio 8 bit o 16 bit in alcune micro lì devi ricaricare il registro da pacchetto a pacchettoAll the best

Bobi

 

[Buriedcode]

Hi Bobcat1, grazie per la tua risposta.

Ho ancora a fare una prova, ma penso che sia possibile, e come lei ha giustamente sottolineato, devo ricaricare il buffer SSP appena un pacchetto ha finito (anche, leggere il buffer, secondo il microchip).Che sarà dura, soprattutto se io uso un OSC 20Mhz, con un datarate di 2.5Mb / s, ogni 'po' dura due cicli di istruzione.Penso che la periferica SSP ha un buffer, che può caricare durante l'invio di un pacchetto.

Naturalmente, avrei solo dovuto caricare in un nuovo byte ogni 16 istruzioni, ma potrebbe essere necessario aggiornare un byte non appena l'SPI ha terminato l'invio, ancora una volta, entro 2 istruzioni.

Sarebbe magnifico se potessi farlo funzionare.Avere un flusso costante di dati, in MB / s in uscita del PIC, e allo stesso tempo, la lettura in pacchetti da un dispositivo separato (eseguendo la clk SPI).It'll save me un carico di spazio a bordo di una CPLD per la serializzazione / deserializzazione, per non parlare di I / O sul PIC.Ma considerando come 'stretto' il codice sarà, io non avrà tempo per fare qualsiasi funzioni complicate, così ho potuto provare l'opzione CPLD.Poi di nuovo, ecco perché 'tabelle look-up' sono state inventate

<img src="http://www.edaboard.com/images/smiles/icon_biggrin.gif" alt="Very Happy" border="0" />Comunque, grazie ancora, se mi capita di entrare in possesso di un oscilloscopio, posso confermare / negare la fattibilità di questo.

BuriedCode.

 

[bobcat1]

SalveÈ possibile Allway passare alla più veloce, come micro MSP430 che sappiano lavorare in 8 Mips o addirittura

LPC2138 - ARM7 migliore che può fare 50 Mips

Per esempio con il LPC2138 SSP è possibile generare fino a 20Mbit al secondo

All the bestBobi

 

[Buriedcode]

bobcat,

Buona idea!Per quanto io amo PIC, e la loro versatilità, io pobably dovrebbe diramano a micros diversi: AVR, Philips, ecc.E considerando il prezzo di queste cose, non la sua intenzione di rompere la banca

<img src="http://www.edaboard.com/images/smiles/icon_wink.gif" alt="Wink" border="0" />Farò qualche ricerca, nella programmazione, le lingue, e 'l'utilità' rispetto al PIC.E 'stato solo di circa 10 mesi da quando ho iniziato con il micro, e ho sempre scrivere in assemblea.Ma, in avanti e verso l'alto.

Thanks for you help.Una volta che ho intorno ad esso, I'll post alcuni risultati nel forum 'l'elettronica amatoriale'.

BuriedCode.