This steadily decreases, but I need to detect when DMX1faded reaches zero (so I can stop it counting down).
If the division isn't equal and goes past zero, it rolls over back to 255 (because it's a byte).
So why can't I just declare DMX1faded as an int?
Would this not allow the result to go negative so that I can detect with a simple 'if (DMX1faded<0){blah blah}.
Strange a ovr error is not produced. When an int goes over or under its boundaries a ovr is generated. I I know a ESP32 produces a ovr error, which can be detected. Oi! Almost forgot the Uno's timers produce overflows that are detected.
Thanks. But why doesn't it allow it? Are you not allowed to mix the types of variable in a calculation? But that doesn't make sense, as I have also tried it by changing all the variables to int's.
Surely the issue with if (DMXmax1 / (DMXrate1 * 4)) >= DMX1faded is that it's possibly never going to reach zero. Therefore I cannot detect when it gets to that point.
And, for such a simple question, I don't see any reason at all to supply pages and pages of code to wade through. My explanation of the problem is plain enough.
Presumably you are using unsigned byte as the variable definition.
It appears that unsigned arithmetic in C++ does not overflow - something that I was not aware of. I cannot find a reference, but this article also mentions it: 4.5 — Unsigned integers, and why to avoid them | Learn C++ (learncpp.com)
You say you tried changing all the variables to ints - but what sort of int? If these were still unsigned the result would be the same.
The only thing that's plainly clear is that you've written bad code that doesn't work and you don’t' know why.
You're right, nobody wants to wade through hundreds of lines of your messy code. So, the fastest way to get real help is to post a small, complete code that compiles and demonstrates the problem at hand (and only that problem). This is called an MRE. It will enable people test your code, confirm the problem, and provide solutions that can be verified.
Of course unsigned arithmetic overflows. And it does so in a manner that's precisely defined by the language specification. But, since @ phoneystark20201 hasn't posted a complete code that includes variable types, there's no way to tell what he's done wrong.
According to ISO/IEC 9899:201x (open-std.org) "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type."
Sorry, I was referring to "wrap around" as overflow. Wrap around clearly happens with unsigned arithmetic (i.e. always using unsigned subtraction when dealing with millis()). I think that's what the section you quoted is saying.
I have told you what variable types they are..... bytes. Said that in the first post.
I didn't think such a simple issue would require an MRE. Not every question surely requires a program to demonstrate it.
If I was having library or a more complicated problem, I would post the entire code.
It's not 'bad' code, it's just code that doesn't appear to do what I thought.
Don't worry. I am not getting into a pointless argument over it. Thank you for everyone's kind advice, an I will sort the problem out myself
