Pic Rs232

Originalmente inviato da FaPIC

Gia'...hai capito quello che voglio fare.
Leggendo in rete, ho visto che non e' possibile connettere direttamente il piedino Rx della porta seriale al pic, visto che uno e' un segnale +-13V, mentre l'altro e' un segnale TTL. Per risolvere il problema, devo utilizzare un convertitore...in rete ho letto del MAX232, confermi?
A questo punto, cercando di pensare a una prematura lista della spesa, mi dovrei procurare: 1 MAX232 per ogni entrata, 1 pic 16F628 e 1MAX232 per l'uscita elaborata. corretto?
Per quanto riguarda invece la programmazione del 16F628, devo necessariamente comprarmi un programmatore, o e' comuqnue effettuabile utilizzando una particolare entrata del 16F628, magari settando qualcosa di particolare? Nel qual caso, potrei pensare a una ulteriore porta rs232 utile solo a provvedere alla programmazione del PIC.

Altra domanda...e' molto probabile che abbia necessita' di conservare in memoria i dati letti da una periferica, in attesa che i dati delle altre periferiche arrivino. Essendo dati NMEA, in formato ASCII, potrei ritrovarmi ad avere problemi nella gestione della memoria?

Grazie ancora.

Il max232 ha internamente 2 porte TX in ingresso e 2 RX in uscita,
per il tuo scopo,essendo le 5 porte che devi configurare 3 in ingresso e 2 in uscita puoi usare un max232 ed un piccolo convertitore per la terza
in ingresso composta da un transistor,un diodo ed alcune resistenze.
Con questo sistema inverti anche il segnale,quelli del MAX gli trovi già invertiti.
Per quanto riguarda la possibilità di usare un serie 16 anche piccolo
non vedo il problema. Io,se lo ho proposto vuol dire che lo sò che si può fare.
(lo ho già fatto per altri scopi)
Ovvio che non prendendo gli esempi in rete,fatti per gestirne una ma creandosi il software di sana pianta. Credo che voi vi riferiate ad esempi
usanti routine che aspettano di leggere tutto il Byte ma
non è l'unico modo per leggere dei dati seriali.
Certo se parlate di comunicare a 115KBaud è un'altro discorso
ma in Assembler non c'è alcun problema per leggere 3 porte e scriverne 2 contemporaneamente,certo la limitazione non è nel Pic ma nel programmatore.
(senza offesa per nessuno)
un segnale RS232,come detto prima esempio a 4800 Baud propone
un cambiamento di stato ogni 208uS che sono 208 istruzioni
(da 1 ciclo) a 4Mhz
e ne bastano una manciata per leggere lo stato di un pin,poi se uno vuole
tenere fermo la MCU aspettando il passaggio di 10 Bit può farlo,
di solito si fà quando si usa una sola seriale ma programmando
a scansione in quel tempo ci stà molto tempo per fare altre cose e
pure per controllare se ci sono altri dati in arrivo sulle altre seriali.
certo bisogna conoscere l'Assembler e saperlo usare bene ed è per
questo che ho proposto una piattaforma multiprocessore programmando in Basic,diventa molto facile anche senza esperienza visto il livello di astrazione.
Però mi è venuto in mente che puoi usare (senza trasferire in I2C)
sempre la seriale creandoti un "tuo" protocollo :
ogni pic piccolo (uno per porta in ingresso per un totale di 3)
legge,aspettando i dati in ingresso l'Rs232 e memorizza in ram
le stringhe (per il GPS bisogna calcolare di avere abbastanza Ram
ma ci sono modelli adatti)
dedichi un pin di questo Pic a ricevere un segnale di richiesta
che gli viene inviato dalla MCU principale.
La MCU principale,quando pronta porta alta l'uscita che và a questo pin
ed aspetta gli venga inviata la stringa poi và a fare lo stesso con le altre 2 MCU e tratta i dati ricevuti,gli invia al pilota automatico e ritorna a leggere.
Le MCU usate come interfaccia controllano
la richiesta della MCU principale dopo aver ricevuto tutta la stringa...
ovvio che deve esserci un tempo massimo per cui se le periferiche non trasmettono la Master passa avanti...
Questo è facilmente implementabile in Basic e ti permette
di trattare il dato sulle mcu secondarie esempio del GPS
ti interessano le coordinate e ci levi tutto il resto...
spero di essemi spiegato,se quello che vuoi è avere velocemente risultati
ti consiglio di andare avanti su questa strada ma le strade possono essere 1000!!!
Se vuoi approfondire l'Assembler...ci vuole il tempo necessario
ed impegno,non fermarti però agli esempi in rete,
saper sfruttare un pezzo di codice già fatto non vuol dire saper programmare!
Ciao!

Originalmente inviato da MSchiepp

Il problema è leggermente diverso: è evidente che non è difficile 'contare' un impulso che dura 200uS con un micro che ha un ciclo di istruzioni di 1uS, ma il problema è che non si riesce a rilevarne e contarne contemporaneamente (e correttamente!) quattro che arrivano in modo completamente asincrono: non è quindi un problema di assembler o C, ma di risorse del micro che non consentono di fare queste cose.
Non a caso vendono le UART già fatte...

Michele

Non sono d'accordo,ripeto lo ho già fatto...
ripeto il programma deve "scansionare" continuamente gli ingressi
e le altre operazioni le fà a rate :
il segnale và alto sul pin,il pic lo vede (20 istruzioni in +
non è un problema),memorizza e continua con la scansione...
da lì ripassa molte volte mentre trascorrono quei fatidici 204 uS
e prende in considerazione solo la lettura + centrale ai 204
scartando il primo bit (partenza) e l'ultimo (chiusura)
mentre gli altri gli mette in una locazione di ram.
Ovvio,ripeto,che lo fà senza fermarsi e continuando a leggere sugli altri ingressi e per questi facendo lo stesso.
restano libere diverso tempo istruzione per fare le altre cose.
Il Pic và programmato per comportarsi come esempio un PLC
cioè non deve fermarsi ad aspettare ma gestisce le varie operazioni a
scansione.

[MSchiepp]

Originalmente inviato da jijuja

Non sono d'accordo,ripeto lo ho già fatto...
il segnale và alto sul pin,il pic lo vede (20 istruzioni in +
non è un problema)

Sicuramente sei molto più bravo di me, ma commento solo due cose:
- quando campioni una seriale via sw devi fare almeno tre campionamenti per ogni bit (le UART 'vere' ne fanno almeno 5)

- 20 istruzioni a 4 Mhz fanno minimo 20 uS (22 visto che ci sarà almeno un salto...): dopo 10 bit hai accumulato un errore di 220uS ai quali devi aggiungere il margine per le tolleranze dei due quarzi (almeno 2% - 3% di scostamento): risultato già dopo 7 bit rischi di campionare nel posto sbagliato... e questo per un solo canale, se moltiplichi tutto per quattro le cose evidentemente non migliorano.

Quando si discute se una soluzione può o meno funzionare non si intende che ci sia qualche caso in cui funziona, ma che sicuramente funziona in tutti i casi, tenendo conto di tutte le tolleranze e di tutte le possibili combinazioni.

Diverso è il caso di utilizzare quattro micro differenti uno per ogni canale, ma per uno che non ha mai visto un pic e che non ha mai scritto una riga di codice mi sembra un inizio un po' ... violento!

Michele

[ElNonino]

Perdonate la mia ignoranza in materia ma usare un chip tipo http://www.elettroshop.com/dettagli.asp?pid=1239 od altri similari dotati di buffers generosi e che si interfacciano facilmente con qualsiasi micro no ?

Non ho capito se il tutto deve essere montato su un un modello o su una imbarcazione vera, nel secondo caso starei molto ma molto attento, è richiesta un'altissima affidabilità e sarebbe bene che l'intero sistema fosse ridondante.

Comunque per un principiante con i PIC la vedo dura e quoto al 100% MSchiepp.

Ciao,non voglio essere + bravo di nessuno,
semplicemente lo avevo già usato.
Certo se mi dici che deve essere preso in considerazione tutto...
Nel programma che usavo io non erano tollerati gli errori,
se fossero presenti non sarebbero stati visti come tali,
le limitazioni principali di un software su un Micro a 4Mhz
per svolgere quel compito sono : gli errori non gestiti (come già detto)
le operazioni possibili su tali dati che non sono "conti" complessi
e quindi frà singoli byte (8 Bit) e non operazioni matematiche
ma semplici trattamenti dei dati ,
una semplice somma a 16 Bit sarebbe praticamente impossibile
in real time,
per riassumere devono entrare dati puliti,le lunghezze delle stringhe
devono essere prestabilite e senza errori cioè esempio sulla stringa NMEA
si potrebbe fare questo :
data questa stringa
$GPGLL,4530.6671,N,00916.9484,E,204620.999,V*23
in uscita avere :
4530.6671,N,00916.9484,E
o un eventuale nulla in caso di dato non valido
(usando il carattere di controllo)

Il programma poi gestisce in modo molto complesso i campionamenti,
io lo usavo come interfaccia per dati in ingresso da 2 sonde
di pressione (4 caratteri ASCII) ed un vecchio convertitore A/D
seriale per altre misure su aereomodello...
Mettevo tutti i dati in colonna e gli ritramettevo.

Quindi il tutto a 4Mhz è tirato all'osso!

Ti dò ragione che questo è improponibile ad un principiante,
sia per il tempo che ci vorrebbe a svilupparlo
(bisogna prima imparare ad usare bene l'Assembler,
leggersi bene il manuale dell'Mplab sul quale si imparano molti trucchi,
fare esperienza passando dai led agli LCD e via dicendo,diciamo
che se trattato come Hobby ci vogliono almeno 6 mesi
di pratica per poi padroneggiare l'architettura del Micro e l'Assembler
in modo tale da portare in opera un programma che svolga quel compito.
(chiaro che esistono persone geniali come persone non portate
ed io parlo da "normale" però con passione)

Se si vogliono i risultati senza dover passare per tutto questo
(a tanti non interessa la programmazione nel vero senso stretto
ma interessa avere quel'atrezzo che fà quella cosa)
meglio un micro + potente o + micro e linguaggi ad alto livello
tipo C o Basic.
Con un bel micro in C si riuscirebbe a fare senza grossi problemi
ma in Basic gestire 3 porte in ingresso contemporaneamente non
è contemplato,per questo ho proposto la piattaforma
multiprocessore,in questo modo tutto diventa semplice
e gestibile in Basic,
si possono usare le versioni Free limitate in quanto lunghezza codice
semplificando il tutto e comunque si parla di un paio di Euro (costo Pic)
ogni ingresso,per le uscite si fanno senza problemi tutte con il
Master visto che il momento per trasmettere lo decidiamo noi.

Che tipo di dati ti trovi in uscita dagli altri strumenti?