Är det en loop som läser av värdet på COMporten?

[Al_Bundy]

Hej!

Jag undrar om man ska ha en loop som hela tiden läser av comporten om man håller på med kommunikation? Ta t.ex tangentbord. Så fort jag skriver denna test så måste väll datorn registera detta direkt? Är det en loop som hela tiden läser av eller är det en funktion som läser av så fort den får känning att något står där ute och knackar på USB porten?

[Klas-Kenny]

Läs på om interrupt.

[sodjan]

Om du menar en vanlig Windows PC så är det ganska komplext.
Det kan vara kombinationer av pollning och interrupt. Sen är det
ju väldig stor skillnad mellan då din egen applikation läser från en
COM port och då Windows hanterar tangentbord (och mus).

Om du studerar Windows API dokumentationen så är det
möjligt att du kan registrera ett interrupt från COM porten
till din egen applikation, men det vanliga är nog pollning.

Om du menar en emulerad COM port via USB så blir det
extra komplext med fler lager med i spelet.

Jag har också för mig att jag har sett avancerade debug verktyg
som spelar in hur system-meddelanden går fram och tillbaka i Windows.

Men vad är det som är problemet?
Vad har du för faktiskt exempel?

[svanted]

kan det vara så att detta forum är bättre än all kunskap som redan finns på internet?

[Nerre]

Det "fiffigaste" är väl att först ha en hårdvaruinterrupt som läser ett tecken från serieporten och stoppar in det i en buffert, sen får ens program (antingen via nån form av interrupt, timer eller "mjukvaru", eller genom pollning) signal om att det finns data att läsa. Så länge bufferten inte blir full så gör det inget om programmet inte läser data direkt.

På en PC har ju UART idag oftast en inbyggd buffert (16 bytes är det väl?) och det finns interrupt både för "tecken mottaget" och "bufferten börjar bli full" (har för mig att man med 16550 kan sätta gränsen för "bufferten börjar bli full" till några olika värden). På DOS-tiden så fick programmen läsa direkt från UART, men under Windows tror jag att kerneln har en större buffert dit data läses och som sen programmet läser från.

Under Windows har jag bara använt Visual Basic och där finns ett event som heter nåt i stil med onComReceive() som man helt enkelt hookar.

[Al_Bundy]

Om du menar en vanlig Windows PC så är det ganska komplext.
Det kan vara kombinationer av pollning och interrupt. Sen är det
ju väldig stor skillnad mellan då din egen applikation läser från en
COM port och då Windows hanterar tangentbord (och mus).

Om du studerar Windows API dokumentationen så är det
möjligt att du kan registrera ett interrupt från COM porten
till din egen applikation, men det vanliga är nog pollning.

Om du menar en emulerad COM port via USB så blir det
extra komplext med fler lager med i spelet.

Jag har också för mig att jag har sett avancerade debug verktyg
som spelar in hur system-meddelanden går fram och tillbaka i Windows.

Men vad är det som är problemet?
Vad har du för faktiskt exempel?

Alltså var det som jag trodde. En loop körs som hela tiden kolla om det finns en storlek av bytes som vill komma in igenom COM porten

Det är inget problem. Jag bara undrar för att veta hur jag ska bygga ett program som tar emot värden hela tiden.

[Al_Bundy]

Det "fiffigaste" är väl att först ha en hårdvaruinterrupt som läser ett tecken från serieporten och stoppar in det i en buffert, sen får ens program (antingen via nån form av interrupt, timer eller "mjukvaru", eller genom pollning) signal om att det finns data att läsa. Så länge bufferten inte blir full så gör det inget om programmet inte läser data direkt.

På en PC har ju UART idag oftast en inbyggd buffert (16 bytes är det väl?) och det finns interrupt både för "tecken mottaget" och "bufferten börjar bli full" (har för mig att man med 16550 kan sätta gränsen för "bufferten börjar bli full" till några olika värden). På DOS-tiden så fick programmen läsa direkt från UART, men under Windows tror jag att kerneln har en större buffert dit data läses och som sen programmet läser från.

Under Windows har jag bara använt Visual Basic och där finns ett event som heter nåt i stil med onComReceive() som man helt enkelt hookar.

Jag har haft problem med bufferten när jag körde kommunikation mellan ATmega och PC. Kunskapens centrum som cirkulerar här i forumet, hävdade att det var min kod som var fel på, men verkligheten visade sig något annat Min PC tog emot värden när jag bad den göra det. Jag måste programmera så att min dator tar emot värden hela tiden. Alltså en loop som kollar "någon här??".

Är det Visual Basic eller .NET du menar?

[Mr Andersson]

Om du skickar mer data än mottagaren kan/vill ta emot så är det ju felprogrammerat. Sen kan man ju argumentera ifall felet är på PC- eller MCU-sidan, dock kvarstår ju att det är ett fel som måste lösas.

MSDN - Serial Communications
Exempelkoden är C men det är ju inga problem att översätta till valfritt annat språk som kan anropa win32 API:t.

[Icecap]

Al: "Min PC tog emot värden när jag bad den göra det"
Men självklart! Och du menar att din Arduino matade på med data när det inte behövdes?

Så slutresultatet är att det är din programmering som är helt fel!

Ska det bara ges data när det behövs får man ena sidan att skicka ett "jag vill ha en gång data nu"-paket och andra ändan svarar med "Jepp, här kommer det data". Och detta upprepar man så ofta som det behövs.

Fungerar inte det använder man istället handskakningen som finns med i en seriell port, alltså speciellt CTS-signalen från mottagande enhet. Är den aktiv är det OK att skicka data, är den inaktiv ska man låta bli.

[svanted]

Jag har haft problem med bufferten när jag körde kommunikation mellan ATmega och PC. Kunskapens centrum som cirkulerar här i forumet, hävdade att det var min kod som var fel på, men verkligheten visade sig något annat Min PC tog emot värden när jag bad den göra det. Jag måste programmera så att min dator tar emot värden hela tiden. Alltså en loop som kollar "någon här??".

är inte programmet i pcn "din kod"?

[Al_Bundy]

Nej. Vi är olika subgrupper som jobbar med varandra. Jag är på hårdvarusidan och resten är på PC:sidan. Jag vet inte exakt vad dom håller på med, men jag vet om att de har inte lyckats få kunna ta emot alla värden jag skickar, bara ett.

[Al_Bundy]

Al: "Min PC tog emot värden när jag bad den göra det"
Men självklart! Och du menar att din Arduino matade på med data när det inte behövdes?

Så slutresultatet är att det är din programmering som är helt fel!

Ska det bara ges data när det behövs får man ena sidan att skicka ett "jag vill ha en gång data nu"-paket och andra ändan svarar med "Jepp, här kommer det data". Och detta upprepar man så ofta som det behövs.

Fungerar inte det använder man istället handskakningen som finns med i en seriell port, alltså speciellt CTS-signalen från mottagande enhet. Är den aktiv är det OK att skicka data, är den inaktiv ska man låta bli.

Hur menar du med handskakningen? Jag har kopplat mitt RTS# till RESET på min AVR, bara för att kunna få auto-reset. Finns det någon handskakning till USB också? För jag ser bara V+, GND, DATA-, DATA+ på USB 2.0.

Är det de handskakning är till för? Att man signalerar "Nu kommer det något. Var beredd!"?

Om du skickar mer data än mottagaren kan/vill ta emot så är det ju felprogrammerat. Sen kan man ju argumentera ifall felet är på PC- eller MCU-sidan, dock kvarstår ju att det är ett fel som måste lösas.

MSDN - Serial Communications
Exempelkoden är C men det är ju inga problem att översätta till valfritt annat språk som kan anropa win32 API:t.

Du hittade en artikeln från 1995! Inte alla gånger man hittar en sådan.

[sodjan]

Ja, det skrev generellt bättre dokumentation förr i tiden.
Det vanliga idag är korta, otydliga och okompletta saker.
Principerna kring seriell kommunikation är ju mycket äldre.

> Hur menar du med handskakningen?

I den seriella kommunikationen. USB är ointressant, det
är bara en transport, kunde lika gärna vara en vanlig kabel.
Varken din AVR eller PC-programmet har en susning om att
det finns en USB länk med i bilden.

> Jag har kopplat mitt RTS# till RESET på min AVR...

Ja, det är ju en specialösning som fungerar vid programmering
av Arduino eftersom de har löst handskakningen i programmerings
protokollet som används. Men det var ju inte det som det gäller här.

Allt pekar på att du måste se över hela din kommunikation. Du kan nog
inte bara kan sända från AVR sidan "blint" utan handskakning. Antingen
väntar AVR'en på en begäran om data och skickar då senaste mätvärdet
(AVR'en kan ju i alla fall ligga och ta nya mätvärden hela tiden). Eller så
skickar du ett värde och när det har lästs så kommer det ett "ACK" och
AVR'en kan skicka ett nytt. Men första förslaget låter bättre, att skicka
på begäran.

Om du bara ligger och kör data rakt "ut i luften", så kommer det förr eller
senare att gå fel. Och som sagt, USB har inget direkt med detta att göra.

[Al_Bundy]

Men kan man verkligen ha handskakning på USB som AVR:en kan kontrollera?
Handskakningen är väll till för att anropa/förvarna att något kommer och motsidan måste vara beredd?

Jag har en idé. När min AVR skickar ett värde så är datorn redo att ta emot. När datorn har tagit emot så skickar den tillbaka ett "OK" värde och då väntar AVR:en på att få emot detta värde efter AVR:en har skickat ett värde. När AVR:en har fått "OK" så skickar den ett nytt värde och samtidigt väntar datorn på detta värde.

Fram och tillbaka, fram och tillbaka...

[sodjan]

> Men kan man verkligen ha handskakning på USB som AVR:en kan kontrollera?

Hårdvaruhandskakning kan vara pyssligt.
Programvaruhandskakning är självklart inget som helst problem,
det är helt oberoende av hur "linjen" ser ut mellan de två parterna
och du har 100% kontroll i din egen kod över det.

> Handskakningen är väll till för att anropa/förvarna att något kommer och motsidan måste vara beredd?

Nej, det skulle jag inte säga. Det är som att ropa till någon och kasta en boll samtidigt
utan att kontrollera att mottagaran är beredd. Det är ingen handskakning. Du måste
vänta tills ("skaka hand" med) mottagaren faktiskt säger att han *är* beredd.