NAZE32 - alternative Software
- Themenstarter JUERGEN_
- Beginndatum
- Status
Hallo,
ich kämpfe mich auch durch den Code ...
eine Geschichte mit Groß-Kleinschreibung von "HSE_Value" (war "hse_value in einigen Abschnitten rund um die Sensoren) bereinigt,
eine hartnäckige Nörgelei des Linkers an einer Stelle (siehe Bildschirm Kopie) bekomme ich nicht geregelt.
Der fragliche "SetSysClock" Aufruf findet sich auffallenderweise nicht in der funktionierenden SG_2.5 im Abschnitt "drv_system".
Im gleichen Abschnitt stolpere ich auch über "systemInit" vs. "SystemInit" in "system_stm32f10x.c" ....
bin aber im Moment zu ausgelaugt, dem systematisch nachzugehen.
Soll keine Meckerei sein! Ist ja nicht umsonst 2.6pre
Gruss
Manfred
ich kämpfe mich auch durch den Code ...
eine Geschichte mit Groß-Kleinschreibung von "HSE_Value" (war "hse_value in einigen Abschnitten rund um die Sensoren) bereinigt,
eine hartnäckige Nörgelei des Linkers an einer Stelle (siehe Bildschirm Kopie) bekomme ich nicht geregelt.
Der fragliche "SetSysClock" Aufruf findet sich auffallenderweise nicht in der funktionierenden SG_2.5 im Abschnitt "drv_system".
Im gleichen Abschnitt stolpere ich auch über "systemInit" vs. "SystemInit" in "system_stm32f10x.c" ....
bin aber im Moment zu ausgelaugt, dem systematisch nachzugehen.
Soll keine Meckerei sein! Ist ja nicht umsonst 2.6pre
Gruss
Manfred
Anhänge
Hi, Zuse!
Willkommen bei der Compilierungsqual!
Mit der px4 toolchain und dem Makefile (in der shell "make") compiliert sich das sofort.
Zu der HSE Geschichte. So wie ich das verstehe (man möge mich bitte korrigieren, als nicht low level Bitschieber), sind die CMSIS files von ARM eigentlich als vereinheitlichte Oberfläche zum Ansprechen der Hardware gedacht. Mit dem Naze v5 und teilweise veränderten Leitungen, musste TC eine Hardwareabfrage realisieren, der Referenztakt der Revisionen ist wohl unterschiedlich (8 vs 12 MHZ) und damit der Multiplier um wieder auf 72MHZ zu kommen. Deswegen hat er u.a die Dateien "system_stm32f10x.c" und "stm32f10x_rcc.c" mit (m.E) nicht STM Standard zusammengehackt (daher auch die einzigartige Groß-/Kleinschreibung). Deswegen ist SG2.5 mit dem CMSIS Ordner der pre2.6 nicht kompilierbar (und umgekehrt). Am Besten https://github.com/Crashpilot1000?tab=repositories das gewünschte Repo komplett als ZIP ziehen und die jeweiligen Dateien zum compilieren nehmen. Mir wäre es auch lieber gewesen, wenn er auf diese HSE Sache in dieser Form verzichtet hätte und nur das Vorhandensein eines spi eeproms abgefragt hätte. Warum er diese Lösung gewählt hat ist mir, sehr wahrscheinlich aus fehlender Sachkenntnis heraus, unklar.
@ VoBo: Stimmt, beim Anpassen des Systemtreibers habe ich doch glatt das "initI2cLCD" vergessen. Da sollte dann die Startup message vernichtet sein, das Parametereinstellen sollte aber gehen.
LG
Rob
Willkommen bei der Compilierungsqual!
Mit der px4 toolchain und dem Makefile (in der shell "make") compiliert sich das sofort.
Zu der HSE Geschichte. So wie ich das verstehe (man möge mich bitte korrigieren, als nicht low level Bitschieber), sind die CMSIS files von ARM eigentlich als vereinheitlichte Oberfläche zum Ansprechen der Hardware gedacht. Mit dem Naze v5 und teilweise veränderten Leitungen, musste TC eine Hardwareabfrage realisieren, der Referenztakt der Revisionen ist wohl unterschiedlich (8 vs 12 MHZ) und damit der Multiplier um wieder auf 72MHZ zu kommen. Deswegen hat er u.a die Dateien "system_stm32f10x.c" und "stm32f10x_rcc.c" mit (m.E) nicht STM Standard zusammengehackt (daher auch die einzigartige Groß-/Kleinschreibung). Deswegen ist SG2.5 mit dem CMSIS Ordner der pre2.6 nicht kompilierbar (und umgekehrt). Am Besten https://github.com/Crashpilot1000?tab=repositories das gewünschte Repo komplett als ZIP ziehen und die jeweiligen Dateien zum compilieren nehmen. Mir wäre es auch lieber gewesen, wenn er auf diese HSE Sache in dieser Form verzichtet hätte und nur das Vorhandensein eines spi eeproms abgefragt hätte. Warum er diese Lösung gewählt hat ist mir, sehr wahrscheinlich aus fehlender Sachkenntnis heraus, unklar.
@ VoBo: Stimmt, beim Anpassen des Systemtreibers habe ich doch glatt das "initI2cLCD" vergessen. Da sollte dann die Startup message vernichtet sein, das Parametereinstellen sollte aber gehen.
LG
Rob
Zuletzt bearbeitet:
Hi Rob,
danke für die Erläuterungen!
Für die grundlegenden Systemsachen nehme ich die CMSIS aus dem CoIDE eigenen Repo ...
nicht weil ich so eigenwillig bin, sondern weil ich noch nicht herausgefunden habe, wie ich "Fremd" Repositories in der CooCox Umgebung einbinde ...
aber bis zu den SG_2.5 läuft das völlig problemlos, auch wenn die CooCox CMSIS nicht mehr ganz aktuell sind und mit dem 4.7 GCC einen klitzekleinen Patch brauchen ...
D.h. bis dato brauchte ich ausschließlich Deine Quellen unter /src und fertig!
Ich werde noch ein wenig herumprobieren und mich notfalls auf Dein Repo werfen ... schau mer mal, wieweit ich die CoIDE "herumkriege"
Gruss
Manfred
danke für die Erläuterungen!
Für die grundlegenden Systemsachen nehme ich die CMSIS aus dem CoIDE eigenen Repo ...
nicht weil ich so eigenwillig bin, sondern weil ich noch nicht herausgefunden habe, wie ich "Fremd" Repositories in der CooCox Umgebung einbinde ...
aber bis zu den SG_2.5 läuft das völlig problemlos, auch wenn die CooCox CMSIS nicht mehr ganz aktuell sind und mit dem 4.7 GCC einen klitzekleinen Patch brauchen ...
D.h. bis dato brauchte ich ausschließlich Deine Quellen unter /src und fertig!
Ich werde noch ein wenig herumprobieren und mich notfalls auf Dein Repo werfen ... schau mer mal, wieweit ich die CoIDE "herumkriege"
Gruss
Manfred
Die Aktualität Deiner CMSIS Dateien ist definitiv nicht das Problem. Der Alleingang der Instanz des guten Programmierstils im CMSIS Ordner verhagelt Dir den Erfolg. SG2.5 benutzt noch die ARM - Standard files, deswegen fluppt das bei Dir.
Wie gesagt, nimm das makefile, dann musst Du Deine IDE nicht "rumkriegen" und das Ergebnis ist gleich.
Wie gesagt, nimm das makefile, dann musst Du Deine IDE nicht "rumkriegen" und das Ergebnis ist gleich.
Zuletzt bearbeitet:
Hi Rob,
ich habe die CoIDE überreden können, wie es aussieht
Kein allzu großer Aufwand ... wenn man den Weg erst einmal begriffen hat
(Details erspare ich Dir und den Mitlesern ohne CooCox IDE).
Das Ergebnis ist ein Hexfile mit der Größe von 287kByte (GCC 4.7.3, Optimierung -Os), dass ich mangels fliegender Hardware nicht wirklich testen kann.
Gruss
Manfred
PS: kann man hier keine Hex-Files hochladen?
ich habe die CoIDE überreden können, wie es aussieht
Kein allzu großer Aufwand ... wenn man den Weg erst einmal begriffen hat
(Details erspare ich Dir und den Mitlesern ohne CooCox IDE).
Das Ergebnis ist ein Hexfile mit der Größe von 287kByte (GCC 4.7.3, Optimierung -Os), dass ich mangels fliegender Hardware nicht wirklich testen kann.
Gruss
Manfred
PS: kann man hier keine Hex-Files hochladen?
@Roberto
Danke.
Hast bewust etwas mit OLED gemacht? Weil es nicht geht. Oder ist es nur ein Nebeneffekt wegen Naze32V5?
Ich habe noch nicht genau geschaut. Mit fehlt es zur Zeit an Energie
Ich habe gestern mein V5 Board gegrillt.
Ich habe am VBAT + und - vertauscht. Ja es steht dran, aber ist anders als im V4
Mich wundert nur, wie mein OLED auch dran glauben musste....
Danke.
Hast bewust etwas mit OLED gemacht? Weil es nicht geht. Oder ist es nur ein Nebeneffekt wegen Naze32V5?
Ich habe noch nicht genau geschaut. Mit fehlt es zur Zeit an Energie
Ich habe gestern mein V5 Board gegrillt.
Ich habe am VBAT + und - vertauscht. Ja es steht dran, aber ist anders als im V4
Mich wundert nur, wie mein OLED auch dran glauben musste....
War keine Absicht mit dem I2C display. Beim ändern der v5 systemsachen habe ich einfach die Zeile initI2cLCD vergessen. Damit dürfte die bootmessage zum Teufel gegangen sein, das Konfigurieren sollte noch gehen (wird dann initialisiert).
Mein V5 Grillbeileid. Vielleicht hat das Vertauschen auch den I2C Bus gut unter Saft gesetzt.
Manche Transmitter sind auch schon verpolt gegrillt worden. Ich frage mich immer, wieso an solchen Stellen nicht einfach eine 1N4001 Diode sitzt, das würde viel Elend verhindern.
Mein V5 Grillbeileid. Vielleicht hat das Vertauschen auch den I2C Bus gut unter Saft gesetzt.
Manche Transmitter sind auch schon verpolt gegrillt worden. Ich frage mich immer, wieso an solchen Stellen nicht einfach eine 1N4001 Diode sitzt, das würde viel Elend verhindern.
Weil der strom- (und temperatur-)abhängige Spannungsabfall an der Diode die Spannungsmessung versaut, vermutlich.
Nach ebenso einem Vorfall, habe mir angewöhnt, nach Lötarbeiten jedes mal die Versorgungsspannungen gegen Platinen schnell mit dem Multimeter durchzupiepen, dauert nur ein paar Sekunden.
Nach ebenso einem Vorfall, habe mir angewöhnt, nach Lötarbeiten jedes mal die Versorgungsspannungen gegen Platinen schnell mit dem Multimeter durchzupiepen, dauert nur ein paar Sekunden.
Zuletzt bearbeitet:
Hi,
zum Thema "Sonar" habe ich gerade ein wenig im Quellcode gegraben, um herauszufinden, mit welcher Kennung das HC-SR04 und speziell die "Daddy_Walross" Variante mit I2C eingestellt wird (="2"), in Carstens BaseflightGUI bin ich nur auf eine Voreinstellung gestoßen.
Bestimmt habe ich mal wieder den steinigeren Weg gesucht und die Angabe finde ich künftig direkter und einfacher, oder?
Zweite gesuchte Info:
ist der I2C-Adapter von "Daddy Walross" 3,3V tolerant oder besteht er auf 5V?
Das MPU6050 Platinchen versorge ich mit 3,3V aus dem STM32 DevBoard und dieses z.Zt. per USB.
Gruss
Manfred
zum Thema "Sonar" habe ich gerade ein wenig im Quellcode gegraben, um herauszufinden, mit welcher Kennung das HC-SR04 und speziell die "Daddy_Walross" Variante mit I2C eingestellt wird (="2"), in Carstens BaseflightGUI bin ich nur auf eine Voreinstellung gestoßen.
Bestimmt habe ich mal wieder den steinigeren Weg gesucht und die Angabe finde ich künftig direkter und einfacher, oder?
Zweite gesuchte Info:
ist der I2C-Adapter von "Daddy Walross" 3,3V tolerant
oder besteht er auf 5V?Das MPU6050 Platinchen versorge ich mit 3,3V aus dem STM32 DevBoard und dieses z.Zt. per USB.
Gruss
Manfred
- Status
