[VC++]Welke methode gebruiken voor monitoren com-poortknopje

[Rockster]

Hallo,

Over een weekje hoop ik mijn mooie Grafische LCD te ontvangen, en ik ben bezig om er zelf een soort van aansturingsprogramma voor te schrijven. Ik heb al redelijk wat ervaring in Pascal, maar vanwege mijn studie wil ik het nu in VC++ gaan doen. Nu zit ik met de volgende vraag:

Op mijn nog te fabriceren mp3-bak komen control-knopjes voor winamp, die ik wil aansluiten op de com-poort. Ik wil een goede respons, dus ik moet niet het knopje 100 ms ingedrukt hoeven houden zodat het programma wat gaat doen

Nu heb ik me al de hele dag het hoofd zitten breken over hoe ik dit nu wil gaan oplossen, zelf had ik de volgende 3 ideeen:

1. Alles in een while loop gooien, lcd updaten, knopjesstatus uitlezen en acties uitvoeren, over and over again (=100% cpu belasting...). Volgens mij zijn er nettere en efficientere methoden
2. De functie WaitCommEvent uit de windows API gebruiken.
3. Op basis van interrupts werken, hier snap ik dus geen snars van

Ik denk dat ik voor oplossing 2 ga, maar hoe moet ik dit implementeren? ik dacht zelf: 2 threads maken (* Rockster is een noob op dit gebied), de ene update het lcd, en de andere wacht met behulp van WaitCommEvent op een verandering in de status can de knopjes?

Is dit ontwerp een beetje redelijk (of fout ), of zijn er handiger / efficientere methoden?

[farlane]

1 Goed mogelijk, ook zonder 100% CPU belasting. ( Gebruik overlapped communicatie )
2 Lijkt volgens mij erg veel op methode 1. Heb er zelf nog nooit mee gewerkt.
3 Lijkt me moeilijk als het onder Win32 moet draaien

Naar mijn idee hoef je hier geen multithreaded progje van te maken als je overlapped io gebruikt.

[Rockster]

Bill Gates schreef:
One of the many factors to consider when choosing between nonoverlapped and overlapped operations is portability. Overlapped operation is not a good choice because most operating systems do not support it. Most operating systems support some form of multithreading, however, so multithreaded nonoverlapped I/O may be the best choice for portability reasons.

Niet dat ik hem ga verkopen of op meerdere os'es ga draaien(=winXP btw), maar ook het voorbeeld wat daar stond was in feite 1 loop die oneindig vaak herhaald werd, met een WaitForSingleObject erin met een wachttijd van 500 mS, volgens mij is dit ongeveer hetzelfde als polling met een Sleep van 500

Ik denk dat ik toch maar 2 threads ga maken, de ene doet het updaten van de LCD en de ander wacht op een commevent met een WaitForSingleObject wachttijd van INFINITE ofzo

[ Voor 0% gewijzigd door Rockster op 20-11-2002 17:18 . Reden: tiepvout (r) ]

[TheMrH]

Niet dat ik hem ga verkopen of op meerdere os'es ga draaien(=winXP btw), maar ook het voorbeeld wat daar stond was in feite 1 loop die oneindig vaak herhaald werd, met een WaitForSingleObject erin met een wachttijd van 500 mS, volgens mij is dit ongeveer hetzelfde als polling met een Sleep van 500

Dat is niet waar. Bij de 1e methode wacht WaitForSingleObject() maximaal 500ms op een event, en returned dus eerder waneer er een event optreed. De 2e niet, die wacht gewoon sowieso 500ms, dus moet je minimaal zo lang het knopje indrukken...

Het idee van die 2 threads lijkt me verstandig, kijk anders naar het vorobeeld, wel oud maar bruikbaar, van MS zelf: TapiComm. Hierin splitsen ze ook een lees en schrijf thread af ism OverappedIO. Heb ik ook gebruikt voor een communicatie progeseltje wat oa SMSt.
Ik waarschuw wel, er zitten wat vieze dingetjes in, en het is C code. Zelf heb ik het omgeschreven naar C++, amar tis nog steeds nie alles...