Bien le bonjour,
Avant de vous exposer mon problème, je vais vous expliquer mon projet et le matériel... long post...
Il s'agit d'un système complet ampli 7.1 avec commande de différents modules... le Matériel quand tout fonctionne parfaitement :
Arduino Mega2560
Capteur BME280
RTC DS3231
Préampli 7.1 ZY-DTS8HD
4 Ampli 2x100w TDA7498
Ecran NEXTION 3.5" (Serial 2)
Module 8 relais (Android Box, Splitter HDMI, Switch HDMI, HDMI2AV, Switch Optical, HDMI2SPDIF, VGA2HDMI, AV2HDMI)
Module 8 relais (6 Disques dur, 2 rampes de LED)
Module 8 Relais (4 amplis + 4 ventilateurs ampli)
Alim 5v 30A
Alim 12v 30A
Alim 24v 30A
7 DS18B20 (1 par Ampli, 1 pour le PC, 2 pour les Alimentation)
2 IRF520 (1 pour ventilateur alims, 1 pour ventilateur PC)
3 TIP120 (utilisés comme switch pour Raspberry PI2 (RecalBox), Raspberry PI3 Ambilight) et LEDS pour Ambilight)
HC-05 en module BT (
Maintenant... le problème...
Sur la MEGA2560, tout fonctionne super bien, mais est très lent lorsque l'on active les commandes par BT ou par le Nextion...
J'ai donc décidé de remplacer la MEGA2560 par une DUE, ajouté les levels shifter 3.3v - 5.0v pour les I/O et le serial, ça fonctionne en effet beaucoup plus vite !!!
Sur la DUE, le plus gros problème vient des ports I2C pour le BME280 et le DS3231.
Impossible des les faire fonctionner.
J'ai donc décidé d'utiliser une NANO328P pour utiliser le port I2C, et envoyer les données Température, Humidité, Altitude, et Pression du BME280, et la date et l'heure du DS3231 vers la DUE en Serial, et c'est la que se pose le problème... j'aimerais pouvoir envoyer les données du genre :
index A = temp (si lecture serie A ce qui suit est la tempétature, fin de message $)
B = hum$
C = Alt$
D = pres$
E = jour$
F = mois$
G = annee$
H = jsem$
I = heure$
J = minute$
Mais je n'ai absolument aucune idée... j'ai lu pas mal d'articles, et tous parle d'envoyer une seule donnée, ce que j'ai déjà fait à maintes reprises, ici, c'est un début de message, le message, fin de message) et je suis complètement perdu...
Est-ce qu'une bonne âme pourrait m'aider pour ça ?
Essaye déjà de résoudre le problème de départ avant de t'attaquer à une usine à gaz.
ce serait dommage de se passer de l'I2C de la DUE à cause d'un simple bug.
Bonjour hbachetti,
Merci pour ta réponse, je vais essayer la modif du Wire.cpp et Wire.h voir ce que ça donne...
Je trouve aussi dommage de ne pas utiliser l'I2C de la DUE, ses performances sont vraiment top !
Surtout que le DS3231 et BME280 sont prévu pour fonctionner aussi bien en 5v qu'en 3.3v !
Je teste, et je reviens vers toi
croisons les doigt !
Re-Bonjour
Voilà, je viens d'essayer différentes librairies corrigée pour la DUE, mais rien ne fonctionne...
Par acquis de conscience j'ai branché mon BME280 et le DS3231 sur une NANO, et ils fonctionnent parfaitement...
Avant d'aller plus loin, je vais essayer de programmer sans les librairies du BME ni du DS3231 voir si j'arrive à avoir quelque chose en ne passant que par le Wire...
Pour le DS3231, il y a cette bibliothèque dans laquelle il est précisé que les connexions doivent se faire sur SDA1/SCL1 (qui n'ont pas de pull ups à la différence de SDA/SCL). Ce qui veut dire que le capteur doit lui avoir ces pull ups :
D'autre part, les câbles de connexions doivent être très courts, faute de quoi tous les parasites récupérés sont interprétés comme des signaux valides. Pour réduire la sensibilité aux parasites, un isolateur de type PCA9517A semble faire l'affaire.
Néanmoins plusieurs problèmes ne sont pas traités par la bibliothèque Wire.h pour DUE, et pour bien faire, il faudrait la réécrire pour tous les éliminer.
Pour la distance des cables, le DS3231 fait 10cm, le BME280 fait 50cm (j'avais peur de la distance à cause des interférences des relais et des SSR...)
mais voilà, après quelques heures pour comprendre le fonctionnement du DS3231 et du BME280 sans librairies, et avec bien entendu la correction de la bibliothèque Wire, tout fonctionne à merveille !!!
Trois jours à ne quasi pas dormir à cause de ça... à essayer tout et n'importe quoi... jamais je n'aurais pensé à la librairie Wire qui serait f... inadéquate lollll, et les librairies BME280 de sparkfun et DS3231 qui seraient aussi incompatible avec la DUE...
Premier projet en DUE, et certainement pas le dernier... quand on voit la vitesse aussi bien en BT que par le touchscreen Nextion, c'est super !!! J'essayerais encore bien les SAMD aussi...
Encore un grand merci pour votre aide à tous les 2
Quel bonheur de voir tout fonctionner... il me reste à peaufiner un peu le programme, et finir les commandes pour le preampli 7.1, et je ferai un tuto explicatif pour ceux qui seraient intéressés
Bonjour
Je suis toujours intéressé par ce qui touche à l'audio.
J'ai un projet de préampli avec filtre actif intégré, sélecteur d'entrées à relais, potentiomètre motorisé + télécommande, avec un ARDUINO bien sûr. Orientation HIFI haut de gamme.
Très heureux de t'avoir dissuadé de complexifier ton système. Tu n'aurais pas encore fini je pense.
Il y a aussi de très belles cartes à base de STM32 : STM32F407ZET6 STM32F103C8T6
Et les fameuses NUCLEO ST chez Farnell
Au boulot j'utilise beaucoup le STM32 avec les librairies ST.
Je n'ai pas encore essayé l'IDE ARDUINO avec le STM32 mais il paraît que c'est possible.
Je n'ai pas encore essayé l'IDE ARDUINO avec le STM32 mais il paraît que c'est possible.
C'est un projet qui a commencé sur le site arduino mais qui a été jugé parasite et a été poussé dehors par arduino.
Ses moyens sont limités.
Arduino version Musto avait lancé une carte à base de STM32. Après le départ de Musto tous les produits Musto ont été immédiatement arrêtés par Bansi (Yun, Linino, Tian, etc...).
AMHA ce serait dommage d'utiliser ces micro ARM STM32 avec l'univers arduino même dissident, qui est bordélique alors qu'ils sont déjà gérés par Mbed est bien plus structuré et sérieux.
ARM-Mbed fait de l'argent en vendant de la propriété intellectuelle à des fabricants de micros contrôleurs, donc peu importe quels micros sont vendus, quelles cartes sont vendues, du moment que les royalties liées aux licences rentrent.
Arduino fait de l'argent en vendant des cartes, ses moyens de développement sont énormément plus faibles et le choix de cartes est limité.
Le choix du modèle économique fait par ARM lui procure plus de moyens financiers pour développer son système que le modèle économique choisi par Arduino, mais avait-il le choix.
La société Arduino a été crée par 4 à 5 anciens enseignants d'un institut universitaire privé qui a fermé.
Se retrouvant au chômage ils ont pompé le travail[ont repris l'idée d'un de leur ancien étudiant et son projet Wiring (code + carte associée, en pompant le code et en changeant juste le micro tout en restant dans la famille avr).
Mauvais signe pour la DUE: sur le store Arduino elle est très souvent en stock 0.
Bien sûr il reste les clones mais ce n'est quand même pas un bon signe d'autant qu'il me semble qu'Arduino met le paquet sur un seul micro Atmel/Microchip ARM SamD21 (Cortex M0 à 48 MHz)
Toutes les nouvelles cartes l'utilisent.
Ce n'est pas gênant en soi mais cela laisse peu de possibilités pour améliorer les bibliothèques de la DUE qui utilise un autre micro plus puissant (Cortex M3 à 92 MHz).
Parce que quand même j'étais loin d'imaginer que la DUE n'avait toujours pas bibliothèque I2C fonctionnelle depuis le temps qu'elle est commercialisée.
C'est un projet qui a commencé sur le site arduino mais qui a été jugé parasite et a été poussé dehors par arduino.
Ses moyens sont limités.
Merci pour l'info.
J'avais aussi envie de tester MBED. Je suis habitué à ST mais c'est vraiment trop lourdingue à la longue, et pas toujours bien architecturé.
@+
Je l'utilise à mon petit niveau.
Ce que j'apprécie c'est le faible cout de la carte F103 et les 50% d'entrée 5V tolérantes qui dispencent d'utiliser des adaptateurs de niveau. Il reste qu'un micro ARM est plus fragile qu'un robuste avr, jamais crammé d'avr, déjà 2 cartes F103.
Pour la programmation les cartes Nucléo ne posent pas de problème.
Pour les cartes F103 bon marché on peut soit réutiliser la partie (détachable) du programmeur de la Nucléo soit utiliser des programmeurs ST-link.
Sous Debian j'ai eu des difficultés : pas de binaire disponible et difficultés pour compiler le logiciel ST-Link -> problème de config soit disant aisé à résoudre, mais pas pour moi.
J'ai préféré prendre le binaire existant pour Fedora (rpm) et avec alien le transformer en deb et celà roule.
J'utilise aussi ST-LINK avec des NUCLEO sur mon UBUNTU, sans problème sauf avec les séries STM32L0, plus capricieux.
Compilation de ST-LINK OK chez moi.
