04/09/2007, 00:17:46
Merci Keldo pour toutes ces bonnes idées.
Je vous laisse cogiter sur la partie électronique.
Pour en revenir aux questions posées sur le protocole FT1.2 j'ai
quelques précisions.
FT1.2 n'est rien d'autre qu'un protocole permettant de transférer des
blocs de données simultanément et de manière fiable entre la BCU et un
autre système.
Son avantage est de ne nécessiter que les connections RXD, TXD et GND,
contrairement à son prédécesseur (PEI type 16) qui nécessite une
gestion très fine des signaux RTS/CTS
Si on se penche d'un peu plus près sur ce qui peut être transmis dans
ces "blocs de données" (voir chapitre 3/6/3 "External message
interface" de la spec), on remarque qu'une BCU permet l'accès à
plusieurs niveaux:
1) Data Link layer (bus monitor)
2) Data Link layer (normal)
3) Transport layer
4) User layer
Si je ne me trompe, le mode busmonitor n'est pas intéressant car il
permet uniquement d'écouter le bus mais pas d'envoyer
L'accès à la couche Data link en mode normal est celui qu'utilise EIBD
lorsqu'on crée un groupsocket. Il permet de recevoir les données
concernant toutes les adresses de groupes et d'envoyer des données
vers n'importe quelle adresse de groupe. Je pense que dans ce cas, la
gestion des Ack/Nack doit être faite par l'utilisateur.
Si on accède à la couche transport, j'ai cru comprendre qu'elle gère
les ack/nack/retransmission pour nous
Enfin si on accède à la couche utilisateur, il est possible de
laisser à la BCU la gestion des objets de groupe et d'aller simplement
lire la valeur (localement dans la BCU) d'un objet, la modifier et
positionner les flags pour lui indiquer ce qu'il faut faire. Le format
des messages est décrit sommairement au paragraphe "4.5 User layer
EMI" et certaines explication complémentaires peuvent être trouvées
dans le chapitre 3/4/1 "User layer" paragraphe "6 Externally
accessible user layer interface"
Comme d'habitude tout est dans la spec, c'est d'ailleurs son utilité
première. Malheureusement pour ceux à qui ça pose problème, elle est
en anglais.
En conclusion, FT1.2 est capable de faire quelque chose de plus ou
mois similaire à TPUART, mais il est également capable de beaucoup
plus, tout dépend comment on veut l'utiliser.
Merci à tous pour vos contributions, il y a quelques mois à peine, je
désespérais en croyant être le seul martien à avoir ce genre d'idées
en tête ;-)
On 3 sep, 10:23, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je suis d'accord avec toi pour ce "grand" cahier des charges.
> Cela permettra de développer confortablement.
> Allez au boulot!
>
> On 31 août, 17:36, keldo <kelderm...@ibelgique.com> wrote:
>
> > On 30 août, 21:04, "stephane.herr...@gmail.com"
>
> > <stephane.herr...@gmail.com> wrote:
> > > Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
> > > je penche pour les BIM pour un début.
>
> > Point de vue prix (opternus) :
> > - BIM avec stack ver. 2.x = environ 40 euros
> > - TP-UART avec composants annexes = environ 15 euros
>
> > Mais, si on se lance dans la fabrication d'une dizaine de platines
> > d'eesai, pourquoi ne pas prévoir les deux interfaces directement ?
> > Il suffit de prévoir les pistes pour le TP-UART (+ quelques composants
> > discrets) ET le connecteur pour la prise PEI du BCU/BIM, après, on
> > peut toujours décider de ne pas souder les composants pour l'un ou
> > l'autre, ça ne devrait quasi rien changer au prix de la platine. Il
> > suffirait de prévoir les pistes depuis les pins TX, RX et GND du PIC
> > pour les deux cas, éventuellement avec des jumpers pour choisir l'une
> > ou l'autre interface.
>
> > Pour le TP-UART, il faut compter une puce SOIC-20 pattes et une
> > quinzaine de composants classiques ou SMD (diodes, résistances, petits
> > condensateurs, un crystal) + les 2 pinoches pour la borne de bus EIB.
> > Le schema quasi complet est disponible dans la datasheet du TP-UART
> > (en mode "normal").
> > Entre le PIC et le TP-UART il faut compter minimum 4 liens (TX, RX,
> > GND et Reset) et maximum 7 liens (TX,RX, Reset, 5V, GND, Save,
> > Temperature Warning).
>
> > Pour le coté BCU/BIM, il faut TX, RX et GND vers le PIC mais il faut
> > aussi prévoir une résistance de haute précision (voir même plusieurs
> > en série si la valeur exacte n'existe pas) pour connecter les pins 5V
> > et PEI-Type du BCU/BIM.
>
> > Cela va compliquer un petit peu le schema mais ajouter une isolation
> > optique entre le PIC et le BCU/BIM ou le TP-UART peut être une bonne
> > idée. Dans ce cas il faut prévoir une alim externe pour le PIC.
> > (La ligne Reset du TP-UART étant bidirectionelle, actif = 0 Volts, il
> > faut sans doute deux pins du PIC et 2 optocoupleurs pour cette ligne
> > si elle est protégée).
> > Si on décide de se passer de l'isolation optique, on peut peut-être
> > alimenter le PIC depuis le TP-UART ou le BCU/BIM mais il faudrait
> > calculer la consommation du PIC et des éventuels accessoires ; au
> > total, pour une platine d'expérimentation, ce n'est sans doute pas une
> > bonne idée.
>
> > - - - - -
>
> > Admettons que l'on mette les optocoupleurs et une alim externe, je
> > propose alors de mettre une entrée pour une alim de 12V DC et
> > d'ajouter sur la platine la place pour les composants (style LM7805)
> > afin de prévoir une sortie 5V DC et une sortie 3,3V DC.
>
> > Une grande partie des PIC haut de gamme (je n'aime pas écrire PIC
> > 16bits, cela porte à confusion avec les PIC "16F" - pour le "16" - et
> > les PIC 18F - qui codent leurs instructions sur 16 bits - alors que
> > les PIC "16bits" codent leurs instructions sur 24 bits ...) ont plus
> > d'un UART, ce serait sympa de prévoir aussi sur la platine de test une
> > prise RS-232 (avec MAX232 ou optocoupleurs) vers le second UART afin
> > de brancher notre petit montage en direct sur un PC, cela peut se
> > réveler très pratique pour le débugage et pour utiliser un bootloader.
>
> > Bien sur, ne pas oublier d'ajouter les pistes pour une led et un
> > microswitch avec le condo et la résistance d'anti-rebond (= led et
> > bouton de programmation de l'adresse physique sur un BCU).
>
> > Autre idée : ajouter un connecteur pour ICD2 ou prévoir des points de
> > connection équivalents pour les 5 signaux nécessaires serait
> > certainement judicieux, toujours pour la programmation et le
> > débuggage.
>
> > Enfin, selon la façon dont est facturé la fabrication de petites
> > series de platine (sans doute un forfait pour une taille maximum
> > donnée), il est peut être judicieux de remplir "l'espace vide" de la
> > platine avec :
> > - l'emplacement pour une petite puce I²C ou SPI (et sa piste "Chip
> > Select") pour ajouter l'eeprom qu'il n'y a plus dans les PIC haut de
> > gamme.
> > - l'emplacement pour un connecteur (ou plusieurs) pour cable plat,
> > permettant de relier les ports I/O du PIC avec d'autres cartes
> > contenant des périphériques (un module relais, dimmers, capteurs de
> > températures, etc.).
> > - l'emplacement pour quelques puces SOIC (14, 18, 20 ou 28 pattes) si
> > l'on désire ajouter l'un ou l'autre périphérique en SMD.
> > - des bandes latérales pré-trouées avec les signaux GND, 3.3V, 5V,
> > SPI, I²C, etc.
> > - une grille de trous métalisés.
>
> > Voila, j'ai donné mes idées en vitesse mais c'est à discuter.
> > Si il y a de la place pour ajouter quelques composants "perso" sur la
> > platine et que le prix reste dans la gamme d'une dizaine d'euros, je
> > suis intéressé par 5 ou 6 pièces.
>
> > De mon coté, je continue doucement à écrire mon assembleur pour le
> > 877A mais j'écris de toute façon d'abord du pseudo code en français et
> > je le laisse en commentaire dans mon code source, donc :
> > 1) c'est un bon exercice pour apprendre les PIC16 - j'ai d'autres
> > projets en tête pour eux de toute manière.
> > 2) avec le pseudo code en français, j'aurai fait le plus gros du
> > travail d'analyse, ce sera alors facile de porter tout cela en C (ou
> > Pascal) quand je passerai sur PIC haut de gamme, ce qui arrivera de
> > toute façon bientôt car mon projet principal en EIB (gestion de
> > chaudière évoluée + paneaux solaires en appoint) va sans doute occuper
> > trop de place en mémoire et l'application serait bien plus facile avec
> > la gestion de la multiplication sur des réels en hardware ...
>
> > D'un autre coté, j'ai un très bon cours sur les PIC16 (et 18) mais
> > rien sur les PIC haut de gamme, je devrai sans doute tatoner un peu
> > plus au début sur un PIC24.
Je vous laisse cogiter sur la partie électronique.
Pour en revenir aux questions posées sur le protocole FT1.2 j'ai
quelques précisions.
FT1.2 n'est rien d'autre qu'un protocole permettant de transférer des
blocs de données simultanément et de manière fiable entre la BCU et un
autre système.
Son avantage est de ne nécessiter que les connections RXD, TXD et GND,
contrairement à son prédécesseur (PEI type 16) qui nécessite une
gestion très fine des signaux RTS/CTS
Si on se penche d'un peu plus près sur ce qui peut être transmis dans
ces "blocs de données" (voir chapitre 3/6/3 "External message
interface" de la spec), on remarque qu'une BCU permet l'accès à
plusieurs niveaux:
1) Data Link layer (bus monitor)
2) Data Link layer (normal)
3) Transport layer
4) User layer
Si je ne me trompe, le mode busmonitor n'est pas intéressant car il
permet uniquement d'écouter le bus mais pas d'envoyer
L'accès à la couche Data link en mode normal est celui qu'utilise EIBD
lorsqu'on crée un groupsocket. Il permet de recevoir les données
concernant toutes les adresses de groupes et d'envoyer des données
vers n'importe quelle adresse de groupe. Je pense que dans ce cas, la
gestion des Ack/Nack doit être faite par l'utilisateur.
Si on accède à la couche transport, j'ai cru comprendre qu'elle gère
les ack/nack/retransmission pour nous
Enfin si on accède à la couche utilisateur, il est possible de
laisser à la BCU la gestion des objets de groupe et d'aller simplement
lire la valeur (localement dans la BCU) d'un objet, la modifier et
positionner les flags pour lui indiquer ce qu'il faut faire. Le format
des messages est décrit sommairement au paragraphe "4.5 User layer
EMI" et certaines explication complémentaires peuvent être trouvées
dans le chapitre 3/4/1 "User layer" paragraphe "6 Externally
accessible user layer interface"
Comme d'habitude tout est dans la spec, c'est d'ailleurs son utilité
première. Malheureusement pour ceux à qui ça pose problème, elle est
en anglais.
En conclusion, FT1.2 est capable de faire quelque chose de plus ou
mois similaire à TPUART, mais il est également capable de beaucoup
plus, tout dépend comment on veut l'utiliser.
Merci à tous pour vos contributions, il y a quelques mois à peine, je
désespérais en croyant être le seul martien à avoir ce genre d'idées
en tête ;-)
On 3 sep, 10:23, "stephane.herr...@gmail.com"
<stephane.herr...@gmail.com> wrote:
> Je suis d'accord avec toi pour ce "grand" cahier des charges.
> Cela permettra de développer confortablement.
> Allez au boulot!
>
> On 31 août, 17:36, keldo <kelderm...@ibelgique.com> wrote:
>
> > On 30 août, 21:04, "stephane.herr...@gmail.com"
>
> > <stephane.herr...@gmail.com> wrote:
> > > Au fait, on part sur les BIM M13x ou les TP-UART finalement ???? moi
> > > je penche pour les BIM pour un début.
>
> > Point de vue prix (opternus) :
> > - BIM avec stack ver. 2.x = environ 40 euros
> > - TP-UART avec composants annexes = environ 15 euros
>
> > Mais, si on se lance dans la fabrication d'une dizaine de platines
> > d'eesai, pourquoi ne pas prévoir les deux interfaces directement ?
> > Il suffit de prévoir les pistes pour le TP-UART (+ quelques composants
> > discrets) ET le connecteur pour la prise PEI du BCU/BIM, après, on
> > peut toujours décider de ne pas souder les composants pour l'un ou
> > l'autre, ça ne devrait quasi rien changer au prix de la platine. Il
> > suffirait de prévoir les pistes depuis les pins TX, RX et GND du PIC
> > pour les deux cas, éventuellement avec des jumpers pour choisir l'une
> > ou l'autre interface.
>
> > Pour le TP-UART, il faut compter une puce SOIC-20 pattes et une
> > quinzaine de composants classiques ou SMD (diodes, résistances, petits
> > condensateurs, un crystal) + les 2 pinoches pour la borne de bus EIB.
> > Le schema quasi complet est disponible dans la datasheet du TP-UART
> > (en mode "normal").
> > Entre le PIC et le TP-UART il faut compter minimum 4 liens (TX, RX,
> > GND et Reset) et maximum 7 liens (TX,RX, Reset, 5V, GND, Save,
> > Temperature Warning).
>
> > Pour le coté BCU/BIM, il faut TX, RX et GND vers le PIC mais il faut
> > aussi prévoir une résistance de haute précision (voir même plusieurs
> > en série si la valeur exacte n'existe pas) pour connecter les pins 5V
> > et PEI-Type du BCU/BIM.
>
> > Cela va compliquer un petit peu le schema mais ajouter une isolation
> > optique entre le PIC et le BCU/BIM ou le TP-UART peut être une bonne
> > idée. Dans ce cas il faut prévoir une alim externe pour le PIC.
> > (La ligne Reset du TP-UART étant bidirectionelle, actif = 0 Volts, il
> > faut sans doute deux pins du PIC et 2 optocoupleurs pour cette ligne
> > si elle est protégée).
> > Si on décide de se passer de l'isolation optique, on peut peut-être
> > alimenter le PIC depuis le TP-UART ou le BCU/BIM mais il faudrait
> > calculer la consommation du PIC et des éventuels accessoires ; au
> > total, pour une platine d'expérimentation, ce n'est sans doute pas une
> > bonne idée.
>
> > - - - - -
>
> > Admettons que l'on mette les optocoupleurs et une alim externe, je
> > propose alors de mettre une entrée pour une alim de 12V DC et
> > d'ajouter sur la platine la place pour les composants (style LM7805)
> > afin de prévoir une sortie 5V DC et une sortie 3,3V DC.
>
> > Une grande partie des PIC haut de gamme (je n'aime pas écrire PIC
> > 16bits, cela porte à confusion avec les PIC "16F" - pour le "16" - et
> > les PIC 18F - qui codent leurs instructions sur 16 bits - alors que
> > les PIC "16bits" codent leurs instructions sur 24 bits ...) ont plus
> > d'un UART, ce serait sympa de prévoir aussi sur la platine de test une
> > prise RS-232 (avec MAX232 ou optocoupleurs) vers le second UART afin
> > de brancher notre petit montage en direct sur un PC, cela peut se
> > réveler très pratique pour le débugage et pour utiliser un bootloader.
>
> > Bien sur, ne pas oublier d'ajouter les pistes pour une led et un
> > microswitch avec le condo et la résistance d'anti-rebond (= led et
> > bouton de programmation de l'adresse physique sur un BCU).
>
> > Autre idée : ajouter un connecteur pour ICD2 ou prévoir des points de
> > connection équivalents pour les 5 signaux nécessaires serait
> > certainement judicieux, toujours pour la programmation et le
> > débuggage.
>
> > Enfin, selon la façon dont est facturé la fabrication de petites
> > series de platine (sans doute un forfait pour une taille maximum
> > donnée), il est peut être judicieux de remplir "l'espace vide" de la
> > platine avec :
> > - l'emplacement pour une petite puce I²C ou SPI (et sa piste "Chip
> > Select") pour ajouter l'eeprom qu'il n'y a plus dans les PIC haut de
> > gamme.
> > - l'emplacement pour un connecteur (ou plusieurs) pour cable plat,
> > permettant de relier les ports I/O du PIC avec d'autres cartes
> > contenant des périphériques (un module relais, dimmers, capteurs de
> > températures, etc.).
> > - l'emplacement pour quelques puces SOIC (14, 18, 20 ou 28 pattes) si
> > l'on désire ajouter l'un ou l'autre périphérique en SMD.
> > - des bandes latérales pré-trouées avec les signaux GND, 3.3V, 5V,
> > SPI, I²C, etc.
> > - une grille de trous métalisés.
>
> > Voila, j'ai donné mes idées en vitesse mais c'est à discuter.
> > Si il y a de la place pour ajouter quelques composants "perso" sur la
> > platine et que le prix reste dans la gamme d'une dizaine d'euros, je
> > suis intéressé par 5 ou 6 pièces.
>
> > De mon coté, je continue doucement à écrire mon assembleur pour le
> > 877A mais j'écris de toute façon d'abord du pseudo code en français et
> > je le laisse en commentaire dans mon code source, donc :
> > 1) c'est un bon exercice pour apprendre les PIC16 - j'ai d'autres
> > projets en tête pour eux de toute manière.
> > 2) avec le pseudo code en français, j'aurai fait le plus gros du
> > travail d'analyse, ce sera alors facile de porter tout cela en C (ou
> > Pascal) quand je passerai sur PIC haut de gamme, ce qui arrivera de
> > toute façon bientôt car mon projet principal en EIB (gestion de
> > chaudière évoluée + paneaux solaires en appoint) va sans doute occuper
> > trop de place en mémoire et l'application serait bien plus facile avec
> > la gestion de la multiplication sur des réels en hardware ...
>
> > D'un autre coté, j'ai un très bon cours sur les PIC16 (et 18) mais
> > rien sur les PIC haut de gamme, je devrai sans doute tatoner un peu
> > plus au début sur un PIC24.