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

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

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?

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

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.

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

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.

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.

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

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.

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