Software > Software

java programming for microcontroller.

<< < (3/3)

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:

--- Quote from: genom2 on December 11, 2012, 02:59:35 PM ---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?

--- End quote ---

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.


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

--- End quote ---

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:

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

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: ---...
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));
        }
    }
}

--- End code ---
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.

Navigation

[0] Message Index

[*] Previous page