Création/Développement de modules EIB sur base de µC PIC

[stephane.herraiz@gmail.com]

Tu as mal lu la doc des opto 6N136, les 25mA sont une valeur
maximum...

On 4 jan, 08:59, olivier95800 <olivier95...@wanadoo.fr> wrote:
> Bonjour,
>
> 1. Si R1=R2=10k, C1 va se charger à 3V3 / 2. J'avais signalé
> précédemment que R2 > 10 x R1.
> 2. idem pour R3/R12. Même si je ne vois toujours pas l'intérêt de
> toute cette tripaille pour simuler "le bouton qui existe sur tous les
> modules KNX"
> 3. et les résistances en série avec les SW, pour éviter de court-
> circuiter les capas ?
> 4. ne pas oublier la capa de 0.1µF au plus près de la broche VCC du
> MAX3222.
> 5. Le TPUART fournit 5mA sur sa broche TXD alors que l'opto 6N136
> nécessite 25mA (!)
> 6. Il y a peut être le même pb avec la broche TXD du BIM
>
> dans quelle famille comptes tu prendre le 7404 ? il faut s'assurer que
> la sortie puisse fournir 25mA.
>
> Olivier

[olivier95800]

Bonjour,

Exact ! avec 3mA dans la photo diode, on doit normalement largement
saturer le photo transistor chargé par 27k (soit 100µA).

Olivier

On 8 jan, 22:17, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Tu as mal lu la doc des opto 6N136, les 25mA sont une valeur
> maximum...
>

[thierryg]

Bonjour
J'interviens dans ce groupe autour de l'EIB avec plusieurs questions.
Si j'ai bien compris une BCU c'est un composant qui permet
d'interfacer l'EIB à autre chose d'intelligent. Ici en l'occurrence
une fonctionnalité particulière.
La BCU se compose d'un accès au médium (ici le TP-UART) et d'un
processeur pour traiter les signaux et les interpréter en tant que
trame.
Si j'ai tout bon, Ou peut-on trouver le protocole pour la BCU. J'ai vu
qu'il y avait un API. Mais c'est pour les BCU du commerce.
Personnellement j'ai juste besoin d'un composant qui fasse
l'interface. Je ne souhaite pas programmer la BCU, comme le laisse
supposer l'API. Surtout que les codes fournis sont pour du 68000 et
que je souhaite pour le moment utiliser du PIC, éventuellement
d'autres processeurs plus tard.

Qui aurait quelques réponses, pistes....

merci

[stephane.herraiz@gmail.com]

Je n'ai pas bien compris tu veux une interface à quoi vers quoi? au
bus?

On 24 jan, 18:03, thierryg <thierry.gourde...@univ-ubs.fr> wrote:
> Bonjour
> J'interviens dans ce groupe autour de l'EIB avec plusieurs questions.
> Si j'ai bien compris une BCU c'est un composant qui permet
> d'interfacer l'EIB à autre chose d'intelligent. Ici en l'occurrence
> une fonctionnalité particulière.
> La BCU se compose d'un accès au médium (ici le TP-UART) et d'un
> processeur pour traiter les signaux et les interpréter en tant que
> trame.
> Si j'ai tout bon, Ou peut-on trouver le protocole pour la BCU. J'ai vu
> qu'il y avait un API. Mais c'est pour les BCU du commerce.
> Personnellement j'ai juste besoin d'un composant qui fasse
> l'interface. Je ne souhaite pas programmer la BCU, comme le laisse
> supposer l'API. Surtout que les codes fournis sont pour du 68000 et
> que je souhaite pour le moment utiliser du PIC, éventuellement
> d'autres processeurs plus tard.
>
> Qui aurait quelques réponses, pistes....
>
> merci

[thierryg]

La question qui soutend est comment se connecter sur l'EIB. Il y a une
partie couche physique et une partie protocole de premier niveau
(synchronisation, détection de collision...) avant de passer les
trames bien formées à la couche du dessus.
A priori, d'après ce que j'en ai compris c'est le rôle d'une BCU, hors
je vois TP-UART. Ce composant se charge de quoi? Que de l'interfacage
couche physique sur la paire torsadée, ou prend en charge également
une partie des couches basses?


On 25 jan, 10:25, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je n'ai pas bien compris tu veux une interface à quoi vers quoi? au
> bus?
>
> On 24 jan, 18:03, thierryg <thierry.gourde...@univ-ubs.fr> wrote:
>
> > Bonjour
> > J'interviens dans ce groupe autour de l'EIB avec plusieurs questions.
> > Si j'ai bien compris une BCU c'est un composant qui permet
> > d'interfacer l'EIB à autre chose d'intelligent. Ici en l'occurrence
> > une fonctionnalité particulière.
> > La BCU se compose d'un accès au médium (ici le TP-UART) et d'un
> > processeur pour traiter les signaux et les interpréter en tant que
> > trame.
> > Si j'ai tout bon, Ou peut-on trouver le protocole pour la BCU. J'ai vu
> > qu'il y avait un API. Mais c'est pour les BCU du commerce.
> > Personnellement j'ai juste besoin d'un composant qui fasse
> > l'interface. Je ne souhaite pas programmer la BCU, comme le laisse
> > supposer l'API. Surtout que les codes fournis sont pour du 68000 et
> > que je souhaite pour le moment utiliser du PIC, éventuellement
> > d'autres processeurs plus tard.
>
> > Qui aurait quelques réponses, pistes....
>
> > merci

[jef2000]

Bonjour,

Le TPUART et le BCU sont deux moyens d'accéder au bus.

Le TPUART supporte 2 modes de fonctionnement:
1) Analog mode: prends en charge une grosse partie de la couche
physique
2) Normal mode: prends en charge la couche physique et une grosse
partie de la couche liaison de données
Détails: http://wp1093618.vwp0921.webpack.hosteur...tpuart.pdf

Le BCU supporte plusieurs mode de fonctionnement.
1) Bus Monitor EMI: prends en charge la couche physique
2) Data Link Layer EMI: prends en charge les couche physique et
liaison de données
3) Transport Layer EMI: prends en charge toutes les couches jusque à
la couche transport (comprise)
4) User Layer EMI: prends en charge toutes les couches jusque à la
couche utilisateur (comprise)

Pour communiquer avec un BCU, il y a plusieurs protocoles série
possibles:
PEI type 16: protocole qui utilise GND/RX/TX/RTS et CTS et est
disponible sur tous les BCU
PEI type 10 (aussi appelé FT1.2): protocole qui utilise uniquement GND/
RX/TX et qui n'est disponible qu'à partir des BCU2
Le second impose moins de contraintes au niveu du timing des messages.

Détails: http://groups.google.com/group/domotique...58ec7e6898

Si tu as juste besoin d'un composant qui fasse l'interface avec le
bus, je te conseille d'utiliser plutôt des BIM que des BCU.
L'électronique est plus ou moins la même mais elles coûtent moins cher
et peuvent être intégrées plus facilement dans tes réalisations.
Ca ressemble à ceci:
http://wp1093618.vwp0921.webpack.hosteur...0_135.html

A+

Jean-François

On 28 jan, 10:17, thierryg <thierry.gourde...@univ-ubs.fr> wrote:
> La question qui soutend est comment se connecter sur l'EIB. Il y a une
> partie couche physique et une partie protocole de premier niveau
> (synchronisation, détection de collision...) avant de passer les
> trames bien formées à la couche du dessus.
> A priori, d'après ce que j'en ai compris c'est le rôle d'une BCU, hors
> je vois TP-UART. Ce composant se charge de quoi? Que de l'interfacage
> couche physique sur la paire torsadée, ou prend en charge également
> une partie des couches basses?
>
> On 25 jan, 10:25, "stephane.herr...@gmail.com"
>
> <stephane.herr...@gmail.com> wrote:
> > Je n'ai pas bien compris tu veux une interface à quoi vers quoi? au
> > bus?
>
> > On 24 jan, 18:03, thierryg <thierry.gourde...@univ-ubs.fr> wrote:
>
> > > Bonjour
> > > J'interviens dans ce groupe autour de l'EIB avec plusieurs questions.
> > > Si j'ai bien compris une BCU c'est un composant qui permet
> > > d'interfacer l'EIB à autre chose d'intelligent. Ici en l'occurrence
> > > une fonctionnalité particulière.
> > > La BCU se compose d'un accès au médium (ici le TP-UART) et d'un
> > > processeur pour traiter les signaux et les interpréter en tant que
> > > trame.
> > > Si j'ai tout bon, Ou peut-on trouver le protocole pour la BCU. J'ai vu
> > > qu'il y avait un API. Mais c'est pour les BCU du commerce.
> > > Personnellement j'ai juste besoin d'un composant qui fasse
> > > l'interface. Je ne souhaite pas programmer la BCU, comme le laisse
> > > supposer l'API. Surtout que les codes fournis sont pour du 68000 et
> > > que je souhaite pour le moment utiliser du PIC, éventuellement
> > > d'autres processeurs plus tard.
>
> > > Qui aurait quelques réponses, pistes....
>
> > > merci

[keldo]

Hello.
Un petit point sur la situation :
Pas mal de changements professionels m'ont occupé ces derniers temps,
mais j'arrive tout de même à avancer petit à petit sur le code du
stack EIB en C sur PIC24.
Il est écrit pour un usage avec TP-UART mais les modifications
nécessaires pour un usage avec FT 1.2 ou des composants discrets du
type FreeBus seront assez minimes ; il faudra néamoins encore écrire
les modules spécifiques à FT1.2 ou à la gestion du timing sur layer 1
avec des composanst discrets, mais ça ne devrait pas changer grand
chose pour le stack EIB lui-même.
Je pense pouvoir mettre en ligne une partie du code d'ici quelques
jours afin de le soumettre à votre analyse critique.

Coté hardware, il y a déja quelques semaines que je me suis fait un
circuit expérimental sur une platine d'essai mais, rien que sur la
sortie du TP-UART je n'obtiens déja pas de résultat concluant : le TP-
UART me transmet correctement les 2 premiers bytes reçu sur le bus EIB
et ensuite ... plus rien ??? (testé à l'oscilloscope).
Bref, j'ai laissé tombé ce coté pour l'instant afin d'avancer sur le
soft, une chose à la fois ...

Keldo

[stephane.herraiz@gmail.com]

Super!
Désolé mais en ce moment je retape un appart (en KNX bien sûr ;-) ) et
je n'ai vraiment pas le temps de bosser dessus...
Tu t'es procuré où le TP-UART?
As tu une liste de références des composants utilisés dans ton montage
(références Radiospares ou Farnell) ?
Bon courage

On 17 mar, 17:14, keldo <kelderm...@ibelgique.com> wrote:
> Hello.
> Un petit point sur la situation :
> Pas mal de changements professionels m'ont occupé ces derniers temps,
> mais j'arrive tout de même à avancer petit à petit sur le code du
> stack EIB en C sur PIC24.
> Il est écrit pour un usage avec TP-UART mais les modifications
> nécessaires pour un usage avec FT 1.2 ou des composants discrets du
> type FreeBus seront assez minimes ; il faudra néamoins encore écrire
> les modules spécifiques à FT1.2 ou à la gestion du timing sur layer 1
> avec des composanst discrets, mais ça ne devrait pas changer grand
> chose pour le stack EIB lui-même.
> Je pense pouvoir mettre en ligne une partie du code d'ici quelques
> jours afin de le soumettre à votre analyse critique.
>
> Coté hardware, il y a déja quelques semaines que je me suis fait un
> circuit expérimental sur une platine d'essai mais, rien que sur la
> sortie du TP-UART je n'obtiens déja pas de résultat concluant : le TP-
> UART me transmet correctement les 2 premiers bytes reçu sur le bus EIB
> et ensuite ... plus rien ??? (testé à l'oscilloscope).
> Bref, j'ai laissé tombé ce coté pour l'instant afin d'avancer sur le
> soft, une chose à la fois ...
>
> Keldo

[keldo]

@stephane h.
> Tu t'es procuré où le TP-UART?
http://www.opternus.de
> As tu une liste de références des composants utilisés dans ton montage
> (références Radiospares ou Farnell) ?
Vu que mon petit montage ne donne pas encore satisfaction (test
oscilloscope), je préfère ne pas donner de mauvaises informations pour
l'instant.
Quand j'aurai un bout de code exploitable qui tournera effectivement
dans le PIC, je m'occuperai de nouveau du hardware, et à ce moment là
je verrai avec toi pour les composants et le schéma.

@Tous
En attendant, je mets dans la section "fichiers" du forum un
petit .ZIP au nom évocateur avec le code que je bidouille pour
l'instant.
C'est "en l'état" et brut de décoffrage, donc pas la peine d'essayer
de le compiler, ça ne marchera pas.
Il manque encore pas mal de fonctions, certaines sont incomplètes et
il y a ça et là l'une ou l'autre incohérence dans l'usage des types de
données ... je dois corriger tout cela prochainement bien sur.
Il y aurait déjà pas mal d'optimisations à faire mais, pour l'instant,
je privilégie la lisibilité et la modularité, une fois que le code
tournera il sera encore temps de réduire le nombre de fonctions et de
nettoyer le code.
Je tente au mieux d'écrire du code qui tournera indifféremment sur
PIC24F, 24H, ds30F et ds33F.
Dans la mesure du possible, j'essayerai de confiner dans un seul
fichier les spécificités de l'accès au bus via TP-UART mais ce ne sera
que partiel car pour réaliser une bonne abstraction de la méthode
d'accès (TP-UART, FT1.2, en direct "à la Freebus", etc.) il faudrait
que je les maitrise toutes, ce qui n'est pas le cas actuellement.
Bref, attendons que le code tourne correctement pour attaquer ce
chapitre ...
Dernière remarque : je n'ai plus programmé depuis environ 10 ans, et
jamais beaucoup en C, de plus je débute avec les PIC, donc soyez
indulgents ...

Voila, si vous avez un peu de temps (et d'expérience en programmation
de PIC24/30/33), n'hésitez pas à m'envoyer vos conseils, avis,
commentaire.

Keldo

[keldo]

Bonjour a tous.
Dans la zone fichiers du forum, je viens de remplacer le fichier
"STACK EIB pour PIC24-30-33. alpha 1.zip" par "STACK EIB pour
PIC24-30-33. alpha 4.zip".
J'avance doucement dans le code :
- Toujours pas la peine de compiler, ce n'est pas encore prêt ...
- Le code est devenu une petit peu plus cohérent entre les type
déclarés et leur usage.
- La configuration automatique selon le type de PIC utilisé se met en
place.
- J'ai restructuré l'organisation entre les différents fichiers afin
(d'essayer) d'isoler le code spécifique au TP-UART et aussi de rendre
le tout plus logique. A terme, les fichiers
"eib_serial_TX_int_routine.x" vont disparaitre.
- Encore quelques fonctions à implémenter (lecture/écriture de la
valeur d'un objet en mémoire) et on pourra enfin tenter une
compilation et un premier test fonctionnel.
- Une fois que les fonction de communication de base seront
fonctionnelles, je pense tenter une modification du code pour utiliser
le schéma de Freebus.org comme module d'interface à la place du TP-
UART, cela évitera de devoir le commander bien cher en Allemagne ...

Tous les commentaires (polis ... :-) sont les bienvenus.

Pour ceux qui ont déjà programmé sur PIC24/30/33, je bute sur un
problème spécifique :
Les PIC disposent de vecteurs d'interruption non utilisés par un
périphérique. Il semble que l'on puisse les utiliser pour générer des
interruptions en software mais je n'ai pas encore trouvé d'explication
claire à ce sujet.
Quelqu'un a-t-il une idée ???
Merci d'avance.

Il semble y avoir un bug dans le système de gestion du forum : dans la
liste des discussions, la date du dernier message écrit n'est pas
correcte pour notre discussion, elle est bloquée sur la date du
premier message.
Une solution ? Ou bien vaut-il mieux clore cette discussion et en
créer une nouvelle ?

Keldo.

[stephane.herraiz@gmail.com]

Bonjour,
Pourrais tu réaliser un document (graph, texte) expliquant en gros la
structure de ton programme et où tu veux en venir.
Cela nous permettra de nous y plonger à notre tour!
Bon courage.

On 14 avr, 11:52, keldo <kelderm...@ibelgique.com> wrote:
> Bonjour a tous.
> Dans la zone fichiers du forum, je viens de remplacer le fichier
> "STACK EIB pour PIC24-30-33. alpha 1.zip" par "STACK EIB pour
> PIC24-30-33. alpha 4.zip".
> J'avance doucement dans le code :
> - Toujours pas la peine de compiler, ce n'est pas encore prêt ...
> - Le code est devenu une petit peu plus cohérent entre les type
> déclarés et leur usage.
> - La configuration automatique selon le type de PIC utilisé se met en
> place.
> - J'ai restructuré l'organisation entre les différents fichiers afin
> (d'essayer) d'isoler le code spécifique au TP-UART et aussi de rendre
> le tout plus logique. A terme, les fichiers
> "eib_serial_TX_int_routine.x" vont disparaitre.
> - Encore quelques fonctions à implémenter (lecture/écriture de la
> valeur d'un objet en mémoire) et on pourra enfin tenter une
> compilation et un premier test fonctionnel.
> - Une fois que les fonction de communication de base seront
> fonctionnelles, je pense tenter une modification du code pour utiliser
> le schéma de Freebus.org comme module d'interface à la place du TP-
> UART, cela évitera de devoir le commander bien cher en Allemagne ...
>
> Tous les commentaires (polis ... :-) sont les bienvenus.
>
> Pour ceux qui ont déjà programmé sur PIC24/30/33, je bute sur un
> problème spécifique :
> Les PIC disposent de vecteurs d'interruption non utilisés par un
> périphérique. Il semble que l'on puisse les utiliser pour générer des
> interruptions en software mais je n'ai pas encore trouvé d'explication
> claire à ce sujet.
> Quelqu'un a-t-il une idée ???
> Merci d'avance.
>
> Il semble y avoir un bug dans le système de gestion du forum : dans la
> liste des discussions, la date du dernier message écrit n'est pas
> correcte pour notre discussion, elle est bloquée sur la date du
> premier message.
> Une solution ? Ou bien vaut-il mieux clore cette discussion et en
> créer une nouvelle ?
>
> Keldo.

[keldo]

On Apr 14, 1:11 pm, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Bonjour,
> Pourrais tu réaliser un document (graph, texte) expliquant en gros la
> structure de ton programme et où tu veux en venir.
> Cela nous permettra de nous y plonger à notre tour!
> Bon courage.

Le projet n'avance pas beaucoup ces derniers jours, je ne parviens pas
à trouver des périodes de temps libre assez longues pour me concentrer
sur le code.
Mais je ne laisse pas tomber, j'espère pouvoir poster une nouvelle
version d'ici une semaine, AVEC un long texte d'explication et peut-
être quelques diagrammes en Visio, histoire de faciliter la
compréhension du bazar ...

Keldo.