I2C <=> RS232 - Page 2

Le Wed, 09 Nov 2011 09:32:57 -0800, Jean-Christophe a écrit :



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).

On 10 nov, 15:21, moi-meme



Le chip proposE9% par Robert remplit bien ces fonctions.

Mais je vais rester sur un uC minimaliste E0% 8 pattes ;
j'en ai dE9%ja dans mes tiroirs et au moins je garderai
la main sur la totalitE9% du chaEE%nage soft & hard.

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



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

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)

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

| AMHA c'est utopique sans B5%C. (et mEA%me avec pas simple
| E0% cause des problE8%mes de tampon et d'adressage).



Avec un uC il n'y a pas de quoi pontifier,
n'importe qui fait ca les yeux fermE9%s.
Une fois j'ai mEA%me dFB% implE9%menter une interface USB/I2C
sur un uC qui n'avait pas du tout d'interface interne I2C,
en regE9%nE9%rant les E9%tats logiques SDA/SCL par soft
via un contrF4%le direct de deux pinouilles I/O.
Et il n'y a vraiment pas de quoi s'enorgueillir.

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




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




J'ai bien prE9%cisE9% qu'il s'agit de deux cartes mais n'ai
pas parlE9% de PC ; ca c'est toi qui l'introduis en hors-sujet.

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

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

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



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.

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



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




Je n'ai rien prE9%cisE9% quand aux cartes en question,
car c'est hors-sujet avec la question posE9%e.

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

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




Tu es encore reparti E0% cF4%tE9% de la plaque.
Mais d'oF9% te vient ce hobby ?




C'est bien le cas, et je ne vois pas
en quoi ce serait AB% trE9%s peu probable BB%
Que tu le saches ou pas, il n'y a pas que des gus
qui exigent un uP surdimensionnE9% avec OS sous Linux
quand il s'agit de dE9%velopper une carte E9%lectronique.




Tu t'es bornE9% E0% rester rE9%solument hors-sujet en dE9%formant
systE9%matiquement chacun des termes de la question posE9%e,
tu ne vas quand mEA%me pas - en plus - faire un caprice.

J'ai eu tord.

on 09/11/11, Jean-Christophe supposed :


http://www.i2cchip.com /

On 12 nov, 09:47, disco67



| On 10 nov, 22:11, Jean-Christophe
| je vais rester sur un uC minimaliste E0% 8 pattes ;
| j'en ai dE9%ja dans mes tiroirs et au moins je garderai
| la main sur la totalitE9% du chaEE%nage soft & hard.

Jean-Christophe brought next idea :


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

Je retourne dans mon univers.

Le 12/11/2011 09:47, disco67 a écrit :


c'est exactement le brochage d'un PIC !

(un 16F628 par exemple)

JJ

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é...

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.

cLx presented the following explanation :


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

"disco67"



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.

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 formulated on vendredi :


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.



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