Da mich die Kommando-Zeile unter Windows nur nervt suche ich gerade ein
Tool mit dem man Binär-Dateien wie Bilder in C-Quelltext konvertieren
kann.
Aber mit graphischer Benutzer-Oberfläche.
Nichts abgedrehtes, einfach nur irgendeine Datei einlesen und als .h
speichern können.
Nett wäre eine Option zum Einstellen der Zeilen-Längen.
Vorzugsweise auch mit den Daten in hex und nicht dezimal.
Auf jeden Fall mit einer Angabe der Länge.
Also so ähnlich wie so:
1
unsignedintg_myData_Size=2824;
2
staticconstunsignedcharg_myData[]=
3
{
4
0xFF,0xD8,0xFF,0xE0,0x00,0x10,
Angesehen habe ich mir "Hexplorer" der zwar in vielen Formaten
exportieren kann, aber nicht als Quell-Text.
Sowas hier ist auch lustig, aber nicht ganz am Ziel:
http://tomeko.net/online_tools/file_to_hex.php?lang=en
Dann habe ich gerade HEXit gefunden und installiert, das ist erstmal
hemmungslos übertrieben für die gewünschte Funktionalität.
Und beim Speichern habe ich dann herausgefunden, dass die installierte
Version nur eine Demo ist und gar nicht speichern kann.
Tipps?
Hex Workshop habe ich gerade gefunden.
Vom Funktions-Umfang her hemmungslos übertrieben für die Aufgabe und
entsprechend "unübersichtlich" zu bedienen.
Aber vom Ergebnis okay:
1
// Length: 2824 / 0x00000B08 (bytes)
2
unsignedcharrawData[2824]=
3
{
4
0xFF,0xD8,0xFF,0xE0,0x00,0x10,0x4A,0x46,
Bytes pro Zeile lassen sich auch einstellen.
Dennoch, wenn noch wer was kompaktes kennt das den Job macht, nur heraus
damit. :-)
Edit: warum auch immer das ausgerechnet in "PC Hard- und Software"
verschoben wurde, damit den Beitrag ja niemand zu Gesicht bekommt der
sowas kennen könnte?
Ich suche ein Tool zur Unterstüzung der Programmierung von
Mikro-Controllern...
Wozu brauchst du denn eine Gui? Wenn du nur die CMD nicht magst hätte
ich eine Idee: Du könntest doch einfach das Konvertirprogramm unter
%AppData%\Roaming\Microsoft\Windows\SendTo ablegen, dann kannst du
einfach mit Rechtsklick->SendenAn eine Datei convertieren. Die Anwendung
wird dabei mit einer Liste der ausgewälten Dateien als Argumente
aufgerufen. Soein Convertierprogram kann eigentlich jeder in <5min
selber schreiben.
GIMP kann Bildformate in C Source files konvertieren. Einfach die
Bilddatei öffnen und dann auf Datei -> Exportieren Als klicken und die
Dateiendung .c angeben.
Da könnte man doch bestimmt was kleines in Python und PyQt schreiben :)
Was genau soll das Programm denn alles können bzw. was soll es an
Einstellmöglichkeiten geben?
Daniel A. schrieb:> Du könntest doch einfach das Konvertirprogramm unter> %AppData%\Roaming\Microsoft\Windows\SendTo ablegen, dann kannst du> einfach mit Rechtsklick->SendenAn eine Datei convertieren.
Hmm, damit bekommt man doch aber keine Argumente mit auf den Weg
gebracht, das Kommandozeilen-Tool müsste also schon per Default das tun
was ich gerade haben will.
Huhu huhu der betrunkene Uhu schrieb:> GIMP kann Bildformate in C Source files konvertieren.
Har, ausgerechnet GIMP, 100+ MB und 99,8% nutzlos für die Aufgabe. :-)
Der Tipp ist allerdings gut wenn man GIMP sowieso schon benutzt.
Kaj G. schrieb:> Da könnte man doch bestimmt was kleines in Python und PyQt schreiben :)
Ja bestimmt, auf diese Idee sind die letzten 20 Jahre doch aber bestimmt
genug Leute gekommen das sowas irgendwo im Netz zu finden ist. :-)
Rudolph R. schrieb:> Hmm, damit bekommt man doch aber keine Argumente mit auf den Weg> gebracht, das Kommandozeilen-Tool müsste also schon per Default das tun> was ich gerade haben will.
Könntest du dann wenigstens Auflisten, was du alles einstellen können
willst? Geht es nur um die Zeilenlänge? Vielleicht schreibe ich dir dann
soein Programm.
Rudolph R. schrieb:> Kaj G. schrieb:>> Da könnte man doch bestimmt was kleines in Python und PyQt schreiben :)>> Ja bestimmt, auf diese Idee sind die letzten 20 Jahre doch aber bestimmt> genug Leute gekommen das sowas irgendwo im Netz zu finden ist. :-)
Ich glaube nicht, dass es dafür bisher bedarf gab. Entweder brauchte man
es für nur wenige Dateien und selten, und dann genügten Komandozeilen
tools, oder man hat es im Makefile automatisiert. Ausserdem ist den
meisten die Zeilenlänge nicht so wichtig, weil die wenigsten ihre
Hexcodes durchlesen.
Daniel A. schrieb:> Könntest du dann wenigstens Auflisten, was du alles einstellen können> willst? Geht es nur um die Zeilenlänge?
Ja, die Zeilenlänge ist der einzige Parameter der mir als nice-to-have
eingefallen ist.
Also sicher nicht entscheidend.
Was mir beim Spielen mit verschiedenen Tools aber aufgefallen ist, die
geben nicht alle die Länge der Daten an.
Das abzählen zu müssen wäre schon lästig, das sind schon immer ein paar
kB pro Bild.
Und dezimale Ausgabe ist auch doof.
> Vielleicht schreibe ich dir dann soein Programm.
Das wäre jetzt nicht notwendig, aber danke für das Angebot.
Ich habe mit Hex Workshop ja jetzt was das funktioniert, nur vielleicht
kennt jemand ja ein anderes Programm das da draussen schon existiert.
:-)
Daniel A. schrieb:> Ausserdem ist den meisten die Zeilenlänge nicht so wichtig,> weil die wenigsten ihre Hexcodes durchlesen.
So wirklich wichtig ist mir das auch nicht.
Aber da ich bei dem Projekt noch in einer wilden experimentier-phase bin
in der ich nach und nach Funktionen implementiere, klatsche ich das
ganze im Moment in eine einzige Quelltext-Datei.
Mit 32 Bytes pro Zeile lässt sich es sich schneller an dem ersten
Test-Bild vorbei scrollen. :-)
Läubi .. schrieb:> Wenn du nur Bilder im Fokus hast:
Ja, aber ich brauche die Rohdaten, weil ich .jpg in einen FT800 schiebe.
Zum wandeln gibt es auch von FTDI ein Tool, aber bisher ist .jpg einfach
kompakter.
Rudolph R. schrieb:> Ja, aber ich brauche die Rohdaten, weil ich .jpg in einen FT800 schiebe
Was heißt bei dir Rohdaten? Die des JPEGs? Dafür braucht man doch
überhaupt kein Tool, einfach die Daten im Flash/EEPRom ablegen und von
dort lesen, oder SD-Card... oder oder ...
Rudolph R. schrieb:> static const unsigned char g_myData[] => {> 0xFF,0xD8,0xFF,0xE0,0x00,0x10,
Der Zweck davon ist, aus dem erzeugten Quelltext Binärdaten zu machen,
aber die Binärdaten sind als JPEG-Datei ja schon vorhanden - sinnloses
Hin- und Herwandeln.
Das ist wie Brötchen backen, nur um die nachher wieder zu Mehl zu
zermahlen. Das macht zwar manchmal Sinn, aber nur unter Mitwirkung des
Finanzamts.
Georg
Rudolph R. schrieb:> Daniel A. schrieb:>> Du könntest doch einfach das Konvertirprogramm unter>> %AppData%\Roaming\Microsoft\Windows\SendTo ablegen, dann kannst du>> einfach mit Rechtsklick->SendenAn eine Datei convertieren.>> Hmm, damit bekommt man doch aber keine Argumente mit auf den Weg> gebracht, das Kommandozeilen-Tool müsste also schon per Default das tun> was ich gerade haben will.
Wenn du nicht jedesmal die Parameter ändern willst, kannst Du hier auch
eine *.bat nehmen und darüber das Kommandozeilentool aufrufen.
Steffen R. schrieb:> Rudolph R. schrieb:>> Daniel A. schrieb:>>> Du könntest doch einfach das Konvertirprogramm unter>>> %AppData%\Roaming\Microsoft\Windows\SendTo ablegen, dann kannst du>>> einfach mit Rechtsklick->SendenAn eine Datei convertieren.>>>> Hmm, damit bekommt man doch aber keine Argumente mit auf den Weg>> gebracht, das Kommandozeilen-Tool müsste also schon per Default das tun>> was ich gerade haben will.>> Wenn du nicht jedesmal die Parameter ändern willst, kannst Du hier auch> eine *.bat nehmen und darüber das Kommandozeilentool aufrufen.
Viel zu kompliziert. Einfach eine Verknüpfung erstellen, in den
Eigenschaften kann man zusätzliche Parameter mitgeben.
Läubi .. schrieb:> Was heißt bei dir Rohdaten? Die des JPEGs? Dafür braucht man doch> überhaupt kein Tool, einfach die Daten im Flash/EEPRom ablegen und von> dort lesen, oder SD-Card... oder oder ...
Ich dachte, dass ich genau das mache, die Daten in das FLASH packen.
In einer für den Compiler verständlichen Form eben.
Okay, wie kann man denn eine .jpg direkter mit einbinden?
Ein #include "meinbild.jpg" wird es ja eher nicht bringen.
SD-Card ist keine Option, das EEPROM ist sowieso zu winzig.
Georg schrieb:> Rudolph R. schrieb:>> static const unsigned char g_myData[] =>> {>> 0xFF,0xD8,0xFF,0xE0,0x00,0x10,>> Der Zweck davon ist, aus dem erzeugten Quelltext Binärdaten zu machen,> aber die Binärdaten sind als JPEG-Datei ja schon vorhanden - sinnloses> Hin- und Herwandeln.
Geht es auch bitte mal konstruktiv?
Wenn das so verkehrt ist, wie fügt man denn dann Binär-Daten einem
Programm so hinzu, dass das Programm da auch noch drauf zugreifen kann?
Georg schrieb:> Der Zweck davon ist, aus dem erzeugten Quelltext Binärdaten zu machen,> aber die Binärdaten sind als JPEG-Datei ja schon vorhanden - sinnloses> Hin- und Herwandeln.>> Das ist wie Brötchen backen, nur um die nachher wieder zu Mehl zu> zermahlen. Das macht zwar manchmal Sinn, aber nur unter Mitwirkung des> Finanzamts.
Dann muss die Firmware aber sämtliche Bildformate unterstützen.
Ein PC-gestütztes Tool würde vom ursprünglichen Format abstrahieren (auf
Kosten des Speichers bei jpg) und einen Bytestrom zur Verfügung stellen.
Rudolph schrieb:> Wenn das so verkehrt ist, wie fügt man denn dann Binär-Daten einem> Programm so hinzu, dass das Programm da auch noch drauf zugreifen kann?
Da niemand weiss, welche Hardware du programmierst und womit, kann da
auch niemand was Konkretes dazu sagen.
So ganz allgemein ist das eine Aufgabe für den Linker. Das Programm
findet die binären Daten ab der Adresse, wo sie hingeladen wurden - wo
denn sonst? Das ist doch nicht anders, wenn du sie zweimal umwandelst.
le x. schrieb:> Dann muss die Firmware aber sämtliche Bildformate unterstützen.
Daran ändert doch die Umwandlung in Source-Code und wieder zurück auch
nichts.
Georg
Timmo H. schrieb:> https://balau82.wordpress.com/2012/02/19/linking-a...
Wo ist jetzt der Unterschied zwischen dem Erzeugen einer meinbild.o und
meibild.c Datei?
Richtig, da ist keiner, das Ergebnis ist das gleiche.
Nur, dass man die Objekt-Datei nicht mehr bearbeiten kann.
Nicht, dass ich das müsste, aber es geht eben nicht, eine Option
weniger.
Ach ja, vom Handling her ist das auch anders, den Inhalt der meinbild.c
kann ich auch einfach in meine bilddaten.h zu den anderen Bildern
kopieren oder sogar in meintestprojekt.c direkt.
Also sicher ist das nicht falsch und auch die Annahme das ich GCC
benutze passt schon, nur sehe ich nicht, was für einen Vorteil diese
Vorgehensweise haben soll.
Georg schrieb:> Da niemand weiss, welche Hardware du programmierst und womit, kann da> auch niemand was Konkretes dazu sagen.
Komisch, was sagt das dann über Deinen ersten Kommentar?
Rudolph R. schrieb:> Ach ja, vom Handling her ist das auch anders, den Inhalt der meinbild.c> kann ich auch einfach in meine bilddaten.h zu den anderen Bildern> kopieren
Das ist dan aber falsch. In .h dateien kommen nur die Deklarationen. Die
Definitionen müssen in .c Dateien sein.
Rudolph R. schrieb:> Also sicher ist das nicht falsch und auch die Annahme das ich GCC> benutze passt schon, nur sehe ich nicht, was für einen Vorteil diese> Vorgehensweise haben soll.
Ganz einfach: dafür gibt es Tools, während du ja für deine
Vorgehensweise vergeblich danach suchst.
Aber das spielt alles keine Rolle, du hast dich nun mal auf deine
eigenen Ideen festgefressen und willst nichts anderes akzeptieren, also
brauche ich dir nicht lange erzählen, wie ich das angehen würde, bzw. in
der Vergangenheit angangen habe. Ende der Debatte.
Georg
Georg schrieb:> Ganz einfach: dafür gibt es Tools, während du ja für deine> Vorgehensweise vergeblich danach suchst.
Ja nee, ist klar.
> Aber das spielt alles keine Rolle, du hast dich nun mal auf deine> eigenen Ideen festgefressen und willst nichts anderes akzeptieren,> also brauche ich dir nicht lange erzählen, wie ich das angehen würde,> bzw. in der Vergangenheit angangen habe. Ende der Debatte.
Dein Beitrag war völlig wertlos getrollt, danke für nichts.
Daniel A. schrieb:> Rudolph R. schrieb:>> Ach ja, vom Handling her ist das auch anders, den Inhalt der meinbild.c>> kann ich auch einfach in meine bilddaten.h zu den anderen Bildern>> kopieren>> Das ist dan aber falsch. In .h dateien kommen nur die Deklarationen. Die> Definitionen müssen in .c Dateien sein.
Nun ja, "falsch" und "müssen" ist vielleicht etwas sehr hart,
schliesslich funktioniert es ohne Probleme. :-)
Aber stimmt schon, das wird sowieso geschickter, das ganze Projekt auf
mehrere .c aufzuteilen.
Was jetzt aber nichts daran ändert, dass man schwerlich mehrere
Objekt-Dateien mal-eben-so zusammen kopieren kann.
Huhu huhu der betrunkene Uhu schrieb:> GIMP kann Bildformate in C Source files konvertieren. Einfach die> Bilddatei öffnen und dann auf Datei -> Exportieren Als klicken und die> Dateiendung .c angeben.
Da ich das gerade mal ausprobiert habe, nein, Gimp macht nicht was ich
haben wollte.
Gimp speichert nicht etwa die Daten einer nnn.jpg als .c, sondern
vielmehr die in dieser Datei enthaltenen Bilddaten nach dem Entpacken.
Das ist jetzt kein Fehler von Gimp und soweit auch plausibel, führt nur
zu einem völlig anderen Ergebnis.
Rudolph R. schrieb:> Nicht, dass ich das müsste, aber es geht eben nicht, eine Option> weniger.
Wenn du auf Hex-Code Ebene eine JPEG Datei editieren kannst ist dir
meine Bewunderung gewisss... du könntest dann aber auch einfach einen
Hex-Editor nutzen. Du willst doch eben einen "Binärklumpen" einbinden
und dann später zugreifen, in dem Link ist doch auch erklärt wie man das
dann in eine c/h File einbindet.
Das gute ist, du kannst das ganze sogar in deinem build-prozess
integrieren und musst dann garnix mehr vorher wandeln.
Läubi .. schrieb:> Wenn du auf Hex-Code Ebene eine JPEG Datei editieren kannst ist dir> meine Bewunderung gewisss...
Naja, ich benutze das jetzt für JPEG, darauf ist das ja aber nicht
beschränkt.
Ganz zu Anfang habe ich auch noch von Hand Null-Bytes an die Daten
angehängt damit die glatt durch vier teilbar sind.
Man könnte auch noch von Hand einen eigenen Header davor machen.
> du könntest dann aber auch einfach einen Hex-Editor nutzen.
Aber sicher nicht für die Objekt-Daten, weil das ja wieder ein
Container-Format ist.
> Du willst doch eben einen "Binärklumpen" einbinden> und dann später zugreifen, in dem Link ist doch auch erklärt wie man das> dann in eine c/h File einbindet.
Und da steht auch, dass man die Binärdaten alternativ auch in Quelltext
wandeln könnte, etwa mit "xxd -i blob.bin >blob_bin.c".
Und das beides Vor- und Nachteile hat. :-)
Das klingt ja interessant, ich möchte aber weder am Makefile rumspielen
noch von Hand irgendwelche Objekt-Dateien on-the-fly erzeugen und linken
lassen.
Das ganze ist sowieso nur eine Sekundär-Baustelle und soweit auch kein
Problem, die Frage war ja nur, ob jemand ein einfaches GUI Tool für
die Aufgabe kennt.
Viel interessanter ist was ich mit den Daten dann machen kann.
In meine FT800 Library neues zu implementieren ist viel interessanter
als die Frage ob ein Bild.o oder ein Bild.c eleganter zu benutzen ist.
Ein bisschen copy-paste um ein neues Bild in die pic_data.c und
pic_data.h einzubinden geht jetzt auf jeden Fall schneller.
Thread beobachten
Seitenaufteilung abschalten