Am Dienstag, 15. August 2017 20:14 CEST, "Arno Steffens" epsi@gmx.de schrieb:
Hallo, mit Mehr-Kern Prozessoren wird das Programmieren doch wieder etwas anders, wie ich zuletzt gemerkt hab. Wie löst man elegant unaufwändig folgendes Problem?
Am einem ARM-board ist per spi/i2c ein Gerät angeschlossen. Eine kleine Bibliothek device.so übersetzt befehle wie "Lese register x", "Schreibe Register y mit z" und führt dann ioctl Befehle aus. Es gibt auch ein dump() Kommando, dass alle Register liest und ausgibt.
Das verstehe ich jetzt nicht ganz - der dump-Befehl liest die Register des angeschlossenen Geräts aus, oder?
Aus dem Anwendungsprogramm wird dann das angeschlossene Gerät mit den device_read(x), device_write(y,z) programmiert.
Jetzt ist mir aufgefallen, dass das dump() welches zuerst aufgerufen wird, die eigentlich erst später im Quellcode geschriebenen Register liefert !
Im Quellcode von was? Deinem Programm auf dem ARM oder dem Gerät? Auf dem Multicore ARM sollten Dich die Register besser nicht interessieren. Ist Deine Anwendung überhaupt Multithreaded?
Erwartet hatte ich die reset/default Werte – weil ja dump (nach poweron) zuerst gecoded ist. Selbst ein sleep(5); dazwischen hat daran nichts geändert, erst sleep(10); was ja irrsinnige Zeiten sind!!!
So richtig hab ich das nicht verstanden, aber bei mir ist Alarm. Kann denn das wirklich sein? 10 sekunden? Klar durch die vielen printf ist das dump länger beschäftigt.
Aber selbst wenn der dump auf einem anderen Kern läuft als der Rest, kann das wirklich passieren ? Und wie kann ich das verhindern? Mitunter kommt es beim Schreiben der Register auf eine Reihenfolge an – das ist letztlich was mich umtreibt.
Das kannst Du Deinem GCC schon beibringen - bin gerade an ganz anderen Baustellen, kann Dir aber, so Du Dich einarbeiten möchtest "Multicore-Software" von Gleim/Schüle aus dem DPunkt-Verlag empfehlen.
Gruss RalfD