The Finite State Machine for the SPI Driver.<\/figcaption><\/figure>\nDriver initialization<\/h4>\n
Looking at SPI finite state machine, we cannot call function spiStart()<\/em> on SPID1<\/em> if this driver is into the state SPI_UNINIT<\/em>.<\/p>\nEvery driver must be initialized and its state moved to XXX_STOP<\/em> (in our example SPI_STOP<\/em>): this operation is performed by a function named xxxInit() <\/em>(in our example spiInit<\/em>). There is an “init” function for every driver and they are called automatically by halInit()<\/em> if the driver switch is enabled<\/p>\n\/**\n * @brief HAL initialization.\n * @details This function invokes the low level initialization code then\n * initializes all the drivers enabled in the HAL. Finally the\n * board-specific initialization is performed by invoking\n * @p boardInit() (usually defined in @p board.c).\n *\n * @init\n *\/\nvoid halInit(void) {\n \/* Initializes the OS Abstraction Layer.*\/\n osalInit();\n \/* Platform low level initializations.*\/\n hal_lld_init();\n#if (HAL_USE_PAL == TRUE) || defined(__DOXYGEN__)\n palInit(&pal_default_config);\n#endif\n#if (HAL_USE_ADC == TRUE) || defined(__DOXYGEN__)\n adcInit();\n#endif\n#if (HAL_USE_CAN == TRUE) || defined(__DOXYGEN__)\n canInit();\n#endif\n#if (HAL_USE_DAC == TRUE) || defined(__DOXYGEN__)\n dacInit();\n#endif\n#if (HAL_USE_EXT == TRUE) || defined(__DOXYGEN__)\n extInit();\n#endif\n#if (HAL_USE_GPT == TRUE) || defined(__DOXYGEN__)\n gptInit();\n#endif\n#if (HAL_USE_I2C == TRUE) || defined(__DOXYGEN__)\n i2cInit();\n#endif\n#if (HAL_USE_I2S == TRUE) || defined(__DOXYGEN__)\n i2sInit();\n#endif\n#if (HAL_USE_ICU == TRUE) || defined(__DOXYGEN__)\n icuInit();\n#endif\n#if (HAL_USE_MAC == TRUE) || defined(__DOXYGEN__)\n macInit();\n#endif\n#if (HAL_USE_PWM == TRUE) || defined(__DOXYGEN__)\n pwmInit();\n#endif\n#if (HAL_USE_SERIAL == TRUE) || defined(__DOXYGEN__)\n sdInit();\n#endif\n#if (HAL_USE_SDC == TRUE) || defined(__DOXYGEN__)\n sdcInit();\n#endif\n#if (HAL_USE_SPI == TRUE) || defined(__DOXYGEN__)\n spiInit();\n#endif\n#if (HAL_USE_UART == TRUE) || defined(__DOXYGEN__)\n uartInit();\n#endif\n#if (HAL_USE_USB == TRUE) || defined(__DOXYGEN__)\n usbInit();\n#endif\n#if (HAL_USE_MMC_SPI == TRUE) || defined(__DOXYGEN__)\n mmcInit();\n#endif\n#if (HAL_USE_SERIAL_USB == TRUE) || defined(__DOXYGEN__)\n sduInit();\n#endif\n#if (HAL_USE_RTC == TRUE) || defined(__DOXYGEN__)\n rtcInit();\n#endif\n \/* Community driver overlay initialization.*\/\n#if defined(HAL_USE_COMMUNITY) || defined(__DOXYGEN__)\n#if (HAL_USE_COMMUNITY == TRUE) || defined(__DOXYGEN__)\n halCommunityInit();\n#endif\n#endif\n \/* Board specific initialization.*\/\n boardInit();\n\/*\n * The ST driver is a special case, it is only initialized if the OSAL is\n * configured to require it.\n *\/\n#if OSAL_ST_MODE != OSAL_ST_MODE_NONE\n stInit();\n#endif\n}<\/pre>\nIf a ChibiOS driver is enabled in the HAL configuration file, it is automatically initialized on HAL initialization. Initialization is related to variable initialization more than on hardware configuration.<\/span><\/p><\/blockquote>\nConfiguring a driver<\/h4>\n
Before to use it, the a driver shall be properly initialized and configured. This operation is carried out by another function: the start. The following code box reports some start function from different drivers.<\/p>\n
\/**\n * @brief Configures and starts the driver.\n *\n * @param[in] sdp pointer to a @p SerialDriver object\n * @param[in] config the architecture-dependent serial driver configuration.\n * If this parameter is set to @p NULL then a default\n * configuration is used.\n *\n * @api\n *\/\nvoid sdStart(SerialDriver *sdp, const SerialConfig *config) {\n ...\n}\n\n\n\n\/**\n * @brief Configures and activates the SPI peripheral.\n *\n * @param[in] spip pointer to the @p SPIDriver object\n * @param[in] config pointer to the @p SPIConfig object\n *\n * @api\n *\/\nvoid spiStart(SPIDriver *spip, const SPIConfig *config) {\n ...\n}\n\n\n\n\/**\n * @brief Configures and activates the ADC peripheral.\n *\n * @param[in] adcp pointer to the @p ADCDriver object\n * @param[in] config pointer to the @p ADCConfig object. Depending on\n * the implementation the value can be @p NULL.\n *\n * @api\n *\/\nvoid adcStart(ADCDriver *adcp, const ADCConfig *config) {\n ...\n}<\/pre>\nSuch functions shall be called at least once by the user application before the real usage. Their purpose is to configure the peripherals and this involves setup of all that hardware configurability.<\/p>\n
In ChibiOS\/HAL every driver except PAL shall be started before to be used.<\/p><\/blockquote>\n
The xxxStart<\/em> function receives two parameters which are a pointer to the serial driver object we want to start (e.g. &SD1, &SPI3, &PWM7 or whatever is the driver we are going to use) and a pointer to a structure which represent the related configuration. This structure contains all the dependencies which are strictly related to the underlying hardware. This means that moving from a STM32 family to another which has a different underlying hardware we most likely have to apply some changes to these configuration structures.<\/p>\nStarting a driver we need a pointer to it and a pointer to its configuration structure. This structure contains all the HW dependencies and has to been reviewed if we port our application on a different microcontroller.<\/p><\/blockquote>\n
The start function usually enables peripheral clock. In certain application (especially those addressed to low power) it is undesidered to keep a peripheral clocked when it is not used. Because of that there is another function we could use to stop the driver and stop the peripheral clock: the stop.<\/p>\n
\/**\n * @brief Stops the driver.\n * @details Any thread waiting on the driver's queues will be awakened with\n * the message @p MSG_RESET.\n *\n * @param[in] sdp pointer to a @p SerialDriver object\n *\n * @api\n *\/\nvoid sdStop(SerialDriver *sdp) {\n ...\n}\n\n\n\n\/**\n * @brief Deactivates the SPI peripheral.\n * @note Deactivating the peripheral also enforces a release of the slave\n * select line.\n *\n * @param[in] spip pointer to the @p SPIDriver object\n *\n * @api\n *\/\nvoid spiStop(SPIDriver *spip) {\n ...\n}\n\n\n\n\/**\n * @brief Deactivates the ADC peripheral.\n *\n * @param[in] adcp pointer to the @p ADCDriver object\n *\n * @api\n *\/\nvoid adcStop(ADCDriver *adcp) {\n ...\n}<\/pre>\nThis function can be called by the user application when the peripheral is unnecessary. It is almost intuitive that after a stop we need a new start to be able to use again the driver.<\/p>\n
Start Do Stop<\/h5>\n
A most common paradigm is the Start-Do-Stop:<\/strong><\/p>\n\n- we start the driver when needed configuring it.<\/li>\n
- we do some operations on that driver.<\/li>\n
- we stop it as soon as it has completed operations.<\/li>\n<\/ul>\n
\/* Starting Serial Driver 2 with my configuration. *\/\nsdStart(&SD2, &my_sd_configuration);\n\n\/* Doing some operation on Serial Driver 2. *\/\n\n\/* Stopping. *\/ \nsdStop(&SD2);\n\n...\n\n\/* Starting again. *\/ \nsdStart(&SD2, &my_sd_configuration);\n\n\/* Carrying out other operation. *\/\n\n\/* Stopping. *\/ \nsdStop(&SD2);\n<\/pre>\nThis offers advantage especially if peripheral is actually used in a small slice of the whole time amount of execution time.<\/p>\n
It is possible to stop a driver to reduce hardware power consumption when peripheral is used for a small percentage of execution time. After being stopped a the driver shall be re-started to be used again.<\/p><\/blockquote>\n
Changing configuration on the fly<\/h5>\n
An approach similar to Start-Do-Stop can be used is used when we need to change driver configuration on-the-fly. In such scenario we can start peripheral multiple time with different configuration. Note that stop is not required rather is discouraged as in case of subsequent start operation certain operation are skipped.<\/p>\n
\/* Starting Serial Driver 2 with my configuration. *\/\nsdStart(&SD2, &sd_cfg1);\n\n\/* Doing some operation on Serial Driver 2 with configuration 1. *\/\nsdDoStuff(&SD2, additional_params);\n\n\/* Starting again. *\/ \nsdStart(&SD2, &sd_cfg2);\n\n\/* Doing some operation on Serial Driver 2 with configuration 2. *\/\nsdDoStuff(&SD2, additional_params);\n<\/pre>\nIt is possible to start driver more than once with different configuration in case we need to change driver configuration on-the-fly.<\/p><\/blockquote>\n
The configuration structure is composed by two separated parts: the first part remains unchanged across all kind of hardware, the second is strictly hardware dependent. Dealing with configuration there are some hints that can help you to figure out how to correctly compose them:<\/p>\n
\n- Take a look to demos under the testhal <\/strong><\/em>folder and testex <\/strong><\/em>folders: in these demos you can find some precomposed configuration that you can copy and use in your application. As the configuration depends on hardware be sure to pick a demo for the subfamily you are currently using.<\/li>\n
- You can take a look to the definition of configuration structure following the breadcrumbs: first you need to detect which LLD your platform is using through the platform.mk<\/em> file, then you have to open the related low level driver header where you can find the configuration structure definition.<\/li>\n
- Those fields which are related to hardware are described in the reference manual, use it to spot the meaning of each bit.<\/li>\n
- Remember that the start function usually does some internal obvious modification to register values passed through the configuration.<\/li>\n
- There are some simple techniques to change certain bit of the register leaving others unchanged. Such operation takes the name of bit-masking<\/strong> and the adopted paradigm to deal with registers read-modify-write<\/strong>. This is a knowledge you really should do have. If don’t I highly suggest to read this article<\/a> (even at later moment).<\/li>\n
- You do not have to define register bitmasks as they are already defined and available in CMSIS<\/strong> header files. You can find these files under the folder chibios182\\os\\common\\ext\\ST.<\/em><\/li>\n<\/ul>\n\n","protected":false},"excerpt":{"rendered":"
The ChibiOS Hardware Abstraction Layer The C programming language is clearly an imperative programming language not designed to be object-oriented. Anyway, the object-oriented approach remains something much more related to the design and mindset more than to syntax. The ChibiOS\/HAL is an Hardware Abstraction Layer which design could be considered very object-oriented. We encountered it in almost every article […]<\/p>\n","protected":false},"author":3,"featured_media":6068,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1221],"tags":[],"coauthors":[241],"class_list":["post-2181","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-further-readings","pumpkin"],"views":21819,"jetpack_featured_media_url":"https:\/\/playembedded.org\/blog\/wp-content\/uploads\/2015\/07\/Object-Oriented.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/posts\/2181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/comments?post=2181"}],"version-history":[{"count":0,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/posts\/2181\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/media\/6068"}],"wp:attachment":[{"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/media?parent=2181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/categories?post=2181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/tags?post=2181"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/playembedded.org\/blog\/wp-json\/wp\/v2\/coauthors?post=2181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/playembedded.org\/wp-content\/uploads\/2015\/07\/HAL-organization.png\")
<\/a>