Non so, andrebbe studiato un pò meglio. Innanzitutto la usleep causa uno sleep effettivo di almeno 1 ms, che è il tick dello scheduler; nel tuo caso, visto l'intervallo esiguo di attesa, avrebbe forse più senso un busy-loop o l'utilizzo del timer rtc (in entrambi i casi, eventualmente con scheduler RR). Metterei anche due bit di stop invece di uno, introduci a costo 0 un ulteriore ritardo di 100us tra i byte. Se non funziona, allora hai un problema da qualche altra parte!
Nota inoltre che questa condizione
Quote:
|
No longer than 6 ms must elapse between two bytes within a telegram sent to the LMS 2xx, otherwise a timeout is detected.
|
rischia di non essere soddisfatta sui kernel 2.4. Per me l'intero "telegram" dovrebbe essere inviato dalla uart, quindi scritto con una unica write. Cercherei di farlo funzionare in questo modo, se ci riesci.
Ricapitolando, per me dovresti:
- due bit di stop
- invio di un "telegram" intero con una unica write (se il telegram è "piccolo", di pochi byte, entra completamente nel buffer della uart; altrimenti devi usare più write con delle poll per controllare lo stato del buffer)
- eventuale attesa tra l'invio di più "telegram". tcdrain può esserti di aiuto qui, per evitare usleep con valori "magici".