PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Syntax-Highlighting für Bascom mit Kate in Linux



lsmod
24.02.2012, 18:37
Ich arbeite mit Bascom unter Linux.
Da die Klicki-Bunti-Oberfläche von Bascom hier nur unschön läuft und der Editor meiner Meinung nach so oder so nix taugt, verwende ich als Editor Kate aus KDE.
Alle modernen Funktionen eines Editors sind hier nutzbar.

In Kate gab es schon ansatzweise ein Syntax-Highlighting für diverse Basic-Dialekte, aber es hat mich gestört das diese für Bascom nicht perfekt sind.
Daher habe ich ein angepasstes Sytax-Highlighting für Bascom erstellt.

Die XML-Datei gehört normalerweise in das Verzeichnis /usr/share/kde4/apps/katepart/syntax und schon kann beim nächsten Aufruf dieses Syntax-Highlighting ausgewählt werden.

Ich habe auch einen Screenshot erstellt, damit man sehen kann wie das Endergebnis in einem Beispiel aussieht.

Viel Vergnügen!

ePyx
24.02.2012, 19:50
Cool. Benutze zwar weder Bascom noch Kate, aber finde es dennoch Klasse. Hab aber ne Frage, hätte nicht einfach der Syntax-Highlighter für einen beliebigen Basic-Dialekt gereicht ? Dazu muss ich aber sagen, dass ich absolut keinen Plan von Bascom habe.

lsmod
25.02.2012, 16:25
Hallo Daniel,

Danke für Deine Einstufung in schön und nutzlos. ;)
Die kann ich aber auch durchaus verstehen, denn wahrscheinlich gibt es kaum Bascom-Anwender in der Linux-Welt.:mrgreen:
Ich verstehe dafür nicht wie man mit dem Original-Editor schreiben kann, wo es doch deutlich Bessere gibt.

Das Syntax-Highlighting für andere Basic-Dialekte unterstützt natürlich nicht die vielen speziellen Befehle und Funktionen von Bascom.
Genau diese machen aber den Reiz der Benutzung von Bascom aus, denn man muss keine Libraries deklarieren und einbinden. sondern kann die vielen komfortablen Funktionen einfach benutzen.
Deshalb ist es auch hilfreich wenn reservierte Worte direkt durch Highlighting hervorgehoben werden.

ePyx
25.02.2012, 16:42
Wollte dein Werk keineswegs als nutzlos hinstellen. War eigentlich nur eine Frage seitens persönlichem Interesse. Gerade weil ich keinen Plan von Bascom habe und wahrscheinlich auch nicht bekommen werden.

Dadurch hab ich auch keine Ahnung, ob es spezielle Schlüsselwörter oder syntaktische Änderungen hinsichtlich der anderen Basic-Dialekte.

Also sorry, wenn es so rüber kam. Freuen tut es mich, dass man etwas für andere macht. Speziell im OpenSource-Sektor.

!*sascha*!
25.02.2012, 19:58
Super!

Der Bascom Editor ist eine Katastrophe :-) Ich habe meine Projekte immer gern auf allen Systemen (Windows/Ubuntu/Mac) griffbereit und freue mich über deine Lösung!

Wenn jetzt der Compiler noch mit Wine funktionieren würde, oder es einen Bascom Compiler für Unix geben würde... *schmunzel*

Danke für deine Mühe.

Gruß,
Sascha

lsmod
27.02.2012, 09:14
Wollte dein Werk keineswegs als nutzlos hinstellen. War eigentlich nur eine Frage seitens persönlichem Interesse. Gerade weil ich keinen Plan von Bascom habe und wahrscheinlich auch nicht bekommen werden.

Du brauchst Dich nicht zu entschuldigen - ich bin eigentlich nur neugierig warum Dich diese Lösung interessiert wenn Du Bascom nicht benutzt?
Was benutzt du dann?


Super!
Wenn jetzt der Compiler noch mit Wine funktionieren würde, oder es einen Bascom Compiler für Unix geben würde... *schmunzel*

Bascom läuft so weit einwandfrei unter Wine.
Es gibt zwar einen Fehler beim Start weil Bascom nicht auf eine Programmierschnittstelle zugreifen kann, aber dann startet die Oberfläche soweit einwandfrei und alle Funktionen sind nutzbar.
Bisher sind mir lediglich folgende Problemchen aufgefallen, die offensichtlich an der Programmierung von Bascom liegen.
1. Alles läuft sehr behäbig und zögerlich.
2. Die Oberfläche verbraucht unnützerweise irrsinnig viel Prozessorleistung, scheinbar weil der Editor mit Polling arbeitet.
3. Da Wine keinen direkten Zugriff auf die parallele Schnittstelle erlaubt noch USB bis jetzt implementert ist kann man nicht direkt flashen.

Zum programmieren ist dies aber alles nicht notwendig, da man die Oberfläche für die Benutzung des eigentlichen Bascom-Compiler nicht benötigt!

ePyx
27.02.2012, 09:24
Du brauchst Dich nicht zu entschuldigen - ich bin eigentlich nur neugierig warum Dich diese Lösung interessiert wenn Du Bascom nicht benutzt?
Was benutzt du dann?

Interessiert hat es mich, da ich keine Erfahrung mit Bascom habe und du dir die Mühe gemacht hast, etwas für Linux zu tun.

Selbst benutze ich momentan ( gezwungen durch meine Arbeit) AVRStudio und dort hauptsächlich C/C++ aber auch Assembler. Privat bin ich aber weitestgehend befreit von Windows und benutze unter Linux meist vim in Kombination mit avrdude, ctag usw., da Eclipse bei mir bisher nicht überzeugen konnte und ich eh meist nur eine Shell habe.

Im Übrigen heißt "Nicht benutzen" ja nicht zwingend uninteressant. Wird schon Gründe geben, warum sich so viele Leute mit Bascom vergnügen.

Also ums knapp zu halten, interessiere mich quasi für fast alles und dachte ich frag mal und honoriere deine Arbeit. ;)

lsmod
27.02.2012, 09:32
Dann natürlich vielen Dank für die Blumen! :)

Ich verstehe C-Code zwar ganz gut, bin aber einfach zu faul es richtig zu lernen und zu benutzen.
Die Syntax ist einfach nicht so eingängig (vor allem die Bezeichner in den Libs) und mich nervt das man alles deklarieren muss.
Ausserdem bin ich kein Freund von der Bearbeitung mehrerer Dateien (.h + .c) für so kleine überschaubare Sachen.
Unter Linux benutze ich sonst auch nur Perl.

Der Quellcode von Bascom ist sehr schön lesbar, auch wenn man diesen längere Zeit nicht mehr benutzt hat.
Der Nachteil ist das komplexere Strukturen nicht wirklich unterstützt werden, aber das ist bei solch kleinen Prozessoren mit so wenig Speicher auch kein wirklicher Nachteil.

Vielleicht kannst du mir trotzdem noch C etwas näher bringen. :-k

ePyx
27.02.2012, 09:47
Nun das mit der Aufteilung in mehreren Dateien hat den großen Vorteil, dass der Code für andere Sachen wiederverwendbar ist (Code-Recylcing). So muss man nicht alles doppelt machen. Hab irgendwann mal in der Uni gelernt, dass man sein Zeug modular halten sollte und da ich auch Arbeit Software entwickel ist bei mir eh immer C/C++ angesagt. Für ganz kleine Controller nehme ich dann halt Assembler.

Bei mir ist das mit der Lesbarkeit übrigens genau andersherum. Ich tue mich schwer beim Lesen von Bascom-Code und antworte daher auch auf keine Threads mit Bascom-Code, zum einen weil ich es anstrengend finde den Code zu lesen ( Jede Sprach hat ihre eigenen Macken+Tücken) und zum anderen, da ich den Leuten meist nicht helfen kann (außer sie wollen noch mehr Fehler ;)). Was ich sich nicht sagen werde ist, dass C die Must-Have-Sprache ist. Allerdings komme ich damit extrem gut klar und nutze sie eh jeden Tag mehrere Stunden am Stück auf verschiedenen Plattformen oder Geräten.

lsmod
27.02.2012, 09:52
Ich stelle Euch also auch noch am besten ein kleines Shellskript zur Verfügung, welches ich zum kompilieren und flashen benutze.

Mit dem Editor Kate editiere ich die Quelldateien, dann habe ich immer noch ein Konsolenfenster im jeweiligen Arbeits-/Projektpfad auf.
Hier rufe ich dann einfach das Shellskript auf.

./binflash Bascomdatei_ohne_bas

Die Datei wird dann kompiliert.
Gibt es Fehler werden diese ausgegeben und die Verarbeitung abgebrochen.
An sonsten werden nur die wichtigsten Daten ausgegeben und danach auf eine Tasteneingabe gewartet.
Danach wird das Binary mit avrdude geflasht.

Dies funktioniert deutlich schneller als unter der Oberfläche, vor allem da man sich das ganze klicken sparen kann. :cool:


Das Shellskript ist immer noch sehr rudimentär und könnte deutlich verbessert werden.
Für Verbesserungen wäre ich also sehr dankbar.

Vor allem habe ich zur Zeit noch jeweils eine Kopie von binflash.sh in jedem Projektpfad.
Der Projektpfad muss jeweils angepasst werden:

Projekt="Projektname"

Ich habe dies noch nicht geändert, da auch die Compileroptionen hier angepasst werden können bzw. müssen:

/usr/bin/wine bascomp.exe 'd:\Bascom\$Projekt\'$1'.bas' SS=100 FR=100 HW=100 CHIP=17
Scheinbar werden die Parameter für den Stack sowie der Chip vom Compiler nicht aus dem Quellcode ausgelesen, sondern dem Compiler beim Aufruf übergeben.

Die Angaben müssen also beim Aufruf mit korrekt übergeben werden!


Der komplette Vorgang erzeugt dann z.B. so eine Ausgabe:

PC:/win/Bascom/Netswitch$ ./binflash.sh Test6

err:winedevice:ServiceMain driver L"IOPort" failed to load
bascomp command line compiler version 1.11.9.x
supports all existing and future DAT files
DAT Directory :C:\Programme\BASCOM-AVR\*.DAT
DAT files found :67
EEPROM : 200 hex
ROMSIZE : 2000 hex
ROMIMAGE : 5E6 hex -> Will fit into ROM
ROMIMAGE : 1510 dec
_ROMSIZE 8192
FLASH USED : 18 %

Compiled - ready to flash!


avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/win/Bascom/Netswitch/Test6.bin"
avrdude: writing flash (1510 bytes):

Writing | ################################################## | 100% 0.94s



avrdude: 1510 bytes of flash written
avrdude: verifying flash memory against /win/Bascom/Netswitch/Test6.bin:
avrdude: load data flash data from input file /win/Bascom/Netswitch/Test6.bin:
avrdude: input file /win/Bascom/Netswitch/Test6.bin contains 1510 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.48s



avrdude: verifying ...
avrdude: 1510 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

lsmod
27.02.2012, 09:56
Was ich sich nicht sagen werde ist, dass C die Must-Have-Sprache ist. Allerdings komme ich damit extrem gut klar und nutze sie eh jeden Tag mehrere Stunden am Stück auf verschiedenen Plattformen oder Geräten.

Dies kann ich blind unterschreiben!
Vor allem ist der entscheidende Punkt das man aus C "sehr schnell wieder rauskommt", wenn man es nicht regelmässig benutzt.
Mit regelmässig ist hier wirklich idealerweise täglich gemeint.
Deshalb kann man von einer starken Modulisierung ebenfalls nur dann profitieren, wenn man im Code immer drinn ist.
Bei "Gelegenheitsprogrammierern" sieht das dann allerdings recht schnell anders aus ...

An sonsten ist C natürlich zur Zeit die Sprache.

Gruß Karsten

ePyx
27.02.2012, 10:08
Ganz so schlimm ist es auch nicht. Es kommt auch darauf an, was du umsetzen willst und wie die Anforderungen bzgl. Speicher und Performance sind. Wenn es sehr komplex wird, dann nützt auch C nichts mehr, da der Overhead sehr schnell und sehr stark wächst. Da wäre dann C++ sicherlich die geeignetere Wahl.

Wenn man ab und an etwas programmiert ist das "Wiederreinkommen" stark von der persönlichen Abstraktionsfähigkeit abhängig. Ich hab mich auch mal an Perl versucht, aber dort war der Syntax für mich schlichtweg unlogisch und hässlich.

21658

Daher gehe ich mal davon aus, dass es anderen mit C oder Assembler und vielleicht auch mit den Basic-Dialekten ähnlich geht. Zu allerletzt ist es auch nicht unwichtig, ob man sich die Sprache selbst aneignet oder sie richtig lernt. Denn wenn man ehrlich ist, dann lernt man im Selbststudium meist eh nur das was man braucht und das dann auch nur solange wie es Spaß macht. :)

lsmod
27.02.2012, 10:37
Ja - genau so dürfte es sein! :)
Ich habe programmieren wirklich nur autodidaktisch gelernt.
Dabei habe ich mit Basic angefangen und bin damit aufgewachsen.
Und somit als Programmierer nie erwachsen geworden. :cheesy:

Perl ist zuerst einmal bis auf das ; am Ende recht ähnlich zu Basic.
Aber noch mal deutlich mehr "Quick and Dirty" !
Vor allem aber lässt es deutlich mehr Varianten zu wie man programmieren kann.
Dies führt manchmal dazu das Quellcode gar nicht mehr compiliert werden muss um unverständlich zu werden. :mrgreen:
Aber es ist dafür auf fast jedem System vorhanden - sogar als Microperl auf Routern u.v.m.