Sida 1 av 3
Digitala utgånar från PC
Postat: 29 april 2007, 15:39:37
av d98mp
Som en del i ett större projekt vill jag kunna styra fyra knappar från mitt program i PC:n med en uppdateringsfrekvens på 1-10ms. Knapparna kortsluter jag med optokopplare, så allt jag behöver är fyra ledningar som kan vara på eller av. Efter att ha surfat runt en hel del verkar det som om man måste använda en slägga för att slå i en spik.
Serieporten vill jag egentligen inte använda eftersom den ju är på väg bort. Att använda USB verkar dock vara mycket omständigt och till slut kom jag på att en PIC16F628 (som jag har liggande) har en USART-modul. Det här känns som den enklaste lösningen och det finns ju adaptrar mellan USB och serieport.
Har jag missat någon enkel lösning? Att använda en extra mikroprocessor för att sätta fyra digitala utgångar känns som övervåld. Fullösningar med RTD och CTS känns osäkra.
Någon som använt USB? Är det så krångligt som det verkar (dvs är uppstartsträckan lång för att kunna skicka en byte till en PIC jämfört med att använda serieporten)?
Någon annan kommentar eller rekommendation?
Postat: 29 april 2007, 15:43:39
av LaRdA
Att använda paralellporten hade varit en möjlighet eftersom den är ganska lätt att styra direkt, men eftersom den också är påväg bort så går inte det.
Postat: 29 april 2007, 17:10:57
av v-g
En sån där USB-->seriell krets sen en trevlig PIC kanske.
Postat: 29 april 2007, 20:29:46
av vfr
Jag tycker att du är helt på rätt väg. Finns det parallellport så är det klart enklast. I annat fall gör man som du säger, bygger den för serieport med en mikrokontroller. Har man serieport så använder man den, annars kör man USB-omvandlare för serieport. Då är det bra att köra "riktig" seriekommunikation med att sända tecken istället för bara RTS/DTR etc.
Vill man ha lite mer komplicerad timing på signalerna än bara av/på, så är det oftast enda möjligheten då RTS/DTR-styrning är svår att få timing på över USB.
Postat: 29 april 2007, 20:40:33
av Tengil
Det finns PIC18 mcu's som har inbyggd USB. Sedan finns det standarddrivrutiner som gör så att du kan kommunicera över USB precis på samma sätt som du skulle göra om det vore en COM-port. Drivarna mappar USB'n till en virituell COM port.
Postat: 4 maj 2007, 10:45:48
av Daniel Ahlin
Jag skulle slaktat ett USB tangentbord. Då får du massor knappar och det är enkelt att skriva mjukvaran.
När du skriver digitala utgångar och knappar i samma mening blir jag fundersam, förutsätter att det är ingångar du menar.
Postat: 4 maj 2007, 16:31:49
av sebastiannielsen
Nej, han menar att han vill styra 4 knappar via mjukvara.
Dvs han har ersatt 4 knappar med 4 optokopplare, och sedan vill han styra dessa optokopplare via datorn.
RTS/DTR är ingen fullösning. Alla signaler stöds i USB<->RS232-adaptrar, det kan dock finnas några få som inte stöder RI-ingången (men RI är en interrupt som måste rensas vid avläsning, vilket gör det svårare att läsa av vilken status den har just nu)
Däremot är bitbangning via TX en "fullösning", eftersom många USB<->RS232-omvandlare stöder inte bitbangning via TX.
2 st USB<->RS232-omvandlare räcker för att få 4 utgångar (DTR + RTS på varje)
Eller om du bara behöver trycka in en knapp åt gången så kan du använda dig av en 4017 för att stega sig fram till den knapp man vill aktivera, och sedan aktivera den helt enkelt, med hjälp av 4 st AND-grindar.
Då kan det vara bra att koppla 1:an på 4017:en till CTS, CD eller DSR (utan AND-grind emellan), så man i mjukvara kan läsa av var 4017:en befinner sig. (man stegar 4017 fram tills man får en etta in på var man nu har kopplat den, och då vet man att 4017:en befinner sig vid ett)
Om du måste trycka ner flera knappar åt gången, så kan du använda dig av 4017 samt 4 st flipflops. Knapparna blir då dubbeltrycksknappar.
Man kan då koppla 2 av varje till OR-grindar, och så kan man i mjukvara läsa av om någon/båda av knapp 1&2 är aktiverad, eller om alla är oaktiverade. Samma gäller 3&4
Postat: 4 maj 2007, 17:41:05
av sodjan
sebastiannielsen> Alla signaler stöds i USB<->RS232-adaptrar...
Jo, men det kan vara svårt att uppnå :
d98mp> med en uppdateringsfrekvens på 1-10ms
med någon slags garanti...
Postat: 4 maj 2007, 17:45:58
av sebastiannielsen
10ms går säkert bra även med USB<->RS232-adapter. VB.NET-kod körs mycket snabbare än 10ms.
Postat: 4 maj 2007, 17:57:58
av sodjan
Alltid ? Helt oavsett vad koden gör ?
Det var inte illa...
Sen tror jag att problemet (om något) ligger
i drivrutinerna och USB "lagret", inte i applikations
nivån...
Nu hjälper det ju inte med 10 ms i alla fall..
Postat: 4 maj 2007, 19:37:42
av arvidb
sebastiannielsen:10ms går säkert bra även med USB<->RS232-adapter. VB.NET-kod körs mycket snabbare än 10ms.
Du borde läsa på lite om pre-emptive multitasking...
I Windows kan man inte räkna med större noggrannhet än ca 10-100 ms mellan två rader kod, eller t.o.m. inom en rad kod om kommandot inte är atomiskt (d.v.s. motsvarar exakt ett maskinkodskommando).
Arvid
Postat: 4 maj 2007, 21:29:25
av xxargs
speciellt inte om man skall igenom ett tjockt lager USB-protokoll med transaktionshanterare etc.
det går inte tillnärmelsevis ha samma tidskontroll på USB-RS232 som man kanske är van med mot äldre datorers UART - detta kan ingen VB-program eller annan programspråk i världen göra något åt då tidstjuven är oförutsägbar och djupt inne i själva OS:t
vi har labbrylar som använder RS232 med HPVEE och är i pricip omöjliga att använda i snabb och säker takt med USB-RS232 då varje transaktion mot USB-RS232 tar 50-60 ms även för enstaka tecken och omedelbar svar, på något som går ytterst smidigt och med goda marginaler med gamla UART-baserade RS232.
Postat: 4 maj 2007, 22:06:06
av TomasL
En PC oavsett operativ, inte ens med gamla DOS, är speciellt bra för realtidsapplikationer.
Postat: 4 maj 2007, 22:11:13
av sodjan
Och inget OS (eller annan typ av plattform) kan bedömas innan man
definierar vad man menar med "realtid"...

Postat: 4 maj 2007, 22:19:56
av TomasL
Nja, är inte realtid just realtid, dvs händer just nu, om jag i programmet skall sätta en port och det skall hända direkt är väl det realtid, allt annat är väl i princip inte realtid.
Vad jag menar med föregående inlägg, en pc är oerhört dålig på att hantera portar och övrig hårdvara, just pga att det är en pc, IO hanteras via DMA, instruktions och data cache gör att du aldrig kan vara riktigt säker på om det du vill hända nu, verkligen händer nu.
Till exempel, om man skall hantera IO-portar direkt, måste man flusha cachen vid varje access, och det tar ju lite tid.