![]() |
BasicX uP for next year
what would you think of havinga basicX microcontroller in place of a Basic Stamp for next year. It is just as easily programmable with a simple BASIC instruction set . Its is much faster, has greater math capabilitues including signed variables, a real time clock, interrupts 400bytes of ram(as opposed to 26) and built in supporp for trig. It would not requre much in the way of redesigning the Robot controller, in fact i THINK it may be pin for pin compatible with the Basic Stamp.
[edit] here is a comparison with the Basic stamp 2 SX microcontroller http://www.basicx.com/Products/BX-24/bx24compare.htm |
Probably, but that'd require FIRST to have to update it, which they probably won't do, considering they're FIRST.
pBasic 2.5 was pretty simple... i don't think you'd want anything simpler than that. |
its really no simpler or harder. its just much more powerful. In fact motst of the code syntax is the same
|
I like the whole real time clock idea in there :)
|
The difficulty in proggramming is another challenge that a team must face, making the language easier takes away from that challenge. Our teams are supposed to overcome these hardships and thrive in them. (whether this was intended or not is questionable, but that isn't the point) We should take these difficult situations and throw them into the face of the creators, and say "look, we have conquered your efficiency and complexity problems, what do you want us to do now?".
or something like that. the clock thing would be nice if they intend us to do a more complex autonomous program next year, though. |
We had a similar discussion on this a while back. I was pushing for the JStamp at the time. Lately, I've been more interested in the BasicATOM Pro.
The biggest limitation is the relationship FIRST has with Parallax. Parallax is, in fact, a major sponsor of FIRST, so there's no good reason to dump them. The Javelin Stamp is the only realistic replacement. I find it to be a very 'dirty' and inefficient design, though. The simplicity of java hardware in the JStamp is much preferable, in my opinion. Either way, java creates a somewhat overly complex structure for the fairly simple operation of controlling a FIRST-level robot. My wish list for the current control system is: 1. More RAM (variable space) 32 bytes (26 usable for variables) is very tight when creating complex control algorithms. Scratch pad works, but it far less intuitive and makes the code much less readable. Same with EEPROM. 2. Trig functions Makes ultra complex designs much easier. It's hard enough to write the algorithms WITH the trig functions. Adam |
the jstamp would be jsut as good. what about a bs2p24
|
Quote:
It'd probably be easier for IFI to switch to a 2p, rather than the BasicX, but the amount of improvement of such a transition, as compared to the energy put into redesigning the system (however slightly) would probably not be worth thier effort. Basic Stamps are very common and extremely simple to program (which is the main reason why most robotics team programmers both love and hate them). The way I see it, starting kids off with PBASIC, on a BS2, is a great way to get them interested and involved in [embeded systems] programming (I bought a 2p24 and a 2p40 recently, and am now interested in PIC C and ASM). PBASIC is almost offensively simple, but for a newbie, it's just easy enough to understand, after reading a few pages of documentation, and looking at the sample code. You can jump in, edit the default code a little, and run it within seconds, and know exactly what you've done (for the most part), without having to know a thing about OOP, compilers, or even the computer you're working on. Realistically, I doubt we'll see any major changes from IFI, concerning the control system, for a while. |
I have to agree with FotoPlasma
Although for many of you advanced programmers pbasic is rediculously simple to use, for someone with no programming experience its the perfect language. I had absolutely no experience programming before I started, I had never even looked at a program in code form prior to this. But I decided I wanted to program and as simple as the task may seem, it was quite an accomplishment for me to create my own code and learn how to use this simple language. In fact after 3 years of robotics, i'm still excited when I learn new commands or am able to improve my old codes. Had the program been in a different language I probably would have decided I didn't have the time to learn the language, nor the money or books to do so. I ask that people concider this, and that every year there are new teams who undoubtebly face the same problem, before jumping to a decision to make the programing language "better".
I would however support a new and 'improved' language if and ONLY if teams could still use the current language and commands. That way they could take the time to learn the new language without loosing time from not being able to program it. |
I threw out the 2p as a suggestion. i really don't know the first thing about the 2p series. The basicX however is pin-for-pin compatible with the BS2SX and would require no reengineering of the robot controller whatsoever. As far as Parallax being a FIRST sponser... well i don't know enough about that to speak. I guess i am frusterated not by the limitations of the basic stamp but more by its simplicity though i respect that the control system needs to be simple enough for those without much programming experience to be able to write programs.
Hey you mentioned you are messinf around with Pic C and ASM. What compiler are you using. i have been thinking about messing w/pics but have not had the time. Quote:
|
Quote:
Microchip (the company who makes the PIC series) maintains various programs pertaining to the PIC series, including an emulator for almost every single PIC model, so you don't even have to own any of the microcontrollers to be able to learn about them, and practically program them. There's one team, around here, who was/is making some PIC controlled "smart-sensors," for use on their robot. I won't go around their back and talk about it without express permission, but what they're doing is very cool. If I get permission soon, I'll respond with more information. <edit> I love spelling mistakes. :( </edit> |
o ic. i was thinking about making some pic-controlled "smart sensors" but never got around to it. maybie next year.
|
Gunn High School, Gunn Robotics Team, GRT, team 192 (heh), made some PCBs with PIC microcontrollers for almost generic use.
Supposedly, all they have to do is reprogram them to have them perform a different function. They're planning on producing a whitepaper on them, later this year. Very cool stuff. |
Quote:
|
Quote:
|
The basic stamp1 has a PIC in it. I believe the BS2SX has a scenix microcontrollerin it.
|
Quote:
|
Quote:
Normally, I would say it's also cheaper this way, but seeing as how I myself have gotten several free samples from Microchip.com, I don't think it would be terribly hard to get either free or cheap processors from them in large quantities. Overall, I think the control system does need to adjust with the times, I just don't think that time has quite come yet. |
Quote:
|
Quote:
|
Quote:
Ultimately, what I would like to see is an interface to completely bypass IFI's microprocessor. That way, they can keep using the Stamp 2SX (or upgrade to a P) and many teams can continue to use it. Then, they provide a way for us to plug in our own microprocessor, of our choosing. It would need 8+ digital i/o and a serial port (and maybe some other stuff). If IFI were to use appropriate buffers, they would be easily able to tell if we blew up the robot controller, or whether it was their problem. This allows teams the flexibility to use a better microprocessor, or at least one that they are more familier with. Now obviously this isn't an easy task, but I think the time would be much better spent then just changing the microprocessor, and keeping the black box attitude. Just the ramblings of a wannabe EE |
Swapping the BSIISX for a BasicX requires no redesign. it is pin for pin compatible with the BS2SX. All they have to do is swap 1 chip. I would like them to go further though. It would be nice to have more I/O options(with buffers) as well as a better display(a VFD or LCD). Poeple are complaining about learning a new system. I think that would be the best part. I like Learning new systems and languages.
|
I agree that the basic stamp chip is getting outdated. With autonomous mode, we overcame some of the problems with timers eventually, but it was a pain. I think we can continue to work with this, but I noticed when working with lots of other teams that sometimes people overthink their functions and make their code super long and use many more variables then they truly need. I think that's mainly the problem, not just the chip. One overcome of the timer problem I noticed with SPAM was for distance to put a switch that gets clicked every however many inches and you can use that so that if boxes stop you or anything happens you'll keep pushing till you go the same distance, I think that overcomes the problems many teams have run into. Maybe more types of sensors (opticals were a great addition last year in my opinion) would make it so robots can do more. Then we might need more variable space, but teams would have a challenge to develop more of a system to work more with the sensors than the timer. There were many methods I've noticed of overcoming some of the issues with the basic stamp chip, and I think we just need to focus more on other methods, that's what FIRST is all about, looking at the challenge and setting off to find a solution, seeing how other teams do it, using that and making a better code the next year. This year they threw us into the deep end of a pool and short circuited many teams *pun intended* but next year we'll know what's coming and in the offseason can breadboard systems and work with them to perform different operations. I think that's a better way then to make it 'simpler coding' because your still challenged and teams are more diverse, and overall makes the competition more interesting.
|
Quote:
|
Quote:
|
We are a rookie team. Programming the basic stamp is well... to basic. I hate the thing with vengence. Its way too slow and has no buffers. Not to mention it has no support for any advanced programming stuff whatsoever. I don't see it as a challenge because its not a challenge. i just see it as letting me spend more of my time doing more programming and less time overcoming language difecencies. The BasicX is simple yet powerful. I don't understand why so many people see a new processor as some sort of taboo.
|
Quote:
|
Don't swtich until major delta can be gained...
I too have a love/hate relationship with Stamp2/Pbasic.
To be honest, I have found work around for most of the stuff that I need to get done... ...but I know that there are much better ways of doing this. I wish that IFI would put out a system that allows for multiple user CPU's -- this would allow for those who wanted to to stay with Stamp2/Pbasic to do so but it would also allow those who are ready for something more to program is C++ on a PowerPC core. Even better, I would like to see IFI come out with something that could be programmed in something like Blocksets from Mat Lab/SimuLink from Mathworks. Bottom line for me is that I think that unless they are going to give us some great new features, IFI should stick with what we have. Joe J. |
Quote:
Also, you can buy a AMD Athlon for $50 including shipping (I just checked pricewatch.com) and there aren't too many teams who can't afford that if it really would help. Which isn't to say I think that allowing teams to plug in their own chip is a good idea, but I wouldn't mind a hardware upgrade. Wouldn't mind it staying the same, either. |
Quote:
I'm quite aware of this, and quite happy with the PBasic. My point is more advanced (electrically) teams would have an advantage in programming in more sophisticated languages on more advanced hardware, i.e. more advanced/accurate/capable autonomous mode, more precise controls, (if a robot can gather sensor data at 400 cycles per second on an 850mhz athlon as opposed to the 25-30 cycles persecond of a basic stamp with a heavy program, there is far more sensor data avaliable to process and react upon if it's gathered at a faster rate), and the like. This wouldn't be too fair to not-so-electrically-inclined teams who stick with the default hardware, incapable of operating with advanced hardware. |
The argument that a faster processor wouldn't be "fair" really doesn't make any sense to me. Think abou it: why doesn't FIRST just ship everyone a standard set of robot blueprints that they are required to use so that those teams without MechEngs aren't disadvantaged?
In my opinion, the number one reason not to change is that there is no need to. Just look at teams like WildStang, who consistently push the control system to its limits and then past them. Until somebody can show that something absolutely can't be done without a new processor, I see no reason to re-do a control system that is considered one of the best in the industry. Would you rather we switched to normal RC equipment? :D --Rob |
Quote:
If all teams were shipped a set of blueprints I'd have no problem. However, the suggestion of this thread implies it would simply be the authorization of custom control interfaces for teams which can build them, which in my opinion, wouldn't be fair. If it were standard in the kit, and all teams were capable of building it as an option, I think it would be cool. Quote:
|
| All times are GMT -5. The time now is 01:31. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi