Newsgroup: it.hobby.elettronica.digitale
Titolo: Concentratore seriali

Ciao!
Vediamo se qualcuno ha idee più brillanti delle mie....
Per un progetto il cliente vuole una quantità industriale di seriali 
(asincrone) diciamo che ne servono almeno 8. Uso un modulo Rabbit e ne 
riesco ad avere on-board 4/5 senza problemi.
Queste le uso per le periferiche 'interattive' dove cioè si necessita un 
continuo scambio di dati.
Per le altre (che al 95% riceveranno solo dati da sensori, per eccesso 
diciamo un centinaio di byte ogni 50 ms) avevo pensato a una soluzione 
di questo tipo:
.scelgo un micretto con una seriale e una spi hw
.mi faccio un array di questi micretti realizzando così un bus con l'spi
.ciascuno di essi non fa altro che ricevere i pacchetti seriali, 
aggiungervi un header con il proprio indirizzo e tenerseli buoni in RAM
.la MCU principale a polling (o se ho sufficienti I/O tramite un IRQ) 
cicla i vari micretti e chiede se hanno qualcosa da dire. In caso 
affermativo trasferisce i dati.
.idem per la trasmissione verso i sensori.
Vantaggi:
.soluzione modulare: posso avere n seriali (con n grande a piacere)
.lavoro con seriali hw e avendo a diposizione un bel buffer evito di 
perdere dati (cosa invece probabile con seriali software)
.delego la bassa manovalanza ai micretti invece di fare sudare la Rabbit 
che già deve pensare al fatto suo
Svantaggi:
.ingombro e costo proporzionali a n
.all'aumentare di n, aumenta il jitter con cui riesco a stare dietro a 
tutte le seriali (ma questo non dovrebbe essere un problema dato il tipo 
di applicazione)
Vi sembra una cosa sensata o è da pazzi? :)
Marco / iw2nzm


Ciao, un paio di alternative potrebbero essere:
1) La Maxim fa un MAX3100 (
http://www.maxim-ic.com/quick_view2.cfm/
qv_pk/1731) che è una UART con interfaccia SPI e una FIFO di 8 bytes,
se ti bastano potrebbe sostituire i micretti risparmiandoti il SW
2) Se la tua MCU è master rispetto ai sensori puoi usare un'unica UART
facendoti un multiplexer a porte logiche o con una semplice PLD

 facendoti un multiplexer a porte logiche o con una semplice PLD
In generale lascio che siano i sensori a trasmettere per ridurre il 
'traffico' e perché alcuni non prevedono la modalità a interrogazione.
In caso contrario sarebbe effettivamente comodo un multiplexer hw ma 
l'avevo scartato proprio per non vincolarmi.
Ciao!
Marco / iw2nzm

 Vi sembra una cosa sensata o è da pazzi? :)
Quale deve essere il bit rate massimo?
Se non è eccessivo, ti basta implementare una UART software
che operi simultaneamente su tutti i bit di una porta. In questo
modo gestisci 8 flussi con una sola lettura/scrittura alla porta.
In realtà la velocità di lettura/scrittura dovrebbe essere n volte
il bit rate per evitare errori e sincronizzare in maniera precisa,
ma è fattibile a occhio.
A.D.

 Vi sembra una cosa sensata o è da pazzi? :)
Io in generale tendo a limitare al massimo il numero di dispositivi in
generale, e di dispositivi da programmare in particolare. Nel caso
specifico mi sembra che aggiungeresti inutilmente costi di sviluppo e
problemi in fase di produzione (dover programmare duemila dispositivi per
ogni scheda non fa bene al morale di chi lo deve fare, e quindi non fa bene
ai costi e alla percentuale di fallosità).
Io avrei probabilmente pensato prima a una UART esterna, che in termini di
features e prestazioni con ogni probabilità si mangia il tuo micretto a
colazione (senza offesa :-)). Ad esempio TI ne ha una quadrupla che costa
8-9 euro su digikey:
http://focus.ti.com/docs/prod/folders/print/tl16c754c.html
-- 
emboliaschizoide.splinder.com

 ma è fattibile a occhio.
uhm, interessante! A questo non avevo pensato. Però i flussi sono 
asincroni e a velocità differenti. Dici che si riesce comunque? Non 
capisco cosa intendi per 'sincronizzare in maniera precisa' dal momento 
che di sincrono non c'è nulla :)
Ciao!
Marco / iw2nzm

 
http://focus.ti.com/docs/prod/folders/print/tl16c754c.html
Beh proprio per questo avevo domandato! :)
Ora cominciamo a ragionare... mi sa che mi spulcio un po' il sito della 
TI magari ne trovo anche qualcun altro!
Grazie
Marco / iw2nzm

 Ora cominciamo a ragionare...
questa "octal UART" della Philips? SCC2698B

Vediamo se qualcuno ha idee più brillanti delle mie....
Io in genere preferisco usare componenti di sicura e facile reperibilità, perchè
magari capita di dover fare una riparazione o sostituzione tra 5-10 anni e poi
nascono i casini e magari bisogna impazzire per cercare un componente o rifare
tutto.
Questa è la ragione per cui tralascerei uart strane o cose simili.
Prendi ad esempio un AtTiny2313, ha la SPI e una UARTsola, ma sfruttando i pins
in interrupt di INT0, INT1 e PCINT ti permetterebbe di implementare facilmente
fino a 4 seriali.
Se ne potrebbero fare anche di + giocando con gli interrupt del timer Capture o
dell'analog comparator, ma non esageriamo.
Il problema principale potrebbe essere nella ram di soli 128 bytes da
suddividere tra i sensori, che comunque di solito mandano comunicazioni lunghe
pochi bytes.
Il tutto in un package da 20 pins con un costo di circa 1Euro, e di facile
reperibilità e ricambio anche tra anni.
My 2 cents,
--
ciao
  Stefano

 che di sincrono non c'è nulla :)
Per implementare una UART devi "campionare" i segnali
ad una frequenza abbastanza più alta di quella di
segnalazione, in modo da potere disporre di almeno 4/5
campioni per bit trasmesso. In questo modo puoi scegliere
il campione "di mezzo" ed essere sicuro di interpretare
bene il dato (ed evitare problemi di jitter o tempi di salita).
Ma come fai a capire che un determinato campione si
trova proprio in mezzo al bit trasmesso? Devi riferirti al
bit di start e ai suoi "bordi". Era questa la sincronizzazione
di cui parlavo, e ciascun flusso dovrà avere la sua
piccola macchina a stati software che fa questa
operazione.
Comunque per un progetto simile, anche usare un CPLD
non sarebbe una brutta idea...
A.D.

 non sarebbe una brutta idea...
Vero, ma non le ho mai usate... tutto dipende anche dalla timeline del 
progetto.
Ciao!
Marco / iw2nzm

 reperibilità e ricambio anche tra anni.
Posso comunque permettermi anche un micro con più RAM non è quello il 
problema!
Ora ci penso su
Grazie!
Marco / iw2nzm

 questa "octal UART" della Philips? SCC2698B
Interessante anche questa. Ma credo proprio che mi orienterò su una 
soluzione con una MCU per i vari motivi emersi.
Anche perché la "complessità" di cablaggio e gestione di queste UART 
sono maggiori di una semplice SPI + MCU esterna.
Ciao!
Marco / iw2nzm

modo gestisci 8 flussi con una sola lettura/scrittura alla porta."
Non è difficile, basta solo sincronizzare lo start bit, come spiega in questa
appnote:
http://www.atmel.com/dyn/resources/prod_documents/doc0941.pdf
--
ciao
  Stefano

 appnote:
Seriali software ne ho già implementate (sia sincrone che asincrone) il 
punto era la gestione dei vari flussi, che richiede appunto 
un'indipendenza dei vari sincronismi ottenibile andando sufficentemente 
veloci rispetto al baud-rate più alto.
Ciao!
Marco / iw2nzm

suggerimento di A.D.
Lui suggerisce un'altra cosa e più complessa, il campinamento di tutti i pin a
intervalli 10 volte più rapidi del baud-rate.
Con l'Interrupt che gestisce lo start bit in pratica devi fare 8 campionamenti
del pin ad un intervallo prestabilito = baud rate, non implementare una macchina
a stati che è una cosa più complessa e difficile da realizzare.
Comunque con il Timer 1 che ha due comparatori potresti facilmente seguire
diverse UART software contemporaneamente.
--
ciao
  Stefano

 è una cosa più complessa e difficile da realizzare.
Se hai 8 flussi asincroni grosso modo la quantità di
operazioni che devi fare è la stessa. Anzi, proprio il
fatto di non conoscere la relazione di fase e la
contemporaneità tra i vari flussi ti costringe ad
implementare meccanismi di controllo e timing
abbastanza intricati anche se usi gli interrupt ed un
campionamento al bit time...
A.D.

campionamento al bit time...
Perchè la stessa?
Se io ricevo lo start bit e so che la ricezione è a 9600 baud, mi basta fare il
primo campionamento a 0,104+0,05ms = 150µSec e tutti gli altri a 104µSec
Una cosa abbastanza semplice da implementare con un timer, più semplice di una
gestione che richiede un campionamento ogni 10-15µSec e la determinazione di
tutto quello che vuol dire casa per caso.
Mentre scrivo mi è anche venuto in mente un modo ancora più semplice, cioè usare
l'interrupt in modo che, salvato il valore del timer sullo start bit, dopo ogni
variazione del pin stesso sia possibile determinare a che punto del frame è
avvenuto il cambio di stato.
Nell'esempio precedente basterebbe sapere a quanti multipli di 104µSec è
avvenuta la variazione del bit.
In questo modo con solo 1 timer e diversi piedini di INT si potrebbero gestire
parecchie seriali.
Comunque, tornando al discorso di prima, mentre in un caso lo start bit è un
evento determinato solamente dal fronte di discesa dell'interrupt, nell'altro
caso bisogna distinguere quando il fronte di discesa è un bit o uno start bit,
partire da lì e poi preparare lo shift register.
Oddio, si può fare, ma è abbastanza più incasinato, almeno secondo me.
--
ciao
  Stefano

 wrote:

volendo, con un po di attenzione, si puo fare un elicottero
modificando ad arte una bicicletta.
Io concordo con Dalai Lamah e mi comprerei una multi
UART...............cioe' l'elicottero.
Mi tolgo il cappello, comunque, al cospetto di chi sa far volare la
bicicletta!.
Dai sto solo scherzando, mi piaceva l'idea della bicicletta volante!!!!

 Prendi ad esempio un AtTiny2313 [...]
Ritroviamoci fra dieci o vent'anni e guardiamo se è più facile che tu
riesca a trovare un AtTinyQuelch'è (e relativo programmatore e software di
programmazione che funzioni sui PC di allora) o una qualsiasi UART della TI
o della National. Queste UART sono derivazioni dirette dell'8250, che
trent'anni fa era già sui PC. Poi fate vobis.
-- 
emboliaschizoide.splinder.com

 a 0,104+0,05ms = 150µSec e tutti gli altri a 104µSec
Si, ma che succede se ricevi "contemporaneamente"
dati su due o più canali differenti, sfasati si un intervallo
che non è multiplo del bit time? Se tutte le sorgenti sono
asincrone questa condizione è tutt'altro che improbabile!
A.D.

 ha scritto nel messaggio 
news:ikEvj.20024$FR.1...@twister1.libero.it...

Mi sono trovato nella stessa situazione in un paio di occasioni.
In una, mi servivano 3 seriali oltre alle 2 già diponibili all'interno del 
18f8722 del progetto originale.
Ho risolto con 3 pic collegati in spi (hw), ognuno con la sua usart a bordo 
(hw).
Comunicano la presenza di dati nel buffer tramite un pin (INT).
Ho testato anche i max3100, ma alla fine si tratta sempre di un dispositivo 
spi, con un buffer di soli 8 bytes, e dal costo superiore a quello dei pic 
che ho utilizzato.
Alla fine ciò che ho implementato mi consente le stesse prestazioni, senza 
quarzo esterno (anche se predisposto sul c.s., uso l'oscillatore interno ai 
pic) e con un buffer di 64bytes.
Un insieme di comandi a basso livello mi consente di programmare i parametri 
delle seriali, dimensione del buffer, handshake, e anche procedere 
all'aggiornamento del firmware.
Inoltre ho delegato ad uno di questi pic pure la funzione di gestore di una 
tastiera a matrice, alleggerendo ulteriormente il carico sulla cpu 
principale.
In una altra applicazione basata su rabbit, oltre alle 4 disponibili me ne 
servivano altre 4.
Per questioni economiche non valeva la pena utilizzare un altro rabbit come 
slave, quindi vista la disponibilità di tutti i pin per la gestione completa 
di un bus, ho adottato una uart a 4 canali.
Economicamente parlando, 4 piccoli pic costano meno di una uart 
(considerando anche la complessità del circuito, che con un tqfp o similare, 
ti 'costringe' ad utilizzare un c.s. multistrato).
Sul discorso delle uart emulate via sw, ti consigli odi utilizzarle solo se 
ti sono necessarie porte seriali aggiuntive da utilizzare alternativamente 
tra di loro e quasi solo esclusivamente in trasmissione, altrimenti 
l'esperienza mi spinge a dirti che ti crei solo parecchi problemi.
Io stesso ho una applicazione dove ad una scheda ho collegato un gsm, un 
display remoto via seriale, 3 stampanti di ticket.
Il gsm è sulla porta hw, le altre 4 seriali sono emulate.
Il traffico verso le stampanti ed il display è a bassa velocità (9600), non 
è mai contemporaneo, ed i dati sono praticamente solo in uscita: 
applicazione tipica delle seriai sw.
Roberto P. 

 parecchi problemi.
Ne sto appena uscendo fuori proprio con questo progetto che sostituisce 
il vecchio apparato fatto da un collega che "malfunzionava" proprio a 
causa delle sw uart. Probabilmente dedicanto un micro intero si riesce 
anche a farlo funzionare ma non credo valga la pena rischiare ora.
Poi nel tempo libero sarei curioso di provare a fare un progettino del 
genere, giusto per vedere come va.
Ciao e grazie anche a te!
Marco / iw2nzm



Vero, ma non è necessaria una grande precisione sul tempo di campionamento, in
teoria hai tutti i 104µSec per rilevare il dato (in pratica ovviamente un pò
meno).
La routine che gestisce l'INT, anche se scritta in C, non dovrebbe arrivare ai
10µSec in un AtTiny che può andare a 20Mhz e avere un ciclo di istruzione di 50
nSec (1 µSec =20 cyc).
In questo caso potresti gestire tranquillamente 5 o 6 seriali asincrone in
contemporanea.
Facendo le routine in asm e andando a calibrare il singolo ciclo credo che ne
potresti gestire parecchie contemporaneamente anche a un baud-rate più alto.
Parola di creatore di biciclette volanti...   :-))
 
--
ciao
  Stefano

trent'anni fa era già sui PC. Poi fate vobis.
Proprio la scorsa settimana ho dovuto mandare una scheda di ricambio con su Z80
di un modello prodotto negli anni 80.
Avevamo in magazzino i componenti + critici e gli stampati, e la cosa +
difficile da trovare è stata una ram da 32k in DIP28, considerato fino a oggi
componente non critico. (adesso ne ho 2 stecche in casa)
Credo che anche tra 10 o 20 anni il modo di risolvere il problema di un Tiny2313
lo troveremmo, anche perchè ne usiamo già parecchi in diverse app.
Sulla UART che dici tu, se decidessi di usarla dovrei in ogni caso tenermi una
stecca di scorta, e solo per un'applicazione, anche perche se tra 20 anni ci
sarà ancora e cosa farà la TI o la National non è dato sapere oggi.
Poi naturalmente sono due diverse visioni del problema, entrambe legittime, io
resto della mia idea di usare meno componenti speciali possibile.
--
ciao
  Stefano

 wrote:
........... e solo per un'applicazione..........
questo non ce lo avevi detto.
Ti basterebbe allora  tenerne per scorta un paio di campioni con la
soddisfazione di poter  usare nel futuro  un oggetto con delle
features notevoli (ho guardato solo la Philips).

features notevoli (ho guardato solo la Philips).
Se posso realizzare abbastanza facilmente la stessa funzione con un oggetto
standard ho molta + soddisfazione, credimi.
--
ciao
  Stefano


vero; me ne accorgo solo ora che me lo fai notare.
ciao