Bascom ähnliche IDE für ARM?

[Jan_Weber]

Was ist denn dann Basic auf einem 3 GigaHertz Pentium nach deiner Definition? Ein plattes Einrad ? Komisch das heute doch ein Großteil aller PC-Anwendungen auch in VB geschrieben werden und kaum noch was in Assembler

Einen PC mit einem µController-System zu vergleichen, halte ich für etwas gewagt. Außerdem habe ich mich auch nicht für ASM eingesetzt, sondern für C. Beim PC hast du ein Betriebssystem dazwischen, du erreichst einen viel höheren Abstraktionsgrad zwischen Hardware und Software. VB ist eine Sprache, die deswegen so populär ist, weil sie vereinfachend ist. Vor .NET war die OOP nur begrenzt implementiert, Auch die Verkapselung von Windows-API-Funktionen in VB-eigenen Funktionen dient der Arbeits-/Verständniserleichterung. Und da sind wir uns sicher einig - VB würdest du nicht zur hardwarenahen Programmierung verwenden, weil es einfach nicht geht. Darum hinkt der Vergleich an dieser Stelle. Außerdem wird der Großteil der PC-Anwendungen nicht in VB, sondern in C/C++/C# etc. erstellt. Auf der Linux-Ebene sowieso, und für Windows gilt das auch.

(Cntrollerprogramme sind ja alle recht klein)

ARMs wurden doch gerade für größere Anwendungen gewünscht?

Ein µC-System braucht nun wohl hardwarenahe Programmierung. Bascom bringt vieles mit und verdeckt damit teilweise Probleme, die später auftreten können. Ihr habt es sicher auch schon erlebt, dass sich die Einsteiger von dem Abstraktionsgrad in Bascom einlullen lassen, und im Endeffekt gar nicht so genau wissen, was ihr Programm da macht, Hauptsache, es läuft irgendwie. Das meine ich jetzt nicht böse. Sie glauben dann, mit so einer Sprache bewaffnet, müsste man das Datenblatt nicht lesen. Mit solchem Handwerkszeug dann aber auf den ARM umzusteigen, halte ich einfach für den falschen Weg.

Ich sage es nochmal ganz deutlich:

1. ich möchte nicht gegen Bascom oder seine User stänkern
2. Die Tatsache, ob man Sprache A oder B bevorzugt, sagt direkt nichts über Wissen und Können aus (obwohl BASIC ja Beginner's All-purpose Symbolic Instruction Code bedeutet )
3. ich wollte nur einbringen, dass mit einer weniger "vorgefertigten" Sprache mehr Möglichkeiten bestehen, erst recht, wenn sie so weit verbreitet ist wie C (kaum ein Algo, den du nicht schon fertig implementiert finden kannst)

Ich werde zu diesem Thema nichts weiter schreiben, weil das ja jetzt schon in einen Krieg der Programmiersprachen ausgeartet ist.

Gruß,

Jan

[Marco78]

Ich werde zu diesem Thema nichts weiter schreiben, weil das ja jetzt schon in einen Krieg der Programmiersprachen ausgeartet ist.

Als Krieg habe ich das noch lange nicht angesehen. Das du nichts weiter schreiben möchtest finde ich schade, weil ich noch ne Frage habe.

und im Endeffekt gar nicht so genau wissen, was ihr Programm da macht,

Ist das mit C anders? Es ist ja auch nur ein Compiler. So wie ich die C-Codes sehe, sehen sie für mich aus wie Basic-Codes. Abgesehen von der Sprache
Aber was im Controller später abläuft ist für mich auch noch nicht erkennbar.
PS: Mit dieser Frage will ich auch nicht stänkern! Ich möchte es wirklich wissen.

[Frank]

In C ist es sogar noch viel schlimmer! Es gibt nur sehr wenige Grundbefehle. Das meiste sind auch nur Libarys also einfach übersetzt "Codeblöcke". Die sind noch nicht mal standardisiert, jeder Hersteller packt andere Funktionen zusammen. Die wenigsten wissen etwas über deren Aufbau.

Das Basic "BASIC ja Beginner's All-purpose Symbolic Instruction Code" bedeutet ist bekannt. Dadurch hat sich die Sprache ja das Vorurteil erworben. Aber der Name wurde vor Urzeiten vergeben, da gabs noch kaum Programmiersprachen und da sah sowohl Basic als auch die Microcontrollerwelt noch ganz anders aus.

Es stimmt schon das C-Programmierer gewungen werden zumindest die Datenblätter genau zu lesen, da man ja jedes Bit im Register selbst setzen muss. In Basic kann man das auch, aber man hat auch die Möglichkeit High Level Befehle zu nutzen um dies zu umgehen. Das erleichtert den Einstieg, verbaut aber nicht die Möglichkeiten.

Ich will aber diese Sprachen - Diskussion auch nicht wieder aufleben lassen, aber ab und zu muss man das ein oder andere erwähnen wenn ein C-Experte wieder ins schwärmen kommt


PS. Übrigens wenn C doch so wunderbar ist, so frag ich mich warum seit Wochen es keiner hinbekommt dieses kleine C-Gegenbeispiel für Pulsein hier noch anzufügen: https://www.roboternetz.de/wissen/in...ourcevergleich
Liegt es vielleicht doch daran das es zu anstrengend ist erst wieder ein Projekt in C aufzusetzen ?

[Hanni]

nu das ist ne ziemlich merkwürdige Vorstellung die Du da äußerst, sorry wenn ich es so sage. Was ist denn dann Basic auf einem 3 GigaHertz Pentium nach deiner Definition? Ein plattes Einrad ? Komisch das heute doch ein Großteil aller PC-Anwendungen auch in VB geschrieben werden und kaum noch was in Assembler Und das je größer der Microcontroller wird um so mehr!

Mal abgesehen davon das ein Grossteil aller PC Anwendungen auch nen Code Overhead hat der absolut unnötig ist ...
Aber das ist nunmal der heutige Programmierstil .. Fast and Dirty ... und wenns nen Fehler gibt werden halt 10 Patches nachgeschoben

Im übrigen: Basic hin oder Basic her ... für Zeitkritische Dinge nimmt man nunmal was richtiges ... also Assembler.

[Jan_Weber]

Das du nichts weiter schreiben möchtest finde ich schade

Na, dann antworte ich nochmal

Ist das mit C anders? Es ist ja auch nur ein Compiler. So wie ich die C-Codes sehe, sehen sie für mich aus wie Basic-Codes. Abgesehen von der Sprache
Aber was im Controller später abläuft ist für mich auch noch nicht erkennbar.

Es ist schon richtig, dass es nicht sofort klar wird, wie ein Compiler diesen oder jeden Quelltext umsetzt. Das gilt selbstverständlich auch für C. In Bascom aber sind fertige Funktionen enthalten, über deren innere Abläufe man nix erfährt. Es werden bei AVR-GCC aber List-Files ausgegeben, in denen die C-Implementation und ihr ASM-Widerpart dargestellt sind, so dass man selber nachlesen kann, was wie gemacht wurde (vorausgesetzt, man beherrscht ASM). Außerdem gibt es vier verschiedene Optimierungsstufen, plus weitere Attribute, mit denen man die Codegenerierung zugunsten von Geschwindigkeit oder Speicherökonomie modifizieren kann. Wie es damit in Bascom steht, weiß ich nicht.

Bei einer eigenen Implementierung von einer pulsein-ähnlichen Funktion in C hätte man von vorneherein die Option, das Ganze interruptbasiert oder mit Polling aufzubauen. Bei Bascom hat man nur letztere Möglichkeit, oder man muss es selbermachen, und dann ist der Arbeitsaufwand in etwa gleich.

Ein weiteres Beispiel wären die polling-basierten Empfangsfunktionen für das U(S)ART von Bascom. Sie funktionieren zwar, sind auch erstmal einfach zu verwenden, bremsen aber unangenehm aus und sind fehleranfällig. Ich muss gestehen, dass ich nicht weiß, ob es auch interruptbasierte UART-Funktionen für den Empfang gibt, die im "Hintergrund" arbeiten. Das würde Bascom in meinen Augen ein wenig rehabilitieren.

Wenn man seine Treiber selber programmieren will, um Begrenzungen von Bascom-Funktionen aus dem Weg zu gehen, dann ist die Wahl zw. BASIC und C nur noch eine reine Geschmacksfrage, die man meiner Meinung nach aber zugunsten von C entscheiden sollte : es ist kostenlos und flexibler.

ARMs verwendet man, wenn andere Controller nicht mehr ebenbürtig sind. Das setzt meinem Verständnis nach voraus, dass man andere Controller bereits ausgereizt hat. Wenn man bereits so weit ist, das man mit Bascom jeden Hardwaretreiber selber schreiben/optimieren muss/kann, dann hat man die Vorzüge von diesem Compiler sowieso längst hinter sich gelassen. ARMs haben eine wesentlich größere Flexibilität, die hinter Bascom-Funktionen zu verkapseln, macht keinen Sinn. Entweder, sie sind einfach zu verwenden, und sie unterschlagen Optionen, oder sie können alles, sind aber wieder komplex.

Die sind noch nicht mal standardisiert, jeder Hersteller packt andere Funktionen zusammen.

Noch nie was von ANSI-C gehört?


Schönen Sonntag,

Jan

[Frank]

Der Overhead ist bei C bzw. CPP Programmen auf dem PC oft sogar größer. Es fällt nur nicht so auf da viele Libarys schon im Wndows-Verzeichnis sind und nicht mitinstalliert werden.
Auch beim keinen Controller hat sich gezeigt das Bascom bei der Codegröße durchaus mit C Schritt halten kann. Also das Argument ging ins Leere.

Der Overhead ist bislang besonders groß bei NET Anwendungen und da spielt es kaum eine Rolle ob das C, C# und Basic ist. Daher ist NET bislang auch nicht sonderlich erfolgreich. Ich mag´s auch nicht.

Das mit den Patches hat nun auch überhaupt nix mit Basic zu tun. Wie Jan_Weber es schon richtig sagt, bislang wird immer noch die mehrzahl der Programme in C oder CPP entwickelt (auch wenn es abnimmt). Und ich möchte mal behaupten das auch die Mehrzahl der bugbehafteten Programme eindeutig in C geschrieben werden.
Dennnoch würde ich das nicht der Sprache anhaften. Es liegt daran das die Entwicklungszeiten immer kürzer werden weil die Kunden auch drauf drängen. Und das wiederum verträgt sich auch nicht gut mit C da halt 5 bis 10 mal soviel Codezeilen gewartet werden müssen. In Assembler wäre das noch viel schlimmer.
In Assembler werden nur noch ganz wenige zeitkritische Dinge programmiert, daher kann man das ja sowohl in Basic als auch C einbinden.

Wir sollten die Vorurteile nun lassen udn uns eigentlich wieder dem Titelthema ARM widmen.

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


Nachtrag: Die war die Antwort auf einen Beitrag zuvor. Den widerlegten Beitrag hat der User offenbar nachträglich gelöscht.

[Rage_Empire]

Also für mich hat die Sparache einen Vorteil, welche am effektivsten erscheint. Ich halte es nicht utopisch einen Pentium mit einem µC zu vergleichen, da beide aud das selbe Prinzip basieren. Nebenbei gesagt ist der Pentium ohne Perepherie recht dumm im gegensatz zu einem µC. Ob jemand gut oder weniger gut programmieren kann oder Ahnung hat würde ich nicht von der Sprache abhängig machen. Dies wird leider aber oft so gehandhabt. Das wäre im Prinzip das gleiche, wie wenn ich alle Windows-User als Anfänger abstempeln würde, da Linux doch so toll ist.
Ich denke, es ist schlußendlich egal mit was man Programmiert, da die Sprache nur der Übersetzung dient. Wenn ich einen PID-Regler Programmieren will, muß ich wissen, wie der arbeitet und wie ich diesen umsetzte. Mit was für einer Sparche ich dies tue ist doch völlig wurscht. Das Endergebnis ist doch immer alles was zählt!

[Frank]

Es ist schon richtig, dass es nicht sofort klar wird, wie ein Compiler diesen oder jeden Quelltext umsetzt. Das gilt selbstverständlich auch für C. In Bascom aber sind fertige Funktionen enthalten, über deren innere Abläufe man nix erfährt. Es werden bei AVR-GCC aber List-Files ausgegeben, in denen die C-Implementation und ihr ASM-Widerpart dargestellt sind, so dass man selber nachlesen kann, was wie gemacht wurde (vorausgesetzt, man beherrscht ASM). Außerdem gibt es vier verschiedene Optimierungsstufen, plus weitere Attribute, mit denen man die Codegenerierung zugunsten von Geschwindigkeit oder Speicherökonomie modifizieren kann. Wie es damit in Bascom steht, weiß ich nicht.

Also wenn man C programmiert muss man auch Assembler perfekt können! Dies hast du mit deinen Argumenten gesagt. Ich denke allein da sspricht gegen C. Man entscheidet sich für eine Sprache um Vereinfachungen zu haben und nicht nachher noch in Assembler debuggen zu müssen.

Abgesehen davon gibt es sowas wie eine Listfunktion in Basom Basic auch. Auch die Codeoptimierung kennt Bascom.

Bei einer eigenen Implementierung von einer pulsein-ähnlichen Funktion in C hätte man von vorneherein die Option, das Ganze interruptbasiert oder mit Polling aufzubauen. Bei Bascom hat man nur letztere Möglichkeit, oder man muss es selbermachen, und dann ist der Arbeitsaufwand in etwa gleich.

Falsch! Selbstverständlich hat man in Bascom auch beide Möglichkeiten! Gewöhnlich nimmt man jedoch den kürzesten Weg.
Ich würde nun gerne mal ein gegenstück zu dem Source in C sehen. Komisch das die C Leute immer theoretisch drüber reden aber praktsich kein Beispiel hin bringen. Ich will damit nicht sagen da sdu es nicht könntest, aber das der Overhead so groß ist, das die C-Programmierer oft keine Lust haben (zu faul sind) sowas aufzusetzen. Oder haben sie nur Angst schlecht auszusehen wenn der Code 5 mal so lang und 10 mal zu kompliziert aussieht?

Ein weiteres Beispiel wären die polling-basierten Empfangsfunktionen für das U(S)ART von Bascom. Sie funktionieren zwar, sind auch erstmal einfach zu verwenden, bremsen aber unangenehm aus und sind fehleranfällig. Ich muss gestehen, dass ich nicht weiß, ob es auch interruptbasierte UART-Funktionen für den Empfang gibt, die im "Hintergrund" arbeiten. Das würde Bascom in meinen Augen ein wenig rehabilitieren.

Dann sage ich es dir hiermit. Es gibt diese UART interrupt Funktionen! Hier gibt es in Bascom gegenüber C keine Nachteile.

Wenn man seine Treiber selber programmieren will, um Begrenzungen von Bascom-Funktionen aus dem Weg zu gehen, dann ist die Wahl zw. BASIC und C nur noch eine reine Geschmacksfrage, die man meiner Meinung nach aber zugunsten von C entscheiden sollte : es ist kostenlos und flexibler.

Welche Begrenzungen???? Es gibt keine Nun wenn dem Programmierer, der offenbar Bascom Basic wenig kennt kein Argunment mehr einfällt, dann kommt nur noch der Preis-Hammer
Und da muss ich sagen das ich den Preis schon alleine wegen der Entwicklungsumgebung für ausgesprochen niedrig halte. Der enorme Zeitgewinn beim entwickeln einer Anwendung macht den innerhalb kürzester zeit wett. Schau dir mal die preise bei C-COmpilern mit so einer Entwicklungsumgebung an!!!

ARMs verwendet man, wenn andere Controller nicht mehr ebenbürtig sind. Das setzt meinem Verständnis nach voraus, dass man andere Controller bereits ausgereizt hat. Wenn man bereits so weit ist, das man mit Bascom jeden Hardwaretreiber selber schreiben/optimieren muss/kann, dann hat man die Vorzüge von diesem Compiler sowieso längst hinter sich gelassen. ARMs haben eine wesentlich größere Flexibilität, die hinter Bascom-Funktionen zu verkapseln, macht keinen Sinn. Entweder, sie sind einfach zu verwenden, und sie unterschlagen Optionen, oder sie können alles, sind aber wieder komplex.

32 Bit Controller nimmt man vorwiegend wenn viele Rechenoperationen und viel Speicher notwendig werden. Und da ein gute rBasic Compiler kaum schlechteren Code als C produziert laufen deien Argumente ins Leere. Wir haben doch gesagt das gerade Hochsprachen bei mehr Rechenleistung gewöhnlich auch immer mehr zum Zue kommen. Bei bestimmten Anwendungen kann dann sogar ein Betriebsystem sinnvoll sein. Hier bewegen wir uns aber im Kreis!

Noch nie was von ANSI-C gehört?

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

Ebenfalls schönen Sonntag
Gruß Frank

Der Overhead ist bei C bzw. CPP Programmen auf dem PC oft sogar größer. Es fällt nur nicht so auf da viele Libarys schon im Wndows-Verzeichnis sind und nicht mitinstalliert werden.
Auch beim keinen Controller hat sich gezeigt das Bascom bei der Codegröße durchaus mit C Schritt halten kann. Also das Argument ging ins Leere.

Das mit den Libraries und DLLs hängt vom jeweiligen Compiler-Hersteller ab. Bei Microsoft ist es auf jeden Fall richtig.

Ich habe nie mit der Codegröße argumentiert. Dass Bascom da gut ist, glaube ich euch, ich persönlich habe es nicht getestet. Ich kritisiere nur, dass du sagst "Weil VB auf dem PC gut ist, ist Bascom auf dem µC auch gut". Die Argumente meinerseits habe ich oben dargestellt, darum wiederhole ich sie nicht nochmal. Da fällt mir ein Zitat aus einem Artikel zum Vergleich der Sprachen/IDEs VB 6 und Delphi ein: "Mit VB gelingen die einfachen Sachen schnell, mit Delphi auch die fortgeschrittenen". Das Non-plus-ultra ist VB auch nicht. Das MSComm-Control möchte ich aber auch nicht missen

Jan

Jan

[Frank]

"Weil VB auf dem PC gut ist, ist Bascom auf dem µC auch gut" das wiederum hab ich nie geschrieben. Du musst auch meine Argumente schon richtig lesen. Ich konnte nur deiner Argumentation: "Je höher die Rechenleistung desto hardwarenäher müsse die Programmierung sein", nicht folgen.

Zum Zitat: Eine dumme Aussage bleibt auch dann dumm wenn man die als Zitat versucht zu veredeln! Gibts Delphi überhaupt noch?