Hallo, meine Elektronikprojekte waren bisher rein analog und arbeite mich gerade mit Mikrocontrollern ein. Zur Programmierung suche ich einen Basic-Dialekt, da hier bereits vom PC Erfahrungen vorliegen. Gefunden habe dazu: - mikroBasic von Mikrolektronika: http://www.mikroe.com - Bascom von Mcselec: http://www.mcselec.com - Luna (freies Projekt): http://avr.myluna.de Welche Erfahrungen habt ihr persönlich zu den genannten Varianten und welche Empfehlung würdet ihr aussprechen, wenn es auch für anspruchsvollere Projekte genügen soll? Ob kostenpflichtig oder nicht spielt dabei eine untergeordnete Rolle. ich freue mich über Meinungen dazu, Andreas
Lass das mit Basic und geh direkt auf "C" , da wirst du auf Dauer sowieso landen.
Schwachsinn auf C zu gehen. Nimm mikroBasic von Mikrolektronika, Kann ich nur empfehlen. Ansonsten, lad dir die Demos runter und probiere aus, mit welcher du am besten zurecht kommst.
Hier wirst du keine andere Antwort bekommem, eher hier http://bascom-forum.de Du kannst mit C Mist programmieren und kannst mit Basic sauberen Code schreiben. Aber genauso kannst du Katholiken, Protestanten, Muslime, .... nach der wahren Religion fragen ....
Hallo, mich interessieren tatsächlich nur persönliche Erfahrungen bezüglich der genannten Varianten. Gruß, Andreas
Nachdem ich mit BASCOM abgekotzt hatte, habe ich C gelernt. Das hab ich nie bereut! Ich kenn niemand, der mit C abgekotzt hat und dann Basic gelernt hat. Ich schreibe das hier natürlich, um Widerspruch zu provozieren und damit solche Fragen hier niemals aufhören mögen.
Nachtrag: ich möchte die Fragestellung mal konkretisieren: - Welche Möglichkeiten habe ich zur Formulierung von Ausdrücken, oder gibt es Einschränkungen? - Welche Modularisierungsmöglichkeiten gibt es? - Welche Möglichkeiten habe ich zur Bitmanipulation und Direktzugriff auf die Hardware? Wie sieht das am Beispiel in eurer Lieblingssprache aus? Gruß, Andreas
Andreas Schath schrieb: > - Welche Möglichkeiten habe ich .... Lieber Andreas, diese Fragen werden selbst in schlechten Tutorials einigermassen beantwortet. Du müsstest halt mal danach suchen und das dann auch lesen. Wenn du das nicht schaffst, dann wirst du mit keiner Sprache weiterkommen, denn suchen und lesen wirst du immer müssen.
Tutor schrieb: > Andreas Schath schrieb: >> - Welche Möglichkeiten habe ich .... > > Lieber Andreas, > > diese Fragen werden selbst in schlechten Tutorials einigermassen > beantwortet. Du müsstest halt mal danach suchen und das dann auch lesen. > Wenn du das nicht schaffst, dann wirst du mit keiner Sprache > weiterkommen, denn suchen und lesen wirst du immer müssen. Hallo Tutor, ja, die Dokumentationen sind für alle Genannten umfangreich vorhanden Die kann ich auch alle drei von a bis z an gemütlichen Abenden durchackern. Sie ersetzen aber keine persönlichen Erfahrungen der Anwender zu ihrer jeweiligen Lieblingsvariante. Darüber hoffe ich mehr zu erfahren um dann bspw. auch an Denjenigen eine Frage stellen zu können. Gruß, Andreas
Was hindert dich daran, die Demos runter zu laden und es selber aus zu probieren ? Die beste Erfahrung ist immer noch die Eigene.
Ich mache gerade die 'kleineren Sachen' gern in Bascom da man schnell zum Ergebniss kommt. Vieles was man sich in C erst zusammensuchen oder bauen muss ist in Bascom recht einfach mit vorhandenen Befehlen möglich (ZB. LCD Display in Text und Grafik, IR-Senden/empfangen) auch der Zugriff auf die Hardware ist recht einfach, entweder mit den Befehlen oder direkter Registermanipulation und nicht zuletzt hilfreich, Bitvariablen die auch einzelnen Ein/Ausgängen zugeordnet werden können. Schwachpunkte sind die dort umständliche Mathematik da keine Kettenoperationen gehen und in Abfragen auch keine Rechnungen (wie zb ist X< y-2 dann ) gemacht werden können. Der etwas grössere Code der im Vergleich zu C ererzeugt wird ist meist zu verschmerzen. Bei geschickter Programmierung ist der in der Regel auch nicht langsamer als das gleiche in C. Für zeitkritische Anwendungen, oder schnelle Regelungen ist Bascom aber nichts, aber dafür muss man auch in C schon recht fit sein. Zum Lernen der Grundlagen und für gelegentliche 'Hobbyprogrammiererei' ist es aber recht gut geeignet, zumal man das erlente Grundlagennwissen über Programmierung dann auch beim Umstieg auf C nutzen kann. Wenn Du aber vorhast mehr als die 8Bitter zu nutzen und auch auf ARM und komplexere Programme aus bist dann nimm lieber gleich C.
Stefan schrieb: > Was hindert dich daran, die Demos runter > zu laden und es selber aus zu probieren ? > Die beste Erfahrung ist immer noch die Eigene. es hat mich nichts gehindert Stefan. Ich habe tatsächlich alle drei Pakete heruntergeladen. Alle drei bieten eine IDE und rein optisch/funktionell stechen mikroBasic und Luna hervor. Dies ist doch aber nur ein subjektiver Eindruck. Ich habe ja nun keine Projekthistorie mit den genannten Sprachen. Persönliche Einschätzungen finde ich sehr interessant und helfen mir schlussendlich abzuwägen. Gruß, Andreas
Alleine das hier schreckt mich vom Basic ab:
> BASCOMAVR BASCOM-AVR BASIC Compiler für Atmel AVR Controller 79,00 €
Und c hat den Vorteil, das es für fast jeden Controller und jedes System
C Compiler gibt.
Also muss man nur eine Sprache erlernen :-)
Dann würde ich mal ein kleines Programm auf alle drei Programmieren und schauen womit man am beste zurecht kommt. Ich benutze selber MikroBasic für PICs. Komme damit sehr gut zurecht. Und wenn es wirklich mal zeitkritsch wird, dann kann man immer noch auf Assemnler ausweichen und es dort einbinden.
Hallo Steffen, vielen Dank für deine Einschätzung! Es beschränkt sich tatsächlich nur auf die 8-Bitter. Bezüglich Programmierung bringe ich Erfahrungen mit, insofern ist "besonders einfach" mit einem geringeren Stellenwert verbunden. Meine Projekte zielen nach der Lernphase auf mehr ab als nur ein paar Leds blinken zu lassen. Du schreibst > keine Kettenoperationen gehen und in Abfragen auch keine Rechnungen > (wie zb ist X< y-2 dann ) gemacht werden können. wie genau stellt sich das dar? ist das eine generelle Einschränkung oder bezieht sich das nur auf Kalkulationen? Gruß, Andreas
Schau mal bei allen 3 von Dir genannten Compiler Anbieter in die Foren. Dann weisst Du wo Du im Ernstfall Unterstützung findest. mikroBasic: Hier werden hauptsächlich PIC's unterstützt, Atmel Prozessoren führen offensichtlic ein Schattendasein. Umständliche Programmierung im Gegensatz zu BASCOM. BASCOM Breite Unterstützung in diversen deutschen und englischen Foren. Meiner Meinung nach der beste Basic-Compiler. LunaAvr Unterstützung nur im Forum des Entwicklers. Aber ein sehr interessanter Compiler der sehr viele Vorteile gegenüber BASCOM oder mikroBasic bietet. Befindet aber noch in der (recht stabilen) Entwicklungsphase und bietet noch nicht so viele Libraries wie BASCOM oder mikroBasic. Ich selber könnte zwar in C programmieren, tue mir das aber für meine Hobbyzwecke nicht an. Mein Favorit war bisher BASCOM, aber neuere Projekte realisiere ich bevorzugt mit LunaAvr. Frontends auf dem PC schreibe ich in Delphi (Pascal). Bevor Du Dich für Dein Hobby zu C überreden lässt schau Dir mal zuerst diesen Link an: http://www.henning-thielemann.de/CHater.html
Ich bin Anfänger und wollte nur meine kleinen Projekte auf AVR zum Laufen kriegen. Habe mir die Demo von mcs runtergeladen und angefangen. Ging sehr leicht und nach 2 Stunden war das erste kleine Programm geflashed. Direkter Zugriff auf HW - kein Problem, sogar mit den Registernamen aus dem Datenblatt. Zeitkritische Programmteile, wie manche ISR sind sehr sehr leicht als Assembleranweisungen in der BASIC Source unterzubringen. IDE finde ich sehr leicht handhabbar. Code schreiben, kompilieren, flashen, Fuseeinstellungen sehr einfach, brauchbarer Simulator - alles mit ein paar Buttondrücken erledigt. Demo ist auf 4kByte kompilierten Maschinencode begrenzt. Mehr kostet dann Geld. Info auf der MCS Seite. Zum Ausprobieren auf jeden Fall empfehlenswert.
amateur schrieb: > @Albert > > Also ist Modula wirklich die beste Programmierumgebung für AVR's - wau! @amateur: Es gibt keine "beste Programmierumgebung". Wer sollte das festlegen?
vielen Dank für eure Meinungen, sehr interressant. mikroBasic scheint tatsächlich vorwiegend für pic verwendet zu werden. insofern neigt sich die Tendenz Richtung Bascom und Luna. Albert: Deine Ausführungen sind schon sehr detailliert, danke dafür. Einer meiner Anforderungen ist beispielsweise die Verarbeitung von Daten die von einem externen Peripheriegerät kommen. Dies zumeist seriell angebunden. Nehmen wir an hierbei sind Datenpakete zu verarbeiten, welche unterschiedliche Datentypenkombinationen beinhalten (binär), z.bsp. zwei Integer32, ein Fließkommawert und ein String in Paketen zu je 32 Byte. Wie sähe hier der Zugriff auf ein empfangenes Paket in Bascom und Luna aus? Luna ist wie es aussieht noch ein junges Projekt mit kleinerer Community. Dennoch bin ich hier tatsächlich aufgeschlossen und schaue mehr auf das Sprachpotential. Bezogen auf mein Anforderungen ist das für mich also kein Ausschlusskriterium. Gruß, Andreas
Warum wurde Linux, Windows, ... nicht in BASIC entwickelt? Je tiefer man in die Materie einsteigt, desto eher nimmt man C oder ASM. Zum Einstieg mag Basic putzig sein, aber wenn es ernst wird?
C_was_sonst_? schrieb: > Warum wurde Linux, Windows, ... nicht in BASIC entwickelt? Damit Linux nur von Liebhabern verwendet wird und Windows immer noch am Sicherheitslücken stopfen ist. C_was_sonst_? schrieb: > Zum Einstieg mag Basic putzig sein, aber wenn es ernst wird? OK. Muß aber schon sehr ernst werden und da wäre mir sowas wie Modula schon lieber, wenn es das für AVR geben würde. Werde demnächst mal das Pascal ausprobieren.
Andreas Schath schrieb: > Dies zumeist seriell > angebunden. Nehmen wir an hierbei sind Datenpakete zu verarbeiten, > welche unterschiedliche Datentypenkombinationen beinhalten (binär), > z.bsp. zwei Integer32, ein Fließkommawert und ein String in Paketen zu > je 32 Byte. Wie sähe hier der Zugriff auf ein empfangenes Paket in > Bascom und Luna aus? BASCOM: Egal ob parallel oder seriell. Es läuft kein Bertriebssystem und man verarbeitet die Daten in der Regel byteweise. zB von der seriellen Schnittstelle byteweise abholen, verarbeiten und den entsprechenden Variablen (float, string, etc) zuweisen. Ist Sache des Programmierers. Doku kann auch als separat ohne Programm von MCS runtergeladen werden.
Andreas Schath schrieb: > mich interessieren tatsächlich nur persönliche Erfahrungen bezüglich der > genannten Varianten. Ich bin von C auf Bascom umgestiegen, weil viele vorgefertigte Routinen nur ein einfaches "config xx" brauchen. Z.B. beim LCD ists ganz einfach! Mit 4 Zeilen Code kannste schon nen Text ausgeben...
MikroBasic für AVR gibt es erst seit ein paar Monaten. Aber wird immer beliebter. Da wird die Zukunft zeigen wie gut es wird.
Stefan schrieb: > MikroBasic für AVR gibt es erst seit ein paar Monaten. > Aber wird immer beliebter. > Da wird die Zukunft zeigen wie gut es wird. Nein, mikroBasic gibt es seit vielen Jahren. Du meinst wohl LunaAvr.
Wenn Basic, würde ich Bascom nehmen. Das wird seit Jahren permanent unterstützt und weiterentwickelt und es gibt eine riesige Anwendergemeinde und einen guten Support.
Andy schrieb: > es gibt eine riesige Anwendergemeinde und einen guten Support. Zum Glück nicht hier im Forum.
Andreas Schath schrieb: > Einer meiner Anforderungen ist beispielsweise die Verarbeitung von Daten > die von einem externen Peripheriegerät kommen. Dies zumeist seriell > angebunden. Nehmen wir an hierbei sind Datenpakete zu verarbeiten, > welche unterschiedliche Datentypenkombinationen beinhalten (binär), > z.bsp. zwei Integer32, ein Fließkommawert und ein String in Paketen zu > je 32 Byte. Wie sähe hier der Zugriff auf ein empfangenes Paket in > Bascom und Luna aus? mit Luna kenn ich mich nicht aus, aber in Bascom hab ich derlei schon programmiert, geht sogar recht einfach. Zum Einen empfängt die UART generell nur Bytes, die schreibt man einfach nacheinander in ein Array rein, das man vorher Dimmensioniert. Dim Empfangsarray (20) as Byte dim Empfangspointer as byte In der UART-Interruptroutine schreibt man die Daten in das Array incr Empfangspointer Empfangsarray(Empfangspointer) = UDR Jetzt kommt der Clue an der Geschichte, die Overlayvariablen. Die Dimemnsioniert man direkt nach dem Ringpuffer z.B. dim byte_absender as byte at Empfangsarray+1 dim byte_empfaenger as byte at Empfangsarray+2 dim byte_kommando as byte at Empfangsarray+3 dim int_uebergabewerte(2) as inetger at Empfangsarray+4 ' 2 Integervariablen dim word_uebergabewerte(2) as word at Empfangsarray+8 dim byte_crc8 as byte at Empfangsarray+12 auf diese Art hat man 2 Variablen, die auf den gleichen RAM-Bereich verweisen. Die serielle Schnittstelle empfängt irgendwas, schreibt das in den Puffer und wenn der Empfang abgeschlossen ist kann ich einfach auf die jeweiligen Werte direkt zugreifen und die weiter verarbeiten ... mach ich so bei Modbus-RTU. Ist eine der größten Stärken von Bascom aus meiner Sicht.
Hallo Andreas, hier ein recht gut zusammenfassender Erfahrungsbericht zu Luna: http://www.avr-praxis.de/forum/showthread.php?2685-Erfahrungen-zu-LunaAVR mikroBasic habe ich selbst auf Arbeit testen dürfen. Qualitativ als gut zu bewerten, jedoch waren wir schlussendlich weniger Überzeugt. Die Vorteile eines Basic-Dialekts liegen für viele Programmierer in der guten Lesbarkeit und Übersichtlichkeit, hier ist die Verwaltungsstruktur der Projekte und der Aufbau etwas kryptisch aus unserer Sicht. Das macht keinen Unterschied zu C. Dennoch professioneller als Bascom. Was dein Anwendungsbeispiel betrifft: in Bascom lädtst du solche Daten vorzugsweise in ein Array und musst dann mit Overlay-Zuweisungen arbeiten. Die Werte müssen dann z.T. in extra angelegte Zielvariablen transferiert werden. Es funktioniert, ist aber unübersichtlich. In Luna kannst du hier aufgrund des Objektmodells entweder einen Speicherblock allozieren und dann mit entsprechenden Funktionen direkt auf die Datentypen zugreifen, oder du deklarierst eine Struktur. In beiden Fällen kannst du die Daten direkt weiterverarbeiten. Mo
verstehe, wenn ich also Daten in Bascom strukturiert anfassen möchte, arbeite ich mit overlay-definition. in Luna wäre das dann z.bsp. ein Memoryblock wenn ich das richtig erfasse, also durch die vom Memoryblock generell vorhandenen Zusatzfunktionen wie xy.bytevalue()? Weiter oben wurde erwähnt, dass man in Bascom nicht direkt in einer if-abfrage rechnen kann. trifft das hier auf Luna auch zu? Gruß, Andreas
Fhutdhb Ufzjjuz schrieb: > dim byte_absender as byte at Empfangsarray+1 > dim byte_empfaenger as byte at Empfangsarray+2 > dim byte_kommando as byte at Empfangsarray+3 > dim int_uebergabewerte(2) as inetger at Empfangsarray+4 > dim word_uebergabewerte(2) as word at Empfangsarray+8 > dim byte_crc8 as byte at Empfangsarray+12 Und das soll schön sein? In C sieht das so aus:
1 | struct paket { |
2 | uint8_t absender; |
3 | uint8_t empfaenger; |
4 | uint8_t kommando; |
5 | int16_t uebergabewerte[2]; |
6 | uint16_t uebergabewerte_u[2]; |
7 | uint8_t crc8; |
8 | };
|
Ganz ohne von Hand zählen zu müssen, an welcher Stelle die Variablen stehen.
Andreas: ja, wie gesagt aber auch Strukturen möglich. Ich finde das auch nicht besonders elegant gelöst in bascom. Anhand von Fabians Beispiel in C sähe das in Luna so aus:
1 | struct paket |
2 | byte absender |
3 | byte empfaenger |
4 | byte kommando |
5 | integer uebergabewerte(2) |
6 | word uebergabewerte_u(2) |
7 | word crc8 |
8 | endstruct |
lässt sich dann auch als Array dimensionieren wenn du mehrere Pakete parallel verarbeitest:
1 | dim pkt(3) as paket |
2 | |
3 | select case pkt(0).empfaenger |
4 | case 0 |
5 | select case pkt(0).kommando |
6 | case CMD_1 |
7 | ... |
8 | endselect |
9 | case 1 |
10 | ... |
11 | default |
12 | 'unbekannter absender |
13 | endselect |
Mo
Vielen Dank für die Beispiele und eure Meinungen. Die gezeigte Variante mit Luna erscheint mir tatsächlich eleganter und wirkt professioneller. Zudem zielt es recht treffend auf meine Anwendung hin. Gruß, Andreas
Ich habe mich jetzt parallel eingehend mit Bascom beschäftigt. Meine Einschätzung dazu ist: Mein Testprogramm lief einwandfrei, die Konfiguration ist für mein Empfinden jedoch etwas unübersichtlich gelöst. Sie resultieren zum Teil in langen Config-Ketten. Die Strukturierung mittels Overlay funktioniert zuverlässig, ist aber auch hier nicht ganz so elegant. Unterprogramme und Variablennamen müssen von Anfang an gut überlegt vergeben werden, damit es nicht zu Kollisionen kommt. Weiterhin ist die Speicheraufteilung mittels framesize und stacksize undurchsichtig. Hier vermisse ich eine grafische Übersicht wie im Reportfenster bei Luna. Eine Modularisierung ist syntaktisch nicht möglich (geschlossene bereiche für Namensvergabe). Wenn ich Fallabfragen vornehme, muss ich z.T. neue Variablen erzeugen um die Rechnung durchzuführen und auch hier war mir neu, dass man nur zwei Parameter verwenden kann. Dies ist wohl die Einschränkung die Steffen erwähnte. Einrückungen im Editor muss man selbst vornehmen und eine optische Strukturierung vermisse ich auch hier. Mein Fazit zu Bascom ist: Ein guter Compiler, aber doch sehr einfach gehalten. Ich kann hier für mich konstatieren, dass Bascom hier meine Erwartungen nicht erfüllt. Gruß, Andreas
der neue Explorer in der 20746 hat schon nochmal einiges gebracht an Übersichtlichkeit. Was noch zu erwähnen wäre, ich hab die Vollversion vor Jahren gekauft, bisher waren alle Updates kostenlos, was den Preis schon erheblich relativiert. Stack und Frame iust ein Graus, das stimmt
@Andreas Sehr schön dass Du die Kanten von Bascom durch eigene Versuche erkannt hast. Es es schon wichtig, unbenommen von den Meinungen Anderer, sich ein eigenes Urteil zu bilden. Du hast es auf den Punkt gebracht. Bascom ist ein solider Compiler, hat aber so seine Unzulänglichkeiten. Das ist auch der Grund warum ich immer mehr zu LunaAVR überschwenke. Da ich aus der Delphi(Pascal) Ecke komme und das Luna Sprachkontrukt hier grosse Ähnlichkeiten aufweist, bis hin zur Objektorientierung, hatte ich keine Probleme mit der Einarbeitung. Inzwischen ist Luna sehr stabil und der Sprachumfang absolut ausreichend. Es könnten aber noch einige Libs mehr sein, das wird aber sicherlich ziemlich schnell kommen.
Eigentlich schade, das FastAVR http://www.fastavr.conm nicht weiterentwickelt wird. Scheint von Mikroelektronica übernommen worden zu sein und wird als MikroBasic(AVR) verkauft, wenn man sich mal die generierten Assemblerlistings ansieht, deutet für mich jedenfalls alles darauf hin. BTW: ich habe mit Fastavr eher viel Erfahrungen sammeln können(müssen), um abschliessend sagen zu können, das - wenn man die Kinderkrankheiten kennt - es super einfach ist, auch komplizierte(umfangreich triffts besser) Programme zu schreiben. Ich programmiere seit her parallel in C ( dank dem Forum hier ) und weiterhin in FastAVR für Sachen, die schnell gehen müssen. Von daher würde ich jetzt mal zu mikroelektronica tendieren. Aber nur der Vorgeschichte wegen. Gruß Fest Rutsch Axelr.
Andreas Schath schrieb: >> keine Kettenoperationen gehen und in Abfragen auch keine Rechnungen > >> (wie zb ist X< y-2 dann ) gemacht werden können. > > > > wie genau stellt sich das dar? ist das eine generelle Einschränkung oder > > bezieht sich das nur auf Kalkulationen? In If Then und ähnlichen Abfragen gehen schon mehrere mit zB. mit And verknüpfte Abfragen wie ' if x<y and x>z then ' nur leider keine mit Rechnungen. also zB ' if x < y+10 and x > y-10 then ' geht nicht, da muss man immer eine Variable für jeden Vergleich deklariert sein und die Rechnung dazu extra. Ich weis nicht ob das bei den anderen Basicvarianten auch so ist, kenne nur Bascom. Übrigens gibt es da eine kostenlose Version mit beschränkter Codegrösse, für kleinere Projekte meist ausreichend.
if x < y+10 and x > y-10 In MikroBasic ist sowas möglich. Muß nur in Klammer gesetzt werden. Wie gesagt schau ihn dir an und wenn Fragen sind, frag ruhig.
@Steffen: ich konnte es mittlerweile nachvollziehen was du damit meintest, danke dir @axelr: Hatte ich bei meiner Recherche ebenfalls vermutet und mich mit mikroBasic befasst, fand das Avr-Thema aber stiefmütterlich behandelt, wie ja bereits festgestellt wurde. @albert: Zu diesem Schluss komme ich unterm Strich am Ende auch. Auch ich arbeite u.A. auf dem PC mit Delphi. Der ähnliche syntaktische Aufbau bei Luna zu modernen objektorientierten Dialekten ist hier sehr hilfreich, das kann ich bestätigen. Dennoch habe ich mich dadurch nicht beeinflussen lassen und auch Bascom getestet. Bei Luna viel mir die Umsetzung meines Testcodes entsprechend leichter. Was man hierbei feststellen muss ist, das die mächtigeren Sprachfähigkeiten von Luna jedoch schneller zu einer programmierweise verleiten, die den erzeugten Code aufblähen können. Hier ist eine intelligentere Auseinandersetzung des Programmierers mit dem notwendigen Programmfluss und die Nutzung der in Luna verfügbaren Objektmethoden notwendig. Es stellt also höhere Ansprüche an den Programmierer. Ich kann mir vorstellen, dass langjährige Bascom-Programmierer es schwer haben ihr eingeübtes Schema der Aufteilung auf Einzelprozesse aufzugeben und effizientere kompakte Formulierungen in Luna zu verwenden. Luna entspricht hier meinen Erwartungen fast vollständig, insofern komme ich hier zum gleichen Schluss wie du. Bascom bietet einen Simulator. Dies ist insofern verlockend, als das man seinen Code direkt testen kann. Luna besitzt keinen Simulator, was mich zuerst verwunderte. In der Realität stellt man bei Bascom dann jedoch fest, dass die Simulation tatsächlich nur eine Simulation ist. Ich konnte mehrere Fälle produzieren bei denen der Code im Simulator lief, aber im Controller abstürzte. Wenn soetwas vorkomen kann, ist diese Art der Fehlersuche obsolet, zudem lässt sich nur rudimentäre Peripheriehardware simulieren. Bei der Fehlersuche mit Luna stellt man fest, dass hier der Fokus auf der Ausgabe über das Terminal liegt. In Verbindung mit den vorhandenen Exceptions in Luna konnte ich damit auch Speicherverletzungen feststellen. Das direkte Suchen der Fehler auf dem Controller halte ich für unverzichtbar. Ein Simulator erscheint mir vor diesem Hintergrund tatsächlich für überflüssig. Ich konnte alle Fehler in angemessener Zeit ermitteln. Gruß, Andreas
Luna bleibt auch für große Projekte kostenlos. Mathematische Terme wie a=b*(c+d) werden in Luna genauso geschrieben. In Bascom (nur bis 4k-Byte kostenlos): a=c+d a=a*b und in C++ hat mich schon immer die Syntax gestört Joe
Joe schrieb: > und in C++ hat mich schon immer die Syntax gestört Die wäre in deinem Beispiel a=b*(c+d); Da steht halt noch ein Semikolon am Ende. Oliver
Oliver S. schrieb: > Joe schrieb: >> und in C++ hat mich schon immer die Syntax gestört > > Die wäre in deinem Beispiel > > a=b*(c+d); > > Da steht halt noch ein Semikolon am Ende. > > Oliver Der Rest ist dann aber doch völlig anders. Der TO hat doch mit seiner Fragestellung ausdrücklich C ausgeschlossen. Manche der Beiträge bezüglich C wirken durchaus missionarisch. C ist heutzutage nicht mehr das Nonplusultra. Die Welt ist bunt, hoffen wir dass irgendwann nicht alles gleichgeschaltet ist bei den Programmiersprachen. Schöne Feiertage wünsche ich :) Gruß, FurtiBurb
Fang doch einfach mit Lunar an! Da es kostenlos ist und ohne Einschränkungen zur Verfügung steht. Nach dem Du die ersten Versuche gemacht hast, wirst du sehen, ob es für deine Zwecke ausreichend ist oder nicht. Solange du "normale" Basic Algo´s verwendest, kannst du dir diese bei Bascom bzw. MicroBasic abschauen und in Lunar umsetzen. Und so lange du bei einem Basic Dialekt bleibst ist auch der Umstieg auf Bascom bzw. MikroBasic nicht so schwer. Diese bieten sicher die besseren vorgefertigten Funktionen. Ich denke nach dem ersten Projekt wirst du selbst sehen, ob Basic für dich das Richtige ist oder ob du den Schritt nach C wagst. Merke: Die beste Programmiersprache ist immer die, mit der man selbst am besten zurecht kommt!
ich habs probiert source von Luna nach mein Bascom zu übersetzen.. geht gar nicht! ich müsste zigfache funktionen nachbilden und dann kann man auch diese klassen nicht umbauen, da gibts immer doppelte namen Fehlermeldung!
Rainer schrieb: > ich habs probiert source von Luna nach mein Bascom zu übersetzen.. geht > gar nicht! ich müsste zigfache funktionen nachbilden und dann kann man > auch diese klassen nicht umbauen, da gibts immer doppelte namen > Fehlermeldung! wozu sollte man soetwas tun? ist mir unbegreiflich frohes Fest!
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.