To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.nxtOpen lugnet.robotics.nxt in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / NXT / 506
505  |  507
Subject: 
Re: Improving the firmware?
Newsgroups: 
lugnet.robotics.nxt
Date: 
Tue, 20 Feb 2007 12:58:03 GMT
Viewed: 
16151 times
  
In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote:
However, a kludge is available. Somewhat like the kludge used to make
3rd party sensors look like the ultrasonic sensor so that they can be
used without modifying firmware. You could "hijack" an existing opcode
and have it serve dual purpose.

The "draw line on NXT LCD screen" opcode might be a good one to choose
since it has four parameters (i.e. the "from" and "to" points). You
could change the implementation of this opcode so that if the first
parameter is negative then it indicates that this is a special user
written function where this parameter now contains the new function
type. This would leave three parameters for your new opcode/function.

It's a good plan, but I don't think that's the right command.  If someone was
calculating the position of a line to draw it may well start or end off-screen
in the negative values.

How about hijacking the FileOpen command, and apply URL-type interpretation to
the string?  (Or any command with a string input, but that seems the most
obvious).

Basic file names would work as normal, accessing the local file store, but you
could apply extra parsing.  If someone was really clever with the Bluetooth they
could make "http://..." URLs work, so for our purposes (and to remain
compatible) we'll define our own service, "nxt://...".  You'd give a command and
a parameter list, e.g.:

"nxt://DoStuff?x=1&y=2"

Return values may be more difficult.  A strict follow-on from this approach
would need you to provide results in memory, then read from memory when you do a
FileRead, finally freeing it when you close the file handle.
You could return with a value immediately, but then that could be
mis-interpreted as a file handle.  You could say all responses will be negative,
but that would stop you using it for mathematical operations.

Another offshoot of this would be to provide extra parameters into existing
file-based functions, for example for DrawGraphic you could add "?mode=xor" to
the end of the filename, and vary the speed of sound replays.

Any opinions?

Jason R



Message is in Reply To:
  RE: Improving the firmware?
 
David Wallace wrote on Tuesday, January 23, 2007 7:34 PM: (...) This is an opportunity for the open source community to improve the firmware. Enhanced firmware does not need to have any dependency on the LEGO or NI development teams. The challenge (...) (18 years ago, 24-Jan-07, to lugnet.robotics.nxt)

14 Messages in This Thread:






Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in NXT programmable brick

 
Verified and Trusted Team of Hackers
7 hours ago
Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR