PIC18 - Uart e buffer a lunghezza variabile

[Dryden]

Buon giorno.

Innanzitutto ringrazio tutti per gli interventi.

Seconda cosa, mi scuso per la mia assenza ma ero via per il week end e non mi andava di dare risposte stringate, inviate con il cellulare.

Vediamo Di fare un po' di chiarezza :)

Come giustamente notato da TardoFreak , la documentazione è un po' scarna, rispetto alle funzionalità del modulo.

Personalmente non ho problemi con la gestione dei comandi AT, anche se in questo caso, i comandi AT si inviano solamente, e questo accade durante la configurazione del modulo stesso.
Una volta configurato il modulo, si invia il comando at+out_trans=0 e il modulo esce dalla fase di configurazione e entra in TRASPARENT MODE.
Questa modalità, invia semplicemente ogni richiesta del client in modo trasparente.

Cosa significa: quando apro il browser internet e invio la richiesta al seguente indirizzo 192.168.37.101:8080
Il modulo mi invia questi dati in formato ASCII (stringa):

Codice: Seleziona tutto

GET / HTTP/1.1
                                                               
Accept: text/html, application/xhtml+xml, */*
                                 
Accept-Language: it-IT
                                                       
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko
     
Accept-Encoding: gzip, deflate
                                               
Host: 192.168.37.107:8080
                                                     
Connection: Keep-Alive


Ogni fine linea è presente il CR e LF.

La stringa ricevuta è diversa, come contenuto e lunghezza, in base al browser utilizzato (IE, FIREFOX, CHROME ecc...) ed è qui che mi incasino.

Ho letto la possibilità di utilizzare XON-XOFF, il modulo supporta questa modalità dopo l'ultimo aggiornamento FW, il problema è che sono io che non so cosa sia avreste un link che spieghi in dettaglio questa modalità di funzionamento?

Come giustamente fatto notare da AlbertoBianchi non mi pare una grande idea usare un timer per temporizzare la ricezione, lo vedo solo come fonte di problemi in quanto esiste la possibilità, in questo modo, di perdere dati o interrupt scatenati da altre "parti" del software.

Ringrazio nuovamente tutti per il tempo dedicatomi :)

[grandegiove]

http://en.wikipedia.org/wiki/Software_flow_control

[Dryden]

@ grandegiove : Grazie per il link sul XOFF-XON

vedendo un po' come funziona, non mi sembra possa risolvere il mio problema.

Il controllo XOFF-XON risolve il problema di lunghezza del buffer per non sforare con la lunghezza dei dati, ma non è in grado di dirmi se la trasmissione è completa oppure no in quanto se fermo la trasmissione dei dati, quando la riprendo non posso sapere a priori se quello che sto infilando nel buffer è il resto del messaggio precedente oppure il resto del messaggio precedente più uno nuovo.

O forse ho compreso male io?

[WALTERmwp]

Avrai una idea di come è costruito (....) altrimenti sulla base di cosa stabilisci la "qualità" di quanto hai ricevuto ?

Saluti

[AlbertoBianchi]

Ogni fine linea è presente il CR e LF.

In questi casi il parsing si fa riga per riga a ciclo continuo.
Devi raccogliere sequenzialmente in una stringa i caratteri in arrivo sul buffer di seriale (la fifo del post 2) fino a che non trovi la sequenza CR/LF (in genere questi due caratteri non si inseriscono), terminare la stringa con '\0' e poi passarla al parser che l'analizza.

Sarà il parser in base al contenuto della riga che va ad analizzare, a decidere in modo 'logico' l'nizio della pagina HTML ed il significato dei successivi elementi che vengono via via esaminati ad ogni nuova riga inviatagli.

In HTML la lunghezza massima consigliata per ogni linea è di 80 car, per sicurezza puoi allocare lo spazio per la stringa un 30/40% maggiore e comunque fare un controllo di sforamento durante il riempimento.
http://stackoverflow.com/questions/2886603/is-there-a-recommended-maximum-line-length-for-html-or-javascript