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

[Gast (Gast)]

Immer wieder habe ich die ein oder andere Idee, wie ich ein aktuelles 
Problem mit einem Controller (vornehmlich aus der ATmega Serie) loesen 
moechte.

Wenn ich dann aber loslege und in losem Zusammenhang hier ein wenig Code 
schreibe, da ein wenig mit der Hardware bastel und nebenbei dann auch 
noch nach Teilen in der Bucht und im restlichen Internet suche, 
verzettel ich mich immer und nach einer Weile geht mir der Ueberblick 
verloren und ich lasse die Bastelei sein.

Genauso ist es dann beim Programmieren ... Mir faellt immer wieder ein 
neuer Weg zur Loesung ein, aber nach einer Weile steht da so viel Code 
mit so viel Kommentar, das es einem schwindelig wird. Auch hier ist nach 
einer Weile das Project beendet und ich aergere mich ueber mich selbst, 
weil ich wieder einmal z.B. eine Woche "verheizt" habe ohne nachher 
etwas vorweisen zu koennen.

Weil ich hier im Forum schon eine Menge sehr aufwendige und auch 
aufwendig recherchierte Projekte gesehen (und zum Teil auch nachgebaut) 
habe, wuerde mich einmal interessieren, wie Ihr denn so an die Sache 
herangeht, wenn Ihr eine Idee habt.

Besonders wuerde mich interessieren, wie Ihr die Software in schreibt. 
Also wie Ihr da vorgeht, ohne nach einer Weile die Uebersicht zu 
verlieren.

Danke schon einmal.

Gruss vom Gast.

[Frankl (Gast)]

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.

[Karl H. (kbuchegg)]

Das wichtigste ist IMHO eine ziemlich genaue Vorstellung davon zu haben, 
wie sich die Funktionalität in einzelne Funktionsbereiche aufschlüsselt, 
welche Techniken verwendet werden sollen etc.

Wenn man das nicht im Kopf kann, dann muss man sich eben Notizen machen. 
Das ist sowieso eine gute Idee, denn wenn du das Profimässig machen 
willst, musst du deinem Auftraggeber im Vorfeld schon sagen, was das 
Zeugs kosten wird und da musst du dann schon sehr genau wissen, was du 
eigentlich machen willst und wie du es machen wirst, abgeleitet vom 
Pflichtenheft (das eigentlich vom Auftraggeber kommen sollte, aber na 
ja, lassen wir dieses Thema mal)

Wenn einzelne Teilbereiche nicht klar sind, oder man sich nicht im 
Klaren ist, welche Technik gut funktioniert, dann ist ein seperates 
Hilfsprogram immer ein gute Idee. Aufgabe dieses Hilfsprogramms ist es 
spezielle Technikfragen abzuklären. Ein Hilfsprogram für solche Dinge 
ist meistens eine gute Idee, weil man da losgelöst vom eigentlichen 
Problem ein Detail abklären und abklopfen kann bzw. verschiedene 
Alternativen durchprobieren kann und so rauskriegt wo die Stärken und 
Schwächen einer bestimmmten Technik liegen.

[MaWin (Gast)]

> 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.

[Stefan M. (celmascant)]

Ich habe mir auch angewöhnt ein Lastenheft bzw. eine Liste der 
gewünschten Funktionen zu erstellen.
Dann Arbeite ich eine Funtkion nach der anderen ab.
Wenn ich also ein Projekt mit 3 Funktionen habe, programmiere ich 3 
theoretisch weitgehend unabhängige Programme, definiere dabei die 
Schnittstellen und binde jede Funktion als Unterprogramm ein.

Das hat den Vorteil das ich mit ein paar Testfunktionen (und wenn es nur 
eine UART-Ausgabe ist) die einzelnen Funktionen prüfen kann.
So hab ich noch halbwegs übersichtliche Programmteile die ich alle extra 
testen kann.

Und dein Problem, das einem während des Programmierens ein besserer Weg 
einfällt, habe ich auch öfters.
Dann überlege ich, mit welchem Aufwand ich mein bestehendes Programm 
ändern kann und ob es sich überhaupt lohnt, bzw. ob es nötig ist es 
anders zu machen.
So kann ich auch im Nachhinen komplette Funktionen neu schreiben, mit 
den alten Schnittstellen, und im Hauptptogramm die neue Version 
einbinden.

Gruss Stefan

[Vlad T. (vlad_tepesch)]

Um mmal ein wenig Klarheit zu bringen:

Lastenheft kommt normalerweise vom Auftraggeber, da schreibt er rein, 
was er gerne hätte, das ist ne Art Wunschliste.

Das Pflichtenheft kommt vom Dienstleister/Entwickler und und beschreibt, 
was geliefert werden soll und unter welchen Bedingungen es funktioniert.

Irgendwo muss man sich dann halt treffen, so dass beide zufrieden sind.

Letztendlich ist das Pflichtenheft der Arbeitsvertrag.

[Markus K. (markus-)]

Hallo Gast,

Dein Problem kenn ich auch. Wenn Du weißt, dass Du nur eine Woche daran 
arbeiten willst, dann musst Du eben das Projekt so zurechtstutzen, dass 
es in einer Woche fertig ist.

Lösungsmöglichkeiten:
- Fertigen Code/Libs von anderen Leuten verwenden. Auch wenn Du glaubst, 
Du könntest das besser machen oder die externe Hardware besser nutzen - 
es kostet einfach Zeit.
- Fertige Hardware verwenden (Prototypenboards oder dergleichen). Statt 
einem USB-Interface das SMD-Chips braucht was wiederum eine geäzte 
Platine verlangt einfach RS232 nehmen und einen fertigen 
RS232-nach-USB-Umsetzer benutzen.
- Geringere Ansprüche, z.B. Textdisplay statt Grafikdisplay, denn dann 
muss man sich weder um Fonts kümmern noch Bilder malen.
- Besser vorbereiten. Also nicht nur einfach mal das Datenblatt 
querlesen, sondern genau anschauen und Beispielcode auch verstehen.
- Projekt in mehrere Teile aufspalten. Wenn Du einen MP3-Player bauen 
möchtest, dann könntest Du das aufspalten in a) SD-Card lesen schreiben, 
Daten kommen per RS232 b) MP3-Decoder ansteuern, Daten kommen per RS232 
c) USB-Interface testen. Erst danach das Gesamtprojekt in Angriff 
nehmen.

Was die Software angeht: Da hilft meiner Erfahrung nach insbesondere, 
wenn man regelmäßig aufräumt. Am Anfang fehlt einem ja noch der 
Überblick, deswegen wird das Design schlecht sein. Wenn man aber 
regelmäßig lange Funktionen in mehrere kleine aufteilt und 
Variablennamen bessere Namen verpasst ist schon viel gewonnen. Dann noch 
einige quick hacks durch saubere Lösungen ersetzen und gut ist.

[Thomas (Gast)]

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:

...
int main(void)
{
        PortInit();
        SetLED(GREEN_OK, ON);
        SetLED(RED_ERROR, ON);
        while (1)
        {
                ;
        }
        return 0;
}

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

...
while (1)
{
        if (g_u8Timer0Triggered_300ms)
        {
                g_u8Timer0Triggered_300ms = 0;
                SetLED(GREEN_OK, TOGGLE);
        }
}
...

Dann Tasterabfrage:

...
while (1)
{
        if (g_u8Timer0Triggered_300ms)
        {
                g_u8Timer0Triggered_300ms = 0;
                SetLED(GREEN_OK, TOGGLE);
        }
        unsigned char u8KeyStatus = GetKeyStatus();
        if (u8KeyStatus == KEY_PRESSED)
        {
                SetLED(RED_ERROR, TOGGLE);
        }
}
...

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

...
unsigned char u8ServoAngle = 0;
while (1)
{
        if (g_u8Timer0Triggered_300ms)
        {
                g_u8Timer0Triggered_300ms = 0;
                SetLED(GREEN_OK, TOGGLE);
                u8ServoAngle++;
                u8ServoAngle %= MAX_SERVO_ANGLE;
                SetServo(u8ServoAngle);
        }
        unsigned char u8KeyStatus = GetKeyStatus();
        if (u8KeyStatus == KEY_PRESSED)
        {
                SetLED(RED_ERROR, TOGGLE);
        }
}
...

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.

[Uboot- S. (uboot-stocki)]

N'abend,

> verzettel ich mich immer und nach einer Weile geht mir der Ueberblick
> verloren und ich lasse die Bastelei sein.
[...]
> Genauso ist es dann beim Programmieren ... Mir faellt immer wieder ein
> neuer Weg zur Loesung ein, aber nach einer Weile steht da so viel Code
> mit so viel Kommentar, das es einem schwindelig wird. Auch hier ist nach
> einer Weile das Project beendet und ich aergere mich ueber mich selbst,
> weil ich wieder einmal z.B. eine Woche "verheizt" habe ohne nachher
> etwas vorweisen zu koennen.

Ist bei mir genauso.

Meine Strategien:

Ich habe den Luxus ein eigens "Bastelzimmer" zu haben. Wenn mal nix 
geht, dann geht eben nix. Es kommt öfters vor, dass mein Projekt mal 2 
Wochen liegen bleibt. Der Vorteil des eigenen Zimmers: Ich kann alles 
liegen lassen und mache nach 2 Wochen genau da weiter wo ich aufgehört 
habe.

Wenn mir während des HW-Basteln was neues, besseres etc. einfällt, dann 
schreibe ich es mir auf und lege den Zettel für die Version 2 auf die 
Seite...

Viel schlimmer ist es beim Programmieren. Mir fallen ständig Wege ein, 
wie man das noch besser/kürzer/schöner machen könnte -> aufschreiben und 
zur Seite legen.

Wenn dann mein Gerät fertig ist, wird es erstmal "produktiv" benutzt. 
Dabei fallen dann die Unzulänglichkeiten zum Beispiel bei der Usability 
auf. Na? was passiert wohl -> aufschreiben und zur Seite legen.

Auf diese Art sind schon entstanden:

- Uboot-X-Ruder-Steurung
- Pressluft-Steuerung für UBoot
- Wecker
- Rolladensteuerung
- Bewässerungscomputer

Wenn ich dann Zeit und Lust habe wird die Version 2 gebaut. Im Moment 
plane ich welche Features der Bewässerungscomputer V2 haben soll - Nach 
der Gartensaison gehts los ...

Parallel plane ich eine Wetterstation ...

Gruß

Andreas

[Michael U. (amiga)]

Hallo,

ich schließe mich da mal (als Hobbyprogrammierer) Thomas (Gast) an.

Komponenten bekommen an die Hardware gebundene einzelen Dateien, in 
Assembler als .inc, in C eben als .h und .c
Die lege ich nacheienander an bzw. kopiere sie aus anderen Projekten 
rein.

Erste Handlung ist bei mir immer den AVR auf ein Steckbrett, ISP fertig 
machen, Quarz ran, wenn nötig und Programmer ran, ob er sich meldet.
Fuses für Takt gleich gesetzt und erstmal als ok abgehakt.

Dann erstmal einen Debug-UART rauf, als Hard- oder Softuart, je nach 
AVR.
Der enthält nur Senderoutinen für send_byte, send_byte_hex, 
send_byte_bin und läuft meist mit 38400. Daran ein RS232 oder 
FTDI-Adapter (liegen Steckbrett fertig rum). UART testen und dann kann 
es losgehen.

Mein momentanes Projekt ist genau in diesem Zustand:
Empfänger-IC SI4735 soll rauf, ist auch schonmal getestet am PC mir der 
Demosoftware.

Jetzt erstmal das Pollin-Display mit Touchscreen an den AVR gehangen, im 
Forum etwas Code-Anleihe gemacht und an den Mega16 hier angepasst, 
meldet sich.
Die Display-Routinen passten nicht in meinen privaten Standard, also .h 
Datei angepasst, Kleinigkeiten in den Funktionen verändert.
Das hat jetzt erstmal die nötigsten Funktionen und spielt.
meist werfe ich auch rigoros alle Funktionen raus, die ich vermutlich 
nicht brauche. Kann ich hinterher wieder reinkopieren. ;-)
Das verschafft mir aber das nötige Verständnis für den übernommenen Code 
und zeigt mir rechtzeitig Abhängigkeiten oder auch Fehler.

Ich benutze selten fertige Bibliotheken (LCD, UART usw.), ich will 
möglichst genau wissen, was da passiert und es macht mir mehr Spaß, 
selber zu schreiben.

Es ist Hobby, also Zeitvertreib weil es mir Spaß macht.
Da kann man sich durchaus ein anderes Herangehen zusammenbasteln als im 
Beruf.

Wichtig ist, was Thomas schon schrieb: der Kram muß sauber gekapselt 
sein,
Meine "Bibliotheken" sind schnell austauschbar, Grundfunktionen sind 
einheitlich. Ein LCD muß erstmal einzelne Zeichen und Text aus Ram und 
Flash ausgeben können und die Zeile/Spalte ansteuern können.

Dann ist es schon beim Test egal, wenn ich mich entscheide, statt des 
2x16 44780 Displays doch ein Grafikdisplay mit T6369C zu nehmen, die 
Anzeigen gehen ohne sonstige Änderungen trotzdem erstmal.

Gruß aus Berlin
Michael

[Simon K. (simon)]

Thomas schrieb:
> 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.

Bestätige ich! Dass man ab und zu sieht, dass es anders besser geht ist 
eigentlich unumgänglich und, wie gesagt, sollte man dann abwägen ob es 
sich lohnt. Man kann auch mal einen Tag ne Rework Phase einlegen, wo man 
den Code überarbeitet, vereinfacht, aussondiert, überflüssige Variablen 
eliminiert.

Aber stimmt, habe letztens Code zum einlesen eines PPM Signals und 
Erkennung, wann das Signal verloren wurde, bzw. wieder da ist 3 mal neu 
geschrieben. Beim letzten mal hat es mit Testen und debuggen fast nur 
noch ein, zwei Stunden gedauert. Die erste vermurkste Version zog sich 
da schon länger hin ;)

[Simon K. (simon)]

Uboot- Stocki schrieb:
> Viel schlimmer ist es beim Programmieren. Mir fallen ständig Wege ein,
> wie man das noch besser/kürzer/schöner machen könnte -> aufschreiben und
> zur Seite legen.
Ich benutze Eclipse, der hat einen TODO-Parser. Den benutze ich sehr 
oft. Das heißt, man schreibt in den Code innerhalb eines Kommentars zum 
Beispiel

/* TODO: Schleife muss noch optimiert werden */

Und dann taucht das in einer Liste auf. Dann kann man darauf 
Doppelklicken und kommt direkt an die Stelle. Das ist ziemlich 
praktisch, da man da nicht beim Fluss des Programmierens unterbrochen 
wird. Weil genau dann kommen einem ja die besten Ideen. Ich hab mir 
angewöhnt, die Idee sofort niederzuschreiben. Ansonsten vergisst man es 
und schreibt es später u.U. auch nicht mehr auf.

[Gunb (Gast)]

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.

[Andi (Gast)]

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.

[Christian H. (netzwanze)]

Wichtig ist vor allem, sich nicht zu verzetteln. Immer nur an einer 
Stelle des Programms arbeiten. Immer nur in kleinen Schritten vorgehen.

Teile das Programm in mehrere Blöcke/Dateien auf. Solch eine Datei läßt 
sich auch einzeln testen. Wenn sie fertig ist, zur Seite damit.

Ich arbeite mich gerne langsam von den IO-nahen zu den IO-fernen 
Funktionen durch. Viel kommentieren (Verhältnis Kommentar:Code > 2:1).

Falls mir auffällt, dass irgendeine Funktion, an der ich gerade nicht 
bin, besser zu machen ist, aber funktioniert, kommentiere ich die Region 
(siehe Simon K.) und hebe sie mir für später auf.

Vorerst gehe ich immer nach dem Motto "never touch a running code" vor. 
Verbesserungen sind später noch in einer neuen Version drin 
(Versionsverwaltung ist Pflicht!).

Was ich mir aus meinem Studium (Eiffen und extream programming) 
mitgenommen habe, sind Vor-, Zwischen- und Nachbedingungen sowie 
automatische Tests.
Das sind per #if/#define auskommentierbare Programmteile, die die 
aktuellen Zustände mit einem Sollwert vergleicht. Ich weiß ja, was eine 
Funktion als Eingabewerte(-bereiche) bekommen darf und was rauskommen 
soll. Sowas kann man auch überprüfen. Im Fehlerfall gibt es eine Meldung 
per RS232 (benötigt nur einen Pin plus Masse; das wird bereits bei der 
Prozessorauswahl berücksichtigt).

Wenn man eine Funktion verbessert werden muss, kann ich so sehr schnell 
sehen, wo etwas nicht stimmt.

Am besten keine Seiteneffekte verwenden. Ein Funktionsergebnis wird 
niemals in eine globale Variable geschrieben (außer es geht wirklich 
nicht anders). Eine Funktion, wie auch eine Codedatei ist als Black-Box 
zu sehen. Was drin steckt, ist egal. Es ist nur wichtig, dass genau das 
raus kommt, was ich erwarte/zulase.

Das war's ersmal. Später eventuell mehr.

[Jan (Gast)]

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.

[Gast (Gast)]

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.

[Winfried (Gast)]

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.

[chris (Gast)]

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.

[Chris389 (Gast)]

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 ?

[Winfried (Gast)]

...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 ;-)

[Michael U. (amiga)]

Hallo,

Winfried schrieb:
> ...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.
Da kann ich nur zustimmen. Lochraster ist deshalb bei mir da immernoch 
angesagt.
Kann ich schnell ändern, wenn es Probleme gibt und hält trotzdem 
zusammen. ;-)

> 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.
Auch da geht es mir nicht anders. Um(neu)bauen kann man dann immernoch, 
wenn nicht, auch gut. Man hat aber erstmal was.
>
> Ich möchte nicht wissen, wieviele halbfertige Projekte jeder in der Ecke
> rumliegen hat. Ich auch ;-)

Ja........ Bei manche Sachen ist aber bei mir auch der Weg das Ziel.
Da liegt eine Lochrasterplatine mit einem AVR und dem C64-SID rum.
Nur, weil es mal eine Diskussion gab, ob man den 6502 mit einem ATMega 
emulieren kann. Jetzt weiß ich: man kann, auch Zyklen-genau (naja, fast 
;)).
Nun spielt der SID dort einen Titel aus einem alten Game fehlerfrei. 
Allerdings brauch ich garkeinen SID-Player.....

Gruß aus Berlin
Michael