nu undrar jag ifall det finns någon enkel tutorial som man kan följa för att lära sig det här? helst i c men asm går väl bra annars
Programera en klocka
Programera en klocka
Har just fått hem min STK500 och tänkte sitta och koda nåt kul, och valet föll på en digital klocka
nu undrar jag ifall det finns någon enkel tutorial som man kan följa för att lära sig det här? helst i c men asm går väl bra annars
nu undrar jag ifall det finns någon enkel tutorial som man kan följa för att lära sig det här? helst i c men asm går väl bra annars
finns massor av roliga byggen och dessutom alla appnotes på:
http://avrfreaks.net/
(appnotes ligger under tools/tooltree)
http://avrfreaks.net/
(appnotes ligger under tools/tooltree)
etnica skrev:I manualen finns det ett asm exempel för dioder.
På Atmels hemsida finns några getstarted tutorials också.
PÅ avrfreaks som nämndes innan finns massa info också.
kollade på hemsidan och manualen men det mesta är färdiga koder i asm, finns det ingen tutorial i c som går i genom steg för steg?Krawk skrev:finns massor av roliga byggen och dessutom alla appnotes på:
http://avrfreaks.net/
(appnotes ligger under tools/tooltree)
-
henkebenke
- Inlägg: 515
- Blev medlem: 31 maj 2003, 10:42:37
- Ort: Helsingborg
Men ge dig. Assembler är inte lösningen på alla problem. Man kan mycket väl få förståelse för en mikrokontroller genom att programmera i C. Och det är skönt att du har citationstecken runt "på riktigt" annars kunde man ju trott att C-kod inte exekverar lika bra som assembler. Som tur är att till skillnad från PIC-kretsarna så är ju AVR gjorda för lite modernare högnivåspråk som C så att man slipper sitta och knacka assembler.
Man kan inte som proffessionell mjukvaruutvecklare (vilket jag antar att du på någotvis är) förespråka assembler i alla lägen för det är BS. Det beror på produktivitet, time to market, prestandakrav mm. Och för en amatör som känner till högvaruspråk att då föreslå att gå över till assembler är ju befängt.
Man kan inte som proffessionell mjukvaruutvecklare (vilket jag antar att du på någotvis är) förespråka assembler i alla lägen för det är BS. Det beror på produktivitet, time to market, prestandakrav mm. Och för en amatör som känner till högvaruspråk att då föreslå att gå över till assembler är ju befängt.
-
bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
..mmm, men en del av finessen med mikrocontroller går förlorad om man kör högnivåspråk. Främsta fördelen med assambler är att man kan få saker att hända exakt tidsmässigt då man vet precis hur många klockcykler något tar. Det är, i mitt tycke, ett skäl som enbart det motiverar den lite bökigare programeringen att kunna få exakt kontroll på timingen, att kunna styra förlopp och det stämmer ner till 10-tals eller 100-tals nanosekunder när är i många sammanhang värt väldigt mycket. För även om C-kod kan bli snabb, så har man där förlorat möjligheten att räkna klockcykler.
oki, oki - visst kör jag också med högnivå ibland, men Sodjan har helt rätt i att det finns en stor vinst i att först lära sig assambler, och så satans svårt är det inte - inte för att komma igång iaf.
oki, oki - visst kör jag också med högnivå ibland, men Sodjan har helt rätt i att det finns en stor vinst i att först lära sig assambler, och så satans svårt är det inte - inte för att komma igång iaf.
-
henkebenke
- Inlägg: 515
- Blev medlem: 31 maj 2003, 10:42:37
- Ort: Helsingborg
Nä, men det vore väl för sorgligt om någon skulle ge upp mikrokontrollers för att någon på ett forum sitter och säger att assembler är den enda sanna vägen. Ska man ha nanosekundsnoggrannhet så må assembler vara den enda vägen. Men sitter man med ett projekt som kräver detta så har man nog själv insett att assembler är sättet att uppnå detta.
Jag påstår att all(och med all menar jag 90-95%) kod i professionellt utvecklade mikrokontrollersystem är skrivet i C. Detta framförallt för att det inte finns någon som vill betala för en som omotiverat producerar 1/10 så mycket kod per tidsenhet bara för att man vill programmera "på riktigt".
Jag påstår att all(och med all menar jag 90-95%) kod i professionellt utvecklade mikrokontrollersystem är skrivet i C. Detta framförallt för att det inte finns någon som vill betala för en som omotiverat producerar 1/10 så mycket kod per tidsenhet bara för att man vill programmera "på riktigt".
Jag sitter med en Fujitsu processor som har 600-700 olika kommandon. Att programmera i assembler kan vara en bra inkörningsport till förståelse av hur det hänger ihop men för att det ska vara något så när effektivt krävs nog en RISC, att sitta och bläddre för att hitta rätt kommando ger inget överblick ocg flyt i programmeringen.
Allt jag gör med PIC gör jag i assembler, 99% av vad jag gör på Fujitsu'n gör jag i C (1% assembler för optimering), 100% av vad jag gör till PC:n gör jag i C++ och 100% av vad jag gör till PocketPC är i C.NET. Detta är helt enkelt det effektivaste.
Att ge sig på en CISC i assembler "för att få överblick" är nonsens, inlärningströskeln är väldig hög, med RISC är den strax mer överskådelig.
Man kan fint fatta hur en MCU fungerar från ett högnivåspråk som C, det kan till och med vara enklare, lite beroende på programmeringsmiljön men för att göra riktigt effektiva program kan jag hålla med om att man ska smaka ordentligt på assembler för att fatta ordentligt men det behöver inte vara ingångsporten, det fungerar även som ett steg på vägen.
Har man å andra sidan realtidskrav (som jag har i en hel del av mina projekt) måste man ha en bra översikt över programflödet, interrupthanteringen, prioritering osv och för det behöver man inte att krypa ner i assembler, det går fint i C....om man väl har fattat hur systemet hänger ihop.
Är svartidskraven mycket höga kan de flesta processorer ändå inte hänga med, där behöver man dedikerade hårdvaralösningar men då är det i alla fall pengar bakom.
Så jag ger inte mycket för att "man måste börja med assembler" och "riktig programmering är assembler", jag har gjort STORA program till Z80 t.ex. (TRS80 komplett ny mjukvara) och det var ta mig fan inte enkelt i assembler, då jag köpte en Pascal ökade min produktivitet avsevärd och sedan har jag fastnat för C som är nära assembler samtidig som jag har enklare programmering.
Det kanske är för män med hår på bröstet att sitta och uppfinna hjulet ett antal gånger i assembler och i vissa lägen kan det ha sin berättigelse men det är inte ofta!
Allt jag gör med PIC gör jag i assembler, 99% av vad jag gör på Fujitsu'n gör jag i C (1% assembler för optimering), 100% av vad jag gör till PC:n gör jag i C++ och 100% av vad jag gör till PocketPC är i C.NET. Detta är helt enkelt det effektivaste.
Att ge sig på en CISC i assembler "för att få överblick" är nonsens, inlärningströskeln är väldig hög, med RISC är den strax mer överskådelig.
Man kan fint fatta hur en MCU fungerar från ett högnivåspråk som C, det kan till och med vara enklare, lite beroende på programmeringsmiljön men för att göra riktigt effektiva program kan jag hålla med om att man ska smaka ordentligt på assembler för att fatta ordentligt men det behöver inte vara ingångsporten, det fungerar även som ett steg på vägen.
Har man å andra sidan realtidskrav (som jag har i en hel del av mina projekt) måste man ha en bra översikt över programflödet, interrupthanteringen, prioritering osv och för det behöver man inte att krypa ner i assembler, det går fint i C....om man väl har fattat hur systemet hänger ihop.
Är svartidskraven mycket höga kan de flesta processorer ändå inte hänga med, där behöver man dedikerade hårdvaralösningar men då är det i alla fall pengar bakom.
Så jag ger inte mycket för att "man måste börja med assembler" och "riktig programmering är assembler", jag har gjort STORA program till Z80 t.ex. (TRS80 komplett ny mjukvara) och det var ta mig fan inte enkelt i assembler, då jag köpte en Pascal ökade min produktivitet avsevärd och sedan har jag fastnat för C som är nära assembler samtidig som jag har enklare programmering.
Det kanske är för män med hår på bröstet att sitta och uppfinna hjulet ett antal gånger i assembler och i vissa lägen kan det ha sin berättigelse men det är inte ofta!
-
bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Det finns som alltid olika sätt att se på saken. Mer komplexa projekt är naturligen rätt bökiga att skriva i assambler och passar sig bättre till högnivåspråk, men om ofta använder mikrokontroller som ersättare till diskreta lösningar för att spara komponenter och dessutom använder sig av 8-bitars RISC-processorer så är det inget som slår assambler. Det finns ju mer än ett sätt att använda mikrokontrollers. Titta exempelvis på de små 6 och 8-pinnars som pic10f och pic 12f, dessa har likssom inte minne nog att använda några högnivåspråk - och om kretsen bara skall vara en klocksynkgenerator som ger en väl definerierd tidsföljd av synksignaler när den får en viss signal på en ingång så känner något annat än assambler som lite fånigt när hela programmet blir 25 rader kod i assambler...
Även denna användning av mikrokontroller är väl motiverad då slutresultatet blir en kompaktare och billigare krets än att bygga upp med hederliga 74-kretsar, dessutom får man mindre emc-problem och lägre effektutveckling.
Även denna användning av mikrokontroller är väl motiverad då slutresultatet blir en kompaktare och billigare krets än att bygga upp med hederliga 74-kretsar, dessutom får man mindre emc-problem och lägre effektutveckling.
Oavsett vad man väljer för språk är det bra att kunna en del om binära och hexadecimala talsystemet, bits, bytes, words, adressering och hur logiska operander som and, or, xor fungerar. Iallafall om man skall programmera microkontrollers.
Jag började med BASIC på ABC-80 och sedan på C-64. Man får trots allt lite förutfattade meningar om datorn genom högnivåspråk. Om man t.ex. tar ett kommando som "print 'Hello World!'" så hade iaf jag den uppfattningen att "Hello World!" skrevs ut med en instruktion på en gång. Så är det givetvis inte, print är en funktion som i tur och ordning loopar sig igenom bokstav för bokstav och skickar dessa till vald IO-enhet.
Däremot skall man defenitivt använda högnivåspråk där sig bör. Jag skulle inte frivilligt ge mig på att t.ex skriva om "float x = a * pi +(z * y)/sin(v)" manuellt i assembler.
mvh Mats
Jag började med BASIC på ABC-80 och sedan på C-64. Man får trots allt lite förutfattade meningar om datorn genom högnivåspråk. Om man t.ex. tar ett kommando som "print 'Hello World!'" så hade iaf jag den uppfattningen att "Hello World!" skrevs ut med en instruktion på en gång. Så är det givetvis inte, print är en funktion som i tur och ordning loopar sig igenom bokstav för bokstav och skickar dessa till vald IO-enhet.
Däremot skall man defenitivt använda högnivåspråk där sig bör. Jag skulle inte frivilligt ge mig på att t.ex skriva om "float x = a * pi +(z * y)/sin(v)" manuellt i assembler.
mvh Mats
