java programming for microcontroller.

[anand]

please anybody tell me if we can program ATMega-32 micro-controller in JAVA.  if so which coder software can i use.

[newInRobotics]

Hi

To my knowledge there are no widely used Java compilers for AVR uCs. To run JavaVM on a microcontroller is not very efficient (if possible at all) and to compile Java code to native machine code defeats the purpose of Java apps being portable. Why do You want to use Java anyway? Atmel provides very good development tools and resources for C.

[anand]

HI newInRobotics,

Actually i have an experience of coding  AVR microcontroller in C, but now i am learning JAVA programming (especially for machine learning and computer vision task). As i want to build a complete embedded system (Robot), i wish to use Java programming for all purpose. java has got a rich classes for such purpose and an ease in mathematical calculations, so i thought can't i use java instead of C for programming AVR.     the other thing is can't i translate java coded program to C and then to hex for AVR?...  please help me in detail  because i am a beginner in JAVA and  might be asking silly questions..!!!

[joe61]

The biggest problem is that AVR chips don't have enough memory to put a JVM into, much less hold programs and data that typically come with a Java program.

You might look at some of the ARM processors, many of them are capable of running Linux, and would be able to suppoprt java to some extent.

Joe

[genom2]

Hello,

may be this is the right thread to introduce HaikuVM.

HaikuVM at its core is just another JAVA VM for micros (I began with AVRs). The point here is, that I decided to go without building an own JAVA runtime. Instead HaikuVM is tailor made to use the leJOS runtime.

HaikuVM has been started to program my ARDUINO based robot in JAVA.
Yes, with HaikuVM you can program an ARDUINO with JAVA!

For those who ever wanted to let the LED of an ARDUINO blink in a parallel thread. This is how it works:

Code: [Select]

package arduino.tutorial;

import static haiku.avr.lib.arduino.WProgram.*;

public class BlinkWithThread extends Thread {
    static byte ledPin = 13;            // LED connected to digital pin 13

    public void run()                   // run over and over again
    {
        while (true) {
            digitalWrite(ledPin, HIGH); // sets the LED on
            delay(1000);                // waits for a second
            digitalWrite(ledPin, LOW);  // sets the LED off
            delay(1000);                // waits for a second
        }
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        pinMode(ledPin, OUTPUT);        // sets the digital pin as output
        new BlinkWithThread().start();
    }
}

HaikuVM works by compiling JAVA bytecode to C code to be finally compiled by a C cross compiler for your target platform. So, the resulting code is small and fast.

Software which you need:

• JAVA 1.6
• WinAVR (C cross compiler for AVRs)
• HaikuVM
• Eclipse IDE (optional)

Features:

• Preemptive threads
• Exceptions
• Synchronization
• double and float support
• Arrays, including multidimensional ones
• Recursion
• Garbage collection
• Supports inheritance and interfaces
• Runs on AVR ATmega8, AVR ATmega328p (and Windows, UNIX)
• Configurable 64, 32 or 16 bit data types including half precision float
• Configurable 16 or 8 bit char type
• Tested with Suns JAVA 1.6
• Zero Assembler Code
• Requires only down to 5k Bytes of code memory (includes HaikuVM and your Java program)
• Needs only 250 Bytes RAM (the rest is for your JAVA application)
• About 55k Java opcodes per second on 8 Mhz AVR ATmega8

[Vendra]

Hi, When i was at high school there was an informatic class about "javarobot" i think they use lego NXT with java. I'm not sure about that but, I'f you're interested, I can get more information. Let me know

[genom2]

Hello Vendra, this is exactly what HaikuVM is all about: bringing JAVA skill and leJOS down to AVR based robots. Where leJOS is a JAVA runtime and a toolset for lego NXT which allows Lego Mindstorms robots to be programmed in JAVA. HaikuVM is a toolset to build your AVR based "javarobot".

[jwatte]

All those nice libraries in Java use way too much resources to fit on a microcontroller. They are designed for full-size processors.

If you already know C/C++ and need libraries for general programming, and for robots in particular, try looking at some of the available libraries:
C++ Standard Template Library (part of the language)
OpenCV (vision)
BOOST
ROS (Robot OS)

[genom2]

For me it's more fun to use JAVA especially when it comes to multithreading or when it comes to code size. Because JAVA bytecode tends to be 4 times shorter than compiled C code for an AVR (@jwatte so it's C which 'use way too much resources'). In other words, if you write a C program which needs 8k flash (which is a complete ATmega8) an equivalent JAVA program only consumes 2k flash (leaving more than enough space for the (Haiku-)VM). I think this small code size comes from the fact that JAVA was originally designed for micro-controllers of the 90th.

@jwatte: BTW this thread is about ATMega-32 micro-controller (and JAVA). I never have heard, that ROS (Robot OS) runs on ATMega-32.

[jwatte]

I never have heard, that ROS (Robot OS) runs on ATMega-32.

Well, there are ROS slave devices that run on Atmega. But the actual suggestion was that, if you're going to run on a machine where the "nice Java libraries" are available, then you might as well run with C++, because it, too, has "nice libraries."
The specific quote from the original poster was this:

java has got a rich classes for such purpose and an ease in mathematical calculations

Which I translated to "nice libraries."

Doing computer vision on an Atmega? Not gonna work, no matter what the library and language!

it's C which 'use way too much resources

I was actually talking about the libraries, not the language. If you want a really compact language, try tokenized Forth :-)
If a VM or interpreted language of some sort hits your performance goals, but all means, use it as code compression!

[genom2]

I'm even more confused. Now I understand that your post is focused on libraries not on language. Ok, I put OpenCV, BOOST and ROS aside because they are not made for AVRs in mind. But what is the rest of your post saying? Are C libraries bigger or smaller than JAVA libraries? Or are they smaller because they include less functions than equivalent JAVA libraries? What's your point here?

Forth: Do you know an AVR port of Forth? If so and when it comes to the fun-part: Does Forth support multithreading?

[jwatte]

Are C libraries bigger or smaller than JAVA libraries? Or are they smaller because they include less functions than equivalent JAVA libraries? What's your point here?

My point is that the stated reason to want to use Java was to use the nice support that comes with the language (which is mainly in the form of libraries.) Thus, I was saying that Java with those libraries won't fit on an AVR. Just like C++ with the large C++ libraries won't fit on an AVR.

Forth: Do you know an AVR port of Forth? If so and when it comes to the fun-part: Does Forth support multithreading?

I do not know of a Forth port for the AVR that supports multi-threading.

In fact, I know no system for the regular AVR-8 chips (like the Arduinos) that support multi-threading, because there is too little RAM to fit much of any stack. You *can* do a multi-threaded system if you can keep the total size of all stacks to something small, like each stack is only allowed 64 or 128 bytes total, and you can only have some small number of threads total, like 4 or 8. Note that the stack size is the total size of all the local variables in all the functions on the call stack, and the AVR does not have a MMU or other hardware to help you detect if you use more than available. And the total amount of RAM in a typical AVR (Arduino style 328p) is 2 kilobytes (2048 bytes.)

I think you're simply trying to use the wrong tool for the job. An AVR microcontroller is great for generating low-level control signals to some number of peripherals, like motor drivers, servo drivers, etc. It can also read and analyze some number of hardware inputs, like buttons, distance sensors, analog voltages, etc. It cannot do anything that requires any real amount of RAM (such as audio, picture, or video processing) nor anything that requires high amounts of signal processing. Using floating point, for example, is emulated, and you can only do a few thousand multiply-add operations with floating point numbers per second.

If you want to do things with pictures, video, and similar, you need an embedded computer with significantly more resources, both for CPU and for RAM. An example is the BeagleBone. Another example might be the Raspberry Pi (less capable than the BeagleBone, though.) A third example is a mini-ITX based small PC computer. On those computers, you can use threads, and do signal/image analysis/processing, and use pretty much whatever language and libraries you want, including multi-threading. (The BeagleBone even has multiple cores IIRC.)

[genom2]

This is what I thought - your were kidding in your reply #9: There is no Forth for AVRs  .
On the other hand, there are some guys who bring C based multi-threading to AVRs (eg. Arduino style 328p). But all these approaches are proprietary and follow no standards (as far as I know). But JAVA sets a standard for multi-threading and HaikuVM follows this standard. Of cause resources are restrictet on most AVRs. But up to 5 threads run like a charm on ATmega328p with HaikuVM (even with these restrictions). And 5 threads - in my experience - are a lot for robots which are based on ATmega328p.

[jwatte]

5 threads - in my experience - are a lot for robots which are based on ATmega328p.

There is only a single execution unit on the AVR. You only need one thread to fully utilize the system. The only reason to use threads is if you somehow think the overhead is worth the ability to keep state on the stack instead of writing explicitly static/continuation-passing code.

Given the small size of the AVR, keeping track of continuation-passing code is typically very simple, so I see no real benefit from threads.

Don't get me wrong; I love threads when used appropriately! In the late '90s, I was part of a start-up that tried to displace Microsoft on the desktop by applying better threading to a GUI and kernel! (We didn't succeed ;-)
But an AVR8 is not a place where threads are appropriately used IMO. In properly constructed software, you need one thread per execution unit to achieve parallelism. Anything more is just trading scarce resources for the ability to be lazy, and/or work around broken system interfaces.

[genom2]

It's more about convenience, readability, scalability and standards. When it comes to parallelism then threads vs. state-machines is like C/JAVA vs. Assembler. I'm not argueing against state-machines or Assembler but in most cases (not all) the benefit is small compared to C, JAVA and threads.

As a simple example for parallelism take this:

Code: [Select]

...
public class BlinkWithThread extends Thread {
    static byte ledPin = 13;            // LED connected to digital pin 13

    public void run()                   // run over and over again
    {
        while (true) {
            digitalWrite(ledPin, HIGH); // sets the LED on
            delay(1000);                // waits for a second
            digitalWrite(ledPin, LOW);  // sets the LED off
            delay(1000);                // waits for a second
        }
    }

    private static long fib(int n) {
        if (n < 2)
            return 1;
        return fib(n - 1) + fib(n - 2);
    };

    public static void main(String[] args) {
        pinMode(ledPin, OUTPUT);        // sets the digital pin as output
        new BlinkWithThread().start();

        for (int i = 0; i<20; i++) {
            Serial.print(i);
            Serial.print(' ');
            Serial.println(fib(i));
        }
    }
}
Albeit it's possible to express this with a state-machine but it becomes ... at least ugly. Looking at the implementation of the Fibonacci function fib(..), you might argue, recursive solutions are evil on micros (and stresses 'the ability to be lazy') but take this function as an example for a tilt-compensated-compass-module function (for robot orientation) where other function calls are deep nested (keywords: read from Two Wire interface; vector operations like cross, dot and normalize; sqrt; atan2; round).

And now (keyword: scalability) think of merging (a more robot-realistic number of) 5 threads into a state-machine. This is horror, even if you use tools like Quantum Leaps state machine platform.

Today, because C compilers are martured, only few reasons exists to use Assembler (even for resource restricted robots).
Maybe, if JAVA for micros become more popular then only few reasons exists to use state-machines to solve parallelism.