|
|
|
![]() |
|
|||||||
|
||||||||
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
Possible Configuration to keep things cheap
Posted by Thomas A. Frank, Engineer on team #121, The Islanders/Rhode Warrior, from Middletown (RI) High School and Naval Undersea Warfare Center.
Posted on 5/23/99 11:11 AM MST Hello All; Maybe the way to do this is with a PC104 card stack. That way, FIRST can get a processor card, a combined A/D and D/A card, and a power supply card, stick them together, and they have a complete controller. The only card they need to make is the serial to PWM card, and that would be very cheap, not to mention highly saleable to the outside world. All commercial off the shelf, no development time at all, and the hardware is cheap enough that there's a good chance the manufacturers could be pursuaded to donate the equipment - especially if the manufacturer gets the rights to the PWM output card. This way, we get a 386/486 class computer, 16 A/D channels, interrupts, real time clocks, and all the rest of the goodies we want. In one off quantities, this would be about a $400-600 setup depending on processor. In production quantities, it would be cheaper. That's probably less than the controllers cost now. Tom Frank |
|
#2
|
|||
|
|||
|
Re: Possible Configuration to keep things cheap
Posted by Mike King, Other on team #88, TJē, from Bridgewater Raynham and Johnson & Johnson Professional.
Posted on 5/23/99 3:35 PM MST In Reply to: Possible Configuration to keep things cheap posted by Thomas A. Frank on 5/23/99 11:11 AM MST: : In one off quantities, this would be about a $400-600 setup depending on processor. In : production quantities, it would be cheaper. : That's probably less than the controllers cost now. : Tom Frank Not that this an indicator, but I remember putting a 500 dollar deposit on the RNET's to 'borrow' them. So I'm betting that your right, and it is cheaper. Mike |
|
#3
|
|||
|
|||
|
Re: Possible Configuration to keep things cheap
Posted by Rick Berube, Engineer on team #121, Rhode Warriors, from Middletown H.S..
Posted on 5/23/99 8:20 PM MST In Reply to: Possible Configuration to keep things cheap posted by Thomas A. Frank on 5/23/99 11:11 AM MST: Certainly some powerful hardware, but what about the software development environment? After all, that's really what we're talking about here right? More processing power, multi-tasking, networking, timers and interrupts. Its all just a bag of buzz words without the software support required to tap into it. One thing I think we're all taking for granted here is the simplistic development environment that the Basic Stamp provided. I submit that such ease for software development is still required. Six weeks remember! How many of you software types had access to the hardware throughout the six weeks? Early in the six weeks? Let's face it, the software will always be one of the last things completed on your 'bot unless you used the default program. 'Bit-heads' want to be able to leverage a set of tested and reliable rtns not re-invent the wheel at crunch time. Even teams with veteran software support do not want to start from ground zero given this schedule (don't take my word for it, ask them!). Consider NetMedia Inc and their BasicX products (http://www.basicx.com). If any of you opened the free issue of the robotic magazine supplied in Florida, you may recognize the name. They offer much of what is being asked for here. More speed (this RISC processor provide 16-30 times the processing power of the Stamp chip (@ 7.37 Mhz no less!), multi-tasking, interrupts, RTC, timers, semaphores, floating pt. math (hey, negative numbers too!), EEPROM (SPI)support, networking support, pin I/O. And BasicX's Basic, was modeled after Microsoft's Visual Basic. They also provide a very similar PC based development environment we rely upon today for the Basic Stamp. Joe here's an excerpt for you: 'Tasks are timeshared on a first-come first-served basis, except for tasks triggered by hardware interrupts. All tasks have the same priority, although if a task is critically important, it can be locked (see procedure LockTask), which means the task itself can decide when to relinquish control of the processor. Under normal conditions, tasks are switched every clock tick. The tick frequency is 512 Hz, which means that if you had 16 tasks all running in an infinite loop, each task would run 32 times a second. Well-designed and cooperating tasks pass on their extra processing time to other tasks if they're in a loop waiting for data or events.' Don't expect to get anywhere near 10Mbs with RF ethernet either. If you assume 4-5 Mbs as a reasonable number, {5Mbs/12 robots ~ 400 Kbs/robot}, more than enough! With some glue-logic (FPGA?) to interface the BasicX high-speed serial interface (400-500Kb) to a PCMCIA interface, I'm sure we could realize the inexpensive network support we all want. Thoughts? Comments? |
|
#4
|
|||
|
|||
|
seems great, now find a board...
Posted by Joe Johnson.
Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems. Posted on 5/24/99 7:39 PM MST In Reply to: Re: Possible Configuration to keep things cheap posted by Rick Berube on 5/23/99 8:20 PM MST: Went to the BasicX.com site. WOW! It is not everything, but it is a lot. Faster, Multitasking, Floating Point Math, other goodies. One particularly good thing would be the internal networking support. If nothing else, FIRST could slap two of these on one board (like they do for the STAMP2's now) and have the entire MASTER/SLAVE communications be transparent to us on the SLAVE side -- no more wasting valuable loop time waiting for serial data to arrive from the MASTER CPU ![]() I have not downloaded the complete documentation (yet :-), but it seems to be a real step in the right direction. I wonder if BasicX would get on board as far as allowing FIRST to distribute the development software? There is a long way to go before picking this particular chip. One thing I would still like is to have the entire controller available for sale. If FIRST were to use this chip, how would they manage to make it do everything we what but still be available for sale. Does anyone know of a board that uses this CPU? Can it be adapted for our uses? I could definitely get behind something based on this chip. It definitely address the code development concern. Joe J. P.S. If FIRST wanted to get more power still, they could allow us to have a Robot Area Network of as many of these babies as we could want. We could effectively get N times the CPU power by having N CPU's onboard all communicating via the onboard RS-485 support. Could be pretty great. |
|
#5
|
|||
|
|||
|
seems great, now find a board...
Posted by Joe Johnson.
Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems. Posted on 5/24/99 7:39 PM MST In Reply to: Re: Possible Configuration to keep things cheap posted by Rick Berube on 5/23/99 8:20 PM MST: Went to the BasicX.com site. WOW! It is not everything, but it is a lot. Faster, Multitasking, Floating Point Math, other goodies. One particularly good thing would be the internal networking support. If nothing else, FIRST could slap two of these on one board (like they do for the STAMP2's now) and have the entire MASTER/SLAVE communications be transparent to us on the SLAVE side -- no more wasting valuable loop time waiting for serial data to arrive from the MASTER CPU ![]() I have not downloaded the complete documentation (yet :-), but it seems to be a real step in the right direction. I wonder if BasicX would get on board as far as allowing FIRST to distribute the development software? There is a long way to go before picking this particular chip. One thing I would still like is to have the entire controller available for sale. If FIRST were to use this chip, how would they manage to make it do everything we what but still be available for sale. Does anyone know of a board that uses this CPU? Can it be adapted for our uses? I could definitely get behind something based on this chip. It definitely address the code development concern. Joe J. P.S. If FIRST wanted to get more power still, they could allow us to have a Robot Area Network of as many of these babies as we could want. We could effectively get N times the CPU power by having N CPU's onboard all communicating via the onboard RS-485 support. Could be pretty great. |
|
#6
|
|||
|
|||
|
Wait a minute...
Posted by Joe Johnson.
Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems. Posted on 5/25/99 5:12 AM MST In Reply to: seems great, now find a board... posted by Joe Johnson on 5/24/99 7:39 PM MST: I was all excited last night about the BasicX chip, but then I slept on it. I have this basic question: Are we willing to give up real time interupts in order to get easy programming? I may have missed it, but I don't see any way to have a task run immediately upon some external switch closing. This means that pulse counting is not really an option. This gets us away from an easy way of computing wheel speed, one of my favorite future features. So, unless some new sensors allow for us to count pulses some other way, I suppose we keep looking. Joe J. |
|
#7
|
|||
|
|||
|
Rest assured...
Posted by Rick Berube.
Engineer on team #121, Rhode Warriors, from Middletown H.S.. Posted on 5/25/99 10:38 PM MST In Reply to: Wait a minute... posted by Joe Johnson on 5/25/99 5:12 AM MST: Based on the time of your posting, I'd say this either keep you up all night or woke you from a sound sleep! I don't recall mentioning that you'd have to give up interrupts? I wouldn't suggest a solution without interrupts (http://www.chiefdelphi.com/wwwboard/messages/2207.html After all we're after a better world through technology here, right. Last time I looked even RISC controllers had interrupts because no one's discovered anything better. To put your mind at ease, here are some excerpts pertaining to the BasicX API from the NetMedia documents. You really should download and review them for yourself. It's quite an impressive chip. I'm not saying there won't be issues/limitations, however it should be considered before being dismissed. Syntax Call WaitForInterrupt(InterruptType) Arguments Item Type Direction Description InterruptType Byte Input Interrupt type. See below for allowable values. Allowable values for InterruptType: bxComparatorToggle = 0 Comparator toggle state bxComparatorFallingEdge = 2 Falling edge of comparator bxComparatorRisingEdge = 3 Rising edge of comparator bxPinLow = 16 Low level on pin 13 bxPinFallingEdge = 24 Falling edge on pin 13 bxPinRisingEdge = 28 Rising edge on pin 13 Description WaitForInterrupt allows a task to respond immediately to a critical event from the outside world. This procedure gives you access to hardware interrupts built into the BasicX chip. WaitForInterrupt blocks the calling task until an external event happens. When the event occurs, the task is scheduled to be run immediately. The task has priority, even if another task is running and locked (see procedure LockTask). Warning If no external event is generated, the calling task could wait indefinitely. Example ' Wait for rising edge on comparator. Call WaitForInterrupt( bxComparatorRisingEdge ) System library The BasicX operating system provides a library of system calls in the following categories: Math functions Abs Absolute value ACos Arc cosine ASin Arc sine Atn Arc tangent Cos Cosine Exp Raises e to a specified power Exp10 Raises 10 to a specified power Log Natural log Log10 Log base 10 Pow Raises an operand to a specified power Sin Sine Sqr Square root Tan Tangent String functions Asc Returns the ASCII code of a character Chr Converts a numeric value to a character Len Returns the length of a string Mid Copies a substring Memory-related functions BlockMove Copies a block of data from one RAM location to another GetEEPROM Reads data from EEPROM GetXIO Reads data from extended I/O GetXRAM Reads data from XRAM MemAddress Returns the address of a variable or array MemAddressU Returns the address of a variable or array PersistentPeek Reads a byte from EEPROM PersistentPoke Writes a byte to EEPROM PutEEPROM Writes data to EEPROM PutXIO Writes data to extended I/O PutXRAM Writes data to XRAM RAMpeek Reads a byte from RAM RAMpoke Writes a byte to RAM SerialNumber Returns the unique serial number of a BasicX chip Queues GetQueue Reads data from a queue OpenQueue Defines an array as a queue PeekQueue Looks at queue data without actually removing any data PutQueue Writes data to a queue PutQueueStr Writes a string to a queue StatusQueue Determines if a queue has data available for reading Tasking CallTask Starts a task CPUsleep Puts the processor in various low-power modes FirstTime Determines whether the program has ever been run since download LockTask Locks the task and discourages other tasks from running OpenWatchdog Starts the watchdog timer ResetProcessor Resets and reboots the processor Semaphore Coordinates the sharing of data between tasks Sleep Pauses task and allows other tasks to run TaskIsLocked Determine whether a task is locked UnlockTask Unlocks a task WaitForInterrupt Allows a task to respond to a hardware interrupt Watchdog Resets the watchdog timer Type conversions CByte Convert to Byte CInt Convert to Integer CLng Convert to Long CSng Convert to floating point (single) CuInt Convert to UnsignedInteger CuLng Convert to UnsignedLong Fix Truncates a floating point value FixB Truncates a floating point value, converts to Byte FixI Truncates a floating point value, converts to Integer FixL Truncates a floating point value, converts to Long FixUI Truncates a floating point value, converts to UnsignedInteger FixUL Truncates a floating point value, converts to UnsignedLong Real time clock GetDate Returns the date GetDayOfWeek Returns the day of week GetTime Returns the time of day GetTimestamp Returns the date and time of day PutDate Sets the date PutTime Sets the time of day PutTimestamp Sets the date, day of week and time of day Timer Returns floating point seconds since midnight Pin I/O DACpin Generates a pseudo-analog voltage at an output pin GetPin Returns the logic level of an input pin InputCapture Records a pulse train on the input capture pin OutputCapture Sends a pulse train to the output capture pin PulseIn Measures pulse width on an input pin PulseOut Sends a pulse to an output pin PutPin Configures a pin to several input or output states RCtime Measures the time delay until a pin transition occurs Communications GetNetwork Reads data from a remote RAM location GetNetworkP Reads data from a remote EEPROM location OpenCom Opens an RS-232 serial port OpenNetwork Opens the network OpenSPI Opens SPI communications PutNetwork Sends data to a remote RAM location PutNetworkP Sends data to a remote EEPROM location PutNetworkPacket Sends a special packet over the network PutNetworkQueue Sends data to a remote queue SPIcmd SPI communications |
|
#8
|
|||
|
|||
|
What are we waiting for?
Posted by Joe Johnson.   [PICTURE: SAME | NEW | HELP]
Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems. Posted on 5/26/99 7:31 PM MST In Reply to: Rest assured... posted by Rick Berube on 5/25/99 10:38 PM MST: I am sold. In fact, I have more or less made up my mind that I want to try using this chip in my real job. Eric, what do you have to say about this proposal? Joe J. |
|
#9
|
|||
|
|||
|
Re: Possible Configuration to keep things cheap
Posted by Joe Ross.   [PICTURE: SAME | NEW | HELP]
Student on team #330, Beach Bot II, from Hope Chapel Academy and NASA/JPL, NASA ARC. Posted on 5/26/99 5:54 PM MST In Reply to: Re: Possible Configuration to keep things cheap posted by Rick Berube on 5/23/99 8:20 PM MST: I think that one thing that we all need to remember while we are all drooling over these new controller options is the rookie teams and those without a software engineer who can devote his entire life to the team. Whatever device FIRST comes up with should have a faster chip and also someway to send feedback to the driver station. Beyond this you are getting into a teritory that only probably 20% of the teams are going to utilize. All this will do is to widen the gap between the top teams and the teams whithout as much resources. One of the advantages to the control system we have now was that great drivers could make up for just about any cool programming trick another team could design. Our team found that because our drivers were so good we only had make a few minor changes to the program and other than that our drivers compensated for any weakness our program may have had. If you start adding all kinds of cool gadgets that will eventually lead to autonomous control, some teams are going to be left behind. I like the idea of giving the teams the control system (or part of it) early. Especially this year (or whenever they change it) some teams are going to need their 6 weeks to learn how to control their robot. By giving the teams the control system early, FIRST might also encourage early registration. This would help make planning the events a lot easier. The downside is that FIRST would have to finish the control system earlier. But then, they could enlist the help of the teams that got the system early to help them work out the bugs. I know that FIRST is doing the best job they can, I just hope our expectations aren't a little too high. Joe Ross Team 330 speed-controller blower-upper extraordinaire |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Qotw [01-05-03]: top 5 things in your mind... | Ken Leung | Rumor Mill | 37 | 13-02-2003 00:45 |
| shirts and things | illumanat'i | General Forum | 15 | 15-01-2003 16:31 |
| a few minor things... | Brandon Martus | Announcements | 0 | 03-01-2003 23:39 |
| A hint of things to come... | archiver | 2001 | 0 | 24-06-2002 01:12 |
| A few things | RebAl | CD Forum Support | 2 | 18-04-2002 18:34 |