Pic Rs232

Quindi adesso mi è tutto molto + chiaro ,bolinometro ed ecoscandaglio
penso (correggimi se sbaglio) abbiano l'uscita come il GPS cioè ogni tot tempo
inviano i dati,questi ovviamente devono essere gestiti in modo tale da poter leggergli
indifferentemente dal momento di invio,anche sovrapposti.
Il pilota automatico utilizzerà l'Rs232 come "porta" in sola ricezione quindi
aspetta gli siano inviati i dati e l'altra uscita penso tu la voglia tenere per un eventuale Computer
o quant'altro comunque immagino "un'uscita" dati che può aspettare.(si parla sempre di mS)
A questo punto userei solo il 16F628,facciamo un pò di conti:
premettendo che gli strumenti "trasmittenti" probabilmente (GPS sicuro)
lavorano con codici ASCII possiamo configurare il tutto esempio
a 4800 Baud ed abbiamo che una stringa da 8 Bit + 1 di inizio e 1 di fine
ci mette (1s/4800Baud)*10bit = 2.083mS ed il singolo bit 0.2083mS o
si può tradurre in 208.3 uS (microsecondi).
Il Pic lavorando a 4Mhz in quel tempo (Assembler) esegue 208 istruzioni...
Sono un'enormità per scansionare 3 porte visto che lo fai in poche istruzioni.
Poi esagerando in quel tempo ti stà anche il ciclo per scrivere sulle uscite
usando tutto a livello Software e ci puoi fare pure i calcoli
(se serve interpretare le stringhe).
Se lo usi in questo modo usi un solo piedino per porta visto che sarebbero unidirezionali
e te ne resterebbero pure 11 libere...(quel pic ne ha 16)
Tieni conto anche che 4Mhz sono con l'oscillatore interno al Pic mentre se usi un quarzo
lo porti a 20Mhz di istruzioni in quel tempo al porto che 208 ne fai 1040!!!
Ovvio che come software c'è un pò da lavorare specialmente se fai calcoli,
se lo usi solo per trasferimento vai come una freccia (sempre assembler)
Alternativa,investi un pò di + come soldi ((te la caverai con una ventina di Euro))
ti scarichi Mikrobasic (gratis non commerciale fino a 2K) ed usi un pic
serie 12 con oscillatore interno ogni porta e in 20 minuti crei un programma di conversione
di "standard" da Rs232 a I2C,sicuramente stai molto meno a livello di tempo
ed usi un Pic Master ( 16F628 ) per gestire calcoli e conversioni dati,
in Basic è una cosa immediata e la versione Free ti basta abbondantemente.
Ovvio che stò parlando di piattaforme per uso non commerciale!!!
Fammi sapere!

[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.

[MSchiepp]

Scusa se dico la mia, ma... lascia stare o trova qualcuno che ti può realizzare il tutto!
Con un PIC come quello non puoi fare quello che ti serve e soprattutto non puoi nemmeno pensare di farlo se parti da zero.

Prima di pensare alla lista della spesa scaricati MPLAB dal sito della Microchip (è l'ambiente di sviluppo per i pic) e incomincia ad imparare ad usarlo: puoi scrivere e simulare tutto il programma per il 628 e vedere se funziona. A quel punto puoi pensare al programmatore e agli altri componenti.

Resta comunque un fatto: non puoi gestire tre seriali asincrone in polling software senza avere almeno tre timer ed interrupt separati e magari avanzando anche il tempo per fare anche qualche elaborazione dei dati letti!

Michele

[marcosinatti]

Originalmente inviato da MSchiepp

Resta comunque un fatto: non puoi gestire tre seriali asincrone in polling software senza avere almeno tre timer ed interrupt separati e magari avanzando anche il tempo per fare anche qualche elaborazione dei dati letti!

Michele

Forse lo si può fare se imposti le seriali a baud bassi, ma secondo me ci vuole un bel PIC18 fatto lavorare a 40Mhz (10mhz x4 con pll) e poi devi lavorare molto di cesello, devi sviscerare così tanto la seriale in assembler al punto di impazzire!!! Almeno per le mie capacità!
L'assembler sinceramente è bello e potentissimo, ma quello che fai in un mese lo puoi fare in 2 giorni in basic o in C, ovviamente non puoi spingere molto come in asm.
Comunque se ti servono i pic li puoi prendere come samples sul sito microchip, ne inviano 3 campioni di 4 tipi diversi (12 in tutto) basta avere un indirizzo e-mail che sia registrato con un dominio commerciale o professionale.
Tanto per intenderci non deve essere @tele2 @libero @alice etc..
Per quanto riguarda il max232 con ognuno puoi convertire 2 linee da ttl a 232 e altre due linee da 232 a ttl, lo schema si trova sul datasheet.
Se ti interessa solo ricevere puoi evitare il max e mettere un partitore che ti porta i +12v della seriale a circa 5v con un diodo per tagliare via il -12v, ovviamente devi invertire la logica con cui leggi il pin, è meno professionale e sicuro ma se hai linee corte funziona alla grande, già sperimentato

Ciao...

[MSchiepp]

Originalmente inviato da marcosinatti

Forse lo si può fare se imposti le seriali a baud bassi, ...

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

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

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!