ZitierenNein, 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.
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/artike...g-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. :-/
Hallo,
Ja, die Timer sind da etwas einfacher gestaltet.Zitat von Mxt
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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!
Hallo,
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Berechtigungen
Lesezeichen