elektroda.net NewsGroups Forum Index - Electronics DE - Einstieg finden CC²-ATmega oder doch besser 8051
Frank Buss
Guest
Guest
Sun Feb 21, 2010 1:44 pm
Stefan Reuther wrote:
Quote:
Unter
http://portal.automotive-his.de/images/pdf/SoftwareTest/his_subset_misra_c_1.0.3.pdf
bekommt man einen Teil der Regeln in knapper Form.
http://portal.automotive-his.de/images/pdf/SoftwareTest/his_subset_misra_c_1.0.3.pdf
bekommt man einen Teil der Regeln in knapper Form.
So beim überfliegen habe ich den Eindruck, daß schätzungsweise die Hälfte
der Regeln bereits Warnungen oder Fehlermeldungen beim GCC generieren. Eine
Regel sollte daher sein, per "-Wall -Werror" zu übersetzen :-)
Quote:
Insbesondere sieht man MISRA recht gut an, dass es vielleicht für die
Implementation von Motorsteuergeräten gedacht ist, aber nicht für
Größeres wie das Infotainment-Gedöns oder generell irgendwelche Dinge,
die Text anzeigen. MISRA verbietet z.B. eigentlich stdio, errno usw.;
deswegen schmeiß ich aber nicht all meinen (portablen!) Code weg und
implementier den fehlerträchtig mit einem eigenen Dateisystem-API neu.
Implementation von Motorsteuergeräten gedacht ist, aber nicht für
Größeres wie das Infotainment-Gedöns oder generell irgendwelche Dinge,
die Text anzeigen. MISRA verbietet z.B. eigentlich stdio, errno usw.;
deswegen schmeiß ich aber nicht all meinen (portablen!) Code weg und
implementier den fehlerträchtig mit einem eigenen Dateisystem-API neu.
Das Dokument oben lässt begründete Ausnahmen zu. Wenn du z.B. unter einem
Betriebssystem etwas programmierst und auf das Filesystem zugreifen willst,
ist es bestimmt im Sinne von fehlerfreieren Code, fopen usw. zu verwenden,
statt in Assembler die traps des Kernels o.ä. manuell aufzurufen.
--
Frank Buss, fb_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Thomas 'tom' Malkus
Guest
Guest
Sun Feb 21, 2010 2:26 pm
Dirk Ruth <d.ruth_at_itecnet.de> writes:
Quote:
Ein OS bietet vor allem gute generische, elegante und sehr
übersichtliche Lösungen für immer wiederkehrende Probleme auf einem
Controller bei denen auch gestandene embedded Programmierer immer
wieder auf die Nase fallen. Das habe ich oft genug auch in
übersichtliche Lösungen für immer wiederkehrende Probleme auf einem
Controller bei denen auch gestandene embedded Programmierer immer
wieder auf die Nase fallen. Das habe ich oft genug auch in
Von welchen Anwendungen sprichst Du eigentlich? Ob OS oder nicht ist
wohl eben auch von der Anwendung abhängig. Wiederverwendbaren Code
habe ich in meiner Bibliothek für 8051er auch.
Quote:
Compiler installiert, sich ein gutes Style-Guide zu besorgen und sich
mal durch MISRA zu arbeiten.
Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher
auch für einen Anfänger von Vorteil sein.
mal durch MISRA zu arbeiten.
Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher
auch für einen Anfänger von Vorteil sein.
Als ich 1979 auf dem Apple ][ angefangen habe, gab es das noch gar
nicht. Trotzdem wurde Software entwickelt und die hat auch funktioniert.
73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Dirk Ruth
Guest
Guest
Mon Feb 22, 2010 5:10 am
Thomas 'tom' Malkusschrieb:
"
Quote:
Dirk Ruth <d.ruth_at_itecnet.de> writes:
Ein OS bietet vor allem gute generische, elegante und sehr
übersichtliche Lösungen für immer wiederkehrende Probleme auf einem
Controller bei denen auch gestandene embedded Programmierer immer
wieder auf die Nase fallen. Das habe ich oft genug auch in
Von welchen Anwendungen sprichst Du eigentlich? Ob OS oder nicht ist
wohl eben auch von der Anwendung abhängig. Wiederverwendbaren Code
habe ich in meiner Bibliothek für 8051er auch.
Ein OS bietet vor allem gute generische, elegante und sehr
übersichtliche Lösungen für immer wiederkehrende Probleme auf einem
Controller bei denen auch gestandene embedded Programmierer immer
wieder auf die Nase fallen. Das habe ich oft genug auch in
Von welchen Anwendungen sprichst Du eigentlich? Ob OS oder nicht ist
wohl eben auch von der Anwendung abhängig. Wiederverwendbaren Code
habe ich in meiner Bibliothek für 8051er auch.
Fürs LED blinken brauchen wir nicht darüber zu reden.
Sobald die Anwendung aber etwas komplexer wird, stellen sich z.B.
solche Fragen:
Wie setze ich mein Zeitgerüst auf?
Wie übertrage ich Daten aus ISRs an die Applikation (Synchronisation)?
Wie mache ich Delays?
Wie breche ich auf ein Event hin eine laufende Applikation sofort ab?
Wie kann ich Code schreiben, der die oberen Probleme löst, meinen Code
aber nicht sinnlos in riesige State-Maschinen zerhackt, nur weil
ständiges Polling aus der Applikation gemacht werden muss, was
wiederum Unübersichtlichkeit und redundanten Code schafft?
Ein OS kann diese Fragen sehr elegant beantworten. Verwende ich kein
OS, muss ich diese Dinge selbst zusammen basteln (also neu erfinden).
Dann aber verbringe ich einen Teil meiner kostbaren Zeit damit,
kernähnliche Funktionalitäten zu implementieren.
Auch bringt so ein OS eine Menge an Mitgift mit, die man häufiger gut
gebrauchen kann. Da sind so Dinge bei wie FIFOs, LIFOs, Stacks,
Queues, Callback-Timer, Initialisierung des Oszillators (+ PLL),
Initialisierung einer seriellen Schnittstelle fürs Debuggen und
Auslesen wichtiger interner Strukturen, nested Interrupts, Memory
Pools usw.
Quote:
Compiler installiert, sich ein gutes Style-Guide zu besorgen und sich
mal durch MISRA zu arbeiten.
Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher
auch für einen Anfänger von Vorteil sein.
Als ich 1979 auf dem Apple ][ angefangen habe, gab es das noch gar
nicht. Trotzdem wurde Software entwickelt und die hat auch funktioniert.
mal durch MISRA zu arbeiten.
Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher
auch für einen Anfänger von Vorteil sein.
Als ich 1979 auf dem Apple ][ angefangen habe, gab es das noch gar
nicht. Trotzdem wurde Software entwickelt und die hat auch funktioniert.
Ja früher war alles anders. Dann schau dir die Software doch heute
nochmal an, erweitere sie und portiere sie mal auf einen anderen
Prozessor. Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Ich stelle nichtmal in Frage, dass Frikkelsoftware im Zeitpunkt der
Erstellung funktioniert, vielmehr liegt ein Teil der Kunst des
Programmierens darin, leicht verständlichen, wartbaren, erweiterbaren
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Dirk
Dirk Ruth
Guest
Guest
Mon Feb 22, 2010 5:10 am
Stefan Reutherschrieb:
"
Quote:
Joerg Wunsch wrote:
Dirk Ruth <d.ruth_at_itecnet.de> schrieb:
Gute generische und portable Lösungen zu entwickeln ist [...]
...bei weitem nicht immer notwendig. Eine generische und portable
Lösung kostet einfach mal ein Mehrfaches an initialem Aufwand, und
gerade für des Bastlers Einzelgerät ist dieser Aufwand schwer zu
rechtfertigen: der wird das nicht in drei Jahren nochmal mit einem
völlig anderen Controller und entsprechend anderer Peripherie neu
bauen müssen. Selbst wenn: der Aufwand für die saubere generische
Lösung wäre selbst dann noch nicht gerechtfertigt, wenn er die zweite
Implementierung komplett nochmal von vorn schreibt.
Definiere "generisch und portabel".
Dirk Ruth <d.ruth_at_itecnet.de> schrieb:
Gute generische und portable Lösungen zu entwickeln ist [...]
...bei weitem nicht immer notwendig. Eine generische und portable
Lösung kostet einfach mal ein Mehrfaches an initialem Aufwand, und
gerade für des Bastlers Einzelgerät ist dieser Aufwand schwer zu
rechtfertigen: der wird das nicht in drei Jahren nochmal mit einem
völlig anderen Controller und entsprechend anderer Peripherie neu
bauen müssen. Selbst wenn: der Aufwand für die saubere generische
Lösung wäre selbst dann noch nicht gerechtfertigt, wenn er die zweite
Implementierung komplett nochmal von vorn schreibt.
Definiere "generisch und portabel".
Darunter verstehe ich z.B., dass es einen unteren Layer (Treiber oder
wie man das nennen mag) gibt, der vor der Applikation alle
hardwareabhängigen Vorgänge versteckt. Der Applikation ist es
letztendlich egal, worauf sie läuft.
Quote:
Ich baue, wenn möglich, meine
Programmmodule generell so, dass sie z.B. mit
#ifdef TEST
int main() {
assert(...);
assert(...);
}
#endif
enden und auf dem PC als Unit-Tests übersetzt werden können.
Programmmodule generell so, dass sie z.B. mit
#ifdef TEST
int main() {
assert(...);
assert(...);
}
#endif
enden und auf dem PC als Unit-Tests übersetzt werden können.
Sehr schön.
Spielt dann also in deinem Beispiel keine Rolle, ob der Controller nun
in ein EEPROM schreibt, oder auf dem PC in eine Datei.
Quote:
Zugegeben,
für eine LED-Blink-Schaltung ist das vielleicht nicht so relevant. Seit
ich das tue, ist die Zahl der Module, die ich ins Produktivsystem auf-
nehme und die einfach funktionieren, deutlich gestiegen. Außerdem hab
ich keine Lust auf Konstanten im Code ("UART_DLL = 17; UART_DLH = 3;"),
also baue ich die Module so, dass Quarz-Takt und gewünschter Ausgangs-
takt Eingangsgrößen sind.
für eine LED-Blink-Schaltung ist das vielleicht nicht so relevant. Seit
ich das tue, ist die Zahl der Module, die ich ins Produktivsystem auf-
nehme und die einfach funktionieren, deutlich gestiegen. Außerdem hab
ich keine Lust auf Konstanten im Code ("UART_DLL = 17; UART_DLH = 3;"),
also baue ich die Module so, dass Quarz-Takt und gewünschter Ausgangs-
takt Eingangsgrößen sind.
Man sieht also es lohnt sich, auch wenn es erstmal mehr Arbeit macht.
Du könntest deine Sourcen ins Internet stellen und jeder könnte was
damit anfangen.
Quote:
Einem Anfänger würde ich sowieso erstmal empfehlen, bevor er einen
Compiler installiert, sich ein gutes Style-Guide zu besorgen und
sich mal durch MISRA zu arbeiten.
MISRA scheitert für einen Hobby-Anfänger schon daran, dass es Geld
kostet.
Unter
http://portal.automotive-his.de/images/pdf/SoftwareTest/his_subset_misra_c_1.0.3.pdf
bekommt man einen Teil der Regeln in knapper Form. Außerdem gibt es
unter <http://www2.research.att.com/~bs/JSF-AV-rules.pdf> auch noch
einen Satz Codierregeln.
Außerdem kenne ich auch in der Industrie keinen, der das
freiwillig verwendet. Es gibt eine Reihe von Leuten, für die es
gemacht worden ist und die es nehmen müssen, es gibt viele sinnvolle
Dinge da drin, aber es gibt auch viele Regeln, die aus den
Unzulänglichkeiten von C-Compilern des letzten Jahrtausends entstanden
sind und in der dort geforderten strikten Form keinen Sinn mehr haben.
Insbesondere sieht man MISRA recht gut an, dass es vielleicht für die
Implementation von Motorsteuergeräten gedacht ist, aber nicht für
Größeres wie das Infotainment-Gedöns oder generell irgendwelche Dinge,
die Text anzeigen. MISRA verbietet z.B. eigentlich stdio, errno usw.;
deswegen schmeiß ich aber nicht all meinen (portablen!) Code weg und
implementier den fehlerträchtig mit einem eigenen Dateisystem-API neu.
Compiler installiert, sich ein gutes Style-Guide zu besorgen und
sich mal durch MISRA zu arbeiten.
MISRA scheitert für einen Hobby-Anfänger schon daran, dass es Geld
kostet.
Unter
http://portal.automotive-his.de/images/pdf/SoftwareTest/his_subset_misra_c_1.0.3.pdf
bekommt man einen Teil der Regeln in knapper Form. Außerdem gibt es
unter <http://www2.research.att.com/~bs/JSF-AV-rules.pdf> auch noch
einen Satz Codierregeln.
Außerdem kenne ich auch in der Industrie keinen, der das
freiwillig verwendet. Es gibt eine Reihe von Leuten, für die es
gemacht worden ist und die es nehmen müssen, es gibt viele sinnvolle
Dinge da drin, aber es gibt auch viele Regeln, die aus den
Unzulänglichkeiten von C-Compilern des letzten Jahrtausends entstanden
sind und in der dort geforderten strikten Form keinen Sinn mehr haben.
Insbesondere sieht man MISRA recht gut an, dass es vielleicht für die
Implementation von Motorsteuergeräten gedacht ist, aber nicht für
Größeres wie das Infotainment-Gedöns oder generell irgendwelche Dinge,
die Text anzeigen. MISRA verbietet z.B. eigentlich stdio, errno usw.;
deswegen schmeiß ich aber nicht all meinen (portablen!) Code weg und
implementier den fehlerträchtig mit einem eigenen Dateisystem-API neu.
Es ging mir nicht darum solche Empfehlungen sklavisch anzuwenden.
Vielmehr sollte man sich als Anfänger mal damit auseinandersetzen
(gern auch kritisch) und überlegen, warum es solche Empfehlungen gibt.
Da haben sich ja einige Leute auch ein paar Gedanken dazu gemacht.
Dirk
Stefan Engler
Guest
Guest
Mon Feb 22, 2010 8:55 am
Am 22.02.2010 04:10, schrieb Dirk Ruth:
Quote:
Ich stelle nichtmal in Frage, dass Frikkelsoftware im Zeitpunkt der
Erstellung funktioniert, vielmehr liegt ein Teil der Kunst des
Programmierens darin, leicht verständlichen, wartbaren, erweiterbaren
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Erstellung funktioniert, vielmehr liegt ein Teil der Kunst des
Programmierens darin, leicht verständlichen, wartbaren, erweiterbaren
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Früher hat man die Software aber auch sauber dokumentiert. Da war von
selbstdokumentierenden Code noch nicht die Rede und jedes Unterprogramm
wurde sauber mit seinen Eingabewerten, Rückgabewerten und Funktionen
dargestellt.
Das PC-Bios wurde entsprechend dokumentiert (nachdem es sowieso genug
Firmen nachempfunden haben, wurde die Dokumentation verfügbar).
So mancher Programmablaufplan ist verständlicher als was man heute an
selbstdokumentierenden Code findet.
Macht bitte also nicht die Programiersprache für die Fehler der
Programmierer verantwortlich. Mit entsprechender Gerissenheit, lässt
sich sogar VBA, ADA und C++ unnachvollziehbar schreiben. (Bei VBA den
Funktionspointer extrahieren und über API-Funktionen aufrufen lassen, etc.)
David Kastrup
Guest
Guest
Mon Feb 22, 2010 10:04 am
Stefan Engler <Lehrerfreund_at_web.de> writes:
Quote:
Am 22.02.2010 04:10, schrieb Dirk Ruth:
Ich stelle nichtmal in Frage, dass Frikkelsoftware im Zeitpunkt der
Erstellung funktioniert, vielmehr liegt ein Teil der Kunst des
Programmierens darin, leicht verständlichen, wartbaren, erweiterbaren
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Früher hat man die Software aber auch sauber dokumentiert. Da war von
selbstdokumentierenden Code noch nicht die Rede und jedes
Unterprogramm wurde sauber mit seinen Eingabewerten, Rückgabewerten
und Funktionen dargestellt.
Ich stelle nichtmal in Frage, dass Frikkelsoftware im Zeitpunkt der
Erstellung funktioniert, vielmehr liegt ein Teil der Kunst des
Programmierens darin, leicht verständlichen, wartbaren, erweiterbaren
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Früher hat man die Software aber auch sauber dokumentiert. Da war von
selbstdokumentierenden Code noch nicht die Rede und jedes
Unterprogramm wurde sauber mit seinen Eingabewerten, Rückgabewerten
und Funktionen dargestellt.
Ich habe schon nichttrivialen Assemblercode (Reversiprogramm auf Z80 mit
Alpha-Beta-Pruning und situationsabhängigen Scoretabellen)
disassembliert, in dem jede Funktion klar ersichtlich und geradeheraus
durchprogrammiert war und die Datenstrukturen und Registernutzung sauber
und zweckgerecht. Der mir unbekannte Autor hätte das Ding als Lehrbuch
veröffentlichen können.
--
David Kastrup
Thomas 'Tom' Malkus
Guest
Guest
Mon Feb 22, 2010 11:00 am
Dirk Ruth (d.ruth_at_itecnet.de):
Quote:
Fürs LED blinken brauchen wir nicht darüber zu reden.
Sobald die Anwendung aber etwas komplexer wird, stellen sich z.B.
solche Fragen:
Wie setze ich mein Zeitgerüst auf?
Wie übertrage ich Daten aus ISRs an die Applikation (Synchronisation)?
Wie mache ich Delays?
Es gibt auch eine Welt zwischen LED blinken und OS. Ich arbeite für einige
Geräte (z.B. RFID, Messgeräte, Steuerungen) mit 8 Bit Controllern, die dafür
völlig ausreichend sind.
Quote:
Ja früher war alles anders. Dann schau dir die Software doch heute
nochmal an, erweitere sie und portiere sie mal auf einen anderen
Prozessor. Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
nochmal an, erweitere sie und portiere sie mal auf einen anderen
Prozessor. Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Gerade vor ein paar Tagen habe ich ein Programm für einen HD6303 geändert
(das war schon etwas schwierig, weil der Compiler nur unter DOS läuft, aber
es gibt ja VMWare). Zur Zeit setze ich gerade Software für den 68HC711 auf
AVR um. Nachher ändere ich noch ein Programm für einen 80537. Und gestern
Abend habe ich eine Software auf ARM9 unter Linux erweitert sowie an einer
Visualisierung mit Qt4 gearbeitet. Dieser Mix aus alt und neu ist tägliche
Arbeit.
Quote:
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
nicht, dass da ein paar structs hinein sollen, sondern dass das
Das ist schon klar
. Ich habe, wie jeder andere wohl auch, einen ganzen
Stapel fertige Routinen, die sich immer wieder verwenden lassen.
Quote:
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Ich werde den Eindruck nicht los, dass Du nur große Projekte, die in einem
Team entwickelt werden, betrachtest. Da stimme ich Dir dann auch zu, okay
ob OS oder nicht ist die Frage, aber Struktur, Styleguide und Docu sind da
sicher wichtig. Aber es gibt auch eine Welt zwischen Hobby und Großprojekt.
73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Thomas Meier
Guest
Guest
Mon Feb 22, 2010 11:42 pm
Quote:
Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
anfangen kann.
Das ist ja i.a. auch gar nicht Sinn der Sache. Wenn man der einzige in
der Firma ist der eine bestimmte Softwarekomponente durchblickt ist das
bestimmt kein Nachteil.
Dirk Ruth
Guest
Guest
Tue Feb 23, 2010 5:37 am
Thomas 'Tom' Malkusschrieb:
"
Quote:
Dirk Ruth (d.ruth_at_itecnet.de):
Fürs LED blinken brauchen wir nicht darüber zu reden.
Sobald die Anwendung aber etwas komplexer wird, stellen sich z.B.
solche Fragen:
Wie setze ich mein Zeitgerüst auf?
Wie übertrage ich Daten aus ISRs an die Applikation (Synchronisation)?
Wie mache ich Delays?
Es gibt auch eine Welt zwischen LED blinken und OS. Ich arbeite für einige
Geräte (z.B. RFID, Messgeräte, Steuerungen) mit 8 Bit Controllern, die dafür
völlig ausreichend sind.
Ja früher war alles anders. Dann schau dir die Software doch heute
nochmal an, erweitere sie und portiere sie mal auf einen anderen
Prozessor. Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Gerade vor ein paar Tagen habe ich ein Programm für einen HD6303 geändert
(das war schon etwas schwierig, weil der Compiler nur unter DOS läuft, aber
es gibt ja VMWare). Zur Zeit setze ich gerade Software für den 68HC711 auf
AVR um. Nachher ändere ich noch ein Programm für einen 80537. Und gestern
Abend habe ich eine Software auf ARM9 unter Linux erweitert sowie an einer
Visualisierung mit Qt4 gearbeitet. Dieser Mix aus alt und neu ist tägliche
Arbeit.
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
Das ist schon klar. Ich habe, wie jeder andere wohl auch, einen ganzen
Stapel fertige Routinen, die sich immer wieder verwenden lassen.
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Ich werde den Eindruck nicht los, dass Du nur große Projekte, die in einem
Team entwickelt werden, betrachtest. Da stimme ich Dir dann auch zu, okay
ob OS oder nicht ist die Frage, aber Struktur, Styleguide und Docu sind da
sicher wichtig. Aber es gibt auch eine Welt zwischen Hobby und Großprojekt.
Fürs LED blinken brauchen wir nicht darüber zu reden.
Sobald die Anwendung aber etwas komplexer wird, stellen sich z.B.
solche Fragen:
Wie setze ich mein Zeitgerüst auf?
Wie übertrage ich Daten aus ISRs an die Applikation (Synchronisation)?
Wie mache ich Delays?
Es gibt auch eine Welt zwischen LED blinken und OS. Ich arbeite für einige
Geräte (z.B. RFID, Messgeräte, Steuerungen) mit 8 Bit Controllern, die dafür
völlig ausreichend sind.
Ja früher war alles anders. Dann schau dir die Software doch heute
nochmal an, erweitere sie und portiere sie mal auf einen anderen
Prozessor. Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Gerade vor ein paar Tagen habe ich ein Programm für einen HD6303 geändert
(das war schon etwas schwierig, weil der Compiler nur unter DOS läuft, aber
es gibt ja VMWare). Zur Zeit setze ich gerade Software für den 68HC711 auf
AVR um. Nachher ändere ich noch ein Programm für einen 80537. Und gestern
Abend habe ich eine Software auf ARM9 unter Linux erweitert sowie an einer
Visualisierung mit Qt4 gearbeitet. Dieser Mix aus alt und neu ist tägliche
Arbeit.
und strukturierten Code zu schreiben. Mit strukturiert meine ich jetzt
nicht, dass da ein paar structs hinein sollen, sondern dass das
Das ist schon klar
. Ich habe, wie jeder andere wohl auch, einen ganzen
Stapel fertige Routinen, die sich immer wieder verwenden lassen.
gesamte Programm eine Struktur hat, dass man Tiefe und
Abstraktionsebenen erkennt, dass eine gewisse Flxibilität möglich ist,
ohne dass sofort alles zusammenbricht.
Ich werde den Eindruck nicht los, dass Du nur große Projekte, die in einem
Team entwickelt werden, betrachtest. Da stimme ich Dir dann auch zu, okay
ob OS oder nicht ist die Frage, aber Struktur, Styleguide und Docu sind da
sicher wichtig. Aber es gibt auch eine Welt zwischen Hobby und Großprojekt.
Also ich mache nicht nur große Projekte, allerding war in den letzten
Jahren kein Controller mehr dabei, der weniger als 48 Pins hatte.
8bitter waren auch nicht mehr dabei, weil Preis/Leistung schlechter
als beim einfachen 16bitter. Die 16bitter kosten ja (>= 48pins) nicht
mehr als ein 8bitter. Und da der Kunde am Ende des Projekts doch immer
noch das eine oder andere Extra wünscht (das Gegenteilige ist mir in
der Praxis noch nie begegnet) darf der Controller auch ein paar Bytes
mehr habe, als unbedingt nötig. Ist dem Kunden wichtiger, als irgendwo
noch ein paar Cents zu sparen und dann vielleicht ein
Controllerwechsel machen zu müssen.
Mit einem Team ist es z.Z. auch nichts (will der Kunde nicht), weil
der Kunde nicht mehr möchte, dass bei Problemen mit der Elektronik der
eine die Schuld auf den anderen abschiebt (hat da wohl schlechte
Erfahrung gemacht). Hard- und Software soll alles aus einer Hand
kommen und nur ein persönlicher Ansprechpartner da sein. Dafür nimmt
er in Kauf, dass das Projekt nun zwar länger dauert, aber dennoch 20%
weniger Mannstunden und Kosten verursacht, weil nun keine
Gruppenorganisation und keine internen Meetings mehr notwendig werden.
Mir solls recht sein.
Also mache ich Elektronikentwicklung, Schaltpläne, Layout, Prototyp,
Software, alle Prüfungen (EMV/TÜV/UL), Dokumentation und
Service-Anleitungen, Upgrades und wohl auch später den Service.
Sieht dann etwa so aus
http://www.itecnet.de/Display-Rueckseite.jpg
http://www.itecnet.de/Display-Vorderseite.jpg
der Controller ist tatsächlich etwas größer als ein 8bitter und die
Software auch etwas umfangreicher (nein da ist kein Linux drauf).
Könne man aber ach noch als Bastler verarbeiten, da kein BGA und somit
nur zwei Lagen.
Allerding steht das Teil jetzt schon ein paar Tage in der Ecke, weil
ich mich z.Z. um das Leistungstel kümmern muss und heute haben mich
die Motoren da dran wieder mal den ganzen Tag über geärgert ....
Dirk
David Kastrup
Guest
Guest
Tue Feb 23, 2010 10:07 am
Thomas Meier <antispam42_at_spamspam.invalid> writes:
Quote:
Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Das ist ja i.a. auch gar nicht Sinn der Sache. Wenn man der einzige in
der Firma ist der eine bestimmte Softwarekomponente durchblickt ist
das bestimmt kein Nachteil.
anfangen kann.
Das ist ja i.a. auch gar nicht Sinn der Sache. Wenn man der einzige in
der Firma ist der eine bestimmte Softwarekomponente durchblickt ist
das bestimmt kein Nachteil.
Haha. Wenn es unmöglich wird, eine Abteilung weiter an den Kundenbedarf
zu skalieren, weil der Durchblicker in der Firma bereits 60h arbeitet
und seinen Urlaub verfallen läßt, dann wird die Abteilung aufgelöst.
Weil ja schließlich eh keiner die Produktivität weiter erhöhen kann.
Die Kundenacquise wird dann an die voraussichtliche Burnoutrate des
hochgelobten gut bezahlten Durchblickers angepaßt.
Wenn er langsam genug ausbrennt, ist sein Knowhow nach Ziehen der
Notbremse (durch ihn oder Management) für den Arbeitsmarkt nicht mehr
brauchbar, weil er keine Zeit und Energie hatte, sich mit irgendetwas
abgesehen von seiner Spezialsoftwarekomponente zu beschäftigen.
Ich fasse mittlerweile nichts an, bei dem ich nicht hinreichend sicher
bin, daß die "Genialität" sich so stark in einigen Zeilen Framework
komprimiert, daß der Rest Normalsterblichen zugänglich ist, das
Framework nur in sehr ungewöhnlichen Fällen angepackt werden muß, und
dann eben so kompakt vorliegt, daß jemand mit den ausreichenden
Hirnkapazitäten die schweren Brocken nicht weitverteilt aufstöbern muß.
--
David Kastrup
Dirk Ruth
Guest
Guest
Tue Feb 23, 2010 3:33 pm
David Kastrupschrieb:
"
Quote:
Thomas Meier <antispam42_at_spamspam.invalid> writes:
Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Das ist ja i.a. auch gar nicht Sinn der Sache. Wenn man der einzige in
der Firma ist der eine bestimmte Softwarekomponente durchblickt ist
das bestimmt kein Nachteil.
Haha. Wenn es unmöglich wird, eine Abteilung weiter an den Kundenbedarf
zu skalieren, weil der Durchblicker in der Firma bereits 60h arbeitet
und seinen Urlaub verfallen läßt, dann wird die Abteilung aufgelöst.
Weil ja schließlich eh keiner die Produktivität weiter erhöhen kann.
Die Kundenacquise wird dann an die voraussichtliche Burnoutrate des
hochgelobten gut bezahlten Durchblickers angepaßt.
Wenn er langsam genug ausbrennt, ist sein Knowhow nach Ziehen der
Notbremse (durch ihn oder Management) für den Arbeitsmarkt nicht mehr
brauchbar, weil er keine Zeit und Energie hatte, sich mit irgendetwas
abgesehen von seiner Spezialsoftwarekomponente zu beschäftigen.
Ich fasse mittlerweile nichts an, bei dem ich nicht hinreichend sicher
bin, daß die "Genialität" sich so stark in einigen Zeilen Framework
komprimiert, daß der Rest Normalsterblichen zugänglich ist, das
Framework nur in sehr ungewöhnlichen Fällen angepackt werden muß, und
dann eben so kompakt vorliegt, daß jemand mit den ausreichenden
Hirnkapazitäten die schweren Brocken nicht weitverteilt aufstöbern muß.
Oder gib sie einem anderen und frag ihn, ob er was damit
anfangen kann.
Das ist ja i.a. auch gar nicht Sinn der Sache. Wenn man der einzige in
der Firma ist der eine bestimmte Softwarekomponente durchblickt ist
das bestimmt kein Nachteil.
Haha. Wenn es unmöglich wird, eine Abteilung weiter an den Kundenbedarf
zu skalieren, weil der Durchblicker in der Firma bereits 60h arbeitet
und seinen Urlaub verfallen läßt, dann wird die Abteilung aufgelöst.
Weil ja schließlich eh keiner die Produktivität weiter erhöhen kann.
Die Kundenacquise wird dann an die voraussichtliche Burnoutrate des
hochgelobten gut bezahlten Durchblickers angepaßt.
Wenn er langsam genug ausbrennt, ist sein Knowhow nach Ziehen der
Notbremse (durch ihn oder Management) für den Arbeitsmarkt nicht mehr
brauchbar, weil er keine Zeit und Energie hatte, sich mit irgendetwas
abgesehen von seiner Spezialsoftwarekomponente zu beschäftigen.
Ich fasse mittlerweile nichts an, bei dem ich nicht hinreichend sicher
bin, daß die "Genialität" sich so stark in einigen Zeilen Framework
komprimiert, daß der Rest Normalsterblichen zugänglich ist, das
Framework nur in sehr ungewöhnlichen Fällen angepackt werden muß, und
dann eben so kompakt vorliegt, daß jemand mit den ausreichenden
Hirnkapazitäten die schweren Brocken nicht weitverteilt aufstöbern muß.
Meine Rede. Besser hätte ich das nicht ausdrücken können.
Dirk
elektroda.net NewsGroups Forum Index - Electronics DE - Einstieg finden CC²-ATmega oder doch besser 8051
