Hallo allerseits Im Rahmen eines ROV-Projektes (ferngesteuertes U-Boot) habe ich mich sehr intensiv mit Arduino beschäftigt. Da ich nun ein Praktikum bei einer Firma beginne, die sich vor allem mit ARM basierten Controllern beschäfftigt, plane ich auf ein Arduino Due umzusteigen, welches einen Atmel SAM3X8E verwendet. Gerne würde ich dieses mit uVision von Keil programmieren. Kurz was ich später machen möchte: -Auslesen von Sensoren I2C/Seriel -Kommunikation über einen weiteren serielle Port mit einem Arduino -Umrechnung von Daten, PID-Regler -Ansteuerung von Brushless-Esps --> Zeitpräzision gefragt Der Einstieg scheint mir hier sehr schwer, sehr würde ich mich über ein paar Links, Videoempfehlungen zu folgenden Themen freuen: -Das simpelste GPIO, gibt es da irgendwelche Funktionen wie analogRead, digitalWrite etc. beim Arduino -Serielle Kommunikation -Die Benutzung von RTOS, CMSIS etc. Was ich mir vor allem als Arduino-Nutzer wünschen würde ist so ein Wiki, wo ich alle Funktionen aus Standard Libarys nachschlagen kann. Vielen Dank für alle eure Antworten Felix
:
Bearbeitet durch User
Hi, steige gerade selbst vom Xmega auf STM32 um. Hier gibt es eine recht komfortable Konfigurationsoberfläche namens CubeMX die einem einiges an Arbeit abnimmt oder als Grundlage für Beispiele dienen kann. Dafür sind die verwendeten HAL-Treiber leider nur dürftig dokumentiert. Ohne Cube und HAL gibt es wiederum sehr viele Tutorials als Video oder in geschriebener Form zu finden. Auch einige mächtige Libraries wie zB hier -> http://stm32f4-discovery.com/ Discovery oder Nucleo Boards gibt es mit verschiedenen Chipvarianten für wenig Geld. Wenn es nicht unbedingt ein Grafikdisplay werden soll, wurde mir für eine ähnliche Anwendung eines dieser Boards empfohlen: http://www.st.com/web/catalog/tools/FM116/CL1620/SC959/SS1532/LN1847/PF260004 http://www.st.com/web/en/catalog/tools/PF260318 Das Erste ist zudem mit Arduino kompatibel. Wie es bei Atmel ARM aussieht, weiß ich leider nicht. Hehe :) Letzteres in Deinem Text wünschte ich mir auch! Zumindest gibt's bei uVision einen netten Reiter wie im Anhang zu sehen. Gruß
:
Bearbeitet durch User
Felix C. schrieb: > Da ich nun ein Praktikum bei > einer Firma beginne, die sich vor allem mit ARM basierten Controllern > beschäfftigt, Klär mal vorher ab, ob irgendein Mitarbeiter etwas von Arduinos hält und man dort damit Programme schreibt. Ich fürchte - oder besser, ich hoffe - das macht man dort nicht. Arduino ist gut zum Schnuppern, aber für industrielle Anwendungen wird nur µC-Leistung verplempert. Wenn Du schon eine Keil IDE einsetzen kannst/willst, vergiss Arduino!
m.n. schrieb: > Arduino ist gut zum Schnuppern, aber für industrielle Anwendungen wird > nur µC-Leistung verplempert. Arduino verwendet C. Da kann man µC-Leistung verplempern, wo es unkritisch ist, eigene C-Routinen verwenden, wo man umfangreichen Arduino-Code vermeiden möchte und Assembler verwenden, wenn man mein, dass es unbedingt nötig ist ;-)
m.n. schrieb: > Felix C. schrieb: >> Da ich nun ein Praktikum bei >> einer Firma beginne, die sich vor allem mit ARM basierten Controllern >> beschäfftigt, > > Klär mal vorher ab, ob irgendein Mitarbeiter etwas von Arduinos hält und > man dort damit Programme schreibt. > Ich fürchte - oder besser, ich hoffe - das macht man dort nicht. > > Arduino ist gut zum Schnuppern, aber für industrielle Anwendungen wird > nur µC-Leistung verplempert. > Wenn Du schon eine Keil IDE einsetzen kannst/willst, vergiss Arduino! Wie ich bereits schrieb, möchte ich umsteigen. Wie du sicherlich weisst handelt es sich bei einem Arduino nur um Board, welches günstig ist, leicht zu montieren etc., aber eine Arm basierte CPU besitzt, welche folglich mit uVision von Keil programmierbar sein sollte, trotzdem danke für den nutzlosen Arduino-Hate.
Hi Felix, Ich weiß nicht wie lange dein Praktikum dort geht, aber vielleicht kannst du die Leute da fragen, ob die dir nicht eine Aufgabe zum lernen geben könnten.(über die gesamte Zeit, dann vor dem Ende mit Präsentation sich dort verabschieden) Es lernt sich einfacher mit einem Ziel und macht mehr Spaß. Wird der ARM dort in der Firma auch eingesetzt, wenn nicht versuche den ihren zu nutzen. (hier kann dir schneller Hilfestellung Vorort gegeben werden) Wichtig JTAG kaufen. Dann die Beispiele von Atmel runter laden und ansehen und verstehen! Gegeben falls Erweiterungen für das Board besorgen.(für Lochraster oder so) >Auslesen von Sensoren I2C/Seriel Ein EEPROM oder IO-Erweiterung für SPI oder I2C sind immer dabei. Temperatursensor usw. >Kommunikation über einen weiteren serielle Port mit einem Arduino paar MAX3232(RS232) oder RS485(3V3) Chips holen. >Umrechnung von Daten, PID-Regler kleine Motor-Steuerkarte gibs bestimmt auch (für PC-Lüfter) >Ansteuerung von Brushless-Esps --> Zeitpräzision gefragt muß ich leider passen Felix C. schrieb: > Was ich mir vor allem als Arduino-Nutzer wünschen würde ist so ein Wiki, > wo ich alle Funktionen aus Standard Libarys nachschlagen kann. Das gabs früher bei Atmel auch, war auf den CDs der HandsOn Trainings dabei.Komplette Lib doku in Doxygen HTML Output, war Ok. Ich glaube heute gibt es nur noch, wenn man Glück hat, ein doxygen Config-File. Aber das geht ja auch. Die Libs der Chip-Herstelle sind aber nur zum Anschauen dar (Und für das Hobby natürlich auch),aber NICHT für den industriellen Einsatz gedacht!!! Also: Header-Files und C-Files studieren! (und gegeben falls anpassen!) Wenn du Hilfe brauchst frag die Leute dort oder frag hier nach, so schwer ist das nicht. Viel Spass
Hallo Stephan vielen Dank für deine ausführliche Antwort. Ich glaube ich hatte mich etwas unpräzise ausgedrückt. Im Rahmen des Baus eines ROV's an, an welchem ich, immer noch, privat arbeite, begann ich der Einfachkeit halber ein Arduino zu nutzen. Da ich nun ein Praktikum beginne und ich die Software des U-Bootes sowieso überarbeiten will, möchte ich dafür nun ein Arduino Due verwenden. Dies hat nur insofern etwas mit meinem Praktikum zu tun, dass ich mich wahrscheinlich nicht an ARM herangetraut hätte, würde ich mich nicht bald beruflich damit beschäftigen. Womit ich dort konkret arbeiten werde, weiss ich noch nicht. Jedoch denke ich mir, dass wenn ich bereits mit uVision und ARM-spezifischen Funktionen wie dem RTOS privat gearbeitet habe, dies mir auch einen einfacheren Einstieg in den Beruf erleichtert, wo ich dann halt mit anderen Prozessoren, aber mit der gleichen IDE arbeite. Stephan schrieb: >>Auslesen von Sensoren I2C/Seriel > Ein EEPROM oder IO-Erweiterung für SPI oder I2C sind immer dabei. > Temperatursensor usw. >>Kommunikation über einen weiteren serielle Port mit einem Arduino > paar MAX3232(RS232) oder RS485(3V3) Chips holen. >>Umrechnung von Daten, PID-Regler > kleine Motor-Steuerkarte gibs bestimmt auch (für PC-Lüfter) >>Ansteuerung von Brushless-Esps --> Zeitpräzision gefragt > muß ich leider passen Dies ist der Grund wieso ich ein Arduino Due verwenden will. Vielleicht mal schnell Googlen. Dort muss ich eben NICHT mir alle Sachen zusammensuchen, sondern habe bereits ein Board mit UART's, I2C, SPI, Steckleisten etc. Was die Brushless betrifft, dort muss einfach ein PPM(Puls-Pausen-Modulation) "erstellen", was man ganz einfach selber schreiben kann. Das mit Atmel werde ich mir mal ansehen.
Felix C. schrieb: > Wie du sicherlich weisst > handelt es sich bei einem Arduino nur um Board, Nein, ich weiß daß es nicht nur ein Board sondern auch eine Entwicklungsumgebung ist. Felix C. schrieb: > trotzdem danke > für den nutzlosen Arduino-Hate. Ich verstehe, Du hast nichts begriffen.
> Was die Brushless betrifft, dort muss einfach ein > PPM(Puls-Pausen-Modulation) "erstellen", was man ganz einfach selber > schreiben kann. Hmmm... Werden Brushless-Motoren nicht günstigstenfalls über Strommessung oder Hall-Sensoren mit einer raumzeigermodulierten dreiphasigen PWM geregelt?
Felix C. schrieb: > Da ich nun ein Praktikum beginne und ich die Software des U-Bootes > sowieso überarbeiten will, möchte ich dafür nun ein Arduino Due > verwenden. erst mal Ok. Das hat auch ein JTAG Interface? JTAG kaufen! Macht das Leben mit MCs leichter. > Dies hat nur insofern etwas mit meinem Praktikum zu tun, dass > ich mich wahrscheinlich nicht an ARM herangetraut hätte, würde ich mich > nicht bald beruflich damit beschäftigen. Ahh. Ok hatte ich anders verstanden. > Womit ich dort konkret arbeiten werde, weiss ich noch nicht. Jedoch > denke ich mir, dass wenn ich bereits mit uVision und ARM-spezifischen > Funktionen wie dem RTOS privat gearbeitet habe, dies mir auch einen > einfacheren Einstieg in den Beruf erleichtert, wo ich dann halt mit > anderen Prozessoren, aber mit der gleichen IDE arbeite. Erleichtern bestimmt. RTOS hat nichts mit ARM zu tun!!! Bitte beachten. RTOS sollte mal heißen 'Real Time Operating System' ABER es bleibt auf den kleinen ARMs leider immer nur ein 'Scheduler' übrig und KEIN Operating System!!!! (meine pers. Meinung!)
Nur mal so eine Frage: Schon mal die Discovery-Boards von STM angeschaut? Da hast du Brenner/Debuger und ein ARM32 für etwa 20 Euro. Ausserdem sehr gute Tutorials und Libs. Also ich weiss nicht, wies in deiner zukünfitiegn Firma aussieht, aber wie schon erwähnt würde ich den gleichen Kontroller verwenden (erspart dir sehr viel Verwirrung). Und nebenbei: Um einen ARM "richtig" zu nutzen und alle seine Spezialitäten gezielt einsetzen wirst du locker 6 Monate auf dem Ding programmieren müssen (C und ASM, dann grosse Schnittstellen, Timergesteuerte-ADC und DMA, Start-Up codes selber schreiben, Bootloader selber schreiben...) Aber viel Erfolg, bei mir war der Umstieg über 2 Jahre hinweg von AVR/Pic auf STM32 (auch industriell) und ich bereue es nicht.
Christof K. schrieb: > Hmmm... Werden Brushless-Motoren nicht günstigstenfalls über > Strommessung oder Hall-Sensoren mit einer raumzeigermodulierten > dreiphasigen PWM geregelt? Doch klar, dafür werden sogenannte ESC's gebraucht. Über das PPM-Signal, welches vom uController kommt, kann man dann die ESC's programmieren und steuern. Stephan schrieb: > JTAG kaufen! Macht das > Leben mit MCs leichter. Wird erledigt. :) Patrick B. schrieb: > Schon mal die Discovery-Boards von STM > angeschaut? Da hast du Brenner/Debuger und ein ARM32 für etwa 20 Euro. > Ausserdem sehr gute Tutorials und Libs. Nein hatte ich bisher noch nicht, aber der STM32 scheint ja ziemlich populär zu sein.
Felix C. schrieb: > Doch klar, dafür werden sogenannte ESC's gebraucht. Über das PPM-Signal, > welches vom uController kommt, kann man dann die ESC's programmieren und > steuern. Aaah. Coole Teile. Da ist ja schon alles drin! Fast langweilig ;P Die regeln scheinbar gern über die induzierte Spannung des Motors. Auch ne Variante. > Nein hatte ich bisher noch nicht, aber der STM32 scheint ja ziemlich > populär zu sein. Deshalb vorhin meine Empfehlung. Der STM32f334 Chip ist speziell für Motorsteuerungen und Powerconversion gedacht und bringt dafür als einziger der Familie einen High Resolution Timer mit. --> http://www.st.com/web/en/catalog/mmc/SC1169/SS1576/LN1820/PF259916 Das Nötige an Kommunikation hat er auch. Die Pinkompatibilität zum Arduino könnte Dir vllt auch noch hilfreich sein bei der Nucleo Serie. --> http://www.st.com/web/catalog/tools/FM116/CL1620/SC959/SS1532/LN1847/PF260004 Wenn Du ein wahres kommunikationsmoster mit Beschleunigungssensor, Speicher USB-Anschluss und Display direkt on Board haben magst, kann ich das hier empfehlen --> http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 Finde dass man hier bei der Pinbelegung nur all zu oft Kompromisse eingehen muss.
:
Bearbeitet durch User
Christof K. schrieb: > Aaah. Coole Teile. Da ist ja schon alles drin! Fast langweilig ;P > Die regeln scheinbar gern über die induzierte Spannung des Motors. Auch > ne Variante. ja aber deutlich schlecher. Und das kann man auch nicht so stehen lassen: Stephan schrieb: > Die Libs der Chip-Herstelle sind aber nur zum Anschauen dar (Und für das > Hobby natürlich auch),aber NICHT für den industriellen Einsatz > gedacht!!! Glaubst du das wirklich oder ist das ein Trollversuch. ST versucht mit STMCube sicher nicht mal so zum Spaß Kompatibilität zwischen der ganzen STM32 Reihe zu schaffen. Auch wenn die Lib manche Macken haben mag. Nur zum anschauen ist das ganz bestimmt nicht.
Hallo avr avr schrieb: > Glaubst du das wirklich oder ist das ein Trollversuch eigentlich wollte ich nicht antworten, aber ich versuche es trotzdem: Ich habe leider nicht die aktuellen File von ST vorliegen daher eine aus dem Netz https://developer.mbed.org/users/mbed_official/code/mbed/file/7d30d6019079/TARGET_NUCLEO_F030R8/stm32f0xx_adc.h Zitat daraus: >THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR >PURPOSE ARE DISCLAIMED. grob übersetzt: DIE IMPLIZIERTEN GARANTIEN DER MARKTFÄHIGKEIT UND FITNESS ZU EINEM BESONDEREN ZWECK WERDEN ABGESTRITTEN. http://www.online-translator.com/ Man kann sich drüber streiten, was diese Aussage soll. bzw was mit gemeint ist. Aber das will ich eigentlich gar nicht, denn es geht auch besser: zertifizierte SW. (meine pers. Meinung!)
Ok, ich hab mich jetzt mal etwas in die Hitex-Guide zum STM32 eingelesen da diese als guter Einstieg zu ARM empfohlen wurde. Nun wäre ich für ein paar Antworten und Korrekturen sehr dankbar. -CMSIS Das ist ein Treiber-Standard um so diese Treiber auf allen ARM-Controller benutzen zu könne. Es enthält anscheinend auch Funktionen die die Peripherie betreffen(I2C, USART, GPIO), wo finde ich diese? -Vergleichbar gibt zu der Arduino-Funktionen-Wiki gibt es bei Atmel das Atmel Software Framework. Die finde ich hier http://asf.atmel.com/docs/3.4.1/api.html. -Sollte ich das richtig verstanden haben, noch eine ganz konkrete Fragen zu den GPIO. Das ist ja meist das erste was man benutzt, wenn man mit einem Controller warm werden will. Ich habe hier jetzt im ASF nämlich gleich 3 Befehle gefunden die mir zum "einschalten" eines Pins geeignet scheinen, was mich echt verwirrt. static void ioport_toggle_pin_level (ioport_pin_t pin) Toggle the value of an IOPORT pin, which has previously configured as an output. http://asf.atmel.com/docs/3.4.1/sam3x/html/group__ioport__group.html Ein als OUTPUT definierter Pin togglen? Also HIGH oder LOW? void pio_set_pin_high (uint32_t ul_pin) Drive a GPIO pin to 1. http://asf.atmel.com/docs/3.4.1/sam3x/html/group__sam__drivers__pio__group.html Ganz offensichtlich zum einschalten. static void ioport_set_pin_level (ioport_pin_t pin, bool level) Set an IOPORT pin to a specified logical value. http://asf.atmel.com/docs/3.4.1/sam3x/html/group__ioport__group.html Ist hier auch das "einschalten" geimeint oder die Änderung des Register ob am Pin ein High oder Low liegt? Entschuldigt wenn meine Fragen etwas noobig sind, aber das ist gerade soviel neues, dass man sich ein wenig erschlagen fühlt. Wenn es eine Dokumentation gibt, die mir das Fragen hier ersparen würde, wäre ich auch sehr dankbar ;) Ich finde das ASF ist iwie ein bisschen minimalistisch gehalten. Gruss und Dank Felix
Felix C. schrieb: > Ok, ich hab mich jetzt mal etwas in die Hitex-Guide zum STM32 > eingelesen da diese als guter Einstieg zu ARM empfohlen wurde. Ja, weil sehr verfuegbar und billig zu haben (STM32-Discovery etc.). > -CMSIS Das ist ein Treiber-Standard um so diese Treiber auf allen > ARM-Controller benutzen zu könne. Es enthält anscheinend auch Funktionen > die die Peripherie betreffen(I2C, USART, GPIO), wo finde ich diese? Jaein. CMSIS enthält ein paar Funktionen fuer die Cortex-M3 Standardperipherie (also NVIC, SysTick und so), aber nicht den Rest. Die normale Peripherie (UART, GPIO, ...) ist herstellerspezifisch - ein STM32 ist völlig anders als ein SAM3X. Zum CMSIS gibt es meistens vom Hersteller ein Register-Headerfile, damit man PIOB->PIO_PSR oder so benutzen kann. > -Vergleichbar gibt zu der Arduino-Funktionen-Wiki gibt es bei Atmel das > Atmel Software Framework. Die finde ich hier > http://asf.atmel.com/docs/3.4.1/api.html. Atmels ASF oder STs StdPeripherals-Library sind dann auf CMSIS aufbauende Bibliotheken, die die Treiber fuer die Peripherie (und vielleicht auch mehr) anbieten. Die sind dann wieder komplett herstellerspezifisch. > -Sollte ich das richtig verstanden haben, noch eine ganz konkrete Fragen > zu den GPIO. Das ist ja meist das erste was man benutzt, wenn man mit > einem Controller warm werden will. > Ich habe hier jetzt im ASF nämlich gleich 3 Befehle gefunden die mir zum > "einschalten" eines Pins geeignet scheinen, was mich echt verwirrt. ASF funktioniert nicht mit STM32. Details stehen im Datenblatt und in der Dokumentation zur Bibliothek. Was die GPIOs betrifft, verwechselst du da was. Ein Pin kann Eingang oder Ausgang sein. > static void ioport_toggle_pin_level (ioport_pin_t pin) > Ein als OUTPUT definierter Pin togglen? Also HIGH oder LOW? Wenn der Pin ein Ausgang ist und derzeit auf HIGH, dann wird er auf LOW gesetzt. Oder von LOW auf HIGH. Wenn der Pin ein Eingang ist, ergibt die Funktion keinen Sinn. > void pio_set_pin_high (uint32_t ul_pin) > Ganz offensichtlich zum einschalten. Nein. Wenn der Pin ein Ausgang ist, wird er auf HIGH gesetzt. Wenn er ein Eingang ist, ergibt die Funktion keinen Sinn. > static void ioport_set_pin_level (ioport_pin_t pin, bool level) > Ist hier auch das "einschalten" geimeint oder die Änderung des Register > ob am Pin ein High oder Low liegt? Damit kannst du einen Pin auf HIGH oder auf LOW setzen. > Entschuldigt wenn meine Fragen etwas noobig sind, aber das ist gerade > soviel neues, dass man sich ein wenig erschlagen fühlt. Wenn es eine > Dokumentation gibt, die mir das Fragen hier ersparen würde, wäre ich > auch sehr dankbar ;) Ja, suche dir einen kleinen ARM raus und schau dir dessen Datenblatt an. Dann wird dir vieles klarer. Und wenn du mit einem STM32 arbeiten willst, sind sowohl ASF als auch Datenblätter von Atmel total falsch. Bei ST gibt es 3 Datenblätter: - eins zu deinem speziellen Chip - eins zu allen STM32 einer Familie - eins zu allen Cortex-M3 Die Datenblätter verweisen jeweils aufeinander. Also, das Datenblatt zu deinem Chip enthält die IDs der Peripherie ("GPIOx hat ID y") und das Datenblatt zur Familie nutzt diese IDs dann ("um ID x zu aktivieren, setze Bit y in Register z"). > Ich finde das ASF ist iwie ein bisschen > minimalistisch gehalten. Ich nutze weder ASF noch STs Bibliothek, sondern das Datenblatt und programmiere die Register selbst. Also ähnlich wie auf einem AVR. Da der Code zwischen den Herstellern sowieso nicht portabel ist, verliert man dabei auch nichts. Gruß, Svenska
S. R. schrieb: > Jaein. CMSIS enthält ein paar Funktionen fuer die Cortex-M3 > Standardperipherie (also NVIC, SysTick und so), aber nicht den Rest. Ok, ja eigentlich total logisch. S. R. schrieb: > ASF funktioniert nicht mit STM32. Ist mir klar, ich lese den Hitex Guide, da dort Sachen stehen, die ARM Cortex M3 Controller im Allgemeinen betreffen, dass es zu einem SAM Unterschiede gibt, gerade da dieser von einem anderen Hersteller ist, ist mir bewusst. Aber ich wusste z.B. nicht dass man auf den SRAM statt auf den Flash schreiben kann, um diesen zu schonen. Ich denke, dass es Ähnliches beim SAM gibt, bzw. werde danach schauen, wenn ich mich näher mit ihm beschäftige. Er wirde gerade geliefert :) S. R. schrieb: > Was die GPIOs betrifft, verwechselst du da was. > Ein Pin kann Eingang oder Ausgang sein. Ich meinte genau das. Meine Frage bezog sich nur darauf, wenn er als Ausgang definiert ist.
> Ist mir klar, ich lese den Hitex Guide, da dort Sachen stehen, die ARM > Cortex M3 Controller im Allgemeinen betreffen, dass es zu einem SAM > Unterschiede gibt, gerade da dieser von einem anderen Hersteller ist, > ist mir bewusst. Es gibt keinen "ARM Cortex M3": ARM selbst produziert keine Chips. Aber alles, was von ARM spezifiziert ist, existiert in genau dieser Form auch auf jedem Chip, der einen CM3-Kern enthält. Also auch auf einem STM32 und auch auf einem SAM3X. > Aber ich wusste z.B. nicht dass man auf den SRAM statt > auf den Flash schreiben kann, um diesen zu schonen. > Ich denke, dass es Ähnliches beim SAM gibt, bzw. werde danach schauen, > wenn ich mich näher mit ihm beschäftige. Er wirde gerade geliefert :) Hä? Jeder Cortex-M3 kann Code aus dem RAM ausführen, wenn du das meinst, ja. Den Flash "einfach so" beschreiben geht sowieso nicht, das machst du mit dem Flash-Controller - und der ist wieder von Hersteller zu Hersteller anders. Ich dachte, du wolltest mit einem STM32 anfangen? Egal, fuer den Einstieg sind beide gut, und Atmels Doku ist auch gut.
:
Bearbeitet durch User
Felix C. schrieb: > Wie ich bereits schrieb, möchte ich umsteigen. Wie du sicherlich weisst > handelt es sich bei einem Arduino nur um Board, welches günstig ist, > leicht zu montieren etc., aber eine Arm basierte CPU besitzt, welche > folglich mit uVision von Keil programmierbar sein sollte, trotzdem danke > für den nutzlosen Arduino-Hate. Du verwechselst da diverses ganz gewaltig. Obendrein hast du - gemessen an deinem Kenntnis-Stand - ein bei weitem zu freches Mundwerk. Begreife mal, daß m.n. dir fachlich HAUSHOCH überlegen ist und weiß, was er da schreibt - du aber nicht. Also, damit du den tiefen Unterschied begreifst: Arduinos werden als Baukasten-Systeme verwendet, die man wie bei der elektrischen Eisenbahn zusammensteckt. Dafür sind die diversen Shields UND die genau darauf abgestimmten Software-Bauklötzchen vorgesehen. Bei eigentlich allen ARM-basierten Systemen in der Industrie ist der Controller lediglich ein Bauteil neben vielen anderen auf der Leiterplatte, welche selbstverständlich projektspezifisch ist. Folglich gibt es keine dransteckbaren Shields, auch keine Software-Bauklötzchen. Der Entwurf des gesamten Systems ist Sache der beteiligten Entwickler. Denke jetzt nicht, daß es ja so tolle Evalboards gibt. Ja, gibt es, aber die sind dafür da, den angezielten Geräteentwicklern den beworbenen Chip schmackhaft zu machen. Dafür gibt es zumeist eine fertige Demo-Software - aber aus dieser lernt man garantiert NICHT mit dem Chip umzugehen. Felix C. schrieb: > Ich habe hier jetzt im ASF nämlich gleich 3 Befehle gefunden die mir zum > "einschalten" eines Pins geeignet scheinen, was mich echt verwirrt. Ja, eben. Du schreibst wie ein Arduino. In der realen ARM-Welt sieht das ganz anders aus. Da solltest du dich eher mit dem Referenz-Manual zum Controller befassen, damit du eine Ahnung bekommst, auf was für einer Hardware du den Tanzboden zu betreten trachtest. Mach erst kleine Schritte, sonst landest du auf deinem Allerwertesten. Sowas wie das Konfigurieren von Pins (nebst zuvorigem Betrachten der benötigten I/O's und ggf. das Wählen von alternativen Pinbelegungen) oder das Setzen/Rücksetzen von GPIO-Portpins macht man normalerweise ohne die von dir genannten "Befehle", was in Wirklichkeit Unterprogramm-Aufrufe sind. Also: Lies dich ein, nimm dazu das Referenz-Manual und die Doku von ARM über die konkret verbaute CPU in dem Chip deiner Wahl. Das ist alles Hardware und die solltst du begreifen, sonst bleibst du ewig eben nur ein Arduino. Felix C. schrieb: > -Sollte ich das richtig verstanden haben, noch eine ganz konkrete Fragen > zu den GPIO. Das ist ja meist das erste was man benutzt, wenn man mit > einem Controller warm werden will. Tja, wieder falsch gedacht. Bei eigentlich fast ALLEN aktuellen ARM's, also Cortexen mit mehr als 30 MHz CPU-Takt steht als allererstes das Aufsetzen der Takte (jaja, Mehrzahl) auf dem Programm. Dann kommt das Pinbelegen und das Einschalten und Aufsetzen der benötigten peripheren Cores. Nochmal: LIES die Literatur über die Hardware! Das ist so unsäglich wichtig, daß man es nicht oft genug wiederholen kann. W.S.
S. R. schrieb: > Es gibt keinen "ARM Cortex M3" OK, danke für die Erklärung. Aber es stimmt doch, dass der ARM M3 Kern, oder wie bezeichnet man das richtig, in jedem Controller sei er von ST, Atmel etc. gleich ist, nur die externe Peripherie ändert z.B. von einem SAM3-Serie zu der ST32-Serie. S. R. schrieb: > Hä? Ich meinte damit, dass ich jenes z.B. nicht wusste, wie vieles noch nicht. Deswegen las ich die Hitex-Guide, da ich keine andere fand, die sich mit einem Microcontroller mit ARM M3 Kern, hoffe das war jetzt richtig so, beschäftigt. Ich wollte einfach ein paar generelle Informationen über Controller die einen ARM Kern verwenden, in der Annahme, dass diese sich wenigstens zum Teil ähneln. S. R. schrieb: > Jeder Cortex-M3 kann Code aus dem RAM ausführen, wenn du das meinst, ja. Das wusste ich z.B. nicht, genau wie vieles andere. S. R. schrieb: > Ich dachte, du wolltest mit einem STM32 anfangen? Felix C. schrieb: > plane ich auf ein Arduino Due umzusteigen, welches einen > Atmel SAM3X8E verwendet. W.S. schrieb: > Du verwechselst da diverses ganz gewaltig. Obendrein hast du - gemessen > an deinem Kenntnis-Stand - ein bei weitem zu freches Mundwerk. Begreife > mal, daß m.n. dir fachlich HAUSHOCH überlegen ist und weiß, was er da > schreibt - du aber nicht. Dass man mir fachlich haushoch überlegen ist, ist mir bewusst. Deswegen stelle ich hier auch Fragen. Zu dem mit dem frechen Maulwerk. Ja, das war frech und da stehe ich auch dazu und wäre es auch wieder. Ich bezweifle nämlich, dass er oder du begreifst wie jemand der ein Arduino-Board benutzt tickt. Ich nehme alle Ratschläge an, dass ich Datenblätter anschauen soll etc. aber du, m.n. und viele weitere aus diesem Forum begreifen ganz offensichtlich nicht, wie es vielen Arduino-Nutzern wie mir ergeht. Damit du das begreifst hier eine kurze Erklärung. Um die 16-20 Jahre, gymnasiale Ausbildung (Ergo, minimale elektrotechnische Kenntisse von seiten der Schule, von Microcontrollern ganz zu schweigen). Da ist alles selbsterlernt, seien das Foren, oder andere Internetbeiträge. Man schustert sich sein Wissen aus tausend Quellen zusammen. Da ist kein Dozent der einem etwas zeigt, auch kein Arbeitskollege und man hat sicher keine Fachbücher, genauso wie man nicht weiss wo man sich Informationen am besten herholt. Und am allerwenigsten weiss man wie man 1500 Seiten starkes Datenblatt auf Fach-Englisch verwendet....weil man es noch nie getan hat. Das Problem ist dann, dass man dann vor, allem in diesem Forum, von einigen Leuten blöd angemacht wird, weil man sich z.B. nicht an die Ratschläge Erfahrener hält. Die sind aber zum Teil gar nicht umsetztbar.Jedenfalls nicht für jemanden mit eben beschriebenem Profil. W.S. schrieb: > Arduinos werden als Baukasten-Systeme verwendet, die man wie bei der > elektrischen Eisenbahn zusammensteckt. Dafür sind die diversen Shields > UND die genau darauf abgestimmten Software-Bauklötzchen vorgesehen. Zudem kommt, dass du anscheinend wirklich keine Ahnung hast. Nur weil es für Arduino jede Menge Boards und optimierte Bauteile auf dem Markt gibt, heisst das noch lange nicht, dass jeder Arduino-Nutzer auch nichts anderes verwendet. Geh mal ins Arduino-Forum und schau dich ein wenig um, ich brauch hier gar nicht mehr zu schreiben. W.S. schrieb: > Sowas wie das Konfigurieren von Pins (nebst zuvorigem Betrachten der > benötigten I/O's und ggf. das Wählen von alternativen Pinbelegungen) > oder das Setzen/Rücksetzen von GPIO-Portpins macht man normalerweise > ohne die von dir genannten "Befehle", was in Wirklichkeit > Unterprogramm-Aufrufe sind. Solange man aber die Register noch nicht richtig im Kopf hat is das aber eine sehr schnelle Art erste Resultate zu erzielen, oder nicht? W.S. schrieb: > Tja, wieder falsch gedacht. Bei eigentlich fast ALLEN aktuellen ARM's, > also Cortexen mit mehr als 30 MHz CPU-Takt steht als allererstes das > Aufsetzen der Takte (jaja, Mehrzahl) auf dem Programm. Dann kommt das > Pinbelegen und das Einschalten und Aufsetzen der benötigten peripheren > Cores. Ok, danke für die Info, werde mich diesbezüglich informieren. W.S. schrieb: > Nochmal: LIES die Literatur über die Hardware! Das ist so unsäglich > wichtig, daß man es nicht oft genug wiederholen kann. Hier hättest du auch noch auf etwas verweisen können. Wie der Thread gezeigt hat und du auch selbst festgestellt hast, bin ich halt nur ein Arduino der das alles nicht auf die Reihe kriegt.
:
Bearbeitet durch User
Felix C. schrieb: > Solange man aber die Register noch nicht richtig im Kopf hat is das aber > eine sehr schnelle Art erste Resultate zu erzielen, oder nicht? Oder: Ich möchte mir ein Aquarium einrichten. Also kaufe ich erst mal Fische...
Felix C. schrieb: > Aber es stimmt doch, dass der ARM M3 Kern, oder wie bezeichnet man das > richtig, in jedem Controller sei er von ST, Atmel etc. gleich ist, nur > die externe Peripherie ändert z.B. von einem SAM3-Serie zu der ST32-Serie. Die ändert sich auch zwischen STM32F und STM32L, oder zwischen SAM3X und SAM3U. > Ich wollte einfach ein paar generelle Informationen über Controller die > einen ARM Kern verwenden, in der Annahme, dass diese sich wenigstens zum > Teil ähneln. Achso, ja. Da gibt's aber auch Dokumentation direkt von ARM. Und praktisch bringt dir das relativ wenig, weil das wesentliche in der Herstellerdokumentation nochmal verkaut wird. > Ich bezweifle nämlich, dass er oder du begreifst wie jemand der ein > Arduino-Board benutzt tickt. Oh, das war aus der Ursprungsfrage schon relativ klar ersichtlich: "Mir scheißegal, wie das Teil funktioniert, ich will wissen, wie ich es benutze." Aber das eine funktioniert ohne das andere nicht. > Da ist kein Dozent der einem etwas zeigt, auch kein Arbeitskollege > und man hat sicher keine Fachbücher, genauso wie man > nicht weiss wo man sich Informationen am besten herholt. Echt? Kein Google, keine Bibliothek, keine Uni oder FH in der Nähe? Lange bevor ich studiert hatte, bin ich mit meiner Mutter mal in die örtliche FH-Bibliothek marschiert und dort haben wir dann gefragt, wie das mit Ausleihen und so ist, weil ich ja kein Student war. > Und am allerwenigsten weiss man wie man 1500 Seiten starkes Datenblatt > auf Fach-Englisch verwendet....weil man es noch nie getan hat. Das kann man hier durchaus fragen. > Das Problem ist dann, dass man dann vor, allem in diesem Forum, von > einigen Leuten blöd angemacht wird, weil man sich z.B. nicht an die > Ratschläge Erfahrener hält. Ja, weil das hier nicht unbedingt die optimale Plattform ist. > Zudem kommt, dass du anscheinend wirklich keine Ahnung hast. [...] > ich brauch hier gar nicht mehr zu schreiben. Brauchst du auch nicht. Eine Frage sagt immer etwas ueber den Fragenden aus, und deine Frage schrie jedem ein "ich habe keine Ahnung und keine Grundlage" ins Gesicht. Wenn du mit der Grundlage zum Automechaniker gehst, dann schickt der dich auch nach Hause mit dem Vermerk "lern erstmal Grundlagen". Mehr hast du hier auch nicht gekriegt. Hier ist ein technisches Forum, keine Flauschigkeitszone. Und das ist auch gut so. :-) > Solange man aber die Register noch nicht richtig im Kopf hat is das aber > eine sehr schnelle Art erste Resultate zu erzielen, oder nicht? Solange du diese "Befehle" nutzt, wirst du die Register nie lernen. Und damit auch nie begreifen, was du da eigentlich tust. Und damit wirst du zwar Erfolge haben, aber bei komplizierteren Dingen gegen eine Wand rennen. Und vermutlich nichtmal merken, dass du in einer Sackgasse stehst und nochmal ganz zum Anfang zurueckmusst. Und du sollst nicht die Register lernen, du sollst die Ideen dahinter verstehen. Die Register sind bei jedem Chip anders, aber die Ideen nicht. >> Bei eigentlich fast ALLEN aktuellen ARM's, also Cortexen mit mehr als >> 30 MHz CPU-Takt steht als allererstes das Aufsetzen der Takte (jaja, >> Mehrzahl) auf dem Programm. > > Ok, danke für die Info, werde mich diesbezüglich informieren. Wenn du das erstmal ignorierst, hast du auf dem SAM3X 4 MHz (wenn ich mich recht entsinne). Auf anderen Chips können das auch gerne mal 32 kHz sein. > W.S. schrieb: >> Nochmal: LIES die Literatur über die Hardware! Das ist so unsäglich >> wichtig, daß man es nicht oft genug wiederholen kann. > > Hier hättest du auch noch auf etwas verweisen können. Wie der Thread > gezeigt hat und du auch selbst festgestellt hast, bin ich halt nur ein > Arduino der das alles nicht auf die Reihe kriegt. Google kaputt? Auf der Arduino-Seite gibt es eine Zuordnung von Arduino-Pin und SAM3X-Pin. Auf der Atmel-Seite gibt es ein SAM3X/A-Datasheet. Pampig werden bringt dir nix.
Ok, ich habe das Gefühl, dass ich hier einen mehrheitlich schlechten Eindruck hinterlassen habe, dass tut mir wirklich leid, entschuldigt bitte. S. R. schrieb: > Brauchst du auch nicht. Eine Frage sagt immer etwas ueber den Fragenden > aus, und deine Frage schrie jedem ein "ich habe keine Ahnung und keine > Grundlage" ins Gesicht. Absolut richtig. Doch wenn man sich mal meine ursprüngliche Frage anschaut, habe ich doch eigentlich recht klar und deutlich gesagt, was ich wissen will und habe auch gesagt, dass ich keine Ahnung habe. Ich weiss jetzt wirklich nicht genau, was da so verkehrt ist. Habt ihr nicht auch mal klein angefangen? Und bei dem Statement zu Arduino bleibe ich auch. In diesem Forum wird jedem schnell klar, dass einem hier keiner zu Arduino rät. Was soll man dann sagen? Verschweigen, dass man damit gearbeitet hat? Ich finde mit Arduino gearbeitet zu haben, ist doch wenigstens ein ganz bisschen Ahnung. Mir ist auch klar, dass man in einem Forum immer auch die persönliche Meinung eines jeden zu hören bekommt, jedoch finde ich, dass man dann wenigstens auch Bezug auf die ursprüngliche Frage nehmen kann. Felix
> Ok, ich habe das Gefühl, dass ich hier einen mehrheitlich > schlechten Eindruck hinterlassen habe, dass tut mir wirklich > leid, entschuldigt bitte. Bei mir hast du keinen schlechten Eindruck hinterlassen. Schlechte Laune kriege ich in anderen Threads. ;-) > Absolut richtig. Doch wenn man sich mal meine ursprüngliche Frage > anschaut, habe ich doch eigentlich recht klar und deutlich gesagt, was > ich wissen will und habe auch gesagt, dass ich keine Ahnung habe. Hmm, ich habe den Anfang gepflegt ignoriert und mich erst ab dem Beitrag mit "Datum: 06.10.2015 16:22" eingeklinkt. Vorher war's eher nicht interessant, und ab da war eigentlich klar, dass du nicht zwischen Arduino und Mikrocontroller unterscheidest. Das Problem mit Arduinos ist nicht die Hardware. Es ist die Denkweise, also ein Fokus auf Ergebnisse statt auf Funktionsweise. Diese Weltsicht, die von Arduino gepflegt wird, ist hier äußerst unbeliebt. Wenn du einen SAM3X in C programmieren kannst, und das auch zeigst, dann wird dich auch niemand hauen, wenn du das auf einem Arduino machst. Aber wenn du die Arduino-Sprache dafuer nutzt, dann musst du schon einen verdammt guten Grund haben, um hier ernstgenommen zu werden. > Habt ihr nicht auch mal klein angefangen? Ja. Und zumindest ich fuehle mich noch lange nicht groß und lerne ständig dazu. > Ich finde mit Arduino gearbeitet zu haben, ist doch wenigstens ein ganz > bisschen Ahnung. Nee, ist es eben nicht. Das ist ja das Problem damit. Arduino ist wie Lego, du baust aus fertigen Bauteilen und Bibliotheken dein Dingens zusammen. Und dem System ist wichtig, dass du nicht weißt, wie es funktioniert, denn das wuerde dich von deinem Ergebnis ablenken. Die wichtigen Informationen siehst du dadrin nicht. Ein bisschen wie Matlab: Da kannst du auch tolle Matrixoperationen mit einem Einzeiler machen. Nur weißt du dann trotzdem nicht, wie Matlab das jetzt gemacht hat. Spielt meistens keine Rolle, wenn du nur das Ergebnis brauchst - aber um sinnvoll an größeren Dingen zu arbeiten, musst du genug Hintergrundwissen haben, um das Ergebnis auch selbst produzieren zu können. Und wenn du die Stufe erreicht hast, kannst du auch problemlos Matlab benutzen. Oder Arduino. Denn dann weißt du auch, was diese Tools nicht können. > Mir ist auch klar, dass man in einem Forum immer auch die persönliche > Meinung eines jeden zu hören bekommt, jedoch finde ich, dass man dann > wenigstens auch Bezug auf die ursprüngliche Frage nehmen kann. In der Logik gilt: Aus Falschem folgt Beliebiges. Und die Grundantwort hier war immer: "Deine Prämisse ist falsch, also ist deine Frage sinnlos, also besorge die erstmal die Grundlagen und komme dann wieder."
Lass dich nicht niedermachen. Fakt ist: Du wirst dich auf einen Hersteller einschießen müssen. Schau dir dessen SDKs an und mit welchen du am schnellsten warm wirst. Achte auch darauf, welche uCs etwas Unterstützung der User haben. Und: Viel Erfolg :)
Ich habe eigentlich nicht nur Arduino-Libarys verwendet, sondern auch Timer-, oder Pin-Register angesteuert...aber egal. Ich bin also jetzt bei null, ok :) Dann ist der konkrete Tipp jetzt also? Das Datenblatt eingehend studieren. Auswendig lernen wie ein Prozessor Befehle entgegennimmt, wie die Busse oder Memoryregister funktionieren, etc. also einfach alles?
Felix C. schrieb: > Das Datenblatt eingehend studieren. Auswendig lernen wie ein Prozessor > Befehle entgegennimmt, wie die Busse oder Memoryregister funktionieren, > etc. also einfach alles? Auswendig lernen nur Mediziner und Geisteswissenschaftler. Fuer dich reicht Verstehen. ;-) Ich habe leider kein gutes Buch zur Empfehlung. Unser Lehrbuch hier ist eher mäßig, dafuer aber teuer. Aber im Prinzip ist das alles nicht so schwer. Am Anfang steht die Interrupt-Vektortabelle. Der erste Eintrag gibt den Anfangswert fuer SP (Stack Pointer) an, der zweite Eintrag gibt den Anfangswert fuer PC (Program Counter) an. Ab der dort angegeben Adresse fängt der Prozessor an, Befehle auszufuehren. Wirf einen Blick auf die Memory Map (Datenblatt unter "Product Mapping"). Da kriegst du eine Uebersicht, wie der 32-Bit Adressraum aufgeteilt ist und was es da wo gibt. Der Prozessor kann Befehle aus dem Flash (ab Adresse 0x00080000) oder aus dem SRAM (ab Adresse 0x20000000) ohne weiteres ausfuehren. Wie du die Daten da hinkriegst, hängt von deiner Umgebung ab - wir nutzen in der Uni Keil und JTAG. Die PIO-Blöcke nutzt du zum GPIOs ansteuern, und die sind etwas nervig gebaut. Wenn du lieb fragst, kann ich dir mal ein Minimalprojekt zusammenbasteln, was die LED auf dem Ding blinken lässt.
So, ich hab meine Bastelei mal ordentlich verpackt. "make all" baut eine Binärdatei, die du an die richtige Stelle tun musst. Dann blinkt eine LED. Anmerkungen: (a) Der Startup-Code ist relativ primitiv, und in C. (b) Ich habe keinen ordentlichen Register-Header von Atmel gefunden, also habe ich mir den Kram selbst nach Datenblatt geschrieben. Da sind also nur die Beschreibungen fuer WDT, SUPC, PMC und PIO drin, kein CMSIS. (c) Interrupts funktionieren, habe ich getestet. (d) Fuer "make flash" musst du JLinkExe (plus .so) von Segger runterladen und reinkopieren, und natuerlich einen J-Link haben. Ansonsten musst du die Datei irgendwie anders flashen. Viel Spaß.
:
Bearbeitet durch User
Vielen vielen Dank S.R. werde mich nochaml melden wenn ich es mir genauer angesehen habe.
Ein Unterschied zwischen vielen 8/16-Bit Architekturen und Controllern mit extern eingekauftem Kern (das betrifft sämtliche ARMs und MIPS, also zB auch PIC32) ist die Integration der Peripherieregister. Bei AVR und PIC hast Du beispielsweise Bit-Befehle, die atomar Bits in Prozessor- und Peripherieregistern ändern können. Atomar heißt wortwörtlich "unteilbar", d.h. es ist unter allen Umständen gesichert, dass dieser Befehl an einem Stück in einem Zyklus ausgeführt wird. Das geht genau deswegen, weil Peripherieregister oder SFRs quasi das gleiche wie Prozessorregister sind. Bei ARM und MIPS geht das nicht. Der zugekaufte Prozessorkern hat definierte Schnittstellen, und alles, was darüber geht, sind Zugriffe auf externen Speicher. Das Setzen eines Bits erfordert also mindestens drei Befehle: 1. Wert aus Speicher in Register laden 2. Bit in Register setzen 3. Wert aus Register in Speicher schreiben Es ist offensichtlich, dass das jetzt nicht mehr atomar ist, weil die ganze Prozedur durch Interrupts, DMA-Zugriffe etc unterbrochen werden kann. Um das doch realisieren zu können, gibts das sogenannte Bit-Banding. Heißt also: Schreibzugriffe auf bestimmte Adressräume bedeuten nicht mehr *a=x in C-Notation, sondern *a|=x oder *a&=(~x) oder *a^=x. Und noch eines musst Du wissen: Die Chiphersteller haben durchaus die Möglichkeiten, den zugekauften ARM-Kern zu parametrisieren. Beispielsweise ob der Multiplizierer schnell oder klein (Chipfläche) sein soll, ob ein Dividierer in Hardware drin sein soll, wie viele Interrupt-Ebenen der Interrupt-Controller bei Cortex M haben soll, ob ein M4 mit oder ohne Floating-Point Einheit sein soll, wie groß das TCM (Tightly Coupled Memory, das ist übrigens der einzige Speicher, der überall gleich ist) sein soll und ob überhaupt welches da sein soll, etc. Das Problem ist also die Vielfalt. Flash und On-Chip-RAM außer TCM ist im Übrigen überall anders, weswegen jeder Chip andere Programmierverfahren braucht. Letztendlich ist das, was Du da baust, eh wieder hersteller- und chipabhängig. fchk
Bitte 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.