Hi,
sagt mal gibt es für ARM kerne auch n basic-ähnliche entwicklungsumgebung?
Druckbare Version
Hi,
sagt mal gibt es für ARM kerne auch n basic-ähnliche entwicklungsumgebung?
Lass Linux darauf laufen und Du hast auch Basic ;)
So ne Art Bascom für ARMs wäre klasse. Hab jedoch noch nichts gefunden, was dem entspricht. Leider!
mit dem linux mach ich mir doch die ganze performance kaputt... das ist vielleicht geil, wenn man irgendwie tcp/ip oder so brauch, aber für einfache anwendungen möchte ich auf ein OS verzichten...
Zitat:
Zitat von sebastian.heyn
Da muss ich mich wohl verlesen haben. Basic und Performance? Hallo?
Also entweder Performance, dann C und Assembler, aus praktischen Gründen (Wartung und Erweiterung der Software) ein Mix aus beiden, oder Performance ist Wurst, dann egal was.
Linux mit einem freien Basic ist dann ein prima Vorschlag...
Hallo,
ich glaube, dass basic nicht immer schlechtere performance haben muss als c ist eigentlich schon oft diskutiert worden, und an vielen stellen soll bascom besseren und kleineren code erzeugen als C. (ist glaub ich hier mal ein vergleich gemacht worden)
Bascom ist ein BASIC-compiler und sollte damit ausreichend effizient sein. Nur Basic-Interpreter sind langsam. Embedded linux ist in diesem Zusammenhang wohl auch nicht die optimale Lösung, braucht nämlich wesentlich mehr Speicher und Flash als auf den ARMs von Haus aus drauf sind. Von der höheren Komplexität gar nicht zu reden.
darum ging es. ich habe auch nie von einem interpreter gesprochen...
manchmal braucht man auch nicht unbedingt so viel performance. bei mir ist es oft so das programme nur an einer bestimmten stelle ein bisschen mehr performance benötigen als der avr zu bieten hat...
Ich muß hier bemerken das ich gleichfalls gerne ein BASCOM ARM hätte! In uC, auch wenn es ein ARM ist, arbeitet man im allgemeinen und möchte es auch, sehr Hardware nah sein. Ein Basic Compiler wie BASCOM AVR ist für nicht C-Freaks auch vom Kode sehr gut zu verstehen. Wenn ich zeitkritischen Kode schreibe denke ich doch sehr genau darüber nach was genau auf Hardware-Ebene passiert. Linux abstrahiert das ja durch seine Funktionalität!
Habe in der aktuellen ct-Zeitschrift gerade gelesen wieviel Kode man unter Windows, Linux, usw. erzeugt um das famose "Hello World" zu erzeugen, absurd!
In der Hoffnug das MCS hier mal rein schaut wünsche ich mir auch ein Bascom ARM :D
Das mit Linux habe ich jetzt noch nicht ganz verstanden. Soll Linux auf dem ARM laufen oder gibt es einen Basic-Compiler für ARM unter Linux? Wenn zweiteres Ja, wie nennt der sich?
Ich könnte damit leben, für solche Anwendungen mal Knoppix von CD zu booten. Oder gibt es nicht auch eine Linuxumgebung, die unter Windows läuft?
Wie auch immer. Das soll jetzt kein Anlaß zur Diskussion sein, sondern nur eine Frage, was es z.Zt. gibt. Ich denke in Zukunft wird sich da noch jemand finden der Basic und ARM vereint.
PS: Wenn man (jemand, der sich damit auskennt) die .DAT von Bascom abändert, müsste es mit Bascm doch auch schon geh'n, oder?
Sehe ich das richtig, das Reichelt noch keinen ARM im Angebot hat?
Ich glaube, dass eher gemeint ist, dass man ein Linux auf dem ARM laufen lässt und darauf dann einen Basic-Interpreter.
Das siehst du vollkommen richtig.Zitat:
Sehe ich das richtig, das Reichelt noch keinen ARM im Angebot hat?
Ich denke auch, daß bedarf an solch einer Oberfläche da wäre. Wie komplex das ist, Bascom für einen ARM umzusetzen weiß nur MCS.
Obwoh Reichelt keine ARMs hat gibts jedoch recht gute und günstige Boards dafür.
Vieleicht geben wir MCS hiermit den Astoß für ein BASCOM-ARM System?
Ich denke, Bascom wird von Nicht-Usern oftmals unterschätzt, da Basic schnell mit einem Interpreter in Verbindung gebracht wird.
ich werd den link mal an mcs schicken. vielleicht arbeitet man dort ja schon an etwas in der richtung.
Selbst Bascom-M16C oder BASCOM-V850 wär verdammt nützlich, wobei ARM wohl gebräuchlicher ist..
Hm, eine Universelle Bascom-Umgebung wäre doch klasse. Eine Umgebeung, die wohl AVRs, ARMs wie auch andere Controller beinhaltet. Damit könnte man ganz einfach Programme von µC zu µC übertragen, was ein riesen Vorteil wäre. Dafür würde ich gern auch etwas mehr Geld ausgeben.
Auf jeden fall...das problem wir einfach die entwicklungszeit sein.
die grundlage ist ja im prinzip schon gelegt..
ich denke man müsste nur irgendwie für dei funktionen/befehle für den jeweiligen prozessor andere asm-routinen bauen. Ist halt ne reine zeitfrage.
Die unkommerzielle Compilerfrage ist bei ARM so eine Sache.
Generell gibt´s natürlich den gnugcc der wunderbar arbeitet.
Nun muss man aber auch das Anwenderfeld der ARMe mal sehen, wer arbeitet denn damit ?
Hauptsächlich braucht man diese Performance in professionellen Bereichen. Hier wird wenig in Basic programmiert sondern entweder in ASM oder C. Selbst C++ ist möglich (siehe WinARM Seite).
Außerdem kann man C relativ schnell lernen wenn man schon Basic kann.
Wenn man schon etwas in Basic und C reingeschnuppert hat kann man sich das Buch "C für Mikrocontroller" zu Gemüte führen, da sind auch nette für Mikrocontroller relevante Dinge drin.
Grüße
Performance ist halt so eine Sache. Nicht alles muss auf einem ARM auch uunbedingt schneller sein. 32 Bit sind erst dann nützlich, wenn man mit so großen Zahlen umgeht. Dafür dauert je nach Prozessor das Port toggeln länger, du hast einen tierischen Overhead, bis Interrupts laufen. Das System ARM ist eine ganz andere Liga. Das sind halt nicht nur größere Register, sondern eine Menge anderes Zeug, das vernünftig bedient werden will. Das vernünftig auszunutzen mit Basic wird schwierig sein.
Wenn du mit Byte-großen Variablen arbeitest, wären für dich vielleicht auch beschleunigte 8051er oder Sx-Controller was. Die haben nicht die komplexe CPU-Struktur mit unterschiedlichen Kontexten etc. wie ein ARM. Die sind so geradlinig wie ein AVR.
Der DS89C420 (8051-basiert) kann bis zu 33 MIPS leisten, bei einem MIPS/MHz, das meiste passiert also in einem Zyklus wie beim AVR. Für die 8051 gibt es ja auch einen Bascom-Compiler. Die Scenix-Dinger sind ja beschleunigte PICs, und es gibt sie wohl bis 75 MHz. Wie da die Relation MIPS/MHz ist, weiß ich nicht.
Jan
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.
Generell ist das Interrupt System komplexer, man kann auch FastInterrupts benutzen, die das System dann schneller abarbeiten ( Schneller = Zeit vom Eintreffen des Interrupts bis zum Sprung in die ISR ) kann.
Man glaubt gar nicht was man mit einem AVR und einer sinnvollen Programmierung alles machen kann, der Schritt in Richtung ARM ist also nicht immer begründet.
Ich verstehe auch nicht, warum so viele Leute Angst haben vor C. Das ist alles gar nicht so schlimm (zumindest bei AVRs). Gut, bei Bascom sind Treiber für jedes Stück Hardware im AVR dabei, aber die sind oft nicht transparent, man weiß also nicht, was sie tun. Viele Leute müssen wahrscheinlich im Blindflug ihre Programme basteln, weil sie nicht genau wissen, wie Bascom das jetzt umsetzt.
Ich habe direkt mit C angefangen, und es ist nicht schwer gewesen. Ich sage das nur, um hier noch mal Mut zu machen. Es setzt Datenblattstudium voraus, mit Bascom würde man viel mehr schaffen, ohne zu wissen, was ein AVR wie macht, aber dennoch, ab einem bestimmten Punkt wird es mit Bascom schwieriger. Das liegt in der Natur der Sache.
Jan
Zitat:
Zitat von Jan_Weber
Da hast du die Antwort ;)Zitat:
Zitat von Jan_Weber
Ich bin von einer C-Control auf einen AVR und dann mittlerweile auf ARM umgestiegen. Natürlich ist es schön wenn man alles schon fertig vorgekaut hat, aber sobald man mal tiefer gehen möchte (in diesem CC2-Basic gibt´s keine Interrupts) ist es schon wieder vorbei.
Da schreibe ich lieber einmal die Treiber neu, lerne etwas dabei und kann dann später günstige Controller kaufen die 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.Zitat:
nicht mal eben abgekündigt werden wie eine C-Control
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
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
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?
@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!
Das ist ja auch ein Punkt:Zitat:
Zitat von Marco78
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.
Natürlich ist ein ARM Core schneller in der Berechnung als ein kleiner AVR, für Bittoggelei ist er aber nicht so schnell.Zitat:
Zitat von Hellmut
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.
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.Zitat:
Zitat von Marco78
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
Ok, den Schuh muss ich mir anziehen. Da habe ich mich wohl missverständlich ausgedrückt.Zitat:
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.
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.
Da fühle ich mich mal nicht angesprochen, weil ich sowas ja nicht behauptet habe. Ich selbst weiss das auch.Zitat:
Die Taktfrequenz an sich sagt noch nichts über die Geschwindigkeit der CPU aus.
Ich denke mal, du weisst es auch, aber nur der Vollständigkeit halber möchte ich es erwähnen.
Das Gleichheitszeichen ist an dieser Stelle nicht ganz richtig. Ungefähr wäre da genauer.Zitat:
AVR = 1 MIPS/MHz
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.
Ü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.
Hi,Zitat:
Zitat von Jan_Weber
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
Na, gerade das timing-kritische Porttoggeln ist ja eine Domände vom 8051er.Zitat:
Zitat von Sanic
Da macht der den AVR locker lang.
Wenn man dann noch einen der 100Mipser nimmt, sieht fast jeder MC alt aus.
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.Zitat:
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
ARMs wurden doch gerade für größere Anwendungen gewünscht?Zitat:
(Cntrollerprogramme sind ja alle recht klein)
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
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.Zitat:
Ich werde zu diesem Thema nichts weiter schreiben, weil das ja jetzt schon in einen Krieg der Programmiersprachen ausgeartet ist.
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 ;)Zitat:
und im Endeffekt gar nicht so genau wissen, was ihr Programm da macht,
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.
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 ? :-)
Mal abgesehen davon das ein Grossteil aller PC Anwendungen auch nen Code Overhead hat der absolut unnötig ist ...Zitat:
Zitat von Frank
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.
Na, dann antworte ich nochmal :)Zitat:
Zitat von Marco78
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.Zitat:
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.
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.
Noch nie was von ANSI-C gehört?Zitat:
Zitat von Frank
Schönen Sonntag,
Jan
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.
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!
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.Zitat:
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.
Abgesehen davon gibt es sowas wie eine Listfunktion in Basom Basic auch. Auch die Codeoptimierung kennt Bascom.
Falsch! Selbstverständlich hat man in Bascom auch beide Möglichkeiten! Gewöhnlich nimmt man jedoch den kürzesten Weg.Zitat:
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.
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?
Dann sage ich es dir hiermit. Es gibt diese UART interrupt Funktionen! :-) Hier gibt es in Bascom gegenüber C keine Nachteile.Zitat:
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.
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 :-)Zitat:
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.
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!!!
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!Zitat:
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.
Doch, nur es gibt nahezu keine Anwendung die mit reinem ANSI-C programmiert wird. Was nützt einem die Kompatiblität auf dem Papier?Zitat:
Noch nie was von ANSI-C gehört?
Ebenfalls schönen Sonntag
Gruß Frank
Das mit den Libraries und DLLs hängt vom jeweiligen Compiler-Hersteller ab. Bei Microsoft ist es auf jeden Fall richtig.Zitat:
Zitat von Frank
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
"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? ;-)