Hallo!
Ich habe mir ein Evalboard mit dem STM32F207VGT6 zugelegt und bin dabei
die Architektur kennenzulernen. GPIO... OK. PLL... OK.
Nun sitze ich allerdings seit > 2 Tagen am UART fest.
Hier etwas Code:
Das Ergebnis dieses Codes ist ... nichts. Die Pins kann ich manuell
schalten, wenn ich statt "GPIO_Mode_AF" "GPIO_Mode_Out" verwende, d.h.
es sind die richtigen Pins. Aber warum sendet die Uart nichts?
Phantomix Ximotnahp schrieb:> und bin dabei die Architektur kennenzulernen.
Hallo du Phantomas..
warum schreibst du bloß so einen aufgedunsenen Kram zusammen? Mein Rat:
Schmeiß die ganze St-Treiberlib oder wie das Zeugs heißt weg und halte
dich an das RefManual. Was dort nicht steht, brauchst du auch nicht! Ich
hänge mal ne Konfigurations- und USART- Bedienung aus einem meiner
Projekte an. Da kannst du sehen, wie man ohne diese ganze
ST-Schaumschlägerei auskommt.
W.S.
Phantomix Ximotnahp schrieb:> Aber warum sendet die Uart nichts?
Ich glaube mich daran zu erinnern, dass man für die Alternate Function
noch den Clock frei geben muss. Hab auf die schnelle folgenden Befehl
gefunden, dann sollte es vielleicht gehen:
W.S. schrieb:> Da kannst du sehen, wie man ohne diese ganze> ST-Schaumschlägerei auskommt.
Für Einsteiger ist sie schon hilfreich um in kurzer Zeit auch
umfangreiche Schnittstellen wie CAN in Betrieb zu nehmen bzw. das
Vorgehen zu sehen und damit eine eigene Bibo schreiben zu können.
W.S. schrieb:> Mein Rat: Schmeiß die ganze St-Treiberlib oder wie das> Zeugs heißt weg und halte dich an das RefManual
Ohne das Referenzmanual geht es nicht, jedoch ist das 14 MB groß :-)
Tom schrieb:>
Nein tut mir leid aber AFIO gibt es nicht, auch nichts ähnliches
> W.S. schrieb:>> Da kannst du sehen, wie man ohne diese ganze>> ST-Schaumschlägerei auskommt.>> Für Einsteiger ist sie schon hilfreich um in kurzer Zeit auch> umfangreiche Schnittstellen wie CAN in Betrieb zu nehmen bzw. das> Vorgehen zu sehen und damit eine eigene Bibo schreiben zu können.
So war der Plan. die PLL habe ich auf diese Weise halbwegs verstanden
(im Prinzip könnt ich die benötigten Register da auch direkt setzen, an
der Stelle ist die ST library recht dünn)
W.S. schrieb:> Da kannst du sehen, wie man ohne diese ganze> ST-Schaumschlägerei auskommt.
Naja, das ist aber keine ST-Schaumschlägerei, sondern allenfalls eine
ARM-Schaumschlägerei (namens CMSIS)
>Nein tut mir leid aber AFIO gibt es nicht, auch nichts ähnliches
Ich kenn deinen STM32 jetzt nicht, aber du hast nicht zufällig
eine Remapped Pinkonfiguration ausgesucht?
Was ich noch anfügen wollte:
Wie gut es mit der Umsetzung geklappt hat, entzieht sich meiner
Kenntnis, aber die Idee von CMSIS ist nicht sooo schlecht. Wenn Du
nämlich diese Schaumschlägerei verwendest, kannst Du Deinen Code später
mit bloss sehr geringen Änderungen auf jeglichem ARM-Cortex-Derivat
irgendeines Herstellers laufen lassen.
Theoretisch. Eben - wie gut es geklappt hat, weiss ich nicht. Ich hab
irgendwann mal ganz flüchtig die Schaumschlägerei eines andern Vendors
(weiss nicht mehr welcher es war) angeschaut. Das API sah sehr ähnlich -
aber halt doch nicht ganz gleich aus.
Simon Huwyler schrieb:> nämlich diese Schaumschlägerei verwendest, kannst Du Deinen Code später> mit bloss sehr geringen Änderungen auf jeglichem ARM-Cortex-Derivat> irgendeines Herstellers laufen lassen.
Träum weiter.
Für CMSIS trifft das zu. Aber nicht für die STlib. Die ist sowohl
hersteller- wie auch familienspezifisch, ist also nicht einmal innerhalb
von ST portabel (etwa STM32 - STR9 - STM8).
Portabel sind nur jene Teile, die in der STlib auch explizit unter CMSIS
einsortiert sind. Nämlich die Interfaces für die Elemente des Cortex-Mx
Prozessors, wie beispielsweise NVIC-Steuerung und Systick.
Wie ich schon schrieb: Wie gut es geklappt hat, weiss ich nicht. Aber
die Idee war definitiv, die Peripherie aller Derivate möglichst
einheitlich abzubilden. Die STLib wurde eben deswegen komplett
überarbeitet, damit sie CMSIS-konform wurde.
A. K. schrieb:> (etwa STM32 - STR9 - STM8)
Das sind ja schliesslich auch keine Cortex.
Das hat nichts mit ST zu tun, das ist ein von ARM gepushtes API!
A. K. schrieb:> Portabel sind nur jene Teile, die in der STlib auch explizit unter CMSIS> einsortiert sind. Nämlich die Interfaces für die Elemente des Cortex-Mx> Prozessors, wie beispielsweise NVIC-Steuerung und Systick.
Das mag die Praxis sein. Das Bestreben war (laut meinen Infos) definitiv
anders.
Ich halte es für ausgeschlossen, dass man mit Aussicht auf Erfolg
Peripherie-Libraries bauen kann, mit denen sich bespielsweise die sehr
unterschiedlichen Timer von STM32, LPC1000 und anderen Cortex-M
Implementierungen unter einen Hut bekommen lassen, ohne dabei 80% der
Funktionalität der jeweiligen Peripherie zu verlieren.
Wenn ST hier etwas mit CMSIS koordiniert hat, dann wohl gewisse
Bezeichnungskonentionen und Zeugs rund um Interrupts und Startup-Code.
Das lief anfangs etwas auseinander.
Simon Huwyler schrieb:> Naja, das ist aber keine ST-Schaumschlägerei,
Das ist eigentlich egal, wer von all den Beteiligten diesen
aufgedunsenen Mist verzapft hat. Die ST-Lib macht hunderte von
überflüssigen Identifiern auf und die verschiedenen Teile der Lib
schieben sich gegenseitig überflüssige Parameter-Struct's zu, die sie
dann auch noch akribisch prüfen - aber die wirkliche praktische
Funktionalität fehlt.
Eine wirkliche Erleichterung für den Programmierer oder gar anwendbarer
Code ist das alles nicht. Es ist Bockmist (auf hohem Niveau -
sozusagen). Ich hatte das Ganze mal wegen der SDIO-Bedienung
durchgeackert und dabei rund die Hälfte des Codes ausgemistet. Ja, läuft
jetzt mit ChaN's FAT, aber zu Ende bin ich mit dem Aufräumen im
SDIO-Code noch lange nicht. Eigentlich hätte ich von ST einen wirklich
optimal geschriebenen Treiber ohne all den Schwulst erwartet, aber wie
heißt das doch: Neese!
Letztendlich ist man entweder ein Pfuscher&Dünnbrettbohrer ode man ist
Robinson, der sich alles selber machen muß.
W.S.
Schau doch mal hier rein:
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
Warum soll das so unrealistisch sein? Linux läuft schliesslich auch auf
123923 verschiedenen Graphikkarten und 213834928374987 verschiedenen
Harddisks etc.... Ok, das ist ein massiv anderer scale, aber
schliesslich handelt es sich um einen simplen HAL.
Wenn Du ein spezielles Feature eines ST brauchst, wirst Du das nie und
nimmer so mit einem ATMEL hinkriegen. Klar. Zaubern kann CMSIS nicht.
Wenn Du aber bloss ein bisschen ADC pollen willst, dann macht es doch
Sinn, dass ARM sagt: Hey, Leute, stellt doch allen Euren Kunden ein
einheitliches API zur Verfügung, die das macht. So die allgemeinen
Sachen.
Und das ist CMSIS. Wenn es nur um die Core-Peripherals ginge, wäre das
ja nicht mal erwähnenswert. Eine Einheitliche Hardware einheitlich
abbilden, dazu braucht es keinen grossen Effort! :-)
Simon Huwyler schrieb:> Das mag die Praxis sein. Das Bestreben war (laut meinen Infos) definitiv> anders.
Versuch dir einfach mal vorzustellen wie das laufen könnte. Die Chips
existieren ja schon. Nun müssten sich also Vertreter von ST, NXP, TI und
ein paar anderen Firmen zusammensetzen und einen API definieren, der
sich dem Anwender hin als von der Implementierung unabhängiges Interface
darstellt, das innerhalb der Lib dann auf die Hardware abgebildet wird.
Die würden selbstverständlich höchst eifersüchtig darauf achten, das
möglichst ihre eigene Struktur bestens abgebildet wird und den Kollegen
(=Konkurrenten) wo es nur geht Knüppel zwischen die Beine werfen.
Wenn trotzdem wider allen Erwartens alles gut geht, dann sind sie nach
etlichen Jahren mit dem ersten Entwurf fertig. Grad rechtzeitig, um ihn
dann mangels irgendeiner Bedeutung in allen Ehren zu beerdigen.
Es gibt genau ein Szenatio, wie sowas funktionieren kann: Eine neutrale
Partei hat den Hut auf und schreibt mindestens in groben Zügen vor, wie
die Peripherie auszusehen hat. Da ARM sich diesen Hut nicht aufzieht
kann das nichts werden.
Nope, sowas gibts in Form von Betriebssystemen. Ohne OS, also
hardwarenah, ist das faktisch ausgeschlossen.
>Zaubern kann CMSIS nicht.>Wenn Du aber bloss ein bisschen ADC pollen willst, dann macht es doch>Sinn, dass ARM sagt: Hey, Leute, stellt doch allen Euren Kunden ein>einheitliches API zur Verfügung, die das macht.
Dummerweise kommen die ADCs nicht von ARM.
Die fügt der jeweilige Hersteller in eigener Hardware dazu.
Schlechtes Beispiel;)
A. K. schrieb:> Da ARM sich diesen Hut nicht aufzieht> kann das nichts werden.
Wie kommst Du darauf? (ehrliche Frage, nicht rhetorisch, es interessiert
mich)
Simon Huwyler schrieb:> Warum soll das so unrealistisch sein? Linux läuft schliesslich auch auf> 123923 verschiedenen Graphikkarten und 213834928374987 verschiedenen> Harddisks etc.... Ok, das ist ein massiv anderer scale, aber> schliesslich handelt es sich um einen simplen HAL.
Ja, in dieser Dimension funktioniert das. Aber in dieser Grössenordnung
kriegst du keinen komplexen Timer vereinheitlicht, oder aber nur so,
dass 50% der Anwender es aufgrund des immensen Overheads bei der
Umsetzung eines herstellerneutralen APIs nicht nutzen können, weil zu
langsam.
holger schrieb:> Dummerweise kommen die ADCs nicht von ARM.> Die fügt der jeweilige Hersteller in eigener Hardware dazu.> Schlechtes Beispiel;)
Nö, kein schlechtes Beispiel. Du hast es nur nicht verstanden :-) Das
ist nämlich genau der Punkt. Klick auf den Link oben und lies, wie ARM
das meint.
Simon Huwyler schrieb:>> Da ARM sich diesen Hut nicht aufzieht kann das nichts werden.>> Wie kommst Du darauf? (ehrliche Frage, nicht rhetorisch, es interessiert> mich)ARM hätte es tun können. Hätte also den Lizenznehmern vorschreiben
können, wie deren UART, Timer, ADCs, CAN usw. ungefähr auszusehen
hätten.
Die Folge davon wäre gewesen, dass wir heute über den Traum eines CMSIS
für MIPS32 nachdenken würden und ARM längst Geschichte wäre. ;-)
Es liegt nämlich im ureigenen Interesse der Lizenznehmer, dass Kunden
nicht schon wegen einer 10c billigeren Konkurrenzchips abwandern,
weshalb allzu grosse Ähnlichkeit eher stört als hilft.
Wisst Ihr - ich habe mich auch schon mit dieser Schaumschlägerei
rumgeplagt und mich gefragt, warum die das denn so kompliziert machen.
Und ich schimpfte auch über ST. Bis ich mal von einem anderen Vendor
(ich glaube, es war NXP) etwas gesehen habe, das verflucht ähnlich
aussah. Und mich dann mal ein bisschen mit CMSIS beschäftigt habe.
Ich sehe das so: Es gibt sehr oft Gründe, die HW direkt anzusprechen.
Aber es gibt auch sehr oft (m.E. auch im Bare-Metal-Bereich viiiiel
öfter) Situationen, bei denen man gut damit leben kann, es halt über
einen Umweg zu machen. Sagen wir mal: 70% der HW-Zugriffe über CMSIS,
30% direkt auf die HW.
Ich denke, DAS ist die Existenzberechtigung von CMSIS. Diese 30% müssen
bei einem Proziwechsel neu geschrieben werden. Die 70% bleiben exakt
gleich.
Das ist realistisch! Man KANN über CMSIS auf die HW zugreifen! Das
funktioniert prima, auch wenn es ein bisschen umständlich ist.
A. K. schrieb:> Es liegt nämlich im ureigenen Interesse der Lizenznehmer, dass Kunden> nicht schon wegen einer 10c billigeren Konkurrenzchips abwandern,> weshalb allzu grosse Ähnlichkeit eher stört als hilft.
Guter Punkt. Aber wenn die einzige Diversifizierung in der Art besteht,
mit der Standardzugriffe (z.B. einzelner ADC-Wert einlesen), dann kann
das ja auch nicht der Sinn der Sache sein?)
Simon Huwyler schrieb:> Klick auf den Link oben und lies, wie ARM das meint.
In der dort beschriebenen CMSIS 2.0 werden m.W. ausschliesslich die
"Core Peripherals" über Funktionen bedient, und periphierieunabhängiger
Kram wie DSP. Diese Core Periperals sind jene eben Teile wie NVIC und
Systick, die als Bestandteil des Cortex-M Cores automatisch integriert
sind.
Der übrige herstellerspezifische Kram kommt effektiv nur als XML-File
vor, vermutlich um Debuggern das Leben zu erleichtern.
Dann schau doch mal das blaue Kästchen unten rechts an!
"The CMSIS has been developed in close partnership with several key
silicon and software vendors. This collaboration, together with feedback
from previous solutions, has resulted in an easy-to-use and
easy-to-learn programming interface for Cortex processor-based devices.
Current CMSIS Partners include:"
Dann kommen viele Labels von Vendors.
Glaubst Du, die haben alle über die Core-Peripherals geplaudert, die von
ARM eh vorgegeben ist?
Simon Huwyler schrieb:> Die 70% bleiben exakt> gleich.
Aber eben, wie gesagt, hier ist der Punkt, bei dem ich gestehen muss,
dass ich NICHT weiss, ob das tatsächlich so ist. Resp. ich habe bei der
(ich glaube es war) NXP-Library wiederum geringfügige Unterschiede zur
ST-Lib gesehen. Die waren so klein, dass mir klar war, dass die APIs der
gleichen Idee entstammten. Aber solche kleine fiese Unterschiede machen
das ganze Konstrukt natürlich zunichte.
Aber eben: Ich kenne im ARM-Cortex-M Segment nur ST.
Simon Huwyler schrieb:> Dann schau doch mal das blaue Kästchen unten rechts an!
Blaue Kästchen male ich dir gerne im Dutzend. Von mir aus auch verziert
mit süssen Träumen über eine Universalprogrammschnittstelle für alles
zwischen 8051 und AMD64. Schau lieber mal in die reale CMSIS 2.1
Spezifikation rein. Kann man dort runterladen. Über die
Uncore-Peripherie findest du dort exakt nichts.
Dann müsste oben die GPIO-Initialisierung "getauscht" werden, vermutlich
ist der Pull-Up "an der falschen Stelle".
Schon mal gemessen, was am TX Pin bei einer Ausgabe anliegt?
Außerdem würde um das USART_SendData "herum" das Abfragen/Prüfen mittels
USART_GetFlagStatus() nicht schaden.
Max schrieb:> Ich verwende folgende Configuration, aber sie ist für STM32F10X_MD_VL.
Leider unterscheidet sich die Programmierung der stm32f1xx und
stm32f2xx/stm32f4xx in vielen kleinen Dingen, wenn man die Library
einsetzt. USART ist in diesem Fall sogar ziemlich ähnlich/gleich, aber
GPIO ist ganz anders.
Das ist ja auch einer der berechtigten Kritikpunkte an der Library: Die
Abstraktion ist immer noch zu konkret :-)
A. K. schrieb:> Schau lieber mal in die reale CMSIS 2.1> Spezifikation rein. Kann man dort runterladen. Über die> Uncore-Peripherie findest du dort exakt nichts.
Hab ich gerade - und tatsächlich nichts gefunden. :-) Muss ich mal
genauer anschauen. Lustig ist einfach, dass a)jemand an einer Konferenz
in einem Vortrag über CMSIS das genau so beschrieben hat - und meine
Rückfrage, ob das wirklich so sei, dass Vendorunabhängig - und
unabhängig von den genauen Features einer Peripherie deren API
standardisiert werden soll, bejahte, dass b) andere Vendors wirklich
sehr sehr ähnliche APIs in ihren Libraries haben, und dass c) für sowas
soooo viele Kunden von ARM mitreden sollen.
Roland H: PD5 ist TX und PD6 ist RX. Das sagen mir zumindest
- das Datenblatt Seite 45
- der STM MicroXplorer
- der Schaltplan vom evalboard
- mein Oszi
- An der UART hängt eine USB-to-UART-bridge die funktioniert und an PD6
kommen von aussen Daten an
glaubs mir, das hab ich 10x geprüft, leider
Der Code von dir und von Max ist auch recht nützlich
Zum Thema AFIO: scheint so als gibt es das nur in der stm32f1xx-Serie,
nicht mehr bei der 2xx-Serie.
@ W.S.
>Ich hatte das Ganze mal wegen der SDIO-Bedienung>durchgeackert und dabei rund die Hälfte des Codes ausgemistet. Ja, läuft>jetzt mit ChaN's FAT, aber zu Ende bin ich mit dem Aufräumen im>SDIO-Code noch lange nicht.
Die >4GB Falle in der SDIO Lib schon gefunden;)
Simon Huwyler schrieb:>> (etwa STM32 - STR9 - STM8)>> Das sind ja schliesslich auch keine Cortex.
Als ob es bei einem API für den Uncore ausgerechnet auf den Befehlssatz
oder den konkreten Core ankäme. Das wär bei diesem Thema der
unwichtigste Teil überhaupt.
Aber das es nicht einmal innerhalb der STM32 Familie funktioniert zeigt:
Roland H. schrieb:> Leider unterscheidet sich die Programmierung der stm32f1xx und> stm32f2xx/stm32f4xx in vielen kleinen Dingen, wenn man die Library> einsetzt.
A. K. schrieb:>>> (etwa STM32 - STR9 - STM8)>>>> Das sind ja schliesslich auch keine Cortex.>> Als ob es bei einem API für den Uncore ausgerechnet auf den Befehlssatz> oder den konkreten Core ankäme. Das wär bei diesem Thema der> unwichtigste Teil überhaupt.
Da hast Du recht. Aber lies nochmal, warum ich das schrieb. Oder: Was
hat ARM mit dem STM8 zu tun?? ;-)
Simon Huwyler schrieb:> Aber eben, wie gesagt, hier ist der Punkt, bei dem ich gestehen muss,> dass ich NICHT weiss, ob das tatsächlich so ist. Resp. ich habe bei der> (ich glaube es war) NXP-Library wiederum geringfügige Unterschiede zur> ST-Lib gesehen. Die waren so klein, dass mir klar war, dass die APIs der> gleichen Idee entstammten. Aber solche kleine fiese Unterschiede machen> das ganze Konstrukt natürlich zunichte.>> Aber eben: Ich kenne im ARM-Cortex-M Segment nur ST.
Dann nimm ein stm32f1-Programm und kompiliere es mal für stm32f2/f4.
Dann nimm ein stm32-CM3-Programm und portiere es auf einen lpc CM3.
CMSIS kommt von ARM und ist "gleich", bezieht sich aber nur auf den
Kern/NIVC etc. Würde ich nicht als "peripher" bezeichnen.
Die Peripherie und die "peripheral library" kommt z. B. von NXP und STM.
Das alte IP will auch genutzt werden. Die Peripherie ist definitiv nicht
gleich.
Wie kompatibel die Peripherie innerhalb von STM32f (Cortex-M3/Cortex-M4)
ist, siehst Du an diesem Thread. Die haben es geschafft, dass die USART
Pins zwischen stm32f1/stm32f2/stm32f4 die gleichen sind (zumindest bei
den von mir eingesetzten CPUs). stm32f2/stm32f4 sind m. W. sogar "drop
in" bezüglich der Pins/Power scheme. Die Library ist viel weniger
kompatibel.
Bei NXP ist beim lpc2103 (ARM7TDMI) und lpc1343/lpc1769 (CM3) z. B. die
USART-Einstellung tupfengleich (zumindest für meine 0815-Zwecke).
Die Unterschiede in der Peripherie sind nicht klein, die sind immens.
Roland H. schrieb:> CMSIS kommt von ARM und ist "gleich", bezieht sich aber nur auf den> Kern/NIVC etc. Würde ich nicht als "peripher" bezeichnen.>> Die Peripherie und die "peripheral library" kommt z. B. von NXP und STM.> Das alte IP will auch genutzt werden. Die Peripherie ist definitiv nicht> gleich.
Auf der CMSIS-Seite zu lesen:
Chip vendors use a wide variety of on-chip peripherals to distinguish
their parts from each other. Device peripherals such as I/O Ports,
Timers, PWMs, A/Ds, or D/As can have different functions and performance
characteristics. This variety is a challenge for the software developer
and makes code reuse difficult. CMSIS addresses these difficulties by
providing a vendor-independent hardware abstraction layer with a common
approach to interface peripherals, real-time operating systems, and
middleware components across all silicon vendor products.
Die Idee hinter CMSIS ist folglich ganz klar, auch die
vendorspezifische Peripherie in der API zu standardisieren. Was für
einen Sinn macht es denn, für immer gleiche Peripherie (die
Core-Peripherie) in Zusammenarbeit mit vielen Vendors eine
standardisierte API zu schreiben? Das, was Du meinst, ist der von ARM
zur Verfügung gestellte Code, den die Vendors 1:1 an ihre Kunden
weitergeben können. Was sie aber zusätzlich machen müssen, ist, _ihre
eigene_ peripherie auch noch CMSIS-konform abzubilden. Und das ist die
ST-Lib. Diese aber als ST-Schaumschlägerei zu betiteln, ist insofern
also nicht ganz fair gegenüber ST, denn es ist eben eigentlich
ARM-Schaumschlägerei....
... die ich (wenn sich alle daran halten) riesige Vorteile mit sich
bringt. Siehe oben.
Roland H. schrieb:> Dann nimm ein stm32f1-Programm und kompiliere es mal für stm32f2/f4.> Dann nimm ein stm32-CM3-Programm und portiere es auf einen lpc CM3.
Wenn der HAL gut gemacht ist, dann funktioniert das eben. Periph-Lib
austauschen und gut ist. Nicht bei 100% des Code, aber sicher bei 70%,
das ist KEINE Träumerei. Technisch nicht. Vielleicht politisch. Darum
mein Einwand: "(wenn sich alle daran halten)".
Simon Huwyler schrieb:> Auf der CMSIS-Seite zu lesen:
Genau das ist Schaumschlägerei, wie auch der von dir erwähnte Vortrag.
Aber das ist der Job von Marketing-Menschen - Leute mit Versprechungen
auf eine rosige Zukunft ködern, die aber leider derzeit noch etwas
unvollständig ist (lies: von der noch keine einzige Zeile existiert,
nicht einmal ein Konzept).
Es gehört andererseits zum Job der Zuhörer, sowas nicht hingerissen über
sich ergehen zu lassen, sondern solchen Spezis ihre Worte live um die
Ohren zu hauen. Sowas mach ich ganz gern, hab da etwas Übung drin. ;-)
Dann deklariere es aber fairerweise auch als ARM-Schaumschlägerei! ;-)
Wie gesagt, das glaube ich Dir auf's Wort, weil ich nämlich keinen
Gegenbeweis habe. Wie ich geschrieben habe, ich habe sogar selber beim
groben Überfliegen einiger .h files kleine Unterschiede zwischen den
Vendors festgestellt. Musste mich aber zum Glück nie mit Portierung
abmurksen.
Aber die Idee ist wirklich nicht schlecht!
(sehr simples) Beispiel LED. Die soll mal leuchten. Dann mal wieder
nicht. Halt blinken. Du hast einen ARM-Cortex-M3. Warum zum Geier muss
ich für jedes derivat eigenen Code schreiben, um das zu bewerkstelligen?
Wenn sich alle Cortex-M-Vendors darauf einigen (würden!), wie ein
GPIO-Zugriff auf höherer Ebene zu funktionieren hat, dann hast Du eben
diese Kompatibiltät. Und in diesem Beispiel ist es Dir auch piepegal, ob
der eine Prozi das auf HW-Ebene auf die Weise A und der andere auf die
Weise B lieber hätte. Du verwendest die Weise C, die für beide
suboptimal ist. Und die LED geht 2us später an.
Bei 70% des Codes ist das egal. Bei 30% nicht. Und diesen 30% (das sind
z.B. die Codezeilen, die davon Gebrauch machen, dass der ADC von Vendor
A besonders schnell sequenziell Kanal a-b-a-c-a-d wandeln kann) kannst
Du jetzt viiiiel mehr Zeit widmen, weil Du eben nicht nachlesen musst,
wie ein ST-GPIO funktioniert, um eine LED zum Leuchten zu bringen.
Alles, was Du wissen musst, ist, wie ein CORTEX-Mx Prozi einen GPIO
schaltet (jetzt bitte nicht wieder einwenden, dass GPIO nicht von ARM
gemacht werden, genau das meine ich ja!!).
Einigen wir uns also darauf, dass die Idee dahinter suuuper wäre, wenn
sie auch wirklich durchgezogen würde? Dass die Realität anders aussieht,
glaube ich Dir, aber das hat nichts damit zu tun, dass es prinzipiell
nicht machbar/sinnvoll wäre.
Bitte lasst das Offtopic Thema. Danke.
Holger schrieb:
>Ich kenn deinen STM32 jetzt nicht, aber du hast nicht zufällig>eine Remapped Pinkonfiguration ausgesucht?
Hast Du das schon geprüft, weil es extrem danach aussieht. Welches Board
benutzt Du?
Simon Huwyler schrieb:> Aber die Idee ist wirklich nicht schlecht!
Aus welcher Perspektive? Aus der des Entwicklers/Integrators?
Vielleicht aber nicht aus der Perspektive derer, die die Chips
herstellen. Die wollen sich u. U. nicht nur über den Preis
differenzieren, wenn der Rest gleich ist.
Vielleicht ist aber die Komplexität auch eine Art "Kundenbindung". Man
kann eben nicht so einfach wechseln.
Vielleicht ist es aber auch aus Sicht des Kunden gut so, wenn es in der
Peripherie Wettbewerb gibt.
Das ist aber alles völlig egal. Die CPUs, die vor mir auf dem Tisch
liegen, sind Fakt - mit ihren SW-Dreingaben. Papier ist geduldig und
gilt nur dann als Information, wenn "reference manual" oder "errata"
draufsteht.
Simon Huwyler schrieb:> Wenn der HAL gut gemacht ist, dann funktioniert das eben. Periph-Lib> austauschen und gut ist.
Sehr witzig. Deine Kristallkugel muss sehr klar sein, wenn Du heute beim
Erstellen einer HAL die zukünftigen Änderungen an der Peripherie
antizipieren und gleich so vorsehen kannst, so dass ein "Austausch"
möglich ist.
Hab ich auch mal gehofft und fleissig auf die "STM peripheral lib"
gesetzt. Bis ich dann den Code vom stm32f1 auf den stm32f4 bringen
wollte.
Simon Huwyler schrieb:> Wie ich geschrieben habe, ich habe sogar selber beim> groben Überfliegen einiger .h files kleine Unterschiede zwischen den> Vendors festgestellt.
Wieso die Mühe? Ich kann Dir versichern, dass der gcc alle
Unterschiede findet ...
Welche .h files meinst Du? Die "core_cm*"? Das ist harmlos.
Ich meine die "stm32f10x*"/"stm32f4xx*" und "LPC13xx*/"LPC17xx*". Hier
tanzt der Bär.
Torben schrieb:>>Ich kenn deinen STM32 jetzt nicht, aber du hast nicht zufällig>>eine Remapped Pinkonfiguration ausgesucht?> Hast Du das schon geprüft, weil es extrem danach aussieht. Welches Board> benutzt Du?
Mit Remapping habe ich mich noch überhaupt nicht beschäftigt, ich werde
das überprüfen. Es gibt jedenfalls mehrere Pinkonfigurationen auf denen
UART2 laufen kann.
>
1
GPIO_PinRemapConfig(GPIO_Remap_USART2, ENABLE);
GPIO_PinRemapConfig gibts bei mir nicht. Davon steht auch nichts in der
Anweisung in der stm32f2xx_usart.c:
Was hat das
Torben schrieb:> STM32F107VC
mit
Phantomix Ximotnahp schrieb:> Ich habe mir ein Evalboard mit dem STM32F207VGT6
zu tun?
Das könnte man auch als "off-topic" bezeichnen :-)
Phantomix Ximotnahp schrieb:> Aber immerhin ein Versuch zu helfen :-)
Hallo?
Meinen Beitrag von
---
Autor: Roland H. (batchman)
Datum: 29.11.2011 22:28
Wenn ich es richtig sehe, ist PD6 RX und PD5 TX.
---
überhaupt schon gesehen und getestet?
du verwendest im ersten post
RCC_AHB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);
was passiert wenn du stattdessen RCC_APB1PeriphClockCmd(...) verwendest?
womit hast du überhaupt deine ganzen clocks konfiguriert?
ich würde dir das stm32 clock configuration tool von st empfehlen. gibts
auf der seite. ist ein excel sheet mit dem man alles sehr komfortabel
einstellen kann
W.S. schrieb:> Hallo du Phantomas..>> warum schreibst du bloß so einen aufgedunsenen Kram zusammen? Mein Rat:> Schmeiß die ganze St-Treiberlib oder wie das Zeugs heißt weg und halte> dich an das RefManual. Was dort nicht steht, brauchst du auch nicht! Ich> hänge mal ne Konfigurations- und USART- Bedienung aus einem meiner> Projekte an. Da kannst du sehen, wie man ohne diese ganze> ST-Schaumschlägerei auskommt.>> W.S.
naja...man kann von der STLib halten was man will, aber zum
konfigurieren ist das Teil nicht schlecht. Und auf jedenfall
selbstdokumentiernder als
1
if((RCC->BDCR&2)==0)/* wenn 32kHz Oszi nicht ready ist */
2
{PWR->CR|=(1<<8);
3
RCC->BDCR=(1<<16)|(1<<15)|1;/* RTC Reset, enable, 32kHz on */
4
RCC->BDCR=(1<<15)|(1<<8)|1;/* RTC enable, LSE als Quelle, 32kHz on */
A. B. schrieb:> RCC_AHB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);> was passiert wenn du stattdessen RCC_APB1PeriphClockCmd(...) verwendest?
Aehm... Ich glaub da ist was dran... Kann es aber erst heut Abend
ausprobieren
A. B. schrieb:> womit hast du überhaupt deine ganzen clocks konfiguriert?> ich würde dir das stm32 clock configuration tool von st empfehlen. gibts> auf der seite. ist ein excel sheet mit dem man alles sehr komfortabel> einstellen kann
Wenn man Microsoft Office hat; unter Open Office geht das irgendwie
nicht^^
Na egal, die Clocks laufen auch so
Roland H. schrieb:> Simon Huwyler schrieb:>> Wenn der HAL gut gemacht ist, dann funktioniert das eben. Periph-Lib>> austauschen und gut ist.>> Sehr witzig. Deine Kristallkugel muss sehr klar sein, wenn Du heute beim> Erstellen einer HAL die zukünftigen Änderungen an der Peripherie> antizipieren und gleich so vorsehen kannst, so dass ein "Austausch"> möglich ist.
Dieses Argument taugt aber gar nichts! Ich muss die zukünftigen
Veränderungen in der Peripherie eben NICHT kennen. DAS ist ja der Zweck
einer HAL. In den 90er Jahren (hab' ich jetzt einfach mal geschätzt)
hatten sie auch keine Kristallkugel zur Hand. Und trotzdem kann man auch
heute einen modernen Bildschirm an einen alten VGA-Port anschliessen.
Standardisiertes Interface ist das Zauberwort. Wenn Du die Vorzüge des
modernen Bildschirms nutzen willst, reicht der VGA-Anschluss zwar nicht
mehr, aber wenn nicht, dann passt das. Genau das ist der Clou:
Standardisierte Interfaces.
Roland H. schrieb:> Vielleicht ist aber die Komplexität auch eine Art "Kundenbindung". Man> kann eben nicht so einfach wechseln.
Deswegen schrieb ich ja auch: Die grösste - nein - die EINZIGE Hürde ist
politisch, nicht technisch.
Aber das mit der Kundenbindung kann auch ins Auge gehen. Mal angenommen,
alle hätten das gemacht, bis auf einen. Dann wäre das ganz klar ein
Argument dagegen, dieses Derivat zu nehmen.
(so wie Windows sich nie gegen die UNIXoiden wird durchsetzen können :-P
- mann, ich sollte aufhören, meine eigenen Argumente zu widerlegen!
;-)))
Roland H. schrieb:> Wieso die Mühe? Ich kann Dir versichern, dass der gcc alle> Unterschiede findet ...>> Welche .h files meinst Du? Die "core_cm*"? Das ist harmlos.
Wieso die Mühe? Weil ich per Zufall mal drauf gestossen bin. Und mal
kurz das Interface für Peripherie X der beiden Derivate zu vergleichen,
einfacher war, als ein neues Build aufzusetzen etc... Wie gesagt: Es war
a) rein interessehalber und b) nur mal ein ganz grober Blick drauf.
Neinein, ich meine nicht die Core-Lib. Ich meine schon die
Vendor-Peripherie.
Phantomix Ximotnahp schrieb:> A. B. schrieb:>> RCC_AHB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE);>> was passiert wenn du stattdessen RCC_APB1PeriphClockCmd(...) verwendest?>> Aehm... Ich glaub da ist was dran... Kann es aber erst heut Abend> ausprobieren>
So, bin nun zuhause und habs ausprobiert. Und... trommelwirbelfrankensteinstimme aufleg ES LEEEEEEBT!
Tatsächlich lag der Fehler nur in dem einen Buchstaben; nun sendets
fröhlich vor sich hin!
Danke an alle nochmal! :-)
Hallo Phantomix Ximotnahp,
ich wil mir auch dieses Board zulegen. Wie sind denn Deine Erfahrungen
damit und würdest Du es weiterempfehlen?
Vom Preis-Leistungs-Verhältnis sieht es ja wirklich gut aus.
Danke für die Info.
Martin
> Wie sind denn Deine Erfahrungen> damit und würdest Du es weiterempfehlen?
Also das Board funktioniert; das einzige was ich noch nicht getestet hab
ist die zugehörige CAN- und Ethernet-Schnittstelle (kommt aber noch).
Zu der Verarbeitung des Boards muss man sagen, es sieht aus wie
teilweise handgelötet, paar sachen sind bei mir leicht schief drauf, ist
aber für ein evalboard OK, solang es funktioniert, finde ich.
Gefallen hat mir jedenfalls die Belegung der Pinleisten am Rand, das ist
wesentlich besser als bei manchen anderen boards.
Softwareseitig siehts ein wenig wenig aus; auch weils die 200er serie
vom stm ist, und alle möglichen Beispiele im Netz sich auf die 100er
beziehen.
Als Programmieradapter kann ich den ST-Link v2 empfehlen, geht bei mir
problemlos und schnell. Schön wärs noch gewesen, wenn statt der
abgewinkelten Pinleiste ein Wannenstecker für den JTAG verbaut worden
wäre, kann man ja aber noch selbst nachrüsten :-)
Lieber Freunden!
Kannst du bitte die leichte code STM32F2xx USART auf stm32-p207 plate.
I habe Probleme mit inizialization
STM_EVAL_COMInit(COM1, &USART_InitStructure); - habe keine Bibliotek
Entschuldigen Sie bitte fur meine Deutch)
Thread beobachten
Seitenaufteilung abschalten