Hallo, ich habe ein fertiges Firmwareprojekt und das soll zum Schutz des Quellcodes in eine Library umgewandelt werden, damit ein Kunde eigene Funktionen dazu entwickeln kann. Ich habe bis jetzt noch nie eine eigene Library erstellt und deshalb noch keine Erfahrung. Hat jemand damit schon Erfahrung und könnte mir einen groben Einstieg vermitteln / weis jemand Tutorial dazu?
:
Bearbeitet durch Moderator
http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD-en-US-5/index.html?GUID-C32ADD88-CB66-4995-A6F7-ABB19006CBAF libs in diesem Umfeld haben allerdings häufig die Eigenschaft, daß das Comipilat prozessorspezifisch ist. Wenn das nur für einen Kunden sein soll, der nur einen Prozessortyp verwendet, dann ist das kein Problem. Ansonsten wirds aufwendig. Oliver
Hallo, ich verwende Atmel Studio 7 und habe eine fertige Software. Die Anforderung ist nun, dass ein Kunde die Software erweitern will. Dabei soll aber unser bestehender Quellcode "geheim" bleiben. Unser Quellcode verwendet Atmel Start und ASF4. Ich dachte daran, unseren Code als Bibliothek zu übersetzen. Hat jemand schon Erfahrung damit / mit selbst erstellten Bibliotheken und hätte Tipps für mich? Danke.
Es muss kein Software-Fort-Knox werden. Außerdem sind da viele zeitkritische Routinen drin, die Laufzeit darf sich praktisch nicht ändern. Also nochmal, wie geht das mit einer Bibliothek?
Elektrolurch schrieb: > Also nochmal, wie geht das mit einer Bibliothek? Frage falsch gestellt, Antwort wäre: Es geht mit einer Bibliothek. Pack deinen geheim-Code in eine vorkompilierte Bibliothek, und liefer dazu den main()-Teil und unkritischen Source mit passendem Makefile.
:
Bearbeitet durch User
Elektrolurch schrieb: > Außerdem sind da viele zeitkritische Routinen drin, die Laufzeit darf > sich praktisch nicht ändern. Dann ist die Hauptfrage, wie sauber Ihr das alles dokumentiert habt, insbesonsere alle Seiteneffekte, damit der Kunde seine Software hinzu basteln kann. Du kannst in der Lib alle internen Symbole entfernen lassen. Nur die Aufrufadressen (API) und belegten RAM-Bereiche werden vom Linker benötigt.
Dein Geheimcode hat mit Sicherheit Referenzen auf die libc drin. Nun hast du zwei Möglichkeiten: Du kannst diese Referenzen schon lösen und den relevanten Teil der libc einbinden. Damit blähst du aber das Programm auf, denn die Kundenerweiterung und die main() müssen ihre Bezüge zur libc erneut auflösen. Oder du linkst die libc erst ganz zum Schluss dazu. Damit erleichterst du einem bösen Dieb deines geistigen Eigentums die Arbeit. Dein Code ist dann wesentlich leichter zu entwirren. Ein weiterer Punkt: Die Routinen deiner lib haben mit ziemlicher Sicherheit vernünftige, lesbare Namen. Auch diese Info hilft dem Software Dieb erheblich bei seiner Arbeit. Natürlich kannst du dir die Extra Arbeit machen und alle Bezüge mit kryptischen Namen versehen. Generell solltest du überlegen, ob dein Kunde der richtige für dich ist. Gegenseitiges Vertrauen ist bei einer Geschäftsbeziehung wichtig. Ich habe in über 50 Jahren Entwicklertätigkeit nur einmal erlebt, dass der Kunde mich über den Tisch ziehen wollte. Aber ich habe mehr als ein Dutzend mal Aufträge bekommen, ein "Pensionsprogramm" wartbar zu machen, weil der ursprüngliche Programmierer keine Lust mehr hatte oder die Unterlagen verschollen waren.
Im prinzip gibt es aus meiner ansicht 2 Ansätze: 1. der oben beschriebene, und auch von vielen verwendete. z.B. die ganzen BLE libs von nRF, ... wobei hier die HW zur separierung einiges an Funktionen schon mitliefert. 2. der umgekehrte weg, der Kunde muss eine Lib gegen eine von dir bereitgestellte API implementieren, die dann in deine Anwendung gelinkt wird. Das kann aber z.B. auch ein script sein, wenn du einen script interpreter in deiner Anwendung integrierst. Einige BT Module hersteller machen das so. Die frage ist auch immer was will der kunde alles an der HW drehen. Das er bei vollem HW zugriff dir auch dein Timing kaput pachen kann sollte dir klar sein. Er kann dir IRQ handlers verbiegen, clockings verstellen, in irgend welche HW register für deinen part falsche werte rein schreiben, ... Ohne aufwand, abstimmung und vertrauen auf das was der andere macht wird das nicht ohne probleme funktionieren. Wie soll das ganze zukünftig gewartet werden. Beide parts werden sich weiter entwickeln. Blöd wird es dann wenn dein part zusätzliche HW resourcen wie z.B. einen HW Timer benötigt, die dein Kunde für etwas anderes bereits verwendet, ....
Wirkliche Geheimnisse kannst Du Deinem Kuden nur in Hardware überlassen, etwa in nem Co-Prozessor, der dann die Geheimen Prozeduren ausführt und deinem Kd. dann die Ergebnisse zurückliefert. Denn wer Deine Library erhält, erhält auch die *.H-Dateien Deiner API. Und natürlich die Bibliothek, die er dann mit nem Disassembler angreifen kann. Da hilft dann auch kein Parser / Interpreter, denn diesen mußt Du ja deinem Kd. in der Bibliothek ja auch mitliefern. mfg
Manche Hersteller, wie z.B. Renesas und TI geben Flash-Routinen nur als Binärbibliothek weiter, die Register sind auch nirgends dokumentiert. Also sollte das ohne Problem möglich sein, die erforderlichen Randbedingungen müssen halt dokumentiert werden. Jörg
Achja, wenn Du Deinen Kd. nur von Unfug mit Deiner Library abhalten willst, schreib dein Programm in C++. Dann kannst Du mit privaten Routinen den Kd zwingen, wirklich nur die API zu benutzen, sowie alles richtig zu initialisieren. Nen Hacker hält diese Verfahrensweise natürich nicht beim Mißbrauch deiner Arbeit ab. mfg
:
Bearbeitet durch User
Elektrolurch schrieb: > Außerdem sind da viele zeitkritische Routinen drin, die Laufzeit darf > sich praktisch nicht ändern. Was, wenn der Kunde ein for(;;); in seinen Code schreibt? Läuft eure Software dann unbeeindruckt weiter? Wenn nicht, dann solltest du schriftlich festhalten, dass ihr nur eure Funktion testet und der Kunde für seine Erweiterungen und die damit verbundenen Probleme selber verantwortlich ist. Oliver S. schrieb: > Das klingt inzwischen nach einfacher Trollerei. > https://www.mikrocontroller.net/topic/545354 Ich habe die beiden Threads zum selben Thema mal zusammengefasst...
> Manche Hersteller, wie z.B. Renesas und TI geben Flash-Routinen nur als > Binärbibliothek weiter, die Register sind auch nirgends dokumentiert. Es gibt zwei Moeglichkeiten sowas zu machen. Erstens ganz normal ueber die Erzeugung einer Libarie. Dann gibt du den Leuten das Headerfile und die compileren das normal. Also genauso die z.B bei libm oder libc. Einfach mal die Doku zum Compiler lesen, da steht das alles drin. Bei den Herstellern laeuft es wohl so die noch dafuer sorgen das die Einsprungadressen im Binaerfile bekannt sind und bei Ueberarbeitungen an der Libarie so auch fest sind. Da brauchst du dann dem Kunden nur ein Funktionheader liefern welche diese Adressen aufrufen. Das hat wohl den Vorteil das Kunde nicht mit den Libarietools in den Libs rumfummeln koennen. Es scheint zumindest gut genug fuer eine RED-Zertifizierung zu sein weil das wohl gerne bei Funkzeug gemacht wird damit der Kunde nicht unerlaubte Frequenzen oder Sendeleistungen einstellen kann. Olaf
Olaf meinte: > Bei den Herstellern laeuft es wohl so die noch dafuer sorgen das die > Einsprungadressen im Binaerfile bekannt sind und bei Ueberarbeitungen an > der Libarie so auch fest sind. Da brauchst du dann dem Kunden nur ein > Funktionheader liefern welche diese Adressen aufrufen. Das hat wohl den > Vorteil das Kunde nicht mit den Libarietools in den Libs rumfummeln > koennen. hey. wie machen die das? Geben sie im Headerfile die Zeiger auf die öffentlichen Funktionen an? Dann braucht ne haeckse ja im Binärfile nur nach den "privaten" Funktionen zu suchen, die dann von höchstem Interesse sind... ;-P mfg
Wenn die Software für den Kunden aber die Bibliothek als Object File bekommt und er die Motivation hat, könnte der Kunde die Bibliothek nicht disassemblieren, um an Infos zu kommen?
Schon mal danke für konstruktive Hinweise. Ach ja, die Programmiersprache ist C (für einen embedded SAM-Prozessor) Der Kunde will hauptsächlich eine Ausgaberoutine selber machen und einen Speicherchip beschreiben / lesen können - wenn's wahr ist... @PeterD >> Du kannst in der Lib alle internen Symbole entfernen lassen Und wie? @Oliver UUps ich habe meinen Beitrag vor dem WE heute nicht mehr gefunden, deshalb nochmal neu gestellt - Asche auf mein Haupt Wie man ein GCC-Projekt neu erstellt weis ich natürlich. Nur mit Bibliotheks-Projekten kenn' ich mich nicht aus. Die Hardware, auf der alles läuft ist immer die gleiche, also auch der Prozessor. @123 >> ...die ganzen BLE libs von nRF, ... wobei hier die HW zur separierung einiges an Funktionen schon mitliefert. Sorry, aber ich verstehe nur Bahnhof >> Das er bei vollem HW zugriff dir auch dein Timing kaput pachen kann sollte dir klar sein. Ja, das ist logisch und genau das waren meine Bedenken. Dem Chef its egal... Was ist eigentlich mit den Atmel-Start Einstellungen / dem Startup-Code / ASF4-Code? Kommt das in die Bibliothek? Wie bindet der Kunde die Bibliothek dann in "sein" Projekt ein?
Elektrolurch schrieb: > Wie man ein GCC-Projekt neu erstellt weis ich natürlich. Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen Sourcecode veröffentlichen musst?
Elektrolurch meinte: > Was ist eigentlich mit den Atmel-Start Einstellungen / dem Startup-Code > / ASF4-Code? > Kommt das in die Bibliothek? Um den Startup kümmert sich der Compiler / Linker von allein, denn er wird als Erstes, noch vor "Main" ausgeführt. > Wie bindet der Kunde die Bibliothek dann in "sein" Projekt ein? Die Bibliothek kommt wei Windows ins Projektverzeichnis, bei Linux ins Standardverzeichnis, der Header wird in den Modulen, die die Bib. benötigen includiert. Außerdem wird die Lib ins Makefile bzw. in das Buildsystem bei Windows eingetragen, damit der Linker sie findet. mfg
:
Bearbeitet durch User
Alexander schrieb: > Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen > Sourcecode veröffentlichen musst? Das ignoriert er (wie so viele andere) geflissentlich.
Alexander schrieb: > Elektrolurch schrieb: >> Wie man ein GCC-Projekt neu erstellt weis ich natürlich. > > Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen > Sourcecode veröffentlichen musst? Aber doch nur, wenn er diese auch nutzt. Hab grad versucht herauszufinden welche Heder-Dateien darunter fallen, hat da einer evtl. ein Link mit einer Übersicht?
@Lotta
>> Die Bibliothek kommt wei Windows ins Projektverzeichnis, bei Linux
ins Standardverzeichnis, der Header wird in den Modulen,
die die Bib. benötigen includiert.
?? Ich programmiere mit Atmel Studio unter GCC einen embedded-Prozessor
ohne Betriebssystem etc...
@Klaus
Ähh, ja. Ich habe doch mal irgendwo gelesen, dass man den Code auch in
komerziellen Projekten verwenden darf. Und das trifft aber auf die
notwendige glibc nicht zu? Na toll...
Also jetzt habe ich mal geschaut. Im Projekt: - libarm_cortexM4l_math - libm Search Path: ..ASF/thirdparty/CMSIS/Lib/GCC
Elektrolurch schrieb: > @Lotta >>> Die Bibliothek kommt wei Windows ins Projektverzeichnis, bei Linux > ins Standardverzeichnis, der Header wird in den Modulen, > die die Bib. benötigen includiert. > > ?? Ich programmiere mit Atmel Studio unter GCC einen embedded-Prozessor > ohne Betriebssystem etc... > > @Klaus > Ähh, ja. Ich habe doch mal irgendwo gelesen, dass man den Code auch in > komerziellen Projekten verwenden darf. Und das trifft aber auf die > notwendige glibc nicht zu? Na toll... https://de.wikipedia.org/wiki/GNU-C-Bibliothek
Georg G. schrieb: > Generell solltest du überlegen, ob dein Kunde der richtige für dich ist. > Gegenseitiges Vertrauen ist bei einer Geschäftsbeziehung wichtig. Als Kunde würde ich mir vor allem überlegen, ob das der richtige Lieferant für mich wäre. Ich kenne mehrere Projekte, bei denen sich der Kunde auf die Lieferung vorkompilierter Bibliotheken einließ und sich anschließend ziemlich übel abzocken ließ. Abgesehen davon wird natürlich auch das Debugging erheblich erschwert, wenn man solch einen Klotz an Fremdfirmware unbekannter Qualität in seinem Projekt hat. In dem einen Fall wurden sämtliche Fehlerberichte abgewiesen, so dass das ganze in einem jahrelangen Streit zwischen den Rechtsabteilungen des Kunden und des Lieferanten endete. Letztendlich gab es mehrere Gerichtsurteile gegen den Lieferanten, die ihn dazu zwangen, Scheibchen für Scheibchen des Quellcodes herauszurücken. In dem anderen Fall musste eine Umstellung des internen Uhrzeitformats auf 64 Bit erfolgen, da dies durch äußere Umstände gefordert war. Der Lieferant der vorkompilierten Bibliotheken rief dann einen siebenstelligen(!) Betrag für die erforderlichen Anpassungen auf.
Alexander schrieb: > Elektrolurch schrieb: >> Wie man ein GCC-Projekt neu erstellt weis ich natürlich. > > Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen > Sourcecode veröffentlichen musst? Also so wie ich das sehe ist es nicht GPL sondern LGPL. Somit ist eine Offenlegung des Codes nicht nötig.
@ Andreas S. & Georg G. und andere Ja, ich habe bei dem Ding auch mächtig Bauchweh und habe die gleichen Befürchtungen. Aber mein Chef will es (noch?) nicht einsehen und der Kunde will das so modular haben, weil er anscheinend selbst noch nicht weis, wie er die Ausgaberoutine etc braucht... @Klaus Also da geht es doch um Linux. So wie ich das sehe, wird glibc in meinem Projekt doch gar nicht benutzt?
Wikipedia: ...Die glibc steht unter der LGPL, was den Einsatz der Bibliothek bei nicht freier Software ermöglicht. @ Adam P. Ja, so lese ich das auch.
Adam P. schrieb: > Also so wie ich das sehe ist es nicht GPL sondern LGPL. > Somit ist eine Offenlegung des Codes nicht nötig. Oh das war mir entgangen, war pauschal davon ausgegangen wo GNU drauf steht ist auch GPL drin. Der Wikipedia Artikel führt auf wie verlinkt werden muss. https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Bedingungen/technische_Einhaltung
Der Kunde will, dass er eine Routine z.B. void func_api(int, int, int)
bekommt die er ersetzen / implementieren kann.
Könnte man das in der Library so ähnlich machen wie...
void SERCOM5_0_Handler ( void ) _attribute_ ((weak,
alias("Dummy_Handler"))); /* SERCOM5_0 */
?
Wie müsste die Definition für func_api aussehen?
ob GPL oder LGPL, im embedded bereich ist das beides nicht brauchbar. Oder wie soll ich bitte schön dynamisch gegen die lib linken ohne windows / linux? Es gibt ja z.B. die newlib die steht unter BDD-3-Clause Die ist auch bei der ARM GNU Toolchain wie sie ARM zum download anbietet auch drinnen. Ausgabe routine, ... was soll das genau heissen? 3 Werte rein und ein string raus? Würde es da ggf nicht reichen einfach nur den Formatstring eines spintf irgend wie austauschbar zu machen?
Elektrolurch schrieb: > Wie müsste die Definition für func_api aussehen? Na genauso... Sag mal, wenn schon so elementare Grundfertigkeiten fehlen, wieso meinst du dass dein Code irgendwie besonders schützenswert ist? Kann es nicht eher sein, dass du den Quelltext verstecken willst, damit der Kunde nicht sieht was er da für einen Pfusch geliefert bekommt?
Prinzipiell gibt es 2 Arten von libs: Entweder enthält sie X Funktionen, die man modulweise in seinem Projekt nutzen kann oder nicht. Z.B. die stdlib. Oder es ist ein fertiges Programm, dass erweitert werden kann. Das scheint bei Dir der Fall. Hier gibt es 2 Mechanismen: entweder "erwartet" die lib 1 oder mehr konkrete Funktionen/ Datenfelder, die der Kunde in seinen C sourcen bereitstellt. Oder er füllt callback-Ptr. Real ist meist von allem etwas implementiert. Du musst Dir nur über diese 4 Arten um Klaren sein um Dir eine Aufteilung zu überlegen. Über allem schwebt die Regel in C: Was in der Applikation ist, wird nicht aus der lib geholt. Und ohne weak etc. musst Du bedenken, dass C-Files der Lib immer komplett eingebunden werden. Also muss die appl alles oder nichts (eines Files)ersetzen. (Darum sind Files manchmal nur 3 Zeilen groß)
Alexander schrieb: > Du weißt aber schon dass glibc GPL lizenziert ist Deshalb benutzt in diesem Umfeld (Cortex-M) auch kein Mensch die glibc, sondern stattdessen die newlib. Diese wiederum ist aus BSD und vergleichbar lizensierten Quellen zusammengestellt.
Wir hatten bei einem früheren Brötchengeber so einen Library-Ansatz mal in Erwägung gezogen, waren am Ende aber froh, dass der Kunde sich doch lieber dazu bereit erklärt hat, eine Sourcecodelizenz zu kaufen. ;-) Wie andere schon erwähnt haben, braucht so ein Lib-Ansatz vieeel Fürsorge in der Dokumentation (API, genutzte Hardware-Ressourcen, nötige Randbedingungen) sowie in der internen Programmierdisziplin (alle nicht als API dokumentierten globalen Funktionen und Objekte müssen "static" sein, oder aber die Dokumentation reserviert explizit einen bestimmten Namensraum für solche Dinge, und alle halten sich intern dran).
Εrnst B. schrieb: > Elektrolurch schrieb: >> Wie müsste die Definition für func_api aussehen? > > Na genauso... > Sag mal, wenn schon so elementare Grundfertigkeiten fehlen, wieso meinst > du dass dein Code irgendwie besonders schützenswert ist? > > Kann es nicht eher sein, dass du den Quelltext verstecken willst, damit > der Kunde nicht sieht was er da für einen Pfusch geliefert bekommt? Wenn die Konkurrenz unseren Quellcode in die Hände bekommt, wirft sie das um Jahre zurück ;-)
Elektrolurch schrieb: > Schutz des Quellcodes in eine Library umgewandelt werden Die Routine um den UART und 5 GPIO zu initialisieren ist natürlich supergeheim. 99% des supergeheimen Codes den ich schon gesehen habe ist einfach nur Bitschubserei und alle meinen immer, dass das um jeden Preis geschützt werden muss. Realität ist jedoch die, dass das meiste wirklich simpel ist und viel Geheimhalterei einfach nur Blödsinn ist. Und wenn ich so Kaspern vom Management dann Mal aufzeige, was sie denn alles zu bezahlen haben (=Arbeitszeit) für ATF Secure Boot LUKS, Signierung mit Hardware Dongle und TPM usw. ist der Schutz auf einmal doch nicht mehr so wichtig. Und das ist ja nur der Schutz des binary. Das gebt ihr ja schon heraus. Und von da ist es nicht mehr weit zum Verständnis des Source Codes... Für Source Code definiert man eine saubere API (editieren die da händisch einzelne Dateien wird das hinsichtlich Wartung ein Albtraum) und eine entsprechende Geschäftsvereinbarung mit NDA. Das ist selbst in Konzernen absoluter Standard. Und da geht eigentlich auch nie großartig etwas schief im Schengen-Raum außer man ist so dumm und nimmt den billigsten Chinesen oder Inder. In dem Sinne, Good Morning Sir!
Warum will der Kunde selbst programmieren ? Lasst ihr euch jeden Furz königlich bezahlen ?. Dann wird er auch nicht die Kosten für eine Lib und deren Pflege übernehmen wollen. Die Entwicklung einer "robusten" Lib mit Dokumentation ist nicht so trivial und die Folgekosten, für euch, sind schwer kalkulierbar. Behalte dabei immer die Regel: Mache eine Schnittstelle so, das sie möglichst "einfach richtig" zu benutzen und möglichst "schwer falsch" zu benutzen ist. Ihr könnt natürlich auch alles möglich kompliziert machen und dem Kunden Schulungen ohne Ende verkaufen ....
Alexander schrieb: > Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen > Sourcecode veröffentlichen musst? Die GNU C Library untersteht der LGPL. Solange er sie nur dynamisch linkt, muß er seinen Sourcecode natürlich nicht veröffentlichen.
Ein T. schrieb: > Solange er sie nur dynamisch linkt Auf einem Microcontroller? Aber wie schon geschrieben: glibc ist hier völlig irrelevant.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ein T. schrieb: >> Solange er sie nur dynamisch linkt > > Auf einem Microcontroller? Unabhängig von der Zielplattform war die Aussage, die GNU C Library unterliege der GPL, nun einmal falsch. > Aber wie schon geschrieben: glibc ist hier völlig irrelevant. Mag sein, ändert aber nichts daran, daß die erwähnte Aussage nun einmal falsch ist. Da sie aber auch von Microsoft-MVPs und anderen FUD-Trollen verbreitet wird, muß man ihr widersprechen, wo immer man sie findet.
Oder einfach erstmal den Thread lesen bevor man antwortet. Wurde bereits hier Beitrag "Re: Source code schützen und trotzdem modular" und hier korrigiert. Beitrag "Re: Source code schützen und trotzdem modular" Bitte meine Trollbeiträge ignorieren.
:
Bearbeitet durch User
Alexander schrieb: > Bitte meine Trollbeiträge ignorieren. Trollbeiträge sind das nicht, denn du hast ja nicht vorsätzlich den Thread stören wollen. GCC ist halt das eine, was man damit macht, ist das andere. Bei GCC wurde ausdrücklich darauf verzichtet, dass man in irgendeiner Form dem Kompilat eine Lizenz aufdrückt – nur der Code des Compilers selbst ist GPL (und wenn du ihn änderst oder ergänzt, fallen diese Änderungen natürlich darunter). Ein T. schrieb: > muß man ihr widersprechen, wo immer man sie findet. Du darfst dir trotzdem den Kontext vorher ansehen und erkennen, dass irgendwelche Anmerkungen in Richtung dynamisches Linken hier schlicht off-topic sind.
@A.S. >> Oder es ist ein fertiges Programm, dass erweitert werden kann. Das scheint bei Dir der Fall. Genau. >> Und ohne weak etc. musst Du bedenken, dass C-Files der Lib immer komplett eingebunden werden. Also muss die appl alles oder nichts (eines Files)ersetzen. (Darum sind Files manchmal nur 3 Zeilen groß) ?? Ist das wirklich so? Also das mit einer weak-Definition in der Library funktioniert nicht? Oder meinst du, dass die Applikations-Funktion so oder so eine gleich lautende Bibliotheksfunktion ersetzt? Aufgabe ist z.B. dass eine vom Kunden geschriebene Ausgabefunktion von einem Timer-Interrupt (in Library) aufgerufen wird. Ich schätze mal, dass das mit einem Funktionspointer am effizientesten machbar ist. Wenn ich ein Library-Projekt erstelle, habe ich wohl nicht die Möglichkeit, dies mit dem Atmel Start Konfigurator zu kombinieren? Heißt, dass Atmel Start im Kundenprojekt drin sein muss? Kann ich ASF4 in der Library benutzen? >> Hier gibt es 2 Mechanismen: entweder "erwartet" die lib 1 oder mehr konkrete Funktionen/ Datenfelder, die der Kunde in seinen C sourcen bereitstellt. Heißt das dass der Linker, eine in der Lib als extern deklarierte Funktion, die in der Applikation definiert ist, einbindet?
Dass keine Verwirrung entsteht, ich habe mich jetzt eingeloggd. Elektrolurch = Alex...
Ich hatte hier ehrlich gesagt auch zuerst an einen Trollbeitrag gedacht. Bitte nicht bös sein aber in einem Unternehmen für solche Entscheidungen verantwortlich zu sein ohne jemals eine Bibliothek erstellt zu haben ist schon sehr abenteuerlich... Wie dem auch sei, ich würde dringendst davon abraten. Man könnte in Erwägung ziehen ob sich die Integration einer Skriptsprache lohnt (z.B. MicroPython) aber alles andere ist ein NO-GO.
Alex schrieb: > Wenn ich ein Library-Projekt erstelle, habe ich wohl nicht die > Möglichkeit, dies mit dem Atmel Start Konfigurator zu kombinieren? > Heißt, dass Atmel Start im Kundenprojekt drin sein muss? > Kann ich ASF4 in der Library benutzen? Atmel Start ist in erster Linie ein (ziemlich umständlicher) Wrapper um die eigentliche Hardware. Mit Bibliothek oder nicht hat das nicht viel zu tun, denn das ist ja Sourcecode (insbesondere habe ich es als sackweise Headerfiles in Erinnerung). Eine solche kannst du im Prinzip immer erstmal draus bauen. Aber wie oben schon geschrieben: mit deinem Kenntnisstand hat das auch meines Erachtens keinen wirklichen Sinn; ihr werdet damit einfach nicht froh werden und einen unzufriedenen Kunden verprellen. Ich habe dir oben beschrieben, auf was man bei sowas alles achten müsste, wenn man es als Bibliothek rausgeben will – und selbst, wenn man weiß, wie eine Bibliothek aufgebaut ist und gebaut wird *), glaub' mir, ist das noch verdammt viel Arbeit. *) Das meint, dass du ungefähr eine Idee hast, was wie in eine Bibliothek reingehört, wie die Module da drin organsiert sind, und wie der Linker mit alldem zusammen spielt. Das impliziert auch, dass du die Tools kennst, die man dafür braucht – und die Frage, ob das irgendeine IDE direkt unterstützt, erübrigt sich dann eigentlich. Tut sie's nicht, schreibst man sich seine eigenen Makefiles oder nimmt PlattformIO oder sowas.
Georg G. schrieb: > Natürlich kannst du dir die > Extra Arbeit machen und alle Bezüge mit kryptischen Namen versehen. Dazu gibt es sogar schon Software, die das automatisch macht. Nennt sich Obfucscator. 123 schrieb: > ob GPL oder LGPL, im embedded bereich ist das beides nicht brauchbar. > Oder wie soll ich bitte schön dynamisch gegen die lib linken ohne > windows / linux? Die LGPL setzt nicht voraus, dass man dynamisch linkt, wenn man closed-source machen will, sondern dass die LGPL-Teile von demjenigen, dem du das Programm gibst, mit vertretbarem Aufwand ausgetauscht werden können. Das dynamische Linken ist nicht die einzige Möglichkeit, das zu erreichen.
Alex schrieb: > Aufgabe ist z.B. dass eine vom Kunden geschriebene Ausgabefunktion von > einem Timer-Interrupt (in Library) aufgerufen wird. > Ich schätze mal, dass das mit einem Funktionspointer am effizientesten > machbar ist. Wenn Deine Lib (Dein Programm!) eine Funktion "foo()" im Interrupt aufruft, UND Du nur diese Funktion im file "libfoo.c" erstellt hast, dann kann der Kunde seine eigene Funktion foo erstellen, wenn er will, und die wird dann statt Deiner aufgerufen. Alex schrieb: > Heißt das dass der Linker, eine in der Lib als extern deklarierte > Funktion, die in der Applikation definiert ist, einbindet? Genau. Wenn Du mit Applikation den Code des Kunden meinst. (Und "extern" ist bei Funktionen hier bedeutungslos)
@A.S. und die Anderen, die konstruktive Hilfe geleistet haben: Danke! Muss die Funktion "foo()" also tatsächlich in eine eigene Datei? Ich habe mal ein minimalstes Test-Lib-Projekt und zusätzlich ein (Kunden-)Testprojekt erstellt. Dann habe ich im Testprojekt bei den Projekteinstellungen-Linker-Library den Namen meiner Lib eingetragen und bei Pfad den Pfad zur library.o eingetragen. Trotzdem findet der Linker anscheinend meine Bibliotheksfunktionen nicht. Was mache ich falsch? Muss ich die Lib noch mit #include einbinden? Wenn ich meine Lib compilieren lasse, werden lib.o, lib.d und libGccLibrary2.a erstellt. Welche davon muss ich verwenden? Wie ist sie in den Projekteinstellungen einzutragen? Danke "für sachdienliche Hinweise" ;-)
Alex schrieb: > Muss ich die Lib noch mit #include einbinden? Bibliotheken werden nicht mittels #include eingebunden, sondern nur die zugehörigen Headerdateien, auch wenn sich diese Unsauberkeit im heutigen Arduionosprech so etabliert hat. Fehlende Prototypen bzw. (externe) Deklarationen fallen aber schon beim Kompilieren und nicht erst beim Linken auf. Ein gefährlicher Fallstrick bei C besteht darin, dass in der Signatur einer kompilierten Funktion keine Informationen über die korrekten Parameter und Rückgabewerte enthalten sind, sondern sich der Linker darauf verlassen muss, dass Aufruf und Funktionsdefinition identisch sind. Bei C++ hingegen sind zumindest grobe Informationen über die Paramtertypen in der Signatur enthalten, Stichwort "name mangeling". Damals(tm) hatte ich einen ziemlich merkbefreiten Kollegen. Wenn ihm die von einer externen Funktion geforderte Parameterliste nicht gefiel, führte er nicht etwa eine entsprechende Konvertierung der Parameter usw. durch, sondern schrieb dann mitten in den Quelltext, d.h. vor seine gerade in Arbeit befindliche Funktion, eine Deklaration der Art "extern int foo(float x)". Damit das dann nicht mit irgendwelche anderen Deklarationen kollidierte, verzichtete er auf die entsprechenden #include-Anweisungen. Und nun ratet mal, wer fast nie rechtzeitig mit seiner Arbeit fertig wurde, weil er völlig konzeptlos an seinem Code herumdoktert musste, und auf wessen Konto etwa 90% aller Fehlerberichte gingen. Um das ganze auch noch zu steigern, schickte er manchmal, vorbei an jeglicher Qualitätssicherung und reproduzierbaren Builds, seine Binaries als offizielle Releases an einen wichtigen Kunden(*). Er verstand auch nicht, dass man für einen "clean build" zuerst alles eincheckt, dann seine Arbeitskopie wegschmeißt (oder besser beiseitelegt), dann eine frische Arbeitskopie auscheckt und kompiliert. Er kompilierte hingegen ohne vorheriges Einchecken, schickte die Binaries an den Kunden, löschte dann seine Sandbox und checkte frisch aus. Nicht nur er, sondern auch die anderen Entwickler stellten anschließend fest, dass der Code nicht einmal kompilierte. Und dank des Löschens der alten Arbeitskopie waren Teile des Quellcodes unwiderbringlich verloren und mussten von ihm auf Grund seiner Erinnerungen noch einmal nachprogrammiert werden. Und damit ihm das nicht noch einmal passierte, ging er dann dazu über, am Ende des Arbeitstages eine rekursives "cvs add" mit "cvs commit" auf seinem Entwicklungsrechner zu machen, so dass dann alle anderen Entwickler beim nächsten Update seine ganzen temporären Dateien und sonstigen Dateischrott auf ihren Rechnern vorfanden. Und dann verstand er überhaupt nicht, warum ihm eines Tages gekündigt wurde. Zu (*): Die E-Mail-Adresse des technischen Ansprechpartners dieses sehr wichtigen Kunden hatte er nur deswegen, weil der zuständige Projektleiter dem Kunden empfahl, die Unmengen an Fehlerberichten direkt an den Entwickler zu schicken. Niemand ahnte, dass der Entwickler dann so blöd sein könnte, seine hingerotzten Binaries direkt an den Kunden zu schicken und dem Kunden zu vermitteln, es handele sich dabei um offizielle Releases.
@Andreas S.: Sorry, aber das ist nicht so nett, deine lange Lebensgeschichte mit reinzupacken. Diese beantwortet mir meine Fragen nicht.
Alex schrieb: > @Andreas S.: > Sorry, aber das ist nicht so nett, deine lange Lebensgeschichte mit > reinzupacken. Diese beantwortet mir meine Fragen nicht. Dann heul doch.
Alex schrieb: > Diese beantwortet mir meine Fragen nicht. Du wirst leider nicht umhin kommen, dir die Grundlagen zum Linker, Objektmodulen und Bibliotheken mal anzulesen. Du kannst nicht erwarten, dass dir diese hier in einem Forumsartikel beigebracht werden können. Früher™ hatte man für sowas bedrucktes Papier. Heutzutage sind Verlage wie O'Reilly nett genug, dir das sogar noch online und kostenlos zur Verfügung zu stellen – nur lesen musst du es schon noch selbst. Starthilfe: https://www.oreilly.com/library/view/programming-embedded-systems/0596009836/ch04.html Sorry, die Art deiner Fragen zeigt einfach, dass du nicht irgendeine spezielle Frage hast (sowas kann man einfach in einem Forum beantworten), sondern dass dir die Grundlagen fehlen.
1) Schaue nach, welche Endung LIBs bei Dir haben.
2) Frage den Compiler/die IDE (per Google), wie LIBs bei Dir erstellt
werden
3) Mache eine Applikation, die quasi nur 2 dummy Funktionen aufruft und
den Rückgabewert ausgibt, z.B.:
int A(void) {return 1;}
int B(void) {return 2;}
int main(void) {printf("A=%i, B=%i", A(), B());}
(ausprobieren)
4) Mache eine neue LIB myLib aus 2 C-Files: a.c mit int A(void) {return
3;} und b.c entsprechend.
5) Füge Deine LIB zum Projekt hinzu (ausprobieren, es passiert noch
nichts)
6) Kommentiere die Funktion A in Deinem main aus.
--> Poste die Warnungen hier und lass Dich dafür schelten, wenn da nicht
mehrere kommen. Trotzdem sollten nun 3 und 2 ausgegeben werden, es
werden auch keine Header der Lib benötigt.
Alexander schrieb: > Elektrolurch schrieb: >> Wie man ein GCC-Projekt neu erstellt weis ich natürlich. > > Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen > Sourcecode veröffentlichen musst? stimmt nicht. Es ist bei glbic die LGPL. Da gelten andere Regelungen. Zudem muß man auch bei GPL den Code nicht veröffentlichen, nur muß man dem Empfänger den geänderten Code zur Verfügung stellen. Wenn der den dann nicht veröffentlicht, bleibt der Code geheim, nur es liegt halt nicht mehr in der eigenen Hand. Gruß Robert
der_eine schrieb: > stimmt nicht. Ooooch, nicht nochmal. Wurde zur Genüge durchgekaut und hat mit dem Thread nun wirklich gar nichts zu tun. Wie wäre es, vor der Antwort einfach mal den ganzen Thread zu lesen?
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.