PIC18 et les instructions étendues...

On Feb 10, 6:36 pm, Laurent CLAUDE

Je doute qu'il s'agisse d'un probl=E8me de cohabitation, dans la mesure ou le bootloader a fonctionn=E9, et que le prog de "souris" se lance. Par contre il faut bien que le prog de "souris" ait pu initialiser l'USB en mode IHM pour son propre usage : as-tu bien v=E9rifi=E9 que c'est bien le cas ?

Tu devrais la trouver chez Microchip, leur site est complet mais assez vaste alors il faut bien chercher (et ne pas se d=E9courager) Mais trouver ces docs en Francais, je crois qu'il faut oublier.

Certainement. Cela va changer la taille et/ou la vitesse d'ex=E9cution du programme mais =E0 priori rien ne s'y oppose. Programmes-tu en ASM ou en C ?

Le 10/02/2010 22:42, Jean-Christophe a écrit :

en fait, je crois (rien de sûr hein !) que le prog de souris disfonctionne (mais ne plante pas) quand il arrive sur ces instructions, et qui d'après le comportement, ce pourrait être pendant l'énumération USB

Ouais, j'en ai bien peur aussi... Bon, aller courage bibi ;-)

Le bootloader est en assembleur, la souris en C. Peut importe l'optimisation pour l'instant, il faudrait déjà que j'arrive à une cohabitation fonctionnelle. Mais, ne maitrisant pas cette famille de pic, je n'arrive pas à compiler le prog souris avec les instructions étendues en 'ON', j'ai un 'build failed'. Une piste ? ...

Merci laurent

On Feb 11, 9:43 am, Laurent CLAUDE

Alors tu dois pouvoir compiler le prog de souris avec une option de compilation interdisant l'usage des instructions =E9tendues.

Pourquoi ne pas d=E9ja le valider sans instructions =E9tendues ? En C cela doit se r=E9sumer =E0 une macro. En ASM cela doit se d=E9valider via un des bits de config.

Ca d=E9pend du compilateur que tu uilises. Pour l'USB, en uC Microchip j'utilise le 18F2455 en C, sous diff=E9rents compilos, je n'ai jamais eu ce genre de probl=E8me. Sur ce NG rodent des abonn=E9s qui font pas mal de PIC, tu as de bonnes chances d'en trouver qui ont le meme compilo que toi. Anyway : RTFM :-)

On Feb 10, 6:36 pm, Laurent CLAUDE

Dans la data sheet du uC j'ai trouv=E9 ceci :

Pour valider les instructions =E9tendues : [ Configuration Bit XINST =3D 1 ]

Extended Instruction Set : The PIC18F2455/2550/4455/4550 family introduces an optional extension to the PIC18 instruction set which adds 8 new instructions and an Indexed Literal Offset Addressing mode. This extension has been specifically designed to optimize re-entrant application code originally developed in high-level languages such as C.

Le 11/02/2010 10:07, Jean-Christophe a écrit :

Là je ne te suis plus, car le prog de souris est par défaut sans les instructions étendues... je te renvois au 1er post.

En fait, en C comme en ASM il s'agit des bits de config, comme tu l'écris : [ Configuration Bit XINST = 1 ] et ça ce passe aussi au niveau du compilo (j'utilise MPLAB, MPASM et C18) dans les 'build options', il y'a une case à cocher pour activer les instructions étendues.

Bon, je vais me plonger dans les manuels... en english (sniff, sniff)

Merci de ta participation Laurent

On Feb 11, 7:12 pm, Laurent CLAUDE

|> Alors tu dois pouvoir compiler le prog de souris avec une option |> de compilation interdisant l'usage des instructions =E9tendues.

Exact, autant pour moi !

D'apr=E8s ce que j'ai lu, la m=E9moire programme n'est pas affect=E9e par l'utilisation ou pas des instructions =E9tendues. Par contre cela a des cons=E9quences sur la m=E9moire donn=E9es. Lire ici (fichier ZIP -> PDF)

On Feb 11, 7:12=A0pm, Laurent CLAUDE

|> Le bootloader est en assembleur, la souris en C.

Je pense =E0 un truc : Puisque le bootloader utilise les intructions =E9tendues, lors l'init apr=E8s reset tu dois avoir XINST =3D 1. Maintenant, avant de rentrer dans le prog utilisateur qui n'utilise pas ces instructions, alors tu peux les d=E9valider avec XINST =3D 0.

Pas sur que ce soit autoris=E9 apr=E9s l'init, et le compilo risque d'y mettre du sien. Mais cela ne coute rien d'essayer.

Le 11/02/2010 22:06, Jean-Christophe a écrit :

Bein, cela me parait être une manip compliquée, je suis pas sûr non plus que ce soit possible d'autant plus qu'il s'agirait de modifier 'en live' (pendant que le programme 'application' tourne) le config-word et qu'il est protégé en écriture (par le bootloader)...

Le prog application hérite de la config du bootloader. Le bootloader étant en ASM et nécessitant ces instructions, je dois adapter le programme application pour qu'il soit compatible avec cette option. J'ai cru comprendre que cela serait possible au moment de la compilation asses facilement (actuellement, c'est encore relatif comme terme ;-) ) parce que ce programme est en C. Mais je n'ai pas encore trouvé la méthode : une simple modification de la directive dans le code et de l'option au niveau de MPLAB ne semblent pas suffire.

j'espère pouvoir dégager du temps pour cette recherche ce week-end, a suivre...

On Feb 12, 6:45 pm, Laurent CLAUDE

Et il n'est pas possible de d=E9valider cette protection ?

Ok, bon courage, et tiens-nous au courant STP, c'est un probl=E8me qui pourrait arriver =E0 d'autres.

Le 12/02/2010 19:03, Jean-Christophe a écrit :

Si si, bien sûr c'est possible. Mais je n'y tiens pas

bien entendu !

On Feb 12, 7:34 pm, Laurent CLAUDE

|> Et il n'est pas possible de d=E9valider cette protection ?

Non, d'ailleurs je n'aurai meme pas du le sugg=E9rer, car ce bit de conf impacte sur l'organisation m=E9moire.

Il semble qu'il faille compiler ton prog utilisateur en validant l'option " instructions =E9tendues ", ce qui ne devrait pas poser de probl=E8me majeur (?)

Le 12/02/2010 19:43, Jean-Christophe a écrit :

en fait je suis en train d'explorer cette piste quand même ! Je me dis qu'au début du prog utilisateur je pourrais :

- défaire la protection à l'écriture sur le config-word

- passer en XINST = OFF

- remettre la protection du config-word

- poursuivre normalement le déroulement du prog ...et une procédure semblable au début du bootloader mais pour passer en XINST = ON

Quant à l'impact sur l'accès à la mémoire, il me semble (à vérifier) que cela ne devrait pas poser de problème si je fais ces manip au tout début de ces deux programmes. Non ?

Le 12/02/2010 19:43, Jean-Christophe a écrit :

et bien si ! voici le fruit de mes essais :

Cas 1 : j'active dans le code : XINST = ON ; mais je laisse MPLAB (Project>build options...>project>MPASM/C17/C18 Suite) sans cocher l'option Résultat : une fenêtre d'avertissement contenant : "The Extended CPU Mode configuration bit is enabled, but the program that was loaded was not built using extended CPU instructions. Therefore, your code may not work properly." >>> BUILD SUCCEEDED

Cas 2 : XINST = ON ; MPLAB : option cochée Résultat : MPLINK 4.34, Linker Error - mixing extended and non-extended mode modules not allowed. Errors : 1 Link step failed. >>> BUILD FAILED

Cas 3 : XINST = OFF ; MPLAB : option cochée Résultat : idem cas 2

Dans le cas 1, je programme mon pic mais le résultat est le même que celui décrit dans mon 1er post, c'est à dire qu'il y'a bug (mais pas plantage) au fonctionnement : "Périphérique USB non reconnu"