@schumi:
Was man sehen kann sind die Hardware-Abbildungen der AVR-Controller, es fehlt aber noch Einiges. Ich denke da an Software-SPI und Software-UART um ein paar Beispiele zu nennen. Ich entwickle Software in verschiedenen Sprachen, von Assembler bis Java. Der Compiler selbst wird mit RealStudio entwickelt, was die Möglichkeit für zusätzliche Linux und Apple-Binarys eröffnet.
@thewulf:
Mitwirkende sind Willkommen. Ausgetestet werden soll inwieweit Designfehler innerhalb der Sprache existieren und ob eigene Projekte portiert werden können. Der Themenbereich meiner Projekte ist auf meine eigenen Anforderungen eingeschränkt. Andere Entwickler haben auch andere Schwerpunkte. Hier sollen die sicher noch vorhandenen Schwächen aufgezeigt werden. Fehlersuche natürlich ebenso.
Ich habe auch keinen wirklichen "Bedarf" gesehen. Wenn man aber so herangeht, müsste man ehrlich sein und sagen, dass es für das iPhone eigentlich auch nie wirklich einen "Bedarf" gab, es gab zu damaliger Zeit ja genügend Nokias in ausreichender Größe, Form und Farbe.Ein gewaltiges Projekt. Aber brauchen wir das wirklich? Ich sehe den Bedarf nicht.
Das Projekt ist entstanden, weil ich es einfach machen wollte: Eine eigene Programmiersprache mit bestimmten Ideen die ich für die Programmierung nützlich erachte (Beispiel: Objektbasierung). Im Verhältnis ist der Aufwand für Mikrocontroller vergleichsweise gering. Jetzt stelle ich das Projekt hier vor, nicht mehr und nicht weniger. Einfach um zu schauen, ob es Andere interessant finden und ihnen als Werkzeug nützlich wäre.
Auch stelle ich das Projekt absichtlich in seiner Entstehungsphase vor, damit interessierte Anwender oder Entwickler die Möglichkeit haben frühzeitig an der Gestaltungsrichtung teilzuhaben. Es mag in seinem momentanen propritären Zustand für meine Zwecke und meine Schwerpunkte ausreichen, wird es aber sicher nicht für Andere. Ich werde in naher Zukunft eine Testversion zusammenstellen, die es den einzelnen ernsthaft Interessierten erlaubt sich ein Bild zu machen, Fehler aufzuzeigen, Richtungsempfehlungen zu äußern oder selbst z.Bsp. an dem Bibliothekscode mitzuwirken. Die bis dahin anstehenden wichtigen Fragen die sich vorab stellen, möchte ich jedoch im Vorfeld klären, nicht erst wenn viele Stunden möglicherweise sinnloser Arbeit Mehrerer investiert sind.
Das sind kürzere Bearbeitungszeiten von Routinen und wirkt sich beispielsweise auf umfangreiche Berechnungen die in gewissen Programmbereichen in Echtzeit erfolgen müssen oder in Interrupt-Serviceroutinen aus.Wie kann man sich diesen Performancegewinn vorstellen? Höheren Motordrehzahlen möglich oder kompliziertere Instrumente?
Dazu ein Beispiel:
Die ersten Versionen einer programmierbaren Zündsteuerung habe ich in Bascom geschrieben. Nun muss man wissen, dass hier neben der einfachen Timerei, der Echtzeitberechnung von bestimmten Werten auch weitere Sensorik dazu kam wie Temperatur und Lastzustand usw. Zusätzlich noch die Echtzeitkommunikation mit der PC-Software, Anzeige und Modifikation aktueller Werte. Hier musste ich feststellen, dass bei der Ausgabe über UART Variablen durch die Interruptroutinen überschrieben wurden und auch die parallele Kommunikation während des Betriebs instabil war. Hier kam man technisch einfach an die Grenzen, egal wie man optimiert hat.
Schlussendlich hab ich das Ganze verworfen und alles in Assembler geschrieben. Ab diesem Zeitpunkt ist die Echtzeitberechnung verbliebener Werte (Vorberechnung mit Tabellen fand schon statt) in seiner Dauer von 300 µs auf 30-68 µs pro Signal geschrumpft, die Echtzeitkommunikation stört die Timer nicht mehr und Variablen werden nicht mehr überschrieben. Da Assembler mächtig tipparbeit ist und ich schon eine eigene große Funktionsbibliothek erstellt hatte, dachte ich man könne das Ganze ja auch einfacher haben und eine eigene Sprache schreiben. Der Code ist aus LunaAVR ist dadurch prinzipiell derselbe wie in meinen Assemblerversionen. ..und ja, dadurch sind auch höhere Drehzahlen möglich.
Gruß, rgf
Zitieren
Zitat von Wsk8
Lesezeichen