FAQ ESS3H32

Objet : Manuel et code d’exemple ESS3H32 — Divergence des broches RS485, interruptions d’entrée, logique d’anti-rebond et compatibilité N16R8
À l’attention de l’équipe d’assistance Eletechsup,
Nous intégrons une carte ESS3H32 à un module ESP32-S3 N16R8. Après avoir consulté les documents du MANUEL ESS3H32 et les exemples Arduino fournis, nous avons relevé plusieurs points nécessitant des éclaircissements.
1. Les affectations des broches RS485 diffèrent entre le manuel et le schéma
Les tableaux des broches dans Read before use.txt et ESS3H32 16DI-16DO ESP32 S3 Expansion Board.pdf indiquent :
Port RS485 : GPIO1, GPIO3, GPIO17
Cependant, Schematic_ESS3H32.pdf semble indiquer :
Fonction RS485    Connexion sur le schéma
Transmission    GPIO43 / TX0 → DI du transcepteur
Réception    GPIO44 / RX0 ← RO du transcepteur
Contrôle de direction    GPIO1 / RS485_RD → DE et /RE

L’exemple ESS3H32_RS485_RW.ino définit :
const int RS485RD = 1;
Serial0.begin(115200);
Il n’affecte pas explicitement les broches TX et RX.
Veuillez confirmer :
- Les broches RS485 correctes sont-elles GPIO43 pour la transmission, GPIO44 pour la réception et GPIO1 pour le contrôle de direction ?
- L’entrée GPIO1/GPIO3/GPIO17 du manuel est-elle une erreur typographique ou décrit-elle une autre révision de la carte ?
- MO5 étant affecté à GPIO17, existe-t-il un partage électrique réel entre MO5 et la RS485 ?
- Quel choix de carte Arduino et quelle version du cœur ESP32 doivent être utilisés pour que Serial0 sélectionne les bonnes broches ?
Le cartouche de titre du fichier du schéma indique également « ES30F27 », REV 1.0, daté du 19-11-2024, bien que le nom du fichier soit Schematic_ESS3H32.pdf. Veuillez confirmer que ce schéma s’applique à notre carte ESS3H32.
2. Interruption matérielle et prise en charge des impulsions courtes pour IN1–IN16
Le schéma et les exemples présentent deux registres à décalage 74HC165 utilisant :
GPIO9  — CLK
GPIO10 — LOAD
GPIO21 — DATA
Les exemples d’entrée fournis utilisent un sondage. Nous n’avons trouvé ni gestionnaire d’interruption de changement d’entrée ni connexion d’interruption distincte entre le circuit d’entrée et l’ESP32-S3.
Veuillez clarifier :
- Un changement sur l’une des entrées IN1–IN16 peut-il générer une interruption matérielle ? Si oui, quel circuit et quelle broche GPIO la fournissent-ils ?
- Existe-t-il un verrouillage d’événement matériel ou un compteur d’impulsions qui conserve les impulsions survenant entre deux lectures ?
- Si l’acquisition repose uniquement sur le sondage, quelle largeur d’impulsion minimale et quelle fréquence d’impulsions maximale peuvent être détectées de manière fiable, en tenant compte des délais des optocoupleurs et de l’intervalle de sondage requis ?
- Que recommandez-vous pour les applications nécessitant un comptage fiable des impulsions ou la détection individuelle des fronts montants/descendants ?
Nous craignons qu’une impulsion commençant et se terminant entre deux opérations de chargement parallèle ne soit complètement ignorée.
3. La comparaison d’anti-rebond des entrées n’affecte pas la valeur renvoyée
Dans ESS3H32_16DI.ino et ESS3H32_16DI_16DO.ino, Get_Input_Value() contient :
Value1 = Read_74HC165();
delay(20);
Value2 = Read_74HC165();

Value = Value1;
if (Value1 == Value2)
{
    Value = Value1;
}
Comme Value reçoit la valeur de Value1 avant la comparaison, la fonction renvoie le premier échantillon même lorsque les deux échantillons diffèrent. La comparaison ne rejette donc pas une entrée instable et ne modifie pas le résultat.
Veuillez confirmer :
- S’agit-il d’une erreur de codage dans les exemples fournis ?
- En cas de non-concordance, la valeur précédemment acceptée doit-elle être conservée, un nouvel échantillon doit-il être pris, ou une autre politique doit-elle être suivie ?
- L’anti-rebond doit-il fonctionner indépendamment pour chaque canal d’entrée ?
- Pouvez-vous fournir un code corrigé pour l’acquisition des entrées et l’anti-rebond ?
Ces exemples contiennent également delay(100) dans la boucle principale. Associé au délai de 20 ms entre les lectures, cela ajoute 120 ms de délai explicite par boucle, sans compter le temps de traitement et de communication. Veuillez expliquer le temps de réponse prévu et les limites de détection des impulsions de ces exemples.
4. Conflit entre MO10–MO12 et les broches de la PSRAM octale N16R8
Les exemples de sortie fournis affectent :
Sortie ESS3H32    GPIO
MO10    GPIO37
MO11    GPIO36
MO12    GPIO35

La documentation de l’ESP32-S3-WROOM-1/1U d’Espressif indique que les broches GPIO35, GPIO36 et GPIO37 sont connectées à la PSRAM octale et ne sont pas disponibles pour d’autres usages sur le module N16R8 concerné.
Veuillez confirmer :
- Le module N16R8 est-il pris en charge lorsque les 16 sorties de l’ESS3H32 sont utilisées ?
- Comment ces circuits de sortie sont-ils isolés de l’activité de la PSRAM, le cas échéant ?
- Quel modèle exact de module prend en charge les 16 sorties sans ce conflit ?
- Une modification matérielle ou une autre révision de la carte porteuse est-elle nécessaire ?
Veuillez fournir le tableau des broches corrigé, le schéma applicable à la révision actuelle de l’ESS3H32, les numéros de modèle de modules pris en charge et les exemples Arduino corrigés.
Merci pour votre aide.
Cordialement,

réponse :

1. Le schéma électrique prévaut. Il n’y a aucun conflit entre les broches RS485 et les broches des MOSFET.

2. « Schematic_ESS3H32.pdf » est le bon schéma électrique.

vous voulez dire que je peux utiliser DO10,11,12 et la PSRAM en même temps, n’est-ce pas ? malgré de   ESS3H32 sortie    GPIO ESP32-S3    Conflit
MO10    GPIO37    Utilisé par la PSRAM SPI octale
MO11    GPIO36    Utilisé par la PSRAM SPI octale
MO12    GPIO35    Utilisé par la PSRAM SPI octale

je viens de tester. on ne peut pas les utiliser en même temps, vous devez faire attention à cela. c’est un gros problème

Oui, nous en avons également pris note ; cependant, l’ESP32 dispose d’un nombre limité de broches, dont beaucoup sont multiplexées.

multiplexé, c’est correct. mais évitez les broches GPIO de la PSRAM

je développe actuellement un nouveau langage de contrôle qui fonctionne comme un automate programmable industriel, mais pas pour l’humain, pour l’IA. le système cible est l’ESP32.   la première carte de développement est le modèle Waveshare 8DI 8RO   votre ess3h32 est la deuxième carte de développement que je choisis.  

comme vous le savez, Waveshare a choisi une approche différente pour les entrées et les sorties.   les entrées nécessitent une plus grande précision temporelle ou le délai en cas d’urgence peut être critique, donc les entrées interrompues doivent avoir cette fonctionnalité, je suppose.

 je vous montrerai quand notre système PLC natif basé sur l’IA et les MCU sera prêt pour les tests bêta.

 https://callin2.github.io/farm_studio_frontend/pig/#en/ch01

 le bouton exécuter l’exemple  vous amène à la source de l’exemple et à la page de simulation