Mydin-classes-diagram

De MCHobby - Wiki
Sauter à la navigation Sauter à la recherche
Page-under-construction.pngPage(s) en cours de traduction/élaboration.

Page(s) under translation/construction

About this section

Before reading the classes documentation, it may be opportune to understand how the MyDin core is designed.

That will help to understand how the code works and where are located the key items when programming your MyDin project with MicroPython.

Class diagram

 

Here a short description of the main classes and their responsibilities:

  • DinControler : Base class responsible for starting the asynchronous execution. It puts every mechanism in place to initiate the setup then start asynchronous tasks including the user_loop task. A this level, the DinCOntroler doesn't know anything about the underlaying microcontroler used. DinControler also takes care of the process termination.
  • PicoControler : Base class for myDin solution based on Raspberry-Pi Pico microcontroler. PicoControler inherits of DinControler (and all its behavior). At the PicoContoler level, we can create object related to microcontroler hardware that will be shared accross all the descendant classes. At the PicoControler level we can define the common I2C bus, RTC clock, internal temperature sensor, watchdog and e.
  • Pico3Mod : Specialized implementation of the PicoControler for a 3 modules size DIN. As the microcontroler is now placed on a PCB with fixed dimensions and obvious placement constraints (due to the 3 modules Din) then the specific hardware design like buttons, LEDs, interface connectors can be defined by this class. This class also defines the interface between the controler and the 3 modules backplane.
  • Pico6Mod : Another specialized implementation of the PicoControler for a 6 modules size DIN. Thanks to additional place available, it is also possible to add a LCD/OLED display, mini-joystick aside the usual interface.
  • TwoRelay3Mod is a specialized Backplane implementation for a 3 modules DIN. Backplane 3 modules shares a common interface with the 3 modules Controler (Pico3Mod and any 3 modules Controler will use exactly the same interface).
Backplane class must implements the attach( controler ) method.
The attach( controler ) method is called by configure() to expose the backplane properties into the controler object.

DinControler

Header

  • Ancestor{{{2}}}
    None
  • Class{{{2}}}
    DinControler
  • Module{{{2}}}
    controler
  • DIN Size{{{2}}}
    Any modules
  • Descr{{{2}}}
    Base class responsible for starting the asynchronous execution. It puts every mechanism in place to initiate the setup then start asynchronous tasks including the userloop task. A this level, the DinControler doesn't know anything about the underlaying microcontroler used. DinControler also takes care of the process termination.

Details about DinControler class are available at "asynchronous tasks" details. Here is the process behind the run() method.

 

Attributes

backplane : object

Reference to the backplane instance created by the configure() function. The backplane is an instance of type BackplaneClass.

is_async : boolean

True when the DinControler is running asyncio code otherwise, the DinControler is running "procedural" code.

This property is set to True by the run() method.

loop_exception : object

If an exception is raised by the userloop during asynchronous execution then the run() exits and loop_exception contains a reference to the catched exception.

When the userloop exits for another reason (eg: APP_RUN=STOP) then the loop_exception should still be None.

Remark: loop_exception is set to None when run() starts.

loop_time_ms : int

xxx

Methods

xx