Entprellen (kein AVR)

Mir scheint die Zeile
  for(i = 0; i < 1000; i++) {} // kurze Pause
sinnlos

Klaus schrieb:
> was haltet ihr davon?

Kann man so machen.

1

 for(i = 0; i < 1000; i++) {} // kurze Pause

verplempert halt Rechenpower ungenutzt.

Wenn sonst nichts (zeit-)kritisches anliegt, ist das eine 
einfache,funktionstüchtige Lösung.
Ansonsten kann man die Vergleichsgeschichte auch per Timer regelmäßig 
aufrufen lassen und entsprechend reagieren.

> for(i = 0; i < 1000; i++) {} // kurze Pause

Die CPU Daeumchen drehen zu lassen, mag in dem Zusammenhang ja
akzeptabel sein, im Allgemeinen ist es das aber nicht.

> was haltet ihr davon?

Eher nichts.

bin grade zufällig drauf gestoßen. Kann kaum programmieren =) deswegen 
meine etwas naive Frage: was müsste ich tun, damit ich diese Routine in 
ein bereits bestehendes Programm integrieren kann?

> for(i = 0; i < 1000; i++) {} // kurze Pause

Ich erwarte von einem anständigen Compiler (und der gcc ist so einer), 
dass er das kommentarlos komplett weg optimiert*. Leider funktioniert 
die Entprellung dann aber nicht mehr richtig.

*) denn diese Schleife hat keine Außenwirkung, außer eben Zeit zu 
verplempern, aber das zählt für den Compiler nicht als "wirkung".

habe in einer Dimplomarbeit eine Routine gefunden (siehe Anhang). Was 
ist mit der?

Buck schrieb:
> habe in einer Dimplomarbeit eine Routine gefunden (siehe Anhang).
> Was
> ist mit der?

Die ist auch nur ein fauler Kompromiss, weil sie ebenfalls Zeit 
verplempert und außerdem von einer bestimmten CPU Geschwindigkeit 
ausgeht.

Jedes mal, wenn man eine Taste drückt, wird das Hauptprogramm solange 
angehalten, wie die Kontakte prellen. Je älter die Taster werden, umso 
länger wird das dauern.

Wenn man Tasten entprellen muss, dann fragt man sie in regelmäßigen 
Intervallen ab. Und die kommen üblicherweise entweder von einem 
Timer-Interrupt. Aber da gibt es noch andere Möglichkeiten.

Auf der einen Seite wollen Leute hier Daten in einstelligen 
Millisekunden übertragen, und dann kommen andere und halten das ganze 
Programm für zig Millisekunden an, bloß um eine simple Taste abzufragen. 
Das kann es doch nicht sein!

Stell Dir mal vor, dein PC würde das so mit der Tastatur und dem 
Maus-Sensor machen! Dann kannst du Videochats aber völlig vergessen. 
Selbst nebenbei MP3 anhören geht dann nicht mehr.

Es muss doch offensichtlich sein, dass man mit so einer Vorgehensweise 
nicht weit kommt.

Teo D. schrieb:
> Buck schrieb:
>> habe in einer Dimplomarbeit eine Routine gefunden (siehe Anhang). Was
>> ist mit der?
>
> Diplomarbeit in was, Sozped?
>
> So würden ANFÄNGER in BASIC programmieren

https://books.google.de/books?id=FklfDAAAQBAJ&pg=PA45&dq=software+entprellen&hl=de&sa=X&ved=0ahUKEwiv6_mzveLoAhXFwKQKHSxlDWgQ6AEIMzAB#v=onepage&q=software%20entprellen&f=false

S.45

Stefan ⛄ F. schrieb:
> Auf der einen Seite wollen Leute hier Daten in einstelligen
> Millisekunden übertragen, und dann kommen andere und halten das ganze
> Programm für zig Millisekunden an, bloß um eine simple Taste abzufragen.
> Das kann es doch nicht sein!
>
> Es muss doch offensichtlich sein, dass man mit so einer Vorgehensweise
> nicht weit kommt.

Was hat das Forum eign zu bieten, wenn man nicht mit einem AVR arbeitet?

Teo D. schrieb:
> Man steht da ein Haufen Scheiß drin! "Interrupt" statt "Index" etc. Wenn
> der sein Dipl. bekommen hat, will ich meien Prof. für lau!




https://www.medit.hia.rwth-aachen.de/fileadmin/MSP430Buch/msp_html_buch.html


habe noch was von der RWTH Aachen zu bieten... in fast allen Aufgaben

aber auch viele, sehr viele Bücher machen sich das Leben leicht...

Buck schrieb:
> https://www.medit.hia.rwth-aachen.de/fileadmin/MSP430Buch/msp_html_buch.html
>
> habe noch was von der RWTH Aachen zu bieten... in fast allen Aufgaben

siehe Aufgaben Kapitel 2

Peter D. schrieb:
> Warum weigern sich alle Anfänger so standhaft, bewährte Tutorials und
> Beispiele zu lesen?

ich glaube, es soll darum gehen, was Bücher und Schulen vermitteln...

Buck schrieb:
> Was hat das Forum eign zu bieten, wenn man nicht mit einem AVR arbeitet?

Eine ganze Menge.

Mir wurde hier zum Beispiel nahegelegt, mich mal mit STM32 zu befassen. 
Mir wurde auch dabei geholfen, dies ohne die komplexe HAL zu tun, die 
mir anfangs noch suspekt war. Ich bekam sogar zwei Beispielprogramme für 
USB (CDC) mit denen ich meine ersten Versuche rasch umsetzen konnte.

Man lernt hier nicht nur bewährte Patterns (wie Entprellung) kennen, 
sondern man kommt mit neuen und alten interessanten Bauteilen in 
Kontakt, von deren Existenz man ohne Dieses Forum vieleicht nie erfahren 
hätte.

Joggel E. schrieb:
> Absolut gar nichts. Bei uns werden solche Mitarbeiter rausgepruegelt.
> Das Entprellen macht man mit einem Timer. Natuerlich nicht blockierend.

warum wird in der Literatur oder an den Schulen kein Augenmerk darauf 
gelegt? Sind wir/ seid ihr zu pingelig?

Buck schrieb:
> warum wird ... an den Schulen kein Augenmerk darauf gelegt?

Teilweise sind die Lehrer schon glücklich, wenn ihre Schüler mehr als 
einen Absatz Text am Stück lesen und sinngemäß wieder geben können.

Stefan ⛄ F. schrieb:
> Ich erwarte von einem anständigen Compiler (und der gcc ist so einer),
> dass er das kommentarlos komplett weg optimiert*. Leider funktioniert
> die Entprellung dann aber nicht mehr richtig.
>
> *) denn diese Schleife hat keine Außenwirkung, außer eben Zeit zu
> verplempern, aber das zählt für den Compiler nicht als "wirkung".

Damit siehst du die Welt völlig anders als z.B. ich.

Ich erwarte von einem anständigen Compiler, daß er das, was ich 
geschrieben habe, korrekt und optimiert in Maschinencode umsetzt.

Aber er darf mir keineswegs über's Maul fahren und einfach Dinge, die 
ich geschrieben habe, ersatzlos wegstreichen - bloß weil seine Autoren 
nicht dasjenige haben voraussehen können, was ICH gerade bezwecken 
will.

Insofern ist der GCC eben kein anständiger Compiler, sondern einer, 
der mutwilligerweise Bugs produziert, um die man als Benutzer nen 
Workaround benutzen muß. Siehe das Thema "nop" in der kleinen 
Trampelschleife im USB-Treiber.

Viele Dinge waren und sind den GCC-Autoren bekannt, werden aber aus 
Hochnäsigkeit nicht behoben. Ich denke grad an den Ärger, den ich bei 
der Lernbetty mit .thumb und .thumbfunc gehabt habe. Daß der GCC 
fälschlicherweise Modewechselcode einbaut beim Aufruf von 
Thumb-Funktionen in Assembler aus Thumb-Funktionen heraus IST ein 
schwerer Bug - und er war jahrelang bekannt, ohne beseitigt worden zu 
sein.



Klaus schrieb:
> ich habe in einem Buch folgene Rountine zum Entprellen gefunden
> ...
> was haltet ihr davon?

Anstatt in irgendwelchen Büchern nach Quellcode zum Kopieren zu suchen, 
rate ich dir dringend an, das zugrundeliegende Problem zu erkennen und 
zu lernen, wie man Probleme löst.

Gerade das eigentlich triviale Problem der Tasten-Eingabe ist etwas, das 
man benutzen kann, um sich im logischen Denken selbst zu schulen. Das 
ist wichtig, wenn du tatsächlich das Programmieren erlernen willst.

W.S.

Klaus schrieb:
> was haltet ihr davon

Nicht in Ordnung.

Wenn nur an 1.2 der zu entprellende Taster hängt, muss man bei // hat 
sich was verändert? auch nur dieses Bit betrachten.

Hat man mehrere (bis 8) Taster, bleibt zwar die Zeile, darf man aber 
später nicht nur auf gesetzt-sein des Bits prüfen, sondern auf 
'verändert worden und gesetzt sein'. Siehe:
http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29.1
Das delay mit for 1000 ist sowieso Quatsch.

Buck schrieb:
> habe in einer Dimplomarbeit eine Routine gefunden (siehe Anhang).
> Was ist mit der?

Schwachsinn.
Wenn er vorher prüfen muss ob ein Taster gedrückt, muss er hinterher 
nicht mehr entprellen, wenn er es richtig macht.

Peter D. schrieb:
> Heutzutage haben viele Bücher kaum mehr Glaubwürdigkeit, als ein
> Twitterbeitrag.

Wissen, das in Büchern vermittelt wird und sich auf aktuelle Technik 
bezieht, habe doch inzwischen eine eher kurze Halbwertzeit, weil sich 
die Technik inzwischen schneller entwickelt als früher.
Tutorien müssten eigentluch auch von den Autoren regelmäßig überarbeitet 
werden.
Das gilt natürlich nicht für Grundlagen, die schon seit zig Jahren 
gelten.

Wenn man ein Betriebssystem verwendet, dann ist doch das "Verplempern 
von Zeit" in einer Warteschleife legitim, solange man diese Zeit anderen 
Threads zur Verfügung stellt.

Ich weiß -zielführende Vorschläge (außer dem von P.Danegger)sind hier 
nicht gern gesehen, dennoch eine Anregung:

Timerinterupt alle 1ms und dort drin im "Vorbeigehen" die zwei Pins 
abfragen, an denen der Encoder sitzt. Gleiches Ergebnis wie letztes Mal? 
Niemand hat gedreht. Anderes Ergebnis? Jemand hat gedreht. Wohin? 
Vergleich mit vorherigen Werten.

Peter D. schrieb:
> Das geht aber nur, wenn man eben keine Zählschleife hinschreibt, sondern
> eine Delayfunktion aufruft. Deren Argument ist dann die Zeit, die das OS
> anderweitig nutzen kann.
> Letztendlich wird das dann auch wieder mit einem Timerinterrupt
> realisiert, nur eben etwas mehr von hinten durch die Brust ins Auge.

Das ist richtig.
Die Version mit der Zählschleife wurde bei uns im Studium 
(Feinwerktechnik) beim 8051-Labor gelehrt. Das haben dann auch die 
Studenten verstanden, die mit sowas gar nichts am Hut hatten.
Bei den Arduino-Tutorien ist ein Blinky-Beispiel vorhanden, dass Delays 
benutzt. Die Erweiterung mit dem entsprechenden Hinweis ("Blocking...") 
wird dann auch vorgestellt, und mit Hilfe der millis()-Funktion 
implementiert.
Auf sowas soll man als Noob kommen?

Wenn ich mir die Arbeit meines Bacheloranten angucke, sehe ich auch 
Optimierungspotential. Er hatte aber auch bis zu dem Zeitpunkt keine 
Erfahrungen auf dem Programmiersektor.
Er war aber auch nicht beratungsresistent.

FeiertagsBastler schrieb:
> Timerinterupt alle 1ms und dort drin im "Vorbeigehen" die zwei Pins
> abfragen, an denen der Encoder sitzt.

Welcher Encoder ? Bist du im falschen thread gelandet ?

Teo D. schrieb:
> FeiertagsBastler schrieb:
>> Timerinterupt alle 1ms und dort drin im "Vorbeigehen" die zwei Pins
>> abfragen, an denen der Encoder sitzt.
>
> Setz da doch einfach ein xy_ms Flag. Gibt sicher noch ein paar Sachen
> mehr, denen ein solcher Timeslot gut zu Gesicht stehen würde....

Für Tasterabfragen:

Wenn ein (oder ein anderer der Taster) gedrückt wurden, lasse ich immer 
dann
(und nur dann) eine Variable in der ISR um 1 hochzählen. Hat der Zahler 
nach 41 Interrupts den Stand von 40 erreicht, dann war der Taster 40ms 
gedrückt und der Druck wirklich ernst gemeint. :)
Dann lösche ich den Zaehler, setze ein Flag in der Form "Set Merker.1"
(heißt: Taster 1 wurde gedrückt) und reagiere im Hauptprogramm auf 
diesen gesetzten Merker. Ich lösche ihn und führe die ihm zugeordnete 
Aufgabe aus.

Auf diese Weise kann ich z.B. acht Taster an einem Port abfragen, in dem 
ich nur auf die Veränderung zum "Ruhezustand" reagiere und den 
entsprechenden Merker setze.

Andreas B. schrieb:
> FeiertagsBastler schrieb:
>> Ich lösche ihn und führe die ihm zugeordnete
>> Aufgabe aus.
>
> Löschst Du in auch, wenn die Taste zwischendurch mal nicht gedrückt
> wurde  (vor 40ms Ablauf)?

Ja natürlich. Muß ich doch, da das ja auch nur eine eingefangene 
Störung gewesen sein könnte.

>
> Schon mal nicht so schlecht, aber schau Dir PeDas Routine an.

Habe ich schon, als sie vor Jahren entstand.

> Der macht
> das wesentlich geschickter.

Von mir aus. Auf die o.g. Methode bin ich selbst lange davor gekommen 
und habe sie in diversen Aufbauten verwendet. Ich trommele und trompete 
aber nicht dafür.

Lothar M. schrieb:
> Ergo darf er "unnütze und leere" Schleifen (also solche ohne
> Einwirkungen von der Umwelt und Auswirkungen auf die Umwelt) einfach
> wegoptimieren.

Und wozu hab ich die dann hingeschrieben?
Nur um dem Compiler etwas zum sofortigen Wegschmeißen zu geben?

Nein, Lothar, so sehe ich das überhaupt nicht.

Ich sag's nochmal: korrekten Maschinencode erzeugen und diesen optimal 
gestalten ist OK, aber mir als Programmierer über's Maul fahren ist ne 
dreiste Unverschämtheit.

Wenn ich eine leere Schleife hinschreibe, dann hat das für den Compiler 
zu bedeuten, daß ich eine leere Schleife im Maschinencode HABEN WILL. 
Punkt. Sonst hätte ich die nämlich nicht hingeschrieben.

Da hier enem Menge Leute nichts anderes kennen als den GCC, habe ich 
eher den Verdacht, daß die daraus resultierenden Ansichten ("Ergo darf 
er.." usw.) einfach nur eine Gewöhnung an den GCC sind - etwa so wie die 
Spritties sich an ihre Sorte Schnaps gewöhnt haben.

Trotzdem: Frohe Ostern und benutzt die Feiertage in Solitude zum 
Nachdenken.

W.S.

W.S. schrieb:
> Ich sag's nochmal: korrekten Maschinencode erzeugen und diesen optimal
> gestalten ist OK

Du weisst schon, was optimieren heisst? Das ist nicht DWIM.
Wenn du unfaehig bist, eine leere Schleife als notwendig zu markieren, 
wird ein Compiler diese Wegoptimieren.

leo

Andreas B. schrieb:
> Dann mußt Du halt die Optimierung abschalten

Nee muss man nicht. Man kann auch Assembler nehmen und Klartext 
schreiben was man will und wie taktgenau man es will.

> Wenn ich unbedingt verzögern will, dann nehme ich eben die delay
> Funktion.

Eine der vielen Funktionen die nur sinnlos Ressourcen verbraten. 
Zeitfunktionen aller Couleur gehen effizient nur unter Zuhilfenahme von 
Timer-Interrupts (auf jeder MCU).

Hallo

Peter D. schrieb:
> Warum weigern sich alle Anfänger so standhaft, bewährte Tutorials und
> Beispiele zu lesen?


Weil vor allem die Beispiele aus dem Forum, aber auch sehr viele andere, 
eben nicht detailliert erklären was innerhalb der Beispiele geschieht, 
bzw. wie man die in ein "echtes" Programm integriert so das alles 
weiterhin plus der Tastenentprellung läuft.

Es handelt sich ja um Anfänger und gar nicht mal so selten auch nur z.B. 
Modellbauer die einfach eine bezahlbare Lösung, also "Selbstbau" mit 
Chinaclone, brauchen und eben -nicht- Programmieren lernen wollen sprich 
für die die Funktion bzw. Schaltung das Ziel ist und die Programmierung 
(vorgegebenen Code zusammenstellen) nur das Mittel zum Zweck.

Versucht doch mal mit den Augen eines Anfängers die "einfach" 
Tastenentprellung die in einen schon existierenden Sourcecode eingefügt 
werden soll (oft in der "Arduinosprache") zu lesen.
Die "Erklärungen" bzw. Kommentare bei der Entprellungsroutine sind 
"immer" auf den Nutzer ausgelegt der schon Programmieren kann - diese 
Nutzer bräuchten eigentlich überhaupt keine Kommentare und Erklärungen - 
sie machen "nur" das Leben einfacher bzw. verhindern das selbst gesucht 
und detailliert nachvollzogen werden muss - also letztendlich "nur" ein 
Luxusservice.

Da eine Entprellung nun mal oft sehr wichtig ist und in produktiven 
Schaltungen auch für den Anfänger (den erwähnten Modellbauer) 
unabdinglich ist kommt es halt zu solchen Programmbeispielen wie es der 
TO im Startbeitrag vorgesetzt bekommen hat - das versteht ein Anfänger 
nach den ersten "Kapiteln" gerade noch so.
Nun ist so eine Entprellung aber bei vielen Anwendungen in der Realität 
eher "Suboptimal" ;-) und es braucht eine vernünftige Ausführung.
Wenn bei der aber nicht Anfänger tauglich (das ist der entschiedene 
Punkt) erklärt wird wie und wo diese Entprellung in ein bestehendes 
Programm integriert wird dann bringt das alles nichts.
Und eben in diesen Punkt haben die meisten Autoren keinerlei Talent und 
gehen (hoffentlich nur unbewusst) davon aus das der Nutzer fast genauso 
viel Ahnung hat wie er, der Autor, selbst.
Was nebenbei bemerkt auch ein typisches Kennzeichen für viel Fachbücher 
ist die als Publikum nicht den absoluten Anfänger als Publikum haben 
(Als schlimmes beispiel fast alle Fachbücher aus den Springer Verlag).

Hennes

nimm die Beispiele aus den Büchern..
In diesem Forum weiß jeder alles "besser" deshalb wechseln auch viele 
hier ständig ihre Jobs, da auch deren Cehfs dieses "Talent" erkannt 
haben, nd denken das er in wo anders besser aufgehoben ist..überall 
besser aufgehoben ist..als in seiner Firma..geht mit Gott..aber bitte 
geh...

An den TO Klaus:

Es ist unwahrscheinlich, dass Du den Erklärungen zu Interrupts und co 
folgen kannst, sonst hättest Du nicht diesen Code gepostet.

Der Code ist zwar übles gefrickel, aber für einen Anfänger üblich, um 
überhaupt anzufangen. Leider ist der Code ohne Erläuterung, wass er 
machen soll, und wo er wie aufgerufen wird auch nicht "verbesserbar".

Der Code ist unvollständig und ergibt so keinen Sinn.

- sind insgesamt mehrere Tasten da und nur eine gleichzeitig erlaubt?

- für die (schlechte) Pause gibt es (schlechte) Lösungen, mit volatile 
oder nop. @ W.S.: Der Compiler kann sie auch deshalb wegoptimieren, weil 
er gar nicht weiß, warum sie leer ist. Könnte auch der präprozessor 
gewesen sein.

Die Taste wird nur beim Drucken entprellt. Das ist ok, wenn es ein 
Schließer ist. Sie wird aber nicht entstört.

Es wird nicht deutlich, wo ggf der idle-code läuft. Oder gibt es keinen?

Die Tutorials hier können auch nicht alles im Detail erklären, sonst 
werden sie zu umfangreich. Ihr Sinn ist lediglich, einen 
Lösungsvorschlag und Fachwörter zu nennen, damit man sich weiter 
informieren kann.

Das ist eine Dimplomarbeit ?

Bei der Hardwareentprellung sitzt der C1 auf der falschen Seite des R2
Eine Endlosschleife in der Softwareentprellung?
Von der weg optimierten Zählschleife mag ich gar nicht reden.

Hugo H. schrieb:
> Andere blöd aussehen lassen, weil man selbst keine Ahnung hat ist
> unterste Schublade. Wenn Zitieren, dann auch richtig.
>
> (Anbei ein Ausschnitt aus der zitierten Diplomarbeit).

also er hat ja direkt im Anschluss einen Link zu Arbeit gepostet, somit 
kann sich jeder ein eigenes Bild maachen. Immer dieses rumgejaule für 
nichts, echt kleingeistig

Buck schrieb:

> Was hat das Forum eign zu bieten, wenn man nicht mit einem AVR arbeitet?

Sinnvolle Konzepte.

Die sind völlig unabhängig von der Zielarchitektur. Man muß sie nur 
begreifen und ggf. geeignet modifizieren können...

Dann funktionieren sie auf einem AVR8 mit 1MHz Takt genauso gut wie auf 
einem Intel der 9. Generation mit 4GHz Takt.

Ja, das ist nix für reine C&Pler. Die fallen auf die Schnauze. Sie 
begreifen weder das Konzept, noch sind sie in der Lage, es ggf. auf das 
Target anzupassen.

Nunja, meine Katze kann auch nicht programmieren. Allerdings: SIE ist 
immerhin klug genug, es erst garnicht zu versuchen...

c-hater schrieb:
> Sinnvolle Konzepte.
>
> Die sind völlig unabhängig von der Zielarchitektur. Man muß sie nur
> begreifen und ggf. geeignet modifizieren können...
>
> Dann funktionieren sie auf einem AVR8 mit 1MHz Takt genauso gut wie auf
> einem Intel der 9. Generation mit 4GHz Takt.
>
> Ja, das ist nix für reine C&Pler. Die fallen auf die Schnauze. Sie
> begreifen weder das Konzept, noch sind sie in der Lage, es ggf. auf das
> Target anzupassen.
>
> Nunja, meine Katze kann auch nicht programmieren. Allerdings: SIE ist
> immerhin klug genug, es erst garnicht zu versuchen...

willkommen im Steinzeitalter, das Alphamännchen hämmert sich auf die 
Brust um gleich darauf die Frauen zu begatten

oh Thomas, du hast diesmal wirklich die falschen Worte getroffen. Ich 
hätte es wohl eher so formuliert: Andreas hat wohl schon resigniert, 
mehr wird er im Leben nicht erreichen

merkst doch, wie schnell es hier still wird. Scheint ja kein seltender 
Fall im Forum zu sein...

wegen solchen Personengruppen gehen emanzipierte junge Frauen auf die 
Straße...

Mw E. schrieb:

> Optimieren beinhaltet nunmal sinnlose Dinge wegzustreichen.

Das ist korrekt. Nur ist ein Compiler leider VIEL zu blöd, zu 
erkennen, was konkret sinnlos oder sinnvoll ist.

Das (und vieles andere) muß ihm sein genervter Benutzer mit viel 
nichtportablem Syntax-Bombast erst beibiegen. Sprich: hier wird massiv 
zusätzliche Komplexität geschaffen, um an anderer Stelle Komplexität 
wegzuabstrahieren zu können.

Jedem Normaldenkenden sollte klar sein: so ein Ansatz kann nur ein 
Kompromiss sein. Und jedem mit hinreichender Erfahrung ist sogar klar: 
das ist ein SEHR fauler Kompromiss. Insbesondere für "kleine" Targets, 
wie etwa AVR8.

Deswegen programmiere ich die AVR8 immer komplett in Assembler. Der 
Gewinn an Produktivität durch den Compiler ist hier komplett in den Skat 
zu drücken. Bringt im besten Fall knapp über garnix (jedenfalls, wenn 
man halt auch Assembler beherrscht) und immer wenn es in die Richtung 
geht, den µC wirklich auszunutzen zum müssen, ist es sogar dramatisch 
kontraproduktiv.

Wenn du anderer Meinung bist: Wenn du meine beiden Buddelschiffe aus 
"Projekte und Code" in C umgesetzt hast, können wir weiter 
diskutieren...

Bis dahin bist du nur ein armes irregeleitetes Würstchen...

Übrigens: ICH könnte das auch in C umsetzen (natürlich nur mit sehr 
viel Inline-Assembler). Das Ergebnis wäre dann allerdings genauso 
portabel wie purer Assemblercode, also praktisch garnicht, spätestens 
sobald man die Architektur verläßt. Also warum sollte man sich dann 
diesen SCHEISS antun, wenn's in Asm viel einfacher geht?

Nenne einen vernünftigen Grund dafür. Und nein: "Ich kann nur C" gilt 
hier nicht! Das könnte man nämlich ändern, wenn man wollte...

c-hater schrieb:

Dem ist nichts, aber auch gar nichts hinzuzufügen.
Nur das Würstchen hätte man weglassen sollen...

Leider erschließen sich die Vorteile von Asm vs. C auf kleinen MCUs nur 
demjenigen der beides kennt. Und die Vorteile einer Hochsprache gibts 
eben nicht für lau, so wie alles im Leben.

Carl D. schrieb:
> Der eine benutzt zur Metallbearbeitung eben eine Feile, der andere
> eine CNC-Station. Bei Software ist heutzutage das (zum Glück) nicht mehr
> eine Frage des Geldes, sondern nur noch des Bedienenkönnes. Und feilen
> haben viele CNC-Bediener früher auch mal gelernt.

Ein ziemlich dummer Vergleich.

Peter D. schrieb:
> Karl B. schrieb:
> AVR hat da noch ein As im Ärmel: Das T-Flag.
>
> Gegenüber den Möglichkeiten des C-Flags beim 8051 sieht das T-Flag
> schlichtweg erbärmlich aus und nicht wie ein Ass. Man kann keine IO-Bits
> nach T moven, verodern, anden oder von T ausgeben, nicht mal togglen
> kann man es. Nur moven von und zu Registerbits geht. Es spart daher nur
> selten mal ein Wort Code. Hätte man es weggelassen, niemand würde es
> vermissen.

Oh dann würde aber eine Menge Software nicht mehr funktionieren. Es 
eignet sich nämlich ganz hervorragend als unabhängiges Merk/Statusbit in 
vielen Routinen und kann bei geschicktem Einsatz als Übergabeparameter 
eine ganze Menge Code sparen. Moven von IO Bits von/nach T samt der 
genannten Verarbeitungsschritte geht natürlich nur über den 
Register-Umweg, das ist richtig. Doch warum sollte man die moven wenn 
man viele davon jederzeit auch direkt auswerten kann (sbis/sbic).

Carl D. schrieb:

> Der eine benutzt zur Metallbearbeitung eben eine Feile, der andere eine
> CNC-Station.

Jepp. Und der korrekte Metallbauer beherrscht halt auch die Feile. Wenn 
es Vorteile verspricht, sie einzusetzen...

Mehr noch: der korrekte Metallbauer kann problemlos erkennen, wann es 
Vorteile verspricht.

Und: der korrekte Metallbauer verbreitet nicht das unhaltbare Mantra, 
dass die CNC-Maschine die EINZIGE Möglichkeit wäre, Metall zu 
bearbeiten.

Genau diese Behauptung ist eigentlich, was mich schon immer am meisten 
gestört hat...

Teo D. schrieb:
> Also kurz und bündig, ich mach in C, weil ich faul bin.
> (Codegeneratoren etc inkl.)

Also kurz und bündig, ich mach in C++, weil ich faul bin.

Hier mal ein C++ Entpreller im beispielhaften Einsatz.
Und noch ein paar Flankenverzögerer in Kette
Natürlich voll auf Arduino!

1

#include <CombieTimer.h>

2

#include <CombiePin.h>

3

#include <CombieTypeMangling.h>

4

5

using namespace Combie::Pin;

6

using namespace Combie::Timer;

7

using namespace Combie::Millis;

8

9

TasterGND<2> S1; // Taster zwischen Pin und GND(invertierend)

10

OutputPin<3> OUT1;

11

12

13

14

EntprellTimer    entprell { 20_ms};  // Schalter entprellen

15

RisingEdgeTimer  ton      { 3_sec};  // steigende Flanke wird verzoegert

16

FallingEdgeTimer toff     { 5_sec};  // abfallende Flanke wird verzoegert

17

18

void setup(void)

19

{

20

  S1.initPullup();

21

  OUT1.init();

22

}

23

24

void loop(void)

25

{

26

  OUT1 = toff = ton = entprell = S1;

27

}

Die Libs halte ich erstmal geheim, interessiert doch sowieso kaum einen 
hier.

Ämm..
Falls das jemand für eine Provokation hält, dann ist das sicherlich kein 
kleiner Dummkopf.

Teo D. schrieb:

> Also kurz und bündig, ich mach in C, weil ich faul bin.

Natürlich, ich doch auch. Programmierer sind faul. Das ist eine Art 
Naturgesetz.

Allerdings: Man sollte auch nicht ZU faul sein. Sonst kann die 
vermeintliche Arbeitsersparnis ganz schnell in tatsächlichen Mehraufwand 
umschlagen...

Man merkt's nur nicht, wenn man halt mögliche Alternativen nicht kennt 
und nicht beherrscht...

Teo D. schrieb:
> "Einfacher" ist halt relativ. Also ICH brauch alleine für die
> Queltexteingabe, in Ass 3-5x so lange.

Das mag für viele Dinge wie Berechnungen gelten wenn man keine 
entsprechenden Bibliotheksroutinen aufrufen kann.
Wenn wir aber beispielsweise von einer kleinen Aufgabe wie dem 
Entprellen reden dann ist das in Asm kürzer und platzsparender 
formuliert als in jeder Hochsprache. Deshalb meine ich auch 
übersichtlicher, was freilich auch Erfahrungssache sein dürfte.

Carl D. schrieb:
> Dumm ist eher daß der CNC-Hasser meint, einzig die Feile wäre richtig.

Zweifellos- alles hat eben sein passendes Zielgebiet.
Werden die Controller größer bleibt Asm immer weniger Gelände.

Carl D. schrieb:

> Dumm ist eher daß der CNC-Hasser meint, einzig die Feile wäre richtig.

Sagt er garnicht...

Im Gegensatz zu deinen vielfach nachweisbaren Bahauptungen, allein die 
CNC-Maschine wäre richtig für alles...

Genau das ist der Unterschied zwischen Pragmatiker und Fanatiker...

Stefan ⛄ F. schrieb:
> Ich erwarte von einem anständigen Compiler (und der gcc ist so einer),
> dass er das kommentarlos komplett weg optimiert*.

Wenn man ihm das erlaubt!

W.S. schrieb:
> Ich erwarte von einem anständigen Compiler, daß er das, was ich
> geschrieben habe, korrekt und optimiert in Maschinencode umsetzt.
>
> Aber er darf mir keineswegs über's Maul fahren und einfach Dinge, die
> ich geschrieben habe, ersatzlos wegstreichen - bloß weil seine Autoren
> nicht dasjenige haben voraussehen können, was ICH gerade bezwecken
> will.

Schön, dass ihr einer Meinung seid. Das nette ist, dass sich der gcc 
wirklich so verhält, wie es W.S. es gerne hätte. Man muss dem gcc 
erlauben, dass er Leerschleifen weg optimiert. Bei -O0 (oder ohne -O) 
macht er das nämlich nicht.

Wenn man nun -Ox mit x>0  benutzt, sollte man schon wissen, was seine 
Tools machen. Erst bei -O2 bleibt von der Leerschleife nichts mehr 
übrig. (arm-none-eabi-gcc 6.3.1)

Diese Funktion:

void optimierung(void)
{
    for (int i=0; i<1000; i++);
}

wird so compiliert:

1) arm-none-eabi-gcc dummy.c -S

optimierung:
  @ Function supports interworking.
  @ args = 0, pretend = 0, frame = 8
  @ frame_needed = 1, uses_anonymous_args = 0
  @ link register save eliminated.
  str  fp, [sp, #-4]!
  add  fp, sp, #0
  sub  sp, sp, #12
  mov  r3, #0
  str  r3, [fp, #-8]
  b  .L2
.L3:
  ldr  r3, [fp, #-8]
  add  r3, r3, #1
  str  r3, [fp, #-8]
.L2:
  ldr  r3, [fp, #-8]
  cmp  r3, #1000
  blt  .L3
  nop
  add  sp, fp, #0
  @ sp needed
  ldr  fp, [sp], #4
  bx  lr
  .size  optimierung, .-optimierung
  .ident  "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620"

2) arm-none-eabi-gcc dummy.c -O1 -S

optimierung:
  @ Function supports interworking.
  @ args = 0, pretend = 0, frame = 0
  @ frame_needed = 0, uses_anonymous_args = 0
  @ link register save eliminated.
  mov  r3, #1000
.L2:
  subs  r3, r3, #1
  bne  .L2
  bx  lr
  .size  optimierung, .-optimierung
  .ident  "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620"

3) arm-none-eabi-gcc dummy.c -O2 -S

optimierung:
  @ Function supports interworking.
  @ args = 0, pretend = 0, frame = 0
  @ frame_needed = 0, uses_anonymous_args = 0
  @ link register save eliminated.
  bx  lr
  .size  optimierung, .-optimierung
  .ident  "GCC: (15:6.3.1+svn253039-1build1) 6.3.1 20170620"

W.S. schrieb:
> Insofern ist der GCC eben kein anständiger Compiler

Doch, der gcc ist ein "anständiger" Compiler. Nur halt nicht Bug frei!

Peter D. schrieb:
> Da hast Du recht. Den Zuweisungsoperator zu vergewaltigen, nur damit
> unlesbarer Code ensteht, will keiner haben.
> Auch wenn Du es ständig wiederholst, wird es davon nicht besser.

Na, na...
Erstmal: Nicht nur der Zuweisungsoperator!
Und dann schon gar nicht, aus dem von dir genannten Grund.

Zudem bieten sich ja ein paar Schreibweisen an:

1

OUT1 = toff = ton = entprell = S1;

1

OUT1(toff(ton(entprell(S1()))));

1

OUT1.set(toff.doTrigger(ton.doTrigger(entprell.doTrigger(S1.pressed()))));

Funktional gleichwertig.

Welche jetzt lesbarer ist?

c-hater schrieb:
> edem Normaldenkenden sollte klar sein: so ein Ansatz kann nur ein
> Kompromiss sein.

Ja

> Und jedem mit hinreichender Erfahrung ist sogar klar:
> das ist ein SEHR fauler Kompromiss.

Nein, es ist ein sehr guter Kompromiss, denn er tut fast immer das, was 
man erwartet. Und wenn man etwas anderes erwartet hat, hilft ein Blick 
in das Assembler Listing und danach ein Blick in die 
Bedienungsanleitung.

Bei dieser Wiederholschleife genügt ein simples NOP, und schon wird sie 
nicht mehr weg optimiert. Diese Eigenarten des Compilers hat man schnell 
im Kopf und andere Compiler verhalten sich weitgehend identisch*, so 
dass man dieses Wissen auch auf ganz anderen Maschinen wieder anwenden 
kann.

*) Sogar Java optimiert leere Schleifen weg!

Peter D. schrieb:
> Nun, wer beides gut kann, der weiß aber auch, daß man die ganz wenigen
> Stellen, wo Assembler Vorteile hat, mit der Lupe suchen muß.

c-hater schrieb:
> Wenn du anderer Meinung bist: Wenn du meine beiden Buddelschiffe aus
> "Projekte und Code" in C umgesetzt hast, können wir weiter
> diskutieren...

Dann mal los, Peter! :)

c-hater schrieb:
> Wenn du anderer Meinung bist: Wenn du meine beiden Buddelschiffe aus
> "Projekte und Code" in C umgesetzt hast, können wir weiter
> diskutieren...

Warum sollte jemand deine Projekte nachmachen, um Anerkennung von Dir zu 
erhalten?

Carl D. schrieb:
> es gibt beim GCC "built in functions"

Schön daß Du drauf hinweist.
Es gibt derer so viele Funktionen die kaum einer alle kennt.
Es gibt die vielen Eigenarten von Compilern.
Es gibt die vielen Optionen von Compilern.
Es gibt sogar Bugs in Compilern.
Programmtexte sind zum Funktionsverständnis oft intransparent weil sie 
zu kryptische Ausdrücke enthalten undoder  Funktionalität hinter 
geheimnisvollen Libs verbergen.

Gut, daß es Assembler gibt.

Peter D. schrieb:

> Nun, wer beides gut kann, der weiß aber auch, daß man die ganz wenigen
> Stellen, wo Assembler Vorteile hat, mit der Lupe suchen muß.

Das kann nur jemand von sich geben, der niemals das Mögliche aus den 
Kleinen herausgeholt hat oder es auch nur versucht hat, dies zu tun...

Aber wenn du ernsthaft glaubst, dass du das kannst: setze einfach meine 
Buddelschiffe in C um. Sollte ja deiner Meinung nach absolut problemlos 
gehen. Die Stellen, wo Assembler Vorteile bringt, muß man ja deiner 
hochkompetenten Aussage zufolge schließlich sowieso mit der Lupe suchen, 
kann also doch kein ernsthaftes Problem für dich erfahrenen und als 
solcher über jeden Zweifel erhabenen C-Programmierer sein...

c-hater schrieb:
> Das kann nur jemand von sich geben, der niemals das Mögliche aus den
> Kleinen herausgeholt hat oder es auch nur versucht hat, dies zu tun...

Du sagst das, als ob er keine Ahnung vom Programmieren hätte. Ich 
jedenfalls kenne da zwei Seiten:

a) Als Hobbyprogrammierer kann ich beliebig viel Zeit in meine Projekte 
stecken. Da macht es mir gelegentlich Spaß, aus ganz kleinen 
Mikrocontrollern das Letzte heraus zu holen.

b) Als professioneller Programmierer muss ich dem Wunsch des Kunden 
nachkommen, möglichst preisgünstig zu arbeiten. Und das läuft in meinem 
Bereich zu 100% darauf hinaus, möglichst viel Arbeitsleistung auf 
Hardware und fertige suboptimale Bibliotheken zu verteilen, damit ich 
selbst möglichst wenig Stunden verbrauche.

Bekannt ist mir noch die Variante c) Wo man Massenprodukte optimiert, 
indem man auf billigste Hardware setzt, selbst wenn dadurch die 
Entwicklungskosten einmalig höher sind.

Du mein lieber c-hater bist mental ausschließlich in der Liga a 
unterwegs. Das ist Ok, aber erzähle den anderen die professionell tätig 
sind nicht, dass die dumm seien. Was hast du schon geleistet, dass du 
dir so ein Urteil erlauben darfst. Hast du wenigstens eine Doktorarbeit 
gemacht? Das wäre das mindeste, was eine leichte Überheblichkeit 
rechtfertigen würde.

Peter D. schrieb:
> Tom schrieb:
>> Dann mal los, Peter! :)
>
> Erstmal finden.

"Buddelschiff" wäre ein ziemlich cleverer Suchbegriff...

Liefert die entsprechenden Threads auf Rang 2 und 4...

Stefan ⛄ F. schrieb:

> Du sagst das, als ob er keine Ahnung vom Programmieren hätte.

Weil er es so schreibt, als wäre es so. Natürlich weiß ich, daß er 
eigentlich auch weiß, daß ich Recht habe. Hätte er das auch 
dementsprechend formuliert, wäre ich schon raus gewesen aus der 
Diskussion.

Er beharrte aber mit fast schon peinlicher Penetranz darauf, wider 
besseren Wissens objektive Tatsachen zu negieren. Und das kann und darf 
einfach nicht unwidersprochen bleiben.

> Du mein lieber c-hater bist mental ausschließlich in der Liga a
> unterwegs.

Ach ja? Was glaubst du, womit ich meine Brötchen verdiene? Und inwiefern 
mich das dann qualifiziert hat, solche Hobbyprojekte umzusetzen, 
Harry-Potter-Magie oder wie stellst du dir das vor?

Nein, es ist natürlich so, wie jeder normaldenkende Mensch vermuten 
würde: Ich mache die Sache professionell, und gelegentlich gelangt mal 
was, was ich rein zur Entspannung und aus Langerweile nebenbei mal als 
Hobbyprojekt umsetze an die Öffentlichkeit.

Carl D. schrieb:
> Ja, das ist genauso wie MOV, LD, LDS, LDDS, L, LDEQ, LDMI, LDMIA, ....

Nun, darauf beschränkts sich dann aber auch.
Passt bei kleinen Controllern auf ganz wenige Seiten.
Jede Instruktion für sich mit ganz einfacher Funktionalität.

>  PIC, AVR, ARM, x86, i51,
> /390, alle sprechen ASM.

Aber nur ganz wenige Anwender brauchen sie alle.
Die unterschiedliche Hardware macht Programme ohnehin ganz selten 
absolut portabel.

Andreas B. schrieb:

> Und Du glaubst jetzt allen Ernstes daß hier irgend jemand versucht, das
> zu dissassemblieren um Deine genialen Programmierkünste zu entdecken?

Braucht er doch nicht. Einfach nur in C selber bauen. Soll ja so ganz 
einfach sein und überhaupt kein Problem. In C geht alles und es stellt 
auch keinerlei Nachteil gegenüber der Verwendung von Assembler dar. 
Nein, es gibt da ja überhaupt nur Vorteile, nix anderes. Sollte allso 
für all die hochgeschätzten C-Apologeten hier eine leichte Fingerübung 
sein. Zumal die Architektur der Software bei beiden Projekten 
wahrheitsgetreu beschrieben ist, der Algorithmus muss also nichtmal 
erfunden werden, nur nachgebaut...

c-hater schrieb:
> Was glaubst du, womit ich meine Brötchen verdiene?

Das weiß ich nicht, aber deine Äußerungen passen nur zur Kategorie a. 
Ich würde dich nicht einstellen weil ich befürchten würde, dass du sehr 
viel zeit mit deinem manuell optimierten Assembler verschwenden würdest.

Es könnte natürlich sein, dass du an einer Stelle arbeitest, wo genau 
das gefragt ist. Das würde ich Dir jedenfalls wünschen. Wenn man das 
machen darf, was man am besten kann, ist damit doch allen geholfen.

Carl D. schrieb:

> Viel schlimmer als seine technischen Ansichten wären seine
> Umgangsformen. Um solche Leute versuche in real immer einen großen Bogen
> zu machen.

Du weichst hier ganz offensichtlich vom Thema ab...

Warum wohl...

Ich habe mal promoviert. Wofür man andere bezahlt, ist mir wirklich egal

c-hater schrieb:
> Ich habe mal promoviert.

Bei aller (meiner) Sympathie für die sachlich technischen Argumente 
würden sich sicher viele hier glücklich schätzen wenn sich das auch in 
den menschlichen Umgangsformen ausdrücken würde.