Hallo, nachdem ich nun seit einiger Zeit mit AVR arbeite habe ich mich auch von dem Angebot von STM verleiten lassen und mir das M3-STM32-dicovery-Board besorgt. Als IDE verwende ich die code-beschränkte Version von Keil. Nachdem erste Leds zum Blinken gebracht werden konnten, wollte ich das Beschreiben der GPIO-Register testen und habe mal eine 8x8 Led-Matrix an den GPIOA gehängt und ein gemultipextes Standbild erzeugt. Das jedoch klappt nicht so recht. Da die Pins von GPIOB sehr "unglücklich" angeordnet sind, bleiben nur noch GPIOA und GPIOC als vollständige Ports zum Versuch übrig. Alle Ports wurden über die ST-Library-Funktionen ordnungsgemäß konfiguriert und initialisiert. Auch der Clock für die Ports wurde aktiviert. Bei GPIOA scheinen die Pins a13 und a14 vom ST-Link belegt zu sein. Ich kann mit diesen Pins arbeiten, wenn ich nach einem Reset über die ST-Software die Verbindung zum ST-Link aktiv trenne. Pin a15 hingegen ist stets unansteuerbar. Laut Schaltplan gibt es hierfür eigentlich keinen Grund. Port GPIOC hat das Problem, dass offensichtlich die Pins c14 und c15 zugunsten des Uhrenquarzes deaktiviert sind. Auch nicht schön. Könnt Ihr mir eventuell erklären, warum Pin a15 generell nicht zu funktionieren scheint und wie ich auch ohne aktives Eingreifen die Pins a13 und a14 als Ausgänge verwenden kann? Mit Gruß Mike
Hast Du schonmal in den Schaltplan geschaut? Kannst Du uns einen Link zum Schaltplan posten? Grüße Sven
Hi Mike, schön zu hören, dass es noch andere Umsteiger gibt. Bin gerade selber mitten drin und ich benutze auch das STM-Discovery.. Dein Problem liegt darin, dass die Pins PA13-PA15 für das Debugging verwendet werden. Genauer gesagt für JTAG und SWD. Im Reset-Zustand sind diese aktiv. Um sie jetzt benutzen zu können musst du die Debugging-Funktione deaktivieren. Dafür musst du die SWF_CFG im AFIO_MAPR Register ändern (siehe Reference Manual RM0041). Das wird bestimmt auch über die Library gehen, aber da müsstest du mal selber schauen.. Das Problem dabei ist jedoch, dass PA13 und PA14 vom SWD verwendet werden, wenn du die Funktion also deaktivierst, dann sperrst du den ST-Link aus. Vielleicht könnte man aber den seriellen Bootloader starten (BOOT-Pin) und und könntest dann SWD über den ST-Link nutzen. Nur so eine Idee, keine Ahnung ob das geht... Schöne Grüße Jan
Hallo, vielen Dank für die Antworten. Ja, das die Pins a13 und a14 mit dem Debugger verbunden sind, geht auch aus dem Schaltplan hervor. A15 hingegen wird laut Plan nicht verwendet. Der entsprechende Schaltplan findet sich in der UM0919 auf Seite 20. Das ist unschön, da somit für das Steckbrett nicht ein einziger vollständiger Port als IO zur Verfügung steht. Selbst aus dem GPIOB ist ein Pin @Jan: wie sind deine bisherigen Erfahrungen mit dem STM32? Arbeitest du eher registerorientiert oder mit der ST-Library? Hast du schon mal etwas mit dem STM32 und Farb-LCDs gemacht? Gruß Mike
Mit dem Problem muss man bei Aufgaben, die einige externe Schnittstellen verwenden, oft leben. Es sei denn der Controller hat eine Crossbar für die Pinbelegung vieler Schnittstellenmodule (Timer, UART, ...), wie sie sich beispielsweise bei den PIC24/33 findet. Feste Pinzuordnungen sind immer unglücklich, für 8 von 10 Anwendern. Hier kommt dazu, dass der gleiche Chip in teilweise 4 Gehäusen mit unterschiedlicher Pinzahl steckt und man zwar Ports weglassen kann, aber nicht in gleichem Mass die Pins von Schnittstellenmodulen. Was bei kleinen Gehäusen zu entsprechendem Gedränge auf den dort implementierten Ports führt, während es bei den zusätzlichen Ports des grössten Gehäuses deutlich ruhiger zugeht. Wenns partout nicht passt, dann verteilt man die selbst wählbaren Pins notfalls nach Simplizität der Verdrahtung quer über die Ports und steuert sie einzeln per Array an, so es die Laufzeit zulässt.
Der PA15 gehört zu der JTAG-Schnitstelle, die nach dem Reset standartmäßig aktiv ist. Steht auch in dem Reference-Manual (RM0041, Table 29, S.115). Meine bisherigen Erfahrungen sind recht positiv. Mit dem Atollic Studio konnte es sofort losgehen, da alles sofort lief. Bis auf den ST-Link, denn dieser verschluckt sich wenn es virtuelle Laufwerke gibt, wie zum Beispiel von den DemonTools oder TrueCrypt. Absolut keine Ahnung wieso, aber es hat mich einige Stunden gekostet um darauf zu stoßen. Ich versuche mich an der Lib, aber diese ist leider sehr grottig dokumentiert. Ich schaue mir die Hardware an und dann schau in ich der Doku der Lib (diese kompilierte HTML-Datei) an welche Funktionen es gibt. Leider sind die Funktionen wenn überhaupt nur sehr spärlich beschrieben. Also wird in den Quelltext geschaut und dort die Kommentare gelesen und teilweise nachvollzogen welche Register gesetzt werden. Also hänge ich dann doch schon recht tief in der Register-Ebene mit drin.. Dagegen ist die StellisWare (Library zu den Stellis CM3s von TI) viel besser dokumentiert. Denn dort gibt es eine PDF-Datei wo alle Funktionen detailiert beschrieben sind. Ich selber habe bisher noch nichts mit LCDs gemacht. Aber n Kollege aus Labor ist im Moment mit so einem 30$ STM32 China-Board mit Touch-LCD am spielen und es gibt schon erste Erfolge. Ich bastel an einem Über-Moodlight mit 10W RGB, CAN, DMX, UART, USB, SPI (RFM12) und Fernbedienung, bei dem ich gerade auf die Platinen warte..
Hallo, ja, auf so ein Board habe ich auch schon spekuliert. Ich war mir nur noch nicht über Qualität und Aufwand (Import) im klaren. Interessant wäre es, wenn ich an solche Displays zu dem Preis auch hier kommen könnte. Wie steht es bei diesem Board mit dem debuggen? Vermutlich muss da ein externer Debugger verwendet werden. Gibt es da evtl. preislich attraktive Konkurrenzprodukte zu ST-Link? Moodlight. Das klingt gut :) Atollic hätte ich auch gerne verwendet. Jedoch war mir die Freischalte-Orgie nicht recht. Daher verwende ich zunächst Keil. Mit Gruß Mike
Also der Aufwand des Imports ist Minimal bei Ebay kaufen, mit Paypal zahlen, sich 2-3 Wochen in Geduld üben. Es KÖNNTE sein, dass das Paket beim Zoll landet, du darfst es dann beim örtlichen Zollamt abholen und 19% Einfuhrumsatzsteuer zahlen wenn der Wert 22€ übersteigt. Debuggen geht über JTAG und SWD. Der genannte Kollege benutzt ein eingebauten JTAG-Adapter eines TI Stellaris DevBoards^^ Wenn es dich interessiert kann ich ihn Montag Abend mal nach seinen Erfahrungen mit dem Display fragen. Ich werde bei meinem Projekt den ST-Link des Discovery über SWD verwenden. Die Installation mit Freischalten bei Atollic habe ich gar nicht so schlimm in Erinnerung. Aber etwas stört gewaltig in der Lite Version: Man kann nur 1 (Einen, One, Uno, 0x01) Breakpoint setzen. Man kann nicht mal einen zweiten setzen, wenn der erste deaktiviert ist. Auf die Daten-Breakpoints könnte ich auch erstmal verzichten, aber diese Beschränkung auf einen BP nervt. Ich habe mal angefragt was denn eine Academic Lizens kostet, bin mal gespannt auf die Antwort.. Bei Keil hat man ja anscheinend nur die 32k Grenze als einzige Einschränkung. Damit sollte man ja schon relativ weit kommen. Das Problem sehe ich nur wenn die Projekte irgendwann doch mal größer werden und man doch mal an der Grenze kratzt. Laut dem was man im Netz so findet wird es dann richtig teuer und es gibt auch keinen non-profit Rabatt...
Kompromiss neben freier Software wie Yagarto und sauteurem Keil ist Rowley Crossworks. Basiert ebenfalls auf GCC. Gibts bei nichtkommerziellem Einsatz für 150$ ohne irgendwelche Begrenzungen. Mittlerweile wird sogar der ST-Link unterstützt.
Mike schrieb: > Nachdem erste Leds zum Blinken gebracht werden konnten, wollte ich das > Beschreiben der GPIO-Register testen und habe mal eine 8x8 Led-Matrix an > den GPIOA gehängt und ein gemultipextes Standbild erzeugt. Wie viele Pins "in Serie" in einem Port benötigt man da? 8 oder 16? Die Discovery-Boards von STM32 sind nun mal Eval-Board zu einem sehr günstigen Preis, das sollte man beachten. Fortlaufende Ports gibt's z. B. hier: http://www.steitec.net/ARM-Stamp-Module/ARM-STM32F103---512-Stamp.html. Hier sind PA0 - 15 an einer Seite, PB ist komplett herausgeführt, wird allerdings "umgebrochen", immerhin mit neun Pins an einer Seite. Port C ist komplett, allerdings nur bis PC13. Aber auch hier ist i. d. R. nur Port C vollständig frei, wenn man noch irgendetwas anderes machen will. Beim Nachfolger stm32f4 discovery gibt das Problem mit einem freien Port nicht, da dort das Problem besteht, freie Pins zu finden :-) Aber auch hier finde ich, dass man dies unter Berücksichtigung des Preises bewertet. Die Board sind schließlich auch Programmierer mit Debugger-Funktionaliät. Bei den atmegas wäre mir allerdings kein µC bekannt, der über einen Port verfügt, welcher 16 freie Pins hat ... Jan K. schrieb: > Ich versuche mich an der Lib, aber diese ist leider sehr grottig > dokumentiert. Ich schaue mir die Hardware an und dann schau in ich der > Doku der Lib (diese kompilierte HTML-Datei) an welche Funktionen es > gibt. Leider sind die Funktionen wenn überhaupt nur sehr spärlich > beschrieben. Also wird in den Quelltext geschaut und dort die Kommentare > gelesen und teilweise nachvollzogen welche Register gesetzt werden. Also > hänge ich dann doch schon recht tief in der Register-Ebene mit drin.. Kenn' ich irgendwo her :-) Man muss sie ja nicht einsetzen. Ich hole mir auch oft die Register heraus oder lese an den asserts, welche Werte Sinn machen. Eine Warnung steht ja auch groß in jedem header: "FOR GUIDANCE ONLY" :-) Z. B. bei UART und CAN stehen im .c - File auch die Initialisierung im Kommentar m. E. besser als im Datenblatt. Mike schrieb: > Atollic hätte ich auch gerne verwendet. > Jedoch war mir die Freischalte-Orgie nicht recht. Daher verwende ich > zunächst Keil. Jan K. schrieb: > Bei Keil hat man ja anscheinend nur die 32k Grenze als einzige > Einschränkung. A. K. schrieb: > Kompromiss neben freier Software wie Yagarto und sauteurem Keil ist > Rowley Crossworks. Basiert ebenfalls auf GCC. Gibts bei > nichtkommerziellem Einsatz für 150$ ohne irgendwelche Begrenzungen. > Mittlerweile wird sogar der ST-Link unterstützt. Bei beiden stm32-Discovery-Boards geht es auch "klassisch". Aktuell mit "summon-arm-toolchain" (verwendet das Linaro-Paket) kein größeres Problem, in beiden Fällen gelingt auch die gdb-Anbindung. Es ist halt am Anfang mühselig, passende Startup-Codes und/oder Linker-Scripte zu suchen bzw. anzupassen und die Toolchain vollständig hinzubekommen. Längerfristig überwiegen m. E. die Vorteile, vor allem wenn man sich parallel z. B. noch mit den LPCs beschäftigen will oder einfach das "klassische" make schätzt. Mike schrieb: > wie sind deine bisherigen Erfahrungen mit dem STM32? Arbeitest du > eher registerorientiert oder mit der ST-Library? Wurde zwar nicht gefragt, bei mir ist es ein klares opportunes "sowohl als auch". Z. B. UART/CAN mit Lib, GPIO direkt. Ist doch auch mal schön, wenn man bei der UART-Initialisierung mal eine "Baudrate" direkt angeben kann.
Hat jemad schon das Board mit TFT LCD vom eBay 120778165441 für ~25€ bzw. 320742992541 oder 300583198839 oder 320774926801 ausprobiert?
Roland H. schrieb: > Wurde zwar nicht gefragt, bei mir ist es ein klares opportunes "sowohl > als auch". Z. B. UART/CAN mit Lib, GPIO direkt. Ist doch auch mal schön, > wenn man bei der UART-Initialisierung mal eine "Baudrate" direkt angeben > kann. Weshalb ich mir meine Libs lieber selber baue. Bei der dann UART, CAN, I2C für die Anwendung ziemlich ähnlich aussehen, ob das nun auf STM32, LPC2000 oder AVR ist.
A. K. schrieb: >> Wurde zwar nicht gefragt, bei mir ist es ein klares opportunes "sowohl >> als auch". Z. B. UART/CAN mit Lib, GPIO direkt. Ist doch auch mal schön, >> wenn man bei der UART-Initialisierung mal eine "Baudrate" direkt angeben >> kann. > > Weshalb ich mir meine Libs lieber selber baue. Bei der dann UART, CAN, > I2C für die Anwendung ziemlich ähnlich aussehen, ob das nun auf STM32, > LPC2000 oder AVR ist. Ja, mache ich auch so: Gleiches "interface", unabhängig vom µC oder "library". Direkte Aufrufe der stm32 library in der Applikation mache ich nicht. Bei den stm32 lasse ich mich dabei dazu verleiten, hier und da die stm library im "backend" einzusetzen, gelegentlich auch nur zur Initialisierung. Kann Zeit sparen, muss aber nicht :-) Obwohl im header behauptet wird "... AIMS AT PROVIDING CUSTOMERS ... IN ORDER FOR THEM TO SAVE TIME". In den USA könnte man das bestimmt einklagen :-)
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.