Quote:
Originally Posted by Terry Sherman
We've seen the 8.3/8.2 Battery Voltage Bug yesterday and today with the following setup:
2007 controller
Beta 14 master firmware.
2007 radios.
2007 OI
We have the PROTECTED memory section defined in the linker command file.
We have the latest FRC 8722 Library file
Has any other teams seen the 8.2v bug resurface? Any ideas?
Thanks!
-Terry
|
Terry, when I talked to Tom Watson at IFI this morning, he again said that I was the only person to report the problem this year. Can you please call IFI so that they are more aware of the problem.
Quote:
Originally Posted by eugenebrooks
For what it is worth, when we had this problem last year we were using a timer to time the rotational interval of the ball shooting wheel. Our code to do this was very compact and carefully combed over for potential race conditions. Small changes to printf statements, or adding static sentinel variables to the code, could cause the 8.2 volt bug to come and go, and in particular, memory movement caused by the sentinel variables could cause hard code errors. The code ran without a hitch on the prior years RC.
Given all this trouble, we did not use any custom interrupt/timer coding this year. Stepping outside of what is commonly used by all the teams seems to get you into serious trouble with the new PIC chip. In my humble opinion FIRST should allow an older controller to resolve the 8.2 bug when it occurs. It just isn't right to lead students through a sophisticated control system development only to have the 8.2 bug take you out at the competition. We are supposed to be inspring the students, not depressing them.
Eugene
|
That's exactly the type of behavior we are seeing. I disabled all printfs and it ran overnight without a code error
I would support allowing the older controllers, however that wouldn't help us without a major code redesign, because we're already over both the code and RAM limit for the older processor.
Quote:
Originally Posted by kaszeta
Our code has 8 ADC channels running Kevin's ADC code at 800 Hz and 16 samples per update (so that we could get 12 bit precision although in testing I think we can work just fine with the default 200 Hz and 4 samples per update), as well as three shaft encoders all running at up to around 1000-2000 pulses/sec. We also generate a *lot* of debug printfs, but the student programmers will probably comment out most of those in the pits. We've got Kevin's serial drivers in there as well, but no camera. I haven't been able to duplicate anything yet with either controller using the fixed library and linker scripts. The 2007 rc has the beta update for the master controller code, but the 2006 rc is un-updated.
I'll try to recreate your setup and torture-test my 2006 RC if I have a chance.
|
We wanted to run the gyro at 1600 hz and 32 samples per update (we've gotten very good results with that in the past). Last year, that was the only sensor we used, so Kevin's ADC code was fine. However, this year, we're using 5 other analog sensors, so it wasn't practical to use his code with a sample rate of 1600*6. Our modifications use the same basic framework, but allow different channels to use different sample rates and samples per update values. It takes longer to execute the interrupt routine, and uses more stack space, but I've proven that the problem isn't throughput or stack space.