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