4 ms·

You see, this is how I would imagine programming for an ATTiny85 would be like. I've taken interest in them myself, but I can't imagine taking a modern-program

You see, this is how I would imagine programming for an ATTiny85 would be like. I've taken interest in them myself, but I can't imagine taking a modern-programming, DRY-worshipping approach where the code itself is a particular abstracted style guide. I'd expect a lot more hexadecimal, repeated sections, and just generally a picture of what ends up in the chip's memory, which is mighty tiny. It seems like there wouldn't be ROOM to make modern corporate programmers happy. I find the article fundamentally weird, like criticizing the rhyme scheme of an instructional manual. That said, startling to learn that you get no sort of warning that 'int' for the ATTiny85 is so different from what you might think it is. I'd be looking for some kind of special int definition that corresponds with what's in the ATTiny85, and just sticking to that.

Arch-TK 3y ago
The ATtiny85 is an 8 bit MCU. It has no int. Moreover, the C standard doesn't impose restrictions on the width of an int other than that it must be able to hold values between -(2^15 - 1) and (2^15 - 1) (yes, you read that right, this is because before C2x int can be one's complement, two's complement or sign and magnitude). Now this is mainly C being an unforgiving language but realising this, it may be easier to piece together what's happening here. Since the ATtiny85 is an 8 bit MCU, anything wider than 8 bits has to be implemented in software. To keep the performance cost of heavy use of int as low as possible, the narrowest possible definition was used. This is in contrast to the author's system which probably uses 32 bit ints. I imagine the code when #included worked fine because of 32 bit ints and broke when compiled for the ATtiny85 because it used 16 bit ints. Warnings _could_ help here (and I believe the author when he says that the Arduino IDE had no obvious way of enabling them), but realistically the solution would have to re-write the code to use fixed width types. That way you could at least rely on the widths being the same. Although at least until C2x, you can't assume two's complement. That being said, it seems to me that trying to "simulate" the chip like this is always going to result in issues, especially when you try to emulate hardware. Probably the best solution here is to bite the bullet and learn how to use simavr which would pay off regardless of using C or Rust.

Arch-TK 3y ago

The ATtiny85 is an 8 bit MCU. It has no int. Moreover, the C standard doesn't impose restrictions on the width of an int other than that it must be able to hold values between -(2^15 - 1) and (2^15 - 1) (yes, you read that right, this is because before C2x int can be one's complement, two's complement or sign and magnitude). Now this is mainly C being an unforgiving language but realising this, it may be easier to piece together what's happening here. Since the ATtiny85 is an 8 bit MCU, anything wider than 8 bits has to be implemented in software. To keep the performance cost of heavy use of int as low as possible, the narrowest possible definition was used. This is in contrast to the author's system which probably uses 32 bit ints. I imagine the code when #included worked fine because of 32 bit ints and broke when compiled for the ATtiny85 because it used 16 bit ints. Warnings _could_ help here (and I believe the author when he says that the Arduino IDE had no obvious way of enabling them), but realistically the solution would have to re-write the code to use fixed width types. That way you could at least rely on the widths being the same. Although at least until C2x, you can't assume two's complement. That being said, it seems to me that trying to "simulate" the chip like this is always going to result in issues, especially when you try to emulate hardware. Probably the best solution here is to bite the bullet and learn how to use simavr which would pay off regardless of using C or Rust.