Modifications

Sauter à la navigation Sauter à la recherche
1 439 octets ajoutés ,  27 mars 2017 à 09:20
aucun résumé de modification
Ligne 1 : Ligne 1 :  
{{LOPY-NAV}}
 
{{LOPY-NAV}}
  −
{{traduction}}
      
== ESP32 et Modules Pycom ==
 
== ESP32 et Modules Pycom ==
Ligne 36 : Ligne 34 :     
== Boot Mode et Safe Boot ==
 
== Boot Mode et Safe Boot ==
If you power up normally, or press the reset button, the LoPy will boot into standard mode; the {{fname|boot.py}} file will be executed first, then {{fname|main.py}} will run.
+
Mode de démarrage et mode "sans échec"...
   −
You can override this boot sequence by pulling {{fname|P12}} (G28) '''up''' (connect it to the 3V3 output pin) during reset. This procedure also allows going back in time to old firmware versions. The LoPy can hold up to 3 different firmware versions, which are: the factory firmware plus 2 OTA images.
+
Si vous démarrer normalement votre carte, ou si vous pressez le bouton "Reset", le Lopy/WiPy2 démarre en mode standard; le fichier {{fname|boot.py}} sera exécuté en premier, ensuite le fichier {{fname|main.py}} sera exécuté.
   −
After reset, if {{fname|P12}} is held high, the heartbeat LED will start flashing slowly in orange color, if after 3 seconds the pin is still being held high, the LED will start blinking a bit faster and the LoPy will select the previous OTA image to boot. If the previous user update is the desired firmware image, {{fname|P12}} must be released before 3 more seconds elapse. If after 3 seconds later, the pin is still high the factory firmware will be selected, the LED will flash quickly for 1.5 seconds and the LoPy will proceed to boot. The firmware selection mechanism is as follows:
+
Il est possible de modifier la séquence de démarrage en plaçant la broche {{fname|P12}} (G28) '''au niveau haut''' (connectez la sur le broche 3V3) durant la phase de réinitialisation. Cette procédure permet également de revenir à une ancienne version du Firmware. Le LoPy/WiPy2 peut maintenir 3 versions différents du Firmware qui sont:
 +
* Le firmware d'usine
 +
* L'image précédente du Firmware
 +
* L'image actuelle du Firmware (celle exécutée au démarrage du WiPy2/Lopy)
   −
'''Safe Boot Pin {{fname|P12}} released during:'''
+
Après le "Reset", si la broche {{fname|P12}} est maintenue au niveau haut, '''la LED heartbeat commence à clignoter lentement en orange'''. Si la broche est toujours maintenue au niveau haut après 3 secondes Alors la LED commence à clignoter un peu plus rapidement et le LoPy/WiPy2 sélectionnera la précédente image pour booter. Si c'est cette image que vous voulez utiliser alors relâchez la broche {{fname|P12}} avant que 3 autres secondes ne s'écoulent. '''S'''i après ce nouveau délai de 3 secondes la broche P12 est toujours au niveau haut '''A'''lors c'est le firmware d'usine qui est sélectionné (la LED clignote rapidement pendant une seconde et demi puis le WiPy2/Lopy procède au démarrage).
* '''Les 3 premières secondes''' - Safe boot, ''latest'' firmware is selected
  −
* '''Les 3 secondes suivantes''' - Safe boot, '''previous''' user update selected
  −
* '''La dernière seconde et demi''' - Safe boot, the '''factory''' firmware is selected
     −
On all of the above 3 scenarios, safe boot mode is entered, meaning that the execution of both {{fname|boot.py}} and {{fname|main.py}} is skipped. This is useful to recover from crash situations caused by the user scripts. The selection made during safe boot is not persistent, therefore after the next normal reset the latest firmware will run again.
+
Le mécanisme de sélection du firmware est le suivant:
 +
 
 +
'''Broche "Safe Boot" {{fname|P12}} relâchée durant:'''
 +
* '''Les 3 premières secondes''' - Safe boot, ''dernier'' firmware sélectionné
 +
* '''Les 3 secondes suivantes''' - Safe boot, la mise-à-jour utilisateur '''précédente'''
 +
* '''La dernière seconde et demi''' - Safe boot, le firmware '''d'usine''' est sélectionné
 +
 
 +
Pour les trois scénarios ci-dessus, le mode "sans échec" (safe boot) est activé, ce qui signifie que l'exécution des deux fichiers {{fname|boot.py}} et {{fname|main.py}} sont suspendu. C'est pratique pour se sortie d'une situation bloquante/crash causée par un script utilisateur. La sélection faite durant le mode "Sans Echec" (safe boot) n'est pas persistant. Par conséquent, le dernier firmware est de nouveau exécuté après un redémarrage/Reset de la carte.
    
Il est possible de [[Hack-pycom-lopy-toolbox#R.C3.A9initialisation_du_syst.C3.A8me_de_fichier|reformater la mémoire flash interne]] si vous rencontrez des problèmes avec le système de fichier.
 
Il est possible de [[Hack-pycom-lopy-toolbox#R.C3.A9initialisation_du_syst.C3.A8me_de_fichier|reformater la mémoire flash interne]] si vous rencontrez des problèmes avec le système de fichier.
    
== Reset / Réinitialisation ==
 
== Reset / Réinitialisation ==
 +
La carte est équipé d'une méthode de réinitialisation matérielle (bouton "Reset") et réinitialisation logicielle (Soft Reset).
   −
There are soft resets and hard resets. A soft reset simply clears the state of the MicroPython virtual machine, but leaves hardware peripherals unaffected. To do a soft reset, simply press Ctrl+D on the REPL, or within a script do:
+
La réinitialisation logicielle efface tous les états de la machine virtuelle MicroPython MAIS laisse l'état matériel des périphériques non affecté. Pour faire une réinitialisation logicielle, pressez simplement la combinaison de touche Ctrl+D dans l'invite de commande REPL -OU- exécutez le code suivant:
    
  <nowiki>>>> import sys
 
  <nowiki>>>> import sys
 
>>> sys.exit()</nowiki>
 
>>> sys.exit()</nowiki>
   −
A hard reset is the same as performing a power cycle to the board. In order to hard reset the LoPy, press the switch on the board or:
+
Un reset matériel revient à faire un faire un cycle d'alimentation (débrancher/rebrancher) de la carte. Pour faire un Reset matériel sur le LoPy ou WiPy2, presser le bouton "Reset" de la carte ou saisissez le code suivant:
    
  <nowiki>>>> import machine
 
  <nowiki>>>> import machine
Ligne 72 : Ligne 78 :     
== Gestion des interruptions ==
 
== Gestion des interruptions ==
In Pycom’s ESP32 MicroPython port there are no restrictions on what you can do within an interrupt handler. For example, other ports don’t allow you to allocate memory inside the handler or use sockets.
+
Dans le portage MicroPython pour ESP32 de Pycom, il n'y a pas de restriction sur ce qui peut être réalisé dans une fonction d'interruption (dit "''interrupt handler''"). Par exemple, d'autres portages ne permettent pas l'utilisation d'un socket ou d'allouer de la mémoire dans la fonction d'interruption.
 +
 
 +
Ces limitations ont étés levées en gérant le mécanisme d'interruption de façon différente. Lorsqu'une interruption est déclenchée, un message est ajoutée dans une queue de traitement, ce qui notifie un thread qui, lui, appelle la fonction d'interruption (''callback handler'') adéquate. Une telle fonction d'interruption reçoit un argument. Par défaut c'est un objet associé avec un événement.
 +
 
 +
Le programmeur peut faire ce qu'il veut dans une fonction d'interruption, comme créer de nouvelles variables, ou même envoyer des paquets de donnée sur le réseau. Gardez juste à l'esprit que les interruptions sont traitées séquentiellement. Essayez donc de finir des fonctions d'interruption aussi courte et rapide que possible.
   −
These limitations were raised by handling the interrupt events differently. When an interrupt happens, a message is posted into a queue, notifying a separate thread that the appropriate callback handler should be called. Such handler would receive an argument. By default it is the object associated with the event.
+
Il y a actuellement deux classes supportant les mécanismes d'interruption, il s'agit de la classe [https://docs.pycom.io/pycom_esp32/library/machine.Timer.html#machine.Timer.Alarm|Alarm] cet de la classe [https://docs.pycom.io/pycom_esp32/library/machine.Pin.html#machine.Pin Pin] (pour les broches). Les deux classes offrent une méthode {{fname|.callback()}} qui active les interruptions et enregistre la fonction de rappel (''le fonction d'interruption'') à appeler lorsqu'il y a une interruption.
   −
The programmer can do whatever is needed inside the callback, such as creating new variables, or even sending network packets. Just keep in mind that interrupts are processed sequentially, so try to keep the handlers as quick as possible in order to attend them all in a short time.
+
{{ambox|text=Actuellement, le système d'interruption peut traiter une queue de traitement de 16 interruptions max.}}
   −
Currently there are 2 classes supporting interrupts, there the [https://docs.pycom.io/pycom_esp32/library/machine.Timer.html#machine.Timer.Alarm|Alarm] class and the [https://docs.pycom.io/pycom_esp32/library/machine.Pin.html#machine.Pin Pin]. Both classes provide the {{fname|.callback()}} method that enables the interrupt and registers the given handler. More details about the usage along with examples can be found in their respective sections.
+
== Tutoriels Pycom ==
 +
Vous trouverez tous les tutoriels PyCom sur cette page:
   −
{{ambox|text=Currently the interrupt system can queue up to 16 interrupts.}}
+
* [https://docs.pycom.io/pycom_esp32/pycom_esp32/tutorial/index.html Tutorials and examples] (''Pycom.io, anglais'')
    
{{LOPY-TRAILER}}
 
{{LOPY-TRAILER}}
29 917

modifications

Menu de navigation