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ß.
Oder sieh dir mal die TI Teile an, http://www.ti.com/tool/ek-tm4c123gxl Das ist jetzt das aktuellste, und auch alles dabei was man brauch.
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 ;-)
Wenn du dich für den STM32 entschieden hast hier noch zwei Tipps meiner persönlichen Favoriten: http://diller-technologies.de/stm32.html und http://mystm32.de/doku.php Gruß
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!
Christian Kreuzer schrieb: > NXP LPC11Cxx wegen dem integrierten CANopen Hier gibt's eine CANopen Demo damit: https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ LPC-P11C24 CAN communication example
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
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.