PIC18 - Uart e buffer a lunghezza variabile

[Dryden]

Buon giorno a tutti.

Vi rompo le scatole perché ho il seguente problema:

PREMESSA:
Sto usando un PIC18f4620 e un modulo wifi-eth/UART
http://www.hlktech.net/product_detail.php?ProId=39

Il tutto mi serve per mettere in piedi un web server.
Il modulo wifi mi invia direttamente i dati in modo trasparente sulla uart del PIC, i quali riesco a leggerli tranquillamente salvandoli in un buffer da 512 byte.

PROBLEMA:
Il mio problema è che la lunghezza della risposta da parte del modulo WIFI è variabile e mi trovo in difficoltà a capire quando la trasmissione è terminata.

A priori non posso sapere ne quanto è lunga la stringa ne quando il modulo trasmette.
Per il "quando trasmette" uso tranquillamente l'interrupt.
Ma come faccio a determinare quando la trasmissione è finita senza perdere parte della stringa?

Pensavo di usare un timer, in modo tale che da quando parte l'interrupt conto XXXms e poi manipolo la stringa. Ovviamente i millisecondi impostati devono essere sufficienti a ricevere qualsiasi stringa, però non mi piace molto come soluzione.

Cosa ne pensate?

Spero di risultare comprensibile

Grazie a tutti

[AlbertoBianchi]

Ciao,
non sapendo come sono formattati i dati che devi ricevere ti posso intanto dare un consiglio gererale su come organizzare la ricezione.
Devi crearti una fifo circolare che è un'area dei memoria con associati un puntatore alla locazione di inserimento del nuovo dato, un altro puntatore alla locazione di prelievo del dato più vecchio ed un contatore che tiene il numero di bytes presenti nella fifo.
La routine che serve l'interrupt di ricezione della uart inserirà il valore arrivato nella locazione indicata dal puntatore di inserimento, dopodichè il puntatore viene incrementato ed anche il contatore dei bytes presenti nella fifo;
Per estrarre un byte, occorre leggerlo dalla locazione indicata dal puntatore di estrazione dopodiché il puntatore di estrazione viene incrementato e quello di riempimento decrementato.
Se la fifo non viene svuotata ad un certo punto si riempirà causando un evento di errore da gestire, in genere chiamato 'fifo overrun'.

Nalla routine del programma di analisi dei dati di ricezione, vi sarà un ciclo di polling che testa se la fifo è vuota
e quando vi saranno dei dati questi verranno estratti ed analizzati secondo il bisogno, creando posto nella fifo per nuovi dati in arrivo.
In questo modo hai un polmone di memoria che ti permette di ricevere dati in forma di stream continuo, e a cui puoi associare un timer per gestire il timeout di ricezione.
qualcosa di simile a questo (è roba vecchia, non su PIC):

Codice: Seleziona tutto

BYTE tx_fifo[BUFF_TX];
BYTE rx_fifo[BUFF_RX];

/ **************************************************************
// gestione buffer di ricezione (FIFO circolare)
// gli elementi entrano in testa ed escono dalla coda

// inserisce un elemento in testa al buffer
monitor void push_rx_fifo(BYTE ch)
{
  rx_fifo[pput_Rx++] = ch;        // SCI Data Register Low
        
  if(pput_Rx >= BUFF_RX) pput_Rx = 0;
     
  if(NumRx < BUFF_RX) {           
    NumRx++;                        // incremento char disponibili
  } else {   
    // In caso overrun sul buffer di ricezione sposta il puntatore
    // di estrazione in avanti per garantire almeno la coerenza dei
    // rimanenti dati presenti nel buffer
    pget_Rx++;                   
    if(pget_Rx >= BUFF_RX) pget_Rx = 0;
  }
}
// restitusce ed elimina l'elemento in coda al buffer
monitor BYTE pop_rx_fifo(void)
{
  BYTE ch = 0;
  if(NumRx) {
    ch = rx_fifo[pget_Rx++];
    if(pget_Rx >= BUFF_RX) pget_Rx = 0;
    NumRx--;
  }
  return ch;
}       


[WALTERmwp]

Ciao Dryden, nell'apertura del suo Post AlbertoBianchi ha messo subito in evidenza la mancanza di una informazione fondamentale.

Puoi non sapere a priori da quanti byte è composto il messaggio che devi ricevere ma come è strutturato lo devi sapere.
Avrai una idea di come è costruito: eventuali caratteri di inizio e fine, posizione predefinita di uno o più byte(s) che ti "dicono" da quanti byte(s) è composto, una informazione (byte) che ti "dice" se il messaggio è parte di un messaggio più lungo, ... e così via.
Questi sono elementi fondamentali altrimenti sulla base di cosa stabilisci la "qualità" di quanto hai ricevuto ?
Il timeout è un altro aspetto importante ma la sua gestione andrebbe coordinata con quanto sopra riportato, credo.
Se sul micro utilizzi la EUSART prevedi l'attivazione di un timer (magari il 2) sull'intervento dell'interrupt (poi perché non sia di tuo gradimento non so) della seriale; però, se e quando ti va in timeout, in base ai dati precedentemente acquisiti (e "bufferizzati") puoi stabilire se il timer è scaduto a causa di un errore di trasmissione oppure per altro.
Quanto sopra, per quel poco che si può riportare in base alla tua richiesta, senza, per altro, avere approfondito le caratteristiche tecniche del prodotto riferito nel link.

Saluti

[TardoFreak]

Se il trasmettitore può essere configurato con il controllo di flusso XON/XOFF il problema è risolto.
Domanda: il trasmettitore supporta tale protocollo?
Se si ho già una funzione di servizio dell' interrupt ultra collaudata e sono pronto a postarla.

[AlbertoBianchi]

Come giustamente ti diceva WALTERmwp per sapere esattamente e con sicurezza quando un messaggio (flusso dati) inizia e termina, serve sapere esattamente come è strutturato.

Normalmente, i dati da trasmettere (soprattutto quando non sono di per se intrepretabili) vengono divisi in pacchetti di varia lunghezza ed incapsulati in una struttura dati maggiormente definita, che prende il nome di frame relativo ad un protocollo di comunicazione (alcuni sono standardizzati, molti altri custom).

La struttura tipica di questi frame prevede 3 parti: un preambolo, un corpo dati significativi ed un epilogo.

In genere nel preambolo c'è uno o più caratteri di riconoscimento di inizio frame, altri dati come l'identificativo di chi invia il frame, quello della destinazione, la lunghezza del frame etc.

Nel corpo dati, chiamato in gergo payload, ci sono appunto l'insieme dei dati trasmessi; spesso se l'insieme di dati da inviare è di lunghezza rilevante viene divisi in blocchi di lungezza fissa o massima ed inviati in una serie di frames contigui.

Nell' epilogo di solito ci sono alcuni byte per verificare la congruenza dei dati ricevuti (checkum o crc)
ed uno o più caratteri di riconoscimento di fine frame;

Generalmente per decodificare un protocollo si costruisce un loop di polling del dato in arrivo sulla fifo di ricezione e quando arriva, si invia il dato ad una macchina a stati finiti che provvede ad analizzare step-by-step le varie sequenze di caratteri in arrivo.

Le funzioni tipiche di questa macchina a stati sono:
- sincronizzazione con l'inizio del frame;
- determinazione della provenienza e della destinazione del frame
- determinazione della quantità e natura dei dati del payload
- separazione del payload dal frame ed eventuale ricomposizione
- sincronizzazione con la fine del frame
- controllo di congruenza sui dati ricevuti
- invio di una risposta se richiesta.

Successivamente il payload integro viene ulteriomente analizzato e utilizzato.

Pensavo di usare un timer, in modo tale che da quando parte l'interrupt conto XXXms e poi manipolo la stringa. Ovviamente i millisecondi impostati devono essere sufficienti a ricevere qualsiasi stringa, però non mi piace molto come soluzione.

L'espediente di stabilire un tempo massimo in cui deve arrivare tutto il pacchetto di dati per stabilire che è terminato, purtroppo è una strada ad alto rischio, che può andar bene oggi, in una certa situazione ma non saprai mai se domani potrà arrivarti un pacchetto più lungo, o per una qualsiasi ragione di latenza incerta si verificherà un caso in cui sfori questo tempo che è hard-coded. Inoltre se abbondi col tempo rischi di avere una situazione di over-run fra trasmissioni successive

Purtroppo non lavorando con i PIC non ho esempi semplici da passarti, ma sono sicuro che gli altri firmwaristi 'PIC aficionados' che frequentano EY da molto prima di me, sapranno aiutarti nello specifico.

[TardoFreak]

Ho dato uno sguardo al prodotto.
Bisognerebbe avere una documentazione un po' più completa.
E' comunque un modem e se accetta i comandi AT basta impostare il controllo di flusso XON/XOFF, implementarlo sul buffer di ricezione (è una cosa semplicissima) del PIC e la cosa è fatta.
Non vedo complicazioni se non quellla di avere una documentazione più dettagliata.

[AlbertoBianchi]

Ciao TardoFreak, ho dato anch'io un' occhiata al minestrone delle specifiche e, se ho capito bene, e sottolineo se, dovrebbe trattarsi di un dispositivo che canalizza una rice/trasmissione seriale grezza sulla rete tramire protocolli UDP o TCP (serial over ethernet).
il set di comandi AT dovrebbe essere dedicato alla configurazione dei parametri operativi del dispositivo lato seriale, mentre lato rete lo si può fare accedendo ad una pagina web di configurazione fornita dal web server interno.

Il dispositivo in questione è un po' grezzo come tools di supporto, ma molto interessante, sia per il fatto che ha anche le connessioni per il connettore ethernet che per il prezzo (10$-15$) (una Xport Lantronix costa circa 50€ ed è solo ethernet)

@Dryden se vuoi realizzare un web server ho visto che in rete ci sono diversi esempi fatti usando arduino che potresti usre come fonte di ispirazione. Ovviamente sono implementazioni molto semplici ma comunque potrebbero essere un punto di partenza.

il manuale d'uso:
http://www.prometec.net/wp-content/uploads/2015/01/HLK-RM04-user-manual.pdf

[TardoFreak]

[quote="AlbertoBianchi"...il set di comandi AT dovrebbe essere dedicato alla configurazione dei parametri operativi del dispositivo lato seriale ...[/quote]
E quindi il problema iniziale, quello della lunghezza del buffer è risolto.
- Si configura il modom con handshake software XON/XOFF
- Quando il buffer è quasi pieno (si lasciano un paio di caratteri per sicurezza) gli si invia il carattere di XOFF
- Quando il buffer può nuovamente ricevere gli si invia un carattere di XON

In questo modo ha risolto il suo problema.
Tutto il resto viene dopo.

[AlbertoBianchi]

Non mi è chiaro quali siano esattamente i problemi di Dryden ma non credo che siano quelli della gestione dei comandi AT, la cosa sarebbe troppo semplice anche per un principiante.
Credo che il campo di interesse sia la gestione delle pagine web, trasmissione e parsing o gestione delle risposte CGI.

[TardoFreak]

PROBLEMA:
Il mio problema è che la lunghezza della risposta da parte del modulo WIFI è variabile e mi trovo in difficoltà a capire quando la trasmissione è terminata.

A priori non posso sapere ne quanto è lunga la stringa ne quando il modulo trasmette.
Per il "quando trasmette" uso tranquillamente l'interrupt.
Ma come faccio a determinare quando la trasmissione è finita senza perdere parte della stringa?
...

Mah, a me sembrava chiaro.
Aspettiamo un suo intervento chiarificatore.