EV3 Brick Microcontroller Details

[tcwan]

Hi,

It seems like LEGO has been exceptionally vague about the specific details of the EV3 Microcontroller.
From digging around the web, I managed to find out some further details regarding the supposed EV3 Brick Microcontroller (based on references in the EV3 Source repository).

It is apparently a Texas Instrument AM1808 microcontroller.
http://www.ti.com/product/am1808

The TI AM1808 is a ARM926EJ-S processor, which implements the ARMv5TEJ instruction set.
This means that it is possible to execute Java byte codes efficiently (without needing a JIT VM).

Unfortunately due to the use of the ARMv5 instruction set, it is not possible to run some of the more current Linux distributions (e.g., Raspberry Pi based) which require ARMv6 and above.

The interesting thing about the AM1808 is that it comes with two "Programmable Realtime Units" (PRU) which are essentially embedded RISC engines.
http://processors.wiki.ti.com/index.php ... evelopment
While the available memory for the PRU is only 4KB code + 512B data per core, it may be possible to use it to do some interesting DSP related tasks.

I wonder if the EV3 is making use of the PRUs at this moment?
It'd be a challenge for someone to port LLVM to this platform to generate code for the PRUs!

[gloomyandy]

I'm pretty sure the prus are being at least partially used already. The EV3 uses UARTs to talk to some sensor types (most of the new EV3 ones). The 1808 only has two hardware UARTs and these are used for ports 1 and 2 (I think). The other two parts use UARTs implemented via the pru. Take a look in the d_uart code you will see there is code there to use the pru for UART emulation. There is also a pru-firmware directory that I'm pretty sure is the code that runs on the unit.

[gloomyandy]

I don't think the Jazelle stuff really ever worked out. My understanding is that modern JIT compilers give better performance than the ARM extensions. Later ARM cores have pretty much dropped support (they do it via software emulation) for this feature. The good news is that Java SE embedded runs fine on the EV3 which provides the Hotspot JIT. That's what I've been using for my work.

[tcwan]

I'm pretty sure the prus are being at least partially used already. The EV3 uses UARTs to talk to some sensor types (most of the new EV3 ones). The 1808 only has two hardware UARTs and these are used for ports 1 and 2 (I think). The other two parts use UARTs implemented via the pru. Take a look in the d_uart code you will see there is code there to use the pru for UART emulation. There is also a pru-firmware directory that I'm pretty sure is the code that runs on the unit.

Ah, I found it.

Too bad about the PRUs being committed to existing tasks.

[tcwan]

I don't think the Jazelle stuff really ever worked out. My understanding is that modern JIT compilers give better performance than the ARM extensions. Later ARM cores have pretty much dropped support (they do it via software emulation) for this feature. The good news is that Java SE embedded runs fine on the EV3 which provides the Hotspot JIT. That's what I've been using for my work.

Hmm. I have not studied this issue previously so I don't have any specific info. However, I think JIT performance is highly dependent on the micro architecture of the CPU, and for the newer generation ARM Cores (e.g. Cortex), they implement more aggressive Out of Order execution semantics which probably provides a significant boost to native code performance (generated by the JIT).

I'm curious, how much memory overhead is used by the Hotspot JIT to store the compiled Byte Codes?

EDIT:
Found some interesting links:
http://stackoverflow.com/questions/7048 ... rm-jazelle
http://stackoverflow.com/questions/1153 ... technology

Guess the speedup is probably mainly due to the JIT compiler's code optimization capabilities

[ridge-runner]

I am preparing to build some prototype sensors for the EV3 Brick.
The NXT pin out was as follows; pin 1 ANALOG interface, +9V white, pin 2 GND black, pin 3 GND red, pin 4 +4.3V green, pin 5 I2C (SCL) RS-485 B yellow, pin 6 I2C (SDA) RS-485 A blue.

Is the EV3 Brick using any of the lines for sending or receiving sensor data differently? Is line 2 or 3 be used for some other data with the EV3? How does Auto ID work?
Thanks,
John

[schodet]

I am preparing to build some prototype sensors for the EV3 Brick.
The NXT pin out was as follows; pin 1 ANALOG interface, +9V white, pin 2 GND black, pin 3 GND red, pin 4 +4.3V green, pin 5 I2C (SCL) RS-485 B yellow, pin 6 I2C (SDA) RS-485 A blue.

Is the EV3 Brick using any of the lines for sending or receiving sensor data differently? Is line 2 or 3 be used for some other data with the EV3? How does Auto ID work?
Thanks,
John

There are some explanations here: https://github.com/mindboards/ev3source ... d_analog.c

The connection seems to be quite clever so that the EV3 can identify each sensor, even when connected to a wrong port.

[ridge-runner]

Thanks schodet,
I had not looked at the source code files much.
John