Communication entre PIC et PICAXE

[dje8269]

Bonjour à tous ,

La communication entre différents µC est elle 100% compatible ? c'est a dire puis-je branché sur un même bus un PIC et un PICAXE ( i2C ou UART ) ?
Est ce que seul le nom des commandes change dans la langage de programmation ? par exemple puis-je retrouve la commande "hserout" sur un PIC , sous un autre nom ?

Pour ne rien vous caché ,voila ce qui me trotte derrière la tête . Je souhaiterais faire des tests ,sur un PIC pour envoyer et recevoir des infos par RF et gérer le programme avec un picaxe ( comme je commence un peu a me débrouiller maintenant).

Je viens de me procurer ce genre de module :

868Mhz

169Mhz

Je souhaiterais essayer de coder ma transmission avec un code de Hamming ou de reed solomon , et ensuite passer ça en manchester et hop le tour est joué ;

Au fil d'une discussion sur futura, il en ai ressortis qu'il était préférable de s'assurer de la bonne reception d'une com, plutôt que d'en recevoir plein et de faire la moyenne ; en résumé, il faut envoyer moins souvent mais être sur de ce qui est recu !

Merci à vous ,

Au plaisir de vous lire

 

[PapyJP]

La communication entre différents µC est elle 100% compatible ? c'est a dire puis-je branché sur un même bus un PIC et un PICAXE ( i2C ou UART ) ?

Vous rêvez! Les PICs sont des microcontrôleurs uniquement programmables en assembleur. Ils ne contiennent aucun firmware donc aucune instruction ' de haut niveau '.
Vous avez à votre disposition 35 instructions élémentaires, point barre.
Par contre, un 16F84 avec un quartz de 4 MHz, éxécute une instruction en 1 us ( quatre cycles d' horloge ).
Faut savoir ce que l' on veut !

Est ce que seul le nom des commandes change dans la langage de programmation ? par exemple puis-je retrouve la commande "hserout" sur un PIC , sous un autre nom ?

En conséquence de ci-dessus, l' instruction ' serout ' n' existe pas.
Il faut environ 60 lignes de code assembleur ( soit environ 60 us ) pour simuler chaque changement d'état des huit bits à transmettre ( ajoutez un bit de start, un bit de stop, et une possible parité ).
A 2400 bits/s ( et non 2400 Baud, le Baud étant une unité information à transmettre, à 2400 bits/s sur 10 bits on ne transmet que 240 informations/s ( soit 240 Baud ) au maximum ), il faut plus de quatre ms par octet.
Le PIC se tourne les pouces entre chaque modif du niveau de sortie !

Mais là ce n' est plus la méthode ' au pif ' ou ' par tests successifs ' qu'il faut utiliser ...............

 

[alainav1]

bonjour,
effectivement le pic ne comprend que le langage machine (assembleur )
cependant il exsite des langages de haut niveau ou l'on ecrit par exemple (en langage basic picsimulator )
Serin PORTC.7, 9600, mot
les instructions sont traduites en assembleur codé et et transferé dans le pic
on a 3 niveaux
code source de haut niveau (basic , langage C ..)
traduction en assembleur
traduction en code machine qui sera implanté dans le pic .
l'avantage du pic c'est que l'on peut ecrire le programme en langage de haut niveau en intégrant du code assembleur en cas de besoin (pour des temps cours par exemple )
j'ai construit la trame d'un emeteur infrarouge (40 Khz) en assembeur et utilisé ce sous programme dans le programme en basic
cependant le picaxe a d'autres avantages (plus facile a programmé par exemple )
comme souvent il n'y a pas d'outil universel il faut le choisir suivant ce que l'on veux faire (même si on peut ecraser une mouche avec un marteau piqueur )
cordialement
Alain

 

[dje8269]

Merci a tous les deux pour vos réponses !

Mais je ne comprends pas ou vous voulez en finir .

Vous me parlez de langage machine, d'assembleur etc .... . Mais que ce soit en assembleur ou en basic ou en C , la communication i2C par exemple est la même pour tous ?
Si je vous ai compris, un PIC et un PICAXE ne peuvent pas communiquer sur un même BUS ? car un BAuds d'un PIC n'est pas le même bauds qu'un picaxe ? je trouve ca étonnant

comme souvent il n'y a pas d'outil universel il faut le choisir suivant ce que l'on veux faire

Justement c'est ce pour quoi je m'interroge, Un pic pour les calculs rapides ( codage et RF) et un picaxe pour le traitement du programme , mais faut bien que les deux puisse s'échanger des infos sinon c'est mort

 

[alainav1]

le baud d'un pic ou autre est un baud
des picaxe ,pic, arduino, peuvent communiquer ensemble via un protocole i2C
l'i2c st un protocole de communication et chaue langage le respectera
seul le vocabulaire sera different
voila un exemple avec mon basic (qui sera traduit en langage machine dans mon pic )
Dim addr As Word
Dim data(31) As Byte

Symbol sda = PORTC.2
Symbol scl = PORTC.3
addr = 0

I2CPrepare sda, scl
I2CStart
I2CSend 0xa0
I2CSend addr.HB
I2CSend addr.LB
I2CStop
I2CStart
I2CSend 0xa1
For addr = 0 To 30
I2CReceiveAck data(addr)
Next addr
I2CRecN data(31)
I2CStop



le programme en picaxe aura une syntaxe differente
(voir le basic du picaxe )
mais les 2 vont se comprendre

 

[dje8269]

Merci alain de ces précisions . C'est donc bien se qui me semblait ; C'est le protocole de communication qui impose a un µC et n'importe lequel , ca façon de travailler ; Maintenant les termes changeront et la façon de faire aussi j'en conviens parfaitement pour parler sur le BUS .

Je crois que seul les test me parleront , mais autant prendre quelques infos avant . Il faut que je mette tous ça sur plaque d'essai !

 

[alainav1]

tiens nous au courant pour que tout le monde profite de tes expériences
cordialement
Alain

 

[PapyJP]

... on ecrit par exemple (en langage basic picsimulator )
Serin PORTC.7, 9600, mot
les instructions sont traduites en assembleur codé et et transferé dans le pic ...

>>> Exact.
Mais ce genre de ' traducteur ' génère en général une foultitude de lignes assembleur, parfois des centaines, voire des milliers.
Si bien que l' on perd souvent tous les avantages des PICs vs Picaxes, à savoir la rapidité. D' où l' interet d' écrire en assembleur pour conserver cet avantage si besoin.
Si vous avez des tuyaux à ce sujet, je suis preneur.

>>> L' I2C est un protocole d' échange. Tous les appareils branchés sur le bus, quels qu'ils soient, qui respectent les règles du protocole pourront dialoguer entre eux.

 

[alainav1]

bonjour,
il est vrai qu les langages de haut niveau traduisent en assembleur le code n'est pas optimisé et prend plus de place
cependant pour mes petits programmes je n'ai pas de soucis
l'idéal est de coder en assembleur (j'ai commencé par programmer en assembleur mais des fonctions simples car c'est fastidieux donc je programme en assembleur qu'e lorsque c'est indispensable )
debuter avec de l'assembleur permet de bien comprendre comment ça marche (j'ai commencé avec le 16f84 et le cours de bigonoff)
on verra pas la différence entre un i2C programmé en assembleur fait maison ou par le langage de haut niveau (il prendra juste un peu moins de place )

 

[BESQUEUT]

bonjour,
il est vrai qu les langages de haut niveau traduisent en assembleur le code n'est pas optimisé et prend plus de place
cependant pour mes petits programmes je n'ai pas de soucis
l'idéal est de coder en assembleur (j'ai commencé par programmer en assembleur mais des fonctions simples car c'est fastidieux donc je programme en assembleur qu'e lorsque c'est indispensable )
debuter avec de l'assembleur permet de bien comprendre comment ça marche (j'ai commencé avec le 16f84 et le cours de bigonoff)
on verra pas la différence entre un i2C programmé en assembleur fait maison ou par le langage de haut niveau (il prendra juste un peu moins de place )

D'autant que la majorité des µp modernes incluent déjà en hard la gestion des ports série, I2C et SPI, souvent même avec quelques octets de mémoire tampon.
Du coup, le dialogue est réellement géré en tâche de fond sans aucune interférence avec le programme principal, et même si on lit 3 ports pour écrire sur 2 autres...
Même un code super optimisé à la mano en assembleur sera bien loin de faire ça (sauf à utiliser les broches dédiées évidement) !

Là où ça devient plus sioux, c'est que peu de langages évolués tiennent réellement compte de l'architecture spécifique de chaque processeur ; d'où le prix de ceux qui le font bien...