DUE, 2 ports I2C, même fréquence d'horloge ?

Bonjour,
Je désire connecter plusieurs périphériques I2C/TWI sur une DUE; une RTC DS1307 (100KHz max), un afficheur LCD (400KHz max) et 3 thermomètres TEMP102 (400KHz en fast mode et jusqu'à 3,4MHz en speed mode).
Pour optimiser la vitesse d'affichage, je voulais passer la fréquence horloge du port I2C (TWI) de 100KHz par défaut, à 400KHz.
Mais bien évidemment la DS1307 ne suivra pas, et comme il y a deux ports sur la DUE, je comptais bien utiliser le deuxième pour le ou les périphériques limités à 100KHz.
Seulement, problème:
la librairie Wire, crée deux instances de TwiWire, qui sont Wire et Wire1, le constructeur configure le port en master avec entre autre paramètre la fréquence désirée pour le port I2C, mais cette fréquence est une constante (TWI_CLOCK), donc, sans modification de la librairie, les deux ports auront la même fréquence d'horloge.

D'où ma question, y aurait-il une raison hardware à cela ?

J'espère avoir été assez clair.

Bonjour,

Avec cette simple modification tu peut choisir la fréquence de chaque port I2C séparément :wink:

void TwoWire::begin(uint32_t twi_clock) {
  if (onBeginCallback)
  onBeginCallback();

  // Disable PDC channel
  twi->TWI_PTCR = UART_PTCR_RXTDIS | UART_PTCR_TXTDIS;

  TWI_ConfigureMaster(twi, twi_clock, VARIANT_MCK);
  status = MASTER_IDLE;
}

D'un point de vue hardware il ne devrait pas y a voir de problémes.

Merci beaucoup Skywodd,
C'était un peu mon idée.
Pourquoi ne soumettrais-tu pas la modif à l'équipe Arduino ?
Je pense que le fait de pouvoir avoir des fréquences d'horloge indépendantes est indispensable.

bilbo83:
Pourquoi ne soumettrais-tu pas la modif à l'équipe Arduino ?

L'API Arduino est uniformisé, tu ne peut pas ajouter un prototype de fonction à cause d'une seule carte avec deux port I2C :wink:
C'est le principe des classes d'abastraction matérielle, tu as une API partout pareil, simple à utiliser mais au détriment des fonctionnalités "bas niveau".

bilbo83:
Je pense que le fait de pouvoir avoir des fréquences d'horloge indépendantes est indispensable.

99.99% des utilisateurs lambda ne savent même pas à quelle fréquence fonctionne leurs modules I2C, ils veulent juste que ça marche, d'où les 100KHz par défaut :wink:

L'API Arduino est uniformisé, tu ne peut pas ajouter un prototype de fonction à cause d'une seule carte avec deux port I2C smiley-wink
C'est le principe des classes d'abastraction matérielle, tu as une API partout pareil, simple à utiliser mais au détriment des fonctionnalités "bas niveau".

L'API est uniformisée, certes, mais pas figée. Depuis que je m'intéresse au monde Arduino (environ un an et demi) j'ai constaté de nombreuses évolutions/modifications de l'API, y compris au niveau des constructeurs avec de nouveaux paramètres. Je pense qu'il y aura d'autres évolutions en fonction des besoins et de l'évolution du matériel.
On voit fleurir de nombreuses librairies dont la qualité est inégale, difficile dans ces conditions de faire le bon choix si on fait parti des 99.99% des utilisateurs lambda. Mieux vaut utiliser les "officielles" dans ce cas.

Très cordialement.

bilbo83:
L'API est uniformisée, certes, mais pas figée. Depuis que je m'intéresse au monde Arduino (environ un an et demi) j'ai constaté de nombreuses évolutions/modifications de l'API, y compris au niveau des constructeurs avec de nouveaux paramètres. Je pense qu'il y aura d'autres évolutions en fonction des besoins et de l'évolution du matériel.
On voit fleurir de nombreuses librairies dont la qualité est inégale, difficile dans ces conditions de faire le bon choix si on fait parti des 99.99% des utilisateurs lambda. Mieux vaut utiliser les "officielles" dans ce cas.

Le truc c'est que dans l'API "de base" il ne doit pas pouvoir y avoir d'incompatibilité. Sinon ce serait le bazar.
Les changements effectuaient entre 002x et 1.0.x en réalité c'est juste l'officialisation de divers astuces déjà possible avec l'API existante (pull-up : pinMode+digitalWrite => INPUT_PULLUP, ...)
Les seules vrai changement d'API que j'ai vu c'est au niveau de la lib ethernet, UDP en particulier et de Wire (pour uniformiser avec l'API Stream (Serial, SPI, ...)).