|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: reprogram during a competition
I would suggest a much simpler way of achieving the same results: optimize your code. It's free, and much less likely to malfunction. I truely doubt that you actually are going to run out of memory, but if you do, come up with creative ways of doing things. Use fewer variables. For example, if you were trying to swap two variables, instead of doing:
Code:
int c; c=a; a=b; b=c; Code:
a+=b; b=a-b; a-=b; Last edited by jgannon : 24-01-2005 at 22:14. |
|
#2
|
|||||
|
|||||
|
Re: reprogram during a competition
Quote:
in order to save memory, my team is using #define s for as much as possible, so when you compile/build it, as much as possible is already done. also, the same for some of the autonomous calculations--look up tables are faster and smaller than calculating something. (especially for trig functions, which you might need for autonomous--distance). plz tell me if im horribly wrong or something... thanks, ~Stephanie |
|
#3
|
||||
|
||||
|
Re: reprogram during a competition
If you need a sufficiently small number of values, table lookup will
save space. It just depends on how many you need. In the general case, an algorithm will save space and table lookup will optimize for speed. The use of #define will not necessarily save space (except in your source files, where you don't care). It depends on how you are doing things. To save space with constants, you want every reference to the value of the constant to be to the same memory location. If you just use the define, you will be storing the constant value everywhere it is used. |
|
#4
|
|||||
|
|||||
|
Re: reprogram during a competition
I might be totally missing something, but like jgannon says it takes (me at least) way more than 1.5 seconds to download a program to the RC. More like 1.5 minutes. And why dont you simply do the processing on something else (how much does a 386 cost?) and just use the RC for I/O?
|
|
#5
|
||||
|
||||
|
Re: reprogram during a competition
Jacob,
At the risk of sounding condescending, I can't believe that anyone is running out of space. If so, take a good hard look at what you are doing. Programming an embedded system is absolutely nothing like programming a PC. First rule: Never, never, ever use floating point arithmetic. Second rule: Never, ever use dynamic allocation of memory. Third: Avoid pointer manipulations unless you understand what it does in the machine (some dereferencing manipulations are murder). Look at the assembly code being generated by the compiler. You can see it in the .lst file that is generated when you build your project. Good Luck, |
|
#6
|
|||||
|
|||||
|
Re: reprogram during a competition
Quote:
Navigation (and all the trigonometry it requires). Multiple independently-tuned PID controls. Adaptive autonomy. Finally, lots and lots of text for communicating with the camera. I can easily understand someone running out of space. Last year's robot only did about half of what we have planned for this year, and it's using about 65 percent of the space. |
|
#7
|
|||||
|
|||||
|
Re: reprogram during a competition
I have to agree with Alan that if you try to dump everything possible this year into the program it can grow large.
Maybe not what you are looking for, but have you tried using the built-in compiler optimization to reduce your program bulk? In MPLAB
You have gotten rid of the IFI printf code, right? |
|
#8
|
|||||
|
|||||
|
Re: reprogram during a competition
Quote:
Fortunately, I have something of a knack for efficient implementations. ![]() |
|
#9
|
|||||
|
|||||
|
Re: reprogram during a competition
Quote:
The default FRC 2.4 version of the code comes in at 18,927 bytes or 55%. Optimizing gets you down to 14,743 bytes or 43% Sorry for the thread hijack Jacob. Us old folks tend to ramble on sometimes. I don't know of any rule that prohibits the downloading of new code as long as it's occurring within the custom circuit rules, and I can't think of any harm that might do from a safety or IFI control perspective. P.S. My wife was a warhawk. Just had a reunion in Vienna this past summer. Last edited by Mark McLeod : 25-01-2005 at 11:51. |
|
#10
|
||||
|
||||
|
Re: reprogram during a competition
Quote:
Quote:
|
|
#11
|
|||||
|
|||||
|
Re: reprogram during a competition
How do you guys connect the RC and the CC? If you used the ttl port then you are going to have to (actually you probably already did) find a way to hook two things to it at once assuming you are using the camera.
Back on topic however, It seems to be legal to reprogram in a match, but you might have a lot of explaining to do. The thing that will worry the judges the most is the possibility of you screwing with their master code. I would stay away from it for this reason, not to mention all of the reasons already mentioned. You are asking for trouble with both the technical and "legal" aspects of it, when it seems like you could accomplish something the same or better more easily, without the concerns over the rules. Thats just what I think. |
|
#12
|
|||||
|
|||||
|
Re: reprogram during a competition
thanks for the answer
as for Quote:
the chip by itself runs TTL levels (+5v) for the signal. with serial comunication, most things will cope just fine with +5, (rs232 spec goes to +15v, but we would use +12v), but some things are just pickey. so if you want to be "fully" compatable with all devices, your going to need a RS232 converter chip. any electrionics provider will sell them... you can get 4 converters in one IC for a buck or two Last edited by jacob_dilles : 25-01-2005 at 15:16. |
|
#13
|
||||||
|
||||||
|
Re: reprogram during a competition
If you are going to have another processor on your robot to do the programming, why not use that processor to offload some of the work?
You also need to check with IFI. I wouldn't be suprised if the field controllers freak out while the User processor is being programmed. |
|
#14
|
|||||
|
|||||
|
Re: reprogram during a competition
Quote:
The way I solved this was to just enable more obtimizations. If you do advanced debuging, read the compiler manual first. A few of them change break points, which I presume apply to the simulator, too. |
|
#15
|
||||
|
||||
|
Re: reprogram during a competition
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| CMUcam II and competition lighting environments | dlavery | Programming | 5 | 16-02-2005 02:07 |
| 2004 WPI EBOT Competition (using Robovation robots) | ahecht | Off-Season Events | 3 | 04-11-2004 21:25 |
| FANATIC - Offseason Animation Competition | opnickc | 3D Animation and Competition | 15 | 10-06-2004 20:54 |
| New Competition in MI, Mailing List | Allison K | Off-Season Events | 0 | 29-03-2004 19:53 |
| Robots prepped for competition | Brandon Martus | FIRST In the News... | 0 | 24-03-2004 17:06 |