Intel Galileo Board

peter-too-
liest du eigentlich die topics, bevor du postest?
Das hat doch nun wirklich überhaupt nichts mit meinem Thema zu tun!
Bitte bleib etwas mehr on-topic und reduziere deine OT-Geschichts- und/oder -Technik-Exkurse etwas !

Hier geht es um (wie Arduinos) mit Sketch programmierbare Galileos, oder notfalls (kommende) mit Sketch programmierbare Sitara- Arduinos und insb. um Timer-Interrupts und Multitasking Libs dafür.

- - - Aktualisiert - - -

ps, @mxt:
der LPC4088 mit seinen nur 512 kB Flash-Programmspeicher und 96 kB SRAM wäre mir eigentlich zu schwach auf der Brust.
Der Lego EV3 hat 16 MByte Flash und 64 MByte RAM plus bis zu 16 GB SD Speicher, das hätte dann eher die nötige Kragenweite.

Sowas mit Sketch programmieren, mit MT und mit Timer-IRQs und mit mind. 50 DPins bzw. GPIO pins (wie Mega oder Due), das ist es was ich suche ...
ob es dann Galileo, RPi, Lego, BBB oder Tre heißt, das wäre mir völlig egal.

Zitat:

---

Zitat von HaWe

ps, @mxt:
der LPC4088 mit seinen nur 512 kB Flash-Programmspeicher und 96 kB SRAM wäre mir eigentlich zu schwach auf der Brust.

---

Das EA LPC4088 Quickstart Board hat 32 MB externen SRAM über ein 32 Bit Interface an den Controller angebunden, außerdem 8 MB externen Flash über QSPI. Alles große was man auf dem Heap anlegt, also mit malloc bzw. new landet im externen Speicher.

Code:

---

#include "mbed.h"
#include "sdram.h"
 
int main (void) {
    void* a, b, c, d, e;
    if (sdram_init() == 1) {
        printf("Failed to initialize SDRAM\n");
        return 1;
    }
 
    a = malloc(        1024); // will be from internal RAM
    b = malloc(  1024*1024); // will be from SDRAM as it is too large
    c = malloc(15*1024*1024); // will be from SDRAM
    d = malloc(15*1024*1024); // will be from SDRAM
    e = malloc(15*1024*1024); // will fail as there is not enough heap left
 
    // deallocation goes here...
}

---

Ich erreiche über Ethernet vom PC aus Schreib- und Leseraten von 6,9 MByte / s auf das Board. Das ist schon ganz ordentlich.

das klingt ja doch sehr ordentlich!
Kann man es mit Sketch programmieren oder mit welcher IDE machst du das?
(Ethernet werde ich allerdings nicht verwenden wollen)

ps,
kriegt man da 50x D/GPIO pins mit 8x pwm und 16x pins per timer-IRQs + slave-I2C + SPI wie beim Mega/Due, ggf. durch ein multi-I/O expansion board? ?

Das Board wird über die mbed Online IDE programmiert. Die ist nicht so unterschiedlich zu Arduino. Da kann man sich in ein paar Tagen umgewöhnen.

Alternativ kann man offline z.B. mit LPCexpresso programmieren und debuggen (basiert auf Eclipse).

So viele IOs hat das Board nicht, entweder man nimmt da einen Portexpander, alternativ kann man auch Boards wie den Due oder den ST Nucleo über I2C, SPI oder UART anbinden. So komplizierte Sachen teil ich eigentlich immer in unabhängige Teilsysteme auf.

online geht leider nicht, weil ich nicht überall Internet habe wo ich es dann bräuchte, und Eclipse braucht dann sicher wieder gpp mit dem ganzen makefile Krempel -
andererseits brauche ich ja bereits jetzt zu den lokalen 50 dPins mit 8 Encoder-Motoren einen weiteren Mega über I2C, der die ganze Sache verdoppelt.
Jetzt nochmal ein Huckepack-System, das dann auch noch Echtzeitfähig sein müsste (250µs IRQ-Takt), wird mir dann aber zu wackelig und zu aufwändig von der Programmierung.

Bleibt als Alternative dann momentan nur der Tre in Sichtweite, nur da stellt sich die Frage, wie man wohl den AVR und den Sitara IDE-mäßig unter einen Hut kriegen will.

Ein Offline mbed gibt es im Herbst mit mbed 3.0.

Falls der Tre noch auf den Markt kommt, wird er es schwer haben gegen das nächste Beagleboard
http://www.elinux.org/Beagleboard:BeagleBoard-X15

Beagleboard kommt nicht in Frage, es läuft ja nicht mit Sketch und braucht auch direkte Linux-Terminal-Manipulationen.
So was kommt grundsätzlich nicht in Frage, auch kein WiFi.

Nochmal:
Alles, was Eclipse und gpp und Linux-Konsole/Shell und LAN und WiFi erfordert, steht außerhalb jeder Diskussion. Die IDE muss in Funktionalität und Einfachheit gerade auch für USB-Upload und Einbinden von fertigen Libs genau so simpel sein wie Sketch. Und Timer-IRQs und premptives Multitasking bieten.

Der Galileo wäre nur aus 1 Grund interessant gewesen, und das wäre Sketch gewesen, und Sketch ist sicher auch für den Tre wieder ein Thema.

Und in beiden Fällen stellen sich dann genau diese besagten Fragen nach Timer-IRQs und premptivem Multitasking. Das ist das eigentliche Problem.

Nach dem wenigen, was über den Betatest des Tre in Blogs an die Öffentlichkeit gedrungen ist, verwendet der Tre nicht die Arduino IDE. Er hostet die Entwicklungsumgebung selber in Node.js, so wie Cloud9 auf dem Beaglebone.

hmm - das sagt mir leider gar nichts.
Dann bleibt wohl doch nur der Galileo mit Sketch übrig als einzige Due-Alternative mit den ungeklärten Problemen
- Timer-IRQs
- preemptives Multitasking

Zitat:

---

Zitat von HaWe

hmm - das sagt mir leider gar nichts.

---

Mittlerweile tröpfelt da wieder Information herein:
http://blog.arduino.cc/2014/12/12/ar...-beta-testing/

Dort kann man lesen

Zitat:

---

These boards have the latest Web IDE pre-installed and ready to go, we are now at a stable IDE release with everything fully functional. We will write a specific post about the new Web IDE next week, so stay tuned!

---

Der Tre wird also programmiert, in dem man sich auf eine von ihm produzierte Webseite begibt. Über die alte Arduino IDE kann man über USB nur der Leonardo-Teil vom Tre erreichen.

Auf dem ARM läuft erst mal das Linux, mit dem Webserver, wahrscheinlich noch mit einer GUI am HDMI-Anschluss. Der Rest an freier Prozessorkapazität wartet dann sicher nicht darauf, Sketches in Echtzeit auszuführen. Im Worst Case kriegen wir nur etwas langsamen IO-Pin Zugriff über das Linux Dateisystem. Im Idealfall würden die Sketches auf den beiden 32-Bit Mikrocontrollern im Sitara laufen ...