Non, il est mis sur tout nos montages, seulement j'ai dis de porter l'attention dessus car effectivement sur le starter kit il n'y en a pas, mais je vais voir ça;Envoyé par Aurélien
et pour l'usb j'avais un doute, faut que je vérifie également, c'est pour cette raison que je l'ai stipulé sur le shéma.
C'est plutot deconseillé de la mettre... Toi même as indiqué sur ton schéma qu'il faut l'enlever en cas de souci et tu ne le fais pas quand tu en as ?
Un doute sur la masse ??
effectivement ta raison, je viens de les avoir (les cartes câblées), et je me suis plus focalisé sur une problèmatique soft après avoir vérifié les alimentations et composant à sa périphérie, j'ai donc retiré la capa mais j'ai le même problème qui persiste, toujours programmation sans problème mais pas de vie et débug toujours le même message
bon , bah j'ai refais un tour sur les composants de la carte, bien qu'il y est des oublis à des endroits qui ne sont pas crucial(sur d'autres fonctions qui ne dépend pas de la prog), la carte que je teste a tout ce qui faut pour a priori fonctionner au niveau du micro , les tensions sont de 3.4 les condos sont bien à leur place, j'ai vérifié les pin de prog, là je ne vois pas en hardware ce qui pourrai empêcher ça programmation, et pourtant.
Ce que je ne comprend pas c'est que j'arrive à la programmer avec mon petit programme test et pas avec le principal, les deux fonctionne mais pas en débug, c'est pour toute ces raison sauf erreur qui me font pensé au soft.
dans un fichier system_init.h
j'ai la définition de plusieurs paramètre et parmis eux
j'ai simplement codé les entré sortie des ports comme ça
pour le port c
#define SYS_PORT_C_TRIS 0xfff9
#define SYS_PORT_C_LAT 0x0
ce que je ne comprend pas , est quand j'écrit ça
#define led4 PORTCbits.RC2 est bizzarement coloré par l'éditeur
ce qui n'est pas habituelle, il ce compile pourtant bien ?
La coloration dépend des paramètres de syntaxe de l'IDE.
Rien de choquant la dedans, c'est d'ailleurs comme ça que je définis mes propres définitions hard...
Verifie si t'utilises bien le bon fichier de linker pour ton debug + config debugger dans projet mplabx
Oui je me doute bien, seulement là ou je dis que c'est bizzare, c'est que je n'est rien changé à ces réglages alors que sur mon prog principal cette même écriture est autrement
le RC2 reste noire, c'est pas tant la couleur qui me gène mais je me pose la question sur la prise en compte d'un terme qui est sensé être compris par le langage machine et qu'apparemment ne fonctionne pas alors que mes pwm , elles fonctionnent (sur mon programme test)
Oui je vérifie , j'ai également ouvert un ticket chez microchip, j'attend leur retour.
bon bah, ça y est, je peux programmé ma carte et la passer en mode débug.
j' ai connecté des éléments manquant , 2 condensateurs sur Vcap (100nf et 10uf) , jai donc mes pwm qui fonctionne correctement, le micro ce met à vivre.
Seulement il fallait bien qu'il y est une ombre au tableau, ma stack ne démarre pas, pas de signal wifi et pas d'éthernet en rj45, même soft que sur mon starter kit qui lui fonctionne.
J'ai vérifié le bus spi1 de la carte wifi, pas d'activité et le leds du connecteur rj45 ne s'alume pas non plus, j'ai repris le même câblage donc sa peut qu'être soft, seulement ayant peut d'expérience de la stack je sais pas trop ou regarder en mode débug , quel données pourrai-je vérifier pour comprendre pourquoi ça ne fonctionne pas.
La stack est géré uniquement par le micro à votre avis ? Le module dp83848c gère uniquement la liaison ethernet rj45 ?
Bonjour,
Un truc que je ne comprend pas, du simple code "c" n'est pas compilable, je fais uniquement ça :
J'ai cette erreur :Code:for (uint8_t i=0; i<20; i++) val = *( httpDataBuff+i);
Code:../src/custom_http_app.c: In function 'TCPIP_HTTP_GetExecute': ../src/custom_http_app.c:276:9: error: 'for' loop initial declarations are only allowed in C99 mode for (uint8_t i=0; i<20; i++) ^ ../src/custom_http_app.c:276:9: note: use option -std=c99 or -std=gnu99 to compile your code make[2]: *** [build/pic32mx_eth_sk+ioexp+11n+freertos/production/_ext/1360937237/custom_http_app.o] Error 1 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2
a priori, j'ai besoin de réglé mon compilateur avec option C99, seulement je ne sais pas comment faire.
merci pour votre aide
Dernière modification par davidif ; 06/06/2016 à 21h57.
Bonjour,
J'ai problème dont je trouve pas de solution :
en fait, je récupère les données tempo_val du buffer , seulement je l'ai récupère dans ce format
je les décrément donc à une certaine période via une variable minute,Code:tempo_val=0x00000000(pour 0 mn) tempo_val=0x00000060(pour 60 mn)
mon problème, là ou je souhaiterai décrémenter un nombre décimal, je décrémente de l'hexa, donc plus long et donc les minute envoyé ne correspondent pas
si je reçois 0x0000000010, je fais -1 = 0x00000000F et pas 9
Donc évidemment inférieur à 9 les temps sont bon mais au dessus j'y suis pas
dois-je faire un conversion des valeur reçu, comment les considérer comme du décimal en l'état et non de l'hexa ?
merci pour votre aide
Bonjour,
oui tu dois convertir en décimal avant de décrémenter, il fat que tu te fasses une fonction type Hex2Dec.
De 0 à 0x0F ça donnera ça par exemple pour une valeur comprise entre 0 et 0x0F:
Tu peux la compléter pour traiter de plus grand nombre.Code:unsigned char hex2dec(unsigned char hex) { if (hex >= 0 && hex <= 0x09) { return hex; } else if (hex >= 0x0A && hex <= 0x0F) { return (hex - 0x0A + 10); } else return(0); // ou gestion d'erreur... }
@+
Merci pour ta réponse, hulk
en fait, quand je récupérais ma valeur, je faisais ça
au lieu de tempo_val=tempo_val*10;Code:for ( inc=6; inc<9; inc++) { val = *( httpDataBuff+inc); if (val!=0) { tempo_val=tempo_val<<4; // cette opération n'est pas bonne val=val & 0x0F; tempo_val=tempo_val+val; // valeur pointé } }
du coup il me faisait une opération logique de décalage , plutôt qu'une opération décimal , donc maintenant ça fonctionne
Merci pour ton exemple, que garde en réserve
