 | | | | | |
LEGO has posted the standard NXT firmware source code today. You can get it on
the NXT'reme page:
http://mindstorms.lego.com/Overview/NXTreme.aspx
The direct link to a EULA is here:
http://mindstorms.lego.com/Overview/OpenSource.aspx
John Hansen
| | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, John Hansen wrote:
> LEGO has posted the standard NXT firmware source code today. You can get it on
> the NXT'reme page:
>
> http://mindstorms.lego.com/Overview/NXTreme.aspx
>
> The direct link to a EULA is here:
>
> http://mindstorms.lego.com/Overview/OpenSource.aspx
>
> John Hansen
Thanks for the heads-up about this! (And also the pointer to the v1.04 firmware
update, too!) It is amazing how far TLC has come since the early days of the
RCX. Even for those who don't plan to change the firmware, there is certainly a
lot to learn from being able to dissect the source code line by line.
| | | | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, John Hansen wrote:
> LEGO has posted the standard NXT firmware source code today. You can get it on
> the NXT'reme page:
>
> http://mindstorms.lego.com/Overview/NXTreme.aspx
>
> The direct link to a EULA is here:
>
> http://mindstorms.lego.com/Overview/OpenSource.aspx
Cool. Do we know which version this is? I assume it's 1.03 or 1.04
ROSCO
| | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, Ross Crawford wrote:
> In lugnet.robotics.nxt, John Hansen wrote:
>
> Cool. Do we know which version this is? I assume it's 1.03 or 1.04
My understanding is that the source is version 1.04.
John Hansen
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, John Hansen wrote:
> LEGO has posted the standard NXT firmware source code today. You can get it on
> the NXT'reme page:
>
> http://mindstorms.lego.com/Overview/NXTreme.aspx
>
> The direct link to a EULA is here:
>
> http://mindstorms.lego.com/Overview/OpenSource.aspx
>
> John Hansen
This is very good news. Thanks for the update. I've been waiting for this for
a long time, particularly to have a look at the rather weak graphics
capabilities. I've had an expanded font (and a much smaller one) kicking around
for a while now.
Is it viable to repeatedly download test versions to the NXT firmware though?
Wasn't there an issue with the number of times you could download?
Does anyone have any plans to develop a system whereby machine code applications
can be run on the operating system? That would give more scope to develop more
advanced applications, as then one could develop libraries to do new things
rather than firmware hacks.
Is there a forum I'm not aware of where this can be progressed? I suppose I'm
getting ahead of myself if no-one's done a successful build and download yet
though...
Jason R
| | | | | | | | | | | | | | | | | | | | | |
> > Jason J Railton wrote on Tuesday, December 12, 2006 4:25 AM
> > To: lugnet.robotics.nxt@lugnet.com
> > Is it viable to repeatedly download test versions to the NXT
> > firmware though? Wasn't there an issue with the number of times you
> > could download?
I've downloaded firmware to NXT 100s of times with no apparent ill
effect.
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, <dickswan@sbcglobal.net> wrote:
>
> > > Jason J Railton wrote on Tuesday, December 12, 2006 4:25 AM
> > > To: lugnet.robotics.nxt@lugnet.com
>
> > > Is it viable to repeatedly download test versions to the NXT
> > > firmware though? Wasn't there an issue with the number of times you
> > > could download?
>
> I've downloaded firmware to NXT 100s of times with no apparent ill
> effect.
I am curious; have you ever had a situation where bad firmware locked up the
NXT? And if so, what was the process to restore it to working order? (I don't
have a bricked brick, I'm just asking for future reference.)
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, Jason J Railton wrote:
> In lugnet.robotics.nxt, John Hansen wrote:
> > LEGO has posted the standard NXT firmware source code today. You can get it on
> > the NXT'reme page:
> >
> > http://mindstorms.lego.com/Overview/NXTreme.aspx
> >
> > The direct link to a EULA is here:
> >
> > http://mindstorms.lego.com/Overview/OpenSource.aspx
> >
> > John Hansen
>
> This is very good news. Thanks for the update. I've been waiting for this for
> a long time, particularly to have a look at the rather weak graphics
> capabilities. I've had an expanded font (and a much smaller one) kicking around
> for a while now.
>
> Is it viable to repeatedly download test versions to the NXT firmware though?
> Wasn't there an issue with the number of times you could download?
>
> Does anyone have any plans to develop a system whereby machine code applications
> can be run on the operating system? That would give more scope to develop more
> advanced applications, as then one could develop libraries to do new things
> rather than firmware hacks.
>
> Is there a forum I'm not aware of where this can be progressed? I suppose I'm
> getting ahead of myself if no-one's done a successful build and download yet
> though...
Flash memories all have a limited number of write cycles before they become
unreliable. Usually, the on-chip write controller will "load-balance" the
writes so that different memory locations all get used the same number of times,
automatically re-mapping physical addresses into the logical address space. I
have read that the flash used in the NXT is rated for 10,000 writes before
problems may occur. (Some modern flash memories are rated for over 1,000,000
write cycles.)
I have also read that there is one section of the flash which is used for a
Table Of Contents, and which therefore must be updated any time a file is loaded
onto the NXT. This area would be re-written any time you add or delete a file
from the NXT, even a simple data-logging application. The article that I saw
did not mention whether the TOC is always in the same physical memory location;
it is more likely that this logical section is re-mapped into a new physical
address during each write operation.
Still, writing any type of file onto the NXT will eventually wear out the flash
memory and lead to failure. If you were to download 30 programs onto your NXT
every day, it would start to have problems after about a year, assuming that
these specs are correct. Running a data-logging application continuously on
your NXT could burn it out even faster.
If you were testing new firmware, you would probably not be writing the flash
any more frequently than someone who was testing an application written using
the standard MindStorms programming environment, (in fact, you would probably be
writing less frequently between test iterations) but this could eventually
become an issue for some people. If you are worried about this, you might
consider writing an emulator for your development machine so that you don't
perform too many writes. This could be a good idea anyway, because you could
run the risk of "bricking" your NXT by downloading buggy firmware. I do not
know whether the firmware download routines are stored in a ROM external to the
flash firmware, but this would be a wise design. The NXT does have a reset
button hidden in the recess of the Technic pin hole beneath the USB connector,
but whether this would simply reboot the buggy firmware I do not know.
I am planning to dig into the firmware source code to see how it ticks. I
personally don't have any immediate plans to customize it yet, since I am still
learning what the NXT can do without my meddling. It would be cool to be able
to compile and run standard C++ apps (brickOS port, anyone?) and I suppose that
there will be many replacement firmware versions available soon enough. But
just like using dremel tools and glue, use of replacement firmware should only
be a last resort, IMHO.
The answers to all of these questions can probably be found in the firmware
source code and in the NXT hardware documentation, which can all be downloaded
from the LEGO web site at the links that John provided. Another great place to
ask these questions is http://www.nxtasy.org. (I see that somebody has already
patched GCC to be able to rebuild the LEGO firmware!) But please do post
questions, answers, and NXT-related announcements here on lugnet.robotics.nxt as
well, since many people still come here as their primary source of information.
Hope this helps!
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, Chris Phillips wrote:
> Still, writing any type of file onto the NXT will eventually wear out the flash
> memory and lead to failure. If you were to download 30 programs onto your NXT
> every day, it would start to have problems after about a year, assuming that
> these specs are correct. Running a data-logging application continuously on
> your NXT could burn it out even faster.
If this limitation had applied to the rcx, I'd have suggested this. Because you
can control the outputs and read the inputs direct from a pc you could run an
emulation of the rcx firmware running your program on the pc. The rcx would then
behave in the same way as if you had downloaded the program onto it. You would
have course have the transmission delay caused by the IR link. But whether that
was a problem would depend on your application. I suspect the same could be
applied to the NXT.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, Steve Lane wrote:
> In lugnet.robotics.nxt, Chris Phillips wrote:
>
> > Still, writing any type of file onto the NXT will eventually wear out the flash
> > memory and lead to failure. If you were to download 30 programs onto your NXT
> > every day, it would start to have problems after about a year, assuming that
> > these specs are correct. Running a data-logging application continuously on
> > your NXT could burn it out even faster.
>
> If this limitation had applied to the rcx, I'd have suggested this. Because you
> can control the outputs and read the inputs direct from a pc you could run an
> emulation of the rcx firmware running your program on the pc. The rcx would then
> behave in the same way as if you had downloaded the program onto it. You would
> have course have the transmission delay caused by the IR link. But whether that
> was a problem would depend on your application. I suspect the same could be
> applied to the NXT.
Now that's a cool idea. I've been messing around with remote-controlling the
NXT via Bluetooth from a PC application, and it seems pretty solid. You'd
definitely have some timing issues running a remote emulation like you describe,
but this could still have some really interesting applications. It would be
pretty cool to have a program on the PC that could read in the .RXE file,
emulate the runtime, and pull the puppet strings remotely.
The worst aspect of this is that any command that requires a response, like
reading a sensor value, forces the Bluetooth to "turn around" which (according
to the docs) incurs a 60ms penalty. I think the timing is a good deal less
problematic when operating over a USB link.
Hmmm...
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
"Steve Lane yahoo.co.uk>" <stevenrobertlane@<nospamplease> wrote in
message news:JABnK0.15z@lugnet.com...
> In lugnet.robotics.nxt, Chris Phillips wrote:
>
> > Still, writing any type of file onto the NXT will eventually wear
> > out the flash
> > memory and lead to failure. If you were to download 30 programs
> > onto your NXT
> > every day, it would start to have problems after about a year,
> > assuming that
> > these specs are correct. Running a data-logging application
> > continuously on
> > your NXT could burn it out even faster.
Fortunately the most common failure mode is a reduction in the
"longevity" of storage. Out of box, the Atmel ARM flash is specified
to retain contents for 40 years. I think most of us could accept an
order or two of magnitude less on this paramter.
There are also two different specs that we're dealing with here. One
is the number of times that complete flash can be rewritten (i.e.
downloading complete firmware and the other is the number of times
that an individual sector can be written (i.e. writing a user program
to flash). I believe the conservative specs for these are 100 and
10,000 respectively.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Dick Swan wrote:
> There are also two different specs that we're dealing with here. One
> is the number of times that complete flash can be rewritten (i.e.
> downloading complete firmware and the other is the number of times
> that an individual sector can be written (i.e. writing a user program
> to flash). I believe the conservative specs for these are 100 and
> 10,000 respectively.
Not to put too fine a point on it, but the 100 cycle limit is
only on the lock bits, I think. This is specified at the
extreme limits of voltage and temperature.
At normal room conditions, actual NXTs were reflashed (which
cycles the lock bits) at least 7,000 times before failure.
Your mileage, will of course vary :-)
Cheers, Ralph
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> This is very good news. Thanks for the update.
I've been waiting for this for
> a long time, particularly to have a look at the
rather weak graphics
> capabilities. I've had an expanded font (and a
much smaller one) kicking around
> for a while now.
Jason, can you share these fonts at all. I am
making good progress on integrating LCD support
into my replacement firmware but I only have one
6x8 font set, and it's not complete. I need the
font to be in the vertical byte format that
the NXT display uses.
> Is it viable to repeatedly download test
versions to the NXT firmware though?
> Wasn't there an issue with the number of times
you could download?
According to the worst case spec sheet, yes. Under
normal temperature and voltage conditions, like
in my office, it's a much bigger number.
I've reflashed my firmware hundreds of times
with no obvious side-effects.
> Does anyone have any plans to develop a system
whereby machine code applications
> can be run on the operating system? That would
give more scope to develop more
> advanced applications, as then one could develop
libraries to do new things
> rather than firmware hacks.
Yes. I have a complete GCC build system, with
a line oriented interface to GDB through the
USB port.
> Is there a forum I'm not aware of where this can
be progressed? I suppose I'm
> getting ahead of myself if no-one's done a
successful build and download yet
> though...
I would really, really like this newsgroup to be
that one point of entry for this kind of
discussion.
It does a couple of things including:
1. Keeps focus in one place
2. Allows web or email information transfer
3. Is searchable
4. Keeps people coming back to Lugnet
Question for Lugnet admins...does this fit
in with your plans, and can I have an offline
discussion with you regarding this.
I was a very early member of Lugnet, and I am
still having trouble with passwords and account
management so that I can post via the web ionterface
when I'm on the road.
Cheers, Ralph Hempel
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics.nxt, Ralph Hempel wrote:
| |
In lugnet.robotics.nxt, Jason J Railton wrote:
| |
This is very good news. Thanks for the update. I’ve been waiting for this
for a long time, particularly to have a look at the rather weak graphics
capabilities. I’ve had an expanded font (and a much smaller one) kicking
around for a while now.
|
Jason, can you share these fonts at all. I am
making good progress on integrating LCD support
into my replacement firmware but I only have one
6x8 font set, and it’s not complete. I need the
font to be in the vertical byte format that
the NXT display uses.
|
About a year ago, I got involved in doing some hacking on the Sony PSP, and
wrote a Windows utility that will rip any font at a chosen size as a bitmapped C
array. If I can figure out which computer I left the sources on, I’ll make it
available. Do you have details on your preferred format? Sounds like you just
need a byte array with one byte per vertical column? Is the MSB at the top or
bottom?
| |
| |
Is it viable to repeatedly download test versions to the NXT firmware though?
Wasn’t there an issue with the number of times you could download?
|
According to the worst case spec sheet, yes. Under
normal temperature and voltage conditions, like
in my office, it’s a much bigger number.
I’ve reflashed my firmware hundreds of times
with no obvious side-effects.
|
On (cough) a different NXT-related forum, John Hansen had this to say:
“Reloading the firmware on the NXT eats up a cycle of the firmware flash page
lock bits on the first two flash pages. These lock bits are rated at 100 cycles
but very reliable sources have said that ATMEL has measured lock bit cycles as
high as 7500. I also know that someone from LEGO has tested reflashing his NXT
repeatedly until it failed. He was able to reflash somewhere around 7000-8000
times (I forget the exact number).”
Your mileage (and flash failure modes) may vary.
| |
| |
Does anyone have any plans to develop a system whereby machine code
applications can be run on the operating system? That would give more scope
to develop more advanced applications, as then one could develop libraries to
do new things rather than firmware hacks.
|
Yes. I have a complete GCC build system, with
a line oriented interface to GDB through the
USB port.
|
This sounds really cool! Is this available somewhere? (No pressure!)
| |
| |
Is there a forum I’m not aware of where this can be progressed? I suppose
I’m getting ahead of myself if no-one’s done a successful build and download
yet though...
|
I would really, really like this newsgroup to be
that one point of entry for this kind of
discussion.
|
I couldn’t agree more. I also can’t help but notice that posting activity on
LUGNET is on a definite upswing of late.
It’s good to have you back, Ralph!
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.nxt, Ralph Hempel wrote:
> > This is very good news. Thanks for the update. I've been waiting for this for
> > a long time, particularly to have a look at the rather weak graphics
> > capabilities. I've had an expanded font (and a much smaller one) kicking around
> > for a while now.
>
>
> Jason, can you share these fonts at all. I am
> making good progress on integrating LCD support
> into my replacement firmware but I only have one
> 6x8 font set, and it's not complete. I need the
> font to be in the vertical byte format that
> the NXT display uses.
Ralph - I'll send them to you. If you want, mail me the byte format and I'll
see if I can run a conversion. I presume it's in the vertical byte format that
the screen uses? I did a full 256 character set that includes upper case, lower
case, punctuation, Latin-9 European accented characters in #160-#255, icons in
the lower 32 characters (arrows where the cursor control codes are, musical note
for the old 'ping' code, etc.) and most of the Greek upper, lower and accented
characters in the #128-#159 undefined area.
Do you have the complete datasheet I uncovered earlier which has the LCD
controller instruction codes?
I know the NXT buffers a bitmapped screen and regularly transfers the data to
the LCD controller. What I though was with a 6x8 font you could write
characters directly to the LCD controller and so free up the RAM.
I also have a smaller 4x6 font that's still quite readable. It could work as a
terminal display, though you'd need to store at least a byte per character
representation of the screen in RAM. From that you could replace one character
at a time directly on the screen, or maybe even generate the screen display
on-the-fly.
This would require it to handle different graphics modes, but once started this
could be expanded. A lot of the fonts are based on my SNOT lettering alphabets,
but expanded.
I was hoping to work on some far more advanced graphics functions, but obviously
that would need to build on someone who's already hacked the firmware. I don't
want to discuss them just yet until I've sounded out the feasibility with
someone who's got an idea of what's involved with re-writing the firmware.
Jason R
| | | | | | | | | | | | | | | | | |
Hello!
Is there any information (in the files or at the internet) how to compile it)
Greetings from Germany
| | | | | | |
