🚀 go-pugleaf

Leon Zandman <usenet@wirwar.com> wrote:
> Philip Paeps <philip+usenet@paeps.cx> wrote:
> > Ik moet communiceren met een serial device dat een beetje onnozel is: het
> > spreekt geen software flow control en mijn hardware beschikt niet over de
> > nodige draadjes voor hardware flow control (en dat kan ik niet makkelijk
> > veranderen).
>
> Ik heb nu een paar jaar ervaring met het aansturen van apparatuur via een
> seriele aansluitingen (RS232) en heb eigenlijk nog nooit een apparaat gehad
> dat flow control gebruikte!

Ik heb altijd wel xon/xoff kunnen gebruiken.  Het is wel lang geleden dat ik
nog iets met normale hardware flow control ben tegengekomen.

> > Nu moet ik daar wel een "asynchroon" protocol over spreken.  Met andere
> > woorden, ik write() nu iets en het device stuurt data terug, maar ik wil
> > die pas binnen een paar seconden/minuten read()en.  Zonder flow control
> > kan ik me niet meteen een manier verzinnen om dat te implementeren.
>
> Zolang je niets read() op die seriel poort blijft de data meestal wel staan,
> dus je kunt in theorie gewoon na een paar minuten alsnog het antwoord
> opvragen. Maar er zijn natuurlijk betere oplossingen.

Dat dacht ik ook.  Jammer genoeg blijkt dat op mijn platform niet het geval te
zijn.  Even getest met een quick&dirty test applicatie.  Nu zijn op de CPU die
ik gebruik de UARTs wel duidelijk als een "afterthought" aangehackt dus dit
verbaast me in het geheel niet.  Bij gelegenheid nog eens in de device driver
duiken om te zien of er nog wat schort, maar ik ben die code al lang moe. ;-)

> > Een mogelijkheid zou zijn om voor mijn write() een thread af te vuren die
> > select() en read() in een buffer en mijn higher level "read" die buffer te
> > laten lezen.  Dat is echter een tamelijk dure oplossing.
>
> Zo doe ik het meestal wel. Alleen maak ik niet per request een nieuwe thread
> aan, maar heb ik een algemene receive-thread beschikbaar.

Zo heb ik dit nu ge�mplementeerd.  Dit spaart me ook een paar context switchen
voor open()/close() per request.  Het maakt het buffer-management een beetje
lastiger, maar al bij al valt het tamelijk goed mee.  Ik heb nog "ergens" een
kleine 9ms latency zitten.  Die krijg ik morgen wel klein.

> Soms laat ik deze continu de seriel poort in de gaten houden en soms
> activeer ik 'm pas nadat ik iets verzonden heb.

Mmm, dat activeren en deactiveren lijkt me een goed idee.  Doe je dit met een
wait condition of met een soort pipe?

> [...]
> Als je de zaken goed synchroniseert (kritieke sectie/mutex o.i.d.) dan moet
> dat geen probleem zijn. Je kunt ook de receive-thread laten kijken of de
> data in de buffer aan bepaalde voorwaarden voldoet, zoals bijv. kijken of er
> een terminator-character aanwezig is. Indien dit het geval is, dan kun je
> het relevante stuk uit de buffer middels een event/message aan je main
> thread presenteren.

Synchronizatie zit redelijk goed in elkaar.  Het protocol is echter by design
tamelijk 'liberaal' op vlak van data -- eigenlijk is het helemaal mijn zaak
niet hoe de data er uit ziet.  Ik moet ze unmangled uit de poort sleuren en
unmangled mijn applicatie doorduwen.

Thanks voor de tips!

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  The most important item in an order will no longer
  be available.