Sleep() è un disegno errato, ma sembra essere la mia unica opzione

Question

Sto scrivendo una classe IO per caricare/scaricare file su un controller su seriale RS-232. Sfortunatamente, non posso inviare un intero file tutto in una volta, devo dividerlo in pacchetti e inviarlo un po 'alla volta. Ecco l'approccio di base ...

ifstream file ("path/to/file.ext", ios::in | ios::binary); 

while(!file.eof()) 
{ 
    //... zero buffer, and add packet header (8 bytes) 
    size_t nResult = file.read(&buffer[8], 129); 
    Serial.Write(buffer, nResult+8); 
    //... see if controller wrote anything to the serial port and process it's command 
    Sleep(600); 
} 

So che l'uso di sonno() non è una buona pratica di progettazione, ma se mi tolgo la dichiarazione di sonno() o addirittura ridurre il tempo di quantità del ciclo dorme, il regolatore genera errori sul fatto che il buffer è pieno e il trasferimento fallisce. C'è un modo migliore per farlo?

Prima di dirlo, no non posso inviare un messaggio al controller per determinare se è pronto per il pacchetto successivo. Non ha quella funzionalità.

Modifica: "cieca" Ho dimenticato di dire che l'intervallo in cui sto avendo a dormire è un po ' Le specifiche del protocollo fornite dal produttore non forniscono dettagli sui tempi necessari tra i pacchetti. Quindi ho dovuto determinare quel valore per tentativi ed errori. Ho paura che potrebbe non funzionare su tutti i PC e molto altro in modo che non funzioni su tutti i controller.

Questo sviluppo è in corso per Windows XP/Vista/7.

Modifica # 2: Inoltre, la quantità di dati per pacchetto è in realtà anche un'indagine su tentativi ed errori. La specifica del protocollo consente di pacchetti di 65.535 byte (inclusa l'intestazione). Ma se si inviano più di 129 byte alla volta, si iniziano a vedere i problemi dove a volte funziona e talvolta no. Sembra anche esserci una relazione tra il tempo che devi dormire e la quantità di byte che puoi inviare. Se rilascio la dimensione del pacchetto fino a 20 byte per pacchetto, posso ridurre il tempo di sospensione a 400 millisecondi. Credo che la ragione di questi problemi derivi dal tempo impiegato dal controller per spostare i dati dal suo buffer al file.

Answer 1

Quello che stai facendo è chiamato sincronizzazione del ciclo cieco. Non è necessariamente un cattivo design. Se il tuo dispositivo non ha la funzionalità per indicare che è pronto per altri dati o meno, questo è l'unico modo per farlo.

È comune che i dispositivi specifichino una velocità di trasmissione dati massima o una quantità minima di tempo tra i byte.

Penso che l'idea di questa pratica scorretta derivi da casi in cui si seleziona ciecamente un valore di ritardo (le prestazioni ne risentiranno se è maggiore di quanto deve essere), se si dispone di metodi di sincronizzazione migliori disponibili o se si è utilizzando i ritardi per coprire i problemi di temporizzazione (ad esempio, in un'applicazione multithread).

Answer 2

Un'altra ragione per cui Sleep potrebbe non essere la cosa giusta è che si desideri che la funzionalità si chiuda anticipatamente. Se invece lo hai fatto

WaitForSingleObject(hTerminatingEvent, 600); 

Si potrebbe avere un altro thread per segnalare l'evento che si desidera chiudere e terminare anticipatamente. (In questo caso questa chiamata di funzione continuerà dopo 600 ms anche se l'evento non viene segnalato.)

Answer 3

Su Windows, utilizzerei un timer attendibile per questo invece di Sleep(), ma se l'hardware ha bisogno di ritardi, quindi avrai bisogno di ritardi