Hallo Leute,
einer meiner Kollegen ist Geocacher und hatte dieses Rätsel zu lösen(s.
pdf). Das Rätsel hatten wir gestern erfolgreich gelöst und zwar hatte
ich nach langem hin und her die Hex-Daten unter MPLAB in das Program
Memory-Fenster eingetippt und sofort die Lösung des Problems erkannt
(Zahlen-Tabelle mit Koordinaten), d.h. es geht mir nicht mehr um die
Lösung sondern um einen anderen Weg dorthin.
Weiss jemand, wie ich das Problem anders (cleverer) lösen kann? Dazu
habe ich mir zwei Möglichkeiten vorgestellt, den Code disassemblieren
oder gleich in ein PIC einspielen. Und hier habe ich die erste
Schwierigkeit. Ich habe den Code in einen Hex-Editor eingetippt. Dann
hatt ich zwar ein Bin-File aber konnte das Bin-File weder disassemlieren
noch in ein PIC einprogrammieren, weil alle Tools, die ich kenne oder
gefunden habe, ein Hex-File wollen.
Weiss jemand, wie ich ein Bin-File disasseblieren bzw. in ein PIC
einproggen kann?
... schrieb:> Schwierigkeit. Ich habe den Code in einen Hex-Editor eingetippt. Dann> hatt ich zwar ein Bin-File aber konnte das Bin-File weder disassemlieren> noch in ein PIC einprogrammieren, weil alle Tools, die ich kenne oder> gefunden habe, ein Hex-File wollen.>> Weiss jemand, wie ich ein Bin-File disasseblieren bzw. in ein PIC> einproggen kann?
Man könnte sicherlich händisch daraus ein Intel-Hex-File erzeugen. Ist
zwar nicht elegant aber bei der 'Codegröße' noch vertretbar.
Intel-Hex-Files sind einfach aufgebaut: vorne kommt noch die Adresse
drann, ein Byte für die Satzkennung und hinten nach eine Prüfsumme.
Wenn du das Zeugs aber sowieso schon in einem Hex-Editor eigetippt hast,
speichere es als Bin-File ab und jag ein Bin2Hex Tool drüber. Dann hast
du ein Intel-Hex-File, mit dem du weiter arbeiten kannst.
ich habe jetzt mit einem bin2hex ein Hex-File erzeugen können. So weit
so gut, aber wenn ich nach dem Disassemblieren das Listingfile anschaue,
stelle ich fest, dass alle Opcodes "geswapt" wurden, d.h. aus 0903 wurde
auf einmal 0309 usw., und demensprechend ist auch der disassemblierte
Code falsch, obwohl im Hexfile 0903 zu lesen ist. Wie lasst sich denn
dieses Problemchen lösen?
... schrieb:> ich habe jetzt mit einem bin2hex ein Hex-File erzeugen können. So weit> so gut, aber wenn ich nach dem Disassemblieren das Listingfile anschaue,> stelle ich fest, dass alle Opcodes "geswapt" wurden, d.h. aus 0903 wurde> auf einmal 0309 usw., und demensprechend ist auch der disassemblierte> Code falsch, obwohl im Hexfile 0903 zu lesen ist. Wie lasst sich denn> dieses Problemchen lösen?
welches bin2hex hast du benutzt?
Ein Commandline Tool?
wenn ja dann rufe es mal mit -? oder /? oder -h oder ?h oder
überhaupt ohne Argumente auf.
Mit ein bischen Glück hat es eine Hilfe mit, in der ein
Command Line Switch beschrieben ist, mit dem man diesen
ByteSwap abdrehen kann
Ein GUI-Tool?
Klappere alle Menüs nach einem Optionen Dialog ab, und sieh nach
ob es dort eine Checkbox gibt, mit der man den Swap abdrehen kann
Das Programm usburn von sprut (www.sprut.de) hat auch einen Disassembler
eingebaut. Die Programm-Worte der PICs sind immer 14 Byte gross, d.h.
eine 4-er ASCII-Gruppe ist ein Programm-Word. Möglicherweise ist der
o.g. Programnm-Code bereits die HEX-Datei, bei der noch die
Anfangs-Adressen fehlen.
BTW: der 16F84 ist so was von "out", schrecklich (das war der allerste
Flash-PIC von Microchip. Oldie -> Gruftie -> Kompostie :) )
ich habe mehrere gefunden und bei allen konnte man das gleiche
einstellen, Offset, Segment ... Ich habe schon nach bin2hex mit Byteswap
gesucht, aber erstmal vergeblich. Mal sehen, ob ich was unter
Linux-Werkzeugen finde
was habe ich von einem Simulator, wenn in dem convertierten
"bin2hex"-File die Bytes jedes Words "verdreht" sind. Der Converter
müsste beim konvertieren von bin nach hex die Bytes in jedem Word
umdrehen. Ich suche erstmal einen bin2hex-Converter, mit dem ich auch
einzelne Bytes drehen kann.
