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.
Dr. Sommer schrieb: > Der F103 kann nur 72 MHz. Stimmt. Konnte ich allerdings nicht mehr korrigieren.
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_slide Bulbus 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.
Stefanus F. schrieb: > 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. ;-) Beitrag "Re: ARM Cortex M3/M4: Wieviele Takte verbraucht diese Funktion?"
Folgende Fragmente stammen von der Firma Microtschip: Nur das du nicht glaubst du waerst der einzige!
1 | loc_CODE_12B: ; CODE XREF: CODE:092Dj |
2 | bcf BANK0:PORTC, RC3 ;SCK/SCL |
3 | nop |
4 | nop |
5 | bsf BANK0:PORTA, RA4 ;SW1 |
6 | nop |
7 | nop |
8 | bcf BANK0:PORTA, RA4 ;SW1 |
9 | nop |
10 | |
11 | loc_CODE_133: ; CODE XREF: CODE:093Aj |
12 | nop |
13 | nop |
14 | nop |
15 | |
16 | loc_CODE_136: ; CODE XREF: CODE:0938j |
17 | nop |
18 | nop |
19 | nop |
20 | nop |
21 | movfw byte_DATA_49 |
22 | call sub_CODE_772 |
23 | nop |
24 | nop |
25 | movfw byte_DATA_4A |
26 | call sub_CODE_772 |
27 | |
28 | loc_CODE_140: ; CODE XREF: CODE:0947j |
29 | nop |
30 | nop |
31 | nop |
32 | |
33 | loc_CODE_143: ; CODE XREF: CODE:0945j |
34 | nop |
35 | nop |
36 | bsf BANK0:PORTA, RA4 ;SW1 |
37 | nop |
38 | nop |
39 | nop |
40 | nop |
41 | nop |
42 | |
43 | loc_CODE_14B: ; CODE XREF: CODE:0952j |
44 | nop |
45 | nop |
46 | nop |
47 | |
48 | loc_CODE_14E: ; CODE XREF: CODE:0950j |
49 | nop |
50 | nop |
51 | b loc_CODE_79 |
52 | |
53 | ... |
54 | |
55 | loc_CODE_544: ; CODE XREF: sub_CODE_537+25j |
56 | movfw BANK0:PORTB |
57 | xorwf byte_DATA_54, w |
58 | bnz loc_CODE_562 |
59 | call sub_CODE_2D9 |
60 | comf byte_DATA_54, f |
61 | nop |
62 | nop |
63 | nop |
64 | nop |
65 | nop |
66 | nop |
67 | nop |
68 | nop |
69 | nop |
70 | nop |
71 | nop |
72 | nop |
73 | nop |
74 | nop |
75 | nop |
76 | nop |
77 | nop |
78 | incfsz byte_DATA_3A, f |
79 | b loc_CODE_544 |
80 | decfsz byte_DATA_39, f |
81 | b loc_CODE_543 |
82 | bsf BANK0:PORTC, RC2 ;SRAM CE |
83 | bsf BANK0:PORTA, RA2 ;SRAM OE |
84 | retlw 1 |
Stefanus F. schrieb: > Wir hatten das doch alles gerade erst durch gekaut! Andere Anforderung -> andere Lösung.
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.
Wie passt eigenltich >NOP is not necessarily a time-consuming NOP. The processor might remove it from the pipeline before it reaches the execution stage. von http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDJJGFB.html zu der Verwendung von nop als Delay auf einem Cortex? lg Oli
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.
Bulbus duodenitis schrieb: > Pikrogramme Sind Pikrogramme Symbole, die durch zur-Explosion-Bringung von Pikrinsäure[1] auf Papier/Beton/Metall geschrieben werden? Wenn ja, dann möchte ich auch ein paar Pikrogramme schreiben! [1] https://de.wikipedia.org/wiki/Pikrins%C3%A4ure
Nein, ein Tippfehler. Neudeutsch "Icons". Nehmen bei mir in Firmwares mit Grafik-LCD tatsächlich den größten Teil des Flash-Speicherplatzes ein.
Aber nicht vergessen: In diesem Thread geht es darum, zu begründen, warum auf einem ARM-Prozessor Wartezyklen grundsätzlich immer Unsinn sind.
Jetzt habe ich mich schon wieder verwechselt. Bin ja eigentlich Bulbus duodenitis (Gast).
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.
Ductus cochlearis (Gast) schrieb: > In diesem Thread geht es darum, daß Du Dich auf Kosten anderer amüsierst.
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.
Ductus cochlearis (Gast) schrieb: > Jetzt habe ich mich schon wieder verwechselt. Bin ja eigentlich > Bulbus duodenitis (Gast). "Mein Gott, Walter!"(tm)
PittyJ schrieb: > Früher gab es mal das Seti-Projekt für überflüssige Rechenzeit. Gibt es noch immer, SETI @ Home: https://setiathome.berkeley.edu/
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.
Normalerweise werden auf kleinen MCUs wie ARM Cortex M keine Bitcoins gemined. Das klingt für mich doch sehr nach einem Strohmann-Argument.
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?
Guido Körber schrieb: > Dafür gibt es doch C++ Compiler? Das schon, aber wer speichert auf seiner MCU schon einen 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.
Oliver H. schrieb: > Wie passt eigenltich > >>NOP is not necessarily a time-consuming NOP. The processor might remove it from > the pipeline before it reaches the execution stage. > > von > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDJJGFB.html > > zu der Verwendung von nop als Delay auf einem Cortex? > Deshalb ja so viele, um die Flash Wait States auch noch auszunutzen.
Beitrag #5394493 wurde von einem Moderator gelöscht.
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?
Bulbus duodenitis schrieb: > Vor was fürchtest Du Dich am meisten? Staudensellerie. Wieso fragst Du?
> Vor was fürchtest Du Dich am meisten?
Das bleibt mein Geheimnis. Und um den Teufel nicht herauf zu beschwören,
fehlt er auch in der Aufzählung.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.