Hallo,
immer wieder lese ich, es macht teilweise nicht mehr unbedingt Sinn, auf
AVRs setzen. Habe aber bislang ausschließlich seit ca 2Jahren mit AVRs
im Hobbybereich gearbeitet. Nun wollte ich mal die andere Seite sehen,
aber naja, irgendwie weiß ich überhaupt nicht, wo ich anfangen soll.
Bislang kenne ich nur avr-gcc.
Damit kam ich weitesgehend ganz gut klar, dank an das Tutorial. Aber bei
dem ARMs sehe ich nun den Wald vor lauter Bäumen nicht mehr.
Ich habe mir für den Start dieses Teil besorgt.
http://www.ebay.de/itm/STM32F0-DISCOVERY-USB-STM32F051R8T6-STM32-ARM-Cortex-M0-Development-Board-/161288388361?pt=Mess_Pr%C3%BCftechnik&hash=item258d897f09
Nun ging es daran, die Software auszusuchen. Bin nun bei der CooCoxIDE
(1.7.7) gelandet. Mit der V2 kam ich nicht klar, da auch die Tutorials
weitesgehend auf die 1er ausgelegt waren und gerade für die Erstellung
eines neuen Projektes sich doch sehr stark geändert hat.
Geschmacklich bin ich noch nicht so überzeugt, wird aber vielleicht noch
kommen. Fand das Atmel Studio aber doch deutlich besser. (Bevorzuge
Visual Studio vor Eclipse).
Die ganzen Initilaisierungen der Ports sind in meinen Augen grundlegend
verschieden.
Gibt es irgendwo ein gutes Tutorial, was man ab arbeiten kann, bei dem
man mal Grundlegend die neue Technik bzgl. Taster einlesen oder Led
setzen lernt?
Hi,
also im Unterschied zum AVR solltest Du dringlichst die vorgegebenen
Initialisierungsroutinen benutzen um die Clocks etc. einzustellen.
Im Gegensatz zum AVR wird das NICHT per Fuses geregelt, sondern durch
die Software zur Laufzeit.
Nach dem Reset erhält die MPU erstmal den Takt vom internen
RC-Oszillator.
Alle weitere Peripherie muss explizit aktiviert werden.
Ansonsten kannst Du die Hardware entweder über die CMSIS
Peripherie-Library programmieren (mit Strukturen und Funktionen) oder
unter Zuhilfenahme der Definitionen im CMSIS direkt auf die
Hardwareregister zugreifen, was dann identisch zum AVR ist.
Es gibt keine spezielle Trennung der Behandlung von Daten und Code (zum
Glück!). D.h. Du kannst in einem C-Programm einfach konstante Daten im
Flash ablegen und per normalem C-Code darauf zugreifen.
Viel Spass!
Mit der CooIDE 2beta komme ich auch nicht klar.
Du kannst Dir auch mal em::Blocks anschauen, das ist etwas kompakter und
auch etwas fixer (meiner Meinung nach).
Basiert ebenfalls auf der GCC Toolchain.
Auf dem Discovery Board hast Du zum einen den ST-Link/V2, also die
Debugging und Programmier-Schnittstelle, und auch eine zweite MPU für
Deine Applikationen. Im Auslieferungszustand sind beide verbunden, Du
kannst aber die Verbindung auftrennen und dann den ST-Link mit Deinen
eigenen Boards verbinden.
Du kannst den ST-Link direkt mit den ST-Link Tool ansprechen (und auf
die aktuelle Version updaten).
CoIDE oder em::Blocks bringen dazu eigene Tools mit die den ST-Link/V2
ansprechen können, bzw. integrieren diese mit dem GDB.
Simon K. schrieb:> immer wieder lese ich, es macht teilweise nicht mehr unbedingt Sinn, auf> AVRs setzen.
Verstehe...
Dafür:
>...... die neue Technik bzgl. Taster einlesen oder Led>setzen lernt?
sind sie sicher zu unterdimensioniert.
By the way... von Atmel gibts nicht nur Tiny's und Mega's, sondern auch
Xmega's und 32Bit Prozessoren sowie ARM Architekturen. Die sind genau so
schön verwirrend was die Peripherie anbetrifft und für Erwachsene Jungs.
Und dass allerbeste ist, man kann das AVR Studio weiter benutzen.
Ja, das stimmt natürlich. Das ist letztendlich eine Frage des eigenen
Gustos, welchem Hersteller man den Vorzug gibt.
Daher kann es sinnvoll sein, sich zunächst die verfügbaren Controller
der Hersteller (NXP, ST, Atmel, ...) und auch die Doku anzusehen.
Der XMega ist nett, hat aber leider viele Limitationen aufgrund der
8/16-Bit Herkunft. Das würde ich mir nicht mehr antun wollen. Ist aber
OT :)
Thomas Holmes schrieb:> von Atmel gibts
... kein kleines günstiges Evalboard mit Debugger gleich drauf, wie bei
den anderen.
Thomas Holmes schrieb:> man kann das AVR Studio weiter benutzen
Das bezweifel ich, du benötigst mind. das Atmel Studio. ;-)
Hast du überhaupt schon einmal einen ARM programmiert?
STM32 oder LPC sind ein guter Anfang. Tutorials wurden verlinkt, auf
geht 's!
Werde mal die Tage den AT91SAM3X8E (Due) und ATSAMD21G18 (Zero)
rumliegen, die ich aber lediglich für Testzwecke ein paar mal mit der
Arduino Software getestet habe. Boards währen beide zu groß und der Due
einfach Oversized für meine Projekte. Oben wurde etwas geschrieben bzgl.
Led und Taster, dass die STM schon zu groß sind. So war das nicht
gemeint. Mir geht es darum, langsam einzuarbeiten.
Atmel scheint inzwischen ja auch ein paar günstigere MCUs rausgebracht
zu haben ~2€. CodeBlocks ist auch nicht das Wahre womit ich mich
anfreunden kann derzeit. Bin halt doch sehr auf das Atmel Studio bislang
fixiert gewesen, auch wenn es nur Windows support hat.
Simon K. schrieb:> immer wieder lese ich, es macht teilweise nicht mehr unbedingt Sinn, auf> AVRs setzen.
Solange man das was man mit den AVRs macht oder zu machen gedenkt
problemlos mit selbigen umsetzen kann gibt es nichts was solcherlei Tun
aus heiterem Himmel plötzlich die Sinnhaftigkeit rauben könnte.
Markus M. schrieb:> Der XMega ist nett, hat aber leider viele Limitationen aufgrund der> 8/16-Bit Herkunft. Das würde ich mir nicht mehr antun wollen. Ist aber> OT :)
Der STM32 ist nett, hat aber leider sehr viele komplexe
Konfigurationsmöglichkeiten aufgrund der 32-Bit Herkunft. Das würde ich
mir für die allermeisten Steuerungsprojekte nicht antun wollen. Ist aber
OT :)
>Solange man das was man mit den AVRs macht oder zu machen gedenkt>problemlos mit selbigen umsetzen kann gibt es nichts was solcherlei Tun>aus heiterem Himmel plötzlich die Sinnhaftigkeit rauben könnte.
Wahr schon klar das dieses sinnlose Geschwafel hier wieder auftaucht.
holger schrieb:> sinnlose Geschwafel
Tja Holger, besser dieses "sinnlose Geschwafel" im Vorfeld als ggf. viel
sinnlos verpulverte Zeit, Geld und Nerven für die ARM-Umsetzung von
Projekten, die auch ein einfacher AVR nebenbei erledigt. ;-)
nana...
Es geht hier nicht um den Glaubenkrieg AVR vs PIC vs ARM vs .....
Habe mit den meisten AVR Familien bereits gearbeitet, AttinyX5, X4,
AttinyX41, Attiny2313, mega1284p, mega2560, mega328, ....
Die sind in ihrem Bereich für mich Spitze. Doch möchte ich auch mal die
andere Seite vom Teich (ARM) sehen und zumindest die Grundlegenden
Basics verstehen um auf Dauer die für mich bessere Hobbylösung
herauszufinden.
@ Simon K. (Gast)
>andere Seite vom Teich (ARM) sehen und zumindest die Grundlegenden>Basics verstehen um auf Dauer die für mich bessere Hobbylösung>herauszufinden.
Das ist die, die dir Spaß macht. Egal ob man mit Kanonen auf Spatzen
schießt oder nicht.
holger schrieb:> Und der Moby mischt sich auch schon wieder da ein> wo er nichts zu suchen, geschweige denn was> sinnvolles zum Thema zu sagen hat.
Das hat der Mobby nie. Weder hier noch hat man ihn je in einem AVR
Thread mit Hilfreichem lesen können. Er ist einfach ein frustrierter
Dummschwätzer. Frustriert, weil die Gemeinde weiter zieht und er ...
Jedes Forum hat seinen Troll. Wir haben unseren Mobby. Wer ihn ernst
nimmt ist selber schuld. ;-)))
Moby schrieb:> hat aber leider sehr viele komplexe> Konfigurationsmöglichkeiten aufgrund der 32-Bit Herkunft
??? Muss man nicht verstehen, oder?
Vor lauter Angst schalte ich jetzt meinen 64 Bit PC sofort aus. Ist
einfach viel zu komplex. ;-)))
Falk Brunner schrieb:> Das ist die, die dir Spaß macht.
Der schaut dann genau so aus:
Simon K. schrieb:> Aber bei> den ARMs sehe ich nun den Wald vor lauter Bäumen nicht mehr.
;-)
