Intel Galileo Board

[Mxt]

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

[HaWe]

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

[Mxt]

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

[Peter(TOO)]

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)

[HaWe]

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.

[Mxt]

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.

[HaWe]

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?

[Mxt]

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.

[HaWe]

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?

[Peter(TOO)]

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)