Forum: Compiler & IDEs Wie Projekt von github in STMCubeIDE importieren?


von Gunnar F. (gufi36)


Lesenswert?

Hallo Experten,

ich programmiere bisher STM32 Controller in der CubeIDE und lasse mir 
das Gerüst von CubeMX generieren. Damit komme ich ganz gut klar. Ich 
habe keine Ahnung von Linux und kommandozeilenorientierter Entwicklung 
(make und desgleichen). Meine Toolchain von ST ist aktuell, also IDE 
2.0, MX 6.16.
Jetzt habe ich dieses Projekt gefunden:

https://github.com/GCY/Pulse-Oximeter-with-MAX3010X

das mich interessiert. Ein Breakout-Board mit MAX30102 habe ich gekauft.
Würde lieber ein STM32F446RE-Nucleo verwenden, anstatt das vom Autor 
verwendete STM32F407-Disc1.
Ich habe in MX ein leeres neues Projekt angelegt, mit einem I2C und 
integrierte die MAX3010x.c/.h in mein Projekt. Jetzt schon gibt es 
natürlich viele Fehlermeldungen, weil der Autor halt andere 
Pinbezeichnungen verwendete als ich.
Wie geht man (ein Experte...) jetzt vor, um das Projekt auf- oder 
umzusetzen?

von Wastl (hartundweichware)


Lesenswert?

Gunnar F. schrieb:
> Jetzt schon gibt es
> natürlich viele Fehlermeldungen, weil der Autor halt andere
> Pinbezeichnungen verwendete als ich.

Und was ist die logische Folgerung daraus? Verwende die gleichen
Pinbezeichnungen wie im Original-Projekt. Muss man dir das erst
vorkauen?

von Wastl (hartundweichware)


Lesenswert?

Gunnar F. schrieb:
> https://github.com/GCY/Pulse-Oximeter-with-MAX3010X

Aus  heutiger Sicht ist das ein "Uralt-Projekt" das du mit
jetzigen modernen Include-Files (aus CubeMX generiert) nicht
mehr verwenden kannst.

Das einzige was du noch verwenden kannst ist das main.c aus dem
du dann mit eigener Hirn-Arbeit ein mit LL- oder HAL-Library
compilierbares und lauffähiges Programm machen kannst.
Ansonsten sehe ich da wenig Chance. Eher noch damit dass du eine
andere IDE, z.B. Embitz, verwendest die dir das Einbinden der
älteren im Projekt mitgelieferten Includes erlaubt. Vermutlich
die Version mit deutlich weniger Aufwand.

von Gunnar F. (gufi36)


Lesenswert?

Wastl schrieb:
> Das einzige was du noch verwenden kannst ist das main.c aus dem
> du dann mit eigener Hirn-Arbeit ein mit LL- oder HAL-Library
> compilierbares und lauffähiges Programm machen kannst.

Danke, im Prinzip habe ich das bisher auch ähnlich gemacht. Halt die 
Hardware .h/.c importiert und mir das Gerüst dann selber gebaut. Aber 
die Anwendung interessiert mich und ich bin oft in der Situation: 
Bekannte bauen unter Linux STM-Projekte. Teilweise mit CubeMX, teils 
ohne, Hardcore Linuxxer, die ausser VIM keine Tools nutzen. JEDESMAL 
komme ich in ewige Bastelei, deren Projekte zu importieren und weiter zu 
bearbeiten.
Habe schonmal Sourcetrail versucht, das sieht auch klasse aus, aber es 
ist mir nicht gelungen, das STM-Projekt mit HAL und CMSIS richtig darin 
zu analysieren.

von Wastl (hartundweichware)


Lesenswert?

Wenn du genug Geduld und Fähigkeiten besitzt kanns du ja mal
das hier versuchen:

https://www.st.com/en/development-tools/spl2ll-converter.html

von N. M. (mani)


Lesenswert?

Wenn es nur ums nachbauen geht nimm die gleichen Pins. Dann geht das hex 
File im Repo...

von Gunnar F. (gufi36)


Lesenswert?

N. M. schrieb:
> Wenn es nur ums nachbauen geht

erstmal wollte ich einfach mit IDE-Unterstützung das Projekt durchsehen. 
Springen zu Deklaration, alle Referenzen anzeigen lassen, etc.
Ohne diese Hilfe fällt es mir schwer, den "Workflow" von fremder 
Software zu erfassen. Jetzt habe ich stundenlange Updates hinter mir, 
kann EGit nicht mehr in CubeIDE nutzen und meine Windows-Installation 
ist korrupt. Faxn dick für heute!
Danke!

von Nemopuk (nemopuk)


Lesenswert?

So ist das: Diese Code Generatoren sind für neue Projekte toll. Aber 
wenn man alte Projekte pflegt oder gar den Mikrocontroller wechselt, 
werden sie eher zum Hindernis. Deswegen meiden deine "Hardcore Linuxxer" 
Cube MX und die HAL.

von Wastl (hartundweichware)


Lesenswert?

Gunnar F. schrieb:
> Faxn dick für heute!

Tja, wenn man den falschen Ansatz wählt ....
..... lieber erst fragen, dann machen.

N. M. schrieb:
> Wenn es nur ums nachbauen geht nimm die gleichen Pins. Dann geht das hex
> File im Repo...

Wie soll das gehen wenn die Hardware schon ganz unterschiedlich ist ...

Gunnar F. schrieb:
> Würde lieber ein STM32F446RE-Nucleo verwenden, anstatt das vom Autor
> verwendete STM32F407-Disc1.

von N. M. (mani)


Lesenswert?

Wastl schrieb:
> Wie soll das gehen wenn die Hardware schon ganz unterschiedlich ist ...

Na dann soll er einfach den gleichen Controller nehmen.
Übersetzen ist ja das eine. Es sollte danach ja auch noch funktionieren.
Keine Ahnung wie gleich die 2 Controller sind. Das kann auch noch 
deutlich mehr Arbeit bedeuten.

von Gunnar F. (gufi36)


Lesenswert?

Hallo zusammen. Ich habe meine Absicht wohl missverständlich 
ausgedrückt: Ich will das Projekt nicht 1:1 nachbauen und genauso in 
Betrieb nehmen. Statt dessen möchte ich mein eigenes Projekt selbst 
umsetzen. Ansonsten hätte ich selbstverständlich dieselbe Hardware 
verwendet und bräuchte nur zu builden und flashen.
Aber bevor ich anfange, suche ich vergleichbare Lösungen und will sehen, 
wie der Treiber funktioniert, aufgerufen wird und welche Daten zurück 
gegeben werden. Wie bereitet der Autor die dann auf und zeigt sie an?
Daraus entnehme ich Anregungen und falls möglich den kompletten Treiber.
In meinem Fall will ich die Daten sowieso nur suf SD-Karte loggen.
Aber eben diese Code-Analyse ist in einer IDE m.E. doch viel 
komfortabler. Aber genau bei dem Schritt bin ich schon oft in dieselben 
Schwierigkeiten gekommen.
Welche IDE und Buildsystem hat der Autor verwendet? Allein das 
erschließt sich mir meistens nicht (wenn nicht schon in CubeIDE 
erstellt). Wie gesagt, von diesen "bare metal" Build und Make habe ich 
leider noch keine Ahnung.
Aber ich bin ja im Versuch, dahingehend dazu zu lernen.

von Nemopuk (nemopuk)


Lesenswert?

Bei mir (privat und beruflich) wurden die IDEs häufiger gewechselt, als 
andere Build Tools. Deswegen fühle ich mich nicht wohl, wenn der Build 
Vorgang von einer bestimmten IDE abhängt. Unabhängige Tools wie Make, 
Maven, meinetwegen auch Shell-Scripte sind mir lieber.

Leider führt das häufig zur Notwendigkeit doppelter Konfiguration, damit 
die IDE alle Definitionen und Libraries findet. Dazu kommt, dass einige 
IDEs die Nutzung unabhängiger Build Tools nur sehr eingeschränkt 
unterstützen.

Netbeans und IntelliJ sind gut darin, die Maven Konfiguration (pom.xml) 
zu interpretieren. Etwas ähnliche praktisches für C/C++ (Makefile) ist 
mir unbekannt.

: Bearbeitet durch User
Bitte 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
Noch kein Account? Hier anmelden.