HIVE-Project

drohne235 hat geschrieben:Mir wäre auch lieber, wenn diese Features von Parallax auch in das Propellertool eingebaut würden. Zumal mir die optische Anzeige der Verschachtlung dort sehr gefällt. Eine sehr gute Variante die Programmstruktur sichtbar zu machen. Außerdem kann man im BST keine Lesezeichen definieren.

Ich besitze zwar hinreichend Windowslizenzen, aber habe absolut keinen Bock auf Windows in meiner Freizeit.
Mir bleiben also nur BST, Homespun und Sphinxcompiler.

BST ist das am weitesten Entwickelte der Dreien... :.(
Ich mag's nicht... es ist nicht quelloffen, träge und bekannte Bugs wurden laaaange nimmer erschlagen... dann lieber die Kommandozeilenvariante BSTC, die ist wenigstens flott zu bedienen...

Sphinx ist dank Quelloffenheit der Sympathiegewinner, kennt aber weder #include, noch #define und Freunde... und gräusig zu bedinen....

Homespun punktet durch Plattformunabhängigkeit dank DotNet/Mono und #define und Freunde sind ihm nicht fremd, ist aber nicht quelloffen...

Der Emacs-Propellermodus und die PZST (oder so ähnlich) sind auch keine Rettung, die stützen sich auf die Kommandozeilenvariante von BSTC.

Catalina-C und GCC benötigen ebenfalls einen Spincompiler unter der Haube, auch sie stützen sich auf Homespun oder BSTC...

Selbst um PropForth hochzupäppeln braucht man einen Spincompiler... :.\

Alles irgendwie unschön...

Die Abhängigkeit von nicht quelloffenen Tools (selbst wenn man denkt man programmiert nicht in Spin und hätte also mit einem Spincompiler garnichts am Hut) stinkt mir hier gewaltig!

...aber es ist Südwind... da bin ich meist schräg gelaunt... vielleicht seh ich das Alles bald schon wieder viel lockerer...

drohne235 hat geschrieben:
ben hat geschrieben:Ist die neuste TriOS Version abwärts kompatibel mit der ersten Hive Version (R13)?
Na klar, ich hab es ja uch noch auf dem ersten Board laufen. Die neue Platine hat einige kosmetische Korrekturen und Verbesserungen und einen RTC.

Heißt das insbesondere daß das aktuelle RTC-Code enthaltende TriOS auf R13-Boards (ohne RTC) noch läuft?

Ich denk ich frag lieber vorher mal bevor ich mir den ansonsten funktionierenden Hive-014 zerflashe und dabei nichts gewinne außer Zeitverlust...

Apropos... ich hab ein make.sh unter Debian-6 zusammengestoppelt und denke das Kompilieren der aus dem SVN gezogenen Quellen klappt damit ganz brauchbar.

Aber die Kompilate sind bislang noch ungetestet bis die "RTC-Code vs R13-Board"-Frage geklärt ist...

Es wäre auch nett wenn die linuxbasierten Betriebssysteme den Windowsen gleichgestellt würden und bstc.linux (genau wie bstc.exe) im SVN läge...
...so wäre außerdem sichergestellt daß eine durch das SVN definierte bstc-Version zum Einsatz kommt statt irgendwelcher Prereleases die der interessierte Freak vielleicht irgendwo hingelegt hat.

Heißt das insbesondere daß das aktuelle RTC-Code enthaltende TriOS auf R13-Boards (ohne RTC) noch läuft?

Läuft problemlos. Wenn die I2C-Routinen der FatEngine keinen realen RTC finden, liefern sie einen Defaultwert zurück. Ich hab mir das zwar nicht ganz genau angeschaut, aber zumindest läuft der Code auf einem Board ohne RTC und bleibt nicht hängen oder liefert irgendwelche Katastrophenwerte zurück.

Make ist natürlich eine wesentlich bessere Lösung als eine Batch-Datei.

Ich werde die beiden Dateien bei der nächsten Gelegenheit mit ins SVN packen, wenn du den Startschuss gibst.

drohne235 hat geschrieben:
Heißt das insbesondere daß das aktuelle RTC-Code enthaltende TriOS auf R13-Boards (ohne RTC) noch läuft?
Läuft problemlos. Wenn die I2C-Routinen der FatEngine keinen realen RTC finden, liefern sie einen Defaultwert zurück. Ich hab mir das zwar nicht ganz genau angeschaut, aber zumindest läuft der Code auf einem Board ohne RTC und bleibt nicht hängen oder liefert irgendwelche Katastrophenwerte zurück.

Primstens... dann trau ich mich auch alsbald mal ans Flashen...

drohne235 hat geschrieben:Make ist natürlich eine wesentlich bessere Lösung als eine Batch-Datei. Ich werde die beiden Dateien bei der nächsten Gelegenheit mit ins SVN packen, wenn du den Startschuss gibst.

make.sh ist noch eine recht geradlinige Übersetzung Deiner make.bat.
Ein richtiges Makefile schwebt mir schon vor aber aber ohne alle benutzten Objekte pro "Hauptprogramm" anzugeben bringt das wenig.

Manuell Alles ins Makefile schreiben was man in OBJ-Abschnitten benutzt hat läuft auf Dauer so auseinander wie Programm und Doku... das kennen wir ja Alle... zumindest die von uns die ehrlich sind...

...automagisch diesen 16-Bit-Zeichenkram aus der Parallax-IDE zu parsen find ich auch grad irgendwie unerquicklich...

Ich muß darüber noch 'ne Weile grübeln und bis dahin ist make.sh halt nix Anderes als ein "Unix-Batchfile"...

Hallo yeti,

yeti hat geschrieben:...automagisch diesen 16-Bit-Zeichenkram aus der Parallax-IDE zu parsen find ich auch grad irgendwie unerquicklich...
Ich muß darüber noch 'ne Weile grübeln und bis dahin ist make.sh halt nix Anderes als ein "Unix-Batchfile"...

Diese 16Bit darstellung ist recht harmlos, komplizierter wird das erst wenn in einem Datenpaket die Darstellung 8/16/24/32 Bit pro zeichen vorhanden ist weil alles von verschidenen Programmen wird und am Ende zu einer Komponente wird wo jede ihren eigenen zeichensatz benötigt.

Mit 8/16 Bit Sieht das noch garnicht so schlecht aus.

Wenn ich mich recht erinnere war die Einleitung der Daten bei 16Bit darstellung $FF, $FF, anschließend der Text in 16Bit Form

Das macht beim Parsen die ganze sache etwas Landessprachen abhänig.

Sollte aber beim umsetzen der Zeichen (Import) mit Hilfe von Tabellen kein Problem sein.

yeti hat geschrieben:...automagisch diesen 16-Bit-Zeichenkram aus der Parallax-IDE zu parsen find ich auch grad irgendwie unerquicklich...

...auch ohne Unicode-16-Zeichen ist das unerquicklich... fällt mir nach ein wenig Abstand nehmen auf...

Man sollte das wie bei gcc lösen: Eine Option die die Quellen durchnudelt ohne Code zu generieren und dabei nur die Abhängigkeiten protokolliert. Das müsste Mister BST dann wohl höchstselbst in den Kompiler einbauen aber das ist der einzig sinnige Weg, denn ein eigener Parser müsste alle Feinheiten des Parsers des Kompilers kennen und alle Präprozessor-Anweisungen ausführen bevor geschaut wird wo nun tatsächlich OBJ steht...

Man sollte Brad mal mit dieser Idee impfen... wenn er mal wieder im Parallaxforum auftaucht...

Bleiben also noch 2 Varianten:

Brav selber alle Objektabhängigkeiten ins Makefile eintragen. Aber auch da muß man schauen z.B. welcher #define unter Umständen welche Änderungen in den Abhängigkeiten verändert und das entsprechend im Makefile mit konditionellen Anweisungen abbilden...

...ooooder...

...das bis zu einer besseren Idee aussitzen und mit dem Kommentar "BSTC ist eh superluxusrattenscharf sauschnell!" auf den geringen Zeitgewinn durch ein sauberes Makefile hinweisen.

drohne235 hat geschrieben:Make ist natürlich eine wesentlich bessere Lösung als eine Batch-Datei.

Die Idee ein "echtes" Makefile zu bauen hab ich erstmal runterpriorisiert... die Begründung steht schon im Thread...

drohne235 hat geschrieben:Ich werde die beiden Dateien bei der nächsten Gelegenheit mit ins SVN packen, wenn du den Startschuss gibst.

bst.linux habe ich nun in meinen lokalen SVN.Repo-Clone gelegt und spiele damit erstmal 'ne Runde rum.
Der aktuelle Stand von make.sh ist (mit geringer Verzögerung) in seinem natürlichen Biotop öffentlich einsehbar: http://www.wuala.com/utanapischti/sync/ ... read-only/
Dies automatisch synchronisierende Verzeichnis erspart mir das manuelle Hochladen nach jeder kleinen Änderung.

Ok...

Die mit make.sh erzeugten Binaries habe ich geflasht und die SD-Karte neu gebastelt und siehe da: Es läuft!

Ich denke das kann sich gut noch 'ne Weile setzen bis es ins SVN kommt, denn es ist ja an oben erwähnter Stelle quasi live einsehbar... im Zweifel sogar mit den neuesten Vertippern.

yeti hat geschrieben:Die Idee ein "echtes" Makefile zu bauen hab ich erstmal runterpriorisiert... die Begründung steht schon im Thread...

Mir ist da gerade etwas aufgefallen:

Code: Alles auswählen

(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ ls -l
insgesamt 12
drwxr-xr-x 2 yeti yeti 4096 14. Jan 13:56 lib
-rw-r--r-- 1 yeti yeti 7025 14. Jan 14:06 xx.spin

Wie Sie sehen sehen Sie Nichts!
...also weder xx.binary-, noch xx.eeprom.

Code: Alles auswählen

(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ ../hive-trios-svn/hive-trios-read-only/bstc.linux -O a -L lib xx.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object xx
Loading Object conio
Loading Object fileio
Program size is 2236 longs
1 Constants folded
Compiled 368 Lines of Code in 0.064 Seconds
(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ ls -l
insgesamt 12
drwxr-xr-x 2 yeti yeti 4096 14. Jan 13:56 lib
-rw-r--r-- 1 yeti yeti 7025 14. Jan 14:06 xx.spin

Wie Sie sehen sehen Sie immernoch Nichts!
...also immernoch weder xx.binary-, noch xx.eeprom.

Aber was war zwischendurch?

bstc hat xx.spin durchgekaut und dabei alle benutzten OBJs aufgelistet.

...da läßt sich vielleicht was draus machen...

Ein Testprogramm mit #define muß her... ich hab das ursprüngliche xx.spin mal radikal aufs Wesentliche zusammengestutzt und nun schaut es so aus:

Code: Alles auswählen

(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ cat xx.spin 
obj
#ifdef use_conio
  ser : "conio"
#endif
  fs : "fileio"

Und der codeerzeugungsfreie Übersetzungslauf:

Code: Alles auswählen

(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ ../hive-trios-svn/hive-trios-read-only/bstc.linux -O a -L lib xx.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object xx
Loading Object fileio

xx - Object requires at least one PUB block

1 Constants folded
Compiled 128 Lines of Code in 0.012 Seconds

Der Fehler war zu erwarten.
...aber es wurde nur das Objekt das nicht in #ifdef/#endif geklammert ist ausgegeben.

Nun nochmal mit definiertem #define-Wert:

Code: Alles auswählen

(yeti@destiny:1)~/Desktop/wrk/tmp/spinsim$ ../hive-trios-svn/hive-trios-read-only/bstc.linux -O a -L lib -D use_conio xx.spin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object xx
Loading Object conio
Loading Object fileio

xx - Object requires at least one PUB block

1 Constants folded
Compiled 193 Lines of Code in 0.02 Seconds

Primstenst!
Das hat Potential!
...und war eigentlich irgendwie naheliegend...
...und die Ausgabe parsen und daraus Makefile-Schnipsel bauen ist auch keine schwarze Magie...

Das muß ich später nochmal mit etwas Abstand betrachten...

HIVE-Project

TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag]

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag

Re: TriOS [aktuelle Arbeitsversion und Log im ersten Beitrag