Bascom ähnliche IDE für ARM?

[Jan_Weber]

nicht mal eben abgekündigt werden wie eine C-Control

Ich habe mich eher gewundert, warum sich so eine Krücke so lange halten kann, dann auch noch zu dem Preis. Eine serielle Schnittstelle ohne Interrupt. Da kam mir das Grausen.

Zu deiner "Antwort" : Ich habe vergessen zu schreiben, dass sich die meisten Treiber aber im Internet finden lassen, kaum ein LCD, dass du nicht ansteuern kannst, dann die Procyon-Lib, die Sachen von P. Fleury, die App-Notes von Atmel mit C-Sourcen (sogar in den Datenblättern ist Quelltext drin).

Da ist es doch schwieriger, sich irgendwelche Krücken mit Bascom zu bauen (meine Meinung).

Jan

[Sanic]

Natürlich gibt´s vieles schon fertig, das ist ja das schöne.
Und wenn man einmal nen Treiber selbstgeschrieben hat dürfte man auch für die meisten anderen Bauteile (wo es vielleicht noch kein Tut für gibt) einen Treiber schreiben können.

Grüße

[Marco78]

Warum soll man 17 Hochsprachen können?
Ich habe vor über 15 Jahren mit Basic angefangen. Abgesehen von ein paar Ausflügen in ein paar andere Sprachen bin ich bis heute dabei geblieben. Allerdings ist es heute Bascom und VB.

Ich komme mit der Sprache klar. Ich würde es ja noch einsehen, wenn "ihr" "uns" ASM aufzwingen würdet. Damit kann man sowohl AVR's als auch ARM's programmieren. Und man hat wirklich den vollen Überblick, was die Hardware grade macht. Was bei C auch nicht der Fall ist.

In Bascom kann man Register auch direkt schreiben und auslesen. Wer es so schnell braucht, kann es tun, wer es nicht braucht, macht es so wie bisher.

Selbst wer mit C schreibt, wird nie wissen, ob sein AVR grade an der Grenze seiner Fähigkeit ist.
Ich habe eher das Gefühl, das man gerne glauben möchte, das Menschen, die mit Bascom programmieren keinen Plan von der Materie haben. Das ist nicht immer so bzw. das ist genau so oft der Fall wie C-ler es nicht wissen.

Wenn es keinen Basic-Compiler für ARM's geben wird und jemand ihn aber unbedingt einsetzen will/muss, wird er gezwungenermaßen auf eine andere Sprache umsteigen. Ich persönlich würde dann auf ASM 'umschulen'. Zum einen, weil ich früher damit schonmal was gemacht habe und zum anderen, weil ich nur da die wirkliche Kontrolle habe.
Wenn man schon was neues lernen muss und will, dann kann man es auch gleich richtig machen.

Versteht mich bitte nicht falsch, ich finde eure Hinweise und Argumente z.T. angebracht, aber pauschal zu sagen, das Basic nur was für Kinder ist, ist falsch.

Waum sollte auch jemand eine schwerere Sprache lernen, wenn er immer nur leichte Aufgaben lösen will und diese schnell erledigt haben möchte?

[Hellmut]

@Jan_Weber: Auch bei den ARM Core basierenden Controllern von Atmel, ich habe mir das Datenblatt des ARM7tdmi angesehen, hat man volle Kontrolle welche Register beim Bedienen eines Interrupts gesichert werden müssen. Braucht man es ganz besonders schnell gibts dort den FIQ. Nach einer Anweisung kann man bereits Kode in seiner Interrupt-service-Routine ausführen lassen und dort entscheiden welche Register zu sichern sind! Wenn man die 75MHz mit den max. 20MHz die man bei den megaxx von Atmel erreicht vergleicht steht zweifelsfrei fest das ein ARM KCore basierender uC wesentlich höhere Geschwindigkeit bietet!

Ich sehe zum Beispiel 2 Beispiele die hier im Forum genannt wurden wo ein ARM Core basierender uC ganz wesentliche Vorteile bieten würde.

Das eine ist der diskret gebaute Graphik-LCD Controller. Hier würde man Daten sowohl viel schneller in den Bildspeicher bekommen und könnte ebenfalls viel schneller Graphiken berechnen und schreiben.

Das zweite wäre die Bedienung und Dekodierung von mit hoher Frequenz auftauchenden Ereignissen.

Was mir bei Bascom übrigens gefällt ist wie sehr sich Assembler und der Basickode nahtlos integrieren lässt. Bascom erkennt die Assemblerbefehle im Quellcode als solche und behandelt sie dann auch als solche! Man kann also fliessend dort wo die Hochsprache und Bibliotheksfunktionen die Kodierung beschleunigen diesen Nutzen und dor wo es Zeitkritisch ist Assemblerkode! Dabei muß man sich mit keinen make-files und ähnlichen Komplexitäten herumärgern. In Bascom Basic schreibe ich meinen Kode, der Compler macht den Rest!

[Sanic]

Waum sollte auch jemand eine schwerere Sprache lernen, wenn er immer nur leichte Aufgaben lösen will und diese schnell erledigt haben möchte?

Das ist ja auch ein Punkt:
Meistens sind es keine leichten Aufgaben mehr auf dem ARM. Leichte Sachen kann man meistens mit einem AVR lösen, ein ARM ist häufig ein anderes Einsatzgebiet. Ich bin jetzt in Basic nicht mehr so vertieft und kann daher nicht sagen wie es auf Mikrocontroller Ebene funktioniert (In der Schule haben wir damals was mit Basic auf PCs gemacht ). Natürlich gibt es auch professionelle Entwickler die Basic bevorzugen, vorallem die, die eben damit aufgewachsen sind. Mittlerweile verschwindet Basic aber größtenteils aus den Lehrräumen (zumindest hier im norddeutschen Raum). Es wird verstärkt auf C/C++ gesetzt.

das ein ARM KCore basierender uC wesentlich höhere Geschwindigkeit bietet!

Natürlich ist ein ARM Core schneller in der Berechnung als ein kleiner AVR, für Bittoggelei ist er aber nicht so schnell.
Besonders die I/O Ports die über den Peripherie Bus angebunden sind, sind sehr langsam (LPC2000 ohne FastI/Os ca. 7.5 MHz). Da gibt´s aber Abhilfe: nennt sich bei Philips "FastI/Os".
Bei den ARMs muss man aber auch nochmal unterscheiden wo/wie man denn den Code ausführt:
- ROM
- Flash

Besonders beim Flash ist wichtig wieviele Commands man in einen Cache läd, wie breit der Bus zum Flash ist etc.
Dazu kann man mal bei den LPCs das Kapitel "Memory Accelerator Module" lesen, da steht etwas zu drin.

[Jan_Weber]

Ich würde es ja noch einsehen, wenn "ihr" "uns" ASM aufzwingen würdet. Damit kann man sowohl AVR's als auch ARM's programmieren. Und man hat wirklich den vollen Überblick, was die Hardware grade macht. Was bei C auch nicht der Fall ist.

Das stimmt nicht, denn der Befehlssatz von AVRs und ARMs unterscheidet sich. Abgesehen dacon, wirst du für BErechnungen im ARM vollständig anders vorgehen. Jedes Register ist riesig. Das vereinfacht vieles. Die Hardware vom AVR verstanden zu haben, führt einen in keiner Weise zum ARM.

C ist effizienter Assembler, das schreiben die Erfinder der Sprache. Das muss erstal nix heißen, es ist aber so. Auch in C lässt sich ASM nahtlos integrieren, kein Problem.

Ich möchte hier niemanden mit Zwang bekehren, denn das ist Blödsinn, ich will nur sagen, dass C nicht so schlimm ist und einfach viel mehr kann. Und einen ARM mit Basic programmieren, das ist wie mit dem Dreirad auf die Autobahn zu wollen.

Die Taktfrequenz an sich sagt noch nichts über die Geschwindigkeit der CPU aus. AVR = 1 MIPS/MHz, PIC = 0,25 MIPS/MHz, alter 8051 = 1/12 MIPS/MHz.

Jan

[Marco78]

Das stimmt nicht, denn der Befehlssatz von AVRs und ARMs unterscheidet sich. Abgesehen dacon, wirst du für BErechnungen im ARM vollständig anders vorgehen. Jedes Register ist riesig. Das vereinfacht vieles. Die Hardware vom AVR verstanden zu haben, führt einen in keiner Weise zum ARM.

Ok, den Schuh muss ich mir anziehen. Da habe ich mich wohl missverständlich ausgedrückt.

Basic ist auch nicht immer gleich. Wer VB im Schlaf schreibt wird sich mit Bascom auch noch etwas weiterbilden müssen. Genau so wie es bei einer anderen Basicversion wäre.
Aber wer es einmal kann, kann leichter umlernen.
Genau wie bei ASM. Aber da geht es ja schon selbst in der AVR-Reihe los das es unterschiede gibt.
Ein 90S oder ein Tiny haben nicht alle Funktionen eines Megas. Die Befehle und Anwendung der Befehle muss auch erst erlernt werden.

Print "Hallo"

Sendet über RS232 ein "Hallo". Das kann ich in Bascom für jeden (unterstützten) AVR schreiben.
Ich muss nur einmal angeben um was für einen AVR es sich da handelt und schon wird es dementsprechend angepasst.
Getadc() liefert mir einen Spannungswert (Achtung, Spannungswert hier bitte nicht auf die Goldwaage legen). Da hat man nicht viel Arbeit mit um ihn zu bekommen.

Aber egal, welche Hochsprache ich nehme, ich weiss nie, was nachher tatsächlich in den Flash gebrannt wird, wenn ich es nicht zuvor im AVR-Studio angeschaut habe.
Jeder Programmierer hat einen anderen Stil. Das gilt auch für die Programmierer von Compilern. Hätte Bascom jemand anders entwurfen, wäre der Assemblercode, der erzeugt wird anders als der jetzige.

Mit Bascom könnte man ohne sich viel Gedanken gemacht zu haben relaiv schnell ein Programm schreiben, ohne genau wissen zu müssen, was ein AVR eigentlich kann und macht.
Ich brache jede Sekunde einen ADC-Wert. Dafür muss man einfach einen Timer einstellen (wofür es ja auch schon ein Tool gibt (RNAvr)) und in der ISR den ADC abfragen.
Programm fertig.

Brache ich die Werte schneller/öfters, wird der Timer umprogrammiert und fertig.

Braucht man den Timer fü etwas anders, steht man blöd da. Schaut man ins Datenblatt und versteht die Zusammenhänge zwischen Taktfrequenz (Code) und Teiler für den ADC und weiss die Wandlungszeit, kann man das ganze in ASM programmieren wenn man die benötigten Zyklen der Befehle kennt, ohne einen Timer zu benutzen.

Wer High-End-Anwendungen programmiert, wird wahrscheinlich nicht auf eine Hochsprache zurückgreifen.
Derjenige weiss dann aber auch genau, welcher Prozessor welche Funktionen hat usw. und wird für seine Anwendung schon den richtigen finden.

Wer sich mit sowas nicht beschäftig, wird auch öfters mal einen AVR wählen, der völlig overdressed ist. Aber auch "Hobbiebastler" werden evtl mal einen ARM wählen, weil sie vielleicht eine Hardwarefunktion brauchen, die ein AVR nicht hat.

Die Taktfrequenz an sich sagt noch nichts über die Geschwindigkeit der CPU aus.

Da fühle ich mich mal nicht angesprochen, weil ich sowas ja nicht behauptet habe. Ich selbst weiss das auch.

Ich denke mal, du weisst es auch, aber nur der Vollständigkeit halber möchte ich es erwähnen.

AVR = 1 MIPS/MHz

Das Gleichheitszeichen ist an dieser Stelle nicht ganz richtig. Ungefähr wäre da genauer.
Die meisten Befehle brauchen nur einen Taktzyklus. Andere brauchen aber auch mehr. Bei 16MHz rechne ich für mich immer etwa 12MIPS um sicher zu sein, das das Programm zeitlich korekt ausgeführt werden kann.
Dabei darf man aber nicht vergessen, das eine Subtraktion weniger Zyklen braucht als eine Addition und dieser weniger Zyklen als quadrieren.
(Warum das so ist, geht tiefer in den Aufbau der Elektronik und ist hier etwas fehl am Platz. ABer das es so ist, wissen die "älteren" unter uns auch, ohne zu wissen, was ein Taschenrechner leisten muss. Man konnte es früher auf den Taschenrechner auch gut selbst sehen, wenn die Aufgaben schwerer wurden. Das Ausrechnen hat sichtbar länger gedauert.)
Und dann hängt es auch von der Größe der Zahlen ab. Bei vielen Zahlen größer als 8 Bit kann ein ARM schon wieder interessant werden. (Was ja auch schon gesagt wurde).

Ich stimme euch zu, das man seine Teppiche weiterhin gen Mekka lassen sollte und sich nicht von ARM's blenden lassen sollte.
Auch, das es bessere Compiler geben mag als Bascom.

Aber, wieviele takten ihren AVR mit 16MHz wenn auch 1MHz intern gereicht hätte.
Es gibt halt Menschen, die beschäftigen sich nicht mit den "Kleinigkeiten" im Datenblatt. Die greifen auch gerne auf größere Geschosse zurück und lassen sich von vielen MHz'en blenden.
Es gibt aber auch welche, die wissen, was sie da tuen und merken, das ein ARM an gewissen Stellen "die Lösung" wäre.
Und für letztere wäre es ein Vorteil, wenn sie ihr alt bekanntes Bascom nehmen würden und einfach nur einen anderen Prozessor einstellen bräuchten.

[Hellmut]

Übrigens Marco78, 1 MIPS/MHz, also eine Anweisung pro Takt ist ja das Prinzip das man bei RISC, also "Reduced Instruction Set CPU", Architekturen verwendet, AVR und ARM gehören beide zu dieser Sorte. 8051, die 68k Architekturen sind CISC Implementationen, also "Complex Instruction Set CPU.

Früher, als externe Speicher wesentlich langsamer waren, als die Strukturgrößen noch sehr groß waren und man so viel weniger auf ein Stück Silizium integrieren konnte waren CISC Lösungen sinnvoll, da man hier davon profitierte das auch komlexe Befehle auf dem Silizium ausgeführt wurden und das dort alles sehr schnell erfolgte, im vergleich zum externen Speicher. Compiler-Entwickler stellten dann aber fest das ihre Werkzeuge zum überwiegenden Teil mit nur einer geringen Untermenge der Befehle auskamen und das man die komplexeren Instruktionen durch mehrere einfache Befehle ebenfalls implementieren konnte. Die CPU hat man dann bei RISC so designed das eben praktisch alle Befehle durch die internen Verarbeitungseinheiten und durch andere Busstrukturen in einem Takt ausgeführt werden konnten. Das ergab einfachere Strukturen die man dann besser implementieren konnte und so auch die Taktzyklen hoch treiben konnte. Deshalb haben RISC Befehle meistens alle die gleiche Länge, die Busbreite, damit diese in einem Takt den Verarbeitungseinheiten zugeführt werden können. Bei CISC findet man Befehle die sehr unterschiedlich lang, teilweise sogar sehr komplex sein können.

[Frank]

Ich möchte hier niemanden mit Zwang bekehren, denn das ist Blödsinn, ich will nur sagen, dass C nicht so schlimm ist und einfach viel mehr kann. Und einen ARM mit Basic programmieren, das ist wie mit dem Dreirad auf die Autobahn zu wollen.

Hi,
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!

Eine 32 Bit Controller macht hier durchaus viel Sinn! Nur leider kenne ich zu den Arm´s auch keine gute Entwicklungsumgebung in der Richtung.

Da für meine Sachen aber momentan sowieso die AVR´s noch besser geeignet sind, störts mich noch nicht. Man darf ja nicht vergessen das die AVR´s bestimmte Aufgaben durchaus genausoschnell oder schneller erledigen.

Aber zu C:
Du kannst zwar sagen das C nicht so schlimm ist, aber genauso kann ich dem C Programmierer sagen das Basic nicht so schlimm ist. Der C Programmierer steht in der Hierachie nicht über dem Basic Programmierer, wie es solche Formulierungen manchmal unterschwellig ausdrücken.
Ein guter Basic Compiler hat kaum Nachteile in der Codegenerierung aber viele Vorteile im Handling, insbesondere bei der Controllerprogrammierung. Nicht umsonst findest Du z.B. bei den AVR´s mehr Beispiele in Bascom Source statt C (schau mal ins Forum). C ist schon etwas sehr umständlich im Handling mit Makefile und Headerdateien. Bei großen Projekten fällt es nicht so sehr ins Gewicht wenn man viel Zeit für die Projektverwaltung, Projektaufsetzung aufbringt. Aber will man mal zwischendurch schnell eine kleine Anwendung recht fix schreiben (Cntrollerprogramme sind ja alle recht klein), so war mir das auf die Dauer immer sehr lästig was in C zu machen. Bis man das Programmgerüst mit den Projektdateien fertig hat, da hat man das ganze in Basic schon längst fertig als EXE auf der Platte. Meist hat dieser C Umstand dazu geführt das man es ganz läßt, weil man halt faul ist!

Und warum sollte man für eine Aufgabe 500 C-Codezeilen schreiben, wenn es in Bascom dann in etwa mit 100 Zeilen genausogut klappt.

Wer gerade viel Übung in C hat, für den lohnt sich Umstieg auf Basic (z.B. Bascom) weniger, gleiches gilt für Basic Programmierer. Ein Umstieg macht nur dann Sinn wenn man ein Projekt in der Sprache die man immer nutzt, nicht umsetzen kann. Und solche Fälle sind sehr sehr sehr selten, eigentlich fast undenkbar wenn man bedenkt das man auch Assembler Code integrieren kann.

Gibt es für einen Controllertyp keinen guten Basic Compiler, so muss man zwangsläufig ausweichen. Dann wiederum würde ich schon C der Assemblersprache vorziehen. C ist immer noch erheblich produktiver als Assembler.

Gruß Frank

Genau Jan, das ist auch wichtig.
Für timingkritische Porttoggelei nimmt man am besten einen AVR.
Wenn man viel rechnen möchte und priorisierte Interrupts gebrauchen kann -> ein ARM.

Na, gerade das timing-kritische Porttoggeln ist ja eine Domände vom 8051er.
Da macht der den AVR locker lang.
Wenn man dann noch einen der 100Mipser nimmt, sieht fast jeder MC alt aus.