Go Down

Topic: Problem with modulo (%) and reset (Read 14 times) previous topic - next topic

vesal

Thanks to try my code.

Quote
...Linux...

No, I'm using Windows 7 64 bit.  But this is not the bootloader problem, because the code works if it happens to reset correctly.

Quote
I added a delay of 1 millisecond in the loop.  Here's the code:


I tried that also and forget to tell.  I thought that it helped, but if you are passioned enough to press the reset button, then the problem comes anyway.

And why?  Because the 1 ms loop takes the most of the time from the main loop, so the certainty to press the reset while in division goes minimal.  

That it the thing it took me so long to  find that division is the problem.  Originally I had so much larger main loop and the problem game very seldom, I even ignored it at the beginning.

And my real concern is that if everybody that has division in his code has the same problem.  Normally people do not press the the reset button all the time, but I think also interrupt in the same case hangs the Arduino.  And that is the main concern.

davekw7x

#21
Dec 31, 2010, 03:05 pm Last Edit: Dec 31, 2010, 03:25 pm by davekw7x Reason: 1
Quote
Windows 7 64 bit


Generally speaking, I think it's really important for posters to tell us exactly what system they are using.  Sometimes it makes a difference to people who would like to help.

One final question, and then I am done for this thread:  Does the symptom persist if you unplug the UNO's USB connection and power it externally?

Anyhow...

I'm sorry to have wasted the board's bandwidth on something that couldn't help you.  But:  See Footnote.


Regards,

Dave

Footnote:
Putting in the delay() that keeps away from micros() is, at best, a Band-Aid that masks the real problem: A system bug that causes the Bad Thing to happen.

What I forgot to mention is that the UNO was absolutely unusable on my Linux system until I updated the firmware in the USB interface chip.  That made it "almost good enough" for casual testing, but it still has problems that I simply can't reproduce with the FTDI interface on Duemilanove boards or other designs that use the FT232 chip for the USB interface.

For Linux users, I still think it's a matter of interaction between the Bootloader and the Operating System's treatment of /dev/ttyACM0.  Whether it can be fixed with a new load of the bootloader or updating firmware in the ATmega8U2 USB chip on the UNO or a change in the Operating System's handling of USB with /dev/ttyACM0 is still awaiting discovery and fix.

vesal

Quote
I'm sorry to have wasted the board's bandwidth on something that couldn't help.


You did not waste the band.  You was the only one who really tried the code and showed to me that the problem can be repeated elsewhere than in my environment.  So lot of thanks and Happy New Year  :D

mspguy

#23
Jan 01, 2011, 03:30 am Last Edit: Jan 01, 2011, 03:32 am by cnt Reason: 1
Quote
Does not matter, because && has stronger precedence than >=.
In case of clarity this would of course be better.


no.  >= is evaluated first then &&
At least according to Kernighan and Ritchie

so,
Code: [Select]

( (!dOn && n1000) >= 500 ) != (!dOn && n1000 >= 500)


EDIT: also,  (!dOn && n1000) >= 500 doesn't make a lot of sense because it is always false ( (!dOn && n1000) evaluates to either 0 or 1, which is always strictly smaller than 500)

retrolefty

Ah Ha, I knew something was mangled in those if statements, but what do I know I'm just a hardware guy faking the programming stuff.  ;)

Lefty

Go Up