Intel Galileo Board

[Mxt]

Nein, so kann das nicht gehen. Da gibt es keine .c Dateien auf der Zielplattform, insbesondere keinen C-Compiler.

Das Linux ist übrigens nicht mal LSB kompatibel, man kann keine Binärdateien von anderen PC Linuxen laufen lassen.

[Peter(TOO)]

Hallo,

Vielleicht habe ich mich ungünstig ausgedrückt. Das Ding ist ein PC mit Pentium Prozessor. Deshalb läuft auch Windows drauf. PCs haben keine solchen Timer wie AVRs.

Ja, die Timer sind da etwas einfacher gestaltet.
Es sind beim PC aber 3 oder 6 16-Bit Timer vorhanden, welche Interrupts auslösen können.
Über den Interrupt-Controller können den Timern dann auch eigene Interrupt-Vektoren zugewiesen werden.

MfG Peter(TOO)

[HaWe]

die x86-Intr kenn ich sogar noch aus alten DOS-Zeiten!
Dabei würden für Sketch-Programme schon 1-2 ausreichen, auf die man manuell Zugriff hätte.
Z.B. eben, um Quadraturencoderstellungen im 250µs-Takt auszulesen und dann die Motorencoderstellung zu berechnen.
Aber wie?

[Mxt]

Es haben wohl schon Leute daran gearbeitet FreeDOS auf dem Galileo zum Laufen zu bringen. Das ist aber nicht ganz so einfach, es ist zwar ein Pentium aber natürlich mit UEFI statt BIOS.

Wie dem auch sei, die MS iot Variante werde ich weiter im Blick behalten, vielleicht kommt die demnächst auch für bessere Hardware. Was ich ursprünglich mit dem Galileo machen wollte läuft mittlerweile sehr erfolgreich mit einem LPC4088.

Falls im Frühjahr das Renesas Peach auch in Europa verkauft wird, gibt es dann auch mbed Boards mit 400 MHz. Und ST Boards mit Cortex M7 kommen sicher auch noch ...

[Mxt]

Anderes Thema ist Multitasking.

...

Wie ist also MT bei Galileo-Sketch geregelt?

So, der Galileo läuft wieder, daher kann ich hier neues vermelden:

Ja, wenn der Galileo mit Windows iot läuft, geht C++11 Multithreading, hier ein Stück Code aus einem Visual Studio Projekt

#include "stdafx.h"
#include "arduino.h"

// Diese beiden Funktionen sollen parallel zum Blink Sketch laufen.
// Im Moment tun sie nicht viel, sie schreiben nur in Debug Ausgabe Fenster von Visual Studio.

void Worker1()
{
    while (true)
    {
        Log("Eins\n");
        Sleep(1000);
    }
}

void Worker2()
{
    while (true)
    {
        Log(L"Zwo\n");
	Sleep(2000);
    }
}

// Hier startet das Programm

int _tmain(int argc, _TCHAR* argv[])
{
    // Starten der beiden Threads
    std::thread t1(Worker1);  
    std::thread t2(Worker2);

    // Starten des Blink Sketch
    return RunArduinoSketch();
}

// Am Rechner ist eine RGB-LED ...

int ledRed = 11;
int ledGreen = 6;
int ledBlue = 10;

void setup()
{
    pinMode(ledRed, OUTPUT);       
    pinMode(ledGreen, OUTPUT);
    pinMode(ledBlue, OUTPUT);

    digitalWrite(ledRed, LOW);
    digitalWrite(ledGreen, LOW);
    digitalWrite(ledBlue, LOW);
}

// the loop routine runs over and over again forever:
void loop()
{
    // Einfaches Blink Beispiel

    digitalWrite(ledRed, HIGH);
    delay(1000);
    digitalWrite(ledRed, LOW);
    delay(1000);

    // Das funktioniert auch im Sketch-Teil, std::thread macht hier aber Probleme (Absturz)
    std::async(std::launch::async, []{ Log(L"Drei\n"); });
}

[HaWe]

danke für die Info!
denkst du, der Bug unter Sketch ist zu fixen ?

[Mxt]

Ich denke das ist nichts schwerwiegendes. Außerdem ist es ja ein öffentlicher Betatest ...

Wahrscheinlich sind die Arduino IO Geschichten ohnehin nicht dazu gedacht parallel benutzt zu werden. Dazu sind die IOs des Galileo auch viel zu langsam. Multithreading ist also eher etwas für große Berechnungen im Hintergrund.

Außerdem ist es Windows, man kann sich auch mit CreateThread (WinAPI) oder _beginthreadex (Visual C++ Runtime) versuchen. Auch kann man nicht nur Threads starten, auch andere .exe-Dateien, die APIs CreateProcess (entspricht Start->Ausführen) und ShellExecute (entspricht Doppelklick auf Datei) werden auch gehen.

Was schon geht ist die Concurreny Runtime, wie man in diesem Beispielsketch sieht:
http://ms-iot.github.io/content/Casablanca.htm
Das ist dann schon richtiges C++11 in einem Sketch  

Man sieht da auch schön die Zielgruppe von Galileo und Tre. Das ist eher was für die Maker, die den Zustand ihrer LEDs twittern wollen. Wenn Dir der Due nicht mehr reicht, wirst Du meiner Meinung nach nicht herumkommen eine andere Plattform zu wählen. Und da dürfte mbed am nächsten an den Anforderungen liegen.

[HaWe]

Auf Windows-Compiler-/WinAPI- und .NET-Ebene schreibe ich keine Programme, ich nutze den Dinosaurier VS ebensowenig wie das Monster Eclipse: NET finde ich ebenso zum Kotzen wie Eclipse mit gpp und makefile und gdb, von ssh und putty ganz zu schweigen.

Auch das Casablanca ist schon wieder 3 Nummern zu kompliziert, und die Tatsche, dass der Galileo grad mal sowenige IO pins hat wie ein Uno macht ihn auch kaum nutzbar, zumal die Pins nicht alle echtzeitfähig sind.

Vom Tre liest man auch nicht viel und von den devs dort auch generell nichts Gutes, was Bugfixes und Driver-Updates angeht: bereits seit Jahren werden da wohl welche längst berichteten Fehler ignoriert, selbst wenn Lösungsvorschläge existieren. Die Stimmung in der Community ist auch alles als freundlich und hilfsbereit, vllt gerade deshalb.

Der BBB wird allgemein noch empfohlen, die IOs sind zahlreich, und es läuft ja sogar schon eine Lego-Labview-VM samt kompatiblen IO Ports auf dem TI Linux (was mich nicht so antörnt, aber immerhin).

http://www.legomindstormsrobots.com/...glebone-black/

https://www.youtube.com/watch?v=1ZUc22_5OJU

Mit welcher IDE wird denn der BBB programmiert? (Simpel und downstripped, hoffe ich ?)

(ps, auch C++ nutze ich nicht, generell auch kein OOP, erst recht kein C# oder Java (*würg*), nur straight-ANSI-C.
Wenn man den C++ Part allerdings so gut versteckt wie bei Sketch. ist es absolut ok.

Aber mit :: und -> kannst du mich jagen!!  

[Mxt]

Mit welcher IDE wird denn der BBB programmiert? (Simpel und downstripped, hoffe ich ?)

Ich schreibe meine Programme für den BBB mit Notepad++ unter Windows, übersetzen tue ich dann auf dem BBB, da habe ich mein Standardmakefile, was ich nur wenig anpassen muss. Kopieren zwischen beiden geht mit WinSCP, eine Art "Norton Commander" im Netzwerk.

Was Arduino angeht, auf eine größeren Controller als den Due würde ich nicht spekulieren, dagegen spricht auch diese Pressemitteilung vom Oktober
http://ir.atmel.com/releasedetail.cfm?ReleaseID=874101

[HaWe]

die Zielrichtung hinter der Pressemitteilung verstehe ich jetzt nicht, aber wenn das heißt : es wird wohl so schnell nichts, dann reicht mir das für den Moment.

Im Prinzip geht es mir um 2 Dinge:
schnelles ansteuern von Encoder-Motoren, i.P. mit L293/L298 oder ähnlichen H-Brücken,
und dann um Sensoren wie entweder standard-I2C und/oder ADC für Sharp GP2D12 IR etc.

Wichtig ist mir Standard-C, kein C++ o.ä.

Damit du siehst und vllt besser verstehst, auf welchem simplem Programmier-Level ich programmiere, hier 3 Links - einmal Sketch mit C und NXC (Multiplexer), einmal Sprachrythmus-Wort-Erkennung (NXC) und einmal neuronales Netz (NXC):
(Nicht wundern über NXC, es ist Not_eXactly_C, eine Text-Adaptation für den NXT)

http://www.mindstormsforum.de/viewto...&t=8302#p65015

http://www.mindstormsforum.de/viewto...t=6386&p=53924

http://www.mindstormsforum.de/viewtopic.php?f=70&t=6620

Auf diesen simplen C-Level (eben wie Sketch C) möchte ich nun leistungsfähigere Programme schreiben, die diese Teilprogramme und Module vereinen und erweitern, mit schnelleren Prozessoren und viel mehr RAM und permanentem Flash...
nur ich möchte mich auf die Motor-Justierung und die KI konzentrieren, nicht erst die Hardware neu programmieren müssen...