Einsteig in Microcontroller und Programmierung

Ja, vor allem, weil man sich dann sicher sein kann dass der Programmierer in Timbuktu den Code von den Jungs hinterm Ural einfach so weiterbearbeiten kann. In der Industrie sind Kompatibilitaet und wenig Versionswechsel alles. Das ist letztlich auch der Grund, warum im Buero MS-Word zumindest in Nordamerika der Standard ist, mit dem ungeschriebenen Gesetz alles auf 97-kompatibel zu lassen. Ueber 12 Jahre de-fakto keine Versionsaenderung bei den Dateien, das ist schon was handfestes.

Ist meist nicht komplett portabel möglich weil Interruptroutinen in ANSI- C nicht spezifiziert sind, also immer per Compiler-Erweiterung realisiert werden müssen. Selbst gcc hat keine einheitliche Syntax für verschiedene Architekturen.

Ich schreib alles, also auch Interrupt-Handler in C. Nur wenn CPU- Spezialbefehle nötig sind muß mal ein Stück Assembler her. Ist immer lästig.

Mit Effizienz oder der "CPU-Bit-Zahl" hats nix zu tun. Assembler ist in der Praxis nicht effizienter. Noch nicht mal auf einem 8052.

Haste mal gemessen wie lange Forth dazu braucht (in Instruktionen)?

In C siehts so aus: PORTx |= 1 Interpretermodus. Was das für Testen von Hardware und Programm- teilen

Doch kann ich. Das ist ein echter Vorteil wenn man mal was ausprobieren will. Dreifach hoch für Forth.

Ist ja jämmerlich. Forth ist so lahmarschig, daß man zum Einsatz von Assembler gezwungen ist? Herzliches Beileid. Mit C wärs nicht passiert.

Stimmt. Je nach CPU sind das 2 bis 30 Instruktionen.

Außerdem brauchts manchmal ein, zwei Assemblerinstruktionen hier und da, z.B. für Idle-Mode und so.

Nirgendwo. Leider kapiert das nicht jeder.

dafür kennt fast jeder Compiler inline Assembler Befehle

Es ist immer die alte Diskussion ... und programmieren tut der Zahnarzt am Wochendende für seine Familie ;-))

Einfach mal den ganzen Artikel lesen: In dem Projekt geht es darum, aus alten Keyboards moderne Controller zu machen, mit denen man dann die bekannten Sythisizer-Programme ansteuern kann. F=C3=BCr Dich interessant d=C3=BCrfte vor allem das Interface zu = der vorhandenen, analogen Keyboard-Elektronik sein.

Mit den MIDI-Signalen wiederrum kann man =C3=BCber einen entsprechenden Controller auch analoge Synthis ansteuern.

Wolfgang

Hä? Schon mal überlegt, wo der "Junge hinterm Ural" das Geld für den kommerziellen Compiler hernehmen soll?

Hä? Wenig Versionswechsel? Die IT-Industrie kannst du nicht meinen...

Erinnert mich an die letzten Tage der DDR: "Stabilität durch Stagnation!"

GW-BASIC ist auch seit ca. 20 Jahren unverändert. Trotzdem würde kein Mensch auf die Idee kommen, das heute zu verwenden.

Und was soll das mit Open vs. Closed Source zu tun haben? GCC übersetzt

Unter aktuellen Linuxen tut 12 Jahre alte Hardware immer noch bestens. Ein aktuelles Windows sagt nur lapidar "kein Treiber gefunden". Closed Source liefert dich auf Gedeih oder Verderb den Launen des Herstellers aus. Wenn man Beständigkeit will, *braucht* man Open Source. Weißt du, ob dein Word97 auf Windoze 7 noch laufen wird? Open Office wird mit

XL

Aehm, manche der Jungs haben sich das alles vermutlich "besorgt".

Noe, schon den Compiler. Da mutete manche Bedienoberflaeche wie das Armaturenbrett eines Opel Kadett B an, aber es funzte alles.

Mitnichten. Hier behaelt man, was gut laeuft. Genauso wie es die Schaltuhren aus den Fuenfzigern noch heute im Baumarkt zu kaufen gibt. Weil die auch bei Gewittern nicht kaputtgehen. In der DDR haette es die vermutlich auch gegeben, mit 10 Jahren Wartezeit oder so ;-)

BW-Basic nicht, aber VBA. Das ist vielleicht noch keine 20, aber m.W. hat es deutlich ueber 10 Jahre auf dem Buckel. Dann haetten wir da noch die ganzen ISA-Bus Geraetchen.

Hab' ich doch nicht gesagt.

Nur dass ausser Akademikern kaum einer TeX benutzt ...

Das hat bisher nur Vista gewagt und ergo hat das hier Hausverbot. Mit XP ging alles von nagelneu bis Asbach Uralt.

Bestaendigkeit hiess bei Bekannten in der Vergangenheit oft "Dafuer gibt es keinen Linux Treiber, das kann ich nicht ansprechen". Z.B. bei Messgeraeten, und gerade da kann ich mir sowas beruflich nicht leisten.

Wenn nicht, bleibt es genau wie Vista draussen. Ich denke aber, das kriegen sie hin.

Warten wir's ab. Letztens hatte jemand (mit Prorammierahnung) versucht, KiCad etwas abgeaendert zu compilieren. Irgendwann nach der x-ten Fehlermeldung hat er's genervt drangegeben.

Es geht nicht um das Geld fürn Compiler, sondern dass der Junge aus dem Ural 8051 und c beherscht.

IT Industrie ist nicht die reale Welt ;-)

In einer Welt, wo Daten nach 10 jahren und mehr noch zur Verfügung stehen müssen ist das schon ein Problem.

Denk mal nach .. warum sollte ein Hersteller, dessen Innovation in Software steckt seinen Source code veröffentlichen wollen ?

GCC übersetzt

Was nützt mir TeX bei einem 20 Jahre alten Word Dokument ? Willkommen in der realen Welt ;-))))

naja ... für Linux 0.9 ohne deutschen Tastaturtreiber und ohne x-Windows kann ich dir zustimmen ;-))

jetzt mal im Ernst du bekommst jedes mal, wo du einen PC mit Linux kaufst bekommst du etwas völlig anderes. Ich hatte in der Vergangenheit schon öfters mit kommerziellen Linux Anwendungen im 50k Euro Bereich zu tun, die nie problemlos auf neuer Hardware bestellt und gekauft werden konnten. Dafür aber öfters mit Linux "Freaks" die sich mehr mit Linux als mit ihrer eigendlichen (bezahlten) Arbeit beschäftigtt haben ..

Du weißt worauf ich hinaus wollte? Der Syntax mag von Compiler zu Compiler im Funktionskopf und in der Deklaration marginal verschieden sein, wenn ich bei einem Hersteller bleibe ist er sogar gleich,und notfalls schreibe ich ein Makro, dass den Syntax umsetzt. Das sind Compiler abhängige Unterschiede.

Mir ging es bei der Portabilität darum, dass ich keine Controller Abhängigkeiten mehr habe um somit schnell und kostengünstig die Plattform wechseln zu können, weil die Hardware hinter einer Art Treiber-Interface verborgen ist. Wenn ich in der ISR Bits kippen muss, dann muss ich mir jedesmal aufs neue klar machen, welche in welcher Reihenfolge gekippt werden müssen.

Dirk

Eine Programmiersprache hat erstmal überhaupt keine Geschwindigkeit, es kommt auf die Implementierung drauf an. Implementierungen von Sprachen mit vielen Dingen, die erst zur Laufzeit gemacht werden können, wie den Typ eines Objekts ermitteln, sind allerdings generell langsamer, als Implementierungen statischer Sprachen wie Forth oder C. Forth ist dabei allerdings keine rein statische Sprache, wie C, da man einige Dinge zur Compilierzeit anstellen kann und im interaktiven Modus, was in C so nicht vorgesehen ist. Man könnte zudem durchaus ein Forth-System entwerfen, was das genauso optimiert umsetzt, wie es manche C Compiler können.

Schon gut. Portabilität heißt in dem Fall eben ein einige wenige Zeilen neu schreiben und per #ifdef einzubauen. Das ist das kleinste Problem.

Nur wenn die Peripherie nicht im Controller integriert ist. Andernfalls heißts Datenblatt lesen und neu schreiben.

Wenn der Compiler und CPU aufeinander abgestimmt wurden ist es kein Wunder. So gibt es bei AVR f=FCr viele C-Befehle direkte Entsprechungen der CPU-Befehle. Ist wohl auch bei Java vergleichbar. Wenn der CPU fast mit Jasmin arbeitet, so ist der Java-Interpreter auf der CPU sehr fix. (Jasmin hat einige Besonderheiten in der Speicherverwaltung, die ein CPU auch beherschen sollte, da sonst die Programme m=FChevoll interpretiert werden m=FCssen).

Intel k=E4mpft halt mit der R=FCckw=E4rtskompatibilit=E4t, sodass sie noch keine M=F6glichkeiten hatten den Pentium gro=DF f=FCr C oder C++ zu optimieren.

Jedenfalls ist es beim AVR Geschwindigkeitsm=E4=DFig fast egal ob nun in C oder Assembler. Nur bei komplexen Timings muss in Assembler gearbeitet werden, da z.B. beim USB-Treiber es wichtig ist wann ein Befehl ausgef=FChrt wird. Bei verlangten 50ppm Timinggenauigkeit kann man sich nicht an die Zuverl=E4ssigkeit eines C-Compilers binden.

Joerg schrieb:

P=20

Zeig mir doch bitte den Treiber f=FCr meinen Rio PMP300. Und ob es der=20 Scanmaker E6 (Achtung! SCSI) unter XP noch tut, wei=DF ich auch nicht.

Guido

Dirk Ruth schrieb:

Hallo,

auch wenn alles wunderbar portabel geschrieben ist, etwas so hardwarenahes wie eine Interruptroutine wird man an den konkreten Prozessor anpassen müssen. Wenn der Prozessor nur einen kleinen Teil seiner Gesamtzeit in Interruptroutinen verbringt und auch keine sehr schnellen Antwortzeiten notwendig sind ist es egal ob man den Interrupt mittels C oder Assembler verarbeitet. Nur bei den inneren Schleifen bei Bildverarbeitung habe ich mal mit Assembler wirklich merklich Zeit einsparen können. Wenn nur ein kleiner Teil der gesamten Software wirklich zeitkritisch ist muß man auch nur den möglichst effizient implementieren.

Bye

Richtig, dafür bedienen die sich gerne mal bei Open Source-Projekten, nach dem Motto "wird ja schon keiner merken" und "sollen die uns ruhig verklagen, diesen Kommunisten glaubt doch eh keiner". Zum Glück wird da gegenangegangen:

Das Problem ist, das Leute "Linux" für das Gesamte halten, Linux ist nur der Kernel, das "Drumherum" ist dann eine Distribution und die unterscheiden sich doch erheblich.

Gruß Henning

Tja, da habe ich mit einer US Robotics ISDN-Karte und einer Intel Videokonferenzkarte andere Erfahrungen gemacht. Leider gab es für diese Hardware nie Linuxtreiber. Dafür habe ich sie aber auch aus der Schrottkiste ziehen können. :-)

Und an wem liegt das? "Treiber" ist USB- oder seriellen Geräten sowieso ein zu hoch gegriffenes Wort, diese Geräte lassen sich bequemst mit Userspaceanwendungen ansprechen, die Ausrede, sich nicht in Linuxtreiberentwicklung einarbeiten zu wollen, zieht da also nicht.

Es gibt halt den Kompromiss zwischen Kosten und Nutzen. Um das Ur-SPICE mit einem aktuellen GCC kompilieren zu können, musste ich auch einige Zeit hineinstecken. Das ist jetzt allerdings auch schon eine Weile her und war WIMRE ein GCC 4.0, mit 4.3 habe ich es noch nicht probiert.

Gruß Henning

Halten wir mal fest: dein Argument *gegen* Open Source ist, daß der "Junge hinterm Ural" sich den kommerziellen Compiler "besorgen" kann, den Open Source Compiler hingegen ganz legal für umme bekommt. Hab ich das richtig verstanden? An der Argumentation mußt du noch arbeiten.

Ein Compiler hat nicht sowas wie eine "Bedienoberflaeche". Die Werte eines Compilers liegen im Inneren. Ein C-Compiler sollte z.B. einen standardisierten Sprachumfang komplett[1] und fehlerfrei unterstützen. Z.B. würde man heute erwarten, daß ein C-Compiler C99 kann (dieser Standard ist ja auch schon 10 Jahre alt). Irgendwie habe ich leichte Zweifel, daß ein 15 jahre alter C-Compiler für 8051 diese Kriterien erfüllt.

VBA hat sich aber mit Sicherheit inkompatibel verändert. Der Vorgang heißt "Evolution". OK, da hast du anscheinend Probleme mit...

Hast du wohl. Lies dein Geschreibsel nochmal.

Was willst du mit diesem Argument denn bitteschön belegen? Nach deiner Meinung ist heute ja auch die Mehrheit der Inschenöre zu blöd für Analogtechnik. Würdest du das als Argument gegen die Verwendung von Analogtechnik akzeptieren?

Ich hab hier Hardware, die wollte schon Win9x nicht mehr kennen. Tip: die Welt ist hinter deinem Horizont *nicht* zu Ende!

Klar, wenn es nie einen Linux-Treiber gab, dann wird es den wohl auch weiterhin nicht geben. Das ist in 99% der Fälle aber die Schuld des Herstellers, weil er weder

a) selber einen Linux-Treiber bereit stellt noch b) Dokumentation (und idealerweise Hardware) bereitstellt, damit Dritte die Arbeit machen können die eigentlich seine wäre

Aber wenn es einmal einen Treiber für Linux gab, dann wirds den auch in *sehr* langer Zukunft noch geben. Und der wird dann auch auf x86 genauso tun wie auf x86_64 oder mips oder sonstwo. Windows-Treiber gibts meist nur für x86 und das gerade angesagte Windoze.

XL

XL