Gesendet: Donnerstag, 17. August 2017 um 11:28 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: "Arno Steffens" epsi@gmx.de Cc: flug@lug-freiburg.de Betreff: Re: [Flug] Multicore Programmierung
On Wed, Aug 16, 2017 at 09:58:33PM +0200, Arno Steffens wrote:
Gesendet: Dienstag, 15. August 2017 um 21:48 Uhr Von: "Uwe Kleine-König" uwe@kleine-koenig.org An: flug@lug-freiburg.de Betreff: Re: [Flug] Multicore Programmierung
On 08/15/2017 09:39 PM, Arno Steffens wrote:
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?
Ja genau. Es sind praktisch lese-Funktionen in einer loop, aber immer noch in der Bibliothek.
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?
Quelltext, compiliert für ARM und dort augeführt. dump(); write(a,b); write(c,d); write(e,f);
Wenn Dein Programm nicht extra Zeugs macht, nutzt das nicht aus, dass Deine Maschine mehr als eine CPU hat. Was passiert denn beim ersten Mal, nachdem Du b, d und f in g, h und i geändert hast? Zeig mal Dein Programm.
Na ich weiß nicht. Werden denn nicht auch ohne explizietes Threading beide Cores genutzt?
Ja, aber transparent für Dein Programm. D.h. für Dich sieht es so aus, als laufe alles auf einem Core.
ALlerdings zeigt mir dump() den Inhalt b,d,f an, und nicht den Inhalt vor der Initialisierung.
Auf dem Multicore ARM sollten Dich die Register besser nicht interessieren. Ist Deine Anwendung überhaupt Multithreaded?
Im Moment noch nicht.
Wenn Dein Programm hauptsächlich dafür da ist, um mit dem spi bzw. i2c-Chip zu kommunizieren, lohnt sich Parallelisierung nicht.
Klar weil das viel langsamer ist. Ich will es ja auch gar nicht parallelisieren. Im Gegenteil hab ich die Befürchtung das da was durcheinander gerät in der Reihenfolge.
Übrigens ist "Mein Programm ist mit Multitasking schneller" ein verbreiteter Irrglauben. Ja, manche Sachen werden wirklich schneller. Aber viele von den man glaubt, dass sie schneller werden, werden entweder nicht schneller, oder sind schlecht programmiert, dass richtig ohne Multitasking noch schneller wäre.
@Ralf: GDB kann ich probieren, auf den Bus gucken ist schon schwieriger - hab kein Oszi daheim. Ja, der angeschlossene SPI Chip hat eine im Datenblatt beschriebenes default-Setup. Daher weiß ich was drin sein sollte.
Hier stimme ich Ralf zu. Deine Annahme fußt auf Annahmen:
- Das Datenblatt ist richtig
- Der Chip hat seit dem letzten Testlauf *wirklich* ein Reset gesehen.
Die Praxis zeigt, dass man auf beide Annahmen besser nichts verwettet.
Ich traue es mich nicht zu sagen: Alles meine Schuld :( Ich hab (wenn man so ab und an mal was macht und wieder vergisst, was man vor Wochen getan hat), diese Init-Routine via rc.d schon mal aufgerufen ... also kein Wunder das die Register schon initialisiert waren. Das klärt für mich noch nicht alles, aber wenn etwas zu komisch ist, dann liegt es doch oft daran, das man was übersehen hat. Sorry!
Trotzdem hab ich wieder was gelernt. Auch ums debguggen hab ich mich mal wieder bemüht. GDB mit Eclipse.... Jaja, geht so. Eine Core dump remote auswerten muss hab ich noch nicht hinbekommen. Das muss ich noch recherchieren. Der zeigt mir da nur irgenwas in einer tiefen Ebene Linux-lib/Kernel an, was nicht hilfreich ist. Und bt gingt auch nicht. Na ich bleib dran und übe weiter. Bedauerlich dass es so wenig (anfängerfreundliche, gern deutsche) Literatur dazu gibt. Und leider kann man wohl mmapped memory nicht im GDB beobachten. Komisch, denn das Programm greift korrekt auf den Speicher zu ....
Gibts das tracing auch für SPI?
if test -d /sys/kernel/debug/tracing/events/spi; then echo "ja" fi
Ich muss mir das die nächsten Tage einfach noch mal in Ruhe anschauen.
Ja bitte.
Du siehst, ein wenig Abstand und noch mal draufgucken ... es hilft! Viele Grüße Arno
Liebe Grüße Uwe _______________________________________________ Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug