Verschil tussen datatype int en long op Arduino

Op de Arduino (AVR-modellen) is een int 16 bits, niet 32 bits. Het gaat dus van -32768 naar +32767.

Dat is verschillend van long wat 32 bits is.

Reacties

• Wat zijn de breedtes van int en long op de 32-bit ARM Arduinos zoals Due?
• Ik denk dat op de Due een int is 32 bits, hetzelfde is een long. Zie hier bijvoorbeeld.

int in AVR GCC is 16 bits , niet 32.

Volgens de C-taalspecificatie , int moet minstens 16 bits of langer zijn en long moet minstens 32 bits of langer zijn.

Het is oké voor een compiler om int te implementeren als 32 bits of zelfs 64 bits. Het is oké als een compiler long implementeert als 64 bits of langer. Maar het is niet toegestaan voor een compiler om long te implementeren als 16 bits.

Dus wanneer welk type moet worden gebruikt?

Als de waarden waarmee je gaat werken kan worden weergegeven binnen 16 bits, dan is het OK om int te gebruiken. Als je meer dan 16 bits nodig hebt, gebruik dan long. Als je meer dan 32 bits nodig hebt, gebruik dan long long.

Laat je niet verleiden door compiler- en / of CPU-specificaties. Zoals door anderen genoemd, zelfs binnen hetzelfde productassortiment, Arduinos, zijn er 16 en 32 bit CPUs beschikbaar. Vertrouw in plaats daarvan alleen op wat de standaardgaranties zijn.

De volledige specificatie van typen in C zijn:

• char moet minimaal 8 bits zijn
• int moet minimaal 16 bits zijn
• long moet minimaal 32 bits zijn
• long long moet minimaal 64 bits zijn

Opmerking: het is volkomen legaal voor compilers om char, int, long en long long te implementeren als 64 bits. Dit is in feite niet ongebruikelijk onder DSPs.

Reacties

• Ook: lees je compilerdocumentatie
• En: sizeof(char) <= sizeof(int) <= sizeof(long) <= sizeof(long long) volgens standaard. Dus als int 64 bits is, dan moet long ook minstens 64 bits zijn.

Het is dezelfde redenering als in C: de grootte van het int type wordt verwacht de natuurlijke woordgrootte zijn die uw systeem het meest efficiënt verwerkt . Het moet ook minimaal 16 bits breed zijn, niet kleiner dan een short, en niet groter dan een long.

Dus een int kan 16-, 32- of 64-bits zijn, gebaseerd op wat uw systeem het beste afhandelt, en dus waarschijnlijk 16 bits breed is op een 8- of 16-bits CPU, 32 op een 32-bits CPU enz.

Ik gebruik int wanneer ik de beste prestaties wil, terwijl ik ervoor zorg te bewaken wanneer ik meer bereik nodig heb dan geboden door 16 bits. Tegenwoordig heb je de neiging te weten wanneer je applicatiecode schrijft voor 16-bits systemen, hoewel dat niet zo waar is voor “bibliotheek” -code waar draagbaarheid van kan zijn grotere bezorgdheid.

In uw voorbeeld, ervan uitgaande dat de auteur hun typen zorgvuldig had gekozen, hebben de int variabelen waarschijnlijk een klein bereik nodig en kunnen ze het zich veroorloven om in woordgrootte te zijn , wat leidt tot mogelijk kortere of snellere code (of beide). De long versies hadden waarschijnlijk meer dan 16-bits bereik nodig (ze zijn gegarandeerd ten minste 32 bits breed). Op de processor die u “had geselecteerd als compilatiedoel, lijkt het erop dat int en long beide zijn geïmplementeerd als 32-bits; dit zou anders zijn (of zou moeten zijn) als je een 16-bits doel-CPU hebt geselecteerd.

Ik gebruik graag typen van stdint.h.

Hoewel ze kleine nadelen hebben, is het voordeel dat ze bieden, dat je precies weet hoe groot je bent, zelfs wanneer je compileert op andere architecturen.

#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. 

Maar je wilt natuurlijk niet een hoop int32_t verplaatsen als je gegevens alleen int16_t nodig hebben.

Opmerkingen

• Dus gebruik geen machinewoord grootte heeft geen invloed op de prestaties op AVR?
• @Ren é – Over het algemeen kan het niet gebruiken van woordgrootte de prestaties van de meeste CPUs beïnvloeden. Maar traditioneel hebben AVR-CPUs 8-bits registers & accumulators met ongeveer 16 bit instructies voor pointer operaties. Dus als ik programmeer, laat ik de code eerst draaien, en daarna optimaliseren voor snelheid if it ‘ is te traag.
• @Ren é – Maar als je er echt pedant over wilt zijn, kun je word als uw gegevenstype. Dit zijn 16 bits op Arduino Uno en 32 bits op Arduino Due & Zero. Maar dit komt terug op het probleem dat u eigenlijk alleen de minimale grootte van uw gegevenstype kent. Stel dat u word gebruikt voor een bepaalde Due-code, maar dan terug wilt porten naar Uno ?! Het gebruik van uint32_t in plaats daarvan zou dit probleem oplossen voordat het begint, maar ja, het zal suboptimaal zijn voor de woordgrootte op Uno. Hoe zit het met toekomstige Arduino-boards … welke woordgrootte zullen ze hebben? 32? 64? 128 !?
• OK. Dus ik zou de machinewoordgrootte gebruiken (int? WORD lijkt een obselete Windows-typedefinitie te zijn) als de ondergrens voldoende is, ik geef niet om de geheugengrootte en heb de snelheid nodig, * _t als ik om de grootte geef?
• schrap dat … gnu.org/software/libc/manual/html_node/Integers.html zegt *fast*_t lijkt de juiste keuze …