Jag står inför ett teknikskifte...
Jag står inför ett teknikskifte...
Jag har tidigare gjort massor av projekt med TI MSP430 och Freescale HC08-serierna. Dessa är dock inte så enkla att få tag på alla gånger. De vanligaste typerna finns, men urvalet är väldigt begränsat.
Det verkar dock som att de flesta hobbyister jobbar med AVR. Således tänkte jag köra några AVR-projekt och se hur jag trivs. Det verkar ju onekligen vara enklare att få tag på AVR i alla fall.
Nu till några frågor, som jag inte riktigt har rett ut än:
Hur programmeras dessa rackare? Jag har sett några olika varianter över parallel och serieport, men de verkar använda rätt många pinnar. Måste AVR programmeras innan man löder fast den?
Hur är det med debugmöjligheterna?
Jag har endast Linux på mina labbdatorer. Finns det bra verktyg för Linux? (Freeware för hobbybruk.)
Jag utvecklar helst i Eclipse, så finns det några plugins för Eclipse så är det ännu bättre.
Vad gäller funktioner och strömförbrukning har jag inga synpunkter. Även om AVR drar mer än MSP430 så bekymrar det mig inte alltför mycket.
Finns det andra arkitekturer jag bör överväga? Vad är alternativen till AVR? (Hoppas jag inte startar ett krig här på forumet nu...)
/Robert
Det verkar dock som att de flesta hobbyister jobbar med AVR. Således tänkte jag köra några AVR-projekt och se hur jag trivs. Det verkar ju onekligen vara enklare att få tag på AVR i alla fall.
Nu till några frågor, som jag inte riktigt har rett ut än:
Hur programmeras dessa rackare? Jag har sett några olika varianter över parallel och serieport, men de verkar använda rätt många pinnar. Måste AVR programmeras innan man löder fast den?
Hur är det med debugmöjligheterna?
Jag har endast Linux på mina labbdatorer. Finns det bra verktyg för Linux? (Freeware för hobbybruk.)
Jag utvecklar helst i Eclipse, så finns det några plugins för Eclipse så är det ännu bättre.
Vad gäller funktioner och strömförbrukning har jag inga synpunkter. Även om AVR drar mer än MSP430 så bekymrar det mig inte alltför mycket.
Finns det andra arkitekturer jag bör överväga? Vad är alternativen till AVR? (Hoppas jag inte startar ett krig här på forumet nu...)
/Robert
Re: Jag står inför ett teknikskifte...
Jag skulle tro att det står ung. 50/50 mellan AVR och PIC.
Och de kan i stora dra det samma och har en stor bredd på urval, dock verkar AVR ha en lite konstig politik med vilka modeller som försvinner och vilka som kommer.
Verktygen är i stort ganska lika, kanske inte till utseendet men i funktioner.
Och båda familjer kan programmeras med ICSP (In-Circutry Serial Programming) kan lägger beslag på 3-4 pinnar just vid programmeringstillfället och rätt designad kan man använda ett par av dessa i det slutgiltiga kretslopp.
Den största skillnad är att man med "rätt" inställning i en AVR kan låsa ute möjligheten att använda ICSP varför man bara kan programmera om den med en parallell programmerare, något som väldig få har. Googla på "bricked AVR", det är en o annan som har upplevd detta. AVR är dessutom beroende av kristallklockan under programmeringen, något som en fel inställning kan göra lite tråkigt.
Men ska du ha en mikroprocessor med lite mer styrka vill jag peka på Renesas M16C som jag använder i ett antal projekt, den kan en hel del.
Och de kan i stora dra det samma och har en stor bredd på urval, dock verkar AVR ha en lite konstig politik med vilka modeller som försvinner och vilka som kommer.
Verktygen är i stort ganska lika, kanske inte till utseendet men i funktioner.
Och båda familjer kan programmeras med ICSP (In-Circutry Serial Programming) kan lägger beslag på 3-4 pinnar just vid programmeringstillfället och rätt designad kan man använda ett par av dessa i det slutgiltiga kretslopp.
Den största skillnad är att man med "rätt" inställning i en AVR kan låsa ute möjligheten att använda ICSP varför man bara kan programmera om den med en parallell programmerare, något som väldig få har. Googla på "bricked AVR", det är en o annan som har upplevd detta. AVR är dessutom beroende av kristallklockan under programmeringen, något som en fel inställning kan göra lite tråkigt.
Men ska du ha en mikroprocessor med lite mer styrka vill jag peka på Renesas M16C som jag använder i ett antal projekt, den kan en hel del.
Re: Jag står inför ett teknikskifte...
"AVR är dessutom beroende av kristallklockan under programmeringen, något som en fel inställning kan göra lite tråkigt."
Vet inte riktigt vad du menar, men man behöver ingen kristall för att programmera avr. Tycker man att prestandan på den inbyggda oscillatorn räcker (vilket den ofta gör) så behövs inga yttre kretsar alls.
För att programmera behöver du exempelvis en sådan här 73-680-04 (OBS jag använder den under windows, kör du linux så vette tusan.)
Vet inte riktigt vad du menar, men man behöver ingen kristall för att programmera avr. Tycker man att prestandan på den inbyggda oscillatorn räcker (vilket den ofta gör) så behövs inga yttre kretsar alls.
För att programmera behöver du exempelvis en sådan här 73-680-04 (OBS jag använder den under windows, kör du linux så vette tusan.)
Re: Jag står inför ett teknikskifte...
gimbal: Man behöver inte om inställningen är ställd på intern, har man ställt den på extern måste en kristall (som matchar inställningarna) sitta monterad. Och man kan inte ändra tillbaka till intern utan en extern kristall..
Re: Jag står inför ett teknikskifte...
Hur är det med debugmöjligheterna?
Jag har endast Linux på mina labbdatorer
Avr har jag inte använt.
Jag kan ju tipsa i alla fall om Pic och Windows.
Det finns en programmerings-enhet till dom som heter icd 2.
(Nu är den nog ersatt av icd 3 som är nyare.)
Med den kan man köra avlusning också. Man kan ställa in
brytpunkter, stoppa processorn och titta på olika register.
Den har jag haft mycket hjälp av.
Man använder Mplab då, som är ett Windows-program.
Till linux finns nog inget sånt för Pic.
Bara ett tips.
Jag har endast Linux på mina labbdatorer
Avr har jag inte använt.
Jag kan ju tipsa i alla fall om Pic och Windows.
Det finns en programmerings-enhet till dom som heter icd 2.
(Nu är den nog ersatt av icd 3 som är nyare.)
Med den kan man köra avlusning också. Man kan ställa in
brytpunkter, stoppa processorn och titta på olika register.
Den har jag haft mycket hjälp av.
Man använder Mplab då, som är ett Windows-program.
Till linux finns nog inget sånt för Pic.
Bara ett tips.
Re: Jag står inför ett teknikskifte...
Kör AVR + STK500 och AVR Dragon
Då kan jag köra nästan alla kretsar, jag har stöd för seriell programmering, hvpp (High voltate parallell programming), möjligheter att debugga direkt i kretsen samt mycket mer, och detta för en kostnad kring 1500:-
AVR kan dessutom köras i Linux utan problem, det kanske även PIC kan men jag hade svårt att få det att lira, men det är över fem år sedan jag provade PIC + Linux och de är ju inte samma som det var då
Mvh
//Minus
Då kan jag köra nästan alla kretsar, jag har stöd för seriell programmering, hvpp (High voltate parallell programming), möjligheter att debugga direkt i kretsen samt mycket mer, och detta för en kostnad kring 1500:-
AVR kan dessutom köras i Linux utan problem, det kanske även PIC kan men jag hade svårt att få det att lira, men det är över fem år sedan jag provade PIC + Linux och de är ju inte samma som det var då
Mvh
//Minus
Re: Jag står inför ett teknikskifte...
> Kör AVR + STK500 och AVR Dragon
> Då kan jag köra nästan alla kretsar, jag har stöd för seriell programmering, hvpp (High voltate
> parallell programming), möjligheter att debugga direkt i kretsen samt mycket mer, och detta för en
> kostnad kring 1500:-
Allt detta går att göra med bara Dragon. Men visst, en STK500 kan också vara bra att ha.
> Då kan jag köra nästan alla kretsar, jag har stöd för seriell programmering, hvpp (High voltate
> parallell programming), möjligheter att debugga direkt i kretsen samt mycket mer, och detta för en
> kostnad kring 1500:-
Allt detta går att göra med bara Dragon. Men visst, en STK500 kan också vara bra att ha.
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: Jag står inför ett teknikskifte...
Egentligen kan man väl säga som så här: Vill du programmera i C väljer du AVR. Är det assembler som gäller går det på ett ut. Det är dock enklare att arbeta med AVR om du kör Linux (tycker jag i alla fall). Jag använde mest Pic förr, men har nu fastnat för enkelheten i kombinationen Linux/AVR/C.
Re: Jag står inför ett teknikskifte...
> Man behöver inte om inställningen är ställd på intern, har man ställt den på
> extern måste en kristall (som matchar inställningarna) sitta monterad.
> Och man kan inte ändra tillbaka till intern utan en extern kristall..
Ja, det är ju det enkla fallet ("Bricked-light"
) då det räcker med
att hänga på en kristall. Men man kan även stänga av ICSP helt och
då hjälper inget annat än en parallell-programmerare.
> Ok, det låter iofs ganska naturligt.
Nja, det har väl ingenting med "naturligt" eller inte att göra.
Det är helt enkelt så AVR fungerar. T.ex PIC fungerar inte alls så
(den kan alltid programmeras om via ICSP), så vad är "naturligt" igentligen ?
> extern måste en kristall (som matchar inställningarna) sitta monterad.
> Och man kan inte ändra tillbaka till intern utan en extern kristall..
Ja, det är ju det enkla fallet ("Bricked-light"

att hänga på en kristall. Men man kan även stänga av ICSP helt och
då hjälper inget annat än en parallell-programmerare.
> Ok, det låter iofs ganska naturligt.
Nja, det har väl ingenting med "naturligt" eller inte att göra.
Det är helt enkelt så AVR fungerar. T.ex PIC fungerar inte alls så
(den kan alltid programmeras om via ICSP), så vad är "naturligt" igentligen ?

Re: Jag står inför ett teknikskifte...
Det är naturligt att den vill ha en extern klocka om man säger att den ska använda en extern klocka.
Sen håller jag med om att det är bättre om själva programmeringen sker med en klocka från progameringsenheten. (vilket jag trodde den gjorde, men det är inget jag undersökt eftersom det (än så länge) bara funkat.)
Sen håller jag med om att det är bättre om själva programmeringen sker med en klocka från progameringsenheten. (vilket jag trodde den gjorde, men det är inget jag undersökt eftersom det (än så länge) bara funkat.)
Re: Jag står inför ett teknikskifte...
KTachLab är till för utveckling i PIC-miljö. Det har stöd för flödes-programmering dessutom.BJ skrev:Hur är det med debugmöjligheterna?
Jag har endast Linux på mina labbdatorer
Avr har jag inte använt.
Jag kan ju tipsa i alla fall om Pic och Windows.
Det finns en programmerings-enhet till dom som heter icd 2.
(Nu är den nog ersatt av icd 3 som är nyare.)
Med den kan man köra avlusning också. Man kan ställa in
brytpunkter, stoppa processorn och titta på olika register.
Den har jag haft mycket hjälp av.
Man använder Mplab då, som är ett Windows-program.
Till linux finns nog inget sånt för Pic.
Bara ett tips.
Jag håller inte på med PIC så jag vet inte hur pass användbart det kan vara.
Funkar enbart till Linux enligt infon på Wiki.
http://en.wikipedia.org/wiki/KTechLab
Re: Jag står inför ett teknikskifte...
Man måste inte programmera en AVR innan den lödas fast på kortet. Vill man kunna programmera direkt på kortet måste man ha minst sex stift som kopplas till den seriella programmeraren: GND, VCC ,MOSI ,MISO ,SCK och RESET.
Det ska gå att programmera i Linux, men jag har inte orkat ordna någon tool-chain , så jag kör den färdiga WINAVR som jag kör i Windows XP. Andra här vet hur man gör i Linux.
Det ska gå att programmera i Linux, men jag har inte orkat ordna någon tool-chain , så jag kör den färdiga WINAVR som jag kör i Windows XP. Andra här vet hur man gör i Linux.
Re: Jag står inför ett teknikskifte...
För PIC och Linux så har du också Piklab som jag själv använder. Men har du en Pickit 2 eller 3 eller ICD 2 och 3 så kan du köra nya MPLAB X från Microchip. Men den är i Beta-stadiet ännu.