I.m clearly thick.... dividing bytes

Using Arduino Programming Questions
#1

OK. Stupid one.

I have a byte that is declared at somewhere between 10-255 called DMXmax1.
I have a byte that is declared at somewhere between 1-60 called DMXrate1.

I have a byte called DMX1faded that is the result of this simple math:

DMX1faded = DMX1faded - (DMXmax1 / (DMXrate1 * 4));

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}.

That doesn't work and I don't see why.

#2

And we can't see your code.

#3

Yea, you could use an int to detect a negative value and do the other thing.

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.

#4

Check if (DMXmax1 / (DMXrate1 * 4)) >= DMX1faded before carrying out the subtraction.

1 Like
#5

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.

Thank you for the advice

#6

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.

#7

Hi,
Welcome to the forum.

Please read the post at the start of any forum , entitled "How to use this Forum".

We need to see all your code.

Thanks.. Tom... :grinning: :+1: :coffee: :australia:

#8

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.

#9

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."

#10

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.

#11

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

#12

What do you mean?

uint8_t DMXmax1 = 255;
uint8_t DMXrate1 = 1;
uint8_t DMX1faded = DMXmax1;
while (DMX1faded != 0) {
    uint8_t decr = DMXmax1 / (DMXrate1 * 4);
    DMX1faded = decr < DMX1faded ? DMX1faded - decr : 0;
    Serial.println(DMX1faded);
}

192
129
66
3
0
#13

Thanks Pieter. Now I understand what you mean.
Not used decr in my code before.

I have now solved the issue. Thanks