|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#16
|
|||||
|
|||||
|
Quote:
|
|
#17
|
|||||
|
|||||
|
Quote:
Matt |
|
#18
|
|||||
|
|||||
|
Quote:
|
|
#19
|
||||||
|
||||||
|
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. |
|
#20
|
||||
|
||||
|
I used Python last summer on my internship . I was a Systems Engineer for the team so I didn't do a whole lot of coding, but the one problem I found with the language is the limitations on bit level manipulation. One of my projects was to work on some CRC Coding and it was some of the ugliest code I have ever developed. I believe that code is still in use because there is no easy way to do the bit manipulation that happens in the encoding process using Python. I really like having these bit manipulation functions when programming robots because it simplifies life a lot. Python is a great language, very portable, but not for what we are doing with a micro-controller.
Steve |
|
#21
|
|||
|
|||
|
When it comes to the programming language, I think the new controller should be flexible. Something like the OOPic, where you can program in Basic, C, or Java. This would cover all of the bases and allow a team to find a programmer comfortable in at least one of those languages. However on the hardware side of things, the OOPic is still probably a little slow. It does allow for more program storage and easy networking of co-processors though. However my vote, if it counts, would be for a multi-language platform.
|
|
#22
|
|||||
|
|||||
|
OOPic
The OOpic is great for that multi-language ablity.
Since I'm a mechanical guy, I need all the help I can get with electronics and software, and the OOPic is the easiest micro that I have found - and they are dirt cheap. And they are object based. And they can be networked together. And they have built in object classes. And they are great. OOpic I have not checked out the OOpic II yet, but it looks like it is more of the same goodness. |
|
#23
|
||||
|
||||
|
personally, IMO, any oo language would be great. Right now im in the process of mastering JAVA, and learning C/C++. Both are simple, but JAVA is easier to learn. I hope that FIRST does go to some kind of a OO language, whether it be C/++, JAVA or even perl, ruby or python.
|
|
#24
|
||||
|
||||
|
Our team is already starting up a PBasic class for the summer. I'm just hoping that if the language changes FIRST lets us know early so we can learn it before build season. Programming a robot is enough work without having to learn a new programming language in the same 6 weeks.
|
|
#25
|
|||||
|
|||||
|
Quote:
http://aspn.activestate.com/ASPN/Coo.../Recipe/113799 Given that I don't really know Python, I'm assuming that's doing bit masking properly (well, in this case it's just grabbing individual bits). However, I think you'll find that most programming languages deal with bit masking very similiarly to Python. From what I can see, it seems to (unsuprisingly) have the exact same methods of accessing bits as C does. Now, if you want a language that doesn't deal well with bitmasking, look at Java. Matt |
|
#26
|
||||
|
||||
|
Personally, I'm no fan of PBASIC. But the only language I hate more is Java. Java became obsolete the moment Sun introduced it -- it's low performance, cumbersome, and crashy in most implementations of its interpreter. It's also occasionally favored by academia, which is why I have a distinct fear that the new processor will be Java based. Seeing as PBASIC was designed for programming newbies, I don't think C is much of a possibility. Same goes to a lesser degree for C++. So I'm banking on an upgraded Parallax stamp. But if it's C#, then I know there's something fundamentally wrong with the universe.
|
|
#27
|
||||
|
||||
|
What's your issue with C#? Unlike Java it is NOT proprietary. C# is an open standard while Sun owns Java outright. And C# is much improved over Java. Easier then C++ to use and much easier then C. Several companies are now out with good development environments for it as well. Have you tried it? I was a big BASIC fan for 30 years and C# is the first langauge to come out that has made me think of changing.
|
|
#28
|
||||
|
||||
|
I would be surprised if they did not use some form of C. I think that it is a way to make a transition from student programming into "real world" programming. If you go up to almost any engineering student, that has or is currently going through a senior project, they will say that they know at least something about C programming. IT is very commonly used in the engineering field, and I believe that it is one way that FIRST is going to be teaching us even more "real world" experiences. The way I see it, what ever language they select, its just a matter of learning its limits, and spending the practice time with it. Remember if you already learned one programming language, I am sure you can learn another.
See you guys at IRI. |
|
#29
|
|||||
|
|||||
|
Given that I teach Java based labs, I feel a bit of a need to stand up for the language. Basically, Java is quite a good language for Object Oriented programming. While some claim that it's slow, with modern Just-In-Time compilers this really isn't all that much of an issue anymore. Java will run just fine on most hardware. I'm not sure why being favored by academia is a bad thing for Java (surprisingly, academia also seems to like C++; I don't think that has any bearing on what quality of language it is). As for having a crashy interpreter, I've never had the official Sun interpreter crash on me. Microsoft's JVM is buggy but that's Microsoft's fault (there are rumours that this was done intentionally). As far as Java being cumbersome, I've not had any problem writing many different programs with it doing many different things. I'm not sure how Java was obsolete the moment Sun introduced it. While it does have a few short comings (generics being the major one which, thankfully, are being fixed in the next revision), they aren't enough to obsolete the language.
As for C#, it is very similiar to Java. Most of the changes are purely syntatical sugar. While it may have been released to a standards body, the key part of the language, the class libraries, is still proprietary and very much tied to the Windows Operating System (WinForms being the main culprit). C# was designed with minimal portability in mind. Unlike Java, it is not write once, run anywhere. I'd be very surprised to see a change to a C# based microcontroller if only because I don't think any exist (can anyone correct me here?). My bet is that if we are switching programming languages it will be to Java. Using the Java framework it would be very easy to design a system that could easily be extended from a framework provided by IFI (namely, using object inheritance and method overloading). Given the direction that the AP test is taking, many colleges (which are switching their CS programs to Java), as well as industry (Java is heavily used on server-side development), I think FIRST will go with a Java based microcontroller if at all possible. Matt |
|
#30
|
|||
|
|||
|
C would be an obvious choice. It's the most popular language for microcontrollers now, even more than basic (including pbasic). C is the most popular language for everything nowadays it seems. There's no reason why it couldn't be C.
As much as I don't like Java, it would quite a reasonable choice as well with the Javelin Stamp and all. Or how about BASIC, C, and Java syntax? That'd be the best route IMO. Allow the programmers to choose their language of choice. It's a possibility. I've been looking into the OOPic lately, and the more I do, the more I love. It has many advantages over the Basic STAMPs. *edit* I just noticed Not2B pointed out the same thing. OOPs ![]() Last edited by jon : 11-06-2003 at 23:12. |
![]() |
| 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 |