![]() |
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. |
| 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