Nachdem ich mich schon seit einiger Zeit mit AVRs beschäftigte, möchte
ich mich auf privater Basis in ARM Controller einarbeiten.
Im Gegensatz zu den AVRs bin ich aber noch komplett überfordert mit den
Möglichkeiten. Daher die konkrete Fragen:
1) Was ist ein preiswertes Einsteiger-Evaluation Board?
Ich habe an das https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/
gedacht oder https://www.olimex.com/Products/ARM/Atmel/SAM3-P256/
2) allerdings ist mir nicht klar, welches ICE ich dann dazu benötige.
Olimex hat ja den
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-COOCOX/, welcher
angeblich mit dem CooCox CoIDE harmoniert...
3) Ein IDE mit Debuggingmöglichkeit (Breakpoints, etc,...) möchte ich
schon verwenden, ich habe eben dieses CooCox als Freeware gesehen. Dann
gäbe es ja auch das ATMEL Studio, welches aber wiederum nicht alle SAM
Modelle unterstützt...
Ich hätte am liebsten etwas, das zusammenpasst; ungern würde ich mir ein
Board kaufen, zu dem ich dann keinen einwandfrei funktionierenden ICE
finde...
Also:
* preisgünstig **lach **
* IDE + Toolchain
* es soll funktionieren, und nicht frustrieren (insbesondere der ICE)
Danke !
ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder
STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST
Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.
ARM Einsteiger schrieb im Beitrag #3151466:
> * es soll funktionieren, und nicht frustrieren (insbesondere der ICE)
Dann darfst du dir ARM nicht nehmen. AVR ist ein Witz dagegen. Sind halt
32bit und da ist alles einen ordentlichen Haken komplexer. Dafür hast
halt Möglichkeiten und Power ohne Ende. Wie gesagt kein Vergleich mit
8bit aber einfach nur geil. Nach ner Woche bist gut drin. Wenn du mit
AVR Probleme hast dann würde ich das aber eher vergessen.
AVR 8bit = kleines Einmaleins
ARM 32bit Cortex M3,M4 = rechnen mit komplexen Zahlen
Linüx schrieb:> AVR ist ein Witz dagegen.
Weiß ich ;-)
Jedoch will ich es lernen, da ARM Controller in Firmen sehr verbreitet
sind.
Mit den AVRs hab ich ja übrigens kein (echtes) Problem.
Mit "es soll funktionieren und nicht frustrieren" meinte ich weniger die
Lernhürde, sondern die Qualität der Entwicklungstools, inclusive ICE.
Wenn ich nicht zuverlässig debuggen kann, hat es keinen Sinn. Mit printf
Ausgaben wird man bei dem Kaliber nicht weit kommen...
ARM Einsteiger schrieb im Beitrag #3151466:
> Nachdem ich mich schon seit einiger Zeit mit AVRs beschäftigte, möchte> ich mich auf privater Basis in ARM Controller einarbeiten.>> Im Gegensatz zu den AVRs bin ich aber noch komplett überfordert mit den> Möglichkeiten. Daher die konkrete Fragen:>> 1) Was ist ein preiswertes Einsteiger-Evaluation Board?> Ich habe an das https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/> gedacht oder https://www.olimex.com/Products/ARM/Atmel/SAM3-P256/ARM ist nicht gleich ARM. Die alten ARM7-Teile solltest Du da lassen, wo
sie sind: beim Händler. Die neueren Cortex M0/M3/M4 sind
leistungsfähiger und gleichzeitig einfacher zu handhaben.
Die Debugschnittstelle ist bei allen Cortex M standardisiert. Diese
haben zum einen das althergebrachte JTAG sowie das neuere SWD, das
deutlich weniger Pins braucht. Nimm eine Debug Probe, die auch SWD kann,
auch wenn das dann etwas teurer wird. (zB Segger J-Link)
Und: Du darfst nicht davon ausgehen, dass Du Software für Controller A
so problemlos auf Controller B portiert bekommst. Der CPU-Kern ist immer
der gleiche, der Interrupt-Controller auch, aber der gesamte Rest an
Peripherie ist von Hersteller zu Hersteller völlig anders. Die
Unterschiede sind ähnlich groß wie zwischen AVR und PIC. So viel zum
Thema Herstellerneutralität.
> * preisgünstig **lach **> * IDE + Toolchain> * es soll funktionieren, und nicht frustrieren (insbesondere der ICE)
Ei ei ei, das sind ja schon drei Wünsche auf einmal. Keil MDK plus
ULINK2 plus irgendein Keil Demoboard funktioniert garantiert, und der
Keil/ARM Compiler erzeugt zweifelsohne hervorragenden Code (Keil gehört
zu ARM), aber preisgünstig geht anders.
fchk
Linüx schrieb:> AVR 8bit = kleines Einmaleins> ARM 32bit Cortex M3,M4 = rechnen mit komplexen Zahlen
Uaaah, "rechnen mit komplexen Zahlen" - meine Güte, da bekomme ich aber
Angst, dass ist ja sooooooooo schwer!
Echt Kollege, wenn man im vierten Semester mal Funktionentheorie hatte,
dann ist das "rechnen mit komplexen Zahlen" das kleine Einmaleins -
also, wie schon Einstein feststellte: "alles relativ".
Auch ARM ist kein Buch mit 7 Siegeln.
Linüx schrieb:> ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder> STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST> Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.
und wo kann man das beziehen?
Gibt es andere Erfahrungsträger mit diesen Boards?
ARM Einsteiger schrieb im Beitrag #3151513:
> Linüx schrieb:>> ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder>> STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST>> Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.>> und wo kann man das beziehen?> Gibt es andere Erfahrungsträger mit diesen Boards?
Embedded World, kaeuflich z.B. bei Watterott
Wenn du Erfahrungstraeger suchst bemueh doch mal die Forumssuche.
Teilweise gibt es auch hilfreiche Artikel in der Artikelsammlung.
Zu erwaehnen waeren auch noch die LPCXpresso Boards - sind aehnlich nur
hald mit NXP Controllern.
Gruss
Ich habe das STM32VL Discovery Board mit der Attolic True Studio IDE
Freeware (begrenzt auf 32 Byte Code) im Einsatz und bin sehr zufrieden
damit.
Beziehen kann man die Boards bei Franell, RS, direkt bei ST oder auf
Messen.
Viel Spaß beim Einstieg in ARM.
Es lohnt sich auf jedenfall und macht richtig viel Spaß
>Ich habe das STM32VL Discovery Board mit der Attolic True Studio IDE>Freeware (begrenzt auf 32 Byte Code) im Einsatz und bin sehr zufrieden>damit.
Das sollte wohl 32kB Code heissen;)
Und was ist wenn du mehr als 32kB Code hast?
IDE wechseln oder den teuren Kram kaufen?
Im Prinzip also Zeitverschwendung.
Ich debugge immer noch bevorzugt über printf.
Bei Langzeittests bleibt auch kaum was anderes übrig.
Oder wenn eine USB Verbindung im Spiel ist, dann
meldet sich das Teil am USB ab wenn man an einem
Breakpoint anhält. Der Host bekommt dann ja auch keine
Antwort mehr. Debugger werden oft hoffnungslos überschätzt.
Es gibt Dinge die man per JTAG nicht debuggen kann weil
sonst die externe Hardware abdreht.
W.S. schrieb im Beitrag #3151556:
> Bloß drauf warten, daß die gebratenen> Tauben dir in den offenen Mund fliegen?
Sehr hilfreich sind solche Aussagen nicht. Wie bist du denn
eingestiegen? Oder hast du das ARM Wissen mit der Muttermilch
aufgesogen. Nicht bös sein, aber du bist schon sehr "überheblich", mit
dem was du da schreibst.
Ich mochte eine vernünftige und bereits erprobte Lösung im Zusammenspiel
von Board und Programmier/Debug Adapter und nicht erst 500€ ausgeben,
bevor ich draufkomme dass es nicht funktioniert.
Ich habe in der Urzeit angefangen mit AVR + STK200. Mit Studio-Assembler
und und heute mit Bascom.
Meine erste ARM Erfahrungen habe ich gemacht mit MbedLPC1768, es ist bis
heute die beste Mbed. Das schwerste für mich ist C/C++ zu lernen. Mbed
(Merkmal ist der Online-Compiler) hat viele sofort laufende Programme.
Mann kann auch ganz einfach von der Online-Compiler aus Programme
exportieren nach Keil (zur nutzung der CMSIS-debugger) oder Codered.
Du brauchst eigentlich kein weitere Hardware, ausser vielleicht ein
Steckbrett um mit LCD oder anderes Spielzeug zu experimentieren.
Ich kann MbedLPC1768 empfehlen als ARM-lernsystem für AVR-erfahrene
Leute.
Das Modul ist nicht gerade billig, aber komplett, kompakt und
ausgereift. Kommt mit viele Softwarebeispiele, und es gibt eine
hilfreiche Forum/Community.
(Es gibt auch noch andere billige Mbed Module.)
Und die Software/Programmierumgebung funktioniert einfach!
holger schrieb:> Das sollte wohl 32kB Code heissen;)> Und was ist wenn du mehr als 32kB Code hast?> IDE wechseln oder den teuren Kram kaufen?
Welche uC SW braucht mehr als 32k? Und Daten oder Bilder kann man direkt
flashen. Allerdings hatte ich kürzlich tatsächlich eine LCD-Touch-Demo
für LPC1788, da war alles im main mit so 60k, sowas trenne ich aber
schon aus Prinzip in User Code und Library.
holger schrieb:> Debugger werden oft hoffnungslos überschätzt.> Es gibt Dinge die man per JTAG nicht debuggen kann weil> sonst die externe Hardware abdreht.
Es könnte natürlich auch sein, dass du Debugger hoffnungslos
unterschätzt!
Ich arbeite mit einem STM32F4..discovery board und der IDE CrossStudio
für Arm von Rowley. Die gibt es relativ preisgünstig für Hobbyisten.
Gibt dafür zwar nicht so viele fertige Beispielprojekte, aber wenn man
die Starthürden überwunden hat, ist die IDE sehr komfortabel.
CooCox verwende ich manchmal alternativ dazu, ist nicht ganz so
komfortabel wie CrossStudio, aber dafür kostenlos und funktioniert auch.
Ich schildere mal kurz meine subjektive Sicht:
Ich war in ner ähnliche Situation wie du, mit AVR+PIC hab ich jeweils ne
handvoll Projekte hinbekommen, hatte aber Null Ahnung von ARM. Ich hab
nen Arduino DUE (SAM3X8E mit 84MHz, Cortex M3, Watterott::46EUR) gekauft
- DUE deshalb, weil es der gleiche uC wie auf den Atmel-Eval-Boards ist.
Für Routinekram wie Upload hab ich dann noch AVR-Studio angepasst.
Wenn man nicht gerade wildes Zeug wie Bilderkennung + Kalman-Filter
programmiert, liegt das Prob mMn nicht in der Komplexität des
Rechenkerns M3 (das macht nach wie vor alles gcc, g++ or whatever)
sondern fast Ausschließlich in der Anpassung des Codes an die knackige
Peripherie. Die Timer-Module zB. sind erheblich komplexer als 'früher',
und auch schon ein sauberes "Hello World" mit Timer-Isr anstatt
NOP-Einschieben bei 84MHz erfordert viel Nachlesen. In der Atmel-ASF hat
es viele gute Code-Beispiele die zT. sofort oder mit ein bisschen
Anpassung laufen.
Und printf ist jetzt auch nicht soooo schlimm. Als Anfänger zwicken dich
da ganz andere Dinge. Im grunde genommen hat JTag nur einen Vorteil:
Zeitersparnis. Gemessen am Gesamt-Zeitaufwand für ein Projekt ist er
aber gering.
Und es stimmt was ein Vorredner schrieb: Diese dicken Biester machen
wirklich einen Heidenspaß.
Der vermutlich preiswerteste Einstieg ist immer noch das
STM32F4Discovery Board. Ich hab mir 2 von den STM32VLDiscovery Boards
mit dem F1 zugelegt, der F4 ist aber dagegen viel leistungsfähiger und
kostet genauso wenig. Ausserdem hat das Board mit den Digital Audio
Komponenten eine spassige Peripherie dabei, die mal interessant werden
kann.
Ich verwende im Moment die letzte unbegrenzte Version von Atollic
(mittlerweile ist die ja auch begrenzt oder teuer), werde aber bald mal
CooCox probieren, angeblich ist dort alles mittlerweile ohne Haare
raufen zu installieren.
Lediglich die Dokumentation von STM zu den MC ist unübersichtlich und
man muss die meisten Abschnitte über Timer usw. mindestens dreimal
lesen.
Du brauchst sonst nur ST-Link V2 von STM zum flashen des Boards und
kannst sofort loslegen.
@ARM Einsteiger
Lese am besten den Artikel: STM32
Da steht über alles mögliche drin, auch Bezugsquellen und
Entwicklungsumgebungen und Tipps für Umsteiger.
STM32F4DISCOVERY ist auch meine Empfehlung. Alles drin und dran und
kostet nur 12..20 EUR.
Wenn Du später mehr machst und eigene Boards baust, dann empfehle ich
den J-LINK EDU von Segger als JTAG Adapter (ist einfach verdammt
schnell). Man kann aber auch den vom Discovery Board mit anderen eigenen
Boards verwenden.
>Linüx schrieb:>> AVR ist ein Witz dagegen.
Ja, ja, wer bei einem AVR die Doku nicht liest wird den auch nie
programmieren können. Somit: wer lesen kann ist klar im Vorteil und der
STM32 hat nun mal ein paar Seiten mehr. Es gibt jede Menge
Code-Beispiele von ST und im WWW.
Dass der STM32 jetzt so viel schwerer ist kann ich beim besten willen
nicht nachvollziehen. Meist gibt es die Lösung mit ein wenig Suchen bei
Google auf dem Silbertablett serviert.
Markus Müller schrieb:> STM32F4DISCOVERY ist auch meine Empfehlung.
Hab das Ding nun bestellt. 15€ inklusive integriertem ICE ist
unschlagbar. Ich hoffe es funktioniert wirklich so gut, wie alle sagen.
Danke für die Entscheidungshilfe ;-)
Hallo zusammen,
das ging ja schnell - ich habe das STM32F4 Discovery Board schon am
Tisch liegen und bereits die CooCox IDE samt ARM-GCC installiert.
Ein Beispielprogramm "blinky" konnte ich bereits erfolgreich übersetzen
und laden.
Im Gegensatz zur AVR Welt ist mir aber noch nicht so ganz klar, wo man
sich die C-Umgebung zusammensucht bzw. darin zurechtfindet. Bei AVR war
es sehr überschaubar und kompakt, jetzt sehe ich den Wald vor lauter
Bäumen nicht. Daher die Frage:
* wo finde ich die Header Files und Macros, um auf Register zuzugreifen
oder tut man das nicht, sondern
* geht über Standard libraries (zB STM32F40xx/41xx/427x/437x DSP and
Standard Peripherals Library
Kurz gesagt: wo lerne ich, wie man praktisch programmiert?
Die CoIDE erstellt viel automatisch generierten Code (Handler, etc,
...), aber wo finde ich das dokumentiert?
Danke!
Ich komme zum Schluss, dass die STM Library von ST wohl nur für Leute
geeignet ist, die auch bei ST arbeiten ...
Ich habe nur mal versucht, zu verstehen, wie die System Clock
eingestellt wird:
* In der "blinky" Anwendung Beitrag "CooCox CoIDE mit STM32F4-Discovery Board"
wird auf die Compileroption -DHSE_VALUE verwiesen, und dass das richtig
eingestellt sein muss. Diese wird aber nirgends verwendet; ändere ich
den Wert, blinken die LEDS genau so wie vorher. --? wozu gibt es das
dann??
* Es gibt zwar eine Funktion SetSysClock, die aber unzureichend
dokumentiert ist. Sicher kann ich nun nachsehen, was da im Detail
passiert und die Zeilen, wo auf Register geschrieben wird entsprechend
anpassen. Dann brauche ich aber keine Library, sondern kann gleich alles
selbst machen. Ich würde mir eine Funktion erwarten, der ich sage, wie
die Frequenz des externen Oszilators ist, welche Taktfrequenz ich
letztlich haben möchte, usw. und erwarte mir dann, dass die PLL
Einstellung richtig vorgenommen wird. So eine Funktion habe ich nicht
gefunden - oder hab ich etwas übersehen?
* Es kann ja nicht sein, dass man sein ganzes Wissen nur aus unendlich
vielen Beispielen im Web zusammendröselt; das mag zwar funktionieren,
ist aber nicht die Vorgehensweise, die ich als Entwickler gewohnt bin.
So gibt es die gut gemeinte Seite
http://diller-technologies.de/stm32.html die mir aber nicht wirklich
weiterhilft, da hier nur Beispiele gezeigt werden, ohne zu sagen, woher
der utor seinerseits die Infos bekommen hat.
DIE FRAGE:
Wie geht es den anderen? Wie kann ich mich systematisch in die Materie
einarbeiten, ohne nur mit Beispielen zu arbeiten, die ich mir irgendwo
zusammensuche? Bitte jetzt nicht sagen "du möchtest alles am goldenen
Servierteller bekommen", etc, ich bin nur nicht gewillt, eine
umfangreiche Library ohne jegliche brauchbare Doku hinzumehmen...
Linüx schrieb:> AVR 8bit = kleines Einmaleins
und was ist mit AVR 32 bit? Die gibt es ja auch. Um zwei Sachen
miteinander zu vergleichen darf man nur einen Parameter ändern,
Architektur oder Anzahl der bits (wie nennt man das richtig?)
Hi ARM Einsteiger,
es ist einfach so, das der ARM um ein vielfaches komplexer ist,
als z.B. ein ATMega128
ich versuche mir zu jedem Thema (bei dir jetzt z.B. der Sysclock)
das Kapitel vom Referenz-Manual durchzulesen (auch wenn es noch so lang
ist)
das gibt dann zumindest einen Einblick wie, wo, was zusammenhängt
und "warum" die Beispiele von STM so sind, wie sie sind
aber sei beruhigt, du bist nicht der einzigste der
damit probleme hat (mir geht es genauso)
P.S. die CoIDE zeigt dir zu jedem Modul (z.B. GPIO)
vom C-File auf der rechten Seite alle Funktionen an,
die man benutzen kann und da steht meist auch ein Text
dabei welche Parameter die Funktionen erwarten
Gruss Uwe
Daniel schrieb:> und was ist mit AVR 32 bit? Die gibt es ja auch.
und was willst du nun damit sagen? Meine Frage bezog sich nicht auf AVR,
weder auf 8, noch 32 Bit...
Hallo,
mache Dich doch mal bei IAR schlau.
Die Entwicklungsumgebung ist sehr gut, unterstützt viele verschiedene
Hersteller von Prozessoren und deren Typen.
Früher hatten die auch mal Eval-Boards mit im Angebot.
Ich arbeite seit Jahren mit damit, hatte früher mit Keil und Realview
gearbeitet - die aber - meiner Meinung nach - nicht so komfortabel waren
wie IAR.
Uwe B. schrieb:> es ist einfach so, das der ARM um ein vielfaches komplexer ist, als z.B. ein
ATMega128
Immer dasselbe ... Auf dem ARM nur mit den Registern eine LED blinken zu
lassen ist total banal:
int main (void)
{
FIO1DIR_bit.P1_25 = 1; // output on pin 1.25
while(1)
{
FIO1PIN_bit.P1_25 ^= 1; // toggle pin 1.25
Delay(100000);
}
return 0;
}
void Delay(volatile unsigned long i) { while (i!=0) i--; }
Und ja, es ist natürlich empfehlenswert, die CMSIS Library zu nutzen,
damit der Code nicht portiert werden muss, aber diese Funktionen machen
auch nichts anderes.
Tutorial für den STM Einstieg z.B.:
http://www.hitex.com/index.php?id=download-insiders-guides
>ist total banal:
bei einem GPIO zugriff geb ich dir recht
aber ich dachte da eher an die Clock-Logik
oder die Benutzung vom DMA
(wobei es den beim ATMega ja gar nicht gibt)
oder z.B. die Interrupt-Programmierung
(im Vergleich zum ATMega)
mann muss sich wie gesagt erst mal einlesen
ist ja aber im Grunde bei jeder CPU so.
Hallo,
tut mir leid das ich den Thread mal kurz missbrauche, aber kennt jemand
gute ARM tutorials in Englisch? Am besten solche für STM Controller, das
höchste der Gefühle wäre natürlich wenn es auf das STM 23F100 Discovery
abgestimmt wäre. Das vom vorletzten Post sehe ich mir noch an.
Grüsse,
pawi777
Uwe B. schrieb:> Interrupt-Programmierung (im Vergleich zum ATMega)
Auch kein Problem: der Compiler definiert ja eine Vektortabelle, da
steht dann z.B. DCD TMR0_IRQHandler, also mache ich eine Funktion die
genau so heisst:
void TMR0_IRQHandler(void)
{
FIO1PIN_bit.P1_25 ^= 1; // toggle
T0IR_bit.MR0INT = 1; // clear pending irq in timer
NVIC_ClrPend(NVIC_TIMER0); // clear pending irq in queue
}
Zum Löschen des Interrupts wird hier eine CMSIS Funktion verwendet, weil
man ansonsten nachsehen müsste, welches Bit zum Timer 0 Interrupt
gehört, und das dann im CLRPEND Register setzen müsste.
DMA ist auch nicht anders: ich sage ich möchte den einen Speicherbereich
in den anderen kopiert haben, z.B. USB FIFO ins RAM, dann macht der das,
und wenn fertig gibt es einen Interrupt: DCD GPDMA_IRQHandler
Die Clock ist tatsächlich ein Kapitel für sich, aber üblicherweise macht
man es so: entweder reicht der interne RC-Oszillator (meist 12 MHz),
dann macht man gar nichts. Oder man ruft das CMSIS System_Init() auf,
dann bekommt man einen für den Chip üblichen Takt (z.B. 96 MHz) und noch
den USB Takt (48 MHz). Wenn man jetzt eine UART Baudrate braucht, die
genau damit nicht erreichbar ist, gibt es für jeden Chip ein Excel-Sheet
zum Download, wo man die Baudrate einträgt, und dann wirft es die ganzen
PLL Register raus. Die meisten Chips haben mehere PLL, das heisst man
lässt den CPU und USB Takt sein, und nimmt PLL1 für die krumme Baudrate.
Vielen Dank für die guten Tipps!
Ich habe mich bereits etwas eingearbeitet und komme mit dem Coox IDE gut
zurecht. Es funktioniert wirklich (bis jetzt zumindest...) einwandfrei.
Die CMSIS Library von ST ist zwar nicht wirklich gut dokumentiert, aber
zusammen mit dem Reference Manual bleibt eigentlich kein Geheimnis
offen.
Ich muss zugeben, dass die Ref etwas umfangreicher ausfällt als bei
8-Bit AVRs, aber es ist auch kein "Buch mit sieben Siegeln": Der
Cortex-4 kann halt wirklich einiges, was ich mir von einer MCU nicht
hätte träumen lassen, und das muss natürlich auch alles in die Doku
rein...
Wenn ich denke, was ich vor ein paar Jahren für einen Olimex Atmega32 +
JTAG ICE ausgegeben habe, und was mich das Discovery Board gekostet hat
(23€ incl. Versandkosten), ... Letzteres ist wirklich super, alles
funktioniert soweit, das Laden und Debuggen funktionierte auf Anhieb und
einwandfrei, ... all dies konnte ich vom damaligen AVR Studio 4 nicht
behaupten!
Das Tutorial
http://www.hitex.com/index.php?id=download-insiders-guides
ist übrigens fast der perfekte Einstieg, bevor man die Details im
Refence Manual nachliest. Danke für den Tip!
N'Abend "Arm Einsteiger"!
Bei Coocox gibt es noch n Add-On namens "CoSmart" damit kann man die
diversen Funktionen pro Pin einfach zuweisen.
Die Unterstützung für die STM's wurde zwar für April angedroht, aber bis
jetzt steht's noch aus. (Bei ner komplett kostenlosen IDE will ich aber
nicht maulen!) Wenn die STM's unterstützt werden, ist eine große Hürde
genommen, weil CoSmart dann den kompletten Start-Up-Code generiert.
Also immer mal bei CoSmart reinschauen.
Gruss - xileH
ARM Einsteiger schrieb im Beitrag #3151565:
> Sehr hilfreich sind solche Aussagen nicht. Wie bist du denn> eingestiegen? Oder hast du das ARM Wissen mit der Muttermilch> aufgesogen. Nicht bös sein, aber du bist schon sehr "überheblich", mit> dem was du da schreibst.
Du irrst dich auch hier - und das gleich mehrere Male.
Zunächst denke ich, daß ein paar deutliche Worte zumindest für dich
sehr hilfreich sind. Wenn ich die letzten Beiträge hier lese, bestätigt
mich das. Der Ansatz der Coocox-IDE ist ja ganz nett, aber bedenke, daß
du dort zu einem erheblichen Teil quasi blindlings den Code benutzt, den
Andere zur Verwendung in genau dieser IDE geschrieben haben. Für mich
ist das wie das Spielen mit Bauklötzern.
Als nächstes sei dir gesagt, daß man das "ARM-Wissen" durch Lesen und
selber Machen erwirbt - ganz ohne Muttermilch. Und zu dem "Machen"
gehört bei uC's eben auch Hardware-Entwicklung, denn ein uC ist (anders
als ein PC) kein Selbstzweck, sondern ein Teil einer
Maschine/Gerät/Apparat, kurzum er hat eine Funktion zu erfüllen, die
außerhalb des uC liegt.
Obendrein bin ich nicht überheblich, sondern nur offen und präzise.
Aber ich verstehe es schon, daß du dir in deinem zu hoch angesetzten
Selbsgefühl gekränkt vorkommst. Ich meine das aber bitterernst. Wir
haben in der Szene schon genug Leute, die sich großartig vorkommen, bloß
weil sie es gelernt haben, in einer bestimmten IDE die richtigen Knöpfe
zu drücken. Aber das ist noch nicht das Fachwissen, was den Könner
ausmacht. Nochmal mein extrem ernster Rat: werde gründlich oder laß es
bleiben.
ARM Einsteiger schrieb im Beitrag #3156635:
> Wie geht es den anderen? Wie kann ich mich systematisch in die Materie> einarbeiten, ohne nur mit Beispielen zu arbeiten, die ich mir irgendwo> zusammensuche? Bitte jetzt nicht sagen "du möchtest alles am goldenen> Servierteller bekommen", etc, ich bin nur nicht gewillt, eine> umfangreiche Library ohne jegliche brauchbare Doku hinzumehmen...
Du bist "nicht gewillt".. die Arbeitsergebnisse Anderer
"hinzunehmen...".
Schon wieder der falsche Grundton deinerseits. Deine Ansprüche sind
maßlos im Vergleich zu deinem Können. Schreib dir deine Libraries
selber, dann weißt du, was du hast, welchen Aufwand das macht und was
man selber können sollte.
Wie es anderen geht?
Nun, am Anfang steht ein Konzept dessen, was man realisieren will, dann
das Suchen nach dem geeigneten uC, dann das Lesen der Doku dazu, dann
ggf. ne Revision aller bisherigen Gedanken und Neuanfang, dann ein zum
Projekt passendes selbstentworfenes Evalboard, mit dem man alle
wichtigen Details erstmal ausprobiert und dann die eigentliche
Realisierung.
Sei froh, daß es das Internet gibt, wo man gute und schlechte, passende
und unpassende Beispiele findet. Lies sie, abstrahiere davon, verstehe
das Prinzip und schreib dir dann deinen eigenen Code. So herum geht es.
W.S.
....autsch, die Predigt hat gesessen, aber so ist es
schlüssig!....Interessiere mich gerade für die selbe Thematik und hoffe
das sich W.S. Hier im Forum anmeldet,oder immer mal drüber schaut ;-)
@W.S.
Nun entspann Dich doch bitte mal etwas.
"ARM Einsteiger" und auch ich sind in Sachen ARM-Welt eben Anfänger.
Ich persönlich komme z.B. von der Hardware-Seite. Eine
Horizonterweiterung finde ich sehr erquickend.
Aber es gibt halt verschiedene Wege etwas zu lernen.
Möglichkeit 1:
Absolut alles von Grund auf, Micro-Schritt für Micro-Schritt, durch
arbeiten.
(Das scheint Dein Weg zu sein.)
- dauert seeeeehr lange (ähnlich Feuersteinklinge zum Akku-Rasierer)
- Erfolgserlebnisse sind dünn gestreut
- Ergebnis aber allumfassend
- Programmieren nur mit Texteditor zwar möglich, aber ... naja
Möglichkeit 2:
Als Quereinsteiger, wie z.B. für mich, ist es einfacher sich mit einer
funktionierenden Lösung auseinander zusetzen um zu schauen, wie und
warum es funktioniert. "Was passiert, wenn ich das hier ändere?" Eine
IDE, die einem die Teils enorm langen Zeichenkollonen schon vorgibt bzw.
automatisch auf Fehler hinweist ist da sehr hilfreich.
- Zeitaufwand erheblicher geringer und somit auch für Arbeitende und
Hobbylogen machbar
- Grundfunktion können am lebenden Objekt erkundet werden
- Lernen der Schreibweise, Reihenfolge und Zusammenhänge quasi parallel
- Erfolgserlebnisse stellen sich erheblich schneller ein und damit
bleibt man am Ball
Möglichkeit 3:
Alles nur zusammenklicken und fluchen + weglegen wenn's nicht klappt.
Diese oberflächlichen "Programmier" entsprechen wohl eher Deinem
Feindbild.
"ARM Einsteiger" gehört aber definitiv (also in meinen Augen) nicht zu
der letzten Gruppe. Warum trifft man sich denn hier im Forum? Um 95%
durch reines Lesen zu lernen und wenn man nix passendes, zuviel oder
widersprüchliches gefunden hat, dann fragt man halt.
Wenn dann im Namen schon "Einsteiger" enthalten ist, dann sollte doch
eher Gnade vor Recht gelten. Das Forum ist doch nicht da um Anderen mit
der großen Gott-Keule die Rübe zu spalten. Wissensaustausch und
Hilfestellung, darum geht es doch. Wenn einem Anfänger, Um- oder
Einsteiger jegliche Freude am Experimentieren genommen wird, dann ist
das Schei... ähm Stuhl!
Oder sehe ich das etwa vollkommen falsch?
Gruss - xileH
xeliH v2 schrieb:> Oder sehe ich das etwa vollkommen falsch?
Nein, das siehst Du genau richtig!
Ich hatte mir zum STM32F4-Discovery die IAR Kickstart Version
angeworfen. Zum einen ist mir IAR ein wenig vertraut, zum anderen ist
die Transparenz der vorgefertigen Demos akzeptabel. Meine 2. Wahl wäre
die (gratis) Lösung von Keil gewesen.
Für Coocox usw. bin ich zu schlicht gestrickt.
ARM Einsteiger schrieb im Beitrag #3159446:
> Die CMSIS Library von ST ist zwar nicht wirklich gut dokumentiert, aber> zusammen mit dem Reference Manual bleibt eigentlich kein Geheimnis> offen.
Viele Demos nutzen diese CMSIS. Eigene Programmteile würde ich aber
zunächst ohne diese "Erleichterung" schreiben. Dann weiß man besser, was
man tatsächlich macht und merkt auch, wie vergurkt teilweise die
Anordnung der Register und deren Inhalt ist.
Später greift man dann selbst zu CMSIS, da diese einem dieses Gegurke
etwas transparenter macht :-)
xeliH v2 schrieb:> Aber es gibt halt verschiedene Wege etwas zu lernen.
Nö.
Eigentlich gibt es nur einen Weg, um es zu lernen, nämlich ES zu
lernen. Alles Andere ist "Nicht-wirklich-gelernt-haben". Aber du meinst
wahrscheinlich was anderes, nämlich sich irgendeinen Arbeitsstil
anzugewöhnen. Das ist häufig Geschmackssache, aber nicht immer. Als
schlechtes Beispiel nenn ich hier mal das Gewese um angeblich neue und
vieeel bessere Integerdeklarationen in C, die in der reealen Welt dann
von jedem Compiler wieder in die altbekannten Worte zurückübersetzt
werden - also alles nur heiße Luft gewesen, man hätte gleich bei char,
int und long bleiben können - allerdings wäre es dann besser gewesen,
wenigstens etwas von der jeweiligen zugrunde liegenden Hardware zu
verstehen. Dann ist das Ganze nämlich plötzlich gar kein Problem mehr.
Selbst bei den für ihre Ähnlichkeit gerühmten ARM-Controllern ist es so,
daß sich die Produkte verschiedener Hersteller an einigen Stellen doch
gar sehr unterscheiden, was zumeist den System-Setup betrifft. Genau
deshalb ist es wirklich nötig, sich das jeweilige Usermanual
reinzuziehen.
Mit Überfliegen und deinem Vorschlag, sich ein blinkendes "Blinky"
anzuschauen und dann ein bissel zu modifizieren, ist eigentlich nichts
gewonnen, denn es fehlt dabei an der Grundlage und auch an der eigenen
Strategie. Vielleicht würde es dich nerven, wenn ich jetzt von mir und
meiner Herangehensweise zu schwafeln beginnen würde, also laß ich das.
Aber wenn du schon dir ein funktionables Beispiel anschauen willst, um
daraus was zu lernen, dann lade dir hier aus der Codesammlung die
"Lernbetty" herunter, kauf dir für stolze 4 Euro bei Pollin ne
"Swissbetty"-Fernbedienung und lerne an diesem Beispiel. Dafür ist das
nämlich gemacht - und die dortige Herangehensweise kann man problemlos
auch auf Cortex-Controllern anwenden. Einige der dortigen Module kann
man sogar völlig unverändert auf anderen Architekturen benutzen. Auf
diese Weise kann man sich mit der Zeit ne Sammlung wirklich
wiederverwendbarer Codes zulegen - wenn man will. Aber sowas wie den
Startupcode verstehen und die prinzipiellen Funktionsweisen sich anlesen
muß man trotzdem, sonst bleibt man im Grunde unwissend.
W.S.
Hi, bin gerade beim Einstieg in die ARM-Welt eines Beaglebone Black und
was ich da erlebe macht mich einfach nur fassungslos. Mit dem
unschuldigen Anliegen einfach nur mal was auf den ersten UART-Port
auszugeben (und dafür den entsprechenden Pad Mux-Mode setzen zu müssen)
führt der Weg über ein vor Komplexität nur so strotzendes >4000 seitiges
(!) AM335x Cortex-A8 (ohne eine Antwort darin zu finden) hin zu einem
Steinzeit-Linux Betriebssystem, das einen Riesen-Popanz um die paar
nutzbaren Hardware-Ressourcen aufbaut dass einem die Haare nur so zu
Berge stehen. Problemloser Hardware-Zugriff: Fehlanzeige. Anbei der
Versuch eines Programmierers, einen UART-Port zu aktivieren...
Also diese teils abartig aufgeblasene Komplexität sollte der angehende
ARM-Programmierer kennen, finde ich. Im Zweifelsfall also besser bei AVR
& Co. bleiben, das lässt noch Zeit für andere Dinge im Leben!
Hi schau dir mal das Kickstarterprojekt
(http://www.kickstarter.com/projects/digistump/digix-the-ultimate-arduino-compatible-board-with-w)
an ist zwar quasi nen Arduino Due Clone aber mit:
32-bit ARM Processor (AT91SAM3X8E)
On board 802.11b/g/n WiFi Module (FCC/CE Approved)
On board nRF24L01+ wireless module (removable)
und man kanns ja auch ohne Arduino einfach als normales Board benutzen.
Mfg
Balin
@ Besser AVR,
also ich bin von AVR auf CortexM3/4 umgestiegen und will niemals wieder
zurück. Da die Teile genauso günstig oder günstiger wie die ATMEGAS
sind, benutze ich selbst dann einen ARM wenn es sich um triale Aufgaben
handelt. Mittlerweile gibts sogar schon Cortexe für unter 1 Euro. Und
kostenlose IDEs die einem viel Arbeit abnehmen sowiso (ich nutze Coocox)
Vielleicht hast du einfach den falschen Einstieg erwischt. Lass dich
nicht unterkriegen!
BesserAVR schrieb:> Anbei der> Versuch eines Programmierers, einen UART-Port zu aktivieren...
Naja, das was du da gepostet hast, hat mit Quellcode nix zu tun. Daß so
ein Zeugs jedermann abschreckt, kann ich dir nachfühlen.
Allerdings sind die Cortex A8 nicht eben grad ein wirkliches
Einsteigersystem. In dieser Riege sollte es m.E. schon wenigstens 32 MB
RAM und ein Windows CE oder sowas ähnliches drauf haben, aber dessen
programmierung hat wiederum nix mit Mikrocontrollern zu tun, sondern
eher mit PC-Programmierung, also Visual Studio oder Free Pascal für Arm
mit Lazarus (falls das schon auf den Cortex A8 portiert ist..)
Zum EInstieg sind allemal die LPC2XXX oder LPC1XXX oder STM32XXX mit
Taktfrequenzen im Bereich 30..150MHz gut. Dort findest du dann auch die
Hardwarenähe, nach der du suchst.
Naja, ich komm mir mittlerweile bissel wie ne tibetanische Gebetsmühle
vor, wenn ich wieder mal hier die billige und einfache Lernbetty hier
in der Codesammlung erwähne. Als Einstiegsgerät in die ARM-Szene allemal
geeignet. Ist schon seltsam: Die meisten Leute hier schielen nach
Cortexen, am liebsten A8 oder höher, aber mit was billigem an der Basis
anfangen, das ist ihnen zu poplig.
W.S.
Ich bin auch gerade am lernen.
Habe bereits jahrelange Hobby-Erfahrung mit AVR und will mich nun in die
Welt der ARM begeben. Genauer gesagt die NXP LPC11Cxx wegen dem
integrierten CANopen. Nach dem lesen der Hardware Manuals war ich erst
mal etwas erschlagen und gleichzeitig verblüfft, was die Teile können.
Für die CMSIS hab ich nichts brauchbares im Internet gefunden, somit
begonnen "Blinky" Zeile für Zeile analysiert und so einen Überblick
bekommen, was es mit CMSIS aufsich hat. An lebenden Beispielen lernen
ist nie verkehrt, aber man muss immer versuchen sie zu verstehen.
Ich bin jedenfalls guter Dinge, dass ich die ARM-Geschichte zum Laufen
bekomme, auch wenn mich der fehlende EEPROM irsinnig stört.
Christian_RX7
Ich bin gerade am überlegen, ob ich meine Graphic Lib auf ARM portieren
soll. Meine Erfahrungen mit dem LPC1114 habe ich hier dokumentiert:
http://code.google.com/p/u8glib/wiki/arm
Ausser dem USB - RS232 Konverter und einem LPC1114 braucht man nicht
wirklich viel.
Den Hype um die CMSIS kann ich mir nicht erklären: Das gemeinsame Subset
aller ARMs beschränkt sich scheinbar im wesentlichen auf ein paar
Interrupts und den System-Takt. Insofern nicht verwunderlich, dass man
nicht viel darüber lesen kann.
Das ZIP Archiv mit dem spezifischen CMSIS Code, den man für den LPC11xx
ganz gut gebrauchen kann, ist auf der oben angegebenen Seite verlinkt.
Oliver
...versuchs doch mal mit 'nem "Teensy 3.0" (MK20DX128 32 bit ARM
Cortex-M4 48 MHz; 18€ bei WATTEROTT)! Läßt sich mit 'ner modifizierten
Arduino-IDE ("Teensyduino") programmieren!
- Einfacher geht's nicht!
Wieder und wieder: STM32F4 Discovery & Coocox. Kosten 12.-€
200Mhz(übertaktet) machen einfach nur Spaß. Wenns wilder wird: Raspberry
(B Vers. ca 28.-€). Lasst euch von den Atmels (so gerne ich sie mag)
nicht
die Weitsicht nehmen! Andere Väter haben auch schöne Töchter ;-)
Gutes Gelingen!
Da stimme ich dir zwar zu, aber man darf sich auch nicht von denen
täuschen lassen.
Das Entwicklungsboard kostet 12 euro, wenn du aber später eigene
Entwicklungen machen möchtest, dann kostet der einzelne Chip auch 12
Euro und damit sogar mehr als bei den Atmels ein SAM4S. Bei höheren
Stückzahlen wird der Unterschied sogar noch extremer, in meinen Augen
ein Pluspunkt für Atmel.
Danke für die gut gemeinten Ratschläge. Den brandneuen Beaglebone Black
hatte ich gewählt weil ich ein GUI + den HDMI-Ausgang benötige.
Nach meinen jetzigen Erfahrungen hätte ich wohl besser den deutlich
ausgereifteren Raspberry gewählt (sagt auch die aktuelle c't).
Einsteigen wollte ich erstmal mit Python.
W.S. schrieb:> Naja, ich komm mir mittlerweile bissel wie ne tibetanische Gebetsmühle> vor, wenn ich wieder mal hier die billige und einfache Lernbetty hier> in der Codesammlung erwähne. Als Einstiegsgerät in die ARM-Szene allemal> geeignet. Ist schon seltsam: Die meisten Leute hier schielen nach> Cortexen, am liebsten A8 oder höher, aber mit was billigem an der Basis> anfangen, das ist ihnen zu poplig.
Einfach nur köstlich :-))
Den CANopen Demo hab ich mir schon angesehen, DANKE für den Tip.
Derzeit warte ich noch auf einen CAN USB Adapter damit ich auch was
sehe.
Ganz so weit bin ich aber auch noch nicht, da ich derzeit mit
verschiedensten Einstellungen herumspiele und LEDs blinken lasse.
Christian_RX7
Armi schrieb:> also ich bin von AVR auf CortexM3/4 umgestiegen und will niemals wieder> zurück. Da die Teile genauso günstig oder günstiger wie die ATMEGAS> sind, benutze ich selbst dann einen ARM wenn es sich um triale Aufgaben> handelt.
Das kann ich so auch bestätigen. Man will nicht mehr zurück. Aber
manchmal ist die Phereferie in den Cortexen aber weit hinter dem was
z.b. ein dsPic kann zurück. Versuch mal einen Cortex zu finden mit dem
man eine 2 Kanal/ 4Ausgänge Phase-Shift PWM ohne Interrupts nutzen zu
müssen hinbekommt und der nicht mehr als 48 Beine hat. Mit STM32 und
LPC1x habe ich das ergebnislos versucht. Ein dsPic im 28poligen DIP
Gehäuse geht dafür gut, und CAN kann er auch. Aber Mplab hasse ich wie
die Pest und der ICD3 ist auch nicht mit einem JLink zu vergleichen.
Leider wie immer, alles Gute ist nie beieinander.
Christian Kreuzer schrieb:> Den CANopen Demo hab ich mir schon angesehen, DANKE für den Tip.> Derzeit warte ich noch auf einen CAN USB Adapter damit ich auch was> sehe.
Also in der Demo ist auch der UART damit siehst Du die CAN-Messages im
Terminal. Natürlich ist ein CAN USB Adapter komfortabler.
https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/
LPC-P11C24 CAN communication example
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten