programmation de PIC sur le terrain

Tue Aug 07, 2007 4:47 am   

Bonjour,

Tout le monde connaît le développement de programmes pour
microcontrôleurs PIC, en assembleur ou en langage de plus haut niveau.
Le transfert du programme dans le composant se fait traditionnellement
au moyen d'un ICD2 ou équivalent. Et tout cela fonctionne très bien dans
le cadre du labo.

Lorsqu'on diffuse une appli, les choses deviennent un peu différentes.
Comment faire pour permettre une configuration de quelques paramètres
logiciels sur le terrain sans exposer le programme source à des copies
ou à des détériorations accidentelles ? Existe-t-il des solutions de
programmes "fermés" mais conviviaux, permettant de guider un utilisateur
non spécialiste et évitant les problèmes mentionnés ?

merci pour vos lumières

Tue Aug 07, 2007 6:07 am   

"artaban" <artaban_at_artaban.fr> a écrit

Quand tu parles de "paramètres "logiciels" ne s'agit-il pas de données de
la mémoire programme ? qui retrouve de ce fait obligatoirement effacé et
reprogrammé
Personnellement je place le µC sur un support insertion nulle
et j'échange simplement les µC. le premier restant non modifié tant que le
second n'est pas au point
Bon apres midi

Tue Aug 07, 2007 6:27 am   

"artaban" <artaban_at_artaban.fr> a écrit dans le message de news:
46b7f968$0$27370$ba4acef3_at_news.orange.fr...

Une liaison RS232 avec un soft dans le PIC pour gerer la modification de ces
paramètres ?
Une "pocket" de configuration devellopée spécialement pour cette application
?

Tue Aug 07, 2007 2:20 pm   

artaban wrote:

La question manque de précisions.

Une fois le circuit installé, et soudé, l'ICD2 USB peut etre branché sur
un ordi portable de technicien, et etre utilisé en ICSP. Ceci permet une
mise à jour in situ du firmware.

Pour récupérer un code source, c'est à la portée de n'importe quelle
bonne volontée:
- déssouder
- lire la référence de la puce si elle n'est pas grattée
- insérer la puce dans le programmeur du constructeur
- désassembler (éventuellement à la main, ce n'est qu'une question de
temps).

le seul moyen d'empècher cela est l'usage de puce protégées (Motorolla
et Microchip en proposent; il faut alors activer spécifiquement les
protections voulues pour interdire la relecture du code binaire)

Si vous voulez que la "mise à jour" soit fesable par l'end user, c'est
très compliqué:
- en soit, le fait que l'end user soit responsable de la mise à jour
implique qu'il a accès à la version binaire du firmware, et il ne lui
reste plus qu'à désassembler (c'est par exemple le cas des BIOS de PC,
mais, aussi du très problématique driver des cartes videos: les
constructeurs s'ingénient à faire le driver le plus complèxe possible,
pour que les concurrents mettent le plus de temps possible à le
reverser, mais, ca arrive TOUJOURS tot ou tard: rien n'est impossible,
ce n'est qu'une question de temps).

Protéger votre code, et, mettre en place une solution de mise à jour du
firmware par le end user sont des désirs strictement incompatibles.

Le seul cas exceptionnel que je connaisse, c'est les boitiers ADSL, qui
sont mis a jour automatiquement, chez le end user, sans intervention
spécifique d'un technicien qualifié, mais possible à une seule condition
(spécifiée dans mon contract ADSL): le end user n'est pas propriétaire
de la boite (mais locataire), ni de la ligne, et n'a pas le droit de
brancher aucun autre équipement sur la ligne que le boitié prévu dans le
contract ...

ceci rend illégal de brancher un analyseur logique sur la ligne pour
enregistrer le firmware durant la mise à jour de ma *box.

Si vous voulez protéger votre code, il faut soit que la mise à jour soit
effectuée sur site par un technicien qualifié qui ait une NDA en votr
faveur, soit rappeler les produits.

si le end user est responsable de la mise à jour, votre code est
décompilable (moyennant motivation et temps).

Autre exception: les licenses de téléphones GSM ... qui sont
explicitement des contracts de vente liée, et qui (pour faire court)
sont décriées comme illégales en france par certains avocats (la mise en
marche du tel vaut pour aprobation par le client de la EULA spécifiée
dans la facture, qui implique moultes clauses, dont, l'interdiction de
l'ouverture du boitier, sinon il perd le droit d'usage du logiciel
associé: ainsi, le client perds le droit d'usage du logiciel à l'instant
ou il prend la décision d'ouvrire le boitier. C'est une astuce de vente
liée qui permet que le client puisse "acheter" le bien matériel, en lui
blocant l'accès au logiciel; considéré comme illégal, puisque dès que le
client ouvre la boite, le constructeur se réserve le droit de bloquer le
logiciel, ce qui rend donc le produit inopérant ...).

--


"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Tue Aug 07, 2007 4:08 pm   

mettre les variables
à ajuster sur site dans une eeprom externe
( puce 8 pins ) et mettre la protection au pic

"artaban" <artaban_at_artaban.fr> a écrit dans le message de news:
46b7f968$0$27370$ba4acef3_at_news.orange.fr...

Tue Aug 07, 2007 7:10 pm   

trallala wrote:

les gens qui n'ont pas froid aux yeux utilisent des potars (sur des
entrées analogiques) pour remplacer des roues codeuses (très chères).

(un potar de précision genre trimmer "peut" couter moins cher qu'une
roue codeuse, sans etre moins précis si c'est un multitour).

--


"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)