Hallo Zusammen,
wollte nur mal kurz in den Wald reinhorchen: macht das Sinn mit den
ganzen STM Tools zu arbeiten? Ich hab irgendwie das Gefühl die
Programmierer von STM wussten selber nicht was Sie da machen... Dieses
ganze hin-und-her-define ist viel zu unübersichtlich und Keil wirf nur
errors alla "..\..\MC_Application\interface\MCInterfaceClass.h(272):
error: #20: identifier "int16_t" is undefined"
Ich gibs zu, vom programmieren hab ich nur wenig Ahnung aber das was STM
da macht... :-?
Hat einer schonmal ein mit dem ST Motor Control Workbench + Motor
Control Library + Keil einen Motor mit einem STM32F4 zu laufen gebracht?
Gruß Ert
Danke für die Hinweise.
Aber die Motor Control Lib dort einzupflegen wird wahrscheinlich noch
mehr Zeit brauchen. Eine blinkende LED war nie ein Problem. Dieses
grafische Programmieren ala FUP sollen mal die SPS Leute machen ;-D.
Die Errors treten erst auf wenn ich die ST Motor Libs mit einbinde, also
hast es wohl doch was mit ST zu tun ;-). Eine FOC selbst zu
programmieren habe ich keinen Bock, naja irgendwo werde ich wohl noch
was einbinden/ausblenden müssen. Mal schauen.
Gruß Ert
So hatte übers We ein bisl Zeit mich damit zu beschäftigen. Ein paar
Bugs sind wech, es bleiben aber weitere
Ziel ist es übrigens einen Modellbaumotor mit einem STM32f4discovery
drehen zu lassen.
Ich steh vor folgendem Problem. Keil sagt mir nach dem compiling (ohne
Error), dass ca 40 Funktionen undefined sind, ala:
STM32f4.axf: Error: L6218E: Undefined symbol EAC_Exec (referred from
main.o).
...
das Problem was ich habe ich weiß garnicht wo die sind. Wenn ich die
Funktionen suche finde ich nur Aufrufe und die Deklaration im h-file.
Einer eine Idee?
Laut der application Manual muss ich noch eine *\MC Library
Compiled\Exe\MC_Library_STM32F4xx_dual_drive.a einbinden, diese wirft
aber auch nur Fehler. Dieses file ist wohl auch offiziell nur für
IAR-IDE gemacht, wobei IAR auch Fehler wirft. ARGGGGG
Ich kann mich nur wiederholen und Fragen: Hat einer schonmal ein mit dem
ST Motor Control Workbench + Motor Control Library + Keil einen Motor
mit einem STM32F4 zu laufen gebracht?
VG Ert
Ert schrieb:> Einer eine Idee?
Ja, natürlich.
Mach dir deine eigenen Gedanken über das Problem, was du in einen Code
umsetzen willst, entwickle deine eigene Strategie, schreib dir deine
eigene Initialisierung und deine eigenen Low-Level-Funktionen und laß
den ganzen aufgebauschten ST-Libkram außen vor. Dieses Zeugs taugt nur
dazu, seine Anwender in den Wald zu schicken und in einer Flut von
überflüssigen Definitionen zu ertränken.
W.S.
>und laß>den ganzen aufgebauschten ST-Libkram außen vor. Dieses Zeugs taugt nur>dazu, seine Anwender in den Wald zu schicken und in einer Flut von>überflüssigen Definitionen zu ertränken.
Blödsinn.
>und laß>den ganzen aufgebauschten ST-Libkram außen vor. Dieses Zeugs taugt nur>dazu, seine Anwender in den Wald zu schicken und in einer Flut von>überflüssigen Definitionen zu ertränken.
Ansich ist die lib ja gut gemeint, aber genau dieses Gefühl habe ich
auch...
>STM32f4.axf: Error: L6218E: Undefined symbol EAC_Exec (referred from>main.o).>>das Problem was ich habe ich weiß garnicht wo die sind. Wenn ich die>Funktionen suche finde ich nur Aufrufe und die Deklaration im h-file.
Das Problem ist das du keine Ahung hast.
>Laut der application Manual muss ich noch eine *\MC Library>Compiled\Exe\MC_Library_STM32F4xx_dual_drive.a einbinden, diese wirft
Na hoffentlich nicht per #include.
Die musst du beim Linker eintragen.
Torsten S. schrieb:> holger schrieb:>> Das Problem ist das du keine Ahung hast.>> Ack.Ert schrieb:> Ich gibs zu, vom programmieren hab ich nur wenig Ahnung aber ....
Da hier ja zwei Leutchen soviel "Ahung" haben kann mir evtl einer mit
Ahnung noch einen Tipp geben?
;-)
holger schrieb:> Na hoffentlich nicht per #include.> Die musst du beim Linker eintragen.
Gesagt getan, beim Linker-Reiter unter Misc controls eingebunden.
Jetzt wirft mir Keil bei linking solche Fehler: "STM32f4.axf: Error:
L6366E: BusVoltageSensorClass.o attributes are not compatible with the
provided cpu and fpu attributes ."
Habe mir noch paar Demoprogramme angeschaut, werde aber nicht wirklich
schlauer woran es jetzt hakt.
Love and peace Ert
W.S. schrieb:> ...schreib dir deine> eigene Initialisierung und deine eigenen Low-Level-Funktionen und laß> den ganzen aufgebauschten ST-Libkram außen vor. Dieses Zeugs taugt nur> dazu, seine Anwender in den Wald zu schicken und in einer Flut von> überflüssigen Definitionen zu ertränken.
Ich denke mittlerweile hat jeder kapiert, dass du am liebsten mit dem
"vi" programmierts & jeglichen Komfort ablehnst...
Ich teile längst nicht alle Meinungen die W.S. hier vertritt, aber in
diesem Punkt hat er recht. Die Libs, egal ob von ST oder NXP, sind alle
schlecht dokumentiert. Um zu durchschauen was in den Libs wie passiert
und um im Debugger dann die Register passend zu interpretieren, muss man
die CPU schon kennen. Und wenn ich sie kenne, sehe ich keine
Notwendigkeit noch eine Lib dazwischen zu haben die ich auch nicht
kenne. Bei Ethernet und Usb ist es sicherlich hilfreich Beispiele zu
haben. Soweit, dass ich einen gesamten Tcp/Ip- oder Usb-Stack komplette
verstehe gehe ich auch nicht. Aber Timer, Gpio, Spi, I2c u.s.w. sollte
man schon beherrschen. Wenn man nicht bereit ist das zu lernen, hat man
in diesem Beruf nichts verloren. Tcp/Ip und Usb sind aber nun wieder
Standards und was völlig anderes als eine Motor-Lib. An den MC-Libs der
Hersteller kann man sich zwar bereichern und lernen, aber zu denken: Das
linke ich mal eben dazu und drehe an ein paar Parametern und es läuft,
ist abwegig. Und das bei einem Kenntnisstand der nicht mal reicht um das
build-System zu durchschauen und ein paar Linkerfehler zu
interpretieren. Fazit: Lern es oder vergiss es.
Und zum Lernen reicht es nicht nur ein paar Fragen ins Forum zu
stellen.
Wenn Komfort dazu dienen soll sich das Lernen und Verstehen zu ersparen,
dann bin ich echt froh schon so alt zu sein, dass ich die Konsequenz
daraus vielleicht nicht mehr erleben muss.
Ert schrieb:> Gesagt getan, beim Linker-Reiter unter Misc controls eingebunden.> Jetzt wirft mir Keil bei linking solche Fehler: "STM32f4.axf: Error:> L6366E: BusVoltageSensorClass.o attributes are not compatible with the> provided cpu and fpu attributes ."
Das Objekt ist mit anderen Optionen übersetzt worden (Endianess,
Instructionset oder FPU Support). Vermutlich ist es der FPU-Support.
Hast du in Options for Target -> Target FPU-Unterstuetzung aktiviert?
Du musst das Objekt bzw. die Library uebrigens nicht von Hand beim
Linker angeben. Du kannst es einfach deinem Projekt hinzufuegen wie eine
Sourcedatei.
Grundsätzlich muss ich mich wundern warum viele gegen die ST Library
wettern. Jemand der die nicht versteht wird wohl kaum in der Lage sein
effizient eigene Treiber zu schreiben. Die Dokumenation dazu ist auch
mehr als selbst erklärend und soweit ich mich erinnere gibt es fuer jede
wichtige IDE Template-Projekte. So schwer ist das nicht.
Matthias schrieb:> Grundsätzlich muss ich mich wundern warum viele gegen die ST Library> wettern.
Weil sie scheiße ist. Ein gigantischer Haufen aus irgendeiner
Meta-Language autogenerierter Code, der allen guten
Programmier-Best-Practices spottet und außerdem auch noch ineffizient
ist. Nerviges Beispiel: Angenommen, ich möchte in einer Header-Datei
Pins definieren, dann muss ich folgendes pro Pin eingeben:
Sehr spaßig wenn man 100 Pins so konfigurieren möchte. Und das, während
die komplette Information, welchen Pin man meint, technisch in ein
32bit-Wort passt.
> Jemand der die nicht versteht wird wohl kaum in der Lage sein> effizient eigene Treiber zu schreiben.
Ich habe meine eigenen Hardware-Treiber für ein paar
STM32F4-Hardwaremodule geschrieben, sie sind elegant, einfacher zu
benutzen und teilweise effizienter, z.B.:
1
autoLED_PIN=STM32::GPIO::PD13;
Initialisieren mit:
1
LED_PIN.init(...);
Das wird aber leider nur mit dem ARM-GCC gehen, nicht mit Keil.
Außerdem: Die ST-Lib (und auch die CMSIS) definieren eine Unzahl an
Makros (mit #define). Warum nur? Mit "const" Variablen ginge es in 99%
der Fälle genauso gut, nur dass die Scope haben, d.h. man könnte in C++
schreiben:
1
namespaceStdPerihpal{
2
#include"stm32f4xx_gpio.hh"
3
}
und schon wären ALLE Konstanten, Variablen, Funktionen im
StdPeriphal-Namespace. Aber danke #define geht das nicht, und du kannst
zB keine Funktion oder Variable "RCC" nennen, denn sonst gibts obskure
Fehlermeldungen. Vermutlich sollte der ST-Code kompatibel zu
uralt-Compilern sein die "const" nicht richtig optimieren können...
> Die Dokumenation dazu ist auch mehr als selbst erklärend
Fand ich jetzt nicht so, aber Geschmackssache
> und soweit ich mich erinnere gibt es fuer jede wichtige IDE Template-Projekte.
So schwer ist das nicht.
Yess, Code-Copy&Pasta ins eigene Projekt. Idealerweise sollte man im
Projekt nur angeben "dies Projekt ist für den STM32F4." und die
IDE/Toolchain sollte den F4-spezifischen Schmodder automatisch beim
compilen verwenden. Und wenn man im Projekt das "F4" zu "F3" ändert wird
der komplette Code automatisch zu F3-Code... (das geht, aber ST kanns
nicht.)
PS: wenn der Compiler meckert, dass int16_t undefiniert ist, ganz oben
(vor die anderen #include's) in die betreffende .c-Datei mal "#include
<stdint.h>" schreiben.
STM32F4 Programmierer schrieb:> Ich habe meine eigenen Hardware-Treiber für ein paar> STM32F4-Hardwaremodule geschrieben, sie sind elegant, einfacher zu> benutzen und teilweise effizienter, z.B.:>
1
autoLED_PIN=STM32::GPIO::PD13;
> Initialisieren mit:>
1
LED_PIN.init(...);
Was ist PD13 dann für ein Objekt?
namespace STM32
{
namespace GPIO
{
class PD13 : public irgendwas
?
Ich überlege mir gerade auch so etwas aufzubauen und suche einen
"Startpunkt".
Die STM Libs sind nett zum lernen wie zum Beispiel der USB Angesprochen
wird, er zeigt aber weder wie USB funktioniert und noch viel weniger wie
das effizient verwendet wird.
Gruß Martin
Dass die STM-Libs unübersichtlich sind, ist nur auf dem ersten Blick so.
Wer sich beim Atmel durchgefummelt bekommt, wird bei den STM-Libs vor
Freude eine Salto machen.
Und ja, die lassen sich mit KEIL asgezeichnet einsetzen. Wimre sind die
sogar (doxygen) dokumentiert mit Examples und allem Schnickschnack.
Martin K. schrieb:> Was ist PD13 dann für ein Objekt?
Ein Template deren Argumente Port+Pin enthalten:
1
staticconstSTM32::GPIO::PinX<3,13>PD13;
Diese werden dann zusammen mit einer großen Liste an
Template-Spezialisierungen verwendet um die korrekte Verwendung der AF's
zu verifizieren.
LT1043 schrieb im Beitrag #3167170:
> http://andybrown.me.uk/wk/2013/03/30/stm32plus-2-1-0/>> Ist wohl einer der Besen C++ Ansätze für die STM32.
Na sowas, genau so wollte ich meine library ursprünglich auch nennen...
Scheint aber nicht sonderlich objektorientiert zu sein. Und verwendet
außerdem intern die ST Library, also eine Abstraktion einer Abstraktion.
Man müsste wohl mal analysieren wie effizient das ist.
Martin K. schrieb:> Die STM Libs sind nett zum lernen wie zum Beispiel der USB Angesprochen> wird, er zeigt aber weder wie USB funktioniert und noch viel weniger wie> das effizient verwendet wird.
An eine eigene USB-Implementation wollte ich mich nicht herantrauen...
Der hier hat's versucht: https://github.com/zyp/laks hat aber nicht so
schönes GPIO Zeug wie ich.
Falls jemand Interesse hat mit mir zusammen die C++ STM32 Library zu
entwickeln kann er sich ja bei mir melden unter profclonk ätt gmx punkt
de
Ich bin mir aber noch nicht sicher ob und wie ich sie releasen oder gar
verkaufen möchte... Eventuell könnte man sich ja einig werden.
Roland Ertelt schrieb:> Dass die STM-Libs unübersichtlich sind, ist nur auf dem ersten Blick so.> Wer sich beim Atmel durchgefummelt bekommt, wird bei den STM-Libs vor> Freude eine Salto machen.
Und ich hatte gehofft andere könnten es besser als ST... Die ST Lib wird
dadurch jedenfalls nicht besser :-)
> Und ja, die lassen sich mit KEIL asgezeichnet einsetzen.
Dafür wurde sie wohl auch entwickelt.
> Wimre sind die> sogar (doxygen) dokumentiert
Einmal "doxygen" aufrufen auf beliebigem Code ist aber keine Leistung
:-)
> mit Examples und allem Schnickschnack.
Ohne die wärs auch quasi unmöglich sie zu verwenden :-/
> Diese werden dann zusammen mit einer großen Liste an> Template-Spezialisierungen verwendet um die korrekte Verwendung der AF's> zu verifizieren.>
Das hört sich spannend an. Ich bin leider nicht der grosse template
Guru, deswegen komme ich so selten darauf diese zu verwenden. Und auf
riesen define Orgien stehe ich auch nicht wirklich.
Gruß Martin
Roland Ertelt schrieb:> Dass die STM-Libs unübersichtlich sind, ist nur auf dem ersten Blick so.> Wer sich beim Atmel durchgefummelt bekommt, wird bei den STM-Libs vor> Freude eine Salto machen.>> Und ja, die lassen sich mit KEIL asgezeichnet einsetzen. Wimre sind die> sogar (doxygen) dokumentiert mit Examples und allem Schnickschnack.
Die Std Lib ja, die Motor Control lib mit vorcompilierten Teilen Nein...
Martin K. schrieb:> Das hört sich spannend an. Ich bin leider nicht der grosse template> Guru, deswegen komme ich so selten darauf diese zu verwenden.
Sie sind wirklich sehr mächtig... In meiner Library werden sie intern
verwendet, der User-Code muss sich damit aber nicht (zwangsweise)
beschäftigen.
> Und auf> riesen define Orgien stehe ich auch nicht wirklich.
Die sind auch schlecht, da #define-Makros keinen Scope haben (d.h.
überall sichtbar sind, ohne namespace o.ä. drumherum) und keinen Typ
haben. "const int foo = ..." o.ä. ist wann immer irgendwie möglich
vorzuziehen...
LTC1043 schrieb im Beitrag #3167719:
> Hier noch der Link auf eine weiter Lib die ich gefunden habe:
Hm witzig dass ich die nicht gefunden habe... Mir aber auch zu
prozedural... Meine Library unterstützt zB folgendes:
Das "pins"-Array könnte man zB Funktionen übergeben etc. Das ist dann
zwar nicht so sonderlich effizient, aber funktioniert... Einfach nur
"STM32::GPIO::PA1.toggle ();" aber ist effizient, da der Compiler vorher
genau weiß welchen Pin man meint.
STM32F4 Programmierer schrieb:> Martin K. schrieb:>> Das hört sich spannend an. Ich bin leider nicht der grosse template>> Guru, deswegen komme ich so selten darauf diese zu verwenden.> Sie sind wirklich sehr mächtig... In meiner Library werden sie intern> verwendet, der User-Code muss sich damit aber nicht (zwangsweise)> beschäftigen.>> Und auf>> riesen define Orgien stehe ich auch nicht wirklich.> Die sind auch schlecht, da #define-Makros keinen Scope haben (d.h.> überall sichtbar sind, ohne namespace o.ä. drumherum) und keinen Typ> haben. "const int foo = ..." o.ä. ist wann immer irgendwie möglich> vorzuziehen...>> LTC1043 schrieb im Beitrag #3167719:>> Hier noch der Link auf eine weiter Lib die ich gefunden habe:> Hm witzig dass ich die nicht gefunden habe... Mir aber auch zu> prozedural... Meine Library unterstützt zB folgendes:>
Das "pins"-Array könnte man zB Funktionen übergeben etc. Das ist
> dann zwar nicht so sonderlich effizient, aber funktioniert... Einfach> nur "STM32::GPIO::PA1.toggle ();" aber ist effizient, da der Compiler> vorher genau weiß welchen Pin man meint.
Genau so etwas habe ich heute ausprobiert, bin da aber gescheitert.
Ich hätte das gerne so, dass ich für unterschiedliche Peripherie Klassen
erstellen kann und beim Instanziieren die passenden Pins mit angebe. Die
Klasse soll dann selbständig evtl. alternativ Funktionen der Pins
aktivieren. Und wenn möglich soll schon der Compiler evtl. Fehler
melden.
Gruß Martin
Martin K. schrieb:> Die> Klasse soll dann selbständig evtl. alternativ Funktionen der Pins> aktivieren. Und wenn möglich soll schon der Compiler evtl. Fehler> melden.
Jup sowas hab ich:
1
auto&pinTX1=STM32::GPIO::PA12;
2
STM32::CAN0.setTxPin(pinTX1);
Wenn man hier (versehentlich) einen anderne Pin als PIN12 angeben würde,
gäbs einen Compiler-Fehler; so ist sichergestellt dass die Pins nur mit
den richtigen AF's verwendet werden. Außerdem wird die korrekte
AF-Nummer bei diesem Funktionsaufruf automatisch im entsprechenden
Hardware-Register gesetzt.
LTC1043 schrieb im Beitrag #3167986:
> Ist deine Library irgendwo verfügbar?
Noch nicht, es fehlt noch einiges; wenn sie vollständiger ist überlege
ich mir ob ich sie an ST verkaufe oder sie in einem
Opensource/Kommerziell-Hybrid-Modell ähnlich zu Qt (
http://qt-project.org/doc/qt-5.0/qtdoc/licensing.html ) anbiete...
Wollte hier nur demonstrieren dass es sehr wohl möglich ist ein
elegantes & effizientes API zu haben, auch wenn ST & Co es nicht
hinbekommen...
STM32F4 Programmierer schrieb:> LTC1043 schrieb im Beitrag #3167986:>> Ist deine Library irgendwo verfügbar?> Noch nicht, es fehlt noch einiges; wenn sie vollständiger ist überlege> ich mir ob ich sie an ST verkaufe oder sie in einem> Opensource/Kommerziell-Hybrid-Modell ähnlich zu Qt (> http://qt-project.org/doc/qt-5.0/qtdoc/licensing.html ) anbiete...> Wollte hier nur demonstrieren dass es sehr wohl möglich ist ein> elegantes & effizientes API zu haben, auch wenn ST & Co es nicht> hinbekommen...
Na solange werde ich nicht warten können, aber für zukünftiges liest
sich das alles sehr gut!
Jetzt müsste es "nur noch" mit dem KEIL Compiler laufen.... und eine
kommerziell Nutzbare Lizenz haben.
In einer Woche bekomme ich meinen USB Analyzer, dann habe ich sowieso
erst einmal eine andere Baustelle am laufen.
Gruß Martin
Martin K. schrieb:> Na solange werde ich nicht warten können, aber für zukünftiges liest> sich das alles sehr gut!
Gut Ding will Weile haben ;-)
> Jetzt müsste es "nur noch" mit dem KEIL Compiler laufen....
Solange Keil nicht mit dem C++11 Standard mitzieht leider nicht :-/ ...
Dafür aber mit Atollic Studio und allen die den GCC nutzen, und
natürlich dem "GCC Blank" ( https://launchpad.net/gcc-arm-embedded ).
Mal sehen was sich mit clang/LLVM machen lässt.
> und eine kommerziell Nutzbare Lizenz haben.
Genau, das ist der Plan (Im gegensatz zu zB libopencm3 :/ )
> In einer Woche bekomme ich meinen USB Analyzer, dann habe ich sowieso> erst einmal eine andere Baustelle am laufen.
Oje, viel Spaß :-)
STM32F4 Programmierer schrieb:> LTC1043 schrieb im Beitrag #3167986:>> Ist deine Library irgendwo verfügbar?> Noch nicht, es fehlt noch einiges; wenn sie vollständiger ist überlege> ich mir ob ich sie an ST verkaufe oder sie in einem> Opensource/Kommerziell-Hybrid-Modell ähnlich zu Qt (> http://qt-project.org/doc/qt-5.0/qtdoc/licensing.html ) anbiete...> Wollte hier nur demonstrieren dass es sehr wohl möglich ist ein> elegantes & effizientes API zu haben, auch wenn ST & Co es nicht> hinbekommen...
Hi,
Gibt es da eigentlich schon etwas neues zu sagen? Ich hätte gerne
genauer gewusst wie das mit den templates und den alternate function
mapping funktioniert ;-)
Gruß Martin
Hey Leute,
ich habe eure interessanten Beiträge gelesen. Deshalb jetzt mal die
alles entscheidende Frage:
Wird aus eurem C+++++ Code denn auch besserer Assembler/Hex-Code? Oder
muss ich davon ausgehen, dass die Standard-Keil-Lib (finde ich ganz
okay) ebenso in den gleichen/selben Assembler/Hex-Code compiliert wird?
Wenn ja, könnt ihr mir dafür ein Beispiel geben?
Ich Frage mich die ganze Zeit, ob ihr nicht das Rad neu erfindet und ob
es dann nur gefühlt runder ist...
Besten Gruß
public
Oh, lange nicht mehr hier reingeschaut.
Martin K. schrieb:> Gibt es da eigentlich schon etwas neues zu sagen? Ich hätte gerne> genauer gewusst wie das mit den templates und den alternate function> mapping funktioniert ;-)
Naja, ich arbeite noch dran, wird auch noch etwas dauern. Eine
Hardware-Zugriff-Library die nur GPIO kann bringt auch noch nicht so
viel... Sobald es ein benutzbares Release gibt werd ich das schon im
Forum ansagen :)
public schrieb:> Wird aus eurem C+++++ Code denn auch besserer Assembler/Hex-Code? Oder> muss ich davon ausgehen, dass die Standard-Keil-Lib (finde ich ganz> okay) ebenso in den gleichen/selben Assembler/Hex-Code compiliert wird?
Mindestens. Wenn man weiß wie, kann man sehr effizienten C++ Code
schreiben. Und effizienter als die StdPeriphal Library zu sein ist wohl
nicht schwer...
public schrieb:> Wenn ja, könnt ihr mir dafür ein Beispiel geben?
Noch will ich nicht zu viel rumzeigen - mit dem Release gibts auf jeden
Fall eine Liste an Code-Beispielen mit dem generierten Code, um zu
zeigen dass es gar nicht effizienter geht.
> Ich Frage mich die ganze Zeit, ob ihr nicht das Rad neu erfindet und ob> es dann nur gefühlt runder ist...
Allein an der Anzahl Code-Zeilen und generierten Maschinenbefehlen kann
man dann die größere Rundheit ablesen... Die StdPeriphal Library ist
mehr ein Steinklotz als ein Rad.
Thread beobachten
Seitenaufteilung abschalten