|
|
Forum: Mikrocontroller und Digitale Elektronik Entprellen (kein AVR)ich habe in einem Buch folgene Rountine zum Entprellen gefunden
was haltet ihr davon? :
Gesperrt durch Moderator
Klaus schrieb: > was haltet ihr davon? Kann man so machen.
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. Klaus schrieb: > was haltet ihr davon? Funktionierendes aber unbrauchbares Gefrickel. OK, für simplere Bastelprojekte durchaus nutzbar. Ich würde mich allerdings schämen.... (Hab allerdings auch schon schlimmeres Verbrochen:) 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".
Angehängte Dateien:
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. 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. 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? Buck schrieb: > 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 Man steht da ein Haufen Scheiß drin! "Interrupt" statt "Index" etc. Wenn der sein Dipl. bekommen hat, will ich meien Prof. für lau! Wieso "kein AVR"? PeDas Code stammt vermutlich vom 8051 und hat (in der C-Version) mit AVR nur insoweit zu tun, daher AVR-Io-Register verwendet. Der Algorithmus selbst hat mit der Ziel-HW nichts zu tun. Mal schauen wie lange es heute dauert, bis die erste lösbare Lösung kommt. Zu Ostern vielleicht mit den bunten Cs. 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 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 Klaus schrieb: > was haltet ihr davon? Sag mal, rede ich gegen ne Wand? Das Thema wurde doch gerade bis zum Erbrechen durchgekaut. Warum weigern sich alle Anfänger so standhaft, bewährte Tutorials und Beispiele zu lesen? Und AVR spezifisch ist auch nur die Syntax für Port einlesen und Timerinterrupt aufsetzen. Der Algorithmus selber ist Hardware unabhängig. 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... Peter D. schrieb: > Das Thema wurde doch gerade bis zum Erbrechen durchgekaut. Beitrag "Re: kein definiertes Verhalten in der ISR" Peter D. schrieb: > Peter D. schrieb: >> Das Thema wurde doch gerade bis zum Erbrechen durchgekaut. > > Beitrag "Re: kein definiertes Verhalten in der ISR" Aber noch nicht heute und noch nicht von jedem ;-) 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. > for(i = 0; i < 1000; i++) {} // kurze Pause > was haltet ihr davon? Absolut gar nichts. Bei uns werden solche Mitarbeiter rausgepruegelt. Das Entprellen macht man mit einem Timer. Natuerlich nicht blockierend. 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. Hallo, > Warum weigern sich alle Anfänger so standhaft, bewährte Tutorials und > Beispiele zu lesen? Weil es sich beim Abfragen eines Tastenstatus um ein scheinbar extrem einfaches Problem handelt. Wenn dann durch das Tastenprellen doch Probleme auftauchen, ist die intuitiv einfachste Lösung eben den Tastenstatus mehrfach mit Pausen dazwischen abzufragen. Und die einfachste Möglichkeit eine Pause zu machen ist nun mal einfach Rechenzeit in Form einer Schleife zu verplempern. Das leuchtet sofort ein. Das diese Methode den Programmablauf blockiert, ist für einen Anfänger zunächst irrelevant. Das Konzept ein Multitasking per Timer-Interrupt zu implementieren, muss ein Anfänger auch erst mal verstehen, zumal in praktisch keinem Programmier(sprachen)-Lehrbuch irgend was dazu steht. Und wenn man eh noch mit den Grundlagen kämpft, erscheint das Ganze zudem enorm komplex und scheinbar unnötig umständlich. Also wird ein schön serieller Programmablauf ohne jede Nebenläufigkeit umgesetzt. Wie schwierig das Denken in Nebenläufgkeit für manche sein kann sieht man exemplarisch in folgender Diskussion: Beitrag "I2C "blockiert" Arduino [Endet 31.10.]" Kurz: für Profis ist die "richtige" Lösung völlig einleuchtend, während dem Anfänger die Problematiken und die daraus ergebenden Fragestellungen nicht mal bewusst sind. rhf 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. Roland F. schrieb: > ist die intuitiv einfachste Lösung eben den > Tastenstatus mehrfach mit Pausen dazwischen abzufragen. Nach dem Delay wird aber nicht nochmal abgefragt, sondern einfach übernommen. Jeder Störimpuls bewirkt daher ein Tastenereignis. "Lehrstuhl für Medizinische Informationstechnik (MEDIT)" ...hört sich spannend an...nun ja, Reiter werden ja auch immer gebraucht... Gruß Rainer Klaus schrieb: > ich habe in einem Buch folgene Rountine zum Entprellen gefunden Früher hat man Artikel erstmal in einem Fachblatt veröffentlich, wo sie dann von Fachleuten gründlich verrissen werden konnten. Erst dann hat man ein Buch geschrieben, was nochmal Korrektur gelesen wurde. Heutzutage haben viele Bücher kaum mehr Glaubwürdigkeit, als ein Twitterbeitrag. Auch im Internet gibt es leider viel Müll, den man aussortieren muß. In der Regel ist das nicht schwer, da ja jeder Kommentare verfassen kann. An den positiven Kommentaren oder Bewertungen kann man erkennen, ob der Artikel fundiert ist. Keine Kommentare bedeuten oft, daß er so schlecht ist, daß er eines Kommentars nicht würdig ist. W.S. schrieb: > 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. Im Prinzip wäre es ideal, wenn der Prozessor jede Hochsprachen-Programmzeile in "null Zeit" ausführen könnte. Dann hätte er maximale Rechenleistung. Und weil dann jeder einzelne Schritt der Schleife in "null Zeit" ausgeführt würde, würde jede "leere" Schleife (und konsequenterweise sogar eine "leere" Endlosschleife!) in "null Zeit" ausgeführt. Ergo darf er "unnütze und leere" Schleifen (also solche ohne Einwirkungen von der Umwelt und Auswirkungen auf die Umwelt) einfach wegoptimieren. > Ich erwarte von einem anständigen Compiler, daß er das, was ich > geschrieben habe, korrekt und optimiert in Maschinencode umsetzt. Ich kann so eine Schleife aber auf viele Arten "optimieren". Wei soll der Compiler erkenne, welche Art von "optimierten Maschinencode" dir da vorschebt? Und wenn der einzige offensichtlich erkennbare Sinn der Schleife das Hochzählen einer Variablen von 0 auf 1000000 ist, dann ist für mich die Zeile i=1000000; exakt funktionsgleich wie die Schleife for (i=0; i<1000000;) i++; Denn nach der Abarbeitung sowohl der einen Zeile wie auch der gesamten Schleife steht in i der Wert 1000000. > Insofern ist der GCC eben kein anständiger Compiler, sondern einer, der > mutwilligerweise Bugs produziert, um die man als Benutzer nen Workaround > benutzen muß. Wenn man eine Programmzeile für die Rechenzeitverschwendung braucht, dann muss das explizit hingeschrieben werden. W.S. schrieb: > 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. +10 Und natürlich darf man sich dazu mal den Code anderer ansehen und ihn auf Vorteile und Schwächen analysieren. Es ist aber generell eine schlechte Idee, daraus eine Publikumsfrage zu machen. Denn wenn du mit diesem Code (den du selbst nicht verstehst) danach ein Problem hast, dann hast eben nur du damit ein Problem. :
Bearbeitet durch Moderator
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. STK500-Besitzer schrieb: > 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. 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. 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. 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.... 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. FeiertagsBastler schrieb: > Für Tasterabfragen: > > Wenn ein (oder ein anderer der Taster).... > ... Ich mach halt das GANZE lieber außerhalb einer ISR, dann weis ich wenigstens, das es keine anderen evtl. zeitkritischeren Dinge, in die Quere kommt! 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)? Schon mal nicht so schlecht, aber schau Dir PeDas Routine an. Der macht das wesentlich geschickter. Carl D. schrieb: > PeDas Code stammt vermutlich vom 8051 Jemand hat das mal auf ARM portiert. Der Hauptunterschied ist, daß dann nicht 8 Pins, sondern 32 Pins parallel entprellt werden. Natürlich kann man auch auf dem AVR uint32_t nehmen und 4 Ports per Shift zusammen fassen. Manche ARMs haben ulkiger Weise trotz 32Bit Architektur nur 16Bit Ports und 16Bit Timer. Da kann ich nur sagen, was hat deren Entwickler denn geraucht. Teo D. schrieb: > Ich mach halt das GANZE lieber außerhalb einer ISR Gerade das ist blöd, wenn die Mainloop mal etwas länger braucht und der Tastendruck schon vorbei ist. Das ärgert den Benutzer sehr, wenn Tastendrücke ignoriert werden. Der Interrupt indes setzt ein Ereignisflag, was die Mainloop auswertet, wenn sie wieder Zeit hat. So geht kein Tastendruck verloren. Der Entprellinterrupt hat außerdem so lächerlich wenig zu tun, daß er mit Abstand die kürzeste Interrupthandler im gesamten Programm ist. 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. Peter D. schrieb: > Carl D. schrieb: >> PeDas Code stammt vermutlich vom 8051 > > Jemand hat das mal auf ARM portiert. Der Hauptunterschied ist, daß dann > nicht 8 Pins, sondern 32 Pins parallel entprellt werden. Ich hab den als C++-Template, da kann ich dann Breite, etc. konfigurieren. Da ist ja auch nichts Plattform-Abhängiges dran. Im Flash sieht man übrigens nicht, daß das nicht "optimiert" im Sourcecode steht. > Natürlich kann man auch auf dem AVR uint32_t nehmen und 4 Ports per > Shift zusammen fassen. Das sorgt aber nur für größeren Registerbedarf und solange die einzelnen Bits unabhängig von einander sind, wäre mehr als uint8_t kein muß, aber langsamer. Dann besser mehrere "Entprell"-Instanzen. :
Bearbeitet durch User
MaWin schrieb: > später nicht nur auf gesetzt-sein des Bits prüfen, sondern auf > 'verändert worden und gesetzt sein'. Hi, AVR hat da noch ein As im Ärmel: Das T-Flag. Und die dazu spezifischen Befehle. Und Statusbit in Flag-Register kopieren. Wird in der Main dann bearbeitet und gelöscht. Aber TO will ja kein AVR. ciao gustav 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. > > 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. Immer wieder erheiternd, dass du so großschneuzig zur Schau stellen musst, dass du auch von wirklich garnichts ne Ahnung hast. Optimieren beinhaltet nunmal sinnlose Dinge wegzustreichen. Aber mit einem "asm volatile("": : :"memory");" in der Schleife ist der Drops dann gelutscht. Zum Glück ist der GCC ein ordentlicher Compiler nach GNU und kein ordentlicher Compiler nach W.S. Mit sowas will man dann nicht arbeiten. 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. 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. Es wird aber vom GCC zum Umsortieren von Bits verwendet, was hielt, wenn mehr-Bit-Werte eher nach Layouterfordernissen auf die Ports verteilt sind. Ganz ohne Einsparungen ist das nicht, um so mehr, je "wilder" die Bits verteilt sind. Man kann eben ohne zusätzlichen Register mit 2 Befehlen einzelne Bits entnehmen und wo anders wieder einfügen. Mit AND, n*SHIFT, OR wäre das komplizierter. Und wie gesagt, GCC weiß das. Aber klar 8051 nennt sich ja auch "Bit-Manipulationsprogramm-Maschine". Da gehört "Rechnen" mit dazu. Ich gehe mal davon aus, das der ursprünglich Programmierer vom Programmieren keine Ahnung hatte, aber lesen konnte (ein Fluch unter dem viele leiden). Man kann ja auch kaum einen Text übers Programmieren lesen, ohne über den Satz: "Finger weg von delay()" zu stolpern. Dass die Zeile mit dem for das gleiche macht interessiert ja keinen, aber delay wurde auf jeden Fall nicht aufgerufen. Interessant in diesem Zusammenhang ist, dass - eigentlich - in diesem Falle delay sogar besser wäre. Natürlich nur, wenn man dem Compiler, irgendwie, den aktuellen Takt beibringt und "lesbare" Zeiten übergibt. Ich jedenfalls habe keine Ahnung, welche Verzögerung das Zählen bis 1000 bewirkt. Sebastian S. schrieb: > Ich gehe mal davon aus, das der ursprünglich Programmierer vom > Programmieren keine Ahnung hatte, aber lesen konnte (ein Fluch unter dem > viele leiden). Man kann ja auch kaum einen Text übers Programmieren > lesen, ohne über den Satz: "Finger weg von delay()" zu stolpern. Dass > die Zeile mit dem for das gleiche macht interessiert ja keinen, aber > delay wurde auf jeden Fall nicht aufgerufen. > Interessant in diesem Zusammenhang ist, dass - eigentlich - in diesem > Falle delay sogar besser wäre. Natürlich nur, wenn man dem Compiler, > irgendwie, den aktuellen Takt beibringt und "lesbare" Zeiten übergibt. > Ich jedenfalls habe keine Ahnung, welche Verzögerung das Zählen bis 1000 > bewirkt. Es gibt auch Intrinsics, die Takt-genau erzögen:
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 W.S. schrieb: > 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. Dann mußt Du halt die Optimierung abschalten, wenn Du nicht willst, daß der Compiler sinnlose Befehle wegoptimiert. Der gcc bietet Dir da viele Optionen. Wenn ich unbedingt verzögern will, dann nehme ich eben die delay Funktion. Man muß auch mit den Werkzeug umgehen können. Ich persönlich nehme halt lieber Timer. Dann brauche ich kleinere Taktraten und spare Strom. Ich glaube ich komme auch langsam drauf, warum die STM so beliebt sind. Da denke ich mal drüber nach..... 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). Asm'ler 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. Wir reden hier aber vom gcc Asm'ler schrieb: >> Wenn ich unbedingt verzögern will, dann nehme ich eben die delay >> Funktion. > > Eine der vielen Funktionen die nur sinnlos Ressourcen verbraten. Da stimme ich Dir vorbehaltslos zu. Deshalb schrieb ich auch "unbedingt". Asm'ler schrieb: > Eine der vielen Funktionen die nur sinnlos Ressourcen verbraten. > Zeitfunktionen aller Couleur gehen effizient nur unter Zuhilfenahme von > Timer-Interrupts (auf jeder MCU). Das setzt aber voraus, dass das betreffende System überhaupt Timer und/oder Interrupts aufweist. Es gibt auch prominente Gegenbeispiele wie z.B. bo8. 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 Na ja, es gibt 2 sinnvolle Möglichkeiten: 1) Ich habe Ahnung. Dann lese ich die entsprechenden Artikel, verstehe ihn und weiß dann wie der Hase läuft. Dann kann ich auch Modifikationen vornehmen oder eine eigene SW schreiben, einfach weil ich es verstanden habe. 2) Ich habe keine Ahnung, dann lese ich den Artikel, verstehe es nicht, vetraue aber den Leuten, die Ahnung davon haben und benutze diese SW einfach Nicht geht und was hier kritisiert wird: 3) Ich habe keine Ahnung, weiss alles besser und bin beratungsresistent. Dann werden hier irgendwelche Elaborate reingestellt und pampig reagiert, wenn dann drauf eingedroschen wird. Dann frage ich mich halt, warum diese Leute dann hier im Forum fragen wenn sie eh alles besser wissen. Es wird ja selten mal nachgefragt, wie z.B. PeDas Routine genau funktioniert. Das könnte ich ja absolut nachvollziehen. Da habe ich auch eine Weile gebraucht bis ich diese Routine kapiert habe. Die ist schon etwas tricky. :
Bearbeitet durch User
Hennes schrieb: > 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. Beim prellen von Kontakten, gibts halt nich viel zu erklären.... An einem Interrupt ist auch nich viel mehr dran.... Das ganze ist den Leuten einfach zu abstrakt, da fehlts an Vorstellungskraft, bzw. an unüberwachter Lebenszeit in der Kindheit. 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?
Beitrag #6219682 wurde von einem Moderator gelöscht.
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. Ein Anfänger ist einer, der anfängt :-) nur mit was?? Ein Modellbauer, der einfach ein schickes Teil mit Rundrumbeleuchtung möchte, muß in der Tat nicht ans Programmieren denken. Aber er muß sich dann auch damit zufrieden geben, was der "Obi-Fachverkäufer" ihm so verklickert. Außerdem kann er auf kommerzielle Produkte zurückgreifen und sich alles zusammenstricken, was das Herz begehrt. Wenn nun Selbiger auf die geniale Idee kommt, das alles billiger und besser und selbst machen zu können, dann kommt es eben zu solchen Anfragen, wie hier. Kunst kommt von können! Eine Aussage, die kein Künstler je unterschrieben hat... Gruß Rainer
Angehängte Dateien:
Buck schrieb: > habe in einer Dimplomarbeit eine Routine gefunden (siehe Anhang). Was > ist mit der? 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). :
Bearbeitet durch User
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: > (Anbei ein Ausschnitt aus der zitierten Diplomarbeit). Ja, dieser Ausschnitt ist sehr bedenklich, ich würde sogar sagen schlichtweg falsch. Es wird der Eindruck vermittelt, daß SW-Entprellung generell schlecht ist und das ist unwahr. Nur diese besonders grottige Entprellung ist schlecht. Das überhaupt Entprellung zu nennen, da rollen sich bei mir die Fußnägel auf. 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 Thomas schrieb: > 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 Du gehörst vermutlich auch zu den Leuten, die sich Ihre Diplomarbeit zusammenkopiert haben. Mit Zitaten haben es ja einige nicht so. Offensichtlich bin ich da zu altmodisch und habe den Zeitgeist verpasst. Andreas B. schrieb: > Du gehörst vermutlich auch zu den Leuten, die sich Ihre Diplomarbeit > zusammenkopiert haben. > Mit Zitaten haben es ja einige nicht so. Offensichtlich bin ich da zu > altmodisch und habe den Zeitgeist verpasst. und du bist wohl ein kniepiger alter mann, der kein sex von seiner Frau bekommt 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.
Beitrag #6220144 wurde von einem Moderator gelöscht.
Beitrag #6220151 wurde von einem Moderator gelöscht.
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. 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. c-hater schrieb: > Also warum sollte man sich dann > diesen SCHEISS antun, wenn's in Asm viel einfacher geht? "Einfacher" ist halt relativ. Also ICH brauch alleine für die Queltexteingabe, in Ass 3-5x so lange. Nach ein paar Tagen, hats mir dann auch noch die letzte Falte, aus den Stirnlappen gebügelt. OK OK, ich bin PICler..... Also kurz und bündig, ich mach in C, weil ich faul bin. (Codegeneratoren etc inkl.) 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). Tom schrieb: > 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. Dumm ist eher daß der CNC-Hasser meint, einzig die Feile wäre richtig. :
Bearbeitet durch User
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!
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. Tom schrieb: > 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. Ivh erinnere nur an den Thread von vor ein paar Jahren, der die Überlegenheit von Hochsprachen ab ATtiny13 gezeigt hat. Der Assembler-Fisch hat am Ende sogar (kurz) zugegeben, daß er nur 2ter war. Die Probleme beginnen dann, wenn man nicht klar ausdrücken kann, was man eigentlich als Ziel hat. 1000mal im Kreis drehen ohne ein Resultat zu produzieren fällt eben solange komplett weg, bis man hingeschrieben hat, daß man dieses Kreiseln braucht. Oder auch wenn, wie in der Diplomarbeit von weiter oben im Code steht: "wenn es kurz am Pin gezappelt hat und wir dann noch mal ein paar ms warten, dann war das ein Tasterdrücken. Oder eben doch nur ein Schmutzimpuls, da ein nochmaliges Lesen nicht zu sehen war. Dabei ist Warten dann snakeoil, genauso wie manche Verständigungsprobleme mit dem Compiler per volatile gelöst werden. -O0 würde da genauso helfen. Also, wer die Maschine nicht bedienen kann, der nimmt eben die Feile. 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... c-hater schrieb: > Genau das ist der Unterschied zwischen Pragmatiker und Fanatiker... Genau deswegen benutz ich die Feile nur wenn ich sie wirklich brauche. Arduino Fanboy D. schrieb: > Die Libs halte ich erstmal geheim, interessiert doch sowieso kaum einen > hier. 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. Klaus schrieb: > ich habe in einem Buch folgene Rountine zum Entprellen gefunden > was haltet ihr davon? ehrlich? nichts! Ich halte PeDas Entprellroutine auch für anwendbar am ESP32, der Timer ist schon auf 10ms gesetzt und da kann ich im IRQ auch entprellen! Die Auswertung und Verwendung kann dann auch in der Loop erfolgen ohne das mir eine Taste entgeht. Arduino Fanboy D. schrieb: > Also kurz und bündig, ich mach in C++, weil ich faul bin. und ich in purem C weil c++ noch lerne! :
Bearbeitet durch User
Und ich in C. In Assembler nur, wenn es notwendig ist (Beim Tiny 10 z.B.) Der echte Crack macht das sowieso nur in Maschinencode. (Beim 6502 weiß ich die sogar noch auswendig) ;-) 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! 2⁵ schrieb: > Nur halt nicht Bug frei! Mag sein, aber in 99.7% der Fälle ist der Bug vor der Tastatur. Tom schrieb: > Leider erschließen sich die Vorteile von Asm vs. C auf kleinen MCUs nur > demjenigen der beides kennt. Nun, wer beides gut kann, der weiß aber auch, daß man die ganz wenigen Stellen, wo Assembler Vorteile hat, mit der Lupe suchen muß. Da sind auch die AVRs keine Ausnahme. Nur die ersten ATtiny12/15 mit Hardwarestack mußte man noch in Assembler programmieren. Man war das ne Qual, nur mit 3 Calls auskommen zu müssen. 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:
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? Stefan ⛄ F. schrieb: > 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. es gibt beim GCC "built in functions", die genau dazu da sind: AVR:
MSP:
Dabei werden genau so viele Takte verbummelt, wie angegeben, ohne daß man erraten muß, wie lange eine Schleife denn wohl laufen wird. Bei andern Plattformen gibt es sowas übrigens nicht, wohl weil man erwartet, daß man z.B. eine /390-CPU nicht zu "busy" warten auf IO benutzt. Peter D. schrieb: > Nur die ersten ATtiny12/15 mit > Hardwarestack mußte man noch in Assembler programmieren. Man war das ne > Qual, nur mit 3 Calls auskommen zu müssen. Hab immer noch'n paar 16F84 rumfliegen, 2 Calls! Ist in Assembler weder eine wirkliche Einschränkung, noch Qual!? Mittlerweile liebe ich es, diese mit C regelrecht zu vergewaltigen. Das zu optimieren, damits überhaupt reinpaßt, ist richtig Sportlich, im Gegensatz zu Assembler.... ;D 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. Tom schrieb: > 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. Dann scheint der Hinweis nicht für dich gedacht gewesen zu sein. :
Bearbeitet durch User
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... Tom schrieb: > 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. Ja, das ist genauso wie MOV, LD, LDS, LDDS, L, LDEQ, LDMI, LDMIA, .... alles ganz einfach und jeder versteht das auch, PIC, AVR, ARM, x86, i51, /390, alle sprechen ASM. c-hater schrieb: > "Buddelschiff" wäre ein ziemlich cleverer Suchbegriff... Und Du glaubst jetzt allen Ernstes daß hier irgend jemand versucht, das zu dissassemblieren um Deine genialen Programmierkünste zu entdecken? Gehts noch? 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. Stefan ⛄ F. schrieb: > 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. Viel schlimmer als seine technischen Ansichten wären seine Umgangsformen. Um solche Leute versuche in real immer einen großen Bogen zu machen. c-hater schrieb: der Algorithmus muss also nichtmal > erfunden werden, nur nachgebaut... Dummerweise interessiert sich halt niemand für einen Westminister Gong o.ä.. Wenn es wenigstens etwas interessantes gewesen wäre... Ich programmiere nur Dinge, mit denen ich dann auch was anfangen kann. 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... 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. c-hater schrieb: > "Buddelschiff" wäre ein ziemlich cleverer Suchbegriff... > > Liefert die entsprechenden Threads auf Rang 2 und 4... Rang 2 gefällt mir! zeigt was machbar ist, aber ich würde das trotzdem in C machen für 88 WS LEDs reicht der MEM vom Arduino und ein 5V 4A Netzteil, damit läuft meine wordclock12h incl. DCF77, IRMP auf nano328p spart auch die Beschaltung vom Vogelfutter :) extra kühlen due ich die Stripes aber nicht, die fahren nur selten volle Helligkeit und haben auch etwas Kupfer drin. |
|
Thread beobachten
Seitenaufteilung abschalten