PulseGenerator : Liaison SPI
De Wiki_du_Réseau_des_Electroniciens_du_CNRS
Aller à la navigationAller à la recherche
Présentation du bus SPI
Comme vous aurez pu le lire sur les sites précédents, il existe différentes conventions de nommage. Microchip utilise les termes SDI/SDO, dont le signal SDO du maître doit-être relié au SDI de l'esclave et vice versa. Pour éviter les confusions au moment du câblage des cartes entre elles, il est donc recommandé d'utiliser les dénominations MISO/MOSI qui évitera une certaine ambiguïté en fonction de point de vu que l'on choisi.
Les 2 cartes microcontrôleur et CPLD, seront reliées ensemble via leur connecteur Pmod. La communication SPI sera réalisée sur le mode 00 et la vitesse max de communication pourra être définit à 10 MHz. Le format de données pourra être de 32 bits, soit 4 octets, encadrés par le signal Slave Select (SS).
|
Les différents modes SPI Cette figure montre les 4 configurations possibles pour une communication SPI, maître et esclave devant avoir les mêmes paramètres. On parle alors du mode 0 au mode 3, en modifiant les paramètres CPOL et CPHA (ou mode 00 à 11).
|
 |
Exemple de mise en oeuvre d'une communication SPI
Afin d'implémenter la communication entre la carte microcontrôleur et la carte CPLD, nous allons dans un premier temps réaliser une mise en oeuvre simple du SPI sur chacune des cartes. Nous prendrons pour exemple l'échange d'une donnée au format d'un octet. En effet à ce stade de la mise en oeuvre, il faut avoir à l'esprit que dans la plupart des cas c'est le périphérique esclave qui va imposer au maître le format de la trame, car il s'agit pour le MCU de piloter un composant externe afin d'étendre ces capacités. Il existe donc de nombreux périphériques esclave intégrant une liaison SPI, comme des mémoires, des expandeurs d'entrée/sortie, des ADC ou DAC, des RTC, etc... Le développeur se doit donc d'étudier la documentation technique du dit esclave, afin de configurer sont MCU de manière à pouvoir le faire fonctionner correctement en fonction du mode SPI et du format des trames.
Imaginons alors d’implémenter le firmware d'un périphérique SPI esclave sur la carte CPLD. Le mode 0 étant le plus répandu, nous le choisirons avec une trame de 1 octet. Chaque octet qu'il recevra du maître sera alors copier vers 8 LED et comme la liaison est Full duplexe, nous pouvons imaginer de définir 8 entrées dont les valeurs seront transmise par l'esclave.
Comment se déroule alors la communication ?
Pour commencer, observons le chronogramme des signaux de la liaisons SPI, avec en rouge l’échantillonnage des données sur les fronts montant du signal SCLK et en orange l'état transitoire des données sur les fronts descendants:
On peut décomposer la communication en trois phases:
- Début de la communication
Le maître du bus SPI, ici la carte PIC, met le signal SS à 0 de façon à indiquer à l'esclave que la communication commence (Slave Select est actif à l'état bas). Ce signal SS est très important et souvent négligé dans l'implémentation des algorithmes.- Coté microcontrôleur en mode maître SPI, il ne fait pas partie du module interne (uniquement dans le mode esclave) et doit-être définit par le développeur qui devra alors réserver autant de ligne SS qu'il y aura d'esclave avec lesquels communiquer.
- Coté CPLD la détection du front descendant de ce signal va permettre d'initialiser les signaux et registres internes avant le premier coup d'horloge, le bit 7 doit alors imposer sont état sur la ligne MISO.
- Acquisition et transfert des bits
Le maître fera ensuite basculé huit fois le signal d'horloge.- Sur les fronts montants, l'esclave enregistre les données provenant du signal MOSI et le maître mémorise sur la ligne MISO la valeur de chaque bit provenant de l'esclave, c'est le Full duplexe.
- Les données sur les lignes MOSI/MISO sont ensuite mise à jour sur les fronts descendants du signal SCLK.
- Fin de la communication
- Le maître tire la ligne SS à l'état haut pour indiquer que le transfert est terminé.
Sur la carte chipKIT™ Pro MX7 (CEREBOT™ MX7cK)
Documentation sur le SVN: ..\Groupe_PIC\PIC32_Datasheet\ PIC32_Family_Sect_23_DS61106G_Serial_Peripheral_Interface.pdf
Parmis les différents modes de fonctionnement des modules SPI des PIC32, ceux-ci permettent les fonctionnements suivants:
- mode maître ou esclave
- mode 8 bits, 16 bits ou 32 bits, en transmission/réception de données
La carte chipKIT™ Pro MX7 supporte 3 ports de modules SPI. Ceux-ci sont accessibles à l'aide des connecteurs Pmod JD, JE, et JF.
Voir sur le SVN: ..\Groupe_PIC\PIC32_Hardware\Chipkit_Pro_MX7\ ChipKIT_MX7_rm.pdf → "Serial Peripheral Interface (SPI)", Page 18 of 38
Les tableaux suivants donnent la correspondance entre les signaux SPI et les broches des connecteurs Pmod:
Module SPI1 du PIC32 sur le connecteur Pmod JD, nous choisirons celui-ci pour notre démo ;-)
| Signaux SPI | PIC32 Signal Name | Connecteur Pmod |
|---|---|---|
| SS | SS1/IC2/RD9 | JD-01 |
| MOSI | SDO1/OC1/INT0/RD0 | JD-02 |
| MISO | T5CK/SDI1/RC4 | JD-03 |
| SCLK | SCK1/IC3/PMCS2/PMA15/RD10 | JD-04 |
Module SPI3 du PIC32 sur le connecteur Pmod JE
Attention, l'UART1 est connecté au FTDI des cartes chipKIT Max32 et chipKIT Pro MX7 pour la communication série avec le PC, soit
- U1ARX/RF2 on FTDI TXD pin
- U1ATX/RF8 on FTDI RXD pin
| Signaux SPI | PIC32 Signal Name | Connecteur Pmod |
|---|---|---|
| SS | AETXD0/SS1A/U1BRX/U1ACTS/CN20/RD14 | JE-01 |
| MOSI | SCL1A/SDO1A/U1ATX/RF8 | JE-02 |
| MISO | SDA1A/SDI1A/U1ARX/RF2 | JE-03 |
| SCLK | AETXD1/SCK1A/U1BTX/U1ARTS/CN21/RD15 | JE-04 |
Module SPI4 du PIC32 sur le connecteur Pmod JF
| Signaux SPI | PIC32 Signal Name | Connecteur Pmod |
|---|---|---|
| SS | AC1RX/SS3A/U3BRX/U3ACTS/RF12 | JF-01 |
| MOSI | SCL3A/SDO3A/U3ATX/PMA8/CN18/RF5 | JF-02 |
| MISO | SDA3A/SDI3A/U3ARX/PMA9/CN17/RF4 | JF-03 |
| SCLK | AC1TX/SCK3A/U3BTX/U3ARTS/RF13 | JF-04 |
Code exemple - SPI maître 8 bits, mode 0
voir ..\Groupe_PIC\PIC32_Tutoriel\SPI\Firmware_v03_Librairie\_main_SPI_Librairie_v01r00.c
void main(void)
{
/** Configure SYSTEM */
SYSTEMConfig(SYS_FREQ, SYS_CFG_WAIT_STATES | SYS_CFG_PCACHE);
mJTAGPortEnable(DEBUG_JTAGPORT_OFF); // Disable JTAG port, free up PORTA
/** Initialisation du module UART */
Init_UART1();
/** Enable multi-vector interrupts */
INTEnableSystemMultiVectoredInt();
/** Initialize the SPI peripheral
* This function opens the SPI channel: turns the channel on and initializes it according to the oFlags input parameter.
* After that the channel is enabled. It also sets the brg register. The SPI bitrate is given by: bitrate=srcClk/(2*(SPIBRG+1))
* The input parametes srcClkDiv specifies the srcClk divisor term (2*(SPIBRG+1)), so the BRG is calculated as SPIBRG=srcClkDiv/2-1.
*
* CKP (clock polarity control) = 0
* CKE (clock edge control) = 0
* 8-bit, Master Mode
* Baud = 1 MHz (with SYS_FREQ: 80e6 et FPBDIV: DIV_4) --> Configuration de la vitesse du signal SCLK du SPI avec srcClk = 20 MHz
*
* void SpiChnOpen(SpiChannel chn, SpiOpenFlags oFlags, unsigned int srcClkDiv)
* . chn: a valid SPI channel number
* . oFlags: C:\Program Files (x86)\Microchip\xc32\v1.31\docs\pic32-lib-help\Microchip PIC32MX Peripheral Library.chm
* SPI > SPI Types > SpiOpenFlags Enumeration
* . srcClkDiv: valid value between 2 and 1024
* Source Clock divisor to extract the bitrate=srcClk/srcClkDiv
*/
SpiChnOpen( SPI_CHANNEL1, SPI_OPEN_MSTEN | SPI_OPEN_MODE8 | SPI_OPEN_CKE_REV | SPI_OPEN_ON, 20 ); // bitrate = 1 MHz
SS_IO = 1; // release chip on startup
SS_TRIS = 0; // make SS pin output
/** Boucle principale du programme */
while (1)
{
if(UART_Received_Flag)
{
UART_Received_Flag = FALSE;
SS_IO = 0; // select chip
SpiChnPutC(SPI_CHANNEL1, UART_Received); // send 8 bits data received from UART
SPI_Received = SpiChnGetC(SPI_CHANNEL1); // read 8 bits data from SPI_CHANNEL1 shift register
SS_IO = 1; // release chip
PutCharacter_UART1(SPI_Received); // Echo what we just received on SPI
}
}
}
Code exemple - SPI maître 32 bits, mode 0
Voici les modifications à faire dans le programme C pour passer la liaison SPI à 32 bits :
void main(void)
{
...
/** Initialize the SPI peripheral at 32-bit in Master Mode */
SpiChnOpen( SPI_CHANNEL1, SPI_OPEN_MSTEN | SPI_OPEN_MODE32 | SPI_OPEN_CKE_REV | SPI_OPEN_ON, 20 ); // bitrate = 1 MHz
...
/** Boucle principale du programme */
...
SS_IO = 0; // select chip
SpiChnPutC(SPI_CHANNEL1, 0xFF00FF00); // send 32 bits data like 4 byte: 0xFF + 0x00 + 0xFF + 0x00
SPI_Received = SpiChnGetC(SPI_CHANNEL1); // read 32 bits data from SPI_CHANNEL1 shift register
SS_IO = 1; // release chip
...
}
Protocole de communication SPI MCU/CPLD
Nous allons pour l'instant faire des propositions permettant d'établir le protocole de communication entre le microcontrôleur et la carte CPLD. En effet, une liaison SPI permet simplement d'interconnecter des composants sous la forme de couple maître/esclave et la signification des trames est généralement imposée par le fonctionnement de l'esclave, le maître pilotant ce dernier en respectant la datasheet fournis par le constructeur.
Dans notre cas, c'est nous qui créons le device et ces fonctionnalités, donc nous devons imaginer comment se fera le dialogue sur la liaison SPI, largeur d'un paquet SPI, signification, vérification des données, etc...
Les propositions du groupe
- pour la communication SPI, la largeur d'un paquet dans une trame est choisi à 8 bits, cela permet notamment d’optimiser les échanges entre le maître et l'esclave car l'architecture interne que nous allons créer dans le CPLD pourra aussi bien avoir des registres de 8 bits que de 32 bits, ce sera alors à la machine à états de faire l'union de 4 paquets (soit 4x 1 octet) pour obtenir une valeur sur 32 bits et ainsi configurer par exemple les registres internes de comptage pour la génération des impulsions DELAY et PULSE.
- la première valeur transmise (1er paquet de 8 bits dans une trame), pourrait-être désigné comme étant le paquet Start Of Frame (SOF)
- SOF → correspond à une adresse d'un registre interne du CPLD (adresse sur 8 bits, mais les registres internes peuvent être sur 8 ou 32 bits)
- échange entre le maître est l'esclave :
- → MOSI: ADDRESS ... (1x 8 bits)
- ← MISO: STATUS .... (1x 8 bits)
- Dans un premier temps seule l'écriture sera implémenter, mais nous pouvons anticiper la lecture des registres internes en réservant une adresse de lecture pour chaque registre, pour cela nous proposons que lorsque le bit de poids faible sera à 0 l'accès au registre se fera en mode WRITE, alors que lorsque il sera à 1 l'accès au registre sera en mode READ.
- Le nombre d'octet que l'esclave recevra après le SOF dépendra du type du registre interne désigner par la valeur de l'adresse, dans le mode READ les données transmises par le maître seront de n octets ayant la valeur 0xFF (READ), afin de lire en retour sur MISO le contenu du registre interne du CPLD.
- la dernière valeur transmise sera désigné comme étant le paquet End Of Frame (EOF) de la trame
- EOF → correspondra à l'envoie de 0xFF, valeur READ
- échange entre le maître est l'esclave :
- → MOSI: READ ............................................... (1x 8 bits)
- ← MISO: lecture du dernier octet transmis par le maître .... (1x 8 bits)
- une trame ne peut-être qu'en accès lecture ou écriture et pour un seule registre, il n'est donc pas possible de configurer plusieurs registres dans une même trame
- par convention les bits de poids forts seront transmis en premier sur la trame (most significant bit (MSB) first and least significant bit (LSB) in last)
- Exemple de trame pour l'écriture d'un registre interne de 8 bits (trame contenant 3 paquets de 8 bits) :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::.......
- ..............__...............................................__
- signal SS : ...\_____________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\___VALUE___/..\____READ___/
- ..............____.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\___VALUE___/
- Exemple de trame pour la lecture d'un registre interne de 8 bits (trame contenant 3 paquets de 8 bits) :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::.......
- ..............__...............................................__
- signal SS : ...\_____________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\____READ___/..\____READ___/
- ..............____.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\___VALUE___/
- Exemple de trame pour l'écritures d'un registre interne de 32 bits (trame contenant 6 paquets de 8 bits) :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::........:: 4 ::........:: 5 ::........:: 6 ::.......
- ..............__............................................................................................__
- signal SS : ...\__________________________________________________________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.. DATA 2 ...__.. DATA 3 ...__.. DATA 4 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/..\____READ___/
- ..............____.............__.............__.............__.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/
- Exemple de trame pour la lecture d'un registre interne de 32 bits (trame contenant 6 paquets de 8 bits) :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::........:: 4 ::........:: 5 ::........:: 6 ::.......
- ..............__............................................................................................__
- signal SS : ...\__________________________________________________________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.. DATA 2 ...__.. DATA 3 ...__.. DATA 4 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\____READ___/..\____READ___/..\____READ___/..\____READ___/..\____READ___/
- ..............____.............__.............__.............__.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/
- Gestion des erreurs
- → Comme vous l'aurez remarqué une trame sera composé soit de 3 ou 6 octets.
- → L'esclave retourne au maître chaque octet qu'il reçoit, il appartient donc au maître de vérifier la correspondance entre la valeur émise et la valeur retourné.
- → Lors de l'échange du premier paquet, l'esclave retourne systématiquement la valeur du registre Status. Le maître peut alors vérifier si le CPLD à bien interpréter la dernière commande envoyé ou si il ne se trouve pas dans un état d'erreur que nous pourrons définir au cours du développent du code du CPLD. Donc si le maître voit un flag d'erreur à 1 dans le registre Status, il doit tout d'abord effacer le flag par une écriture dans le registre Status. Pour cela, puisque l'erreur a eu lieu lors de l'envoie de la trame précédente et que ce registre est lu lors de l'envoie d'une nouvelle trame, le maître doit interrompre l'envoie de la trame en cours pour d'abord effacer l'erreur puis après avoir éventuellement retransmis la trame défectueuse, emmètre dans un second temps la trame qu'il avait du interrompre.
- Trame A, N-1: exemple d'une trame d'écritures d'un registre interne de 32 bits avec une erreur dans le paquet EOF
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::........:: 4 ::........:: 5 ::........:: 6 ::.......
- ..............__............................................................................................__
- signal SS : ...\__________________________________________________________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.. DATA 2 ...__.. DATA 3 ...__.. DATA 4 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/..\____0xAA___/
- ..............____.............__.............__.............__.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/
- → pourrait par exemple positionner un flag ERR_EOF à 1 dans le registre Status...
- Trame B, N: exemple d'une nouvelle écritures d'un registre interne de 32 bits, mais le maître détecte une erreur à la lecture du registre Status (du à la trame A, N-1) et décide d'interrompre cette trame
- n° du paquet: .......:: 1 ::.......
- ..............__.................__
- signal SS : ...\_______________/
- ..............____.... SOF ....____
- signal MOSI: .....\__ADDRESS__/
- ..............____.............____
- signal MISO: .....\__STATUS___/
- → détection d'une erreur dans le registre Status et arrêt prématuré de la trame B
- Trame N+1: ré-émission de la trame A pour l'écritures d'un registre interne de 32 bits (cette fois sans erreur lors de l'emission) :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::........:: 4 ::........:: 5 ::........:: 6 ::.......
- ..............__............................................................................................__
- signal SS : ...\__________________________________________________________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.. DATA 2 ...__.. DATA 3 ...__.. DATA 4 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/..\____READ___/
- ..............____.............__.............__.............__.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/
- Trame N+2: enfin l'émission de la trame B pour l'écritures d'un registre interne de 32 bits :
- n° du paquet: .......:: 1 ::........:: 2 ::........:: 3 ::........:: 4 ::........:: 5 ::........:: 6 ::.......
- ..............__............................................................................................__
- signal SS : ...\__________________________________________________________________________________________/
- ..............____.... SOF ....__.. DATA 1 ...__.. DATA 2 ...__.. DATA 3 ...__.. DATA 4 ...__.... EOF ....____
- signal MOSI: .....\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/..\____READ___/
- ..............____.............__.............__.............__.............__.............__.............____
- signal MISO: .....\__STATUS___/..\__ADDRESS__/..\_MSB VALUE_/..\___VALUE___/..\___VALUE___/..\_LSB VALUE_/
- Proposition d'adressage des registres internes du CPLD pour le projet Pulse Generator, permettant la configuration des différents timing, le fonctionnement des Trigger et la lecture de l'état du système. Comme pour le bus I2C, nous proposons que dans le premier octet transmis, les 8 bits correspondes à une adresse sur 7 bits d'un registre interne, + le bit de poids faible désignant le type d'accès à celui-ci (READ/WRITE), soit 0bxxxx xxx R/W :
| Adresse mémoire CPLD | Accès | Nom du registre | Description du registre d’interfaçage mémoire |
|---|---|---|---|
| 0x00 | Write | Status | Permet d'écrire dans le registre "Status" pour par exemple ré-initialiser les valeurs des flags internes |
| 0x01 | Read | Status | Permet de lire l'état des entrées/sorties et les valeurs des flags internes |
| 0x02 | Write | Trigger | Configuration des signaux de déclenchement pour les différentes voies |
| 0x03 | Read | Trigger | Lecture de la configuration des signaux de déclenchement pour les différentes voies |
| 0x04 | Write | Delay_01 | Configuration du temps de retard du pulse de la voie 1 |
| 0x05 | Read | Delay_01 | Lecture de la configuration du temps de retard de la voie 1 |
| 0x06 | Write | Pulse_01 | Configuration du temps d'impulsion du pulse de la voie 1 |
| 0x07 | Read | Pulse_01 | Lecture de la configuration du temps d'impulsion du pulse de la voie 1 |
| 0x08 | Write | Delay_02 | Configuration du temps de retard du pulse de la voie 2 |
| 0x09 | Read | Delay_02 | Lecture de la configuration du temps de retard de la voie 2 |
| 0x0A | Write | Pulse_02 | Configuration du temps d'impulsion du pulse de la voie 2 |
| 0x0B | Read | Pulse_02 | Lecture de la configuration du temps d'impulsion du pulse de la voie 2 |
| 0x0C | Write | ... | Configuration |
| 0x0D | Read | ... | Lecture |
- Autres Propositions ?
Vous pouvez rédiger vos propositions sur cette page, ou-bien nous les envoyer sur la liste de diffusion du projet ;-)
Description des registres internes du CPLD
Légende
- R: accès en lecture (Readable bit)
- W: accès en écriture (Writable bit)
- U: non implémenté (Unimplemented bit)
- 1 ou 0 = valeur au démarrage ou au reset de la carte (bit: Enable or Disable)
Registre Status
Il est possible de réserver un bit ou une plage de bits pour créer des indicateurs permettant de connaitre l'état du système et son bon fonctionnement...
- Nous pouvons proposer un bit "Power On Reset" (POR), qui sera forcément à 1 lors de la mise sous tension. Ce bit (comme tout les autres d’ailleurs) devra être remis à zéro dès le début de la communication avec la carte CPLD. L’intérêt de bit POR est que si pour une raison ou une autre la carte CPLD fait un reset du à un problème de tension pendant le fonctionnement de la carte, le maître pourra alors s'en rendre compte soit lors d'un accès à un registre, soit lorsqu'il fait une lecture du registre Status.
- erreur dans le paquet SOF, si l'adresse transmise ne fait pas partie des adresses mémoires du PULSE GENERATOR, le bit ERR_SOF est mise à 1
- erreur dans le paquet EOF, celui-ci doit toujours être égale à 0xFF, dans le cas contraire (exemple de non respect du format des trames) la carte CPLD positionne à 1 sont bit ERR_EOF
- 3 ou 4 bits pourrait être réserver pour placer un n° de version du firmware de la carte CPLD, si le nombre de bits libres est suffisant
| Bit | Type | Name | Description |
|---|---|---|---|
| 0 | R/W | bit_0 | POR |
| 1 | R/W | bit_1 | ERR_SOF |
| 2 | R/W | bit_2 | ERR_EOF |
| 3 | U | bit_3 | none |
| 4 | U | bit_4 | none |
| 5 | U | bit_5 | none |
| 6 | U | bit_6 | none |
| 7 | U | bit_7 | none |
Registre Trigger
Le nombre de Trigger dépendra du nombre de voies que l'on pourra implémenter sur la carte CoolRunner, pour l'instant sur cette version de proto, il est proposé qu'à une sortie soit associé un Trigger.
- Si celui-ci est désactivé alors la sortie ne pourra jamais être déclenché
- Nous proposons de pouvoir choisir le niveau de déclenchement sur front montant ou front descendant de l'entrée Trigger de chaqu'une des voies
- Un 3 ème bit de contrôle est proposé par LD afin de rajouter une fonction d'armement du Trigger pour la sécurité, d'un point de vu algorithme l'impacte est minime et cela permet de sécurisé le déclenchement de la sortie impulsion. Comme il s'agit d'une entrée supplémentaire associé à la détection de l'entrée Trigger associé, le bit doit permettre simplement de choisir si cette entrée est active ou pas. Si cette entrée est active alors celle-ci doit-être maintenue à l'état haut pour que l'entrée Trigger soit prise en compte. Nous pourrions également rajouter un bit de configuration pour savoir si l'état "Armement" de ce signal doit se faire sur un état haut ou un état bas (niveau TTL 0-5V), merci de donner votre avis...
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
