Forskel mellem datatype int og lang på Arduino

På Arduino (AVR-modeller) er int 16 bit, ikke 32 bit. Således går det fra -32768 til +32767.

Det er forskelligt fra long hvilket er 32 bit.

Kommentarer

• Hvad er bredderne på int og long på 32-bit ARM Arduinos som Due?
• Jeg tror på Due, at en int er 32 bits, det samme er long. Se f.eks. her .

int i AVR GCC er 16 bits , ikke 32.

I henhold til C-sprogspecifikationen , int skal være mindst 16 bit eller længere, og long skal være mindst 32 bit eller længere.

Det er OK for en compiler at implementere int som 32 bit eller endda 64 bit. Det er OK for en compiler at implementere long som 64 bit eller længere. Men det er ikke tilladt for en compiler at implementere long som 16 bit.

Så hvornår skal man bruge hvilken type?

Hvis værdierne du vil arbejde med kan repræsenteres inden for 16 bit, så er det OK at bruge int. Hvis du har brug for mere end 16 bits, skal du bruge long. Hvis du har brug for mere end 32 bits, skal du bruge long long.

Vær ikke fanget med compiler- og / eller CPU-specifikationer. Som nævnt af andre, selv inden for det samme produktsortiment, Arduinos, der er 16 og 32 bit CPUer til rådighed. I stedet stol kun på, hvad standarden garanterer.

Den fulde specifikation af typer i C er:

• char skal være mindst 8 bit
• int skal være mindst 16 bit
• long skal være mindst 32 bit
• long long skal være mindst 64 bit

Bemærk: Det er helt lovligt for kompilatorer at implementere char, int, lang og lang lang som 64 bit. Dette er faktisk ikke ualmindeligt blandt DSPer.

Kommentarer

• Også: Læs din compiler-dokumentation
• Og: sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(long long) i henhold til standard. Så hvis int er 64 bit, skal long også være mindst 64 bit.

Det er den samme ræsonnement som i C: størrelsen af typen int forventes at være den naturlige ordstørrelse, som dit system håndterer mest effektivt . Det skal også være mindst 16 bit bredt, ikke mindre end en short, og ikke større end en long.

Så en int kan være 16-, 32- eller 64-bit baseret uanset hvad dit system håndterer bedst, og så sandsynligvis er det 16 bit bredt på en 8- eller 16-bit CPU, 32 på en 32-bit CPU osv.

Jeg bruger int når jeg vil have den bedste ydeevne, mens jeg er opmærksom på at beskytte, når jeg har brug for mere rækkevidde end 16 bits. I disse dage har du tendens til at vide, hvornår du skriver applikationskode til 16-bit systemer, skønt det ikke er så sandt for “biblioteks” -kode, hvor bærbarhed kan være af større bekymring.

Hvis du antager, at forfatteren havde valgt deres typer omhyggeligt, kræver int variabler sandsynligvis et lille interval og kunne have råd til at være ordstørrelse , hvilket fører til potentielt kortere eller hurtigere kode (eller begge dele). long dem krævede sandsynligvis mere end 16-bit rækkevidde (de er garanteret mindst 32 bit brede). På processoren, som du valgte som et kompileringsmål, ser det ud til, at int og long begge blev implementeret som 32-bit; dette ville være anderledes (eller skal være), hvis du valgte en 16-bit mål-CPU.

Jeg kan godt lide at bruge typer fra stdint.h.

Selvom de har mindre ulemper, er fordelen, de giver, at du ved nøjagtigt den størrelse, du håndterer, selv når du kompilerer med andre arkitekturer.

#include <stdint.h> uint8_t my_byte = 0xf0; int16_t trig_pin = 2; int16_t echo_pin = 4; uint32_t duration, cm , blah; uint64_t big_int; // etc. 

Men selvfølgelig vil du ikke bevæge dig rundt i en flok int32_t, når dine data kun har brug for int16_t.

Kommentarer

• Så du bruger ikke maskinord størrelse påvirker ikke ydeevnen på AVR?
• @Ren é – Generelt kan ikke brug af ordstørrelse påvirke ydeevnen på de fleste CPUer. Men traditionelt har AVR-CPUer 8bit-registre & akkumulatorer med nogle 16 bit instruktioner til pointeroperationer. Så når jeg programmerer, får jeg koden først, og optimer derefter til hastighed hvis den ' er for langsomt.
• @Ren é – Men hvis du virkelig vil være pedantisk omkring det, kan du bruge word som din datatype. Dette er 16 bits på Arduino Uno og 32 bits på Arduino Due & Nul. Men dette kommer tilbage til problemet med egentlig kun at kende minimumstørrelsen på din datatype. Sig, at du bruger word på en eller anden Due-kode, men derefter ønsker at bakke-port til Uno ?! Brug af uint32_t i stedet ville løse dette problem, før det starter, men ja det vil være ordstørrelse suboptimalt på Uno. Hvad med fremtidige Arduino-tavler … hvilken ordstørrelse vil de have? 32? 64? 128 !?
• OK. Så jeg vil bruge maskinens ordstørrelse (int? WORD ser ud til at være en ubegrænset definition af Windows-typen), hvis den nedre grænse er tilstrækkelig, er jeg ligeglad med hukommelsesstørrelse og har brug for hastigheden, * _t hvis jeg er interesseret i størrelse?
• skrot der … gnu.org/software/libc/manual/html_node/Integers.html siger *fast*_t synes at være vejen at gå …