Picaxe & I2C

[Laurent]

Bonjour,
J'ai mis en oeuvre un picaxe 40X2 et réussi à le faire communiquer avec un module GSM TM2 via l'UART.
Mon problème est que le Picaxe ayant une seule UART , déjà réservée pour un autre périphérique (qui n'accepte que l'UART comme bus), je dois absolument faire communiquer ce module TM2 de Teltonika avec le Picaxe par le bus I2C.
Or, n'ayant pas pu trouver l'adresse I2C du module TM2 (j'ai même écrit à son DG), je me suis dit que la solution était de communiquer sur l'adresse $00 (adresse d'appel général).
Or, problème, à l'analyseur logique, je vois qu'aucun signal n'est émis sur le bus I2c par le Picaxe (déclaré en maître) alors que l'analyseur logique détecte les données transmises à d'autres adresses (ex: $E0 ou 49 ou ...). le fait que j'arrive à faire échanger les deux modules (Picaxe et TM2) via l'UART montre que le module GSM fonctionne mais rien (pas de données émises par le picaxe déclaré en maître) à l'adresse $00

Que puis-je faire ?
J'en suis à 3 mois à essayer de communiquer en I2C (et même en SPI) et rien .

Laurent

 

[PieM]

Bonsoir,

Si vous avez déjà d'autres composant sur le bus I2C, à priori vous ne pouvez utiliser l'adresse générale $00.
Mais, je ne suis pas certain que le bus I2C soit fait pour les commandes AT de ce module !

Sous qu'elle tension est alimenté votre picaxe 40X2 ? Le TM2 est sous 3.8V ...

Vous dites "le Picaxe ayant une seule UART". Non! Vous pouvez définir plusieurs liaisons sur un picaxe. Seuls hserin / hserout sont affectés à des broches précises.

 

[Laurent]

Bonjour,

Le TM2 est alimenté en effet sous 3,7V tandis que le Picaxe 40x2 l'est sous 3.3V.
Les alimentatiosn sont séparées.

Il n'y a qu'un composant sur le bus I2C, c'est à dire le TM2. Moi aussi, je finis par douter que le bus I2C puisse être réservé pour les commandes AT .

De votre propos, je comprends que l'on pourrait avoir plusieurs UART , ce qui résoudrait définitivement mon problème. Mais comment mettre en oeuvre une duxième UART ? Sur quelles broches, avec quelles instructions (hserin/out sont déjà réservés) et quel mécanisme de gestion des interruptions?

Laurent

 

[BESQUEUT]

Mais comment mettre en oeuvre une duxième UART ? Sur quelles broches, avec quelles instructions (hserin/out sont déjà réservés) et quel mécanisme de gestion des interruptions?

Voir instructions Serin et Serout à partir de la page 206 du tome 2.
La réception est bloquante (au sens où le Picaxe attends une réponse ou un timeout paramétrable).

Il y a aussi le "Background Receive" qui permet au Picaxe de faire quelques bricoles tout en recevant des données dans un "tampon".
Mais tous les exemples montrent une boucle d'attente en pause... autant revenir à ce qui précède...

En gros, il ne faut pas espérer "écouter" deux ports série simultanément avec un Picaxe.

La seule façon serait d'établir un protocole (handshake) qui permette d'écouter l'un, puis l'autre. Si les périphériques en question ne supportent pas ce type de protocole, on pourrait dédier un Picaxe à chacun, puis tenter d'établir le handshake entre les Picaxes. Mais même ceci n'est pas évident car un Picaxe ne sait pas écouter pendant qu'il transmet des données...

 

[PieM]

Mais comment mettre en oeuvre une duxième UART ? Sur quelles broches, avec quelles instructions (hserin/out sont déjà réservés) et quel mécanisme de gestion des interruptions?

Avec serin / serout, vous pouvez gérer une liaison sur les broches que vous voulez.
Par contre, seule le hserin gère une interruption avec un flag (hserflag).

Vous avez besoin de plusieurs liaisons UART avec interruption ?? Est ce vraiment utile avec un module comme le TM2 ?

 

[Laurent]

D'abord merci à vous (BESQUEUT et PIEm) d'avoir pris le temps de vous intéresser à mon cas.

Vous m'avez donné les bases d'une solution; ce qui suit vous semble-t-il logique , cohérent ?

Principe de mon montage: un picaxe interfacé avec deux capteurs (sur deux entrées I/O), un TM2 GSM (envoi d'alertes et réception de paramètres par sms) et un Xbee-wifi (transmission sortante de données ) qui doit être impérativement connecté au picaxe via l'uart pour fonctionner en mode dit transparent.

- surveillance de l'état de deux capteurs par deux interruption (setint - flags), car il faut les "suivre" en continu
- UART (via hserin/heserout) pour gérer des flux sortants et entrants vers et depuis un xbee: transmission de l'info du changement d'état du(es) capteur(s)
- liaison série (serin/serout) avec TM2 pour alerte SMS; quand on utilise cette liaison, c'est soit qu'il y a un capteur (numérique) qui a déclenché et ce n'est pas grave qu'un serin bloque la prise en compte d'un nouveau changement d'état de capteur, soit parce qu'on a reçu un sms (traitement pas urgent) destiné à paramétrer la configuration du système;

mon programme ferait ainsi:

1 - programme "principal"
. surveillance (via des serin) de l'arrivée d'un sms et, si tel est le cas, prise en compte (modificatiosn de données exploitées par le programme principal)

2 - programme d'interruption "évènement capteur"
. identification du capteur (par test de l'état individuel des deux entrées OU par lecture d'un registre qui identifierait directement sur quelle entrée le changement d'état est survenu ??)
. envoi de données via liaison série (serout/serin) par sms via le TM2
. envoi de données via xbee/wifi (via hserout/hserin)
. réactivation des interruptions (setint)

Merci encore pour l'aide apportée

PS: une petite info concernant l'I2C (que j'ai renoncé à utiliser grâce à votre aide) : je m'étonnais de ne pas voir de signal à l'analyseur logique quand je lançais à un hi2Cout à l'adresse $00 d'appel général; eh bien, c'est normal, les picaxe (tous) ne gèrent pas les appels globaux (adresse $00) sur le bus I2C, cela m'a été confirmé

Laurent

 

[PieM]

Si votre liaison XBee est importante, en réception, indépendamment des deux entrées interruption, vous pouvez déclarer le hserin en back ground comme le disait Besqueut. Les données reçues seront dans le scratchpad qui comporte 1023 bytes sur le 40X2. Vous seriez prévenu d'une entrée par le hserflag (voir hsersetup et setintflags)

Mais de toute façon , il faut bien comprendre que toute interruption va perturber les instructions en cours soumises à une variable de timing.
Donc il faut être certain que l'interruption ne peut pas survenir durant un serout, un serin, ou un hserout ...

Une solution serait de rendre les interruptions inactives (SETINTFLAGS OFF) durant les transmissions, si elles sont gérées en dehors de la routine interrupt.

les picaxe (tous) ne gèrent pas les appels globaux (adresse $00) sur le bus I2C, cela m'a été confirmé

Je ne pense pas que cela soit exact; pour preuve, un extrait de programme de P.H Anderson sur 20X2 ....

The PICAXE abbreviates the above sequence as;

   Hi2cin [SlaveAdr_2], RamLocation, (Lo, Hi, PEC)

[COLOR="#FF0000"]Note that a general slave address may be used in addressing a device if it is the only device on the I2C bus.[/COLOR]

' MLX90614_1.Bas
'

' copyright, Peter H Anderson, Baltimore, MD, Mar 12, 11

#picaxe 20x2
#Terminal 9600
........
...........
..........
Top:

[COLOR="#FF0000"]  

    SlaveAdr_2 = $00 * 2 ' use general slave adr[/COLOR]

Again:

    RamLocation = $06 ' ambient temperature

 

[PieM]

Suite,


Il semble d'après la doc que le TM2 soit prévu avec un contrôle de flux CTS/RTS . Donc cela devrait faciliter et fiabiliser les choses en faisant gérer le CTS par le picaxe...

 

[Laurent]

Merci. Pour moi , tout est clair (à ce stade).

Une précision: j'ai bien vu le post de PIEm qui indique comment envoyer un appel général sur bus I2C mais le doc ci-dessous (lien) est affirmatif sur le fait que ces appels ne sont pas gérés par le picaxe. J'en suis d'autant plus convaincu que quand on fait un hi2cout sur adressse générale, contrairement à toutes les autres adresses, aucun signal de quelque sorte n'est émis sur les lignes sda ou scl du picaxe.

http://www.picaxeforum.co.uk/showthread.php?21717-I2c-address-retrieval

Bonne journée

 

[PieM]

Bonjour,

Une précision: j'ai bien vu le post de PIEm qui indique comment envoyer un appel général sur bus I2C mais le doc ci-dessous (lien) est affirmatif sur le fait que ces appels ne sont pas gérés par le picaxe. J'en suis d'autant plus convaincu que quand on fait un hi2cout sur adressse générale, contrairement à toutes les autres adresses, aucun signal de quelque sorte n'est émis sur les lignes sda ou scl du picaxe.

L'exemple donné concerne un capteur de température infra rouge. Et effectivement, celui ci, est prévu pour répondre par défaut à l'adresse $00. En fait il ne s'agit pas d'un appel général, mais particulier pour ce capteur ... Ceci explique donc cela .