Totof a écrit :Pour Arduino et les interruptions et le transfert vers Processing, ça devrait le faire pourtant
Alors il faut bien distinguer 2 choses : ce qu'il est possible de faire (tout), et ce que peut gérer Processing (dans ce domaine, pas grand chose).
La lib permet, via attachInterrupt(), de réagir à un événement externe (changement d'état sur un pin), et là je pense ne rien t'apprendre... Ces interruptions sont au nombre de 2 sur un Uno, sur les I/Os 2 et 3 (ce sont les interruptions INT0 et INT1).
Sauf que des interruptions, il y en a 26 en tout, y compris pour des événements internes du genre "réception de données série terminée" ou "conversion A/D terminée" par exemple (pour l'ATmega328, la liste complète est en p. 65 du
datasheet).
Il y a donc 24 interruptions qui ne sont pas gérées par Processing, et pour lesquelles on doit donc tout se taper à la main, via une déclaration du type :
Code : Tout sélectionner
ISR(USART_TX_vect)
{
// Traitement de la réception d'un caractère
}
Et bien sur, les configurations de registre qui s'imposent, en positionnant les flags "Interrupt Enable" correspondants, ici le bit RXCIE0 de UCSR0B.
Donc oui, c'est possible, mais ce n'est pas géré par Processing.
Totof a écrit :Peux tu un peu développer le problème que tu soulève SVP , ça m'intéresse
1° cette fréquence pour la pleine résolution du CAN
2° le soucis du polling
Alors pour le 1, je ne fais que me référer au datasheet, p. 240 pour l'ATmega328 :
Atmel a écrit :the successive approximation circuitry requires an input clock frequency between 50kHz and 200kHz to get maximum resolution. If a lower resolution than 10 bits is needed, the input clock frequency to the ADC can be higher than 200kHz to get a higher sample rate.
Par contre aucun moyen de savoir quelle est la résolution réelle en fonction de la fréquence, il faut donc considérer que le (les ?) LSB n'est pas significatif au-dessus de 200kHz, ce qui équivaut à une résolution de 9 bits (ou moins).
Pour le polling, c'est assez simple. Par exemple, si tu veux faire une lecture sur une entrée analogique, voici le code correspondant de la lib Arduino :
Code : Tout sélectionner
// start the conversion
sbi(ADCSRA, ADSC);
// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));
Si une conversion met 112µs, le while() bloquera donc ton processeur pendant cette durée, soit exactement 1792 cycles. Si ton application a des calculs à faire, ou un affichage à mettre à jour, il serait donc bien de s'en occuper pendant ces 1792 cycles, qui permettent déjà de faire pas mal de trucs intéressants
Dans le cas de mon traceur, si je faisais tout par polling, je ne ferais rien d'autre que des conversions A/D pendant 5ms, puis tous mes traitements pendant les 5ms suivantes, et rebelote.
Si au contraire je me base sur des interruptions, je peux lancer ma conversion, et mettre en forme mes données en faisant les calculs qui vont avec (par exemple pour déterminer le courant de cathode à partir de la valeur lue) en temps masqué. Ca permet un "multi-taches" basique, et donc de faire plus en autant de temps. On risque donc moins de rater une échéance, et l'exécution du programme est plus fluide.
EDIT : Pour que les choses soient bien claires, quand je parle de "Processing", pour moi ce sont les libs et l'IDE Arduino (je fais ptet un raccourci un peu rapide, là), pas ce qui tourne sur le PC... En relisant ton dernier post, il me semble qu'il y a confusion et qu'on ne parle pas tout à fait de la même chose
)
