Forum: Mikrocontroller und Digitale Elektronik lib oder source code?


von Frank (Gast)


Lesenswert?

Hallo,

wenn ihr projekte macht, habt ihr für eure standardsachen (z.B. timer, 
uart, interrupts ...) eine lib erstellt und bindet diese ein oder 
kopiert ihr immer den kompletten source code ein?

von Vincent H. (vinci)


Lesenswert?

Lib aus Source via CMake.

von Johannes S. (Gast)


Lesenswert?

Lieber Quellcodes:
- Optionen können beim Kompilieren berücksichtigt werden
- einfacheres Debuggen möglich
- intellisense config ist einfacher

Als Projektstruktur sind Libs, OS und Apps auf einer Ebene, damit 
benutze ich ich die gleichen libs in mehreren Projekten.

von Jemand (Gast)


Lesenswert?

Ich verwende Meson, da binde ich andere Bibliotheken mittels Symlink als 
subproject ein. Hat ggü. direktem Kopierem oder Verlinken den Vorteil, 
dass ich nicht alle Pfade jedes Mal neu konfigurieren muss.

von A. S. (Gast)


Lesenswert?

Ich hoffe, Du meinst nicht wirklich "kopieren", sondern external oder 
linken. Die meisten eigenen  libs sind ja doch von irgendwas abhängig, 
Prozessor, Allignment, Quarztakt, endian, ... .

Da ist "mit im Projekt kompilieren" deutlich einfacher.

Eine echte lib gibt es bei uns meist nur zwischen verschiedenen Gruppen 
oder Programmierern, z.b. HAL einer Plattform.

von S. R. (svenska)


Lesenswert?

Ich habe ein paar Varianten (z.B. uart_polled.c, uart_interrupt.c) und 
kopiere die in neue Projekte. Hat den Vorteil, dass ich die bei Bedarf 
spezifisch anpassen kann.

Allerdings habe ich nicht viele Projekte, eine richtige Bibliotheks- 
oder IP-Infrastruktur lohnt sich dafür nicht. Zumal ich allgemein nicht 
so viel gemeinsam nutzbaren Code habe, aber dafür eher kleine Projekte.

Eine richtige Bibliotheks-/IP-Verwaltung lohnt sich da nicht. Immerhin 
ist jedes Projekt mit eigenem Git versioniert.

von Olaf (Gast)


Lesenswert?

> eine lib erstellt und bindet diese ein oder
> kopiert ihr immer den kompletten source code ein?

Es lohnt sich so zu programmieren das man eine lib draus machen koennte. 
Also gerade interne Spezialitaeten zu vermeiden und alles extern ueber 
Funktionen, Datenstrukturen und Callbacks zu konfigurieren. Ob man dann 
aber bei der Geschwindigkeit heutiger Rechner bei compilieren noch einen 
Vorteil von der Lib hat sei mal dahingestellt.

Olaf

von Joerg W. (joergwolfram)


Lesenswert?

Ich baue für grundlegende Dinge Libs, eigentlich "lasse ich bauen" und 
packe alles in eine (inzwischen recht gross gewordene) Library. Dazu 
habe ich vor einigen Jahren ein grundlegendes Konzept entwickelt und auf 
inzwischen 25 Mikrocontrollerfamilien mehr oder weniger erfolgreich 
portiert. Grundlegende Funktionen wie set_portpin_output(PORT,pin) 
funktionieren auf einem AVR genauso wie auf einem MPC57xx, einem HCS08 
oder einem STM32L4xx. Solche Sachen habe ich einmal in ASM realisiert, 
um solche Dinge wie Clock oder Modul enable brauche ich mich dann nicht 
mehr zu kümmern. Es ist zwar nicht so schnell wie direkt die Register zu 
beschreiben, aber wesentlich schneller als beim Arduino.

Dazu kommen natürlich noch weitere Funktionen wie z.B.

set_clock(CLOCK_I_32);

Auf allen Plattformen, die PLL und einen internen Oszillator haben, wird 
damit ein CPU-Clock von 32MHz abgeleitet vom internen RC-Oszillator 
eingetellt. Auf einem AVR würde der Compiler/Linker die fehlende 
Konstante "CLOCK_I_32" bemängeln. Denn die kommt vom Headerfile zum 
Controller, die wiederum auch teilautomatisch erzeugt werden. Ohne 
diverse Automatismen wäre das sowieso längst nicht mehr zu stemmen, aber 
selbst die Headerdatei für die Bibliothek mit den ganzen 
Funktionsprototypen wird mittlerweise von einem (Perl-)Script erstellt, 
welches die ganzen Source-Unterverzeichnisse "scannt".

Auf den Grundfunktionen wie GPIO, UART, SPI, I2C, PWM, CAN... bauen dann 
weitere Funktionen auf, wie z.B. Sensoren, Displays oder externe 
Flashes/EEPROMS. Aber auch hardwareunabhängige Sachen wie CRC oder 
Crypto sind im Laufe der Zeit mit dazugekommen.

Damit lassen sich die meisten Sachen, die ich brauche, abdecken. Und die 
(logischerweise auch automatisch generierten) Makefiles haben gleich 
noch die passenden Befehle für meinen "Universalprogrammer" mit drin, so 
dass ein "make run" für das RAM compiliert und dort startet (soweit der 
Controller es erlaubt) und ein "make prog" für das Flash.

Jörg

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.