Hallo,
ich programmiere zwar heute nur noch hobbymässig, aber das eben schon
seit über 30 Jahren, angefangen mit 6510 und Z80. Aktuell mit dem
STM32F427 an einem Grafikdisplay und diversen anderen Peripherien.
Die Zeiten wo man beim 8051 grad mal 2K RAM und 4KB ROM hatte sind lange
vorbei, C gab es auch schon in den 90igern. Code wurde damals tot
optimiert und wurde dadurch teilweise auch unleserlich.
Von den 1MB Flash habe ich grad mal 80kb voll und das sind schon 4500
Zeilen Source Code in 13 Sourcen. Vor allem durch math.h und float
Funktionen. Von den 192 KB RAM sind grad mal 20kb in Nutzung, nahezu
alles sind dynamische Variablen.
Ich möchte 4 Graphen darstellen, die alle ein wenig anders sind, andere
Beschriftungen, andere Wertebereiche. Früher war klar, dass ich eine
Routine schreibe, die mit zig if then else bzw. switch case alle 4
Möglichkeiten abdeckt, dazu ne Menge Zeiger und irgendwann der Knoten im
Hirn, ob das noch alles stimmt.
Ich bin fast soweit dass ich diese Routine, die schon etwas Platz
braucht einfach 4 Mal kopiere und das anpasse was nötig ist, völlig
egal, ob die anderen 3 Routinen zu 90% deckungsgleich sein werden. Die
1MB kriege ich doch eh nie voll.
Wie ist da die Philosophie heute? Mehr Wert auf Lesbarkeit und Struktur,
Fehlerfreiheit der der Codierung oder eben doch "Optimaler Code"?
1
/* Zeichnet eine Druck Bar ein
2
Eingabe: Zeiger auf Info Struct wo Eckdaten der Messwerte stehen
Christian J. schrieb:> Wie ist da die Philosophie heute? Mehr Wert auf Lesbarkeit und Struktur,> Fehlerfreiheit der der Codierung oder eben doch "Optimaler Code"?
Kommt drauf an welchen uC man verwenden will. Mit nem Attiny4 musst du
auch heute noch auf die Code-Größe achten ;)
Christian J. schrieb:> Ich bin fast soweit dass ich diese Routine, die schon etwas Platz> braucht einfach 4 Mal kopiere und das anpasse was nötig ist, völlig> egal, ob die anderen 3 Routinen zu 90% deckungsgleich sein werden. Die> 1MB kriege ich doch eh nie voll.
Man benutzt Funktionen häufig nicht weil man damit Platz spart (das ist
z.B. auf dem PC meistens vollkommen egal), sondern weil der Code damit
wartbar(er) bleiben soll. Wenn du dir sicher bist, nie wieder etwas am
Code ändern zu müssen, kannst du ihn durchaus kopieren und dann
anpassen. Falls dir aber doch noch ein Fehler auffällt, musst du ihn an
vier Stellen korrigieren.
Gerade bei komplexen Projekten ist aber die Regel, den gleichen Code
nicht mehrfach in einem Projekt zu haben, sehr sinnvoll und berechtigt.
Am Ende bleibt es aber deine Entscheidung, mach was du für richtig
hältst (sofern es auch nur für dich ist). Du bist auch der, der die
Suppe wieder auslöffeln muss.
Die Grafiken sehen damit aber auch so aus wie vor 30 Jahren auf einem
Apple ][...
Mit einem STM32F4 mit Grafikcontroller bekommt man schönere Sachen hin,
schau dir mal touchgfx an. Und dann bekommst du auch den 1 MB Flash +
Zusatzflash voll :-)
Johannes S. schrieb:> schau dir mal touchgfx an.
Ich habs mal versucht mit uGFX und wieder sein lassen, da es mit cmake
arbeitet, was die embitz IDE nicht unterstützt. Und obwohl Open Source
werden dämlicherweise nur kommerzielle IDE (Keil, IAR, Attolic) als
Beispiele aufgeführt auf der Homepage. Nix CooCox, nix Embitz. Und
irgendwie graut es mir davor mich da einzuarbeiten. Auch wenn es dann
schöner und moderner ausschaut.
>> Wie ist da die Philosophie heute? Mehr Wert auf Lesbarkeit und Struktur,>> Fehlerfreiheit der der Codierung oder eben doch "Optimaler Code"?
Wer bezahlt...
...das FlashROM?
...deine Arbeitszeit beim Code-Schönschreiben?
...deine Arbeitszeit beim Fehlerbereinigen?
Vom nicht-benutzten Speicher (RAM & ROM) gibt's kein Geld zurück.
Kevin S. schrieb:> Falls dir aber doch noch ein Fehler auffällt, musst du ihn an> vier Stellen korrigieren.
So sehe ich das auch. Ich hasse Copy&Paste.
Ich versuche deshalb, die Unterschiede zu separieren und eine Funktion
für alles zu schreiben. Die Unterschiede kommen in ein Array von
Structs, da sieht man auch schön, was die Unterschiede sind. Und der
Funktion wird nur der Index oder Pointer darauf übergeben.
Der viele Speicher ist sehr praktisch wenn man Bootloader und Updates
machen möchte.
So kann man z.B. den Flash unterteilen in
- Bootloader
- Applikation
- Update Applikation
128KB für einen Bootloader vorsehen, der USB und Ethernet sogar
beherrscht.
Die Applikation mit 896KB maximal.
Wenn man ein Update herunter lädt wird dieser erst in die Sektion
"Update Applikation" geladen und wenn da die CRC usw alles stimmt, dann
kopiert der Bootloader das FLASH um in den Applikations Bereich.
Verbindungsabbruch oder sonstige Probleme gehören somit der
Vergangenheit an.
Oder man unterteilt den Flash in mehrere Etappen:
Der Bootloader sichert erst die aktuelle Applikation, spielt das neue
ein und wenn die neue doch nicht startet und ein Reset macht, dann
kopiert der Bootloader die alte Applikation zurück.
Es gibt viele Möglichkeiten wie man so viel Flash nutzen kann. Davon
haben früher die Entwickler nur träumen können, oder einen externen
DataFlash anschließen müssen.
Christian J. schrieb:> Ich bin fast soweit dass ich diese Routine, die schon etwas Platz> braucht einfach 4 Mal kopiere und das anpasse was nötig ist, völlig> egal, ob die anderen 3 Routinen zu 90% deckungsgleich sein werden. Die> 1MB kriege ich doch eh nie voll.
Deine Philosophie in Sachen "Programmierung" und "Hardwareentwicklung"
ist ziemlich abenteuerlich. Das hat alles so ein Geschmäckle von
Rumgefrickel, bis es einigermaßen tut.
Ja, kann man machen. Will man aber eigentlich nicht. Aber wenn es für
deine Ansprüche reicht und ohnehin nie gewartet werden soll, dann ist es
nunmal dein Stil - aber gib das dann bloß nicht an irgendjemanden
weiter. Niemals. Das ist peinlich.
Wiederverwertbar ist es dann auch nicht.
S. R. schrieb:> Deine Philosophie in Sachen "Programmierung" und "Hardwareentwicklung"> ist ziemlich abenteuerlich.
Darum frage ich hier vielleicht? Ein fach um mal zu horchen was up to
date ist?
Peter hat es schon sehr nett formuliert ein Array of structs löst viele
Probleme und es sieht elegant aus.
Also frisch ans Werk.....
Peter D. schrieb:> Ich versuche deshalb, die Unterschiede zu separieren und eine Funktion> für alles zu schreiben.
Ich bin davon ab, zumindest was Hardware betrifft. Meist ist dann doch
nicht alles gleich gemappt im Adressbereich. Oder es gibt ein paar
Besonderheiten, die dann eine (unnötige) Abstraktion erfordern. Ich
lasse daher Code von der Make-Umgebung ver-x-fachen. Z.B. Sio2.c aus
Sio1.c. Alle Vorkommen von z.B. _Sio1 werden durch _Sio2 ersetzt. Und
ein Konstrukt, um Unterschiede im Code per Präprozessor aus- und
einzublenden.
Vorteile:
- direkter klarer Code. Echte Unterschiede werden direkt beschrieben.
- Breakpoint setzen konkret möglich
- meist zerfällt der Code, so dass z.B. nur 120% für 2 Sios notwendig
sind. Und der Linker kann gezielt arbeiten.
- eine unnatürliche Abstraktion gespart. Damit kann die IDE eher
Informationen z.B. beim mouseover anzuzeigen.
Das es sinnvoll ist, sinnvolle Abstraktionen zu versuchen, allein zum
besseren Verständnis, ist noch kein Grund, diese nachher auch
umzusetzen.
da wird das Chart nur für 'Pressure' Daten gemacht. Ich würde das
strikter trennen, die Daten sind nur ein Array eines Datentyps. Der kann
evtl. mehrere Formate haben wie Xt, XY, Y und X äquidistant usw. Und in
der Info Struktur dann nur die Formatinfo für die einzelnen Elemente.
Das kann man weiter strukturieren und unterteilen in Hintergrund,
Skalen, Datenoptionen usw.
und anstelle von Konstanten wie HISTO_Y_MAX diese Werte eben auch in
eine size/position Struktur in die Infodaten. Z.B. in die Y-Skala die
dann relativ zum Hintergrund positioniert wird. Und die Hintergrund
pos/size bestimmt dann wo das Chart gezeichnet wird. Und schon kann man
den Code für n Charts an verschiedenen Positionen verwenden.
Hiermit werfe ich einfach mal C++ in den Raum.
Nicht das man damit mit den Flash einfach zugeballert bekommt sondern
weil sich eben damit die gewünschte unterschiedliche Verhalten
anschinend gleichartiger Objekte erreichen lässt:
https://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Polymorphie
Johannes S. schrieb:> da wird das Chart nur für 'Pressure' Daten gemacht. Ich würde das> strikter trennen, die Daten sind nur ein Array eines Datentyps.
Grundsätzlich kann man das Zeichnen des Bargraphen mit normierten float
Werten 0-1 durchführen und alle Größen auf diese 0-1 projzieren. Völlig
egal ob Druck, Spannung usw.
Die Aufgabenstellung lautet ja: Projeziere den Druck in den Grenzen von
990 - 1025 mbar auf eine Pixelstrecke von N Pixeln. Das sind Dreisätze.
HIST_X_MAX etc sind Pixelkoordinaten, die fix sind, damit das Diagramm
so liegt, dass alles passt. Alles darum ist relativ, verschiebt sich die
Koordinate, verschiebt sich auch die Beschriftung usw.
In der info steht nur drin, in welchen Größenordungen die sich über den
Darstellungszeitraum bewegt haben, damit der Graph sich dynamisch
anpasst, gestaucht wird oder gespreizt.
Es geht immer noch besser aber ich mache es erstmal lauffähig und dann
fange ich an das Ganze zusammen zu fassen.
1
/* Transponiert die Koordinate in in 0/0 System mit Nullpunkt
2
unten links */
3
#define cvx(x) (x)
4
#define cvy(y) (LCD_WIDTH - (y))
5
6
/* Pixel Eckdaten des Histogramms bez auf 0/0 unten links */
Geldgeber schrieb:>>> Wie ist da die Philosophie heute? Mehr Wert auf Lesbarkeit und Struktur,>>> Fehlerfreiheit der der Codierung oder eben doch "Optimaler Code"?>> Wer bezahlt...
Das ist gar nicht der Punkt. Die Frage ist vielmehr: Welches ist die
Resource, die als erstes knapp bzw. die am teuersten nachzukaufen ist:
> ...das FlashROM?> ...deine Arbeitszeit beim Code-Schönschreiben?> ...deine Arbeitszeit beim Fehlerbereinigen?
und in praktisch allen Fällen ist Entwicklerzeit die mit Abstand
teuerste bzw. spärlichste Resource - sogar für Hobbyprojekte, wo das
Ziel nicht ökonomisch determiniert ist, sondern durch Erkenntnisgewinn
bzw. erreichbare Resultate im Rahmen deiner (begrenzten) Lebenszeit
vorgegeben ist. Die Frage, inwieweit du das jetzt in Code schreiben
und Code debuggen aufteilst, ist an sich noch mal spannend. Aber die
Erfahrung lehrt, daß Code weit häufiger gelesen (+verstanden
+verbessert) wird, als initial geschrieben. go figure...
Lass mal die Ideologie-Frage weg und mach erst mal eine
Überschlagsrechnung, was von Geld- und Zeitaufwand günstiger ist!
- Zeitgemäß Programmieren ist schon schön.
Aber man muss sich auch erst mal (was Zeit kostet) an neue µCs
und Entwicklungsumgebungen gewöhnen.
- Codegröße ist ein wichtiger Parameter, wenn der gewählte µC wenig
Platz für das Programm bietet.
Hast du genug Platz - warum solltest du ihn nicht zu 50% nutzen?
Dann ist immer noch 50% Platz für Erweiterungen, an die niemand
vorher gedacht hat...
- Bearbeitungszeit ist ein wichtiger Parameter, wenn man mit dem
vorgegebenen Systemtakt und schnell (schlecht) programmierten
Routinen nicht zum Ziel kommt.
Mit etwas Erfahrung lässt sich abschätzen, ob mehr Gehirnschmalz
(kostet Zeit), oder ein höherer Systemtakt günstiger ist...
Christian J. schrieb:> Wie ist da die Philosophie heute? Mehr Wert auf Lesbarkeit und Struktur,> Fehlerfreiheit der der Codierung oder eben doch "Optimaler Code"?
Das ist eine Frage der Prioritäten, was für Dich am wichtigsten ist.
Heute wie damals gilt, daß verschiedene Optimierungen auf Kosten
voneinander gehen.
Du kannst durchaus copy&paste machen, viermal nahezu dieselben Dinge nur
mit leichten Variationen tun. Aber dies nicht aus Faulheit oder
Inkompetenz, sondern per Default sollte das als zu vermeidender Pfusch
gelten, sofern Du nicht gute Argumente hast, wieso es genau so besser
ist.
Vor allem dann, wenn Du nachweisen kannst, daß es auf jedes bißchen
Geschwindigkeit real wirklich ankommt, UND wenn Dein Profiling beweist,
daß diese Optimierungen überhaupt in den kritischen Codepfaden liegen.
"Wir haben genug Flash auch für schlecht wartbaren, aufgeblähten Pfusch"
zählt dabei nicht als Argument, weil dieser Ansatz den "time to
market"-Faktor spätestens bei den Folgeversionen versaut, und sogar in
der Entwicklung ist das wegen erhöhten Testaufwands für die vermehrten
Codepfade auch nicht schneller.
Eine Ausnahme sind Templates in C++, die ggf. zwar den Binärcode
aufblähen könnten, was bei genug Flash aber egal ist, und wo im Source
gerade keine zig separaten Codestellen vorliegen.
Christian J. schrieb:> uC Programmierung Spielt Codegröße überhaupt noch eine Rolle?
Ja, sogar beim PC spielt die Grösse eine Rolle, fast jede Software ist
unnötig grosse Bloatware und wäre besser wenn sie kleiner wäre.
Christian J. schrieb:> Ich bin fast soweit dass ich diese Routine, die schon etwas Platz> braucht einfach 4 Mal kopiere und das anpasse was nötig ist,
Ist vor allem wartungstechnisch eine Katastrophe, hinterher wird ein
Fehler nur in 3 von 4 korrigiert, oder eine Erweiterung nur in 2
einprogrammiert.
Es wäre aber ok, ein professionelles 25,0k grosses Chartingtool zu
verwenden, von dem nur 4 Charts verwendet werden..
Christian J. schrieb:> Wie ist da die Philosophie heute?
Wie vor 30 Jahren ;-)
> Mehr Wert auf Lesbarkeit und Struktur, Fehlerfreiheit der> der Codierung oder eben doch "Optimaler Code"?
Wieso "oder"?
Das Ziel war und ist immer optimaler Code. "Optimum" bedeutet
aber: "Das Beste". Nicht "das Allerkleinste", nicht "das
Komplizierteste", nicht "das Schönste", nicht "das Schnellste",
sondern "das Beste".
In der Technik ist "das Optimum" normalerweise der optimale
Kompromiss, d.h. das beste Gleichgewicht zwischen wider-
streitenden Anforderungen.
Heutige Software ist VIEL komplexer als Software vor 30 Jahren;
infolgedessen sind auch Lesbarkeit, Struktur, Fehlerfreiheit
viel wichtiger als damals. Da sich die Randbedingungen geändert
haben, liegt der Gleichgewichtspunkt heute woanders als vor
30 Jahren.
Peter D. schrieb:> So sehe ich das auch. Ich hasse Copy&Paste.> Ich versuche deshalb, die Unterschiede zu separieren und> eine Funktion für alles zu schreiben. Die Unterschiede> kommen in ein Array von Structs, da sieht man auch schön,> was die Unterschiede sind. Und der Funktion wird nur der> Index oder Pointer darauf übergeben.
Es ist schön und zu bewundern, wenn Dir das im ersten Anlauf
aus einem Guss gelingt, aber das kann nicht jeder. (Ich
kanns zum Beispiel nicht.)
Ich finde nichts Schlimmes daran, zunächst mal mit Copy&Paste
einzelne Varianten auszuformulieren, um dann in der nächsten
Runde umzuordnen und zusammenzufassen.
Man muss gar nicht immer alles im ersten Anlauf richtig machen;
es genügt, wenn man die Schwächen dann behebt, wenn sie einem
das erste Mal auf den Fuß fallen.
letztendlich ist es eine Frage von wirtschaftlichkeit ...
wenn du ein produkt hast das in millionen stückzahl produziert wird und
man 10 Cent einsparen kann weil man nur einen halb so großen Flash
nutzt, dann wird man sich einen Entwickler Leisten der 1 Jahr lang den
code optimieren kann bis es passt.
Aber man handelt sich einen riesen Rattenschwanz ein, schlechter
wartbarer und wiederverwendbarer code ... evtl. nutzt man weniger gut
abgehangene 3rd party libs etc. :)
Gefühlt folgen die Codegrößen ebenfalls dem Mooreschen Gesetzt. Alle 18
Monate brauchen wir doppelt so großen FLASH.
Possetitjel schrieb:> Es ist schön und zu bewundern, wenn Dir das im ersten Anlauf> aus einem Guss gelingt, aber das kann nicht jeder.
Wie kommst Du darauf?
Viele Sachen, die ich vor ein paar Jahren geschrieben habe, würde ich
heute anders machen. Der Programmierstil ändert sich ständig.
Und auch, wenn ich Code in neue Projekte übernehme, mache ich noch
Verbesserungen daran.
Es ist eh schwer (unmöglich), eine optimale, universelle und fehlerfreie
Lib zu schreiben. Ein Kollege hatte kürzlich einen Fehler gesucht und
dann den Fehler in einer importierten Lib gefunden. Es war ein
Copy&Paste Fehler.
ASF, HAL, Code-Wizzards usw. können helfen, aber auch viel Ärger
verursachen. Und man ist damit völlig vom Support des Herstellers
abhängig.
Peter D. schrieb:> Wie kommst Du darauf?> Viele Sachen, die ich vor ein paar Jahren geschrieben habe, würde ich> heute anders machen. Der Programmierstil ändert sich ständig.
Ich glaube es gibt gibt hier nur wenige, die besseren Code schreiben als
Du :-) Ich bin nicht oft hier aber "Made by Danegger" ist ein Begriff
;-)
Possetitjel schrieb:> Es ist schön und zu bewundern, wenn Dir das im ersten Anlauf> aus einem Guss gelingt, aber das kann nicht jeder. (Ich> kanns zum Beispiel nicht.)
Aus einem Guss und erster Anlauf ist überhaupt nicht erforderlich.
Vergleiche es mit dem überstürzten Einzug in die erste Wohnung. Irgendwo
liegt eine Matratze, ein Tapeziertisch mit Plastikwanne als Küche und
überall stehen Kartons mit Krempel rum.
Aber wichtig: es läuft. Das Chaos ist nicht schlimm. Es ist nur schlimm,
wenn es so bleibt. Und wenn Geld (Zeit) da ist, werden halt ein paar
Schränke gekauft (Module zusammengefasst) oder eingeräumt
(refakturiert).
Und ja, wenn man das 5 mal gemacht hat, dann gelingt einem so ein Einzug
auch relativ schnell. Aber noch schlimmer als eine chaotische Wohnung
ist eine von vorne bis hinten durchgestylte Wohnung mit perfekter
Ordnung, die Du schon vor dem Einzug aufgeben musst, weil das Geld alle
ist. Oder in die das erste Dir wichtige Möbelstück (Funktionalität)
nicht mehr reinpasst.
Es ist halt die Frage ob man mit der Planung anfängt oder erstmal die
Features zu testen.
Da gab es mal ein schönes Buch : Mr. Bunnis Guide to ActiveX. Die Beste
Grafik darin ist 'my first VisualBasic program' :
http://www.mrbunny.com/sample.html
Als Informatiker kriege ich jedenfalls Pickel wenn ich so langen Code
sehe der maximal einmal verwendbar ist.
Mit welchen Projekten beschäftigt Ihr Euch denn?
Sobald etwas für echte Stückzahlen entwickelt wird spielt die Codelänge
natürlich eine wichtige Rolle. Auch 3 Cent pro Mikrocontroller mit
doppelt so großem Speicher kann sehr viel Geld sein.
Zum Geldverdienen: Industrieprojekte mit kleineren Stückzahlen wo die
Lohnkosten oft deutlich über den Materialkosten liegen. Wartbarkeit ist
hier viel wichtiger als Optimierung.
µC Projekte privat: keine Zwänge :-) Um einen einfachen Sensor
abzufragen nehme ich da allerdings auch keinen Cortex-M7, da freue ich
mich über das breite Spektrum an Cortex-M und das grosse Angebot das man
mittlerweile hat. Und so eine Anzeige- und Bedieneinheit habe ich auch
angefangen, da finde ich es Top was man von ST für rel. wenig Geld
bekommt.
tarm46 schrieb:> Mit welchen Projekten beschäftigt Ihr Euch denn?>> Sobald etwas für echte Stückzahlen entwickelt wird spielt die Codelänge> natürlich eine wichtige Rolle. Auch 3 Cent pro Mikrocontroller mit> doppelt so großem Speicher kann sehr viel Geld sein.
Einzelstücke, Prototypen, Kleinstserien < 100 Stück, Großserien > 100k
mit großen Controllern > 4 MiB Flash und Mannjahrzehnten
Entwicklungszeit.
In keinem Fall rechnet sich das Sparen an Resourcen. Selbst bei den
Großserien liegen die Entwicklungskosten im Bereich der HK. Spät in der
Entwicklung einen anderen Prozessor qualifizieren zu müssen wäre
katastrophal.
tarm46 schrieb:> Sobald etwas für echte Stückzahlen entwickelt wird spielt die Codelänge> natürlich eine wichtige Rolle. Auch 3 Cent pro Mikrocontroller mit> doppelt so großem Speicher kann sehr viel Geld sein.
Das hat miteinander aber nichts zu tun.
für die (SW-) Entwicklung ist es einfach Dummheit, nicht den Typen mit
maximalem Speicher zu nehmen.
Wenn das Design fertig ist, die Entwicklung abgeschlossen, dann ist es
ein weiterer Schritt, dies notfalls in Assembler in den kleinstmöglichen
Typen zu hacken. Dessen Code muss dann auch nicht wartbar sein, sondern
nur "richtig".
tarm46 schrieb:> Auch 3 Cent pro Mikrocontroller mit> doppelt so großem Speicher kann sehr viel Geld sein.
Die 3 Cent massiert ein guter Einkäufer schneller weg, als du 10 Zeilen
debuggten Assemblercode hinlegst.
MfG Klaus
Klaus schrieb:> Die 3 Cent massiert ein guter Einkäufer schneller weg, als du 10 Zeilen> debuggten Assemblercode hinlegst.
Sicher? Wenn der µC (inklusive Großkundenrabatt) nur 10 Cent/Stück
kostet?!
Schreiber schrieb:> Klaus schrieb:>> Die 3 Cent massiert ein guter Einkäufer schneller weg, als du 10 Zeilen>> debuggten Assemblercode hinlegst.>> Sicher? Wenn der µC (inklusive Großkundenrabatt) nur 10 Cent/Stück> kostet?!
Unrealistisch
Schreiber schrieb:> Sicher? Wenn der µC (inklusive Großkundenrabatt) nur 10 Cent/Stück> kostet?!
Auch dann. In Wirklichkeit kost das Silizium eigentlich nichts, die
Kosten für das Gehäuse und das Bonden bestimmen den Preis, wenn ein Chip
mal eingeschwungen ist. Die Anzahl der I/Os, die Größe des Gehäuses
bestimmen den Preis, da inzwischen die Größe des Siliziums nur noch von
der Anzahl der I/Os bestimmt wird. Der equivalente Chip mit mehr
Speicher ist wahrscheinlich der Gleiche wie der mit weniger Speicher,
halt nur lasergetrimmt.
Das mag sich dann am Ende zwar nicht direkt im Stückpreis niederschlagen
(der wird zu leicht von Technikern rumposaunt und versaut die Preise),
aber das Gesamtpaket aus Transport und Finanzierungskosten, wer trägt
Wechselkursrisiken, Abrufmengen und Zahlungszielen, Verbindung mit
anderen Bauteilen und Bestellungen etc. wird das am Ende ergeben. Gute
BWL haben genauso ihre Tricks drauf wie gute Ingenieure.
MfG Klaus
Thread beobachten
Seitenaufteilung abschalten