probleme programme C(cc5x) sur 16f84A

[Tix]

Salutations

Je suis en train de bricoler avec un pic16f84. J'ai un "buzzer" de carte mere sur la sortie 5 port B de mon µC

J'ai codé une petite fonction sensée envoyer sur cette pin un signal de fréquence f et de durée d :

void sound(uns16 f, uns16 d)
{
	int i; 
	uns16 p = 50000 / f; // une demi période en dizaines de µscondes
	uns16 d2 = d * 100; // d(ms) --> d2(10µs)
	uns16 p2 = p * 2;    // p2 = période du signal (µs)
	uns16 duree = d2 / p2; //nombre de périodes
	for(i=0; i<=duree; i++)
	{
		PORTB.5 = 1;
		delay_10us(p);	
		PORTB.5 = 0;	
		delay_10us(p);		
	}
}

je ne comprends pas pourquoi, mais ma fréquence étant à peu pres bonne, j'ai je ne sais quel probleme avec la durée... elle varie en fonction de ma fréquence, et parfois meme, en dépit de tout autre facteur ...

J'ai vérifié mon raisonnement quatres ou cinq fois, mais je ne comprends pas pourquoi il ne fais pas ce que je lui demande.

Sauriez vous maider ?

merci, ++ Tix.

[gcortex]

Si ton pic éxécute 4M instructions par seconde,
et qu'une instruction C prend 4 instructions assembleur,
çà fait 10 instructions en 10µs
sans compter les saut + retour de sous routine + sauvegarde des variables + ...

Travaille plutot en assembleur avec un timer !!

[gcortex]

+ restitution du contexte

Le pic n'a donc pas le temps d'éxecuter la séquence
(je devance ta remarque )

[cherwam07]

Travaille plutot en assembleur avec un timer !!

Moi je serai même pour qu'on ai à passer un diplome d'assembleur avant d'avoir le droit au C sur un PIC

Dans cette "simple" fonction, il y a deux divisions, et deux multiplications....en plus sur 16 bits.
Ca ferait rigoler le plus simple des processeur de PC, mais c'est un enfer pour un PIC (8 bits) qui n'est équipé ni d'un multiplieur (je crois que c'est vrai pour tous les 16f) et encore moins d'un diviseur.

Clairement ce sont ces quatre opérations que ton PIC en entrain de faire la majorité du temps.

Il va falloir changer de stratégie....ou de micro

[gcortex]

Dans cette "simple" fonction, il y a deux divisions, et deux multiplications....en plus sur 16 bits.
Ca ferait rigoler le plus simple des processeur de PC, mais c'est un enfer pour un PIC (8 bits) qui n'est équipé ni d'un multiplieur (je crois que c'est vrai pour tous les 16f) et encore moins d'un diviseur.

heureusement cette séquence n'a lieu qu'une seule fois, avant de faire le bip

[cherwam07]

Posté par cherwam07 Voir le message
Dans cette "simple" fonction, il y a deux divisions, et deux multiplications....en plus sur 16 bits.
Ca ferait rigoler le plus simple des processeur de PC, mais c'est un enfer pour un PIC (8 bits) qui n'est équipé ni d'un multiplieur (je crois que c'est vrai pour tous les 16f) et encore moins d'un diviseur.

heureusement cette séquence n'a lieu qu'une seule fois, avant de faire le bip

Hmmm pas faux. Au temps pour moi, ca n'explique donc pas que la durée de l'impulsion soit étrange.
Alors il faudrait peut-être regarder si les résultats des calculs sont bien codables sur 16 bits.

Tu peux nous donner des paramètres qui semblent marcher et d'autres qui semblent planter ?

[gcortex]

pour çà vient du fait que le code n'est pas optimisé

[Tix]

merci pour vos réponses =)

bien, écoutez, apparement, le compilateur y ets pour beaucoup...

au lieu de mettre :

uns16 variable = ...;
uns16 variable2 = ...;
uns16 variable3 = ...;

j'ia tenté ca :

uns16 variable = ..., variable2 = ... variable3 = ...;

et ca fonctionne à peu pres comme il le faut... (la fréquence est cependant trompée, vous l'avez bien démontrés)

peu on introduire de l'assembleur dans un code C sur CC5X ?
si oui, commetn gere t'on un timer en Assembleur ? (j'ai de tres faibles bases en assembleur, encore moisn sur PIC, c'ets pas des kernels sur PC ces betes là -_-')

P.S: Pourrais-je palier à certaisn de ces problemes d'optimisation en passant à 20Mhz ? Comment pensez vous pouvoir optimiser ce code sinon ?

merci, ++ Tix.

[mictour]

Bonjour Tix,
...Et si tu t'inspirais du fichier DELAY.C dans le dossier cc5xfree ?
Bonne prog, mictour.

[freepicbasic]

Je connais 2 raisons qui donnerait des temps aléatoires.

1) soft , les interruptions étant actives des éléments externes quelqu'ils soinent perturbent la base de temps, l'int RBIF par exemple autorisée alors que les pins sont en l'air ferait ce genre de problème.

2) hard, des capas trop faibles sur le quartz filtre mal les harmoniques , lesquels arrivent a passer parfois dans des "extra-cycles" modifiant la fréquence de l'horloge.

Quant aux remarques sur les calculs elles sont justifiées et le calcul devrait être fait dans le main() une fois pour toute , surtout si l'on fait une boucle de sound et que l'on ne veut pas faire un son haché.
Mais le calcul n'explique pas la variation de durée...