ZitierenWas soll daran kompliziert sein ? Man schreibt seinen Code in ein Textfeld im Browser, genauso wie hier im Forum.
Was soll daran kompliziert sein ? Man schreibt seinen Code in ein Textfeld im Browser, genauso wie hier im Forum.
ach so, für den Tre also nur der Editor als HTML-Seite statt ein anderer Editor?
das ist ntl einfach, stimmt.
Und dann wie weiter?
einfach irgendwie auf "Hochladen" Button klicken und dann läuft der Tre, ganz ohne Extra-Compiler und ganz ohne Linux-Shell?
Das wäre ja super!
Geändert von HaWe (13.12.2014 um 12:21 Uhr)
Hochladen brauch man ja nichts, es ist ja dann alles auf dem Tre. Auch der (oder die ?) Compiler. Da laufen dann irgendwelche Scripte, die den dann ausführen. Wenn da pro Sketch ein g++ für ARM und ein g++ für den AVR laufen, kann man sich in der Zwischenzeit sicher noch gut anderen Hobbies widmen ...
So viel anders als mbed ist das dann auch nicht mehr. Nur das mbed aus dem Internet geladen wird. Was aber auch den Vorteil hat, das man gerade mal blinzeln kann, bis das Programm übersetzt ist ...
ach was, der compiliert auf sich selber mit eigenem Compiler ? Das geht ??
das ist ja ein Ding!
Aber super-praktisch und super-simpel sicher! Dann lass ich mich mal überraschen!
So, der Galileo läuft wieder, daher kann ich hier neues vermelden:Zitat von HaWe
Ja, wenn der Galileo mit Windows iot läuft, geht C++11 Multithreading, hier ein Stück Code aus einem Visual Studio Projekt
Code:#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"); }); }
danke für die Info!
denkst du, der Bug unter Sketch ist zu fixen ?
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.
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!!
Geändert von HaWe (14.12.2014 um 10:59 Uhr)
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
Berechtigungen
Lesezeichen