Vilken är lättast/smartast att börja med?
När det gäller ICSP debugger till PIC finns det ett par man kan bygga själv se http://www.edaboard.com/ftopic161641.html
C-utvecklingsmiljön till PIC18, MCC18+MPLAB, tycker jag är helt OK.
PS. Du kan ju kolla på:http://biphome.spray.se/frl_linder/PIC1 ... start.html
C-utvecklingsmiljön till PIC18, MCC18+MPLAB, tycker jag är helt OK.
PS. Du kan ju kolla på:http://biphome.spray.se/frl_linder/PIC1 ... start.html
Jag har inte själv pysslat med pic i någon större utsträckning, men det jag har förstått av inläggen här på forumet så är det en del bök med att flytta koden mellan olika modeller. AVR:erna är mer enhetliga i sin uppbyggnad mellan olika modeller, Rätta mig om jag är ute och cyklar eller knör på mopeden som inte vill starta!
Jag kör både PIC och AVR,
programmerare för dessa så kör jag ICD2, AVRDRAGON och USBASP.
Jag skriver all kod i c och ser igentligen ingen större skillnad mellan AVR och PIC, båda har sina fördelar och nackdelar.
PIC har bättre skrivna manualer, fast atmega manualerna är inte dåliga.
Sedan att chip försvinner utan ersättare hos atmel har jag inte varit med om, visst koden kanske måsta ändras lite för det ska fungera.
programmerare för dessa så kör jag ICD2, AVRDRAGON och USBASP.
Jag skriver all kod i c och ser igentligen ingen större skillnad mellan AVR och PIC, båda har sina fördelar och nackdelar.
PIC har bättre skrivna manualer, fast atmega manualerna är inte dåliga.
Sedan att chip försvinner utan ersättare hos atmel har jag inte varit med om, visst koden kanske måsta ändras lite för det ska fungera.
Sodjan, det var väl uppgraderingar som jag har sett. Det kallas väl familj istf modell.
Det är grabben som kör med PIC. det svär lite ibland. Han funderar på avr.
Men pic som har funnits så länge, det borde ju egentligen finnas pic-gcc, eller? Som hanterar processor byte på samma sätt som avr-gcc, då borde skillnaderna för oss som kör C bli ännu mindre... .
Vilken som är lämpligast beror i huvudsak på vad som ska göras, om det krävs en speciell processor. Sedan på vad man har för erfarenheter sedan tidigare, tex språk osv.
För mig spelade det ingen roll om jag använde pic eller avr, det var miljön. Då make, gcc och C är mycket kanda sedan tidigare och jag fick nys om winavr så blev det avr.
Nu har det mödosamma arbetet börjat (så smått) med att bygga upp ett skal runt avr som jag kan stubba bort och bara testa applikationerna i Linux, vi får se om det någonsin blir färdigt!
Det är grabben som kör med PIC. det svär lite ibland. Han funderar på avr.
Men pic som har funnits så länge, det borde ju egentligen finnas pic-gcc, eller? Som hanterar processor byte på samma sätt som avr-gcc, då borde skillnaderna för oss som kör C bli ännu mindre... .
Vilken som är lämpligast beror i huvudsak på vad som ska göras, om det krävs en speciell processor. Sedan på vad man har för erfarenheter sedan tidigare, tex språk osv.
För mig spelade det ingen roll om jag använde pic eller avr, det var miljön. Då make, gcc och C är mycket kanda sedan tidigare och jag fick nys om winavr så blev det avr.
Nu har det mödosamma arbetet börjat (så smått) med att bygga upp ett skal runt avr som jag kan stubba bort och bara testa applikationerna i Linux, vi får se om det någonsin blir färdigt!
Nä, så långt ska jag inte dra det hela. Tanken är att göra själva applikationens kod utan en gnutta avr-specifik kod. Själva implementationen mot hårdvara görs i ett eller flera lib som sedan byts ut för att simulera i linux. vill man sedan köra applikationen i på en pic så skapar man lib för denna. Det brukar vara på det sättet när man gör en applikation mot flera plattformar.
Det som kan spela in är hur overhead, onödiga funktions anrop etc. .
Det som kan spela in är hur overhead, onödiga funktions anrop etc. .
Vad menar du med "andra plattformar" ? Andra mikrokontrollers ?
Eller andra miljöer typ Win/Linux/whatever ? I så fall tror jag inte alls på det.
Har du skrivit någonting alls till mikrokontrollers tidigare ?
Det går knappt att skriva en applikation som man kan köra på
PIC och AVR bara genom att byta ut någon "hårdvaru-lib". Redan där
är skillnadera så pass stora så att stora delar av applikationen sannolikt
kommer att skrivas på olika sätt beroende på vilken processor man använder.
OK, om man vill köra sub-optimalt kanske, men inte om man vill
få ut allt av de olika processorerna.
Eller andra miljöer typ Win/Linux/whatever ? I så fall tror jag inte alls på det.
Har du skrivit någonting alls till mikrokontrollers tidigare ?
Det går knappt att skriva en applikation som man kan köra på
PIC och AVR bara genom att byta ut någon "hårdvaru-lib". Redan där
är skillnadera så pass stora så att stora delar av applikationen sannolikt
kommer att skrivas på olika sätt beroende på vilken processor man använder.
OK, om man vill köra sub-optimalt kanske, men inte om man vill
få ut allt av de olika processorerna.
sodjan, vad Ulf beskriver är mer regel än undantag i större projekt. sparar utvecklingskostand och utvecklare kan komma igång långt innan hårdvaran finns tillgänglig.
Byta mellan PIC och AVR? enkelt! Vi modellerar ASIC i C och testkör prototypen i ARM och/eller FPGA mot riktig hårdvara (med långsammare klocka förstås)....
Byta mellan PIC och AVR? enkelt! Vi modellerar ASIC i C och testkör prototypen i ARM och/eller FPGA mot riktig hårdvara (med långsammare klocka förstås)....
Plattformar, det kan vara processor, OS, simulatormiljö eller emulatormiljö.
Några snuttar har det blivit på avr, men desto mer på jobbet mot olika telekomplattformar.
Om vi tar ett litet exempel;
min appliktion vill göra utskrifter på en display, det kan vara lcd via 1.wire, eller någon annan typ. Funktionerna som kommer att avändas är writeDisplay(char *s), och clearDisplay(). Ytterligare en funktion behövs för initiering initDisplay(...), denna tar specifika argument för vilken port etc som den sitter på, eller om det är 1-wire kommunikation till den.
Min applikation struntar i hur writeDisplay(char *s), och clearDisplay() är implementerade, den bara förväntar sig att dom gör det dom ska.
Det enda i det läget som är plattformsberoende är initDisplay(), och oftast är det så att det är initieringen som måste ifdef:as.
Applikationen kan nu lika gärna använda en display som egentligen är ett fönster i tex Linux, eftersom make används av både i Linux och winavr och vips så kommer applikationens utskrift i fönsteret.
Det är mot denna nivå som applikationen ska jobba, annars kan det bli väldans bökigt.
I förlängningen av detta så finns även en idé att ha ett interface till datorn som en mcu kopplas till. Applikationen körs på mcu:n och extern hårvara (displayer knappar etc. emuleras av datorn.
Och räcker inte hastigheten till så är det bara att skaffa något som är snabbare, är det minnet som tryter skaffa mer minne.
Några snuttar har det blivit på avr, men desto mer på jobbet mot olika telekomplattformar.
Om vi tar ett litet exempel;
min appliktion vill göra utskrifter på en display, det kan vara lcd via 1.wire, eller någon annan typ. Funktionerna som kommer att avändas är writeDisplay(char *s), och clearDisplay(). Ytterligare en funktion behövs för initiering initDisplay(...), denna tar specifika argument för vilken port etc som den sitter på, eller om det är 1-wire kommunikation till den.
Min applikation struntar i hur writeDisplay(char *s), och clearDisplay() är implementerade, den bara förväntar sig att dom gör det dom ska.
Det enda i det läget som är plattformsberoende är initDisplay(), och oftast är det så att det är initieringen som måste ifdef:as.
Applikationen kan nu lika gärna använda en display som egentligen är ett fönster i tex Linux, eftersom make används av både i Linux och winavr och vips så kommer applikationens utskrift i fönsteret.
Det är mot denna nivå som applikationen ska jobba, annars kan det bli väldans bökigt.
I förlängningen av detta så finns även en idé att ha ett interface till datorn som en mcu kopplas till. Applikationen körs på mcu:n och extern hårvara (displayer knappar etc. emuleras av datorn.
Och räcker inte hastigheten till så är det bara att skaffa något som är snabbare, är det minnet som tryter skaffa mer minne.
OK...
Alltså, en enskild funktion (t.ex writeDisplay) är ingen "applikation".
Vad jag menar är att en applikation (d.v.s när man bygger
ihop alla sina funktioner till något användbart) kan komma
att se ganska olika ut på en uC än på en Win/Linux miljö.
Och även (om man vill utnyttja resp arkitektur fullt ut) på
en AVR mot en PIC. Därför är det lite svårt att designa applikationer
utan tanke på vad det ska köras på. Men det märker du vad det lider...
Alltså, en enskild funktion (t.ex writeDisplay) är ingen "applikation".
Vad jag menar är att en applikation (d.v.s när man bygger
ihop alla sina funktioner till något användbart) kan komma
att se ganska olika ut på en uC än på en Win/Linux miljö.
Och även (om man vill utnyttja resp arkitektur fullt ut) på
en AVR mot en PIC. Därför är det lite svårt att designa applikationer
utan tanke på vad det ska köras på. Men det märker du vad det lider...
