Hi, vermute mal das diese Frage nicht ganz neu ist. Ich habe mich jetzt ganz gut in die AVR mittels Bascom eingearbeitet, aber für Multimedia und Grafikausgabe auf Video, VGA und allem, sind die ja etwas rechenschwach. Ich habe mir auch schon oft Programme in C angeschaut und kam zu dem Ergebnis, dass ich lieber bei Basic bleibe. Zu Zeiten meiner Ausbildung bin ich bei Pascal eingestiegen, dann ging es weiter zu Windows-Programme proggen mit Delphi und heute ist es Bascom. Nun die große Frage, welcher 32 Bit Controllertyp wird auch gut in Basic unterstützt? Die ARM Controller, weiß ich dass es für diese auch Editoren in Basic gibt. In Spin für die neuen Propeller Chips, habe ich auch mal reingeschaut, finde aber dass dort schnell die Übersicht flöten geht. Gut an den Propeller-Chips ist hingegen, dass bis zu 8 Aufgaben zeitgleich abgearbeitet werden können. Und mir sind noch die die PIC32 Controller untergekommen, mit denen ich mich aber bisher noch nicht befasst habe. Wichtig ist auch, dass es, wie bei Bascom, viele Beiträge mit BeispielCode im Netz gibt und vielleicht auch das eine oder andere deutsche Buch dazu. Ich Danke Euch für Eure Meinung ;).
wenn du viele Beispiele willst nimm C oder C++, Basic ist ehr exotisch auf den 32bittern
Hallo, also Basic und 32 bit, dann solltest du eine x86 mit DOS und Basic Interpreter nehmen. Richtig mit einem 32bit uC arbeiten, da wirst du langfristig nicht um C drum rum kommen. Und es tut auch nicht weh, eine weitere Sprache zu lernen. Grüße aus Berlin
Mein Umstieg von 8bit-PIC und 8bit-Atmel auf 32bit erfolgte mit Atmel-32bit-SAM-Controllern und parallel dazu mit Analog Devices ADuC-Controllern. Das Atmel-32bit-SAM-Controller-Board verstaubt, den (und die vielen Nachfolger) ADuC verwende ich inzwischen wie eine 8bit-Atmel-CPU: simpel zu programmieren, leistungsfähig und schnell. Das liegt an der guten und übersichtlichen IDE und der einfachen Programmierung. Wie auch bei 8bit-Atmel. Die anderen 32bit- und ARM-Controller-Familien, die ich bisher benutzen mußte, waren deutlich schwieriger in Betrieb zu nehmen und sind nicht gerade einfach zu programmieren. Meine ganz persönlichen Erfahrungen. Für das "schnelle" und einfache nehme ich nach wie vor 8bit-Atmel und alles andere wird je nach spezieller Anforderung eben von einer anderen passenden Controller-Familie erledigt. Also ohne direkten "Engpaß" bei 8bit-Atmel oder anderen Zwang zum Umstieg würde ich nicht wechseln wollen. Bin doch kein Masochist. Blackbird
Juti, dann mache ich das mal. Hab ein ganz nettes C-Tutorial zum Anfang gefunden. http://www.c-programmieren.com/C-Lernen.html Werde das einfach mal Schritt für Schritt durchgehen. Auf die Art hatte ich damals auch recht schnell Bascom erlernt.
>Autor: Blackbird (Gast) >Das Atmel-32bit-SAM-Controller-Board verstaubt, Welches? Vielleicht könnte ich das ja bei dir "abstauben" :-)
So, ich habe mir inzwischen C schon erstmal angeschaut und wenn ich nicht alles auf einmal können will, sondern die Tutorials eins nach dem anderen abarbeite, dann sollte das auch alles kein Thema sein. Das C eine Art Universalsprache ist, für fast alle Controllerarten, ist auch klar. Nur eine Frage stellt sich mir gerade. Ein Programm für einen AtMega, kann ich dieses abgesehen von Änderung des Quarz und des Controllertyps fast 1:1 auch auf meinetwegen einem Arm übernehmen oder gibt es dafür dann wieder andere Compiler, welche unter Umständen wieder leicht andere Befehlssätze haben?
Stefan S. schrieb: > Ein Programm für einen > AtMega, kann ich dieses abgesehen von Änderung des Quarz und des > Controllertyps fast 1:1 auch auf meinetwegen einem Arm übernehmen Controller-Programme bestehen grob gesagt aus 2 Teilen. Ein Teil ist abhängig von der verbauten Interface-Hardware, Ports, Timer etc. Der andere Teil baut darauf auf. Der hardware-bezogene sieht bei jedem Hersteller völlig anders aus, auch innerhalb eines Herstellers können die Unterschiede gross sein. Bei ziemlich kleinen Programmen überwiegt der hardware-bezogene Teil. Je grösser es wird, desto geringer ist der Anteil, grob gesagt. Wenn du mit Migration eines Programms rechnen musst, dann achte darauf, den hardware-bezogenen Teil sauber vom Rest zu trennen und mit einer klaren hinreichend abstrakten Schnittstelle zu versehen.
Stefan S. schrieb: > Ein Programm für einen > AtMega, kann ich dieses abgesehen von Änderung des Quarz und des > Controllertyps fast 1:1 auch auf meinetwegen einem Arm übernehmen oder > gibt es dafür dann wieder andere Compiler, welche unter Umständen wieder > leicht andere Befehlssätze haben? Ja und nein. Also den Code der Programmlogik kannst du übernehmen die Ansteuerung der Controllerhardware (Pins, Timer, etc..) nicht. Deshalb fügt man bei Projekten die man leichter auf diversen Controllern laufen lassen will zusätzliche Abstraktionsebenen ein.
Alles klar. Also so wie üblich oben die Deklaration, am Besten den Ports auch Namen zugewiesen und erst danach das eigentliche Programm. Juti alles klar. Danke.
> gibt es dafür dann wieder andere Compiler, > welche unter Umständen wieder leicht andere Befehlssätze haben? Ja. C Programme sind immer nur für einen ganz bestimmten Chip compiliert. Wenn du einen anderen Chip nimmst, must Du das Programm zumindest neu compilieren. Oft unterscheiden sich auch die Peripherie-Funktionen. Der eine Chip hat vielleicht Port A, B und C, währen der andere nur Port B und C hat, dafür aber USB. Oder so. Das ist aber nicht eine Frage der Sprache. C ist standarisiert. ABgesehen von ein paar wenigen Erweiterungen, die Du nicht nutzen musst, unterstützt jeder C Compiler den Ansi Standard - also den gleichen Befehlssatz. Die meisten Compiler unterstützen viele Controller. Der avr-gcc unterstützt zum Beispiel alle AVR Mikrocontroller. Für PIC brauchst DU aber einen anderen Compiler. Und für ARM wiederum einen anderen, da kommst sogar auf die Marke an. ARM von STM ist nämlich nicht gleich ARM von Atmel oder Broadcom oder wer auch immer. Nichtmal innerhalb einer Marke ist ARM=ARM. Aber dazu gibts ja einen Grundlagenartikel in diesem Netz. Lies den mal.
Stefan S. schrieb: > Alles klar. Also so wie üblich oben die Deklaration, am Besten den Ports > auch Namen zugewiesen Auch, aber das wär zu einfach. Du wirst dann nämlich feststellen, dass sich deine Pins völlig anders auf die Ports verteilen, und dass die Art, Pins anzusprechend, bei AVRs und ARMs ziemlich anders aussieht. So setzt man beispielsweise bei AVRs Pins traditionell mit PORTx |= Maske; während man es bei ARMs oft mit PORTxSET = Maske; macht. Ausserdem funktionieren Timer, UARTs, SPIs recht unterschiedlich. Einfaches Defines tun es da nicht. Eine UART beispielsweise bildet man auf Funktionebene ab, d.h. man baut als Abstraktionsebene Funktionen wie UartInit, UartReceive, UartTransmit
> am Besten den Ports auch Namen zugewiesen und erst > danach das eigentliche Programm. Das ist zu einfach gedacht. Bei ATtiny hat jeder Port ein Rgeister, um die Richtung (in/out) festzulegen, und die Inputs haben optional Pull-Up Widerstände. Bei ATxmega hast Du wesentlich mehr features. Da werden die Ports ganz anders initialisiert. Selbst der Zugriff aufPorts ist je nach Mikrocontroller Serie anders. Manche haben z.B. ein Register sowohl für Input als auch für Output: PORTA=3; a=PORT3; Andere haben dazu separate Register, etwa so: PORTA.OUT=3; a=PORTA.IN; Die Abstraktion sollte daher noch etwas weiter gehen. Zum Beispiel, um LED's zu schalten würde ich Makros oder Funktionen definieren wie Led_rot_an() und Led_rot_aus(). Oder Lese_Taste(), Init_serial_Port(), Sende_Seriell('x'), y=E,pfange_Seriell(); Das müsste Dir aus der Bascom Welt schon bekannt vorkommen.
Das Dumme an solchen Abstraktionen ist, dass es bei deren Festlegung ungemein hilft, wenn man bereits eine gewisse Übersicht über verschiedene Hardware hat. Also Erfahrung. Um zu wissen, wo man sie ansetzt, um sich einerseits keinen Weg zu verbauen, aber sich andererseits das Leben nicht unnötig schwer zu machen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.