Forum

Moi aussi je n'arrive pas à me servir du module DIL64 R32C. Je suis sous WinXP, j'ai installé le pilote Prolific, je lance KD100, je charge un des programmes de démo, mais au chargement KD100 répond par un message d'erreur. Quelqu'un pourrait-il publier une démarche step-by-step pour lancer les démonstrations Toggle_LED et Génération_Sinus ?

Bonjour,

Pour ma part j'utilise le debugger E8A et là, il n'y a aucun soucis pour faire du pas à pas dans les exemples.

Bonjour "J.M.R",

Tu peux le trouver ICI (Farnell) ou LA (Glynn) avec un nouveau look .

Amicalement, Yves.

Bonjour "jérém",

Quelques difficultés principalement causées par l'ordre de passage à l'installation, des pilotes déjà installés ou autres caprices de la gestion de l'USB dans windows provoquent des réactions dans le forum.
Ces phénomènes se rencontrent également lorsqu'on utilise des produits purement commerciaux (l'internet est plein de ces doléances) ou lorsqu'on change d'environnement surtout s'il est accompagné d'un changement de version du système.

Une description ordonnée des opérations à réaliser figure en page 9 de la revue de novembre.

Si cela ne fonctionne pas en suivant cette procédure il faudra peut-être désinstaller les pilotes préalablement installés avant de recommencer l'opération (après un redémarrage de préférence).
Je passe les solutions de :
- reformatter le disque et réinstaller en partant de zéro;
- de jeter le PC avec son système VISTA et d'en trouver un équipé de XP sans aucun pilote USB installé;
L'incompatibilité ascendante est une spécialité de Bill et nous sommes prisonniers de son mercantilisme. Ces remarques ne pouvant engager que moi et non la revue.

Amicalement, Yves.

Bonsoir,
Je confirme qu'il s'agit d'un beau joujou avec lequel on arrive a faire des choses. J'ai réussi a faire fonctionner l'ensemble et je crois que l'info passée ds la revue de ce mois ci (nov) va bien eclaircir les choses.
Il faut se farcir la doc (sur le R32C), mais il n'y a rien d'étonnant la dedans. il ne faut quand même pas négliger cette démarche.

J'invite quand même tout les "joueurs" de R32C de partager leurs codes source, afin de bien tous progresser au plus vite.

Merci
J.M.R.

Bonjour,
pour apporter des connaissances :

- quand on utilise malloc,calloc,free.., ne pas hésiter à augmenter la taille de la "HEAP" (dans HEW,menu 'built'->renesas tool chain->cliquer sur Assembly source file->changer l'option assembly:"-D__HEAPSIZE__=0300H:" par "-D__HEAPSIZE__=3000H:" par exemple).
La taille doit être un peu plus grande que ce que l'on veut allouer et pas plus grande que 32kb moins 400h (taille RAM - taille SFR1(00000000h->00000400h)).

- bonne adresse d'info : http://www.over-blog.com/profil/blogueur-2713076.html

- Les opérations mathématiques des 'floating point numbers' se font en taille 'double'.
Pour passer en taille 'float', ajouter l'option HEW->build->renesas tool chain->onglet 'C'->Category"Code Modification"->cocher[-fD32]
Cela diminue la taille des données (/2 pour les 'float') et augmente la vitesse par 35!(environ d'après mesure par timer de 160 multiplications,mais en fait surement plus,peut être 84fois d'après une mesure sur 1 multiplication).

- Pour utiliser les interruptions :
écrire #pragma INTERRUPT nom_de_l_interrup
écrire une fonction void nom_de_l_interrup(void)
ouvrir le fichier "sect100.inc" (si fenêtre à gauche abre des programmes non ouverte ->alt+k) nom_du_projet->Assembly source file->ncrt0.a30->sect100.inc(double-cliquer)
prendre exemple pour modifier suivant besoin:
.......

;-----------------------------------------------------------------------;
; VARIABLE VECTOR SECTION                                               ;
;-----------------------------------------------------------------------;
	.section	vector,	romdata
	.org	VECTOR_ADR
.if 1
	.glb _nom_de_l_interrup
	.lword	dummy_int	; BRK               (software int 0)
	.lword	dummy_int	; reservation area  (software int 1)
	.lword	dummy_int	; uart5 trance/NACK (software int 2)
	.lword	dummy_int	; uart5 receive/ACK (software int 3)
	.lword	dummy_int	; uart6 trance/NACK (software int 4)
	.lword	dummy_int	; uart6 receive/ACK (software int 5)
	.lword	dummy_int	; uart5/uart6 bus collision (software int 6)
	.lword	dummy_int	; reservation area  (software int 7)
	.lword	dummy_int	; DMA0              (software int 8)
	.lword	dummy_int 	; DMA1              (software int 9)
	.lword	dummy_int 	; DMA2              (software int 10)
	.lword	dummy_int 	; DMA3              (software int 11)
	.lword	dummy_int	; TIMER A0          (software int 12)
	.lword	dummy_int	; TIMER A1          (software int 13)
	.lword	dummy_int	; TIMER A2          (software int 14)
	.lword	_nom_de_l_interrup	; TIMER A3          (software int 15)
	.lword	dummy_int	; TIMER A4          (software int 16)

........


- J'utilise FlashSta100 pour écrire le programme en mémoire. J'ai réglé la vitesse Baud rate à 38400. A 57600, cela va plus vite mais la vérification est toujours incorrecte(l'écriture du programme m'a toujours semblé bonne néanmoins). A 115200, la vitesse est trop rapide pour le quartz.

Je suis débutant, en espérant que cela aide.

Quand on utilise beaucoup de variables dans des fonctions de programmes C,vérifier que la pile de données ne soit pas dépassée :
-ouvrir "renesas call walker" dans le menu tools de HEW
-dans la fenêtre de droite, la première ligne indique le programme principal avec entre parenthèses le nombre max d'octets utilisés par les variables
-vérifier et au besoin augmenter la taille de la "user stack" ans HEW,menu 'built'->renesas tool chain->cliquer sur Assembly source file->changer l'option assembly:"__USTACKSIZE__=0300H:" par "__USTACKSIZE__=1000H:" par exemple.