|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools |
Rating:
|
Display Modes |
|
#13
|
||||||
|
||||||
|
What I want, but probably will not get...
A lot of great thoughts on this topic.
I agree with the idea that C would totally freak out the vast majority of FIRST teams. That doesn't mean it wouldn't be a good choice, just that it is going to mean a lot of teams will run with the default code just for fear of the dark... What I REALLY want is what I probably will not get: A multitasking kernel and a means of having access to real time interrupts. Why? Because the lower 75% of teams were killed by the autonomous programming this year. Why was that? Because of 2 things (in my opinion): #1, Programming of ANY kind was hard due to the nature of the multiple things that have to be controlled on a typical robot. #2 A serious autonomous mode all but required a co-processor on the custom circuit board. The programmers have the best and the worst job in all of FIRST. It is the best because when a program does its job, the coder can stand up and take well deserved bows. It is the worst because of the 6 weeks and 3 days FIRST teams have to complete their robot, building & wiring & mechanical debugging the robot usually takes 6 weeks, 2 days and 23 hours -- leaving about 1 hour to complete the task of writing bug free robot code. A multitasking kernel will VASTLY simplify the coding time required to make a robot work (wheels task, arm task, gripper task, switch debounce task, joystick filter task, etc. easy and independent). Access to real time interrupts would make a competitive autonomous mode within reach of the lower 75% of teams. By the time most of these teams realized they needed a more complex custom circuit board than they had planned, there was no time left to actually implement it. Giving teams access to real time interrupts (in a way that would not frighten them off), would allow for a competitive autonomous mode without a co-processor on the custom circuit board. This will allow more teams to have competitive autonomous programs. Multitasking is going to chew up RAM so gobs more RAM is probably a side requirement of getting what I want. For what its worth, I have evaluated BasicX as a result of some of the folks on this forum saying it was a worthy replacement for STAMP2. I think not. While it has a number of great improvements over PBASIC, it has its own set of issues. Mostly they come down to not having enough RAM to allow for mere mortals to use multitasking without crashing the system by overrunning the stack. 400 bytes seems nice until you actual try to do something -- like put a print.debug statement somewhere in your code. My current favorite is Basic-Tiger. Many, many pluses to using this chip. The only minuses are is that it is a German company (translated manual -- yuck) and (not unrelatedly) the chips are a bit pricey. Like I said, I doubt I will get what I want, but that does not keep me from asking... Joe J. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| What is your most prefered programming language? | Hailfire | Programming | 156 | 19-01-2005 21:42 |
| 2004 Championship Eligibility Criteria!!! | dez250 | General Forum | 214 | 28-12-2003 20:11 |
| Championship Qualification - How you would've done it | Ken Leung | Championship Event | 6 | 26-10-2003 14:00 |
| Making heads or tails of the new announcement... | Jessica Boucher | General Forum | 66 | 26-09-2001 11:13 |
| TI programming using Z80 assembly language | Jeff Wong | Chit-Chat | 1 | 07-06-2001 01:27 |