Die 10 wichtigsten Faustformeln

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

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.

0: Never run a touched system!

6) garbage in - garbage out

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

7) Wenns auf Anhieb klappt .... stimmt was nicht.

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

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

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.

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.

Öfter mal 10 Minuten NOP auf User-Ebene wirkt Wunder!

- Das Pflichtenheft ist ein sich bewegendes Ziel.

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.

Thilo M. schrieb:

> Z. KEIN Alkohol am Rechner

Genau so sehen viele Tastaturen auch aus.

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.

Die wichtigste in der Programmierung wurde noch nicht genannt:

Alle Konstanten sind als variabel zu betrachten.

U = R * I

Ab in's Off......

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.

12. whenever can steal code: do it!

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

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.