Das stimmt. Bei mir ist bisher nur der Startup-Code in Assembler. Der Keil optimiert so sauber und den Startup-Code liefert der auch noch für alle Typen mit, da muss man selten mal ran.
73 de Tom-- DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Thomas 'tom' Malkusschrieb: "
Also auch der Bastler will sicher mal, wenn er über den Anfängerstatus mit LED blinken usw. hinausgekommen ist, ein Display o.ä. anschließen. Dann ist es aus mit 8bit und 8051. Dann wird es selbst für einen
16bitter schwierig.Wenn ich schon 16bit-Register habe (Timer, Capture/Compare, PWM), dann würde ich schon ganz gern auch mit 16bit rechnen. Zumal der Preisunterschied für einen Bastler zwischen 8-/16- und 32bit völlig unerheblich ist.
Als nächstes stellt sich dann die Frage, ob ich stumpfsinnige Kernelfunktionen schreiben (nochmal neu erfinden), oder doch lieber gleich zu einem embedded OS greife und mich lieber um meine Applikation, also meine eigendliche Anwendung kümmern will.
Dirk
^^^^^^^^^^^^^^^^^^^^^ Das führt dann zur Gretchen-Frage: Welche Randbedingungen hat die angepelite Anwendung? Um einen Sensor auszulesen und den Wert zur gefälligen Betrachtung auf einem Display darzustellen, benötigt man nicht wirklich ein Betriebssystem. Wenn die Messwerte in Formeln integriert und über Ethernet abgefragt werden sollen, sieht es schon anders aus. Und wenn es um zeitkritische Messungen geht, hat man es mit einem anderen BVündel von Schlangen zu tun.
------
-- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
Am 20.02.2010 20:13, schrieb Dirk Ruth:
Du meinst man sollte, wenn AVR's genommen werden, die verh...sten von C...ad nehmen?
Wenn man sich die Compiler anschaut und die existierenden kostenfreien Bibliotheken, so kann man bei modernen Entwicklungswerkzeugen fast vom System sprechen. (Außerdem kann man das Rad nicht mehr neu erfinden,
Das kann der Bastler auch gerne tun. Ich werde keinen 32 Bit Controller für eine Steuerung einsetzen, bei der ein 8 Bit Controller ausreichend ist.
Es gibt Anwendungen, die brauchen keine 32 Bit, keinen 16 Bit und auch kein Embedded OS. Ich verwende auch 32 Bit ARM Controller mit Linux als OS. Aber deswegen setze ich das nicht für jede kleine Steuerung ein, mal abgesehen davon, dass ein OS auch höchst hinderlich sein kann.
Es gibt genügend Anforderungen für 8 Bit Controller, es gibt genügend neue Controller mit 8051er Kern und entsprechend Second Source.
Aber die Leute, die mit den Controllern umgehen können werden immer weniger, weil alle Welt 32 Bit mit Embedded OS und Superdisplay haben will.
Mir nur recht ;-)
73 de Tom-- DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Stefan Englerschrieb: "
Was für Buchstaben muss ich da jetzt einsetzen? Ist das ein Einstellungstest?
Schöner Link ;-))
Dirk
Das schrub ich auch nicht.
Das schrub ich auch nicht.
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 mittelständischen Firmen gesehen, wo Leute schon seit 15 Jahren jeden Tag Software entwickeln. Da gibt es einige klassische Probleme, wo immer wieder ohne Ende irgend etwas zusammengemurkst wird, weil es ohne OS einfach keine guten generischen Lösungen gibt. Einige Beispiele könnte ich hier nennen.
Auch die hier oft empfohlenen AVR-Seiten im Internet sind fast ausnahmslos ein Quell vermurkster Software, die nur funktioniert, wenn es auf den Controller läuft, dessen Header oben includiert ist und der am gleichen Quarz läuft. Da sieht man dann tolle Software-Beispiele, wo sich über Seiten immer eine Zeile echten Codes mit einer while-Schleife für ein delay abwechselt. Wenn man solchen Müll einem Anfänger gibt, dann kann man auch nicht erwarten, dass der irgenwann mal besseren Code schreibt. Wenn man sieht, dass auf der Applikationsebene irgendwelche Bits in irgendwelchen Hardware-Registern gedreht werden, dann kann einem einfach nur noch schlecht werden. Hatte auch schon so einige Projekte, die über ein paare Jahre gewachsen waren und schon den ein oder anderen Prozessorwechsel hinter sich hatten. Da blieb dann nur noch alles wegzuschmeißen und komplett neu anzufangen, weil durch den vermurksten Code neu machen einfach billiger war. Schade um die Zeit die da drin steckte.
Gute generische und portable Lösungen zu entwickeln ist weitaus schwieriger, als irgendwelchen Code, den man gerade in Gedanken hat runter zu tippen, vielleicht noch in Kombination mit Timings, die man ebend mal schnell mit dem Scope ausgemessen hat.
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. Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher auch für einen Anfänger von Vorteil sein. Das ist dann so, als wenn der Heimwerker mit gewerblichen Werkzeugen arbeitet.
Dirk
Dirk Ruth schrieb:
...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.
Lass mal die Kirche im Dorf. Hier ging es nicht um Produkte, die in Tausender Auflagen über 10 Jahre hinweg zu bauen und zu pflegen sind.
MISRA scheitert für einen Hobby-Anfänger schon daran, dass es Geld kostet. 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. Selbst die neueren des aktuellen C-Standards (der ja auch noch aus dem letzten Jahrtausend stammt) haben dort noch keinen Einzug gehalten, damit kann ich das Teil einem Anfänger nicht mehr als "große Leitlinie" guten Gewissens vorsetzen. Ich weiß, es gibt auch genügend Compiler-Hersteller, die zu faul sind, sich dieses C-Standards mal anzunehmen. Den sollten aber die Kunden, die schließlich dafür Geld zahlen, mal auf die Finger klopfen, dass sie das auch haben wollen, nachdem Opensource das ja nun schon eine ganze Weile hat.
-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Der Autor dieses bekannten Buches:
Das ist dann wohl die "generische Lösung" die Portabilität, Einheitlichkeit & viele andere Sekundärtugenden propagiert.
MfG JRD
Definiere "generisch und portabel". 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. 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.
Unter
bekommt man einen Teil der Regeln in knapper Form. Außerdem gibt es unter auch noch einen Satz Codierregeln.
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.
Stefan
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 :-)
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@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
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.
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
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.
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
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.
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.
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.
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
Am 22.02.2010 04:10, schrieb Dirk Ruth:
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.)
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
Dirk Ruth ( snipped-for-privacy@itecnet.de):
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.
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.
Das ist schon klar ;-). Ich habe, wie jeder andere wohl auch, einen ganzen Stapel fertige Routinen, die sich immer wieder verwenden lassen.
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
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.
Thomas 'Tom' Malkusschrieb: "
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
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
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.