Hi, für mein aktuelles Project würde ich gerne eine SMD-Platine ätzen lassen, welche alle benötigten Komponenten enthählt, also auch den Microcontroller. Mein Projekt funktioniert derzeit mit einem Teensy 3.2. Spiele aber mit dem Gedanken auf einen ATMega zu wechseln. Ich benötige mindestens 2 Serielle Schnittstellen und einen I2C-Bus. Um alles auf eine Platine zu bekommen habe ich mir mal die Schematics für den Arduino Mega und den Teensy 3.2 angesehen. Ich bin mir noch nicht ganz sicher, wie ich alles zusammen bekomme. Ziel ist es, dass der Microcontroller einfach über USB und der Arduino IDE programmierbar ist (also wie beim normalen Teensy oder Arduino). Im späteren verlauf des Projektes will ich einen Raspberry Pi anschliesen, der dann das Programmieren für mich übernimmt (per USB oder direkt über die Seriellen Pins). Aber auch das Programmieren per USB soll mir die Entwicklung erleichtern. Ich würde im Endeffek dann den Microcontroller verwenden, welcher ein einfacheres programmieren per USB und Arduino IDE ermöglicht. Beide haben in meinem Vorhaben ihre Vor- und Nachteile - ich tendiere aber eher zum Cortex m4, da er mehr Rechenleistung hat. Folgendes habe ich bisher herausgefunden: Um die Programmierung per USB zu ermöglichen brauche ich einen passenden Bootloader, richtig? Für den MK20DX256VLH7 (mit Cortex M4-Core), wie er beim Teensy verwendet wird, gibt es einen Flash-Chip mit schon aufgespieltem Bootloader (https://www.pjrc.com/store/ic_mkl02.html). Das heißt, ich müssten diese beiden Chips einfach wie auf der Teensy Schematic (https://www.pjrc.com/teensy/schematic32.gif) zu sehen ist verbinden und es sollte Out-of-the-Box funktionieren oder? Als alternative habe ich mir den ATMega2560 angesehen. Um diesen auf meinem Board zum laufen zu bekommen müsste ich erst per ISP den Arduino-Bootloader aufspielen, ehe programmieren mit USB möglich ist, richtig? Die Schematic des Arduino Mega (https://www.arduino.cc/en/uploads/Main/arduino-mega2560-schematic.pdf) ist aber etwas verwirrend. Ich verstehe nicht so ganz warum da ein ATMega8U2 verwendet wird. Erhält dieser das zu flashende Programm per USB und Programmiert dann den ATMega2560 per ISP? Ich habe öfters den Begriff SWD gefunden. Ist das der richtige Begriff in meinem Context, also includiert er das flashen und ist es das, was Arduino und Teensy verwenden? Eine weitere Sache, die mich verwirrt ist, dass der Arduino Mega und Teensy keine USB-to-Uart Konvertoren verwenden, der Arduino Nano jedoch schon (FT232RL). Kann mir einer Sagen warum? Ist dieser z.B. beim MK20DX256VLH7 schon eingebaut? Gibt es noch weiter sachen, die ich beachten muss, wenn ich mir mein eigenes Board mit Microcontroller zusammenstelle? Sorry für meine Anfängerfragen, ich habe bisher nur die Developmentboards verwendet und es ist meiner Meinung nach ein ziemlich umfangreiches Thema, da weiß ich nicht so recht, wo ich anfangen soll. Vielen Dank für eure Hilfe. Mit freundlichen Grüßen Mick
Mick schrieb: > Erhält dieser das zu flashende Programm per > USB und Programmiert dann den ATMega2560 per ISP? IIRC ist im großen Mega ein serieller Bootloader, der 8U2 macht dasselbe wie ein USB2Serial Konverter. Ein fabrikneuer (nackter) 2560 hat den aber nicht drin, der muss per ISP aufgespielt werden. Mick schrieb: > Ist dieser z.B. beim > MK20DX256VLH7 schon eingebaut? Vieel besser: Der hat natives USB eingebaut, was wesentlich flexibler und schneller als 'ne UART Bridge ist. Leider ist USB programmiertechnisch anspruchsvoll, wenn man nicht was vorgekautes verwenden will. Bei den AVRs ist USB nur in den *U? Serien mit drin. Mick schrieb: > Ich habe öfters den Begriff SWD gefunden. Das ist die Debug Schnittstelle von fast allen modernen ARM-µC Varianten. Es gibt dafür reichlich Hardware, z.B. St-Link. Die emöglichen oft auch Debugging, was bei AVR den teuren Atmel-ICE benötigt. Keine Ahnung was davon in der Arduino-IDE funktionert - ich bin Eclipse-User.
Mick schrieb: > Um die Programmierung per USB zu ermöglichen brauche ich einen passenden > Bootloader, richtig? Ja. Manche Controller, wie manche STM32, haben den schon fix eingebaut. Mick schrieb: > Ist das der richtige Begriff > in meinem Context, also includiert er das flashen Ja. Mick schrieb: > und ist es das, was > Arduino und Teensy verwenden? Nein. Ich würde dringend dazu raten, das SWD auch zum Debuggen zu nutzen (über einen entsprechenden Adapter, wie den ST-Link wenn du dich für STM32 entscheidest) und nicht nur zum Flashen. Das geht in der Arduino-IDE leider nicht, aber in vielen anderen schon. Dies vereinfacht die Programmierung und Fehlersuche gewaltig. Damit würde sich auch der Bootloader erübrigen. Mick schrieb: > Ich verstehe nicht so ganz warum da ein > ATMega8U2 verwendet wird. Erhält dieser das zu flashende Programm per > USB und Programmiert dann den ATMega2560 per ISP? Dieser ist einfach nur als USB-Seriell Adapter programmiert, quasi als FT232-Ersatz. Die beim Teensy genutzten Freescale-Chips sind im Hobby-Bereich nicht weit verbreitet; die STM32 hingegen schon, und auch für die gibt es (teilweise) ein Arduino-Paket und viele Beispiel-Codes.
:
Bearbeitet durch User
Jim M. schrieb: > IIRC ist im großen Mega ein serieller Bootloader, der 8U2 macht dasselbe > wie ein USB2Serial Konverter. > > Ein fabrikneuer (nackter) 2560 hat den aber nicht drin, der muss per ISP > aufgespielt werden. Niklas G. schrieb: > Dieser ist einfach nur als USB-Seriell Adapter programmiert, quasi als > FT232-Ersatz. Verstanden, vielen Dank. Jim M. schrieb: > Vieel besser: Der hat natives USB eingebaut, was wesentlich flexibler > und schneller als 'ne UART Bridge ist. Leider ist USB > programmiertechnisch anspruchsvoll, wenn man nicht was vorgekautes > verwenden will. Niklas G. schrieb: > Ja. Manche Controller, wie manche STM32, haben den schon fix eingebaut. Niklas G. schrieb: > Ich würde dringend dazu raten, das SWD auch zum Debuggen zu nutzen (über > einen entsprechenden Adapter, wie den ST-Link wenn du dich für STM32 > entscheidest) und nicht nur zum Flashen. Niklas G. schrieb: > die STM32 hingegen schon, und auch für die gibt es > (teilweise) ein Arduino-Paket und viele Beispiel-Codes. Bedeutet das, dass der STM32 mit den Arduino Libraries kompatibel ist? Das würde ich sehr bevorzugen, da ich für mein Projekt einige Arduino/Teensy-Libraries verwendet habe. Ich will mich ungern mit Timern, etc. beschäftigen müssen. Das wäre bei meinem aktuellen Kentnisstand über embedded-Entwicklung noch zu fehleranfällig und würde glaube ich nur zu Frust führen. Niklas G. schrieb: > Damit würde sich auch der > Bootloader erübrigen. Wieso würde sich der Bootloader erübrigen? Ich glaube ich verstehe das konzept von SWD etwas falsch. Ich habs mir so vorgestellt: ich schließe den USB-Anschluss direkt an USBDP und USBDM des STM32 an und es funktioniert. Ist das falsch? Würde man den ST-Link nicht auch nur an eine Serielle Schnittstelle anschliesen? Bzw. würde dieser mehr als nur TX und RX benötigen? Also mein Ziel ist aufjedenfall eine Plug and Play platine zu haben, die ich einfach ohne zusätzliche geräte flashen kann, daher würde ich Debugging ersteinmal hinten anstellen, auch wenn is hilfreich ist. Primär ist mein gedanke eigentlich, meine Platine zusammen mit dem Raspberry in einem gehäuse zuhaben, dass ich nicht öffnen muss, um neue Software aufzuspielen Da wird das mit dem Debuggin vermutlich sowieso schwirig. Der STM32 klingt aufjedenfall interessant und ich habe mir mal ein paar angesehene. Kannst du mir sagen, auf was ich beim Kauf achten muss, dass der korrekte Bootloader schon vorinstallier ist? Die STM32F103 Serie sieht ganz gut aus. Ich habe folgendes gelesen: All STM32 microcontrollers contain a standard bootloader preloaded by ST Microelectronics. The standard ('factory', 'native', 'STM') bootloader is always available -- being stored in read-only memory -- and cannot be modified or deleted. You can access it by configuring the boot pins high or low, and then powering (or resetting) the MCU. Through the standard bootloader you can upload firmware to the MCU. This can either be an application (Arduino sketch) or another 'non standard' bootloader with more features. (Quelle: http://wiki.stm32duino.com/index.php?title=Bootloader) Das klingt eigentlich genau nachdem was ich suche. D.h. ich muss mich um den Bootloader an sich nicht mehr kümmern, da das aufspielen über USB direkt funktionieren sollte oder? (Mit dem Standard-Bootloader) Ich denke dieser wird es: https://www.mouser.de/ProductDetail/STMicroelectronics/STM32F103CBT7?qs=sGAEpiMZZMvyL6eCuHiWihZK7s8S69p4 Angenommen ich würde folgendes Tutorial verfolgen:http://grauonline.de/wordpress/?page_id=1004 müsste ich dann den STM32duion einmal bootloader über RX-TX installieren, und kann dann meins Sketches über USBDM und USBDP flashen? Vielen dank für eure Hilfe!
Mick schrieb: > All STM32 microcontrollers contain a standard bootloader preloaded by ST > Microelectronics. nicht alle STM32 microcontroller lauschen auf allen Interfaces wenn man mit BOOT0=High startet! > Ich denke dieser wird es: > https://www.mouser.de/ProductDetail/STMicroelectronics/STM32F103CBT7?qs=sGAEpiMZZMvyL6eCuHiWihZK7s8S69p4 Der ignoriert z.B. USB!
Mick schrieb: > Bedeutet das, dass der STM32 mit den Arduino Libraries kompatibel ist? Einige Modelle ja, dafür muss man ein eigenes Arduino-Paket installieren: https://github.com/stm32duino/Arduino_Core_STM32 Probiere es aus bevor du Hardware kaufst... Mick schrieb: > Ich will mich ungern mit > Timern, etc. beschäftigen müssen. Das wäre bei meinem aktuellen > Kentnisstand über embedded-Entwicklung noch zu fehleranfällig und würde > glaube ich nur zu Frust führen. Es gibt auch noch mbed.org und die HAL-Library, die hier einiges wegabstrahieren. Mick schrieb: > Ich habs mir so vorgestellt: ich schließe > den USB-Anschluss direkt an USBDP und USBDM des STM32 an und es > funktioniert. Ist das falsch? Darüber kannst du nur flashen aber nicht debuggen, und das auch nur wenn ein Bootloader vorhanden ist (bei manchen STM32 fest eingebrannt). Mick schrieb: > Würde man den ST-Link nicht auch nur an > eine Serielle Schnittstelle anschliesen? Nein, den ST-Link schließt man an SWDIO, SWCLK und nRESET (optional noch an SWO) an - eben die SWD-Schnittstelle. Darüber kann man dann debuggen und flashen, daher kein Bootloader nötig. Das ist eben nicht nur eine simple USB-Seriell-Wandlung. Mick schrieb: > Also mein Ziel ist aufjedenfall eine Plug and Play platine zu haben, die > ich einfach ohne zusätzliche geräte flashen kann, daher würde ich > Debugging ersteinmal hinten anstellen, auch wenn is hilfreich ist. Willst du unbedingt auf die große Arbeitsersparnis des Debuggings verzichten, nur um kein zusätzliches Gerät anschließen zu müssen? Du kannst das ja auch notfalls fest verbauen, ist ja nicht teuer. Mick schrieb: > Primär ist mein gedanke eigentlich, meine Platine zusammen mit dem > Raspberry in einem gehäuse zuhaben, dass ich nicht öffnen muss, um neue > Software aufzuspielen Da wird das mit dem Debuggin vermutlich sowieso > schwirig. Auch das Entwicklungs-Exemplar auf dem du die Software testest? Das wird mühsam. Mick schrieb: > Kannst du mir sagen, auf was ich beim Kauf achten muss, dass > der korrekte Bootloader schon vorinstallier ist? Im Datasheet nach "Boot" oder "Bootloader" suchen. Der F103 ausgerechnet hat keinen USB-Bootloader... Mick schrieb: > Das klingt eigentlich genau nachdem was ich suche. D.h. ich muss mich um > den Bootloader an sich nicht mehr kümmern, da das aufspielen über USB > direkt funktionieren sollte oder? (Mit dem Standard-Bootloader) Ja. Aber eben nicht debuggen. Und besonders stabil ist der Standard-Bootloader leider auch nicht... Mick schrieb: > Angenommen ich würde folgendes Tutorial > verfolgen:http://grauonline.de/wordpress/?page_id=1004 > müsste ich dann den STM32duion einmal bootloader über RX-TX > installieren, und kann dann meins Sketches über USBDM und USBDP flashen? Könnte gehen, hab ich so noch nicht gemacht. Wie gesagt, ich rate dringend zum Debugger - der macht aus einem "es geht nichts und ich habe keine Ahnung warum" ein "Variable x ist in Zeile 27 um 1 zu groß".
Niklas G. schrieb: > Es gibt auch noch mbed.org und die HAL-Library, die hier einiges > wegabstrahieren. Danke für die Info, ich werds mir ansehen. stm42 schrieb: > Der ignoriert z.B. USB! Niklas G. schrieb: > Im Datasheet nach "Boot" oder "Bootloader" suchen. Der F103 ausgerechnet > hat keinen USB-Bootloader... "The bootloader embedded in STM32F10xxx devices supports only one interface: the USART1." (Quelle: https://bin.jvnv.net/f/Qjbxx) Das bedeutet ich müsste erstmal über SUART wie in dem tutorial das ich gepostet habe den bootloader flashen oder, aber dann sollte es gehen? Niklas G. schrieb: > SWDIO, SWCLK und nRESET (optional noch an SWO) ... bzw. über diese Pins mit dem ST-Link oder? Ich gebe dir Recht mit dem debuggen, es ist wirklich sehr hilfreich. Ich denke ich werde auf meinem Board Pinheader dafür vorsehen. Aber schön wäre es trotzdem, wenn ich bei kleinen Änderungen das gehäuse nicht öffnen müsste. Habt ihr alternative Vorschläge, welcher statdessen gut wäre? Niklas G. schrieb: > Probiere es aus bevor du Hardware kaufst... Ja da hast du eigentlich recht, bis grade wusste ich aber leider nicht wie. Mir ist aber gerade eingefallen, dass ich eine Adapterplatine bestellen könnte. Der STM32 hat einen intenern 8Mhz oscillator, das heißt wenn ich nur das flashen testen will, benötige lediglich die richtige Spannungsversorgung oder übersehe ich was? Sorry für meine vielen Anfängerfragen - für mich ist das alles noch Neuland und ich bin sehr unsicher im Umgang mit Datasheets, etc. Danke für die ausführlichen Antworten und Geduld.
Mick schrieb: > Das bedeutet ich müsste erstmal über SUART wie in dem tutorial das ich > gepostet habe den bootloader flashen oder, aber dann sollte es gehen? Müsste... habe das noch nicht gemacht. Mick schrieb: > Habt ihr alternative Vorschläge, welcher statdessen gut wäre? Kommt drauf an was für Peripherie du brauchst. Das Tool STM32CubeMX hat eine parametrische Suche. Mick schrieb: > Der STM32 hat einen intenern 8Mhz oscillator, das heißt wenn ich nur das > flashen testen will, benötige lediglich die richtige Spannungsversorgung > oder übersehe ich was? Der interne Oszillator ist zu ungenau für UART und USB. Bei einigen der neueren STM32 geht USB ohne Quarz, schau im Datenblatt... Es gibt aber Minimal-Boards wo praktisch nur Controller und Quarz drauf sind, z.B. die "Blue Pill" Boards.
Mick schrieb: >> SWDIO, SWCLK und nRESET (optional noch an SWO) > ... bzw. über diese Pins mit dem ST-Link oder? > Ich gebe dir Recht mit dem debuggen, es ist wirklich sehr hilfreich. Ich > denke ich werde auf meinem Board Pinheader dafür vorsehen. Aber schön > wäre es trotzdem, wenn ich bei kleinen Änderungen das gehäuse nicht > öffnen müsste. Dann pack den Debugger doch mit aufs Board. Den hier z.B.: https://github.com/ataradov/free-dap Der Hardware-Aufwand ist recht gering. Wenn Du nur einen einzigen USB-Port nach außen haben willst, dann nimm einen kleinen USB 1.1 Hub mit dazu. Z.B: TUSB2036. Da kannst Du das native USB, einen FTDI-Chip an UART1 und den Debugger anschließen. TI macht das bei einigen Lauchpad-Boards so. fchk
Frank K. schrieb: > Wenn Du nur einen einzigen USB-Port nach außen haben willst, dann nimm > einen kleinen USB 1.1 Hub mit dazu. Z.B: TUSB2036. Da kannst Du das > native USB, einen FTDI-Chip an UART1 und den Debugger anschließen. TI > macht das bei einigen Lauchpad-Boards so. Des werd ich mir mal merken. --- Ich habe gestern noch etwas recherchiert und bin auf folgendes Tutorial gestoßen. Der Raspberry PI, den ich ohnehin schon verwenden will understützt scheinbar shcon SWD und das Programmieren und Debuggen ist wohl ermöglicht, daher werde ich den USB-Anschluss wohl nur optional drauf machen. (Quelle: https://www.hackster.io/turtle-rover/wireless-programming-and-debugging-with-stm32-and-rpi-bddfa5) Vielen Dank für eure Unterstützung, ich werde das mal die Tage ausprobieren, sobald die Teile da sind.
Thread beobachten
Seitenaufteilung abschalten
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.