Guten Abend, mich würde es mal interessieren, was die 10 wichtigsten Faustformeln aus dem Bereich der Mikrocontroller sind, die man im Alltag beim Entwickeln der Hard- und Software ständig benötigt (aus technischer Sicht) ? 0. 1. 2. 3. 4. 5. 6. 7. 8. 9.
Hello, ich fang mal an... 1. Die bereitschaft zu haben sich ausgibig mit den jeweiligem Datenblatt auseinander zusetzen. Gruss
2) Alles an delay, was länger als ein paar µs ist, ist eine sichere Bank, dass es irgendwann zu Problemen kommen wird.
3) In einer ISR macht man keine Ausgabe auf UART oder LCD Eventuell ein einzelnes Zeichen aber auf keinen Fall Strings
MobyDick schrieb: > mich würde es mal interessieren, was die 10 Wichtigsten-Faustformeln aus > dem Bereich der Mikrocontroller sind, die man im Alltag beim Entwickeln > der Hard- und Software ständig benötigt (aus technischer Sicht) ? > > 0. Das Datenblatt. > 1. Gute Kenntnisse in der verwendeten Programmiersprache, am besten auch ein Buch dafür. > 2. Wissen, was man machen will. > 3. Keep it simple, stupid an short. > 4. Optimiert wird erst ganz zum Schluss. > 5. Der Fehler steckt im Detail. > 6. Den Fehler immer erst bei sich selbst suchen. > 7. Für die banalen Fehler sucht man am längsten. > 8. Glückssteigernde Mittel sind gut gegen Frust (z.B. Schokolade). > 9. Mit guter Musik arbeitet es sich besser. :-)
4) Wenn der µC nicht das macht, was du willst, dann ist nicht der µC defekt, sondern du hast deine Wünsche in Form des Programmes falsch formuliert. Der µC bzw. der Compiler hat immer recht. Und selbst wenn tatsächlich der Tausend-Gulden-Schuss eintritt, das der Compiler nicht recht hat, hilft es dir nichts darüber zu lametieren.
5) Halbstarken-Sprüche beeindrucken weder Compiler noch µC. Wissen und Können hingegen tun es.
4. Compiler sind wie Franzosen, kaum spricht man ihre Sprache nicht perfekt, schnautzen Sie einen an.
7) Programmieren wäre so schön, wenn es keinen quengelnden Kunden gäbe
8) Wer in der Elektronik nicht an Wunder glaubt, ist ein hoffnungsloser Illusionist.
Binsenweisheit Erfahrungen sind das unbestimmte Zeitintgral über die eigenen Fehlschläge + Integrationskonstante C. C= die Erfahrungen der Anderen. C ist manchmal mehr wert.
11 1/2. Wenn gcc merkwürdige Fehlermeldungen oder Warnungen wirft, den Code kurz mit Dummy-Funktionen versehen und in LLVM compilieren. Clang bietet um den Faktor 100 besser aufbereitete Fehlermeldungen (http://clang.llvm.org/diagnostics.html).
Mit Formeln kommt man nicht weit. Es gibt fürs Programmieren keine Superformel und alles gelingt. Aber es gibt Schritte, die das Programmieren einfacher und vor allem zuverlässiger machen: 0. PC ausschalten 1. Pflichtenheft erstellen 2. überlegen 3. Ablaufplan erstellen 4. Ablaufplan überprüfen, ob logisch korrekt 5. dann erst PC wieder anschalten und PAP in Code umsetzen 6. Keine kryptischen Hexwerte im Programm 7. Laß den Compiler Konstanten ausrechnen, der kann das besser als Du. 8. Daten vom Interrupt im Main immer volatile casten 9. In Unterfunktionen aufteilen, es gibt keine untere Grenze dafür 10. nichts vermuten oder hoffen, sondern nachschlagen und prüfen (worst case) Peter
sei clever - aber nicht zu clever. Dein Compiler ist viel smarter als du denkst (auch wenn einige das bestreiten) Zuerst machs richtig, und dann erst machs schnell. Du hast nichts von einem Programm, welches alles rasend schnell berechnet - wenn alles was es berechnet falsch ist.
Hallo, um Karl heinz Buchegger von 23.12.2010 16:53 noch etwas zu verkürzen: Ein µC macht nicht immer, was er soll. Er macht aber IMMER, was man ihm sagt... Gruß aus Berlin Michael
Auch wenn es schon inhaltlich kam. 1. Irren ist menschlich. 2. Der Compiler irrt nie. und §1 Der Compiler hat immer recht. §2 Sollte der Compiler mal nicht recht haben, so tritt automatisch §1 in kraft.
> Ein µC macht nicht immer, was er soll. > Er macht aber IMMER, was man ihm sagt... Es sei denn der Hersteller hats verbockt und es gibt ein ellenlanges Errata Blättchen. Dann macht er manchmal auch einfach was er will :-)
4. Kaum macht man's richtig, geht's. 5. Wenn's einfach wär' könnt's ja jeder.
pöse pöse schrieb: > Es sei denn der Hersteller hats verbockt und es gibt ein ellenlanges > > Errata Blättchen. > > Dann macht er manchmal auch einfach was er will :-) Trotzdem sitzt das größte Problem meistens vor dem Computer und nicht in der Schaltung. mfg.
> 3. >Keep it simple, stupid an short. Wofür das ISDN-Ding Beitrag "ISDN am AVR (Mega8)" geradezu ein Paradebeispiel ist.
6. Geräte, die beim Betrieb Geräusche machen sind Fehlkonstruktionen (soweit das Geräuscherzeugen nicht ihr eigentlicher Zweck ist).
Karl heinz Buchegger schrieb: > 7) Programmieren wäre so schön, wenn es keinen quengelnden Kunden > > gäbe Wer seinem Kunden erzählt, was das Ding noch alles könnte, ist selber schuld. mfg.
X. so schnell wie nötig, so langsam wie möglich Y. das Problem sitzt vor dem Monitor Z. KEIN Alkohol am Rechner
Karl heinz Buchegger schrieb: > In einer ISR macht man keine Ausgabe auf UART oder LCD > Eventuell ein einzelnes Zeichen aber auf keinen Fall Strings warum das?
Weil so eine Ausgabe dauert und du den ISR aufhalten tust. Zum Schluss bewegt man sich nur noch im ISR und nicht mehr im Hauptprogramm...
Dokumentiere gut! Präventiver Code: Wenn dir an irgendeiner Stelle bewusst wird, dass bestimmte Umstände zu Katastrophen führen würden, sichere es so ab, dass diese Fehler abgefangen und gemeldet werden. Wenn Software irgendwo Mist macht, ignoriere es nicht, sondern lasse es sofort sichtbar werden. Wenn nicht für den Benutzer, dann zumindest im Logfile. Benutze eine Versionsverwaltung für den Code, so das du immer auf eine bestimmte Release zurückgreifen kannst.
1. Wenn etwas schiefgehen kann, dann geht es schief. 2. Wenn etwas auf verschiedene Arten schiefgehen kann, dann geht es immer auf die Art schief, die am meisten Schaden verursacht. 3. Hat man alle Möglichkeiten ausgeschlossen, bei denen etwas schiefgehen kann, eröffnet sich sofort eine neue Möglichkeit. 4. Die Wahrscheinlichkeit, dass ein bestimmtes Ereignis eintritt, ist umgekehrt proportional zu seiner Erwünschtheit. 5. Früher oder später wird die schlimmstmögliche Verkettung von Umständen eintreten. 6. Wenn etwas zu gut erscheint, um wahr zu sein, ist es das wahrscheinlich auch. 7. Wenn etwas nicht schiefgegangen zu sein scheint, dann wurde der Fehler lediglich noch nicht entdeckt, wodurch alles nur noch schlimmer wird. 8. Geht etwas nicht schief, so tritt sofort Regel 1 in Kraft. (Murphy's law, nach Wikipedia) Ich kenne noch: - Toleranzen addieren sich unabhängig vom Vorzeichen immer zur ungünstigsten Seite. - Das Butterbrot fällt immer auf die bestrichene Seite. Ich hatte noch kein Projekt, bei dem nicht eine gehörige Portion Murphy drin war.
Hc Zimmerer schrieb: > - Das Butterbrot fällt immer auf die bestrichene Seite. Wie erst gestern in Wissen vor 8 bewiesen: Das ist nur aufgrund der genormten Toastbrote-Abmessungen und der durchschnittlichen, mitteleuropaeischen Tischhoehe so!
0. Alle Faustformeln sind, wenn es darauf ankommt, falsch :) Oliver
Hc Zimmerer schrieb: > - Das Butterbrot fällt immer auf die bestrichene Seite. Außer man bindet das Butterbrot auf eine Katzenrücken. Da die Katze immer auf die Füße fällt, ist die Lösung nicht definiert :-) http://www.nichtlustig.de/comics/full/010712.jpg :-)
Karl heinz Buchegger schrieb: > sei clever - aber nicht zu clever. > Dein Compiler ist viel smarter als du denkst (auch wenn einige das > bestreiten) Das bringt uns zu einer weiteren Standard-Regel: "Assumptions are the root of all evil." Darunter gehört auch die Annahme, der Compiler sei nicht smart genug, aber auch die, der Compiler sei smart genug. Es gibt tatsächlich extrem viel Code, wo nicht in einer Doku (von Compiler, Bibliothek oder sonstwas) nachgelesen wurde, wie's richtig geht, sondern man einfach irgendwas angenommen hat, das dann meistens nur zum Teil richtig ist. Ich halte das für eine der größten Fehlerursachen überhaupt in der Programmierung. Thomas Eckmann schrieb: >> Dann macht er manchmal auch einfach was er will :-) > > Trotzdem sitzt das größte Problem meistens vor dem Computer und nicht in > der Schaltung. Das kann korrelieren, wenn die Schaltung im Kopf vor dem Computer entstanden ist ;-) Thomas Eckmann schrieb: > Karl heinz Buchegger schrieb: >> 7) Programmieren wäre so schön, wenn es keinen quengelnden Kunden >> >> gäbe > > Wer seinem Kunden erzählt, was das Ding noch alles könnte, ist selber > schuld. Meistens läuft es doch eher umgekehrt. Der Kunde kommt mit seinen ganzen utopischen Forderungen und akzeptiert nicht, wenn man ihm sagt, daß das Ding das nicht kann. Floh schrieb: > Hc Zimmerer schrieb: >> - Das Butterbrot fällt immer auf die bestrichene Seite. > > Außer man bindet das Butterbrot auf eine Katzenrücken. Da die Katze > immer auf die Füße fällt, ist die Lösung nicht definiert :-) > > http://www.nichtlustig.de/comics/full/010712.jpg > :-) Hoffentlich probiert das nie einer real aus. Wahrscheinlich fällt uns dann der Himmel auf den Kopf, oder es gibt eine Raumfaltung, damit auf beiden Seiten Boden sein kann.
diese Faustregeln sind so gut wie die Vorsaetze fuers neue Jahr vielmehraiszehn...einefaustimauge
Die wichtigste in der Programmierung wurde noch nicht genannt: Alle Konstanten sind als variabel zu betrachten.
- LEDs benötigen Vorwiderstand und können gut mit PWM (Interrupts) programmiert werden - Treiber hinter IC-Baustein - Moore-Automat hängt nuuuur vom inneren Zustand ab - Multimeter und Batterien haben Innenwiderstand
Rolf Magnus schrieb: > Meistens läuft es doch eher umgekehrt. Der Kunde kommt mit seinen ganzen > > utopischen Forderungen und akzeptiert nicht, wenn man ihm sagt, daß das > > Ding das nicht kann. Dem kann man allerdings auch nicht widersprechen. mfg.
11. Wenn man länger als 2 Tage erfolglos einen Programmierfehler in der Firmware sucht, liegt das Problem mit großer Wahrscheinlichkeit in der Hardware.
13. Macht der Vorversuch Mut wird die Entwicklung gut! Mehrere kleine Schritte bringen einen weiter als ein grosser.
14. Müssen zwei Platinen über einen Stecker verbunden werden, dann wird sicher einer falsch gezeichnet. (gespiegelt) 14.a Das garantiert bei jedem Projekt 14.b Auch nach 10 Jahren Berufserfahrung
Noch einer ... Wer die Füsse hochlegen kann, hat Zeit für bessere Ideen.
Eine der wichtigsten: Vertraue keiner Faustformel! Fausformeln beinhalten meistens starke Vereinfachungen. In 99.9% der Fälle sind diese Vereinfachungen zwar zulässig und verändern das Ergebnis nicht gravierend, trotzdem sollte man die Schwächen der genutzten Faustformel kennen. Dazu braucht man dummerweise genau das theoretische Wissen, das einem die Faustformel ersparen möchte.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.