y is parallax stil using PBASIC
primitive lower life form ?
switch to C++, Java, VB
i h8 labels
i h8 labels
If you are going to complain about something, at least take the time to completely spell out your words…
Also, think about what you are saying, in order for a language to run on a chip, it has to be compiled down to machine code. Languages such as VB and java require an interpreter to run, and, without a lot of effort cannot be compiled to machine code.
Lets try to keep the posts mainly positive.
Thanks
Tom Schindler
Word to Tom Schindler.
If you’re so against PBASIC, I’d like to see you write all of your robot code in PIC assembly… PBASIC may be unnecessarilly uncool, but I don’t think it’s really supposed to be easy. If it were easy, everyone would do it.
The way I see it, PBASIC’s faults are just another design challenge. We can’t use certain things/materials/mechanisms on the robot, physically, for no other reason but to challenge us to do more with less, I believe. The same goes for the price limit, limits on the use/amount of pneumatics, etc.
I’m not too coherent right now, but I think I’m making myself clear.
We’ve all had our little frustrating times with PBASIC, but I think it’s a good thing…
Get a grip…
please tell me you arent one of those ppl who thinks we should put Linux, C++, or some other overkilll programming language on the RC. Pbasic is the easiest and best solution for FIRST, you dont need a degree in comp Sci or have to be an “l33t HaX0r” to use.
and i agree completly in Fotoplasma, the language is yet another design complexity… it may be frustrating but it’s another challenge.
lol, you think Pbasic is bad… you should see the language they use for actual industrial control… it makes the lego Mindstorm language look like Assembly shudder
if you have a better solution then make your own RC
~Pyro
*Originally posted by maDGag *
**y is parallax stil using PBASICprimitive lower life form ?
switch to C++, Java, VB
i h8 labels **
maDGag,
What exactly is your point…it’s just another programming language.
Are you complaining about the limits of the language…well, have you ever thought about the resources available on a tiny pic micro-controller? What, do you expect virtual memory?
Is it too “difficult” to deal with?
Well, that’s the way life is right? We have to get through it with what we have available to us…Engineering solutions to problems is no different.
The limits of the STAMP only require you to be more intelligent about your approach. It makes you think…which is a great big part of what FIRST is all about anyways…right?
-Quentin
go download the newest version, then you dont have to worry about labels
Well, Parallax did release a java based interpretor (javelin or something) but it’s not for the RC we have.
But yeah, "well, have you ever thought about the resources available on a tiny pic micro-controller? " The Robot Controller from last year has a PBASIC 133MHZ processor which is, sadly enough, faster than one of my computers which run’s Linux (Redhat 8) with X. The new RC for this year might have a processor that’s even faster (PBASIC 2.5 vs 2.0).
*Originally posted by rwaliany *
**
But yeah, "well, have you ever thought about the resources available on a tiny pic micro-controller? " The Robot Controller from last year has a PBASIC 133MHZ processor which is, sadly enough, faster than one of my computers which run’s Linux (Redhat 8) with X. The new RC for this year might have a processor that’s even faster (PBASIC 2.5 vs 2.0). **
Sorry, but last year’s was 50Mhz. Same this year.
I could have sworn I read 133MHZ in the Control Systems Manual or something. Oh well, if it’s 50mhz then it runs at the same speed as that linux computer.
The Basic Stamp 2sx (the BS in the RC) is officially clocked at 50MHz.
There’re two other processors in the RC, (PICs, if I recall correctly) so there might be some confusion about total processing power, or whatever.
I can’t seem to find the schematics. I had a sheet with all the information about the three processors in the RC and the basic packets/communication messages.
*Originally posted by rwaliany *
**The Robot Controller from last year has a PBASIC 133MHZ processor which is, sadly enough, faster than one of my computers which run’s Linux (Redhat 8) with X. The new RC for this year might have a processor that’s even faster (PBASIC 2.5 vs 2.0). **
OK, well as someone else already pointed out the Stamp does not run at 133MHz, but even if it did it wouldn’t matter. You’ve fallen into the “megahertz myth” trap here. What that means is that you can’t compare two different processors (Pentium versus BASIC Stamp) even if they run at the same speed. The reason for this is that each different type of processor does a completely different amount of work with each tick of the clock. Also remember that the BASIC Stamp (as well as all the other microcontrollers inside the OI/RC) is only an 8 bit processor.
This is exactly why it makes no sense when people compare a 2GHz Pentium to a 1GHz Macintosh and claim that the Mac is slower. It’s apples and oranges.
Also the change from PBASIC 2.0 to 2.5 has nothing to do with the processor. You should be able to use new 2.5 code with an old robot controller, because the tokenizer converts it all down to the same machine instructions anyway.
BTW, it’s been a while since I looked at it, but I believe the other 2 processors in the RC are PIC16c74s.
Im fine w/Pbasic but i do think vit would be cool to at least give the Javelin Stamp a try.
The last I heard from FIRST (this was from Eric about a year and a half ago) was that they were looking at using some other programming language besides PBasic. However, they wanted to make sure that there would always be the option of using PBasic. I don’t know what’s come of it since then.
Matt
I reallt do hope they do persue something else. Its a big change going from mainly C++ Java and PHP to Pbasic.
*Originally posted by Dave Flowerday *
**Also remember that the BASIC Stamp (as well as all the other microcontrollers inside the OI/RC) is only an 8 bit processor.
**
Isn’t the Stamp 16-bit, since it always chews on 16-bits of data at a time? If not, what determines the “bits” of a processor?
*Originally posted by rbayer *
**Isn’t the Stamp 16-bit, since it always chews on 16-bits of data at a time? If not, what determines the “bits” of a processor? **
The Stamp that we’re using is based on a Scenix SX28AC microcontroller which is an 8 bit unit. Typically when someone refers to the “bits” of a processor it is referring to the maximum size of integer that the processor can operate on. What this means is that, at the assembly language level, an 8 bit processor can only perform operations on 8 bit numbers. So the assembly level “add” command on an 8 bit controller can only add 2 8 bit numbers. However, you can still do 16, 32, or whatever bit math by operating on the numbers in 8 bit quantities. So if an 8 bit processor wants to add 2 16 bit numbers, it first adds the lower 8 bits of the two numbers then adds the upper 8 bits of both numbers plus the carry bit from the previous operation. I hope I’m making sense here as I can tell I’m not explaining it very well.
Anyway the bottom line is when the Stamp works with 16 bit values it is really being translated into a series of 8 bit operations inside the microcontroller running the stamp interpreter.
*Originally posted by Rickertsen2 *
**I reallt do hope they do persue something else. Its a big change going from mainly C++ Java and PHP to Pbasic. **
It is? Last I checked, PHP, C++ and Java all had IF / ELSE / GOTO control structures… Besides, programming is 90% about high level logic and 10% about syntax. A good programmer isn’t limited by the language they have in front of them. They can think logically about the problem, come up with a solution, and then translate that solution into whatever syntax they have.
PBasic isn’t bad. At least it’s not raw assembly.
*Originally posted by Dave Flowerday *
**The Stamp that we’re using is based on a Scenix SX28AC microcontroller which is an 8 bit unit. Typically when someone refers to the “bits” of a processor it is referring to the maximum size of integer that the processor can operate on. What this means is that, at the assembly language level, an 8 bit processor can only perform operations on 8 bit numbers. So the assembly level “add” command on an 8 bit controller can only add 2 8 bit numbers. However, you can still do 16, 32, or whatever bit math by operating on the numbers in 8 bit quantities. So if an 8 bit processor wants to add 2 16 bit numbers, it first adds the lower 8 bits of the two numbers then adds the upper 8 bits of both numbers plus the carry bit from the previous operation. I hope I’m making sense here as I can tell I’m not explaining it very well.Anyway the bottom line is when the Stamp works with 16 bit values it is really being translated into a series of 8 bit operations inside the microcontroller running the stamp interpreter. **
Ah, that makes sense.
What would the resultant of this be, does it overflow, whats the actual resultant though in binary?
01001010 10011101 +
11001010 10100101
^^
20010101 01000010
1 00010101 01000010
00010101 01000010
… any ideas? I haven’t had time to look this up. The question always comes up when I’m away from my computer.
Yes, it will overflow. However, as far as I know there is no program-accessible carry bit that will let you know when this happens. Instead, you will just get the last 16 bits back and that first 1 will be lost.