www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 8-BIT Controllerentwicklungen -> Wie machen das Profis ?


Autor: UBoot-Stocki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen,

mich interessiert wie professionelle Entwickler die Elektronik 
von(Controllergesteuerten) Geräte entwickeln. Ich denke an Geräte wie 
Waschmaschinen, Gefrierschränke, Kaffeemaschinen, DVD-Player etc. Eben 
alles was potentiell von einem 8-Bitter gesteuert wird.

Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit 
Pflichtenheft, Struktogramm und Coding...

Wie oft ändert sich das Design während einer Eintwicklung? Was passiert 
bei Erweiterungen?

Eben wie das so abläuft ....

Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt: 
Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen 
oder ich Erweitere das Gerät um einen weiteren Controller der dann 
Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren 
Controller zu nehmen ...
Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der 
bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit 
kommt mit dem Essen) nicht evtl. völlig falsch war ...

Gruß

Andreas

Autor: Der kleine Tierfreund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch nicht anders, falls so eine allgemeine Frage überhaupt beantwortet 
werden kann. Die Fragen sind die gleichen und das ultimativ perfekte 
Design gibt es nirgendwo, bzw. nur bis zur nächsten Änderung.

Wenn genug Geld/Zeit vorhanden ist werden schon mal mehrere Designs 
beauftragt nur um sich ein Bild zu machen, aber das ist eher die 
Ausnahme.

Equipment Erfahrung und Knowledge sind in einer anderen Dimension, aber 
so weit ich das überblicken kann, kochen alle mit Wasser.

Und Rapid Prototyping nützt wenig da die Designprozesse nicht vom Design 
abhängen sondern von den Prozessen (Firmenstrukturen). Je größer  der 
Laden ist um so aufwändiger wird das drumherum.

Stichworte: Keil, IAR, Hitex, In Circuit Debug, usw

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

Bewertung
0 lesenswert
nicht lesenswert
UBoot-Stocki wrote:

> Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit
> Pflichtenheft, Struktogramm und Coding...

Bei uns geht das so, dass zunächst mal der Kunde in die Mangel genommen 
wird. Was will er genau haben. Das hört sich einfach an, ist aber 
mitunter einer der schwierigsten Punkte im ganzen Projekt: Aus dem 
Kunden seine genauen Vorstellungen rauskitzeln und das ganze so in 
Schriftform giessen, dass er das als Auftrag dann auch unterschreibt. 
Dabei auf all die kleinen Nebenbedingungen nicht vergessen, die einem 
später das Leben schwer machen werden und an die zum jetzigen Zeitpunkt 
keiner denkt (die aber später massiv Geld kosten werden).
Wenn dein Kunde sagt: "Ach, das ist ganz einfach, das geht so ..." oder 
"Das brauchen wir nicht" oder "Das kommt in der Praxis nicht vor", dann 
diese Aussage im Detail unbedingt festhalten bzw. nachbohren. Gerade 
dieses "Das kommt nicht vor" stellt sich im Nachhinein oft als Boomerang 
heraus.

Danach setzt sich ein Entwickler hin und überlegt mal in groben Blöcken, 
wie man die Kundenvorstellungen realisieren kann. Dabei muss er einen 
Überblick bekommen, was an Input notwendig ist und was als Output vom 
Programm rauskommen soll. Er überlegt sich, welches UI dafür adequat 
wäre, wobei er darauf achtet, möglichst vorhandene UI-Elemente 
wiederverwenden zu können. Wenn das gelingt ist es gut, wenn nichts da 
ist, kann man sich überlegen ob man die Aufgabenstellung ein wenig in 
die Richtung treiben kann, so dass irgendwas von der Halde passt. Wenn 
alle Stricke reißen, muß man was Neues erfinden.

Steht das ganze soweit und ist auch der Schritt 'Verarbeitung' in groben 
Zügen klar, dann gehen wir das mit dem Kunden noch mal durch. Zur 
Verarbeitung (also: wie du die Logik aufziehst) wird er nicht viel 
sagen. Erstens vertraut er dir, dass du schon weißt was du tust, 
zweitens ist es für Durchschnittskunden extrem schwer, eine logische 
Abfolge von vielen Kommandos mit seinen Vorstellungen zu vergleichen, 
egal wie du sie ihm präsentierst. Aber zum UI wird er sich äußern und 
das ist gut so. Das vermeidet zum einen, dass er hinterher sagt "Ich hab 
mir das aber ganz anders vorgestellt" zum anderen gibt es dir Hinweise, 
ob du bei der Verarbeitung etwas übersehen hast. Wenn der Kunde zb. auf 
der Output Seite unbedingt noch einen zusätzlichen Wert angezeigt haben 
will, dann hast du was übersehen.

> Wie oft ändert sich das Design während einer Eintwicklung? Was passiert
> bei Erweiterungen?

Im Idealfall ändert sich dann nichts mehr.
Diesen Idealfall hab ich noch nie erlebt :-)

OK. Wenn was rauskommt, dann treffen 2 Welten aufeinander. Hängt 
natürlich auch davon ab, wann diese Erweiterung notwendig wird. Ist es 
noch früh genug im Entwicklungsprozess, dann sind Entwickler 
normalerweise kooperativ, solange das nicht das Gesamtsystem komplett 
umdreht.
Je mehr sich aber die Dead-Line nähert, desto mehr werden Entwickler 
anfangen zu mauern. Erfahrene Entwickler haben längst gelernt, dass es 
tödlich ist, 2 oder 3 Wochen vor Abgabe noch irgendwelche großartigen 
Design-Änderungen zu akzeptieren. Das führt letztendlich immer zu 
versteckten Fehlern in bereits einwandfrei funktionierenden 
Programmteilen, die der Kunde dann dir anlasten wird. In so einem Fall 
gilt die Devise: Die gewünschte Änderung in einen neuen Auftrag 
verchieben, der nach dem laufenden Auftrag abgehandelt wird und erst 
beginnt, wenn das bisherige vom Kunden abgenommen wurde. Sonst wartest 
du nämlich ewig auf dein Geld und Gehälter wollen schliesslich auch 
bezahlt werden.

> Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt:
> Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen
> oder ich Erweitere das Gerät um einen weiteren Controller der dann
> Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren
> Controller zu nehmen ...

In so einem Fall, wird man versuchen, zu retten was zu retten ist ohne 
allzu gravierende Änderungen vorzunehmen. Die Variante, die am wenigsten 
Softwareänderungen verursachen wird, ist es, einen größeren Controller 
zu nehmen, sofern der kompatibel ist.
Ein zusätzlicher Controller bringt eine neue Komponente ins Spiel: Die 
beiden müssen miteinander kommunizieren können. Und das unter allen 
Umständen oder Sonderfällen. Wenn dein System nicht von vorne herein auf 
solche Multitasking Spezialitäten ausgelegt war, dann handelst du dir 
damit einen neuen Sack Flöhe ein, die mit deinem eigentlichen Problem 
(neue Funktionalität) erst mal gar nichts zu tun hat, dein 
Komplettsystem aber trotzdem lahmlegen kann.

> Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der
> bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit
> kommt mit dem Essen) nicht evtl. völlig falsch war ...

Kommt immer drauf an, wie gross der Appetit wird.
Einem Kunden wirst du natürlich nicht jede gewünschte Änderung 
abschlagen. Du musst ihn auch etwas bei Laune halten. Aber grundsätzlich 
lautet die Devise: Sieh zu, dass du zuerst das realisierst, was du 
ursprünglich mit dem Kunden ausgemacht hast. Erweiterungen bzw. 
Änderungen kannst du jetzt schon im Softwaredesign berücksichtigen (also 
etwas Vorarbeit leisten), aber so dass sie der Kunde sieht, wird es erst 
realisiert, wenn der Folgeauftrag da ist.

Grundsätzlich halte ich den Ansatz des 'iterativen Modells' für so 
schlecht nicht. Für gewerbliche Zwecke kann das zwar mächtig ins Auge 
gehen, aber für Privat ist das OK. So sammelt man nämlich dann auch 
Erfahrung, wie man Module aufbaut, so dass der Aufbau nicht vor 
möglicher Felxibilität untergeht, man sich aber auf der anderen Seite 
auch nicht eine Weiterentwicklung mutwillig verbaut. Das ist eine 
Gratwanderung, die mal lernen muss.
Ab und an auch mal den Schritt zurück machen und das Gesamtsystem 
betrachten. Wie könnte man Dinge vereinfachen, wenn man 'in Stein 
gemeisseltes' Urgestein verändert. Für solche Betrachtungen hab ich 
schon oft Testprogramm-Systeme gebaut. Einfach nut um zu sehen, wo mich 
eine Änderung hinführen wird, welche Auswirkungen bestimmte Änderungen 
haben werden, was sich vereinfacht, was komplizierter wird. Auf die Art 
sammelt sich dann ein Fundus an erprobten Methoden an.

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:
> Aus dem
> Kunden seine genauen Vorstellungen rauskitzeln und das ganze so in
> Schriftform giessen, dass er das als Auftrag dann auch unterschreibt.

Und falls Nachfragen entstehen, weil etwas vorher nicht hunderprozentig 
klar war:

SCHRIFTLICH, niemals per Telefon.

"Ja, aber wenn wir das anders umsetzen ist [abuse hier einsetzen] 
möglich, wollen Sie das wirklich?"

Wen hatte ich zwei Wochen später unfreundlich motzend am Telefon? Bzw 
wessen Chef?

Autor: Matthias Nix (vbchaos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dito...

Bei uns (und ich denke eigentlich ueberall) ist das schwierigste, genau 
zu wissen und zu erfahren, was der Kunde genau will.

Die weiteren Schritte sind etwas Kunden-, Betriebs- und Designer 
abhaengig. Mancher Kunde will genau DEN Controller, andere sagen "8 Bit 
passt doch, Hersteller egal". Hat die Firma vielleicht Vertraege mit 
Controller-Herstellern, ist klar, was gewaehlt wird. Hat die Firma 
vielleicht x-Jahre Erfahrung mit einem Controllertyp gesammelt und 
massiv Design- und Coderessourcen angehaeuft, ist auch klar, was gemacht 
wird bzw. wo die Prioritaet sitzt. Manche Peripherie laesst sich anhand 
des Controllers auswaehlen, bei anderen ist es eine reine Kosten- 
und/oder Glaubensfrage. Es bleibt aber vielfach eine einfache Frage der 
vorhandenen Ressourcen, warum irgendwas ganz neu machen, wenn es schon 
fuer einen anderen Controller da ist? Es sei denn natuerlich, der Kunde 
will es so und bezahlt dafuer :)

Wir starten hier normalerweise mit DemoBoards, die auf dem selben 
Controller aufbauen wie das Projekt spaeter dann auch. Es wird zumeist 
eines gewaehlt, dass moeglichst viel der spaeteren Peripherie bereits 
mit dabei hat. Anhand der mitgelieferten Schematics hat der Designer in 
manchen Punkten dann einen Anhaltspunkt, und die Software Leute koennen 
parallel auf dem DemoBoard schon arbeiten.

Spaeter wird das zusammengefuegt. Das erste Design hat meist einige 
Schwachstellen und Kinderkrankheiten. Es dauert manchmal 1-2 Tage, bis 
die Software Leute problemlos ihren Code da reinkriegen. die meisten 
Redesign-Issues kommen dann auch aus der Software-Schmiede, die diverse 
kleine Fehler finden. Zusaetzlich ueberpruefen die Hardware Leute ihr 
Design noch selber, werden sicherlich kleinere Maengel an Footprints und 
Shapes finden (was ihr Ego nicht unerheblich erschuettert :) ).

Das Redesign Spiel geht solange, bis es passt. Gaengig sind eigentlich 2 
oder 3 Versionen, bei groesseren Sachen auch mal 4 oder 5. Sollte man 
aber nicht haeufig machen, kostet nur :)

Autor: Johnny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei uns (und ich denke eigentlich ueberall) ist das schwierigste, genau
> zu wissen und zu erfahren, was der Kunde genau will.

Leider wissen die meisten Kunden selber nicht so genau, was sie 
eigentlich wollen...

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Leider wissen die meisten Kunden selber nicht so genau, was sie
>eigentlich wollen...

Einige Forenbesucher auch nicht...(LED soll blinken...)

Autor: Juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Prototypen wird erstmal ein Kontroller mit relativ viel Speicher 
verwendet, damit es da keine Zeitverluste gibt. Fuer die Grossserie 
(dazu kam es dann aber nicht) wird dann abgespeckt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
UBoot-Stocki wrote:
> Wird da "Rapid Prototyping" angewand oder geht das "klassisch" mit
> Pflichtenheft, Struktogramm und Coding...

Pflichtenheft wäre schön, in der Praxis wirds leider selten richtig 
genutzt.


> Wie oft ändert sich das Design während einer Eintwicklung?

Zu oft.

> Was passiert
> bei Erweiterungen?

Wenn möglich als extra Projekt einstufen, d.h. neuer Auftrag, neue 
Entwicklungszeit.



> Hintergrund: Meine Hobby-Entwicklung steht nun vor dem Wendepunkt:
> Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen
> oder ich Erweitere das Gerät um einen weiteren Controller der dann
> Teilaufgaben übernimmt. Eine weitere Option wäre einen größeren
> Controller zu nehmen ...

Oftmals ist ein altes Projekt so vergurkt, daß eine neue CPU nichts 
bringt. Der Flaschenhals ist nicht die Rechenleistung, sondern der 
Ablauf. Es wird Rechenzeit an falschen Stellen vergeudet.

Ein weitere Controller ist so ziemlich das schlimmste, weil man dann 
erstmal ein zuverlässiges, echtzeitiges, fehlertolerantes 
Kommunikationsprotokoll entwickeln muß.

Die effektivste Methode ist, nochmal von vorne anzufangen, d.h. ein 
neuer Programmablaufplan.
Klingt erstmal aufwendig, aber man weiß ja schon, wie das alte Projekt 
funktioniert hat.
Und man wundert sich dann, wieviel sich nur durch den neuen 
Programmablauf alles optimieren läßt.



> Mich Interessiert wie die Profis an sowas rangehen und frage mich ob der
> bisherige Ansatz eines "interativen" Entwicklungsmodells (der Appetit
> kommt mit dem Essen) nicht evtl. völlig falsch war ...

Es reizt jeden Entwickler, beim neuen Projekt sofort den Editor zu 
öffnen und:
main()
{
...
}
zu schreiben.
Aber das ist die mit Abstand ineffektivste Methode und dauert am 
längsten.

Der beste Start eines Projekts ist, den PC auszuschalten und Papier und 
Bleistift zu nehmen.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juergen wrote:
> Im Prototypen wird erstmal ein Kontroller mit relativ viel Speicher
> verwendet, damit es da keine Zeitverluste gibt.

Und genau dadurch ergeben sich dann erst recht Zeitverluste, weil es den 
Programmierer zu schludrigem, ungeplanten Programmieren von 
Spaghetticode verleitet.

Das richtige Maß zu finden ist nicht einfach, da hilft eigentlich nur 
Erfahrung.

Viel hilft jedenfalls nicht viel. Wenn ich viel Speicher habe, geht ja 
auch viel CPU-Leistung für die vielen Zugriffe drauf, d.h. die Leistung 
sinkt weiter.

Ich versuche immer, die Abläufe in möglichst kleine universelle 
Funktionen zu zerlegen, damit sie schön einfach und übersichtlich sind 
(Ich habe leider kein Elefantengedächtnis für riesige Codemonster). Und 
damit sinkt der Speicherverbrauch automatisch mit.


Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Die effektivste Methode ist, nochmal von vorne anzufangen, d.h. ein
> neuer Programmablaufplan.

Stimme zu.
Allerdings kriegt ein Kunde meistens einen Herzinfarkt, wenn du ihm das 
so erzählst :-) Da muß man dann öfter mal psychologisch etwas 
'tricksen', ansonsten hängt dir der Kunde dieses Neuschreiben sofort als 
'das geht aber auf eure Kappe' an.

> Klingt erstmal aufwendig, aber man weiß ja schon, wie das alte Projekt
> funktioniert hat.

Und vor allen Dingen hat man einen wesentlichen Vorteil: Man hat 
speziell auf dieser Aufgabenstellung in der Zwischenzeit eine Menge 
Erfahrung gesammelt, kennt all die kleinen Problemchen und wie man sie, 
manchmal schlecht als recht, umgangen hat und kann das neue Projekt 
gleich so aufsetzen, dass diese Problemkreise gar nicht mehr auftreten. 
Dafür gibts dann zwar neue, aber so ist das Leben.

> Der beste Start eines Projekts ist, den PC auszuschalten und Papier
> und Bleistift zu nehmen.

Das kann man gar nicht oft genug dick unterstreichen.

Autor: ahem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Kunde, oder derwelche, der etwas will, will zuerst mal das Falsche. 
Da muss er aber selbst herausfinden. Mit etwas glueck kann man die 
Aenderungen schon vorausahnen, mit etwas glueck den Kunden dahingehend 
beieinflussen. Denn der Termindruck kommt sowieso, aber von extern. 
Irgemdwann will/muss der Kunde an genau diese Messe, und muss da schon 
etwas haben. Das absolute Minimum ist die Gewissheit, dass das Problem 
geloest ist. Dann laesst sich noch was mit Attrappen erreichen.
Und ja, hin und wieder sollte man einen Redesign durchfuehren. Lieber 
neu anfangen, als weiter mit Effizienz Null rumprfriemeln.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als reiner Hobbyprogrammierer sehe ich das ziemlich entspannt. Wenn bei 
Mikrocontrollerprojekten nicht der Weg das Ziel ist, kaufe ich ein 
fertiges Gerät...

>Entweder ich redesigne den Code um Platz zu schaffen für neue Funktionen
Ein Redesign bei "gewachsenen" Projekte ist nie verkehrt, aber erwarte 
nicht, daß da plötzlich gigantische Reserven frei werden. Dazu kommt: Du 
hattest am Anfang des Projektes keine Vorstellung über den Umfang, und 
hast es heute immer noch nicht. So ist das halt unter uns Hobbiisten 
(und bei manchem "Profi" auch...).

>oder ich Erweitere das Gerät um einen weiteren Controller der dann
>Teilaufgaben übernimmt.
Vergiß es. Wenn sich die Aufteilung nicht völlig logisch ergibt (d.h. 
man kann zwei vollwertige Geräte draus machen), wird das viel zu komplex 
und nicht handelbar.

>Eine weitere Option wäre einen größeren Controller zu nehmen ...
Yepp. Wie heisst es so schön: Wende niemals Gewalt an, nimm gleich den 
großen Hammer :-) Ob der Prozessor nun 1,50 oder 3,50 bei Angelika 
kostet, ist doch völlig egal.

Oliver

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.