val av programeringsspråk?
i första hand för pic, men egenteligen för all programering
vill bara ha en snabbkoll på vilka funktioner ni vill annvända för att gå upp i nivå på programmeringspråk
ok, är det någon som kör med ren maskinkod?
skulle väl fungera på några få rader
assemblern är väl funkis till det mesta, bara man vet hur man hanterar det
men till vilken sorts uppgifter tycker ni att det är rimligt att hoppa upp till c eller någon annan lite högre programeringsspråk?
subjektiv frågeställning men jag undrar ändå
för min del så måste jag fundera i vilken ordning man skall försöka lära sig saker och ting
går ju arbetslös så man har lite mera tid till att leka sig igenom saker och ting
för min del så är det mest svåra att få full koll på hårdvaran, att kunna utnyttja den optimalt
val av programeringsspråk?
-
matseng
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Maskinkod och assembler är samma sak i alla praktiska hänseenden eftersom maskin-opkoderna har ett ett-till-ett-förhållande till assemblerinstruktioerna.
Istället för att skriva $ea så skriver man NOP.
I det stora hela kan man nog säga såhär:
Vill man utnyttja hårdvaran omtimalt - använd assembler
Vill man utnyttja sin tid optimalt - används C
Sen är det upp till hur stora serier som man ska tillverka av prylern för att avgöra om det är kostnadseffektivt att lägga ner typ 50000 kr extra programmeringstid för att kunna använda en uC som är typ 20 kr billigare per styck eftersom man i teorin kan använda en mindre och billigare uC om man skriver väloptimerad kod i assembler istället för C.
Fast det är i teorin det.... I praktiken så stämmer det bara i bland.
Istället för att skriva $ea så skriver man NOP.
I det stora hela kan man nog säga såhär:
Vill man utnyttja hårdvaran omtimalt - använd assembler
Vill man utnyttja sin tid optimalt - används C
Sen är det upp till hur stora serier som man ska tillverka av prylern för att avgöra om det är kostnadseffektivt att lägga ner typ 50000 kr extra programmeringstid för att kunna använda en uC som är typ 20 kr billigare per styck eftersom man i teorin kan använda en mindre och billigare uC om man skriver väloptimerad kod i assembler istället för C.
Fast det är i teorin det.... I praktiken så stämmer det bara i bland.
Små enkla funktioner i PIC = Assembler.
Till allt annat använder jag C. Det är ett ganska standart språk, kostnadseffektivt (funktioner/timme), relativt enkelt att lära sig, strukturerat (ytterst viktigt vid större program). Man kan vid behov göra "fula" saker som kan lösa komplicerade problem.
MEN: inlärningströskeln kan vara ganska hög för nybörjare, att läsa en annans C-program utan kommentarer är döden. Man kan vid behov göra "fula" saker som kan lösa komplicerade problem och dessa "fula" saker kan ge upphov till mycket knepiga problem. Standartfunktioners implementering kan vara helt fel till det projekt man jobbar med men C-standarten medger att man anpassar ganska mycket.
Håller man sig till ett "standart" språk kan man byta mål utan större problem och kan till och med återanvända programrutiner. Jag ha t.ex. utan problem återanvänd en mjukvara-IIC-bus tillsamman med en MAX6900 (Real Time Clock) och en DS1621 (Temp. mätare) enbart vid att definiera 2 pinnars namn och sen inkludera "IIC.h", "MAX6900.h" och "DS1621.h" i projektet. MCU:n är helt annolunda än den projekt dessa "drivrutiner" är skrivit till men det fungerar perfa ändå.
Det heter portning och fungerar inte lika smärtfritt alltid men ett välskrivit program medger att man enbart behöver ändra serieportrutinen t.ex. om man bytar MCU och behöver skriva helt andra värden i registrar som heter annolunda också.
Så jag håller mig till C och gärna C++.
Till allt annat använder jag C. Det är ett ganska standart språk, kostnadseffektivt (funktioner/timme), relativt enkelt att lära sig, strukturerat (ytterst viktigt vid större program). Man kan vid behov göra "fula" saker som kan lösa komplicerade problem.
MEN: inlärningströskeln kan vara ganska hög för nybörjare, att läsa en annans C-program utan kommentarer är döden. Man kan vid behov göra "fula" saker som kan lösa komplicerade problem och dessa "fula" saker kan ge upphov till mycket knepiga problem. Standartfunktioners implementering kan vara helt fel till det projekt man jobbar med men C-standarten medger att man anpassar ganska mycket.
Håller man sig till ett "standart" språk kan man byta mål utan större problem och kan till och med återanvända programrutiner. Jag ha t.ex. utan problem återanvänd en mjukvara-IIC-bus tillsamman med en MAX6900 (Real Time Clock) och en DS1621 (Temp. mätare) enbart vid att definiera 2 pinnars namn och sen inkludera "IIC.h", "MAX6900.h" och "DS1621.h" i projektet. MCU:n är helt annolunda än den projekt dessa "drivrutiner" är skrivit till men det fungerar perfa ändå.
Det heter portning och fungerar inte lika smärtfritt alltid men ett välskrivit program medger att man enbart behöver ändra serieportrutinen t.ex. om man bytar MCU och behöver skriva helt andra värden i registrar som heter annolunda också.
Så jag håller mig till C och gärna C++.
C och C++ är väl de (högnivå?)språk som är "närmast" assembler. D.v.s det är skrivet för att enkelt kunna kompileras till maskinkod och för att kunna portas mellan processorarkitekturer. Om man skall skriva högoptimerad C/C++ kod bör man ha bra koll på hur kompilatorn funkar och därmed också helst kunna lite assembler.
Fram tills rätt nyligen (och antagligen fortfarande i vissa fall) använde/använder spelprogrammerare m.fl. assembler för att optimera tidskritiska algoritmer, naturligtvis i kombination med C/C++ som används för merparten av koden. Om man ser till en tidskritisk funktion som anropas c.a. 100 kanske 1000 ggr per sekund inser man snart vad några instruktionscykler mer eller mindre påverkar den totala tiden.
Också att beakta är att dagens kompilatorer blir mer och mer avancerade och bättre på att optimera kod både för prestanda och storlek.
Idealet är väl att kunna båda, men som sagt man skall välja programmeringsspråk efter vad som passar bäst till det projekt man gör. Alla språk har sina för och nackdelar.
Mats
Fram tills rätt nyligen (och antagligen fortfarande i vissa fall) använde/använder spelprogrammerare m.fl. assembler för att optimera tidskritiska algoritmer, naturligtvis i kombination med C/C++ som används för merparten av koden. Om man ser till en tidskritisk funktion som anropas c.a. 100 kanske 1000 ggr per sekund inser man snart vad några instruktionscykler mer eller mindre påverkar den totala tiden.
Också att beakta är att dagens kompilatorer blir mer och mer avancerade och bättre på att optimera kod både för prestanda och storlek.
Idealet är väl att kunna båda, men som sagt man skall välja programmeringsspråk efter vad som passar bäst till det projekt man gör. Alla språk har sina för och nackdelar.
Mats
Precis!
Jag hade en funktion i vår grafiska LED-skylt där jag skulle kopiera ganska stora buffrar och memcpy() fungerade men jag tyckte att det gick för långsamt till den effekt jag ville ha.
Jag gjorde då en likvärd funktion fast med words och det gick snabbare men riktigt fjutt på den kom det då jag tog .LST-filen, saxade ut just den rutin och putsade på maskinkoden så den blev optimal. Jag fick ner tiden till ca: 1/3 av memcpy() tiden och det var det värd.
Assembler är mycket bra att kunna men när man kommer upp i storlek på program blir det lätt oöverskådligt så jag föredrar C(++) men som sagt: man kan putsa till lite då och då.
Assembler ger också ett ganska bra bild på hur systemet jobbar, ett bild man kan ta med till högnivå-världen.
Jag hade en funktion i vår grafiska LED-skylt där jag skulle kopiera ganska stora buffrar och memcpy() fungerade men jag tyckte att det gick för långsamt till den effekt jag ville ha.
Jag gjorde då en likvärd funktion fast med words och det gick snabbare men riktigt fjutt på den kom det då jag tog .LST-filen, saxade ut just den rutin och putsade på maskinkoden så den blev optimal. Jag fick ner tiden till ca: 1/3 av memcpy() tiden och det var det värd.
Assembler är mycket bra att kunna men när man kommer upp i storlek på program blir det lätt oöverskådligt så jag föredrar C(++) men som sagt: man kan putsa till lite då och då.
Assembler ger också ett ganska bra bild på hur systemet jobbar, ett bild man kan ta med till högnivå-världen.
Är det någon fler än jag som skulle vilja plocka bort C++ ur listan över hårdvarunära programmeringsspråk? 
För mig är C++ Basic på C-språk. Innehåller en hel del finesser som direkt gör att man inte har full koll på minnesanvändning etc.
Vad jag vet finns inte ens någon vettig C++-kompilator för MCU, eller?
Detta är endast min åsikt, eftersom jag inte alls använder C++ ens i PC-miljö.
Använder själv C till i princip alla projekt (mest större 8051-projekt då), och slänger in inline-assembler där det är som mest kritiskt.
Mvh
speakman
För mig är C++ Basic på C-språk. Innehåller en hel del finesser som direkt gör att man inte har full koll på minnesanvändning etc.
Vad jag vet finns inte ens någon vettig C++-kompilator för MCU, eller?
Detta är endast min åsikt, eftersom jag inte alls använder C++ ens i PC-miljö.
Använder själv C till i princip alla projekt (mest större 8051-projekt då), och slänger in inline-assembler där det är som mest kritiskt.
Mvh
speakman
C lämpar sig utmärkt för MCU, kombinerat med lite assembler här och där. Man ska också kunna assembler och känna till processorn man skriver för väl, då kan man skriva C-kod som blir så effektiv som möjligt. Väldigt enkelt exempel:
När man kodar på PC kör man kanske med int för en räknare även om den bara räknar upp till 100, men på en 8bits processor bör man välja char istället.
När man kodar på PC kör man kanske med int för en räknare även om den bara räknar upp till 100, men på en 8bits processor bör man välja char istället.
C är utmärkt till MCU!
Att sedan 8051 är en så ålderdomlig struktur att den är nära nog omöjlig att optimera är en annan sak.
Själv använder jag Fujitsu MB90F583 och jag har kollat i LST-filerna iblant när jag ska se om jag kan klämma lite och det är minimalt man kan putsa men sedan är den processor gjort med C i åtankan och det är väl den stora skillnad.
Vi använde 8031 förut men då jag kom skrotade jag den nära nog direkt, en snabb uträkning sa mig att vi ville få 16*MIPS per krona vid att byta till Fujitsun och då allt jag hade programmerat för att rädda det gamla var i C portade jag koden med minimala problem.
Att sedan 8051 är en så ålderdomlig struktur att den är nära nog omöjlig att optimera är en annan sak.
Själv använder jag Fujitsu MB90F583 och jag har kollat i LST-filerna iblant när jag ska se om jag kan klämma lite och det är minimalt man kan putsa men sedan är den processor gjort med C i åtankan och det är väl den stora skillnad.
Vi använde 8031 förut men då jag kom skrotade jag den nära nog direkt, en snabb uträkning sa mig att vi ville få 16*MIPS per krona vid att byta till Fujitsun och då allt jag hade programmerat för att rädda det gamla var i C portade jag koden med minimala problem.
Jag tror det blev en enorm missuppfattning här. 
Det jag menade var att jag också använder C för MCU, vilket jag även anser vara det mest optimala då inline-assembler lätt kan användas för att optimera vissa funktioner.
Det jag däremot inte ser som en fördel är C++, som jag anser bara medför svårigheter i MCU-miljö.
Och visst är 8051 gammalt, men väl fungerade än för generella ändamål.
Ser inte varför den skulle vara svårare än någon annan att optimera?
Mvh
speakman
Det jag menade var att jag också använder C för MCU, vilket jag även anser vara det mest optimala då inline-assembler lätt kan användas för att optimera vissa funktioner.
Det jag däremot inte ser som en fördel är C++, som jag anser bara medför svårigheter i MCU-miljö.
Och visst är 8051 gammalt, men väl fungerade än för generella ändamål.
Ser inte varför den skulle vara svårare än någon annan att optimera?
Mvh
speakman
Nä, jag kan nog hålla med att kompilern kan optimera bra även på 8051.
Vad jag menar är att arkitekturen i 8051 är så pass ålderdomlig att den är svår att optimer i sig, oberoende på programmeringsnivå så att säga.
Men visst, har man inte skit-bråttom duger den och tiden har ju givit en massa olika versioner med roliga grejor inbyggda. jag tycker att vid generella applikationer är det egentligen inte frågan om vilken MCU man använder men mer en fråga om programmeringsmiljö.
Jag har kommit så pass långt med C att när jag ska göra de enheter som vi lever på att sälja använder jag exakt samma kommunikationsdefinitionsfil oberoende på om det är med BCB6 till PC:n eller C till MCU:n.
Då uppstår inga fel vid att man skrivar fel eller så, definitionen är den samma varje gång, skitsmidigt.
Vad jag menar är att arkitekturen i 8051 är så pass ålderdomlig att den är svår att optimer i sig, oberoende på programmeringsnivå så att säga.
Men visst, har man inte skit-bråttom duger den och tiden har ju givit en massa olika versioner med roliga grejor inbyggda. jag tycker att vid generella applikationer är det egentligen inte frågan om vilken MCU man använder men mer en fråga om programmeringsmiljö.
Jag har kommit så pass långt med C att när jag ska göra de enheter som vi lever på att sälja använder jag exakt samma kommunikationsdefinitionsfil oberoende på om det är med BCB6 till PC:n eller C till MCU:n.
Då uppstår inga fel vid att man skrivar fel eller så, definitionen är den samma varje gång, skitsmidigt.
