Svenska ElektronikForumet

Svenskt forum för elektroniksnack.
https://elektronikforumet.com/forum/

Jesses följetång om AVR programmering i C...

https://elektronikforumet.com/forum/viewtopic.php?t=37925

Sida 11 av 13

Re: Jesses följetång om AVR programmering i C...

Postat: 12 februari 2010, 22:48:23
av eqlazer
Du kan läsa ADCW istället för att behöva läsa de två resultatdelarna separat.

Re: Jesses följetång om AVR programmering i C...

Postat: 12 februari 2010, 23:00:07
av jesse
aha, det var intressant. Jag funderade på om det på något vis gick att läsa som ett 16-bitars integer direkt, men var osäker på ordningen (ADCL måste läsas före ADCH, och skrivs det på samma rad, t.ex. adc = ADCL | (ADCH << 8 ); så är det inte definierat i vilken ordnig det kommer att utföras. Därför måste det skrivas på samma rad.

Men om de har särskilt gjort ADCW för ändamålet så antar jag att den läser i rätt ordning.
Tack för tipset!

int eller uint8_t ...

Postat: 9 april 2010, 17:26:49
av jesse
Jag har fortfarande inte vant mig vid högnivåspråk. :doh:

Jag tänker hela tiden i åtta bitar, och när jag ska göra t.ex. en loop som ska räkna från 0 till 15 så skriver jag:

Kod: Markera allt

for (uint8_t i = 0; i < max; i++) {
Och tänker mig då att i är ett positivt åttabitars heltal.

Men GCC är ju smartare än så. Även om int ska vara minst 16-bitars så optimeras detta bort av sig självt och resultatet blir exakt samma kod som om jag hade använt uint8_t:

Kod: Markera allt

for (int i = 0; i < max; i++) {
Jag antar att så inte skulle vara fallet om inte variablen "max" hade varit 8-bitars också. Men ändå känner jag mig osäker när jag skriver "int": om "max" är 15 eller 45 så är det inget problem. Men om max är 200?

int är ju signed. Om jag skalar ner det till bara 8-bitar borde ju den bara klara upp till +127. Antingen fattar kompilatorn alltihop - den gör om "i" till en 8-bitars unsigned char, eller så tänker den att hoppsan - här blir det overflow om jag kör 8 bitar - bäst att räkna med 16 bitar... och så blir det en 16-bitars variabel fast man inte behöver det... Jag anar att kompilatorn inte är så dum, men som sagt... jag litar inte på att den alltid gör om allt jag skriver till det bästa.

Re: Jesses följetång om AVR programmering i C...

Postat: 9 april 2010, 17:31:59
av E85
varför skriva int om det är en unsigned char eller uint8_t du vill ha?

Re: Jesses följetång om AVR programmering i C...

Postat: 9 april 2010, 17:33:57
av AndLi
+/- är högsta bit:en, om du då har en int16 och tar de lägsta 8 bitarna och stoppar in i en uint8 så får du ett tal 0-255.

Re: Jesses följetång om AVR programmering i C...

Postat: 9 april 2010, 17:47:17
av jesse
E85: tja.. ehhh.. bra fråga... vet inte. Får för mig att uint8_t är så långt att skriva. :vissla:

Men det är ju bekvämt om man kunde skriva int överallt, eftersom det har hänt att jag av gammal vana skrivit uint8_t fast loopen kanske ska gå 350 varv , och det blir ju inte bra :(

t.ex. skriver jag ett program :

Kod: Markera allt

#define MAX 100
...
for (uint8_t i; i < MAX; i++) { ... }
och senare får jag för mig att ändra MAX till 300 och glömmer då hur i är deklarerat i alla for-satser...

Vet inte om den (GCC) skulle varna om jag gör en sådan jämförelse i < MAX ?

Re: Jesses följetång om AVR programmering i C...

Postat: 9 april 2010, 17:52:13
av vfr
Det kan faktiskt finnas ytterligare en anledning att kunna köra med generell "int"-typ. Det ger en generell kod som är flyttbar utan att man begränsar sig i storlek eller låser sig till en viss minimistorlek på datan.

Re: Jesses följetång om AVR programmering i C...

Postat: 17 april 2010, 06:39:47
av stekern
Jag tycker det är precis tvärtom, genom att använda definerade storlekar på datatyperna får du en mer generell kod.
Tänk dig att du flyttar över kod från en plattform där en datatyp är större en den är i den du flyttar över till (t.ex 16 bit int vs 32 bit)
Det är bäddat för problem om man på ursprungsplattformen gjort antagandet att 32 bit kommer få plats i den.

Jesse: Du kan väl då lika gärna skriva int16_t överallt eftersom detta är samma sak som int i avr-gcc, samma optimisation kommer givetvis ske som om du skulle skriva int.

Edit: och ja, gcc brukar klaga om man jämför med ett för stort tal

Re: Jesses följetång om AVR programmering i C...

Postat: 17 april 2010, 14:19:36
av jesse
Håller med stekern i princip, så - ja jag kommer att fortsätta med uint8_t på mina små loopar.
Men det jag lärt mig av det här är väl att jag inte ska vara rädd att skriva uint16_t om det skulle finnas den minsta risk att någon gång i framtiden "MAX" (*) skulle ändras till ett tal högre än 255

(*) se tidigare inlägg

Re: Jesses följetång om AVR programmering i C...

Postat: 25 april 2010, 17:49:48
av jesse
satt och programmerade - höll på att lägga till lite satser i en funktion , ett par globala variabler och lite annat - testar att kompilera och hela kompilatorn får tuppjuck.

Nu har jag gått igenom allt jag kan tänka på och vet inte var felet är. Har (ännu) inte hittat några saknade } - parenteser...

Vad bör jag leta efter för fel när jag får ett sådant här kompilatorresultat:

Kod: Markera allt

Build started 25.4.2010 at 16:46:57
avr-gcc  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99                              -Winline                                                                                             -DF_CPU=19660800UL -Os -funsigned-char -funsigned-bitfields -fpack-struct 
-fshort-enums -MD -MP -MT spi.o -MF dep/spi.o.d  -c  ../spi.c

avr-gcc -mmcu=atmega644 -Wl,-Map=bms6802.map main.o spi.o bms.o flashmem.o uart.o dogm16.o ampere.o     -o bms6802.elf
spi.o: In function `SPI_MasterInit':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../spi.c:28: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
spi.o: In function `SPI_MasterInit':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../spi.c:28: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
bms.o: In function `ntcTemp':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../bms.c:31: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
bms.o: In function `ntcTemp':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../bms.c:31: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
flashmem.o: In function `SPI_flashadress':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../flashmem.c:31: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
flashmem.o: In function `SPI_flashadress':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../flashmem.c:31: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
uart.o: In function `uart0_init':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../uart.c:27: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
uart.o: In function `uart0_init':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../uart.c:27: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
dogm16.o: In function `d16_keyCheckB':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../dogm16.c:80: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
dogm16.o: In function `d16_keyCheckB':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../dogm16.c:86: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
ampere.o: In function `eeprom_read_byte':
c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: multiple definition of `BMS_readings'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:196: first defined here
ampere.o: In function `eeprom_read_byte':
c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: multiple definition of `BMS_crcerr'
main.o:c:/program/atmel/winavr-20090313/lib/gcc/../../avr/include/avr/eeprom.h:197: first defined here
[b]make: *** [bms6802.elf] Error 1
Build failed with 1 errors and 0 warnings...[/b]
En sak som är säker är att det inte är de felen som den listar upp...
t.ex.

Kod: Markera allt

spi.o: In function `SPI_MasterInit':
C:\AVR_projekt\AVR_GCC_projekt\BMS6802A\default/../spi.c:28: multiple definition of `BMS_readings'
Jag har inte rört funktionen `SPI_MasterInit' och den innehåller inte ens ordet `BMS_readings'.
Och så fortsätter det... Går jag t.ex. igenom SPI_MasterInit så är den inget fel på.
Antagligen saknas det en hakparentes nånstans, eller i värsta fall - jag har råkat radera ett stycke kod på okänd plats med en tangenttryckning.

Tyvärr vill jag inte återgå till tidigare version av programmet - jag har moddat programmet i flera timmar idag men inte gjort kopior under tiden. Senaste kopian gjordes på morgonen när jag började. Så det blir i princip att jobba 10 timmar till om jag inte hittar felet. Hjälp! :verysad:

Re: Jesses följetång om AVR programmering i C...

Postat: 25 april 2010, 17:59:42
av jesse
Det är märkligt.... men precis när man tryckt på "skicka" på forumet så ser man något.... och ... vips... probelmet löst. Jag som slitit mitt hår i en timme nu!

Felet var bara att jag försökte initiera två globala variabler i en .h-fil istället för i en .c -fil. jag flyttade dem och allt blev bra.
Det framgår kanske av felkoden ovan att det var `BMS_crcerr' och `BMS_readings' som spökade. Fattar inte att jag inte såg det innan. (Får skylla på att jag suttit för länge framför skärmen).

Re: Jesses följetång om AVR programmering i C...

Postat: 25 april 2010, 17:59:57
av E85
Har du

Kod: Markera allt

#ifndef __FILNAMN_H
#define __FILNAMN_H

...kod..

#endif
i alla include-filer?

edit: Kul att det löste sig.....

Re: Jesses följetång om AVR programmering i C...

Postat: 25 april 2010, 18:58:15
av jesse
jodå, det har jag i alla .h-filer.

Re: Jesses följetång om AVR programmering i C...

Postat: 23 juli 2010, 15:52:03
av jesse
det var ett tag sen jag postade här, så nu är det väl dags igen.... :P

Jag ska göra en lista med element som består av olika typer: en pekare till en funktion, ett heltal samt en text. Listan är konstant, så den går med fördel att läggas i programminnet.

jag antar jag bör göra nånting sånt här:

Kod: Markera allt

struct item {
    int *funktion;
    int value;
    char text[12];
och sedan

Kod: Markera allt

struct item PROGMEM  list1[ANTAL] = {  
    { funk1, 1, "start"} 
    { funk2, 25, "open"} 
    { funk1, 0, "stop"} 
}

void funk1(int data) {
   //do something
}
sen vet jag inte riktigt hur jag ska köra funktionen ...
exempelvis item[3] ska köra funktionen funk1 med argumentet 0.



men jag har problem med int*funktion; - det är ju inte en pekare till "int" utan till en funktion, som sedan skall tilldelas adressen till en funktion.... det ska ju inte stå "int" där, antar jag, men jag känner inte till någon typ för funktion?

Kod: Markera allt

//testar:
int *pekare = show_display;
ger warning: initialization from incompatible pointer type

Re: Jesses följetång om AVR programmering i C...

Postat: 23 juli 2010, 16:06:42
av E85
http://www.safercode.com/blog/2008/11/2 ... -void.html
Kanske ger nåt tips.

Lite mer info:
http://www.newty.de/fpt/index.html
Alla tidsangivelser är UTC+02:00 Europe/Stockholm
Sida 11 av 13

Drivs av phpBB® Forum Software © phpBB Limited

Swedish translation by phpBB Sweden © 2006-2020