Bascom ähnliche IDE für ARM?

Das hast du tatsächlich nicht expressis verbis gesagt. Das war nur eine Überspitzung meinerseits. So in etwa habe ich es aber verstanden.

Du hast aber VB als Beispiel herangezogen. Davon, dass Kommentare grün und Schlüsselwörter andersfarbig sind, wird Bascom erstens noch nicht zu VB. Und zweitens einen PC mit grafischem OS einem blanken ARM gegenüberzustellen, das führt zu nichts.

Selbstverständlich kann man bei höherer Rechenleistung "bequemer" programmieren und ein wenig verschwenderisch sein. Die Leistung eínes ARM sollte man aber nicht mit einer eher schwachen Sprache mit Absicht verballern. Es macht keinen Sinn, die Komplexität des ARMs mit fertigen Funktionen zu überdecken, die irgendwann unflexibel werden.

Und zu der dummen Aussage: so dumm ist die gar nicht, da kann ich dir sogar mehrere Beispiele bringen.

Erstens: unter VB gibt es keine vorzeichenlosen Datentypen. Gerade im Zusammenhang mit der µC-Programmierung ist es mir mehrfach störend aufgefallen, das 255 aus dem AVR nicht auch 255 im Typ Byte in VB sein können. Vorzeichenlose 32-Bit-Ints gibt es nicht, nur zur Repräsentation müsste man Currency oder Float wählen. Auf beiden können keine Bitmanipulationen angewandt werden. Dazu habe ich mir dann in Delphi eine DLL gebaut, etwas unorthodox.

Zweitens ein etwas eindrücklicheres Beispiel: Ich habe parallel zum Studium und davor für eine Firma ein paar finanzwirtschaftliche Programme mitentwickelt. VB haben wir vor allem in Form von Add-Ins für Excel und Access verwendet, und um Codebeispiele für Kunden zu erstellen, um das Wesentliche kurz darzustellen. Ein Produkt unter anderem war ein Währungsrechner, der multiplattformfähig (Großrechner in allen Variationen, Sprachen von Cobol bis C, alle Kombinationen von PCs + OS) sein und bis in den Billiardenbereich rechnen können musste, ohne an Genauigkeit zu verlieren. Mit VB war das nicht möglich, die Datentypen waren zu klein/inpäzise. Der Arithmetik-Kern war daher in C geschrieben worden.

Mit Delphi wäre das auch möglich gewesen, allerdings wären dann die Großrechner-Leute unzufrieden gewesen :)

Jan

Jan:
Ich weiß nicht was du hier bewirken willst, wenn du mit c so große töne spuckst. Hast du schonmal Projekte mit Bascom umgesetzt? Es macht wenig sinn von etwas zu reden, was man mal so mitbekommen, bzw. gesehen hat. Wußtest du das es Beispiele gibt wo Bascom einen effektiveren Source erzeugt als c?

Ich rede nicht davon, das Bascom größere Binaries ausspuckt, habe ich nie gesagt. Ich meine nur, dass die "Vereinfachung" Sachen auch schwerer machen kann, weil sie zu Ungunsten der Transparenz geht. Ich habe sehr wohl mit Bascom gearbeitet, habe es aber wieder sein lassen und bin auf AVR-GCC umgestiegen. Allerdings habe ich Anfang 2002 das letzte Mal mit Bascom herumgespielt. Kann sein, dass es heute mehr und bessere Funktionen gibt.

Mich hat es jedenfalls angekotzt, dass viele Funktionen auf Polling basierten, dass Timerhardware von Bascom blöd verwendet wurde, so dass man mit eigener Software nicht mehr recht damit arbeiten konnte. Dann hieß es selbermachen. Und das ist in Bascom genauso viel Aufwand wie in C.

Kann sein, dass sich heute alles geändert hat. Vielleicht wäre ich heute begeisterter Basic-Programmierer, wenn ich mich von der ersten Frustration wieder aufgerafft hätte.

Ich wiederhole nochmal, was ich oben gesagt habe: Ich will hier keinen mit Zwang bekehren, vielleicht gibt es aber Lösungen, die mit einer anderen Sprache besser gelöst werden können. Nur das wollte ich anmerken.

Zitat:

---

Zitat von Frank

Also wenn man C programmiert muss man auch Assembler perfekt können! Dies hast du mit deinen Argumenten gesagt.

---

Wie du darauf kommst, verstehe ich nicht. Ich habe nur gesagt, dass es möglich ist, das Kompilat genau zu verstehen, weil es im Detail offengelegt wird. Ich war mir nicht sicher, ob das in Bascom geht oder nicht.

Zitat:

---

Zitat von Frank

[Thema pulsein]

Falsch! Selbstverständlich hat man in Bascom auch beide Möglichkeiten! Gewöhnlich nimmt man jedoch den kürzesten Weg.

---

Also kann man dem Compiler sagen, diese Funktion irgendwie Interruptbasiert umzusetzen? Das man mit Bascom alles selber zu Fuß implementieren kann, ist mir wohl bewusst.

Leute, ich lasse es jetzt wirklich. Ich wollte eure Gefühle in Bezug auf Bascom nicht verletzen. Wenn man wirklich die Wahl zwischen IRQ- vs. Polling-basiertem Ablauf frei treffen kann, bin ich positiv überrascht. Das hätte ich gerne genauer beschrieben von euch. Ich bilde mir ein, dass es zu meiner Bascom-Zeit noch anders war. Aber das kann ich mit Sicherheit nicht sagen.

Zitat:

---

Doch, nur es gibt nahezu keine Anwendung die mit reinem ANSI-C programmiert wird. Was nützt einem die Kompatiblität auf dem Papier?

---

Besser 60%ige Kompatibilität (wahrscheinlich meistens mehr) als ein proprietärer Dialekt, den man mit sonst nichts übersetzen kann.

Gruß,

Jan

Jetzt ist es auch so weit, das ich einen kleinen Krieg sehe :(

Haben wir das nötig?

Wie wäre es denn, wenn alle ihr Wissen teilen und man einen Beitrag schreibt, in dem alles nötige steht?
Bezugsquellen, z.Zt. verfügbare Compiler, sonstige benötigte Hardware und evtl sogar eine Auflistung der Funktionen und Möglichkeiten...

Was streitet ihr rum? Es ist doch klar: C ist eine wunderbare Sprache, sie erinnert mich immer an ein spiegelverkehrtes Kreuzworträtsel. Aber ein C-Buch macht sich im Bücherregal wirklich gut. Braucht man ja auch wenn man mal Besuch bekommt. Nur programmieren muss man natürlich mt Bascom Basic, man darfs nur nicht verraten.

Zitat:

---

Zitat von Frank

Was gibts denn nun für gute Entwicklungsumgebungen, vielleicht listen ein paar ARM Experten die Möglichketen auf damit der Thread wieder einen Sinn hat ;-)

---

Wie bereits im "ARM Einstieg" Thread aufgeführt:

WinARM (Programmers Notepad mit arm-elf-gcc)
Rowley Crossworks (Komplette IDE mit funktionierenden JTAG Debugmöglichkeiten).
Keil µcVision

Grüße :)

Mehr gibts nicht?

Zitat:

---

Zitat von Anonymous

Mehr gibts nicht?

---

Das sind die, die mir so ohne Grübeln einfallen.
Auf der kommerziellen Ebene gibt´s bestimmt noch mehr.

Moin


Zu "Bascom-ARM"

Ja,würde ich begrüßen aber ich glaube da wird noch lange nix draus denn wenn man sieht wie Mcselec sich mit den beiden anderen abstrampelt dann kann ich mir kaum vorstellen das die sich an nen 32-bitter heran wagen.
Aber vieleicht aus ner anderen Richtung.
Die Teile sind ja im Kommen und da hat sich bis jetzt ja immernoch jemand gefunden der es macht.


Zur Allgemeinen Diskussion um die beste Sprache:

Mir ist es latte ob einer in Basic,C,C++,D8.25,Assembler,TB,Pascal,Cobol,Lisp oder Löffelsprache Proggt also erwarte ich auch das es den anderen egal ist womit ich arbeite.

Wichtig ist nur das Ergebnis.
Läuft es so wie man es will dann ist die Welt in Ordnung.

So. Diese ewige Diskussion ist echt krass. Die gibts echt in jedem Forum... Dabei fällt mir immer wieder auf, dass viele C-überzeugte Menschen gerne dazu neigen ein bisschen überheblich zu klingen, und sich auch nicht von Iihrer Meinung abbringen zu lassen... Ich wollte hier mal folgendes anmerken:

Ich habe nie C gelernt weil der syntax für mich (also FÜR MICH) einfach unübersichtlich ist. Daher habe ich meine Programme immer in TP und wenn es sein musste in ASM (innerhalb TP) geschrieben.. Als ich mit AVR angefangen habe war das einfach -ohne jetzt jemand von meiner Meinung überzeugen zu wollen- die einfachst zu erlernende und die einfachst zu bedienende Entwicklungsumgebung, und wenn ich sehe, dass bei ausgetauschtem C-Code immer 30 (Übertreibung) Dateien dabei sind, finde ich doch eine .bas Datei einfach angenehmer..
Was die effizienz des Codes angeht: Mein erstes Project knüpfte an ein bestehendes I2C-System an, und konnte mit 16Mhz gerade so mithalten (ein V850 prügelt die Daten schon recht fix raus). Jetzt ist der Code hier und da verbessert wurden (ohne ASM schnipsel) und er läuft ohne Mühe bei 8Mhz intern. Man sollte sich also nie hinstellen und sagen das es am Compiler liegt. Oft wird einfach schmutzig programmiert, und das nicht nur in basic