Valeur des octets dans un .hex - Page 2

Do you have a question? Post it now! No Registration Necessary

Threaded View
Re: Valeur des octets dans un .hex
Le mardi 19 juillet 2011 C3%A0 22:39 +0200, LeLapin a C3%A9crit :
Quoted text here. Click to load it

VoilC3%A0, t'as pigC3%A9 le problC3%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


Re: Valeur des octets dans un .hex
Le 19/07/2011 23:07, Loïc GRENON a écrit :
Quoted text here. Click to load it
dois
Quoted text here. Click to load it
en 8
Quoted text here. Click to load it

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

Re: Valeur des octets dans un .hex
jj a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

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 : http://www.keil.com/support/docs/1584.htm

--
LeLapin



Re: Valeur des octets dans un .hex
Le 20/07/2011 07:39, LeLapin a écrit :
Quoted text here. Click to load it

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

Re: Valeur des octets dans un .hex
On 19 juil, 23:07, LoEF%c GRENON

Quoted text here. Click to load it

Ton compilateur gE9%nE8%re du code exE9%cutable et des
donnE9%es 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 composE9% d'octets pouvant
EA%tre compris entre 0x00 et 0xFF tandis-que le HEX
est composE9% d'octets limitE9%s E0% 0x7F au maximum.

Un bootloader qui transfE8%re au uC son firmware
au format HEX implique bien sFB%r qu'E0% la rE9%ception
le uC fasse la conversion inverse ascii vers binaire,
( dont l'implE9%mentation est triviale E0% rE9%aliser )
l'intE9%rEA%t E9%tant que le HEX fournit les adresses cible
et un checksum permettant de vE9%rifier la cohE9%rence de ces
donnE9%es et surtout la bonne communication du PC vers le uC.

Maintenant si tu caresses l'idE9%e de bootloader ton uC
via une communication au format MIDI, tu seras tributaire
des limitation de ce format et il te faudra transcoder tes
donnE9%es 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'interprE9%teur
logiciel de ton uC entre deux modes : AB% MIDI BB% et AB% non-MIDI BB%.
Cela te permettrait de conserver le mEA%me port sE9%rie du uC
pour les communications MIDI et aussi pour le bootloader.
Une fois que tu as basculE9% en mode AB% non-MIDI BB%,
ton uC pourra rE9%ceptionner le fichier HEX tel quel,
sans que tu aies besoin de traffiquer le HEX.

Re: Valeur des octets dans un .hex
Jean-Christophe a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

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



Re: Valeur des octets dans un .hex
On Jul 20, 11:12 am, LeLapin

Quoted text here. Click to load it

Je ne comprends pas pourquoi vous tenez tant
E0% transcoder le fichier HEX en un format binaire
intermE9%diaire E0% 7 bits pour la transmission MIDI,
puisque de toutes faE7%ons le HEX est dE9%ja en 7 bits ?

Le PC peut transfE9%rer au uC le fichier HEX tel quel,
via la com MIDI : pas besoin d'inventer un autre format,
le uC connaitra les adresses cible oF9% loger le code
et les donnE9%es, et surtout pourra vE9%rifier 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 rE9%soudre un problE8%me qui n'existe pas.

Re: Valeur des octets dans un .hex
Jean-Christophe a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

--
LeLapin



Re: Valeur des octets dans un .hex
On 20 juil, 11:51, LeLapin

Quoted text here. Click to load it

Oui.
Et dans le cas oF9% il n'envoie pas le HEX, il devra connaitre
le format du fichier binaire gE9%nE9%rE9% par son compilateur,
(format pas toujours documentE9%, contrairement au HEX)
l'analyser pour en extraire les adresses cible,
ajouter lui-mEA%me des blocs de checksum, etc;
donc une interfaE7%e logicielle plus compliquE9%e cF4%tE9% uC.
Au final c'est plus simple d'envoyer directement le HEX.

Quoted text here. Click to load it

Oui mais c'est trivial, le format HEX est trE9%s simple tandis-que
le format binaire propriE9%taire du fichier issu de la compilation,
qui contient des blocs de code machine et des donnE9%es,
c'est trE9%s trE9%s souvent bien moins simple E0% transcoder.

Quoted text here. Click to load it

Je ne crois pas avoir vu de uC dont le code machine est
*formellement* limitE9% E0% 7 bits, ni E0% un produit entier de 7 bits.
Comment tu fais pour passer une opE9%rande 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 E7%a complique
plus que de simplement envoyer le HEX.

Enfin, dans le cas exposE9% c'est comme E7%a que je ferai.

Re: Valeur des octets dans un .hex
Jean-Christophe a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

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.
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Je n'ai parlé que des PIC16 parce que c'est le seul que j'ai vérifié :
<http://ww1.microchip.com/downloads/en/devicedoc/35007b.pdf>
Voir à partir du chapitre 7.0. C'est du 14 bits pur sur 2 octets sans
MSb.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: Valeur des octets dans un .hex
On 20 juil, 17:49, LeLapin

Quoted text here. Click to load it

Je comprends bien, mais E0% moins qu'il ne charge
des kilo-tonnes de code (?) avec une com sE9%rie
E0% 115200 bps la durE9%e de transfert restera acceptable.

Quoted text here. Click to load it

Good point. (avec un proto sur un bench, moi non plus)
Mais sachant que la probabilitE9% d'erreur de transmission
augmente avec la vitesse de transfert ... ok, ok, j'arrEA%te.

Quoted text here. Click to load it

Tu pars du postulat que le code commence E0% une adresse donnE9%e,
et que tout le reste suit ... mais ce n'est pas toujours le cas.
( mEA%me remarque en ce qui concerne les blocs de donnE9%es )

J'admets que l'ont peut trE9%s bien E9%crire 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 transfE9%rE9% (qu'il soit en binaire ou en HEX)
Il m'est arrivE9% dans le passE9% de ne recharger dans
la mE9%moire du proto que les routines modifiE9%es,
le reste E9%tant toujours prE9%sent aux adresses voulues :
cela ne peut fonctionner que si les adresses cibles
font partie du protocole de transfert du bootloader.
( et que l'on maEE%trise icelui idem )

Quoted text here. Click to load it

Ben non, pas du code objet, mais du code exE9%cutable linkE9%.
Sinon, comment une fonction d'un .obj connaitrait-elle
l'adresse d'appel d'une autre fonction d'un autre .obj ?

Quoted text here. Click to load it

Pas dans le cas (le plus courant aujourd'hui)
ou les blocs ne sont pas nE9%cE9%ssairement contigus :
code principal, routines d'interruptions, datas ...
(sans parler des rE9%solutions d'adresses du code objet
qui, elles, sont bien prE9%sentes dans le HEX aprE9%s le link)

Quoted text here. Click to load it

Ok.

| Comment tu fais pour passer une opE9%rande qui vaut 0xFFFF ?
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Ben non, puisque c'est du code machine.
Il peut trE9%s bien exister une instrucion uP codE9%e 0xF7,
ou une adrese mE9%moire interne au uC,
ou sur la carte de son proto, qui contient l'octet 0xF7.
En binaire pur il y a par dE9%finition 50 % de chances
qu'un octet ait son bit de poids fort E0% un, alors bon.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

D'accord, et ca ne vaut pas de coup de
se crEA%per le chignon sur le transcodage.
(quoique ca pourrait EA%tre marrant,
juste pour le plaisir de taquiner)

Quoted text here. Click to load it

ArrivE9%s 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 nE9%cE9%ssite
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 donnE9%es est forcE9%ment contigFC%e.
Et je maintiens l'intE9%rEA%t de conserver les adresses :
ca assouplit les possibilitE9%s, et dans certains cas
je suis mEA%me sFB%r que c'est carrE9%ment indispensable.

Re: Valeur des octets dans un .hex
Le mercredi 20 juillet 2011 C3%A0 11:51 +0200, LeLapin a C3%A9crit :
Quoted text here. Click to load it

Effectivement, je ne sais pas coder de bootloader qui lise le .hex.
Je peux mC3%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%A9lC3%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 prC3%A8s tout ce qu'il me faut p=
our
attaquer.

Quoted text here. Click to load it
Oui, mais de toute l'un ou l'autre il faudra l'C3%A9crire ;)

Merci encore C3%A0 vous tous :)


Re: Valeur des octets dans un .hex

Quoted text here. Click to load it

    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 /

Re: Valeur des octets dans un .hex
On 20 juil, 19:11, LoEF%c GRENON

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

A l'E9%poque j'utilisais le format S19 pour les uP Motorola.
Mais il se valent, dans le sens oF9% ils intE9%grent tous
l'adresse de destination du bloc ainsi qu'un checksum.

Quoted text here. Click to load it

Yapuka.



Re: Valeur des octets dans un .hex
Le 20/07/2011 19:11, Loïc GRENON a écrit :
Quoted text here. Click to load it

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

Re: Valeur des octets dans un .hex
Le 20/07/2011 11:12, LeLapin a écrit :
Quoted text here. Click to load it

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

Re: Valeur des octets dans un .hex
Loïc GRENON :
Quoted text here. Click to load it

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:
<URL: http://pages.interlog.com/~speff/usefulinfo/Hexfrmt.pdf
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:
<CIT>
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.
</CIT>
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.

Quoted text here. Click to load it

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



Re: Valeur des octets dans un .hex
Le 19/07/2011 19:02, Loïc GRENON a écrit :

Bonjour,

Quoted text here. Click to load it

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

Re: Valeur des octets dans un .hex
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 E7%a, aucun problE8%me.

Quoted text here. Click to load it

Non : aprE8%s le link final, le compilo ne gE9%nE8%re 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 E9%ditable ASCII
ou le bit 8 est toujours E0% zE9%ro.
(l'octet binaire FF transcodE9% en ascii donne 4646
et chacun de ces 4 digits a bien son bit 8 E0% zE9%ro)

Pour que ce soit bien clair :

Un fichier binaire pur de 256 octets de 0x00 E0% 0xFF
http://cjoint.com/?0GuwO5RNLNy

Les mEA%mes donnE9%es au format HEX
http://cjoint.com/?0GuwQRfmo1L

Edite les deux avec un E9%diteur texte,
puis avec un E9%diteur binaire : fiat lux.


Quoted text here. Click to load it

Ce qui est glauque est d'affimer des craques
qui vont semer le trouble dans la tEA%te de l'OP,
qui demande des explications en admettant
lui-mEA%me ne pas s'y connaitre tant que ca.

Re: Valeur des octets dans un .hex
Le 20/07/11 22:51, Jean-Christophe a écrit :
Quoted text here. Click to load it

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.

Site Timeline