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.
Grüße,
Daniel
Super!
Der Bascom Editor ist eine KatastropheIch 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
Du brauchst Dich nicht zu entschuldigen - ich bin eigentlich nur neugierig warum Dich diese Lösung interessiert wenn Du Bascom nicht benutzt?Zitat von ePyx
Was benutzt du dann?
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!
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.
Grüße,
Daniel
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.
Geändert von lsmod (27.02.2012 um 09:52 Uhr)
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
Grüße,
Daniel
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
Geändert von lsmod (27.02.2012 um 10:04 Uhr)
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.
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.
Grüße,
Daniel
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.
Die Datei wird dann kompiliert.Code:./binflash Bascomdatei_ohne_bas
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.
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:
Ich habe dies noch nicht geändert, da auch die Compileroptionen hier angepasst werden können bzw. müssen:Code:Projekt="Projektname"
Scheinbar werden die Parameter für den Stack sowie der Chip vom Compiler nicht aus dem Quellcode ausgelesen, sondern dem Compiler beim Aufruf übergeben.Code:/usr/bin/wine bascomp.exe 'd:\Bascom\$Projekt\'$1'.bas' SS=100 FR=100 HW=100 CHIP=17
Die Angaben müssen also beim Aufruf mit korrekt übergeben werden!
Der komplette Vorgang erzeugt dann z.B. so eine Ausgabe:
Code: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.
Berechtigungen
Zitieren
Lesezeichen