Hallo zusammen,
für Bitbanging-Treiber auf ARM-MCUs nutze ich sehr gerne Wartezyklen.
Nicht etwas als Notlösung, weil eine bestimmte Peripherie nicht den
Aufwand des Umstiegs auf eine komplett andere MCU rechtfertigt: Nein,
ich liebe Wartezyklen. Vor kurzem bin ich sogar von einem STM32F103 mit
78 MHz auf einen STM32F446 mit 178 MHz umgestiegen, damit ich mehr NOP()
unterbringen kann. So habe ich es geschafft in bestimmten Regionen von
Hardwaretreibern von 20% NOP-Dichte auf fast 70% NOP-Dichte zu kommen.
Das soll mir erst einmal jemand nachmachen!
Wie sinnvoll ist diese Vorgehensweise?
Viele Grüße
Bulbus
Bulbus duodenitis schrieb:> Wie sinnvoll ist diese Vorgehensweise?
wenn man sonst keine Hobbys hat und irgendwie den Tag rumbringen will
kann man das machen.
Es ist tierfreundlicher als Schnecken auf die Schwänze zu klopfen.
Bulbus duodenitis schrieb:> Wie sinnvoll ist diese Vorgehensweise?
Es ist nur sinnvoll wenn du die NOPs nicht per copy&past einfügst
sondern alle einzeln eintippst.
Bulbus duodenitis schrieb:> Wie sinnvoll ist diese Vorgehensweise?
Ganz schlecht. Das klingt nämlich verdächtig nach NOP-Slides[1] und die
werden nur von Kriminellen und Hackern verwendet. Pass nur auf dass
nicht eines Tages die Polizei vor deiner Haustür steht!
[1] https://en.wikipedia.org/wiki/NOP_slideBulbus duodenitis schrieb:> Wie sinnvoll ist diese Vorgehensweise?
Sehr sinnvoll! Denn der Vorteil von NOP-Slides ist ja dass man egal wo
man in der Reihe von NOPs ist, am Ende immer bei der nächsten gültigen
Instruktion ankommt. Solltest du deinen Mikrocontroller im Weltraum
aussetzen wo durch Höhenstrahlung die Bits in Program Counter geflipt
werden könnten, ist das eine gute Lösung um immer in einen sicheren
Zustand zu "rutschen". Im Bestfall hast du n-1 NOPS und eine gültige
Instruktion, dann ist dein Design 100% strahlungsfest.
bla schrieb:> Im Bestfall hast du n-1 NOPS und eine gültige> Instruktion, dann ist dein Design 100% strahlungsfest.
Wenn der eine, gültige Befehl im Programmspeicher dann auch noch ein NOP
ist, sogar 200%! ;)
Wie viele Threads werden hier noch rund um das Thema "Warteschleifen"
eröffnet? Mein Troll-Detektor vermutet, dass hinter all diesen Threads
der selbe Mensch steckt.
Bulbus duodenitis schrieb:> auf fast 70% NOP-Dichte zu kommen.> Das soll mir erst einmal jemand nachmachen!
Ja das ärgert mich auch immer wieder, daß die 32Bitter soviel Flash
haben. Da bleibt nur, viel unnützen Code zu erzeugen, um den Flash voll
zu kriegen.
Peter D. schrieb:> Da bleibt nur, viel unnützen Code zu erzeugen, um den Flash voll> zu kriegen.
Naja, wenn es nur darum geht, sind schöne Schriftarten und große
Pikrogramme natürlich auch ein Weg.
Heißt: ARM nimmt sich die Freiheit heraus, künftige Versionen der Cortex
M herauszubringen, bei denen ein NOP() wegoptimiert werden kann, ohne
die Doku zu ändern.
Statt zu warten könnte man nebenher wenigsten nach Crypto-Coins
schürfen.
Dann hätte es wenigstens einen Sinn.
Früher gab es mal das Seti-Projekt für überflüssige Rechenzeit.
Horst schrieb:> Ductus cochlearis (Gast) schrieb:>> In diesem Thread geht es darum,> daß Du Dich auf Kosten anderer amüsierst.
Nope. Es geht darum, daß ein anderer Thread, in dem es darum geht, wie
man Wartezeiten sinnvoll implementiert, nicht mit dem völlig anderen
Thema zerklüftet wird, daß dies grundsätzlich komplett sinnlos sei.
Dieser Thread bietet jetzt die Plattform, auf der die Vertreter dieser
Meinung, die ich nicht teile, ihre Argumente darstellen können.
Deswegen übrigens auch die völlig übertriebene Eröffnung. Es sollte ja
ein leichtes sein, diese zu Widerlegen, um dann systematisch auch die
anderen, weniger einfachen Fälle beweisen zu können.
Johnny B. schrieb:>> Früher gab es mal das Seti-Projekt für überflüssige Rechenzeit.
Das ist aber nicht hilfreich. Es geht immer noch darum: Warum sind
Wartezeiten auf einer ARM-MCU um jeden Preis zu vermeiden?
Ductus cochlearis schrieb:> Das ist aber nicht hilfreich. Es geht immer noch darum: Warum sind> Wartezeiten auf einer ARM-MCU um jeden Preis zu vermeiden?
Nein. Es geht um "Wie schlimm sind Wartezyklen auf ARM-Prozessoren?".
Die Antwort lautet:
"Nicht sehr", wenn man a) erfolgreich Cryptocoins mint auf b)
anderermanns Stromrechnung. Sonst wirds teuer, wenn mann alle paar
Minuten die Knopfzellen wechseln muss.
Peter D. schrieb:> Ja das ärgert mich auch immer wieder, daß die 32Bitter soviel Flash> haben. Da bleibt nur, viel unnützen Code zu erzeugen, um den Flash voll> zu kriegen.
Dafür gibt es doch C++ Compiler?
> Es geht immer noch darum: Warum sind> Wartezeiten auf einer ARM-MCU um jeden Preis zu vermeiden?
Die Frage ist Quatsch. Sie sind nicht "um jeden Preis" zu vermeiden.
Die Frage ist schon so absolut formuliert, also ob davon die Welt
untergehen würde. Tut sie aber nicht.
Stefanus F. schrieb:> Die Frage ist Quatsch. Sie sind nicht "um jeden Preis" zu vermeiden.>> Die Frage ist schon so absolut formuliert, also ob davon die Welt> untergehen würde. Tut sie aber nicht.
Was ist denn dann zu vermeiden?
> Was ist denn dann zu vermeiden?
Unsinnige Fragen stellen. Impotent werden. Arbeitslos werden. Sich
verzetteln, weil man unbedingt keine Delays verwenden wollte. Nicht
weiter kommen, weil man endliche Automaten nicht verstanden hat.
Stefanus F. schrieb:> Unsinnige Fragen stellen. Impotent werden. Arbeitslos werden. Sich> verzetteln, weil man unbedingt keine Delays verwenden wollte. Nicht> weiter kommen, weil man endliche Automaten nicht verstanden hat.
Interessante Zusammenstellung. Vor was fürchtest Du Dich am meisten?
Autor: Bulbus duodentritis (Gast)
Datum: 18.04.2018 09:57
>Wie sinnvoll ist diese Vorgehensweise?
Je nach Anforderung ziemlich sinnvol.
Ich mag NOPs sehr, sie sind so einfach zu verstehen.
Aber Deine Frage lässt auf eine Art Schwachsinnigkeit schließen.
Ferguson schrieb:> Ich mag NOPs sehr, sie sind so einfach zu verstehen.
Träum weiter. ;-)
Bei Intel wird dabei, der Codierung nach, nicht etwa nichts getan,
sondern AX mit AX vertauscht. Vielleicht wars anno 8086 auch wirklich
so.
Und was genau man unter "keiner Operation" verstehen soll, ist auch
nicht so einfach. Also ob eine Ausführungseinheit belegt wird, um nichts
zu tun, oder ob nicht einmal das geschieht. Was ARM dazu in Manual
schrieb ist keine Zukunftsmusik.
Dazu kommen noch Tabellen in diversen x86 Optimierungs-Guides, wie man
NOPs so codiert, dass mit möglichst geringer Laufzeit N Bytes verbraten
werden. Also Optimierung von NOPs! Das ist ausserdem keineswegs bei
allen x86 gleich.
Beim Z80 war der Opcode von NOP 0x00.
Das war recht praktisch, wenn man mal etwas auskommentieren wollte.
Einfach 00en rein, und es wurde nichts gemacht.
Beim 68000 war es schon 0x4E71, da war es nicht mehr so einfach.
Das geht jetzt aber nicht!
Wenn in einem Thread erst einmal darauf bestanden wird, daß Busy Waiting
grundsätzlich falsch ist und jetzt hier plötzlich legitime
Anwendungsfälle aufgezählt werden, ist das doch irgendwie merkwürdig.
Bulbus duodeniti schrieb:> jetzt hier plötzlich legitime> Anwendungsfälle aufgezählt werden, ist das doch irgendwie merkwürdig.
Vielleicht solltest Du nicht in einem Elektronikforum nach Hilfe suchen
sondern beim Psychologen Deines Vertrauens.
> jetzt hier plötzlich legitime> Anwendungsfälle aufgezählt werden, ist das doch irgendwie merkwürdig.
Naja, wenn ich frage, warum Bomben schlimm sind, bekomme ich auch
entsprechende Antworten. Doch wenn man etwas länger darüber sinniert
fallen einem auch gute Gründe ein, Bomben zu bauen.
Die Antworten wurden schon durch die Fragestellung beeinflusst.
