| |
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
|
|
Message is in Reply To:
7 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in...
Robotics
NXT programmable brick
|
|
|
|
|
|
