View Single Post
  #434   Spotlight this post!  
Unread 13-03-2008, 22:32
Manoel's Avatar
Manoel Manoel is offline
Registered User
FRC #0383 (Brazilian Machine)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 2000
Location: Porto Alegre, RS, Brazil
Posts: 608
Manoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond reputeManoel has a reputation beyond repute
Send a message via ICQ to Manoel Send a message via MSN to Manoel
Re: New C18 3.0+ Compatible FRC Code

Quote:
Originally Posted by Manoel View Post
I've had the exact same problem you described, except I was using a competition dongle (practice time at home). The problem only happened three times, two with the flashing code error light. The other time, code error turned on steady and only a cold boot would fix it (resetting didn't do a thing).

The problem appeared to happen when we clicked the "set arm position" button, but all that does is change a variable's value, the function that sets it gets called every slow loop regardless of a button press. I couldn't replicate the problem in any way, I just noticed that it coincidentally happened when we pressed one of those buttons.

There's nothing too slow in my code (absolutely no for/while loops, only a few printfs, two 8 CPR home-made encoders and two analog channels reading - that's the heaviest section) and most of it is standard Kevin code. My "fix" to the steady code error light was a Master processor reprogramming (and updating the user code with the same code that was running before), and I haven't been able to replicate the problem. I didn't even think it was a big deal, but now that you may have the same problem there could be something wrong (and if there is, it's probably in this sequence: our code -> our RC hardware -> the PIC silicon -> Kevin's code )

Hopefully it went away, but, once again, it was too sporadical to know for sure.

Kevin, I can send you my code if you want, but I really don't think there's anything wrong with it.
Once again thanks for writing it!
Well, we were able to track down this problem today (on a regional practice day, what were the odds!). We have a custom made encoder in our robot and the perforated disk was in a position such that, in rare ocasions, it would trigger the IR receiver on and off continuously. That was generating several thousand interrupts per second and bogging the processor down. The problem only ocurred on a very specific position of the encoder, explaining why it was so intermittent (looking almost random).

In the end, it wasn't my code's fault, neither Kevin's (obviously ). Great when you can blame the other guy for the hardware, heh?
__________________
Manoel Flores da Cunha
Mentor
Brazilian Machine
Team # 383