Traduction fichier de base.
#1
Bonjour à tous,

Dans ma traduction des fichiers de base en C , j'en suis environ à 99% maintenant.

Je butte seulement sur de petites choses qui risque de remettre toute la traduction en cause !

Pour des raisons évidente je cherche à garder 100% de la compatibilité avec les firmware actuel mais j'essaye également de garder l'esprit des fichiers asm pour que chacun s'y retrouve facilement par comparaison.

Mon problème est le suivant !

Citation :;-----------------------------------------------------------------------------
; CONSTANTES DE VERIFICATION
;-----------------------------------------------------------------------------
; Ces deux informations seront écrites toujours au même endroit en mémoire
; flash.
; Ceci permet donc de vérifier si le fichier hex qu'on tente de bootloader
; correspond au pic et au type de carte de destination.
;-----------------------------------------------------------------------------
ORG 0x02 ; emplacement constant pour toutes les cartes
DB DESTI,TYPEPIC ; type de destinataire et type de pic
; protégé des écrasements bootloader

Les octets de vérification se trouvent en adresse 0x02 !
Vous me direz que ce n'est pas bien grave. Seulement voila , lorsque le compilateur compile l'entry point en 0x0000 qui est censé pointer vers le bootloader il le fait de la façon suivante :

0x0000 => GOTO BOOTLOADER
0x0002 => NOP
0x0004 => Return 0

Pour des raisons de sécurité je suppose.

Vous aurez donc compris qu'il y a déjà quelque chose en 0x0002.

J'ai donc le droit à un joli :
Citation :Error - section 'info_boot' can not fit the absolute section. Section 'info_boot' start=0x00000002, length=0x00000002
Errors : 1

Puisqu'il y a déjà quelque chose et que j'essaye d'y coller "BG" pour Beau Gosse ou BiGonoff (cirage de pompe subtil off)

Ma question est donc la suivante :

- A part une méthode un peu sale pour écraser ces octets au premier démarrage du programme , connaissez vous une autre méthode propre pour remédier à ça ?

Cordialement,

Mithril
Répondre
#2
Salut,

As tu réussi à te dépanner ? Je suis vraiment intéressé par ta version en C des fichiers de base (même si ce n'est pas totalement fonctionnel), ce serait parfait si tu pouvais les mettre en ligne Wink

A bientôt,
Quentin
Répondre
#3
Salut,

Moi aussi ça me tente bien Smile

Par contre je comprend pas ton premier message, les octets de vérification sont en mémoire flash alors que le point d'entrée est en mémoire programme. Je suis loin d'être champion en ASM mais on peut pas enregistrer une donnée à l'adresse 0x02.

Dans les fichiers de base pour CE4 :

Code :
ORG 0xF00000
    DE "BG"                        ; en-tête pour vérification mode normal
                                ; si pas "BG", on passe en bootloader

Si ça peut t'aider, à bientôt
Tant que vous avez des dents, croquez des pommes !  (^_^) ♪♫  ♪
Répondre
#4
Salut
------


Citation :Par contre je comprend pas ton premier message, les octets de vérification sont en mémoire flash alors que le point d'entrée est en mémoire programme. Je suis loin d'être champion en ASM mais on peut pas enregistrer une donnée à l'adresse 0x02.

La mémoire flash et la mémoire programme, c'est la même chose Wink

Ce qu'il veut dire, c'est qu'en schématisant, le source asm de base génère ceci en mémoire programme :

0x00/0x01 : bra bootloader (instruction exécutable)
0x02 : destinataire (donnée)
0x03 : type de pic (donnée)
0x04/0x07 : infos sur la carte (données)
0x08 : bra interruptions HP

etc.


Or, le compilateur C, lui, prend comme principe que par défaut le programme utilisateur peut se trouver n'importe où après compilation et donc va utiliser un goto au lieu d'un bra.
Le goto tient sur 4 octets et non deux, ce qui donne

0x00/0x01 : premiers octets de l'instruction goto main
0x02/0x03 : octets suivants, vus comme un nop de façon séparée
0x04/0x05 : retlw 0 (probablement utile au compilateur).

etc.

Et donc, les adresses en mémoire programme qui sont libres en théorie (vu que j'opère un bra d'entrée en 0x00 et qu'il n'y a rien avant l'adresse 0x08 qui est le "vecteur" d'interruption HP), et que j'ai utilisé pour mettre des valeurs de vérification des firmwares (pour que Domogest vérifie si on charge le fichier hex prévu pour la bonne carte), sont en fait utilisées par le compilateur lui-même, qui impose son organisation de la mémoire flash, et donc avec un goto comme première instruction.

Les solutions sont :

- Soit imposer au compilateur de modifier la façon dont il génère le hex (voir si c'est possible)
- Soit retirer les lignes posant problème dans le source et ajouter ces lignes manuellement en éditant le fichier hex produit (pas pratique, mais bon...)
- Soit modifier Domogest pour qu'il accepte ces constantes de vérification à un autre emplacement (mais les fichiers hex ne seront évidemment plus compatibles avec les autres)

Si j'étais dans ce cas de figure et que je n'arrivais pas à modifier les paramètres du compilateur, j'opterais pour le moins pire: Je ferais un petit logiciel qui remplace le "goto" du début par un "bra", et qui écrase la suite avec les valeurs correctes des data à placer. Si j'avais écrit le source en C, j'aurais organisé la mémoire différemment, mais vu que je programme en langage d'assemblage, j'ai opté pour le plus pratique et le plus rationnel.

Attention, ces solutions ne fonctionnent QUE si et seulement si l'adresse "Bootloader" du "goto" est en page 0, sinon il y a un gros problème car le bra ne fonctionnera pas et il n'y a pas de solution, excepté la modification de Domogest.


Citation :A part une méthode un peu sale pour écraser ces octets au premier démarrage du programme

C'est surtout une méthode qui ne fonctionnera pas : En effet, ces constantes servent à Domogest pour déterminer si le fichier bootloadé est correct ou pas. Vu qu'il ne sera pas considéré correct il ne sera pas bootloadé et donc pas exécuté.


Ceci étant, ce problème existe en théorie mais pas dans la réalité pratique:


En effet, sous Domogest CE4 ce problème n'existe pas, puisque le plugin dépend de la carte et que c'est le plugin qui gère le bootloader.

Moralité:

- Porter un logiciel déjà écrit en C n'a aucun intérêt (les applications des cartes actuelles fonctionnent déjà, nul besoin de les porter)

- Écrire un fichier de base pour les futures applications ne nécessite pas de se préoccuper de ce problème, puisque celui qui utilisera ce fichier de base C pour une future carte écrira le plugin en conséquence et donc les adresses en question ne sont en aucun cas une obligation. Dit autrement: le fichier de base "C" n'a pas à "singer" le comportement du fichier asm: Celui qui utilise le fichier C réalisera son plugin en fonction du code produit.

A+
Bigonof
Répondre
#5
Bonjour à tous,

Je ne vous oublie pas , je suis seulement très très pris par la rénovation de ma maison, actuellement ma maison est partiellement dépouillé et je met tout en œuvre pour finir l'isolation avant l'hiver ce qui m'impose d'être moins présent pour le côté domotique.

Citation :Je suis vraiment intéressé par ta version en C des fichiers de base

Je te met ça au plus vite en ligne ! Désolé pour l'attente encore une fois !

Citation :La mémoire flash et la mémoire programme, c'est la même chose

Exactement !
Flash => mémoire Programme , mémoire non-volatile qui a une bonne endurance mais qui ne pouvait être écrite qu'un nombre de fois très limité. Cela va en s'améliorant puisque l'ont trouve aujourd'hui sur des PIC faible coût des flash qui peuvent émuler des fonctionnement d'EEPROM avec plusieurs centaine de milliers d'écriture possible.

EEPROM => Mémoire également de type non-volatile avec possibilité d'écriture importante ! Problème de cette mémoire , elle est très gourmande en place sur la puce en silicium c'est pourquoi leur taille est très souvent limité.

RAM => Mémoire volatile de data de travail. On coupe l'alimentation et on perd les informations stockés ! L'avantage de cette mémoire est qu'elle est très rapide ! Donc bien utile pour faire des calculs !

Citation :Porter un logiciel déjà écrit en C n'a aucun intérêt (les applications des cartes actuelles fonctionnent déjà, nul besoin de les porter)

Le but n'est bien sur pas de porter ce qui a été écrit en asm vers le C car mis à part un risque de dégrader les performances , il n'y a rien à gagner c'est sur !
Le but de tout ça était de faire des fichier de base en C qui semble plus simple à appréhender pour le développement de nouvelles carte.
Ce sont ces fichiers que j'ai utilisé pour développer mon interrupteur tactile avec wheel type Ipod. (Que je partagerais quand ils sera 100% terminé, je n'ai qu'un proto fonctionnel aujourd'hui et je ne souhaite pas diffuser un typon qui ne me satisfait pas entièrement)



Voilà ! Désolé encore , je pensais que tout irais un peu plus vite mais le temps que tout cela me prends et bien supérieur à ce que j'avais planifié à l'origine. J'ai promis pas mal de chose à la communauté et je m'y tiendrais , je ne serais juste pas tout à fait aussi rapide que prévu !


Cordialement,

Mithril


Ps: Je suis à la recherche de quelqu'un capable de fabriquer un disque de 53mn en verre ou PVC de 4mm , avec une gravure circulaire en arc de cercle d'1mm de profondeur en pourtour et tout cela à un prix raisonnable. Si vous avez des pistes !


[Image: pad_preview.png]
Répondre
#6
Salut
------


Citation :Le but n'est bien sur pas de porter ce qui a été écrit en asm vers le C car mis à part un risque de dégrader les performances , il n'y a rien à gagner c'est sur !
Le but de tout ça était de faire des fichier de base en C qui semble plus simple à appréhender pour le développement de nouvelles carte.

C'est bien pour ça que j'expliquais qu'en fait ton problème n'existe pas, il te suffit de ne pas en tenir compte et d'écrire le plugin en fonction de ce que tu auras décidé

A+
Bigonoff
Répondre
#7
bonjour Mithril,

faire un disque de 53 mm diamètre en PVC c'est facile et pas cher .
sur ce site http://www.usinages.com/forums/demandes-de-fabrication-et-sous-traitance.81/ tu peux demander un devis en précisant la matière et la quantités de pièces .

pour le faire en verre ,sa ces cher car tu devras avoir un moule ;du verre colorer ( vitrail ) ; et un four réglable ou brique réfractaire et chalumeaux avec une sonde de température.

mais ces faisable cher soi.

a+
Répondre
#8
Salut
------

Il y a des sociétés qui découpent le verre au laser, mais je n'ai plus les références

A+
Bigonoff
Répondre
#9
Bonjour,
Je suis également a la recherche des fichiers de base traduit en C pour le developpement d'une nouvelle carte Domocan. Cela faciliterai grandement l'écriture du firmware.
en vous remerciant par avance
Laurent
Répondre
#10
Bonjour,

Je suis en train de finaliser une base en C (sur 18F2680) qui fonctionne partiellement pour l'instant. Si il n'y a pas d'imprévu, je pourrais te la proposer une fois finalisée dans quelques semaines.

A+
Répondre
#11
Bonjour,
Je suis preneur d'une version partiellement finalisée pour commencer.

J'ai finalisé le hard d'une carte pour Domocan, il reste le soft a écrire et je suis plus à l'aise avec le langage C ...

Merci par avance

Laurent
Répondre