Svenska ElektronikForumet

Hej alla.

Jag sitter här och våndas över att jag inte får till programmeringen på mina AVRer.
Det känns som att allt sökande och läsande och informationsinsamlande jag gör på nätet hamnar i två kategorier, Beginner(blinka led) eller Advanced(100000 rader assebly utan comments).
Det finns inget mittemellan fack.

Jag har koll på hur utvecklingsmiljöerna funkar, AVRStudio, WinAVR, AVR-GCC i linux, hur hårdvaran funkar, hur programmeringen av kretsarna funkar.
Jag förstår de flesta koncept som utgör byggstenarna till större kretsar. (7 segments display multiplexing, HD44780 LCDer, I2C bussar, RS232, EEPROM, lalalalal)
Jag kan cadda kretskort i eagle, jag kan skriva ut på oh-film, jag kan belysa, jag kan etsa, borra och löda.
Jag har etsat och byggt ihop ett "utvecklingskort" med en Mega32 på. Som har RS232 port och breakoutheaders för alla pinnar osv. Den har avr109 bootloader så jag programmerar den via RS232porten.
Jag har en AVR ISP MkII USB programmerare.
Jag har en STK500.
Jag har 3 hemmabyggda Paralellportsprogrammerare.
Jag har upp till öronen med komponenter, maskiner och lödstationer.

Som sagt, jag har alla förutsättningar.
Men när det kommer till firmware så blir jag bara frustrerad över min inkompetens.

Har tidigare skrivit lite små löjliga testprogram i C för avr (AVR-GCC) men inget som verkligen blivit klart eller användbart.
Håller nu på och försöker koda i assembly istället för att försöka få bort den där onödiga C känslan som gör att man inte riktigt är med på vad som egentligen händer. (visst är jag medveten om att det säkert är lättare att skriva större program i C, men den diskussionen är för en annan tråd och en annan tid)

Det är där jag känner att jag är. Och jag behöver hjälp i rätt riktning. Vad är nästa steg för mig? Vad borde jag göra?

Jag känner att jag skulle vilja ha någon form av.. Kurs eller liknande som man skulle kunna tvinga sig att göra alla uppgifter i. För att lära sig..
En kurs med successivt mer avancerade koncept. Fast som små projekt så man kan bygga ihop en pryl och sedan ha den kvar, och möjligtvis ha användning för den.

Hu. Hoppas att någon förstår mitt kanske lite röriga inlägg och känner igen sig i det.

Jag tror jag förstår "läget", så att säga...
Svaret är nog att det inte finns några genvägar, bara att dyka
i i den djupa del av av bassängen och simma utav bara f-n.

> Vad är nästa steg för mig? Vad borde jag göra?

Problemet med att ge något generellt svar för "nästa steg" är att det inte
riktigt tydligt framgår var du står. Har du testat någon ASM kod alls ? Är det
något du har kört fast på ? Har det med den övergripande designen att göra ?
Eller saknar du helt enkelt uppslag till något att göra med en AVR alls ?

Vad är det dom driver din motivation ? Att lära sig AVR som sådant ?
Eller att det ska/måste bli något "användbart" ?

Det låter som att du är en bra bit på vägen!

Det framgår inte riktigt hur mycket du lyckats göra än. Har du lyckats få till att blinka lysdioder, läsa knappar (kanske med avstudsning) och allehanda kombinationer av dessa? Då har du ju grundkonceptet.

Så länge man inte går in på mer hårdvarunära prylar som timers, interrupts och power-hantering så är det inte speciellt mycket som skiljer mellan programmering i mikrokontrollers (-kontrollrar? -kontrolli?) och generell programmering.
Är du nybörjare inom programmeringsvärlden överlag så är det ju bara att kötta på och öva. Själv skulle jag nog vilja påstå att det är enklare att börja med C-programmering och sedan känna på ASM.
Är det just mikrokontrollerprogrammeringen som är problemet så är det nästan samma sak som gäller. Öppna databladet för någon krets och gå igenom de olika periferienheterna, hitta på små projekt. Gör en klocka man kan styra med knappar, styr några 7-seg LED:ar, pip med en högtalare. Du kan inte räkna med att allt du gör skall kunna ha någon större användning.

Svaret är nog att det inte finns några genvägar, bara att dyka
i i den djupa del av av bassängen och simma utav bara f-n.

Med simma utav bara f-n förstår jag vad du menar, såklart.
Jag är fullt medveten om att det inte finns några genvägar.

Jag har tänkt att jag skulle göra något "simpelt" projekt som tex en äggtimer, med 4st 7segments displayer.
Men jag känner fastnar på design aspekter, såsom, ska den vara batteridriven? Ja, det ska den, vilken typ av batterier ska jag använda? ett 9v batteri med en linjärregulator? enkelt men det känns så fel, för jag vet att ett laddningsbart li-ion batteri med en boostkrets skulle vara mycket bättre, men då ska juh batteriet laddas på något smidigt sätt också.. USB laddning kanske? och då skulle man juh ha en usb-rs232 så man kan uppdatera firmware i den via den också.
Och när man ändå tänker på batteritiden så kanske man skulle hålla sig till en LCD displat istället för en LED. och då skulle man juh gå ner på 3.3v logik och köra en DOG display istället.. lalalala
och sådär fortsätter hela karusellen och jag får inget gjort.

Problemet med att ge något generellt svar för "nästa steg" är att det inte
riktigt tydligt framgår var du står. Har du testat någon ASM kod alls ? Är det
något du har kört fast på ? Har det med den övergripande designen att göra ?
Eller saknar du helt enkelt uppslag till något att göra med en AVR alls ?

Jag har läst div assembly tutorials de senaste 2-3 veckorna och tittat på kod till PIC programm som vi har på jobbet tex. som är snyggt kommenterade på svenska osv.
Jag försökte ikväll att skriva att litet program som skulle läsa ett tecken från uarten och skicka tillbaka det. bara. Men innan jag ens kommit igenom init rutinen så fastnade jag (iofs så kännde jag mig rätt uppgiven med tanke på tiden och att jag ska upp om ca 5 timmar till jobbet), och skrev detta inlägg.

Kan för all del bifoga mitt patetiska försök till kod. Någon kanske kommer ihåg ett projekt som jag la upp här för herrans jösses massa länge
sedan som jag gjorde i skolan med en butterfly som läste av en NES handkontroll
och skrev ut status på en LCD. c-koden
Det där va väl sist jag gjorde något med en avr som faktiskt funkade som jag skrev koden till själv.(Bortsätt från LCD rutinen, men jag skrev en efteråt själv som funkade)

Vad är det dom driver din motivation ? Att lära sig AVR som sådant ?
Eller att det ska/måste bli något "användbart" ?

Det är nog att lära mig mera och träna, så när jag känner att jag skulle behöva bygga en tex, ny tempstyrning till min laminator för att kunna köra toner transfer med så ska jag kunna göra det och inte köra fast på saker som firmware.
Eller att jag ska kunna genomföra mitt tankeprojekt med en avr i bilen som har dubbelriktad kommunikation över rflänk så jag kan se kupétemp på fjärrkontrollen samt starta min Webasto brännare utan att springa ut i tofflorna och morronrocken och slira runt i snön för att trycka på den egenhändigt dit borrade tryckknappen i bilen.

Så som sagt, jag vet ungefär vad som behövs, träning träning träning. övning ger färdighet, men det som jag inte vet är vad jag ska öva på. det måste väl finnas klassiska projekt som man kan ge sig på för att lära sig? (som är mer än bara blinka en lysdiod, fast fortfarande inte för överväldigande)

Ännu ett "tröttinlägg"

Tycker nästan du har svarat själv!

Häng inte upp dig på detaljer. Innan du är helt hemma på AVR-biten så bygg grejerna på labbplatta/utvecklingkort först. Då kan du koncentrera dig på det du faktiskt vill lära dig. När du väl kommit fram till nåt vettigt så kan du börja skissa på krimskramset såsom strömförsörjning, vilken färg på lådan osv.

Det finns inga dumma frågor, bara dåliga kläder!

Allting årdnar siig och korven den har två.

Haha, aja. Nej men det är väl bara att försöka lite hårdare.. men man känner sej lite vilsen i assemblyprogrammeringen.

Själv började jag med C-programmering (för windows) och när det kom till mikrokontrollers så var det ASM på en Motorola HC11. Kommer dock ihåg att jag tänkte "C" när jag kodade assembler i början.
Du väljer naturligtvis själv men jag skulle nog påstå att det viktigaste när man börjar är att man ska kunna fokusera på målet, vilket jag tycker är lättare om man har en högre abstraktionsnivå (som i C). Är målet att lära sig ASM så visst, traggla på. Dock så ligger det ju i dess natur att allting blir krångligare och omständligare.

En ganska intressant tråd.

Jag har tänkt att jag skulle göra något "simpelt" projekt som tex en äggtimer, med 4st 7segments displayer.
Men jag känner fastnar på design aspekter, såsom, ska den vara batteridriven? Ja, det ska den, vilken typ av batterier ska jag använda? ett 9v batteri med en linjärregulator? enkelt men det känns så fel, för jag vet att ett laddningsbart li-ion batteri med en boostkrets skulle vara mycket bättre, men då ska juh batteriet laddas på något smidigt sätt också.. USB laddning kanske? och då skulle man juh ha en usb-rs232 så man kan uppdatera firmware i den via den också.
Och när man ändå tänker på batteritiden så kanske man skulle hålla sig till en LCD displat istället för en LED. och då skulle man juh gå ner på 3.3v logik och köra en DOG display istället.. lalalala
och sådär fortsätter hela karusellen och jag får inget gjort.

Känner igen mig själv på att jag lätt fastnar för att jag är alldeles för pedantisk.
Jag gör alltid en "standarduppkoppling" när jag ska börja ett AVR-projekt : Jag använder alltid en 12V väggvårta, en 7805 spänningsregulator och så är jag igång. Skulle jag vilja driva den på 9 voltsbatteri så är det bara att koppla in. Jag gör hårdvaran så enkel som möjligt för att komma igång med programmeringen. Sen när det fungerar , är det läge att fundera på om du ska ha specialbatteri eller annat...

Sen när det kommer till kod: (Nu orkar jag inte läsa ditt exempel ovan, skyller på tiden på dygnet ), men allmänt:

Se till att dela upp koden tydligt i olika delar som var och en gör sin bit.
Kör inte allt på en gång, utan testa varje del för sig. Testa programsnuttarna och låt dem meddela sig med omvärlden - blinka lysdiod = jag lever och fungerar, eller skriv ut olika saker på UART som bekräftar att varje rutin fungerar som den ska. Koppla sedan ihop dem noggrannt med bestämda "interface" (dvs. med vilka register eller variabler de olika delarna kommunicerar med varandra).

Jag tycker inte att C-programmering gör att man tappar kontrollen. C-programmering är precis lika exakt som assembler - med skillnaden att du använder "variabler" istället för processorregister. Det är helt enkelt snabbare och bekvämare, och du riskerar inte att olika rutiner råkar använda samma register... Gör ett flödesschema och rita upp programflödet. Har man ingen översikt är det lätt att gå vilse i programkoden.

Lycka till...

Jag måste hålla med jesse här dela upp och simplifiera delarna. Man kan se det som ett korthus, själva korten är ju inte avancerade det är när man sätter samman dem det "verkar" avancerat.

Jag gör precis såhär nu senast håller jag på med en UV-scanner (uvbox för oss som inte är smarta nog att köpa en riktig på en gång )

Och jag började med att kolla hur den gamla fungerade i princip sitter där en ULN2008 (fast annan krets) som driver stegisen. Jaha så då kopplar jag upp en ULN2008 och provar så den fungerar, såklart börjar jag med en blinkande LED på labbdäcket, det är bara att trycka i en LED och ett motstånd så ser man verkligen att koden kommer över och att Main-loopen fungerar som tänkt.

Sen undan för undan bygger koden på med kod för stegmotorn, först fasta långa delayer så man kan kolla att fasföljden (eller vad man ska kalla det) är ok med LEDs sen snabbare för att se att det fungerar. Sen ska motorn köras bakåt också

Därefter ville jag ju ha en display (såklart ) och då man väl får igång den så har man en otroligt enkel felsökare. Tänk skicka A, B, C osv för varje sekvens i programmet eller när den går i interupt eller vad man nu önskar så kör man bara på tills allt harmonierar.

Hårdvaran kör jag med funkar det så funkar det och då funkar det. Det är inte (ännu) medicinskt utrustning jag tillverkar så pajjar det så är det bara jag som får lida. Uppkopplingen sker alltid nästan på labbdäck och sen ritar jag ett kort i Eagle.

En smidig sak jag brukar använda är min displaydrivare som är betydligt enklare att koppla upp än en display och dessutom inte tar lika många utgångar. Sen har jag en färdig harrang av kod till denna för att skriva så man får den snabbt igång. Annat bra felsökningssätt är serieporten, tryck på en MAX232 och du har en utmärkt felsökare.

Koden kopierar jag ofta mellan projekten sen modifierar jag. Har man använt A/D på ett ställe är det ju onödigt att uppfinna hjulet igen särskilt då inställningarna till stor del är desamma. Här är det enormt viktigt med _bra_ kommentarer så man dels vet vilken sektion man ska ta och vad man egentligen gör, det kan ju vara flera månader (år) senare man är där och rotar.

Sen är det bara att gneta på och går något fel så dela upp, dela upp, dela upp och dela upp. Till sist hittar man den del som inte fungerar. Jag har tex fått att MPSIM (förr inte nu) visade fel värde på några variabler och då förutsatte man vissa saker som inte stämde men tillslut så efter mycket... så

Allt som allt så för mig är själv bäste dräng, jag vet vad JAG vill göra och kan lättare fokusera när jag vet vad målet är, jag orkar inte bygga något som jag ändå inte ska använda eller testa sen.

Det är ju roligt att testa det man är intresserad av tex mäta temperaturer, flöden, ljus, tryck, gravitation, kompassriktning, tid osv osv finns alltid något man är intresserad av då spinner man vidare på det så har man ju också ett mål med det hela vilket gör det mer motiverat.

Färdiga koder har jag nästan helt slutat med då jag mest blir sur över hur uselt eller olikt mig de tänker, det tar nästan lika lång tid att fatta allt som att göra det själv. Kodsnuttar däremot brukar jag nappa från tex http://piclist.org (finns säkert nåt liknande för AVR) när det gäller typ roten ur, sin/cos/tan eller nåt sånt.

Mycket babbel blev det men kanske något är upplysande/motiverande?

Vad skönt att läsa om någon som har samma beslutsvånda som jag.

Ang. batteri 5V /3.3V, laddning, USB, m.m. kolla på http://www.electrokit.se/kretskort-expe ... t_41003061

Jag har själv varit i den sits, man kan nog till att veta att det är mycket man inte kan...

Då är det viktigt att definiera sitt projekt hårt innan man börjar! Man måste helt enkelt besluta att äggtimern man vill bygga ska vara batteridriven, en vanlig regulator och sedan ska timer-funktionen vara det viktiga! När detta är definierat är resten bara jobb.

Denna projekt-definition är faktisk en mycket viktig del av utvecklandet att kunde! Man ska träna på den precis som man ska träna på programmering, CAD, felsök osv. Det är så med alla design att man kan alltid förbättra något när man egentligen har löst alla problem, konsten är att spika fast att "detta ska den och nu är målet uppnått! Avslut!"

Känner igen det där med att tänka och tänka och tänka utan att GÖRA något allt för väl. Jag hamnar ofta i precis samma sits där jag hela tiden tänker; "men... det hade ju kanske varit bättre att göra såhär. Eller, ska jag lägga till den här funktionen också? Men om jag gör det så måste jag ju.. .och sen och då och bla och GAH!".

När jag hamnar där då brukar jag tänka på något som ett av mina befäl under värnplikten sa till en av mina polare innan han sparkade honom i röven: "Tänk inte! Skjut!" Det låter löjligt enkelt men ofta är det faktiskt det som behövs, sluta fundera och GÖR nåt, skit i om det inte är preciiis så som du tänkt, ofta slutar det med något bra i alla fall.

Ja, jag håller också fast vid den metoden.
Börja bygg och var inte rädd för att riva och göra om.
Försöker man alltid vara smart och göra den "bästa" lösningen
direkt kommer man aldrig imål, speciellt som förutsättningarna
tenderar att förändras hela tiden

/johan

Och samma beslutsvånda som gäller hårdvaran gäller även mjukvaran.
Vad jag vill säga med det här inlägget:

bygg grunden först. Lägg sedan på snickarglädjen.

Exempel: jag bygger en temperaturregulator till ugn. Jag vet att den kan ha en massa finesser osv.. men jag lägger allt åt sidan och gör följande:

1) sätter alla in/utgångar
2) drar igång en klocka som räknar upp 100 ggr/sekund (timer)
3) återanvänder kod för UART och SPI från tidigare projekt. Dessa ligger bekvämt i egna c- och h-filer.
3.1) testar alla utgångar, lysdiod och optotriac som styr ugnen. fungerar!
4) Börjar snickra på interfacet för AD-omvandlaren, som är en extern AD7705. Delar upp i små funktioner: skicka data - ta emot data och vänta på "data ready". Sedan mer specialiserade funktioner: konfigurera klockregister, setupregister, välja kanal.
5) testar funktionerna och ser att jag kan läsa in data, välja kanal osv... verifierar med voltmeter och beräknat resultat. siffror visas om rådata på UART.
6) knåpar ihop en rutin för beräkning av temperatur utifrån en matematisk formel för PT100-element samt för wheatstone-brygga. Använder en tabell och approximerar.


Nu har jag så jag kan läsa temperatur i grader celcius.

7) använder timern (2) för att läsa av ett resultat 4 ggr per sekund.
presenterat data på UART en gång per sekund.
9) använder färdiga funktioner i uart.c att ta emot text och siffror och skapar två kommandon: ställ bryttemperatur och nollställ klockan.

Nu har jag kommit så långt att jag kan prova ugnen. Nu gör jag flera tester på temperaturförändringar , mätnoggrannhet med mera. Provar att löda flera kretskort i ugnen.

10) Ändrar så att värmaren styrs av en intern timer i processorn med PWM istället för som innan ON/OFF på en pinne i PORTD. Gör en enkel P-regulator.
11 ) börjar pilla med en PID-regulator....

Här kan man se att den "fiffigaste finessen" kan man säga är PID-regulatorn: Kronan på verket. En ostrukturerad programmerare hade säkert gärna velat börja programmera på den redan någon gång mellan punkt 1 och 3... Men praktiska tester i verkligheten visar att en PID-regulator är helt onödig i det här sammanhanget. Och hade skapat en hel del osäkerheter huruvida AD-omvandlaren verkligen fungerar som den ska.

Nu är det en massa kvar att göra:

Det finns display och knappar - dessa har jag inte brytt mig om. De kan göra regulatorn befriad från PC:n.
Man kan skapa olika temperaturprofiler som man kan välja mellan.
Det kan behövas en "automatisk lucköppnare" för ugnen och kanske en fläkt...
Ett larm som ljuder när det är klart (eller om något är fel).

Men detta ser jag som överbyggnad... basen finns nu där. (fast programmet tar just nu upp 94% av processorns minne, jag underskattade visst behovet)

I det här fallet har jag inte ritat något flödesschema alls. Det beror på att programmet är mycket enkelt i sin struktur och bygger mer på fristående objektorienterade moduler än på sekventiell exekvering. Nästa "objekt" blir alltså en temperaturprofil...

Eftersom C inte är ett objektorienterat språk får man hålla reda på sina objekt själv. Jag har mer och mer börjat använda globala strukturer (struct) för att samla alla variabler för ett objekt.

bachler skrev: ...
..

Jag har läst div assembly tutorials de senaste 2-3 veckorna och tittat på kod till PIC programm som vi har på jobbet tex. som är snyggt kommenterade på svenska osv.
..
..

Jag känner igen mig så väl i det du skriver. Många kloka svar har du fått. Just det där velandet, att vilja ha kontroll på allt samt kanske avsaknanden av de mest grundläggande strukturerna i maskinnära programmering ställer till det.

När jag läser ditt inlägg hänger jag lite grann upp mig på meningen i citatet ovan. Om du tittat på assembler programmerings exempel från en massa olika ställen kanske du får så många alternativa sätt att lösa problem på att du tappar strukturen. Och det är väl det du insett när du efterlyser ett utbildningsmaterial som går hela vägen så att säga.

När du dessutom blandar exempel med PIC- och AVR-lösningar på assemblernivå, (maskinnära nivå) förmodar jag att du gör en björntjänst eftersom hårdvaran är så pass olika och strukturen på registren, instruktioner etc inte är lika. Nu har jag aldrig hållit på med PIC-programmering och är medioker på AVR-programmering, men personligen känner jag att det inte vore rätt väg för mig att gå.

Hoppas du hittar något som passar dig bra! Själv skulle jag vilja ha din beslutsamhet att jobba framåt med assembler programmeringen för att uppnå framsteg. Jag har allt för länge varit för lat för att uppnå framsteg.