Jag har kopplat in en Atmega128 till en USB-modul som heter UM232R. Nu har jag kopplat rxd -> txd och vice versa. Det fungerar att skicka data från AVRen till USB-modulen och läsa av detta i ett terminalfönster på datorn.
I manualen till UM232R står det att man ska koppla in CTS# och RTS# till två pinnar på mikrokontrollern för att ha hårdvaruhandskakning. Dessa har jag alltså inte kopplat in men det funkar ändå.
Nu håller jag på att CADa upp ett kretskort för hela härligheten och funderar på om man behöver RTS/CTS inkopplade. Jag slipper gärna det och använder pinnarna till andra saker. Dock har jag ju inte testat att skicka data från PCn till AVRen ännu, och jag har inte möjlighet att testa det innan jag etsar kortet.
Kan jag med gott samvete skita i CTS/RTS?
När vill man använda hårdvaruhandskakining? Jag hittar inget om det i manualen till Atmega128. Jag har även sökt runt lite på UART hardware handshaking utan att hitta nåt relevant.
Atmega128, UART, hårdvaruhandskaking?
Det beror på vilken hastighet som körs och hur mycket annat det är att göra. I många fall behöver man inte det för mikrokontrollers, men antingen får du testa, eller räkna på det. D.v.s hur långa tider mellan tecknen kan din kontroller vara "borta" och inte hantera nya inkommande tecken?
Kör man med avbrott och inte har svinhög baudrate så brukar det inte vara några problem.
Kör man med avbrott och inte har svinhög baudrate så brukar det inte vara några problem.
så då kan man anta att det funkar åt andra hållet när det funkade åt första...
Jag skall egentligen bara använda USB-funktionen ganska sällan. Det är till en datalogger som sparar allt på ett SD-kort och sen tankar man över det till datorn via USB när man behöver. Så det gör ju kanske inte så mkt om det inte går med högsta hastighet.
Jag skall egentligen bara använda USB-funktionen ganska sällan. Det är till en datalogger som sparar allt på ett SD-kort och sen tankar man över det till datorn via USB när man behöver. Så det gör ju kanske inte så mkt om det inte går med högsta hastighet.
Så vitt jag vet så har inte AVR eller PIC någon inbyggd hårdvaruhandskakning
i själva USART'en, utan det får byggas in i den programvara som driver USART'en.
Ett annat sätt för att slippa de extra ledningarna är att köra med Xon/Xoff
fködeskontroll, det är tillräckligt standardiserat så att det stöds av det mesta,
t.ex drivrutinerna till vanliga COM portar i Windows. OCh det fungerar
utmärkt över t.ex länkar med radiomoduler eller IR. Eller att ACK-protokoll,
men det slöar ner överföringen även när det igentligen inte behövs. Xon/Xoff
skickas bara när det är nödvändigt.
> Har man en avbrottsdriven mottagning med en buffert så är det sällan som
> det behövs om man håller sig till hastigheter runt 9600.
Väldigt svårt att generallisera på det där sättet. Det är helt beroende på vad
som ska "göras" med datat och mycket mindre att göra med den faktiska
hastigheten på förbindelsen.
i själva USART'en, utan det får byggas in i den programvara som driver USART'en.
Ett annat sätt för att slippa de extra ledningarna är att köra med Xon/Xoff
fködeskontroll, det är tillräckligt standardiserat så att det stöds av det mesta,
t.ex drivrutinerna till vanliga COM portar i Windows. OCh det fungerar
utmärkt över t.ex länkar med radiomoduler eller IR. Eller att ACK-protokoll,
men det slöar ner överföringen även när det igentligen inte behövs. Xon/Xoff
skickas bara när det är nödvändigt.
> Har man en avbrottsdriven mottagning med en buffert så är det sällan som
> det behövs om man håller sig till hastigheter runt 9600.
Väldigt svårt att generallisera på det där sättet. Det är helt beroende på vad
som ska "göras" med datat och mycket mindre att göra med den faktiska
hastigheten på förbindelsen.
-
Swech
- EF Sponsor
- Inlägg: 4750
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
mega128 an har gott om RAM så att lägga upp en buffer och
ta hand om eventuella stora block med data är inget problem.
Du har m.a.o en kort och snabb interruptruting som bara fyller på
din buffer.
Antar att du inte skall skicka data kontinuerligt i riktigt stora mängder...
Det nämns 9600 baud. Men hur fort skall du köra egentligen?
Är det inga extrema hastigheter så kan du strunta i CTS/RTS
Swech
ta hand om eventuella stora block med data är inget problem.
Du har m.a.o en kort och snabb interruptruting som bara fyller på
din buffer.
Antar att du inte skall skicka data kontinuerligt i riktigt stora mängder...
Det nämns 9600 baud. Men hur fort skall du köra egentligen?
Är det inga extrema hastigheter så kan du strunta i CTS/RTS
Swech
Det var därför jag skrev "väldigt sällan".' Det finns mängder med konstruktioner som snackar serie-data via bara tre trådar och som sällan har problem. Eller alla prylar som snackar via IrDa.sodjan skrev: > Har man en avbrottsdriven mottagning med en buffert så är det sällan som
> det behövs om man håller sig till hastigheter runt 9600.
Väldigt svårt att generallisera på det där sättet. Det är helt beroende på vad
som ska "göras" med datat och mycket mindre att göra med den faktiska
hastigheten på förbindelsen.
Grejen är ju att RTS/CTS egentligen bara fungerar åt ena hållet, RS-232 är ju inte gjort för "två datorer" utan för "en dator och en terminal" eller möjligen "en dator och ett modem".
Som jag tolkar det hela här så ska megan dessutom främst sända data? Och då blir ju plötsligt megans förmåga att ta emot data något som blir ganska ointressant.
Megan skall sända en ganska stor mängd data när man tömmer loggen. Ca 1GB eller så. Men när man gör det behöver den inte syssla med annat så det gör inget att det tar resurser. Sen skall även ta emot data i form av konfigurationsparametrar vid justering av systemet och även då behöver den ju inte göra annat.
När systemet går som vanligt så skall data loggas ca var 5e till 10e sekund till SD-kortet via SPI. Data tas även in från en GPS-modul via den andra USARTen. Sen är det en display och lite knappar men det är ju inte en så beräkningsintensiv manick så det finns nog resurser över.
Jag skippar nog RTS/CTS och löser eventuella problem med Xon/Xoff. Tack för all hjälp!
När systemet går som vanligt så skall data loggas ca var 5e till 10e sekund till SD-kortet via SPI. Data tas även in från en GPS-modul via den andra USARTen. Sen är det en display och lite knappar men det är ju inte en så beräkningsintensiv manick så det finns nog resurser över.
Jag skippar nog RTS/CTS och löser eventuella problem med Xon/Xoff. Tack för all hjälp!
> Det finns mängder med konstruktioner som snackar serie-data via bara tre trådar
Självklart, men det betyder inte att det alltid saknas handskakning i dessa fall,
den sker bara inte med hårdvarusignalerna.
> Det nämns 9600 baud. Men hur fort skall du köra egentligen?
> Är det inga extrema hastigheter så kan du strunta i CTS/RTS
Här hänger jag inte med. Vad har baudraten med eventuellt behov av
hårdvaruhandskaning att göra ? Antingen så hinner man läsa ett tecken
från USART'en innan nästa har kommit in, eller så gör man det inte.
Om man kör så fort att man inte hinner läsa tecknen så hinner man
sannolikt inte heller hantera CTS/RTS, dessa är främst till för att styra
flödet över lite lägre tid (än tiden mellan två tecken). Typ nivåreglering
av en buffert. Och då har det större betydelse hur snabbt (rellativt överföringen)
som datat i bufferten bearbetas.
> Jag skippar nog RTS/CTS och löser eventuella problem med Xon/Xoff.
Om du har kontroll över båda ändar av kommunikationen så är det sannolikt
en vettig lösning. I dag så är det nog väldigt sällan som man bygger bytt
med hårdvaruhandskakning...
> Megan skall sända en ganska stor mängd data när man tömmer loggen...
Då är det alltså inte processorn utan andra änden (en PC?) som måste "hänga med".
Jag antar att du sänder i någon slags block och har någon ACK-liknande
protokoll för att hantera eventuella omsändningar o.s.v....
Självklart, men det betyder inte att det alltid saknas handskakning i dessa fall,
den sker bara inte med hårdvarusignalerna.
> Det nämns 9600 baud. Men hur fort skall du köra egentligen?
> Är det inga extrema hastigheter så kan du strunta i CTS/RTS
Här hänger jag inte med. Vad har baudraten med eventuellt behov av
hårdvaruhandskaning att göra ? Antingen så hinner man läsa ett tecken
från USART'en innan nästa har kommit in, eller så gör man det inte.
Om man kör så fort att man inte hinner läsa tecknen så hinner man
sannolikt inte heller hantera CTS/RTS, dessa är främst till för att styra
flödet över lite lägre tid (än tiden mellan två tecken). Typ nivåreglering
av en buffert. Och då har det större betydelse hur snabbt (rellativt överföringen)
som datat i bufferten bearbetas.
> Jag skippar nog RTS/CTS och löser eventuella problem med Xon/Xoff.
Om du har kontroll över båda ändar av kommunikationen så är det sannolikt
en vettig lösning. I dag så är det nog väldigt sällan som man bygger bytt
med hårdvaruhandskakning...
> Megan skall sända en ganska stor mängd data när man tömmer loggen...
Då är det alltså inte processorn utan andra änden (en PC?) som måste "hänga med".
Jag antar att du sänder i någon slags block och har någon ACK-liknande
protokoll för att hantera eventuella omsändningar o.s.v....
I nuläget har jag bara testat att ta in datan till terminalfönster och det funkar ju. Tanken är att jag i framtiden skall göra PC-mjukvara som tar emot datan, lagrar den och presenterar den. Jag har alltså kontroll över båda ändar av kommunikationen.
Alla vekar iaf vara överens om att hårdvaruhandskakning inte är nödvändigt.
Det är för övrigt detta system frågan gäller.
Alla vekar iaf vara överens om att hårdvaruhandskakning inte är nödvändigt.
Det är för övrigt detta system frågan gäller.
