Gast
#2393421
Hallo, damit meine ich, ob es auch Basicumgebung gibt um einen ARM zu programmieren. Beim Atmega ist es ja Bascom
Gast
#2393426
wenn man C kann ist es nicht so schlimm wenn man aber gegen alle Warnungen die Sackgasse BASIC/BASCOM gewählt hat -> Pech
Bei welchem Problem ist ein ARM sinnvoll zusammen mit BASIC?
Gast
#2393429
Es ist gaaaaaaanz-ganz schwer, so um die 25-30 kilo... Jetzt aber im Ernst: Lass Basic sein, für einen ARM gibt es einen solchen Kinderspielzeug eh nicht. Dafür aber sehr gute C-Compiler soweit das Auge reicht. Beispielweise könntest du deinen google-Streifzug hier starten: http://www.mikrocontroller.net/articles/STM32
Wenn du C auf dem Avr lernst fühlt es sich (rein Geschwindikeitsmäßig) erstmal wie ARM an.
Gast
#2393434
>Wenn du C auf dem Avr lernst fühlt es sich (rein Geschwindikeitsmäßig) >erstmal wie ARM an. hihihi
Gast
#2393435
Wenns um Hochsprache geht ist das wohl gleich ABER die haben viel mehr Hardware drin das mußt du erstmal ne ganze Menge Initialisieren um ne LED anzuschalten. Also C sollte man schon können in Assembler macht man da nicht mehr viel (Bei neueren CortexM3). Und man muß sich darauf einstellen das man am sich am Anfang ne weile mit der Hardware beschäftigen muß. Also 1000 Seitenm Datasheet lesen ist der Anfang danach weiß man woran man ist. Danach kann man ich mit der Entwicklungumgebung auseinandersetzen und versuchen ne LED zum leuchten zu bringenn bis zu DMA über nen Multilayer Busmatrix.
Gast
#2393445
Man sind da viele Fehler drin. Lass BASIC sein. Lern C auf dem PC. Mikrocontroller kennst du ja schon vom AVR (zwar in BASIC). Nachdem du C gelernt hast probierst du das nochmal auf nem AVR und gehst zu ARM gute Nacht
versuch mal mit PIC32 Arduino - auf jedem fall schneller als ein AVR8 Bascom, aber bei weitem nicht so komplex wie ARM im C
Also so schwer ist der ARM auch wieder nicht. Im Artikel STM32 sind in wenigen Punkten die Hauptunterschiede für AVR/8051 Umsteiger beschrieben, die man beachten sollte. Schon richtig, dass der ARM mehr Hardware Peripherie drin hat, und jedes einzelne HW-Teil hat auch nahezu unbegrenzte Möglichkeiten. Aber das ist doch eher ein Vorteil, auch wenn man zu Anfang auch mal etwas mehr lesen darf. Demos gibt es für den STM32 nahezu genauso viele wie für den AVR.
Also, was soll denn das Basic-Gebashe ob einer programmieren kann oder nicht teilt sich nicht an der verwendeten Sprache / Syntax. Ich für meinen Teil bevorzuge auch die Basic-Syntax, finde sie einfach schöner lesbar als C. Wobei ich letzteres mir auch angeeignet habe. Es gibt für ARM das HBBR-Basic, das auch verschiedene ARMs unterstützt. Wie gut der Compiler ist kann ich aber nicht beurteilen.
Fhutdhb Ufzjjuz schrieb: > Also, was soll denn das Basic-Gebashe ob einer programmieren kann oder > nicht teilt sich nicht an der verwendeten Sprache / Syntax. Mag sein, meistens aber schon. Denn mit Basic ist es deutlich schwerer effizient zu programmieren. Je näher die Sprache HW-gebunden ist, desto schneller. Natürlich liegt es auch am Programmierer, aber wer C verstanden hat kann mehr als wenn man Basic programmieren kann. > Ich für meinen Teil bevorzuge auch die Basic-Syntax, finde sie einfach > schöner lesbar als C. Wobei ich letzteres mir auch angeeignet habe. Geht mir genau umgekehrt. Ich habe vielleicht 3-4 Bascom-Programme geschrieben und bin an der Syntax verzweifelt. Bascic ist wie eine richtige Sprache - total unlogisch. Mit C habe ich keine Probleme. > Es gibt für ARM das HBBR-Basic, das auch verschiedene ARMs unterstützt. > > Wie gut der Compiler ist kann ich aber nicht beurteilen. Ich glaube, man darf behaupten, dass die Basic-Compiler zu 99% den C-Compiler stark unterliegen.
Gast
#2393507
uff schrieb: > Beim Atmega ist es ja Bascom Wenn du noch bis Dezember warten kannst:: http://www.mikroe.com/eng/products/view/753/mikrobasic-pro-for-arm/
Samuel K. schrieb: > Mag sein, meistens aber schon. Denn mit Basic ist es deutlich schwerer > > effizient zu programmieren effizienz ist nicht alles, für viele Aufgaben reicht BASCOM vollkommen aus, es ist nicht immer notwendig das allerletzte aus der Hardware raushollen. Dort wo es sinvoll ist, ist entwicklungszeit für BASCOM Programme ist kurzer und die Fehleranfälikeit gerinneger da vieles eh bereits von den BASCOM Bibliotheken abgedeckt wird was in C mühsam von Hand programiert werden soll. Dazu fehlt im BASCOM die schlimmste Fehlerquelle in C -> Wildgelaufene Pointer. Die syntaktische nähe zur VisualBasic durfte für dem Einem oder Anderem genauso ein sehr großem Vorteil darstellen vor allem wenn es eine verbindung PC<-> uC geben soll. Es ist immer die Frage was ist das richtige Wergzeug für das Aktuelle Problemm.... Ein gut geschriebener logisch aufgebauter BASCOM Programm ist immer noch 1000 mal besser als ein schlampig geschriebener C Programm und im iNet findet man unmengen von der letzten Sorte.
Gast
#2393663
uff schrieb: > damit meine ich, ob es auch Basicumgebung gibt um einen ARM zu > programmieren. Hallo mein Lieber, ich hoffe mal, du als Verursacher dieses Threads liest auch noch mit. Also: die ARM-Programmierung ist eigentlich sehr viel leichter und angenehmer als beim AVR - mal abgesehen von den Anfangshürden beim Verstehen der Assemblerbefehle, der CPU-Struktur und des Interrupt-Geschäftes. Ja, ist für einen BASIC-Benutzer erstmal ein gewaltiger erster Schritt, aber du wirst hinterher nie wieder zurück wollen. Man hat plötzlich Platz und Speed und alle Annehmlichkeiten wie Gleitkomma bis zu double, mathematische Funktionen, einheitliche Pointer überall hin usw. Mein Rat: Lade dir von ARM die technischen Dokumente, vom IC-Hersteller deiner Wahl die PDF's zum Controller und von Keil deren Tollchain herunter und benutze sie. Das Ding ist erstmal kostenlos, dafür aber begrenzt in der Codegröße - aber du willst auf den Anfang ja sowieso kein Riesenprogramm schreiben. Wenn Blinky erstmal läuft, dann sehen wir weiter. Ach ja, guck nicht bloß auf STMxxx, sondern schau dich etwas weiter um. NXP macht auch ARM- und Cortex-Controller (deren Manuals finde ich etwas leserlicher als die von ST), Texas auch (Stellaris) und Firmen wie Nuvoton machen auch Cortexe. Von denen bekommt man evtl sogar für fastgarnix ein Mini-Evalboard, wo die eine Hälfte ein passender JTAG/SWD-Adapter ist. Sowas ist zusammen mit deren Brennsoftware fast unschlagbar für den Einstieg. Ach ja, nochwas: Bei NXP und ST sind in den uC's fest eingebaute Bootlader drin. Dafür braucht man bloß noch eine serielle Strippe und das Brennprogramm (NXP: FlashMagic, ST.. ähem "Flashloader-Demonstrator" oder so, fällt mir grad nicht ein) zum Programmieren - JTAG ist dafür nicht erforderlich. W.S.
Gast
#2393679
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.