I2C <=> RS232

[Jean-Christophe]

'soir,
J'ai deux cartes qui doivent discuter ensemble,
l'une est en I2C et l'autre en RS232 et je
voudrais éviter d'utiliser un uC juste pour ca :
connaissez-vous un chip qui translate de l'I2C
vers du RS485 ? (dans les deux sens bien entendu)

[Robert Lacoste]

"Jean-Christophe" <5...@free.fr> a écrit dans le message de news:
070c4854-1918-4a1c...@h12g2000vbf.googlegroups.com...

>'soir,
>J'ai deux cartes qui doivent discuter ensemble,

>'une est en I2C et l'autre en RS232 et je
>voudrais éviter d'utiliser un uC juste pour ca :
>connaissez-vous un chip qui translate de l'I2C
>vers du RS485 ? (dans les deux sens bien entendu)

Voir chez NXP, par exemple SC16IS740 (disponible par exemple chez Digikey).
Mais la mise en oeuvre de ce type de produits n'est pas si transparente que
çà...
Cordialement,


--
Robert Lacoste
ALCIOM - The mixed signal experts
www.alciom.com

[Jean-Christophe]

"Robert Lacoste"

>> "Jean-Christophe" a écrit :

>> J'ai deux cartes qui doivent discuter ensemble,
>> une est en I2C et l'autre en RS232 et je
>> voudrais éviter d'utiliser un uC juste pour ca :
>> connaissez-vous un chip qui translate de l'I2C
>> vers du RS485 ? (dans les deux sens bien entendu)

Correction : (...) vers du RS232 ? (dans les deux sens)

> Voir chez NXP, par exemple SC16IS740 (disponible par exemple chez
> Digikey). Mais la mise en oeuvre de ce type de produits n'est pas si
> transparente que çà...

Merci Robert : je DL la datasheet pour investiguer.
( mais à première vue, s'il faut le paramétrer, autant
utiliser un petit PIC à 8 pattes déja dans les tiroirs )

[moi-meme]

ben i2C c'est un système maître-esclave et synchrone. Le changement de
sens est hard. Il est aussi multi esclave.

RS232 c'est (éventuellement) full duplex et asynchrone (le synchrone en
RS232 c'est pas classique).

AMHA c'est utopique sans µC. (et même avec pas simple à cause des
problèmes de tampon et d'adressage).

[Jean-Christophe]

On 10 nov, 15:21, moi-meme

> ben i2C c'est un système maître-esclave et synchrone.
> Le changement de sens est hard. Il est aussi multi esclave.
> RS232 c'est (éventuellement) full duplex et asynchrone
> (le synchrone en RS232 c'est pas classique).
> AMHA c'est utopique sans µC. (et même avec pas simple
> à cause des problèmes de tampon et d'adressage).

Le chip proposé par Robert remplit bien ces fonctions.

Mais je vais rester sur un uC minimaliste à 8 pattes ;
j'en ai déja dans mes tiroirs et au moins je garderai
la main sur la totalité du chaînage soft & hard.

[moi-meme]

Le Thu, 10 Nov 2011 13:11:03 -0800, Jean-Christophe a écrit :

> Le chip proposé par Robert remplit bien ces fonctions.
>
> Mais je vais rester sur un uC minimaliste à 8 pattes ; j'en ai déja dans
> mes tiroirs et au moins je garderai la main sur la totalité du chaînage
> soft & hard.

+1
c'est un problème de protocole avant d'être un problème hard.

[DEMAINE Benoit-Pierre]

On 10/11/11 13:28, Jean-Christophe wrote:
> "Robert Lacoste"
>
>>> "Jean-Christophe" a écrit :
>>> J'ai deux cartes qui doivent discuter ensemble,
>>> une est en I2C et l'autre en RS232 et je
>>> voudrais éviter d'utiliser un uC juste pour ca :
>>> connaissez-vous un chip qui translate de l'I2C
>>> vers du RS485 ? (dans les deux sens bien entendu)
>
> Correction : (...) vers du RS232 ? (dans les deux sens)

Bit banging coté RS232 => pas besoin de hard (pourquoi payer pour un
composant quand on peux faire sans ?).

--
>o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

[DEMAINE Benoit-Pierre]

On 10/11/11 21:21, moi-meme wrote:
> AMHA c'est utopique sans µC. (et même avec pas simple à cause des
> problèmes de tampon et d'adressage).

Mon monde est probablement un rêve pour toi, car je l'ai fait.

En fait, on se fout de savoir si c'est un port série ou parallèle, le code
est le même.

ATTENTION: sur les OS actuels, il faut faire TRES attention à la vitesse
de scheduling, la VM, et la gestion de priorité des processus. J'ai eu des
problèmes très fun sous Linux 2.4 parce que j'avais (à l'époque) mal
compris la gestion processus et des interruptions sous Linux (et je me
suis retrouvé avec 50 Bauds ... sur un AMD 1.4G, c'était un peu lent ^^ ).
Tu aura le même problème (sauf si tu es sous DOS 6.x ou antérieurs: DOS 7
est multi-taches)

[Jean-Christophe]

On 11 nov, 05:05, DEMAINE Benoit-Pierre

| "Jean-Christophe" a crit :

| J'ai deux cartes qui doivent discuter ensemble,
| une est en I2C et l'autre en RS232 et je

| voudrais viter d'utiliser un uC juste pour ca :

| connaissez-vous un chip qui translate de l'I2C

| vers du RS232 ? (dans les deux sens bien entendu)


> Bit banging coté RS232

La transmission s'effectue dans les deux sens ;
l' I2C tourne à 100 kbps et le RS232 à 9,6 kbps ;
et de plus les signaux I2C (SCL & SDA) ne sont pas
directement mappables sur les signaux RS232 (TX & RX)
Ce n'est donc pas une solution, sinon je l'aurais déja fait.

> => pas besoin de hard (pourquoi payer pour
> un composant quand on peux faire sans ?).

Dans un cas comme celui-ci on ne peut faire sans,
un minimum de réflection l'aurait montré.


> DEMAINE Benoit-Pierre (aka DoubleHP)
> " not only blind but deaf "

[Jean-Christophe]

On 11 nov, 11:13, DEMAINE Benoit-Pierre

| On 10/11/11 21:21, moi-meme wrote:
| AMHA c'est utopique sans µC. (et même avec pas simple
| à cause des problèmes de tampon et d'adressage).

> Mon monde est probablement un rêve pour toi, car je l'ai fait.

Avec un uC il n'y a pas de quoi pontifier,
n'importe qui fait ca les yeux fermés.
Une fois j'ai même dû implémenter une interface USB/I2C
sur un uC qui n'avait pas du tout d'interface interne I2C,
en regénérant les états logiques SDA/SCL par soft
via un contrôle direct de deux pinouilles I/O.
Et il n'y a vraiment pas de quoi s'enorgueillir.

Et si c'est sans uC : décris comment tu t'y es pris.

> En fait, on se fout de savoir si c'est un port
> série ou parallèle, le code est le même.

S'il y a du code alors il y a bien un uC ou un uP.

> ATTENTION: sur les OS actuels, il faut faire TRES attention à la vitesse
> de scheduling, la VM, et la gestion de priorité des processus. J'ai eu des
> problèmes très fun sous Linux 2.4 parce que j'avais (à l'époque) mal
> compris la gestion processus et des interruptions sous Linux (et je me
> suis retrouvé avec 50 Bauds ... sur un AMD 1.4G, c'était un peu lent ^^ ).
> Tu aura le même problème (sauf si tu es sous DOS 6.x ou antérieurs: DOS 7
> est multi-taches)

J'ai bien précisé qu'il s'agit de deux cartes mais n'ai
pas parlé de PC ; ca c'est toi qui l'introduis en hors-sujet.

[DEMAINE Benoit-Pierre]

On 11/11/11 12:01, Jean-Christophe wrote:
>> > En fait, on se fout de savoir si c'est un port
>> > série ou parallèle, le code est le même.
> S'il y a du code alors il y a bien un uC ou un uP.

oui, celui de la machine ou tu as ton RS232.

[Jean-Christophe]

On 11 nov, 12:15, DEMAINE Benoit-Pierre

| On 11/11/11 12:01, Jean-Christophe wrote:
| S'il y a du code alors il y a bien un uC ou un uP.

> oui, celui de la machine ou tu as ton RS232.

Il y a une carte avec un port I2C, une autre
avec un port RS232, et la question est :
comment INTERFACER ces deux ports
avec le moins de ressources possibles.

Et tu viens parler de bitbang,
puis de PC sous Linux ...

[DEMAINE Benoit-Pierre]

On 11/11/11 11:23, Jean-Christophe wrote:
>> > Bit banging coté RS232
> La transmission s'effectue dans les deux sens ;
> l' I2C tourne à 100 kbps et le RS232 à 9,6 kbps ;
> et de plus les signaux I2C (SCL & SDA) ne sont pas
> directement mappables sur les signaux RS232 (TX & RX)
> Ce n'est donc pas une solution, sinon je l'aurais déja fait.

Si tu avais regardé ce qu'est le bit banging ... tu n'aurais pas pu
objecter que c'est incompatible avec le RS232 pour la raison que tu invoque.

Puisque tu dis que tu n'es pas sur un PC, c'est encore plus simple que je
pensais: tu n'as donc aucun problème de scheduling. Et tu as donc la
maitrise totale des signaux qui sortent de ton port. Tu déconfigure le
RS232, et tu ... fais du bit banging à l'ancienne.

Sur un PC, il est */EVIDEMENT/* "utopiste" d'utiliser les pattes Tx et Rx:
le bit banging se fait avec les autres pins; les 6 autres pins que tout le
monde oublie ...

Sur un "pas PC", tu repasse ton port en TTL, et l'I2C se fait en bit
banging les yeux fermés.

La méthode simple utilise 3 pins, ou, deux pins si tu en as une en
bi-directive. Je ne sais pas si c'est possible de le faire avec seulement
2 pins unidirectives (une dans chaque sens).

Quand au débit, ce n'est pas un problème. Quand tu aura écrit tes unités
correctement, tu aura remarqué que tes débits sont identiques:
- ton I2C est à 100kbps
- un RS232 CLASSIQUE tourne à 9.6kBps, ou B ne se lit pas Byte, mais BAUD.
En comptant le bit de latence, ça fait 96kbps. Parce que si ton RS232
tourne à 9.6kbps, soit 960 BAUD, à ta place, je m'inquiéterais, car les
modems à 1.4 k BAUD sont plus vieux que moi ... alors un PC qui ne
pourrait faire que 960 BAUDs ...

=> 100 / 96 ... moins de 4% entre les deux.

Et de toute façon, la question ne se pose pas, pour deux raisons:
- un vrai bon RS232 monte à 54kB (soit 500 kbps)
- le bit banging, si tu avais cherché, ne se fait pas avec les lignes Tx
Rx, mais RTS CTS. Et ton débit peut dépasser les 500kbps de très loin: tu
es limité par la vitesse du CPU, pas celle du hard.

Enfin, peut être que TON I2C tourne à 100kbps, mais le protocole monte à
4M ... alors, oui, si tu bossais à 4M là j'avoue qu'un port RS232 peut se
coucher, mais puisque tu n'es qu'à 100k, ça passe sans problème.

Donc, le bit banging est envisageable. Des milliers de gens l'ont fait
avant moi (je ne suis pas assez malin pour ré-inventer la roue: je ne peux
qu'améliorer e travail des autres, je suis incapable de créer une bonne idée).

[DEMAINE Benoit-Pierre]

On 11/11/11 12:23, Jean-Christophe wrote:
> Il y a une carte avec un port I2C, une autre
> avec un port RS232, et la question est :
> comment INTERFACER ces deux ports
> avec le moins de ressources possibles.
>
> Et tu viens parler de bitbang,
> puis de PC sous Linux ...

Effectivement, j'avais retenu "une carte et un PC"; j'avais zapé que tu
avais deux cartes.

Mais pour le reste: quelle différence entre une carte et un PC ? quand tu
vois que la majorité des cartes sont des ARM, et que jusqu'il y a très
peu, la majorité des cartes tournaient sur 486 ...

Quand à Linux et à mes problèmes de scheduling, bah, la majorité des
cartes, qu'elles soient sous 486 ou sous ARM ... ont des OS multi-tache,
et la majorité supportent Linux.

Donc, à part le cas très peu probable ou tu aurais dev un firmware toi
même, de zero (pratique qui tend à disparaître avec le temps), tu devrais
être concerné par mes avertissements.

[Jean-Christophe]

On 11 nov, 12:33, DEMAINE Benoit-Pierre

> Si tu avais regard ce qu'est le bit banging

J'ai implémenté en ASM du bitbang sur des
uP qui n'avaient pas du tout de port série,
à une époque où tu salissais encore tes couches.

> tu n'aurais pas pu objecter que c'est incompatible
> avec le RS232 pour la raison que tu invoque.

Les vitesses des deux ports sont imposées, différentes et fixes :
il est hors de question d'agir en amont pour changer ces vitesses.
De plus la gestion de SCL & SDA de l' I2C ne peut se faire à partir
des seuls *signaux* TX & RX du RS232 sans ajouter un chip
d'interfaçage.

> Puisque tu dis que tu n'es pas sur un PC, c'est encore plus simple que je

> pensais: tu n'as donc aucun probl me de scheduling. Et tu as donc la

> maitrise totale des signaux qui sortent de ton port.

Non, absolument pas. Ce ne sont pas les données du problème
que j'ai posé, mais tu t'obstines à répondre à côté.
Les cartes sont comme elles sont et il est hors de question
d'y changer quoi que ce soit. La question posée est
d'interfacer des *signaux* I2C avec des *signaux* RS232,
pas de changer les ports, ni les vitesses, ni le code.


> Tu d configure le RS232, et tu ... fais du bit banging l'ancienne.

Alors autant dropper le port RS232 pour utiliser
directement un port I2C et j'aurais directement
deux ports I2C donc plus aucun problème d'adaptation !
Tu es têtu, à vouloir changer les données du problème
posé pour y apporter une solution qui n'y répond pas.


> Sur un PC (snip)

Déja dit : pas de PC ici.

> Sur un "pas PC", tu repasse ton port en TTL,

> et l'I2C se fait en bit banging les yeux ferm s.

Déja dit : pas d'action en amont.
Un port I2C, un port RS232, et l'interface au milieu.
Je ne vois pas ce qu'il y a de si difficile à comprendre.


> La m thode simple utilise 3 pins, ou, deux pins si tu en as une en

> bi-directive. Je ne sais pas si c'est possible de le faire avec seulement
> 2 pins unidirectives (une dans chaque sens).

> Quand au d bit, ce n'est pas un probl me. Quand tu aura crit tes unit s
> correctement, tu aura remarqu que tes d bits sont identiques:
> - ton I2C est 100kbps
> - un RS232 CLASSIQUE tourne 9.6kBps, ou B ne se lit pas Byte, mais BAUD.

Je n'ai pas parlé de byte : ca c'est toi qui en parles.
Quand aux unités, le Baud mesure le nombre de *symboles*
par seconde et dans mon cas le symbole est un bit ;
alors 9,6 kbps ca veut dire 9600 bits par seconde,
c'est comme ca ... sauf pour toi, apparament.


> En comptant le bit de latence, a fait 96 kbps.

9,6 ca veut dire 9,6 et non pas 96.
Si pour toi une vitesse de 9,6 k correspond à 96 k
alors 1 = 10 et il y a de quoi se poser des questions.


> Parce que si ton RS232 tourne 9.6kbps,
> soit 960 BAUD, ta place, je m'inqui terais,

Oh que oui, je suis inquiet : mais pas pour moi :o)


> car les modems 1.4 k BAUD sont plus vieux que moi ...

> alors un PC qui ne pourrait faire que 960 BAUDs ...

Déja dit : pas de PC ici.

> => 100 / 96 ... moins de 4% entre les deux.

100 / 9,6 ca fait 1041 % ...
C'est plus une paille, c'est une poutre.


> Et de toute fa on, la question ne se pose pas, pour deux raisons:
> - un vrai bon RS232 monte 54kB (soit 500 kbps)

Une fois pour toutes : les vitesses sont fixes et inchangeables.
Tu changes les données du problème, donc ta réponse ne s'y rapporte
pas.


> - le bit banging, si tu avais cherch , ne se

> fait pas avec les lignes Tx Rx, mais RTS CTS.

Sur un uC on bitbang via des ports I/O *quelconques*
il n'est donc même plus question de dénominations
telles que CTS/RTS. Encore une fois tu parles de PC
alors qu'il n'en est pas question ici. C'est lourd.


> Et ton d bit peut d passer les 500kbps de tr s loin:
> tu es limit par la vitesse du CPU, pas celle du hard.

Les vitesses sont fixées et inchangeables, c'est une des données
du problème : si tu tiens absolument à faire l'impasse là-dessus,
tu ne répond pas la question posée, alors inutile de t'obstiner.

> Donc, le bit banging est envisageable.

Non, et encore moins pour la gestion des signaux SCL & SDA de l' I2C.
Ca aussi je l'ai déja répété, mais tu sembles sourd et aveugle.

> Des milliers de gens l'ont fait avant moi

> (je ne suis pas assez malin pour r -inventer la roue: je ne peux
> qu'am liorer e travail des autres, je suis incapable de cr er une bonne id e).

Prétendre apporter une solution à un problème posé en changeant
les données dudit problème, ca s'appelle répondre à côté.
Et vu que tu fais la même chose sur d'autres threads de fse,
quelque chose me dit que tu ne le fais même pas exprès.

> DEMAINE Benoit-Pierre (aka DoubleHP)
> " not only blind but deaf "

Si tu tiens vraiment à raconter que tu as fait du bitbang
via CTS/RTS sur un PC sous Linux, ouvre un nouveau thread
mais n'essaie pas dérisoirement d'imposer cela à tout prix
dans un thread où c'est hors-sujet avec la question posée.

[Jean-Christophe]

On 11 nov, 12:37, DEMAINE Benoit-Pierre

> quand tu vois que la majorit des cartes sont des ARM

Non, je ne le vois pas.
Arrête de projeter tes croyances sur les autres.


> jusqu'il y a tr s peu, la majorit des cartes tournaient sur 486

Je n'ai rien précisé quand aux cartes en question,
car c'est hors-sujet avec la question posée.

On se fout bien de savoir si ces cartes ont un uC
minimaliste à 8 MHz ou des uP double coeur à 1 GHz
ni de savoir s'il y a un OS temps réél ou pas.

La question ne concerne QUE les deux ports physiques
et leur interfaçage, et ca c'est *externe* aux cartes.
Qu'est-ce que tu n'as pas encore compris à cette question ?


> Quand Linux et mes probl mes de scheduling, bah, la majorit des

> cartes, qu'elles soient sous 486 ou sous ARM ...

> ont des OS multi-tache, et la majorit supportent Linux.

Tu es encore reparti à côté de la plaque.
Mais d'où te vient ce hobby ?


> Donc, part le cas tr s peu probable ou tu
> aurais dev un firmware toi m me, de zero

C'est bien le cas, et je ne vois pas
en quoi ce serait « trés peu probable »
Que tu le saches ou pas, il n'y a pas que des gus
qui exigent un uP surdimensionné avec OS sous Linux
quand il s'agit de développer une carte électronique.


> tu devrais tre concern par mes avertissements.

Tu t'es borné à rester résolument hors-sujet en déformant
systématiquement chacun des termes de la question posée,
tu ne vas quand même pas - en plus - faire un caprice.

[moi-meme]

Le Fri, 11 Nov 2011 05:03:03 -0800, Jean-Christophe a écrit :

> J'ai implémenté en ASM du bitbang sur des uP qui n'avaient pas du tout
> de port série, à une époque où tu salissais encore tes couches.

avec des boucles de temps logicielles ...

[LeLapin]

Jean-Christophe a tapoté du bout de ses petites papattes :

> Si tu tiens vraiment à raconter que tu as fait du bitbang
> via CTS/RTS sur un PC sous Linux, ouvre un nouveau thread
> mais n'essaie pas dérisoirement d'imposer cela à tout prix
> dans un thread où c'est hors-sujet avec la question posée.

Vas-y, mords-le ! ;)

--
LeLapin

[DEMAINE Benoit-Pierre]

J'ai eu tord.

[Jean-Christophe]

On 11 nov, 14:58, LeLapin

> Vas-y, mords-le ! ;)

:o)

[Tonton Th]

On 11/11/2011 12:33 PM, DEMAINE Benoit-Pierre wrote:

> - un RS232 CLASSIQUE tourne à 9.6kBps, ou B ne se lit pas Byte, mais BAUD.
> En comptant le bit de latence, ça fait 96kbps. Parce que si ton RS232

J'ai vraiment l'impression que tu racontes n'importe quoi, là.

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[DEMAINE Benoit-Pierre]

On 11/11/11 17:50, Tonton Th wrote:
> On 11/11/2011 12:33 PM, DEMAINE Benoit-Pierre wrote:
>
>> - un RS232 CLASSIQUE tourne à 9.6kBps, ou B ne se lit pas Byte, mais BAUD.
>> En comptant le bit de latence, ça fait 96kbps. Parce que si ton RS232
>
> J'ai vraiment l'impression que tu racontes n'importe quoi, là.

Oui, je me suis trompé; mais j'ai quand même certains PC avec des ports à
112kbps.

Je me suis trompé à cause de certains projets avec des BAUDs de 4 et/ou 8
bits, ou je case un Byte par BAUD.

par ailleurs: 9600 BAUDS, ça fait à peine 8000 bits par seconde ...

[LeLapin]

DEMAINE Benoit-Pierre a tapoté du bout de ses petites papattes :

> Je me suis trompé à cause de certains projets avec des BAUDs de 4 et/ou 8
> bits, ou je case un Byte par BAUD.

D'abord un mot de 4 bits ça s'appelle pas un byte mais un nibble,
ensuite si le baudrate est différent du bitrate c'est soit que tu
modules, soit que tu utilises plusieurs fils, et encore, dans ce
dernier cas je ne suis pas certain que ce soit le bon terme.

--
LeLapin

[Jean-Christophe]

On 11 nov, 18:41, DEMAINE Benoit-Pierre :

> j'ai quand même certains PC avec des ports à 112kbps.

Sur un PC le port RS232 peut être initialisé à
diverses vitesses; aussi bien 150 bps que 115,2 kbps.
Alors je ne vois pas l'utilité de ta remarque,
sauf à essayer de te raccrocher aux branches.

> Je me suis trompé à cause de certains projets

Je me demande sur quel genre de projet tu
pourrais bosser, ca fait froid dans le dos.


| On 11/11/2011 12:33 PM, DEMAINE Benoit-Pierre :

| un RS232 CLASSIQUE tourne à 9.6kBps,
| ou B ne se lit pas Byte, mais BAUD

Un « Baud » étant un « symbole par seconde »
ton affirmation « Bps = Baud par seconde »
équivaut à « Bps = symbole par seconde par seconde »
ce qui ne veut rien dire pour la plupart
des Etres Humains normalement constitués.

> DEMAINE Benoit-Pierre (aka DoubleHP)
> " not only blind but deaf "

And heavy, too.

[LeLapin]

Jean-Christophe a tapoté du bout de ses petites papattes :

> Un « Baud » étant un « symbole par seconde »
> ton affirmation « Bps = Baud par seconde »
> équivaut à « Bps = symbole par seconde par seconde »
> ce qui ne veut rien dire pour la plupart
> des Etres Humains normalement constitués.

Si, ça veut dire que le baudrate accélère. ;)

--
LeLapin

[val]

Dans son message précédent, LeLapin a écrit :

Ça vient aussi tout simplement des bits de start et stop qui ne
transmettent aucun signal, à la différence des bits codant les
quartets.

[LeLapin]

val a tapoté du bout de ses petites papattes :

Les bits de start, de stop et de parité comptent.

--
LeLapin

[val]

Après mûre réflexion, LeLapin a écrit :

Il n'y a pas de règle, c'est toi qui décide : raw bit rate, net bit
rate...

[LeLapin]

Classiquement, quand on ne précise pas, c'est inclus. Quand on dit
vulgairement 9600 bauds par exemple.

--
LeLapin

[disco67]

on 09/11/11, Jean-Christophe supposed :
> 'soir,

> J'ai deux cartes qui doivent discuter ensemble,

> l'une est en I2C et l'autre en RS232 et je
> voudrais éviter d'utiliser un uC juste pour ca :

> connaissez-vous un chip qui translate de l'I2C

> vers du RS485 ? (dans les deux sens bien entendu)

http://www.i2cchip.com/

[Jean-Christophe]

On 11 nov, 20:15, LeLapin

Tu veux dire que le *symbole* accélère :o)

Bps ( Baud par seconde ) : mesure d'accélération
en « symbole par seconde carrée »
( c'est donc pour ca que les fils chauffent ! )

Bref, l'interface pour passer de l'I2C au RS232 se fera via
un PC à 2 GHz sous Linux avec noyau propriétaire recompilé,
support NFS par Firewall IP de masquerading Ethernet
en double filtrage coaxial sur ICMP modifié 42.3 bis,
un trombonne, une clé à molette, un sac de couchage,
un faux nez lumineux et une perruque tournante.

------------------------------------------------------------------
3733T tEcHnOLOgY wiZaRd hAcK3Rz GuRu
Intel double Core 4 GHz 64 Go SDRAM
DD 512 Go Quantum SCSI CdRom 128X
Ecran 17' Sony Trinitron (pitch 0.25)
Souris Logitech, clavier Mitsumi
OS : Win7, Linux (Ru73 dA wOrLdZ)
Peugeot 406 diesel aileron arriere
Autoradio SuperMegaBass 2x200 Watt
Sexe : 32 centimètres
-------------------------------------------------------------------

[Jean-Christophe]

On 12 nov, 09:47, disco67

> http://www.i2cchip.com/

| On 10 nov, 22:11, Jean-Christophe
| je vais rester sur un uC minimaliste à 8 pattes ;
| j'en ai déja dans mes tiroirs et au moins je garderai
| la main sur la totalité du chaînage soft & hard.

[disco67]

Jean-Christophe brought next idea :

C etait juste une suggestion (avec 18 pattes), çà servira à
d'autres....

Je retourne dans mon univers.

[jj]

Le 09/11/2011 18:32, Jean-Christophe a écrit :
> 'soir,
> J'ai deux cartes qui doivent discuter ensemble,
> l'une est en I2C et l'autre en RS232 et je
> voudrais éviter d'utiliser un uC juste pour ca :
> connaissez-vous un chip qui translate de l'I2C
> vers du RS485 ? (dans les deux sens bien entendu)

Dans tous les cas, il faut implémenter un système qui supporte chaque
protocole de chaque coté. cela ne peut pas être totalement transparent.

as tu accès aux applications de chaque coté ?

JJ

[jj]

c'est exactement le brochage d'un PIC !

(un 16F628 par exemple)

JJ

[disco67]

jj expressed precisely :

Bah....oui, l'important c'est la fonction non ? Parce que autrement
....faut reinventer la roue. Surtout si le "full duplex" doit etre
supporté...

[cLx]

On 16/11/2011 09:43, disco67 wrote:
> jj expressed precisely :

>> c'est exactement le brochage d'un PIC !
>> (un 16F628 par exemple)

> Bah....oui, l'important c'est la fonction non ? Parce que autrement .....faut

> reinventer la roue. Surtout si le "full duplex" doit etre supporté...

Pour un truc aussi simple, quitte à utiliser un µC, autant le faire soi-même,
ça serait dommage de perdre la maîtrise du firmware de la carte.

[Jean-Christophe]

"jj"

> Dans tous les cas, il faut implémenter un système qui supporte chaque
> protocole de chaque coté. cela ne peut pas être totalement transparent.

Oui, le protocole de com et le format des trames est bien entendu le même.

> as tu accès aux applications de chaque coté ?

Oui, mais l'install client hard & soft est fixe et ne peut changer.
( un mix entre du matos déja installé et de nouvelles cartes )
A terme toutes les installs seront homogènes,
mais d'ici là faut il bien faire discuter ce petit monde.

Merci JJ mais je vais utiliser un uC 12F à 8 broches.

[jj]

Le 16/11/2011 10:20, Jean-Christophe a écrit :
> "jj"
>
>> Dans tous les cas, il faut implémenter un système qui supporte chaque
>> protocole de chaque coté. cela ne peut pas être totalement transparent.
>
> Oui, le protocole de com et le format des trames est bien entendu le même.
>
>> as tu accès aux applications de chaque coté ?
>

> Oui, mais l'install client hard& soft est fixe et ne peut changer.

> ( un mix entre du matos déja installé et de nouvelles cartes )
> A terme toutes les installs seront homogènes,
> mais d'ici là faut il bien faire discuter ce petit monde.
>
> Merci JJ mais je vais utiliser un uC 12F à 8 broches.
>
>

oui, je pense que je ferai pareil à ta place, comme cela tu pourras
adapter le soft du 12F à ton besoin sans avoir besoin de toucher au reste.

bon développement!

JJ

[disco67]

cLx presented the following explanation :

Donc reinventer la roue, si on a le temps et la motivation why not...:)

[Jean-Christophe]

"disco67"

>>>> c'est exactement le brochage d'un PIC !
>>>> (un 16F628 par exemple)
>>> Bah....oui, l'important c'est la fonction non ? Parce que autrement
>>> .....faut reinventer la roue. Surtout si le "full duplex" doit etre
>>> supporté...
>> Pour un truc aussi simple, quitte à utiliser un µC, autant le faire
>> soi-même,
>> ça serait dommage de perdre la maîtrise du firmware de la carte.
> Donc reinventer la roue, si on a le temps et la motivation why not...:)

Sachant que de toutes facons il faudra au moins configurer
un chip, je préfère largement programmer 24F à 8 pattes
minimaliste pour garder la maîtrise de toute la chaîne.
Ut dixi.

[LeLapin]

disco67 a tapoté du bout de ses petites papattes :

C'est surtout un bon moyen de :
- s'instruire en refaisant toute l'analyse du problème et se heurter
aux problèmes de développement. Ce genre d'expérience ressert toujours.

- améliorer la roue. Ou au pire, mieux l'adapter au cahier des charges
précis.

Moi j'ai toujours développé comme ça.C'est un excellent moyen de se
rendre indispensable quand on est entouré d'ingénieurs qui font du Lego
ou du livresque.

--
LeLapin

[disco67]

LeLapin formulated on vendredi :

> disco67 a tapoté du bout de ses petites papattes :
>> cLx presented the following explanation :
>>> On 16/11/2011 09:43, disco67 wrote:
>>>> jj expressed precisely :
>>>>> c'est exactement le brochage d'un PIC !
>>>>> (un 16F628 par exemple)
>>>> Bah....oui, l'important c'est la fonction non ? Parce que autrement
>>>> .....faut reinventer la roue. Surtout si le "full duplex" doit etre
>>>> supporté...
>>>
>>> Pour un truc aussi simple, quitte à utiliser un µC, autant le faire
>>> soi-même,
>>> ça serait dommage de perdre la maîtrise du firmware de la carte.
>>
>> Donc reinventer la roue, si on a le temps et la motivation why not...:)
>
> C'est surtout un bon moyen de :
> - s'instruire en refaisant toute l'analyse du problème et se heurter aux
> problèmes de développement. Ce genre d'expérience ressert toujours.

Le seul probleme c est que certains problemes "tordus" ont necessités
des millions d heures ingenieur. Ca existe tout terminé. Mebon chacun
passe sont temps comme il le peux.

>
> - améliorer la roue. Ou au pire, mieux l'adapter au cahier des charges
> précis.
>
> Moi j'ai toujours développé comme ça.C'est un excellent moyen de se rendre
> indispensable quand on est entouré d'ingénieurs qui font du Lego ou du
> livresque.

Donc vous avez le temps...(sic...)

[LeLapin]

Quand on est payé pour, on a toujours le temps. Et quand on est un bon
développeur à l'esprit vif, on va bien plus vite qu'une meute
d'ingénieurs sans imagination.

--
LeLapin

[disco67]

After serious thinking LeLapin wrote :

Si vous saviez le nombre de fois que je l ai entendue celle là....:(

[LeLapin]

Moi aussi, en forme de compliment. :)

--
LeLapin

[cLx]

On 18/11/2011 11:54, disco67 wrote:
> Le seul probleme c est que certains problemes "tordus" ont necessités des
> millions d heures ingenieur. Ca existe tout terminé. Mebon chacun passe sont
> temps comme il le peux.

Pour faire un truc aussi simple que de faire passer des octets d'un bus à
l'autre, dont les couches physiques sont déjà toutes prêtes ? OK je suis
d'accord avec toi s'il était question de le refaire avec des transistor
discrets, mais avec un micro-contrôleur, faut pas pousser quand même :P

"Faire un pont diviseur de tension pour convertir du 0-10V en 0-5V ? Pas
envie de réinventer la roue, ça, des millions d'heures-ingénieur y ont déjà
été consacrées, il vaut mieux acheter une carte PC/104 avec un ADC, un DAC,
et un logiciel sous licence pour réaliser cette fonction."

--
cLx
"hé oui, c'est déjà vendredi !"

[Jean-Christophe]

"disco67"

> Le seul probleme c est que certains problemes "tordus" ont necessités des
> millions d heures ingenieur. Ca existe tout terminé. Mebon chacun passe
> sont temps comme il le peux.

Si, pour faire un bridge I2C/RS232 il te faut des millions d'heures,
c'est sūr que tu passes ton temps comme tu peux.
De mon cōté, je ne vais pas approvisionner un nouveau chip
alors que j'ai du 12F ą disposition, et pour moins cher.
--------


De toutes facons j'ai déja fait mon choix ;o)
| Jean-Christophe, 12 nov, 13:38

| Bref, l'interface pour passer de l'I2C au RS232 se fera via

| un PC ą 2 GHz sous Linux avec noyau propriétaire recompilé,

| support NFS par Firewall IP de masquerading Ethernet
| en double filtrage coaxial sur ICMP modifié 42.3 bis,

| un trombonne, une clé ą molette, un sac de couchage,