+ Quelle est l'utilisation de la mémoire RAM, Flash, persistante ?

Aperçu des besoins de stockage

Nous avons actuellement besoin d'environ 526 octets de mémoire persistante.

+ Existe-t-il un tableau des besoins en mémoire par microcontrôleur ?

s. Tableau sous : Quels sont les besoins en mémoire RAM, Flash, mémoire persistante.
Les besoins en mémoire devraient être similaires pour tous les types de microcontrôleurs. Cela dépend entre autres du compilateur utilisé et des bibliothèques associées.

+ La taille de la bibliothèque DALI 2-Release, qui doit être associée à l'application, peut varier légèrement selon les microprocesseurs.

Sur les systèmes embarqués, vous n'avez généralement que des bibliothèques statiques.

+ De combien de mémoire a besoin un simple Control Gear DT 6 (module LED) ?

s. Tableau sous : Quelle est la quantité de mémoire nécessaire RAM, Flash, mémoire persistante

+ Est-il possible de répartir la pile DALI sur deux contrôleurs afin que les pilotes de bas niveau soient exécutés sur un "contrôleur à bas coût" ?

Nous ne supportons pas cela. Le pilote de bas niveau est responsable du timing au sein de l'API, ce timing est critique, une communication supplémentaire entre deux processeurs serait une résistance au timing important.

+ Est-il possible de faire fonctionner deux instances de la pile DALI dans un contrôleur Cortex ?

Oui, s'il s'agit de types différents -> par exemple un Device et un Gear.

+ Quelle est l'interface avec les pilotes de bas niveau ?

L'accès est réalisé via des callbacks avec un tampon de données contenant les données et l'horodatage. L'API-LL est exécutée directement, c'est-à-dire que les modifications sont immédiatement lancées en arrière-plan. Les trames reçues sont stockées temporairement dans une file d'attente qui doit être traitée par le programme principal. doivent être traitées par le programme de premier plan.

+ Quelles sont les ressources HW et les ressources d'interruption nécessaires ? (par ex. timer,....)

• s. Tableau sous : Quelle est la quantité de mémoire nécessaire RAM, Flash, mémoire persistante
• Deux GPIO sont nécessaires. Une comme entrée (DALI_RX) et une comme sortie (DALI_TX). La broche DALI_RX doit pouvoir être interrompue.
• Une minuterie avec une résolution de 1µS (microseconde) et l'interruption de la minuterie correspondante.
• Les interruptions du LowLevelDriver doivent avoir la même et la plus haute priorité dans le système.

+ Quelle est la durée de rétention des interruptions ou, le cas échéant, combien de temps les interruptions sont-elles bloquées ?

Les valeurs suivantes sont valables pour un MCU Cortex M4 avec une fréquence d'horloge de 168 Mhz. Ceci peut être appliqué de manière linéaire à d'autres fréquences d'horloge.

a) Interruption du timer :
2.7µs toutes les 10000µs en mode "Idle".
4.1µs par bit à l'émission avec un temps d'inactivité consécutif de 430µs ou 840µs.

b) Interruption de changement de niveau :
Typique : 2.2µs par changement de niveau. Rarement 3.3µs au maximum.

En réception, seul le temps b) est nécessaire.
En émission, la somme de a) + b).

+ Le DALI stack a-t-il des exigences de timing spécifiques pour le système ?

Le programme utilisateur doit appeler la fonction "dalill_processQueues()" au moins toutes les 5ms. L'appel ne doit pas être bloqué (par exemple par l'enregistrement de données persistantes).

+ Quel est l'effort nécessaire pour porter les fichiers de la bibliothèque ? ANSI, C++ ?

La pile DALI est programmée en ANSI-C + GNU Extensions. L'utilisation de la pile DALI est possible pour les applications programmées en C++ en définissant "__cplusplus".

+ Quelle est l'utilisation pour les environnements multitâches comme RTOS ?

L'API fonctionne sous RTOS. Là, le "DaliProcessQueues" est externalisé dans un thread séparé - pour activer ce thread pour les données entrantes du bus, il y a le CallBack "SignalToThread" que le LowLevelDriver appelle après la réception des données. Toutes les actions pour l'API doivent être appelées à partir de ce thread, car l'API n'est pas multithreadable. Les interruptions du LowLevelDriver doivent avoir la même et la plus haute priorité dans un RTOS.

+ Dans le manuel, il est mentionné que plusieurs appareils DALI peuvent être instanciés dans un firmware. Est-il possible d'avoir les mêmes types de dispositifs (concrètement deux ou plusieurs modules LED DT 6) ?

Il est possible d'instancier une unité de contrôle et un périphérique de contrôle ou un périphérique d'entrée sur un système. Toutefois, il n'est pas possible de faire fonctionner en parallèle des appareils de même type. Une extension serait en principe envisageable, de sorte que deux boîtiers de contrôle DT6/8 puissent également être instanciés.

+ Dans la configuration minimale requise, la fréquence d'horloge est de 32MHz. Quel pourcentage de la puissance de calcul d'un microcontrôleur est utilisé par la pile DALI ?

Dies kann nicht eindeutig beantwortet werden. Unter Last (z.B. Dimm-Prozess) ca. 15% und im Ruhezustand <1%. data-preserve-html-node="true" Bei höheren Taktfrequenzen entsprechend weniger.

+ La bibliothèque DALI 2 nécessite le support d'une mémoire non volatile de 526 octets. Qu'est-ce qui est stocké dans la mémoire non volatile ? Quand la sauvegarde a-t-elle lieu (fonctionnement normal, panne de courant, etc.) ? Existe-t-il une API pour prendre en charge l'accès non volatile ?

La norme DALI spécifie ses propres variables et leur stockage dans une mémoire persistante ou volatile, par exemple, il est défini que la "shortAddress" est stockée dans une NVM (Non-volatile memory). Les variables de travail telles que le contenu du DTR0 (Data Transfer Register 0) ne sont pas conservées après un redémarrage du système.

Les variables persistantes sont écrites à un intervalle de temps spécifiable et la mémoire persistante est limitée à un certain nombre de lectures/écritures. Afin de préserver la durée de vie de la mémoire, le stockage des données persistantes peut également être configuré de manière à ce qu'il soit effectué en cas de brown-out ou d'arrêt du système.

Nous ne fournissons pas d'API, la pile DALI ne fournit que des callbacks qui permettent de demander à l'application du client de sauvegarder les données persistantes.

+ Comment les bibliothèques ou les logiciels sont-ils livrés ? Librairie ? (Si oui, quels compilateurs sont supportés) ? Une documentation sur le portage est-elle disponible ?

• Il y a deux modèles pour la livraison du logiciel de la pile DALI.
  i. Fichiers sources, où le client peut modifier/adapter les fichiers sources
  ii. Librairie statique, dans laquelle le client reçoit le fichier d'en-tête "libdali.h" et les fichiers objets de la pile déjà compilés dans le fichier de librairie "liblibdali.a".
• La chaîne d'outils doit être fournie si elle n'est pas déjà disponible chez MBS.
• Les librairies sont déjà compilées sans erreur ni avertissement (avec GCC, le compilateur IAR et le compilateur Keil avec l'extension GNU activée).
• En règle générale, aucun portage n'est nécessaire pour le haut niveau de la pile DALI, qui est indépendant du matériel. Les seuls portages qui doivent être effectués sont les routines proches du matériel dans dali_ll_hal.c, qui doivent être mises à disposition du pilote de bas niveau en tant que callbacks.

+ DALI Multi-Master : Comment concevoir un système multi-maître ? Cela fait-il partie du standard DALI ?

Avec les paramètres correspondants, un système peut être configuré en tant que Control Device Multi-Master. Dès qu'un Multi-Master ou dès qu'un Input-Device (en principe également un Multi-Master) se trouve sur le bus, il ne doit pas y avoir de Single-Master - cela fait partie du standard DALI.