New programming language next year?
 

OK, now nobody flip out... but well, I've heard we're getting a new Controller next year. Got announced at a meeting last week. And they won't comment on whether or not it uses PBASIC. Perhaps Java? Who knows, but I say they should leave it as is. We're used to PBASIC! We can adapt either way though. Has anyone else heard about this?

It was announced at the Team Forums that there would indeed be a new robot controller, and it would use a new programming language.

The FIRST representatives also indicated that teams would be made aware of this language in the fall in order to prepare for it.

Of course, as with everything in FIRST, this could all change.

I just pray it is C++ :D

That's what it should be anyway :rolleyes:

Thanks for the clear-up
 

Thanks to Dave Flowerday for clearing up the issue of the new language being a rumor. FIRST has good minds behind it though, and I trust them to make a good choice. I suppose the biggest question will be whether or not it's similar to PBASIC or more object oriented. Any opinions? P.S. if anyone wants some old PBASIC code from this year, then drop me a line at BonsaiMagpie@aol.com. I worked on autonomous and came up with some pretty nifty stuff. Good bit of code for potentiometer matching with incorporated motor ramping.

Object oriented is good. It's nice and happy and easy to use :p. Well, at least after two years of C++ and two weeks of Java (Applets).

If they do, C++ would be a likely choice.

All I heard from the FIRST representative was that IFI has been upgrading the control system, and should be releasing information about the changes within the next month or two. Nothing was said about a new language.

All we can do, at this point, is wait.

/me reloads IFI's website looking for any sign of news.

Well, I suppose it depends on which forum you went to. I believe the quote from the Illinois forum was "There will be a new robot controller next year."

Personally, my guess is that it won't use PBASIC, simply because we're already using the fastest BASIC Stamp. C++ isn't very realistic for a low-cost embedded microcontroller. Too much overhead, and too much code space required. C might happen, but honestly I think that would be just too complicated for a good percentage of teams to deal with (teams that don't have software types as mentors, and don't have any students who already know it). I can only hope they don't use Java (I've never used a Java program that didn't feel slow and bloated, and I imagine a microcontroller based implementation wouldn't be much better).

I would expect so see something like the BasicX chip: for one thing, it's pin-compatible with the current controller, meaning IFI could probably drop it in to their current control system with no other hardware changes. It uses a dialect of BASIC, which is nice for inexperienced teams. It has 400 bytes of RAM and executes 65,000 instructions/second versus the BS2SX's 10,000.

Anyway, this is all speculation on my part. I believe we really will see a new user CPU next year, but like I said before, it's all up in the air until you hear the official announcement.

Just based on a previous conversation with a FIRST staff member, I don't think IFI will settle for "only" a 6.5x increase in speed.

I agree that C++ is not a likely choice. In my mind, it will either be C (the most popular microcontroller language) or java (the current most popular teaching language). Considering that AP CS is switching from C++ to Java this year only makes me think that they are less likely to use C++.

I know that a few years ago Eric from FIRST was interested in allowing either C or Java programming to be used for programming the robot controller. However, at the time, he was adamant that any change of language would be an "in addition to" PBasic and not a replacement.

My bet would be that we'll switch to Java as there is a JStamp out there that's almost pin compatible and runs Java.

Matt

I hope it's C. I know that language decent.

Java is C++ for the internet in my opinion. They are both OOP.

if i can do regular math (with none of the crazy MAX/MIN/adding 2000 to each equation) i'll be happy.

if i can store more variables easier, i'll be even happier.

if it runs at a respectable speed, i'll be very happy.

the problem is, if FIRST wants more autonomy, we need better controllers. it looks like it's going that way.

one other interesting point that was brought to my attention today...

We presented our robot at a local fair-type day (main street is closed, vendors set up shop, everyone has a good time). many people, when corrected about the FIRST/BB issue ;), asked about the controller. When I explained how we were forced to use the IFI one, many people said, "oh, that's dumb, you can't do anything with it." which brings me to my point, that being, with this new controller, will we have more options on the EE/SE side, similar to what the MEs have already?

C++ is more likely then Java. Even though Java is coming around for embedded applications C and C++ are more common. Of course if I have my choice it would be C# but that's unlikely. I think it will still be some sort of BASIC though. BASIC rocks.

PYTHON!!!
(I can"t code much more than a "Hello World," but I like python and the nerds I deal with dig it too.)
Anyone know how python compares to these others as a potential language for small robot controllers [in general, not just for FIRST next year]?

::Runs back into shop and hides from angry programmers::

Python is more on the DOS side-of-programming. Delphi would be more possible out of the two I think (Delphi is a superset to Python like C++ is to C).

No, it's not. Delphi is based on Pascal (basically it's Object Pascal). Python is a completely separate language. They may have some similarities but they're separate languages.

Matt

If by 'DOS side-of-programming' you mean text-based programming, then yes. Python works on Macintosh, Unix, Windows, and more.

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.

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

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.

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.

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.

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.

If you were looking for bit masking in Python, perhaps this class would help:
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

Please, don't let it be Java!
 

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.

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.

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.

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

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 :D

<quote>
As for C#, it is very similar to Java. Most of the changes are purely syntactical 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 micro-controller if only because I don't think any exist (can anyone correct me here?).
<end quote>

Actually C# was designed for portability. You can run it on Windows, Mac OS X and FreeBSD already and people are working on a Linux version. This does include a lot of the class libraries, though not all of the WinForms stuff. But it's still pretty powerful and less proprietary then Java. And of course you can write a program once and run it on your laptop, your cell phone, your PDA and a host of other small devices. I love the PDA emulator for testing C# PDA programs using Visual Studio .NET BTW. It's been a lot of fun to play with. Hopefully I'll have a PDA soon but I can still program for it without one. In any case the .NET framework was designed from the ground up to be portable across hardware platforms and form factors.

Syntactic sugar being the only differences from Java? I don't think so. For example you can not overload operators in Java but you can in C#. And then there is the whole notion of wrapper classes for Java that you have no need for in C#. Java doesn't treat everything as an object and C# does. That's a pretty big deal in my opinion. That's just the tip of the iceberg too.

I don't know of a C# microprocessor yet but one day soon I have hopes. Just my opinion not based on anything I know.

Alright, I'll concede that C# is a viable option -- but as Mr. Thompson says there has never been a microcontroller based upon it.

Now, some more Java bashing.

I will not deny that Java is the only perfect language. Esperanto was perfect too. But the most useful languages do not necessarily have the most regular syntax. Because of the language's structure, Java compilers can static check for many mistakes that would become run-time errors in almost any other language. The trouble is that this same rigid style forbids the programmer to abbreviate, and often necessitates the circuitous style that epitomizes bad OOP. Java is C++ minus everything that has turned into one of the most widely used languages ever (second only to C). Java has no pointers, no multiple inheritence, none of the lower level features that make C and C++ so demonically fast.

I highly doubt that the language will be too far away from PBASIC. Many rookie and smaller teams won't have the man power or resources to code in a drastically different program.

I don't know about that. Afterall, for a rookie team, it wouldn't be a "drastically different program[ming language]." :) And anyway, with a decent default program included, and perhaps some nice comments it shouldn't be that hard to learn another language. It's just a problem of syntax afterall, and there's tons of resources available on the web.

I don't know why "smaller teams" necessarily imply a lack of programming knowledge. But for the teams that indeed lack a lot of such knowledge, they probably didn't use anything but relatively simple (or should I say basic) PBASIC. And remember that
is pretty much the same in any language (we won't get into the wonder that is Scheme).

There's this new language called "Omnicron" or something like that. It is like PBasic and C/++ in my opinion. It's quite good, and very easy to learn. Just search for Omnicron, and it should be somewhere (I can't find the link right now).

Or my personal favorite, prefix notation (Y = YZ+) which is apparently used in a couple lesser known forms of C++ and PASCAL.

Java is much more portable than C#. I can run Java with GUI's on just about every operating system known to man. I've heard speculation of being able to run C# on cell-phone but have seen no evidence. Java is built-in to most of the higher end cell phones these days.

Now, as far as syntatic sugar goes, operator overloading is by definition syntatic sugar. All it adds is a way of writing code a bit more simply. It doesn't add anything new to the programming language. There also was a mention of the fact that C# treats all data types as objects whereas Java doesn't. This is true. Whether or not this is really a benefit is debatable. Java does, however, provide object wrappers for the primitive types which should provide all the featuers that C# does.

The main disadvantage to C# is that it's not a particularly mature language. It's also being pushed by a company that hasn't been known for cross-platform compatibility in the past.

As far as Java removing all the "good stuff," from C++, that's not really true at all. C++ have some features that can make it fast. It also has a lot of features that are very easy to screw up (multiple inheritance, operator overloading, pointers, memory management). Java was a language that was designed to be easy to program in. Often times, with the speed of today's computers, using Java is just as fast as C++.

I think the key factor in designing a program is picking the right language for the job. There is no one right language for everything so don't think there is.

As for (x y +), that's postfix notation. Writing something as (+ x y) is prefix notation. What we're used to (x + y) is called infix notation. Postfix and prefix are easy to parse which is why some languages (namely, LISP) as well as some calculators (HP's) use that method for input of mathematical expressions. Postfix is also sometimes referred to as Reverse Polish Notation but I believe that may be a bit derogatory.

Matt

All in all...
 

OK. In review ...

Whatever language we end up with, it seems pretty well established that it'll be one of the following. I present this list in order of my estimation of likelihood.

1. Faster PBASIC
2. Another BASIC dialect
3. Java
4. C
5. C++

Let's compare them.

[P]BASIC:
+Easy to learn, a derivative of one of the oldest computer languages.
-Limiting in that it provides only for sequential programming (arguably a fitting model for some strategies), difficult to program in a structured fashion

Java:
+Object-oriented, maniacally so. Syntactically ideal, inherently prevents many kinds of logic errors. Portable, not too difficult to learn. Already popular.
-Restrictive syntax often complicates coding. Syntactic sugar counts for something.

C:
+Popular, ubiquitously so. Reliable, preposterously fast. Very common in microcontrollers. Enormous base of knowledge.
-Much more difficult than Java and BASIC. Generally compilers don't catch all the dumb errors Java does.

C++:
+Proven to be just about as reliable as C. OOPic like Java. Permits lower-level operations, like pointer operations and memory management. Plenty of syntactic sugar.
-A wee bit slower than C. The most complicated syntax of all four languages. Arguably the most difficult to learn.

As promising as many newer languages -- like Python, this Omnicron, and so forth -- may be, I don't give them any serious consideration as a candidates for FIRST. Plus it's rare to find such languages in embedded packages except, of course, in single-board Linux machines. And those can be expensive.

Re: All in all...
 

Python is new(er)? I thought it was old...since Delphi is based off of it.

The link to Omicron is here: http://www.strandmark.com/omicron.shtml

Re: Re: All in all...
 

Delphi (the programming language) is based off Pascal (it's Object Pascal). It is not based on Python. Python derives elements from a variety of languages but isn't based on anything. Where does this idea that Delphi is based on Python come from? I think Delphi is older than Python.

Matt

Re: Re: Re: All in all...
 

I got Pascal and Python mixed up, sorry about that.

I've seen C# programs on cell phones. Seems to work fine. I haven't seen Java on a cell phone though I hear it works.

I was reading a video game magazine and as it turns out a lot of games that are on cell phones are java based.

Sorry to correct you on this one, but cellphones use the J2ME is used on most cell phones for their applications. You can read on here .

I would remind you that "most" and "all" are not the same thing.

C#, being the Microsoft child that it is, is only on cellphones that have WinCE on it. The other cellphones have their own OS which the mobility of JAVA can conform too.

a Basic X would be great. read THIS.
One possibility i have been thinking about is having a socket where a BasicX24, BS2/BS2SX/BS2P24, OOPIC-C, Atom-24, etc.... could be inserted. These chips are pin for pin compatible and completely interchangable. What about a "real"(assembly programmed) microcontroller and a high level language compiler.
As for a language being too complicated for rookies... I think its complete BS. I RT%M and got aquanted with the control system in about an hour or so. Its not hard. If you know one language its not hard to learn another. I would love a change.

pin for pin compatible doesn't buy much...
 

Pin for Pin compatible doesn't really buy much for you in this environment.

Innovation First has to design a system to work with these different chips. I doubt that they are so compatible that they could each be plugged in and made to work with the same Master CPU code.

As to BasicX -- I have tried it and it is pretty cool. I especially like the multitasking ability. The main drawback as far as I can see is that the 1000 bytes of ram seem like a lot until you actually have a few tasks running. It especially stinks that the BasicX version of the Pbasic Debug command pops stuff onto the task stack. This can be a disaster because a complex debug statement can easily overrun the stack and crash the code.

It would be cool, but it is a bit scary to think about folks having random code crashes due to stack overflows.

Joe J.

Re: pin for pin compatible doesn't buy much...
 

Why wouldn't it work. Please explian.

Tasks and Stacks...
 

Every task has to have a place to store data. As you define new tasks, you also define a stack space.

So far, so good.

But, BasicX is a language for consenting adults, by which I mean that it depends on you to be a adult and to alot enough stack space so that the stack does not overflow.

If you DO overflow the stack, you overwrite the data from another task -- and as likely as not the data overwritten will be a non-trivial byte of data, the program counter for that task for example. This is sort of a disaster. All the more so because I had a problem with Task A and Task B crashed! Very tricky to debug.

The problem is made worse by the fact that the print.debug command pushes data onto the stack, and lots of it. You can have program that is working just fine and the it crashes simply because the number you are trying to display cannot be displayed as "5.30" but has to switch to "5.3333E00"

These kinds of bugs would be very hard for many teams to discover, yet alone repair.

Joe J.

Re: Tasks and Stacks...
 

EEEWWW!! Thats sounds like it could be quite a pain to debug. Maybie BasicX would be a little hard for some teams. That still leaves lots of other options though.

The New RC
 

I doubt it would be in C++ because they would probably give us a RC similar to last years. It would be in C if anything. Does anybody know what the RC is, what the specs are on it, and where docs and incs could be downloaded?

working with many different parallax and ifi items before, they mainly use versions of basic, it seems like next year pbasic will still be able to use but it seems the main language would be basicx, it is capable of have higher storage and also faster reaction times to input sensors, seems like autonomous will be present again.

~Mike

Re: The New RC
 

The old RC has been taken apart and examined by at least one of the engineers from team 111, Wildstang. I believe Dave Flowerday (I apologize if I am mistaken) has made a few posts on this topic, but I can't find them, right now.

The control system is vaguely (not too many really technical details) documented by IFI in the various documents on their website ( www.innovationfirst.com/firstrobotics/ ). So far as I can remember from various sources (if you ask, I can probably dig them up), the BS2sx is just a dumb interface to two PIC chips that handle signal processing, PWM, sensor inputs, etc.

At the FIRST Team Forums, they said that IFI was renovating the entire control system. The meaning of this is up to interpretation, and I doubt that every single FIRST rep said the exact same thing, but I tend to agree with you. I find it highly unlikely that we'd find anything other than C (it's very common in the uC world, it's well-known (most engineers could work their way around the syntax, probably, anyway), and it's nowhere near as convoluted as ASM can be (not that I don't like ASM, mind you).

Anyway, I've probably said too much, not to mention the fact that I've probably said it all before...

Re: Re: The New RC
 

Cool. By "renovating", do you mean that they are massively overhauling the RC unit, making minor changes to the current one, or replacing the RC completely?

from what i have heard they are updating the chip so it has more memory for storage and it looks like the controller may be updated a little but don't expect much...
~Mike

Re: Re: Re: The New RC
 

Heh. Well, that's the question. If I'm not mistaken, there were statements that there will be "a new language" for the control system, and that IFI would be releasing information concerning their changes within the next few weeks (they said late June was unlikely, and July was much more likely), but you know how these kinds of things are with deadlines. :p

I don't think that anyone, besides employees of IFI, knows much about the extent of the renovations.

I've heard from 2 different people that next year there will be more of a plug and play system, less programming more clicking. Obviously this is a rumor and i have no proof or anything, and won't bother claiming, "knowing someone at first" I personally would find this sad though, unless you could code on your own and choose not to use the other system.
-Eric

I see. I sure hope that that rumor is false - it would be a shame. It seems unlikely thought because the FIRST people claimed that they were trying to involve more programming. I guess all we can really do is wait for them to announce it though.

just from what was said at many of the forums, implied that they wanted more autonomous programming, meaning they would need a better language (BasicX) and a larger chip. The plug and play rumor i have heard also and i hope for the games sake that it is false, plug and play would cause the game to be toned down more or less...
~Mike

Exactly.

hey at least someone agrees with me! LoL, well i just hope they leave it where you can program your own bot with your own code... So we all don't seem manufactured on an assembly line to where everyone has the same controls.
~Mike

Yea, i mean, it would be nice for newer teams or teams with less human resources to have drag and drop robot programming, but for everyone else, it would depreciate the entire value of prgramming the robot. Besides, it would cheat inexperienced/lacking teams out of an important learning experience.

On another note, wouldn't it be cool if instead of using the simple 900MHz RF RCs, we could choose our own "RC" CPU and our own prefered programming language as long as it complies with the FIRST standards. You know, like instead of low band RF, they use WiFi or Bluetooth or some other different RF type. If they allowed us that much freedom, we wouldn't even have to bother with the whole, "i hope they add/remove this..." thing.

There is a type of programming called lucky logic, its used with fisher technics and is a good starting programming tool, it lets you drag and drop pics of operations, it helps teach you what order things need to be done in...

The problem with this is that the frequency can be interrupted then by other people, they use the current system so they have control over the robots for if a problem arose, they can be shut down by the officials field side. Also they have it set up so you will not interrupt another robot in another places/on another field... Though it would be nice if we could pick our own language...
~Mike

Well, yea, i mean ofcourse they would come up with some sort of security, but it won't be any less secure than it currently is. What i mean is that they could basically network the robots as devices and they would have an "admin" control or something allowing them to read and send data and whatnot. It could even use a popular protocol such as IPX/SPX.

Well i really doubt the robots would ever be placed on a network type of set up because of the logistics of it, with the current set up any robot can be placed on any comp port and be ran and controlled with out individual set up based on that bot, but how your saying, this would need allot more individual set up and updating through out the event. with this not only would it cost more... but it would also go back to the basis of more volunteers/staff needed.
~Mike

Yea, i know, but it would be pretty cool.

OOOO My favorite topic. I just pray to we get something with interrupts, direct access to processor pins, a lot more speed, floating point math and a Real LCD would be nice. You know things are falling behind, when many teams simply have the RC acting as a slave to an outboard processor. I have said this many times before, but i would like either a BasicAtom, JStamp, OOPIC, or BASICX. Really i have even seen sub $100 386SX class embedded computers. (okay now im just dreaming i know first would never give us that much flexibility.)

Exactly, interrupts are a must. If we get something that has a word size greater than eight bits, floating point math shouldn't be necessary. An LCD would be so sweet, but would probably cost more than FIRST is willing to throughput. But yea, i will be somewhat saddened if the new RC doesn't have more speed and support for some kinda of multi-tasking, be it interrupts or a multi-threaded OS... Linux maybe?? Haha.

I was wondering about this I was reading through my book. Could Innovation First switch from the Basic Stamp quasi-interpretor system to a microcontroller that can use a compiler? That would make everyone happy in this forum. From the people who do not want to leave PBASIC to the people who want to program in something else. The only thing that is really bad about it is that the prices for some compilers are in the hundred of dollars.

Use .NET, doesn't FIRST get it for a fraction of the sales price? [I highly doubt Microsoft gives it away for free, but they might].

Well, if they use a mainstreamed language such as C, they could simply supply a compiler, IDE plugin or whatnot. There are uncountable freeware compilers and a decent selection of IDEs (MS Notepad is the best). They could easily create one, or distribute an OEM compiler made for the distributed hardware.

Actually I am going to use a free C compiler that I got from my book to program the Pic microprocessor. To be honest I know that .NET is a compiler but I thought microprocessors need specially designed compilers. I am pretty new to this though. Can anyone clarify this? I shall start a new thread.

If you want a REAL IDE, use Dev-C++ (REAL free IDE that is). I don't think they'll do that, it'd take away to much time just to get it basically working.

[edit]
Actually, to be on the techy side, .NET is an IDE, not a compiler. I forgot what the compiler is called (IDE just makes it easier to code, compile and such).

Actually the last couple of years Microsoft HAS given FIRST teams a free copy of Visual Studio.

And it's not all that expensive for schools anyway. With the MSDN AA for High Schools program a high school can get Visual Studio for $399 and install it on all the lab computers, all the faculty computers and all the students who are taking programming courses can install it on their home computers at no additional cost. http://www.msdnaa.net/hsmember/ for more information.

PS: Yes I do work for Microsoft but I thought this was a good deal when I was a high school computer teacher too.

I didn't know....I didn't think they did though, but it's sweet that they do.

Only thing about that is that what happens when your school (and city) is in debt? [darn this city of mine].

What the heck?

The .NET tools we get from Microsoft (through FIRST) have nothing to do with programming the robot, at all. Also, I'm willing to bet that Microsoft donates all of their software to FIRST, free of charge. Just like the tobacco and alcohol industries, Microsoft's best strategy is to "hook 'em when they're young," and for the most part, we're pretty young.

He's referring to the fact that Parallax is forcing us all to stay in the dark ages by using a closed (mileage / definitions may vary) tokenizer, which uses one of the most limited embeded system programming language in the world. If we had access to the Basic Stamp's assembly language level, there'd be a lot less of a problem, fundamentally, with using a Basic Stamp as the programming interface to the control system.

<rant type="irritable">
As a personal opinion, Parallax seems to be taking a typically Microsoft-esque approach to the marketing of their microcontroller series of products. They inflate the price of a low-quality product, and sell it to people who can't be bothered to learn about the intricasies of the system they're using.

Sure, it's really convenient for a hobbiest to be able to pick up a BS2 for less than $100, and be able to program it using a computer's serial port with a very rudimentary programming language. I will admit that there's a lot to say for "ease of use" features, but I can't see how they can possibly justify charging $50 for a hacked up bunch of components (the BS1 and BS2 use a PIC16C57, which you can get for around $3, and the BS2sx uses a Scenix SX28AC, which you can order from Digikey for less than $5). When you pay them $50 (for one of their "lower-end" microcontrollers, as the BS2p24 and p40 go for $80 and $100, respectively), you're paying for two things, basically: 1) $10, maybe $15 worth of actual electronic components, and B) anywhere from $35 to $90 for the privelige to use PBASIC (barf). They might have put enough programming labor into making the best tokenizer in the known universe, but that doesn't really impress me.

At least Microsoft doesn't go out of their way to try to convince you that they built your entire computer from scratch...
</rant>

Sorry about that. I'm irritated.

If what I've heard is correct, we won't have to deal with Parallax anymore, after this year....

And after that post, someone corrected me, and I said Ok.

the tokenizer.dll is very horid, but it also gets the job done when needed....look at rbbayer's programs. Some use the tokenizer.dll (atleast 1 of them).

GOOD! How about some cheap little 386s instead?

Microprocessors need compilers to generate machine language binaries from source, per architecture (the x86 standard is a good example of an architecture, as there are many manufacturers of CPUs which all are (more or less) compatible, binary-wise). The same goes for microcontrollers. The Scenix microcontroller mentioned in my previous post has a free C compiler that you can download from the internet. Microchip provides MPLAB and MPASM as an umbrella C / ASM IDE and an assembler, respectively. There's a program named IC-PROG which provides assembling functions for many different microcontrollers / microprocessors.

Google is very useful, with regard to much of what I just said.

I am familiar with the functionality of the Parallax tokenizer, and I would like to take a bit of time to personally thank Rob Bayer, and everyone who has contributed to his software (I'm thinking Joe Ross, but I'm not absolutely certain) for all of their hard work.

Me to...I am not saying I dispise them, I am not saying I don't like their work (well, Rob's anyways...I never seen much of anyone else's). I give them all the credit for what they've done to the FIRST community period.

Man I give anyone kudos who understands this stuff. Basic itself I can understand fairly well but past that my jaw just drops because of all those numbers. Thanks Fotoplasma that clarrified it for me. This forum also help me a lot. If I ever have a question about something there is usually something on it here. Now on to learn C then C++ then C+++.

C+++ isn't out yet.....but by the time FIRST ends, it probably will ;)

[If it is, then please show me....because I'd like to learn it. And I'M NOT FLAMING FIRST.......just so that no one jumps on me again]

Hehe! You're very welcome! And by the way, I'm pretty sure it'd be "(C++)++", or something like that. Definitely not C#, though. :p

What about C<<2?

According to the guys who designed C# it is intended to be (C++)++. Picture two plus signs on top of two plus signs.

Honestly, I can see how this can be. Isn't it true though that it is not a very good language (don't take me for that statement, I just read it.)?

Do you mean C++ or C#? C++ is not a very good language. C# is an outstanding language. How good is C#? It is so good that a bunch of Microsoft hating, Linux loving developers are creating an open source compiler for C#. C# is so good that the Java people are borrowing features from C# for a future version of Java. C# is probably the best language I know of. Of course I've only programmed professionally in about 10 languages and played with a few more.

You cannot directly compare any language like that, it depends on the situation and you cannot outright say one is horrible and the other is fantastic. For example FORTRAN will blow away most languages in math crunching, even C#. But C++ can devastate VB in efficency when used properly. It's not as simple as one is good and one is bad.

Well it's not simple but I think that you can say that some languages are bad. At least on a reletive scale. When one compares OOP languages for general programming they can pretty reasonably say that Java and C# are much better then C++. Both Java and C# correct major problems with C++ and make for safer programming.

And performance often depends more on the unerlying runtime and associated libraries then on the language itself. FOr example, a lot of the really graet mathamatical things that people do with FORTRAN are do more to special libraries that have been developed for use with it then the language itself. Plus there are special purpose additions to the langauge for array processors that have been added to FORTRAN largely for historical reasons (math guys like FORTRAN) then necessaty. IF the same extensions were added to other languages they would be faster too.

Take a look at other languages as well. The JVM is slow. Someone came out with a much faster one and Sun sued the company that made it and forced them off the market. IF that hadn't happened maybe Java performance would be bettter. And the performance of VB improved greatly when the unerlying platform was upgraded to .NET. So I would not use performance as the key to what is a good language.

What you look it is things like being type safe. Like having syntax that makes it easy to create the kind of programming structures you want. And things that are basic to the language.

Im getting antsy. I just wish they would go ahead and tell us.

I hope it sticks with PBASIC though honestly....or else my whole project will be a waste of time (and HD space).

Don't bet on it...

You got some insider scoop? (j/p).

I don't really see why not....every programmer that's been in FIRST for 1 year knows it, and every new programmer can catch on pretty fast basically.

I'd be better, because then mentors and whatnot don't have to teach every programmer a new language. If they have no internet, then they're basically screwed then.

I've been told that the new system will have all of the same functionality as the PBASIC interface.

Cool. I hope it does. Maybe it'll be ZBASIC? (lol, that'd be scary if it was).

Java and C# are not inherently better than C++. Anyone who told you as such doesn't know what they're talking about. Java, C#, and C++ all have their various advantages. Java is very good at being cross platform (much more so than C# contrary to what Microsoft would have you believe). C# is very good at Windows development (even if it isn't particularly mature). C++ is very good for large projects that require speed, low memory requirements, or device level programming.

Basically, it comes down to using the correct tool for the job. Sometimes C++ is correct, sometimes it's Java or C#. Other times it's assembly (in fact, I'm starting a project at work with assembly as soon as the developer's kit arrives). Sometimes you need to use straight C or possibly Perl or Lisp. There is no one programming language that is better than the others.

Matt

It also depends on what you are more comfortable with. Like the debate between OpenGL vs DirectX or the Win32 vs MFC. Arguments are fine, but none are the #1 answer. Both have pro's and con's, just like everything else. If you're making a game, use what you feel more comfortable with. Making an IDE? Use whatever you feel comfortable with. It's like FIRST, this year there were debates in every team probably about which kind of bot to build. Some said Stacker, some said pusher, and probably other types were brought up.

>> Sorry <<: I had to use the FIRST comparison, it kinda cleared up what I was saying.

One thing said above that is true is "it depends on ..." who's writing, and what is being programmed. It also depends on the hardware in some cases.

I quickly scanned the thread, but don't see any mention of the Javelin Stamp - "A 24 pin processor programmed with a subset of the Sun Microsystems Java language", as they say on the Parallax.com site.

This means Stamps (read familiar-to-IFI processor) can talk in PBasic or Java. This might rule out APL or COBOL as possible languages for next year, as well as Forth.