Jesses följetång om AVR programmering i C...

[bos]

Med andra ord läser du fel böcker. K&R (som jag länkade till) är originalet som förklarar _språket_ och inte hur du gör si och så (med vissa undantag - ett par C-lib-funktioner finns förklarade). Du skriver exempelvis att du sökte på nätet för att lära dig "extern". Om du slarvläser böckerna du har eller om det inte framgår i dem vet jag inte, men att ha tre C-böcker och inte veta vad extern gör känns lite anmärkningsvärt.

Om det är så att du verkligen lära dig C så läs K&R (finns säkert som PDF på nätet nånstans). Boken är skriven av de personer som uppfann språket, så bättre språkreferens finns inte att hitta. Men om du däremot bara är ute för att få reda på hur du gör en viss sak eller moment utan att egentligen veta hur språket fungerar så är kanske inte boken ett bra val för dig. Det är bara du själv som vet vad du vill ha ut av språket.

Av denna tråd att döma är det mycket du har att lära av hur C hanterar variablar (extern, bland annat). Du kanske kan börja där om du inte orkar skaffa en bok till?

[sodjan]

Detta med separata kompileringar, länkningar och hur symboler hanteras
är igentligen ingenting specifikt för just C. Det fungerar i princip likadant
oavsett språk. Det som kan skilja lite är vilka nyckelord som används i de
olika språken. De språk jag brukar använda har vanligtsvis en "Reference manual"
som ger alla detaljer samt en "User Guide" som visar hur man använder det
som Ref-manualen beskriver i praktiken. Det som verkar saknas just här är
just en "User Guide" för den aktuella utvecklingsmiljön...

Om man aldrig ha jobbat med miljöer med källkod => objektkod => exefiler
så kan det vara lite rörigt i början.

Ovanpå detta kan även en IDE snurra till det lite extra genom att t.ex
skapa kommandorader "on-the-fly" där det kan förekomma definitioner
av symboler (som alltså inte syns i källkoden). Jag antar att det är denna
väg som F_OSC (eller igentligen den där symbolen med okänt namn)
kommer in i bilden.

[jesse]

Bos: Det är just det jag tycker är så kasst med många böcker om progrmmering - de förklarar hur jag gör en sak, men inte varför eller hur. En referensbok är vad jag söker.

Sodjan: Jo, jag känner ganska förvirrad i programmeringsmiljön. Jag använder ju AVRStudio4 med AVR-GCC och den är ju jättebra, men att fatta vad som pågår i kulisserna är ibland hopplöst. Det gör ju inte saken bättre att jag aldrig tidigare gjort ett program i C, inte ens för PC. (Bortsett från ett "Hello World" som jag gjorde för någon vecka sedan i "Quincy C" IDE.) Men hjälpfilerna till avr-libc har varit en guldgruva, liksom en del C-tutorials på nätet.

Jag visste vad extern betydde, hade bara inte tänkt på att det behövdes där. Har inte vanan inne än, så att säga, men jag är på gång

[speakman]

En av anledningarna att jag ratar IDE:er med projekthanterar et al och föredrar att skruva på filnivå är bl.a. att man lär sig på djup nivå hur saker fungerar och man kan göra saker med fingertoppskänsla. Det är väldigt många som fortfarande inte förstår skillnaden mellan kompilering och länkning, trots många år bakom C-filer...

[SvenW]

Jag skulle tro att det bästa sättet att lära sig programmering är just det du gör: hoppa in och jobba med just avr-gcc.
Läroböcker är nödvändigt, men inte tillräckligt.
Just genom att lösa praktiska och angelägna problem lär man sig bäst.
Det ger motivation. Genom att börja med små program och se hur kompilatorn lägger ut kod, hur map-filen ser ut, hur makefilen fungerar etc så får man efterhand förståelse. Ibland kör man fast och fattar ingenting. Då är det bara att sova på saken eller fråga någon som kan.
En annan viktig sak är att träna sig i konsten att läsa andras kod.
Då lär man sig hur man inte skall göra

[jesse]

Angående att lära sig läsa andras kod: mitt "problem" är nog att jag sällan fattar andras kod. Dels för att de är dåligt kommenterade, men dels för att macron och funktioner har helt obegripliga namn baserade på en rad förkortningar , och dessa ska man förstå! Enda sättet att fatta sån kod är ju att lusläsa varje rad och kolla vad den gör. Vilket inte är så lätt med alla dessa macros mm...

Så efter några fruktlösa försök så gör jag en helt egen kod istället. Då förstår jag i alla fall logiken.

[SvenW]

Det gäller som sagt att träna sig. En annan viktig sak är att ha bra verktyg. En bra editor/codebrowser. Emacs är perfekt när man väl lärt sig konfigurera den, eller skall vi säga 'programmera upp' den.
Detta tar också tid att lära, naturligtvis.
Om man ser ett okänt makro, eller en okänd funtion, så ska det bara handla om ett musklick för att ha headerfilen/definitionen/deklarationen/manualsidan på skärmen framför sig. Har man inte bra hjälpmedel går det inte.
Ett exempel på bra och lättläst c-kod är gtk+. Kod avsedd för enchipsdatorer är däremot i allmännhet ganska svår.
Jag har lite grann som hobby att läsa c-kod. En mycket udda hobby tycker nog många. Hur som helst med det, jag har nog läst igenom mer än hälften av gtk+, stora delar av källkoden till ngspice, gnucap, gEDA-gschem, PCB, tgif, xcircuit, linuxkärnan.

[Mr M]

Det här med vad man ska inkludera i c- och h-filerna

Headers files should only include those (header) files that are required for header file to compile. Do not include files that are only used by the associated .c file. The #include statements in your header files define the dependency of the file –fewer the dependencies the better.

Samma gäller för C-filer också.

[Mr M]

Om det är så att du verkligen lära dig C så läs K&R (finns säkert som PDF på nätet nånstans). Boken är skriven av de personer som uppfann språket, så bättre språkreferens finns inte att hitta.

Men även om de skrev språket så kanske de inte är de bästa att lära ut det. Har den boken hemma (+ lösningsboken till alla övningarna) och i början tyckte jag den var klurig, så jag köpte andra böcker. Men nu när man vet mer så funkar KR-boken också.

[Mr M]

Det gäller som sagt att träna sig. En annan viktig sak är att ha bra verktyg. En bra editor/codebrowser.

Apropå bra IDE. Jag har börjat testa Eclipse IDE för C programmering (gratis IDE). Och den är skitbra. Ifall man håller muspekaren på en funktion, variabel, eller makro så kommer det upp en lite gul ruta under som visar var motsvarande definieras.

Man kan även ändra namn på funktioner och variabler så letar den upp alla dessa i projektfilerna och ändrar på dem.

Sen går det att få upp vilka funktioner som anropar en funktion.

Och det finns även kodformatering om man vill ha det, så det ser snyggt ut (lägger in mellanslag, tabbar, indenteringar m.m)

http://www.eclipse.org/cdt/

[swesysmgr]

Problemet att grundkurser i C oftast inte kommer till dessa saker. Jag har tre böcker hemma just nu, inte i någon av dem nämns hur man gör ett projekt med mer än en källfil! Ändå är en av dem på 595 sidor!

Men du ar väl rätt, jag skulle vilja ha en bra grundöversikt på över språket och programmeringsmiljön.

Boken du hänvisar till verkar finnas även på svenska!

K&R är bra med mycket innehåll på rimligt antal sidor och otroligt snygg och kompakt kod jag själv ännu inte kan drömma om att skriva men kanske lite svår för en ren nybörjare.

Jag som inte är så rutinerad på detta tycker ofta det är enklare att dela på problemet och skriva och tänka ut huvudprogram och algoritmer som ett vanligt C-program och sedan portera över det till AVR, då vet man om det är fel i programmets tänk eller i kommunikationen med hårdvara/begränsningar i målmiljön.

IDE eller inte och i så fall vilken tycker alla olika om, att ha tillgång till en vettig debugger så att man kan se vad som händer och vad som gick fel tycker jag är ovärderligt när man lär sig ett nytt språk.

Om du kan lite grundläggande programmering innan så tycker jag att Skansholm/Bilting "Vägen till C" lär ut språket inkl. pekarhantering, länkning m.m. på ett mycket bra och koncist sätt samt på ett rimligt antal sidor.

[jesse]

Ja, Skansholm är bra. Jag har läst hans javaböcker, så jag litar på att hans böcker om C håller lika hög kvalitet. (Logiskt, enkelt, rakt på sak utan onödigt snack och med rejäla definitioner)

Om man ser ett okänt makro, eller en okänd funtion, så ska det bara handla om ett musklick för att ha headerfilen/definitionen/deklarationen/manualsidan på skärmen framför sig.

Försök det, ni som förespråkar kommandoradskompilering.

AVRStudio är ju hyfsat bra, men den funktionen hade jag gärna sett! Men att den själv letar upp stället där man får en varning eller error är ju supervärdefullt. Annars går ju halva dan åt att leta i koden. Tyvärr har AVRStudio en bugg som gör att den ibland inte hittar i filerna. Det uppstår ibland, och jag har inte kommit på varför. Jag måste starta om AVRStudio för att den ska hitta igen. När den vär börjar krångla så funkar varken simulatorn (den visar inte var den är), find in files, eller att slå upp felaktiga rader i koden. Dessutom så om man editerar en fil och sparar den, så får kompilatorn tag på en äldre version av filen (vilken man inte kan se på skärmen) vilket naturligtvis gör att man kan bli tokig, då konstiga saker uppstår.

[bearing]

Du ska naturligtvis inte leta manuellt. I linux använder jag "grep" för att leta rätt på definitioner. I windows använde jag länge Crimson Editor som har inbyggd "grep". Nu har Crimson-programmet slutat uppdateras. Windows har ju inbyggd "search in files", men den söker inte i alla filtyper trots att man anger *. Grep finns att ladda hem till windows från sourceforge.

[speakman]

Om man ser ett okänt makro, eller en okänd funtion, så ska det bara handla om ett musklick för att ha headerfilen/definitionen/deklarationen/manualsidan på skärmen framför sig.

Ehm, ja när jag flyttar markören över en funktion så får jag hela prototypen i minibuff i Emacs. Och vill jag hoppa hoppa in i definitionen av funktionen trycker jag Alt+. (alt-knappen och punkt samtidigt, M-. som det heter på emacska).

[SvenW]

Det var intressant. Hur lockar du fram den finessen?