www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Die 10 wichtigsten Faustformeln


Autor: MobyDick (Gast)
Datum:

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

Autor: thisamplifierisloud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0. never touch a runnning system.

Autor: hein blöd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello,

ich fang mal an...

1. Die bereitschaft zu haben sich ausgibig mit den jeweiligem Datenblatt 
auseinander zusetzen.

Gruss

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2) Alles an delay, was länger als ein paar µs ist, ist eine sichere
   Bank, dass es irgendwann zu Problemen kommen wird.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
3) In einer ISR macht man keine Ausgabe auf UART oder LCD
   Eventuell ein einzelnes Zeichen aber auf keinen Fall Strings

Autor: Floh (Gast)
Datum:

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

:-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Harald82 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
thisamplifierisloud schrieb:
> 0. never touch a runnning system.

SUPER! Genau so ist es!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
5) Halbstarken-Sprüche beeindrucken weder Compiler noch µC.
   Wissen und Können hingegen tun es.

Autor: El Jefe (bastihh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4. Compiler sind wie Franzosen, kaum spricht man ihre Sprache nicht 
perfekt, schnautzen Sie einen an.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0: Never run a touched system!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
6) garbage in - garbage out

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
7) Programmieren wäre so schön, wenn es keinen quengelnden Kunden
   gäbe

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
7) Wenns auf Anhieb klappt .... stimmt was nicht.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8) Wer in der Elektronik nicht an Wunder glaubt, ist ein hoffnungsloser 
Illusionist.

Autor: Padex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Binsenweisheit
Erfahrungen sind das unbestimmte Zeitintgral über die
eigenen Fehlschläge  + Integrationskonstante C.

C= die Erfahrungen der Anderen.
C ist manchmal mehr wert.

Autor: Atmi (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: heinzhorst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
KISS - keep it smart and simply.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Michael U. (amiga)
Datum:

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

Autor: Simon (Gast)
Datum:

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

Autor: pöse pöse (Gast)
Datum:

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

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
4. Kaum macht man's richtig, geht's.
5. Wenn's einfach wär' könnt's ja jeder.

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 3.
>Keep it simple, stupid an short.

Wofür das ISDN-Ding Beitrag "ISDN am AVR (Mega8)"
geradezu ein Paradebeispiel ist.

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
6. Geräte, die beim Betrieb Geräusche machen sind Fehlkonstruktionen 
(soweit das Geräuscherzeugen nicht ihr eigentlicher Zweck ist).

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Öfter mal 10 Minuten NOP auf User-Ebene wirkt Wunder!

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X. so schnell wie nötig, so langsam wie möglich
Y. das Problem sitzt vor dem Monitor
Z. KEIN Alkohol am Rechner

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- Das Pflichtenheft ist ein sich bewegendes Ziel.

Autor: Kostia G. (Gast)
Datum:

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

Autor: Gerd (Gast)
Datum:

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

Autor: Winfried (Gast)
Datum:

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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U=R*I !!!

Autor: Hc Zimmerer (mizch)
Datum:

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

Autor: Johnny Voltage (Gast)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. schrieb:

> Z. KEIN Alkohol am Rechner

Genau so sehen viele Tastaturen auch aus.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0. Alle Faustformeln sind, wenn es darauf ankommt, falsch :)

Oliver

Autor: Floh (Gast)
Datum:

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

Autor: Rolf Magnus (rmagnus)
Datum:

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

Autor: hans hoch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
diese Faustregeln sind so gut wie die Vorsaetze fuers neue Jahr

vielmehraiszehn...einefaustimauge

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die wichtigste in der Programmierung wurde noch nicht genannt:

Alle Konstanten sind als variabel zu betrachten.

Autor: mörfi_2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer viel misst, misst viel Mist.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U = R * I

Autor: M. W. (hobbyloet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ab in's Off......

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
work smart, not hard!

Autor: God (Gast)
Datum:

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

Autor: Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

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

Autor: Bitschubser (Gast)
Datum:

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

Autor: Jürgen Franz (unterstrom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
12. whenever can steal code: do it!

Autor: g_a_s_t (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
13. Macht der Vorversuch Mut wird die Entwicklung gut! Mehrere kleine 
Schritte bringen einen weiter als ein grosser.

Autor: Markus Müller (mmvisual)
Datum:

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

Autor: thisamplifierisloud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch einer ...

Wer die Füsse hochlegen kann, hat Zeit für bessere Ideen.

Autor: Kapitän Ahab alias Klaus2m5 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Ladung der Harpune kann nie stark genug sein.

Autor: Captain Subtext (captainsubtext)
Datum:

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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