Oresat-notes

^ Oresat type driver object

Putting together an Oresat device driver type object, realized in C, starting with devp:

112 void tmp101Start(TMP101Driver *devp, const TMP101Config *config) {

Object devp is a pointer to an object/data structure of type TMP101Driver. TMP101Driver and TMP101config are defined as:

1	2
/** * @brief TMP101AN temperature sensor class. */ struct TMP101Driver { /** @brief Virtual Methods Table.*/ const struct TMP101VMT *vmt; _tmp101_data };	/** * @brief TMP101 configuration structure. */ typedef struct { #if (TMP101_USE_I2C) || defined(__DOXYGEN__) /** * @brief I2C driver associated with this TMP101. */ I2CDriver *i2cp; /** * @brief I2C configuration associated with this TMP101. */ const I2CConfig *i2ccfg; /** * @brief TMP101 Slave Address */ i2caddr_t saddr; #endif /* TMP101_USE_I2C */ } TMP101Config;

For first steps work we really only need the I2C related structures and pointers. If we are to use TMP101Config for this we must understand how this data structure is configured at start up. There is a place where devp->config is assigned a value, a value which is passed by reference to the void routine tmp101Start(). Looking at who calls this routine, we must return to the driver code in ina226.c because nothing yet calls the just started TMP101AN driver code. Source file solar.c calls this routine:

  215     ina226Start(&ina226dev, &ina226config);

And ina226Config is initialized this way:

static const INA226Config ina226config = {
    &I2CD2, 
    &i2cconfig,
    INA226_SADDR,
    INA226_CONFIG_MODE_SHUNT_VBUS | INA226_CONFIG_MODE_CONT |
    INA226_CONFIG_VSHCT_140US | INA226_CONFIG_VBUSCT_140US |
    INA226_CONFIG_AVG_16,
    (5120000/(RSENSE*CURR_LSB)),
    CURR_LSB
};

For our first step purposes we really only need the first three data members of this data structure: an I2C device reference, and I2C configuration structure, and the I2C address of a given TMP101AN sensor. Those two sensors are wired with addresses 0x48 and 0x4A on the solar board. So we'll simplify the TMP101Config type in tmp101an.h, which right now is in the solar sources directory.

^ Notes to sort

Note) Looks like a command shell is realized in code near end of file:

   psas/oresat-firmware/src/f4/app_control/source/command.c

Note) ina226.c and other device type driver source files in 'psas/oresat-firmware/common' give examples of I2C calls in ChibiOS environment.

INA226_SHARED_I2C

References:

  *  https://www.playembedded.org/blog/stm32-i2c-chibios/

Note)  Example file which calls an I2C init function among other things, in routine app_init():

 oresat-firmware/src$ vi ./archive/f0/app_solardemo/main.c

   /*
 * I2C configuration
 */
static const I2CConfig i2cfg1 =
{
    I2C_100KHZ_TIMINGR,
    0,
    0,
};

uint8_t data[8];

static void app_init(void) {
    //=== App initialization

    // Start up debug output
    sdStart(&SD2, &ser_cfg);

    i2cInit();
    i2cStart(&I2CD1, &i2cfg1);

    for (uint8_t i = 0; i < 8; ++i) {
        data[i] = 0;
    }

    canTPDOObjectInit(CAN_PDO_1, CAN_ID_DEFAULT, 0, 0, 8, data);
}

Note)  pointer *devp is of type INA226Driver, where is this defined?

   185 /**
   186  * @brief   Sets INA226 Alert type and value
   187  *
   188  * @param[in] devp       pointer to the @p INA226Driver object
   189  * @param[in] alert_me   the value to write to Mask/Enable register (0 to disable)
   190  * @param[in] alert_lim  the value to write to Alert Limit register
   191  *
   192  * @api
   193  */
   194 void ina226SetAlert(INA226Driver *devp, uint16_t alert_me, uint16_t alert_lim) {
   195     i2cbuf_t buf;
   196 
   197     osalDbgCheck(devp != NULL);
   198     osalDbgAssert(devp->state == INA226_READY,
   199             "ina226SetAlert(), invalid state");

Note) Device states for INA226 enumerated as follows:

:~/projects/psas/oresat-firmware/common/include$ grep -nr -A 2 -B 2 INA226_STOP ./*
./ina226.h-277-typedef enum {
./ina226.h-278-    INA226_UNINIT = 0,                  /**< Not initialized.                 */
./ina226.h:279:    INA226_STOP = 1,                    /**< Stopped.                         */
./ina226.h-280-    INA226_READY = 2,                   /**< Ready.                           */
./ina226.h-281-} ina226_state_t;

^ Virtual Methods Table VMT

So there's this idea and reference to virtual methods table data structures in ina226.h and .c. In ina226.h *vmt</vmt> is defined as being:

    326 /**
    327  * @extends BaseObjectVMT
    328  *
    329  * @brief   @p INA226 virtual methods table.
    330  */
    331 struct INA226VMT {
    332     _ina226_methods
    333 };
  .
  .
  .
    345 /**
    346  * @brief INA226 Power Monitor class.
    347  */
    348 struct INA226Driver {
    349     /** @brief Virtual Methods Table.*/
    350     const struct INA226VMT     *vmt;
    351     _ina226_data
    352 };

In file oresat-firmware/ext/ChibiOS/os/hal/include/hal_objects.h:

     39 #define _base_object_methods                                                \^M
     40   /* Instance offset, used for multiple inheritance, normally zero. It^M
     41      represents the offset between the current object and the container^M
     42      object*/                                                               \^M
     43   size_t instance_offset;^M
     44 ^M

     45 /**^M
     46  * @brief   @p BaseObject specific data.^M
     47  * @note    This object defines no data.^M
     48  */^M
     49 #define _base_object_data^M
     50 ^M
     51 /**^M
     52  * @brief   @p BaseObject virtual methods table.^M
     53  */^M
     54 struct BaseObjectVMT {^M
     55   _base_object_methods^M
     56 };^M
     57 ^M
     58 /**^M
     59  * @brief   Base stream class.^M
     60  * @details This class represents a generic blocking unbuffered sequential^M
     61  *          data stream.^M
     62  */^M
     63 typedef struct {^M
     64   /** @brief Virtual Methods Table.*/^M
     65   const struct BaseObjectVMT *vmt;^M
     66   _base_object_data^M
     67 } BaseObject;^M