Svenska ElektronikForumet

Ofta gör jag olika räknare som jag deklarerar som int. men jag har upptäct att det inte funkar om jag tex ska räkna upp till 100k. Nedan har jag en typisk kod. Här räknar upp till 60K och dey funkar fin men sätter jag som innan nämnt 100k så uppfylls aldrig If satsen.

En int på uc är ibland 16 bitar alltså 0-65535 alt +- 32767...

Så öka till en större datatyp så kommer det funka...

Ett tips är att deklarera med uint16_t istället för uint så är det tydligare vilken storlek du får.

Aehhh det har jag missat helt. Googlade hur stort int var och då var det betydligt större

Och bara int som typ är farlig. Beroende på kompiler kan den vara allt från 8 bit till 64 bit.

Det är ytterligare en grund till att vara specifik med datatyp.

En int kan oftast vara av den typ som det är enklast för processorn att läsa/skriv.

Storleken av en int är inte definierat exakt utan beror på vilken processorarkitektur man kör på.

Lite enkelt så kan man säga attInt brukar vara "native" längd på minnet för respektive platform. För 64-bitars processorer brukar den vara just 64-bitar medan en 8-bitars MCU är en int i regel 8-bitar.
Använder man standard intarna som AndLi skrev så ser man bitlängden på ett enkelt sätt.

Ja då är det utrett. Tackar tackar

I många fall är standard + - tal det vill säga en av tecknen används för att ange detta.

Om talet inte kan vara -.

Kan unsigned int ger dubbelt så stora tal som int.

Många programmerings språk följer C standar.

Där anges endast relativ storlek char = tecken minst int större.

På 8-bitar bukar detta betyd char -128 till 127 unsigned char 0 till 255.

Något att tänka på för räknar variabel variabler....

Kolla upp stdint.h. Använd alltid datatyper med specifik storlek, så som uint32_t för tal som aldrig ska vara negativa och sint32_t för tal som ska kunna vara negativa.

Använder man dessa datatyper slipper man spännande överraskningar när man byter till en plattform som har fler/färre bitar.

newbadboy skrev: ↑25 augusti 2022, 16:58:15 Aehhh det har jag missat helt. Googlade hur stort int var och då var det betydligt större

Lägger bara till att int är förkortning av integer som betyder heltal.
Alltså en datatyp utan decimaler. Säger inget om hur stor den kan vara, därav att en googleträff kan säga att den kan vara jättestor.
Tar man i från tårna med en 64bit integer så kan den vara från -9 223 372 036 854 775 808 till 9 223 372 036 854 775 807.

Signed och unsigned är om den kan gå negativt eller inte. (sint / uint)

En del väljer att kalla de olika storlekarna på integers för olika saker. double integer, word, long, mm.

Enligt standard är:
char minst 8 bitar
short minst 16 bitar
int minst 16 bitar
long minst 32 bitar
long long minst 64 bitar

Dessutom får de inte "gå om varandra" så om t.ex. 'int' är 64 bitar måste både 'long' och 'long long* också vara minst 64 bitar.

Unsigned och signed är alltid lika långa.

När en variabel 'slår om' till noll igen så får man naturligtvis ingen varning för det eftersom det enligt standard skall vara just så att den slår om.
Alltså att t.ex. en unsigned 16-bitars int går till max 65535 sen slår den om till 0.

Om sedan aktuell kompilator följer standard är en annan fråga.
Läs i filen 'limits.h' som innehåller makron med min- och max-gränser m.m. för aktuell kompilator.

newbadboy skrev: ↑25 augusti 2022, 16:58:15 Aehhh det har jag missat helt. Googlade hur stort int var och då var det betydligt större

Alltså, googla inte utan titta i 'limits.h' vad som gäller för din kompilator. Google vet inte vilken kompilator du har. Eller ja, det vet Google m.fl. naturligtvis...

Uppfattat.

ojz0r skrev: ↑25 augusti 2022, 18:22:24 För 64-bitars processorer brukar den vara just 64-bitar medan en 8-bitars MCU är en int i regel 8-bitar.

På praktiskt taget alla 64-bitsplattformar är en "int" faktiskt fortfarande 32 bittar. Processorerna har instruktioner också för 32 bittars heltal, vilka används för just "int" och "unsigned int".
Det är väldigt ovanligt med CPU-arkitekturer som bara stödjer 64-bittars heltal. (jag tror jag har sett en men kan inte komma på vad den hette ...)

En sak som skiljer sig dock, är "long int". Under Windows är den typen 32-bit för bakåtkompatibilitet med 32-bittars Windows, men annars brukar "long int" vara 64-bit på 64-bittarsplattformar.

På 8-bittars AVR brukar "int" vara 16-bittar, men det ska gå att sätta till 8 med en kompilatorflagga.
Jag brukar i min kod använda "int8_t" överrallt och hoppas att kompilatorn är smart nog att optimera bort förlängning till 16 i de flesta uttryck.

bit96 skrev: ↑26 augusti 2022, 11:29:09 När en variabel 'slår om' till noll igen så får man naturligtvis ingen varning för det eftersom det enligt standard skall vara just så att den slår om.
Alltså att t.ex. en unsigned 16-bitars int går till max 65535 sen slår den om till 0.

Obs att C-standarden endast säger att "unsigned int" (och större) slår om.

För "int" så blir det istället "undefined behaviour", vilket C-kompilatorn har rätt att ignorera.
Det betyder att det faktiskt kan bli galet numeriskt fel på sätt som inte går att förutse.

En anledning till detta är att C också stödjer ovanliga processorer och microcontrollers som inte lagrar "signed"-typer i tvåkomplementsform, eller som implementerar "mättad arithmetic" (eller var de nu heter på svenska, alltså där resultatet blir ett MAX-värde och inte slår om).

Obs också att "unsigned"-typer mindre än "unsigned int" alltid förlängs till "int" i beräkningar — och inte till unsigned int. Det betyder att högre bittar ligger kvar, och att resultatet kan bli negativt eller undefined.
Därför bör man vara noga med att cast'a till "unsigned int", och ev. maska om det behövs för att vara säker på att det ska slå om korrekt som en mindre typ.

@Findecanor: Tack för rättelsen.