Newsgroup: it.hobby.elettronica.digitale
Titolo: Libreria C per far parlare due MCU via seriale con controllo flusso.

Ciao,
conoscete una libreria c che mi permetta di avere un minimo di controllo di flusso
nel dialogo via seriale tra due MCU?
 
Mi basterebbe uno stream (resettabile/chiudibile da entrambe le parti) e la possibilita di mandare messaggi OOB(Out Of band).
 
Un po come se avessi un solo socket TCP e un solo socket UDP (senza pero implementare tutto lo stack ip/ppp).
 
Giulia


Non stai chiedendo una cosa così semplice, da quello che ne so. Spesso 
anche io ho avuto questa esigenza ed ho dovuto scrivermi un protocollo 
proprietario ad-hoc, senza mai essere completamente soddisfatto.
 
La cosa che mi convince di più è un protocollo simile ad HDLC (vedi su 
Wikipedia), tipicamente usato in collegamenti sincroni, ma utilizzabile 
anche se collegamenti asincroni, come una seriale tra due MCU.
 
Ha un meccanismo di apertura/chiusura di una connessione (dello stream), 
tramite gli U-frames.
 
E' utilizzabile su connessioni multi-drop half-duplex master-slave, 
tramite il flag P/F di polling.
 
Ogni frame dei dati ha una numerazione che può essere usata per 
controllare le ritrasmissioni in caso di errore. Ogni frame è dotato di 
una checksum.
 
Purtroppo non ho mai trovato una implementazione del protocollo 
asincrono per MCU... magari tu sei più fortunata/brava :-)
 

Protocolli come quello che cerchi presuppongono una certa potenza di calcolo ed una disponibilità di risorse dipendenti dalla mole di dati ma anche da tutte le altre funzioni che le due MPU devono eseguire..
Di solito si parte da un vero e proprio sistema operativo capace di far eseguire contemporaneamente più programmi con differenti priorità (multitasking), tra i quali le comunicazioni (seriali o parallele) e le funzioni di I/O con maggiore priorità.
 
Senza però conoscere le caratteristiche delle MPU utilizzate, si va poco lontano ;-)
 
Puoi descrivere l'hardware che hai intenzione di usare? 
Magari esiste già qualcosa su github (es per quadricotteri o simili).


cercando per uart mux ho trovato questo :
 
http://www.eluaproject.net/doc/v0.8/en_sermux.html
 
 
si puo' provare a sfruttare il mux delle seriali per fare la 
trasmissione OoB
 
sperando che sia implementato anche l'handshaking ( come richiesto dall OP )
 
intanto me lo sono segnato visto che potrebbe essermi utile ;-)
 
 


PIC32MX e ESP8266, hanno entrambi potenza da vendere, non e' quello il problema!!!
Comunque sembra che hdlc vada bene , per adesso mi sto facendo una mini macchina a stati in c (senza uso di malloc)
per separare i frame hdlc dallo stream seriale e avere pachetti puliti(gia' andrebbe bene cosi),
per tutto il resto (ritrasmissione ecc ecc) vedremo.
 
Giulia

 mi sto facendo una mini macchina a stati in c (senza uso di malloc)
 
Come mai senza malloc? Forse la domanda è ingenua ma non ho esperienza 
di programmazione su microcontrollori.
 
-- 
Andrea
 

 puliti(gia' andrebbe bene cosi),
 
Io ho scritto qualcosa, anche se per bus multi-drop half-duplex.
Infatti ho due implementazioni: HDLC per master e HDLC per slave.
 
Nel master ho la possibilità di creare diverse connesociasioni che ho 
chiamato, guardacaso, socket. Ad ogni socket è assto uno stato 
(connesso/non connesso, ecc) e l'indirizzo dello slave.
 
All'inizializzazione, per ogni slave posso impostare una frequenza di 
polling diversa. Quando il master ha il controllo del bus (ricordo che è 
half-duplex), verifica l'esistenza di un socket con timer di polling 
scaduto e, se esiste, lo interroga dandogli il token (flag P/F) e 
aspettando una risposta.
 
Chiaramente, se la risposta non arriva dopo un certo tempo, il token 
viene ripreso "con la forza" dal master.
 
In via teorica, HDLC permetterebbe di inviare un certo numero di frame 
prima di rilasciare il token. Però, per fare ciò, l'implementazione 
(master e slave) dovrebbe parcheggiare *tutti* i frame trasmessi e non 
ancora confermati dal ricevente, in quanto potrebbero essere andati 
tutti persi e dover essere ritrasmessi. Questo vuol dire avere un bel 
po' di RAM.
Nella mia implementazione, viene trasmesso un solo frame per volta.
Anche perché non è molto diverso inviare 1 pacchetto da 500 byte, 
piuttosto che 10 pacchetti da 50 byte.
 
Avrei voluto fare in modo che lo slave potesse modificare a run-time la 
frequenza di polling, in base alle situazioni che possono cambiare nel 
tempo. Si potrebbero sfruttare gli U-frame. Ma non ho fatto nulla su 
questo fronte.
 
Se ti interessa scambiare un po' di idee/codice, il mio indirizzo è valido.
 
Non sarebbe male mettere in bella il tutto e farne un progetto 
open-source... ad avere del tempo.
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

Cara Giulia, parlare di "PIC32MX e ESP8266" dichiarando che "hanno entrambi potenza da vendere, non e' quello il problema!!! " mi ha fatto "sorridere"..
È più che evidente che il problema stia nella tua scarsa esperienza di sviluppo di firmware, altrimenti non avresti mai risposto in modo così superficiale!
Quello che più mi irrita in voi "praticoni" in elettronica digitale, è che venendo da un mondo dove la programmazione è fatta su strumenti dalla potenza ridondante siete poi convinti di poter fare tutto anche con strumenti essenziali (dove però si deve prevedere TUTTO) a bassissimo costo..
E mi chiedo: se sei così "preparata" e saccente da rispondere in modo così vago (senza prima spiegare il tipo di applicazione che vuoi fare), come mai ti rivolgi ad altri per la soluzione di un problema che dovresti saper affrontare senza difficoltà?
I casi sono due:
- o sei solo il solito "furbetto" che per non dover "lavorare" chiede ad altri la soluzione per poi magari farsi pagare dal cliente anche questo lavoro (disonestà professionale);
- oppure sei una dei tanti che crede di sapere tutto, e tratta un argomento molto più complesso del previsto senza prima approfondirne tutti i necessari aspetti (ma senza voler ammettere la propria ignoranza!).
Delle due io propengo per la seconda..
Ma vediamo di quanto mi sbaglio.. Rispondi a questa semplice domanda:
- ha fatto una precisa analisi dell'hardware e delle caratteristiche necesarie utili ad affrontare il problema che sei chiamata a risolvere (timing delle azioni da eseguire con relative priorità, trattamento dei consumi, situazioni di blackout, verifica delle condizioni della sicurezza vs persone o cose, costi di produzione e vendita, dimensioni del prodotto finale, problematiche di produzione ed assemblaggio, ecc)?
Se la tua risposta è esauriente, allora mi domando il perché della tua risposta così superficiale (e varrebbe l'ipotesi del "furbetto"), altrimenti sarebbe meglio tu mettessi da parte l'orgoglio e ti "abbassassi" a capire che non si può conoscere tutto (sopratutto in informatica) e che quando si parla di firmware, la complessità delle soluzioni è di molto superiore rispetto a quella che si incontra scrivendo software per un computer fatto e finito (senza problemi hardware). E per questo, quando si cerca aiuto (come ha fatto tu) si deve essere aperti e pronti a far comprendere al prossimo il problema (anche se si rischia di far vedere che non si hanno le necessarie "basi" per affrontarlo .. e questo fa parte del processo di apprendimento e crescita.. ;-).
 
 

Il giorno mercoledì 26 agosto 2015 09:36:40 UTC+2, Kokiua ha scritto:
[...]
 
Sciapo'

 - oppure sei una dei tanti...
...
 
Ehm... Non mi immolerei ma credo di ricordare che Giulia è un Lui (ipocoristico di Giuliano).
 
Per quanto riguarda il contenuto tassonomico del commento, posso trovarmi d'accordo ma mi par un tantin severo. :(
Conoscendo il soggetto, non credo che siamo innanzi nemmeno alla sindrome di Gundam.
 
Piccio.
 


Perche una malloc puo' fallire (sopratutto quando hai poca ram e molta frammentazione), un array statico
non puo' fallire!!
Sarebbe tutto poco deterministico ed esposto ai memory leak.
 
Giulia
 

 Cara Giulia, parlare di "PIC32MX e ESP8266" dichiarando che "hanno entrambi potenza da vendere, non e' quello il problema!!! " mi ha fatto "sorridere"..
Sono contenta per le risate, comunque visto che ai bei tempi ho fatto di tutto (e dico tutto) con un C64(assemblando anche a mano) direi che macchine a 32bit 
con centinaia di Kb di ram e Mb di ROM e supporto DMA non sono assolutamente un limite, penso che l'unico abituato troppo bene sei proprio tu che chiami 
"essenziali" questo popo' di macchine, ad avercele all'epoca!!
 
Giulia
 
 
 


Poco sopra c'e' Piccio che ipotizza Giulia sia masculo
E quindi la curiosita' ora regna soprana (o 'sovrana' oppure anche 'sorana')
Ah Giuliaaa, sei una Giulia (con la presa) o un Giuliano (con la spina)?
Mica per me eh, per Piccio
 
 
 
 

 Mica per me eh, per Piccio
 
Certo però che anche il tuo nickname crea incertezza-gender con quelle due vocali finali.
 
:)
 
Piccio.

Giulia, ti tratterò ancora da "femmina" visto che è così che ti firmi :-)
Non amo stare a vedere chi ce l'ha più "grossa" (l'esperienza intendo ;-) ma credimi se ti dico che quando tu giocherellavi con il commodor 64 (che al tempo ho anche venduto) io era già da alcuni anni (oggi sono nonno ;-) che mi dilettavo con l'elettronica digitale e la programmazione dei primissimi processori.. E pensa che a quel tempo anche le università italiane stavano muovendo i primi passi in questa fantastica scienza. Nella mia esperienza di più di 30 anni, ho "solo" avuto la fortuna di assistere (vivendola) alla rivoluzione e alla vertiginosa crescita dell'informatica e dell'elettronica (da sempre anche un mio hobby).
Ti ripeto che l'atteggiamento da "saccente" che dimostri nei tuoi interventi mal si accorda con una richiesta di aiuto!
Forse non sarai più giovane, ma purtroppo una cosa ancora non l'hai imparata: la modestia e la tolleranza verso il prossimo.. doti che si "guadagnano" solo se non si ha la costante paura di non essere all'altezza dei compiti che la vita riserva!
Detto questo ti saluto, promettendoti che non interverrò più in questa inutile discussione, se non (se ne avrò tempo e voglia) nel caso io legga grossolane e superficiali inesattezze (se non altro per evitare ad altri di essere male informati, per mia mera "deformazione professionale")

Kokiua ha scritto:
[cuttone]
Insomma la solita retorica ad hominem per nascondere le leggerezze che stanno dietro le tue affermazioni, come se per gestire bene una seriale ci volesse tutta 
sta conoscenza/esperienza, volevo evitarmi di reinventare l'acqua calda e sei partito per la tangente,
ti saluto prof,  le tue lezioncine sono di una noia mortale...
 
Giulia
 

Il 24/08/2015 11:17, Giulia ha scritto:

Che tristezza... già questo forum ha perso un sacco negli ultimi anni, 
poi lo riempiamo pure di post inutili, come il mio :-(
 

di essere male informati, per mia mera "deformazione professionale")
 
Ti lamenti? questi sono abituati ad Arduino 
 
 
 
---
Questa e-mail e stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus