[Da der Thread ohne das PDF keinen Sinn mehr hat und der TE massiv außerhalb des Forums angefeindet worden ist, wurde der Inhalt hier in Abstimmung der Moderatoren entfernt.]
:
Bearbeitet durch Moderator
Christof E. schrieb: > Die Admins vom Mikrocontroller.net legten mir nahe eine eigenen Thread > zu eröffnen Absolut richtig. Danke (ist sehr umfangreich).
:
Wiederhergestellt durch Admin
1) Es haißt #include <avr/io.h> und nicht avr\io.h (auch nicht unter Windows). 2) #include <avr/sfr_defs.h> sollte nicht notwendig sein, denn es wird bereits von avr/io.h includiert. 3) double ist erst seit v10 ein 64-Bit Typ, und selbst da nur mit -mdouble=64. In dem von dir verwendeten WinAVR ist double = float, also nicht C/C++ konform. 4) Soweit is sehe verwendest du auch Features, die nicht ANSI-C sind wie Interrupts, Inline Assembly und util/delay.h, avr/eeprom.h etc. 5) Auf PDF-Ebene wäre ein Inhaltsverzeichnis genz nett, so wie jetzt ist man da recht verloren wenn man was sucht. Dass die Seiten nicht numeriert sind macht's nicht einfacher. 6) Es wird stdint.h eingeführt, später aber hausbackene Typen wie UINT16, UINT8, Bool (besser: bool aus stdbool.h), etc. verwendet. 7) Keine Angst vor Typographie! Anstatt 256 = 2^8 würde ich wenn möglich, mathematischen Formelsatz mit Superscript für Exponenten verwenden; insbesondere wenn daneben C-Code mit ^ = XOR steht. 8) Periode ist nicht Frequenz, sondern 1 / Frequenz. 9) *räusper* LaTeX Code aus irgendwelchen Wikis rauskopieren kann man nachen — falls das verwendete Satzprogramm LaTeX unterstützt. Aber (sic)
1 | Z_\mathrmmathrm{bit} = } = } = \fracfrac\mathrmmathrm{F_{CPU}}{F_{CPU}}{F_{CPU}}{F_{CPU}}{F_{CPU}}\mathrmmathrm{BAUDRATE}{BAUDRATE}{BAUDRATE}{BAUDRATE}{
|
10) Es gibt keine konsistenten Code-Formatierungen. Selbst kleine Codefragmente sind nicht durchgehend formatiert und daher schwerer zu erfassen als notwendig. 11) Float-Berechnungen in einer ISR wie (float) OCR1A sind ein absolutes NO GO!!! 12) Teilweise wir #include <...> verwendet wo #include "..." hingehört. An einer Stelle steht sogat #include "i2clcd.h,, (Gänsefüßchen unten!!") "Ab hier wird's Chaotisch [...]" fürwahr, hätt ich schon früher erwartet den Satz ;-) Ich hör jetzt mal auf da querzulesen; weiteremifehlen kann ich diesen "pile of images and copy-pasted code snippets" nicht.
Hi... Ich finde den Artikel/PDF schon ganz ok. Es steckt etwas Humor drin und ist natürlich auch informativ. Fein. -------- Was mir allerdings gar nicht schmeckt, ist die "ungarische Notation", das was bei dir Variablen Prefix heißt. Erstens: Ich kann den Code nicht lesen! C ist schon schwer genug, ohne diese zusätzliche Hürde. Zweitens: Das ist redundante Information und damit eine unnötige Fehlerquelle
Arduino Fanboy D. schrieb: > Hi... > > Ich finde den Artikel/PDF schon ganz ok. > Es steckt etwas Humor drin und ist natürlich auch informativ. > > Fein. Ja, das ist ja im Prinzip auch gut. Aber leider sind viele Fehler drin, sowohl Tippfehler, als auch inhaltliche - teils sogar Verständnisfehler. Mir ist schon klar, dass da einiges an Arbeit drin steckt, aber so wie es jetzt ist, würde ich es leider nicht weiterempfehlen.
Hallo nanana... Stimmt.! vieles, dort und da, was so nicht sein sollte. Oder sogar verwirrt. Ich schrieb auch. "Dort und da "Fehlerhaft ,aber brauchbar." Es ist ein Powerpoint Vortrag und eine Erklär-Arbeitsgrundlage, und werden normalerweis im Kurs alles erklärt, wie es gemeint ist. Habe aber keinen Lektor. Wenn ich Fehler finde, beseitige ich dies auch sobald wie mögl. Es ist eine Anleitung, mit Registern statt mit Bibliotheken, deren Arbeitsweise man nicht kennt, umgehen zu lernen. Mit Verwendung von ANSI-C und nicht C++. Was unnötig sperrig ist für das kleine Controllerchen. Das tut es. Und darum geht es.. Grund: Ich stelle fest, das Studenten immer weniger von der Arbeitsweise verstehen, weil diese mit SKETCH Bibliotheken arbeiten, ohne zu verstehen was diese tun, Python mit seinen Datentyp Schmuddeleien tut sein übriges. Es ist eher eine Ver-Bildung. Es geht darum Die Qualität, gerade die Binäre, von "C" zu vermitteln. Im Gegensatz zu SKETCH. Was eher verschleiert, was der Controller tut. ....Und Methoden kennezulernen, wie Bit Parsing, Stepmotor Sequenzen interrrupt gesteuert etc.. oder einfach ein paar Debugging Tricks. Auch Textbasierte UART Kommunikation für Befehle von außen. Was sich bewährt hat.. Ping, 12<13> --> Pong, 456<13> Includes Schreibweise wie "avr\io.h" sind evtl historische relikte und werden problemlos compiliert. das macht es nicht falscher. ebenso der ISR (interrupt vector) Natürlich ist ISR( interruptroutine ) etc kein ANSI-C. Aber AVR Controller Spezifisch. und sehr wohl implementiert in WINGW. wie auch <iom328p.h> unit32_t usw.. <iom328p.h> - Verknüpfung Kritik in Ehren, aber diese Methoden sind für den AVR so vorgesehen. ! Tatsächlich macht der Autoformat von PowerPoint einen ungefragt ärger. Die Gänsefüßchen oben und unten z.B. Das überliest man dann auch.. Die Inkonsistenzen wie Format Einrückungen etc. sind ein Folge davon Code-Beispiele (mehr sind es nicht) in diese Postkartenformate des PowerPoint zu pressen. Wer will, kann sich diese vollständig downloaden. WINAVR deshalb, weil der "Programmers Notepad" Nackt, aber dafür übersichtlich ist und sehr gut funktioniert. Man braucht keine Wochen, um damit arbeiten zu lernen, wie z.B. Eclipse oder AVR Studio. Wo man ganz schön allein ist, wenn einem niemand hilft am Anfang. Und es ist für Anfänger. Ich habe an keiner einzigen Stelle ein TEX Format "copy paste" gemacht.!? Wie kommen sie darauf? Copypasted habe ich aus meinen Quellfiles im Notepad. das seltsame ..."\fracfrac\mathrmmath" habe ich nirgends gefunden!!. Kann evtl ein "export aus Powerpoint" Fehler sein. Ich habe im Akrobat unter WIN10 dieses nicht gesehen. Aber gut. Wenn ich Zeit habe, versuche ich noch ein paar Fehler zu finden, korrigieren. Die Sache jedoch selbst, ist so richtig. Vor allem geht es darum, es selbst zu machen, eine Servo, Schrittmotor mit eigenen Routinen zum laufen zu bringen, und so qualifiziert zu kontrollieren, was der Controller tut, zu verstehen wie die Signale wo udn warum so sind. Also Spass zu haben.
...ich darf widersprechen. Die Voranstellung von typbezeichnenenden Buchstaben, (sie nennen es ungarische Notation) zum Variablenname ist keine Redundanz, und keine Fehlerquelle. Im Gegenteil. Siehe: uint8_t u8NN = 0; if( u8NN < -2 ) ....kann so nicht stimmen weil "u8NN"--> unsigned 8 Bit namens NN heißt, und nicht negativ werden kann. Und das erkennt man im Code nur daran, dass man den Zähler sprechend u8NN nannte. *gpcaStr = 0; ---> sprich "Global Pointer auf char array String" Also kürzer und klarer wird es nicht. Genau das ist der Sinn von typisierten Variablennamen. Das alles ist nicht frei erfunden und daher gesagt. Es gibt eine Handlungsrichtline:MISRA C:2012 Info hier: https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard (frei verfügbar) und hier: https://www.misra.org.uk/Publications/tabid/57/Default.aspx Diese Information ist von Frank Büchner.
Christof E. schrieb: > ...ich darf widersprechen. > Die Voranstellung von typbezeichnenenden Buchstaben, (sie nennen es > ungarische Notation) zum Variablenname ist keine Redundanz, und keine > Fehlerquelle. Mit modernen IDEs wird der Typ sehr schnell sichtbar. Typ im Namen geht gar nicht. > Das alles ist nicht frei erfunden und daher gesagt. > Es gibt eine Handlungsrichtline:MISRA C:2012 > Info hier: > https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard > (frei verfügbar) > > und hier: > https://www.misra.org.uk/Publications/tabid/57/Default.aspx MISRA ist ne andere Welt. Ich würde vermeiden mir hier einzelne Empfehlungen rauszupicken. Entweder du machst MISRA oder nicht. Für die allgemeine Entwicklung ist MISRA überholt und unmaßgeblich.
Christof E. schrieb: > Das alles ist nicht frei erfunden und daher gesagt. > Es gibt eine Handlungsrichtline:MISRA C:2012 Mishra wird zwar professionell (unter Zwang) genutzt, läuft aber unter der Rubrik „professioneller Blödsinn“. Bei dem Thema Codestil gibt es kein falsch und kein richtig. Es gibt nur persönliche Geschmäcker, und über die soll man nicht streiten. Ich sehe es wie meine Vorschreiber: ungarische Notation ist vollständig überflüssig. Oliver
Christof E. schrieb: > Includes Schreibweise wie "avr\io.h" sind evtl historische relikte und > werden problemlos compiliert. das macht es nicht falscher.
1 | % avr-gcc blub.c |
2 | blub.c:1:10: fatal error: avr\io.h: No such file or directory |
3 | 1 | #include <avr\io.h> |
4 | | ^~~~~~~~~~ |
5 | compilation terminated. |
Mit dem richtigen Slash geht’s. Du kannst nun die Probleme kleinreden und deine Sachen verteidigen, oder du verbesserst dein Script einfach. Vom Letzteren hätten alle was, btw.
:
Bearbeitet durch User
Christof E. schrieb: > Im Gegenteil. Siehe: > > uint8_t u8NN = 0; > if( u8NN < -2 ) > ....kann so nicht stimmen weil "u8NN"--> unsigned 8 Bit namens NN heißt, > und nicht negativ werden kann. Dazu warnt mich schon mein Editor. Bei etwas älteren Modellen kommt die Warnung dann erst vom Compiler. > *gpcaStr = 0; ---> sprich "Global Pointer auf char array String" > Also kürzer und klarer wird es nicht. Für mich steht die Bedeutung der Variable im Vordergrund für ihren Namen, nicht der Typ. > Das alles ist nicht frei erfunden und daher gesagt. > Es gibt eine Handlungsrichtline:MISRA C:2012 > Info hier: > https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard > (frei verfügbar) Dort steht aber nichts von einem u8, sondern lediglich was von globalen Variablen, Zeigern, Variablen, die einen booleschen Wert enthalten (aber nicht zwingend vom Typ bool sein müssen) und Handles (unabhängig von deren Datentyp). Genau so war die ungarische Notation eigentlich gedacht. Oliver S. schrieb: > Christof E. schrieb: >> Das alles ist nicht frei erfunden und daher gesagt. >> Es gibt eine Handlungsrichtline:MISRA C:2012 > > Mishra wird zwar professionell (unter Zwang) genutzt, läuft aber unter > der Rubrik „professioneller Blödsinn“. MISRA ist vor allem für das Management da, damit sie auch das Gefühl haben können, was für die Codequalität getan zu haben. Meine Meinung: Jemand, der nicht programmieren kann, kann es auch mit MISRA nicht, und jemand, der es kann, braucht MISRA nicht. > Bei dem Thema Codestil gibt es kein falsch und kein richtig. Es gibt nur > persönliche Geschmäcker, und über die soll man nicht streiten. > > Ich sehe es wie meine Vorschreiber: ungarische Notation ist vollständig > überflüssig.
Also Leute. Dieser Kurs ist für Anfänger, bzw etwas Erfahrene im Controllerleben und ANSI-C und die, die sich zum ersten mal im Leben trauen, Drähte an Strom und Servos und dem gekauften Controller anzulegen. und die etwa schlaueres, und vor allem selbst machen wollen, als Sketch Programme zu kopieren. Die Anderen brauchen offensichtlich keinen Kurs. ...und das mit WINAvr mit (Anfänger) Ansi-C. Auch hat die WINAVR nur den "Programmers Notepad". und damit keine Typenanzeige. .....und zwar ganz vorsätzlich. !! so wird man gezwungen, nachzudenken, was man tut, Das es modernere IDEs gibt, wissen wir. Aber diese sind leider auch für Anfänger, bzw leicht Fortgeschrittene, unglücklich. Wenn diese erst 2..3 Tage mit einer störrischen IDE, schon ab AVRStudio arbeiten lernen sollen, dann wird das nix. ! Hab sprobiert. Meine Erfahrung ist, das mir sogar Physik Studenten im 6. Semester ab einem Niveau über der ADC Registerbedienung zu 50% aussteigen. Früher 20 Teilnehmer/Jahr, heute ~5..6... zu viel Stress, zu wenig Zeit, noch weniger "Vorkönnen" aus dem Abi. Keine Kompelxen Zahlen, eine Sinus Wertetabelle normiert zu erzeugen ist auch nicht drin mit den heutigen Schulkentnissen. So sieht es auch ..hat eben alles seine Grund. Ich empfehle selber mal eine, auf 800 Seiten gewachsene, Powerpoint zu machen. Natürlich absolut tadelos. Wer Rechtschreibfehler findet, kann mir das sagen oder diese behalten. kriegen wir uns also wieder ein?
Christof E. schrieb: > ist keine Redundanz Ist es wohl! Cyblord -. schrieb: > (sie nennen es ungarische Notation) Ja! Ob es genau diesen Vorgaben entspricht ist nicht wichtig. Das Prinzip ist auf jeden Fall gleich. Falls du danach suchst, findest du viele Versuche das einzuführen. Unter anderem bei Google und Microsoft. Auf die Barrikaden sind sie gegangen die Programmierer und das mit Fug und Recht (aus meiner Sicht) Oliver S. schrieb: > über die soll man nicht streiten. Ja, und darum werde ich jetzt auch in dieser Sache das Maul halten.
Also Leute. Dieser Kurs ist für Anfänger, bzw. etwas Erfahrene im Controllerleben und ANSI-C und die, die sich zum ersten mal im Leben trauen, Drähte an Strom und Servos und dem gekauften Controller anzulegen. und die etwa schlaueres, und vor allem selbst machen wollen, als Sketch Programme zu kopieren. Die Anderen brauchen offensichtlich keinen Kurs. ...Das ganze mit WINAvr mit (Anfänger) Ansi-C. Auch hat die WINAVR nur den "Programmers Notepad". und damit keine Typenanzeige. .....und zwar ganz vorsätzlich. !! so wird man gezwungen, nachzudenken, was man tut, Das es modernere IDEs gibt, wissen wir! Aber diese sind leider auch für Anfänger, bzw. leicht Fortgeschrittene, unglücklich. oder (für Anfänger) völlig unbrauchbar, wie Eclipse. Sketch Wenn diese erst 2..3 Tage mit einer störrischen IDE, schon ab AVRStudio arbeiten lernen sollen, dann wird das nix. ! Hab sprobiert. Dann springen die ersten 2/3 ab. Meine Erfahrung ist, das mir sogar Physik Studenten im 6. Semester ab einem Niveau über der ADC Registerbedienung zu 50% aussteigen. Früher 20 Teilnehmer/Jahr, heute ~5..6... zu viel Stress, zu wenig Zeit, noch weniger "Vorkönnen" aus dem Abi. Keine Ahnung von kompelxen Zahlen, eine Sinus Wertetabelle normiert zu erzeugen ist auch nicht drin mit den heutigen Schulkentnissen. (Abi) So sieht es aus! ..hat eben alles seinen Grund. Ich empfehle selber mal eine, auf 800 Seiten gewachsene, Powerpoint zu machen. Dauert halt alle paar Tage ein paar Stunden, ein paar Monate. Natürlich absolut tadelos. Wer Rechtschreibfehler findet, kann mir das sagen oder diese behalten. Sollte formal , wie einer sagt ,definitiv etwas falsch sein, ist dies keine Absicht, sondern meine Schlampigkeit. Würde aber gern wissen wo, und nicht einfach behaupten. Tja. menschlich halt... Kriegen wir uns also wieder ein?
Arduino Fanboy D. schrieb: > Cyblord -. schrieb: >> (sie nennen es ungarische Notation) Och, da ist mir ein Fehlzitat unterlaufen. Der Eigentümer ist Christof E. (christof) und nicht Cyblord
Beitrag #6412592 wurde von einem Moderator gelöscht.
Christof E. schrieb: > Also Leute. > Dieser Kurs ist für Anfänger, bzw. etwas Erfahrene im Controllerleben > und ANSI-C und die, die sich zum ersten mal im Leben trauen, Drähte an > Strom und Servos und dem gekauften Controller anzulegen. … genau bei denen wär’s halt wichtig, die kleinen Stolperstellen wegzumachen. Damals, als man noch Bücher gekauft hat, hatte ich mal eines mit so subtilen Fehlern – was dazu führte, dass die Beispiele nicht richtig funktionierten, bzw. ich mit den Texten teils nix anfangen konnte, weil sie mir einfach nicht logisch erfassbar schienen. Das hat mich ziemlich frustriert – ich war ja Anfänger, und hab ich das erste Mal im Leben an so ein Tastenbrett getraut, um Programmieren zu lernen – das war ein Buch, also musste es schließlich an mir liegen, wenn ich es nicht hinbekomme, oder? Ich hab das beinahe wieder an den Nagel gehängt. Tu deinen Lesern das bitte nicht an – korrigiere, wo’s einfach möglich ist, zeitnah. Das ist doch nur ’n PDF und nix Gedrucktes, das man nicht mehr ändern kann.
:
Bearbeitet durch User
Ja. Ich versuche zu verstehen: Danke für den Hinweis. Aber,... das ist doch recht einfach, was ich da meine. Da ich es so mache, mache ich es auch einfach so. Schon seit 30 Jahren. schon seit ich diese Methodik bei Petzolds Win3.1 gelesen habe. Mit Erfolg. Es geht mir darum sich zu trauen, die Register selbst zu benutzen. Timer selbst zu Stellen, den OCRx selbst zu definieren anhand der Verwendeten Takte und der gewünschten Frequenz. Ich wollte bewusst keine IDE, die mir die Intelligenz abnimmt, auf die Datentypen zu achten. Das führt zu Schmuddel Code, wie ich bei Sketch und Python Programmen gesehen habe. gruselig. die Formatierung ist manchmal etwas zu gross. Das war wegen der Beamertauglichkeiit. Ist halt kein redigiertes Buch. Jack V. schrieb: > Christof E. schrieb: >> Also Leute. >> Dieser Kurs ist für Anfänger, bzw. etwas Erfahrene im Controllerleben >> und ANSI-C und die, die sich zum ersten mal im Leben trauen, Drähte an >> Strom und Servos und dem gekauften Controller anzulegen. > > … genau bei denen wär’s halt wichtig, die kleinen Stolperstellen > wegzumachen. Damals, als man noch Bücher gekauft hat, hatte ich mal > eines mit so subtilen Fehlern – was dazu führte, dass die Beispiele > nicht richtig funktionierten, bzw. ich mit den Texten teils nix anfangen > konnte, weil sie mir einfach nicht logisch erfassbar schienen. > > Das hat mich ziemlich frustriert – ich war ja Anfänger, und hab ich das > erste Mal im Leben an so ein Tastenbrett getraut, um Programmieren zu > lernen – das war ein Buch, also musste es schließlich an mir liegen, > wenn ich es nicht hinbekomme, oder? Ich hab das beinahe wieder an den > Nagel gehängt. > Tu deinen Lesern das bitte nicht an – korrigiere, wo’s einfach möglich > ist, zeitnah. > > Das ist doch nur ’n PDF und nix Gedrucktes, das man nicht mehr ändern > kann.
Hallo, laut meiner Meinung nach fehlt hier ganz klar eine Gliederung nach Themen. Das sieht alles wild gemischt aus gespickt mit paar Elektronikschaltungen. Ich sehe ehrlich gesagt keinen roten Faden. Ich bezweifel auch das man damit Vorträge halten kann, du müßtest ja ständig hin und herspringen. Schau dir einmal ein Programmier- und Elektronikbuch an wie die aufgebaut und gegliedert sind. Was mich auch stört sind die zu vielen und zu großen Bilder und Schrift. Man ist permanent am blättern wenn man 3 Wörter gelesen hat. Das lenkt nur ab. Ich gehe davon aus das es kein Bilderbuch sein soll. Normaler Text und Programmcode könnte sich farblich unterscheiden. Und zwar im Gesamten .pdf und nicht nach Lust und Laune mal hier mal da. Das lesen fällt sehr schwer. Was sich jedoch widerspricht ist, du meckerst in deiner ersten Verteidung gegen Arduino, verwendest aber in deinem Vortrag Arduino. So hart das jetzt klingt. Es ist wirklich nur eine wilde Sammlung von deinen Notizen. Bevor du antwortest, du wolltest Kommentare lesen ...
Beitrag #6412628 wurde von einem Moderator gelöscht.
Jack V. schrieb: > Christof E. schrieb: >> Also Leute. >> Dieser Kurs ist für Anfänger, bzw. etwas Erfahrene >> im Controllerleben und ANSI-C und die, die sich zum >> ersten mal im Leben trauen, Drähte an Strom und >> Servos und dem gekauften Controller anzulegen. > > … genau bei denen wär’s halt wichtig, die kleinen > Stolperstellen wegzumachen. Richtig. Das Problem ist: Man muss alle nebensächlichen Details, die keinen Erklärwert haben, weglassen, weil sonst der unkundige Leser in der Masse der Einzelheiten ersäuft -- man muss aber DIE Details, die zum Verständnis wichtig sind, sachlich richtig, logisch klar und sprachlich verständlich darstellen. Das ist eine saumäßige Arbeit -- ich weiss das aus eigener Erfahrung.
Gegentest auf Kritik #include <avr\io.h> mit Backslash
ES GEHT !
mein WINAVR, von dem ich immer rede, tut es auch, ebenso wie ich sagte!
Es hat somit avr/io.h im richtigen Pfad.
und ich habe ein zugehöriges makefile
und nicht nur "avr-gcc blub.c"
Deshalb ist es nicht aufgefallen. So einfach ist das.
wenn an zwei Stellen in 800 Seiten das "\" Stand, ist das erträglich,
nicht?
nämlich mit:
Compiling C: main.c
avr-gcc -c -mmcu=atmega328p -I. -gdwarf-2 -DF_CPU=16000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -MMD -MP -MF
.dep/main.o.d main.c -o main.o
-------------------------------------------------------------
define AUTOR "=/\= Christof Ermer =/\= "
#define IHAVENOBRAIN "I have no brain"
#define USEYOURS "Use your own"
#include <avr/sfr_defs.h>
#include <avr\io.h> //siehe Backslashs
#include <util\delay.h> //siehe Backslashs
// ***************
int main(void)
// ***************
{
DDRC = 1;
while( 1 )
.
.
-----------------------------------------------
Ergebniss:
Size after:
AVR Memory Usage
----------------
Device: atmega328p
Program: 176 bytes (0.5% Full)
(.text + .data + .bootloader)
Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)
Jack V. schrieb:
> Christof E. schrieb:
>> Includes Schreibweise wie "avr\io.h" sind evtl historische relikte und
>> werden problemlos compiliert. das macht es nicht falscher.
>
>1 | % avr-gcc blub.c |
2 | > blub.c:1:10: fatal error: avr\io.h: No such file or directory |
3 | > 1 | #include <avr\io.h> |
4 | > | ^~~~~~~~~~ |
5 | > compilation terminated. |
6 | > |
> > Mit dem richtigen Slash geht’s. > > Du kannst nun die Probleme kleinreden und deine Sachen verteidigen, oder > du verbesserst dein Script einfach. Vom Letzteren hätten alle was, btw.
Christof E. schrieb: > Gegentest auf Kritik #include <avr\io.h> mit Backslash > ES GEHT ! Unter Windows, ja. Unter Linux hat ein Backslash ’ne andere Bedeutung. Wäre schon schön, wenn da der allgemein anerkannte Standard genutzt würde, damit’s portabel bleibt. Oder du schreibst ganz am Anfang dran, dass es nur für Windowsnutzer ist – dann ist’s für viele eh gleich gestorben. Hätte für dich den Vorteil, dass du viel weniger Fehlermeldungen reinbekommst. Wenn das das Ziel ist: nur zu.
Hallo, damit auch Verbesserungskommentare kommen. Seite 411. Mechanische Taster sollten nicht in einer ISR entprellt werden. Du fängst hier an einem Anfänger die Entprellung mit ISR zu zeigen. Danach verweist du auf Polling in der Mainloop. Das Wort Polling fällt aber nicht. Das verfällt zur Randbemerkung ohne Lösung. Das müßte umgekehrt aufgebaut sein. Tasterentprellung mit Polling zeigen/erklären und bei externen einmaligen/seltenen Triggerereignissen auf die ISR eingehen. Nur dazu musste den Timer vorher erklären um ein zyklisches Polling erreichbar zu machen. Ob das dann allerdings noch Anfängerniveau hat müssen andere beurteilen. Damit bin ich wieder bei Arduino. Wenn das ein vernünftiges Buch werden soll musste viel umsortieren usw. Das es schwer ist wissen wir alle. Kritik zu lesen ist auch schwierig, weiß ich auch, nur ohne die wirds nicht besser, weil man in seiner Gedankenwelt bleibt und die Probleme anderer damit nicht sieht.
Also Jack. Was ist mit Dir los? Geht es auch mal ohne naseweiser Überheblichkeit? Kriegen sie sich mal ein. Da Sie den Kurs nicht brauchen, weil sie es ja besser können, verlassen sie einfach diesen Thread. So einfach ist das, Wie oft mus sich sagen, das ich WINAvr benutze. Und dass ich einfach ein Praxis Kursarbeitsskript zur Verfügung stell(t)e. Eine Stoffsammlung, ein Merkzettel, und keine redigierte Doktorarbeit. Wer Linux macht, kann dies auch tun, und es wird gehen. Weil es ums das Verständnis geht Den "\" habe ich zu "/" gedreht. ( Was WINAVR (merke WINDOWS) tolerierte ) ...und das kann jeder andere auch. So "viele" Anfänger , für die es "Eh gleich gestorben ist, weil ich Windows verwende, sind es wohl auch nicht. Und ob das mein Ziel sei. !Nein ist es nicht. Jack V. schrieb: > Christof E. schrieb: >> Gegentest auf Kritik #include <avr\io.h> mit Backslash >> ES GEHT ! > > Unter Windows, ja. Unter Linux hat ein Backslash ’ne andere Bedeutung. > Wäre schon schön, wenn da der allgemein anerkannte Standard genutzt > würde, damit’s portabel bleibt. Oder du schreibst ganz am Anfang dran, > dass es nur für Windowsnutzer ist – dann ist’s für viele eh gleich > gestorben. Hätte für dich den Vorteil, dass du viel weniger > Fehlermeldungen reinbekommst. Wenn das das Ziel ist: nur zu.
Christof E. schrieb: > Also Jack. Was ist mit Dir los? > Geht es auch mal ohne naseweiser Überheblichkeit? > Kriegen sie sich mal ein. Wenn schon förmlich, dann bitte richtig, mit „Sie“ und so, und konsequent, also ohne „dir” dazwischen, ja? Ansonsten wollte ich nicht überheblich wirken, sondern nur darauf hinweisen, dass der Backslash an der Stelle problematisch ist, auch, wenn es bei dir keinen Unterschied macht – zumindest, wenn du nicht die Hälfte oder mehr der μC-Lernwilligen ausschließen willst. Edit, OT: TOFU wär’ zu vermeiden. Die Neunziger sind wirklich vorbei.
:
Bearbeitet durch User
Christof E. schrieb: > Also Leute. > Dieser Kurs ist für Anfänger, bzw. etwas Erfahrene im Controllerleben > und ANSI-C und die, die sich zum ersten mal im Leben trauen, Drähte an > Strom und Servos und dem gekauften Controller anzulegen. > und die etwa schlaueres, und vor allem selbst machen wollen, > als Sketch Programme zu kopieren. Und genau dafür ist dein Dokument eben nicht wirklich geeignet. Fang beim Urschleim an, aber mach's kompakt und stringent. Von vielen Bildern, die irgend eine Leiterplatte oder ähnliche Zeugs zeigen, wird niemand klüger. Ich geb dir mal nen Rat, da ich weiß, daß das Schreiben von Dokumentationen keine wirklich einfache Sache ist. Also: Schreibe deinen Text so, als ob du ihn für einen alten Advokaten schriebest. Dieser Advokat versteht von deinem Fachgebiet erstmal überhaupt nichts, aber er hat einen rasiermesserscharfen Verstand und er kann logisch denken und er vergiß nichts, was du ihm zuvor erklärt hast. Er kann auch kombinieren, aber dabei zieht er Dinge aus seiner Lebenswelt hinzu, die mit deiner Welt nichts gemeinsam haben, also mache deine Erklärungen so, daß alle Stücke zum Begreifen deiner Argumentation von dir bereits zuvor dargelegt worden sind, so daß man zum Verstehen nicht auf eigene Faust kombinieren muß. Fang beim Anfang an und nicht in der Mitte. Mache dir ein Konzept und eine Gliederung und lege ganz am Anfang fest, was du zu erklären beabsichtigst. Benutze keine Abkürzungen oder Spezialausdrücke, die du nicht zuvor sauber erklärt hast. Gehe logisch vor und mache keine Gedankensprünge. Schweife auch nicht ab. Ergehe dich nicht in Nebensächlickkeiten. So, das sollte für den Anfang reichen. Nun begutachte mal selber deine Dokumentation nach eben diesen Kriterien. W.S.
Christof E. schrieb: > Da Sie den Kurs nicht brauchen, weil sie es ja besser können, verlassen > sie einfach diesen Thread. So einfach ist das, Also, ich finde, dass du dich nicht so sehr aufregen solltest... Denn das führt fast unweigerlich zu einem Tunnelblick. Auch gerne dazu, dass man Kritik in der Sache, zu persönlich nimmt. z.B. kannst du keinem verbieten was er/sie/es sagt. Das ist einfach irrational, alleine weil dein Ärmchen viel zu kurz sind, um das durchzusetzen. Formal ist das hier eine strenge Hierarchie Betreiber-->Moderatoren-->User-->Gäste Praktisch herrscht hier zum größten Teil Anarchie. Allerdings mit zuwenig Verantwortungsbewusstsein/Vernunft, um richtig gesund zu sein. ---------- Desweiteren: Viele sind hier in der harten Praxis aktiv und erkennen jede kleine Macke in Texten/Programmen. Können aber Kritik häufig nicht gut rüber bringen. Mein Rat: Nimm dir die Kritik, die berechtigte, nicht zu sehr zu Herzen, aber nimm sie in den Verstand auf. Bei der nächsten Überarbeitung kann man/du sie ja korrigieren. Grundsätzlich finde ich es richtig, gut und Lobenswert, Anfängern, egal welcher Couleur, das Thema näher zu bringen. Auch wenn ich sicherlich vieles anders gemacht hätte, möchte ich stark bezweifeln, ob meins besser geworden wäre.
Vielen Dank. wenigstens mal was vernünftiges an Kritik.
Offenbar wurde nicht klar, wie ich das gemeint habe,
Nicht der Interrupt entprellt. !!
Er setzt nur ein Ereignis Flag, so das der eigentliche
Key-Debounce-Polling ( wo auch immer, im Main, im Timer? ) angestossen
wird. So die Idee.
PRINZIP:
#define KEY_INT_EVENT 0x01
ISR( INT0.....
{
gu8KeyFlags |= KEY_INT_EVENT;
// dann Stop INT0_Interrupt usw...
}
// irgendwo z.B. Mainloop
if(gu8KeyFlags & KEY_INT_EVENT)
{
gu8KeyFlags &= ~KEY_INT_EVENT; // clear flag
....Polling , was immmer passiert
}
Ich wollte damit vor allem die "Möglichkeit" der Ablaufsteuerung mit
Flags zeigen. Dass damit Code Aktiv geschaltet werden kann..
so war das gemeint
ich werde es überarbeiten.
Aber dann neuer Link auf meiner Homepage.
Inhaltsverzeichnis... schwierig.
Tatsächlich springe ich die Themen je nach Kursablauf an.
Oft gibt das Niveau einen kerzengeraden Weg nicht vor.
Tastentprellung braucht eine ganzen Vormittag mit Übung.
Ernüchternd, nicht?
Deshalb habe ich das als Fleisaufgabe mit nach Hause gegeben.
seit etwa 10 Jahren ist der Wurm drin, seit dem Bachelor, Master..
Früher wollten die Studis was wirklich selber machen, nicht nur Punkte
abgreifen. Weis auch nicht wie das wird.
Sowas STM32 habe ich als Lehrstoff an der Physik schon gesteckt. Geht
wohl nur in FOS/THs im Informatik Studium.
Allein in einem Kurs ein STM32 oder EFM32 Entwicklung im Eclipse, mit
Debugger zum laufen zu bringen,..katastrophe...das braucht soviel Zeit
mit Frusts, das die durchschnittliche Zwischensemster ganztags Kursdauer
von nur 10 Tagen kaum reicht.
Wir werden sehen....
Ihre Kritik ist sehr hilfreich.......
Veit D. schrieb:
> Hallo,
>
> damit auch Verbesserungskommentare kommen.
> Seite 411.
> Mechanische Taster sollten nicht in einer ISR entprellt werden.
> Du fängst hier an einem Anfänger die Entprellung mit ISR zu zeigen.
> Danach verweist du auf Polling in der Mainloop. Das Wort Polling fällt
> aber nicht. Das verfällt zur Randbemerkung ohne Lösung. Das müßte
> umgekehrt aufgebaut sein. Tasterentprellung mit Polling zeigen/erklären
> und bei externen einmaligen/seltenen Triggerereignissen auf die ISR
> eingehen. Nur dazu musste den Timer vorher erklären um ein zyklisches
> Polling erreichbar zu machen. Ob das dann allerdings noch Anfängerniveau
> hat müssen andere beurteilen. Damit bin ich wieder bei Arduino.
>
> Wenn das ein vernünftiges Buch werden soll musste viel umsortieren usw.
> Das es schwer ist wissen wir alle. Kritik zu lesen ist auch schwierig,
> weiß ich auch, nur ohne die wirds nicht besser, weil man in seiner
> Gedankenwelt bleibt und die Probleme anderer damit nicht sieht.
Oliver S. schrieb: > Mishra wird zwar professionell (unter Zwang) genutzt, läuft aber unter > der Rubrik „professioneller Blödsinn“. > > Ich sehe es wie meine Vorschreiber: ungarische Notation ist vollständig > überflüssig. STIMMT! nochmals doppelt und fett unterstrichen! MISRA war/ist eine Totgeburt, wer hierzu referenziert hat keinen eigenen praktischen Hintergrund dazu und nichts selber real dazu erlebt. Ungarische Notation war mal vor 20 Jahren eine "kleine Idee" und heute komplett tot/unbenutzt/null added value!
Apollo M. schrieb: > MISRA war/ist eine Totgeburt, wer hierzu referenziert hat keinen eigenen > praktischen Hintergrund dazu und nichts selber real dazu erlebt. > > Ungarische Notation war mal vor 20 Jahren eine "kleine Idee" und heute > komplett tot/unbenutzt/null added value! Misra ist gut. Für seine Anwendung. Und was ist die? Für Sicherheitsgerichteten Code mit begrenzter, eng umrissener Aufgabe, den größtenteils Anfänger schreiben oder warten. Es geht bei Misra vor allem darum, die Fallen zu kennen und zu versichern, dass man sie kennt. Ich sehe allerdings nicht, wo Misra ungarische Notation verlangt. Vor allem jenen Abklatsch mit der integer-Größe im Namen. Aber immerhin hat es "der Ungar" bis ins All geschaft (als Weltraumtourist).
Beitrag #6412849 wurde von einem Moderator gelöscht.
A. S. schrieb: > Misra ist gut. Für seine Anwendung. Und was ist die? Für > Sicherheitsgerichteten Code mit begrenzter, eng umrissener Aufgabe, den > größtenteils Anfänger schreiben oder warten. Und genau darin liegt das Problem. Solchen Code dürften Anfänger gar nicht erst bearbeiten. Man lässt ja auch nicht den Praktikanten im Krankenhaus eine Herzoperation durchführen. Den befähigt man auch nicht dazu, indem man ihm einfach ein Heftchen mit Regeln vorlegt.
MISRA erfüllt imho mehrere Aufgaben:1. Der Entwickler muss sich Gedanken über seinen Code machen, entweder weil er die Regeln befolgt, oder weil er Abweichungen dokumentieren/argumentieren muss. 2. Das Management ist zufrieden, weils etwas quantifizierbares gibt, das jemand unterschreiben kann. 3. Der Kunde ist zufrieden, weil er Verantwortung abgeben kann. Das alles kann zu gutem Code führen, muss es aber nicht. Wenn man zB in AUTOSAR-Sourcen schaut, wird man mit einer recht großen Menge an MISRA-Violation-Rechtfertigungen konfrontiert. Anfänger sind aber (vermute ich) eher überfordert damit, sich auch um das noch zu kümmern, während sie sich noch immer nicht sicher sind was & und * so alles anstellen ... Da ist eine strukturierte Vorgehensweise (die für Code im MISRA-Umfeld ja auch dringend nötig ist) etwas, das deutlich hilfreicher ist.
Beitrag #6412960 wurde von einem Moderator gelöscht.
Beitrag #6412970 wurde von einem Moderator gelöscht.
HI > Ich wollte einigen, vor allem Anfängern, > ein Geschenk machen. Quidquid id est, timeo Danaos et dona ferentes. MfG Spess
spess53 schrieb: > Quidquid id est, timeo Danaos et dona ferentes. und wieviele Leute hier im Forum können deinen Lateinischen Satz verstehen? Warum nicht in Altgriechisch, oder gar in Sanskrit? Das gibt noch mehr Authentizität!
:
Bearbeitet durch User
Beitrag #6412989 wurde von einem Moderator gelöscht.
Wegstaben V. schrieb: > spess53 schrieb: >> Quidquid id est, timeo Danaos et dona ferentes. > > und wieviele Leute hier im Forum können deinen Lateinischen Satz > verstehen? Alle, die noch eine Suchmaschine bedienen können? :-) Und mit „Φοβοῦ τοὺς Δαναοὺς καὶ δῶρα φέροντας.“ oder "Phobou tous Danaous kai dōra pherontas." hätte das auch funktioniert.
:
Bearbeitet durch User
Beitrag #6413001 wurde von einem Moderator gelöscht.
Beitrag #6413019 wurde von einem Moderator gelöscht.
Beitrag #6413036 wurde von einem Moderator gelöscht.
Beitrag #6413083 wurde von einem Moderator gelöscht.
Also ich bekomme bei der PDF Augenschmerzen... - Viel zu überladen (genau so wie die Internetseite) - Code schlecht formatiert - "ungarische Notation"? - ... Als Anfänger wäre ich da direkt raus. ...manchmal ist weniger mehr.
:
Bearbeitet durch User
Adam P. schrieb: > Also ich bekomme bei der PDF Augenschmerzen... > > - Viel zu überladen (genau so wie die Internetseite) > - Code schlecht formatiert > - "ungarische Notation"? > - ... > > Als Anfänger wäre ich da direkt raus. > > ...manchmal ist weniger mehr. Es ist primär als Powerpoint Beamer Version mit Erklärung gedacht. PDF ist daher oft ungünstig formatiert. (..Kritik von außen) Es fehlt ein Inhaltsverzeichnis. Warum? Weil die Reihenfolge sich dauernd ändert, neues dazukommt. Und es von der Vorbildung abhängt, was interessiert und wann wo gebraucht wird. Also, einfach mit STR+F nach Themen suchen, die einem interessieren. Oder einfach durchblättern und ausprobieren. Es ist für Neulinge, ungeübte oder leicht vorgebildete gedacht. Nicht für Profis, die es sowieso besser wissen. Und jedes fehlende „;“ mokieren. Codebeispiele sind ab und zu inkonsistent formatiert. Das liegt daran das manches sehr alt, anderes neu ist. Oder der Platz/Seite genutzt werden sollte. Die vielen Bilder sollen die Ödnis mancher Lehrbücher vertreiben helfen.Die „Ungarische Notation“ ist mein Stil, in meinem Kursskript. Punkt Rechtschreibfehler sind leider in der Natur meines ADHS möglich.
Christof E. schrieb: > Es ist für Neulinge, ungeübte oder leicht vorgebildete gedacht. Nicht > für Profis, die es sowieso besser wissen. Und jedes fehlende „;“ > mokieren. Es wurde schon ein paar mal gesagt, aber du scheinst es nicht glauben: GERADE für Anfänger, gerade wenn man etwas für andere macht, wenn man LEHREN möchte, dann müssen die Infos präzise sein. Das Material muss konsistent sein. Es ist ein Irrglaube dass man bei Anfängern über so was hinwegsehen kann. Und ein paar Fehler und Ungenauigkeiten würden da nichts ausmachen. Gerade da braucht man eine saubere Struktur und der Autor/Dozent muss diese saubere Struktur auch verinnerlicht haben. Nur so kann man Wissen effizient vermitteln. Ehrlich gesagt, merkt man an derart schludrigen Arbeiten, dass der Autor selbst nicht so fest im Sattel sitzt was den Stoff angeht. Deine falschen Includes z.B. sowohl die Backslahes als auch die überflüssige ..sfr.h verdeutlichen das: Für jemanden der vor sich hin frickelt spielt das keine Rolle. Auf seinem Windows System läuft das und der zusätzliche include tut ihm nicht weh. Will ich aber LEHREN, so muss ich erstmal VERSTEHEN warum der Backslash nicht sein darf und ich muss das include-system der AVR Toolchain verstanden haben. Habe ich das nicht, sollte ich anderen auch nichts in der Richtung beibringen. Ich gebe Halbwissen weiter und trainiere falsche Vorgehensweisen an. Der Hinweis: "Auf WinAVR läuft es, ich habe doch gesagt ich nutze nur Windows" ist in diesem Zusammenhang wenig schmeichelhaft, bis extrem peinlich. Zumindest für jemanden der anderen etwas beibringen will. Es bringt nichts wenn der Blinde, den Blinden die Farben beibringt. Es gibt nichts schlimmeres als ein ein Lehrer den eigenen Stoff nicht kapiert hat. Und dazu gehört mehr als: "Also gestern gings bei mir".
:
Bearbeitet durch User
Cyblord -. schrieb: > GERADE für Anfänger, gerade wenn man etwas für andere macht, wenn man > LEHREN möchte, dann müssen die Infos präzise sein. Das Material muss > konsistent sein. Das sind dann die Fälle, wo Schüler/Studenten hier im Forum schreiben: "...ich habe mich ans Skript gehalten, aber mein Programm funktioniert nicht..." Christof E. schrieb: > Es ist für Neulinge, ungeübte oder leicht vorgebildete gedacht. GENAU...Neulinge sind meistens eh schon vom Inhalt (Programmiersprache / Hardware) am Anfang überfordert und dann kommt noch der mega Input an Bildern usw. Und wenn ein Profi, der eigentlich keine PDF benötigt, sagt: "Das ist too much", was soll da ein Anfänger bitte denken.
@ von Cyblord -. (cyblord) Also jetzt mal gut Könnten wir diese beisenden Herabwürdigungen und Besserwisserei mal sein lassen.! Hängen Sie sich bitte nicht an einigen Relikten mit einen Backslash auf, Mir ist es nicht aufgefallen, weil eben WINAvr das toleriert. WinAVR war die Wahl FÜR Anfänger. Weil einfach und nackt. Das heisst nicht, das ICH NUR damit arbeiten kann, weil sonst zu blöd! Oder einer #include sfr.h zuviel. das ist formal sicher unnötig, aber kein Fehler. Das habe ich schon korrigiert, oder werde es noch. Es ging mir darum junge Leute zu motivieren nicht z.B. dieses doofe Sketch zu machen oder überhaupt Projektkopierer zu werden. Tatsächlich konnte ich schon einige junge Leute dazu bringen, als Entwickler zu arbeiten und ein Brikett mehr aufzulegen. und damit habe ich wohl Erfolg gehabt. Ich selbst arbeite mit C++ und EFM32 von Silconlabs unter Eclipse. Was wirklich steinig ist. Und gerade jetzt und heute programmiere ich den Raspi mit CodeLite für ein MINT Girl Projekt. So und jetzt mal zu ihnen Es ist ein Frechheit Anderen die Kompetenz abzusprechen, weil irgendwelche Artefakte in 800 Seiten sind. Ich verbitte mir das: Für was halten Sie sich! Für den Oberguru? Auch ich habe 35 Jahre Berufserfahrung mit QNX, und Luftfahrt zertifizierter Software. Ich brauche ihr Gedöns nicht. Und nicht ich muss mich schämen für schlechten Stil. Und wen Sie andere für "zu blöd für Kurs" halten, kann sich jeder selbst hier eine Meinung bilden für schlechten Kommunikationsstil. Ich dachte es ist ein gute Idee in einem Mikrocontroller Forum meinem Mikrocontroller Kurs zur Verfügung zu stellen, den ich wohl nicht mehr nutzen kann, weil Corona keine Kurse zulässt, auch nächstes Jahr, und danach ein Nachfolger sein eigens Ding mach. Schade. Aber es reicht mir hier. Beschämend. Aber nicht für mich
Beitrag #6413228 wurde von einem Moderator gelöscht.
Christof E. schrieb: > @ von Cyblord -. (cyblord) > Also jetzt mal gut > Könnten wir diese beisenden Herabwürdigungen und Besserwisserei mal sein > lassen.! Wenn du jede Kritik nur so siehst, dann wird das nichts. Arbeite mal an deiner Kritikfähigkeit. Die ist elendig verkümmert würde ich mal sagen. > Hängen Sie sich bitte nicht an einigen Relikten mit einen Backslash auf, > Mir ist es nicht aufgefallen, weil eben WINAvr das toleriert. > WinAVR war die Wahl FÜR Anfänger. Weil einfach und nackt. > Das heisst nicht, das ICH NUR damit arbeiten kann, weil sonst zu blöd! Ich habe doch ausgeführt WARUM das ein Problem ist. Bitte nochmal lesen und es verstehen! > Oder einer #include sfr.h zuviel. > das ist formal sicher unnötig, aber kein Fehler. Ich habe doch ausgeführt WARUM das ein Problem ist. Bitte nochmal lesen und es verstehen! > Ich selbst arbeite mit C++ und EFM32 von Silconlabs unter Eclipse. > Was wirklich steinig ist. Und gerade jetzt und heute programmiere ich > den Raspi mit CodeLite für ein MINT Girl Projekt. Ich finde es zweifelhaft wenn du Leuten was beibringst mit so einer Einstellung und quasi keiner Kritikfähigkeit. > So und jetzt mal zu ihnen Uiui jetzt bekomm ich Angst. > Es ist ein Frechheit Anderen die Kompetenz abzusprechen, weil > irgendwelche Artefakte in 800 Seiten sind. > Ich verbitte mir das: > Für was halten Sie sich! Für den Oberguru? Du kannst dir verbitten was du willst. Schlechten Code und schlechte Skripte werde ich als solches benennen. Und JA, das muss nicht von mangelender Kompetenz herrühren, es gibt sicher gute Entwickler die schlechte Skripte machen, aber bei deiner ganzen Pfuscher-Einstellung glaube ich daran nicht. Ich bleibe dabei, dass du in der ganzen Materie selbst eher so Try&error unterwegs bist und weit entfernt von "fest im Sattel". > Auch ich habe 35 Jahre Berufserfahrung mit QNX, und Luftfahrt > zertifizierter Software. Und da schludert man sich mit falschen Includes durch? Oder machst du das nur bei minderwertigem Code für deine Schüler? Sind die es nicht Wert dass man ordentlich arbeitet? > Ich dachte es ist ein gute Idee in einem Mikrocontroller Forum meinem > Mikrocontroller Kurs zur Verfügung zu stellen, den ich wohl nicht mehr > nutzen kann, weil Corona keine Kurse zulässt, auch nächstes Jahr, und > danach ein Nachfolger sein eigens Ding mach. > Schade. Aber es reicht mir hier. Beschämend. Aber nicht für mich Ach wolltest du gar kein ehrliches Feedback sondern nur Applaus? Dann schreib das nächstes mal dazu.
Christof E. schrieb: > Es ist ein Frechheit Christof E. schrieb: > Ich dachte es ist ein gute Idee in einem Mikrocontroller Forum meinem > Mikrocontroller Kurs zur Verfügung zu stellen Natürlich...aber man sollte auch Kritik annehmen. Stefan hat hier auch sein Skript reingestellt und wurde ebenfalls mal hier & da auf Fehler oder Abweichungen angesprochen, jedoch empfand er dies nicht als Frechheit. Man sollte sich der Kritik annehmen und es dann besser machen. Die ganzen Anmerkungen kommen doch nicht aus Langeweile, sondern, weil es Tatsache ist. Dies ist kein Angriff und wer dies so empfindet, dann können wir auch nicht weiterhelfen.
Cyblord -. schrieb: > GERADE für Anfänger, gerade wenn man etwas für andere macht, wenn man > LEHREN möchte, dann müssen die Infos präzise sein. Das Material muss > konsistent sein. Ich hätte ja echt nicht gedacht, dass ich in diesem Leben nochmal Cyblord meine volle Zustimmung ausdrücken würde. ;-) Aber diesmal ist nicht nur der Inhalt seiner Aussage in Ordnung (das passiert gar nicht so selten bei ihm) sondern auch der Tonfall. Christof E. schrieb: > Kritik in Ehren, aber diese Methoden sind für den AVR so vorgesehen. ! Wenn du es nicht schaffst, Johann ernst zu nehmen, dann sorry, ist dir leider nicht zu helfen. Seine Argumente sind nicht nur inhaltlich zutreffend (logischerweise, bei seinem Hintergrund), sondern ja nun wirklich sehr sachlich formuliert. Bevor du ihnen widersprichst mit derart banalen Aussagen wie der von mir gerade zitierten, solltest du vielleicht einen Blick mehr in die Details von AVR-GCC und avr-libc werfen. Damit würde ich mich der Nichtempfehlung des Dokuments für Anfänger leider anschließen. Es gab ja einige hier, die versucht haben, dir zu einem besseren (fehlerfreien und konsistenten) Dokument zu verhelfen, aber wenn du deren Kritik nur an dir abperlen lässt ("ist ja nicht für Profis gedacht", "geht bei mir so"), dann lohnt das nicht. ps: Ich weiß, wie aufwändig es ist, Dokumentation zu schreiben. Ein großer Teil der avr-libc-Doku ist von mir, und ich habe auch schon Workshops und Vorträge zur Genüge gehalten.
:
Bearbeitet durch Moderator
jtreumer schrieb im Beitrag #6413228: > Hallo Christof Ermer, > > herzlichen Dank für die Mühe, die Du Dir mit der Zusammenstellung des > Crash-Kurses gemacht hast. Ich freue mich darüber, dass mir jemand aus > freien Stücken und kostenlos seine Arbeit zur Verfügung stellt. Die Art > und Weise, wie hier Kritik geübt wird (und sei sie teilweise auch > sachlich begründet), ist einfach nur daneben. > > SCNR, LG Jürgen Danke
Beitrag #6413242 wurde von einem Moderator gelöscht.
Christof E. schrieb: > WinAVR war die Wahl FÜR Anfänger. WinAVR ist übrigens seit 10 Jahren ungepflegt.
Christof E. schrieb: > Ich dachte es ist ein gute Idee in einem Mikrocontroller Forum meinem > Mikrocontroller Kurs zur Verfügung zu stellen, den ich wohl nicht mehr > nutzen kann, weil Corona keine Kurse zulässt, auch nächstes Jahr, und > danach ein Nachfolger sein eigens Ding mach. > Schade. Aber es reicht mir hier. Beschämend. Aber nicht für mich Das wäre schade. Viele haben die Gliederung angesprochen. Darauf würde ich mal bei Stefans Seite verweisen: http://stefanfrings.de/mikrocontroller_buch/ Gut Sie arbeiten im Kurs praktisch immer mit Beamer da ist soviel Text nicht gut. Deswegen denke ich, dass es eine gute Idee ist es zu splitten. Eine PPP(auch als pdf zur Veranschaulichung) und eine pdf für Arbeits- & Lernsmaterial und eine pdf mit Projekten. Erst ab Seite 15 zeigen Sie wozu ein µC verwendet wird. Direkt danach Projekte und dann sprichen Sie die CPU an und zeigst auf 4 unterschiedlichen Bildern mit dem gleichen Inhalt. Dann kommen bei Seite 34 bis Seite 57 verschiedenste µController. Und den Schaltplan würde ich nicht von Eagle nehmen sondern selber einen schönen zeichnen und alles unwichtige weglassen. Eine Seite wo verschiedene µController drauf sind reicht. Usw. für andere Themen. Das Steckbrett haben Sie gut angerissen. Mehr braucht es nicht. Ich bin kein Anfänger, aber mir wäre es zuviel Theorie auf einmal. Bekommen Sie Feedback von Ihren Studenten? So ein Fragebogen ist sehr nützlich. Am besten anonym dann sind die ehrlich.
Und was genau soll an Cyblords Kritik unsachlich gewesen sein?!
Jörg W. schrieb: > Cyblord -. schrieb: > Wenn du es nicht schaffst, Johann ernst zu nehmen, dann sorry, ist dir > leider nicht zu helfen. Seine Argumente sind nicht nur inhaltlich > zutreffend Wer sagt den , das ich dass nicht umsetze wa sJohann sagte, acuh cyborg hat in manchem Recht Wer Recht hat hat Recht. Die Backslashs , etc, überflüssige Includes.... Mir ist das nicht aufgefallen. Die eigenen Fehler und Redundanzen sieht man schlecht. Was ich korrigieren kann, mache ich. Aber diese Ton hier ist unter meiner Würde.!! Vieles was man umformatieren sollte, oder besser gar nicht formatieren. Kommentare habe ich versucht einzufärben Wem mein Stil nicht gefällt, die vielen Bildchen, braucht nicht weiterzulesen. So einfach ist das. Die Zielgruppe sind Andere. Ich habe es sonst auf dem Beamer wo ich was dazu sage und zeige. Aber es erklärt sich von selbst. Die Bildchen. Ich mache das so, weil es mir gefällt. WinaAVR ist gnadenlos veraltet. Das weis ich. Aber gerade die Nacktheit des Programmers Notepad macht vieles klarer. Ein Klick auf Make Ein Klick auf Programm.. und gut ists.. Und ein Ordnername ist zugleich der Projektname.. ohne komplizierte Workspaces usw. Hat alles seinen Grund Nachricht von der Aussenwelt: Ich habe es mit zunehmend schlecht vorgebildeten Studienanfängern zu tun. Da brauch ich nicht mit AVR Studio kommen. Die blicken das nicht, die Projektverwaltung, in der kurzen Zeit. Hab's ausprobiert und bin reumütig zu WINAVR zurück Wie abreiten im C++ Kurs z.B. mit DEV_C++ . Ebenfalls Saurier. Das Debugging, grauenhaft. Aber eben auch verständlich, und kostenlos. Da mein Skript nicht geschätzt wird, habe ich die Löschung des Threads beantragt. Das Skript werde ich von berechtigten Fehlern befreien. Aber so schlimm waren die jetzt nicht, offen gesagt. Artefakte, Relikte. zumeist. Das Powerpoint beim Kopieren ein Autoformat macht und ein Gänsefüßchen runtersetzt... also ich bitte.. Meist sind diese Texte Nachts um 10:00, zuhause, wo das Skript zumeist entstand, kurz vor einem Kurs, dazugekommen. Es geht immer noch um Strukturen. Wie einen Timer Bitmuster Sequenzen ausgeben lassen, was Schrittmotor Steuerungen zulässt. Das ist wichtig, wie man das macht, Flags, oder UART Text Kommunikation+ Steuerung mit externen Steueroberflächen wie LabView ( Uni üblich )... und das kann man mit dem Skript auch selbst lernen. Wie die letzten 16 Jahre (ohne festes Skript) zeigen.
Rainer S. schrieb: > Christof E. schrieb: >> Ich dachte es ist ein gute Idee in einem Mikrocontroller Forum meinem >> Mikrocontroller Kurs zur Verfügung zu stellen, den ich wohl nicht mehr >> nutzen kann, weil Corona keine Kurse zulässt, auch nächstes Jahr, und >> danach ein Nachfolger sein eigens Ding mach. >> Schade. Aber es reicht mir hier. Beschämend. Aber nicht für mich > > Das wäre schade. Viele haben die Gliederung angesprochen. Darauf würde > ich mal bei Stefans Seite verweisen: > http://stefanfrings.de/mikrocontroller_buch/ > > Gut Sie arbeiten im Kurs praktisch immer mit Beamer da ist soviel Text > nicht gut. Deswegen denke ich, dass es eine gute Idee ist es zu > splitten. > Eine PPP(auch als pdf zur Veranschaulichung) und eine pdf für Arbeits- & > Lernsmaterial und eine pdf mit Projekten. > > Erst ab Seite 15 zeigen Sie wozu ein µC verwendet wird. Direkt danach > Projekte und dann sprichen Sie die CPU an und zeigst auf 4 > unterschiedlichen Bildern mit dem gleichen Inhalt. > > Dann kommen bei Seite 34 bis Seite 57 verschiedenste µController. Und > den Schaltplan würde ich nicht von Eagle nehmen sondern selber einen > schönen zeichnen und alles unwichtige weglassen. Eine Seite wo > verschiedene µController drauf sind reicht. > > Usw. für andere Themen. > > Das Steckbrett haben Sie gut angerissen. Mehr braucht es nicht. > > Ich bin kein Anfänger, aber mir wäre es zuviel Theorie auf einmal. > > Bekommen Sie Feedback von Ihren Studenten? So ein Fragebogen ist sehr > nützlich. Am besten anonym dann sind die ehrlich. Vielen Dank Ich sehe, da ist noch was zu tun für mich. Habe evtl zuviel reingestopft. Wollte auf alles vorbereite sein Ich habe mir das gespeichert und berücksichtige dies sobald ich dazu kommen Vilen Dank Chriostof Ermer
Christof E. schrieb: > Wem mein Stil nicht gefällt, die vielen Bildchen, braucht nicht > weiterzulesen. So einfach ist das. Oder er liest weiter und gibt dir Feedback. Ist das nicht erwünscht? Ich meine du solltest "deinen Stil" mal überdenken. Allein wenn man deine Website anschaut. Ist DAS dein Stil? Ernsthaft? Und die Folien sind überladen. Das ist ein Fakt. Keine Stilfrage. Schau dir doch mal grundlegende Aspekte für gute PP Folien an. Tipps gibts da heute an jeder Ecke. Ein bisschen sollte man sowas schon annehmen. > Da brauch ich nicht mit AVR Studio kommen. Die blicken das nicht, die > Projektverwaltung, in der kurzen Zeit. > Hab's ausprobiert und bin reumütig zu WINAVR zurück > Wie abreiten im C++ Kurs z.B. mit DEV_C++ . Ebenfalls Saurier. > Das Debugging, grauenhaft. Aber eben auch verständlich, und kostenlos. Bei der modernen SW-Entwicklung geht es eben auch um Tools. Es geht um guten Code und um die sinnvolle Nutzung der Werkzeuge. Bei JEDEM Beruf geht Fachwissen und Werkzeugbeherrschung Hand in Hand. Was würdest du zu einem Schreiner sagen, der alles mit der Nagelfeile sägt, weil er prof. Sägen zu anstrengend findet? Dabei ist egal wie gut er vermeintlich ist. Es ist kein prof. Vorgehen. Was soll bei dir gelehrt werden? Frickeln auf Microcontrollern? Oder hat das wirklich irgendwas mit PROFESSIONELLEM Arbeiten zu tun? Ich meine, es kommt immer auf den Anspruch drauf an. Aber ich habe da was von Uni gelesen. Ich meine ich mache ja gerne mal Witze über Physiker die SW Entwickeln, aber da werden doch alle Klischees erfüllt.
Christof E. schrieb: > Da brauch ich nicht mit AVR Studio kommen. Die blicken das nicht, die > Projektverwaltung, in der kurzen Zeit. Das wundert mich jetzt nicht. Aber du kannst natürlich auch Notepad++ mit einem neueren Compiler benutzen, dann ist das wenigstens nicht mehr so hornalt. Es ist ja nicht nur, dass allerlei aktuelle Verbesserungen im C-Standard seither aufgekommen sind, insbesondere sind seit dem alten GCC, der im WinAVR drin ist, unzählig viele Bugfixes in den Compiler eingearbeitet worden (und zwar von ebendiesem Johann, der sich ganz oben zu Wort gemeldet hat). Auf die sollte man nun wirklich nicht verzichten. Ja, das gibt's dann nicht schlüsselfertig als Paket, aber für einen Kurs an der Uni sollte man so ein Paket ja auch mal selbst zusammenstellen können. Du kannst m.W. den Compiler separat bei Atmel/Microchip nehmen, ohne dass man den gesamten Atmel-Studio-Rassel runterladen muss. Christof E. schrieb: > Aber diese Ton hier ist unter meiner Würde. Komm, gerade Johann hat das doch außerordentlich sachlich kommentiert, viele andere auch. Das ist ein Forum und damit eben öffentlich, ignoriere einfach die, deren Ton dir nicht gefällt. > Das Powerpoint beim Kopieren ein Autoformat macht und ein Gänsefüßchen > runtersetzt... also ich bitte Auch wenn du bittest: einen Anfänger können gerade derartige Kleinigkeiten massiv verwirren. Der sucht sich dann mühevoll raus, wie er die falschen Gänsefüßchen überhaupt auf der Tastatur findet, nur um danach einen Compilerfehler an den Kopf geworfen zu bekommen.
Christof E. schrieb: > Gegentest auf Kritik #include <avr\io.h> mit Backslash > ES GEHT ! Wow! Du weißt schon, dass aus "A => B" nicht folgt "B => A"? Hier mit: A = "Code ist korrekt" B = "Code macht, was er soll" Das ist ein omnipräsenter Denkfehler! Warum? Weil man B nicht testen kann für * alle Eingaben und Timings * alle Compiler-Optionen, mit denen übersetzt wird * alle erlaubten Predefines wie -DF_CPU= * alle Compiler-Versionen * alle Hosts, auf denen der Compiler läuft Häufig begegnet einem der Denkfehler bei Antwort auf Fragen wie "Was macht der Code?", wenn mit "Schau dir an, was ein Simulator macht" geantwortet wird. Die Antwort ist in dem Sinne korrekt, dass ein Simulator zeigt, was der Maschinencode für bestimmte Eingaben macht. Aber daraus erhält man eben nicht die Semantik des C/C++ Codes! Und auch nicht seine Korrektheit! Kleine Fehler und Ungereimtheiten Das Problem damit ist, dass Anfänger oder Leute, die nicht sicher mit der Materie umgehen können, nicht darüber hinweglesen — eben weil sie sich noch nicht damit auskennen. Es stellt sich dann ein diffuses Gefühl ein von "das versteh ich nicht", und Anfänger denken dann schnell sie seien zu blöd um das alles zu verstehen, werden frustriert etc. und / oder lernen es so auswendig, wie es da steht. Klar, in einer Präsenzveranstaltung kann man nachfragen, falls einem klar ist, was da inkonsistent ist. In einem Dokument zum Selbststudium geht Nachfragen aber nicht. Was wären z.B. Deine Antworten auf die Fragen: * Warum heißt es manchmal #include <avr/io.h> und manchmal #include <avr\io.h>? * Warum wird avr/sfr_defs.h included? * Warum ist manchmal ein ";" hinter der schließenden "}" eines Blocks und manchmal nicht? Weil es funktioniert? Aufbau Das Dokument ist offenbar als Mitschrift oder Dokumentation einer Präsenzveranstaltung gewachsen, und als solches hat es wohl seine Daseinsberechtigung. Das bedeutet aber noch lange nicht, dass es für ein Selbststudium geeignet wäre. Solch ein Werk zu erarbeiten ist sau viel Arbeit, und es wäre definitiv mehr als eine Dokumentation dessen, was in einem bestimmten Präsenzkurs dann und wann mal Thema war. M.E. wäre ein gangbarer Weg genau andersrum: Man nimmt ein zum Selbststudium geeignetes Werk, und darauf basierend konzipiert man eine Präsenzveranstaltung. Aber so ein Werk zu erstellen ist ein erheblicher Klotz an Arbeit, und man macht das nicht mal eben nebenher! Und es braucht definitiv einen Lektor. Und zwar einen, der sich mit der Materie auskennt. Formatierung Kritik an Formatierung mag Dir haarspalterisch erscheinen. Hat ja nix mit dem Inhalt zu tun. Aber: Menschen erfassen einen Text nicht nur als Abfolge von Buchstaben und Glyphen, sondern als Bild. Das gilt insbesondere auch für Code: Ob der gut oder grottig formatiert ist, ist einem Compiler egal. Für einen Menschen ist es nicht egal. Die Lehre, die sich damit beschäftigt, heißt Typographie. Vor 100 Jahren gab es noch Typographen und Setzer, die Texte und Bilder in eine Form brachten, die für den Leser möglichst gut und ermüdungsfrei erfassbar war — natürlich ohne den Inhalt anzufassen. Das betrifft Formatierung von Texten, Wahl von Schriftschnitten und Seitenspiegel, etc. Mit Aufkommen von Textverarbeitungsprogrammen ist dieser Beruf praktisch ausgestorben: Textsatz etc. wird vom Autor selbst vorgenommen, oft ohne dass dem Autor typographische Prinzipien und Anforderungen überhaupt bewusst sind. Er wählt Fonts und Vorlagen, die der hübsch findet, und gut ist... Wie gut und ermüdungsfrei ein Text zu lesen ist, hängt aber wesentlich auch mit der Form zusammen. Ist nun mal so. Dein Dokument hat das Problem, dass es eine Präsentation ist, d.h. es passt nur recht wenig Text auf eine Seite, was wiederum die Möglichkeiten, ihn typographisch angemessen zu gestalten, stark einschränkt. Insbesonere Quellcode, der sehr stringente Formatierung erfordert, leidet sehr darunter. Was das Dokument angeht, hab ich aber den Eindruck, dass noch nichtmal versucht wurde, eine eingehende und konsistente Code-Formatierung zu erreichen, includive Naming Conventions etc. Das macht den Code schwerer erfassbar, als es sein müsste. Insbesondere würd ich nicht eine hausbackene Formatierung erfinden, sonderen eine etablierte Formatierung wählen und die auch durchhalten. > wenn an zwei Stellen in 800 Seiten das "\" Stand, ist das erträglich, > nicht? Siehe oben. Code für Anfänger muss m.E. extrem gut sein. Damit meine ich nicht trickreich, sondern konsistent, absolut fehlerfrei, gut nachvollziehbar, stringent formatiert etc. Anfänger lesen nämlich nicht über Ungereimtheiten, Schlampereien oder Fehler hinweg, sondern lernen sie, oder es behindert sie beim Verstehen; oft ohne dass sie die Probleme artikulieren können — einfach weil sie sich noch nicht damit auskennen. Dem Dokument hätte es definitiv nicht geschadet, wenn ein Besserwisser[tm] im Kurs gewesen wäre :-)
Danke verstehe Die meisten Sachen habe ich schon korrigiert auf meiner page Meist flüchtigkeistartefakte. Kann den Downloadlink hier nicht ändern. Aber auf meiner Seite ist das jetzt bereinigt Das Skript habe ich zuletzt Feburar erweitert. Dann kam Corona. Das einige #include <avr/sfr_defs.h> zuviel solche Aufregung machen, hätte ich nicht geahnt. Na gut. Ich selbst öffne diese immer wieder mal zum nachsehen. Überflüssige Formate Es gibt einen Trick,. Text Kopieren, in Notepade pasten, kopieren. und zurück. und schon hat man alle Fomatierungen los. Dann kann man sich das nochmals ansehen Das Beamerformat lässt leider nur wenige Zeilen/Seite zu und dies dann noch mindesten .28 gross sonst wird es zu klein für die hinteren Reihen. Was meine Augen mit 60 dazu mein ist klar. Den Text habe ich meist spät abends zusammengesucht. Irgendwann, Immer wieder. daher wohl das unterschiedliche Aussehen. Und viel Arbeit habe ich so auch tagsüber. Ok. Da muss dann halt nochmals der Formatputz drüber. Es war einfach immer ein Arbeits-Merkzettel. Kein redigiertes Buch Aber ich habe von Leuten die damit gearbeitet haben immer wieder Erfolgsmeldungen bekommen. ADC- Servo- Sensoren Shiftbausteine etc.. CLK, DATA, ENABLE , LCD.. Stepmotor. und das ohne externe, nicht einsehbare Bibliotheken.-- Mehr kann man in 8..10 Tagen gar nicht erreichen. Und leider wird es Zeit für Weitergabe. Das war mein Intention Übrgens Stefan Frings Seite ist einfach klasse,. !! Da komme ich mit meinem Kompozer HTML nicht hin.. Aber dazu habe ich auch nicht die Zeit.. Mit 60 überlegt man sich , was man nicht mehr tut. Dennoch habe ich mir den Spass erhalten. Baue gerad eine Kurzwellen MorseSender mit Dekodierung auf Raspie mit einem AVR als Arbeitsknecht... Darum geht es. Spass zu haben ,was man tut
Christof E. schrieb: > Stimmt.! vieles, dort und da, was so nicht sein sollte. Oder sogar > verwirrt. > Ich schrieb auch. "Dort und da "Fehlerhaft ,aber brauchbar." > Es ist ein Powerpoint Vortrag und eine Erklär-Arbeitsgrundlage, und > werden normalerweis im Kurs alles erklärt, wie es gemeint ist. > Habe aber keinen Lektor. Wenn ich Fehler finde, beseitige ich dies auch > sobald wie mögl. > Es ist eine Anleitung, mit Registern statt mit Bibliotheken, deren > Arbeitsweise man nicht kennt, umgehen zu lernen. Mit Verwendung von > ANSI-C und nicht C++. Was unnötig sperrig ist für das kleine > Controllerchen. > Das tut es. Und darum geht es.. erst einmal vielen Dank für das Skript - ich finde es gut :-) Was jetzt die Kritik anbelangt ... die kann man in einem update aufgreifen - aber ansonsten ist Kritik nicht berechtigt. Leute, das Skript ist zum kostenfreien Download - wer unbedingt meint es müsse der heilige Gral sein, der kann sich ja gern so für 80 Euronen im Handel eindecken ... wäre mir zu teuer :-)
Christof E. schrieb: > Übrigens Stefan Frings Seite ist einfach klasse,. !! > Da komme ich mit meinem Kompozer HTML nicht hin.. Danke für das Lob. Meine Seite ist allerdings komplett hand-gedengelt, mit Notepad. Alte Gewohnheit. Johann L. schrieb: > Soweit is sehe verwendest du auch Features, die nicht ANSI-C sind wie > Interrupts, Inline Assembly und util/delay.h, avr/eeprom.h etc. Bei Mikrocontrollern kommt man wohl kaum umhin, Dinge zu benutzen, die "nicht ANSI-C sind".
Stefan ⛄ F. schrieb: > Christof E. schrieb: >> Übrigens Stefan Frings Seite ist einfach klasse,. !! >> Da komme ich mit meinem Kompozer HTML nicht hin.. > > Danke für das Lob. Meine Seite ist allerdings komplett hand-gedengelt, > mit Notepad. Alte Gewohnheit. > > Johann L. schrieb: >> Soweit is sehe verwendest du auch Features, die nicht ANSI-C sind wie >> Interrupts, Inline Assembly und util/delay.h, avr/eeprom.h etc. > > Bei Mikrocontrollern kommt man wohl kaum umhin, Dinge zu benutzen, die > "nicht ANSI-C sind". Ich bin beeindruckt. Solche Leute machen Freude
Christof E. schrieb: > Es gibt einen Trick,. Text Kopieren, in Notepad pasten, kopieren. und > zurück. und schon hat man alle Fomatierungen los. Für sowas nutze ich "PureText" von Steve Miller. Unverzichtbar auf Windows. In meinen Augen.
Beitrag #6413394 wurde von einem Moderator gelöscht.
Christof E. schrieb: > PRINZIP: > #define KEY_INT_EVENT 0x01 > ISR( INT0..... > { > gu8KeyFlags |= KEY_INT_EVENT; > // dann Stop INT0_Interrupt usw... > } > > // irgendwo z.B. Mainloop > if(gu8KeyFlags & KEY_INT_EVENT) > { > gu8KeyFlags &= ~KEY_INT_EVENT; // clear flag > ....Polling , was immmer passiert > } > Ich wollte damit vor allem die "Möglichkeit" der Ablaufsteuerung mit > Flags zeigen. Es stellt sich aber die Frage, wozu? Im Endeffekt ist es das gleiche, wie in der main direkt auf's INT0-Flag zu pollen — es sein denn, in main vergeht eine Mindestzeit in der Größenordnung von 10ms zwischen den Abfragen des Flags. Dies wiederum kann geschehen durch Delay (abzulehnen), oder indem eine Timer-ISR alle 10ms ein Flags setzt, das in main abgeholt wird um zu testen, ob ein KEY_INT_EVENT auszuwerten ist. Entprellung geschieht am einfachsten, indem man in einer Timer-ISR alle 10ms den Status der Taster abfragt. Weiterer Vorteil ist, dass man nicht einen dedizierten Port wie INT0 braucht, sondern den Port frei wählen kann. Insbesondere wichtig, wenn man mehrere Taster hat oder INTx für was anderes wirklich braucht. Und in vielen Anwendungen hat man eh ne periodische Timer-ISR, z.B. für LED-Blink, (Trigger von) Morse-Ausgabe o.ä., etc. Falls die entsprechende IRQ öfter triggert als alle 10ms (wahrscheinlich), dann macht man die 10ms per Software in dieser ISR. Außerdem gibt's nen Glitch im Code da nicht atomar:
1 | gu8KeyFlags &= ~KEY_INT_EVENT; // clear flag |
Falls gu8KeyFlags noch andere Flags beherbergt, was der Name nahelegt, dann funktioniert er sporadisch nicht wie angedacht. Testfall:
1 | #include <stdint.h> |
2 | |
3 | #define KEY_INT_EVENT (1 << 0)
|
4 | |
5 | volatile uint8_t gu8KeyFlags; |
6 | |
7 | void foo (void) |
8 | {
|
9 | gu8KeyFlags &= ~KEY_INT_EVENT; |
10 | }
|
Assembly von avr-gcc:
1 | foo: |
2 | lds r24,gu8KeyFlags |
3 | andi r24,lo8(-2) |
4 | sts gu8KeyFlags,r24 |
5 | ret |
Falls zwischen LDS und STS eine ISR ein anderes Flag verändert (z.B. für einen anderen Taster), dann wird dies vom STS überschrieben. > Inhaltsverzeichnis... schwierig. Bei ca. 800 Seiten aber unabdingbar. Und es hilft Dir selbst dabei, alles zu organisieren und den Überblick zu bewahren. > Tatsächlich springe ich die Themen je nach Kursablauf an. Offenbar. Aber was macht ein Leser, der das Dokument wie von Dir angedacht zum Selbststudium verwendt? > Zwischensemster ganztags Kursdauer von nur 10 Tagen Weia. Da kann man nur hoffen, ihr habt genug Trichter.
Johann L. schrieb: >> Zwischensemster ganztags Kursdauer von nur 10 Tagen > > Weia. Da kann man nur hoffen, ihr habt genug Trichter. Und erwartet nicht, dass irgendwer etwas lernt.
Stefan ⛄ F. schrieb: > Bei Mikrocontrollern kommt man wohl kaum umhin, Dinge zu benutzen, die > "nicht ANSI-C sind". Korrekt, aber dann sollte man halt auch nicht "ANSI C" drüber schreiben - zumal der C-Standard seit ANSI C89 (so wäre die korrekte Bezeichnung) inzwischen bereits weitere Versionen kennt, und die Standardisierung an die ISO übergegangen ist. C99 brachte uns insbesondere <stdint.h> und damit die genannten Ganzzahlen mit wohldefinierten Größen (uint8_t etc.), die gerade im Controller-Umfeld massiv Einzug gehalten haben. Die Ergänzungen von C11 und C17 haben dagegen noch nicht ganz die Verbreitung gefunden.
Seite 656 aus dem externen Link - zufällig mal hingeblättert:
1 | // ********************** |
2 | uint8_t PseudoRandom(void) |
3 | // ********************** |
4 | {
|
5 | static uint8_t s=0xaa,a=0; |
6 | s^=s<<3; //XOR |
7 | s^=s>>5; |
8 | s^=a++>>2; |
9 | }; |
10 | Zufallsfund: |
11 | Auf der suche nach einer Speicherschonenden |
12 | Zufallszahlengenerierung |
13 | (was die Leute sich so ausdenken) |
Die Funktion PseudoRandom() ist definiert mit einem Rückgabewert vom Typ uint8_t, liefert aber gar nichts zurück. Ich muss mich meinen Vorrednern anschließen: Gerade Anfängern sollte man Code präsentieren, der selbst auch getestet und auf Richtigkeit überprüft wurde. Solche Stolperfallen wie falsche Gänse, Slashes und fehlende Rückgabewerte schrecken gerade Anfänger ab, wenn sie am Code verzweifeln, weil sie ihn gar nicht durch den Compiler bekommen. Die armen Anfänger wissen in solch einer Situation überhaupt nicht, wie sie den Fehler beheben können und werden dann einfach das Handtuch werfen. Und wieder einer weniger... Dieses Dokument ist in dieser Form kontraproduktiv und bedarf ganz klar einer strikten Überarbeitung, sorry.
:
Bearbeitet durch Moderator
Beitrag #6413503 wurde von einem Moderator gelöscht.
Beitrag #6413551 wurde von einem Moderator gelöscht.
Frank M. schrieb: > Seite 656 aus dem externen Link - zufällig mal hingeblättert: >
1 | > // ********************** |
2 | > uint8_t PseudoRandom(void) |
3 | > // ********************** |
4 | > {
|
5 | > static uint8_t s=0xaa,a=0; |
6 | > s^=s<<3; //XOR |
7 | > s^=s>>5; |
8 | > s^=a++>>2; |
9 | > }; |
10 | > Zufallsfund: |
11 | > Auf der suche nach einer Speicherschonenden |
12 | > Zufallszahlengenerierung |
13 | > (was die Leute sich so ausdenken) |
14 | > |
> > Die Funktion PseudoRandom() ist definiert mit einem Rückgabewert vom Typ > uint8_t, liefert aber gar nichts zurück. > > Ich muss mich meinen Vorrednern anschließen: Gerade Anfängern sollte man > Code präsentieren, der selbst auch getestet und auf Richtigkeit > überprüft wurde. Solche Stolperfallen wie falsche Gänse, Slashes und > fehlende Rückgabewerte schrecken gerade Anfänger ab, wenn sie am Code > verzweifeln, weil sie ihn gar nicht durch den Compiler bekommen. > > Die armen Anfänger wissen in solch einer Situation überhaupt nicht, wie > sie den Fehler beheben können und werden dann einfach das Handtuch > werfen. Und wieder einer weniger... > > Dieses Dokument ist in dieser Form kontraproduktiv und bedarf ganz klar > einer strikten Überarbeitung, sorry. Ja, das return hat das kopieren nicht überlebt. Aber daher die Ruprik Fundus. auf das fehlene return kommt man ja noch.. Dennoch, haben Sie recht. Typische Flüchtigkeitsfehler, die man selber nicht sofort sieht., Evtl war schon ein Troliinger eingeschraubt um 23:00, was so meine bevorzugte Zeit ist für Codestöbereienen.. Ist schon gelöscht.. Kann mich aber erinnern, dass ich das ausprobiert hatte. Ging hervorragend, Grafische Verteilungsprüfung war bestens. Manchmal ist sowas hilfreich. Kleiner Tipp IN YT gibt es eine Prof WEIZ https://www.youtube.com/channel/UCjTfChr0yyz4iZq0x12Q6xA mit hervorragenden Mathe Videos. Da habe ich das mit der Zufallsverteilung her. Sie glauben nicht was da alles für Misst existiert. Doch. Sie glauben es
Jörg W. schrieb: > C99 brachte uns insbesondere <stdint.h> Ich glaube, die Binärzahlen (literale) gehören inzwischen auch zum Standard.
Stefan ⛄ F. schrieb: > Ich glaube, die Binärzahlen (literale) gehören inzwischen auch zum > Standard. Nur in C++. In C habe ich das gerade an die WG14 eingereicht … ich gehe mal davon aus, dass es (anders als 1999) durchgehen wird, insbesondere da C++ es bereits standardisiert hat.
Jörg W. schrieb: >> Ich glaube, die Binärzahlen (literale) gehören inzwischen auch zum >> Standard. > Nur in C++. Echt? Das ist ja seltsam, wie unlogisch!
Stefan ⛄ F. schrieb: > Ich glaube, die Binärzahlen (literale) gehören inzwischen auch zum > Standard. Ich bin mir nicht sicher, ob das nicht nur eine GCC-Erweiterung ist, oder ob das wirklich alle Compiler unterstützen? In C++14 dürfte es standardisiert sein, aber in C eher nicht.
Angehängte Dateien:
-
PseudoRandom.png
5,4 KB -
random.png
5,4 KB -
lfsr1.png
5,2 KB
Christof E. schrieb: > Ging hervorragend, Grafische Verteilungsprüfung war bestens. Naja, "geht so", würde ich mal sagen. Bringt es ungefähr auf die gleiche Qualität, wie wenn ich die stdlib-Funktion random() auf 8 Bits einkürze. Wenn man aber ein LFSR (gängige Praxis für eine Pseudo-Random-Zahl) mit 8 Bits aufbaut, wird es sauberer. Die Funktion lsfr1() habe ich mir aus dem englischen Wikipediaartikel: https://en.wikipedia.org/wiki/Linear-feedback_shift_register mal schnell zusammengeschustert:
1 | uint8_t lfsr1(void) |
2 | {
|
3 | static uint16_t lfsr = 0xe1; |
4 | uint8_t bit; |
5 | unsigned period = 0; |
6 | |
7 | /* taps: 8 6 5 4; feedback polynomial: x^8 + x^6 + x^5 + x^4 + 1 */
|
8 | bit = ((lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 4)) /* & 1u */; |
9 | lfsr = (lfsr >> 1) | (bit << 15); |
10 | |
11 | return lfsr; |
12 | }
|
Anbei die Histogramme für PseudoRandom(), (int)random & 255 und lsfr1(), jeweils für 20000 Durchläufe. Ich denke, man kann die Unterschiede sehen. ;-) (Hatte mich jetzt mal persönlich interessiert, wie gut sowas jeweils ist.)
:
Bearbeitet durch Moderator
Beitrag #6413598 wurde von einem Moderator gelöscht.
Seite 473 ff:
1 | //MAKROS
|
2 | #define INIT_74165PORTDIR() (INSHIFT_74165_DDRX = INSHIFT_74165_DDRX_VALUES);
|
3 | #define SET_74165_CLK() (INSHIFT_74165_PORT |= INSHIFT_74165_CLK_BIT);
|
4 | #define CLR_74165_CLK() (INSHIFT_74165_PORT &= ~INSHIFT_74165_CLK_BIT);
|
5 | #define SET_74165_SHLD() (INSHIFT_74165_PORT |= INSHIFT_74165_SHLD);
|
6 | #define CLR_74165_SHLD() (INSHIFT_74165_PORT &= ~INSHIFT_74165_SHLD);
|
Man beachte die Semikolons am Ende. Anwendung auf Seit 474:
1 | CLR_74165_CLK(); <--- mit Semikolon |
2 | CLR_74165_SHLD() <--- ohne Semikolon |
3 | _delay_us(1); |
4 | SET_74165_SHLD(); <--- mit Semikolon |
Hier ist die unheitliche Anwendung von Makros zu bemerken: Mal mit, mal ohne Semikolons. Ein Anfänger fragt sich: "Warum?!?". Ich sage da nur: Uff, nochmal gutgegangen, denn fatal wäre folgende Anwendung:
1 | if (flag) |
2 | CLR_74165_CLK(); |
3 | else
|
4 | mach_was_anderes(); |
Da wundert sich dann der mutmaßliche Anfänger, warum der C-Compiler ihm diese absolut unverständliche Fehlermeldung
1 | error: ‘else’ without a previous ‘if’ |
um die Ohren knallt. (Hint: doppeltes Semikolon) @christof: Semikolons in C-Makros sind absolut zu vermeiden. Wenn, dann gehören sie ausschließlich in den Programmcode.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > In C habe ich das gerade an die WG14 eingereicht … ich gehe mal davon > aus, dass es (anders als 1999) durchgehen wird, insbesondere da C++ es > bereits standardisiert hat. Gab es 1999 eine Begründung warum es nicht eingeführt wurde?
Beitrag #6413607 wurde vom Autor gelöscht.
Christof E. schrieb: > uint8_t u8NN = 0; > if( u8NN < -2 ) > ....kann so nicht stimmen weil "u8NN"--> unsigned 8 Bit namens NN heißt, aber NN ist eine Variable und die sollten doch Kleinbuchstaben bekommen? Mir war mal so als wenn Großbuchstaben den #define vorbehalten sind. Ich nenne also meine Variablen uint8_nn um beim Beispiel zu bleiben.
Cyblord -. schrieb: > Gab es 1999 eine Begründung warum es nicht eingeführt wurde? Steht im C99 Rationale: "A proposal to add binary constants was rejected due to lack of precedent and insufficient utility." ;-)
Beitrag #6413615 wurde von einem Moderator gelöscht.
Joachim B. schrieb: > aber NN ist eine Variable und die sollten doch Kleinbuchstaben bekommen? > Mir war mal so als wenn Großbuchstaben den #define vorbehalten sind. Reine Konvention. (BTW an die ich mich auch halte). Er meinte den Vergleich einer vorzeichenlosen Variablen mit einem negativen Wert, lies nochmal.
Jörg W. schrieb: > Christof E. schrieb:> Die Funktion lsfr1() habe ich mir aus dem englischen Wikipediaartikel: > https://en.wikipedia.org/wiki/Linear-feedback_shift_register > mal schnell zusammengeschustert: >
1 | > uint8_t lfsr1(void) |
2 | > { |
3 | > static uint16_t lfsr = 0xe1; |
4 | > uint8_t bit; |
5 | > unsigned period = 0; |
6 | >
|
7 | > /* taps: 8 6 5 4; feedback polynomial: x^8 + x^6 + x^5 + x^4 + 1 */ |
8 | > bit = ((lfsr >> 0) ^ (lfsr >> 2) ^ (lfsr >> 3) ^ (lfsr >> 4)) /* & |
9 | > 1u */; |
10 | > lfsr = (lfsr >> 1) | (bit << 15); |
11 | >
|
12 | > return lfsr; |
13 | > } |
14 | >
|
> > Anbei die Histogramme für PseudoRandom(), (int)random & 255 und lsfr1(), > jeweils für 20000 Durchläufe. Ich denke, man kann die Unterschiede > sehen. ;-) > > (Hatte mich jetzt mal persönlich interessiert, wie gut sowas jeweils > ist.) Ohh gefällt mir sehr
Christof E. schrieb: >> unsigned period = 0; > Ohh gefällt mir sehr Sorry, das "unsigned period" ist noch ein copy&paste-Überbleibsel aus dem Wikipedia (dort haben sie ja die Periode ermittelt), das kann weg.
Frank M. schrieb: > Reine Konvention. (BTW an die ich mich auch halte). prima, sind wir mindestens schon mal 2 Frank M. schrieb: > Er meinte den Vergleich einer vorzeichenlosen Variablen mit einem > negativen Wert, lies nochmal. hatte ich verstanden war aber nicht mein Kontext dazu und trotzdem sieht man den Fehler sofort! auch ein uint8_nn kann nicht negativ werden ;) genau wie ein u8NN nur ist u8NN unübersichtlicher im Gegensatz zu uint8_nn
Jörg W. schrieb im Beitrag #6413607: > Christof E. schrieb: > >> Löschen Sie diesen Thread und vor allen den Kopierlink zur PDF >> Das ist ein Aufforderung zur Löschung des Threads. > > Dafür gibt es keinen Grund. Vor allem, da die pdf unter CC BY-NC-SA 3.0 AT steht. Jörg W. schrieb: > "A proposal to add binary constants was rejected due to lack of > precedent and insufficient utility." Weißt du was mit precedent gemeint ist? Gab es zu dem Zeitpunkt keine Sprache, die binary constants hatte, oder gabes noch keine c-Compiler, die eine derartige Erweiterung hatten?
Jörg W. schrieb: > "A proposal to add binary constants was rejected due to lack of > precedent and insufficient utility." Ich kann mich täuschen, aber heißt das auf Deutsch übersetzt nicht so viel "F...ck dich und deinen Vorschlag"? ;-)
Beitrag #6413637 wurde von einem Moderator gelöscht.
mh schrieb: >> "A proposal to add binary constants was rejected due to lack of >> precedent and insufficient utility." > > Weißt du was mit precedent gemeint ist? Gab es zu dem Zeitpunkt keine > Sprache, die binary constants hatte, oder gabes noch keine c-Compiler, > die eine derartige Erweiterung hatten? Ich vermute mal, das Standardkommittee kannte keinen C-Compiler, der sowas damals implementiert hatte (obwohl es davon bestimmt schon welche gab).
korrekt Die Var heißt u8NN Also ein Zähler mit unsigned 8 Bit Länge. Ich schreibe Variablen mit Typzeichen aus Kleinbuchstaben und dann Jede Silbe mit Großbuchstaben Asunahme. außer einem banalen Zähler u8YY ist OK, da man zumindest den Typ sieht, was ja mit Kleinbuchstaben davor steht, daher u8NN; Nur die beliebten "Ein-Buchstaben variablen wie in Lehrbüchern for( i = .... das gibt es bei mir nicht, So sieht man immer!!, mit was man arbeitet. #define ICH_BIN_EIN_DEFINE 123UL int32_t * pi32DiesIsteinPointerauf32Bit= NULL; Das mag alt sein Ich auch Ich mache das seit den frühen 90erm, und ich liebe es. hier ein Beispiel aus den frühen 2000enern https://homepages.uni-regensburg.de/~erc24492/GPS_Secrets/GPS_Secrets.html
Beitrag #6413654 wurde von einem Moderator gelöscht.
Beitrag #6413658 wurde von einem Moderator gelöscht.
Christof E. schrieb: > So sieht man immer!!, mit was man arbeitet. Den Typ der Variablen (bzw. die Definition selbst) zeigt so gut wie jede IDE an, wenn man mit der Maus drüber fährt. Statt solche unwichtigen Äußerlichkeiten für wichtig zu halten, solltest Du besser an den Inhalten feilen, zum Beispiel Beitrag "Re: Mikrokontroller Crash Kurs mit ANSI-C, mit ATMega Register Nutzung" , wo es um die falsche Verwendung von Semikolons in Makros geht. Ich hatte mir zunächst eigentlich nur die Bilder angeschaut, an lediglich zwei Stellen bin ich beim Überfliegen am C-Code hängengeblieben und bin direkt in zwei Fettnäpfchen gestolpert.
Christof E. schrieb: > Das mag alt sein Ungarische Notation ist nicht nur alt, sondern war immer ziemlich umstritten. Siehe Wikipedia-Artikel darüber. Selbst Microsoft (die es lange eifrig verfochten haben) mag das inzwischen nicht mehr … Als persönliche Vorliebe mag das OK sein, als generelle Empfehlung eher nicht. Einbuchstabige Variablen können gut und gern die Lesbarkeit vereinfachen, insbesondere, wenn man C99-mäßig in einer for-Schleife den Scope auf die Schleife limitiert:
1 | for (int i = 0; i < limit; i++) |
2 | dosomething(i); |
Vergleiche das mit
1 | for (int Schleifenzaehler = 0; Schleifenzaehler < limit; Schleifenzaehler++) |
2 | dosomething(Schleifenzaehler); |
oder
1 | for (int iSchleifenzaehler = 0; iSchleifenzaehler < iLimit; iSchleifenzaehler++) |
2 | vDosomething(iSchleifenzaehler); |
Was lässt sich schneller erfassen? ;-)
Jörg W. schrieb: > Was lässt sich schneller erfassen? ;-) Eben. Dazu kommt: Ungarische Notation koppelt den Namen an den Typ. Ändert man den Typ, MUSS man auch den Namen ändern -> Redundant. Dann hat man in C ja oftmals Präfixe wegen fehlendem Namespace. Am Ende hat man 90% Präfix und 10% Variablenname.
1 | for (int iSchleifenzaehler = 0; iSchleifenzaehler < iMotorDriver_Limit; iSchleifenzaehler++) |
2 | vMotorDriver_Dosomething(iSchleifenzaehler); |
:
Bearbeitet durch User
Cyblord -. schrieb: > for (int iSchleifenzaehler = 0; iSchleifenzaehler < iMotorDriver_Limit; > iSchleifenzaehler++) Ineinander verschachtelte Schleifen mit iGanzAeussererSchleifenzaehler, iAeussererSchleifenzaehler, iInnererSchleifenzaehler und iGanzInnererSchleifenzaehler werden dann besonders spaßig.
:
Bearbeitet durch Moderator
mh schrieb: > Weißt du was mit precedent gemeint ist? Gab es zu dem Zeitpunkt keine > Sprache, die binary constants hatte, oder gabes noch keine c-Compiler, > die eine derartige Erweiterung hatten? Gute Frage. Borland Pascal hatte damals schon binäre Zahlen und der GCC auch.
Stefan ⛄ F. schrieb: > und der GCC auch Nein, ganz gewiss nicht. Das darf ich ausnahmsweise mal besser wissen. :-)) (Wenn du ins ChangeLog guckst, weißt du, warum. ;-)
:
Bearbeitet durch Moderator
Christof E. schrieb: > Frank M. schrieb: >> Seite 656 aus dem externen Link - zufällig mal hingeblättert: >>
1 | >> // ********************** |
2 | >> uint8_t PseudoRandom(void) |
3 | >> // ********************** |
4 | >> {
|
5 | >> static uint8_t s=0xaa,a=0; |
6 | >> s^=s<<3; //XOR |
7 | >> s^=s>>5; |
8 | >> s^=a++>>2; |
9 | >> }; |
10 | >> Zufallsfund: Auf der suche nach einer Speicherschonenden |
11 | >> Zufallszahlengenerierung (was die Leute sich so ausdenken) |
12 | >> |
>> >> Die Funktion PseudoRandom() ist definiert mit einem Rückgabewert vom >> Typ uint8_t, liefert aber gar nichts zurück. >> > > Ja, das return hat das kopieren nicht überlebt. > [Snip Rechtfertigung, Weinchen nach 23:00 etc.] > > Kann mich aber erinnern, dass ich das ausprobiert hatte. > Ging hervorragend, Ein Paradebeispiel dafür, dass Code, der ganz klar falsch ist, zu "richtigem" (das, was der Autor erwartet) Assembly übersetzt werden /kann/: Es ist nicht unwahrscheinlich, dass der Compiler R24 für s reserviert, und dann ist der erzeugte Code so wie erwartet, denn R24 ist laut ABI auch das return-Register für uint8_t. Aber: Wenn das in anderem Kontext verwendet wird, zum Beispiel mit einer neueren Compilerversion, die besser optimiert und den Code inlinet, dann steht s womöglich nicht mehr in R24. Und Du merkst den Unterschied noch nicht mal, weil der Wert ja "zufällig" sein soll. Es gibt genügend andere Register, deren Wert sich auch "zufällig" (auf für den Anwender nicht unmittelbar nachvollziehbare Weise) ändert. Kommentar zum Generator selbst verkneif ich mir. Und mit genug Alk sieht sogar ne Konstante zufällig aus... SCNR
Beitrag #6413696 wurde von einem Moderator gelöscht.
> #define SET_74165_CLK() (INSHIFT_74165_PORT |= INSHIFT_74165_CLK_BIT); > #define CLR_74165_CLK() (INSHIFT_74165_PORT &= ~INSHIFT_74165_CLK_BIT); > #define SET_74165_SHLD() (INSHIFT_74165_PORT |= INSHIFT_74165_SHLD); > #define CLR_74165_SHLD() (INSHIFT_74165_PORT &= ~INSHIFT_74165_SHLD); > Ja das ist Blödsinn. Semikolon hat da nix verloren. Kein Ahnung wie das da reingefunden hat. Schon korriegiert Unglaublich was man alles nicht sieht. Ein strengerer Compiler ist da doch hilfreich
Beitrag #6413702 wurde von einem Moderator gelöscht.
Christof E. schrieb: > Ein strengerer Compiler ist da doch hilfreich Da hilft kaum ein Compiler. Makros sind halt reine Textersetzungen, daher darf man auf der rechten Seite hinschreiben, was man will. Auch völliger Blödsinn kann dort stehen, solange der Makro halt nie benutzt wird.
1 | #define FOO das ist bullshit hier!
|
2 | #include <stdio.h> |
3 | |
4 | int main(void) |
5 | {
|
6 | printf("Hello world!\n"); |
7 | return 0; |
8 | }
|
Das compiliert völlig ohne Warnungen. Da doppelte Semikola auch nirgends angemahnt werden, merkt man solche Fehler halt sehr spät. Sowas muss man wirklich bereits bei der Eingabe sehen lernen.
Jörg W. schrieb: > In C habe ich das gerade an die WG14 eingereicht Du verbringst Deine Zeit mit dem Kampf gegen — Windmühlen?
Johann L. schrieb: > Jörg W. schrieb: >> In C habe ich das gerade an die WG14 eingereicht > > Du verbringst Deine Zeit mit dem Kampf gegen — Windmühlen? Vielleicht ja nicht, mal sehen. :-)
Beitrag #6413717 wurde von einem Moderator gelöscht.
Beitrag #6413721 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > insbesondere, wenn man C99-mäßig in einer > for-Schleife den Scope auf die Schleife limitiert: > for (int i = 0; i < limit; i++) > dosomething(i); Nur nebenbei interessehalber: Gibt es einen GUTEN Grund, dies so zu tun? Dank im Voraus.
Gegenfrage: gibt es auch nur einen guten Grund, es nicht so zu tun? Oliver
Egon D. schrieb: > Jörg W. schrieb: > >> insbesondere, wenn man C99-mäßig in einer >> for-Schleife den Scope auf die Schleife limitiert: >> for (int i = 0; i < limit; i++) >> dosomething(i); > > Nur nebenbei interessehalber: Gibt es einen *GUTEN* > Grund, dies so zu tun? > > Dank im Voraus. Je begrenzter der Scope der Variablen, desto besser kann optimiert werden. Auch wird der Code übersichtlicher, weil klar ist, die Variable hat nur in der Schleife Gültigkeit und sonst NIRGENDS.
Cyblord -. schrieb: > Auch wird der Code übersichtlicher, weil klar ist, die Variable hat nur > in der Schleife Gültigkeit und sonst NIRGENDS. Der Schuss kann auch nach hinten losgehen - durch unbeabsichtigtes Shadowing:
1 | #include <stdio.h> |
2 | |
3 | int main () |
4 | {
|
5 | int i = 42; |
6 | |
7 | for (int i = 0; i < 3; i++) |
8 | {
|
9 | printf ("%d\n", i); |
10 | }
|
11 | |
12 | printf ("%d\n", i); |
13 | return 0; |
14 | }
|
1 | cc -Wall -Wextra a.c && ./a.out |
2 | 0 |
3 | 1 |
4 | 2 |
5 | 42 |
(Manchmal kommt es vor, dass man den Wert der Schleifenvariablen nach der Schleife braucht. Wenn man da immer reflexartig mit loop-internen Laufvariablen arbeitet, kann man das schon mal übersehen und wundert sich dann, warum i nach der Schleife einen ganz anderen Wert hat)
:
Bearbeitet durch Moderator
Nein. Keinen einzigen, bis auf den genannte Fall, daß man den Wert des Zählers außerhalb der Schleife benötigt. Oliver
Beitrag #6413739 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > mh schrieb: >>> "A proposal to add binary constants was rejected due to lack of >>> precedent and insufficient utility." >> >> Weißt du was mit precedent gemeint ist? Gab es zu dem Zeitpunkt keine >> Sprache, die binary constants hatte, oder gabes noch keine c-Compiler, >> die eine derartige Erweiterung hatten? > > Ich vermute mal, das Standardkommittee kannte keinen C-Compiler, der > sowas damals implementiert hatte (obwohl es davon bestimmt schon welche > gab). Ich hab endlich die Dokumente auf der open-std Seite gefunden. Danke für das Paper! Einfach, klar und direkt (fehlen nur die Referenzen auf Rothfüssige Bücher ;-) ) Weißt du zufällig wo man N2562 - N2564 finden kann? Die Links auf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2567.htm führen bei mir ins Nichts.
Cyblord -. schrieb: > Je begrenzter der Scope der Variablen, desto besser > kann optimiert werden. Okay, danke. Das leuchtet mir ein. > Auch wird der Code übersichtlicher, weil klar ist, > die Variable hat nur in der Schleife Gültigkeit > und sonst NIRGENDS. Hmm.
Oliver S. schrieb: > Nein. Keinen einzigen, bis auf den genannte Fall, > daß man den Wert des Zählers außerhalb der Schleife > benötigt. Bei allem Respekt: Ich habe ausdrücklich nach einem GUTEN Grund, es zu TUN gefragt -- und zwar deshalb, weil ich solchen penetranten Prinzipienreitern wie Dir signalisieren wollte, dass ich an penetranter Prinzipienreiterei nicht interessiert bin. Dir dennoch einen Guten Tag.
Frank M. schrieb: > Der Schuss kann auch nach hinten losgehen - durch unbeabsichtigtes > Shadowing: Dagegen gibt es -Wshadow und Verwandschaft.
Egon D. schrieb: > und zwar deshalb, > weil ich solchen penetranten Prinzipienreitern wie > Dir signalisieren wollte, dass ich an penetranter > Prinzipienreiterei nicht interessiert bin. Dann müsstest du auch Fragen: Welchen GUTEN Grund gibt es nicht einfach ALLE Variablen global zu machen? Die Antwort ist dieselbe.
Frank M. schrieb: > Manchmal kommt es vor, dass man den Wert der > Schleifenvariablen nach der Schleife braucht. > Wenn man da immer reflexartig mit loop-internen > Laufvariablen arbeitet, kann man das schon mal > übersehen und wundert sich dann, warum i nach > der Schleife einen ganz anderen Wert hat Ja, das war der erste Grund meiner Frage. Der zweite Grund ist: Es widerspricht meiner Denkweise. Ich renne ja auch nicht erstmal nach dem Spiralbohrer, den ich für das Loch brauche, um dann, wenn ich wieder an der Bohrmaschine stehe, festzustellen, dass mir auch der Futterschüssel fehlt... Ich definiere VORHER die Menge der Dinge, die ich brauche (Operanden) und beschreibe anschließend die Folge der Operationen -- aber ich rühre in der Regel nicht beides durcheinander. Dafür ist mein Gehirn nicht geschaffen.
Cyblord -. schrieb: > Egon D. schrieb: >> und zwar deshalb, >> weil ich solchen penetranten Prinzipienreitern wie >> Dir signalisieren wollte, dass ich an penetranter >> Prinzipienreiterei nicht interessiert bin. > > Dann müsstest du auch Fragen: Welchen GUTEN Grund > gibt es nicht einfach ALLE Variablen global zu machen? Nein, das muss ich nicht, denn den Grund dafür kenne ich. > Die Antwort ist dieselbe. Nein.
mh schrieb: > Weißt du zufällig wo man N2562 - N2564 finden kann? Die sind zwar offenbar intern bei Koordinator schon mal aufgetaucht (sodass er ihnen eine Dokumentennummer erteilt hat), aber danach noch nicht zur Veröffentlichung - warum auch immer. mh schrieb: > Dagegen gibt es -Wshadow und Verwandschaft. Nur schade, dass das nicht bei -Wall -Wextra enthalten ist.
Egon D. schrieb: > Ich definiere VORHER die Menge der Dinge, die ich brauche (Operanden) > und beschreibe anschließend die Folge der Operationen Spätestens bei C++ kann das schnell Probleme bereiten - weshalb ja dort auch die Möglichkeit, Variablen auch später als nur am Beginn eines Blocks zu definieren, zuerst da war. Wenn du nämlich für ein Objekt zum Anlegen unbedingt Initialwerte brauchst, die du am Anfang des Blocks noch gar nicht hast, dann kannst du das Objekt an dieser Stelle noch nicht erstellen. C99 hat die Möglichkeit, Variablen auch innerhalb des Blocks zu definieren, übernommen, und ich finde, das macht den Code überschaubarer, da man die Definition der Variablen dann nahe an der Verwendung vornehmen kann (jetzt mal unabhängig davon, dass der Scope "nach unten offen" ist).
Jörg W. schrieb: > Definition der Variablen dann nahe an der > Verwendung Das ist einfach grundsätzlich ein guter Stil. Einfach mal am Anfang einer Funktion zwanzig Variablen zu definieren ist C89 Stil und einfach nicht mehr zeitgemäß. Es bringt auch nichts.
Hallo Christof, https://homepages.uni-regensburg.de/~erc24492/C_ProgTests/Bereichs_Ueberlauf.html Das solltest du ebenfalls unbedingt überarbeiten, wird bestimmt auch in deinem .pdf enthalten sein. Das funktioniert alles ohne casten. Wenn man mit unsigned Variablen rechnet, kann man keine negativen Werte erhalten. Sowas hier wird im Arduino Forum jeden Neuling verklickert bis er es verstanden hat. :-) Überlauffehler gibts nicht, solange man die Rechnung/den Vergleich nicht verändert.
1 | void heartbeat (const byte pin, const unsigned long interval) |
2 | {
|
3 | static unsigned long lastMillis = 0; |
4 | static bool state = LOW; |
5 | unsigned long ms = millis(); |
6 | |
7 | if (ms - lastMillis >= interval) |
8 | {
|
9 | lastMillis = ms; |
10 | state = !state; |
11 | digitalWrite(pin, state); |
12 | }
|
13 | }
|
Viele schreiben es auch so.
1 | void heartbeat (const byte pin, const unsigned long interval) |
2 | {
|
3 | static unsigned long lastMillis = 0; |
4 | static bool state = LOW; |
5 | |
6 | if (millis() - lastMillis >= interval) |
7 | {
|
8 | lastMillis += interval; |
9 | state = !state; |
10 | digitalWrite(pin, state); |
11 | }
|
12 | }
|
Kannste leicht abändern, wenn du fertige Methoden nicht magst.
Jörg W. schrieb: > mh schrieb: >> Dagegen gibt es -Wshadow und Verwandschaft. > > Nur schade, dass das nicht bei -Wall -Wextra enthalten ist. Sehe ich auch so, -Wextra würde sich schon dafür anbieten. Shadowing halte ich schon für beachtenswert, denn ich gehe in so einem Fall immer von einem Programmierfehler aus.
Egon D. schrieb: > Ich definiere VORHER die Menge der Dinge, die ich > brauche (Operanden) und beschreibe anschließend die > Folge der Operationen -- aber ich rühre in der Regel > nicht beides durcheinander. Dafür ist mein Gehirn > nicht geschaffen. Dann hast du alle "Operanden" mit undefiniertem Zustand definiert? Oder initialisierst du alles mit 0, auch wenn es keinen logischen Grund für diesen Wert gibt? Jörg W. schrieb: > mh schrieb: >> Weißt du zufällig wo man N2562 - N2564 finden kann? > > Die sind zwar offenbar intern bei Koordinator schon mal aufgetaucht > (sodass er ihnen eine Dokumentennummer erteilt hat), aber danach noch > nicht zur Veröffentlichung - warum auch immer. Schade, ich würd gerne wissen was sich hinter 2564 versteckt. Mal schaun ob ich in nem Monat nochmal nachgucke. > mh schrieb: >> Dagegen gibt es -Wshadow und Verwandschaft. > > Nur schade, dass das nicht bei -Wall -Wextra enthalten ist. Jörg W. schrieb: > mh schrieb: >> Dagegen gibt es -Wshadow und Verwandschaft. > > Nur schade, dass das nicht bei -Wall -Wextra enthalten ist. Da sind so viele Dinge nicht enthalten die sehr praktisch sind (ich hab neben -Wshadow z.B. immer -Wconversion in der langen Liste)
Jörg W. schrieb: > da man die Definition der Variablen dann nahe an der Verwendung > vornehmen kann (jetzt mal unabhängig davon, dass der Scope "nach unten > offen" ist). Zu dem Problem "nach unten offen": Geschweifte Klammern um den Block, innerhalb dessen die Variable leben soll, verhindern diesen "Defekt". Dafür braucht man dann noch nichtmals mehr C99, das ging schon immer ;-) Also:
1 | {
|
2 | int local; |
3 | ...
|
4 | }
|
Aber ehrlich gesagt: Ich mache das auch nicht. So ein eigener Geschweifter-Klammern-Block im losen Raum hängend sieht irgendwie komisch aus.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber ehrlich gesagt: Ich mache das auch nicht. Ich auch nicht. Historische Anekdote: da habe ich mir vor 30 Jahren mal bei einem OS9-Compiler einen Wolf gesucht. Er hat mit der öffnenden geschweiften Klammer den stack space für die Variable eingeräumt - ihn aber mit der schließenden nicht wieder ausgeräumt. Das schaffte er nur, wenn man es wirklich auf Funktionsebene getan hat. Zuweilen nutze ich solche geschachtelten Blöcke innerhalb der case-Teile eines switch: direkt nach dem 'case' darf man keine Variable definieren. (Ich glaube aber, das soll sich in C2x ändern. Zumindest deutet irgendeiner der Nxxxx-Titel auf sowas hin.)
Jörg W. schrieb: > Egon D. schrieb: >> Ich definiere VORHER die Menge der Dinge, die ich >> brauche (Operanden) und beschreibe anschließend >> die Folge der Operationen > > Spätestens bei C++ kann das schnell Probleme bereiten - > weshalb ja dort auch die Möglichkeit, Variablen auch > später als nur am Beginn eines Blocks zu definieren, > zuerst da war. [...] Okay. Dass ich das Argument nicht im einzelnen nach- vollziehen kann, könnte daran liegen, dass ich von C++ keine Ahnung habe. :) Ich glaube Dir das einfach. > C99 hat die Möglichkeit, Variablen auch innerhalb > des Blocks zu definieren, übernommen, In Ordnung: Da viele Leute sowohl C++ als auch reines C verwenden, hat man das Ausdrucksmittel übernommen. Ist mir zugänglich. > und ich finde, das macht den Code überschaubarer, Das sei jedermann zugestanden -- aber das war nicht der Aspekt, um den es mir ging. Mir ging es um die Frage: Mache ich als C-Anfänger (reines C! ohne Plusplus!) etwas nachweislich technisch Nachteiliges, wenn ich diese Schreibweise nicht verwende.
Jörg W. schrieb: > Zuweilen nutze ich solche geschachtelten Blöcke innerhalb der case-Teile > eines switch: direkt nach dem 'case' darf man keine Variable definieren. Da mache ich die geschweiften Klammern fast ausnahmslos. Aber nicht wegen der dann definierbaren Variablen (angenehmer Nebeneffekt), sondern weil sich mein Auge sonst gegen den Bruch der Klammern-Tiefe "wehrt". Also ein rein optischer Effekt. Automatismus: "{" rückt um 4 Blanks ein, "}" wieder um 4 Blanks aus. Bei switch() ohne geschweifte Klammern nach jedem "case" wird diese Hierarchie durchbrochen. Also:
1 | switch (x) |
2 | {
|
3 | case 1: |
4 | {
|
5 | ...
|
6 | break; |
7 | }
|
8 | case 2: |
9 | {
|
10 | ...
|
11 | break; |
12 | }
|
13 | }
|
Ja, ich weiß: Das sind jede Menge überflüssiger Klammern. Aber da bin ich konsequent ;)
:
Bearbeitet durch Moderator
mh schrieb: > Egon D. schrieb: >> Ich definiere VORHER die Menge der Dinge, die ich >> brauche (Operanden) und beschreibe anschließend die >> Folge der Operationen -- aber ich rühre in der Regel >> nicht beides durcheinander. Dafür ist mein Gehirn >> nicht geschaffen. > > Dann hast du alle "Operanden" mit undefiniertem > Zustand definiert? Hmm. Meistens. Ja. Warum fragst Du? > Oder initialisierst du alles mit 0, auch wenn es keinen > logischen Grund für diesen Wert gibt? Nee. Wenn es einen inhaltlich irgendwie sinnvollen Grundzustand gibt, initialisiere ich natürlich. Wenn nicht, dann nicht. Ich achte aber ziemlich streng darauf, dass ich lokalen Variablen erst beschreibe, ehe ich sie lese. Das ist einfach alte Gewohnheit vom Z80-Assembler her...
Egon D. schrieb: > Ich achte aber ziemlich streng darauf, dass ich lokalen > Variablen erst beschreibe, ehe ich sie lese. Das ist > einfach alte Gewohnheit vom Z80-Assembler her... Gewohnheit? Lokale Variablen sind sonst nun mal uninitialisiert und enthalten irgendwelchen Müll. Warum sollte man den lesen wollen?
Egon D. schrieb: > Ich achte aber ziemlich streng darauf, dass ich lokalen > Variablen erst beschreibe, ehe ich sie lese. Das ist > einfach alte Gewohnheit vom Z80-Assembler her... Darauf brauchst du nicht mehr achten, wenn du Variablen erst definierst, wenn du sie auch richtig initialisieren kannst. Dann kann man nicht mehr unbeabsichtigt uninitialisierte Variablen lesen und undefined behavior auslösen. Bis vor ein paar Jahren hatte gcc noch einige Probleme damit korrekt zu erkennen, ob eine Variable initialisiert ist, bevor auf sie zugegriffen wird. Damit wurde die entsprechende Warnung sehr nervig (oder noch ist?)
mh schrieb: > Egon D. schrieb: >> Ich achte aber ziemlich streng darauf, dass ich lokalen >> Variablen erst beschreibe, ehe ich sie lese. Das ist >> einfach alte Gewohnheit vom Z80-Assembler her... > > Darauf brauchst du nicht mehr achten, wenn du Variablen > erst definierst, wenn du sie auch richtig initialisieren > kannst. Dann kann man nicht mehr unbeabsichtigt > uninitialisierte Variablen lesen und undefined behavior > auslösen. Sicher -- aber da ich ohnehin zwanghaft darauf achte, bringt mir diese neue Freiheit keinen Vorteil ;) Ich wollte im übrigen keinen Glaubenskrieg auslösen, sondern wirklich nur die Hintergründe wissen.
mh schrieb: > Bis vor ein paar Jahren hatte gcc noch einige Probleme damit korrekt zu > erkennen, ob eine Variable initialisiert ist, bevor auf sie zugegriffen > wird. Damit wurde die entsprechende Warnung sehr nervig (oder noch ist?) Gerade so etwas:
1 | #include <stdio.h> |
2 | |
3 | int f (int x) |
4 | {
|
5 | int i; |
6 | |
7 | if (x) |
8 | {
|
9 | i = 4; |
10 | }
|
11 | |
12 | printf ("%d\n", x); |
13 | |
14 | if (x) |
15 | {
|
16 | printf ("%d\n", i); // i uninitialized? |
17 | }
|
18 | |
19 | return 0; |
20 | }
|
hat er früher zu Unrecht angemeckert. Da hat er sich gebessert. Aber leider ist gcc in dieser Beziehung auch abgestumpft:
1 | #include <stdio.h> |
2 | |
3 | int f (int x) |
4 | {
|
5 | int i; |
6 | |
7 | if (x) |
8 | {
|
9 | i = 4; |
10 | }
|
11 | |
12 | printf ("%d\n", x); |
13 | |
14 | if (! x) // changed here! |
15 | {
|
16 | printf ("%d\n", i); // i uninitialized? |
17 | }
|
18 | |
19 | return 0; |
20 | }
|
Das meckert gcc nicht mehr an. Okay, ich habs gerade mit gcc 6.3.0 getestet, weil gerade nichts neueres zur Hand.
Beitrag #6413861 wurde von einem Moderator gelöscht.
Beitrag #6413865 wurde von einem Moderator gelöscht.
Beitrag #6413868 wurde von einem Moderator gelöscht.
Beitrag #6413871 wurde vom Autor gelöscht.
Beitrag #6413875 wurde von einem Moderator gelöscht.
Beitrag #6413876 wurde von einem Moderator gelöscht.
Beitrag #6413879 wurde vom Autor gelöscht.
Frank M. schrieb: > Das meckert gcc nicht mehr an. Okay, ich habs gerade mit gcc 6.3.0 > getestet, weil gerade nichts neueres zur Hand. Auf https://godbolt.org/ steht dir ne große Auswahl an Versionen zur Verfügung.
Beitrag #6413881 wurde von einem Moderator gelöscht.
Beitrag #6413887 wurde vom Autor gelöscht.
Beitrag #6413891 wurde vom Autor gelöscht.
Moin, - ist jetzt zwar zu spaet, aber ich hatte so schoen angefangen zu schreiben: Ich sehe nicht den Mehrwert (oder Sinnhaftigkeit) dieses PDFs (und auch der Kurse): - Ein Seminar „Messen mit dem Mikrocontroller“ in Physik waere in zwei Wochen moeglich (z.B. physikalisches Pendel (mit einem Poti am Pendel), TOF-Messung (billige Lichtschranken), Beschleunigung-Bestimmung (man merkt auch, Analysis I und Numerik waren nicht umsonst). Der Student lernt etwas und versteht vielleicht, wie man physikalische Probleme angeht. - Fuer Mikroelektronik ist der Kurs nichts, der ATMega328P ist zwar nett, der Student lernt aber nichts (aktuell ist STM32 mit vernuenftigen Debugging, mehr Ompff von Allem). Du willst die Standardprodukte (Keil, Atmel Studio, Eclipse) nicht benutzen. OK. Was soll der Student mit Deiner Bastelei? Stand der Mikrocontroller-Entwicklung 1995 kennenlernen? Ich sehe wirklich nicht den Einsatzbereich dieses Hochschulkurses. Der Student lernt nichts was er gebrauchen koennen (ausser ein bisschen Arduino spielen). Da erwarte ich von einer Hochschule mehr. Deutlich mehr. >>> Ich hatte gesehen, dass dieser Kurs beendet wird. Das ist gut, denn der 328P ist leider etwas alt. <<< Ich weiterer Punkt ist der sehr entspannte Einsatz von Urheber- und Persoenlichkeitsrechte: Alle Photos selber gemacht, oder? Michelle Feynman gefragt? Bavaria Atelier GmbH gefragt? Zumindest versucht, die Originalquellen Deiner Aussagen zu suchen und zitieren? Studenten muessen eine Erklaerung unterschreiben, welche Teile ihre eigene Leistung sind und was zitiert wurde. Oder die Studenten am Ende gefragt, dass sie zeitlich und raeumlich unbegrenzt veroeffentlicht werden sollen? Ohne Moeglichkeit der Widerrede? Finde ich nicht so gut. Trotz allem, Gruesse Th.
Beitrag #6413917 wurde von einem Moderator gelöscht.
Beitrag #6413929 wurde vom Autor gelöscht.
Beitrag #6413936 wurde von einem Moderator gelöscht.
Beitrag #6413946 wurde von einem Moderator gelöscht.
Beitrag #6413972 wurde von einem Moderator gelöscht.
Beitrag #6414007 wurde von einem Moderator gelöscht.
Christof E. schrieb: > #define CLR_74165_SHLD() (INSHIFT_74165_PORT &= ~INSHIFT_74165_SHLD); >> > > Ja das ist Blödsinn. > Semikolon hat da nix verloren. > Kein Ahnung wie das da reingefunden hat. > Schon korriegiert > Unglaublich was man alles nicht sieht. Ein strengerer Compiler ist da > doch hilfreich ... die Klammer ist bei so einem Makro auch sinnlos, besser do{...}while(0) oder gleich ganz ohne.
:
Bearbeitet durch User
Beitrag #6414014 wurde von einem Moderator gelöscht.
Apollo M. schrieb: > ... die Klammer ist bei so einem Makro auch sinnlos, besser > do{...}while(0) oder gleich ganz ohne. Das stimmt so nicht. CLR_74165_SHLD wird mit einer expression ersetzt, die eine Wert hat. Wenn du das in ein while packst ist es ein statement und hat keinen Wert mehr. (wenn man die Probleme mit dem ; ignoriert)
Beitrag #6414025 wurde von einem Moderator gelöscht.
Beitrag #6414036 wurde von einem Moderator gelöscht.
Beitrag #6414039 wurde von einem Moderator gelöscht.
Beitrag #6414041 wurde von einem Moderator gelöscht.
Beitrag #6414049 wurde vom Autor gelöscht.
Beitrag #6414054 wurde von einem Moderator gelöscht.
Beitrag #6414059 wurde von einem Moderator gelöscht.
Beitrag #6414060 wurde von einem Moderator gelöscht.
Beitrag #6414063 wurde von einem Moderator gelöscht.
Beitrag #6414065 wurde von einem Moderator gelöscht.
Beitrag #6414069 wurde von einem Moderator gelöscht.
Beitrag #6414071 wurde von einem Moderator gelöscht.
Beitrag #6414076 wurde von einem Moderator gelöscht.
Beitrag #6414094 wurde von einem Moderator gelöscht.
Beitrag #6414107 wurde vom Autor gelöscht.
Beitrag #6414116 wurde von einem Moderator gelöscht.
Beitrag #6414120 wurde von einem Moderator gelöscht.
Beitrag #6414126 wurde von einem Moderator gelöscht.
Beitrag #6414133 wurde von einem Moderator gelöscht.
Beitrag #6414155 wurde von einem Moderator gelöscht.
Beitrag #6414165 wurde von einem Moderator gelöscht.
Beitrag #6414194 wurde von einem Moderator gelöscht.
Beitrag #6414318 wurde von einem Moderator gelöscht.
Beitrag #6414330 wurde von einem Moderator gelöscht.
Beitrag #6414358 wurde von einem Moderator gelöscht.
Beitrag #6414364 wurde von einem Moderator gelöscht.
Beitrag #6414377 wurde von einem Moderator gelöscht.
Beitrag #6414420 wurde vom Autor gelöscht.
Beitrag #6414437 wurde von einem Moderator gelöscht.
Beitrag #6414438 wurde vom Autor gelöscht.
Beitrag #6414445 wurde von einem Moderator gelöscht.
Beitrag #6414447 wurde von einem Moderator gelöscht.
Beitrag #6414449 wurde vom Autor gelöscht.
Beitrag #6414451 wurde von einem Moderator gelöscht.
Beitrag #6414454 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten