Buongiorno,
devo realizzare un progetto in cui devo far comunicare due PIC remoti. . Devo quindi scegliere il livello fisico e il protocollo da utillzzare.
Fino ad ora ho sempre realizzato mediante PIC slave Modbus RTU su RS485 (il master era un PLC).
Ora però dovrei scrivere il firmware per implemenatere il Master Modbus RTU, assai più arduo che realizzare uno slave.
Qualcuno ha esperienza in merito e potrebbe dirmi come muovermi? (devo implementare logiche di ritrasmissione , di rilevazione d'errore e non so come muovermi).
Consigliate un'alternativa all'utilizzo di ModBus su RS485?
Una prerogativa del sistema è che deve essere molto immune ai disturbi (Rs485 era una buona soluzione grazie alla sua robustezza)
Grazie mille.
Comunicazione fra PIC: Modbus oppure?
Moderatore:
Paolino
24 messaggi
• Pagina 1 di 3 • 1, 2, 3
0
voti
L' intefaccia piu' semplice (per DUE SOLI micro) e' una seriale full duplex RS232. Usi le UART dei micro con poche righe di programma.
Se vuoi controllare gli errori definisci un protocollo, ci metti un campo di checksum e finito il chiasso.
Dipende da quello che vuoi fare.
Se vuoi controllare gli errori definisci un protocollo, ci metti un campo di checksum e finito il chiasso.
Dipende da quello che vuoi fare.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Grazie per la risposta,
ho provato a implemetare una semplice comunicazione fra due PIC 18F4620 mediante USART. Premesso che il sistema non funziona il princiape dubbio riguarda l'implementazione del MASTER: devo indicare in qualche modo l'inizio della trasmissione del pacchetto (per esempio un pacchetto MODBUS)?
Sono di corsa, per ora allego il codice del Master, così magari qualcuno può già dirmi cosa non va. Grazie!
(l'idea è implementare Modbus ma per ora non riconosce nessuno dei dati inviati, quindi devo prima superare questo scoglio).
ho provato a implemetare una semplice comunicazione fra due PIC 18F4620 mediante USART. Premesso che il sistema non funziona il princiape dubbio riguarda l'implementazione del MASTER: devo indicare in qualche modo l'inizio della trasmissione del pacchetto (per esempio un pacchetto MODBUS)?
Sono di corsa, per ora allego il codice del Master, così magari qualcuno può già dirmi cosa non va. Grazie!
(l'idea è implementare Modbus ma per ora non riconosce nessuno dei dati inviati, quindi devo prima superare questo scoglio).
- Codice: Seleziona tutto
MASTER
'TRASMISSIONE RS485 ------------------------------------------------------------
sub procedure InvioRs485(dim count as byte)
dim i as byte
DIR485=1
for i=0 to (count-1)
USART_Write(bufTx485[i])
next i
while (TXSTA.TRMT=0) 'attend
wend
delay_us(40)
DIR485=0
end sub
'MAIN---------------------------------------------------------------------------
main:
USART_Init(9600)
RCSTA=%10010000
TRISC=%11000000 'RC3 output (RC6 e RC7) input (USART)
while(1)
'Invio di un byte
'Preparazione buffer da inviare
bufTx485[0]=1
bufTx485[1]=2
bufTx485[2]=3
bufTx485[3]=4
bufTx485[4]=5
bufTx485[5]=6
bufTx485[6]=7
bufTx485[7]=8
InvioRs485(8)
delay_ms(1000)
wend
end.
-

grandegiove
1.151 1 4 8 - Expert

- Messaggi: 517
- Iscritto il: 18 ott 2010, 9:59
0
voti
grandegiove ha scritto:Grazie per la risposta,
ho provato a implemetare una semplice comunicazione fra due PIC 18F4620 mediante USART. Premesso che il sistema non funziona il princiape dubbio riguarda l'implementazione del MASTER:...
Premetti male. Il sistema funziona benissimo. Semmai sei TU che hai sbagliato qualcosa.
Pero' vedo che non t' interessa far comunicare due PIC ma implementare il Modbus punto e basta.
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Ciao, con "il sistema non funziona" intendevo che io ho sbagliato qualcosa e quindi non funziona ! Era una ammissione di colpa.
Il fatto è che proprio non riesco a farli comunicare! Sostanzialmente i dati che invio allo Slave con l'USART del Master non riesco a leggerli con l'USART dello Slave.
E non so cosa sbaglio..
Il fatto è che proprio non riesco a farli comunicare! Sostanzialmente i dati che invio allo Slave con l'USART del Master non riesco a leggerli con l'USART dello Slave.
E non so cosa sbaglio..
-

grandegiove
1.151 1 4 8 - Expert

- Messaggi: 517
- Iscritto il: 18 ott 2010, 9:59
0
voti
Se mi spieghi come raggiungerti, ti posso dare il sorgente di tutto il protocollo già fatto. Non è ModBus, ma funziona molto bene. (Volevo farne un articolo, ma sei arrivato prima tu).
Anzì: se io te lo do, tu ne faresti un articolo EY? Visto che la risorsa la ricevi gratis, dovresti almeno restituire qualche forma di impegno.
Anzì: se io te lo do, tu ne faresti un articolo EY? Visto che la risorsa la ricevi gratis, dovresti almeno restituire qualche forma di impegno.
-

Candy
32,5k 7 10 13 - CRU - Account cancellato su Richiesta utente
- Messaggi: 10123
- Iscritto il: 14 giu 2010, 22:54
0
voti
Se mi spieghi come raggiungerti, ti posso dare il sorgente di tutto il protocollo già fatto. Non è ModBus, ma funziona molto bene. (Volevo farne un articolo, ma sei arrivato prima tu).
Mi sembra un'ottima idea. Il fatto che non sia Modbus non è un problema, l'obiettivo è realizzare una comunicazione robusta ed efficiente: ti mando la mail in privato.
L'unico ostacolo potrebbe essere che sul posto di lavoro (dove devo realizzare il progetto) abbiamo la licenza solo del compilatore Basic (MikroBasic) e quindi dovrò tradurlo ma se il sorgente è in C non dovrebbe essere un problema.
Anzì: se io te lo do, tu ne faresti un articolo EY? Visto che la risorsa la ricevi gratis, dovresti almeno restituire qualche forma di impegno.
Asolutamente d'accordo. Se ne comprendo bene il funzionamento nessun problema a rendere partecipe la community con un articolo.
-

grandegiove
1.151 1 4 8 - Expert

- Messaggi: 517
- Iscritto il: 18 ott 2010, 9:59
0
voti
Avevo capito male allora.
Strano che tu non riesca a far comunicare due PIC tramite la seriale. E' semplicissimo. Nel datasheet ci sono anche indicate, passo per passo, le istruzioni per inizializzare l' UART ed utilizzarla sia in trasmissione che in ricezione.
In mikrobasic (come in mikroC) e' ancora piu' semplice. Il compilatore fa tutto e nella pagina di help c'e' anche un esempio di applicazioni perfettamente funzionante.
Poi dirmi la sigla dei PIC che usi?
Strano che tu non riesca a far comunicare due PIC tramite la seriale. E' semplicissimo. Nel datasheet ci sono anche indicate, passo per passo, le istruzioni per inizializzare l' UART ed utilizzarla sia in trasmissione che in ricezione.
In mikrobasic (come in mikroC) e' ancora piu' semplice. Il compilatore fa tutto e nella pagina di help c'e' anche un esempio di applicazioni perfettamente funzionante.
Poi dirmi la sigla dei PIC che usi?
"La follia sta nel fare sempre la stessa cosa aspettandosi risultati diversi".
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
"Parla soltanto quando sei sicuro che quello che dirai è più bello del silenzio".
Rispondere è cortesia, ma lasciare l'ultima parola ai cretini è arte.
-

TardoFreak
73,9k 8 12 13 - -EY Legend-

- Messaggi: 15754
- Iscritto il: 16 dic 2009, 11:10
- Località: Torino - 3° pianeta del Sistema Solare
0
voti
Allora, l'articolo, che comprende la risorsa, l'ho fatto io: conoscendo il lavoro fatto, mi è risultato più facile.
Buon proseguimento.
http://www.electroportal.net/candy/wiki/progetti-nel-cassetto-un-bus-multimaster-per-microcontrollori-pic
Buon proseguimento.
http://www.electroportal.net/candy/wiki/progetti-nel-cassetto-un-bus-multimaster-per-microcontrollori-pic
-

Candy
32,5k 7 10 13 - CRU - Account cancellato su Richiesta utente
- Messaggi: 10123
- Iscritto il: 14 giu 2010, 22:54
0
voti
Ringrazio infinitamente candy per il lavoro fatto, davvero un bel lavoro, presto mi cimenterò nella lettura dettagliata del lavoro.
Nel frattempo però non riesco ancora ad usare la Usart: ho ridotto i codici al semplice invio e ricezione di un byte ma il comportamento che ottengo è a dir poco ENIGMATICO (dopo i codici lo illustro...)
Uso due PIC18F4620
Seguono i due codici:
MASTER:
SLAVE
Il Master trasmette cicclicamente il dato. Lo slave riceve è stamapa su LCD.
Solo che dato trasmesso e ricevuto non coincidono!
La comunicazione credo vada a buon fine in quanto se trasmetto x ricevfe sempre y.
Ho trovato queste strane corrispondenze:
Trasmetto 55 ricevo 100 (LCD stampa d)
57 ricevo 99 (LCD stampa c)
59 ricevo 98 (LCD stampa b)
61 ricevo 97 (LCD stampa a)
63 ricevo 96 (LCD stampa ')
Trasmetto 50 ricevo 51 (LCD stampa 3)
54 ricevo 50 (LCD stampa 2)
58 ricevo 49 (LCD stampa 1)
62 ricevo 48 (LCD stampa 0)
Credo che l'errore sia quindi nell'interpretazione del dato.
Ho provato a ragionare sui binari in termini di "bit di parità" ma non ne ho ricavato nulla.
Il fatto poi che aumentando il valore trasmesso cali quello ricevuto mi fa pensare a qualche problema in termini di big/little endian.
Temo di essere un po' annebbiato..
Se qualcuno riesce a risolvermi questo enigma mi toglierebbe dalla brace,
grazie mille
Nel frattempo però non riesco ancora ad usare la Usart: ho ridotto i codici al semplice invio e ricezione di un byte ma il comportamento che ottengo è a dir poco ENIGMATICO (dopo i codici lo illustro...)
Uso due PIC18F4620
Seguono i due codici:
MASTER:
- Codice: Seleziona tutto
program Master_Modbus
symbol DIR485 =PORTC.5
dim buf485 as byte[5]
'TRASMISSIONE RS485 ------------------------------------------------------------
sub procedure InvioRs485(dim count as byte)
dim i as byte
DIR485=1
for i=0 to (count-1)
USART_Write(buf485[i])
next i
while (TXSTA.TRMT=0) 'attend
wend
delay_us(200)
DIR485=0
end sub
'MAIN---------------------------------------------------------------------------
main:
USART_Init(9600)
RCSTA=%10010000
TRISC=%11000000 'RC3 output (RC6 e RC7) input (USART)
while(1)
buf485[0]=62
InvioRs485(1)
delay_ms(200)
wend
end
SLAVE
- Codice: Seleziona tutto
program Master_Modbus
symbol DIR485 =PORTC.5
dim buf485 as byte[5]
'TRASMISSIONE RS485 ------------------------------------------------------------
sub procedure InvioRs485(dim count as byte)
dim i as byte
DIR485=1
for i=0 to (count-1)
USART_Write(buf485[i])
next i
while (TXSTA.TRMT=0) 'attend
wend
delay_us(200)
DIR485=0
end sub
'MAIN---------------------------------------------------------------------------
main:
USART_Init(9600)
RCSTA=%10010000
TRISC=%11000000 'RC3 output (RC6 e RC7) input (USART)
while(1)
buf485[0]=62 '(valore da trasmettere )
InvioRs485(1)
delay_ms(200)
wend
end
Il Master trasmette cicclicamente il dato. Lo slave riceve è stamapa su LCD.
Solo che dato trasmesso e ricevuto non coincidono!
La comunicazione credo vada a buon fine in quanto se trasmetto x ricevfe sempre y.
Ho trovato queste strane corrispondenze:
Trasmetto 55 ricevo 100 (LCD stampa d)
57 ricevo 99 (LCD stampa c)
59 ricevo 98 (LCD stampa b)
61 ricevo 97 (LCD stampa a)
63 ricevo 96 (LCD stampa ')
Trasmetto 50 ricevo 51 (LCD stampa 3)
54 ricevo 50 (LCD stampa 2)
58 ricevo 49 (LCD stampa 1)
62 ricevo 48 (LCD stampa 0)
Credo che l'errore sia quindi nell'interpretazione del dato.
Ho provato a ragionare sui binari in termini di "bit di parità" ma non ne ho ricavato nulla.
Il fatto poi che aumentando il valore trasmesso cali quello ricevuto mi fa pensare a qualche problema in termini di big/little endian.
Temo di essere un po' annebbiato..
Se qualcuno riesce a risolvermi questo enigma mi toglierebbe dalla brace,
grazie mille
-

grandegiove
1.151 1 4 8 - Expert

- Messaggi: 517
- Iscritto il: 18 ott 2010, 9:59
24 messaggi
• Pagina 1 di 3 • 1, 2, 3
Torna a Firmware e programmazione
Chi c’è in linea
Visitano il forum: Nessuno e 1 ospite

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)