Brille toujours, brille partout. Partie 2

La version actuelle de la carte du module processeur

La deuxième partie du matériel sur le système de contrôle d'éclairage de vélo fait maison est arrivée. Permettez-moi de vous rappeler que j'ai décidé de construire un réseau RS-485, dans lequel il y a des dispositifs de contrôle et de direction, et le maître est un ordinateur sur lequel le programme qui implémente la logique s'exécute. Avant de passer à la description de la logique du système, je parlerai des améliorations et des changements de paradigme en termes de matériel qui ont résulté de la discussion et des tests de prototypes de la première partie .

Dopilirovanie

Premièrement, il a été décidé de rendre les glandes modulaires, par analogie avec Arduino et un certain nombre d'autres projets. J'ai pensé que mon module principal (processeur) contient plus de composants que de modules fonctionnels, donc ce sera la mère. Et des "boucliers" y seront insérés. En termes de circuits, les modifications suivantes ont été apportées:

1) Un stabilisateur de puissance (AMS1117-5.0) a été ajouté.
2) Le câblage d'alimentation du microcontrôleur est modifié.
3) La carte du module principal est divorcée en tenant compte de la fabrication industrielle, mais la deuxième couche de cuivre est utilisée au minimum - vous pouvez fabriquer une carte monocouche à la maison et installer des cavaliers.
4) Ajout d'un cavalier Endpoint pour terminer la ligne sur le dernier appareil.
5) Ajout d'un cavalier de verrouillage RST pour bloquer la réinitialisation du microcontrôleur.
6) De manière similaire à l'article 3, les cartes filles de l'encodeur et le pilote de bande LED sont divorcés.
7) J'attends la première commande d'essai de circuits imprimés, alors que seuls les modules principaux (ITEAD Studio).


La carte fille du pilote de bande LED

Vanity autour de RS-485

Maintenant, je me tourne vers le maître du réseau. En termes de fer, tout y est simple - enfin, du moins je le pensais. J'ai pris un adaptateur USB-UART, y ai connecté une petite carte avec MAX485 et plusieurs résistances et j'ai commencé à travailler. Et il a marché sur un excellent râteau, bien documenté, mais pour un débutant ce n'était absolument pas évident.

Le MAX485 doit être commuté entre la réception (faible sur les broches épinglées ~ RE et DE) et la transmission (élevée). Guidé par une logique simple, j'ai utilisé la sortie DTR du convertisseur (sur CP2102) pour contrôler le mode, en le tirant par programmation. Et j'ai eu une honte. D'une manière ou d'une autre, le système ne fonctionnait qu'avec des délais trop longs entre la réception et la transmission. Et tout cela parce que le DTR bascule lentement. Avec quelle lenteur, je n'avais rien à mesurer, alors je viens de fournir un lien vers une étude de râteau plus saine en utilisant un oscilloscope.

À partir du même matériau, j'ai compris ce qui suit: l'utilisation du FT232 sera la moins douloureuse, car elle a une conclusion, lorsque la puce est configurée par défaut, elle est juste conçue pour commuter les modes RS-485. Autrement dit, un niveau élevé apparaît dessus lors de la transmission via UART. Ainsi, le clone chinois Arduino Nano a été extrait des bacs, ~ RST est court-circuité à la masse, le fil est soudé à la 13e étape du FT232, et tout cela est connecté au MAX485. Cela fonctionne comme une horloge. Dans la version «combat» du système, bien sûr, une telle conception ne sera pas utilisée - l'industrie chinoise est heureuse d'offrir des planches prêtes à l'emploi similaires.

Logique système

Enfin, à quoi ressemble l'ensemble du processus du point de vue du maître. Il fonctionne avec des objets de périphérique, qui peuvent être contrôlés ou exécutifs. Les gestionnaires sont divisés en réels ("fer"), virtuels et temporisateurs. L'exécutif ne peut être que réel.

Des dispositifs de contrôle virtuels seront nécessaires lors de la mise en œuvre d'une gestion de système plus complexe, en particulier lorsqu'une interface Web lui sera attachée. Ils seront également utiles pour l'intégration avec quelque chose que je n'ai pas encore trouvé. Oui, ici, probablement, je dois dire qu'en général un tel «appareil» fait partie du système.

Un périphérique est un objet de la classe Device. L'ensemble minimal d'attributs est le nom, le type et l'indicateur d'utilisation. En outre, en fonction du type, l'adresse sur le bus, le nom du périphérique esclave, la priorité de contrôle, les valeurs initiales des registres et certains autres attributs peuvent être ajoutés. Les principales méthodes de la classe concernent le travail avec des appareils réels - c'est la lecture et l'écriture des registres.

Et maintenant, après avoir plus ou moins décidé de la structure du programme du système, nous pouvons commencer la mise en œuvre. Actuellement, il existe les éléments suivants:
1) Module Comm485 contenant une description de la classe Conn. Les méthodes de classe sont l'ouverture et la fermeture d'une connexion, l'envoi et la réception d'un paquet et la vérification d'une somme de contrôle.
2) le module Device485 contient la classe Device décrite ci-dessus.
3) le module logiciel principal.


Carte fille codeur

En fait, deux choses sont implémentées dans le module principal. La première consiste à créer les objets nécessaires de la classe Device en fonction du fichier de configuration. Le second est directement la logique du système.

Dans le processus

Actuellement, les travaux suivants:

1) Compilation d'une liste des actionneurs impliqués.
2) Pour chaque artiste, une liste des dispositifs de contrôle impliqués est compilée.
3) Les valeurs des registres du dispositif de commande avec la priorité la plus élevée sont enregistrées dans les registres de l'actionneur et de la commande, qui ont une priorité inférieure.

Autrement dit, supposons que nous ayons un encodeur (fer) avec une faible priorité et un dispositif de contrôle virtuel avec une priorité élevée. En mode veille, le périphérique virtuel est désactivé. Lorsque vous devez régler la lumière sans soulever le cinquième point du canapé, un appareil virtuel est activé (pendant une courte période) pour donner de nouveaux paramètres à l'interprète et à l'encodeur.

Mais très probablement, après une petite modification du logiciel, le mode principal sera le suivant: il y a deux appareils de contrôle avec la même priorité. Lors de la modification des registres de l'un d'entre eux, les valeurs sont écrites dans les registres de l'exécuteur testamentaire et de l'autre gestionnaire, qui n'ont subi aucune modification.

En fait, pour l'instant. Le projet est disponible sur github., dans le dossier hôte, vous pouvez voir un code Python effrayant. Il y a deux modules (Comm485, Device485), le programme principal (hôte) et le dossier cfg dans lequel se trouvent les fichiers de configuration: établir une connexion UART et une liste de périphériques.

La suite suivra certainement.

PS Être victime de la migration de Habr, dans un certain nombre de possibilités est limitée.

Source: https://habr.com/ru/post/fr381907/