Tråden med råd om programmering.

[JimmyAndersson]

Jag lovade att jag skulle skriva lite om mina erfarenheter av PIC-programmering och varför/hur det nu äntligen har "lossnat".

Syftet är inte att inlägget ska visa "sanningen" eller "lösningen". Vilka skor som känns bekväma är helt individuellt...
Tanken är istället att väcka lite inspiration hos de som tycker att programmering av mikrokontrollers känns som en enda uppförsbacke.
Kan även tillägga att det inte gäller någon speciell typ av mikrokontroller eller något speciellt språk.


Texten fram till nästa "--------" är bara lite (nåja host..) bakgrund för min del.
Hoppa över om ni inte orkar läsa.


När jag blev medlem här så kunde man förstås inte undgå inlägg av typen "Det vore lättare att göra med en PIC/AVR"
och efter ett tag blev man förstås sugen att lära sig bemästra denna "problemlösare".
Efter den obligatoriska tråden där jag ställde samma frågor som många andra (vilket jag förstås inte visste då) så insåg
jag snabbt att detta var ett ämne där man förväntas kunna namnen på allt direkt (se svaren i tråden).
Uppförsbacken var påbörjad.

Den fortsatte förstås så fort jag börjat. (Se här om ni vill). Jag försökte överföra den klassiska "blinka med en lysdiod"
till en PIC-krets men det blev bara problem. Kollade allt jag kunde tänka mig och höll på att få fnatt.
Tillslut kom Sodjan på att det var fel i den versionen av XWisp2. Nämnde jag att uppförsbacken var påbörjad?


Sedan har jag fått alla möjliga fel:
En version av XWisp2w som rapporterade om att det var fel på "fuses" i en adress som inte ens skulle ha några fuses.
En annan version som lät mig "tanka över" kod till varje PIC-krets enbart två gånger, sedan fick jag fel.
Felmeddelande om att MPLAB inte kunde skriva till COF-filen när två "symboler" (variabler) var bortkommenterade....
MikroBasic-kod som get helt tokiga resultat på lysdioder när jag lagt till en rad, trots att raden inte utförde något.
Tömd linker-fil till MPLAB.
osv osv osv....

Lagom kul att upptäcka sådana orsaker när man nött koden i evigheter.....
Flera gånger har jag letat fel i kod och lusläste datablad tills jag fått migrän.
Man har sååå gärna velat hitta felen. Trots veckors pauser,
flitigt läsande, genomgång av allt man någonsin kan tänka sig,
men ändå fel. Också är det någon fånig grej som löser problemet.
Jag har t.ex gjort en tråd om ett problem där jag tillslut fotade labplattan
och *då* såg jag att jag hade 1k motstånd istället för 10k.
Det där med motståndet är ett typiskt exempel på hur det kan bli
när man kämpat tills det går lite för fort och man missar de enklaste sakerna.
Ett annat exempel är när jag totalt glömt skillnaderna mellan PIC16 och PIC18
eller missat helt grundläggande saker.

Jag har på senare tid bävat inför varje projekt som krävt PIC-programmering
just eftersom det alltid har börjat lugnt och roligt, men *alltid* blivit till något
irriterande och påfrestande hopplöst problem, även om jag testat med långa
pauser och gjort annat både i och mellan projekten.



I maj i år lämnade jag mitt påbörjade assembler-projekt med etshylla-belysning.
Dels pga alla problem och dels för att det var roligare att vara ute att jobba när det var varmt.
Fem månader senare tog jag fram samma kod-projekt igen, mest för att jag kände för att göra något
innan sovdags och dels för att inte glömma bort hur man gjorde.
Faktiskt så gick det bra. Gjorde en PWM-grej. Fixade så man kunde styra den med en pot.
Vad 17...? Det känns *kul!* ??
Dagen efter lockade koden igen. Satte upp en till timer och den fungerade utan fel på första försöket.
Hmm... har det lossnat? Varför? Hur? Insåg att jag programmerade assembler till PIC ungefär lika
lätt och avslappnat som jag annars programmerar PHP (ett av mina favoritspråk).

Efter mycket om och men så vågade jag skriva ett litet inlägg om det.
Trodde ju först att det var något tillfälligt ryck jag fått.

Men nu är faktiskt det projektet klart!
PWM-styrning av lysdioder, meny med tre funktioner som styrs med enbart en knapp, osv.

Jag fattar ingenting:
Först kämpar man i några år och önskar att det ska "lossna" men det blir bara problem.
Efter fem månader så sätter man sig bara och gör klart sitt livs första riktiga PIC-baserade projekt!


Om det var sådär j-kla lätt så kunde det väl ha fått lossna tidigare?
("Lossna" = Att man kan sitta och knappa och det *blir* saker, programmera utan att det tar tvärstopp hela tiden.)

-----------




Ok, ska vi ta det jag egentligen *skulle* skriva om?

Varför lossnade det?

Ärligt talat är jag inte säker. Jag har tagit långa pauser tidigare, så den variabeln tror jag inte riktigt på som avgörande.
Visst: Det *är* jättebra att ta pauser. Ta en fika, promenad, tänk på något *helt* annat, osv.

Jag kan däremot säga att det känns annorlunda och lättare nu.
Där tycker jag att många gör fel. Jag fattar inte varför det ska vara så intensivt och allvarligt som
det blir i många trådar där folk behöver hjälp.
Hm, jag insåg just en grej... Det var inte bara programmeringen jag tog paus från i somras:
Jag var knappt *här* heller.


Här är iallafall några tips:

• Vet du vad du håller på med?
  
  • Har du kul eller känner du dig tvingad?
    Hatar du databladet eller sitter du och ler och tänker "shit, allt står ju här!" ?
    Det kan vara oändliga timmar med koden eller någons "RTFM!"-inlägg som ökar frustrationen och då sätter
    reptilhjärnan igång. Vips fattar man ingenting. Det kan vara språket eller matten som begränsar.
    Att då försöka förstå hela databladet eller felmeddelanden är som att försöka trä på en 5 nummer
    för liten sko. Det går säkert, men kommer du att ha kul under tiden?
    ..för det var väl därför som du började med det här?
    
    Steg 1 alltså: Ta det inte så allvarligt. Luta dig tillbaka.
    Försök att se det som en kul utmaning.
    Är det kämpigt så kanske du har gått för fort fram?
• Lugn och fin!
  
  • Ta en sak i taget. Skriv/felsök inte hela koden på en gång.
    Vet du vad man måste börja med? Är alla config-register inställda som de ska? Då kan du gå vidare.
    Gå igenom sida för sida. I/O, timers, osv och "ställ in" grej för grej så det är som det ska. Stäng gärna av
    interrupt, analoga ingångar mm när du kommer dit. När du gått igenom allt sådant (man brukar hamna på
    sidor om "Instruction set summary" i databladet då) så brukar jag låta MPLAB (eller vad man använder för
    att göra om källkod till .hexfil) "Bygga" (Build All) koden för att se så jag inte snavat någonstans.
    
    Sedan tar man steg för steg. Vad behöver du ha i koden? Läsa av en knapp? LCD? Sekunder och minuter?
    Ta en av dem i taget. Få en sak att fungera innan du tar nästa. Ska en pot styra något? Använd ett
    fast värde istället för poten tills det-som-ska-styras fungerar. Verifiera varje sak. Sedan, när alla delar
    är klara och testade så kan du låta det ena styra det andra.
  • Verifiera. Dvs, kolla så det du säger dig veta, faktiskt är samma sak som det som verkligen händer.
    Försök att ta *en* sak i taget. T.ex först config-register. Verifiera CPU'n (klura ut hur man gör det med oscilloskop)
    så du slipper anta att den går rätt och att det är något annat som gör att en timer gör så en lysdiod blinkar för sakta...
    Hur vet du att du får ett interrupt när du vrider på poten? Kan alla utgångar ge 5V? osv.
  • Ha inte för bråttom med att svara på inlägg om ditt problem.
    Det är lätt att tänka "Om jag svarar snabbt så kommer hjälpen snabbt och då kommer jag snabbt vidare".
    Glöm det! Man missar alltid något då. Apropå det: Ta med *allt*. Det är lätt att tro att "det här har ingen
    betydelse" eller "det här har jag kollat" när man ska skriva ett inlägg.
    Förresten: Försök att lösa problemen utan forumet. Se det som en sport så långt det går
    och ta bara upp problemet när du känner att du inte kommer längre på egen hand.
  • Ta tid på dig att förstå vad som står i databladet vid det du vill göra. Hoppa inte över det.
    Hur ska man kunna felsöka om man inte förstår hur det ska vara?
    Fråga eller sök mer info.

Slutligen: Jag skriver ju att man ska ta det lugnt.
Det är främst riktat till dem som liksom jag nötte datablad och kod tills man höll på att få licensierat tokfnatt.
För andra kan det lika gärna vara tvärt om på den punkten, dvs att man tagit det lite för lugnt.
Resten gäller för båda "typerna".


..Så nu kommer aldrig få några problem mer? Det sa jag inte.
För min del så sitter jag inte längre fast som superlim så fort det ska göras något.
Det går mycket lättare och jag löser de flesta klurigheterna själv, men ändå lär man förstås köra fast.
Syftet med tråden är att ni som känner igen er kanske kan hitta något som underlättar för er.


Har ni fler tips? Skriv gärna i tråden.

[Marta]

Databladet till en PIC kan säkert kännas helt överväldigande för en nybörjare, som då frågar sig vilka delar som är verkligt viktiga att läsa.

Beskrivningarna av de moduler som Du *inte* skall använda kan Du vanligtvis hoppa över.

Läs nogsamt hela beskrivningen över de moduler Du *skall* använda. Speciellt texten i de skuggade rutorna, den måste Du förstå *helt och hållet* för att inte fastna på de speciella hinder som dessa rutor beskriver. Ofta andra moduler som måste stängas av innan aktuell modul fungerar som Du vill.

Sist i avsnittet för varje modul finns en liten sammanställning över vilka register och bits däri som påverkar modulen. Läs denna noggrannt och kontrollera bit för bit att dessa inställningar verkligen är som Du vill ha dem.

Läs *alltid* beskrivningarna av övergripande moduler, exempelvis oscillatormodulen. T.ex. finns det PIC's som startar i snigelfart tills en bit i ett register har ändrats.

Skall utgångarna driva t.ex. LED's eller annat som tar lite ström, läs alltid "Electrical specifications" just för aktuell PIC. Ta aldrig för givet att alla är samma. Var uppmärksam på att det finns gränser för sammanlagd ström som riskerar att överskridas även om ingen enskild pinne har överbelastats.

Undvik till att börja med att använda interrupts. Kom också ihåg att stacken är begränsad.


För att Ditt program alltid skall ha samma startförutsättningar är det en god ide att inleda med att nolla samtliga RAM-adresser. Gör det däremot *inte* med SFR-adresserna. (Special Function Register är alla de adresser som gör något mera än att lagra värdet Du skriver i den. Exempelvis de första 32 adresserna i en PIC-12 eller -16).

[MicaelKarlsson]

Tipset jag fick från min lärare i Fortran (och statistik) var att alltid sätta sig med penna och papper och skissa på hur programmet skall se ut. Om det görs med pseudokod, JSP-diagram, flödesschema eller egenkonstruerad metod spelar ingen roll. Huvudsaken är att man skaffar sig en vettig struktur på programmet och bryter ner det i mindre bitar.

[Icecap]

Jag har som regel att testa/räkna igenom extremfall om jag gör en beräkningsrutin.
* Vad händer vid negativa värden?
* Vad händer vid noll?
* Vad händer vid -1?
* Vad händer vid högsta positiva värde?
osv. När allt är gått igenom är det dags att testa rutinen i praktiken, detta betyder dock ofta att man kan behöva skriva ut värden.

Saker att kolla igenom är:
* Kan alla mellanresultat vara i de variabler som är avsatt till dom?
* Blir resultaten de rätta? (här går Excel/OO-Calc varm...)

Instämmer helt i M.K. sätt: skriv ner flödet, rita, pilar eller vad som fungerar. Jag brukar skriva stolpar över vilka funktioner som ska byggas och hur de ska kopplas ihop men papper o penna är inte alls ovanligt!

Man kan komma mycket långt med en eller ett par LED som debugging! Bäst är det med några LED + ett oscilloskop, då kan man se vilka rutiner som kallas.

Om man bara har en pinne kan man göra som följer:
Rutin 1: Höjer en LED-pinne när den startar och sänker den när den sluter.
Rutin 2: Höjer, sänker och höjer LED-pinnen vid start och sänker den vid slut.
Detta ger en extra kort puls i början som man kan se på oscilloskopet.
Rutin 3: Höjer, sänker, höjer, sänker, höjer osv...

Det ger lite overhead men man kan se vilka rutiner som kallas och följden också och man behöver inte markera alla rutiner samtidig, bara de intressanta.

Men jag får hålla med TS: blir det overload i skallen ska man lugna sig, gå/springa/cykla en tur, kela med katten (eller musen...), då kommer det ordning igen. Att sitta o titta håglöst på datorn hjälper inte!

[bachler]

Bra tråd.

[psynoise]

Jag använder nästan samma arbetsmetod till alla områden som jag är osäker på. Konstruktion av både digitalt och analogt brukar göras enligt top-down-metoden. Det kan bli blockschema efter blockschema som mer i detalj beskriver dom olika delblocken i konstruktionen. Innan jag sätter mig framför programmeringen vet jag exakt vad som ska göras av programmet enligt anteckningar. Ytterliggare brukar huvudalgoritm eller tillståndsmaskinen bli serverad med enklaste möjliga data som har blivit omvandlad i utomstående funktioner.

[stekern]

Jag är precis tvärtom, jag kör mer enligt bottom-up principen. Implementerar del för del, testar de och sedan knyter ihop helheten.
Båda principerna har sina för och nackdelar.

Instämmer helt med att pauser är bra, lösningar på mina problem brukar oftast komma på bussen hem efter att ha suttit flera timmar med att försöka lösa något på jobbet.
Eller på bussen till jobbet när jag pulat med nåt hobbyprojekt på morgonen.

[sodjan]

Jag tror ni snackar runt varandra lite...

Det är ju skillnad på design resp implementering/kodning.

Top-bottom fungerar ofta bra för design/systemeringen. D.v.s
den övergripande planeringen innan man skriver första kodraden.
Högsta nivån är ju ungefär "nu ska jag göra en mörkrumstimer" t.ex.

Implementeringen/kodningen däremot måste ofta göras tvärtom,
ofta finns det flera saker som behöver testas i "botten" av
applikationen innan man kan gå vidare och knyta ihop det.

[Josty Kid]

Har blivit sugen på att börja programmera någon familj PIC känns ju fint när man läser den fina guiden. Har nog inte skrivit kod sedan Basic och Comal var modernt.

Men till ämnet, jag lärde mig att skriva program på papper - urtråkigt - men ack så effektivt. Då får man snabbt en struktur med funktioner och de variabler som behövs. Jag har alltid gjort så, som underlag för duktiga programmerare. Som oftast får välja både språk och processor utifrån behovet av kod och funktioner. Det är faktiskt en förutsättning för att kunna köpa in en tjänst eller beställa ett programmerings jobb att kunna speca vad man vill ha.

Kan låta tråkigt men jag tror faktiskt att det är lika användbart för små som stora projekt och speciellt för någon som jag som är ovan.

[Icecap]

Precis som sodjan skriver brukar man först få ett överblick så att man har något att jobba emot. Sedan börjar man faktisk i det lilla med simpla rutiner, t.ex. läsa knappsats, skriva till display, serieport-kommunikation, EEPROM och vad som behövs, dessa enskilde rutiner kan sedan testas och verifieras, det är sinnessjukt mycket enklare att bygga med testade klossar som fungerar!

En idé är att se till att evt. display fungerar först, det gör det mycket enklare att skriva ut debug-värden och verifiera funktioner på andra rutiner, serieporten kan också vara extremt användbar till detta.

Jag har ett lite kretskort med en MAX232 på samt 4 sladdar som jag kan koppla till vad jag nu vill debugga, då är det klart med DSUB9 och bara att koppla till en dator och köra något terminalprogram.

[jesse]

Trevligt initiativ!

Förresten: Försök att lösa problemen utan forumet.

Fast det är väldigt ofta som jag har suttit i timmar och slitit mitt hår framför en massa kod utan att fatta nånting, jag sätter mig för att beskriva problemet i en tråd, och precis när jag ska trycka på "sänd"-knappen ser jag vad felet är... så uppenbart! Sen är det bara att radera det inlägget. Det är som om att skriva ett inlägg är nån slags terapi. Man tvingas tänka på saker man annars inte tänkt på.

Vet du vad man måste börja med? Är alla config-register inställda som de ska? Då kan du gå vidare.

Det känns som om man kan fastna redan här i svår frustration.... ehh.. vad betyder "config-register? Finns det ordet med i något datablad? Vad betyder det? Måste man verkligen ställa in alla register, eller räcker det med att ställa in dem jag vill, och hur ska de ställas in och varför.... och vet jag inte svaret på dessa frågor kan jag alltså inte gå vidare

Nej... det är nog lättare med OP-förstärkare. Dom funkar direkt.

[PHermansson]

Man kan komma mycket långt med en eller ett par LED som debugging! Bäst är det med några LED + ett oscilloskop, då kan man se vilka rutiner som kallas.

Om man bara har en pinne kan man göra som följer:
Rutin 1: Höjer en LED-pinne när den startar och sänker den när den sluter.
Rutin 2: Höjer, sänker och höjer LED-pinnen vid start och sänker den vid slut.
Detta ger en extra kort puls i början som man kan se på oscilloskopet.
Rutin 3: Höjer, sänker, höjer, sänker, höjer osv...

Det ger lite overhead men man kan se vilka rutiner som kallas och följden också och man behöver inte markera alla rutiner samtidig, bara de intressanta.

En utveckling av detta är att låta dioden blinka. Hade lite problem med RS232 nyss, hittade inte felet trots mycket letande. Till slut gjorde jag en loop som skickade tecken oavbrutet till PC'n. I loopen lades även en funktion som tände led'en, väntade 250mS, släckte led'en och väntade 250mS. Och visst blinkade dioden, men låångsamt. Fel klockfrekvens alltså, tanken var att Atmegan skulle gå i 12MHz med kristall, men den var inställd på Intern oscillator 8MHz samt att CKDIV8 var satt (standard på Atmega168). När detta ändrats till Ext fullswing Crystal och CKDIV8 bockats ur blinkade dioden klart snabbare, och seriekommunikationen började fungera. Det är för övrigt mkt enklare att hantera Fuses för AVR-processorer med AVR Studio än med avr-gcc, brukar använda Avr-gcc i Linux men startar upp en virtuell Windows XP när jag ska ställa in Fuses.

[JimmyAndersson]

Kul att det blev en så givande fortsättning på tråden.

Jesse:
'Det känns som om man kan fastna redan här i svår frustration.... ehh.. vad betyder "config-register? Finns det ordet med i något datablad?'

Just "config" är en engelsk förkortning för "konfiguration". "Register" är i princip vad det låter som.
I datablad för PIC-kretsar så hittar man dessa register under kapitlet "Special features of the CPU" -> "Configuration bits". Där kan man hitta saker som t.ex vad som ska användas som systemklocka (t.ex intern/extern oscillator), läs/skrivskydd, Power-up timer, osv. Man kan ganska förenklat jämföra dem med BIOS-inställningarna på en vanlig dator, där man ställer in saker som ska börja gälla redan vid start.

Det är många uttryck som förekommer i den här kategorins trådar.
Den här tråden är inte tänkt för frågor/svar eller att svara på detaljer som gäller mikrokontrollers.


För att förstå hur mikrokontrollers/datorer fungerar (t.ex hur minne och instruktioner fungerar) "på djupet" så finns det några trådar med boktips. Man måste inte kunna allt om det, men det underlättar om man förstår grunderna.
Däremot bör man helt klart förstå det binära talsystemet. Utan det så blir det som att läsa datablad utan att kunna engelska.

Ett annat tips kan vara att lära sig hur logik-kretsar som t.ex räknare, logiska grindar som NAND, osv fungerar.
När man lär sig det så får man faktiskt även ett par aha-upplevelser när det gäller vårt vanliga talsystem (0-9).

[jesse]

Jag vet inte hur det är med PIC, men med de enklare AVR'erna kan man starta utan att konfigurera nånting, förutom det man ska använda (vanligtvis en I/O-port). Den startar upp med intern 8 MHz oscillator som delas ner till 1MHz, sen är det bara att ställa in om man vill ha en utgång nånstans, t.ex.

Kod: Markera allt

ld r16,0b00000001;
out DDRB,r16; gör pinne B0 till utgång

Sen när man ska använda fler grejer, så som timer/counter, USART, ADC osv... så får man lära sig att ställa in dessa var och en för sig så som man vill ha dem.

Alltså behöver man inte ställa in alla config-register först, eller några alls egentligen. Det kan man göra efterhand som de behövs. (Under programmeringsprocessen menar jag. Konfigurationerna som man lägger till brukar man ju lägga allra först i programmet, innan man börjar med själva "uppgiften".

Det gör utvecklandet enklare - om jag ska blinka en lysdiod så testar jag porten först - att jag kan tända och släcka. Sedan är det dags att börja ställa in en timer för att sköta blinkandet.

[PHermansson]

Där finns det väl en viss skillnad mellan AVR och PIC? Med AVR sätter man igång de funktioner som behövs efter hand och det verkar alltid funka. Med Pic ska man aldrig anta någonting utan konfigurera alla relevanta register från början.