ATMega16 + USART +PC [LÖST]
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: ATMega16 + USART +PC
Onekligen knepigt ja. Jag har ju rätt hårdvara uppkopplad och körklar på arbetsbordet, ska se om jag kan testa din kod imorgon.
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: ATMega16 + USART +PC
Jag var tvungen att anpassa koden lite då jag har en mega168, där ska det vara en extra 0:a i många register. Jag kommenterade också bort InitPWM och PWMOutput-funktionerna. MCU:n svarar då varannan gång, alltså varannat tryck på tangentbordet ger en bokstav tillbaka. Sen tog jag bort större delen av loopen i main, allt utom " FanCH = USARTReadChar(); USARTWriteChar(FanCH); ", då får jag en bokstav per tryck som det ska va. Använder terminalprogrammet Minicom för att testa.
Vad händer för dig om du gör samma sak?
Vad händer för dig om du gör samma sak?
Re: ATMega16 + USART +PC
Jag gjorde precis som du sa och fick samma resultat som dig, alltså ett tryck för varje bokstav. funkade fint.
Förstår inte,problemet måste ju sitta i nån av if/switch satserna då eller? men jag ser inte vad det skall vara för fel!?
Testade även mitt egenskrivna program, och fick resultatet jag är ute efter.
edit: Uppdatera med test av eget program
Förstår inte,problemet måste ju sitta i nån av if/switch satserna då eller? men jag ser inte vad det skall vara för fel!?
Testade även mitt egenskrivna program, och fick resultatet jag är ute efter.
Kod: Markera allt
a1a2a3a4a5a6a7a8a9a8a7a6a5a4a3a2a1a0d1d2d3d4d5d6d7d8d9d8d7d6d5d4d3d2d1d0a1a2a3a4a5a4a3d1d2d3d4d5d6d5d4d3
edit: Uppdatera med test av eget program
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: ATMega16 + USART +PC
Som jag skriver, när jag har med if-satserna returneras varannat tecken. Och så ska det vara. Första tecknet tas hand om "FanCH = USARTReadChar(); USARTWriteChar(FanCH); ", det andra av " data = USARTReadChar();" längre ned.
Jag får inte fenomenet att samma tecken kommer många gånger som du fick ovan, så det har nog med timern att göra. Jag har inte testat att aktivera den, registernamnen verkar skilja en del mellan mega16 och 168.
Jag får inte fenomenet att samma tecken kommer många gånger som du fick ovan, så det har nog med timern att göra. Jag har inte testat att aktivera den, registernamnen verkar skilja en del mellan mega16 och 168.
Re: ATMega16 + USART +PC
hmm.
Kanske borde ha nämt innan, inte äns tänkt på det, sitter med en FTDI kabel (TTL-232R-5V) , mellan USB och AVRén, men den blir ju en vanlig com port i datorn, så det borde väl inte göra någon skillnad?
Kanske borde ha nämt innan, inte äns tänkt på det, sitter med en FTDI kabel (TTL-232R-5V) , mellan USB och AVRén, men den blir ju en vanlig com port i datorn, så det borde väl inte göra någon skillnad?
Re: ATMega16 + USART +PC
funkar det nu alltså?
Jag funderar på en sak: ditt program är uppbyggt så att det tar emot olika tecken på olika ställen i programmet. Det kanske kan fungera bra, men ofta kan det också ge upphov till diverse fel eller konstigheter. Antag till exempel att du kommer i otakt med tecknen, så att när du ska skicka ett 'a' så kommer en siffra och tvärt om...?
När jag själv ställdes inför problemet att skicka och ta emot UART första gången så valde jag att göra det interruptstyrt, och att den fyller en liten buffert med tecken ända tills man trycker enter (eller om bufferten blir full). När man tryckt enter så sätter interruptrutinen en flagga. Varje tecken som fyller på bufferten sänds också tillbaks till terminalen som bekräftelse (eko). Jag låter även interruptrutinen ta hand om specialtecken, t.ex. "backspace" ('\b'): den fyller inte på bufferten med detta tecken, utan backar ett steg samt ekar tillbaks sekvensen "\b \b" vilket raderar tecknet på skärmen i terminalprogrammet.
Sedan i "main" så kör jag en evig loop där den så ofta som möjligt kollar av flaggan. Om det är något går jag till en särskild funktion som läser av bufferten och använder bland annat en switch-sats för en massa olika kommandon som bara består av en bokstav... beroende på vilket kommando man skrivit så kan den sedan exempelvis läsa in ett decimaltal från bufferten (från ascii) till en 16-bitars int.
då kan jag skriva t.ex. "a 1000" för att ställa in ett värde på 1000, "z" för att nollställa en räknare, eller "t200" eller "t-20" för att ställa in en temperatur. När funktionerna väl finns färdiga som läser av decimaltal.
Jag har inte koden framför mig, och den är inte föredömlig på något vis, men den har fungerat bra för det mesta. AVR:en reagerar alltså inte förrän man matat in hela raden och tryckt på enter - då kollar den vad man skrivit och utför rätt åtgärd. Jag tycker generellt illa om de typiska read_UART-funktionerna som stoppar processorn tills man matat in ett tecken. Då kan den ju inte göra någonting under tiden utan är låst. Detta avhjälps av att man gör om det till ett interrupt med flagga.
Nu funkade det ju för dig med bara en siffra - 0 till 9, men antag att du behövde mata in ett större tal, från 1 till 255... då måste AVR:en veta när du skrivit färdigt talet (det kan ju bestå av en, två eller tre siffror, och om det kommer in en tvåa kan den ju inte veta om du menar "två" eller om det bara är början på ett längre tal, t.ex. "255". Därför måste man använda sig av till exempel mellanslag eller radslut som tecken på att man skrivit färdigt talet. Så att låta avsluta en inmatning med "enter" är en bra idé.
En annan idé om vi nu håller oss till ditt eget program: antag att du skriver a5 så gör den något, men om du skriver g7 händer inget? Hur ska du veta att den tagit emot och tolkat koden? Då kan du göra så att när du fått in ett godkänt kommando (exempelvis "a7") så svarar AVR:en med att skriva ny rad och "ok".
EN annan sak man kan göra för att förtydliga kommunikationen är att AVR:en skriver ut ny rad och en prompt, ">" (som i DOS/UNIX) när den är redo att ta emot ett kommando. Då får man så att säga klartecken att det är dags att mata in något.
Det finns ju hur mycket som helst egentligen om man vill göra det snyggt och användarvänligt!
Jag funderar på en sak: ditt program är uppbyggt så att det tar emot olika tecken på olika ställen i programmet. Det kanske kan fungera bra, men ofta kan det också ge upphov till diverse fel eller konstigheter. Antag till exempel att du kommer i otakt med tecknen, så att när du ska skicka ett 'a' så kommer en siffra och tvärt om...?
När jag själv ställdes inför problemet att skicka och ta emot UART första gången så valde jag att göra det interruptstyrt, och att den fyller en liten buffert med tecken ända tills man trycker enter (eller om bufferten blir full). När man tryckt enter så sätter interruptrutinen en flagga. Varje tecken som fyller på bufferten sänds också tillbaks till terminalen som bekräftelse (eko). Jag låter även interruptrutinen ta hand om specialtecken, t.ex. "backspace" ('\b'): den fyller inte på bufferten med detta tecken, utan backar ett steg samt ekar tillbaks sekvensen "\b \b" vilket raderar tecknet på skärmen i terminalprogrammet.
Sedan i "main" så kör jag en evig loop där den så ofta som möjligt kollar av flaggan. Om det är något går jag till en särskild funktion som läser av bufferten och använder bland annat en switch-sats för en massa olika kommandon som bara består av en bokstav... beroende på vilket kommando man skrivit så kan den sedan exempelvis läsa in ett decimaltal från bufferten (från ascii) till en 16-bitars int.
då kan jag skriva t.ex. "a 1000" för att ställa in ett värde på 1000, "z" för att nollställa en räknare, eller "t200" eller "t-20" för att ställa in en temperatur. När funktionerna väl finns färdiga som läser av decimaltal.
Jag har inte koden framför mig, och den är inte föredömlig på något vis, men den har fungerat bra för det mesta. AVR:en reagerar alltså inte förrän man matat in hela raden och tryckt på enter - då kollar den vad man skrivit och utför rätt åtgärd. Jag tycker generellt illa om de typiska read_UART-funktionerna som stoppar processorn tills man matat in ett tecken. Då kan den ju inte göra någonting under tiden utan är låst. Detta avhjälps av att man gör om det till ett interrupt med flagga.
Nu funkade det ju för dig med bara en siffra - 0 till 9, men antag att du behövde mata in ett större tal, från 1 till 255... då måste AVR:en veta när du skrivit färdigt talet (det kan ju bestå av en, två eller tre siffror, och om det kommer in en tvåa kan den ju inte veta om du menar "två" eller om det bara är början på ett längre tal, t.ex. "255". Därför måste man använda sig av till exempel mellanslag eller radslut som tecken på att man skrivit färdigt talet. Så att låta avsluta en inmatning med "enter" är en bra idé.
En annan idé om vi nu håller oss till ditt eget program: antag att du skriver a5 så gör den något, men om du skriver g7 händer inget? Hur ska du veta att den tagit emot och tolkat koden? Då kan du göra så att när du fått in ett godkänt kommando (exempelvis "a7") så svarar AVR:en med att skriva ny rad och "ok".
EN annan sak man kan göra för att förtydliga kommunikationen är att AVR:en skriver ut ny rad och en prompt, ">" (som i DOS/UNIX) när den är redo att ta emot ett kommando. Då får man så att säga klartecken att det är dags att mata in något.
Det finns ju hur mycket som helst egentligen om man vill göra det snyggt och användarvänligt!
Re: ATMega16 + USART +PC
Detta kommenterade jag tidigt i tråden men jag minns inte
att du någonsin svarade eller kommenterade på det det :
> En annan sak, du har "_delay_ms(100)" på ett par ställen i koden. Om det körs
> under tiden som överföring pågår, så kan du inte köra snabbare än ca 100 baud
> utan att tappa tecken (du borde få "overflow" i AVR'en, men jag vet inte om du
> testar för det). Varför har du den delay'en där ?
FTDI-kabeln bör vara OK om du använder justa drivers.
att du någonsin svarade eller kommenterade på det det :
> En annan sak, du har "_delay_ms(100)" på ett par ställen i koden. Om det körs
> under tiden som överföring pågår, så kan du inte köra snabbare än ca 100 baud
> utan att tappa tecken (du borde få "overflow" i AVR'en, men jag vet inte om du
> testar för det). Varför har du den delay'en där ?
FTDI-kabeln bör vara OK om du använder justa drivers.
Re: ATMega16 + USART +PC
Yes, sorry att jag missa svara på det, tagit bort alla delays men problemet kvarstår.
jag får pilla vidare helt enkelt.
jag får pilla vidare helt enkelt.
Re: ATMega16 + USART +PC
OK.
Ta PHermanssons kod och testa...
Men å andra sidan så skrev du ju :
> "Testade även mitt egenskrivna program, och fick resultatet jag är ute efter."
Så då är allt OK med andra ord ? Eller vad menade du med det där ?
Ta PHermanssons kod och testa...
Men å andra sidan så skrev du ju :
> "Testade även mitt egenskrivna program, och fick resultatet jag är ute efter."
Så då är allt OK med andra ord ? Eller vad menade du med det där ?
Re: ATMega16 + USART +PC
Nja, när jag komenterade bort nästan all kod förutom USART delen, så fungerade det så som jag vill.
Men så fort jag sätter in PWM koden och IF och Switch satserna så börjar det strula, så nånstans där ligger väl problemet.
Men så fort jag sätter in PWM koden och IF och Switch satserna så börjar det strula, så nånstans där ligger väl problemet.
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: ATMega16 + USART +PC
Jo men då är det ju bara att fortsätta ringa in felet. Funkar det med/utan PWM/If? I mitt fall funkade det ju med If, så testa att ta med denna del först. Aktivera Pwm igen, sk*ter det sig? Gå in i detalj på PWM-rutinerna, kommentera rader och stycken och se var felet uppstår.
Ibland kan man inte se felet direkt utan tvingas vara envis och ringa in det istället.
Ibland kan man inte se felet direkt utan tvingas vara envis och ringa in det istället.
Re: ATMega16 + USART +PC
> så nånstans där ligger väl problemet.
Vadå "ligger väl problemet" ?
Det är ju bara att ta bort tills det fungerar och sedan lägga
tillbaka tills det slutar fungera o.s.v gång på gång på gång tills
du har bara en enda sak kvar som det beror på, d.v.s om du
lägger till det så slutar det, om du tar bort det så fungerar det.
Vad är problemet ?? Har du inte tålamod nog ?
> Men så fort jag sätter in PWM koden och IF och Switch satserna så börjar det strula,
*Självklart* testar man då med PWM koden *ELLER* IF *ELLER* Switch satserna.
Men tar man inte bort och lägger till allt på en gång. Hur vet du då vad som är felet !?
Vadå "ligger väl problemet" ?
Det är ju bara att ta bort tills det fungerar och sedan lägga
tillbaka tills det slutar fungera o.s.v gång på gång på gång tills
du har bara en enda sak kvar som det beror på, d.v.s om du
lägger till det så slutar det, om du tar bort det så fungerar det.
Vad är problemet ?? Har du inte tålamod nog ?
> Men så fort jag sätter in PWM koden och IF och Switch satserna så börjar det strula,
*Självklart* testar man då med PWM koden *ELLER* IF *ELLER* Switch satserna.
Men tar man inte bort och lägger till allt på en gång. Hur vet du då vad som är felet !?
Re: ATMega16 + USART +PC
PROBLEMET LÖST! Pinsamt 
Satt o testade igen o igen o igen med att ändra i koden, läste om registrerna på AVR'n. satt o klia mig i skallen.
Tittade sen ner på mitt breadboard och insåg väl att det kanske blir störningar o så som ställer till det i AVR´n med USART'n.
Problemet löstes genom att sätta en kondensator (10µ) mellan kollektor och edmitter på IRL510'n
Som sagt, man är ju ganska ny på det här, och Pinsamt värre!
Går och ställer mig i skamvrån.
Måste läsa på om avkoppling!!!!!
Tack för all hjälp och hoppas att ni inte hatar mig pga min okunskap!

Satt o testade igen o igen o igen med att ändra i koden, läste om registrerna på AVR'n. satt o klia mig i skallen.
Tittade sen ner på mitt breadboard och insåg väl att det kanske blir störningar o så som ställer till det i AVR´n med USART'n.
Problemet löstes genom att sätta en kondensator (10µ) mellan kollektor och edmitter på IRL510'n
Som sagt, man är ju ganska ny på det här, och Pinsamt värre!
Går och ställer mig i skamvrån.
Måste läsa på om avkoppling!!!!!
Tack för all hjälp och hoppas att ni inte hatar mig pga min okunskap!
Re: ATMega16 + USART +PC [LÖST]
Låter det inte som en bra idé att sätta en kondensator där (om du med kollektor och emitter menar drain och source). Det innebär att när transistorn är passiv kommer kondensatorn laddas genom motorn, och när transistorn slås på kommer kondensatorn laddas ur hastigt genom transistorn.
Har du kopplat som i paint-bilden?
Kopplingen saknar sk. frihjulsdiod. Dioden ska sättas parallellt med motorn. Utan frihjulsdioden kommer energin i motorns induktans inducera en hög spänning över transistorn varje gång transistorn går från ledande till icke ledande. Kondensatorn minskar denna spänningen, men belastar samtidigt transistorn då den slås på. De snabba urladdningarna ger värme i kondensatorn. Kan bli så varmt att kondensatorn blir het och går sönder.
Har du kopplat som i paint-bilden?
Kopplingen saknar sk. frihjulsdiod. Dioden ska sättas parallellt med motorn. Utan frihjulsdioden kommer energin i motorns induktans inducera en hög spänning över transistorn varje gång transistorn går från ledande till icke ledande. Kondensatorn minskar denna spänningen, men belastar samtidigt transistorn då den slås på. De snabba urladdningarna ger värme i kondensatorn. Kan bli så varmt att kondensatorn blir het och går sönder.