volatile i c på avr

[pere76]

Jag försöker skriva lite kod för att snacka med en attiny2313 över comporten.

Efter lite klurande kom jag fram till att jag behöver en global teckenbuffer.
Därför lägger jag till:

Kod: Markera allt

#define RX_BUFSIZE 80
volatile char b[RX_BUFSIZE]; 
volatile int rxn=0;

Direkt efter #include filerna.
Sen dör min attiny2313 och inget funkar, min kontrolllysdiod blinkar inte 1 ggr i sekunden som den brukar.
Om jag kommernterar bort ovanstående och kompilerar upp igen så funkar allt.
Får man inte använda volatile?
Hur gör jag då en en buffer som sparar allt tills jag tryckt på return?
Ska väl inte behöva skriva det till eepromet heller?
Jag kör avr gcc 4.2.2

[thepirateboy]

Jag tror du missuppfattat volatile. Det ska användas för att kompilatorn inte ska optimera bort kod, t ex jämförelser när en variabel kan ändras av interrupt. Se exempel på Wikipedia. http://en.wikipedia.org/wiki/Volatile_variable

Det ser ingen anledning att du behöver deklarera den globala bufferten volatile för att ta emot data från UARTn.

http://www.nongnu.org/avr-libc/user-man ... q_volatile

[pere76]

Tack!
Visst har jag missupfattat volatile!

Är van att programmera i python i på linux/bsd och med risk för att inte passa in i detta forum tycker jag att c är onödigt besvärligt.
Fast jag är inte sugen på att skriva en pythontolk till avr heller.

[speakman]

Det blir lite missvisande att jämföra ett jättehögnivå-språk med ett närmast maskinnära språk. Jag kodar också Python och tycker det är "vackert" på många punkter. Men jag har ändå överseende med C.

[cykze]

Jag deklarerar alltid globala variabler som jag vill komma åt både från en ISR och "resten av koden" som volatile. I det här fallet kanske du har en ISR för att läsa in en byte från UART:en och lägga in den i bufferten. Den bufferten vill du troligtvis kunna komma åt från någon annan del av programmet. Är den då inte deklarerad som volatile så skulle det väl kunna hända att kompilatorn redan har läst in bufferten i RAM:et till några temporära register. Kompilatorn vet ju inte att bufferten i RAM:et kan ha ändrats av någon utomstående (ISR:en). Därför kan det hända att data i de temporära registrena faktiskt innehåller äldre data än det som ligger i RAM:et. Vet inte riktigt om mitt resonemang stämmer. Men jag kör med volatile för att vara på den säkra sidan.

Anledningen till varför AVR:en beter sig konstigt kan bero på att du använder för mycket RAM. En tiny2313 har ju bara 128 bytes med RAM. Din buffert upptar 80 bytes. Du kanske har fler variabler? Sen måste ju stacken ha plats att växa också. "avr-size" kan ge lite information här.

[pere76]

Jag håller med dig!

Vid felsökningen minskade jag ner bufferten och då började det fungera fler gånger. Men inte alltid när jag ändrat i koden.
Mitt problem verkade vara klurigare än så, tror det är min hemmabyggda programmerare som inte resetar tillräckligt länge eller lågt eller något.

När jag gick förbi programmeraren några timmar senare såg jag att lysdioden börjat blinka igen.
Altså var det något annant än koden som var problemet.
Processorn startar inte upp alla gånger efter programmering.
volatile var bara en tillfällighet.

Men jag börjar inse att jag aldrig kommer ha en chans att klämma in hälften av min kod på en attiny2313. Är ganska grön på detta och hade ingen aning om hur lite 2kb flash och 128 b ram var.
Dags att plocka fram min butterfly igen.

[cykze]

Verifierar din programmerare att programmet har sparats korrekt i program-/flashminnet?

Har du mätt spänningen på Reset-pinnen när AVR:en kör?

Är matningsspänningen stabil? Har du avkopplingskondingar?

Slå på optimeringen i GCC, t ex med flaggan "-Os", så tar koden mindre plats.

Den här koden använder jag för att ha koll på storleken. Jag har för mig att jag snodde den från Obdev's USB-lösning. Kör igång skriptet med elf-filen som argument. Lär nog inte fungera så bra under Windows dock (såvida du inte kör Cygwin).

Kod: Markera allt

#!/bin/bash

set -- `avr-size -d "$1" | awk '/[0-9]/ {print $1 + $2, $2 + $3, $2}'`

echo "ROM: $1 bytes (data=$3)"
echo "RAM: $2 bytes"

exit 0

Det kan också vara bra att jämföra C-koden med den genererade asm-koden. Asm-koden får du fram med
avr-objdump -S dittprogram.elf > kod.lst. Kompilera programmet med "-g"-flaggan så får du "inline-C" i Asm-outputten.

Slutligen, lägg in allt i en Makefile så behöver du inte komma ihåg alla kommandon.

[pere76]

Tack för tipsen.
Jag kör avr-gcc 4.2.2 och avrdude under OpenBSD och makefilen är gigantisk och rapporterar allt och lite till så mitt c-program på inte så många rader har redan ätit mer än hälften av minnet på en attiny2313.

Tror inte det är något fel med själva programmeringen, snarare mina programeringskunskaper och min hemmabyggda programmerare.
Avkopplingkondensator, är det samma sak som en semesterkoncentrator
Om du menar mellan vcc och gnd så har jag en sådan. Fast den skulle definitivt kunna sitta närmre processorn.
Jag misstänker att det är programmeraren som håller någon pinne aktiv lite för länge efteråt och då startar processorn inte upp ordentligt, får väl läsa på signalnivån framförallt på resetpinnen lite bättre.
Programmeraren är trots allt ett hemmabygge.

[bearing]

Är det en sån där med fem motstånd till parallellporten?

Om motstånden har rätt storlek tror jag inte den gör fel. Min femmotståndare funkar alltid. Jag kopierade SvenW:s. http://elektronikforumet.com/forum/view ... de#p380972

[pere76]

Jag kör med siprog som den heter i avrdude.conf
Det är en transistor som drar i resetpinnen. Anledningen är att jag tror att paralellportsvarianten inte fungerar i OpenBSD
Det är lite svårt att se spänningen på resetpinnen med en multimeter.
Får nog ta med prylarna till jobbet och provköra med osciloskopet där.
Har läst på så mycket om c nu så jag vet att det inte är mina programmeringskunskaper som är problemet.

[cykze]

Att mäta likspänningen mellan Reset och jord kan du väl ändå göra med en multimeter? Passa på att mäta Vcc också.

[pere76]

Reseten är lite snabbare än vad jag är....
Reseten är dessutom kopplad till TX pinnen så den är svår att tvinga hög.
Men vid "normalt" användande är vcc 5.13V och reset 5.03V .
Fast när jag tänker efter borde jag kunna sätta resetpinnen till någon annan pinne i seriellporten och ändra i avrdude.conf

Jag kanske ska börja med att bygga en ny programmerare och köpa en en färdig rs232-ttl omvandlare och se om det funkar bättre då.
Vissa dagar går den jättebra, andra dagar startar den aldrig, lite för klurigt tycker jag.

[bearing]

Varför fungerar inte parallellporten i Open BSD?

För att avrdude ska rättighet att använda parallellporten måste det köras med superuserrättigheter. I ubuntu använder jag sudo:

Kod: Markera allt

sudo avrdude -P /dev/parport0 ...

[pere76]

Jag ska inte säga till 100% att parallellportsprogrammeraren till avrdude inte fungerar i OpenBSD.
Men OpenBSD saknar drivrutinen ppi för att snacka direkt med parallellporten som NetBSB och FreeBSD har.
För att inte bygga en programmerare som inte skulle fungare byggde jag siprog istället för den var jag säker på att den skulle fungera.

Men det kanske är bäst att bygga en paralellportsversion och installera upp linux på någon gammal burk och testköra för att se om problemen löser sig.
Det går ju fort att installera linux och paralellportsprogrammeraren byggs av några motstånd och en gammal skrivarkabel man knipsar på mitten.
Om problemen inte löser sig är det min hårdvara jag får titta på.

Jo sudo känner jag till, har jobbat med systemadministration och datorsäkerhet i snart 15 år
Kanske dags att skriva en personlig presentation snart.

[cykze]

Har du provat att helt enkelt koppla bort programmeraren efter att du har lagt in programmet?