Arduino och definitionen av int

[bearing]

CC5x, som jag tror är en norsk (:D) kompilator för PIC definierar int som 8-bit.

[maDa]

Givetvis är det FLASH_SIZE som har ändrats, trodde det var klart?

ATMega168 och ATMega328 har 16k resp. 16k Flash. ATMega1280 har slådeles 128k.

[sodjan]

"Givetvis" !? Om det nu var så självklart, vad gällde då frågan egentligen?
Min spontana känsla var att det var ett gammalt projekt som kompilerades
om under samma förutsättningar, eventuellt med en nyare kompilator...

Om om nu FLASH_SIZE har ändrats och nu är större en en "int" så förstår jag
inte riktigt varför frågan handlar om att "definitionen av int" skulle ha ändrats
(i första inlägget).

[TomasL]

Det enda man med säkerhet kan veta är:
En char är den minsta typen som kan hålla hela arkitekturens teckentabell, på de flesta arkitekturer handlar det då om 8-bitars ASCII, men man kan ju faktiskt tänka sig en arkitektur som använder sig av 16-bitars unicode som standard, och då blir CHAR 16 bitar.
En INT är minst lika stor som en CHAR eller större, osv för de andra typerna.
så en 8-bitars INT är precis lika korrekt som en 16 bitars, eller 32 bitars.
Det enda som är hårt definierat är flyttal.

[lillahuset]

Det enda som är hårt definierat är flyttal.

Och inte ens det.

[bearing]

"Givetvis" !? Om det nu var så självklart, vad gällde då frågan egentligen?
Min spontana känsla var att det var ett gammalt projekt som kompilerades
om under samma förutsättningar, eventuellt med en nyare kompilator...

Håller med. Jag fick samma intryck.

Men det tidigare projektet måste ju varit på max 16k, för om det var 32k hade räknaren väl fortfarande inte rymts i en int16
32k:
FLASH_SIZE = 32768
MAX_INT16 = 32767
(EDIT: Om det nu inte är så att kompilatorn identifierar detta specialfall och genererar fungerande kod. För räknaren behöver ju bara gå till 32767, vilket ryms, men jämförelsen görs väl i en "standardloop" mot 32768, och stannar på 32768, så ska inte fungera i så fall.)

Arduino med 16k FLASH är ovanligt. Det är mest på senare tid som kineserna börjat sälja Arduino Nano med M168 istället för M328.

Så det verkar inte troligt att det gamla projektet körts på en 16k.

[Icecap]

Jag testade i mina projekt på Renesas RX210 med bytes osv. Det var intressant.

Jag hade en flyttalsuträkning som ville må bäst av att använda en double. Det visade sig att jag var tvungen att använda C99 eller nyare för att kunde ha en verklig double samt såklart slå på att en double verkligen skulle vara på 64 bits.

Det samma med en long long: C99 eller nyare för att kunde räkna med dom.

[bearing]

Menar du att variablerna blev 32-bit flyttal istället för 64-bit som du ville ha?
Gissar att det beror på argument till kompilatorn, och/eller flyttals-biblioteket du använder.

[Icecap]

bearing: korrekt.

Ja, det beror på kompilern, vilken C-version man använder (C90, C99, C11) samt om man flippar rätt inställning ihop med rätt C-version.

[Jan Almqvist]

...
Men det tidigare projektet måste ju varit på max 16k, för om det var 32k hade räknaren väl fortfarande inte rymts i en int16
32k:
FLASH_SIZE = 32768

Kanske har FLASH_SIZE varit 32000?

(Man får iaf. många träffar på Google med FLASH_SIZE och 32000.)

[bearing]

Ah, då förstår jag. De har alltså definierat en kB till 1000.

Bootloadern är ungefär 2k har jag för mig, så checksumman kommer att summera knappt halva bootloadern med resten (program, data, och tomt utrymme (0xFFFF)). Är det rätt?

[JanErik]

Hmm, storleken kommer härifrån...

Kod: Markera allt

#if defined(__AVR_ATmega1280__) 
  static const unsigned long FLASH_SIZE = 128000;
#elif defined(__AVR_ATmega2560__) // mega, Mega ADK
  static const unsigned long FLASH_SIZE = 256000;
#else
  static const unsigned long FLASH_SIZE = 0;
#endif

[bearing]

har varit 0 tidigare?

Du har inte tänkt svara på frågorna i tråden?

[JanErik]

Tycker inte det ska ha kunnat varit det eftersom det nog har detektat att firmware flashats om.