Hallo, ich möchte euch meinen Oberoncompiler für die C16x-Familie vorstellen. Der Compiler erzeugt sauber strukrurierten Assemblercode, der mit einem Assembler wie AS von Alfred Arnold assembliert werden kann. Daher ist es auch möglich direkt Assemblercode in das Oberonmodul einzubinden, wodurch auch die Dinge die der Compiler nicht unterstützt genutzt werden können. Der Compiler ist in Pascal geschrieben und sollte sich auf allen Systemen die der FPC unterstützt nutzen lassen. Im Anhang erstmal eine Zusammenfassung darüber was bisher geht, das obligatorische Beispiel und Executables für Windows und Linux zum Spielen. Ich habe noch eine Menge weiterer Beispiele, Tools und Dokumentationsfragmente, bei Interesse liefere ich die gerne nach. Den Sourcecode gibt es bei Interesse demnächst via SVN. Wegen der Opcodekompatibilität sollte der Compiler auch die neueren Derivate wie XC16x und XE16x unterstützen, dazu müsste aber eventuell der Startupcode angepasst werden. Dies ist außerhalb des Compilers möglich, konnte von mir mangels Hardware aber nicht getestet werden. Interessiert sich jemand dafür, Guido
Alex W. schrieb: > Ist das nicht Pascal? Siehe http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 Zitat: Oberon, 2000 offiziell in ETH Oberon umbenannt, ist eine von Niklaus Wirth und Jürg Gutknecht entwickelte, objektorientierte, streng strukturierte Programmiersprache. Sie ist den ebenfalls von Wirth entworfenen Vorgängern Pascal und Modula-2 recht ähnlich, allerdings strukturierter als Pascal und mächtiger, gleichzeitig aber erheblich weniger umfangreich als Modula-2.
Für das SVN bekommt man wohl nicht so einfach Zugriff, deshalb der aktuelle Stand als tgz. Momentan bin ich dabei strukturierte Variablen als variable Parameter zu implementieren. Dies ist für mich Voraussetzung für den Modulimport. Es sind Buildskripte für Linux und Windows dabei, eventuell müssen für die ausführbaren Dateien die absoluten Pfade hierin eingefügt werden. Ich habe noch ein paar umfangreichere Beispiele hinzugefügt, dabei nur Buildskripte für Linux, die lassen sich ja aber leicht in .bat umwandeln. Viel Spaß damit, Guido Achso: Einen Artikel im Wiki habe ich unter OberonC16x angelegt, vielen Dank an Gjlayde für das "Wikifying".
Arrays und Records können jetzt an Prozeduren als variable Parameter übergeben werden. Im .tgz (wäre .zip vernünftiger?) sind wieder Executables für Linux und Windows. Als Demo habe ich das CAN-Beispiel entsprechend angepasst und es gefällt mir so schon viel besser ;-). Die Doku habe ich angepasst und noch einen Abschnitt zur Speicherverwendung angehängt. Viel Spaß, Guido
Hallo Guido, find ich echt gut was Du da machst - aber leider ca. 5-10 Jahre zu spät. Die C16X-Familie war sehr weit in der Industrie verbreitet. Heute wird sie in neuen Entwicklungen durch ARM-Cores ersetzt. Die Controller-Familie ist viel zu teuer in der Herstellung. Infinieon und ST (C16X = ST10X) werden den Produktionsprozess nicht mehr aus Kostengründen umstellen. Für den Controller gab es keinen freien Compiler, für eine Entwicklungsumgebung musste man ca. 3000-5000€ hinlegen... Daher haben viele auf einen freien Compiler (Basic, Pascal oder C) gewartet. Werde Dein interessantes Projekt weiter verfolgen - viel Erfolg!!!
Hallo C167, danke für die Ermunterung. So arg veraltet ist die Familie noch nicht, die letzten Mitglieder sind ja erst vor ca. 3 Jahren auf den Markt gekommen (XE16x) und werden sicher noch lange produziert werden. Für das Hobby ärgerlicher ist die schlechte Verfügbarkeit, es ist ja fast unmöglich sowas zu kaufen (Darisius ist wohl der einzige Anbieter). Mit den ärmlichen Controllern hast du natürlich recht, in meiner ursprünglichen Planung war die C16x-Version nur ein Framework, das ich auch für andere Controller nutzen kann (oder auch jemand anders). Aber da ist mir wohl Astrobe zuvorgekommen, die Australier hatten wohl aber auch Wirths Code zur Verfügung (das kann ja jeder). Gruß, Guido
Hallo Guido, > die letzten Mitglieder sind ja erst vor ca. 3 > Jahren auf den Markt gekommen (XE16x) und werden sicher noch > lange produziert werden. Da gebe ich Dir recht, dass die µC noch lange produziert werden. Der Grund ist, das die C16X vor ca. 10 Jahren Quasie der Industriestandard in Deutschland für 16biter war (8biter 8051). Es gibt sehr viele ältere Automotiv- und Indusrieprodukte, die den Controller immer noch einsetzen, die noch mehrere Jahre verkauft werden. Die XE16x (oder ST10F2XX) ist eine Laufzeitverlängerung der Produkte, ohne aufwendiges Redesign - nicht mehr! Jedoch sind die Controller "not recommended for new design". ST setzt beim ST10FXXX ganz auf STM32XXX Preisunterschied von ca. 5:1 und das bei einem Leistungsunterschied von ca. 1:7. Die Strategie bei Infineon ist mir allerdings nicht ganz klar. In den meisten aktuellen spezial Chip-Lösungen setzen die ARM-Cores ein. Aber eine eigene ARM-Controller Familie haben sie, meines Wissens, nicht. Es gibt halt schon zuviele Anbieter. Infineon konzentriert sich auf High-Performance 8biter (XC800), was jedoch auf lange Sicht keinen Erfolg haben wird. Viele herausragende Leistungsmerkmale, die den Erfolg der C16X-Famile ausmachten, hat ARM in der Cortex-Reihe übernommen. Dies ist auch der Grund warum es sowenig Resonanz auf Deine tolle Arbeit hier im Forum gibt. Trotzdem, bastle an Deinem Compiler bitte weiter!
C167 schrieb: > Die XE16x (oder > ST10F2XX) ist eine Laufzeitverlängerung der Produkte, ohne aufwendiges > Redesign - nicht mehr! Zum Glück, daher Opcodekompatibel. Aber mit MAC-Unit und deutlich mehr Dampf. > Jedoch sind die Controller "not recommended for new design". > Dazu finde ich nichts, auch nicht bei den XC2xxx. > ST setzt beim ST10FXXX ganz auf STM32XXX Preisunterschied von ca. 5:1 > und das bei einem Leistungsunterschied von ca. 1:7. > Wobei die ST-Derivate wohl noch teurer sind als die Originale und ebenso schwer zu bekommen. > Die Strategie bei Infineon ist mir allerdings nicht ganz klar. Gibt es sowas überhaupt bei Infineon? > Viele herausragende Leistungsmerkmale, die den Erfolg der C16X-Famile > ausmachten, hat ARM in der Cortex-Reihe übernommen. Muss ich mal genauer anschauen. Beim Compilerbau merkt man sehr schnell, wie genial die C166-Familie designed war. Wenn man bedenkt, dass das noch Siemensianer waren, die damals ja wie Beamte belächelt wurden. > Trotzdem, bastle an Deinem Compiler bitte weiter! Klar, der Modulimport fehlt ja noch ;-). Gruß, Guido
Hallo an Alle, > Für das Hobby ärgerlicher ist die schlechte Verfügbarkeit, es ist ja fast > unmöglich sowas zu kaufen. Also wenn jemand Interesse hat, habe noch sehr viele, teilweise original verpackte, Typen: - 144 x SAF-C167CR-LM - 17 x ST10F167-Q6 - 26 x ST10R167-Q6 - 24 x ST10F168-Q6 - 25 x ST10F269-Q3 - 154 x ST10F275-CAA - 20 x SAK-C164CI-LM - 20 x SAK-C161CS-32FF - 20 x SAF-XC164CS Bei Interesse kurze Nachricht hier im Forum.
Hallo C167, ein paar davon könnte ich schon gut brauchen, insbesondere ST10F269 und/oder XC164. Eventuell auch wenige der älteren, dann kann ich den ROMemulator mal wieder benutzen. Für St10F275 finde ich kein Datenblatt, soviel Flash werde ich aber wohl auch nicht brauchen. Gruß, Guido
Hallo Guido,
> Für St10F275 finde ich kein Datenblatt.
Der ST10F275 war nur kurz im Programm. Die Daten kannst Du dem Flyer
entnehmen.
STM produziert eigentlich hauptsächlich ST10F276. Nach dem Testen wird
der Typ bestimmt
- Alles OK (FLASH und RAM) --> ST10F276 oder höher ???
- Ein paar Speicherbänke außerhalb der Spezifikation,
dann interne Umkonfiguration und es gibt ST10F275, ST10F273 ...
Letztendlich hat man, aus wirtschaftlichen und Absatzgründen, dann ganz
auf den ST10F275 verzichtet...
Frank M. schrieb: > ebenfalls von Wirth Wieviele Programmiersprachen will denn der gute Nikolaus noch entwicklen? IMO hätte der erstmal richtig nachdenken sollen, und dann eine einzige gute zusammenbauen sollen, so wie Dennis Ritchie - Gott hab ihn seelig.
Naja, erstens ist er Professor ;-) , zweitens entwickelt man sich doch im Leben weiter und kann dann irgendwann bessere Konzepte vorlegen. C war nichts als eine Art Makrosprache für Assembler. Ich glaube, das stand auch in einem der frühen Papers zu C. Kurioserweise hat sich diese unsägliche Sprache zum Industriestandard entwickelt. Mit der Folge, daß es unendlich viele Abstürze und Datenverluste von PCs bisher gab. Wildgewordene Pointer, schreiben über die Bounds von Arrays, usw. Pascal gefällt mir übrigens auch nicht :-)
Angehängte Dateien:
-
dbg1.png
64 KB
Hallo, ein Forumsteilnehmer, mein 1. Sponsor :-), hat mich überzeugt, dass so ein Projekt ohne Source-Level-Debugger wenig Sinn macht. Also habe ich mal einen ersten Entwurf hierzu mit Lazarus erstellt. Auch an diesem lässt sich sicher noch vieles verbessern. Es gibt erstmal nur eine Linuxversion, sie ist gezipped, wodurch sie wenigstens etwas handlicher wird. Da sich der Rest der Dokumentation nicht geändert hat, hänge ich nur den Teil über den Debugger an. Der Compiler musste für diesen natürlich angepasst werden, daher noch ein neues tgz. In den nächsten Tagen werde ich versuchen, den Debugger unter Windows zum Laufen zu bringen, wenn das klappt, gibt es auch die Quellen dazu. Viel Spaß, Guido
Abdul K. schrieb: > Naja, erstens ist er Professor ;-) , zweitens entwickelt man sich doch > im Leben weiter und kann dann irgendwann bessere Konzepte vorlegen. > > C war nichts als eine Art Makrosprache für Assembler. Ich glaube, das > stand auch in einem der frühen Papers zu C. Kurioserweise hat sich diese > unsägliche Sprache zum Industriestandard entwickelt. Mit der Folge, daß > es unendlich viele Abstürze und Datenverluste von PCs bisher gab. > Wildgewordene Pointer, schreiben über die Bounds von Arrays, usw. So ein quatsch aber auch. C war und ist für die Systemprogrammierung gedacht. Und da kannst du keine Speicherverwaltung drumrumbauen. Und auch keine Arraygrenzen prüfen, schon gar nicht wenn der Speicher erst zur Laufzeit dynamisch angefordert wird. Wer soll diese Grenzen denn prüfen? Sieht man doch schon an den µC Projekten sehr gut. Wenn du zur Laufzeit speicher mit malloc anforderst, und dort ein array speicherst wie soll jemals jemand überprüfen können ob beim Zugriff darauf die Grenzen einehalten werden? Da braucht man ein Stück SW welches dies tut. nennt man auch Betriebssyste. In Fällen wo du aber ein OS selber bauen willst oder aber ohne OS auskommenst will (µC) geht das einfach nicht. gruß cyblord
Ja eben. Du schreibst es selber! C ist für das Implementieren eines BS gedacht und nicht für Anwendersoftware! Wer ein BS schreibst, ist absolut sattelfest und schreibt im Allgemeinen recht fehlerfreie Software. Der Rest der Menschheit <wie ich> ist in einer Skriptsprache besser aufgehoben. Alles wird überprüft. Da macht ein Performanceverlust von 50% gar nichts.
Abdul K. (ehydra) schrieb: > C war nichts als eine Art Makrosprache für Assembler. Ich glaube, das > stand auch in einem der frühen Papers zu C. Kurioserweise hat sich diese > unsägliche Sprache zum Industriestandard entwickelt. Mit der Folge, daß > es unendlich viele Abstürze und Datenverluste von PCs bisher gab. > Wildgewordene Pointer, schreiben über die Bounds von Arrays, usw. > Pascal gefällt mir übrigens auch nicht :-) C gefällt dir nicht, Pascal auch nicht. Was findet denn dein Gefallen? :-)
Abdul K. schrieb: > Ja eben. Du schreibst es selber! C ist für das Implementieren eines BS > gedacht und nicht für Anwendersoftware! Wer ein BS schreibst, ist > absolut sattelfest und schreibt im Allgemeinen recht fehlerfreie > Software. Der Rest der Menschheit <wie ich> ist in einer Skriptsprache > besser aufgehoben. Alles wird überprüft. Da macht ein Performanceverlust > von 50% gar nichts. Wo wird denn C heutzutage noch für normale Anwendungen benutzt? C++ wenn dann schon, und seit einiger Zeit wohl immer häufger via MFC/VisualC++ also ebenfalls komplett speicherverwaltet innerhalb .Net. Und eben bei µC (=Systemprogrammierung). Wo es ebenfalls Sinn macht. Wie schon geschrieben, du kannst nicht einfach hergehen und eine Programmiersprache bauen welche sich überhaupt nicht mit Pointern und Speicherüberlauf ausseinandersetzen muss. Denn dies erfordert eine weitere Abstraktionsschicht, also z.B. JVM bzw. .NET. In dem Moment wo du nativen Maschinencode erzeugen willst, welcher ohne eine solche Umgebung läuft, kannst du zur Laufzeit einen Arrayüberlauf oder Nullpointer nicht mehr feststellen. Hier kann am Ende nur noch das OS einen Riegel vorschieben indem es die Anwendung davon abhält ausserhalb ihres Speicherbereichs zu schreiben und sie damit killt. gruß cyblord
Forth und NET sind schonmal gute Ansätze.
Gnade bitte, dass meine kleine Implementierung solche Sachen nicht berücksichtigt, liegt doch nur an meinen begrenzten Fähigkeiten. Das richtige Oberon ist ja ein Betriebssystem und kennt natürlich Pointer und OOP, die auf diesen basiert. Die Speicherkontrolle gelingt natürlich auch ohne BS, in pascaloiden Sprachen sind die Längen aller Strukturen ja wohlbekannt. Auch hier ist es ausschließlich meine Entscheidung gewesen darauf, entgegen dem dringenden Rat N.Wirths, der mit einer Beispielimplementierung unterbaut ist, zu verzichten, da auf einem µC halt keine einheitliche Fehlerbehandlungsmethode zur Verfügung steht. Gegen Nullpointer ist wohl aber auch unter Oberon kein Kraut gewachsen, obwohl, soweit ich das überblicke, immerhin das fragwürdige nil abgeschafft wurde. Grüße, Guido
>das überblicke, immerhin das fragwürdige nil abgeschafft wurde.
Ich meine, nil ist in allen Oberon-Varianten vorhanden, wie z.B. auch in
Ruby. Eben ein per Definition ungültiger Zeiger.
Abdul K. schrieb: > Forth und NET sind schonmal gute Ansätze. Wie bitte?? Du meinst, dieses unsägliche Forth sei ein guter Ansatz? Und DotNet auch? Zu interpretierender Text als EXE verkappt? Also, Abdul, du scheinst in diesem speziellen Punkt momentan zum Stänkern aufgelegt zu sein, also beruhige dich bitte wieder. Und cyblord schrieb: > So ein quatsch aber auch. Ähem.. der Quatsch ist ganz deinerseits mit Verlaub. Angefangen hatte es tatsächlich mit Assembler-Erweiterungen wie PL/M, PLC, dann BPLC, B und dann als C Erweiterung von B. Aber das ist alles Historie und was heutzutage Bedeutung hat ist die Tatsache, daß C eben von haus aus eine unsaubere Sprache ist, bei der von Anfang an Wert auf Maschinenabhängigkeiten, Seiteneffekte und Zusammenfassungen gelegt wurde, die damals als hilfreich angesichts sehr unvollkommener Compiler angesehen wurden. Das ist heutzutage ganz anders, die Compiler sind sehr viel mächtiger geworden - aber die sprachimmanenten Seiteneffekte sind geblieben. Und genau diese sind es, die den Programmierern selbst nach jahrelanger Praxis immer wieder üble Schnitzer unterkommen lassen. Die berüchtigten Buffer-Überläufe auf dem Stack würden sich selbst mit C problemlos vermeiden lassen, wenn es denn eine strenge Typ- und Bereichsprüfung im erzeugten Code und Disziplin bei den Programmierern gäbe. Aber beides gibt es nicht. Schlampige Programmierer haben sich eine zu ihnen passende Sprache auserkoren, die Compiler bauen keine Indexüberprüfung in den erzeugten Code ein, weil ja ohnehin kaum jemand mit Indizes arbeitet, sondern allzeit Pointer benutzt werden und nun ist es wie es ist. Die meisten Fehler passieren in C beim Dereferenzieren oder beim fehlerhaften Deklarieren und anschließendem Versuch, das Ganze per Cast mit der Brechstange zu richten - wenn man mal von Bösartigkeiten wie Malware absieht. W.S.
Salewski, Stefan schrieb: > Ich meine, nil ist in allen Oberon-Varianten vorhanden, wie z.B. auch in > Ruby. Eben ein per Definition ungültiger Zeiger. Also doch noch. :-(. Woran erkennt man einen ungültigen Pointer ( = Adresse)? Wirth umgeht das Problem, indem er einen Wächterpointer namens Guard anstelle nil verwendet, dies ließ mich vermuten, dass nil vernünftigerweise obsolet ist. Danke für den Hinweis, Guido
W.S. (Gast) schrieb: > Wie bitte?? > Du meinst, dieses unsägliche Forth sei ein guter Ansatz? > Und DotNet auch? Zu interpretierender Text als EXE verkappt? > Also, Abdul, du scheinst in diesem speziellen Punkt momentan zum > Stänkern aufgelegt zu sein, also beruhige dich bitte wieder. Dein Stänkern hier ist aber auch nicht besser und zudem nicht mal wahrheitsgemäß.
W.S. schrieb: > Abdul K. schrieb: >> Forth und NET sind schonmal gute Ansätze. > > Wie bitte?? > Du meinst, dieses unsägliche Forth sei ein guter Ansatz? > Und DotNet auch? Zu interpretierender Text als EXE verkappt? > Also, Abdul, du scheinst in diesem speziellen Punkt momentan zum > Stänkern aufgelegt zu sein, also beruhige dich bitte wieder. Ich bin Hardware-Mensch, der sich mit kleinen C-Programmen noch rumärgern darf. Mehr ist da nicht. Ich brauche also eine Sprache die effektiv ist und auch nach Monaten Abstinenz noch benutzbar bleibt. Aus der Sicht eines täglichen Programmierers ist das Spielzeug, was die Software angeht. Daher kann es keine einheitliche Sichtweise geben. Ich weiß nicht was an Forth so schlimm ist. Es ist ein interessantes Konzept. Leider in Vergessenheit geraten. Aber mit Oberon hat dies nicht mehr viel zu tun.
>Also doch noch. :-(. Woran erkennt man einen ungültigen Pointer >( = Adresse)? Wirth umgeht das Problem, indem er einen Wächterpointer >namens Guard anstelle nil verwendet, Na ja, man definiert eine beliebige Adresse als ungültig -- wenn ein Pointer dort hin zeigt, ist er ungültig. Ein Pointer bzw. ein Objekt, für das noch kein Speicher angefordert wurde zeigt dann eben dort hin. Wenn mit dem Objekt gearbeitet wird, muss der Compiler stets Code für den Test auf NIL erzeugen, sofern man den Test nicht durch eine Compileroption deaktiviert. Um Speicher-Freigabe kümmert sich ja der Garbage-Collector, jedenfalls bei Oberon-2. Mit dem Guard -- war das Oberon-0, das Lehrbeispiel? Wirth hat ja eine Reihe von Oberon-Versionen gemacht -- nach Pascal und Modula.
W.S. schrieb: > Schlampige Programmierer haben sich > eine zu ihnen passende Sprache auserkoren, die Compiler bauen keine > Indexüberprüfung in den erzeugten Code ein Grumpf, dann sollte ich das doch wohl strenger handhaben? Anschiss angekommen, Konsequenzen, weiß noch nicht. :-) Aber grundsätzlich sind deine Argumente schon korrekt.
Ja Stefan, das ist mir schon klar. Aber gerade bei einem Controller mit segmentiertem Speicher, über den reden wir hier ja, gibt es keine definitiv ungültige Adresse. Ich hätte vermutet, dass dieses Problem schon in Modula beseitigt wurde. Da muss ich wohl noch mal recherchieren. Gruß, Guido
Guido B. schrieb: > Ja Stefan, das ist mir schon klar. > > Aber gerade bei einem Controller mit segmentiertem Speicher, über > den reden wir hier ja, gibt es keine definitiv ungültige Adresse. > Ich hätte vermutet, dass dieses Problem schon in Modula beseitigt > wurde. Da muss ich wohl noch mal recherchieren. > Es gibt eigentlich alles! Also Vorsicht! Bei 68K wird z.B. der Speicherzugriff vom Speicherinterface beantwortet. War glaube ich /DTACK. Kommt der nicht, gibts Exception!
Guido B. (guido-b) schrieb: > W.S. schrieb: ... > Aber grundsätzlich sind deine Argumente schon korrekt. Findest du das tatsächlich? Ehrlich gesagt kann ich nicht nachvollziehen wie man im Zeitalter der Skriptsprachen noch immer gegen Code-Interpretation polemisiert (HTML-5 lässt grüßen) und dann auch noch das falsche Beispiel dafür als Kronzeugen anführt (.NET).
>Aber gerade bei einem Controller mit segmentiertem Speicher, über >den reden wir hier ja, gibt es keine definitiv ungültige Adresse. >Ich hätte vermutet, dass dieses Problem schon in Modula beseitigt >wurde. Da muss ich wohl noch mal recherchieren. Na Du kannst doch beliebig einen Wert als ungültig definieren. Du musst nur dafür sorgen, dass Pointer mit eben diesem Wert initialisiert werden, und bei Zugriff auf Objekte auf diesen Wert testen. Wenn NIL dann sollte eine definierte Ausnahmebehandlung erfolgen. Nebenbei: Oberon war ja eher für den PC gedacht. Allerdings gab es ganz spät von Wirth eine Version für ARM, die könntest Du dir mal ansehen. Und dann gab es hier ja mal jemanden, der einen Pascal-Compiler für AVR machen wollte: Beitrag "Projekt: Pascal-Compiler für AVR" Ich persönlich kann auf einem uC mit C leben -- aber eigentlich auch nur da.
Ersa schrieb: > Findest du das tatsächlich? Meine Aussage bezog sich ausschließlich auf den zitierten Teil des Beitrags. Aber hier reden wir doch von der µC-Programmierung, naja Forth gibt es schon, aber Skriptsprachen sind in diesem Bereich doch eher unüblich.
Salewski, Stefan schrieb: > Nebenbei: Oberon war ja eher für den PC gedacht. Allerdings gab es ganz > spät von Wirth eine Version für ARM, die könntest Du dir mal ansehen. Hi Stefan, die liegt mir vor, in Form vom kommerziellen Astrobe. Dieses beruht auf den nicht veröffentlichten Quellen N.Wirths. Aber ich rede nicht von Plänen, sondern stelle hier mein funktionierendes Projekt vor. N.B.: welche Adresse würde sich für nil denn eignen? Im segmentierten Speicher gibt es diese erstmal nicht. Und initialisieren muss in pascaloiden Sprachen der Programmierer!
Schaut man etwas in den Embedded-Zukunft, wird sicherlich nur ARM übrigbleiben. Den anderen Architekturen wird die Luft ausgehen und neue sind momentan nicht in Sicht. Oder habe ich etwas verpaßt? Ja genau, richtig gelesen: Abdul prophezeit das AVR und ähnliche schon bald tot sind. Forth gibt es in Form von IPS-32 für ARM und fliegt über unseren Köpfen als 'Hochsicherheitssystem' in Amateur-Satelliten. Gut, man kann nicht alles wissen. C ist einfacher der billige Heinrich. Darauf hat sich die Controller-Welt eingeschworen. Ob man will oder nicht. So muß ich es leider auch benutzen, denn die Entwicklungsumgebungen bieten meist nur ein Assember und ein C Interface. Aber man darf ja mal über den Zaun schauen.
>wie man im Zeitalter der Skriptsprachen noch immer gegen >Code-Interpretation polemisiert Zeitalter? Beim Commodore C64 wurde Basic interpretiert. Ruby, Python usw. sind ja ganz nett, aber ich bedaure schon sehr, dass es keinen Compiler gibt. Das ist einfach eine riesige Resourcenverschwendung, C und C++ sind ja ca. um den Faktor 100 schneller. So manch Server könnte durch einen kleinen Handy-Chip ersetzt werden, wenn die Skripte gut kompiliert wären.
Guido B. schrieb: > N.B.: welche Adresse würde sich für nil denn eignen? Im segmentierten > Speicher gibt es diese erstmal nicht. Und initialisieren muss in > pascaloiden Sprachen der Programmierer! Das hängt von der CPU ab. Meist wird -1 verwendet.
Abdul K. schrieb: > Das hängt von der CPU ab. Meist wird -1 verwendet. Beim C16x ist -1 = 0xFFFFh, eine gültige Byteadresse. O.k. ein Pointer benötigt ein Word, es war aber immer eine blöde Idee und N.Wirth zeigt, wie es besser geht.
>Und initialisieren muss in >pascaloiden Sprachen der Programmierer! Nein. Anfangswerte von Pointern bzw. dynamisch (mit NEW()) erzeugten Objekten müssen NIL sein. Wären sie uninitialisiert, also zufällig, könnte man ja die Ungültigkeit nicht immer erkennen. Bei Oberon-2 war es dann auch üblich, dass INTEGER usw. auf 0 vorbelegt wird, damit vermeidet man lange Zeit unentdeckte Fehler wegen fehlender Initialisierung.
Guido B. schrieb: > Abdul K. schrieb: >> Das hängt von der CPU ab. Meist wird -1 verwendet. > > Beim C16x ist -1 = 0xFFFFh, eine gültige Byteadresse. O.k. ein > Pointer benötigt ein Word, es war aber immer eine blöde Idee > und N.Wirth zeigt, wie es besser geht. Du scheinst undankbar zu sein. Erst fragst du um dann sofort rumzumeckern. Natürlich ist für die CPU jede Adresse erstmal korrekt. Wirth habe ich nie länger gelesen. Das war mir zu schwülstig. Der Speicher wird traditionall von Null an belegt mit Hardware und damit auch mit Daten. Die letzte Speicheradresse bietet sich also an. Apple hat z.B. eine Adresse verwendet, die zu einer Exception führt weil sie ungerade ist und die 68K nur auf geraden Adressen zugreifen wird, denn der Apple Memory Manager bietet der Anwendungssoftware nur gerade Adressen an. Greift das Programm auf einen ungeraden Pointer zu, so wird es also sofort abgeschossen. Der berühmte Busfehler 1 kommt in einem Dialog zum Anwender. Andere haben sich spezielle Strings ausgedacht, BEEF irgendwas. Näheres findest du auf Wikipedia. Immer diese jungen Hüpfer.
Hallo, jetzt habe ich den Debugger auch unter Windows kompiliert bekommen. Getestet unter Win2k und XP. Dabei ist mir aufgefallen, dass sein "Formular" für ein älteres Notebook doch etwas riesig ist, werde ich bei Gelegenheit verkleinern. Die aktuellen Quellen dafür hänge ich als tgz an. @ Abdul: Ich bin nicht undankbar, die Idee mit der ungeraden Adresse habe ich doch gewürdigt. Da wäre ich halt nicht darauf gekommen, so etwas ruft auch bei den C16x einen Trap hervor. Aber den "jungen Hüpfer" nimmst du gefälligst zurück, sonst streite ich nicht mehr mit dir. ;-) Als solcher würde ich bestimmt keinen Oberoncompiler in Pascal schreiben. Viel Spaß, Guido
W.S. schrieb: > Wie bitte?? > Du meinst, dieses unsägliche Forth sei ein guter Ansatz? > Und DotNet auch? Zu interpretierender Text als EXE verkappt? Viel Ahnung hast du nicht gerade, aber nen Rundumschlag starten wollen. tztz. .Net Code wird genau wie Java Code KOMPILIERT. Es entsteht Maschinencode, auch Bytecode genannt. Nur wird dieser Code anschließend nicht nativ auf der CPU ausgeführt, sondern von einer virtuellen CPU. Allein dies ist der Unterschied und mit einem Interpreter hat das wenig zu tun. Deine Argumente gegen C sind genauso ahnungslos. Wie soll Systemprogrammierung ohne Pointer aussehen? Wie willst du bei dynamisch alloziertem Speicher einen Überlauf festestellen? Was hat überhaupt der Compiler damit zu tun, wenn später im Programm dadurch ein Überlauf stattfindet? Das kann NUR der Programmierer durch umsichtiges Programmieren verhindern, keine Sprache (was ist das, der Syntax, kann der was dafür?), oder Compiler oder sonst was. Das geht nur bei stärker abstrahierten Sprachen innerhalb einer Speicherverwaltung. Im Bereich Systemprogrammierung nunmal nicht. gruß cyblord
Also mal ehrlich, was soll dieser Flame-War ?! Nur weil jemand C nicht mag heißt das nicht das C schlecht ist. Und nur weil Pascal bestimmte Prüfungen vornehmen kann (!!) heißt das nicht das die Programme automatisch fehlerfrei sind. Und nur weil Zeiger eben nicht ganz unkritisch sind heißt das nicht das es automatisch Probleme mit sich bringt. Ein Programm ist immer nur so gut wie der der es programmiert hat. Und wenn Zeiger Amok laufen dann hat der Programmierer Mist gemacht, und nicht die Programmiersprache. Klar gibt es noch den Compiler der da zwischenfunken kann und Mist bauen kann. Aber hat das was mit C zu tun ?! Wenn man halbwegs gescheit programmiert passieren solche Sachen auch nicht. Klar kann Pascal Prüfungen auf Arrayüberläufe einbauen. Aber Typ-Schweinereien kann man in Pascal auch machen, die dann bestimmt auch zu bösen Abstürzen führen. Wenns danach geht wäre C# dann besser. Und gibts das auch für nen AVR ?! Mal im Ernst. Was soll das ?! C ist nunmal die universelle Programmiersprache die recht nah an der Maschine ist und wird zumeist als erste Sprache auf einem neuen Prozessor implementiert. Pascal ist einfacher lesbar und durch forwarding auch schnell compilierbar, braucht bei Arrayüberlaufprüfung aber auch mehr Zeit. Ist ansonsten aber leicht erlernbar und auch relativ gut auf uCs zu implementieren. C# ist ne neue Krankheit von Microsoft was auf einem uC wahrscheinlich nicht implementierbar ist (jedenfalls keinem AVR/PIC/8/16-Bitter und keine kleinen 32 Bitter). Java geht auch nur rudimentär auf nem AVR. Wobei die Interpretersprachen (also ALLE Sprachen die Bytecode erzeugen der auf einer virtuellen CPU läuft) allesamt recht viel Ressourcen brauchen, und je nach Sprache auch gar nicht umsetzbar sind (AVR und C# z.b.). Forth gibts eh immer mal wieder ohne das es sich so durchsetzen kann. Und Basic ist auch fast überall zuhause. Hab ich noch ne Programmiersprache (bis auf vllt Algol, Fortran) vergessen ? Leute leute ...
Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua. Das ist ja das Problem. Ich brauch nur in den Windoof-Ordner schauen, wieviele Libs dort sich sammeln. Von den vielfachen Kopien woanders auf der HD gar nicht zu sprechen. Achso, wir waren ja bei Controllern.
>Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua. Welche von den "vergessenen" ließen sich denn auf einem uC implementieren ? >Ich brauch nur in den Windoof-Ordner schauen, wieviele Libs dort sich >sammeln. Dann bleib bei Linux, CP/M oder sonstwas. Jedes Betriebssystem hat seine Macken. Klar ist Windows nicht das tollste. Aber es läuft und wird benutzt. Egal ob da ein "Hype" hintersteckt oder nicht. Meinst du etwa wenn Apples Betriebssystem weltweiter Standard wäre wäre die Welt besser ? Ich glaube nicht. Ähnlich sehe ich das bei Linux. Es gibt kein perfektes OS. Also braucht man sich meiner Meinung nach auch nicht ärgern. Oder wie stellst du dir das vor das a) für dich zu ändern und b) für die Welt zu ändern ? >Achso, wir waren ja bei Controllern. Eben. Und da ist weder Pyhton, Ruby, C#, .net oder sonst eine der "neueren" Sprachen sinnvoll. Da bleibt als ernstzunehmende Sprache nur C, Pascal, Basic und eben Assembler übrig oder ?
Vor allem würde ich Pascal streichen und durch Oberon ersetzen. ;-)
Rene B. schrieb: >>Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua. > > Welche von den "vergessenen" ließen sich denn auf einem uC > implementieren ? > Alle. >>Ich brauch nur in den Windoof-Ordner schauen, wieviele Libs dort sich >>sammeln. > > Dann bleib bei Linux, CP/M oder sonstwas. Jedes Betriebssystem hat seine > Macken. Klar ist Windows nicht das tollste. Aber es läuft und wird > benutzt. Egal ob da ein "Hype" hintersteckt oder nicht. Meinst du etwa > wenn Apples Betriebssystem weltweiter Standard wäre wäre die Welt besser > ? Ich glaube nicht. Ähnlich sehe ich das bei Linux. > Es gibt kein perfektes OS. Also braucht man sich meiner Meinung nach > auch nicht ärgern. Oder wie stellst du dir das vor das a) für dich zu > ändern und b) für die Welt zu ändern ? Es beruhigt zu hören, daß die Softmasochisten auch keine Lösung haben. > >>Achso, wir waren ja bei Controllern. > > Eben. Und da ist weder Pyhton, Ruby, C#, .net oder sonst eine der > "neueren" Sprachen sinnvoll. Da bleibt als ernstzunehmende Sprache nur > C, Pascal, Basic und eben Assembler übrig oder ? Momentan fällt mir keine ein. Ich konnte mich aber eh nie wirklich entscheiden. Interessant finde ich noch den Propeller-Dialekt. Klar, das ist ein Nischenprodukt.
Abdul K. (ehydra) schrieb: >>> Achso, wir waren ja bei Controllern. >> Eben. Und da ist weder Pyhton, Ruby, C#, .net oder sonst eine der >> "neueren" Sprachen sinnvoll. Da bleibt als ernstzunehmende Sprache nur >> C, Pascal, Basic und eben Assembler übrig oder ? > Momentan fällt mir keine ein. Aber mir! Wer sagt denn das C#/.NET hier "nicht sinnvoll" seien? Ist doch längst realität! http://www.netduino.com/ http://www.elektor.de/elektronik-news/renesas-sh-2-controller-mit-net-micro-framework.1466629.lynkx http://www.dfrobot.com/index.php?route=product/product&product_id=506
@Abdul >>>Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua. >> >> Welche von den "vergessenen" ließen sich denn auf einem uC >> implementieren ? >> > >Alle. Ruby, Python, PHP auf nem Mega8 ?!?!? Zeig mal ... @ersa >Aber mir! Wer sagt denn das C#/.NET hier "nicht sinnvoll" seien? Ist >doch längst realität! Auch hier : Auf einem Mega8 ?!?! Zeig mal ... Von einem 32-Bitter zu reden ist dann kein Problem. Ich meine Linux auf einem ARM/SH2/AVR32 usw ist keine Kunst. Das man bei nem Ruby/Python/Linux/C#/.net System meist eh noch Megabyteweise RAM braucht um überhaupt gescheit arbeiten zu können ist dann auch normaler Verschwendungswahnsinn. Also selbe Welt wie aufm PC, oder ? Aber bleiben wir doch mal bei kleineren Controllern (8/16-Bit). Wo gibts Verwendung für .net/Python/PHP usw auf so kleinen Kisten ? Wie gesagt : nen ARM mit 128MB RAM ist keine Kunst. Da kann ich prinzipiell auch auf nem PC bleiben, und mal eben nen Megabyte allokieren um mir 5 Messwerte zu speichern ... So wie es unter "echten" (Ironie) Sprachen wie eben PHP, C#, Pyrhon üblich ist. Und solche Leute wundern sich dann das sie mit C nicht klarkommen ... warum nur ?
Moins Guido + allerseits, @Guido: mach weiter so ! Vielleicht wäre es hilfreich, wenn Du kurz und klar die Vorteile einer "sicheren" Programmierung eines uC in Oberon gegenüber C+statischen Code-Check Tools wie lint darstellen könntest ? Es gab da mal Anfragen im Forum, wo Leute konkretes Interesse hatten auch Hobby-Projekte mit einem C16x uC zu machen, aber sich dagegen entschieden haben weil es keine freie Hochsprachen-Toolchain gab und die C Demoversionen von Tasking, Keil und Hitec arg in der Codegrösse beschränkt waren. Diese Lücke schließt Guido mit seinem Projekt und hat nun auch noch einen Source-Level Debugger zum vernünftigen Entwickeln dazu geschaffen. Also, Ihr alle da draussen mit einer C16x Hardware in der Schublade: Evaluiert die Toolchain, gebt Euer konstruktives Feedback an Guido ! MfG, tom (der sponsor ;-).
Hallo Tom, natürlich ist Feedback wichtig, sonst müsste man so ein Projekt ja nicht veröffentlichen, daher nochmals Dank an dich. Leider ist in diesem Thread nicht viel davon sichtbar, Stefan Salewski war bisher der einzige konstruktive Teilnehmer. Es ist aber auch klar, dass nur Leute mit zufälligerweise vorhandener Hardware mitspielen können. Zum Thema sicheres Programmieren möchte ich mich eigentlich nicht sehr weit aus dem Fenster lehnen, da ich gerade hier sehr nachlässig war und viele Eigenschaften Oberons die hierzu beitragen in meinem kleinen Compiler (noch) nicht realisiert sind. Natürlich exisistiert die strikte Typenüberprüfung, die nicht nur triviale Fehler ausschließt, sondern auch Bufferoverflows bei Prozeduraufrufen unmöglich macht. Durch die Implementierung des Modulimports kommen Kapselung und typisierte Bezeichner hinzu, wobei dieser bisher aber erst zu ca. 70 % implementiert ist. Andere Punkte hierzu habe ich bisher vernachlässigt, vor allem weil es bei Mikrocontrolleraufbauten keine definierte Fehlermethode gibt, aber auch weil ich seit über 30 Jahren programmiere und mir diese Fehler dementsprechend nicht mehr passieren. Im Zusammenhang mit dem Debugger muss ich das nocheinmal überdenken. Ich werde mir überlegen, ob ich Tests auf überlaufende Arrayindizes, Divisionen durch 0, Stackkollision und ev. noch andere Fehler realisiere. Jetzt wo auf deine Anregung hin der erste Schritt getan ist, wäre das vermutlich nur konsequent. Praktisch bedeutet dies nur, dass außer Debug-An und -Aus zusätzliche Stufen in den Compiler eingebaut werden müssen. Grüße, Guido
Angehängte Dateien:
-
dbg2.png
58 KB
Hallo mal wieder, ich habe jetzt optionale Tests im Compiler implementiert. Diese werden mit der Option -db2 bzw. -db3 aktiviert, wobei letztere zusätzlich den Monitor anhängt, der natürlich die zusätzlichen Traps bedient. Ohne Monitor muss sich die Anwendung um diese Traps kümmern, genauere Angaben finden sich in der Doku. Option -db1 funktioniert wie bisher. Die Tests beinhalten: - Stack-Kollision - Arrayindizes - Überlauf u.ä. bei arithmetischen Operationen Habe ich etwas vergessen? Zusätzlich habe ich das Layout des Debuggers überarbeitet, der sollte jetzt auch auf das Display eines Netbooks passen. Bei Unterbrechungen wird jetzt auch das PSW übertragen und aufbereitet dargestellt. Die Windowsversion des Debuggers hat wohl noch Timingprobleme mit der ser. Schnittstelle, unter Wine läuft sie bei mir nicht. Das werde ich mal noch optimieren. Viel Spaß, Guido
Leider ein ziemlich blöder Fehler im Monitor, gut, dass ihn noch niemand bemerkt hat ;-). Es war sicher nicht der letzte, aber wenn jemand ernsthaft testen möchte, bitte den angehängten Monitor verwenden. Wer den Fehler erkennt, hat sehr viel von der Arbeitsweise des Compilers verstanden. Viel Spaß, Guido
TheMason schrieb: > Auch hier : Auf einem Mega8 ?!?! Zeig mal ... > > Von einem 32-Bitter zu reden ist dann kein Problem. Ich meine Linux auf > einem ARM/SH2/AVR32 usw ist keine Kunst. Das man bei nem > Ruby/Python/Linux/C#/.net System meist eh noch Megabyteweise RAM braucht > um überhaupt gescheit arbeiten zu können ist dann auch normaler > Verschwendungswahnsinn. Also selbe Welt wie aufm PC, oder ? Darauf läuft es eh hinaus. Wie ich schon schrieb: Am Ende wird es nur noch ARMs geben! Vor allem wenn man jetzt eine Entscheidung für eine Softwareumgebung sucht und diese dann realisiert, werden locker 3 Jahre vergehen. Bei einem Profi-Programmierer - ich fange erst gar nicht an ;-) > > Aber bleiben wir doch mal bei kleineren Controllern (8/16-Bit). Wo gibts > Verwendung für .net/Python/PHP usw auf so kleinen Kisten ? Wie gesagt : > nen ARM mit 128MB RAM ist keine Kunst. Da kann ich prinzipiell auch auf > nem PC bleiben, und mal eben nen Megabyte allokieren um mir 5 Messwerte > zu speichern ... So wie es unter "echten" (Ironie) Sprachen wie eben > PHP, C#, Pyrhon üblich ist. Ich bin dafür kein Experte im Sinne einer Marktübersicht. Aber zumindest gibts z.B. sogar Java auf FPGAs. > Und solche Leute wundern sich dann das sie mit C nicht klarkommen ... > warum nur ? Mir gefällt die Art und Weise von C nicht. Für meine kleinen Projekte komme ich mit C klar. Was den Oberon-Compiler angeht: Leider ist der C16x ein absoluter Exot. Wenn Guido das für ARM rausbrächte, wäre die Resonsanz sicherlich erheblich größer.
Tja Abdul, da hast du vermutlich Recht. Ich will eine Portierung nicht ausschließen und habe mir die Cortex M3 diesbezüglich auch schon angesehen, im Moment kann ich aber nur schreiben, warum ich das am Anfang nicht getan habe: 1.) Ich habe den Compiler für die C166-Famile geschrieben, weil ich beim Datenblattstudium erkannt habe, dass diese hierfür ideal geeignet sind. Ursprünglich wollte ich diese als besseren Ersatz für die MCS51er verwenden und auch in Assembler programmieren. Ihre Architektur ist aber optimal für einen Compiler geeignet und das hat mich überzeugt. Die ARMs sind dagegen viel schlechter für meinen Compiler geeignet. Ein Kontextswitch in vier Takten bei gleichzeitigem Verzicht auf die träge Stack-Machine ist auch mit einen M3 nicht realisierbar. 2.) Es gibt keinen richtigen freien Assembler für die ARMs. Ich kann aber einen Single-Pass-Compiler nicht mit einem Singel-Pass-Assembler kombinieren. Also müsste ich die Codeerzeugung in den Compiler mit übernehmen. Das ist machbar, entsprechende Implementierungshinweise und -Beispiele sind von N. Wirth mitveröffentlicht. Es beraubt mich aber des einfachen "Inlineassemblers" und darauf möchte ich nicht verzichten. 3.) Es gibt mit Astrobe einen Oberoncompiler für einige ARMs und Chris Burrows ist mit diesem viel weiter als ich. Er unterstützt Oberon praktisch vollständig mit Pointern und OOP. Astrobe soll bis zum 1. Quartal nächsten Jahres auf den M3 fertig portiert sein und, ich mache ja ungern Werbung für die Konkurrenz, die PE ist vom Preis her auch für Hobbyisten tragbar (vergleichbar mit Bascom). Ich muss ev. nochmal klarstellen, dass mein Compiler alle C166er unterstützen soll. Mangels Hardware kann ich nur nicht alle 50 Typen testen. Es ist also garnicht so exotisch, gerade in der Industrie werden diese Kontroller in großen Mengen eingesetzt. Gruß, Guido
Naja, frag mal hier rum wieviele Leute den benutzen?! Stückzahlen und Design-Wins sind nicht das gleiche. Rein technisch sehe ich den C16x überlegen gegenüber ARM. Aber das ist im Markt leider nicht entscheidend. Oder vielleicht auch gottseidank so?? Sonst hätten immer nur die Platzhirsche das sagen und die smarten Jungbullen kämen nie zum Zuge. Ich hatte mal einen i2c-Bitbanger für 8051 in C für Keil-C geschrieben. Bekanntermaßen ist das ein sehr guter Compiler, der das letzte aus der Architektur rausholt (Ein Punkt der viel zu wenig beachtet wird!). Wie ich so bin, hat mein Code endlos viele Unterprogramme aufgerufen. Fast wie Forth ;-) Ein Kunde wollte den Code dann auf einem C166 laufenlassen. Also schrieb ich das Ding einfach um. War nicht viel Arbeit, denn: 1. Memorymodell-Bezeichner entfernt 2. Die 3 Routinen für das Port-Bit-Handling geändert, da der C166 Portbits anders anspricht. Dann einfach mit Keil-C166 kompiliert. Hat natürlich keinen Fehler erzeugt, aber es ging trotzdem nicht! Das Ende vom Lied: Der C166 hat den praktisch gleichen Code um den Faktor 8000 schneller ausgeführt. Was den externen i2c-Bausteinen nicht schmeckte. Daraufhin kam dann eine Delay-Routine mit rein. Dabei lief der C166 noch gar nicht mit voller Geschwindigkeit. Vergleich mit 12MHz 8051. Das als Anekdote.
Abdul K. schrieb: > Naja, frag mal hier rum wieviele Leute den benutzen?! Stückzahlen und > Design-Wins sind nicht das gleiche. Das war mir schon klar, es gab ja aber bisher auch keine freie Entwicklungsumgebung dafür. Mit seiner Portzahl und seinen Schnittstellen ist er auch ganz sicher keine Konkurrenz zu den AVR. Nach meinem Gefühl ist er hier im Forum vor allem für die Heimautomatisierer und Robotiker interessant. Ich bin mal gespannt, ob ich noch ein paar Mitstreiter für dieses Projekt finde! Immerhin gibt es schon Feedback und Toms Idee mit dem Debugger hat mir schon sehr geholfen. Natürlich hätte ich so was aus eigenem Antrieb nicht in Erwägung gezogen, es bedeutet ja Arbeit. Die war aber doch sehr übersichtlich und mittlerweile möchte ich auf den Debugger nicht mehr verzichten. Auch seine Folgeidee werde ich wohl bei Gelegenheit noch umsetzen, gefällt mir ;-). Abdul, lachendes und weinendes Auge wechseln sich ab. Das lachende deshalb, weil ich im Moment bei ebay noch Hardware zum Einstellungspreis erwerben kann. Gruß, Guido Edit: Faktor 8000 ist nicht realistisch, so um 20, bei neueren Chips nochmal das 10- Fache ist erreichbar.
Der Faktor 8000 wurde schon real gemessen. Das liegt sicherlich an der doch recht umständlichen Verarbeitung von Unterprogrammen beim 8051. Da läuft man mit Makros besser.
@guido Ich weiß nicht ob ich neben der Diskussion um die Sinnhaftigkeit dieser oder jenen Programmiersprache schon geschrieben hab das ich das Projekt an sich echt gut finde. Vor allem das du einen Debugger "mitlieferst". Mein Lob dafür schonmal. Da ich die Idee einer Interpreter/Systemsprache habe interessiert mich dein Compiler und dein Debugger von der Umsetzung her. Da ich selbst mit Pascal nicht mehr soviel mache (zumeist Delphi für den PC) bzw keinen C16x Prozessor nutze habe ich leider nicht so die Verwendung dafür. Aber bei dem AVR-Basic von Uwe Berger hab ich auch keine direkte Verwendung dafür gehabt, aber dennoch "mitgemischt" :-). Allein schon um mal zu sehen was man noch da rausholen kann, und weil mich Programmiersprachen und deren Interpretation bzw Compilation für "kleine" Controller schon interessieren. Von daher würde mich deine Umsetzung schon interessieren, und dadurch das du auch einen Debugger dabei hast erst recht. Weiter so !
@Guido hast du schon einen C164 in deiner Raupensammlung ? gruss, tom.
Jo Tom, habe ich schon. Der CS-LM ist angekommen, vielen Dank. Werde ich gelegentlich testen. Erstmal habe ich mir den CS8900A vorgeknöpft ;-). Gruß und Dank, Guido
Angehängte Dateien:
-
firefox.png
27 KB
Hallo, heute mal was anderes, ein kleiner Webserver in OberonC16x. Das von tom gesponsorte DevBoard beinhaltet auch einen CS8900A-Chip mit allem Zubehör, so dass es nahelag, hierfür eine kleine Ethernetanwendung zu entwickeln. Dieser Webserver antwortet auf ARP-Requests (auf seine MAC), auf ICMP-Echo-Requests (vulgo ping) und liefert eine kleine Webseite aus, die in den Codespeicher eingefügt ist. Seine Codelänge liegt ohne Debugging-Hilfen bei ca. 5 kBytes, inklusive der minimalen Webseite. Das Ergebnis ist sicher nicht optimal, ich habe es mit der Wikipedia einerseits und tcpdump andererseits auf die Schnelle zusammengebastelt. Insbesondere TCP ist nur rudimentär implementiert, es wird nur eine Verbindung akzeptiert, weitere Anforderungen werden per Reset abgewiesen. Auch sollten einige weitere Timeout- und Sicherheitsüberprüfungen eingefügt werden. Der Interrupt für den CS8900 gefällt mir auch nicht, für eine reale Anwendung würde ich lieber darauf verzichten und per Polling zugreifen. Die vernünftige Wahl des Pollingintervalls müsste aber noch ermittelt werden. Für mich ist diese Implentierung als Testplattform in Ordnung, meine Interessen tendieren mehr in Richtung CAN-Ethernet-Bridge mittels UDP und der Nutzung von SNTP. Viel Spaß, Guido
Hallo, eine Fehlerbereinigung, da mir bei der Ethernetanwendung vorgeführt wurde, dass z.B. arithmetische Operationen mit Arrayelementen nicht funktionieren. Die Workarounds sind in der obigen Anwendung zu finden aber hoffentlich jetzt nicht mehr nötig. Wie immer sind Executables für Windows und Linux im trunk zu finden. Weiterhin habe ich die Inline-Prozeduren INC(x,y), DEC(x,y), wobei der 2. Parameter entfallen kann, sowie SWAP(x) implementiert. Diese habe ich auch bei Enet.mod schmerzlich vermisst. Natürlich können solche Sachen leicht als Oberon-Prozeduren realisiert werden, da hierfür oft aber nur eine einzelne Assembleranweisung nötig ist, erscheint mir der zusätzlich Kontextswitch als übermäßiger Overhead. Das ist im Compiler besser aufgehoben. Wenn ich in einem anderem Thread hier lese, dass manche Compiler schon für einen Bootloader den Code um einen Faktor 5 gegenüber Assembler aufblähen, kann ich nur müde grinsen. Wenn ich das nicht besser könnte, würde ich weiter in Assembler programmieren. Viel Spaß, Guido
Hallo, weiter gehts mit Inline-Prozeduren. Heute gibt es neu PeekW und PokeW zum Speicherzugriff in Words. Da diesen u.a. die Speicherseite mit übergeben wird, kann damit auf den gesamten Speicherbereich des Controllers zugegriffen werden. Das Ziel ist, dass man Assembler nur noch in Ausnahmefällen braucht. Momentan fehlt mir hierzu noch eine Idee, wie man LUTs in Oberon realisieren könnte. Außerdem habe ich die Relation IN in Form eines Bitmustervergleichs implementiert. Zwar werde ich den Typ SET wohl nicht implementieren, weil ich hierfür nie eine sinnvolle Verwendung gesehen habe, aber diese Relation ist auch einfach für Ganzzahlen sehr praktisch, zumal sie vom Compiler sehr effektiv umgesetzt werden kann (3 Assembler- Anweisungen). Die Auswahlmenge ist auf einem 16-Bit-System natürlich arg begrenzt (0 .. 15), da hat man mit 32 Bit deutlich mehr Nutzen, aber um z.B. mehrere Zustände einer kleinen FSM zusammenzufassen reicht es allemal und viele verknüpfte Bedingungen mit OR werden damit unnötig. Diese erzeugen nunmal sehr viel Code. Da ich mit Kate unter KDE programmiere, habe ich mir natürlich auch eine entsprechende Sprachdefinitionsdatei hierfür erstellt (von Pascal.xml geklaut und entsprechend angepasst). Diese hänge ich auch mal an, zukünftig packe ich sie einfach in das trunk mit rein. Diese Datei gehört nach ~/.kde/share/apps/katepart/syntax/ und bietet dann Syntaxhighlighting und Codefolding. Unter Windowws habe ich das vor längerer Zeit auch mal probiert und für den Crimson- Editor realisiert. Dieser wird aber wohl nicht mehr gepflegt.:-( Falls da jemand Bedarf hat, würde ich mir das nochmal ansehen. Viel Spaß, Guido
Hallo, für das Netbook ist Kate mit KDE sicher zu schwergewichtig. Auf der Suche nach Alternativen habe ich mal Geany probiert. Mit der angehängten, von der Pascal-Definition übernommenen und nur leicht angepassten Konfiguration, die nach "homedir"./config/geany/filedefs gehört, wird darunter Syntaxhighlighting und Codefolding unterstützt. Ich habe den Scanner so erweitert, dass er Fehlermeldungen imho exakt so wie fpc auf der Konsole ausgibt, trotzdem interpretiert Geany diese nicht richtig. Wenn jemand eine Lösung hierfür hat, immer her damit. Mit F8 wird damit die Compilierung gestartet, mit F9 der Assembler, sofern beide installiert sind. Das geht natürlich auch über die zugehörigen Quickbuttons. Schon schön zu sehen, wie sich Geany entwickelt hat. Allerdings unterscheidet es nicht zwischen Groß- und Kleinschreibung, der Compiler schon. Daher nicht wundern, wenn Schlüsselwörter trotz Typo hervorgehoben werden. Die Alternativen sind halt rar, Emacs wäre natürlich eine Möglichkeit, aber ich habe keine Lust auch noch einen Lisp-Kurs zu absolvieren. Keine neuen Quellen, die gibts wieder, wenn es sich lohnt. Viel Spaß, Guido
Hallo leute, ich bin neu in ST10, heute habe ich die serielle schnitstelle zum laufen gebracht, kann mir aber jemand helfen wie ich softwareweise die CSSEL bit 0 loesche (P0H.1), weil ich am P6 GPO outputs habe, und an den P0H ist der ADC channel besetzt an meinem experimentierboard. Geht es auf oftwarewesise? Ich habe einen ST10F276.
Und dafür musst du einen Zombie über die Sprache Oberon aufwecken?
Hallo igor, schaue ins User-Manual: >The number of chip select signals is selected via PORT0 during reset. The >selected value >can be read from bit-field CSSEL in register RP0H (read only) in order to >check the configuration during run time. Da geht also mit Software nichts.
Hi Guido, Danke für die kurze Hilfe an den Fragenden... Der Support+Doku von ST was diese Derivate betrifft ist - na ja, nicht berauschend. Deswegen ist es schön, wenn jemand weiterhilft. Hätte Kollege User prx auch machen können ohne sich einen Zacken aus der Krone zu brechen IMHO. Ansonsten viel Spass und Erfolg beim Weiterentwickeln der Toolchain ! Ist übrigens die einzige freie=kostenlose Hochsprachencompiler-linker-debugger Toolchain für C16x Derivate. Und dafür gehört Guido ein dickes Dankeschön vs. Zombie ;o). ! Gruss, tom.
Danke für die Blumen Tom, ja, es geht weiter aber momentan in kleinen Schritten. Ich probiere gerade eine nutzbare Lösung mit Flashspeicher hinzubekommen, möglichst mit Debugger. Dann fehlt noch der Modulimport, den muss ich auf den Herbst verschieben. Klar kann ich helfen und tue das gerne, ein bisschen was verstehe ich mittlerweile ja schon von den Controllern. ;-) Bei der Vielzahl an Derivaten ist der Überblick natürlich nicht ganz einfach, aber da ich mir auch gerade einen kleinen Vorrat an F276ern zugelegt habe, kenne ich auch die etwas. Warum Leute ohne Sachverstand meinen Forumspolizei spielen zu müssen, erschließt sich mir allerdings auch nicht ganz. Grüße, Guido
Moins Guido, meinst Du "nur" programmieren des Flashes per debugger oder auch debuggen von im Flash lokiertem code ? Das wäre ja oberkomfortabel und ein SUPER feature des debuggers. Allerdings müsste für breakpoints/single step die betreffende page/sector im code gepatched werden, um den sprung in den monitor jeweils zu veranlassen. Habe nicht mehr im Kopf wie die granularität des on-chip flashes ist. 128 oder 256 bytes sind mal schnell hin und her übertragen, bei grösseren kuchenstücken wird es dann schon unhandlicher... vielleicht fällt ja jemandem noch etwas anderes pfiffiges ein dazu ? Grüße + frohes Schaffen weiterhin (Ba-Wü hat ja ein langes Wochenende vor sich :-). tom.
Hallo Tom, Haltepunkte im Flash hatte ich garnicht eingeplant, aber so wie dir du das vorstellst könnte es sogar gehen. Bei den St10F276 ist die erste Flashseite sehr fein aufgeteilt, zu Anfang in 8-k-Blöcken. Zum Flashen könnte man in den 2. Block ausweichen oder in das XRAM. Im Moment spiele ich aber mit einer selbstgekochten Platine mit C167 und AM29F040, damit hätte ich in diese Richtung keine Chance. Mir hat aber der Debugger schon gefehlt und alles außer Haltepunkten müsste eigentlich auch im Flash machbar sein. Ich müsste nur die Flashfunktion in den Debugger integrieren oder diesen ohne BSL betreiben können. Da muss ich mir mal genauere Gedanken machen, zusammenfrickeln möchte ich das nicht. Jaa, sehr langes Wochenende! Aber manchmal möchte ich den Compiler ja auch nur einfach für Anwendungen nutzen. :-) Grüße, Guido
Hey, cooles Projekt! Hast du vor den Code öffentlich zu machen? Mich als (Informatik)Student würde es sehr interessieren, wie das Projekt aufgezogen ist.
asdf schrieb: > Hey, > cooles Projekt! > Hast du vor den Code öffentlich zu machen? > Mich als (Informatik)Student würde es sehr interessieren, wie das > Projekt aufgezogen ist. Danke, der Code ist doch offen. Du musst nur etwas hochscrollen und das letzte angehängte "trunk.tgz" auspacken. Ich werde demnächst mal eine neue Version anhängen. Für dich als Informatikstudent ist das sicher ein gutes Beispiel dafür, wie man es nicht machen soll. :-) Gewachsener Code halt.
Moins Guido, Nun, nur download in 29F040 flashes und ein guter alter C167 ;o). Die Flash Programmier-Routinen sollten im RAM laufen, read-while-write geht mit den 29F0x0 chips nicht. Falls Du den monitor per BSL ins interne RAM lädst, könnte man den um flash-spezifische programmierroutinen erweitern, oder die dynamisch nachladen (löschen, schreiben - je nachdem was gerade gebraucht wird). Falls Du bezüglich der 29f0x0 programmierroutinen hilfe brauchst - einfach bei mir melden, ok. ? Gruss, Tom.
Tomas Kuckenburg schrieb: > Nun, nur download in 29F040 flashes und ein guter alter C167 ;o). Tja Tom, nicht immer braucht man einen Boliden, der mit 40 MHz rennt. ;-) Danke für das Angebotr aber der Flasher läuft schon, trotz gekreuzter Datenleitungen zur Layoutvereinfachung. Und ja, der muss im XRAM laufen. Damit kann ich ihn nicht aus dem Monitor nutzen, da er mir sonst die Variablen zertöppert. :-( Soweit ich das überblicke gingen solche Haltepunkte nur mit den "großen" ST10F, bei denen das Programm in einem Flasblock läuft und daraus den 2. Block ändern kann. Ich überlege mir eine andere Möglichkeit: Im Compiler wird die Inlineprozedur "Breakpoint" eingeführt, die bei entsprechendem Debuglevel eine illegale Instruktion in den Code einfügt. Durch diese wird wieder der Monitor aufgerufen, der nach einer Stackmanipulation das Programm weiterlaufen lassen kann. Singlestepping geht so zwar nicht, es ist aber besser als nichts. Erst muss ich aber den Debugger auf Flash umrüsten, da sind schon einige Änderungen nötig. Da das Flashen aber schön schnell geht, macht es schon Spaß damit. Grüße, Guido
Moins Guido, Guido B. schrieb: > Danke für das Angebotr aber der Flasher läuft schon, trotz > gekreuzter Datenleitungen zur Layoutvereinfachung. Und ja, der > muss im XRAM laufen. Damit kann ich ihn nicht aus dem Monitor > nutzen, da er mir sonst die Variablen zertöppert. :-( Ja, da wird es mit dem verfügbaren on-chip RAM schnell knapp. Ist leider so und die sector-Granularität bei den 29f0x0 sowie die erase/write times sind etwaaaaaas groß ggf. Kann man nix machen ausser ggf. durch RAM ersetzen auf der HW. Falls Du mal einen sockel für plcc-32 brauchst, so etwas habe ich noch irgendwo rumzuliegen. Leider gab (gibt ?) es kein RAM in dem gleichen housing, nur teure steck-adapter mit den begleitenden evtl. kontaktierproblemen. > Soweit ich > das überblicke gingen solche Haltepunkte nur mit den "großen" ST10F, > bei denen das Programm in einem Flasblock läuft und daraus den 2. > Block ändern kann. Ja, read-while-write war/ist ein klassisches flash-problem. kannst das nicht von der gleichen speicherbank (CSx) ausführen... > Ich überlege mir eine andere Möglichkeit: Im Compiler wird die > Inlineprozedur "Breakpoint" eingeführt, die bei entsprechendem > Debuglevel eine illegale Instruktion in den Code einfügt. Durch diese > wird wieder der Monitor aufgerufen, der nach einer Stackmanipulation > das Programm weiterlaufen lassen kann. Singlestepping geht so zwar > nicht, es ist aber besser als nichts. jepp, ein "statischer" Brechpunkt, definiert zur compile-zeit. Auf jeden Fall besser als gar nichts und ein nützliches Feature ! Hast Du in Deiner IDE die Möglichkeit eingebaut, eine Applikation zwischen debug (mit moni) und relase-config einfach umzuschalten ? Ist ja doch einiges an Unterschied in Lokierung und ISR-table(s) nötig. Mach weiter so + Grüsse, tom ;o) !
Hallo Tom, > Ja, da wird es mit dem verfügbaren on-chip RAM schnell knapp. Ist leider > so und die sector-Granularität bei den 29f0x0 sowie die erase/write > times sind etwaaaaaas groß ggf. Kann man nix machen ausser ggf. durch > RAM ersetzen auf der HW. Falls Du mal einen sockel für plcc-32 brauchst, > so etwas habe ich noch irgendwo rumzuliegen. Leider gab (gibt ?) es kein > RAM in dem gleichen housing, nur teure steck-adapter mit den > begleitenden evtl. kontaktierproblemen. Ich war auch verblüfft, dass dies völlig unproblematisch ist. Die Write-Time für ein Byte liegt mit ca. 7 µs weit unter der Übertragungszeit via RS232 und auch die Erase-Time pro Sektor ist mit 1 s kaum bemerkbar. Da bringt die Umstellung von Intel-Hex auf binär viel mehr. Die Geschwindigleit hiermit hat den Spaß sofort erhöht und die spezifizierte Zyklenzahl von 10^6 bei den AM29F040 bremst auch nicht. > Ja, read-while-write war/ist ein klassisches flash-problem. kannst das > nicht von der gleichen speicherbank (CSx) ausführen... > Die großen ST10Fxx bieten dafür die Möglichkeit mit ihren zwei Flash-Blöcken, das wird mir aber zu controllerspezifisch. > jepp, ein "statischer" Brechpunkt, definiert zur compile-zeit. Auf jeden > Fall besser als gar nichts und ein nützliches Feature ! > > Hast Du in Deiner IDE die Möglichkeit eingebaut, eine Applikation > zwischen debug (mit moni) und relase-config einfach umzuschalten ? Ist > ja doch einiges an Unterschied in Lokierung und ISR-table(s) nötig. > Jo, ich muss zum Debuggen nur dem Compiler die Option "-db1" mitgeben, dann kümmert er sich um den Rest. > Mach weiter so + Grüsse, > > tom ;o) ! Mach ich, im Moment läuft aber nicht mal mehr der Monitor. Keine Ahnung, was schiefläuft, vermutlich patzt der Compiler, da ich ihn natürlich wieder verändert habe. Wenn ich wieder etwas mehr Zeit habe, werde ich das genauer untersuchen, auf die Schnelle ist mir nix aufgefallen. :-( Grüße, Guido
Hi Guido, uppps - Du hattest wirklich immer intel-hex runtergeladen ? Binär ist dann doch die bessere Wahl. Weniger + schneller zu übertragen und Du kannst den Parser targetseitig sparen. Falls Du noch paar 29F010/F040 brauchst - einfach kurz Bescheid geben, ok. ? Viel Spass + Erfolg, Tom.
Jo Tom, habe ich, aber jetzt schreibe ich alles auf Binärübertragung um. War halt angenehm, dass die Adressen gleich mitübertragen werden und das Parsen war unproblematisch da ich das ja schon in Oberon durchführen konnte. Ich integriere gerade die Funktion des Flashers in den Debugger, so dass dieser für beides benutzt werden kann. Hoffentlich übersehe ich nichts, so dass dies auch für die Typen mit internem Flash funktioniert. Eigentlich sollte nur der Flasher angepasst werden müssen und der wird ja, als 2. Stufe des BSL, separat geladen. Die Flexibilität des Memtools werde ich aber sicher nicht erreichen. Nebenbei noch ein paar Erweiterungen und Optimierungen im Compiler, die machen richtig Spaß. :-) Leider momentan halt zu wenig Zeit, aber das wird auch wieder besser werden. Grüße, Guido
Hallo, da ich in der nächsten Zeit wohl nicht viel am Compiler weiterentwickeln kann, hier mal noch der letzte Stand. Wie immer sind ausführbare Dateien im tgz unter bin/ zu finden. Ich habe noch die Inlineprozeduren Intsen und Intsdis implementiert, so dass man jetzt wohl ohne Inlineassembler auskommen kann. Die Schreibweise für alle Inlineprozeduren habe ich vereinheitlicht, s. Doku. Auch der Breakpoint für Module im Flash ist implementiert. Die Anfangsadresse der Modulinitialisierung wird als letzter Vektor (0x1FC) übergeben und kann damit vom Debugger an fester Flashadresse ausgelesen werden. Den Stackstart habe ich auf 0xFCE0 umgelegt, damit die PEC-Pointer verfügbar bleiben. Zusätzlich habe ich einen Codelängenzähler implementiert, mit dessen Hilfe der Compiler weiß, wielang das Modul wird. Mittelfristig möchte ich damit die Segmentgrenze für den Code knacken, Genaueres steht in der Doku im Abschnitt über den Programmspeicher. Viel Spaß, Guido
Mal was anderes, die Dokumentation als EBook. Lässt sich auch auf kleinen Readern prima lesen und gefällt mir gut. :-) Zur Erstellung habe ich die LaTeX-Quellen mit latex4ht in HTML umgewandelt und dieses dann in Calibre gefüttert. Toll, wie einfach das geht. Viel Spaß, Guido
Hallo, ganz konnte ich die Finger doch nicht weglassen. Eigentlich wollte ich nur die Inlineprozedur Adr implementieren, die die Adresse einer globalen Variablen im RAM liefert. Damit kann man einfach Arrays als Puffer für PEC-Transfers verwenden. Dies ist soweit getan. Dabei sind mir aber noch eine Menge Fehler bei der Behandlung von Arrays und deren Indizes aufgefallen, die ich natürlich soweit korrigiert habe. Hoffentlich gibt es jetzt mit globalen Arrays keine Probleme mehr, für "lange" Prozeduren würde ich lokale Arrays eh noch als nicht implementiert betrachten. Zusätzlich habe ich den Scanner mal aufgeräumt, Rudimente meiner ersten Ideen zum Modulimport beseitigt. Der erfolgt dann irgendwann doch konform zu N.Wirth. Viel Spaß, Guido P.S.: Executables sind wie immer im trunk.tgz.
Hi Guido, Gibt es etwas Neues oder bist Du noch im Winterschlaf ? Für C16x Interessierte hätte ich noch ein Phytec Kitkon 164 günstig abzugeben ! gruss, Tomas.
Hi Tom, leider gibt es garnichts neues, obwohl ich nicht im Winterschlaf bin. Ich bin momentan durch anderes so beschäftigt, dass ich nicht dazukomme, mich um den Compiler zu kümmern. Ideen habe ich noch genug und es wird ca. Mitte des Jahres sicher wieder weitergehen. Zum Kitcon-164 noch: Das benutze ich auch, nett ist die Echtzeituhr im C164, die im C167 nicht vorhanden ist. Mein Kitcon-164 ist daher zurzeit mit einem TCXO (12,8 MHz) ausgerüstet. Grüße, Guido
Hallo, nach längerer Zeit mal wieder eine Erweiterung. Ich habe einen ersten Versuch zur Implementierung von Funktions- prozeduren unternommen. Diese ersetzen die von Pascal gewohnten functions und sehen in Oberon-Syntax z.B. so aus (wobei ich Odd gelegentlich als Inlineprozedur implemetieren werde):
1 | PROCEDURE* Odd(v: INTEGER): BOOLEAN; |
2 | BEGIN
|
3 | IF v MOD 2 = 1 THEN RETURN TRUE |
4 | ELSE RETURN FALSE; END; |
5 | END Odd; |
Diese habe ich schon lange vermisst, weil der Notbehelf mit variablen Parametern nicht gerade zur Lesbarkeit des Programms beiträgt. So wird das schon klarer:
1 | IF Odd(i) THEN Writeln("Ungerade") |
2 | ELSE Writeln("Gerade"); END; |
Das Problem war, dass ich keine Idee hatte, wo das Ergebnis abgelegt werden soll. Die Lösung ist simpel: der Compiler legt sich eine globale Variable namens "_FRESULT" an und speichert den mit RETURN übergebenen Wert dort. Das wird zwar später noch viel Spaß beim Modulimport bringen, hat aber den großen Vorteil, dass alle Zugriffe auf dieses Ergebnis automatisch der strengen Typenüberprüfung unterliegen, weil es ja eine ganz normale Variable darstellt, deren Typ auf die jeweilige Prozedur gesetzt wird. Ausführbare Dateien sind wie immer im bin-Ordner des tgz, erweiterte Dokumentation folgt demnächst. Viel Spaß, Guido P.S.: Ich bin gerade auch an einem Disassembler dran, den ich in den Debugger integrieren möchte. Auch dazu demnächst mehr.
Hi Guido, Schön, mal wieder etwas Neues von Dir/C16xOberon zu hören. Hast Du mal daran gedacht, einen Link zu Deinem Compiler evtl. bei den Oberon-Leuten in Zürich zu platzieren ? So könnten evtl. ein paar mehr interessierte Entwickler weltweit den nutzen wollen oder vielleicht auf andere uC-Plattformen portieren ? Herzliche Grüsse, Tom.
Yo, ich nochmal... da bin ich gerade beim guhgelln drüber gestolpert: Oberoncompiler für NXP LPC2000 und Cortex-M3 Arm's. http://www.astrobe.com/default.htm Eine sicherere Programmiersprache als "C", auch für die aufkommende uC-Generation - keine schlechte Idee aus meiner Sicht. Gruss, Tom ;o).
Hallo Tom, danke für das Feedback. Ich bin mir nicht sicher, ob an der ETH diesbezüglich noch viel läuft, die meisten Webseiten sind seit vielen Jahren im Umbau, also tot. Selbst wenn, die Jungs da betreiben ja ein Betriebssystem unter Oberon und sind an meinem kleinen Compiler sicher nicht interessiert. Ich hätte schon auf den einen oder anderen Mitstreiter gehofft. aber die Kombination ist wohl doch zu exotisch. Wobei ich die Vorbehalte gegenüber Oberon nicht verstehe, da es ja doch noch eine Menge Pascal-Programmierer gibt. Die Unterschiede sind gering und die Vorteile von Oberon gegenüber Pascal offensichtlich. Über Astrobe habe ich ja schon weiter oben geschrieben. Ich habe vor knapp 3 Jahren ein Developementboard mit einem NXP LPC2xxx inklusive Astrobe-Lizenz gekauft. Der Compiler ist ganz was anderes als meiner, das "kleiner" in der Threadüberschrift ist daher kein Understatemant. Astrobe ist natürlich 32-bittig und unterstützt das vollständige Oberon inklusive OOP und z.B. 32-Bit-real-Typen. Gleichzeitig sind gerade die NXP-Controller sehr billig. Die Erweiterung auf Cortex M3 ergibt natürlich weitere Kundenkreise. Mit Astrobe habe ich aber selbst garnichts probiert, es hat mich nur darin bestärkt meinen eigenen Compiler voranzutreiben. Die Probleme damit waren, wobei ich mich auf die für Hobbyisten bezahlbare Personal-Edition beziehe: - Windows only - kein Kommandozeilencompiler, also ZwangsIDE - kein Assembleroutput, keine Kontrolle des erzeugten Codes - Folgekosten, da der Kaufpreis eine 1-Jahres-Lizenz bedeutet Ein Oberon-Compiler für ARM7 ist nutzlos, da kann man genausogut den GCC verwenden. Für die Cortex-M3 sieht die Sache schon anders aus. Es wäre sicher möglich meinen Compiler darauf zu portieren. Ich glaube aber nicht, dass ich das leisten werde. Mir reichen die C16x, sofern ich die Nachfolger einbeziehe. Wenn aber jemand anders dies in Angriff nehmen möchte bin ich gerne bereit dabei zu helfen. Meine Roadmap sieht folgendermaßen aus: Zunächst werde ich den Typ INTEGER in WORD umbenennen, damit INTEGER für signed 16-Bit-Typen verfügbar wird. Wenn das läuft gibt es eine neue Dokumentation. Dann möchte ich die SFR-Deklaration in den Compiler übernehmen, Dies wird für die Controller von Infineon einfach, da ich die entsprechenden Definitionen von DAVE übernehmen kann. Für die STM-Controler wird das schwieriger, von STM gibt es keinerlei Support. Natürlich könnte man die Hedaerfiles von Keil benutzen, das wäre aber Klauen. Also werde ich diese für die meinerseits vorhandenen Typen händisch erstellen müssen. Später soll dann natürlich die Unterstützung für INTEGER realisiert werden,die manches Programmierproblem vereinfachen kann. Grüße, Guido
Falls jemand mitspielen, d.h. probieren, möchte: Hier Beitrag "Phytec KC167 board, suche Handbuch und verschenke 4 Stück" verschenkt der Hans gut geeignete, gebrauchte Dev-Boards. Für die könnte ich eine komplette Startumgebung (vorzugsweise unter Linux) mit Schnellstartanleitung zusammenstellen.
Moins Guido, ähemmmm - header files für diverse STM32-CM3, wenn Du nicht die sourcen von Keil nimmst sondern die vom gcc und dann per script nach oberon konvertierst ? gruss, tom.
Hallo, die ersten Schritte von den Natürlichen zu den Ganzen Zahlen ist vollbracht. Ist für so einen jungen Burschen ja nicht ganz einfach.;-) Jetzt gibt es also INTEGER für vorzeichenbehaftete und WORD für vorzeichenlose 16-Bit-Zahlen. Wie für pascaloide Sprachen üblich müssen Werte der Typen über Trunc bzw. Abs ineinander umgewandelt werden, die als Inline-Funktionsprozeduren hinzugekommen sind wie auch Odd. Die einfachen Optimierungen des Compilers, wie z.B. Schieben statt Multiplizieren oder Dividieren, greifen für INTEGER natürlich nicht, so dass der Overhead damit etwas zunimmt. Kann ich mit leben. Zusätzlich habe ich die verknüpften Bedingungen umstrukturiert, weil mir Odd einige Fehler darin aufgewiesen hat. Irgendwie waren die logischen Verknüpfungen verloren gegangen, sind jetzt wieder im Spiel. Have Fun, Guido P.S.: Executables sind wie immer im trunk.tgz.
Wieder einen Schritt weiter, ich habe die Registerdefinitionen in den Compiler übernommem, so dass der Assembler kein Includefile mehr benötigt. Der bekommt einfach die Registeradressen übermittelt und ist, Dank der Arbeit Alfred Arnolds, damit zufrieden. Damit habe ich Alles in eigener Hand, was vor allem für die moderneren Derivate interessant ist. Eine Deklaration der SFR ist dementsprechend nicht mehr nötig und auch nicht mehr möglich. Als Standard sind die Register des C167CR in Form einer Unit in das Steuerprogramm obcc eingebunden. Diese Definition kann durch den Kommandozeilenparameter -ir überschrieben werden, ein paar Beispiele für andere Controller liegen den Sourcen bei. Das Vorgehen hierzu ist in der Dokumentation beschrieben. Als nächstes möchte ich Pointer implementieren, dank Abdul ist klar, wie NIL zu handhaben ist, der Heap ergibt sich auch fast von selbst. Viel Spaß, Guido
Hallo, die Pointer sind implementiert. Ich bin über deren Sinn noch etwas unschlüssig aber die Möglichkeit verkettete Listen anzulegen ist im Vergleich zu Assembler schon nett. Die Pointer werden vom Laufzeitsystem nicht initialisiert, das muss der Nutzer (also ich) selbst übernehmen. Es lohnt aber, da ein mit NIL initialiserter Pointer beim Zugriff einen BTRAP-Interrupt auslöst, ein Fehler sich also mit einer zugehörigen ISR leicht abfangen lässt. Ich hänge mal mein Testmodul (ptest.txt) zur Demonstration an. Es gibt keine Garbage-Collection, schon die Freigabe eines Pointerelementes mittels dispose würde nach meinem Geschmack zuviel Overhead und Ressourcenbedarf produzieren. Die Verwaltung des Heaps obliegt also dem Nutzer, im Testmodul ist auch diese demonstriert (sein Output ist als Kommentar daran angehängt). Wie im Testmodul zu sehen ist, können für ISRs jetzt auch die Vektornamen anstelle ihrer Nummern angegeben werden. Da der Compiler sie eh kennt, war es mir zu mühselig immer die Nummern nachzuschlagen. Dabei ist mir aufgefallen, dass noch immer die Vektoren des C167CR fest im Generator vorgegeben sind. als nächsten Schritt werde ich diese an die Registerdefinitionen anhängen, so dass sie für andere Controllertypen leicht angepasst werden können. Leider gibt es hierfür keine schönen Dateien in DAVE, da ist wohl Handarbeit angesagt. Viel Spaß, Guido
Hallo, hier die nächste Version mit folgenden Erweiterungen und Änderungen: Arrays und Records können jetzt am Block zugewiesen werden. Bis zu 5 Words kopiert der Compiler direkt, für größere Strukturen legt er eine Kopierschleife an. Bei dieser Gelegenheit habe ich mir gleich die lokalen Strukturen in "langen" Prozeduren vorgeknöpft, die jetzt auch benutzbar sind. Diese werden temporär auf dem Frame angelegt. Die Interruptvektoren können jetzt an das jeweilige Derivat angepasst werden. Dazu werden ihre Definitionen an die SFR-Definitionen angehängt und mit diesen geladen. Beispiele für den C164CI und den ST10F276 habe ich den Quellen zugefügt. Alle Systemprozeduren habe ich jetzt konsequent auf Großschreibung umgestellt. Damit wird alles was der Compiler kennt komplett groß geschrieben, was den Zusatznutzen bringt, dass sein Scanner beim Einlesen eine Umwandlung vornehmen kann. Wenn sich jemand an der Großschreibung stört, kann er jetzt mit der Option "-uu1" (UseUpper) seinen Quellcode komplett in Großbuchstaben umwandeln lassen, so dass keine Fehlermeldungen entstehen. Zur Annäherung an N.Wirths Modul System habe ich PEEkW in GET, POKEW in PUT und BREAKPOINT in HALT umbenannt. ADR und GET muss ich bei Gelegenheit zum selben Zweck noch in funktional umschreiben. Viel Spaß, Guido P.S.: Executables sind wie immer im trunk dabei.
:
Bearbeitet durch User
Grmmpf, vor lauter Rumhantieren mit lokalen Arrays und Pointerlementen habe ich einen Bug für globale Arrays mit konstantem Index eingebaut. Eine kurze Zeile in der Prozedur Index im Generator behebt das Problem. deshalb hierzu nur einen Patch. Wenn es jemand probieren möchte: obcc.diff in das Verzeichnis trunk schieben und von dort aus mit
1 | patch -p0 -i ./obcc.diff |
patchen. Viel Spaß, Guido
Hallo, heute mal eine Frage zur Codeerzeugung. Eigentlich ist relozierbarer (relocatable) Code für den C167 erstmal nicht erstellbar, weil ein Lesen des Instruction-Pointers durch das Programm nicht möglich ist. Andererseits behauptet Keil, dass ihr Compiler genau dieses schafft. Übersehe ich da einen Trick? Stackfummeleien scheiden aus. ;-) Wenn das möglich wäre, und ich war bisher felsenfest davon überzeugt, dass die Siemensianer hier an alle Eventualitäten gedacht haben, würde mir dies eine Linkliste für alle Sprünge ersparen. Hat jemand eine Idee? Grüße, Guido
Hallo Guido, tolles Projekt! Ein C-Object File ist relocatable. Auch die einzelnen Funktionen in den LIB. Nach dem Linkprozess erfolgt die Location. Dann sind die Adressen fix.
Danke Locator, für die Blumen und die Bestätigung. Dann muss wohl wirklich ein Linkprozess die Adressen auflösen. Naja, für die globalen Variabken ist das ja auch notwendig.
ein Beispiel: http://www.keil.com/c51/lx51.asp "... The linker resolves external and public references and assigns absolute or fixed addresses to relocatable program segments. ..."
Hallo, nach halbjähriger Umzugs-Schockstarre geht es hier wieder weiter. Ich habe Lookup-Tables (als TABLE) implementiert, zusätzlich Bytetransfers via GETB und PUTB. Ein paar kurze Spezialitäten kommen noch dazu (SRST, EINIT und DUMMIJMP), so dass ich in meinen Programmen nicht mehr auf Assembler zurückgreifen muss. Als Beispiel hänge ich eine zweite Stufe des Bootstraploaders an, die einen AM29F040B am 8-Bit-Bus eines C167 ohne Multiplex mit Daten versorgt. Es muss mit der Compileroption "-ps\$0E000" compiliert werden, da es von der 1. BSL-Stufe an die Startadresse des XRAMs geladen wird und die Initialisierung nicht vom Compiler erstellt wird. Der Hintergrund ist, dass ich die Codeerzeugung mit in den Compiler übernehmen möchte. Das erleichtert größere Erweiterungen enorm, ist aber zunächst mal sehr viel Arbeit. Die direkte Einbindung von Assemblercode bleibt dabei natürlich auf der Strecke, aber nach meinem Gefühl ist sie mittlerweile sowieso unnötig. Falls noch etwas fehlt, kann es ja schnell implementiert werden. Executables sind wie immer im trunk.tgz, viel Spaß, Guido
Hallo, die Codeerzeugung ist erstmal abgeschlossen, der Compiler funktioniert jetzt standalone. Vor allem im Generator waren hierzu einige Umbauarbeiten notwendig, hoffentlich ist dabei nicht zu viel kaputt gegangen. Allerdings ist die Wartbarkeit dadurch deutlich verbessert worden, so dass Fehler leichter eingegrenzt werden können. Ich habe auch die Dokumentation überarbeitet, eine Übersicht an den Anfang gestellt, überholte Abschnitte gelöscht und die Details in einem eigenen Kapitel gesammelt. Dieses wird zukünftig sicher noch wachsen, da ich keine Lust nehr habe, für jede Kleinigkeit im Quelltext rumzuscrollen. Wozu hat man schließlich ein EBook! Als Beispiel hänge ich die überarbeitete Version meines Miniwebservers auf dem MCB167-NET an. Mit der Option -uw0 compiliert liegt seine Länge immer noch bei knapp 5.7 kiB. Die ausgelieferte Webseite ist jetzt, völlig unlesbar, als Tabelle eingebunden (weil das jetzt geht!), für eine echte Anwendung würde ich diese in ein anderes Speichersegment schreiben und mit GET darauf zugreifen (in CopyPage). Zum Compilieren muss enet.txt in enet.mod umbenannt werden, das Resultat erscheint dann als Enet_0.bin. Executables sind wie immer im trunk, viel Spaß, Guido
Lieber Guido, kannst Du den auch für den Cortex M3/M4 schreiben, so einen Oberoncompiler? Das wär richtig Klasse! Joern
Hallo Joern, im Prinzip wäre das schon möglich. Es gibt aber für die M3 Cortex bereits den Oberoncompiler Astrobe von CFB-Software. Der Autor Chris Burrows ist viel weiter als ich, den Vorsprung werde ich wohl nicht aufholen können. Gruß, Guido
Hallo, es hat etwas länger gedauert aber hier ist die nächste Version. Mittlerweile ist der Modulimport realisiert und funktioniert grundlegend. Auch das Linken übernimmt hierbei der Compiler, alle nötigen Informationen erhält er aus einer Symboldatei, einer reinen Textdatei, die er beim Export erstellt. An strukturierten Typen können bisher Arrays und Records skalarer Elemente importiert werden, komplexere Strukturen werde ich nach Bedarf implementieren. Die Einzelheiten habe ich in der Dokumentation erläutert der ich auch ein kurzes Kapitel über den Bootstraploader hinzugefügt habe. Eine ganze Menge Fehler habe ich wieder korrigiert, aber das sind sicher nicht die letzten. Als Beispiel hänge ich das frische Modul zum Lesen von SD-Karten im FAT16- Format an. Zum Testen muss das in "sdc.mod" umbenannt und mit der Option "-im1" compiliert werden. Executables sind wie immer im trunk, viel Spaß, Guido
Hallo ich habe Interesse an 25 x ST10F269-Q3 bitte melden!
> Hallo ich habe Interesse an 25 x ST10F269-Q3 bitte melden!
Damaliger Einkaufspreis 36€, jetziger Verkaufspreis 15€.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.