Hallo ich bin Blutiger Anfänger.
Ich habe bis lang mit WINXP Bascom und meinem ATtiny2313 einfache
blinkschaltungen zusammen gebaut und Programmiert.
Jetzt wollte ich mal fragen ob ich es Verstanden habe.
Ich schreibe ein Programm in der Sprache BASIC mit hilfe von BASCOM
erstelle ich eine .HEX Datei die ich dann mit PONYPROG in den AVR
schiebe.
Genau das gleiche mit C. Ich schriebe eine Programm mit C z.b mit myAVR
oder avr-gcc und diese beiden Programme machen dann eine .HEX-Datei die
ich dann mit Ponyprog in den AVR schiebe.
Die Programme die die .HEX Datei ertsllen heisten Compiler?
Ist das soweit korrekt?
Ich wollte jetzt auf LINUX umsteigen.
Wie gesagt ich habe mit BASCOM gearbeitet und suche schon seit einiger
Zeit nach einer Bascom Version für Linux (mit wine geht es nicht).
Könntet ihr mir einen Tip geben?
Ich habe bei jedem mit BASCOM geschrieben Programm ganz am Anfang so
angefangen: $INCLUDE=..., $BAUD0... $CRYSTAL=...
Muss ich das NUR bei BASCOM machne oder immer wenn ich mit BASIC
Programmiere?
VIELEN LIEBEN DANK FÜR DIE HILFE! EUER DANIEL HUBERTUS
>BASCOM
hat einen Hersteller. Wenn der keine Linux-Variante anbietet, ist es
auch eher unwahrscheinlich, dass es gibt.
>Die Programme die die .HEX Datei ertsllen heisten Compiler?
Ja.
>Soll das heißen, wenn ich weiter unter linux arbeiten möchte habe ich>keine Möglichkeit in der Sprache Basic meine AVR Programme zu schrieben?
Vermutlich. Informationen sollte man zu diesem Thema beim Hersteller
finden.(FAQ, Mail...)
>die neueste BASCOM-Version soll auch unter Linux (Wine) laufen.
[OT]
Irgendwie widerspricht es sich meiner Meinung nach, Linux und Bascom zu
verwenden - Ist aber nur meine Meinung. Vermutlich gibt es aber auch
"reine Linux-Anwender".
[/OT]
bei mir funktionier auch die aktuellste BASCOM version über wine nicht,
noch nicht mal ne Fehlermeldung gibt er aus.
http://www.yabasic.de/
das habe ich gefunden mal schaun ob damit was anzufangen ist
Auf der anderen Seite sollte man sich einfach mal fragen, ob die
Notwendigkeit besteht, unter
Klickibuntikernelkompilierungsskriptgülleterminal zu arbeiten. man kommt
ja offensichtlich nicht sehr weit. Windows rules...
Wenn du auf Linux umsteigen wirst, muß du auch für Linux stehen und das
Windows nicht mehr benutzen. Erst wird auf Windows geschimpft und dann
wird wieder mit WINE gearbeitet....lol...
Mut zur Lücke und kein geplänkel.
MFG
Steig auf C oder Assembler um, da hast du alles was du brauchst unter
GNU/Linux (bis auf debugger für Assembler :( , zumindest hab ich noh
keinen gefunden).
Hallo,
Falls das noch jemand interessiert:
Ich habe, nachdem ich es nicht geschafft habe Bascom-avr unter wine zum
laufen zu bringenm, heute mal den bascom command line compiler
ausprobiert. Das ist zwar nur der Compiler also ohne IDE o.ä., aber
diesen habe ich unter Linux (Kubuntu dapper mit wine 0.9.28) ohne
größere Probleme zum Laufen bekommen!
Wenn interesse besteht kann ich hier noch ein genaues Workaround
veröffentlichen!
@ Aufreger deluxe: Was allerdings Linux mit klickibunti zutun hat, musst
du mir mal genauer erklären (vorallem bei den anforderungen vom neuen,
bunten windows desktop unter vista G)
>Was allerdings Linux mit klickibunti zutun hat, musst>du mir mal genauer erklären
Wenn man unter Linux unbedingt "wine" braucht, kann man sich wohl doch
nicht von Windows trennen...
Besser als mit solchen Gebastel ist man dran, wenn man auf C oder
Assembler umsteigt, oder die BASCOM-Entwickler dazu bringt, BASCOM auch
für Linux zu entwickeln (sollte eigentlich relativ unproblematisch ein,
eine "hübsche" IDE an den Compiler zu knüpfen...).
Für C und Assembler gibt es schon Lösungen für Linux - für BASCOM eben
noch nicht.
>Linux mit klickibunti
Wer benutzt Linux denn als reine Consolen-Anwendung?
Sowas macht man doch nur, wenn man einen Router, Server oder anderen
"Sklaven" aufbaut.
Bei Anwendungen hat man sich doch inzwischen an "Klicki" gewöhnt, wenn
man auch noch einen Farbmonitor besitzt, ist "bunti" nicht weit...
>bunten windows desktop unter vista
Sowas kommt mir nicht auf den PC. Ich habe noch mit Monochrommonitoren
gearbeitet (bernstein, grün und schwarz/weiß).
Wenn es so einfach wäre MCS dazu zu bringen Bascom auf Linux zu
portieren hätten sie es denke ich schon gemacht. Immerhin gibt es ja in
deren Knowledgebase sogar einen Eintrag wie jemand den BASCOM-8051 mit
wine installiert hat, das Problem ist denen daher offensichtlich
bekannt, kann oder soll aber nicht behoben werden ;)
>>Wenn man unter Linux unbedingt "wine" braucht, kann man sich wohl doch>>nicht von Windows trennen...
Imho liegt das mehr daran das man sich nicht von Bascom trennen will und
das nunmal nicht unter linux läuft. Ich wäre froh wenn ich wine nicht
bräuchte (für andere sachen brauche ich es übrigens auch garnicht)
Und nochmal zum klickibunti :p
"Wer benutzt Linux denn als reine Consolen-Anwendung?" -> immerhin geht
es linux ohne x-server, im gegensatz zu windows. Der windows-desktop ist
genauso bunt, daraus lässt sich imho schließen, dass klickibunti nix mit
linux oder windows zu tun hat, sonderni viel mehr mit den allgemenen
erwartungen an eine grafische oberfläche in heutiger zeit. (ich habe
auch noch mit monochrommonitoren gearbeitet.) naja, lassen wir das,
linux oder windows-grundsatzdiskussionen kann man woanders führen
Das problem habe ich auch. viele anwendungen gibt es einfach nicht für
linux, wenn man sich in eine bestimmte software, aus welchem grund auch
immer, eingearbeitet hat kommmt man leider oftmals nicht um eine kleine
windows installation drum rum..
>immerhin geht es linux ohne x-server, im gegensatz zu windows.
Ich gehe mal davon aus, dass es "immerhin geht linux ohne x-server, im
gegensatz zu windows."
Bis 2000/XP auf den Markt kam, waren sämtliche Windows-Versionen
DOS-Aufsätze und liefen quasi auch ohne klickibunti...
Wenn es bunt und laut ist, kommt es bei vielen besser an...
>kann oder soll aber nicht behoben werden ;)
Vermutlich...
Achtung, sonst gehts hier noch so um wie im Heise Forum...
Da ich auch gerne unter Linux oder auch MacOS (weil hat
Unixkern/Funktionalität) arbeite bin ich jetzt auch beim AVR-GCC
gelandet, obwohl ich am liebsten mit Pascal programmieren würde.
Aber immerhin endlich ein wirklicher Grund für mich C zu lernen!
die gcc kann doch pascal... zumindest gibts da einen patch soweit ich
das mitbekommen hab ... also müsste nur jemand die libs für pascal
schreiben und schon kannst deine avrs mit pascal füttern ;)
btw wenn jemand es bunt und trotzdem schnell UND übersichtlich haben
will mandriva-pro 2007 ;) mit wirklich geil konfiguriertem kde.. und die
3d-effekte kann man auch einschalten wenn man sehen will was man so
machen und trotzdem auch noch damit arbeiten kann mit einer
billigst-3d-karte ohne min 1gig ram und dual-core ;P
ich find das alles krank.. 2 hdtv streams kann ich auch ohne probs mit
meiner fx5200 und nem sempron 2600+ gleichzeitig anschaun wenn ich will
(warn test ob der vdr so ohne weiteres 2 unterschiedlichs OSDs anzeigt)
aber irgendwie geht das hier alles schon in richtung off-topic...
wie oben schon erwähnt .. neueste version von bascom und neuest version
von wine (am besten aus dem cvs) dann schaun was sich tut...
73
Nee, ich bleib jetzt mal bei C, zumindest bei den uC, wollts ja schon
immer lernen, war nur zu faul.
Beim wine gibts unendlich viel zum einstellen (Configfiles) und wenn ein
Programm nicht starten will kommt man normalerweise in einen Debugger,
der ist aber Terminalgebunden, also die Programme zum testen am besten
via Kommandozeile starten (also "~$ wine bascom.exe" oder wie die EXE
heisst).
Aber die Erfahrung zeigt dass die Programme dann doch meist nicht so
schön wie unter Windows laufen, leider.
das stimmt nur bedingt... das problem ist, dass die gdi-api,mfc und auch
etwas exotischere libs teilweise buggy sind und da baut man dann halt
workarounds ein.. und die könnten teilweise auf dem falschen verhalten
aufsetzen und dann krachts unter wine...
ein anderer punkt der mir vor allem bei bascom einfällt ist das
programmieren und debuggen.. da wirst du dich sicher ärgern dürfen damit
du wine beibringst die richtigen com-ports mit den richtigen devices in
/dev zu verknüpfen ;)
im übrigen brauchst du eigentlich nur winecfg auf der kommandozeile
ausführen und einmal drüberlesen was da so steht.. teilweise hilfts
programme mit den seltsamen virtuellen-desktops laufen zu lassen..
überall wo du nicht sicher bist nix verändern dann sollts hinhaun...
in den debugger kommst du eigentlich nur wenns wirklich kracht.. und das
tuts eigentlich nur bei der oben beschriebenen workaround-problematik
oder wenn irgendwelche funktionen nur als stub in wine drinnen sind...
btw es gibt ja auch open-source "windows"... reactos :)
73
Hi Hans!
MFC ist ja leider gar net soo exotisch, an denen bin ich beim Wine ja
schon oft verzweifelt.
COM-Ports sind übrigens kein Problem, gingen z.b. auch bei dem C-Control
Programm ganz gut.
Aber beim wine hat sich auch schon viel getan muss man sagen, '95 hatte
der ja noch Probleme mit notepad, auch wenn inzwischen 11 Jahre
vergangen sind ist das ja sehr viel Arbeit so viel closed source
nachzubauen.
Reactos beobachte (und teste) ich auch immer ein bisschen, klingt
vielversprechend dauert aber sicher noch ein weilchen bis man das
produktiv einsetzen kann.
Grüße,
Alex
Ich frage mich die ganze Zeit, was daran schwierig ist, einen vorhanden
Compiler (und was noch dazu gehört) auf eine andere Plattform bzw. ein
anderes Betriebssystem zu portieren. Wenn er in einer portablen Sprache
geschrieben ist (z.B. C), dann sollte es eigentlich ziemlich einfach
sein - ich meine nicht das Zeug, was noch zum Entwickeln dazu gehört,
wie IDE etc.
Ein Compiler für AVR sollte doch auf jedem PC laufen können. Dabei
handelt es sich ja eigentlich um nichts anderes als eine
Textersetzungsmaschine (jetzt dürfen mich Compilerbauer verhauen...).
Wenn man den Compiler, wie den gcc, als Consolen-Anwendung entwickelt,
sollte ein Plattformwechsel unproblematisch sein.
Böse Vermutungen: Die Entwickler von BASCOM haben entweder keine Lust,
etwas für Linux zu entwickeln, oder das Programm ist auf einer
Windows-Maschine gewachsen und in einer unportablen Programmiersprache
entstanden...(oder die Jungs sind einfach mit der Portierung
überlastet...)
Übrigens habe ich grossen Respekt vor Leuten, die Compiler entwickeln -
egal für welche Sprache - ich könnte sowas nicht unbedingt.
Viele Softwarefirmen (mit denen ich bis jetzt zu tun hatte) haben Angst
das Ergebnis dann zu supporten.
z.B: wegen der vielen Linuxdistributionen, Einstellungen und so.
Tja, und VB-Programme sind wohl überhaupt etwas schwierig zu portiern...
Denke auch das es wohl hauptsächlich daran liegt. Andererseits zeigt
sich auch oft, dass Anwendungen, die erst spät auf andere
Betriebssysteme portiert werden, enorm viele Fehler aufweisen, da es
anscheinend eben doch nicht so einfach ist das alles zu portieren.
Ja, zum Beispiel Kylix, also Delphi wurde mittels winelib auf Linux
portiert, hatte nicht nur viele Fehler, sondern war auf wenige
Distributionen beschränkt, lief unter SuSE 7.0 noch am besten, genauso
wie die damit erstellten Applikationen.
Ich muss leider selbst immer wieder Programme für Windows schreiben,
genauso wie für Linux und Portablität bzw. eine einheitliche
Entwicklungsumgebung wird mir immer wichtiger, deshalb der Schritt zu C.
Wir werden schon ganz schön Offtopic,
aber vielleicht hilfts und Daniel fängt auch mit C an. ;-)
