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 Sprachebasic beine AVR Programme zu schrieben?
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?
Hallo, die neueste BASCOM-Version soll auch unter Linux (Wine) laufen. Stand glaube ich wohl in den ReleaseNotes. Dirk
>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. ;-)
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.