Wie fangt Ihr an, ein Project auf dem Controller umzusetzen ?

Doku ist alles z.B Pflichtenheft oder auch Neudeutsch Spec.
Aufzählen der W's. Blockschaltbild u.s.w. Solche Hilfen leben mit dem 
Projekt.

> Wie fangt Ihr an, ein Project auf dem Controller umzusetzen ?

Na, abgesehen von Kinderkacke ist es erst mal notwendig, die 
physikalischen Gegebenheiten zusammenzusammeln, unter denen das Projekt 
funktionieren soll. Welche Kenndaten haben die Sensoren, welche Aktoren 
braucht man, welche Algorithmen führen zur Lösung. Hat man alle 
Informationen zusammen, probiert man aus, ob die einzelnen Dinge 
funktionieren wie versprochen, man realisiert also kleine 
Funktionsblöcke die man testen kann. Erst zu Schluss, nach Auswahl der 
Plattform, wirft man alles zusammen.

> vornehmlich aus der ATmega Serie loesen moechte.

Wer mit so einem "möchten" beginnt, hat ein gewaltiges Problem mit der 
Organisation. Man wählt natürlich den uC der die Aufgabe zum vermutlich 
niedrigsten Preis löst, wobei der Gesamtpreis zählt, also Beschaffung, 
Entwicklung, nötige Peripherie, Stromquelle und Gehäuse. Ob dazu ein 
ATmega optimal ist, stellt sich erst raus, wenn man weiß, was alles 
notwendig ist.

> Besonders wuerde mich interessieren, wie Ihr die Software in schreibt.

Programmieren können heisst nicht, die 50 Schlüsselworte der 
Programmiersprache auswendig zu konnen die gerade en-vouge ist, sondern 
ob man 300, 30000 oder 3 Mio Quelltextzeilen überblickt. Und ich glaube, 
ja, es hängt von der Anzahl der Zeilen ab, je weniger man braucht, um so 
komplexer können die Programme werden, bevor man den Überblick verliert.

Zum Thema Code-Aufteilung:

Auf uCs mag ich die Bottom-Up-Methode mit frühem Testen und reichlich 
Abstraktion.

Gnadenlos übertriebenes Beispiel: Ein Board, das mit einem Servo eine 
schwarze Platte in die Sonne dreht, die Temperatur der Platte misst und 
im Minutentakt auf externem Datenflash speichert und auf Tastendruck 
über RS232 an den PC sendet. Status-LEDs braucht man immer, einen Taster 
auch, Sonneneinstrahlung koennte man mit einem Fototransistor an der 
Platte messen, für die Temperatur habe ich irgendwo mal den KTY81 
erwaehnt gesehen.

Also zuerst eine Funktion, die die Status-LEDs kapselt, schreiben und 
testen:

1

...

2

int main(void)

3

{

4

        PortInit();

5

        SetLED(GREEN_OK, ON);

6

        SetLED(RED_ERROR, ON);

7

        while (1)

8

        {

9

                ;

10

        }

11

        return 0;

12

}

Danach gleich klären, ob die Timer tun und in main() die LEDs blinken 
lassen:

1

...

2

while (1)

3

{

4

        if (g_u8Timer0Triggered_300ms)

5

        {

6

                g_u8Timer0Triggered_300ms = 0;

7

                SetLED(GREEN_OK, TOGGLE);

8

        }

9

}

10

...

Dann Tasterabfrage:

1

...

2

while (1)

3

{

4

        if (g_u8Timer0Triggered_300ms)

5

        {

6

                g_u8Timer0Triggered_300ms = 0;

7

                SetLED(GREEN_OK, TOGGLE);

8

        }

9

        unsigned char u8KeyStatus = GetKeyStatus();

10

        if (u8KeyStatus == KEY_PRESSED)

11

        {

12

                SetLED(RED_ERROR, TOGGLE);

13

        }

14

}

15

...

Dann die Servo-Ansteuerung einbauen (Servo haengt direkt an einem 
PWM-Ausgang und wird mit passender Frequenz und Tastverhaeltnis 
angesteuert) und testen:

1

...

2

unsigned char u8ServoAngle = 0;

3

while (1)

4

{

5

        if (g_u8Timer0Triggered_300ms)

6

        {

7

                g_u8Timer0Triggered_300ms = 0;

8

                SetLED(GREEN_OK, TOGGLE);

9

                u8ServoAngle++;

10

                u8ServoAngle %= MAX_SERVO_ANGLE;

11

                SetServo(u8ServoAngle);

12

        }

13

        unsigned char u8KeyStatus = GetKeyStatus();

14

        if (u8KeyStatus == KEY_PRESSED)

15

        {

16

                SetLED(RED_ERROR, TOGGLE);

17

        }

18

}

19

...

Danach RS232-Ausgabe testen (z.B. u8ServoAngle ausgeben), ADC testen 
(Poti, Rohwert auf RS232 ausgeben). Jetzt ist es interessant, welche 
Spannungen der Fototransistor liefert. Schaltung aufbauen, messen, evtl. 
ein OPV dazu etc., so dass etwas messbares wie Nacht=1V, Mittagssonne=3V 
herauskommt. Dann gleich den ADC+Fototransistor in einer Funktion mit 
passender Umrechnung kapseln (auch auf RS232 ausgeben). Dann könnte man 
eine Methode überlegen, die Richtung der maximalen Sonneneinstrahlung zu 
bestimmen. Z.B. alle 10 Minuten die Platte ganz herumdrehen und den 
Winkel mit der höchsten Lichtintensität merken. Also in main() alle 10 
Minuten OptimumPlatePosition() aufrufen, die das Drehen, Messen und 
Vergleichen erledigt.

Ziel ist es, dass die aufrufende Funktion nicht wissen muss, was eine 
aufgerufene Funktion intern tut, nur der Rückgabewert ist interessant. 
Dazu ist es wichtig, dass alles ueber definierte Schnittstellen 
(Parameter, Rückgabewerte und Referenzparameter) passiert, unsichtbare 
Seiteneffekte sind extrem schlechter Stil. main() weiss nicht, was genau 
in OptimumPlatePosition() passiert, OptimumPlatePosition() weiß nicht, 
was SetServo() und GetLightIntensity() intern tun, GetLightIntensity() 
weiss nicht, welche Register GetADC() anspricht, usw. Man koennte auch, 
statt in OptimumPlatePosition() SetServo() direkt aufzurufen, eine 
Funktion SetPlateAngle() aufrufen, die ihrerseits SetServoAngle() (oder 
nach einem Hardware-Umbau stattdessen TurnStepperMotor()) aufruft.


Grüße,
Thomas

PS: Keine Angst haben, Code wegzuwerfen und neuzuschreiben. Nach der 
ersten umstaendlichen und unlesbaren Version, in der viel Arbeit steckt, 
hat man immerhin das Problem verstanden, die neue, richtige Lösung geht 
dann schneller von der Hand.

Hallo,

das tolle in unserer Firma ist, dass ich schon seit Jahren versuche das 
Chaos zu reduzieren, indem die Erstellung von Pflichtenheften zur 
Pflicht wird. Bekomme immer wieder zu hören "Da haben wir keine Zeit 
für!", um dann am Ende des Projekts die vermeintlich gesparte Zeit dann 
doch reinstecken zu müssen, weil das Pflichtenheft am Anfang gefehlt 
hat.

Wiederholung folgt. Mache es dann meist für mich persönlich und mit 
Erfolg bei der Umsetzung. Nur traurig, wenn's woanders auf taube Ohren 
stösst.

Also, Pflichtenheft ist Pflicht.

Ich kann da ne Versionsverwaltung für Quellcode auch nur wärmstens 
empfehlen.
Man hat immer Zugriff auf frühere Versionen und kann wenn man mal ne 
neue Funktionalität programmiert hat und es funktioniert nichts mehr 
einfach zurückgehen oder genau nachverfolgen "wo man warum was geändert 
hat".
Im Hinblick auf größere Zusammenarbeit später in Teams ist es sowieso 
sinnvoll sich damit zu befassen.
Insbesondere dir sollte das helfen wenn du den Überblick verliert und 
auch mehr motivieren immer Teilprobleme zu löschen und diese dann 
"einzuchecken".

TortoiseHG für Windows ist echt super einfach und schnell zu handhaben 
und braucht keinen Server oder so arbeitet auch lokal.
http://bitbucket.org/tortoisehg/stable/wiki/Home

Für private Projekte schreibe ich mir einfach in einer Textdatei auf was 
so etwa alles rein soll, dann werden die einzelnen Teilkomponenten 
einzeln als Prototyp gebaut und ausprobiert bis alles klappt und dann 
schrittweise zusammengefügt. Das praktisch ist wenn man so eine 
funktionierende Teilkomponente hat kann man die auch recht einfach 
später in anderen Projekten weiterverwenden.
Wenn es schön werden soll und/oder für ne Freund ist kommt uU später ne 
Platine, sonst funktioniert Lockraster auch immer sehr gut.

Vielleicht ist Entwicklung auch nicht das richtige für Dich. Es könnte 
sein, dass Du dafür einfach nicht geboren wurdest.

Eventuell liegt Deine Stärke in der Ideenfindung und nicht in der 
Umsetzung.

Man sollte immer das machen, was man am besten kann.

Hallo vom Threadopener.
Da bin ich ja erst einmal froh, das ich als Hobbybastler nicht allein 
mit meinem Problem dastehe ...

@MaWin
Ich gebe Dir vollkommen recht, das dieses "moechte" mich schon oft in 
die falsche Richtung gelotst hat.
Allerdings mache ich die Mikrocontroller-Bastelei nur als Hobby und da 
kann ich mir leider nicht den Luxus leisten, Entwicklungswerkzeuge fuer 
eine Bandbreite an Controllern zuzulegen.

Deiner Definition von "programmieren koennen" stimme iich voll zu.
Meine Erfahrung im Programmieren waechst derzeit noch mit jedem Projekt 
und die Anzahl der Codezeilen wird immer mehr zu meinem Problem. Meist 
fange ich an und die Probleme sind mit z. B. 30 Zeilen Code geloest. Ein 
Teilproblem weiter kommt mir eine Idee, wie ich das Teilproblem von 
vorhin anders besser loesen kann. Dann wird aus 30 Zeilen eine Loesung 
mit 10 Zeilen.
Ein paar Tage spaeter dann beim Test kommt es zu einem Problem / 
Falscher Funktion / ... und genau dann verliere ich den Ueberblick wegen 
der vielen Optimierungen.

@Thomas (Gast)
Genau so wie Du mit dem Servo habe ich mein letztes Projekt auch 
versucht auf die Beine zu stellen.
Es sollten Temperatur, Drehzahl, Spannung des Empfaengerakku und 
Lenkwinkel (Aus der Lenkservostellung) eines 1:5 R/C Car mit einem 
RFM-12 Modul uebertragen werden.

Nach dem Test der einfachen Funktionen (Ausgabe auf RS 232, statt auf 
RFM 12) klappte dann nach dem Einbinden der RFM 12 Programmteile nix 
mehr.

Wenn man dann eine Woche oder mehr kaempft und keine Loesung findet, 
dann frustet das schon.

@alle
Danke fuer die vielen nuetzlichen Tipps und Hinweise. Besonders wichtig 
scheint es danach zu sein, das man sich vor dem Arbeiten erst einmal 
nacheinander Aufschreibt, was man machen will.
Das habe ich bisher nie gemacht, sondern es wurde immer gleich 
"Hardware" und Software geschaffen.

Vielen Dank bis hierher von Einem, der nun sicher oefter mal ein 
verwertbares Projekt hinbekommt.

Es gibt ja auch einige Hilfsmittel, um die Struktur und das Design einer 
Software zu planen und später auch besser zu überblicken. Das einfachste 
Hilfsmittel wäre der Programmablaufplan:

http://de.wikipedia.org/wiki/Programmablaufplan

oder für strukturierte Programmierung:
http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm

Für Softwaredesign gibt es je nach Paradigma (strukturiert, 
objektorientiert, modulbasiert ...) genügend Fachliteratur, wo man sich 
einlesen kann.

Meine Erfahrung ist: Viel zu oft wird einfach drauf losprogrammiert, 
anstatt erstmal mit solchen Werkzeugen eine vernünftige Struktur zu 
finden. Das ist wie Haus bauen ohne Architekt und Bauplan. Das geht bei 
kleinen überschaubaren Projekten noch gut, führt aber oft auch zu Code, 
der an vielen Stellen so wirkt wie: "Ups, da hab ich gar nicht dran 
gedacht, muss ich jetzt irgendwie notdürftig zurechtflicken."

Was ich auch ganz wichtig finde: Man muss eine geistige Fähigkeit 
entwickeln, seine Handlungsimpulse erstmal wahrzunehmen, um dann genau 
zu schauen, welchen Impulsen man wirklich nachgeht. Das erfordert auch 
Disziplin. Man muss nicht jede Optimierung sofort machen, nicht jedes 
Feature, was einem einfällt sofort einbauen. Aber genau hier liegt das 
Problem, manche haben keinerlei Kontrolle über ihre Impulse, müssen 
alles sofort umsetzen. Und das führt zum typischen "verzetteln".

Wenn ein Projekt schon ziemlich fertig ist, sage ich irgendwann: "Ab 
jetzt kommen keine neuen Features mehr rein, nur noch Fehlersuche und 
Stabilisierung." Man kann das ja auch aus größeren Projekten wie Debian, 
wo irgendwann ein Freeze gemacht wird. Das ist wirklich manchmal schwer, 
sich diese Selbstdisziplin aufzuerlegen, keinerlei neue Features mehr 
einzufügen, sondern nur noch dafür zu sorgen, dass der Code sich 
stabilisiert.

Übrigens: Im Schreiben von Software spiegelt sich sehr viel der 
Charakter desjenigen wieder, der sie schreibt. Da kann man sich wirklich 
gut kennenlernen. Mit dem, was einem wichtig ist und was auch die 
eigenen Schwachpunkte sind. Man kann schon sagen: Zeig mir deine 
Software und ich sag dir, wer du bist.

Was ich hier vielleicht noch dazufügen möchte,
bei einem Projekt mache ich mir 3 Listen,
eine Featur list, ähnlich Pflichtenheft, nur als Liste.
Dann eine nice to have feature list und eine HW-Liste, wo pins, externe
HW und so drauf sind.
Darauf basierend entscheide ich dann den Controller usw. inkl 
Programmierung.
Die nice to have featurelist wird dann noch priorisiert, und wenn es 
einfach
zu programmieren ist, dann kommen auch die Teile in die Programmierung 
rein.
In der Programmierung werden dann noch die später zu optimierenden oder 
zu
vervollständigen Teile mit TODO sowie eine Zeile Kurzbeschreibung 
gekennzeichnet, sodaß ein Grep die ganzen TODO´s rausholen kann.
Weiters werden auch Teile, welche fehlerhaft, nur Ansatzweise, oder auch
nur als Dummy-Funktion implementiert sind, mit einem XXX gekennzeichnet,
ähnlich wie die TODO.
Dies ist ganz nützlich, um schnell ein Gesamtwerk zu haben, wo nicht 
wichtige
Sachen oder eine nicht volle Implementierung nicht erforderlich ist, und 
dann
ev. vor Fertigstellung dann nochmals das Pflichtenheft sowie die 
Featurlisten
nochmals durchgesehen werden, um dann ev. noch Änderungen reinzumachen, 
oder
ev um eventuelle Denkfehler auszuräumen. Diese XXX Stellen müssten dann 
prioritisiert eliminiert werden, vor den TODO. Weiters gibt es noch ein
HINT marker, welche auf eventuelle Nebeneffekte oder auf Sachen die 
aufzupassen sind hinweist, oder auch nur auf Sachen, welche das nächste 
Mal
besser zu machen wären oder so.

Das Thema interessiert mich auch, mal ein wenig drüber nachgedacht komme 
ich zu folgender Methode:

- Zunächst wird eine Art Bedienungsanleitung geschrieben. Dabei entsteht 
auch die Information, welche Schnittstellen, also Ein- und 
Ausgabeelemente benötigt werden.

- Anhand dieser werden Ein-und Ausgabeelemente der Hardware festgelegt 
und die Hardware designed. Je nach Größenordnung kann man das ganze dann 
eventuell zunächst modular oder auf dem Steckbrett aufbauen.

- Jede Schnittstelle bekommt eine Funktion, es entstehen zunächst nur 
die Funktionsnamen, Über- und Rückgabewerte sowie eine Beschreibung

- Umsetzung in möglichst kompaktem Pseudocode, weitere Abstraktion durch 
Auslagern von weiterverarbeitenden Teilen in Funktionen, wiederum nur 
Name, Übergabe- und Rückgabewerte sowie Beschreibung

Es bleibt ein einfacher Pseudocode stehen, der das Zusammenspiel der 
Funktionen beschreibt.

- Umsetzung der Funktionen, angefangen bei den Hardwarenahen, in ein 
Programm, Tests, wenn Zufrieden keine Änderungen mehr.

- Nebenbei: Todo-Listen führen über neue Featureideen, mögliche bessere 
programmiertechnische Umsetzung u.s.w.

---

Wenn das Gerät nun wie in der "Bedienungsanleitung" angegeben 
funktioniert die nächste Version unter Berücksichtigung der gemachten 
Todo-Listen beginnen.


Passt das so ? Weitere Anregungen ? Standardisierte Diagramme, die einen 
dabei unterstützen ? Hilfsoftware-Vorschläge ?

...und bei aller Strukturierung der Arbeit auch immer noch dran denken, 
dass es Spaß machen soll. Bei großen Projekten z.B. motiviert 
unglaublich, wenn schonmal ein Einfachst-Prototype irgendwas tut. 
Anstatt erstmal 2 Monate nur Planung und Design zu machen. Auch 
sogenannte "Meilensteine" festzulegen, verschafft einem irgendwie ein 
gutes Gefühl, weiter zu kommen.

Bescheiden zu werden, scheint mir auch eine Tugend. Viele haben 
tausenden Einfälle und verschätzen sich gnadenlos, wie viel Arbeit das 
alles bedeutet. Dann lieber erstmal die Minimalvariante fertig bekommen, 
als die eierlegende Wollmilchsau im ersten Anlauf machen zu wollen.

Ich möchte nicht wissen, wieviele halbfertige Projekte jeder in der Ecke 
rumliegen hat. Ich auch ;-)