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
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.
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 :-)
