Valeur des octets dans un .hex

Le mardi 19 juillet 2011 =C3=A0 22:39 +0200, LeLapin a =C3=A9crit :

=C3=A0 7 bits.

ppli en

inon (si le

sex tu dois=20

d'un sysex est en 8=20

ras pas le=20

Voil=C3=A0, t'as pig=C3=A9 le probl=C3=A8me (simple) mais la solution la pl= us simple, je trouve que c'est de coder tout sur 7 bits (en envoyant le MSB des 7 octets qui suivent, puis les 7 octets sur 7 bits, etc ...) que de fair un traitement uniquement si j'ai un 0xF7 qui traine

Reply to
Loïc GRENON
Loading thread data ...

Le 19/07/2011 23:07, Loïc GRENON a écrit :

dois

en 8

Ben le plus simple à mon avis c'est d'envoyer le fichier hex directement en ascii donc codé sur 7 bits.

Bien sûr à l'émission, il faut filtrer pour ne pas envoyer d'octet >$7F si le fichier est défectueux par exemple.

Ainsi, tu auras 2 octets représentant 2 caractères pour coder 1 octet.

la technique de transformation est alors assez simple.

de plus, tu auras les champs d'adresse pour adresser les données transférées, donc tu ne transmettra que les données utiles, et pour le nombre d'octets nécessaires. (pas d'obligation de transmettre des multiples de 8x7 bits par exemple...)

Une autre alternative, est d'envoyer en premier(s) octet la longueur (encodée sur 7 bits) puis le message en 8 bits, tant que la longueur n'est pas atteinte, le sysex n'est pas refermé.

jj

Reply to
jj

Loïc GRENON :

C'est le principe même des .hex, "hexadecimal object file format". AVR utilise le plus répandu et très ancien Intel HEX. Dans Google, /avr hex file format/ puis /intel hex file format/. Vous aurez par exemple:

C'est justement un format destiné au transport et au stockage de dumps mémoire en 8, 16 ou 32bit en format ASCII (sur 7bit). Je cite:

Hexadecimal object file format is a way of representing an absolute binary object file in ASCII. Because the file is in ASCII instead of binary, it is possible to store the file is non-binary medium such as paper-tape, punch cards, etc.; and the file can also be displayed on CRT terminals, line printers, etc.

Je n'ai pas tout compris votre toolchain (sauf que j'imagine qu'un compilateur qui peut être un assembleur génère au départ le .hex, et que vous allez transporter ce .hex dans un flux MIDI) mais assurément vous pouvez vous "affranchir d'un encodage 8 bits -> 7 bits", puisque ça consisterait à refaire ce que fait le format Intel HEX.

Ce genre de /coup de chance/ est très rare ;-) En revanche, il faut regarder attentivement le contenu du fichier pour vérifier que vous n'êtes pas dans le cas de rares octets complets balisant de grandes nappes de caractères ASCII. A propos, par ASCII on désigne une représentation par 128 valeurs, de 0 à 127, donc sur 7bit en binaire naturel. Les caractères ASCII imprimables en sont un sous-ensemble.

--
Pierre Maurette
Reply to
Pierre Maurette

jj a tapoté du bout de ses petites papattes :

Oui mais si c'est des .hex Intel, il faut soit décoder dans le µC (à ce moment on peut envoyer le fichier tel quel puisque c'est de l'Ascii) soit le décoder sur le PC avant de l'envoyer. Car le format des .hex est quelque peu spécial, c'est pas juste une suite d'octets en Ascii, y'a des trucs qui ne sont pas les datas. Voir :

formatting link

--
LeLapin
Reply to
LeLapin

On 19 juil, 23:07, Lo=EFc GRENON

Ton compilateur g=E9n=E8re du code ex=E9cutable et des donn=E9es vers un fichier purement binaire dont le format varie suivant le compilateur ; Ce fichier est ensuite converti au format HEX qui, lui, est standard, et purement ascii. Donc le binaire est bien compos=E9 d'octets pouvant =EAtre compris entre 0x00 et 0xFF tandis-que le HEX est compos=E9 d'octets limit=E9s =E0 0x7F au maximum.

Un bootloader qui transf=E8re au uC son firmware au format HEX implique bien s=FBr qu'=E0 la r=E9ception le uC fasse la conversion inverse ascii vers binaire, ( dont l'impl=E9mentation est triviale =E0 r=E9aliser ) l'int=E9r=EAt =E9tant que le HEX fournit les adresses cible et un checksum permettant de v=E9rifier la coh=E9rence de ces donn=E9es et surtout la bonne communication du PC vers le uC.

Maintenant si tu caresses l'id=E9e de bootloader ton uC via une communication au format MIDI, tu seras tributaire des limitation de ce format et il te faudra transcoder tes donn=E9es pour qu'elles soient transparentes au protocole MIDI, ce qui est un exemple de mercurochrome sur une jambe de bois.

Je verrais un code de commande permettant de basculer l'interpr=E9teur logiciel de ton uC entre deux modes : =AB MIDI =BB et =AB non-MIDI =BB. Cela te permettrait de conserver le m=EAme port s=E9rie du uC pour les communications MIDI et aussi pour le bootloader. Une fois que tu as bascul=E9 en mode =AB non-MIDI =BB, ton uC pourra r=E9ceptionner le fichier HEX tel quel, sans que tu aies besoin de traffiquer le HEX.

Reply to
Jean-Christophe

Jean-Christophe a tapoté du bout de ses petites papattes :

En fait le mode Sysex du Midi est une pas mauvaise idée. La seule contraite est de faire passer seulement 7 bits, ou 8 bits en évitant (ou en faisant un traitement spécifique, genre escape-coding) pour passer un F7 sans fermer la sysex. Mais peux-tu confirmer (j'ai uniquement vérifié avec les PIC16) que ce genre de µC travaille sur 14 bits (2x7) pour son code ? Ce qui simplifierait tout puisque dans sa sysex il n'enverrait que 7 bits par octet.

--
LeLapin
Reply to
LeLapin

On Jul 20, 11:12 am, LeLapin

Je ne comprends pas pourquoi vous tenez tant =E0 transcoder le fichier HEX en un format binaire interm=E9diaire =E0 7 bits pour la transmission MIDI, puisque de toutes fa=E7ons le HEX est d=E9ja en 7 bits ?

Le PC peut transf=E9rer au uC le fichier HEX tel quel, via la com MIDI : pas besoin d'inventer un autre format, le uC connaitra les adresses cible o=F9 loger le code et les donn=E9es, et surtout pourra v=E9rifier les checksum.

Si ce qui bloque en MIDI est le bit de poids fort, puisque le cas ne se pose pas avec un fichier HEX vous tentez de r=E9soudre un probl=E8me qui n'existe pas.

Reply to
Jean-Christophe

Jean-Christophe a tapoté du bout de ses petites papattes :

Ne connaissant pas l'OP, j'envisageais la possibilité qu'il ne veuille/sache pas coder un bootloader qui lise le .hex. Dans le cas contraire, j'ai déjà donné un lien vers les specs de ce standard pour qu'il puisse le faire.

Oui, si le bootloader sait décoder ce format (tu me diras c'est pas compliqué mais faut quand même l'écrire).

Le problème ne se pose pas non plus si son µC (comme les PIC16) a du code en 7 bits x n.

--
LeLapin
Reply to
LeLapin

On 20 juil, 11:51, LeLapin

ur

Oui. Et dans le cas o=F9 il n'envoie pas le HEX, il devra connaitre le format du fichier binaire g=E9n=E9r=E9 par son compilateur, (format pas toujours document=E9, contrairement au HEX) l'analyser pour en extraire les adresses cible, ajouter lui-m=EAme des blocs de checksum, etc; donc une interfa=E7e logicielle plus compliqu=E9e c=F4t=E9 uC. Au final c'est plus simple d'envoyer directement le HEX.

Oui mais c'est trivial, le format HEX est tr=E9s simple tandis-que le format binaire propri=E9taire du fichier issu de la compilation, qui contient des blocs de code machine et des donn=E9es, c'est tr=E9s tr=E9s souvent bien moins simple =E0 transcoder.

Je ne crois pas avoir vu de uC dont le code machine est

*formellement* limit=E9 =E0 7 bits, ni =E0 un produit entier de 7 bits. Comment tu fais pour passer une op=E9rande qui vaut 0xFFFF ? Si tu pars d'un fichier en binaire pur il faudra bien tenir compte des octets dont le bit de poids fort est =E0 un, inclure cela dans une exception pour la com MIDI, etc. Oui, c'est faisable, mais =E7a complique plus que de simplement envoyer le HEX.

Enfin, dans le cas expos=E9 c'est comme =E7a que je ferai.

Reply to
Jean-Christophe

Jean-Christophe a tapoté du bout de ses petites papattes :

D'où le fait que je lui aie filé l'adresse de Hex2Bin, qui fait des octets à la queue-leu-leu en binaire pur sans chichis ni surplus.

Si la liaison est correcte (faut pas déconner non, plus, en labo j'ai jamais vu un checksum servir à quoi que ce soit si on respecte les normes hard de liaison) pas besoin de checksum. Pour le problème d'emplacement, Hex2Bin met tout à plat 'avec remplissage des inutilisés) je crois, donc tu as juste un bloc d'octets prêts à graver/flasher, de la première adresse à la dernière utilisée.

A nouveau, avec Hex2Bin il n'aura pas le "binaire" à linker avec tout le bordel dedans mais du code objet pur, comme s'il avait décodé le .hex en binaire à la volée dans son bootloader.

Je n'ai parlé que des PIC16 parce que c'est le seul que j'ai vérifié :

Voir à partir du chapitre 7.0. C'est du 14 bits pur sur 2 octets sans MSb.

Chevauchement sur les 14 bits pour un octet entier. Le PIC16 que j'ai pris en exemple ne traite pas de mots de 16 bits, il faut le faire en deux instructions.

Puisque les données qu'il a à envoyer doivent avoir un rapport avec le Midi, et que le F7 est réservé, il ne risque pas de le renconter. Si dans les données il a des variables persos avec la possibilité qu'il y ait un F7, il faut réfléchir à l'ampleur de la prog différentielle de traiter un séquence d'échappement qui n'aura à gérer que le code d'échappement et le F7, ce qui est minimaliste, genre :

Si code d'échappement, attendre octet suivant. Si à nouveau code d'échappement, envoyer l'octet de la valeur du code d'échappement, sinon si octet suivant est l'octet signifiant "envoyer F7", alors envoyer F7.

C'est simplissime, dans tous les langages, et en chainant les sinon - si, il peut gérer d'autres exceptions bien qu'il n'y en ait pas l'utilité dans ce cas.

Les deux se valent. Pour ma part, connaissant encore trop peu les PICs, je préfèrerais minimaliser le code embarqué et jouer sur mon terrain.

--
LeLapin
Reply to
LeLapin

Le 19/07/2011 19:02, Loïc GRENON a écrit :

Bonjour,

Au contraire je vois un TRES gros problème. Le compilo génére un code exécutable sous forme Hexa évolué (IntelHex par ex, ou S1S8 dans le bon vieux temps du 68K ...) et toi tu veux tout simplement mettre les MSB=0 !?

M'est avis que c'est un peu glauque ... pour le moins.

Bonne chance tout de même !

H
Reply to
Habib

Le mercredi 20 juillet 2011 =C3=A0 11:51 +0200, LeLapin a =C3=A9crit :

andard pour=20

Effectivement, je ne sais pas coder de bootloader qui lise le .hex. Je peux m=C3=AAme dire que je ne sais pas coder de bootloader, tout court; puisque ce sera mon premier. Par contre, je veux le faire et apprendre; et cette solution d'envoyer directement le fichier HEX m'a l'air un peu plus =C3=A9l=C3=A9gante. Je ne connaissais pas non plus le format Intel HEX (mis =C3=A0 part de nom, quoi et j'ai d'ailleurs confondu HEX et binaire ...)

Bref, maintenant je dois avoir =C3=A0 peu pr=C3=A8s tout ce qu'il me faut p= our attaquer.

=20

Oui, mais de toute l'un ou l'autre il faudra l'=C3=A9crire ;)

Merci encore =C3=A0 vous tous :)

Reply to
Loïc GRENON

J'espère que ce sera opensource, d'autant plus que j'aime bien les trucs en MIDI :)

--
              Nous vivons dans un monde étrange/
              http://foo.bar.quux.over-blog.com/
 Click to see the full signature
Reply to
Tonton Th

Le 20/07/2011 07:39, LeLapin a écrit :

oui, mais ce n'est pas trop difficile à faire car les tailles de champs sont fixes.

j'ai écrit des routines de lecture/écriture en C, ce n'est pas sorcier.

l'idee c'est de l'envoyer en ascii pour rester sur 7 bits.

de plus, la somme de contrôle peut être utilisée pour fiabiliser le transfert.

sinon, le programme de transfert coté PC peut alléger les trames afin de ne transmettre que la "charge" utile.

jj

Reply to
jj

Le 20/07/2011 11:12, LeLapin a écrit :

les 14 bits ne sont pas utilisables, les données sont codées sur 8 bits, seules les instructions sont codées sur 14 bits.

jj

Reply to
jj

On 20 juil, 17:49, LeLapin

Je comprends bien, mais =E0 moins qu'il ne charge des kilo-tonnes de code (?) avec une com s=E9rie =E0 115200 bps la dur=E9e de transfert restera acceptable.

Good point. (avec un proto sur un bench, moi non plus) Mais sachant que la probabilit=E9 d'erreur de transmission augmente avec la vitesse de transfert ... ok, ok, j'arr=EAte.

Tu pars du postulat que le code commence =E0 une adresse donn=E9e, et que tout le reste suit ... mais ce n'est pas toujours le cas. ( m=EAme remarque en ce qui concerne les blocs de donn=E9es )

J'admets que l'ont peut tr=E9s bien =E9crire le code de facon =E0 ce que ce soit possible, mais c'est une contrainte qui disparait quand les adresses sont incluses dans le ficher transf=E9r=E9 (qu'il soit en binaire ou en HEX) Il m'est arriv=E9 dans le pass=E9 de ne recharger dans la m=E9moire du proto que les routines modifi=E9es, le reste =E9tant toujours pr=E9sent aux adresses voulues : cela ne peut fonctionner que si les adresses cibles font partie du protocole de transfert du bootloader. ( et que l'on ma=EEtrise icelui idem )

Ben non, pas du code objet, mais du code ex=E9cutable link=E9. Sinon, comment une fonction d'un .obj connaitrait-elle l'adresse d'appel d'une autre fonction d'un autre .obj ?

otloader.

Pas dans le cas (le plus courant aujourd'hui) ou les blocs ne sont pas n=E9c=E9ssairement contigus : code principal, routines d'interruptions, datas ... (sans parler des r=E9solutions d'adresses du code objet qui, elles, sont bien pr=E9sentes dans le HEX apr=E9s le link)

=E9 :

Ok.

| Comment tu fais pour passer une op=E9rande qui vaut 0xFFFF ?

Oui, je ferais comme ca aussi, sauf que rien ne me contraint =E0 passer du code HEX =E0 un format interm=E9daire binaire 7 bits pour le transfert via MIDI, puis, =E0 la r=E9ception uC, passer encore =E0 un autre format pour retrouver le binaire pur. Ca fait 2 transcodages contre un seul pour HEX =3D> binaire pur.

Un code machine qui ne traite pas le 16 bits ca me semble un peu, disons, bizarre ... Mais pourquoi pas.

Ben non, puisque c'est du code machine. Il peut tr=E9s bien exister une instrucion uP cod=E9e 0xF7, ou une adrese m=E9moire interne au uC, ou sur la carte de son proto, qui contient l'octet 0xF7. En binaire pur il y a par d=E9finition 50 % de chances qu'un octet ait son bit de poids fort =E0 un, alors bon.

Encore une fois je suis tout =E0 fait d'accord avec ton approche, mais (encore une fois) si j'avais =E0 impl=E9menter ce truc, j'enverrais direct le HEX en profitant de ses avantages : bit 8 d=E9ja =E0 z=E9ro pour la com MIDI, un seul transcodage, pas d'exception 0xF7 ou autre =E0 traiter, etc ...

D'accord, et ca ne vaut pas de coup de se cr=EAper le chignon sur le transcodage. (quoique ca pourrait =EAtre marrant, juste pour le plaisir de taquiner)

n.

Arriv=E9s =E0 ce point, si on veut continuer la comparaison il va falloir commencer =E0 poster du code : une ligne de C pour passer du HEX au binaire.

Bon, =E0 part le fait que ta technique n=E9c=E9ssite

2 transcodages contre un seul pour la mienne, le point fort qui les distingue est que la tienne perd l'adresse, et par suite la localisation des blocs de code ou de donn=E9es est forc=E9ment contig=FCe. Et je maintiens l'int=E9r=EAt de conserver les adresses : ca assouplit les possibilit=E9s, et dans certains cas je suis m=EAme s=FBr que c'est carr=E9ment indispensable.
Reply to
Jean-Christophe

On 20 juil, 19:11, Lo=EFc GRENON

Alors je te conseille subrepticement de le coder pour un format HEX, tu auras l'avantage d'avoir un bootloader standard. (=E0 moins que tu ne veuilles jouer l'obfuscation anti-reverse engineering)

A l'=E9poque j'utilisais le format S19 pour les uP Motorola. Mais il se valent, dans le sens o=F9 ils int=E9grent tous l'adresse de destination du bloc ainsi qu'un checksum.

Yapuka.

Reply to
Jean-Christophe

On 20 juil, 18:43, Habib

| Pour cela, je dois m'assurer que le 8e bit | de chacun des octets que j'envoie soit nul. | Pour tout =E7a, aucun probl=E8me.

Non : apr=E8s le link final, le compilo ne g=E9n=E8re pas directement un format HEX, mais du binaire pur. Ce n'est qu'ensuite qu'un utilitaire transforme le binaire au format HEX, qui est un format =E9ditable ASCII ou le bit 8 est toujours =E0 z=E9ro. (l'octet binaire FF transcod=E9 en ascii donne 4646 et chacun de ces 4 digits a bien son bit 8 =E0 z=E9ro)

Pour que ce soit bien clair :

Un fichier binaire pur de 256 octets de 0x00 =E0 0xFF

formatting link

Les m=EAmes donn=E9es au format HEX

formatting link

Edite les deux avec un =E9diteur texte, puis avec un =E9diteur binaire : fiat lux.

Ce qui est glauque est d'affimer des craques qui vont semer le trouble dans la t=EAte de l'OP, qui demande des explications en admettant lui-m=EAme ne pas s'y connaitre tant que ca.

Reply to
Jean-Christophe

Le 20/07/2011 19:11, Loïc GRENON a écrit :

Je vois que l'on y arrive !

oui, le fichier hex est simple, c'est une suite d'octets codés en ascii

ça commence par un ':' puis un champ adresse de taille fixe puis les données et enfin un checksum que tu n'es pas obligé de lire.

maintenant, tu peux imaginer que coté pc, tu aies un programmle qui te prépare un format à toi, mais c'est dommage de ne pas utiliser ce format si standard.

jj

Reply to
jj

Le 20/07/11 22:51, Jean-Christophe a écrit :

Tiens tu réapparait ici toi ?? Je pensais t'avoir "file-killer" ... bon.

Monsieur, je n'ai pas besoin de toi pour savoir ce qu'est un fichier .hex. Si j'ai dit qu'un compilo génère un fichier hex, ce qui rigoureusement est faux je te l'accorde, un compilo ne gènère pas non plus un binaire pur comme tu as l'air de le croire, c'est l'assembleur qui s'occupe de ça.

Je ne pense pas que l'auteur de ce fil voulait mettre à 0 les MSB d'un fichier hex, si c'est ça alors c'est glauque.

Mettre les MSB à 0 d'un fichier objet (.o ou so) et ensuite générer un hex c'est super glauque.

Mais ce qui l'est encore plus, glauque, vois-tu Monsieur, c'est que tu te jettes sur mes interventions comme ... comme ... comme un Jean-Christophe-qui-sait-et-qui-va-vous-montrer ... etc, etc, etc.

La prochaine fois évite d'intervenir quand je parle.

JC -> kill-file

Habib.

Reply to
Habib Bouaziz-Viallet

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.