Subject:
|
Re: Brute Force Brick
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 5 Mar 2004 23:53:14 GMT
|
Viewed:
|
930 times
|
| |
|
|
in lugnet.robotics, Steve Hassenplug wrote:
> > > We've talked about having firmware that
> > > could be compatable with the RCX op-codes,
> >
> > ...you should make it look like an RCX with expanded sensor and
> > motor capabilities to us users. This means, that you should adapt the RCX
> > op-codes as a virtual machine
> That's pretty much what I was thinking.
The question is, if typical teen users can program a nacked microprocessor.
Providing a tasking system is necessary to avoid programming interupt
service routines. Do you know, if the BFB has a timer, that allows to implement
a preemptive tasking system (like the RCX has) ?
If the people at BFB
http://www.hitechnic.com/development_lab.htm
dont like to build an RCX Opcode virtual machine, it would be nice to have
a firmware at least, that provides a tasking system. Then you can use the
Linux GNU gcc, (available for windoze too) if he supports the microprocessor
in the BFB. You must supply the tasking system calls in a linked library.
In this case, the gcc would act as a cross compiler. The BFB should have
a monitor program in the firmware. The monitor program consists of two
parts: the mainprogram and the task(s) in the tasking system.
The mainprogram gets control after power on. The task in the tasking
system allows to send print messages from the gcc BFB bot program.
This should be done via a ring buffer and printed out in a terminal
program, running on a PC. This is, where the UHF interface comes
into play.
Providing the print statement in the BFB is a minimum requirement,
if you dont have a debugger in the firmware. The RCX solves this
problem by introducing the datalog.
The UHF interface is a genious connection between the BFB and
the PC, where you develop the programs. Because you have a
stable connection, regardless, where the bot is.
This allows a steady connection by the monitor program. The
monitor program is running on both sides: on the BFB and the PC.
You can divide the monitor program screen output on the PC into
different sections:
a status line displaying battery voltage and so on.
a scrolled section, where the command interface of the monitor program
takes place.
Of course, building a program, like NQC does, that simply downloads
a file is possible. It would be more nice to do it in the main program
of the monitor program, that is started, after the power is set on on the
BFB.
> load binfile
would be a nice monitor command. Note, it needs support at both sides.
> go
starts the downloaded program. Remember, the print task must be started
too, together with the statusline update. If you implement this, no datalog
is necessary.
On the other hand, RCX datalog output is valuable as input to PC programs,
interpreting the datalog. Remember the spirit.ocx
The print command combined with the lack of a debugger isnt a real obstacle
to real time processing debugging. In real time applications, you cannot set
debugger breakpoints everywhere in the code to find a subsequent error,
because the environment isnt freesed, if the breakpoint occurs.
Think about building a ship autopilot or other general controller applications.
The debugger stops program execution, if he reaches a breakpoint but the
environment process will run on. Its hard or impossible to find the cause of
the error, if he is subsequent.
So you need printout of program information in real time.
I think, the possibilities of an UHF interface are greatfull.
300 Dollars are not too much for it, if the BFB has its own character, that
gives him a place between RCX and HandyBoard. Or above?
Expanding the IO via a serial bus would be nice. Probably the serial
expansion bus could connect multible BFBs in an multiprocessing net?
Greetings
Ralph
|
|
Message has 1 Reply:
 | | Re: Brute Force Brick
|
| (...) The question is: What is the target market? The BFB was made for people who have outgrown an RCX. (...) Yes, that's available on the BFB, not the RCX. (...) true. (...) That's what the UHF is for. Most of the stuff you're talking about here (...) (21 years ago, 8-Mar-04, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
