HEX-Datei + Include möglich?

Wolfgang Horn Gast #285291
Lesenswert?
• ▲
▼ 
Hi, Ron,

"Es geht darum, einen Teil des Codes "zu verstecken" und einen
anderen
Teil anpaßbar zu halten."

Hm. Was verstehst Du unter "verstecken?"

Code vor dem Compiler zu verstecken, weil Du diesen Code nur zum
Debuggen brauchst, aber nicht in der Release-Version? Den schließt man
besser in #ifdefine DEBUG und #endif ein.

Code vor der Ausführung zu verstecken, so eine Art Overlay-Technik?
Kenne ich vom ADSP21160 und anderen Prozessoren mit Code im
RAM-Speicher, aber nicht im Embedded-Bereich.

Dann könnte ich Deine Frage noch so verstehen: Ja, möglich ist
natürlich die Interpreter-Technik: Im Flash steht der Interpreter für
BASIC oder FORTH, in das SRAM des Prozessors schreibst Du - und
könntest sogar "on the fly" ändern - das zu interpretierende
Programm.

Wenn Du etwas anderes gemeint hast, dann schreib' bitte noch mal
konkreter.

Ciao
Wolfgang
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ron Gast #285293
Lesenswert?
• ▲
▼ 
Code vor dem Anwender verstecken. Also ich will nicht, daß jemand
anderes mir in das Hauptprogramm schaut, er soll aber eine Include (?)
verändern können und dann neu compilieren etc.

Das man die HEX-Datei auch lesen und zurückübersetzen kann, ist mir
dabei klar und ist hinnehmbar, da ich denke, wer sich so viel Mühe
macht, darf dann auch alles Wissen ;-) Wobei er vermutlich mit neu
programmieren schneller gewesen wäre.

Jetzt verständlicher?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
peter dannegger Gast #285294
Lesenswert?
• ▲
▼ 
"Es geht darum, einen Teil des Codes "zu verstecken" und einen
anderen
Teil anpaßbar zu halten."

Klingt nach einem 8051-Derivat mit Code im internen Flash und noch
Flash extern drangepappt.


Einfach ist das ganze auf keinen Fall.
Erst recht nicht, wenn man in C programmiert, da muß man sich gründlich
in die Internas des verwendeten Compilers einlesen.


Man muß irgendeine Art Dispatcher programmieren, d.h. am Anfang des
externen Flash steht eine Struktur, die die Aufrufadressen, die
Parameterformate und überhaupt das Vorhandensein der externen
Funktionen enthält.


Peter
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #285297
Lesenswert?
• ▲
▼ 
Hi

dann compilierst du die Routinen deren Sourcecode du "verstecken"
willst in eine .o Datei und lieferst die dann mit. Der der diese
Routinen dann verwenden will linkt sie einfach zum Projekt dazu. Du
kannst mit avr-ar auch eine Bibliothek erstellen wenn du mehrere .o
Dateien ausliefern willst. Ist im Prinzip ganz einfach. Achte aber
darauf den Compiler keine Debugsymbole in die .o Datei schreiben zu
lassen (nicht -g an der Kommandozeile angeben) oder entferne diese vor
der Auslieferung mit avr-strip

Matthias
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ron Gast #285298
Lesenswert?
• ▲
▼ 
OK. So halb habe ich es verstanden. Bleibt nur noch eine Frage:

Ich nutze immer das Standard-Makefile, wie es auch im Tutorial benutzt
wird. Wie kann ich dem denn klar machen, daß ich einmal nur die
Objektdatei haben will und dann beim zweiten mal diese dazu gelinkt
werden soll?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #285299
Lesenswert?
• ▲
▼ 
Hi

Grundsätzlich solltest du dir etwas Grundwissen zur Funktionsweise der
GCC Toolchain aneignen.

Es wird mit dem Standard Makefile immer eine .o pro C-Datei erzeugt.
Die kannst du so ausliefern (evtl. Debuginformationen entfernen). Beim
linken fügst du diese dann einfach dazu. Wie und ob man das mit dem
Standardmakefile bzw. mit MFile realisieren kann weiß ich nicht da ich
meine eigenen makefiles verwende.

Matthias
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ron Gast #285300
Lesenswert?
• ▲
▼ 
Vielleicht habe ich ja ein Brett vor'm Kopf, aber da ich auch im Web
nicht fündig werde, hier noch mal meine Bitte um eine Einführung in C

Ich will das machen, wobei geheim.h nicht weitergegeben werden soll,
sondern nur als Objectdatei

geheim.h:
void geheimeaktion ()
{
  // irgendwas
}

public.h:
void publicaktion ()
{
  // was anderes
}

haupt.c:
#include geheim.h
#include public.h
void main ()
{
  geheimeaktion();
  publicaktion();
}

Jetzt kann ich public.h und geheim.h mit (vereinfachter Aufruf)
gcc -c geheim.h
gcc -c public.h
in Objectdateien übersetzen

Wie compiliere und linke ich aber haupt.c? Da fehlt doch noch
irgendwas.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Μαtthias W. Persönliche Seite #285301
Lesenswert?
• ▲
▼ 
Hi

erstmal:
Funktionen gehören niemals (es gibt Ausnahmen die wir jetzt mal
ignorieren) in .h Dateien. .h Dateien beschreiben Schnittstellen,
.c-Dateien enthält die Implementierung.

geheim.h
1
void geheimeaktion (void);


geheim.c
1
void geheimeaktion (void)

2
{

3
  //some C code

4
}


nichtgeheim.h
1
void aktion (void);


nichtgeheim.c
1
void aktion (void)

2
{

3
  //some C code

4
}



haupt.c
1
#include "geheim.h"

2
#include "nichtgeheim.h"

3


4
int main (void)

5
{

6
  aktion();

7
  geheimeaktion();

8


9
  return 0;  

10
}


Dann:

gcc -c geheim.c
gcc -c nichtgeheim.c
gcc -c haupt.c
gcc geheim.o nichtgeheim.o haupt.o

Du lieferst dann geheim.h zusammen mit geheim.o aus.

Matthias
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #285302
Lesenswert?
• ▲
▼ 
Zunaechst mal nennst Du die Dateien mit dem Code, den Du nicht
als Source weitergeben willst um in geheim.c.
Source Code steht immer in *.c Dateien. In den *.h Dateien
beschreibst Du nur welche Funktionen es gibt, wie sie heissen
und welche Parameter sie haben. Diese *.h Dateien braucht Dein
Endbenutzer, weil er sie per #include in seinen Source Code
einbinden muss.

geheim.h
********

void geheimaktion();

geheim.c
********

#include "geheimaktion.h"
void geheimaktion()
{
  /* hier ist die Implementierung von geheimaktion */

haupt.c
*******
#include "geheimaktion.h"

int main()
{
  geheimaktion();
}

Compiliert wird
  haupt.c   zu haupt.o
  geheim.c  zu geheim.o

Dann werden haupt.o zusammen mit geheim.o zum fertigen
Program gelinkt.

Wenn soweit alles stimmt, dann gibst du weiter:
   geheim.o
   geheim.h

Dein Benutzer kann sich dann ein neues haupt.c schreiben.
Dazu braucht er die geheim.h und zum linken die geheim.o

Wie das ganze konkret ablaeuft haengt nicht unwesentlich vom
verwendeten Compiler ab. Du musst also dessen Doku studieren,
wie beim Linken die Objectfiles angegeben werden.

Und Nein: Den Code in ein *.h File zu packen mag fuer Dich
jetzt zwar einfacher aussehen, ist aber definitiv die falsche
Vorgehensweise.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ron Gast #285303
Lesenswert?
• ▲
▼ 
@*

Vielen Dank! Jetzt habe ich es gerafft und alles klappt. Das mit dem
Aufteilen von .h und .c war mir bisher immer entgangen. Jetzt macht das
doch gleich viel mehr Sinn.

Bleibt nur die Frage: fluche ich jetzt auf die Literatur oder mich? :-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren