mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie schlimm sind Wartezyklen auf ARM-Prozessoren?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-17 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der F103 kann nur 72 MHz.

Autor: Volle2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Der F103 kann nur 72 MHz.

Stimmt. Konnte ich allerdings nicht mehr korrigieren.

Autor: Idefix der Trollspürhund (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wuff wuff!

Autor: Ralf (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Autor: bla (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas E. (picalic)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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%! ;)

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?"

Autor: Doofischlumpf (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Folgende Fragmente stammen von der Firma Microtschip:

Nur das du nicht glaubst du waerst der einzige!

loc_CODE_12B:        ; CODE XREF: CODE:092Dj
    bcf  BANK0:PORTC, RC3  ;SCK/SCL
    nop
    nop
    bsf  BANK0:PORTA, RA4  ;SW1
    nop
    nop
    bcf  BANK0:PORTA, RA4  ;SW1
    nop

loc_CODE_133:        ; CODE XREF: CODE:093Aj
    nop
    nop
    nop

loc_CODE_136:        ; CODE XREF: CODE:0938j
    nop
    nop
    nop
    nop
    movfw  byte_DATA_49
    call  sub_CODE_772
    nop
    nop
    movfw  byte_DATA_4A
    call  sub_CODE_772

loc_CODE_140:        ; CODE XREF: CODE:0947j
    nop
    nop
    nop

loc_CODE_143:        ; CODE XREF: CODE:0945j
    nop
    nop
    bsf  BANK0:PORTA, RA4  ;SW1
    nop
    nop
    nop
    nop
    nop

loc_CODE_14B:        ; CODE XREF: CODE:0952j
    nop
    nop
    nop

loc_CODE_14E:        ; CODE XREF: CODE:0950j
    nop
    nop
    b  loc_CODE_79

...

loc_CODE_544:        ; CODE XREF: sub_CODE_537+25j
    movfw  BANK0:PORTB
    xorwf  byte_DATA_54, w
    bnz  loc_CODE_562
    call  sub_CODE_2D9
    comf  byte_DATA_54, f
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    nop
    incfsz  byte_DATA_3A, f
    b  loc_CODE_544
    decfsz  byte_DATA_39, f
    b  loc_CODE_543
    bsf  BANK0:PORTC, RC2  ;SRAM CE
    bsf  BANK0:PORTA, RA2  ;SRAM OE
    retlw  1



Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir hatten das doch alles gerade erst durch gekaut!

 Beitrag "STM32F103: Delay mit TIM2"

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Wir hatten das doch alles gerade erst durch gekaut!

Andere Anforderung -> andere Lösung.

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Oliver H. (olitheone)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: bla (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Ductus cochlearis (Gast) (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nein, ein Tippfehler. Neudeutsch "Icons". Nehmen bei mir in Firmwares 
mit Grafik-LCD tatsächlich den größten Teil des Flash-Speicherplatzes 
ein.

Autor: Ductus cochlearis (Gast) (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Aber nicht vergessen: In diesem Thread geht es darum, zu begründen, 
warum auf einem ARM-Prozessor Wartezyklen grundsätzlich immer Unsinn 
sind.

Autor: Ductus cochlearis (Gast) (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Jetzt habe ich mich schon wieder verwechselt. Bin ja eigentlich Bulbus 
duodenitis (Gast).

Autor: PittyJ (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ductus cochlearis (Gast) schrieb:
> In diesem Thread geht es darum,
daß Du Dich auf Kosten anderer amüsierst.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ductus cochlearis (Gast) schrieb:
> Jetzt habe ich mich schon wieder verwechselt. Bin ja eigentlich
> Bulbus duodenitis (Gast).

"Mein Gott, Walter!"(tm)

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/

Autor: Ductus cochlearis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: bla (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Normalerweise werden auf kleinen MCUs wie ARM Cortex M keine Bitcoins 
gemined. Das klingt für mich doch sehr nach einem Strohmann-Argument.

Autor: Guido Körber (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Nop (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Guido Körber schrieb:

> Dafür gibt es doch C++ Compiler?

Das schon, aber wer speichert auf seiner MCU schon einen C++ Compiler?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Steffen R. (steffen_rose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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.

Autor: Bulbus duodenitis (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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: Toni Tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bulbus duodenitis schrieb:
> Vor was fürchtest Du Dich am meisten?

Staudensellerie. Wieso fragst Du?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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: Ferguson (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bulbus duodeniti (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.