Archiv verlassen und diese Seite im Standarddesign anzeigen : Bascom ähnliche IDE für ARM?
sebastian.heyn
28.11.2005, 17:06
Hi,
sagt mal gibt es für ARM kerne auch n basic-ähnliche entwicklungsumgebung?
Lass Linux darauf laufen und Du hast auch Basic ;)
Rage_Empire
28.11.2005, 18:02
So ne Art Bascom für ARMs wäre klasse. Hab jedoch noch nichts gefunden, was dem entspricht. Leider!
sebastian.heyn
28.11.2005, 18:19
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...
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...
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...
sebastian.heyn
29.11.2005, 08:04
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.
sebastian.heyn
29.11.2005, 14:09
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.
Sehe ich das richtig, das Reichelt noch keinen ARM im Angebot hat?
Das siehst du vollkommen richtig.
Rage_Empire
30.11.2005, 07:26
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.
sebastian.heyn
30.11.2005, 08:28
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..
Rage_Empire
30.11.2005, 08:47
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.
sebastian.heyn
30.11.2005, 08:54
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
Jan_Weber
15.12.2005, 13:34
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.
Jan_Weber
15.12.2005, 13:50
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
Ich verstehe auch nicht, warum so viele Leute Angst haben vor C.
Gut, bei Bascom sind Treiber für jedes Stück Hardware im AVR dabei
Da hast du die Antwort ;)
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 ;)
Jan_Weber
15.12.2005, 14:45
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
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!
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
16.12.2005, 18:28
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
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.
Ü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.
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.
Jan_Weber
17.12.2005, 19:15
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
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.
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/index.php/Sourcevergleich
Liegt es vielleicht doch daran das es zu anstrengend ist erst wieder ein Projekt in C aufzusetzen ? :-)
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
18.12.2005, 10:43
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
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
18.12.2005, 11:00
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!
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
"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? ;-)
Jan_Weber
18.12.2005, 14:08
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
Rage_Empire
18.12.2005, 16:33
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?
Jan_Weber
18.12.2005, 17:10
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.
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.
[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.
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.
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?
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.
sebastian.heyn
06.01.2006, 06:51
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
Rage_Empire
06.01.2006, 11:27
@Sebastian:
Da muß ich dir schon recht geben, daß viele die in C schreiben davon schon fast zu überzeugt sind. Weil Bascom auf Basic basiert wird dies im Kopf von den Leuten (meißt die mit Bascom noch nie was zu tun gehabt haben) mit Basic-Interpretern von früher oder mit VB in Verbindung gebracht. Dabei muß man sagen, das Basic nicht gleich Basic. Zudem Hadelt es hier um einen Compiler und nicht um einen Interpreter. Was die Effeziens und Überschaubarkeit von Bascom angeht, habe ich bis jetzt nichts besseres gefunden, wobei hier sicherlich noch das eine oder andere Verbessert werden könnte. Auch die Möglichkeit auf den µC dermaßen einzugehen, bis runter auf ASM-Ebene finde ich eine super Sache.
Ich kann den beiden Vorgängern nur zustimmen. dabei möchte ich hinzufügen das BASCOM-AVR eine sehr umfangreiche Bibliothek hat, wodurch man mit wenigen und einfach zu verstehenden Befehlen vergleichweise komplexe Aufgaben implementieren lassen. Ich möchte hier auf I2C und auf die LCD Befehle als Beispiel ansprechen. trotzdem ist man unglaublich flexibel, siehe die Möglichkeit die Zuordung von praktisch beliebigen PINs zu den einzelnen I/F Leitungen eines LCD-Displays, sogar wenn dieses über 2 "enable" Signale jeweils 2 Zeilen eines Display anzusprechen hat. Gäbe es vergleichbares für ARM könnte man vieles schnell nach dort portieren!
Ich kann den beiden Vorgängern nur zustimmen. dabei möchte ich hinzufügen das BASCOM-AVR eine sehr umfangreiche Bibliothek hat, wodurch man mit wenigen und einfach zu verstehenden Befehlen vergleichweise komplexe Aufgaben implementieren lassen. Ich möchte hier auf I2C und auf die LCD Befehle als Beispiel ansprechen. trotzdem ist man unglaublich flexibel, siehe die Möglichkeit die Zuordung von praktisch beliebigen PINs zu den einzelnen I/F Leitungen eines LCD-Displays, sogar wenn dieses über 2 "enable" Signale jeweils 2 Zeilen eines Display anzusprechen hat. Gäbe es vergleichbares für ARM könnte man vieles schnell nach dort portieren!
Hmm, so wie ich das sehe, gibt es Bascom nur für den AVR, auch sonst sind die ganzen Basic Dialekte doch sehr auf die jeweiligen Controller zugeschnitten.
Da es GCC für fast alle Prozessoren gibt, hat man da eine sehr grosse Flexibilität, z. B. wenn man zu spät feststellt, dass der Controller doch zu klein wurde.
Da reicht es dann, ein paar Initialisierungen zu ändern und man kann (wenn das Programm vernünftig gemacht wurde) alte Programme auf neuen Controllern relativ fix aufsetzen.
Mal davon abgesehen, dass man mal schnell besondere Routinen auf dem PC testen kann.
Gruss
Axel
sebastian.heyn
10.01.2006, 16:00
bascom-8051 gibt es auch, soviel ich weiss
Rage_Empire
10.01.2006, 16:18
Ja, und jetzt fehlt noch Bascom-ARM ;-)
auch sonst sind die ganzen Basic Dialekte doch sehr auf die jeweiligen Controller zugeschnitten.
Das ist mir noch nicht aufgefallen.
Es wäre schön wenn du dazu ein Beispiel hast.
Ich kann ein Programm für einen Tiny26 schreiben und durch ändern einer Datei es auf nem Mega8 laufen lassen (Die Pins ändern lass ichmal außen vor, das hat man bei jeder Sprache.)
Mal davon abgesehen, dass man mal schnell besondere Routinen auf dem PC testen kann.
Das geht im Simulator auch.
Rage_Empire
10.01.2006, 19:00
Wie schon gesagt, es sind zuviele, die Bascom nicht wirklich kennen aber es (da es eine Basicorientierte Sprache ist) gleich als untauglich abtun.
Wohlgemerkt zum Simulieren am PC #-o ......Bascom ist eine IDE-Plattform! Das sagt doch wohl alles darüber aus.
Mal was zur Logik:
Wenn ich noch keinen Audi A6 gefahren bin, kann ich auch nichts über ihn sagen! Und wenn ich nur Mercedes fahre werde ich nie erfahren, was Audi für autos baut!
Euch ist schon aufgefallen das diese Provokation mit Gastaccount gemacht wurde ja ? :wink:
"Euch ist schon aufgefallen das diese Provokation mit Gastaccount gemacht wurde ja ?"
Es ging mir nicht ums Provozieren, sondern ich habe lediglich meine Meinung und meine Argumente dazu geschrieben, weil ich mich mit dem Thema gerade beschäftige.
Ich gebe allerdings zu, dass ich mich mit dem Bascom nicht grossartig beschäftigt habe. Da ich auch viel in Linux etc. programmiere, kommt für mich halt nur C in Frage, weil ich keine zwei oder drei Programmiersprachen parallel machen will.
Da ich mich gerade in ARM einarbeite (so bin ich hier überhaupt gelandet) ist C halt die erste Wahl. Und gerade beim ARM, wo irgendwann auch mal Themen wie Betriebssystem etc. anstehen, werde ich gleich mit C anfangen.
Gruss
Axel
Eine Stichelei als Meinung zu tarnen macht es nicht besser.
Gut,kann ich auch:
Du gibts ja zu Bascom nicht zu kennen und mir hallen dabei schon wieder Rage_Empire's Worte in den Ohren also woher nimmst du das Recht darüber zu urteilen was Sinnvoll ist ?
Wie schon gesagt, es sind zuviele, die Bascom nicht wirklich kennen aber es (da es eine Basicorientierte Sprache ist) gleich als untauglich abtun.
Die Argumente gegen Basic sind teilweise arg veraltet ;)
Ich höre immer wieder was von "Goto Zeilennummer"," Spaghetticode" etc..
(Wobei ich mich frage, was denn formal der Unterschied zwischen einem "bösen" GOTO und einem "guten" einfachen Sprungbefehl in Assembler ist ..)
Einige Leute glauben aber anscheinend immer noch, daß sich seit den Zeiten des ZX81 / C64 Basics nix geändert hat.
Naja, egal.
Wie schon gesagt wurde, ist die beste Programmierspache die, mit der man am besten zurechtkommt.
(oder mit der man am schnellsten sein Problem gelöst kriegt ?
oder die, die einem die meiste Arbeit abnimmt ? )
"Bei Basic weiß du nicht was das Programm genau macht"
Weiß ich bei C wohl auch nicht wirklich.
Aber im Ernst: das interessiert mich auch nicht wirklich, wenn der Controller das macht, was er soll. ;)
Wozu habe ich denn sonst Hochsprachen?
Gruß
Christopher
Ich würde doch bitten die persönlichen Angriffe zu unterlassen und zur Sachdiskussion zurückzukehren.
Welche Sprache man verwendet kommt immer auf die persönlichen Vorlieben und auf das Problem an, das man damit lösen möchte.
Ich muss hier allen Recht geben, die sagen, dass Basic inzwischen eine Programmiersprache ist mit der man schnell und gut Probleme lösen kann.
Was die Übersichtlichkeit angeht, muss ich sagen, dass sich Basic und Assembler beide nichts geben. Wenn man sich nicht sehr am Riemen reisst, wird jeder Basiccode durch zuviel Sprünge - bei Assemblercode geht das noch sehr viel schneller - unübersichtlich.
Das bedetet aber nicht, das C-Code generell übersichtlicher ist. Es kommt immer auf den an, der programmiert.
Auf Mikrocontrollerebene kommt man nur extrem selten auf so komplexe Programme, dass Basic an Struktur verliert, auf dem PC sieht das schon anders aus. Und der ARM steckt irgendwo dazwischen.
Generell lässt sich das Problem Basic - C relativ leicht lösen:
Für Einsteiger ist Basic besser geeignet, weil alles klar und am Namen erkennbar ist.
Für Vollprofis, die sich 8h am Tag damit beschäftigen, ist C effizienter, da ür die gleiche Funktion weniger Zeichen benötigt werden. Ob das dann für einen Aussenstehenden einfacher zu verstehen ist, mag ich bezweifeln.
Mein Fazit: Für Profis, die sowieso den ganzen Tag nichts ausser ihren Controller programmieren, ist C angenehmer. Für Hobbyprogrammierer ist Basic sicher die Sprache der Wahl, vor allem, da beide Sprachen inzwischen nahezu gleicheffizienten Code erzeugen.
Letztendlich ist es aber eine rein persönliche Entscheidung, genauso wie die Frage, ob man lieber einen AMD oder einen Intelprozessor nimmt - oder ob AVR oder PIC. Für alles gibt es gute Argumente und jede Seite ist überzeugt die besseren Argumente zu haben.
Daher würde ich um folgendes bitten: begrabt die Diskussion - es geht hier nicht darum, ob Basic oder C besser sind, sondern es geht darum, ob jemand eine Bascom-ähnliche IDE für ARMs kennt.
MfG
Stefan
@stegr: Hast absolut recht. Ich bezeichne mich als "Hobby-Programmierer" und finde mit BASCOM-AVR das für mich sehr hilfreiche Tool. Der Grund warum ich einen ARM einsetzen würde wenn es ein Produkt wie BASCOM dafür gebe ist eine Anwendung bei der ich ein hochaulösendes LCD Graphik Display mit Touchpanel als Multifunktionsdisplay einsetzen möchte, welches mit meinem Modellsegelboot über die Funkmodule von Robotikhardware.de kommuniziert. Mit dem jetzt auschliesslich verfügbaren BASCOM-AVR Compiler werde ich die Lösung mit einem mega128-Modul mit SD-Speicher I/F und einem Modul mit dem passenden Epson LCD-Controller implementieren.
Dabei bin ich mir bewusst das der mega128 das "bottleneck" sein dürfte. Um die Lösung trotzdem hinreichend schnell zu machen werde ich den "off-screen" "onchip" Speicher des LCD Controllers mit Bildelementen laden die ich über BitBlt Befehle des LCD Controllers in den abgebildeten Bildspeicher kopiere.
Hätte ich jetzt einen ARM mit hinreichendviel Speicher könnte ich diesen viel mehr mit "rendering" Aufgaben auslasten. Ich würde also im Prinzip seine Rechenleistung und die Mächtigkeit seiner Speicherschnittstelle nutzen. So versuche ich die begrenzte Leistungsfähigkeit des AVR Controllers betreff beider Parameter dadurch zu verbergen das ich vorbereitete Bildelemente lokal abgespeichert halte und bei Bedarf rein kopiere.
sebastian.heyn
12.01.2006, 12:04
ich verstehe eigentl. gar nicht wie hier C ins spiel gekommen ist:
"Bascom ähnliche IDE für ARM"
AH ich verstehe basCom
ich verstehe eigentl. gar nicht wie hier C ins spiel gekommen ist:
"Bascom ähnliche IDE für ARM"
AH ich verstehe basCom
Nö,schau mal auf Seite eins dieses Topics wer damit angefangen hat.
Ich kann mir ein gewisses schmunzeln nicht verkneifen denn das
erinnert mich an ein gewisses hier nicht genanntes Forum indem man
paranoide Angstzustände bekommt wenn das Wort "Registrierung" aufkommt
weil man gerne mal seine Vorlieben provokannt und "Anonym" herausbrüllen möchte da man der Argumentation nicht fähig ist. :wink:
Rage_Empire
31.01.2006, 12:40
Ja, hat schon jemand inzwischen was gefunden, womit der ARM in "Basic"-Umgebung programmiert werden kann?
Nö,ich hab aber auch nicht danach gesucht.
Jetzt mal wieder nach über einem Jahr Pause die Frage:
Gibt es was neues?
Ich wäre auch an einer Basic-Umgebung für ARMs interessiert!
jon
Das gibts was aber noch nicht so prall.
https://garage.maemo.org/projects/bac/
Betriebssystem ist Linux. Und mit dem komme ich nicht so ganz zurecht. Bin zu sehr von Microsoft verwöhnt ;)
Also nichts für mich.
Gibt es vielleicht noch etwas anders?
jon
Quäl doch einfach mal die Suchmaschinen.
Nur weiß ich nicht mit welchen Suchwort :( :(
jon
Ach, ja.
Suchen will gelernt sein :-k ;) ;)
Ich würde das naheliegendste nehmen.
"ARM Basic Compiler Controller"
"ARM Basic Compiler Controller"
Da kommt erstmal ganz viel zu BASCOM ](*,) ](*,)
Aber so wirklich etwas finden, dass ich wenigstens als DEMO runterladen kann, tue ich nicht. ](*,) ](*,)
jon
Ja was willst denn haben ?
Mundfertig mit Bildern ?
Etwas anstrengen mußte dich schon selber. ;)
Ich will ein Programm, möglichst umsonst, mit dem ich einen ARM7TDMI proggen kann. Als Programmiersprache wäre ein Basic-Dialekt schön, da ich noch nie mit ASM oder C gearbeitet habe und ich nicht die Zeit und lust habe mich in eine der Sprachen einzuarbeiten.
Ich habe alle 17 Seiten, die Google mit Suchergebnissen hat, durchgesucht nur nichts gefunden :(
jon
P.S.:Was meinst du mit "Mundfertig mit Bildern?"??
P.S.:Was meinst du mit "Mundfertig mit Bildern?"??
Na das dir jegliche Müh abgenommen wird.
Etwas eigenständige Suche mußt du schon selber leisten.
Das dürfte ja nicht zuviel verlangt sein denn wenn du das nicht hinbekommst wie willst du dann erst Programieren ? ;)
Spiel mit den Suchbegriffen dann findest du auch die Projekte.
ckuehnel
11.03.2007, 22:43
Von MCS Electronics ist BASCOM-ARM angekündigt. Ein Termin ist mir noch nicht bekannt.
Es gibt aber HBBR Basic, was man auch mal ansehen kann.
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.
Alex20q90
21.01.2008, 20:46
Jungs das Streiten hat keinen Wert! Wenn einer Mercedes fährt ist er gegen BMW. Audi oder Opel. Aber alle haben 4 Räder und bringen einen (mehr oder weniger^^) ans Ziel!
Genauso ist es mit Basic und C (oder ASM/TP/VB).
Basic ist nichts weiteres als verständliches C
Ich habe angefangen mit Pascal (1996) für PC-Software. Zeitgleich mit Assembler für die 90s von Atmel. Nebenher am C64 mit dem Basic-Interpreter rumgetippselt. 1998 wurde ich voll allen über C vollgelabert. Also angefangen mit C. { } if i ==...Prellt etwa die Tastatur? && schon wieder.. Ich fand C als eher "ekelhaft" und mir kam es so vor als wollte man die Programmierer schikanieren. Dann bin ich wieder zu Assembler zurück und entdeckte den Basic-Compiler Bascom. Ich hab nix davon wenn ich sage "boaa 30000-Zeilen Quellcode! Kniet nieder vor mir" um dann festzustellen das ich mit "Config GraphLCD" das gleiche erreichen konnte. Eine Datei anstatt viele *.c und *.h! Für mich ist C wie die Krieger in Wow. Man muss ihnen minutenlang sagen was sie hauen sollen, und treffen nach einigen Versuchen indenen sie steif und fest behaupten daß das Erzvorkommen sich ständig bewegt wenn sie sich wegdrehen, auch mal den Mob...
Mittlerweile hab ich mich auch noch für Visual Basic endschieden, da der Dialekt _ähnlich_ des Bascom-Dialektes ist!
Und es ist egal ob einer der C programmiert Bas schlecht findet! Warum? Meine Prozessoren juckt es nicht! Sie machen das wass sie sollen! Und wenn nicht, dann fällt halt mal ne Drohne vom Himmel (kennt Ihr die X-Ufos? Kann man mit nem AVR selber baun!)
Grüße
Alex
Ja, schade,
von MCS hört man zu dem Thema nichts.
Auch nichts zur, früher einmal angekündigten, neuen, IDE.
Naja, da müssen wir wohl noch abwarten.
Gruß
Christopher
Das ist auch nicht verwunderlich.
Abgesehen das Bascom-AVR gut läuft,spürbar weiterentwickelt wird usw. gibt es da zum einem den Umstand das die ARM "nur" in SMD erhältlich sind und viele noch davor zurückschrecken und zum anderen ist eine IDE für nen 32-Biter "wesentlich" komplexer als für die doch einfach gehaltenen 8-Bit Modelle.
Dazu besteht bei MCS ein gewisser Erwartungsdruck an die Fähigkeiten der ersten Version.
Irgendeine halbgare prä-Alpha ins Web stellen und dann jahrelang daran mehr oder weniger herumdoktern ist hier nicht möglich.
Da muß die erste Beta schon handfester sein.
Und zuletzt schätze ich mal das die Jungens von MCS mit Bascom-AVR und 8051schon genug ausgelastet sind.
Es ist also in der Tat noch mit Wartezeiten zu rechnen.
Eine gute Gelegenheit Assembler zu lernen ;)
Rage_Empire
12.06.2008, 11:40
Gibts hier inzwischen was neues?
Scheinbar noch nicht.
Man könnte jetzt noch die neuen XMegas ins Gespräch bringen.
Ich denke aber auch, dass Mark schon mit Bascom AVR gut zu tun hat.
Hi,
zumindest steht es in der Bascom - Hilfe drin,
daß eine ARM Version entwickelt wird.
Gruß
Christopher
@repi64: Auf meine Anfrage bei MCS ab wann die Xmega unterstützt werden habe ich vor einiger Zeit die Antwort erhalten das sie noch auf Muster der megax warten. Daraus schliesse ichdas MCS sich um die megax kümmern wird sobald diese wirklich verfügbar sind.
Allerdings zeigen die megax verglichen mit den mega´s bereits eine wesentlich erhöhte Komplexität. Mal sehen wie es weiter geht.
Hi,
auch ein "Arm-Basic": http://www.coridiumcorp.com/Programming3.php
HBBR-Basic: http://www.hbbrbasic.com/
Umsonst: [-X
mfg Karl
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.