Hallo,
ich habe einen Bootloder für einen AVR128DA28 geschrieben bei dem
APPCODE und APPDATA getrennt gebrannt werden können. Aus Performance
gründen würde ich gerne die aus dem Atmel Studio erzeuge intel hex Datei
auftrennen ohne ein externes Tool programmieren zu müssen.
Quasi eine hex Datei für APPCODE und eine für APPDATA. Kann Atmel Studio
sowas überhaupt?
Um Code im APPDATA abzulegen verwende ich Folgenden Befehl:
Die Linker variable .APPDATA ist an die FUSES angepasst und beinhaltet
die Adresse 0xC700. Der APPCODE Bereich befindet sich in der selben
Datei nur ohne Attribut (bzw. die vordefinierte .text linker variable
ist auf die Adresse nach dem Bootloader eingestellt). Ich füge mal eine
Beispiel Datei zur Veranschaulichung an.
Besten dank
BG
Umbrecht
Stored B. schrieb:> Aus Performance> gründen
Welche Performance?
> würde ich gerne die aus dem Atmel Studio erzeuge intel hex Datei> auftrennen ohne ein externes Tool programmieren zu müssen.
Na dann nimm halt einen der unzähligen existierenden Text-Editoren.
Genau das ist *.hex nämlich: reiner Text.
c-hater schrieb:> Welche Performance?
100% zu übertragen dauert länger als 50%.
c-hater schrieb:> Na dann nimm halt einen der unzähligen existierenden Text-Editoren.> Genau das ist *.hex nämlich: reiner Text.
Warum sollte ich so etwas wollen?
Stored B. schrieb:> 100% zu übertragen dauert länger als 50%.
Das kommt mir so vor wie der Autofahrer der im Stadtverkehr mit
Vollgas auf die nächste rote Ampel zufährt um dort dann länger
auf die Grünphase warten zu dürfen.
Stored B. schrieb:> Warum sollte ich so etwas wollen?
Weil es damit möglich ist, genau das zu tun, was du tun willst?
> Quasi eine hex Datei für APPCODE und eine für APPDATA. Kann Atmel Studio> sowas überhaupt?
Im Übrigen geht natürlich auch das. Man macht einfach zwei Projekte.
Eins für den Bootloader und eins für die Anwendung. Die beiden Projekte
dürften sogar in einer Projektmappe sein, wobei ich den Sinn hier nicht
wirklich sehen würde, denn schließlich ist es ja der typische Job eines
Bootloaders, verschiedene Anwendungen laden zu können.
c-hater schrieb:> Weil es damit möglich ist, genau das zu tun, was du tun willst?
Sicher aber ich möchte es ja automatisch haben.
c-hater schrieb:> Im Übrigen geht natürlich auch das. Man macht einfach zwei Projekte.> Eins für den Bootloader und eins für die Anwendung. Die beiden Projekte> dürften sogar in einer Projektmappe sein, wobei ich den Sinn hier nicht> wirklich sehen würde, denn schließlich ist es ja der typische Job eines> Bootloaders, verschiedene Anwendungen laden zu können.
Ich kenne diese Funktion und nutze sie tatsächlich, allerdings macht es
mir in meiner Anwendung mehr sinn in einem Projekt direkt zu bleiben.
Der Bootloader wird nicht verändert. Aktuelle AVRs haben 3 Sektoren
Bootloader, APPCODE und APPDATA. Die zwei zuletzt genannten werden quasi
vom Bootloader geschrieben. Und das kann durch eine Datei geschehen oder
eben durch zwei.
beo bachta schrieb:> Das kommt mir so vor wie der Autofahrer der im Stadtverkehr mit> Vollgas auf die nächste rote Ampel zufährt um dort dann länger> auf die Grünphase warten zu dürfen.
Ich sehe mich da eher als jemanden der die Ampelschaltung kennt und die
Rotphase ohne Bremsereien überwinden kann.
paulsen schrieb:> Ja, das Leben ist kurz. Wieviel Zeitgewinn erhoffst du dir?
Selbst wenn es nur 0,5us sind, wo ist dann das Problem? Warum muss man
immer diskutieren?
Stored B. schrieb:> Ich kenne diese Funktion und nutze sie tatsächlich, allerdings macht es> mir in meiner Anwendung mehr sinn in einem Projekt direkt zu bleiben.
Warum?
> Der Bootloader wird nicht verändert. Aktuelle AVRs haben 3 Sektoren> Bootloader, APPCODE und APPDATA. Die zwei zuletzt genannten werden quasi> vom Bootloader geschrieben. Und das kann durch eine Datei geschehen oder> eben durch zwei.
Na dann eben drei Projekte. Eins für den Bootloader, eins für das, was
in Appcode landen soll und eins dafür, was in Appdata landen soll.
> Selbst wenn es nur 0,5us sind, wo ist dann das Problem? Warum muss man> immer diskutieren?
Klar, Unsinn muss man immer diskutieren. Und sei es nur dazu, um
klarzustellen, dass es sich um Unsinn handelt.
Stored B. schrieb:> paulsen schrieb:>> Ja, das Leben ist kurz. Wieviel Zeitgewinn erhoffst du dir?>> Selbst wenn es nur 0,5us sind, wo ist dann das Problem? Warum muss man> immer diskutieren?
Äh, darf man nicht mehr nachfragen??
c-hater schrieb:> Na dann eben drei Projekte. Eins für den Bootloader, eins für das, was> in Appcode landen soll und eins dafür, was in Appdata landen soll.
Ok, angenommen ich mache das. Wie kann ich dann vom APPCODE Projekt auf
eine Funktion im APPDATA Projekt zugreifen? Hier stehe ich etwas auf dem
Schlauch..
paulsen schrieb:> Äh, darf man nicht mehr nachfragen??
Kommt darauf an welche Frage. Aber ich denke wenn die erste Frage schon
so ging eher nein.
Stored B. schrieb:> paulsen schrieb:>> Äh, darf man nicht mehr nachfragen??>> Kommt darauf an welche Frage. Aber ich denke wenn die erste Frage schon> so ging eher nein.
Dann entschuldige bitte, dass ich helfen wollte. (Wollte dein Problem,
die Randbedingungen halt besser verstehen...)
Stored B. schrieb:> Ok, angenommen ich mache das. Wie kann ich dann vom APPCODE Projekt auf> eine Funktion im APPDATA Projekt zugreifen? Hier stehe ich etwas auf dem> Schlauch..
Indem man einen Header generiert, der die Funktionen und die
dazugehörigen Adressen exportiert und diesen Header dann einbindet. Was
denn sonst?
c-hater schrieb:> Indem man einen Header generiert, der die Funktionen und die> dazugehörigen Adressen exportiert und diesen Header dann einbindet. Was> denn sonst?
Schon klar aber dann dreht man sich ja im Kreis. Dann habe ich zwar
reinen APPDATA Code aber der APPCODE Code ist gemischt mit APPDATA. Oder
sehe ich das Falsch?
Stored B. schrieb:> c-hater schrieb:>> Welche Performance?>> 100% zu übertragen dauert länger als 50%.
Das ist keine Antwort.
Ich gehe davon aus, daß im Endeffekt immer Bootloader, APPCODE und
APPDATA in den µC geschrieben werden müssen. Durch das einzelne
Schreiben von APPCODE und APPDATA verlierst du sogar Zeit.
Ausnahme: die Entwicklungsphase, wo eventuell nur eines der beiden
geändert wurde. Aber genau da ist der Zeitgewinn doch irrelevant? Also
solange der Bootloader mehr als 2 Byte pro Minute übertragen kann.
Ansonsten ist das relativ trivial. objcopy kann sections ausschneiden.
Damit erzeugst du nach dem Linken, aber vor der Konvertierung zu Hex,
zwei Files. Eins nur mit der APPDATA section und eins mit allem anderen.
Dann konvertiert du beide zu Hex. Nun brauchst du nur noch etwas Magie,
um herauszufinden welches File sich geändert hat (Prüfsumme?) damit du
es flashen kannst.
Jetzt mußt du bloß noch rausfinden, wie du das dem Studio beibiegst. Mit
make wäre das trivial. Mit Atmel Studio? <schulterzuck>
PS: den Trick mit objcopy kann man sich von alten AVR-Makefiles
abschauen. Da wurde genau so mit der EEPROM section verfahren.
Axel S. schrieb:> Ich gehe davon aus, daß im Endeffekt immer Bootloader, APPCODE und> APPDATA in den µC geschrieben werden müssen. Durch das einzelne> Schreiben von APPCODE und APPDATA verlierst du sogar Zeit.
Bootloader wird nicht verändert. APPCODE und APPDATA können gemeinsam
auf den FLASH gebrannt werden oder jeder Sektor einzeln. D.H. der
Bootloader vergleicht mit den eingestellten Adressen. Wurde APPCODE
gewählt und es werden Daten für APPDATA empfangen, werden diese
Ignoriert und nicht gebrannt.
Axel S. schrieb:> Jetzt mußt du bloß noch rausfinden, wie du das dem Studio beibiegst. Mit> make wäre das trivial. Mit Atmel Studio? <schulterzuck>>> PS: den Trick mit objcopy kann man sich von alten AVR-Makefiles> abschauen. Da wurde genau so mit der EEPROM section verfahren.
Wäre intressant.
Stored B. schrieb:> Schon klar aber dann dreht man sich ja im Kreis. Dann habe ich zwar> reinen APPDATA Code aber der APPCODE Code ist gemischt mit APPDATA.
Was verstehst du unter "gemischt"? Bezüglich der Lage im Speicher ist
dadurch natürlich nichts gemischt.
Aber natürlich ruft der Code in Appcode dann Code auf, der in Appdata
liegt. Aber das genau war doch auch das Ziel der Operation, oder?
Wenn nicht, braucht der Code in beiden Bereichen ja überhaupt nichts von
dem jeweils anderen zu wissen. Dann braucht man natürlich auch keine
Information über einen Header austauschen.
Stored B. schrieb:> Axel S. schrieb:>> Ich gehe davon aus, daß im Endeffekt immer Bootloader, APPCODE und>> APPDATA in den µC geschrieben werden müssen. Durch das einzelne>> Schreiben von APPCODE und APPDATA verlierst du sogar Zeit.>> Bootloader wird nicht verändert. APPCODE und APPDATA können gemeinsam> auf den FLASH gebrannt werden oder jeder Sektor einzeln.
Das ist mir durchaus klar. Nur: auf einen niegelnagelneuen µC muß
alles draufgeschrieben werden. Und weil man den Bootloader da noch nicht
hat, muß man den µC dazu anderweitig an den Brenner bringen. Und wenn
man das hat, kann man auch gleich alles in einem Rutsch flashen.
Zumindest in der Serienfertigung. Und das wäre das einzige, wo der
Gewinn an Geschwindigkeit sich irgendwie bemerkbar machen würde.
Bei der Entwicklung ist es zumindest denkbar, daß sich nur einer der
beiden Teile ändert. Aber da hat man nichts vom Geschwindigkeitsgewinn.
Und Updates beim Kunden? Da wird man alles überbügeln. Schon weil man
gar nicht weiß, was der alte Stand ist.
>> PS: den Trick mit objcopy kann man sich von alten AVR-Makefiles>> abschauen. Da wurde genau so mit der EEPROM section verfahren.>> Wäre intressant.
Machen. Nicht labern.
c-hater schrieb:> Aber natürlich ruft der Code in Appcode dann Code auf, der in Appdata> liegt. Aber das genau war doch auch das Ziel der Operation, oder?
Ich verstehe APPDATA so, daß da DATEN liegen. Kein Code.
c-hater schrieb:> Axel S. schrieb:>>> Ich verstehe APPDATA so, daß da DATEN liegen. Kein Code.>> Dann hast du dir den Code aus dem OT nicht angesehen...
Im Endeffekt soll beides Funktionieren, vermutlich stehen später aber
nur noch Daten drin. Für mein Problem macht es aber keinen Unterschied.
c-hater schrieb:> Aber natürlich ruft der Code in Appcode dann Code auf, der in Appdata> liegt. Aber das genau war doch auch das Ziel der Operation, oder?
Richtig. Ich versuche es mal so zu erklären wie ich es von dir
Verstanden habe.
Ich habe in APPDATA z.B. die Funktion (void)uart_string(char *s) {...}.
Angenommen APPDATA ist ein eigenes Projekt, wird nur dieser Teil
erzeugt, was gut ist.
Im Projekt für APPCODE rufe ich über einen Header die im APPDATA
befindliche uart_string Funktion auf. Dadurch wird aber nicht nur ein
"call" gemacht sondern die ganze Funktion eingebunden und somit habe ich
im APPCODE.hex auch APPDATA daten (in dem Fall natürlich nur die eine
Funktion).
Oder gibt es dafür attribute die ich nicht kenne um das zu verhindern?
Stored B. schrieb:> Im Projekt für APPCODE rufe ich über einen Header die im APPDATA> befindliche uart_string Funktion auf. Dadurch wird aber nicht nur ein> "call" gemacht sondern die ganze Funktion eingebunden und somit habe ich> im APPCODE.hex auch APPDATA daten (in dem Fall natürlich nur die eine> Funktion).
Woher weisst du das? Wenn uart_string per attribute ins APPDATA-Segment
gelegt wird, dann liegt die da auch. Sollte der Compiler die wirklich
ins APPCODE-Segment inlinen, kannst du das mit noiline verhindern.
Da du aber jetzt von einem "APPCODE"-Projekt sprichst, erkläre doch
nochmal, was du genau vorhast. Das klingt alles noch etwas wirr.
Oliver
Oliver S. schrieb:> Woher weisst du das?
Weil ich es im hex file sehe.
Oliver S. schrieb:> Wenn uart_string per attribute ins APPDATA-Segment> gelegt wird, dann liegt die da auch.
Das stimmt ja auch.
Oliver S. schrieb:> erkläre doch> nochmal, was du genau vorhast.
Ganz konkret, es soll eine APPCODE.hex und eine APPDATA.hex geben. In
APPCODE.hex soll im Endeffekt nur die Aufrufadresse der Funktion aus
APPDATA stehen, und nicht die ganze Funktion.
Folgender Ausschnitt der APPCODE.hex Datei beinhaltet Speicherbereiche
der APPCODE und APPDATA Sektion:
Die unteren zwei Zeilen gehören aber nicht in diese Hex Datei.
Theoretisch kann ich natürlich nun hergehen und diese Löschen, da sie ja
in der APPDATA.hex enthalten sind. Aber ich möchte dass das Automatisch
"ausgeblendet" wird.
Stored B. schrieb:> Ganz konkret, es soll eine APPCODE.hex und eine APPDATA.hex geben. In> APPCODE.hex soll im Endeffekt nur die Aufrufadresse der Funktion aus> APPDATA stehen, und nicht die ganze Funktion.
Wenn du so vorgehst, wie ich beschrieben habe (also mit getrennten
Projekten), passiert genau das. In APPCODE steht dann nur noch ein call
oder rcall <Adresse in APDATA>. Wie sollte da auch mehr stehen? Der
Compiler kennt dann doch nur die Signatur der Funktion und ihre
Aufrufadresse (beides aus dem Header), über den Rumpf der aufzurufenden
Funktion weiss er rein garnix. Dementsprechend ist es ihm auch völlig
unmöglich, den Inhalt der Funktion irgendwie nach APPCODE zu
transferieren.
Stored B. schrieb:> Oliver S. schrieb:>> erkläre doch>> nochmal, was du genau vorhast.>> Ganz konkret, es soll eine APPCODE.hex und eine APPDATA.hex geben. In> APPCODE.hex soll im Endeffekt nur die Aufrufadresse der Funktion aus> APPDATA stehen, und nicht die ganze Funktion.
Wenn du Code zwischen Projekten sharen willst, dann brauchst du eine
Konvention, wie der Aufruf erfolgen soll. Gebräuchlich wären Sprung-
oder Vektortabellen auf einer festen Adresse.
Normalerweise löst der Linker die Bezüge zwischen Modulen auf, nachdem
er sie im Adreßraum (ziemlich willkürlich) angeordnet hat. Aber das
funktioniert so natürlich nur, wenn du ein Projekt hast.
Es klingt aber immer mehr wie eine Schnapsidee.
Axel S. schrieb:> Wenn du Code zwischen Projekten sharen willst, dann brauchst du eine> Konvention, wie der Aufruf erfolgen soll.
Ja klar. Wäre hier halt die Standardkonvention des Compilers.
> Gebräuchlich wären Sprung-> oder Vektortabellen auf einer festen Adresse.
Das allerdings hat mit den Aufrufkonventionen rein garnix zu schaffen.
Das wäre nur eine (zusätzliche) Vereinbarung zur Beschaffung der
Einsprungadresse. Eigentlich unnötig. Reduziert allenfalls den Aufwand
zur Generierung der Header-Datei. Und das auch nur, so lange sich das
API nicht ändert...
c-hater schrieb:> Axel S. schrieb:>>> Wenn du Code zwischen Projekten sharen willst, dann brauchst du eine>> Konvention, wie der Aufruf erfolgen soll.>> Ja klar. Wäre hier halt die Standardkonvention des Compilers.
Was du meinst ist das ABI. Darum geht es mir nicht. Auch wenn das
natürlich außerdem noch passen muß (oder man kann keine Parameter /
Returnwerte verwenden).
>> Gebräuchlich wären Sprung->> oder Vektortabellen auf einer festen Adresse.>> Das allerdings hat mit den Aufrufkonventionen rein garnix zu schaffen.
So wie ich das gemeint habe schon.
Aber gut. Nennen wir es halt "Methode zur Bekanntmachung der Adressen
von Speicherobjekten in der APPDATA Sektion"
> Das wäre nur eine (zusätzliche) Vereinbarung zur Beschaffung der> Einsprungadresse. Eigentlich unnötig.
Keineswegs. Zumindest dann, wenn man beide Teilprojekte unabhängig
voneinander (weiter)entwickeln will. Wenn man das nicht will, braucht es
aber den ganzen Zirkus mit einzeln flashen gar nicht.
Ich bleibe dabei:
Axel S. schrieb:> Es klingt aber immer mehr wie eine Schnapsidee.
Da muß schon was substantielles kommen, um mich zu überzeugen.
Stored B. schrieb:> Ganz konkret, es soll eine APPCODE.hex und eine APPDATA.hex geben.
Was ja erst einmal kein Problem ist.
Stored B. schrieb:> Folgender Ausschnitt der APPCODE.hex Datei beinhaltet Speicherbereiche> der APPCODE und APPDATA Sektion:
Wie hast du denn APPCODE.hex erzeugt? Wenn da Adressen von APPDATA drin
stehen, hast du offensichtlich was falsch gemacht.
Daher nochmal: Beschreib doch nicht, was deiner Meinung nach nicht geht,
sondern, was du vorhast.
Willst du APPCODE.hex und APPDATA.hex unabhängig voreinander aus den
gleichen Sourcen erzeugen?
Oliver
Axel S. schrieb:> Keineswegs. Zumindest dann, wenn man beide Teilprojekte unabhängig> voneinander (weiter)entwickeln will. Wenn man das nicht will, braucht es> aber den ganzen Zirkus mit einzeln flashen gar nicht.
Nun, das ist ein Szenario. Mir schwebte eher ein anderes vor. Nämlich
das von quasikonstantem "ROM-Code". Sprich: Appdata enthält eine
umfangreiche Sammlung von gut durchgetestetem Code, der in vielen
Anwendungen nützlich sein kann.
c-hater schrieb:> Nun, das ist ein Szenario. Mir schwebte eher ein anderes vor. Nämlich> das von quasikonstantem "ROM-Code". Sprich: Appdata enthält eine> umfangreiche Sammlung von gut durchgetestetem Code, der in vielen> Anwendungen nützlich sein kann.
Das klingt eher nach einem Anwendungsfall für "ich baue mir eine
Bibliothek und linke diese statisch in meine Projekte".
In dem Fall aber aufpassen - Anpassungen auf verschiedene
Controllertypen per Präprozessor funktionieren in der Bibliothek nicht
mehr, ohne sie neu zu kompilieren. Und dann könnte man auch gleich den
Code einfach in jedes Projekt kopieren...
c-hater schrieb:> Das allerdings hat mit den Aufrufkonventionen rein garnix zu schaffen.> Das wäre nur eine (zusätzliche) Vereinbarung zur Beschaffung der> Einsprungadresse. Eigentlich unnötig. Reduziert allenfalls den Aufwand> zur Generierung der Header-Datei. Und das auch nur, so lange sich das> API nicht ändert...
Funktioniert dieses "Function Sharing" auch wenn z.B. am Bootloader
Nachträglich was geändert wird? Oder muss man dann irgendwelche Adressen
im Hauptprogramm noch anpassen?
Falls nein, gibt es da irgendwelche Beispiele dazu? Vielleicht hilft es
dem TO ja was.
XM
Xavier Meinert schrieb:> Vielleicht hilft es> dem TO ja was.
Der ist anscheinend bei dem Versuch, zu verstehen, was er eigentlich
überhaupt machen will, in der Versenkung verschwunden.
Oliver
Nachdenklicher schrieb:> Das klingt eher nach einem Anwendungsfall für "ich baue mir eine> Bibliothek und linke diese statisch in meine Projekte".
Das ist natürlich nicht dasselbe.
Insbesondere hast dann eben nicht die Trennung der Code-Bereiche, die
offensichtlich gewünscht ist. Warum auch immer das für den TO so
erstrebenswert sein mag...
Ich würde darauf tippen, dass das letztlich ein "verbesserter"
Kopierschutz werden soll. Natürlich hoffnungslos. Aber das wird er schon
noch rausfinden, falls es tatsächlich um sowas ging.
Letztendlich ist der APPDATA-Teil eine Art dynamisch gelinkter lib, nur
das es auf dem System keinen Linker gibt, der zur Runtime die Symbole
auflöst.
Daher muß die Symbolauflösung von Hand (in Assembler) dazu gebaut
werden.
Oliver
Oliver S. schrieb:> Letztendlich ist der APPDATA-Teil eine Art dynamisch gelinkter lib, nur> das es auf dem System keinen Linker gibt, der zur Runtime die Symbole> auflöst.
Nein, das ist natürlich Unsinn. Es ist eher ein Spezialfall einer
statisch gelinkten Lib. Nämlich der, dass der Compiler (und auch der
Linker) nichts über den Inhalt der aufzurufenden Funktion weiss.
Inlining verbietet sich also von selbst, LTO ist garnicht möglich, weil
der ggf. auszusiebende Code garnicht im Compile-Umfang der App ist.
> Daher muß die Symbolauflösung von Hand (in Assembler) dazu gebaut> werden.
So sehr ich Asm auch mag: Nein, braucht man hier wirklich nicht. Wozu
auch? Höchstens um zu verstehen, was wirklich passiert (ein immer
überaus empfehlenswerter Ansatz)...
Alles passiert zur Compiletime (der Anwendung). Der Comiler erfährt aus
dem Header den Namen (oder meinetwegen auch: das "SYMBOL") der Funktion
(was allerdings nur zur Compiletime noch irgendeinen Nutzen hat), die
Signatur der Funktion (die die Genererierung des Codes vor und ggf. auch
nach dem Aufruf steuert, je nach Aufrufkonvention) und die absolute
Adresse der Funktion, die den Job machen soll. Der Compiler weiß also
alles, was er wissen muß, um die Funktion korrekt und direkt aufzurufen.
Wozu sollte da noch irgendwas zur Laufzeit passieren? Und was?
Der Trick ist im Kern eigentlich nur, die Aufrufadresse der Funktion mit
in den Header zu packen, den der Compiler der Anwendung zu sehen
bekommt. Und wenn man wissen will, wie man sowas macht, ist "ROM-Code"
keine schlechtes Google-Futter (zumindest als Teil des Suchausdrucks)...
Du kriegst das schon hin, noch zwei Winter und auch du kommst
dahinter...
Erstmal vielen dank für eure Zahlreichen Antworten. Gleichzeitig möchte
ich mich entschuldigen für meine Späte Antwort aber mir fehlt aktuell
einfach die Zeit und Motivation da ich, Frau und Kind krank geworden
sind..
Um vielleicht nochmal Licht ins dunkle zu bringen, meine Anwendung dient
zum Testen und ist nicht für Massenproduktion.
Ich stelle mir das so vor das z.B. auf APPDATA Funktionen oder Variablen
sind die selten bis nie angepasst werden müssen. Eine LCD oder OLED
Ansteuerung zum Beispiel. Wobei nachträgliche Änderungen natürlich
möglich sein sollen.
Auf APPCODE soll dann der zu testende Code sein, ohne den ganzen Ballast
jedes mal Mittschleppen zu müssen, der ja dann schon auf APPDATA
existiert (APPCODE ruft quasi hierbei Funktionen aus APPDATA auf).
Die Spaltung in zwei unterschiedliche hex Dateien hat einfach den Grund,
wenn ich die komplette hex Datei auf den Flash kopiere (also APPCODE und
APPDATA) dauert das einfach ab einer Gewissen Größe recht lange, trotz
ignorieren, einer der beiden Sektoren (es kann quasi Gewählt werden
welcher Sektor geschrieben wird, der andere wird zwar Empfangen aber
einfach Ignoriert).
Grund für die langsame Übertragung ist, dass die Baudrate auf 9600
eingestellt ist. Natürlich könnte ich diese erhöhen, dann würde sich
mein Problem erledigen aber aus Grund von Kompatibilitätsgründen möchte
ich 9600 eigentlich beibehalten.
c-hater schrieb:> Der Trick ist im Kern eigentlich nur, die Aufrufadresse der Funktion mit> in den Header zu packen, den der Compiler der Anwendung zu sehen> bekommt. Und wenn man wissen will, wie man sowas macht, ist "ROM-Code"> keine schlechtes Google-Futter (zumindest als Teil des Suchausdrucks)...
Ich habe es bisher so gemacht das ich einfach die Adresse der Funktion
rausgesucht habe und dann einen direkten Call (in C) gemacht habe. Bei
der kleinsten Änderung müssen natürlich alle Adressen überprüft werden,
was blöd ist.
Ich habe mal nach deinen Suchbegriff gesucht aber nichts zu dem Thema
gefunden. Ich schließe aber aus deiner Beschreibung, dass du einfach
selber Adressen über die Pointer vorgibst und diese über den Header mit
dem anderen Projekt teilst.
Mir stellt sich aber bei der Methode die Frage, wenn du mehrere
Funktionen haßt, und eine davon änderst, kann es ja passieren das die
eine Funktion in die andere fest Adressierte Funktion kollabiert? Du
müsstest dann auch auf der einen Seite alles anpassen oder täusche ich?
Ich muss zugeben das diese Art von dynamischen Funktion teilen Neuland
für mich ist. Dass netz gibt dazu Beispiele, sich Linker Dateien zu
schreiben die sowas ermöglichen aber das finde ich sehr umständlich..
Edit:
Durch erneutes Lesen deines Beitrags @c-hater hat sich obige Frage
erledigt. Du gibst ja quasi nicht die Adressen vor, sondern der
Compiler. Du nutzt dann eben nur die Pointer als Adressrückgabe für das
andere Projekt. Ich denke der Grundsatz ist klar aber (noch) nicht die
Ausführung in meinem Projekt. Ich hoffe auf baldige Besserung das ich
wieder testen kann. Sogar das schreiben dieses Beitrags ist einfach
Anstrengend.
Thread beobachten
Seitenaufteilung abschalten