 | | | | | |
NXT Spec From
LEGO Service FAQ
• 32-bit ARM7 microprocessor
• 256 Kbytes FLASH, 64 Kbytes RAM
• 8-bit microprocessor
• 4 Kbytes FLASH, 512 Byte RAM
• Bluetooth wireless communication
• USB 2.0 port
• 4 input ports, 6 wire digital platform
• 3 output ports, 6 wire digital platform
• Dot matrix display 60 x 100 pixels
• Loudspeaker – 8 KHz sound quality
• Power, 6 AA Batteries
Some flash is nice but 64K RAM is just too little. We can forget about doing
voice processing.
| | | | | | | | | | | | | | | |
In lugnet.robotics, Ka-On Lee wrote:
| |
Some flash is nice but 64K RAM is just too little. We can forget about doing
voice processing.
|
My thought exactly. Perfect opportunity to build an outboard speech recognition
device using new technology speech recognition chips hooked to the new digital
interface (whatever that turns out to be) to communicate recognition “hits” back
to the NXT CPU.
I tried it with the RCX, but the low quality of the then available off-the-shelf
recognition chip sets added to the difficulty of encoding the “hits” back to the
RCX made it an ungainly proposition. There are a few people out there with some
of my original prototypes, but it wasn’t something you’d make in quantity.
JB
| | | | | | | | | | | | | | | | | |
Subject:
|
Re: mindstorms NXT
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 7 Jan 2006 03:33:35 GMT
|
Original-From:
|
Chris 'Xenon' Hanson <XENON@nospam3DNATURE.COM>
|
Viewed:
|
7878 times
|
| |
|
Ka-On Lee wrote:
> • 32-bit ARM7 microprocessor¬
> • 256 Kbytes FLASH, 64 Kbytes RAM¬
Niiice.
> • 8-bit microprocessor¬
> • 4 Kbytes FLASH, 512 Byte RAM¬
Interesting. I wonder if this is an H8? Maybe the NXT can emulate an RCX somehow?
Doesn't seem like that would be all that valuable. Maybe I'm reading too much into it.
--
Chris 'Xenon' Hanson | Xenon @ 3D Nature | http://www.3DNature.com/
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
| | | | | | | | | | | | | | | | | |
In lugnet.robotics, Ka-On Lee wrote:
| |
NXT Spec From
LEGO Service FAQ
• 32-bit ARM7 microprocessor
• 256 Kbytes FLASH, 64 Kbytes RAM
• 8-bit microprocessor
• 4 Kbytes FLASH, 512 Byte RAM
• Bluetooth wireless communication
• USB 2.0 port
• 4 input ports, 6 wire digital platform
• 3 output ports, 6 wire digital platform
• Dot matrix display 60 x 100 pixels
• Loudspeaker – 8 KHz sound quality
• Power, 6 AA Batteries
Some flash is nice but 64K RAM is just too little. We can forget about doing
voice processing.
|
So- it’s a 32-bit processor and an 8-bit? With both 512 bytes and 64k bytes of
RAM?
Wonder who wrote that spec?
| | | | | | | | | | | | | | | | |
Subject:
|
Re: mindstorms NXT
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 7 Jan 2006 06:56:59 GMT
|
Original-From:
|
William Grant <tanarrifujitsu@optusnet.com.+StopSpam+au>
|
Viewed:
|
8145 times
|
| |
|
Ka-On Lee wrote:
> NXT Spec From
> <http://www.lego.com/eng/service/faqs.asp?section=ConsumerService-FAQ-Products&catid=E8D0CD47-16B8-4B2F-900C-8FC40C163598&faqid=17262#17262
> LEGO Service FAQ>
>
> • 32-bit ARM7 microprocessor¬
> • 256 Kbytes FLASH, 64 Kbytes RAM¬
> • 8-bit microprocessor¬
> • 4 Kbytes FLASH, 512 Byte RAM¬
> • Bluetooth wireless communication¬
> • USB 2.0 port¬
> • 4 input ports, 6 wire digital platform¬
> • 3 output ports, 6 wire digital platform¬
> • Dot matrix display 60 x 100 pixels¬
> • Loudspeaker – 8 KHz sound quality¬
> • Power, 6 AA Batteries¬
>
>
> Some flash is nice but 64K RAM is just too little. We can forget about doing
> voice processing.
64K RAM!? That's absolutely ludicrous! The RCX has 32kb entirely of
programmable memory (if I remember correctly), and that is just alright.
64kb is not much space to work in at all in this era!
Anyway, a dot-matrix display is nice, as is Bluetooth (especially as it
can communicate between robots), and should be significantly more
reliable than Infrared (albeit probably more power hungry).
William.
| | | | | | | | | | | | | | | | | |
In lugnet.robotics, William Grant tanarrifujitsu@optusnet.com.au wrote:
| |
Ka-On Lee wrote:
| |
NXT Spec From
LEGO Service FAQ
• 32-bit ARM7 microprocessor
• 256 Kbytes FLASH, 64 Kbytes RAM
• 8-bit microprocessor
• 4 Kbytes FLASH, 512 Byte RAM
Some flash is nice but 64K RAM is just too little. We can forget about doing
voice processing.
|
64K RAM!? That’s absolutely ludicrous! The RCX has 32kb entirely of
programmable memory (if I remember correctly), and that is just alright.
64kb is not much space to work in at all in this era!
|
Actually, 64K of RAM is quite a bit. You have to remember that with the RCX you
had 32K for everything. With the NXT all of the program code will go into
(and run directly from) the 256K of flash -- this includes things that take up
the most space: text, constant tables for state machines, etc.
The amount of RAM you need is very small. Micro-controllers I’ve used for custom
handhelds, engine controllers and transmission controllers (all real-world and
done in the last 2-3 years) have had at most 8K of RAM. As long as you have
enough flash and know how to make the most of it you can do a lot of really
interesting stuff.
All around this is a really big step up.
I’m curious if we’ll be able to use the 8-bit uC or if it is dedicated to
managing the motors and sensors (off loading basic driver functionality but not
being re-programmable).
Michael
| | | | | | | | | | | | | | | | | | | | | |
| |
|
Michael Zapp wrote:
> Actually, 64K of RAM is quite a bit. You have to remember that with the RCX you
> had 32K for [everything]. With the NXT all of the program code will go into
> (and run directly from) the 256K of flash -- this includes things that take up
> the most space: text, constant tables for state machines, etc.
It depends where your ambitions lie.
If you want to analyse audio or video or map your environment somehow -
then 64Kb is pathetically small.
If all you want is something that's just a small step ahead of an RCX
then it's plenty.
Of course you should be able to treat Flash memory as writable (slowly)
backing store and page data in and out of RAM as you need to - but even
so, it's not a whole lot.
Let's look at some concrete examples:
VIDEO:
One frame of video from a cheap digital video camera might be 640x480
RGB pixels of three bytes each is almost a Megabyte. That's four times
the amount of flash memory in the NXT. Yes, you *could* use monochrome
or you *could* use lower resolutions - but this is the brand shiney new
machine for the future, accepting these kinds of restrictions seems
harsh. Plus, if you are doing motion detection or something, you'll
need more than one frame of data and lots of space for intermediate
steps in the calculations.
AUDIO:
If you are grabbing audio at (say) 12Khz for speech analysis - then
64Kb is six seconds of audio.
MAPPING:
If you are mapping a 30' x 30' room - and (say) you need a byte for
every square inch of the floor so you can map the position of chair
legs and such - then you've just eaten 128Kbytes right there.
So 64Kb (or even 256Kb + 64Kb) is pretty limiting for some of the
kinds of things a robot might want to do.
As a money-saving measure, keeping the amount of memory small makes
sense for Lego. But you can buy a 256 MEGABYTE USB flash drive for
$8.50. That's one thousand times more than the 256Kbytes that the NXT
has.
> The amount of RAM you need is very small. Micro-controllers I've used for custom
> handhelds, engine controllers and transmission controllers (all real-world and
> done in the last 2-3 years) have had at most 8K of RAM.
Sure - and I've built an entire telephone exchange in an Intel 8008 with
512 bytes of RAM and 4kb of ROM.
You can always find applications that don't need that much memory - but
that's not the question. The question is: Can you find useful and
important applications that are impossible with only 64Kb. I think
there are lots of those.
> As long as you have
> enough flash and know how to make the most of it you can do a lot of really
> interesting stuff.
Sure - *some* interesting stuff - but not video, audio or mapping.
> All around this is a really big step up.
Well, it's a step up - but not all that big.
> I'm curious if we'll be able to use the 8-bit uC or if it is dedicated to
> managing the motors and sensors (off loading basic driver functionality but not
> being re-programmable).
Probably it's dedicated - but even if it's not, given the microscopic
amount of flash and RAM that it has - and given that it's probably
100 times slower than the ARM7, it's hard to see what you'd gain by
messing with it.
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> It depends where your ambitions lie.
Well, then let's hope there's some way we can increase the amount of memory
availible. I don't know about the hard-wired aspect of adding memory, but with
Bluetooth... anybody thinking about a Bluetooth external memory module? Perhaps
we can toss a Blackberry piggyback on the NXT for memory... or for that matter,
processing. It would seem to me for a community that reverse-engineered a much
less accesible device, the NXT may be turning us loose in the candy store...
after hours at that.
--
Brian Davis
| | | | | | | | | | | | | | | | | | | | | | | | |
Hi Steve,
> > As long as you have
> > enough flash and know how to make the most of it you can do a lot of
> > really
> > interesting stuff.
>
> Sure - *some* interesting stuff - but not video, audio or mapping.
Not so sure about that. I would try to use the bluetooth link and let my
computer do the video, audio or mapping work. I did that kind of thing
with the RCX and the IR connection and it was a nightmare sometimes, it
only worked reliable with stationary robots ( i did a sorter with vision
command and a learning neural net, that worked fine, but a moving bot
lost connection all the time)
I imagine a seekbot that runs through my livingroom, saves his data with
bluetooth, can use 500MB of my notebook's RAM if it likes and... well,
in the moment I count my money and wait...
Regards,
Michael
| | | | | | | | | | | | | | | | | | | | | | | | |
> Of course you should be able to treat Flash memory as writable (slowly)
> backing store and page data in and out of RAM as you need to - but even
> so, it's not a whole lot.
Not all flash ram is slow,
ferro flash ram (e.g. FRAM) has zero write cycle time.
Stef
| | | | | | | | | | | | | | | | | | | | | | | | | | |
> > Of course you should be able to treat Flash memory as writable (slowly)
In the case of room mapping, would speed be so important? Isn't it it
in the ms range? (A lot compared to an instruction cycle, but good
enough for a moving bot)
| | | | | | | | | | | | | | | | | | | | | | | | |
> If you are mapping a 30' x 30' room - and (say) you need a byte for
> every square inch of the floor so you can map the position of chair
> legs and such
You could use a bit per square inch
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Ignacio Martinez Vazquez wrote:
> > If you are mapping a 30' x 30' room - and (say) you need a byte for
> > every square inch of the floor so you can map the position of chair
> > legs and such
>
> You could use a bit per square inch
You could - but I might want to store more than one bit of information
per square inch (eg a 'confidence' figure or a 'time since last mapped'
number - or to store multiple maps so I can see how the
map is changing over time).
The point is that having such an incredibly small amount of memory
(by modern standards) forces you into ugly compromise solutions from
your shiney new system from day #1.
If this system is going to be around for the same amount of time as
the RCX (what? nearly 10 years now?) - it ought not to look antiquated
from the very beginning.
You can buy Flash memory USB 'thumb drives' for $8.50 in quantity
with anywhere from 128Mbytes upwards. (Check out - for example
www.customflashsolutions.com - but even in one-off quantities,
128Mb flash drives can be bought for $14).
That's ONE THOUSAND TIMES more flash memory than the NXT is claimed
to have.
Dunno about you - but if I'm going to be paying over $250 for a
robotics system, I'd pay the extra $8 to get a thousand times
more memory.
I'm so horrified about this that I'm half convinced that this must
be a mis-print and that the NXT *surely* has 128Mb and not 128Kb.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> The point is that having such an incredibly small amount of memory
> (by modern standards) forces you into ugly compromise solutions from
> your shiney new system from day #1.
I'm curious - I'm a physicist, not by any means a hardware type. What *is* a
standard amount of on-board FLASH for a embedded system? The NXT uses some sort
of ARM processor (what the heck does that stand for anyway?) - how FLASH-rish do
these come? And how hard is it to mate such a CPU chip with another chip or two
of FLASH?
> If this system is going to be around for the same amount of time as
> the RCX (what? nearly 10 years now?) - it ought not to look antiquated
> from the very beginning.
Well, to be fair, the same could safely be said of the RCX. It had less RAM
ten years ago than my Apple ][ did more than 20 years ago!
> You can buy Flash memory USB 'thumb drives' for $8.50 in quantity
> with anywhere from 128Mbytes upwards.
How hard is it to interface a thumb drive with a device like the ARM? From
other discussion here the difference between slave and master USB devices seems
to be important. How much extra hardware or software do you need to make
something like the NXT a USB master device, so it could handle things like a
thumb drive?
> I'm so horrified about this that I'm half convinced that this must
> be a mis-print and that the NXT *surely* has 128Mb and not 128Kb.
With Bluetooth at least we'll have access to potentially a whole computer's
worth of memory (at a slower rate? I really need to learn about Bluetooth).
--
Brian Davis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Brian Davis wrote:
> In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
>
> > The point is that having such an incredibly small amount of memory
> > (by modern standards) forces you into ugly compromise solutions from
> > your shiney new system from day #1.
>
> I'm curious - I'm a physicist, not by any means a hardware type. What *is* a
> standard amount of on-board FLASH for a embedded system?
Since I'm an engineer, I will give you the standard engineering answer:
Depends on the requirements! :-)
> The NXT uses some sort
> of ARM processor (what the heck does that stand for anyway?)
http://en.wikipedia.org/wiki/ARM_architecture
http://www.arm.com
The ARM architecture has been around for years and has been a very effective
RISC based embeddded CPU core. That Wiki article does a good job explaining the
history and the various implementations of the ARM core (ARM7 is the NXT but I
have no idea which version of ARM7 it is, I can guess from the specs but it
would be nice to know the EXACT chip).
I haven't compiled anything for ARM in quite sometime (as many of stated, you
can probably develop a cross environment to natively build ARM7 code).
> - how FLASH-rish do
> these come? And how hard is it to mate such a CPU chip with another chip or two
> of FLASH?
Straightforward usually.
> How hard is it to interface a thumb drive with a device like the ARM? From
> other discussion here the difference between slave and master USB devices seems
> to be important. How much extra hardware or software do you need to make
> something like the NXT a USB master device, so it could handle things like a
> thumb drive?
Impossible I believe or at least the part of making it a host device (master).
> With Bluetooth at least we'll have access to potentially a whole computer's
> worth of memory (at a slower rate? I really need to learn about Bluetooth).
Yeah, this seems like the best route! (same here when it comes to Bluetooth)
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
pisymbol wrote:
> The ARM architecture has been around for years and has been a very effective
> RISC based embeddded CPU core. That Wiki article does a good job explaining the
> history and the various implementations of the ARM core (ARM7 is the NXT but I
> have no idea which version of ARM7 it is, I can guess from the specs but it
> would be nice to know the EXACT chip).
I would be inclined to guess that the ARM is just the CPU core
implemented in the same chip as all the other stuff the NXT uses.
One of the huge reasons for picking the ARM is that it's very well
suited to being integrated into the same chip as a bunch of other
stuff.
> I haven't compiled anything for ARM in quite sometime (as many of stated, you
> can probably develop a cross environment to natively build ARM7 code).
That much is very easy. The GNU C and C++ compilers have back-ends for
the ARM and there are LOTS of people doing all sorts of things on ARM
devices so there is plenty of expertise out there.
For example, there are people porting Linux onto the GameBoy Advance
and the Nintendo DS...so you just KNOW there is a ton of freebie stuff
out there for this CPU.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> pisymbol wrote:
>
> > The ARM architecture has been around for years and has been a very effective
> > RISC based embeddded CPU core. That Wiki article does a good job explaining the
> > history and the various implementations of the ARM core (ARM7 is the NXT but I
> > have no idea which version of ARM7 it is, I can guess from the specs but it
> > would be nice to know the EXACT chip).
>
> I would be inclined to guess that the ARM is just the CPU core
> implemented in the same chip as all the other stuff the NXT uses.
Right but that's not what I'm really asking! :-)! I'm sure its a variation of an ARM7 chip which will implement the standard ARM ISA. However, with any ARM7 implementation it can be catered to a specific applications. From the ARM website:
"The ARMv7 architecture defines three distinct processor profiles: the A profile
for sophisticated, virtual memory-based OS and user applications; the R profile
for real-time systems; and the M profile optimized for microcontroller and
low-cost applications.
All ARMv7 architecture profiles implement ® technology which is built on the
foundation of the ARM industry-leading Thumb code compression technology, while
retaining complete code compatibility with existing ARM solutions. The ARMv7
architecture also includes the ™ technology extensions to increase DSP and media
processing throughput by up to 400 percent, and offers improved floating point
support to address the needs of next generation 3D graphics and games physics,
as well as traditional embedded control applications."
Source: http://www.arm.com/products/CPUs/architecture.html
So for example, is the NXT chip capable of SIMD? I suspect it is since the NXT FAQ talks about playing music. What about Jazelle? I know someone asked about using Java with the NXT (a nice idea from the programmers standpoint). I know the J2ME KVM can be as small as 128K.
> One of the huge reasons for picking the ARM is that it's very well
> suited to being integrated into the same chip as a bunch of other
> stuff.
>
> > I haven't compiled anything for ARM in quite sometime (as many of stated, you
> > can probably develop a cross environment to natively build ARM7 code).
>
> That much is very easy. The GNU C and C++ compilers have back-ends for
> the ARM and there are LOTS of people doing all sorts of things on ARM
> devices so there is plenty of expertise out there.
>
> For example, there are people porting Linux onto the GameBoy Advance
> and the Nintendo DS...so you just KNOW there is a ton of freebie stuff
> out there for this CPU.
Oh no doubt Steve. In fact, someone stated that historically ARM was "hard" to
program for and I have to disagree. One of the advantages of ARM is its
simplistic ISA. Since its RISC (in the classical sense), its ISA is already
straightforward to use, i.e. there aren't half a dozen instructions that can
yield the same result like x86 and each instruction has the same basic format.
Moreover, since these are embedded chips, their execution units are very simple.
I think the ARM7 has a simple classic 3-stage pipeline (Fetch, Decode, Execute).
This makes it easier on the compiler guys to generate streamlined assembly
unlike Intel which at this point has made assembly look like Java byte code!
The first order of business for the NXT is to have some kind of sane cross or
toolchain environment that people could download and use.
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
pisymbol wrote:
> So for example, is the NXT chip capable of SIMD? I suspect it is since the
> NXT FAQ talks about playing music.
You can play music quite easily without SIMD.
> What about Jazelle? I know someone asked about using Java with the
> NXT (a nice idea from the programmers standpoint). I know the J2ME KVM
> can be as small as 128K.
Well, you can run Java on an RCX...
http://lejos.sourceforge.net/
...so you certainly have the capacity to do so on the NXT.
> In fact, someone stated that historically ARM was "hard" to
> program for and I have to disagree.
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
> The first order of business for the NXT is to have some kind of sane cross or
> toolchain environment that people could download and use.
That's gonna happen VERY quickly if Lego let us get into the machine
at the machine code level as they did with the RCX. There is already
a complete OpenSourced tool chain for the ARM in the form of the GNU
gcc/g++ compilers and libraries.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, steve sjbaker1@airmail.net wrote:
| |
pisymbol wrote:
| |
So for example, is the NXT chip capable of SIMD? I suspect it is since the
NXT FAQ talks about playing music.
|
You can play music quite easily without SIMD.
| |
What about Jazelle? I know someone asked about using Java with the
NXT (a nice idea from the programmers standpoint). I know the J2ME KVM
can be as small as 128K.
|
Well, you can run Java on an RCX...
http://lejos.sourceforge.net/
...so you certainly have the capacity to do so on the NXT.
| |
In fact, someone stated that historically ARM was “hard” to
program for and I have to disagree.
|
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
|
Do you mean machine code (binary) or assembly language? I first learned assembly
language programming on a MIPS chip (RISC). I’ve also done it on a Motorola
68HC11 (a microcontroller), and I’ve written both pure machine code and assembly
language for the Intel 8086. I much prefer the MIPS processor, followed by the
68HC11, and dead last is any Intel x86 chip. Bleah.
For machine code, pretty much any chip is “hard” to program.
| |
| |
The first order of business for the NXT is to have some kind of sane cross or
toolchain environment that people could download and use.
|
That’s gonna happen VERY quickly if Lego let us get into the machine
at the machine code level as they did with the RCX. There is already
a complete OpenSourced tool chain for the ARM in the form of the GNU
gcc/g++ compilers and libraries.
|
I fully expect they will, since they released the LASM documentation (RCX
firmware bytecodes) with the Mindstorms SDK.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Jordan Bradford wrote:
| |
| |
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
|
Do you mean machine code (binary) or assembly language?
|
There the same.
| |
I first learned
assembly language programming on a MIPS chip (RISC). I’ve also done it on a
Motorola 68HC11 (a microcontroller), and I’ve written both pure machine code
and assembly language for the Intel 8086. I much prefer the MIPS processor,
followed by the 68HC11, and dead last is any Intel x86 chip. Bleah.
For machine code, pretty much any chip is “hard” to program.
|
I guess my last post didn’t make it.
Fundamentally, Steve is correct that RISC is typically more complex to program
since it uses less general purpose registers and more complex instructions (it
tries to do more per clock tic than CISC).
However, these days, the lines between CISC and RISC are pretty much gone
(Intel’s execution unit is RISC based converting the assembly you write into
micro-ops). Moreover, both ARM and MIPS are extrememly well documented and
understood so as many have stated, programming even at the assembly level is not
hard. The real issue with assembly is typically the hand building of the final
binary (with custom linker layout files which can get real complicated depending
on the architecture and complexity of the program).
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Alexander Sack wrote:
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
| |
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
|
Do you mean machine code (binary) or assembly language?
|
There the same.
|
Obviously you’ve not coded in machine language, or you’d know they are not.
| |
| |
I first learned
assembly language programming on a MIPS chip (RISC). I’ve also done it on a
Motorola 68HC11 (a microcontroller), and I’ve written both pure machine code
and assembly language for the Intel 8086. I much prefer the MIPS
processor, followed by the 68HC11, and dead last is any Intel x86 chip.
Bleah.
For machine code, pretty much any chip is “hard” to program.
|
I guess my last post didn’t make it.
Fundamentally, Steve is correct that RISC is typically more complex to
program since it uses less general purpose registers and more complex
instructions (it tries to do more per clock tic than CISC).
|
You misunderstand RISC and CISC. CISC instructions often combine data memory
references with arithmetic, logical, or brach capabilities. RISC machines do
not. RISC instructions try to do *less* per clock tick, thus the instructions
take less logic, and can run *faster*.
Typically RISC instructions are simpler than CISC instructions. Often RISC
architectures separate memory related instructions from arithemtic, logical,
branch or other miscelaneous instructions. RISC machines typically have many
more registers than a CISC machine. The SPARC machines that Sun makes (RISC)
gives you 31 general purpose registers which can be used for address or data.
Compare this with the 68000 CISC where you get 8 address and 8 data.
The reason that folks think RISC is more complex to program is that it typically
takes a few RISC instructios to emulate a CISC instruction. I don’t find it
more or less difficult, just different. I’ve done assembly on 8080, 8085, 8086,
80286, IMB 360, IBM370, IBM 390, 6502, 6800, 6811, 68000(all CISC), as well as
SPARC, and soon to be ARM7 (RISC). I find the orthoginality of RISC instruction
sets much nicer than the redundancy of CISC machines. Having worked on
simulation of future CISC and RISC products from the gates up, I find RISC a
much better machine design.
I’ve programmed a bit of machine code on IBM 370. What a pain.
| |
However, these days, the lines between CISC and RISC are pretty much gone
(Intel’s execution unit is RISC based converting the assembly you write into
micro-ops). Moreover, both ARM and MIPS are extrememly well documented and
understood so as many have stated, programming even at the assembly level is
not hard. The real issue with assembly is typically the hand building of the
final binary (with custom linker layout files which can get real complicated
depending on the architecture and complexity of the program).
|
In most cases the toolsets are easy to come by these days thanks in large part
to GNU.
Kev
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Kevin L. Clague wrote:
| |
In lugnet.robotics, Alexander Sack wrote:
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
| |
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
|
Do you mean machine code (binary) or assembly language?
|
There the same.
|
Obviously you’ve not coded in machine language, or you’d know they are not.
|
If you are talking about the actual 1’s and 0’s that represent machine code then
you are correct and I misinterpreted your last post, i.e. the binary. When
people speak of binaries they are usually referring to something like an
executable binary such as ELF or COFF. I saw “high-level language” and short
circuited.
Yes, I have never coded at the machine code level and pray I never have too.
| |
| |
| |
I first learned
assembly language programming on a MIPS chip (RISC). I’ve also done it on a
Motorola 68HC11 (a microcontroller), and I’ve written both pure machine
code and assembly language for the Intel 8086. I much prefer the MIPS
processor, followed by the 68HC11, and dead last is any Intel x86 chip.
Bleah.
For machine code, pretty much any chip is “hard” to program.
|
I guess my last post didn’t make it.
Fundamentally, Steve is correct that RISC is typically more complex to
program since it uses less general purpose registers and more complex
instructions (it tries to do more per clock tic than CISC).
|
You misunderstand RISC and CISC. CISC instructions often combine data memory
references with arithmetic, logical, or brach capabilities. RISC machines do
not. RISC instructions try to do *less* per clock tick, thus the
instructions take less logic, and can run *faster*.
Typically RISC instructions are simpler than CISC instructions. Often RISC
architectures separate memory related instructions from arithemtic, logical,
branch or other miscelaneous instructions. RISC machines typically have many
more registers than a CISC machine. The SPARC machines that Sun makes (RISC)
gives you 31 general purpose registers which can be used for address or data.
Compare this with the 68000 CISC where you get 8 address and 8 data.
|
Yup I switched them. My bad, that’s correct. RISC needs to have more general
purpose registers to make up for the lack of complex instruction types on CISC.
Thanks for the review.
| |
The reason that folks think RISC is more complex to program is that it
typically takes a few RISC instructios to emulate a CISC instruction. I
don’t find it more or less difficult, just different. I’ve done assembly on
8080, 8085, 8086, 80286, IMB 360, IBM370, IBM 390, 6502, 6800, 6811,
68000(all CISC), as well as SPARC, and soon to be ARM7 (RISC). I find the
orthoginality of RISC instruction sets much nicer than the redundancy of CISC
machines. Having worked on simulation of future CISC and RISC products from
the gates up, I find RISC a much better machine design.
|
I think its all personal preference at this point. Like I said, the lines
between RISC and CISC are much less than they use to be.
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Alexander Sack wrote:
| |
In lugnet.robotics, Kevin L. Clague wrote:
| |
In lugnet.robotics, Alexander Sack wrote:
| |
In lugnet.robotics, Jordan Bradford wrote:
| |
| |
I said that RISC machines (in general) are harder to program in
machine code. The ARM is as easy as any other processor to program
in high level languages.
|
Do you mean machine code (binary) or assembly language?
|
There the same.
|
Obviously you’ve not coded in machine language, or you’d know they are not.
|
If you are talking about the actual 1’s and 0’s that represent machine code
then you are correct and I misinterpreted your last post, i.e. the binary.
When people speak of binaries they are usually referring to something like an
executable binary such as ELF or COFF. I saw “high-level language” and short
circuited.
Yes, I have never coded at the machine code level and pray I never have too.
|
Now you’re talkin! I’ve never really done more than a half dozen instructions,
unless it was a homework problem waaaaaaaay (and I really mean waaaaaaaay ;^)
back in college.
| |
| |
| |
| |
I first learned
assembly language programming on a MIPS chip (RISC). I’ve also done it on
a Motorola 68HC11 (a microcontroller), and I’ve written both pure machine
code and assembly language for the Intel 8086. I much prefer the MIPS
processor, followed by the 68HC11, and dead last is any Intel x86 chip.
Bleah.
For machine code, pretty much any chip is “hard” to program.
|
I guess my last post didn’t make it.
Fundamentally, Steve is correct that RISC is typically more complex to
program since it uses less general purpose registers and more complex
instructions (it tries to do more per clock tic than CISC).
|
You misunderstand RISC and CISC. CISC instructions often combine data
memory references with arithmetic, logical, or brach capabilities. RISC
machines do not. RISC instructions try to do *less* per clock tick, thus
the instructions take less logic, and can run *faster*.
Typically RISC instructions are simpler than CISC instructions. Often RISC
architectures separate memory related instructions from arithemtic, logical,
branch or other miscelaneous instructions. RISC machines typically have
many more registers than a CISC machine. The SPARC machines that Sun makes
(RISC) gives you 31 general purpose registers which can be used for address
or data. Compare this with the 68000 CISC where you get 8 address and 8
data.
|
Yup I switched them. My bad, that’s correct. RISC needs to have more
general purpose registers to make up for the lack of complex instruction
types on CISC. Thanks for the review.
|
I guess this is what CISC proponents say. I don’t know that I agree. I think
that no matter the architecture type *more* is better! Register access is
orders of magnitudes faster than memory access, so less memory access are
better.
Register access time halves every two years, yet DRAM access times halve every
six years. Memory is painfully slow these days.... but now I’m *really* off
topic!
| |
| |
The reason that folks think RISC is more complex to program is that it
typically takes a few RISC instructios to emulate a CISC instruction. I
don’t find it more or less difficult, just different. I’ve done assembly on
8080, 8085, 8086, 80286, IMB 360, IBM370, IBM 390, 6502, 6800, 6811,
68000(all CISC), as well as SPARC, and soon to be ARM7 (RISC). I find the
orthoginality of RISC instruction sets much nicer than the redundancy of
CISC machines. Having worked on simulation of future CISC and RISC products
from the gates up, I find RISC a much better machine design.
|
I think its all personal preference at this point. Like I said, the lines
between RISC and CISC are much less than they use to be.
|
I think that the fact that X86 has effectively gone RISC indicates that RISC is
winning the conceptual battle. You trade a little bit of programming effort
spread across a lot of programmers, for the ability to toss out a lot of
hardware complexity and the engineering cost that it takes to make sure the
complexity is really working.
Sun’s most recent hardware announcement was for a four stage instruction
pipeline that chip vs chip dramatically outperforms anything Intel (3X) has
(with their 20+ stage pipeline). Now that we’re this far off topic, maybe we
need to move this thread ;^)
It is fun to discuss, but doesn’t really have much to do with NXT so I’ll sit
down and be quiet.
Kev
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Kevin L. Clague wrote:
| |
I think that the fact that X86 has effectively gone RISC indicates that RISC
is winning the conceptual battle. You trade a little bit of programming
effort spread across a lot of programmers, for the ability to toss out a lot
of hardware complexity and the engineering cost that it takes to make sure
the complexity is really working.
|
I totally agree! I stated this in another thread (or maybe this one) that
assembly code on Intel is like Java Byte Code (but worse). I mean its not like
you *really* know as a “high-level assembly programmer” exactly the order in
which micro-ops were executed.
If your a compiler guy (I know two guys who were at one point heavily involved
with gcc), developing for Intel is a nightmare (how do you know the following
set of instructions doesn’t cause an unneccessary stall 20 stages in the pipe,
etc.).
| |
Sun’s most recent hardware announcement was for a four stage instruction
pipeline that chip vs chip dramatically outperforms anything Intel (3X) has
(with their 20+ stage pipeline). Now that we’re this far off topic, maybe we
need to move this thread ;^)
It is fun to discuss, but doesn’t really have much to do with NXT so I’ll sit
down and be quiet.
|
Sure thing but Kevin this has been a fun discussion to say the least! (and a
good review for me)
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Brian Davis wrote:
> In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> > The point is that having such an incredibly small amount of memory
> > (by modern standards) forces you into ugly compromise solutions from
> > your shiney new system from day #1.
>
>
> I'm curious - I'm a physicist, not by any means a hardware type. What *is* a
> standard amount of on-board FLASH for a embedded system?
It depends on the application obviously...but thinking of consumer
devices that cost around the same ballpark as the NXT and which are
likely to be sold in similar quantities, we have PDA's, handheld games,
MP3 players and digital cameras.
* PDA's generally have somewhere in the tens to hundreds of Megabytes
of flash and maybe a few megs of RAM.
* The Nintendo DS hand-held game system has 4Mbytes RAM and it's
teeny-tiny game cartridges have hundreds of Megabytes of ROM memory.
* A typical digital camera has a few megabytes of RAM and hundreds of
megabytes of flash.
* A solid-state MP3 player would be likely to have hundreds of Megabytes
of flash and very little RAM.
> The NXT uses some sort
> of ARM processor (what the heck does that stand for anyway?)
ARM == Acorn RISC Machine
RISC == Reduced Instruction Set Computer
Acorn == A British company that designed and manufactured the ARM until
one of the big companies took them over.
RISC computers are generally quite hard to program at the machine code
level, but easier and more efficient for automated program compilers.
The ARM has been around in different incarnations for maybe 15 to 20
years. The ARM7 used in the NXT is a couple of generations behind the
cutting edge (eg the Nintendo DS uses an ARM9 as it's main CPU). The
big thing that makes the ARM popular for embedded systems like this one
is that the ARM circuitry is fairly compact (because it's a RISC
machine and therefore runs very SIMPLE instructions very fast). This
allows system developers such as LEGO to put lots of other circuitry
onto the same chip and thereby save a ton of money. Given the small
amount of RAM, it's likely that the RAM is on the same chip as the
ARM. It's even possible that the 8 bit microprocessor is also on
that same chip.
> - how FLASH-rish do
> these come? And how hard is it to mate such a CPU chip with another chip or two
> of FLASH?
Expanding the amount of memory (presuming you were prepared to do some
surgery to the circuit board) might be very easy - or it might be
impossible. It depends greatly on whether the main CPU chip has enough
address pins to access more memory.
> > If this system is going to be around for the same amount of time as
> > the RCX (what? nearly 10 years now?) - it ought not to look antiquated
> > from the very beginning.
>
> Well, to be fair, the same could safely be said of the RCX. It had less RAM
> ten years ago than my Apple ][ did more than 20 years ago!
Yes - but that would be to compare a desktop system with an embedded
computer.
Memory capacities double about every one to two years - so you'd
expect maybe between 5 and 10 doublings in capacity between the RCX and
the NXT if they were following industry trends.
So 32Kb for the RCX would become between 1 Mbyte and 32 Mbytes for the
NXT.
If you think that's agressive, look at the Nintendo Advance (64Kb,
released in early 2001) which has grown to the Nintendo DS (4Mb, late
2005) which is six doublings in four years!
> > You can buy Flash memory USB 'thumb drives' for $8.50 in quantity
> > with anywhere from 128Mbytes upwards.
>
> How hard is it to interface a thumb drive with a device like the ARM?
It would be pretty tough.
> From other discussion here the difference between slave and master USB devices seems
> to be important.
Yes. It's crucial.
In effect, the USB port on the NXT is only useful for talking to a PC
(or perhaps a PDA if it had a USB host port).
> How much extra hardware or software do you need to make
> something like the NXT a USB master device, so it could handle things like a
> thumb drive?
It's more major surgery - but it's hard to say how hard it would be at
this early stage. It's certainly going to be a lot more than cutting a
couple of tracks and soldering in a couple more wires.
From a software perspective, there are plenty of OpenSourced drivers
for USB flash devices that could probably be adapted to make this work,
I doubt that would be a problem.
> > I'm so horrified about this that I'm half convinced that this must
> > be a mis-print and that the NXT *surely* has 128Mb and not 128Kb.
>
> With Bluetooth at least we'll have access to potentially a whole computer's
> worth of memory (at a slower rate? I really need to learn about Bluetooth).
Yes - that's an interesting direction.
I'm also pretty un-knowledgeable about Bluetooth. I don't think there
are Bluetooth flash memory drives or anything though. A quick search of
Bluetooth devices suggests that just about the only things people are
using this interface for is cellphone hands-free operation and wireless
audio headsets.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
>
> The ARM has been around in different incarnations for maybe 15 to 20
> years. The ARM7 used in the NXT is a couple of generations behind the
> cutting edge (eg the Nintendo DS uses an ARM9 as it's main CPU). The
> big thing that makes the ARM popular for embedded systems like this one
> is that the ARM circuitry is fairly compact (because it's a RISC
> machine and therefore runs very SIMPLE instructions very fast). This
> allows system developers such as LEGO to put lots of other circuitry
> onto the same chip and thereby save a ton of money. Given the small
> amount of RAM, it's likely that the RAM is on the same chip as the
> ARM. It's even possible that the 8 bit microprocessor is also on
> that same chip.
It's also possible (likely?) that LEGO are using an already available ARM7 chip,
such as http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str710 or
http://www.atmel.com/dyn/products/product_card.asp?part_id=3524
ROSCO
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Ross Crawford wrote:
> In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> >
> > The ARM has been around in different incarnations for maybe 15 to 20
> > years. The ARM7 used in the NXT is a couple of generations behind the
> > cutting edge (eg the Nintendo DS uses an ARM9 as it's main CPU). The
> > big thing that makes the ARM popular for embedded systems like this one
> > is that the ARM circuitry is fairly compact (because it's a RISC
> > machine and therefore runs very SIMPLE instructions very fast). This
> > allows system developers such as LEGO to put lots of other circuitry
> > onto the same chip and thereby save a ton of money. Given the small
> > amount of RAM, it's likely that the RAM is on the same chip as the
> > ARM. It's even possible that the 8 bit microprocessor is also on
> > that same chip.
>
> It's also possible (likely?) that LEGO are using an already available ARM7 chip,
> such as http://mcu.st.com/mcu/inchtml.php?fdir=pages&fnam=str710 or
> http://www.atmel.com/dyn/products/product_card.asp?part_id=3524
It is most often cheapest to buy rather than make, so using a proven solution
off the shelf makes a lot of sense.
Think of the development costs of using ARM IP on a custom chip. Suddenly LEGO
would become a hardware development group, and the costs would be really high.
Even if they used PLAs, they would still have a large development cost in design
and verification. This is just for the hardware.....
They still have the development and testing costs of the software. One has to
wonder if National Instruments is doing all the software design and testing, or
whether like the RCX, LEGO does firmware and NI does the programming
environment?
We know we have ARM7, 256KB flash, 64KB RAM, Analog to Digital, PWM, Bluetooth,
and LCD. Do either of these chips fit well with these capabilities.
Anyone out there knowledgable about graphic LDC displays? Do they have a
standard interface, or are they all proprietary?
I would assume that LEGO will go with off the shelf parts that provide the best
capabilities for the lowest cost.
Kev
>
> ROSCO
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
--- steve <sjbaker1@airmail.net> wrote:
> ARM == Acorn RISC Machine
> RISC == Reduced Instruction Set Computer
> Acorn == A British company that designed and manufactured the ARM until
> one of the big companies took them over.
>
> RISC computers are generally quite hard to program at the machine code
> level, but easier and more efficient for automated program compilers.
Just FYI, I programmed an ARM chip over 10 years ago (so it must have been a
less powerful one than this). The assembly code was surprisingly clean,
simple, and powerful. ARM is a great architecture. Something like BrickOS
with a GNU C compiler will make this a very powerful platform, especially in
relation to what other robotics hobby products are out there (stamp, pic,
atmel, etc)
I'm all for more powerful platforms, but at $250 there was no way they could
have gone to megabytes.
One thing I think TLG should consider, given that (acc. to some article that
was linked here) 50% or so of their market for RIS was adult hobbyists --
they should come out with a high-end product at a considerably higher price.
A $400 set with say NTX with 2 megs of ram, more pieces, maybe different
motors, would sell pretty well I think.
If they don't, then hopefully aftermarket companies can pick up the slack.
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
dan miller wrote:
>
> I'm all for more powerful platforms, but at $250 there was no way they could
> have gone to megabytes.
>
> One thing I think TLG should consider, given that (acc. to some article that
> was linked here) 50% or so of their market for RIS was adult hobbyists --
> they should come out with a high-end product at a considerably higher price.
> A $400 set with say NTX with 2 megs of ram, more pieces, maybe different
> motors, would sell pretty well I think.
>
> If they don't, then hopefully aftermarket companies can pick up the slack.
I agree. When the RCX was found to have limitations in the enthusiast
community I can't say I blamed LEGO that much. With the RCX they didn't
know they were going to have a market with hobbyists anywhere near that
size.
Now we have the NXT. And we don't know for sure what expansion or
hacking possibilities or limitations it truly has. I think though that
given the RCX's past it should have been clear to LEGO that there would
be interest in a more expandable and even higher priced model in the
hobbyist market. It wouldn't have to be an upgraded unit even, just a
socket for a memory expansion card would be cool.
I know they have limits for the cost and the price for the kids/consumer
market. But they know now that the majority of the RCX's were bought by
adults with significantly more cash on hand than the average child. I'd
be very surprised if they didn't think of some way to capitalize on this.
I forget how many RCX's were sold so far, one figure was 40,000 but that
may have been per year. I remember this surprised LEGO. So even if
20,000 went to children, that means that 20,000 went to adults. Many of
whom bought more than one, and who also spent money on other LEGO sets,
sensors and other accessories. If there was a $400-$500 RCX available at
the time, I a large portion of those 20,000 adult sales would have been
the higher end model. Or if there was a $200 expansion pack for more I/O
and memory I bet a majority of the 20,000 would have gotten expanded.
Of course bakc then they had no idea the market even existed. Seems like
a shame to let an easy way to take advantage of a market slip away a
second time.
-Kyle
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Kyle McDonald wrote:
If there was a $400-$500 RCX available at
> the time, I a large portion of those 20,000 adult sales would have been
> the higher end model. Or if there was a $200 expansion pack for more I/O
> and memory I bet a majority of the 20,000 would have gotten expanded.
Just to play devils advocate for a minute, but you don't know how many adults
need the upgraded version. Some of the truly hardcore users hang out here but
they are only a relatively small amount of people.
A normal rcx is good enough for me (now that we have Swan, giving us more
variables, etc).
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, dan miller danbmil99@yahoo.com wrote:
| |
One thing I think TLG should consider, given that (acc. to some article that
was linked here) 50% or so of their market for RIS was adult hobbyists --
they should come out with a high-end product at a considerably higher price.
A $400 set with say NTX with 2 megs of ram, more pieces, maybe different
motors, would sell pretty well I think.
If they don’t, then hopefully aftermarket companies can pick up the slack.
|
You forget LEGO already did that with the Scout in the Robotics Discovery Set.
But perhaps it was too limited for people to want to buy it.
If the NXT has a memory expansion slot inside it that would satisfy quite a few
people I think.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> consumer devices that cost around the same ballpark as the NXT...
Well, there's a significant cost above and beyond the electronics here. The
NXT *might* be comparable to a PDA, but tossing in 500+ precision-molded little
plastic parts probably drives the cost up considerably (heck, just from buying
sets I *know* it does, where as the plastic case of a PDA or Nintendo is really
cheap).
> and which are likely to be sold in similar quantities,
I really doubt the number of Mindstorms sets sold compares well with the
number of PDAs, Nintendos, Playstations, etc. I think I read somewhere that
annual sales are around 40,000 for the RIS, while given the number of folks in
my town and the prevelance of something like a GameBoy, my town alone must move
something like 10,000+ GameBoys annually (& Elkhart, IN, isn't that big!). I'm
really unclear on how economies of scale come in, but something like a GameBoy
is probably 10x to 100x times more unit sales. As to the other things you
mention, they all require significant amounts of memory to function, while
embedded systems don't usually. I can see why a digital camera or MP3 player
must have a lot of memory, but it's far less clear to me that this is the
important thing for something like the NXT (truth be told, I'm not sure *what*
the priority woukld be for something like the NXT - anyone?).
> ARM == Acorn RISC Machine
> RISC == Reduced Instruction Set Computer
> Acorn == A British company that designed and manufactured the ARM until
> one of the big companies took them over.
Thank you! I sometimes feel lost in the world of acronyms.
> The big thing that makes the ARM popular for embedded systems like
> this one is that the ARM circuitry is fairly compact (because it's
> a RISC machine and therefore runs very SIMPLE instructions very fast).
> This allows system developers such as LEGO to put lots of other circuitry
> onto the same chip and thereby save a ton of money.
OK, that makes sense. So LEGO designed their own chip for this? They didn't
do that for the RCX (I'm not sure why). I guess I hadn't thought of customizing
the chip - I assumed that was wicked expensive, so they were using off-the-shelf
components (like another replier to this thread found) and just customizing at
the circuit board level.
> Expanding the amount of memory (presuming you were prepared to do some
> surgery to the circuit board) might be very easy - or it might be
> impossible. It depends greatly on whether the main CPU chip has enough
> address pins to access more memory.
Drat. It really looks like the first use of our toys is going to be to break
them open to count pins again and read off chip specs. I wish LEGO would release
this stuff to us at some point.
> If you think that's agressive, look at the Nintendo Advance (64Kb,
> released in early 2001) which has grown to the Nintendo DS (4Mb, late
> 2005) which is six doublings in four years!
OK. But I suspect the drive for higher memory there was much more important
than it would be fomr something like the RCX/NXT, wouldn't it?
> I don't think there are Bluetooth flash memory drives or anything
> though.
I've not looked. I do know there are Bluetooth mice and keyboards, and
printers. At least for the printers you have to transmit a reasaonble amount of
information in a semi-timely way, so the data transfer speeds can't be *that*
bad. And I *love* the idea of perhaps building a robot that a bystander could
interat with via their cell phones :-). The question there, as somebody else
mentioned, is if LEGO will allow (or we can add) true Bluetooth capacity or at
least some flexibility, and not just "you get to send this single 8-bit digit".
--
Brian Davis
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On 1/9/06, Brian Davis wrote:
> bad. And I *love* the idea of perhaps building a robot that a bystander could
> interat with via their cell phones :-). The question there, as somebody else
I keep hearing this (and reading in the official press releases) but
having recently shopped for a cell phone, I can tell you that everyone
available here (Ontario) that I can find has the bluetooth crippled to
it will ONLY talk to bluetooth headsets. Can't even use them for
address book sync with a PC.
This tells me that the likelihood of a NXT bot controlled by a
cellphone is NILL.
(guess we'll just have to wait for the bluetooth remote control that
will come later in an expansion set like the original RCX IR remote
did)
-Rob A>
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Mon, 9 Jan 2006 14:31:47 GMT
Rob Antonishen <rob.antonishen@gmail.com> wrote:
> I keep hearing this (and reading in the official press releases) but
> having recently shopped for a cell phone, I can tell you that everyone
> available here (Ontario) that I can find has the bluetooth crippled to
> it will ONLY talk to bluetooth headsets. Can't even use them for
> address book sync with a PC.
Ouch, that's bad. Here in Sweden I can confirm that bluetooth phones
with other features are around - for instance, my own phone can sync,
and others can be used to remote control toys. Apart from the Ericsson
car, I found TV output and several GPS receivers. The latter seem to be
aimed at PDAs.
http://www.sonyericsson.com/spg.jsp?cc=global&lc=en&ver=4001&template=ps1&zone=ps&lm=ps1&pid=10109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Rob Antonishen wrote:
> On 1/9/06, Brian Davis wrote:
>
>
> > bad. And I *love* the idea of perhaps building a robot that a bystander could
> > interat with via their cell phones :-). The question there, as somebody else
>
>
> I keep hearing this (and reading in the official press releases) but
> having recently shopped for a cell phone, I can tell you that everyone
> available here (Ontario) that I can find has the bluetooth crippled to
> it will ONLY talk to bluetooth headsets. Can't even use them for
> address book sync with a PC.
>
> This tells me that the likelihood of a NXT bot controlled by a
> cellphone is NILL.
>
> (guess we'll just have to wait for the bluetooth remote control that
> will come later in an expansion set like the original RCX IR remote
> did)
One (Verizon) of the 2 top carrier's in the US tried to cripple the
bluetooth in at least one model, and it created a large PR storm. I"m
not sure whether they changed their position on that model or on future
models but I havne't heard as much complaining recently.
Cingular, the other carrier, has never crippled it's phones that I know
of. I recently upgraded from a Sony Ericsson (SE) T637 to a SE Z520,
and both are fully bluetooth enbled. They can transfer files, audio,
etc. The Z520a can even act as a mouse for my bluetooth laptop - push
the joystick on the phone the pointer moves on the screen. Pretty cool.
There are other control profiles to for things like a slide show in
Powerpoint.
I imagine it's something like this that LEGO forsees being used to
control a robot. Hopefully this won't be the only thing it can do.
-Kyle
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Rob Antonishen wrote:
> On 1/9/06, Brian Davis wrote:
>
>
> > bad. And I *love* the idea of perhaps building a robot that a bystander could
> > interat with via their cell phones :-). The question there, as somebody else
>
>
> I keep hearing this (and reading in the official press releases) but
> having recently shopped for a cell phone, I can tell you that everyone
> available here (Ontario) that I can find has the bluetooth crippled to
> it will ONLY talk to bluetooth headsets. Can't even use them for
> address book sync with a PC.
That's because you can actually catch a phone virus via bluetooth
(it's not very secure).
My wife's phone caught one - and it was a pain to get rid of.
> This tells me that the likelihood of a NXT bot controlled by a
> cellphone is NILL.
Well, not NIL - but less likely than perhaps you might like.
However, it's gonna be useful for having robots talk back to
a PC or to each other. That's good enough for me.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On Mon, January 9, 2006 9:31 am, Rob Antonishen wrote:
> This tells me that the likelihood of a NXT bot controlled by a
> cellphone is NILL.
every place that talks about the NXT also talks about "Bluetooth technology that
allows your robot to communicate with external devices such as mobile phones".
<http://www.firstlegoleague.org/default.aspx?pid=21400>
Personally, I REALLY think controlling a NXT bot with a cellphone will be possible.
Steve
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Steve Hassenplug wrote:
> On Mon, January 9, 2006 9:31 am, Rob Antonishen wrote:
> > This tells me that the likelihood of a NXT bot controlled by a
> > cellphone is NILL.
>
> every place that talks about the NXT also talks about "Bluetooth technology that
> allows your robot to communicate with external devices such as mobile phones".
>
> <http://www.firstlegoleague.org/default.aspx?pid=21400>
>
> Personally, I REALLY think controlling a NXT bot with a cellphone will be possible.
>
> Steve
Or with a GameBoy Advance with the wireless link peripheral (uses Bluetooth).
It's not a common piece of hardware, but some of the newer Pokemon games come
with it. I think about 15 games support it currently.
Anyway, my GBA is one thing I'll be trying to connect to my NXT. I might even be
able to bootload the GBA from the NXT, which means I (and other people with
their GBAs) won't need to have a program on a blank GBA-compatible flash-RAM
cartridge.
Fun stuff.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Jordan Bradford wrote:
> Anyway, my GBA is one thing I'll be trying to connect to my NXT. I might even be
> able to bootload the GBA from the NXT, which means I (and other people with
> their GBAs) won't need to have a program on a blank GBA-compatible flash-RAM
> cartridge.
That sounds pretty interesting as a GBA is a decent controller compared to
celphone buttons.
But, is there a programming language that covers enough celphones? This would
make that project more practical for the range of impact. There is already this:
http://alex.seewald.at/BlueCar/
Right now, I am looking for a pda with usb host. That could solve the memory and
video processing issues like the Robo-sapien brain transplant. I presume that
real time data logging should be possible across usb. I wonder:
Can the usb connection start running programs on the fly?
Can several NXTs can be hubbed using USB?
Some other thoughts that I made over at fbtb:
I really hope that we get some backward compatibility. Specifically, an infrared
EYE sensor needs to send/receive signals with the old RCX's. Extra icing would
be the 6m commercial irda range vs the 1m range of pdas. That would be the
easiest and best hurdle. Second, a digital wire to 2x2 convertor could maybe
send power to the old motors and get a signal from old sensors.
I am a bit surprised that the finished models do not show more gears. That seems
to greatly reduce the system flexibility. I really don't mind less wheels. My
LEGO experience has always been oversupplied with wheels.
I am glad that the display is good for something. Having to always analyze the
datalog on a PC is a pain.
Mounting the brick could have some top/bottom/front/rear pin holes but that is
not a big issue. I am really curious about the bottom of the brick. What
features does it have?
I too think the motors and sensors look amazingly large. That's probably to
appeal to the younger tinkerers. Studless pieces are supposed to make it look
more "human" and thus more "friendly". And Studs are not that strong for robots.
So, this should get these sets into junior school and high school is a great
thing.
The motor's 5 point mounting wheel looks like it will be really torque. Maybe
that is why they are larger. The axle hole THROUGH it will be very versatile.
Can anyone tell me what might be in the arm of the motors?
I hope one of the first pieces to come out is a multiplexer. Running more
sensors and motors from one RCX has always been desired.
I am very glad about who the chose for MUP. I think they made a very positive
influence on the product for us.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
> Can anyone tell me what might be in the arm of the motors?
Probably a gear reduction, similar to the RC motor:
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=116083
Philo
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
> I keep hearing this (and reading in the official press releases) but
> having recently shopped for a cell phone, I can tell you that everyone
> available here (Ontario) that I can find has the bluetooth crippled to
> it will ONLY talk to bluetooth headsets. Can't even use them for
> address book sync with a PC.
Blame the phone companies. (Verizon is probobly the worst offender but
others are guilty too)
I know of many hacks where people have re-enabled features (including such
things as bluetooth address book sync and bluetooth file transfer) that the
phone companies have disabled (especially prevalent in areas where you are
forced to buy the phone from the service provider).
My interest is in Motorola phones (being that I own one alblit one without
bluetooth) but such hacks may exist for other phones too.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> Brian Davis wrote:
> > In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
>
> > > The point is that having such an incredibly small amount of memory
> > > (by modern standards) forces you into ugly compromise solutions from
> > > your shiney new system from day #1.
> >
> >
> > I'm curious - I'm a physicist, not by any means a hardware type. What *is* a
> > standard amount of on-board FLASH for a embedded system?
>
> It depends on the application obviously...but thinking of consumer
> devices that cost around the same ballpark as the NXT and which are
> likely to be sold in similar quantities, we have PDA's, handheld games,
> MP3 players and digital cameras.
>
> * PDA's generally have somewhere in the tens to hundreds of Megabytes
> of flash and maybe a few megs of RAM.
> * The Nintendo DS hand-held game system has 4Mbytes RAM and it's
> teeny-tiny game cartridges have hundreds of Megabytes of ROM memory.
> * A typical digital camera has a few megabytes of RAM and hundreds of
> megabytes of flash.
> * A solid-state MP3 player would be likely to have hundreds of Megabytes
> of flash and very little RAM.
>
> > The NXT uses some sort
> > of ARM processor (what the heck does that stand for anyway?)
>
> ARM == Acorn RISC Machine
> RISC == Reduced Instruction Set Computer
> Acorn == A British company that designed and manufactured the ARM until
> one of the big companies took them over.
>
> RISC computers are generally quite hard to program at the machine code
> level, but easier and more efficient for automated program compilers.
Well, *any* machine is harder to program at machine code level. If you mean
assembly, I diagree. I spent the first 18 years of my career on IBM mainframes,
and the last 5 on SPARC machines. They each have their advantages and
disadvantage from a programming perspective. CISC machines have less registers
(including Intel X86) and are harder to program because of this.
ARM7 has a nice number of registers that is much larger than those in an Intel
box.
>
> The ARM has been around in different incarnations for maybe 15 to 20
> years. The ARM7 used in the NXT is a couple of generations behind the
> cutting edge (eg the Nintendo DS uses an ARM9 as it's main CPU). The
> big thing that makes the ARM popular for embedded systems like this one
> is that the ARM circuitry is fairly compact (because it's a RISC
> machine and therefore runs very SIMPLE instructions very fast). This
> allows system developers such as LEGO to put lots of other circuitry
> onto the same chip and thereby save a ton of money. Given the small
> amount of RAM, it's likely that the RAM is on the same chip as the
> ARM. It's even possible that the 8 bit microprocessor is also on
> that same chip.
Do you think that flash might also be on-chip? Google shows very few matches if
you look for 64K RAM, 256K flash, 32-bit and ARM.
>
> > - how FLASH-rish do
> > these come? And how hard is it to mate such a CPU chip with another chip or two
> > of FLASH?
>
> Expanding the amount of memory (presuming you were prepared to do some
> surgery to the circuit board) might be very easy - or it might be
> impossible. It depends greatly on whether the main CPU chip has enough
> address pins to access more memory.
>
> > > If this system is going to be around for the same amount of time as
> > > the RCX (what? nearly 10 years now?) - it ought not to look antiquated
> > > from the very beginning.
> >
> > Well, to be fair, the same could safely be said of the RCX. It had less RAM
> > ten years ago than my Apple ][ did more than 20 years ago!
>
> Yes - but that would be to compare a desktop system with an embedded
> computer.
>
> Memory capacities double about every one to two years - so you'd
> expect maybe between 5 and 10 doublings in capacity between the RCX and
> the NXT if they were following industry trends.
>
> So 32Kb for the RCX would become between 1 Mbyte and 32 Mbytes for the
> NXT.
>
> If you think that's agressive, look at the Nintendo Advance (64Kb,
> released in early 2001) which has grown to the Nintendo DS (4Mb, late
> 2005) which is six doublings in four years!
Game consoles always *have* to be very agressive in their technological
progress. They basically give away the hardware, and make money on games.
This business model does not apply here, so LEGO can't afford to keep up with
the most advanced technology and keep their selling cost as low as it is.
>
> > > You can buy Flash memory USB 'thumb drives' for $8.50 in quantity
> > > with anywhere from 128Mbytes upwards.
> >
> > How hard is it to interface a thumb drive with a device like the ARM?
>
> It would be pretty tough.
>
> > From other discussion here the difference between slave and master USB devices seems
> > to be important.
>
> Yes. It's crucial.
>
> In effect, the USB port on the NXT is only useful for talking to a PC
> (or perhaps a PDA if it had a USB host port).
>
> > How much extra hardware or software do you need to make
> > something like the NXT a USB master device, so it could handle things like a
> > thumb drive?
>
> It's more major surgery - but it's hard to say how hard it would be at
> this early stage. It's certainly going to be a lot more than cutting a
> couple of tracks and soldering in a couple more wires.
>
> From a software perspective, there are plenty of OpenSourced drivers
> for USB flash devices that could probably be adapted to make this work,
> I doubt that would be a problem.
>
> > > I'm so horrified about this that I'm half convinced that this must
> > > be a mis-print and that the NXT *surely* has 128Mb and not 128Kb.
> >
> > With Bluetooth at least we'll have access to potentially a whole computer's
> > worth of memory (at a slower rate? I really need to learn about Bluetooth).
>
> Yes - that's an interesting direction.
>
> I'm also pretty un-knowledgeable about Bluetooth. I don't think there
> are Bluetooth flash memory drives or anything though. A quick search of
> Bluetooth devices suggests that just about the only things people are
> using this interface for is cellphone hands-free operation and wireless
> audio headsets.
Kev
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Mon, 9 Jan 2006 14:59:51 GMT
"Kevin L. Clague" <kevin_clague@yahoo.com> wrote:
> Well, *any* machine is harder to program at machine code level. If
> you mean assembly, I diagree. I spent the first 18 years of my
> career on IBM mainframes, and the last 5 on SPARC machines. They
> each have their advantages and disadvantage from a programming
> perspective. CISC machines have less registers (including Intel X86)
> and are harder to program because of this.
>
> ARM7 has a nice number of registers that is much larger than those in
> an Intel box.
That could have something to do with the fact that the x86 architecture
is extremely low on registers, pretty much all of which have special
functions (CX for counting, BX for addressing, AX:DX for
multiplications, SI+DI for memory copying). Compare this to the 68k
family, a CISC platform which starts out with 8 address and 8 data
registers. I've only seen fewer than the x86 on the 6800, which is
remarkable in that it has about 3 registers. That was tight enough that
GCC *couldn't* generate code for it, instead the gcc 68hc11 target
actually uses the low area of RAM to emulate registers (which isn't
that far off, as the 6800 typically contains that ram on-chip and has a
special addressing mode for them).
The H8 in the RCX is a 16-bit CPU, and couldn't really have worked with
much more memory than the RCX had - the 32KiB included was impressive,
and covers half the addressable space.
It also seems rather clear to me that Lego is operating on a tight
budget currently, so there was no real option to toss in an "expanded"
variant yet. We're half a year from product launch, and already people
worry about the product *line* being limited?
Bluetooth, protocol wise, is a bit of a mix between IrDA and USB. It
was not intended for storage devices, and in fact a device like a usb
flash drive would be complicated for the NXT to access - you'd be
dealing with file systems and block I/O. The same issues would be
associated with all the other memory card types.
Bluetooth networking is essentially PPP based, and as with the RCX the
protocol would probably be considered overkill. There's no need to run
IP or Ethernet when the lower level protocol already gives us
addressing and discovery.
We can expect the base library to be limited to the minimum necessary,
which would be just serial-style connections. This would straight away
give communication with phones, computers, GPS receivers and other NXTs.
The particular improvements over the IR sported by the RCX are
reliability, speed, and multiple connections. That last bit is the one
we might not see much of in the official software, but there *will* be
others.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Another possibility for the grinder bunch is seeing if the onboard flash chip can be
SMT desoldered and replaced with a larger capacity model with the same pinout.
I'm assuming there will be various third-party OSes to run on NXT pretty quickly, so
even if the onboard NXT OS can't be persuaded to recognize the expanded flash, other OSes
might.
The same goes for modding the USB controller, and possibly the onboard RAM. We'll just
have to wait and see what we're given, and what we can do with it.
--
Chris 'Xenon' Hanson | Xenon @ 3D Nature | http://www.3DNature.com/
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, Kevin L. Clague wrote:
> Game consoles always *have* to be very agressive in their technological
> progress. They basically give away the hardware, and make money on games.
>
> This business model does not apply here, so LEGO can't afford to keep up with
> the most advanced technology and keep their selling cost as low as it is.
Kevin, does that have to be true though? I'm wondering if a better strategy
would have been to sell the NXT Core kit at a slight loss but try to make it up
on expansion sets? (sort of like the game console market)
Give the NXT more capabilities that would expand the audience of the set to not
just kids and hard-core Lego fans, but a whole different kind of fanbase. I'm
not sure what those added/extended features are (I'm not talking about more
memory per say but high-level functionality that may require more resources such
as in-core memory) yet, but it seems to me at first glance that the NXT set is
an improved Mindstorms with the same business mindset (entice kids who played
with Legos as little children to continue using Lego products as they become
pre-teens/teens).
Anyway, it just a thought...
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Alexander Sack wrote:
> Kevin, does that have to be true though? I'm wondering if a better strategy
> would have been to sell the NXT Core kit at a slight loss but try to make it up
> on expansion sets? (sort of like the game console market)
I doubt it -- for game consoles, the computer is useless without the 'expansion
sets'. For Mindstorms, most consumers will be happy with the basic product;
expansion sets are add-ons, not required purchases. I don't see a way to
transform Mindstorms into a model of "give away the durable item to profit from
sales of multiple consumable products."[1]
--
Steve
1) Game software being consumable in the sense that you'll only want to play the
same game for so long.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Steve Bliss wrote:
> In lugnet.robotics, Alexander Sack wrote:
> > Kevin, does that have to be true though? I'm wondering if a better strategy
> > would have been to sell the NXT Core kit at a slight loss but try to make it up
> > on expansion sets? (sort of like the game console market)
>
> I doubt it -- for game consoles, the computer is useless without the 'expansion
> sets'. For Mindstorms, most consumers will be happy with the basic product;
> expansion sets are add-ons, not required purchases. I don't see a way to
> transform Mindstorms into a model of "give away the durable item to profit from
> sales of multiple consumable products."[1]
That's a really good point. I suspect LEGO feels that the basic, core set
should cover all the bases to make access to Mindstorms/NXT easier for kids and
their parents.
Though there still maybe avenues in the future to offer a more advanced core set
that allows for expansions and add-ons.
-aps
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
> Bluetooth devices suggests that just about the only things people are
> using this interface for is cellphone hands-free operation and wireless
> audio headsets.
And GPS... *drools*
But the bot must be outdoors :(
| | | | | | | | | | | | | | | | | | | | | | | | | |
> The point is that having such an incredibly small amount of memory
> (by modern standards) forces you into ugly compromise solutions from
> your shiney new system from day #1.
Yup. For my solution, you need ugly byte operation. Not good for a 10
year old. Still, with these robots you often design the environment to
suit your limitations (eg. smaller room)
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> the NXT *surely* has 128Mb and not 128Kb.
Where did the 128Kb number come from?
First of all, whether it is standard or not, I like to use a capital "B" to
indicate bytes (or spell out byte) and a small 'b' to indicate bits. So, based
on the Lego NXT Faq, the NXT brick has 256KB(ytes) of FLASH plus an additional
64kB(ytes) of RAM. Thats a total of 2.5Mb(its). I'm not sure where the 128kb
that you mention comes from?
At any rate, it seems like having 10 times the memory of the RCX (not counting
the small FLASH and RAM that is used by the 8-bit microcontroller in the NXT) is
quite a good step. It seems like many valuable applications will work within
those bounds. Certainly there are applications that can be conceived in which
this is not enough memory. Then again, there are some that can be conceived in
which even 128Mbytes is not enough.
Mike
| | | | | | | | | | | | | | | | | | |
I am not very familiar with the NXT platform but as it sounds now could you
possibly plug a USB Flash memory stick into the USB port (or connector) on
the NXT and use it for data storage?
- John
> > Some flash is nice but 64K RAM is just too little. We can forget about
> > doing
> > voice processing.
>
> 64K RAM!? That's absolutely ludicrous! The RCX has 32kb entirely of
> programmable memory (if I remember correctly), and that is just alright.
> 64kb is not much space to work in at all in this era!
>
> Anyway, a dot-matrix display is nice, as is Bluetooth (especially as it
> can communicate between robots), and should be significantly more
> reliable than Infrared (albeit probably more power hungry).
>
> William.
>
| | | | | | | | | | | | | | | | | |
In lugnet.robotics, John O'Keefe wrote:
> I am not very familiar with the NXT platform but as it sounds now could you
> possibly plug a USB Flash memory stick into the USB port (or connector) on
> the NXT and use it for data storage?
Isn't there an inherent problem with this idea? If the NXT is a slave device, it
is a power consumer, right? That would imply that if you connected a USB storage
device, the device would not get power, since the NXT won't have been designed
to source power, just consume it.
JB
| | | | | | | | | | | | | | | | | |
Subject:
|
Re: mindstorms NXT
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 9 Jan 2006 02:13:28 GMT
|
Original-From:
|
steve <(sjbaker1@airmail)spamcake(.net)>
|
Viewed:
|
8061 times
|
| |
|
John wrote:
> I am not very familiar with the NXT platform but as it sounds now could you
> possibly plug a USB Flash memory stick into the USB port (or connector) on
> the NXT and use it for data storage?
As we currently understand things, the USB port is a 'slave' port - not
a 'master' - so you can plug the NXT into a PC - but you can't plug
things like thumb drives into the NXT because that would be plugging a
'slave' USB device into another 'slave' - and USB doesn't allow that.
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> John wrote:
> > I am not very familiar with the NXT platform but as it sounds now could you
> > possibly plug a USB Flash memory stick into the USB port (or connector) on
> > the NXT and use it for data storage?
>
> As we currently understand things, the USB port is a 'slave' port - not
> a 'master' - so you can plug the NXT into a PC - but you can't plug
> things like thumb drives into the NXT because that would be plugging a
> 'slave' USB device into another 'slave' - and USB doesn't allow that.
Right, see my other post about ARM7 and USB (I wish I knew how to link it but
this web interface is killing me!). The biggest issue is one of the devices
would have to implement a host constoller interface and a USB storage class
driver. Typically slave devices do not have the resource bandwidth for either.
My guess is the USB device is really for flashing the firmware and controlling
the NXT from your desktop (though there maybe other use cases I'm not thinking
about).
Another idea floating around was to use an iPAQ likes substance. That won't
work since typically PDAs (well last I checked) were not capable of being a host
(I had Linux running on my iPAQ for quite sometime and even wrote some doc for
the Debian version).
I believe the most potential for controlling the NXT is bluetooth. It would be
SO COOL to be able to remotely control and collect data in real-time. I am not
as familiar with bluetooth as I am with USB but I do have the specs somwhere
(they maybe open anyway - I know the IEEE1394/Firewire stuff wasn't open and had
to use at one point my student IEEE membership to grab them).
Hope this is helpful!
-aps (Alexander)
| | | | | | | | | | | | | | | | | | |
| |
|
I'm somewhat bemused by the comments on limited memory, CPU
capacity, features, etc on the new NXT brick.
At $250 it fits right in the middle range of the other
popular consumer hobbyist robotics kits which range in price
from $100 to $500. These kits include the Parallax Scribbler
($100), the Parallax Boe-Bot ($150), the Radio Shack VEX
($300 kit + $150 for software) and several less popular /
less well-known products.
The VEX and Scribbler have both been on the market for less
than six months so they represent a good data point for
price and feature comparison. The NXT product appears to
blow them both away.
Scribbler is lowest priced at $100. But it is not a kit.
It's a pre-assembled robot. Feature set is awesome - two
motors, line follower detection, sound, infrared distance
sensors - for this price. But there is absolutely no
customization. You can use preloaded programs or write your
own. It's brain is a Parallax Basic Stamp. I think there's
less than 256 bytes of RAM in a Basic Stamp. The version
used in the Scribbler is a masked-ROM Microchip PIC CPU. PC
programming connection is via RS-232 cable. The RCX is a
better / more flexible system than this.
The VEX system is essentially an erector set with
electronics. It comes with two motors, two servos, two bump
sensors and an awesome RF system. It has a host of optional
sensors. But it's really expensive. It uses dual PIC 18F8520
CPUs; this is a 8-bit CPU with less capacity than the H8 in
the RCX. One processor is for system functions and one is
for user programs. There's a total of 32K bytes flash and
1.8K of RAM. PC programming connection is via RS-232 cable;
a USB-to-RS-232 adaptor is included with the VEX kit. It's a
nice system and very robust mechanically but everything
takes ages to assemble using nuts and bolts. It's very hard
to program.
When you compare the announced specs of the NXT, the
difference is dramatic. More RAM, more flash, 32-bit vs
8-bit CPU, great LCD display vs none, high speed USB link vs
serial, integrated Bluetooth wireless, etc.
| | | | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Dick Swan wrote:
| |
Scribbler is lowest priced at $100. But it is not a kit.
It’s a pre-assembled robot. Feature set is awesome - two
motors, line follower detection, sound, infrared distance
sensors - for this price. But there is absolutely no
customization. You can use preloaded programs or write your
own. It’s brain is a Parallax Basic Stamp. I think there’s
less than 256 bytes of RAM in a Basic Stamp. The version
used in the Scribbler is a masked-ROM Microchip PIC CPU. PC
programming connection is via RS-232 cable. The RCX is a
better / more flexible system than this.
|
I hadn’t looked at the Scribbler prior to this post...
and I am stunned at how much their programming language (Scribbler Program Maker
GUI) resembles the original RIS software:
I’m guessing that they designed theirs on the “success” of the RIS...
-Rob A>
| | | | | | | | | | | | | | | | | | |
In lugnet.robotics, Alexander Sack wrote:
> Right, see my other post about ARM7 and USB (I wish I knew how to link it but
> this web interface is killing me!).
It's simple. For a message in plain text (i.e. not FTX) simply paste your link,
the Lugnet web interface automatically inserts hyperlink code.
-Orion
| | | | | | |
