Nu ska man kanske inte lära sig C via en bok om hur man programmerar AVR. Om man inte kan något om C och samtidigt vill lära sig programmera AVR i C så bör man ha flera böcker:
1) en bok om C som ska vara kompilator- och systemneutral. (Där ingår givetvis standardbiblioteken så man lär sig att använda bibliotek).
2) en bok om AVR programmering i C.
I det senare fallet bör det nog finnas med vissa AVR specifika bibliotek eftersom det annars blir väldigt jobbigt att koda. T.exAVR-LibC. Annars blir det svårt med en massa saker.
Jag har haft "Programmeringsspråket C" av Brian W. Kernighan hemma drygt en månad nu och tycker följande: Det kan hända att den är bra på så vis att den tar upp alla aspekter av språket och verkligen går in i varje detalj. Det är viktigt att känna till om man ska kunna programmera bra. Men för en nybörjare som precis ska lära sig C så upplever jag den onödigt komplicerad och den kunde varit mycket mer lättläst. Så för nybörjare rekommenderar jag någon annan bok om C på en lite enklare nivå. Nu har jag inte hittat nån sådan än som jag verkligen gillar. Har läst "C genom ett nyckelhål" av Håkan Strömberg. Den var väl sådär... lite rörig (dåligt strukturerad) men ändå lätt att förstå för en nybörjare. Bäst är givetvis att ha både nybörjar- och proffslitteratur hemma.
Är det inte dags för något nytt? Programmeringsspråk AVR
Re: Är det inte dags för något nytt? Programmeringsspråk AVR
Det finns sällan *en* enda bok som täcker in alla behov.
Från de miljöer där jag är van att jobba så är det normala att t.ex alla
kompilatorer (t.ex C) har flera olika manualer med lite olika inriktning.
Det vanliga är att det finns minst en "User Guide" och en "Languange Reference Manual".
I fallet med C finns det även en "C Run-Time Library (RTL) Reference Manual".
"C User Guide" (drygt 700 sid) är den mer praktiskt inriktade där t.ex hantering av
källkod, kompilering och länkning finns beskrivet med många praktiska exempel.
"C Languange Reference Manual" (ca 350 sid) är mer torr där allt beskrivs mer i detalj på
ett koncist och exakt sätt. Det är dock ingen speciellt bra introduktion till C.
(Böckerna av Kernighan verkar ligga inom denna kategori).
"C RTL..." (nästan 1100 sidor) är ytterligare detaljerad och beskriver t.ex hur man länkar C
kod mot den "shareable image" som ingår i RunTime miljön för C samt fördjupade beskrivningar
av det som ingår i C "Runtime Library" (d.v.s i princip det man kallar "libarna") miljön.
Så min poäng är att vilket bok man ska leta efter beror helt på vad det är man vill veta.
Är det en introduktion till språket? Då kan det fungerar med en generell bok från biblioteket.
Eller är det en specifik manual för den speciella miljö som man tänker jobba i? Då får man
nog leta efter det som konstruktören för den specifika verktyget (kompilatorn) erbjuder...
"Reference Manual" säger också
Från de miljöer där jag är van att jobba så är det normala att t.ex alla
kompilatorer (t.ex C) har flera olika manualer med lite olika inriktning.
Det vanliga är att det finns minst en "User Guide" och en "Languange Reference Manual".
I fallet med C finns det även en "C Run-Time Library (RTL) Reference Manual".
"C User Guide" (drygt 700 sid) är den mer praktiskt inriktade där t.ex hantering av
källkod, kompilering och länkning finns beskrivet med många praktiska exempel.
"C Languange Reference Manual" (ca 350 sid) är mer torr där allt beskrivs mer i detalj på
ett koncist och exakt sätt. Det är dock ingen speciellt bra introduktion till C.
(Böckerna av Kernighan verkar ligga inom denna kategori).
"C RTL..." (nästan 1100 sidor) är ytterligare detaljerad och beskriver t.ex hur man länkar C
kod mot den "shareable image" som ingår i RunTime miljön för C samt fördjupade beskrivningar
av det som ingår i C "Runtime Library" (d.v.s i princip det man kallar "libarna") miljön.
Så min poäng är att vilket bok man ska leta efter beror helt på vad det är man vill veta.
Är det en introduktion till språket? Då kan det fungerar med en generell bok från biblioteket.
Eller är det en specifik manual för den speciella miljö som man tänker jobba i? Då får man
nog leta efter det som konstruktören för den specifika verktyget (kompilatorn) erbjuder...
"Reference Manual" säger också
Purpose of the ANSI Standard :
The ANSI C standard was developed by a committee of program developers
and knowledgeable C users to address the problems caused by inexact
specification of the C language. These problems were primarily related to
portability of programs between different types of machines. The committee
analyzed the language for areas where its syntax and semantics were vague or
indeterminate, and then chose precise definitions for those C constructs. The
result is an unambiguous, machine-independent definition.
The ANSI C standard states that it:
"specifies the form and establishes the interpretation of programs expressed
in the programming language C. [The standard’s] purpose is to promote
portability, reliability, maintainability, and efficient execution of C language
programs on a variety of computing systems."
The standard specifies:
• Representation, syntax, and constraints of the C language
• Semantic rules for interpreting C programs
• Representation of input and output in C programs
The ANSI C standard does *not* specify:
• How C programs are compiled
• How C programs are linked
• How C programs are executed
• All minimum or maximum limits on the size of machines running ANSI C programs
Re: Är det inte dags för något nytt? Programmeringsspråk AVR
Nu var väl Gildebrand ute efter en nybörjarbok om C förstår jag.
Men det räcker inte om man ska fatta hur man programmerar en AVR (det är en del special med microcontrollers som man inte kan få reda på i en bok om C), så då gäller, förutom nybörjarboken i C en bok om AVR-programmering i C. Och den nämdes ju tidigare i den här tråden. Den är värd att lånas på biblioteket, men knappast värd att köpas - när man väl lärt sig grunderna i AVR programmeringen så kan man överge den boken och förlita sig till bl.a. AVR-LibC bibliotekets hjälpfiler.
Men det räcker inte om man ska fatta hur man programmerar en AVR (det är en del special med microcontrollers som man inte kan få reda på i en bok om C), så då gäller, förutom nybörjarboken i C en bok om AVR-programmering i C. Och den nämdes ju tidigare i den här tråden. Den är värd att lånas på biblioteket, men knappast värd att köpas - när man väl lärt sig grunderna i AVR programmeringen så kan man överge den boken och förlita sig till bl.a. AVR-LibC bibliotekets hjälpfiler.
Re: Är det inte dags för något nytt? Programmeringsspråk AVR
Innan jag kommenterar det här måste jag säga att jag har goda kunskaper i programmering i allmänhet, och bra koll på C++ samt java. Basic har jag använt under 90-talet men jag är nog är skapligt rostig där. Jag har programmerat en massa C också (mest AVR och ARM7), men jag måste erkänna att det kan finnas teoretiska luckor i sådana delar som jag inte använder så mycket. Kunskaper i C#, ASP, etc. är i princip noll.
Jag har sett lite större system (Cortex M3) som har gått jäkligt bra trots C++. Alla verkar tro att man behöver sluka minne så in i h-vete bara för att man använder ett objektorienterat språk. Det är inte helt sant, om man gör det på rätt sätt kan man få de godbitar man vill använda utan att kostnaden blir för stor. I de småsaker som de flesta AVR:er gör så spelar det faktiskt inte någon roll med optimeringen. Hur många gånger har man inte slagit av optimeringen vid felsökning, och därefter inte satt på den igen eftersom det inte behövs? Sen finns det en del system som behöver all optimering de kan få. Då är det helt rätt med C, jag säger inget annat.
Några stora fördelar med C++ i embedded:
(1) Portabilitet. I min mening ska man använda C++ fullt ut i PC-system och större embedded (ARM7 och uppåt). Det borde då vara smart att kunna dela källkod med de mindre CPUerna i samma system.
(2) Debug. Jag tycker det är lättare att hålla ordning på vad som används av olika delar, och på så vis blir felen mer lokala och mindre "oj jag råkade skriva över halva minnet". Huruvida man kan använda STL Vector eller liknande effektivt nog låter jag vara osagt (dock lovar jag att jag kommer att testa om jag får tag i någon vettig C++ till AVR).
(3) Kan blandas med C. Jämfört med att ge sig på java(urk) så går det utmärkt att blanda C och C++. Alltså kan man skriva de hårdvarunära rutinerna i C och skriva sin Main och den övergripande hanteringen av datastrukturer etc. i C++. Ungefär som man gjorde med assembler och C på 80-90-talet.
(4) Minneshantering. Dynamiskt allokerat minne i embedded-världen är inte alltid bra. Men ibland är det faktiskt användbart. Problemet som jag har sett är att i ett par C-kompilatorer för embedded så saknas en minneshanterare. Man kan alltså inte använda malloc() direkt utan man måste antingen ladda ner någon tredjepartshistoria eller göra en egen specialare. Jag har hittils inte sett en embedded C++-kompilator som inte implementerar new().
(5) Hårdvaruabstraktion. Detta är ibland direkt olämpligt för en liten AVR, men ibland kan det vara möjligt att se t.ex. en SPI-kanal som ett objekt, så att samma kod kan användas på olika familjer.
...aargh, nu blev man ju sugen på C++. Vilken är den minsta/billigaste familjen som man kan få tag på en gratis C++-kompilator till?
Jag har sett lite större system (Cortex M3) som har gått jäkligt bra trots C++. Alla verkar tro att man behöver sluka minne så in i h-vete bara för att man använder ett objektorienterat språk. Det är inte helt sant, om man gör det på rätt sätt kan man få de godbitar man vill använda utan att kostnaden blir för stor. I de småsaker som de flesta AVR:er gör så spelar det faktiskt inte någon roll med optimeringen. Hur många gånger har man inte slagit av optimeringen vid felsökning, och därefter inte satt på den igen eftersom det inte behövs? Sen finns det en del system som behöver all optimering de kan få. Då är det helt rätt med C, jag säger inget annat.
Några stora fördelar med C++ i embedded:
(1) Portabilitet. I min mening ska man använda C++ fullt ut i PC-system och större embedded (ARM7 och uppåt). Det borde då vara smart att kunna dela källkod med de mindre CPUerna i samma system.
(2) Debug. Jag tycker det är lättare att hålla ordning på vad som används av olika delar, och på så vis blir felen mer lokala och mindre "oj jag råkade skriva över halva minnet". Huruvida man kan använda STL Vector eller liknande effektivt nog låter jag vara osagt (dock lovar jag att jag kommer att testa om jag får tag i någon vettig C++ till AVR).
(3) Kan blandas med C. Jämfört med att ge sig på java(urk) så går det utmärkt att blanda C och C++. Alltså kan man skriva de hårdvarunära rutinerna i C och skriva sin Main och den övergripande hanteringen av datastrukturer etc. i C++. Ungefär som man gjorde med assembler och C på 80-90-talet.
(4) Minneshantering. Dynamiskt allokerat minne i embedded-världen är inte alltid bra. Men ibland är det faktiskt användbart. Problemet som jag har sett är att i ett par C-kompilatorer för embedded så saknas en minneshanterare. Man kan alltså inte använda malloc() direkt utan man måste antingen ladda ner någon tredjepartshistoria eller göra en egen specialare. Jag har hittils inte sett en embedded C++-kompilator som inte implementerar new().
(5) Hårdvaruabstraktion. Detta är ibland direkt olämpligt för en liten AVR, men ibland kan det vara möjligt att se t.ex. en SPI-kanal som ett objekt, så att samma kod kan användas på olika familjer.
...aargh, nu blev man ju sugen på C++. Vilken är den minsta/billigaste familjen som man kan få tag på en gratis C++-kompilator till?
Re: Är det inte dags för något nytt? Programmeringsspråk AVR
Renesas kompiler kan köra i C++-läge, gratis upp till 64k kod.
1: C++ är inte speciellt portabelt, det är ANSI C däremot. Faktisk använder jag samma källkod med alla definitioner osv. till µC & PC om de ska kommunicera med varandra, enkelt och ger ingen fel pga. glömda uppdateringar.
2: Det är väl knappast en C++ grej, det är mer en programmeringsteknisk grej.
3. Öhhh... C++ ÄR C fast med lite mer gruppering.
Jag gillar C++ för att man kan göra klasser men det går lika bra att skydda variabelnamn vid att ha olika funktioner i egna filer och använda "static" rätt, vad som är problemet med C++ är alla initieringar och termineringar som kan ställa till det om man inte har koll på läget.
Att skapa en klass tar inte fler resurser så det kan vara trevligare med C++, problemen uppstår ofta för att vissa använder dessa "smarta" funktioner som finns med lite olika kompilers (t.ex. lcdout(enhelveteslistamedparameter)) och om man gör en universell klass ska den ju innehålla "allt" och inte bara vad som behövs i det aktuella projekt varför den har en tendens att bloata ganska allvarligt.
1: C++ är inte speciellt portabelt, det är ANSI C däremot. Faktisk använder jag samma källkod med alla definitioner osv. till µC & PC om de ska kommunicera med varandra, enkelt och ger ingen fel pga. glömda uppdateringar.
2: Det är väl knappast en C++ grej, det är mer en programmeringsteknisk grej.
3. Öhhh... C++ ÄR C fast med lite mer gruppering.
Jag gillar C++ för att man kan göra klasser men det går lika bra att skydda variabelnamn vid att ha olika funktioner i egna filer och använda "static" rätt, vad som är problemet med C++ är alla initieringar och termineringar som kan ställa till det om man inte har koll på läget.
Att skapa en klass tar inte fler resurser så det kan vara trevligare med C++, problemen uppstår ofta för att vissa använder dessa "smarta" funktioner som finns med lite olika kompilers (t.ex. lcdout(enhelveteslistamedparameter)) och om man gör en universell klass ska den ju innehålla "allt" och inte bara vad som behövs i det aktuella projekt varför den har en tendens att bloata ganska allvarligt.
