Kan möjligtvis ha att göra med att jag får försöka hålla i kablarna till potentiometern själv med några metallklämmor men det borde ju funka ändå tycker jag. Gissar att det är nåt annat.
Nu kanske jag tänker helt fel här Jennie men jag förstår det som att du använder 5V som ref och sen drar in 3,3V till ADC:n.
Om så är fallet så får jag det till att du behöver minst 3,9V för att läsa "200" om det är en 8-bitars ADC.
Har du provat att bara dra en 5V kabel direkt till ingången på ADC:n och se om den tänds?
Tycker det verkar lite underligt att du ska använda AVCC (5V) som ref och sen en 3,3V-signal som värde. På så sätt kommer man ju aldrig kunna nyttja "hela spannet"... Eller har jag otur?
EDIT:
Slänger in en annan teori men ha i bakhuvet att jag svammlar rätt mycket.
Skummade igenom databladet och din µC har 10 bitars ADC men tror inte det framgår om du verkligen måste använda alla 10 i uppgiften. Om du ska använda alla 10 bitar så bör ju en 3,3V-signal ge dig väl över värde 200 men man måste då läsa ut registren på rätt sätt.
I din funktion get_sample() så returerar du ADCL + (ADCH*256). Jag vet inte om man kan slå ihop registren så men skulle det inte gå att bara nyttja ADCH-registret för att få igång funktionen? Dvs, bara return ADCH och därmed enbart nyttja 8 bitar och även använda samma Vref-nivå som du har till potten.
EDIT2: Såg först nu att du inte har någon serieresistor med LED:en på bilden. Ni kanske har det i verkligheten men ville bara nämna att det nog behövs för att inte elda den.
(Rörigare inlägg får man leta efter)
Kan vara värt att kolla med multimeter på mcu A/D-benet för att säkerställa att där verkligen är en spänning som varierar när du vrider poten. Samma sak med den I/O som tänder/släcker lysdioden, att den varierar som tänkt. Kan vara så illa att de där två snabba blink du ser är lysdioden som går sönder om det inte är ett behagligt seriemotstånd.
Trodde jag hade löst det genom att byta från ADC0 till AD0 men tjii fick jag, men sen insåg jag att jag bara stängde på och av den. Prövat allting ni sagt här men inget funkar.
Nej, jag har faktiskt inte löst det här ännu. Faaan
Jag brukar få tipset att dela upp programmet/funktioner i delar och verifiera att varje del fungerar korrekt, precis som adent var inne på också.
Är nedan testat och fungerar?
- Lysdioden. Är denna hel? Om osäker så koppla direkt mellan railarna med ett seriemotstånd runt 330 Ohm
- Utgången på MCU:n. Är denna konfigurerad som utgång och ej bränd? Prova att aktivera den i programmet, med LED + resistor kopplat utan att någon annan funktion körs.
- getSample() funktionen. Följ adents råd. Få detta att fungera. Efter det kan man gå vidare med verklig ADC-hantering
EDIT: Stavfel
Senast redigerad av Magnus_K 5 maj 2015, 23:26:24, redigerad totalt 1 gång.
Kan du inte skriva ut värdena som du får via getSample() i debug-utskriften? Att skriva ut väl valda variabler kan korta ner felsökningen med flera tio-potenser...
Du har ändrat koden men inte kommentaren som säger vad koden gör.
Nästa som läser kommer att fundera på om det är en bug. Om din lärare upptäcker det kanske du blir kuggad på det felet. Om det inte upptäcks kuggar jag honom/henne.
För oss som inte är bekanta med AVR får du gärna förklara varför den flaggan inte skall vara där.
Nej, egentligen struntar jag i det, men vi vill nog se att du förstått och inte bara testat dig fram till en lösning som fungerar.
(1 << ADIE) står för Analog Digital Interrupt Enable (eller någonting liknande, interrupt är det i alla fall).
Den biten ska inte vara igång när man som jag använde polling för då är MCU:n inställd på interrupt istället för polling. Så tog bara bort den och då fungerade det, så pass enkelt var det faktiskt trots allt strul.
Fick av nån anledning för mig att jag skulle sätta ADIE-biten hög då jag skulle använda polling på Interrupt-flag-biten (ADIF), men så var det alltså inte.
Här gissar jag: Om man slår på interruptet kommer processorn att hoppa via den odefinierade interruptvektorn och köra kod där. Frågan är vad den är.
Aha. google är bra Detta gäller avr-gcc:
If an unexpected interrupt occurs (interrupt is enabled and no handler is installed, which usually indicates a bug), then the default action is to reset the device by jumping to the reset vector.
Men i samma mening står detta som verkar trevligt att använda. Det visste jag inte, så även jag har lärt mig nått