I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un μp de gestion, tu as une floppé de bus qui converge vers ce μP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
[^] # Re: oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un μp de gestion, tu as une floppé de bus qui converge vers ce μP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
"La première sécurité est la liberté"