Seriale: write() throttling?

Question

Sto lavorando a un progetto che invia dati seriali per controllare l'animazione di luci a LED, che devono rimanere sincronizzati con un motore di animazione. Sembra esserci un grande buffer di scrittura seriale (dispositivo seriale USB chipset OSX (POSIX) + FTDI), quindi senza limitare manualmente le chiamate a write(), il software può ottenere diversi secondi prima delle luci.

Attualmente mi sto limitando manualmente la velocità di scrittura seriale alla velocità di trasmissione (telaio di serie 8N1 = 10 byte per byte di dati 8, 19200 bps seriali -> 1920 byte al secondo max), ma io sto avendo un problema con l'animazione alla deriva fuori sincrono con le luci nel tempo - inizia bene, ma dopo 10 minuti c'è un ritardo notevole (100ms +) tra l'animazione e le luci.

Questo è il codice che limitano la velocità di scrittura seriale (chiamato una volta per frame di animazione, 'trascorso' è la durata del frame corrente, 'baud' è il bps (19200)):

void BufferedSerial::update(float elapsed) 
{ 
    baud_timer += elapsed; 

    if (bytes_written > 1024) 
    { 
     // maintain baudrate 
     float time_should_have_taken = (float(bytes_written)*10)/float(baudrate); 
     float time_actually_took = baud_timer; 
     // sleep if we have > 20ms lag between serial transmit and our write calls 
     if (time_should_have_taken-time_actually_took > 0.02f) 
     { 
      float sleep_time = time_should_have_taken - time_actually_took; 
      int sleep_time_us = sleep_time*1000.0f*1000.0f; 
      //printf("BufferedSerial::update sleeping %i ms\n", sleep_time_us/1000); 
      delayUs(sleep_time_us); 

      // subtract 128 bytes 
      bytes_written -= 128; 
      // subtract the time it should have taken to write 128 bytes 
      baud_timer -= (float(128)*10)/float(baudrate); 
     } 
    } 
} 

Chiaramente c'è qualcosa che non va, da qualche parte.

Un approccio molto migliore sarebbe quello di essere in grado di determinare il numero di byte attualmente nella coda di trasmissione, e cercare di mantenerlo al di sotto di una soglia fissa, ma non riesco a capire come farlo su un OSX (POSIX).

Qualsiasi consiglio è gradito.

Answer 1

Se si desidera rallentare l'animazione in modo che corrisponda alla velocità massima che è possibile scrivere sui LED, è sufficiente utilizzare tcdrain(); qualcosa di simile:

while (1) 
{ 
    write(serial_fd, led_command); 
    animate_frame(); 
    tcdrain(serial_fd); 
} 

Answer 2

È possibile utilizzare il controllo del flusso hardware.

Non so che tipo di hardware hai sull'altro lato del collegamento seriale, ma i lati della cabina potrebbero sincronizzarsi e regolarsi tramite le linee di handshake RTS/CTS.

Questo è ciò a cui sono destinati, dopo tutto.

Answer 3

Basta tenere una velocità di trasmissione fissa che è leggermente più veloce di quello che deve essere, e sincronizzare i LED con l'animazione per ogni blocco di N fotogrammi di animazione:

for each block 
{ 
    writeBlockSerialData(); 
    for each frame in block 
    { 
     animateFrame(); 
    } 
} 

La velocità di trasmissione leggermente più veloce farà in modo che la il buffer seriale non trabocca gradualmente.

Ci sarà una piccola pausa tra i blocchi di dati seriali (millisecondi) ma questo non dovrebbe essere percepibile.

MODIFICA: si presume che si disponga di una velocità di animazione fissa.

Answer 4

Si è dovuto inserire i dati su un registratore a banda termica seriale una volta (molto simile a una stampante di ricevute) e aveva lo stesso tipo di problemi. Qualsiasi ritardo nei dati ha causato salti nell'output stampato che sono inaccettabili.

La soluzione è molto semplice: se si conservano i dati nel buffer seriale del kernel in ogni momento, l'output sarà esattamente (velocità di trasmissione/(1 + bit di dati + stop di bit)) caratteri al secondo. Quindi basta aggiungere un numero sufficiente di byte pad NUL per distanziare i tuoi dati.

Alcuni dispositivi potrebbero fare molto male se vedono NUL byte nei dati, suppongo, nel qual caso questo non funzionerà. Ma molti ignorano semplicemente i byte NUL extra tra i messaggi, il che consente di utilizzare il timer hardware molto accurato all'interno della porta seriale per controllare i tempi.

Answer 5

Ecco un approccio, utilizzando il multi-threading, che è diverso rispetto al mio altra risposta:

ledThread() 
{ 
    while(animating) 
    { 
     queue.pop(packet); 
     writeSerialPacket(packet); 
     flushSerialPacket(); // Blocks until serial buffer is empty 
    } 
} 

animationThread() 
{ 
    time lastFrameTime = now(); 
    time_duration elapsed = 0; 
    while(animating) 
    { 
     buildLedPacket(packet); 
     queue.push(packet); 
     elapsed = lastFrameTime - now(); 
     lastFrameTime = now(); 
     animateNextFrame(elapsed); 
    } 
} 

Nel pseudocodice sopra, la coda è un blocco producer-consumer queue, con una capacità di uno. In altre parole, il produttore bloccherà durante queue.push() mentre la coda non è vuota. Invece di una coda di blocco, è possibile utilizzare anche un buffer "ping-pong" con una variabile di condizione o semaforo.

Ogni frame di animazione viene visualizzato dopo aver trasmesso i dati LED corrispondenti. Il tempo trascorso che la porta seriale impiega per trasmettere un pacchetto viene utilizzato per calcolare il prossimo fotogramma dell'animazione.

Il vantaggio di avere due thread è che è possibile utilizzare la CPU per l'animazione mentre si attende la trasmissione dei dati seriali (la trasmissione di dati seriali non richiede praticamente alcuna CPU).

È difficile descrivere questo materiale multi-threading con solo parole. Vorrei avere una lavagna su cui scrivere. :-)