Hallo liebes Forum! In den letzten Wochen habe ich mich etwas in die Materie eingearbeitet und auch schon ein paar kleinere Projekte (hauptsächlich Übungen mit limitiertem Realnutzen wie adc, uart, i2c, diverse Sensoren auslesen, aber auch eine Phasenanschnittsteuerung mit LCD Statusanzeige, etc.) verwirklicht. Als programmer hatte ich ein altes Stk500 zur Verfügung, als IDE kam erst Eclipse zum Einsatz und später das Atmel Studio - nur wegen des inkludierten Simulators, ansonsten würde ich mir die Windows VM gerne sparen. Nun möchte ich in näherer Zukunft einige etwas anspruchsvollere Projekte (BLDC sensorless z.B.) angehen und kann jetzt schon absehen, dass ich dazu doch richtiges 'on chip debugging' benötige. Auch wenn die 8-bit chips sicher leistungsfähig genug dafür wären, so ärgere ich mich doch über die Firmenpolitik das JTAG Protokoll der avr geschlossen zu halten und somit die Leute zur Nutzung ihres Atmel Ice zu zwingen. Daher tendiere ich mittlerweile dazu mir ein Segger J-Link und ein paar NucleoBoards (M0 und auch ein M4F) zu besorgen und auf stm32 umzusteigen - auch wenn das noch mal Lernaufwand bedeutet. Jetzt meine konkreten Fragen: Ich möchte gerne Eclipse, das Gnu Arm Plugin und das StmCube Framework benutzen. Spricht da etwas dagegen? Oder generell gegen mein Vorhaben von avr auf arm umzusteigen? Was für ein Kabel brauche ich um den J-Link und das NucleoBoard zu verbinden, nehme ich JTAG oder SWD? Habt ihr noch andere Hinweise? Was soll ich auf keinen Fall vergessen, wenn ich meine Bestellung bei RS aufgebe? Vielen lieben Dank! Paul
Ja, die ganzen SAM Controller habe ich auch schon gesehen. Ist mir eigentlich auch egal ob Microchip oder ST, habe mich jetzt eben in meinen Recherchen auf stm32 konzentriert. Gibt's zu den SAM auch ein kostenloses HAL? Gibt's da sonst Argumente für SAM und gegen stm32 oder andersherum (aus der Sicht eines Umsteigers von avr). Als programmer/debugger dürfte der J-Link ja für beide geeignet sein - oder kocht Microchip bei den SAMs auch sein eigenes closed source Süppchen?
Paul S. schrieb: > (BLDC sensorless z.B.) Wer sowas vorhat, liest sowieso das Reference Manual und kann direkt mit der Hardware sprechen. Ein "Hardware Abstraction Layer" stört dabei nur und kostet mehr Einarbeitungszeit. > Oder generell gegen mein Vorhaben von avr auf arm umzusteigen? ARM und besonders die STM32 sind heute dermaßen "in", dass das ein Gegenargument sein könnte ;) Andererseits ist Atmel aufgekauft worden... > nehme ich JTAG oder SWD? Die kleineren Chips haben nur SWD. Auf dem "genormten" Cortex-M-Debug-Stecker (10-polig, RM 1.27) sind beide Schnittstellen drauf. Weder Segger J-Link noch die STM-Demo-Boards haben diesen Stecker. Von Segger gibt es natürlich ein Adapterkabel. SWD ist von ARM und gehört zum Cortex-M Kern. JTAG auch, aber da kann sich der Chip-Hersteller eher einmischen. Wenn ein Programm wirklich rechnen muss, sind die M0 ohne Hardware-Division klar im Nachteil. Die M0+ haben wenigstens eine MPU und können die Vektortabelle ins RAM verlegen. Die (hier im Forum) beliebtesten STM32F1xx sind die allererste Generation. Bei den nicht ganz so alten STM32F2, F3 und F4 merkt man deutlich, dass ST dazu gelernt hat. Die dritte Generation, die L0, L1, L4, ist nochmal besser geworden, besonders die internen Oszillatoren und die Leckströme, aber auch die EMV-Eigenschaften. Bei den noch neueren G0 und G4 gibt es besonders kleine Gehäuse, aber sonst fällt mir nichts ein. > Daher tendiere ich mittlerweile dazu mir ein Segger J-Link... Vom Werbetext her gefällt mir die Black Magic Probe besser. Die kann vielleicht etwas nicht, weil es noch niemand gebraucht hat, aber die billigen Geräte von Segger können manche Sachen absichtlich nicht. Teile wie ST-Link können aber mit beiden nicht mithalten.
Vielen Dank, Bauform B! Das war schon mal sehr hilfreich! Ja, habe heute mal die Dokumentation vom HAL überflogen...fast 1900 Seiten. Vielleicht überwiegt da der Aufwand zur Einarbeitung wirklich den Nutzen! Die Black Magic Probe werde ich mir mal ansehen.
Bauform B. schrieb: > Vom Werbetext her gefällt mir die Black Magic Probe besser. Den kann ich zwar nicht mit den Seeger vergleichen (nie gehabt), aber beim BMP vermisse ich nichts. Arbeitet bei mir super mit McuXpresso (für LPC, basierend auf Eclipse) zusammen. STlinkV2 clones gibt es im schicken Alugehäuse für'n Appel und nen Ei in der Bucht. Da macht man dann BMP drauf und hat einen super Debugger. Hier habe ich mich mal darüber ausgelassen: Beitrag "LPC debuggen mit Black magic probe auf STlinkV2 clone"
:
Bearbeitet durch User
CubeMX-IDE + ST-LinkV3 ist die Kombi, die man für die STM32 uCs braucht. SWD und JTAG werden unterstützt. Die Einarbeitung in CubeMX/HAL dauert etwas, aber man kommt schnell weiter, auch bei komplexeren Funktionen. Für ATSAM gibt es ASF, Doku grausam undurchsichtig, genau so wie das Online Konfigurationswerkzeug Atmel Start
Nucleo und Discovery boards von STM haben alle eine ST-link die ueber USB-micro/mini laufen. Brauchen sie nur ein standard USB kabel. Bei die meiste lauft ueber diese Schnittstelle sogar auch noch eine Virtual Com port.
genau, die Debug/Flash Hardware haben die an Board und die reicht für die ersten und zweiten Gehversuche allemal. Wenn man bastelwütig ist kann man die auch auf BMP oder eine J-Link (light) Version umflashen, ist aber mittlerweile auch nicht mehr unbedingt nötig. Was man nicht machen sollte ist den Debugger von einem Nucleo abzutrennen, ausser das soll als fertiges Gerät in ein Gehäuse. Da gibt es nämlich keine Steckverbinder um den einfach wieder anzuschliessen. Für andere Boards ist dann so ein low cost BMP ganz praktisch. Und auch wenn es viele andere Hersteller für Cortex-M gibt, im Hobbybereich haben sich die STM32 sehr breit gemacht. ST hat das aggressivste Marketing und viele Nucleo/Discovery für kleines Geld in den Markt geworfen. Auch einzelne Chips sind gut verfügbar (mittlwerweile muss man allerdings aufpassen das einem nicht Fälschungen angedreht werden). Und an SW hat ST auch alles für den Einstieg und Privat kostenlos (gegen Registrierung) im Angebot.
Paul S. schrieb: > Daher tendiere ich mittlerweile dazu mir ein Segger J-Link und > ein paar NucleoBoards (M0 und auch ein M4F) zu besorgen und auf stm32 > umzusteigen Alle Nucleo Boards enthalten bereits einen ST-Link Adapter. Den J-Link brauchst du daher nicht - es sei denn du willst dich speziell mit dem J-Link vertraut machen. Du kannst den Chip über beide Schnittstellen programmieren und debuggen. Angeblich ist SWD schneller, habe ich irgendwo mal gelesen. Aber ich weiss es nicht, denn JTAG habe ich noch nie benutzt. Bisher konnte ich mit der schlankeren SWD Schnittstelle alles machen, was ich wollte. > Was für ein Kabel brauche ich um den J-Link und das NucleoBoard zu > verbinden, nehme ich JTAG oder SWD? STM32 Controller haben beide Schnittstellen. Bei den Nucleo Boards sind sie allerdings beide nicht auf separate Stecker herausgeführt. Das heisst: Du brauchst lose Dupont Kabel. > Was soll ich auf keinen Fall vergessen, > wenn ich meine Bestellung bei RS aufgebe? Ein zweites Nucleo-Board als Ersatz und zum Vergleichen dazu kaufen. Dann suchst du dir nicht einen Wolf, wenn eventuell das Board kaputt gegangen ist. Ich würde Dir empfehlen, nicht gleich mit einem fetten F7xx anzufangen. Die L0 Serie ist für den Anfang ganz angenehm, nur für diese gibt es von ST Code-Beispiele die ohne Cube HAL laufen und daher leichter nachvollziehbar sind, wenn man sich mit den Registern vertraut machen will. Wenn die die L0 Serie zu klein ist, nimm einen aus der F3 Serie, die sind auch noch überschaubar und haben sogar eine FPU. > Ich möchte gerne Eclipse, das Gnu Arm Plugin und das StmCube > Framework benutzen. Spricht da etwas dagegen? Die Cube IDE ist Eclipse und hat das alles schon drin. > Ja, habe heute mal die Dokumentation vom HAL überflogen... > fast 1900 Seiten. Und das ist noch nicht alles. Zusätzlich musst du das Referenzhandbuch der Serie lesen, und das Datenblatt des konkreten Chips. Das sind nochmal über 1000 Seiten. Du wirst die HAL nicht richtig anwenden können, solange du mit dem Funktionsumfang deines Mikrocontrollers nicht halbwegs vertraut bist. In der HAL sind zahlreiche Konstanten definiert, deren Bedeutung du nur im Referenzhandbuch des Chips erklärt findest. Als Einstieg zum Lernen empfehle ich Dir http://stefanfrings.de/stm32/index.html
Paul S. schrieb: > Gibt's zu den SAM auch ein > kostenloses HAL? Natuerlich. Ist alles bei der Atmel Studio Installation dabei. Paul S. schrieb: > oder > kocht Microchip bei den SAMs auch sein eigenes closed source Süppchen? Nein.
Paul S. schrieb: > Vielen Dank, euch allen! Was ich noch erwähnen möchte: Die meisten Videos/Tutorials/Anleitungen beschreiben, wie man die Pin Konfiguration des STM32 mit der CubeMX GUI durchführt, und am Ende CubeMX dazu verwendet, die Peripherieinitialisierung mittels automatischer Codeerzeugung zu erhalten. Ich selbst halte davon wenig, weil viel unnötiger Code erzeugt wird, der für die ersten Gehversuche völlig überflüssig ist und nichts zu beiträgt. Ich würde daher empfehlen, so wenig wie möglich CubeMX als Hilfstool zu benutzen. Gleiches gilt für die HAL und LL Libraries. Ich empfehle wirklich, die einzelnen Register selbst anzusprechen. Da sieht man auch sehr viel schneller, welches Bit im Register welchen Einfluss hat. Mir hat es enorm geholfen, die Architektur des STM32 besser zu verstehen und eine PWM zu generieren. Gruß,
Alex schrieb: > Ich würde daher empfehlen, so wenig wie möglich CubeMX als Hilfstool zu > benutzen. Gleiches gilt für die HAL und LL Libraries. Hallo Alex! Ja, genau das war auch der Tenor diverser Artikel, die ich auf stackoverflow und anderen US Seiten gefunden hatte. Ganz lieben Dank nochmals!
Man kann sich aber auch freuen das die CM soviel Power und Resourcen haben das man nicht alles dem Performancegott opfern muss und ordentliche OS incl. RT und Ethernet/USB/GUI verwenden kann ohne angeflanschte Hilfsprozessoren.
Hallo, einen schnellen ARM-Einstieg gibt´s auch noch mit Teensy. Sehr bastlerfreundliche Platinen. Ich habe einen 3.5er und eine Hand voll 4.0er, allerdings alle noch in der Testphase. Da braucht man nur ein USB-Kabel und kann loslegen. Die FPU vom 4er (Cortex M7 mit 600MHz) macht sogar 64 bit double. Hab da mal ein paar kleine Benchmarks gemacht (SIN/COS/WURZEL ziehen). Schon erstaunlich was man damit in Echtzeit machen kann ;-) Der 3.5 er ist 5V tolerant. Die Arduino-IDE funktioniert für ein paar Tests reibungslos, mehr als ne blinkende LED sollte man aber dann doch eher mit Visual Studio machen. https://www.pjrc.com/store/teensy40.html Gibt´s aber auch mittlerweile bei den üblichen dt. Distributoren. Gruß Dominik
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.