New C18 3.0+ Compatible FRC Code

[Guy Davidson]

We used it. There was one wierd issue with something that used to happen in the initialization routine not happening any more (initializing two variables to values read from the ADC), but that could be connected to me disabling the gyro code, or something else. If I can't find it after I try to look for it harder, I'll let you know.

Overall though, the code worked fantastically well.

[Bharat Nain]

Originally Posted by Kevin Watson

You're welcome . Of the teams that used my code last week, did any bugs pop up?

-Kevin

While we did not use any of you gyro or encoder or any other fancy code, we did use your base new format. It was wonderful and easy to work with. We did not have any problems with the code itself and generally we are all very glad you made something like this. The Quick_ADC function was enough for our mast even though it was really fast (relatively). Thanks for the hard work to provide such a quality product.

[gwt8641]

Can anyone confirm that this code works when interfaced to the competition control?

I ran this code, compiled with the 3.0 compiler, with no issues prior to competition. During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.

Any ideas? It very well might not even be related to Kevin's libraries... but the default .hex file from IFI seems to work, so I'm stumped. I can't even find a 2.4 version of the compiler, so I hope to make this work.

Thanks!

[billbo911]

Originally Posted by gwt8641

Can anyone confirm that this code works when interfaced to the competition control?

During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.


Thanks!

We tested it without issues at a local practice event. The competition port was used to control the systems.

From your description, it sound like you may be using a "While" loop.??

We did this and killed our selves. Once we realized what happened, we dropped the "While" loop and everything returned to normal.

[Guy Davidson]

It definitely works. We ran it at Portland.

[Tom Bottiglieri]

Originally Posted by gwt8641

we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.

What sort of malfunctions?

[gwt8641]

Originally Posted by Tom Bottiglieri

What sort of malfunctions?

The Green power light on RC flashes slowly. On the OI, the "No Data / Radio" light flashes and "Code Error" is on solid. If I keep playing with the reset and program buttons I can get it to run normally for a while and get it into program mode.

I just looked for while loops thinking maybe I mistakenly typed it instead of an "if" statement or something, but didn't find anything. Any other ideas on what may cause this?

Thanks for the help!

[Kevin Watson]

Originally Posted by gwt8641

Can anyone confirm that this code works when interfaced to the competition control?

I ran this code, compiled with the 3.0 compiler, with no issues prior to competition. During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.

Any ideas? It very well might not even be related to Kevin's libraries... but the default .hex file from IFI seems to work, so I'm stumped. I can't even find a 2.4 version of the compiler, so I hope to make this work.

Thanks!

I've received quite a few e-mails and PMs with positive feedback on the code (team 1024 used the code in Chicago last week and won). Two people have had problems, but one turned out to be a call to printf() inside an interrupt service routine that was quickly fixed. Tom Bottiglieri is having a weird issue with the RC occasionally throwing the red-light-of-death when it's cold booted, but it's not clear to me what is causing the problem.

If you want, you can zip up your code and send it to me for a quick look.

-Kevin


Edit: Whoops, 1024's master programmer just contacted me to point out that they used some of my other code, but not the 2008 base code.

[ldeffenb]

Originally Posted by gwt8641

Any other ideas on what may cause this?

Thanks for the help!

Anything that causes your program to be slow at responding to the master processor during normal execution can cause a Code Error light (Red Light Of Death). Even an over-chatty set of printfs can cause this to occur.

If you are using interrupts for things like encoders and have too high resolution encoder (say 256 pulse per rotation) on a shaft that spins too quickly (say > 4 revolutions per second), then that encoder alone can generate >1000 interrupts per second. We use a guideline of no more than 4000 interrupts per second and very small, streamlined interrupt processing.

If you've configured a millisecond timer interrupt, then you've got 1000 per second occurring there also.

One indication that you're being a bit slow in responding to the master controller is a sluggish response to OI commands like joystick motion. That's the first indication, although you may not see it if the slow response occurs on some other event (like hitting a limit switch or turning on a motor to high speed that is being read by an encoder).

All things to think about. I hope you get it figured out!

Lynn (D) - Team Voltage 386 Software

[RyanN]

Originally Posted by gwt8641

The Green power light on RC flashes slowly. On the OI, the "No Data / Radio" light flashes and "Code Error" is on solid. If I keep playing with the reset and program buttons I can get it to run normally for a while and get it into program mode.

I just looked for while loops thinking maybe I mistakenly typed it instead of an "if" statement or something, but didn't find anything. Any other ideas on what may cause this?

Thanks for the help!

This sounds almost like your Master Processor is messing you up, especially since you say that the battery indicator LED flashes slowly. Try to first reload the master code using a different computer, a different serial port, and redownload the code, as some information may be getting messed up. Also start fresh, preferably with IFI's code and see if you encounter the same issues. If you don't have any issues, go back to the default version of Kevin's code, if that doesn't give you issues, then load your code to see if that gives you any issues.

Basically, go through some troubleshooting steps. Go back to what you know should work, and if it doesn't, then call IFI for them to fix your RC.

Nothing that you code should mess with the indicator lights on the RC... this is what leaves me to believe that your master code is corrupted.

[gwt8641]

Originally Posted by Kevin Watson

I've received quite a few e-mails and PMs with positive feedback on the code (team 1024 used the code in Chicago last week and won). Two people have had problems, but one turned out to be a call to printf() inside an interrupt service routine that was quickly fixed. Tom Bottiglieri is having a weird issue with the RC occasionally throwing the red-light-of-death when it's cold booted, but it's not clear to me what is causing the problem.

If you want, you can zip up your code and send it to me for a quick look.

-Kevin

I'm sorry, I think my first post came across as more accusatory than I intended. Kevin, you did an awesome job with this code and your work is much appreciated. I've been using various bits of your code for years now with great success. My reason for posting was hope that someone else had encountered the same problem we hit and had a simple solution.

I'm still not sure exactly what is going on. Reloading the user program to our RC seems to briefly fix the problem, leading me to believe that this program is somehow becoming corrupt. I no longer believe Kevin's 3.0 compatible code to be contributing in any way (and I'm glad to be using it!)

Kevin, I'll still zip and send you our program.

Thanks all!

Greg

[Manoel]

Originally Posted by gwt8641

Can anyone confirm that this code works when interfaced to the competition control?

I ran this code, compiled with the 3.0 compiler, with no issues prior to competition. During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.

Any ideas? It very well might not even be related to Kevin's libraries... but the default .hex file from IFI seems to work, so I'm stumped. I can't even find a 2.4 version of the compiler, so I hope to make this work.

Thanks!

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!

[gwt8641]

Originally Posted by Manoel

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

This sounds real close to what I keep seeing. It usually happens in response to a change in command input, but I can't figure out exactly what triggers it.

The fix I've discovered is to re-upload the master and user code (although sometimes just re-uploading the user code works). Not sure if this is relevant to the new 3.0 compatible code, maybe we should move to a different thread?

- Greg

[Kevin Watson]

Originally Posted by gwt8641

I'm sorry, I think my first post came across as more accusatory than I intended.

There's generally a lot of finger pointing in the engineering profession, so I'm used to it by now . In all seriousness, if someone thinks they've found a bug in my code, I'm very interested in hearing about it.

-Kevin

[LordRed]

Was your battery fully charged at the time of the error?