Är AVR något att ha egentligen?
Är AVR något att ha egentligen?
Jag har använt AVR lite till och från under några år och mest gillat den. Nu har hag försökt använda den mer seriöst i hobbysammanhang men då har jag blivit rejält besviken.
Problemen har varit med programmering, det fungerar inte konsekvent och processorerna brukar låsa sig och man får åka till Elfa och skaffa en bunt nya.
Snackar man med folk som håller på mycket med AVR så verkar det som att det är helt normalt och avrfreaks kryllar av trådar med voodoo-tips på hur de mest rutinerade användarna brukar förse sina konstruktioner med pull-upmotstånd och dioder, som inte finns i någon officell dokumentation eller strider mot densamma, för att få det att funka.
På jobbet har jag jobbat med en del olika processorer (programmerat) och det hör ju till att det strular men inte på dethär sättet. Mest har det varit 32-bitars processorer så inga AVR-konkurrenter.
Hursomhelst, vad säger ni som har erfarenhet av AVR och andra 8-bitars. Är det bara att jag som har haft otur och att problem syns tydligt tack vare aktiviteten på avrfreaks eller är AVR skakiga jämfört med tex PIC?
Problemen har varit med programmering, det fungerar inte konsekvent och processorerna brukar låsa sig och man får åka till Elfa och skaffa en bunt nya.
Snackar man med folk som håller på mycket med AVR så verkar det som att det är helt normalt och avrfreaks kryllar av trådar med voodoo-tips på hur de mest rutinerade användarna brukar förse sina konstruktioner med pull-upmotstånd och dioder, som inte finns i någon officell dokumentation eller strider mot densamma, för att få det att funka.
På jobbet har jag jobbat med en del olika processorer (programmerat) och det hör ju till att det strular men inte på dethär sättet. Mest har det varit 32-bitars processorer så inga AVR-konkurrenter.
Hursomhelst, vad säger ni som har erfarenhet av AVR och andra 8-bitars. Är det bara att jag som har haft otur och att problem syns tydligt tack vare aktiviteten på avrfreaks eller är AVR skakiga jämfört med tex PIC?
Vad menar du med att "processorerna brukar låsa sig" ?
> brukar förse sina konstruktioner med pull-upmotstånd och dioder, [...] för att få det att funka.
Det där är lite väl raljerande. DU kanske skulle vara lite mer konkret. Ge något
exempel. För att få *vad* att fungera ?
> eller är AVR skakiga jämfört med tex PIC?
Även "skakiga" är för svepande för att kunna kommentera på ett seriöst sätt.
> brukar förse sina konstruktioner med pull-upmotstånd och dioder, [...] för att få det att funka.
Det där är lite väl raljerande. DU kanske skulle vara lite mer konkret. Ge något
exempel. För att få *vad* att fungera ?
> eller är AVR skakiga jämfört med tex PIC?
Även "skakiga" är för svepande för att kunna kommentera på ett seriöst sätt.
Inget jag har varit med om iallafall, men så vet jag inte riktigt *vad* det är du beskriver heller.
Jag har använt AVR i några år varav det senaste året *väldigt* många och har aldrig varit med om några mysko fel som inte beskrivits i databladen (inga "mysko" fel överhuvudtaget faktiskt), och då använder vi ändå ungefär 3-600 i veckan däri alltifrån rullande konstruktioner till oss, kunder och nyutvecling till oss och kunder.
EDIT: kollade lite på avrfreaks för att försöka förstå vad du (trådskaparen) menar men hittar inte riktigt vad det skulle kunna vara.
Det enda problem jag kan komma på som är vanligt är att folk sätter fusebitarna fel och kretsen inte svarar på lågvoltsprogrammering(normalt isp) sen
På vilket sätt menar du?...och det hör ju till att det strular men inte på dethär sättet.
Jag har använt AVR i några år varav det senaste året *väldigt* många och har aldrig varit med om några mysko fel som inte beskrivits i databladen (inga "mysko" fel överhuvudtaget faktiskt), och då använder vi ändå ungefär 3-600 i veckan däri alltifrån rullande konstruktioner till oss, kunder och nyutvecling till oss och kunder.
EDIT: kollade lite på avrfreaks för att försöka förstå vad du (trådskaparen) menar men hittar inte riktigt vad det skulle kunna vara.
Det enda problem jag kan komma på som är vanligt är att folk sätter fusebitarna fel och kretsen inte svarar på lågvoltsprogrammering(normalt isp) sen
Senast redigerad av björn 30 november 2007, 08:55:16, redigerad totalt 1 gång.
Vad menar du med att du måste köpa nya?? Har du stält in fuse att du bara kan programmera kretsen en enda gång? Varför i sådana fall, det var ju för hobbybruk?!! Man brukar annars kunna programmera om dom i all evighet. Du flashar inte med för hög hastighet, va?? Programmerar du via ISP eller High voltage?? Vad använder du för att programmera dom med för hårdvara?? STK500/STK200/AVR-ISP?? Vilken mjukvara??processorerna brukar låsa sig och man får åka till Elfa och skaffa en bunt nya.
> Programmerar du via ISP eller High voltage??
Är det inte så med AVR/ISP att man kan "låsa sig ute" om man råkar
sätta osc-configen (eller något annat) fel ?
Hittade en bra sammanfattning :
http://electrons.psychogenic.com/module ... OGuide.php
Se "Final things To Remember" en bit ner på sidan...
En stor skillnad mellan AVR och PIC är att en PIC *alltid* kan omprogrammeras
via standard ISP oavsett hur fuses (config) är satt.
I en AVR finns det flera sett (t.ex SPIEN eller fel osc) som strular till det för ISP.
Och då är det en parr HV programmerare som behövs för att rätta till det.
Så, visst, för en nybörjare som experimenterar med fuses, så är det
sannolikt enklare att klanta till det med en AVR än med en PIC.
Och en PIC saknar helt en fuse/config bit som *helt* stänger av
omprogrammering.
Lösningen (i AVR fallet) är naturligstvis "don't do that"...
Är det inte så med AVR/ISP att man kan "låsa sig ute" om man råkar
sätta osc-configen (eller något annat) fel ?
Hittade en bra sammanfattning :
http://electrons.psychogenic.com/module ... OGuide.php
Se "Final things To Remember" en bit ner på sidan...
En stor skillnad mellan AVR och PIC är att en PIC *alltid* kan omprogrammeras
via standard ISP oavsett hur fuses (config) är satt.
I en AVR finns det flera sett (t.ex SPIEN eller fel osc) som strular till det för ISP.
Och då är det en parr HV programmerare som behövs för att rätta till det.
Så, visst, för en nybörjare som experimenterar med fuses, så är det
sannolikt enklare att klanta till det med en AVR än med en PIC.
Och en PIC saknar helt en fuse/config bit som *helt* stänger av
omprogrammering.
Lösningen (i AVR fallet) är naturligstvis "don't do that"...

Jag har råkat sätta fel klockkälla ett par ggr.. fixade det genom att skicka 50% dutycycle PWM på en viss pinne (tror det var xtal2) samt sänkte hastigheten på programeringen till en frekvens som ligger under PWMen, då går det ställa om inställningarna med ISP! Så har du bara en fungerande µC så är det lungt!
Vad jag menar är att kretsen varken svarar på debugwire eller SPI.Stinrew skrev:Vad menar du med att du måste köpa nya?? Har du stält in fuse att du bara kan programmera kretsen en enda gång? Varför i sådana fall, det var ju för hobbybruk?!! Man brukar annars kunna programmera om dom i all evighet. Du flashar inte med för hög hastighet, va?? Programmerar du via ISP eller High voltage?? Vad använder du för att programmera dom med för hårdvara?? STK500/STK200/AVR-ISP?? Vilken mjukvara??processorerna brukar låsa sig och man får åka till Elfa och skaffa en bunt nya.
Inga fuse bit ändrade med avsikt iallfall. ATMEGA88, WinAVR, AVR Studio, Dragon (och JTAGICE mk II). Så interfacet är debugwire. Kort och prydlig bandkabel till Dragon. Noll ESD-disciplin. Avkopplingskondigar: ja.
Finns det några möjligheter att man pillar på fuse bits och klockkällor utan att veta om det? (Kan elf-filen innehålla sådan info tex?)
sodjan: Jo, jag kunde ha backat upp med lite exempel. ("Det kryllar av trådar" skrev jag...dom finns kanske är mer rätt.) Ett exempel med en klingande titel: http://www.avrfreaks.net/index.php?name ... ic&t=55705
Och självklart, AVR funkar nog bra för de flesta, annars skulle ingen använda det. Jag påstår inte att AVR inte funkar alls. Men det är ungefär såhär: Bara för att en massa andra människor använder MS Word och tycker att det funkar bra så är det ingen tröst när *ditt* dokument kraschar.
> Finns det några möjligheter att man pillar på fuse bits och klockkällor utan att veta om det?
Utan att veta vad man gör, sannolikt...
Och i *det* fallet (eftersom du frågade om det) så är det lättare
att ställa till det för sig med en AVR än en PIC. Det finns fler sätt
i en AVR att röra till fuse bitarna så att ISP inte fungerar längre.
Sen verkar din länk specifikt handla om Dragon problem...
Utan att veta vad man gör, sannolikt...

Och i *det* fallet (eftersom du frågade om det) så är det lättare
att ställa till det för sig med en AVR än en PIC. Det finns fler sätt
i en AVR att röra till fuse bitarna så att ISP inte fungerar längre.
Sen verkar din länk specifikt handla om Dragon problem...
> Kan bara ställa mig till skaran som *aldrig* fått "mystiska" fel på AVR.
Dom gånger jag trott jag har stött på mystiska fel har det alltid varit SBS (skit bakom spakarna).
Det fins egentligen bara två saker som kan strula:
1. pull up på reset, måste vara exakt 10k.
2. stabil spänning under programmering. tänk på att flash programmering drar rätt många mA, så du kan få en dipp i din Vcc. sjunker Vcc när du programmerar flash så kan en bit programmeras med ett felaktigt värde. I värsta fal kan det vara en fuse bit, och har du riktig otur kan du "bricka" din krets.
Använder du dragon kan det också vara lite svårt att lista ut var Vcc egentligen kommer ifrån (från dragon eller kortet?). Jag har för mig att dragon vill kunna stänga av Vcc precis när debugWire initieras.
Dom gånger jag trott jag har stött på mystiska fel har det alltid varit SBS (skit bakom spakarna).
Det fins egentligen bara två saker som kan strula:
1. pull up på reset, måste vara exakt 10k.
2. stabil spänning under programmering. tänk på att flash programmering drar rätt många mA, så du kan få en dipp i din Vcc. sjunker Vcc när du programmerar flash så kan en bit programmeras med ett felaktigt värde. I värsta fal kan det vara en fuse bit, och har du riktig otur kan du "bricka" din krets.
Använder du dragon kan det också vara lite svårt att lista ut var Vcc egentligen kommer ifrån (från dragon eller kortet?). Jag har för mig att dragon vill kunna stänga av Vcc precis när debugWire initieras.