On teensy 3.2 (Sorry, using up old stock) is unsigned long 32 bits?

Yes, " teensy 3.2 has unsigned long 32 bits "

uint32_t is explicit name though uint should be the same as it is a 32 bit MCU
 
Also:
Code:
void setup() {
while (!Serial);
uint xx;
Serial.printf( "sizeof uint %d", sizeof(xx));
}
void loop() {}

gives: sizeof uint 4
 
One last question..

Is the teensy 32 bit unsigned long "the same" as say.. The Arduino Mega unsigned long 32 bit? Or perhaps are they packed differently? I ask these things because I have a binary file created by teensy and the pretend Mega on Wokwi can't seem to read it correctly.
 
Must admit, it's been so long that I've done much with AVR that I couldn't really remember with certainty. So I wrote a little test.

Code:
unsigned long n = 0x12345678;

void setup() {
  while (!Serial) ;
  delay(250);
  unsigned char *p = (unsigned char *)&n;
  Serial.println(p[0], HEX);
  Serial.println(p[1], HEX);
  Serial.println(p[2], HEX);
  Serial.println(p[3], HEX);
}

void loop() {
}

Sure enough, it prints this when run on Teensy 2.0.

Code:
78
56
34
12

Same result on Teensy 4.1.

Both Teensy 2.0 and Teensy 4.1 are little endian.
 
Just for completeness, I dug out an Arduino Mega board. My little program lacks Serial.begin() which definitly is needed on Mega.

Code:
unsigned long n = 0x12345678;

void setup() {
  Serial.begin(9600);
  while (!Serial) ;
  delay(250);
  unsigned char *p = (unsigned char *)&n;
  Serial.println(p[0], HEX);
  Serial.println(p[1], HEX);
  Serial.println(p[2], HEX);
  Serial.println(p[3], HEX);
}

void loop() {
}

With this version, Arduino Mega also is confirmed to be little endian.

Code:
78
56
34
12
 
As to why your program's binary data isn't compatible, just a blind guess without seeing the code, maybe it's related to padding the compiler adds when variables are in a struct or class? On 8 bit AVR, usually no padding is added. On 32 bit ARM, typically the compiler will add unused padding bytes so 16 bit variables align to even addresses and 32 bit variables align to addresses with the 2 low bits both zero.

You can declare your struct with a special packed attribute, so no padding will be used. But access is slower, because the compiler will use 4 single byte accesses for a 32 bit variable, as it must do on 8 bit AVR, rather than a single 32 bit access.
 
The code in question : https://github.com/leftCoast/LC_blockFile

I wrote this using unsigned long, awhile ago. Now I wonder if I should have used uint32_t? I'm getting the old "Shot myself in the foot" feeling. When I loaded one of these file into Wokwi, I couldn't read it. But if I created a fresh one there, it seemed ok.
 
Back
Top