Yes, signed types always have such issues. That is a big reason why I
started by saying you should /never/ be using "char" for arithmetic -
always use int8_t or uint8_t (or int_fast8_t, uint_least8_t, etc., or
application-specific typedefs of these). Leave "char" for holding
characters - ASCII le
Thanks. Did forget to mention that *16/256 instead of >>4 does insert
some code to add ((2^n) -1) on negative values (because /16 and >>4 is
not the same).
So a direct optimization on shr would be better.
Kind regards, Jochen
Am 30.12.20 um 12:19 schrieb David Brown:
Hi,
As a general point
Hi,
As a general point, never use "char" like this - use either uint8_t or
int8_t depending on whether you want signed or unsigned. Usually if you
are doing shifts, it's uint8_t you want.
The AVR compiler has trouble with some of these kinds of expressions. I
think it has something to do with t
