 | | | | | | |
| |
|
Over the past couple days I have used the IAR Embedded Workbench to implement
some enhancements and bug fixes for the standard NXT firmware.
The bug fixes are as follows:
1. RIC drawing code incorrectly checked the size of the OP_LINE structure for
OP_PIXEL operations making it impossible to use the pixel operation without a
workaround.
2. RIC drawing code left out the case for the OP_CIRCLE operation making it
impossible to use circle operations in RIC files.
3. RIC drawing code was limiting the user arguments to 0xF (16 entries) via a
mask which should have been 0xFF (allowing for 256 entries).
4. Internal IOMapWrite and IOMapRead calls were unnecessarily limited to 64
bytes. This limit has been raised to 800 bytes (which is the number of bytes of
normal and popup display memory).
The enhancements are as follows:
1. New syscall functions
a. IOMapReadByID and IOMapWriteByID. These two syscall functions use a ULONG
module id rather than a module name to read or write to the module IOMAP. This
eliminates the overhead of a FINDFIRSTMODULE call (which does several string
comparisons) and a CLOSEMODULEHANDLE call.
The syscall function ID values are IOMapReadByID = 34, IOMapWriteByID = 35. The
structures for calling these syscall functions are:
TIOMapReadByID struct
Result sbyte
ModuleID long
Offset word
Count word
Buffer byte[]
TIOMapReadByID ends
TIOMapWriteByID struct
Result sbyte
ModuleID long
Offset word
Buffer byte[]
TIOMapWriteByID ends
The module IDs are:
CommandModuleID = 0x00010001
OutputModuleID = 0x00020001
InputModuleID = 0x00030001
ButtonModuleID = 0x00040001
CommModuleID = 0x00050001
IOCtrlModuleID = 0x00060001
SoundModuleID = 0x00080001
LoaderModuleID = 0x00090001
DisplayModuleID = 0x000A0001
LowSpeedModuleID = 0x000B0001
UIModuleID = 0x000C0001
Here are my test results of calling IOMapRead and IOMapReadByID with each test
executing 10000 iterations. Times are in milliseconds:
Test | IOMapRead | IOMapReadByID |
-----------------------|------------|---------------|
UI Module Battery Lvl | 3252 | 1206 |
Loader Module Free Mem | 2408 | 1183 |
-----------------------------------------------------
c. DisplayExecuteFunction. This system call exposes the Display module
function pointer and lets you execute any of the supported drawing functions via
that pointer. The supported functions are
0 DISPLAY_ERASE_ALL()
1 DISPLAY_PIXEL(On, X1, Y1)
2 DISPLAY_HORIZONTAL_LINE(On, X1, Y1, X2)
3 DISPLAY_VERTICAL_LINE(On, X1, Y1, Y2)
4 DISPLAY_CHAR(On, X1, Y1, Y1) (Y1 is the Char ascii value)
5 DISPLAY_ERASE_LINE(X1) (X1 is line number, 0-7)
6 DISPLAY_FILL_REGION(On, X1, Y1, X2, Y2) (X2 & Y2 are width & height
downward; 63-Y1 & Y2 must be multiples of 8)
7 DISPLAY_FRAME(On, X1, Y1, X2, Y2) (X2 & Y2 are width & height downward)
The ability to set or clear a pixel via the *_LINE functions using the On
parameter is also an enhancement (they used to only support set).
The syscall function ID is DisplayExecuteFunction = 36. The structure used to
execute this syscall function is:
TDisplayExecuteFunction struct
Status byte
Cmd byte
On byte
X1 byte
Y1 byte
X2 byte
Y2 byte
TDisplayExecuteFunction ends
Here are my test results of calling DisplayExecuteFunction with each test
executing 10000 iterations. Times are in milliseconds:
Test | Timing |
------------------------|------------|
DISPLAY_ERASE_ALL | 2881 |
DISPLAY_PIXEL | 1165 |
DISPLAY_HORIZONTAL_LINE | 1490 |
DISPLAY_VERTICAL_LINE | 1237 |
DISPLAY_CHAR | 2234 |
DISPLAY_ERASE_LINE | 1410 |
DISPLAY_FILL_REGION | 1537 |
DISPLAY_FRAME | 1474 |
--------------------------------------
d. CommExecuteFunction. This system call exposes the Comm module function
pointer and lets you execute any of the supported communication functions via
that pointer. The supported functions are
0 SENDFILE(Param1, Name)
1 SEARCH()
2 STOPSEARCH()
3 CONNECT(Param1, Param2)
4 DISCONNECT(Param1)
5 DISCONNECTALL()
6 REMOVEDEVICE(Param1)
7 VISIBILITY(Param1)
8 SETCMDMODE()
9 OPENSTREAM(Param2)
10 SENDDATA(Param1, Param2, Param3, Name) (length, port, ?, buffer)
11 FACTORYRESET()
12 BTON()
13 BTOFF()
14 SETBTNAME()
15 EXTREAD()
16 PINREQ()
17 CONNECTREQ()
The syscall function ID is CommExecuteFunction = 37. The structure used to
execute this syscall function is:
TCommExecuteFunction struct
Result word
Cmd byte
Param1 byte
Param2 byte
Param3 byte
Name byte[]
RetVal word
TCommExecuteFunction ends
d. LoaderExecuteFunction. This system call exposes the Loader module function
pointer and lets you execute any of the supported file system functions via that
pointer. The supported functions are
0x80 OPENREAD(FileName, Length)
0x81 OPENWRITE(FileName, Length)
0x82 READ(FileName, Buffer, Length)
0x83 WRITE(FileName, Buffer, Length)
0x84 CLOSE(FileName)
0x85 DELETE(FileName)
0x86 FINDFIRST(FileName, Buffer, Length)
0x87 FINDNEXT(FileName, Buffer, Length)
0x89 OPENWRITELINEAR(FileName, Length)
0x8A OPENREADLINEAR(FileName, Buffer, Length)
0x8B OPENWRITEDATA(FileName, Length)
0x8C OPENAPPENDDATA(FileName, Length)
0x90 FINDFIRSTMODULE(FileName, Buffer)
0x91 FINDNEXTMODULE(Buffer)
0x92 CLOSEMODHANDLE()
0x94 IOMAPREAD(FileName, Buffer, Length)
0x95 IOMAPWRITE(FileName, Buffer, Length)
0xA0 DELETEUSERFLASH()
0xA3 RENAMEFILE(FileName, Buffer, Length)
The syscall function ID is LoaderExecuteFunction = 38. The structure used to
execute this syscall function is:
TLoaderExecuteFunction struct
Result word
Cmd byte
FileName byte[]
Buffer byte[]
Length long
TLoaderExecuteFunction ends
2. Set or Clear when drawing. Not only is this exposed via the new
DisplayExecuteFunction syscall function, but it is also exposed via the existing
display syscall functions. With DrawPoint, DrawLine, DrawRect, and DrawCircle
you can set the 0x04 bit (DRAW_OPT_CLEAR_PIXELS) in the Options field of the
arguments structure then instead of setting the pixels on, these functions will
turn off (clear) the affected pixels. Additionally, in RIC files the various
opcode structures within the file can set this bit in the CopyOptions field in
order to clear rather than set the affected pixels.
3. Speed enhancements. I have tweaked some of the drawing routines to improve
speed. The vertical line drawing function draws a byte at a time rather than
one bit at a time now. The erase line and erase screen functions now are
optimized to use memset rather than iterate and set a single byte at a time.
The DrawRect system function now directly uses the DRAW_HORIZONTAL_LINE and
DRAW_VERTICAL_LINE drawing commands rather than drawing one pixel at a time.
The DrawLine system function directly calls these same two drawing commands if
the line is horizontal or vertical and if the start and end points are the same
it calls the set pixel routine just once.
Here are my test results of calling the standard drawing system calls with each
test executing 10000 iterations. Times are in milliseconds:
Test | JCHFirm | NXT 1.04 |
----------------------|---------|----------|
DrawRect | 1879 | 4473 |
DrawLine (Horizontal) | 1431 | 3297 |
DrawLine (vertical) | 1256 | 3590 |
DrawLine (Diagonal) | 3715 | 3617 |
--------------------------------------------
So even though in each of the drawing routines there is extra logic which allows
for either setting or clearing the affected pixels the optimized routines are
significantly faster than the standard NXT firmware routines (with the exception
of the diagonal line case).
4. SetScreenMode system call function now also lets you clear the screen in
addition to its existing behavior (which was to just restore the default NXT
screen).
My goal is to persuade LEGO to incorporate these changes into the standard NXT
firmware. The problem is they don't have the manpower to test these changes
in-house. And pretty thorough testing with NXT-G is needed to make sure that
the baseline product doesn't experience problems due to the fixes and
enhancements I've made. What I hope can happen is that many members of the LEGO
Robotics community can step forward and volunteer to test this enhanced firmware
using NXT-G, the LabView NXT toolkit, and NBC or NXC. If we can together put in
hundreds of hours of testing of these fixes and enhancements then perhaps LEGO
will release these changes in a future firmware update.
Thank you in advance for your willingness to help. You do good work!
The enhanced NXT firmware can be downloaded from
http://bricxcc.sourceforge.net/lms_arm_jch.zip
Extract the .a79 file and download it to your NXT using NeXTTool, BricxCC, the
LEGO MINDSTORMS NXT software, the ATMEL SAMBA utility, or your favorite firmware
downloader. You may need to rename it with a .rfw extension in order to use the
standard NXT software to download it. The firmware image does not contain any
files and its size fits into the 1.04 firmware size so any files on your NXT
should continue to work okay but it is possible that you will need to reload
your sounds, icons, and programs.
Please post here or email me if you are testing the firmware. Also, please
report by posting on the Lugnet nxt hacking newsgroup (or by emailing me) any
problems you encounter while running with the enhanced firmware installed on
your NXT. You can tell that you are running the enhanced firmware because it
reports 1.05 as its version number.
I can provide sample code in NBC and/or NXC which demonstrates how to use these
new features to anyone who needs it.
John Hansen
| | | | | | | | | | | | | | | |
John Hansen wrote:
> Over the past couple days I have used the IAR Embedded Workbench to implement
> some enhancements and bug fixes for the standard NXT firmware.
>
> The bug fixes are as follows:
<snipped description>
Holy crap John! You've been really busy! For anyone poking
around in this forum, I can say that what John has done is pretty
significant.
I have written my own firmware for the brick so I know
how much work must have gone into testing this.
For anyone interested in testing this, I'd encourage you
to do so and report back if there are any bugs or issues.
There is nothing like positive support from users to motivate
us along in the thankless task of improving firmware.
Ralph
PS. Even negative feedback is useful because it means SOMEONE
out there at least tried it :-)
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt.nxthacking, Ralph Hempel wrote:
> John Hansen wrote:
> > Over the past couple days I have used the IAR Embedded Workbench to implement
> > some enhancements and bug fixes for the standard NXT firmware.
> >
> > The bug fixes are as follows:
>
> <snipped description>
>
> Holy crap John! You've been really busy! For anyone poking
> around in this forum, I can say that what John has done is pretty
> significant.
It actually was not a very big deal. I was familiar with the firmware source
code since I had looked at it quite a bit since it was released, trying to
figure out how to get it to compile with GCC. All the RIC bug fixes were things
I figured out during my port of the firmware C code to Delphi for the purposes
of writing an RIC editor at the end of last year (still not done). I submitted
the fixes back at the beginning of December. But this week, downloading a 30
day evaluation version of the IAR embedded workbench was the key to actually
moving forward with some of the changes I have been wanting to see for quite
some time.
Speeding up the line drawing code was pretty easy. Hooking in the clear/set
functionality was also extremely simple. Adding new syscall functions to the
standard firmware is trivially easy. None of this stuff is anywhere near as
complicated as writing your own firmware. I can send you my modifications to
the display module if you think they would be useful in pbLua.
Honestly, anybody could do this. With the IAR embedded workbench it is
*extremely* simple if you are a half-way decent C programmer and you can run an
IDE build process (i.e., click the "rebuild all" menu options). One of my goals
is to transition the source code from the IAR compiler to the GCC compiler
without having to make substantial code changes. But for now I am extremely
happy to use the eval version of the IAR tools to get things moving.
> I have written my own firmware for the brick so I know
> how much work must have gone into testing this.
I must say that I have not tested calling any of the Comm and Loader module
functions. I just hooked up the syscall function mechanism to the existing
IOMAP function pointer that was used in a lot of places. I may spend some time
wrapping up the file iteration stuff and some of the exposed bluetooth
functionality in a nicer package for use in NXT-G, NBC, and NXC.
> For anyone interested in testing this, I'd encourage you
> to do so and report back if there are any bugs or issues.
> There is nothing like positive support from users to motivate
> us along in the thankless task of improving firmware.
The only time it takes to test this firmware, just to be clear, is the time it
takes to download it to your NXT and then just keep using your brick just like
you already have been using it. If you run into any problems post here or email
me. The goal is to collect reports indicating that after lots of normal usage
via the NXT software, the LabView NXT toolkit, and via NBC/NXC that everything
works exactly as it did before without any problems.
> PS. Even negative feedback is useful because it means SOMEONE
> out there at least tried it :-)
Absolutely.
John Hansen
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt.nxthacking, John Hansen wrote:
> In lugnet.robotics.nxt.nxthacking, Ralph Hempel wrote:
> > John Hansen wrote:
> > > Over the past couple days I have used the IAR Embedded Workbench to implement
> > > some enhancements and bug fixes for the standard NXT firmware.
I would have liked to have one permanently, but it seems a little steep. Last
summer I got a limited edition (32KB or something) along with the an AT91
evaluation board.
> > >
> > > The bug fixes are as follows:
> >
> > <snipped description>
> >
> > Holy crap John! You've been really busy! For anyone poking
> > around in this forum, I can say that what John has done is pretty
> > significant.
>
> It actually was not a very big deal. I was familiar with the firmware source
> code since I had looked at it quite a bit since it was released, trying to
> figure out how to get it to compile with GCC.
Perhaps Section 5.1 is useful: http://nxtgcc.sourceforge.net/nxtgcc.pdf
Best,
Rasmus
PS: I just tried to post but it did not appear, so apologies for possible
double posting.
PSS: My NXT is at work, so I have to wait one or two day to test your code.
> All the RIC bug fixes were things
> I figured out during my port of the firmware C code to Delphi for the purposes
> of writing an RIC editor at the end of last year (still not done). I submitted
> the fixes back at the beginning of December. But this week, downloading a 30
> day evaluation version of the IAR embedded workbench was the key to actually
> moving forward with some of the changes I have been wanting to see for quite
> some time.
>
> Speeding up the line drawing code was pretty easy. Hooking in the clear/set
> functionality was also extremely simple. Adding new syscall functions to the
> standard firmware is trivially easy. None of this stuff is anywhere near as
> complicated as writing your own firmware. I can send you my modifications to
> the display module if you think they would be useful in pbLua.
>
> Honestly, anybody could do this. With the IAR embedded workbench it is
> *extremely* simple if you are a half-way decent C programmer and you can run an
> IDE build process (i.e., click the "rebuild all" menu options). One of my goals
> is to transition the source code from the IAR compiler to the GCC compiler
> without having to make substantial code changes. But for now I am extremely
> happy to use the eval version of the IAR tools to get things moving.
>
> > I have written my own firmware for the brick so I know
> > how much work must have gone into testing this.
>
> I must say that I have not tested calling any of the Comm and Loader module
> functions. I just hooked up the syscall function mechanism to the existing
> IOMAP function pointer that was used in a lot of places. I may spend some time
> wrapping up the file iteration stuff and some of the exposed bluetooth
> functionality in a nicer package for use in NXT-G, NBC, and NXC.
>
> > For anyone interested in testing this, I'd encourage you
> > to do so and report back if there are any bugs or issues.
> > There is nothing like positive support from users to motivate
> > us along in the thankless task of improving firmware.
>
> The only time it takes to test this firmware, just to be clear, is the time it
> takes to download it to your NXT and then just keep using your brick just like
> you already have been using it. If you run into any problems post here or email
> me. The goal is to collect reports indicating that after lots of normal usage
> via the NXT software, the LabView NXT toolkit, and via NBC/NXC that everything
> works exactly as it did before without any problems.
>
> > PS. Even negative feedback is useful because it means SOMEONE
> > out there at least tried it :-)
>
> Absolutely.
>
> John Hansen
| | | | | | | | | | | | | | | | | | |
...
>
> should continue to work okay but it is possible that you will need to reload
> your sounds, icons, and programs.
>
> Please post here or email me if you are testing the firmware. Also, please
> report by posting on the Lugnet nxt hacking newsgroup (or by emailing me) any
> problems you encounter while running with the enhanced firmware installed on
> your NXT. You can tell that you are running the enhanced firmware because it
> reports 1.05 as its version number.
Hi John,
I just tried to load it and just tested the "Try-me" light sensor. It worked
fine. Not so much help, but I can try some more another day.
Good work.
Rasmus
>
> I can provide sample code in NBC and/or NXC which demonstrates how to use these
> new features to anyone who needs it.
>
> John Hansen
| | | | | | | | | | | | | | | | | |
| |
|
"John Hansen" <afanofosc@comcast.net> wrote in message
news:JF0sGr.M2w@lugnet.com...
> Over the past couple days I have used the IAR Embedded Workbench to • implement
> some enhancements and bug fixes for the standard NXT firmware.
big snip
Great job John. And thank you especially for CommExecuteFunction. I couldn't
believe that Lego didn't allow a way to make a Bluetooth connection from a
program. With your firmware modifications, I am able to do this now.
I have only tested BTON, BTOFF, CONNECT, and DISCONNECT, but I intend to
test more of the commands that are a part of this syscall. I will also post
my results on here along with the parameters and return values that I am
able to interpret. I encourage others to test John's changes as well to give
him the leverage needed to convince Lego to take the changes.
3 CONNECT(Param1, Param2)
Param1 - index of device to connect to
Param2 - connection (1 - 3)
Result - BTCONNECTFAIL (0x9500, 38144). This can occur if you try to use a
connection that is already in use.
4 DISCONNECT(Param1)
Param1 - connection (1 - 3)
12 BTON()
Result: 0 - SUCCESS
RetVal: 0 - if already ON
1 - if was OFF
13 BTOFF()
Result: 0 - SUCCESS
RetVal: 1 - Always
A suggestion: it would be nice if the Name struct member of
TCommExecuteFunction were implemented so you could connect by name as well
as by index.
David Wallace
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt.nxthacking, David Wallace wrote:
> Great job John. And thank you especially for CommExecuteFunction. I couldn't
> believe that Lego didn't allow a way to make a Bluetooth connection from a
> program. With your firmware modifications, I am able to do this now.
That's great news, David. I'm glad that you are having success using the new
CommExecuteFunction system call. I haven't had a chance to test it at all yet
personally but I was very confident that it would just work seeing as how
exposing it via the syscall mechanism uses these functions exactly the same as
how they are called by the user interface.
> I have only tested BTON, BTOFF, CONNECT, and DISCONNECT, but I intend to
> test more of the commands that are a part of this syscall. I will also post
> my results on here along with the parameters and return values that I am
> able to interpret. I encourage others to test John's changes as well to give
> him the leverage needed to convince Lego to take the changes.
It would be great if we could pursuade LEGO to incorporate these changes since
they have no negative downside and a huge positive upside.
> A suggestion: it would be nice if the Name struct member of
> TCommExecuteFunction were implemented so you could connect by name as well
> as by index.
I think this would be a nice feature. I'll probably add it as a new function
id. Something like CONNECTBYNAME which would use the next available integer
value (which I don't recall off the top of my head).
I have been working on developing a unified code base which works with GCC and
IAR. I've got all the .txt files fixed so that the source compiles on GCC and
IAR but there are several other issues that I still need to sort out. Once I
get that completely working I will make my changes available publically. I'll
talk to Rasmus about putting the code on the sourceforge project he created.
John Hansen
| | | | | | |
