Digitala utgånar från PC
Digitala utgånar från PC
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?
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?
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.
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.
-
- Inlägg: 35
- Blev medlem: 18 januari 2006, 21:36:14
-
- Inlägg: 3663
- Blev medlem: 11 september 2004, 09:30:42
- Ort: gbg
- Kontakt:
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
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
-
- Inlägg: 3663
- Blev medlem: 11 september 2004, 09:30:42
- Ort: gbg
- Kontakt:
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
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
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.
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.
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.
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.