Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel Galileo Board
klingt eigentlich ganz interessant, zumindest für manche Anwender:
http://www.aliexpress.com/item/Intel-Galileo-Gen-2-development-board-GALILEO-GEN-2-DEV-BOARD-QUARK-5/32244794699.html
Intel Board, aber auf Linux-Basis, programmierbar mit der Arduino-IDE, den man also komplett mit Sketch programmieren kann, so einfach wie sonst Arduinos?
ohne Linux-Shell, Konsole, ssh, putty, Eclipse, makefile, linker oder was auch immer...?
das wäre ja wirklich phänomenal.
Allerdings: nur Uno R3 Pin- und Softare kompatibel, also nur 11 freie DPins.
Das ist allerdings schlecht für Q.-Encoder-Motore, denn da braucht man ja schon jew. für 1 alleine 5 DPins, mit 2 Motoren ist da schon Schluss.
Und je 2 der DPins müssen per IRQs abgefragt werden und 1 weiterer braucht pwm - das macht die Verwendung von Erweiterungsshields für mehr Encodermotore fast unmöglich, oder?
Und dann bleiben leider noch nicht mal DPins für Taster übrig. Das ist schlecht, das reicht ntl. bei weitem nicht, und wohl auch nur 1x Hardware-I2C und vermutlich auch nur 1x SPI.
Aber mal gucken, vllt kommt ja mal irgendwann ein Mega- oder Due-Pinout-kompatibler Galileo.
Hallo,
siehe auch mein Posting hier dazu:
https://www.roboternetz.de/community/threads/65219-Intel-Galileo
Aber mittlerweile habe ich ihn eingemottet. Die aktuelle Intel Software scheitert beim Aktualisieren der Firmware. In den früheren Versionen hat das immer problemlos funktioniert. Deshalb kann ich auch das aktualisierte Windows Image nicht mehr testen.
Windows/VS ist dann allerdings wohl nicht so interessant. Aber die Arduino-Sketch IDE finde ich schon interessant.
Frage, ob dann auch alles mit AVR-Libs wie AVR-IRQs und Timer und sprintf-float-Patch etc. funktioniert.
Halbe Leistung des RPi klingt auch nicht so prall, was heißt das im Vergleich zum Arduino Due?
(Da stellet sich wieder die Frage nach einem benchmark ;) )
edit...:
Haha - für den Arduino Mega und Due gibts ja meinen Benchmark!! :D
- kannst du den mal da drüber laufen lassen? Ist ja 100% Arduino-Sketch! :D
http://www.mindstormsforum.de/viewtopic.php?f=71&t=8095&start=75#p65463
Um ein Haar wäre er Samstag in der Tonne gelandet ...
Wie gesagt, er läuft ja gerade nicht. Die Firmware müsste ja erstmal geupdatet werden ...
Rechnen tut er viel schneller als ein Due. Das Problem sind die IOs. Die sind um einiges langsamer als beim Uno ! Das hat man beim Nachfolger Galileo Gen 2 verbessert, aber es ist immer noch langsam. Microsoft hat da mit seinem neuen "Lightning" Treiber wohl versucht das Maximum herauszuholen.
Der Nachfolger vom Galileo ist übrigens der Edison. Da rechnet ein Dual-Core Atom mit 500 MHz. Die IOs hängen an einem zusätzlichen 100 MHz Quark-Prozessor. Der Weg vom Sketch zu den IOs ist also eher länger geworden. Außerdem verwenden die IOs 1,8 V Logik (!), weshalb man eine Adapterplatine mit Pegelwandlern braucht.
Ansonsten kann ich den Galileo zum aktuellen Wetter sehr empfehlen. Ich habe bisher keinen anderen Bastelrechner gesehen, der so heiß wird ...
Ansonsten kann ich den Galileo zum aktuellen Wetter sehr empfehlen. Ich habe bisher keinen anderen Bastelrechner gesehen, der so heiß wird ... *LMFAO*
vllt ein Kühlkörper oben drauf? 8-)
ansonsten, wenn du ihn mit der Arduino-Sketch FW nochmal aufsetzen könntest...?
Es bleibt ja immerhin auch der Weg per I2C-Mega-Slave und ein nicht so anspruchsvolles Uno-Erweiterungsshield.
Ich wär da schon sehr interessiert.
Je einfacher zu programmieren, desto besser, Linux-Shell und Eclipse und VS sind mir ein absolutes Gräuel.
Immerhin klingt es ausbaufähig...
Minst du, du kriegst den Test hin?
Dann würd ich ihn dir sogar abkaufen, wenn's dann läuft :D
Es ist die Arduino-Firmware die nicht läuft. Intel hat eine eigene Version der Arduino 1.5.3 Software. Da gibt es einen Menupunkt zum Firmwareupdate. Da hat er den Geist aufgegeben ...
och schade.... :(
- - - Aktualisiert - - -
keine Garantie mehr drauf zum Einschicken und reparieren lassen?
Peter(TOO)
09.12.2014, 17:20
Hallo,
Ansonsten kann ich den Galileo zum aktuellen Wetter sehr empfehlen. Ich habe bisher keinen anderen Bastelrechner gesehen, der so heiß wird ...
Das alte Intel-Problem!
Das war schon so, als AMD noch offiziell Secondsource des 8086 gefertigt hatte.
AMD-CPUs benötigten weniger Strom, bei gleicher Taktrate wie ein Intel. Entsprechend konnte AMD seine CPUs mit einem etwas höheren Takt als Intel laufen lassen.
Das war dann auch der Grund für die Auflösung des Vertrages zu Zeiten des Pentiums.
Das selbe Problem gab es auch zwischen Motorola und Hitachi.
Die 680x-Familie gab es nur von Hitachi in CMOS (630x). Zudem konnte Hitachi, mit dem selben Prozess, auch noch EPROM mit auf den Chip packen.
OK, ist alles auch schon gegen 30 Jahre her ....
Der grosse Rechtsstreit zwischen Motorola und Hitachi war dann Anfang der 90er Jahre.
MfG Peter(TOO)
ich find das Teil schon interessant - zum Thema Hitze, wie bereits gefragt:
vllt ein Kühlkörper oben drauf?
was nimmt man da GENAU für einen?
was für eine Wärmeleitpaste?
habe da bisher überhaupt keine Berührungspunkte zu.
ps,
besonders interessiert mich ntl auch die Sache mit den IRQ-Timern bzw den AVR Timer-libs etc.
Für einen Kühlkörper wäre es gut, wenn die Oberfläche eben wäre. Das ist aber ein Metall-Gehäuse mit einer Erhebung in der Mitte. Sieht aber schon so aus, als ob es mit der Wärme klar kommt. Man spürt aber, wenn man einen Finger 1-2 cm drüber hält, deutlich die Hitzestrahlung.
Wahrscheinlich lässt sich das Ding wieder erwecken, eventuell über die serielle Konsole an dem Kopfhörerstecker (!). Aber im Moment beschäftige ich mich lieber mit funktionierenden Rechnern.
hi,
alles klar, danke für die Info!
Ganz wichtig wäre für mich noch zu wissen, wie das Teil mit Timer-IRQs zurecht kommt.
Beim Mega verwende ich AVR-Timer IRQs,
beim Due die DueTimer lib.
Beides brauche ich, um im 250µs-Rhytmus in Echtzeit 12-18 DPins für die Quadraturencoderstellungen abzufragen.
Wie geht das mit den IRQ-Timern aber beim Galileo?
Anderes Thema ist Multitasking.
Beim Due verwende ich die Scheduler lib, weil sie einfach konfigurierbar und steuerbar ist, leider ist das MT nur kooperativ (für die geringen Anforderungen aber ausreichend).
Bei gpp C für Linux (EV3) habe ich auch schon POSIX pthread benutzt, ist auch recht einfach zu handhaben und sogar preemptiv, hier kann man über die Zeitscheiben dann auch sehr langwierige Berechnungen pseudo-parallel und trotzdem quasi in Echtzeit durchführen (parallele Mustererkennungen über FFT und Neuronale Netze oder auch Routen-Neuplanung über Astar, die jeweils ein paar Sekunden dauern können, und trotzdem Echtzeit-Navigation per Odometrie und Sensor-Fusioning mit Kalman bei derweil fahrenden Robotern).
Wie ist also MT bei Galileo-Sketch geregelt?
Das Ding ist ein Pentium, kein Mikrocontroller. Timer IRQs wie beim AVR gibt es da wahrscheinlich gar nicht. Die Arduino-Software für den Galileo implementiert meines Wissens nach gar keine Timer. Aber einige andere Dinge, wie ein Ethernet-Shield, werden simuliert.
Wenn er unter Windows läuft, geht natürlich Windows Multithreading. Aber mit Echtzeit ist unter Windows nicht viel zu machen.
zu den Timer IRQs: auch der Due ist kein AVR, sondern ein 32-bit ARM Cortex, und auch der hat Sketch Timer-IRQ-Libs!
(#include <DueTimer.h> )
Also müsste man doch auch für den Galileo Timer-IRQs erwarten dürfen!
zum MT: was gibt es da fürs Galileo-Sketch? Galileo ist ja Linux-basiert und Sketch verwendet auch (verdeckt) gpp C/C++, und für Linux gibt es POSIX-Libs, die man per gpp C #includen kann -
(#include <pthread.h>)
was geht also hier beim Galileo mit Sketch?
Lade die Arduino IDE runter und probiere es
https://communities.intel.com/docs/DOC-22226
ich habe doch gar keinen Galileo, was soll ich da installieren?
Was ich bräuchte, wäre eher eine Art doxygen-help-files oder ein Programmer's Guide, wo man per Schlagwortsuche entsprechende Programmierbeispiele findet mit Querverweisen etc, ähnlich wie hier für den NXT:
http://bricxcc.sourceforge.net/nbc/nxcdoc/nxcapi/group___command_module_functions_ga7ecb5d6444d6b22 83730af5ddd145b75.html#ga7ecb5d6444d6b2283730af5dd d145b75
In der Arduino IDE gibt es einen Button um das Programm zu checken, ohne es zu übertragen. Damit kannst du zumindest prüfen, ob Sachen wie pthread im Prinzip gehen.
Die IDE wird auch, wie die Zip-Version der normalen Arduino 1.5.x, nur entpackt nicht installiert.
Doku ist auch wieder bei MS besser:
http://ms-iot.github.io/content/SampleApps.htm
http://msdn.microsoft.com/en-us/library/windows/desktop/bg126469.aspx
ach so ist das! Danke, gucke sofort nach!
- - - Aktualisiert - - -
hmmh...
kann da nichts zu Timer-IRQs und Multitasking per Sketch 1.5.3 finden :(
ps,
pthread müsste sich ja auch bereits auf dem Linux-Image befinden, wenn es nicht schon dort ist, geht es nicht (ist iwie ein kernel-Modul oder so, kenne mich damit aber nicht aus).
Was man also bräuchte, wäre eine ganz klare und eindeutige Beschreibung und Anleitung mit Beispiel-Sketchen, wie man IRQs und MT per Galileo-C-Sketch impementiert!
Peter(TOO)
10.12.2014, 14:07
Hallo,
Das Ding ist ein Pentium, kein Mikrocontroller. Timer IRQs wie beim AVR gibt es da wahrscheinlich gar nicht. Die Arduino-Software für den Galileo implementiert meines Wissens nach gar keine Timer.
Das Eine hat mit dem Anderen nichts zu tun.
- Beim Mikrocontroller ist einfach alles auf einem Chip, CPU, RAM, ROM, Und die ganze Peripherie (Ports, Timer, UART usw.).
Der Mikrocontroller ist ein, ohne zusätzliche externe Chips, voll funktionsfähiger Computer.
- Bei der klassische CPU ist nur die CPU auf dem Chip, evtl. noch die Takterzeugung, Memory Management, DMA und Cache. An Eingängen gibts es nur Reset, NMI, IRQ und noch welche um den Bus Freizuschalten und für WAITs.
Hier benötigt man noch jede Menge zusätzliche Hardware um einen Computer zu haben.
- Die Intel Quark sind SoC (Systen on Chip).
Da ist ein ganzer PC auf dem Chip, also fast alles was sich normalerweise auf dem Mainboard befindet.
Allerdings benötigt man noch externen Speicher um einen funktionierenden Computer zu erhalten.
Beim Intel Galileo wird ein Intel Quark SoC X1000 verwendet.
Welche CPU bei den 3 Varianten verwendet wird, ist grundsätzlich egal.
Praktisch ist das Ganze nur eine Kostenfrage. Kosten verursacht hauptsächlich die Chipfläche und der verwendete Prozess. Je nach Strukturgrösse bekommt man eine bestimmte Anzahl Transistoren auf 1mm2 unter.
Nun muss man halt entscheiden ob man mit den Transistoren lieber RAM und ROM macht und eine einfache CPU oder halt umgekehrt.
Bei der RISC-Idee ging es eigentlich darum, eine CPU mit wenig Transistoren zu haben. Mit einem Teil der gesparten Transistoren konnte man dann noch zusätzliche Register spendieren.
Bei der Analyse von RISC-Programmen hatte sich gezeigt, dass viele der komplexen Befehle nur selten gebraucht werden, aber natürlich jede Menge Transistoren zur Implementierung benötigen. Um Transistoren bei CISC einzusparen, verwendete man µCode. Jeder CPU-Befehl wurde als kleines internes Programm auf der CPU ausgeführt, was natürlich mehrere Taktzyklen zur Ausführung benötigt. Bei RISC werden die meisten Befehle in einem Takt ausgeführt.
Der erste RISC-µP war eigentlich der 6502.Die Idee der ehemaligen 6801-Entwickler war es, mit möglichst wenigen Transistoren, und somit kleinem Chip, einen günstigeren Prozessor zu entwickeln. Es gab anfänglich einen 6501, welcher pinkompatibel zum 6801 war, der wurde dann aber gerichtlich verboten.
Der 6502 brauchte dann im allgemeinen für die Befehlsabarbeitung einen Takt pro Speicherzugriff. Da die Adressberechnung nur mit 8-Bit durchgeführt wurde, musste ein interner Takt eingefügt werden, wenn sich ein Übertrag vom LSB zum MSB ergab. Wegen der einfacheren Logik, machte die CPU einfach einen Dummy-Lesezugriff mit dem Zwischenresultat der Adressberechnung.
Dieses Verhalten bedingte dann ein Umdenken bei den Peripherie-Bausteinen. Bis dahin war es üblich, beim lesen eines Statusregisters, dieses dabei gleich zurück zusetzen. Beim 6502 konnte dies dann aber durch einen Dummy-Zugriff versehentlich geschehen :-(
Also musste man zum Zurücksetzen extra einen Schreibzyklus verwenden.
MfG Peter(TOO)
nochmal zurück zu meiner Frage, denn das ist der eigentliche Knackpunkt:
zu den Timer IRQs: auch der Due ist kein AVR, sondern ein 32-bit ARM Cortex, und auch der Due hat Sketch Timer-Interrupt -Libs!
(#include <DueTimer.h> )
Also müsste man doch auch für den Galileo Timer-Interrupts erwarten dürfen- wie geht das also genau (z.B. alle 250µs) ?
zum MT: was gibt es da fürs Galileo-Sketch? Galileo ist ja Linux-basiert und Sketch verwendet auch (verdeckt) gpp C/C++, und für Linux gibt es POSIX-Libs, die man per gpp C #includen kann -
(#include <pthread.h>)
was geht also hier beim Galileo mit Sketch für Multitasking?
Was man also bräuchte, wäre eine ganz klare und eindeutige Beschreibung und Anleitung mit Beispiel-Sketchen, wie man Zimer-Interrupts und MT per Galileo-C-Sketch impementiert!
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.
@HaWe Eine pthread.h müsste aber in der Arduino IDE sein. Dort ist ja auch der g++ mit seinen Headerdateien. Es wird ja nur die fertig übersetzte Datei ins Linux kopiert.
Das Linux kommt übrigens in eine Datei (!) auf der SD-Karte. Da die Karte mit Fat32 formatiert ist, kann die Datei und damit der Speicherplatz des Linux nie größer werden als 4 GB. Unter Windows stehen dagegen die ganzen maximalen 32 GB einer SDHC-Karte zur Verfügung. SXDC-Karten kann die Hardware nicht verwenden.
hi,
nein, pthread wird nicht statisch sondern dynamisch verlinkt. Alle Bibliotheken müssen sich auf dem Linux-Zielsystem befinden!
per makefile heisst der Befehl dazu
LDFLAGS=-lpthread
man muss dazu die Headerdatei statisch einbinden, aber die ganzen .c files dynamisch verlinken auf der Zielplattform.
Nicht jedes Linux ist aber POSIX-kompatibel, und einfach die POSIX-Dateien zum Linux "rüberschieben" reicht nicht.
Aber eigentlich wollte ich ja mit dem ganzen makefile-Mist auch überhaupt nichts mehr zu tun haben... :(
ps,
wenn Sketch auch auf Windows läuft, wäre mir das auch recht-
Hauptsache: Timer-Intr für 250µs-Echtzeit DPin-Polling und preemptives Multitasking WIE mit pthread etc.
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.
... wollte damit ntl sagen:
wenn der Sketch-Crosscompiler auch auf das Galileo-Windows-OS als Zielplattform kompiliert statt auf eine Linux-Ziellattform...
aber der C-Compiler ist ntl genau der von Sketch!!
- - - Aktualisiert - - -
Aber wenn das Linux so dermaßen inkompatibel ist, dann bräuchte man eben fertige Bibliotheken wie timer1 oder wie DueTimer für die Intr, wie es Arduino gemacht hat,
sowie Bibliotheken wie Scheduler oder ähnliche, die entfernt wie pthread arbeiten, schon fertig implementiert und dokumentiert.
So wie es auch für den Due gemacht wurde.
Was will man mit so einer Roboter-Steuer-Platine ohne Multitasking und was will man mit GPIO pins ohne Timer-Interupts ???
Möglicherweise gibts das ja - wahrscheinlich sogar irgendwo oder irgendwie - aber wo und wie ist das genau dokumentiert und mit Beispielsketchen belegt?
Schön fand ich das hier
http://www.heise.de/developer/artikel/Arduino-Galileo-eine-Frage-der-Positionierung-2194351.html
So berichtet eine bekannte slowakischen Elektronikhandlung unter der Hand von extremen Problemen beim Verkauf des Galileos: Seit Ankündigung konnte kein einziges Stück an den Mann/die Frau gebracht werden. Sowohl Raspberry Pi als auch "normale Arduinos" fanden derweil reißenden Absatz.
ja, das Konzept ist tatsächlich Klasse:
einen Linux-Computer (auch wenn er nur quasi virtuell ist) mit Arduino Sketch programmieren!
NIEMALS würde ich mich jemals wieder mit Linux-SD-Images, Eclipse und makefile und Projetdateien und ssh und putty und den verquarzten Linux-Konsolen-Befehlen herumärgern wollen.
C-programm schreiben und hochladen in einer simplen IDE per Mausclick via USB - das war's!
Oder besser: das WÄR's. :-/
Peter(TOO)
10.12.2014, 16:29
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)
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?
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 ...
Die meisten MT-Libs wie FreeRTOS oder OSEK sind irrsinnig schwierig zu benutzen.
Das Scheduler-System des Due, einfach neue parallel laufende loops zu starten (loop, loop1, loop2,...) , wäre genau richtig, ein RTOS muss es noch nicht mal sein.
Allerdings müsste ein Scheduler für das Umschalten zwischen den Zeitscheiben sorgen (preemptiv eben).
Ich brauche mir aber nur anzugucken, wie schwierig OSEK auf dem NXT (nxtOSEK mit Toppers C) zu implementieren ist - nee danke.
Mit NXC ist das perfekt gelöst:
start (taskname)
stop (taskname)
mehr braucht man da nicht.
Wer z.B. auch POSIX pthread kennt, der weiss, was ich meine und wie es machbar und zumutbar ist für Hobby-Programmierer.
Oder MT nach C11-Standard natürlich.
Ich las gerade woanders aber auch das Stichwort "Arduino Tre".
Nicht dass es jetzt hier zu OT wird -
Wenn es nun den (v.a. ntl für den Sitara-Hauptprozessor) mit Sketch programmierbar gäbe - das könnte auch der Hit werden.
Aber eben komplett mit der Sketch IDE und mit den bekannten automatischen link/makefile- und Terminalfenster-Funktionalitäten
(ok, vllt endlich einem bessren Editor),
...aber nicht mit dem Eclipse- und dem ssh- und putty-Mist!
Peter(TOO)
10.12.2014, 21:14
Hallo,
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 ...
Das Datenblatt des RZ/A1H ist etwas fett geworden, über 3'000 Seiten.
Renesas scheint recht zuversichtlich zu sein, die RTC geht bis zum Jahr 9'999 ;-)
Zudem scheinen die alles auf den Chip gepackt zu haben, was die Patente hergaben.
MfG Peter(TOO)
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.
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.
#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
hmm - das sagt mir leider gar nichts.
Mittlerweile tröpfelt da wieder Information herein:
http://blog.arduino.cc/2014/12/12/arduino-tre-developer-edition-2nd-round-of-beta-testing/
Dort kann man lesen
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 ...
das ist jetzt leider weit außerhalb meines Fähigkeits-Horizonts... Webserver? produzierte Website? Was soll ich mit einer Website?
Das klingt sogar noch komplizierter als Eclipse mit gpp und shell.
Egal, wenn es nicht eine simple Arduino-IDE mit USB ist, ist es eh gestorben.
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!
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 ??
:shock:
das ist ja ein Ding!
Aber super-praktisch und super-simpel sicher! Dann lass ich mich mal überraschen! :cool:
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"); });
}
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/lego-minstorms/evb-replace-mindstorms-ev3-brick-beaglebone-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!! ;)
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
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/viewtopic.php?f=70&t=8302#p65015
http://www.mindstormsforum.de/viewtopic.php?f=70&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...
Die Pressmitteilung bedeutet grob "Der Stammlieferant der Arduino Controller ist Mitglied beim Konkurrenzverein geworden".
Was deine Wünsche angeht ist das einfach:
- Ohne Linux fallen alle Cortex A* Boards aus.
- Ohne IDE fallen alle Einsteigerboards der Chiphersteller aus.
- Ohne C++ fällt dann noch mbed aus.
Es bleibt also nichts mehr übrig, außer Arduino.
Suche beendet.
das hatte ich schon befürchtet, genau so bin ich ja auf den Mega und dann den Due gekommen ;)
die Hoffnung war halt: andere einfache IDE, evtl. Web-IDE (hatte sich ja ganz vielversprechend angehört).
- - - Aktualisiert - - -
ps, edit:
Linux als OS ist ja ok, wenn ich nichts davon mitkriege - heißt: kein ssh, kein putty etc.
ich kriege ja auch nichts vom Due-OS mit, wenn ich nur compiliere und über USB hochlade!
C als Sprache wäre ja unter Linux ok, es ist ja quasi dessen Muttersprache. Aber ohne Shell ist ernsthafte Linux Programmierung auf dem gewünschten Niveau völlig unrealistisch. Man kann nicht auf diesem Level mit dem BBB (sicher auch mit dem Tre) arbeiten, wenn man nicht wissen will, was z.B. Device Trees sind.
stimmt, weiß ich nicht, und will ich ehrlich gesagt auch nicht wissen.
Ist wie Windows: Zum programmieren finde ich es schrecklich, aber wenn ich Excel-Tabellen schreibe oder Sketch programmiere, muss ich ja auch nichts über Windows etc wissen - es läuft, gut, ok, das reicht...
:-/
genauso ist es, wie wenn ich den lego-Linux-EV3 mit dem Windws-PC und der Lego-GUI-IDE programmiere: weder von Windows noch von Linux muss ich irgendwas wahrnehmen, außer ihre nackte Existenz.
Ein Betriebssystem ist für mich dafür da, dass es im Hintergrund arbeitet, ohne dass man davon was merkt - bzw. je weniger, desto besser. 8-)
wie ist hier inzwischen der Stand der Erfahrung mit dem Galileo?
- Lässt sich das Hitze-Problem bei der 1. Gen. mit einem Kühlkörper in den Griff kriegen? Oder evtl. mit einem Mini-Lüfter?
- Läuft der Galileo (Gen.1) mit der aktuellen Arduino Sketch IDE 1.6.5 (oder 1.6.3) ? Hier kann man ja über Info/Boards Manager/IntelGalileo die libs nachinstallieren)
- Wie werden Timer implementiert (ähnlich <DueTimer.h> ?) ?
- wie wird Multitasking gehändelt (ähnlich wie <pthread> oder wie GCC <thread> oder der Due <Scheduler.h>) ?
(den Gen.2 würde ich mir jetzt erstmal wegen des viel höheren Preises noch nicht gleich von Anfang an zulegen)
wie ist hier inzwischen der Stand der Erfahrung mit dem Galileo?
Mit der Arduino Software habe ich meinen nicht mehr benutzt. Manchmal spiele ich noch mit dem Windows 8.1 darauf herum.
Insgesamt hat der Galileo wohl keine große Zukunft. Intel geht in Richtung Edison und Microsoft in Richtung Raspi.
Solange man das Ding nicht in ein Gehäuse einbaut, ist die Hitzeabstrahlung noch tolerierbar. Ein Gen1 und ein Gen2 unterscheiden sich nur in ein paar Details: Andere Versorgungsspannung, anderer USB-Stecker, anderer Port-Extender-Chip für die IOs.
willst du nicht mal die 1.6.5er Arduino Version aufspielen, testweise?
Nö, da gibt es interessantere Dinge zu erforschen.
Das angeblich für Fortgeschrittene gedachte ArchLinux ist auf dem Raspi2 doch deutlich umgänglicher, als dieses komische Yocto Linux auf dem Galileo. (Was wahrscheinlich eher an Intel, als an Yocto liegt.)
Wenn man viel mit IOs machen will, was bei Dir ja wohl der Fall ist, macht der Galileo keinen Sinn. Das wenige was er an Rechenleistung hat, kann man z.B. nutzen um langsame IO Geschichten (z.B. Raumtemperatur) ins Netz zu bringen. Die wenigen lahmen IOs können mit der Rechenleistung nicht wirklich was anfangen.
Da ist die Kombination aus Linux Rechner (z.B. Raspi 2) und über USB angeflanschten Mikrocontroller (meinetwegen Due, besser mbed) um mehr als das 10fache leistungsfähiger. Theoretisch ginge das auch mit Galileo statt Raspi, aber dann muss man wieder mit dem zusammgeflickten Linux rummachen.
Das sollte sowieso klar sein, der Galileo ist ein Linux Board. Wer wissen will, wie die Timer implementiert sind, muss sich Intels Linux Treiber ansehen. Damit müsstest Du dich genauso anfreunden, wie mit der Tatsache, dass Arduino Sketch eigentlich C++ ist, kein C. (Google findet dazu einen witzigen Thread von einem HaWe in einem Raspi Forum. Der scheitert daran, seinen angeblichen C Code, der C++ Header enthält, mit dem gcc zu übersetzen ...)
So gesehen gibt es ja doch ein wenig neues, hier haben wir es geschafft dem Due etwas moderneres C++ unterzuschieben
https://www.roboternetz.de/community/threads/67455-Arduino-IDE-%28Linux%29-DUE-C-Linken-geht-nicht
ich dachte gerade an den Galileo, weil er ja die Arduino-IDE hat - damit sollten dann aber doch die üblichen Befehle, wie man sie von Sketch für die AVRs und auch den Due kennt, auch über Sketch für den Galileo laufen?
Also libs in den Arduino-Installationsordner kopieren (z.B. die Timer- oder Multitasking-libs) ,
und dann mit #include im Programm einschließen.
So geht es mit Sketch für Uno, Nano, Mega, und Due.
Das schöne an Sketch ist doch gerade, dass ich mit dem Betriebssystem im Prinzip keine speziellen Berührungspunkte habe und dass die Syntax und die Betriebsfunktionen alle komplett von der Arduino-IDE gemanaged werden.
Ist das bei der IDE für den Galileo etwa anders?
In der Tat habe ich nicht vor, irgendwas auf Linux-Betriebssystem-Ebene zu machen, das muss schon die Arduino-IDE leisten (etwa Timer oder Scheduler oder Thread oder was auch immer) - so wie sie es auch für Windows und den Windows-Crosscompiler und die AVR/ARM-"Betriebssysteme" bzw "Firmware" tut). Hier interessiert mich ja auch nicht, was welches Betriebssystem tut oder lässt. Ein Linux-Gewurschtel wie beim Raspi kommt für mich nicht in Frage, auch mbed- oder gcc- Gewurschtel ist mir zuwider, das muss schon die Arduino-Sketch-IDE richten, dafür ist sie ja schließlich da (und genau deshalb habe ich mich ja so schnell und so gut mit dem Due angefreundet)!
Aber vielleicht ist das ja inzwischen auch schon mit der 1.6.5er IDE so, daher interessieren mich auch spezielle persönliche Erfahrungen damit.
Ist das bei der IDE für den Galileo etwa anders?
Das hat mit der IDE nichts zu tun. Der Galileo ist nur ein "Software Arduino", genauso wie der Tre oder diese angekündigten Teile von Samsung.
Die Arduino-IDE erzeugt für Galileo (und sicher auch für den Tre) nur ein Linux Kommandozeilenprogramm, dass das Verhalten eines Arduinos simuliert. Direkten Zugriff auf die Hardware, wie bei einem Mikrocontroller, hat man dabei nicht. Die Arduino Befehle, wie digitalWrite() werden zu entsprechenden Betriebssystemaufrufen umgesetzt. Alles was mit IOs zu tun hat, ist auf solchen Rechnern deutlich langsamer, als auf einem Mikrocontroller.
Im Prinzip nur ein in Watte gepacktes Linux. Deshalb reicht es ja auch nicht, um mit dem Galileo zu testen, nur die Arduino IDE zu installieren. Man muss bei Intel ja noch das Image für die passende SD-Karte herunterladen. Betreibt man einen Galileo ohne SD-Karte ist das Programm ja weg, wenn man ihn ausschaltet.
hmmh - heißt das, dass dann die Arduino-IDE auf dem Galileo-Linux gar keine echten Executables für den Intel-Prozessor erzeugt (im Gegensatz zu Geany für das ARM-Raspi-Debian-Linux) ?
Doch, das sind schon echte Linux Executables, keine Scripte. Die werden auf dem PC übersetzt und auf das Board kopiert und dort für automatischen Start konfiguriert.
Wenn man einen Galileo einschaltet, braucht erst mal das Linux 2-3 Minuten zum Starten (das zeigt schon den Unterschied zum Pi), dann wird das Programm vom letzten geladenen Sketch gestartet.
Findet ein Galileo keine startbare SD-Karte, hat er ein noch kleineres Reserve-Linux in der Firmware. Das entpackt er dann in den RAM. Aber jedesmal neu. Deshalb ist der letzte Sketch dann weg.
Gerade heute morgen festgestellt:
offenbar unterstützt Intel auf seiner Download-Seite kein XP (mehr).
Hat oder kennt wer Hardware-Treiber für XP? die aktuelle Arduino IDE (1.6.5) läuft ja bestens auf meinen XP-Rechnern, insb. auch für meine Due's.
Keine Ahnung, ob es da je Treiber für XP gegeben hat. Auch habe ich mir nicht angesehen, wie mit der Arduino 1.6.x das Firmware Update funktioniert.
Ein Galileo muss ja meist erst mal mit der zur jeweiligen Arduino IDE Version passenden Firmware geflasht werden. Das neigt sowieso zu Abstürzen ...
Intel scheint auch einige Doku zum Galileo entfernt zu haben. Da landet man jetzt auf den Seiten zum Edison.
ok, sieht aus, als wäre das Thema Galileo damit erledigt :-/
Anscheinend überlässt Arduino die Linux Boards ganz Partnern wie Intel und Samsung. Den Tre hat man jetzt von der Arduino Produktseite entfernt ...
haha, noch ein Nachschlag zum Thema Galileo: Zum Totlachen!
http://www.golem.de/news/test-intels-galileo-board-1312-103167.html
Das wär ja GENAU das richtige für mich gewesen, ogottogottogottogottogott..... 30484
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.