"Kompilierten" Code in asm einbinden (Atmega)

siehe http://www.bullhost.de/r/relokatibel.html

Moin,

   vielen Dank für Eure Antworten! Also ich habe das mal ausprobiert, 
und es scheint wirklich gut zu funktionieren. Das mit den relativen 
Sprüngen ist natürlich eine gute Sache, dann brauche ich ja eigentlich 
keine festen Adressen, unter denen die Unterprogramme liegen...

   Vielen Dank noch einmal,
      Ozzy

Also....  damals... beim Apple II (6502 Processor)
hat man das auch so gemacht. Der hatte, glaube ich, 5 Stück Slots
für Erweiterungsboards. Jeder Slot hatte aber einen eigenen 
Adressbereich.
Damit die selbstgebaute Karte aber in jedem beliebigen Slot funktioniert
musste der Code eben relativ sein.

Gruss k.

Moin,

es geht aber genau um dieses kryptische. Ich möchte Code vorgeben der 
allerdings nicht (ohne weiteres) lesbar/veränderbar ist. Klar kann man 
das auch wieder lesbar machen, aber es soll das ganze erschweren. Da 
helfen mir auch keine Macros...

...  du willst also ein Plugin ?

Dan reicht ja auch ein HEX-Block ohne wirkliche Funktion.
Einfach eine 256 byte grosse Ziffernfolge als Prüfsumme.

Gruss k.

Moin,

ne, es geht um ein Programmierpraktikum. Die Leute sollen etwas 
programmieren, aber manchmal ist es eben schwierig Fehler zu 
lokalisieren. Deshalb möchte ich meinen Code als backup-Lösung nehmen 
können. Da die Leute die Fehler in dem entsprechenden Unterprogramm 
selber finden sollen und nicht einfach plump die Lösung kopieren ohne 
nachzudenken, soll die Backup-Lösung nicht einfach lesbar sein...

spess53 schrieb:
> Die Hexdatei von deinem
> Programm über einen Disassembler laufen lassen und schon ist dein
> Aufwand für die Katz.

Das ist nun auch nicht richtig.
Wenn man passende Füllbytes einbaut ist der Disassembler auch
im Arsch. Der Disassembler orientiert sich ja am erwarteten
Alignment.

Klaus

Hallo Spess,

eigentlich wollte ich nur sagen, das ein dissassebler auch sehr
leicht an der Nase herumzuführen wäre, da schon ein falscher
Startpunkt zu unsinnigen Ergebnissen führt.
Wenn man dann halnwortige Jumps einfügt sollte dieser Disasm
vollkommen aus dem Tritt kommen.

K.

spess53 schrieb:
> Was sind 'halnwortige Jumps'?

Nun , ein DisASM ist ja eine Software, die die ASM Befehle aus einer
Hexstruktur herauslesen will.
Wenn man dan aber einen Offset für den Start hinzufügt kommt etwas
ganz anderes und unsinniges heraus.
Sicher wird der kundige Anwender das Offsetfenster so lange verschieben,
bis es Sinn macht.

Aber ein Programm welches unsinnigerweise sachen auf den Stack packt
und es logisch versetzt wieder darunter holt wird wohl schwerlich
zu disassen sein.


k.

Alter 6502 Hase schrieb:
> Und das ohne relative JMP und JSR Befehle.

Die Software stellt fest wo sie ist und macht ihre Arbeit..
... das fand ich super

k.

Ich find' es unsinnig. Entweder sind dann die Aufgaben zu schwer/falsch 
gestellt oder die Schüler haben eh keinen Bock.

Was soll es den helfen, wenn ich mit einer Aufgabe nicht weiterkomme 
"erst mal" eine fertige Routine zu nutzen? Damit ich mit der nächsten 
Aufgabe auch nicht weiterkomme weil mir das Vorwissen fehlt?

Läubi .. schrieb:
> Was soll es den helfen, wenn ich mit einer Aufgabe nicht weiterkomme
> "erst mal" eine fertige Routine zu nutzen?

vieleicht weißt du nicht mehr wie das als Anfänger ist wenn man noch 
keine Erfahrung hat und an zig Baustellen den Fehler suchen soll, 
deshalb kann es durchaus sinnvoll sein nur in einer Baustelle zu suchen 
und sich beim Rest auf funktionierenden Code verlassen.

Oh, da habe ich ja etwas losgetreten... Um das Umfeld ein klein wenig zu 
erläutern: in den ATmega kommen in Echtzeit Daten von einer externen 
Quelle rein. Diese sollen dann verarbeitet werden. Z.B. soll ein 
bestimmten Pattern (Preambel) gefunden werden, und danach die 
nachkommenden Daten weiter verarbeitet werden.
Solche Sachen lassen sich allerdings verdammt schwer simulieren. 
Natürlich kann man das mit Stimuli-Dateien machen, aber ich denke es 
kann immer Abweichungen zwischen Realität und Simulation geben (leicht 
abweichende Taktgeschwindigkeiten,...).
Realtime-Anwendungen lassen sich natürlich auch besch*** Debuggen. Man 
kann nicht so einfach mit dem Debugger da durch gehen, da die Daten ja 
wie gesagt in realtime kommen. Deshalb ist es auch, gerade frü Anfänger, 
schwierig, die Fehlerstelle zu finden. Um den Fehler nun einzugrenzen 
könnte man also fertigen Code vorgeben. Wenn das Programm nicht läuft, 
dann kann der eigene Code durch den vorgegeben austauscht werden, und 
hiermit das/die falschen Unterprogramm(e) erkannt werden. Dann soll man 
sich natürlich selber überlegen, wo der Fehler ist (NATÜRLICH können 
Fragen gestellt werden).
Ich persönlich(!) finde es aber besser, den Leuten den fertigen Code 
nicht auf dem Präsentierteller zu überreichen, sondern sie nachdenken zu 
lassen. Es geht hierbei ja nun nicht um Gemeinheiten, aber man nimmt 
Sachen einfach sehr schnell hin, wenn man sie sieht, statt sich zu 
überlegen, warum das jetzt falsch ist.
Es geht mir auch nicht darum, den Hex-Code dann noch zu zerstückeln, 
dass er bloß nicht deassembliert werden kann. Die Leute bekommen diese 
Codestücke nur in der Übung von mir und haben da gar nicht die 
Möglichkeit, das zu übersetzen. Und wer das kann, der hat auch mit dem 
Rest keine Probleme...

P.S. Dieser Text spiegelt meine persönliche Meinung wieder!

Und ich stimme Walter S. zu!

Walter S. schrieb:
> vieleicht weißt du nicht mehr wie das als Anfänger ist wenn man noch
> keine Erfahrung hat und an zig Baustellen den Fehler suchen soll

Deswegen schreib ich ja:
"Entweder sind dann die Aufgaben zu schwer/falsch gestellt"

Als Aufgabe für einen Anfänger eignet es sich wohl kaum eine eigenes 
RTOS zu schreiben...

Sinnvolle und aufeinander aufbauende kleine Aufgaben welche man am 
Simmulator oder in Real testet dann schon eher.

Es bringt doch nix einem Grundschüler einen Taschenrechner in die Hand 
zu drücken falls er "bei einigen Rechnungen für das Lösen eines 
Integrals" er es nicht schafft diese im Kopf zu lösen.