You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/12/10 06:52:00 UTC
[12/13] incubator-mynewt-site git commit: Added driver overview.
Updated HAL to current design. Included PR #131.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/294de97a/develop/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/develop/mkdocs/search_index.json b/develop/mkdocs/search_index.json
index ea82980..9cada04 100644
--- a/develop/mkdocs/search_index.json
+++ b/develop/mkdocs/search_index.json
@@ -6272,7 +6272,7 @@
},
{
"location": "/os/modules/hal/hal/",
- "text": "Hardware Abstraction Layer\n\n\nDescription\n\n\nThe Hardware Abstraction Layer (HAL) includes a set of APIs \n(Application Programmer Interface) to connect to \nthe underlying hardware components including MCU components and peripheral\ncomponents.\n\n\nThe goal is to allow libraries, modules and applications written for Mynewt to \nbe shared within the Mynewt community and used across the variety of supported\nMynewt platforms. A secondary goal is to provide a simple consistent API \nto commonly used MCU components and peripherals to make development easier.\nNothing in the HAL precludes the user of the underlying physical devices,\nit only limits the portability of the end application.\n\n\nExample\n\n\nA Mynewt contributor might write a light-switch \nmodule (\nlibs/light\n) that provides the functionality of an intelligent light \nswitch. This might involve using a timer, a General Purpose Output (GPO) \nto set the light to the on or off state, and flash m
emory to log the times the \nlights were turned on or off. The contributor would like this module to \nwork with as many different hardware platforms as possible, but can't \npossibly test across the complete set of hardware supported by Mynewt.\n\n\nSolution\n: The contributor uses the HAL APIs to control the peripherals.\nThe Mynewt team ensures that the underlying HAL devices all work equivalently\nthrough the HAL APIs. The contributors library is independent of the specifics\nof the hardware. \n\n\nDependency\n\n\nTo include the HAL within your project, simply add it to your package\ndependencies as follows:\n\n\npkg.deps: \n . . .\n hw/hal\n\n\n\n\n\nPlatform Support\n\n\nNot all platforms (MCU and BSP) support all HAL devices. Consult your MCU\nor BSP documentation to find out if you have hardware support for the \nperipherals you are interested in using. Once you verify support, then\nconsult the MCU implementation and see if the specific HAL interface you are\nusi
ng is in the \nmcu/xxx/src/hal_xxxx.c\n implementation. Finally, you \ncan build your project and ensure that there are no unresolved hal_xxx \nexternals.\n\n\nHAL Architecture\n\n\nVisit the \nHAL architecture\n page to get a understanding \nof our current hal and its evolution.\n\n\nImplementing HAL Interfaces\n\n\nIt might be that a specific HAL interface is not supported on your MCU or\nplatform. See the specific HAL documentation for that interface for tips\non implementing this for your MCU.",
+ "text": "Hardware Abstraction Layer\n\n\nDescription\n\n\nThe Hardware Abstraction Layer (HAL) in Mynewt is a low-level, base peripheral abstraction. HAL provides a core set of services that is implemented for each MCU supported by Mynewt. Device drivers are typically the software libraries that initialize the hardware and manage access to the hardware by higher layers of software. In the Mynewt OS, the layers can be depicted in the following manner.\n\n\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n| app |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n| (n)drivers |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u20
14\u2014\u2014\u2014\u2014\u2014+\n| HAL | BSP |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n\n\n\n\n\n\n\n\n\nThe Board Support Package (BSP) abstracts board specific configurations e.g. CPU frequency, input voltage, LED pins, on-chip flash map etc.\n\n\n\n\n\n\nThe Hardware Abstraction Layer (HAL) abstracts architecture-specific functionality. It initializes and enables components within a master processor. It is designed to be portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.). It includes code that initializes and manages access to components of the board such as board buses (I2C, PCI, PCMCIA, etc.), off-chip memory (controllers, level 2+ cache, Flash, etc.), and off-chip I/O (Ethernet, RS-232, display, mouse, etc.)\n\n\n\n\n\n\nThe driver sits atop the BSP and HAL. It abstracts the c
ommon modes of operation for each peripheral device connected via the standard interfaces to the processor. There may be multiple driver implementations of differing complexities for a particular peripheral device. The drivers are the ones that register with the kernel\u2019s power management APIs, and manage turning on and off peripherals and external chipsets, etc. \n\n\n\n\n\n\nGeneral design principles\n\n\n\n\n\n\nThe HAL API should be simple. It should be as easy to implement for hardware as possible. A simple HAL API makes it easy to bring up new MCUs quickly.\n\n\n\n\n\n\nThe HAL API should portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.).\n\n\n\n\n\n\nExample\n\n\nA Mynewt contributor might write a light-switch driver that provides the functionality of an intelligent light\nswitch. This might involve using a timer, a General Purpose Output (GPO)\nto set the light to the on or off state, and flash memory to l
og the times the\nlights were turned on or off. The contributor would like this package to\nwork with as many different hardware platforms as possible, but can't\npossibly test across the complete set of hardware supported by Mynewt.\n\n\nSolution\n: The contributor uses the HAL APIs to control the peripherals.\nThe Mynewt team ensures that the underlying HAL devices all work equivalently\nthrough the HAL APIs. The contributors library is independent of the specifics\nof the hardware. \n\n\nDependency\n\n\nTo include the HAL within your project, simply add it to your package\ndependencies as follows:\n\n\npkg.deps:\n . . .\n hw/hal\n\n\n\n\n\nPlatform Support\n\n\nNot all platforms (MCU and BSP) support all HAL devices. Consult your MCU\nor BSP documentation to find out if you have hardware support for the\nperipherals you are interested in using. Once you verify support, then\nconsult the MCU implementation and see if the specific HAL interface (xxxx) you are\nusing is i
n the \nmcu/\nmcu-name\n/src/hal_xxxx.c\n implementation. Finally, you\ncan build your project and ensure that there are no unresolved hal_xxxx\nexternals.",
"title": "toc"
},
{
@@ -6282,147 +6282,117 @@
},
{
"location": "/os/modules/hal/hal/#description",
- "text": "The Hardware Abstraction Layer (HAL) includes a set of APIs \n(Application Programmer Interface) to connect to \nthe underlying hardware components including MCU components and peripheral\ncomponents. The goal is to allow libraries, modules and applications written for Mynewt to \nbe shared within the Mynewt community and used across the variety of supported\nMynewt platforms. A secondary goal is to provide a simple consistent API \nto commonly used MCU components and peripherals to make development easier.\nNothing in the HAL precludes the user of the underlying physical devices,\nit only limits the portability of the end application.",
+ "text": "The Hardware Abstraction Layer (HAL) in Mynewt is a low-level, base peripheral abstraction. HAL provides a core set of services that is implemented for each MCU supported by Mynewt. Device drivers are typically the software libraries that initialize the hardware and manage access to the hardware by higher layers of software. In the Mynewt OS, the layers can be depicted in the following manner. +\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n| app |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n| (n)drivers |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\n| HAL |
BSP |\n+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014+ The Board Support Package (BSP) abstracts board specific configurations e.g. CPU frequency, input voltage, LED pins, on-chip flash map etc. The Hardware Abstraction Layer (HAL) abstracts architecture-specific functionality. It initializes and enables components within a master processor. It is designed to be portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.). It includes code that initializes and manages access to components of the board such as board buses (I2C, PCI, PCMCIA, etc.), off-chip memory (controllers, level 2+ cache, Flash, etc.), and off-chip I/O (Ethernet, RS-232, display, mouse, etc.) The driver sits atop the BSP and HAL. It abstracts the common modes of operation for each peripheral device connected via the standard interfaces
to the processor. There may be multiple driver implementations of differing complexities for a particular peripheral device. The drivers are the ones that register with the kernel\u2019s power management APIs, and manage turning on and off peripherals and external chipsets, etc.",
"title": "Description"
},
{
+ "location": "/os/modules/hal/hal/#general-design-principles",
+ "text": "The HAL API should be simple. It should be as easy to implement for hardware as possible. A simple HAL API makes it easy to bring up new MCUs quickly. The HAL API should portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.).",
+ "title": "General design principles"
+ },
+ {
"location": "/os/modules/hal/hal/#example",
- "text": "A Mynewt contributor might write a light-switch \nmodule ( libs/light ) that provides the functionality of an intelligent light \nswitch. This might involve using a timer, a General Purpose Output (GPO) \nto set the light to the on or off state, and flash memory to log the times the \nlights were turned on or off. The contributor would like this module to \nwork with as many different hardware platforms as possible, but can't \npossibly test across the complete set of hardware supported by Mynewt. Solution : The contributor uses the HAL APIs to control the peripherals.\nThe Mynewt team ensures that the underlying HAL devices all work equivalently\nthrough the HAL APIs. The contributors library is independent of the specifics\nof the hardware.",
+ "text": "A Mynewt contributor might write a light-switch driver that provides the functionality of an intelligent light\nswitch. This might involve using a timer, a General Purpose Output (GPO)\nto set the light to the on or off state, and flash memory to log the times the\nlights were turned on or off. The contributor would like this package to\nwork with as many different hardware platforms as possible, but can't\npossibly test across the complete set of hardware supported by Mynewt. Solution : The contributor uses the HAL APIs to control the peripherals.\nThe Mynewt team ensures that the underlying HAL devices all work equivalently\nthrough the HAL APIs. The contributors library is independent of the specifics\nof the hardware.",
"title": "Example"
},
{
"location": "/os/modules/hal/hal/#dependency",
- "text": "To include the HAL within your project, simply add it to your package\ndependencies as follows: pkg.deps: \n . . .\n hw/hal",
+ "text": "To include the HAL within your project, simply add it to your package\ndependencies as follows: pkg.deps:\n . . .\n hw/hal",
"title": "Dependency"
},
{
"location": "/os/modules/hal/hal/#platform-support",
- "text": "Not all platforms (MCU and BSP) support all HAL devices. Consult your MCU\nor BSP documentation to find out if you have hardware support for the \nperipherals you are interested in using. Once you verify support, then\nconsult the MCU implementation and see if the specific HAL interface you are\nusing is in the mcu/xxx/src/hal_xxxx.c implementation. Finally, you \ncan build your project and ensure that there are no unresolved hal_xxx \nexternals.",
+ "text": "Not all platforms (MCU and BSP) support all HAL devices. Consult your MCU\nor BSP documentation to find out if you have hardware support for the\nperipherals you are interested in using. Once you verify support, then\nconsult the MCU implementation and see if the specific HAL interface (xxxx) you are\nusing is in the mcu/ mcu-name /src/hal_xxxx.c implementation. Finally, you\ncan build your project and ensure that there are no unresolved hal_xxxx\nexternals.",
"title": "Platform Support"
},
{
- "location": "/os/modules/hal/hal/#hal-architecture",
- "text": "Visit the HAL architecture page to get a understanding \nof our current hal and its evolution.",
- "title": "HAL Architecture"
- },
- {
- "location": "/os/modules/hal/hal/#implementing-hal-interfaces",
- "text": "It might be that a specific HAL interface is not supported on your MCU or\nplatform. See the specific HAL documentation for that interface for tips\non implementing this for your MCU.",
- "title": "Implementing HAL Interfaces"
- },
- {
- "location": "/os/modules/hal/hal_architecture/",
- "text": "Hardware Abstraction Layer\n\n\nThis page presents a picture of the HAL architecture in its current state. The \nMynewt is pre-1.0, and we expect significant changes to the HAL as we add\nsupport for more functionality and platforms.",
- "title": "Architecture"
- },
- {
- "location": "/os/modules/hal/hal_architecture/#hardware-abstraction-layer",
- "text": "This page presents a picture of the HAL architecture in its current state. The \nMynewt is pre-1.0, and we expect significant changes to the HAL as we add\nsupport for more functionality and platforms.",
- "title": "Hardware Abstraction Layer"
- },
- {
"location": "/os/modules/hal/hal_api/",
- "text": "HAL Interfaces\n\n\nThe HAL supports separate interfaces for many peripherals. A brief\ndescription of the interfaces are shown below.\n\n\n\n\n\n\n\n\nHal Name\n\n\n Interface File \n\n\nDescription \n\n\n\n\n\n\n\n\n\n\nadc\n\n\nhal_adc.h\n\n\nAn interface for controlling Analog To Digital Converters.\n\n\n\n\n\n\ncputime\n\n\nhal_cputime.h\n\n\nAn interface for getting the CPU uptime, an interface to set arbitrary timers based on the CPU time, and an interface for a blocking delay if CPU time.\n\n\n\n\n\n\ndac\n\n\nhal_dac.h\n\n\nAn interface for controlling Digital to Analog Converters.\n\n\n\n\n\n\nflash\n\n\nhal_flash.h\n\n\nA blocking interface to access flash memory.\n\n\n\n\n\n\nflash map\n\n\nflash_map.h\n\n\nAn interface to query information about the flash map (regions and sectors)\n\n\n\n\n\n\ngpio\n\n\nhal_gpio.h\n\n\nAn interface for manipulating General Purpose Inputs and Outputs.\n\n\n\n\n\n\ni2c\n\n\nhal_i2c.h\n\n\nAn interface for controlling
Inter-Integrated-Circuit (i2c) devices.\n\n\n\n\n\n\npwm\n\n\nhal_pwm.h\n\n\nAn interface for controlling Pulse Width Modulator Devices.\n\n\n\n\n\n\nspi\n\n\nhal_spi.h\n\n\nAn interface for controlling Serial Peripheral Interface (SPI) devices.\n\n\n\n\n\n\nsystem\n\n\nhal_system.h\n\n\nAn interface for starting and resetting the system\n\n\n\n\n\n\nuart\n\n\nhal_uart.h\n\n\nAn interface for communicating via asynchronous serial interface .",
+ "text": "HAL Interfaces\n\n\nThe HAL supports separate interfaces for many peripherals. A brief\ndescription of the interfaces are shown below.\n\n\n\n\n\n\n\n\nHal Name\n\n\n Interface File \n\n\nDescription \n\n\n\n\n\n\n\n\n\n\nbsp\n\n\nhal_bsp.h\n\n\nAn hardware independent interface to identify and access underlying BSP.\n\n\n\n\n\n\nflash api for apps to use\n\n\nhal_flash.h\n\n\nA blocking interface to access flash memory.\n\n\n\n\n\n\nflash api for drivers to implement\n\n\nflash_map.h\n\n\nAn interface to query information about the flash map (regions and sectors)\n\n\n\n\n\n\ngpio\n\n\nhal_gpio.h\n\n\nAn interface for manipulating General Purpose Inputs and Outputs.\n\n\n\n\n\n\ni2c\n\n\nhal_i2c.h\n\n\nAn interface for controlling Inter-Integrated-Circuit (i2c) devices.\n\n\n\n\n\n\nOS tick\n\n\nhal_os_tick.h\n\n\nAn interface to set up interrupt timers or halt CPU in terms of OS ticks.\n\n\n\n\n\n\nspi\n\n\nhal_spi.h\n\n\nAn interface for controlling Serial P
eripheral Interface (SPI) devices.\n\n\n\n\n\n\nsystem\n\n\nhal_system.h\n\n\nAn interface for starting and resetting the system.\n\n\n\n\n\n\ntimer\n\n\nhal_cputime.h\n\n\nAn interface for configuring and running HW timers\n\n\n\n\n\n\nuart\n\n\nhal_uart.h\n\n\nAn interface for communicating via asynchronous serial interface.\n\n\n\n\n\n\nwatchdog\n\n\nhal_watchdog.h\n\n\nAn interface for enabling internal hardware watchdogs.",
"title": "Summary"
},
{
"location": "/os/modules/hal/hal_api/#hal-interfaces",
- "text": "The HAL supports separate interfaces for many peripherals. A brief\ndescription of the interfaces are shown below. Hal Name Interface File Description adc hal_adc.h An interface for controlling Analog To Digital Converters. cputime hal_cputime.h An interface for getting the CPU uptime, an interface to set arbitrary timers based on the CPU time, and an interface for a blocking delay if CPU time. dac hal_dac.h An interface for controlling Digital to Analog Converters. flash hal_flash.h A blocking interface to access flash memory. flash map flash_map.h An interface to query information about the flash map (regions and sectors) gpio hal_gpio.h An interface for manipulating General Purpose Inputs and Outputs. i2c hal_i2c.h An interface for controlling Inter-Integrated-Circuit (i2c) devices. pwm hal_pwm.h An interface for controlling Pulse Width Modulator Devices. spi hal_spi.h An interface for controlling Seria
l Peripheral Interface (SPI) devices. system hal_system.h An interface for starting and resetting the system uart hal_uart.h An interface for communicating via asynchronous serial interface .",
+ "text": "The HAL supports separate interfaces for many peripherals. A brief\ndescription of the interfaces are shown below. Hal Name Interface File Description bsp hal_bsp.h An hardware independent interface to identify and access underlying BSP. flash api for apps to use hal_flash.h A blocking interface to access flash memory. flash api for drivers to implement flash_map.h An interface to query information about the flash map (regions and sectors) gpio hal_gpio.h An interface for manipulating General Purpose Inputs and Outputs. i2c hal_i2c.h An interface for controlling Inter-Integrated-Circuit (i2c) devices. OS tick hal_os_tick.h An interface to set up interrupt timers or halt CPU in terms of OS ticks. spi hal_spi.h An interface for controlling Serial Peripheral Interface (SPI) devices. system hal_system.h An interface for starting and resetting the system. timer hal_cputime.h An interface for configuring and run
ning HW timers uart hal_uart.h An interface for communicating via asynchronous serial interface. watchdog hal_watchdog.h An interface for enabling internal hardware watchdogs.",
"title": "HAL Interfaces"
},
{
- "location": "/os/modules/hal/hal_adc/hal_adc/",
- "text": "hal_adc\n\n\nThe hardware independent interface to Analog To Digital Controllers\n\n\nDescription\n\n\nAnalog to Digital converters (ADCs) read analog values (voltage) and convert\nthem to digital values to be used in your applications. For a description\nof ADC, see \nwikipedia\n\n\nDefinition\n\n\nhal_adc.h\n\n\nHAL_ADCs Theory Of Operation\n\n\nADCs have different conversion rates, resolution (bits) and reference voltages.\n\n\nThe HAL_ADC has APIs to allow the application or library to query the capabilities\nof a specific ADC.\n\n\n\n\n\n\n\n\nMethod Name\n\n\n Description \n\n\n\n\n\n\n\n\n\n\nhal_adc_get_bits\n\n\ngets the resolution of the ADC in bits. For example if the ADC is 10 bits, a read will return a value from 0 through 2^10 - 1 = 1023.\n\n\n\n\n\n\nhal_adc_get_ref_mv\n\n\ngets the underlying reference voltage for the ADC in millivolts. For example, if the ADC is 10 bits and the reference voltage is 5000 mV a ADC reading of 1023 corresponds to
5V; a ADC reading of 0 corresponds to 0 volts.\n\n\n\n\n\n\n\n\nGiven this information, the application or library could convert any reading\nto millivolts. Since this is a common operation, the HAL_ADC API has a helper\nfunction to perform this function: \nhal_adc_to_mv()\n.\n\n\nThe current HAL_ADC API provides a blocking read command to initiate an ADC\nconversion, and return the result of that conversion. Conversion time is\nhardware dependent, but this is not an instantaneous operation. Libraries\ncan use the \nhal_cputime\n APIs to \ntime conversions if that is relevant to the application.\n\n\nFuture HAL_ADC APIs will include periodic ADC conversion, non-blocking ADC\nconversion and direct-to-memory DMA conversion.",
- "title": "ADC"
+ "location": "/os/modules/hal/hal_bsp/hal_bsp/",
+ "text": "hal_bsp\n\n\nThis is the hardware independent BSP (Board Support Package) Interface for Mynewt.\n\n\nDescription\n\n\nContains the basic operations to initialize, specify memory to include in coredump, configure interrupt priority etc.\n\n\nDefinition\n\n\nhal_bsp.h\n\n\nExamples",
+ "title": "BSP"
},
{
- "location": "/os/modules/hal/hal_adc/hal_adc/#hal_adc",
- "text": "The hardware independent interface to Analog To Digital Controllers",
- "title": "hal_adc"
+ "location": "/os/modules/hal/hal_bsp/hal_bsp/#hal_bsp",
+ "text": "This is the hardware independent BSP (Board Support Package) Interface for Mynewt.",
+ "title": "hal_bsp"
},
{
- "location": "/os/modules/hal/hal_adc/hal_adc/#description",
- "text": "Analog to Digital converters (ADCs) read analog values (voltage) and convert\nthem to digital values to be used in your applications. For a description\nof ADC, see wikipedia",
+ "location": "/os/modules/hal/hal_bsp/hal_bsp/#description",
+ "text": "Contains the basic operations to initialize, specify memory to include in coredump, configure interrupt priority etc.",
"title": "Description"
},
{
- "location": "/os/modules/hal/hal_adc/hal_adc/#definition",
- "text": "hal_adc.h",
+ "location": "/os/modules/hal/hal_bsp/hal_bsp/#definition",
+ "text": "hal_bsp.h",
"title": "Definition"
},
{
- "location": "/os/modules/hal/hal_adc/hal_adc/#hal_adcs-theory-of-operation",
- "text": "ADCs have different conversion rates, resolution (bits) and reference voltages. The HAL_ADC has APIs to allow the application or library to query the capabilities\nof a specific ADC. Method Name Description hal_adc_get_bits gets the resolution of the ADC in bits. For example if the ADC is 10 bits, a read will return a value from 0 through 2^10 - 1 = 1023. hal_adc_get_ref_mv gets the underlying reference voltage for the ADC in millivolts. For example, if the ADC is 10 bits and the reference voltage is 5000 mV a ADC reading of 1023 corresponds to 5V; a ADC reading of 0 corresponds to 0 volts. Given this information, the application or library could convert any reading\nto millivolts. Since this is a common operation, the HAL_ADC API has a helper\nfunction to perform this function: hal_adc_to_mv() . The current HAL_ADC API provides a blocking read command to initiate an ADC\nconversion, and return the result of that conversion. Conversio
n time is\nhardware dependent, but this is not an instantaneous operation. Libraries\ncan use the hal_cputime APIs to \ntime conversions if that is relevant to the application. Future HAL_ADC APIs will include periodic ADC conversion, non-blocking ADC\nconversion and direct-to-memory DMA conversion.",
- "title": "HAL_ADCs Theory Of Operation"
+ "location": "/os/modules/hal/hal_bsp/hal_bsp/#examples",
+ "text": "",
+ "title": "Examples"
},
{
- "location": "/os/modules/hal/hal_cputime/hal_cpu_timer/",
- "text": "hal_cputime\n\n\nThe hardware independent interface to system time.\n\n\nDescription\n\n\nContains several different interface.\n\n\n\n\nAn interface to get the current CPU time\n\n\nInterfaces to convert between CPU time and clock time (microseconds etc.)\n\n\nAn Interface to set up a software timer based on CPU time.\n\n\n\n\nDefinition\n\n\nhal_cputime.h\n\n\nCPU Time\n\n\nThe CPU time is not the same as the \nos_time\n. Typically,\nthe os_time is set to a much slower tick rate than the CPU time. The CPU\ntime should be used for timing real-time events at exact times. The os_time\nshould be used for system level timeout etc that are not in fine time\nresolutions. In fact, cputime is not part of the os at all, but a hardware\nlayer abstraction to high resolution timers.\n\n\nThere are methods to get the cputime as 32-bit and 64-bit values. Both\nvalues may eventually wrap, but for timing short events a 32-bit value\nmay be sufficient and would",
- "title": "CPU timer"
+ "location": "/os/modules/hal/hal_flash/hal_flash/",
+ "text": "hal_flash\n\n\nThe hardware independent interface to flash memory that is used by applications.\n\n\nDescription\n\n\nThe API offers basic initialization, read, write, erase, sector erase, and other operations.\n\n\nDefinition\n\n\nhal_flash.h\n\n\nExamples",
+ "title": "flash API for apps"
},
{
- "location": "/os/modules/hal/hal_cputime/hal_cpu_timer/#hal_cputime",
- "text": "The hardware independent interface to system time.",
- "title": "hal_cputime"
+ "location": "/os/modules/hal/hal_flash/hal_flash/#hal_flash",
+ "text": "The hardware independent interface to flash memory that is used by applications.",
+ "title": "hal_flash"
},
{
- "location": "/os/modules/hal/hal_cputime/hal_cpu_timer/#description",
- "text": "Contains several different interface. An interface to get the current CPU time Interfaces to convert between CPU time and clock time (microseconds etc.) An Interface to set up a software timer based on CPU time.",
+ "location": "/os/modules/hal/hal_flash/hal_flash/#description",
+ "text": "The API offers basic initialization, read, write, erase, sector erase, and other operations.",
"title": "Description"
},
{
- "location": "/os/modules/hal/hal_cputime/hal_cpu_timer/#definition",
- "text": "hal_cputime.h",
+ "location": "/os/modules/hal/hal_flash/hal_flash/#definition",
+ "text": "hal_flash.h",
"title": "Definition"
},
{
- "location": "/os/modules/hal/hal_cputime/hal_cpu_timer/#cpu-time",
- "text": "The CPU time is not the same as the os_time . Typically,\nthe os_time is set to a much slower tick rate than the CPU time. The CPU\ntime should be used for timing real-time events at exact times. The os_time\nshould be used for system level timeout etc that are not in fine time\nresolutions. In fact, cputime is not part of the os at all, but a hardware\nlayer abstraction to high resolution timers. There are methods to get the cputime as 32-bit and 64-bit values. Both\nvalues may eventually wrap, but for timing short events a 32-bit value\nmay be sufficient and would",
- "title": "CPU Time"
+ "location": "/os/modules/hal/hal_flash/hal_flash/#examples",
+ "text": "",
+ "title": "Examples"
},
{
- "location": "/os/modules/hal/hal_dac/hal_dac/",
- "text": "hal_dac\n\n\nThe hardware independent interface to Digital To Analog Converters.\n\n\nDescription\n\n\nFor a description of Digital to Analog Converters, see \n\nwikipedia\n\n\nDefinition\n\n\nhal_dac.h\n\n\nHAL_DAC Theory Of Operation\n\n\nDACs have differing conversion resolution (bits), reference voltages (Volts)\nand conversion times (sample rate).\n\n\nThe hal_dac implements function to query some of these values from the\nBSP.\n\n\n\n\n\n\n\n\nMethod Name\n\n\n Description \n\n\n\n\n\n\n\n\n\n\nhal_dac_get_bits\n\n\ngets the resolution of the DAC in bits. For example if the DAC is 10 bits, it supports setting of value from 0 through 2^10 - 1 = 1023.\n\n\n\n\n\n\nhal_dac_get_ref_mv\n\n\ngets the underlying reference voltage for the DAC in millivolts. For example, if the DAC is 10 bits and the reference voltage is 5000 mV setting the DAC value to 1023 corresponds to 5V; setting the DAC value to 0 corresponds to 0 volts.\n\n\n\n\n\n\n\n\nFrom these two piec
es of information the application or library can\ndetermine how to set a specific output voltage. NOTE: each underlying\nhardware may return different values for these settings.\n\n\nThe API to set the DAC output value is blocking. This means the function \nwill return after the DAC value has been programmed.\n\n\nFuture HAL_DAC APIs will include A DMA interface to automatically write \nDMA data to the DAC based in events.\n\n\nThe Mynewt HAL also supports a \nPWM\n interface which can \nbe used in conjunction with a low pass filter to set an analog output voltage.",
- "title": "DAC"
+ "location": "/os/modules/hal/hal_flash/hal_flash_int/",
+ "text": "hal_flash_int\n\n\nThe API that flash drivers have to implement.\n\n\nDescription\n\n\nThe BSP for the hardware will implement the structs defined in this API.\n\n\nDefinition\n\n\nhal_flash_int.h\n\n\nExamples\n\n\nThe Nordic nRF52 bsp implements the hal_flash_int API as seen in \nhal_bsp.c\n\n\nconst struct hal_flash *\nhal_bsp_flash_dev(uint8_t id)\n{\n /*\n * Internal flash mapped to id 0.\n */\n if (id != 0) {\n return NULL;\n }\n return \nnrf52k_flash_dev;\n}",
+ "title": "flash_int"
},
{
- "location": "/os/modules/hal/hal_dac/hal_dac/#hal_dac",
- "text": "The hardware independent interface to Digital To Analog Converters.",
- "title": "hal_dac"
+ "location": "/os/modules/hal/hal_flash/hal_flash_int/#hal_flash_int",
+ "text": "The API that flash drivers have to implement.",
+ "title": "hal_flash_int"
},
{
- "location": "/os/modules/hal/hal_dac/hal_dac/#description",
- "text": "For a description of Digital to Analog Converters, see wikipedia",
+ "location": "/os/modules/hal/hal_flash/hal_flash_int/#description",
+ "text": "The BSP for the hardware will implement the structs defined in this API.",
"title": "Description"
},
{
- "location": "/os/modules/hal/hal_dac/hal_dac/#definition",
- "text": "hal_dac.h",
+ "location": "/os/modules/hal/hal_flash/hal_flash_int/#definition",
+ "text": "hal_flash_int.h",
"title": "Definition"
},
{
- "location": "/os/modules/hal/hal_dac/hal_dac/#hal_dac-theory-of-operation",
- "text": "DACs have differing conversion resolution (bits), reference voltages (Volts)\nand conversion times (sample rate). The hal_dac implements function to query some of these values from the\nBSP. Method Name Description hal_dac_get_bits gets the resolution of the DAC in bits. For example if the DAC is 10 bits, it supports setting of value from 0 through 2^10 - 1 = 1023. hal_dac_get_ref_mv gets the underlying reference voltage for the DAC in millivolts. For example, if the DAC is 10 bits and the reference voltage is 5000 mV setting the DAC value to 1023 corresponds to 5V; setting the DAC value to 0 corresponds to 0 volts. From these two pieces of information the application or library can\ndetermine how to set a specific output voltage. NOTE: each underlying\nhardware may return different values for these settings. The API to set the DAC output value is blocking. This means the function \nwill return after the DAC value has been programmed.
Future HAL_DAC APIs will include A DMA interface to automatically write \nDMA data to the DAC based in events. The Mynewt HAL also supports a PWM interface which can \nbe used in conjunction with a low pass filter to set an analog output voltage.",
- "title": "HAL_DAC Theory Of Operation"
- },
- {
- "location": "/os/modules/hal/hal_flash/hal_flash/",
- "text": "",
- "title": "Overview"
- },
- {
- "location": "/os/modules/hal/hal_flash/hal_flash_int/",
- "text": "",
- "title": "flash_int"
- },
- {
- "location": "/os/modules/hal/hal_flash/hal_flash_map/",
- "text": "",
- "title": "flash_map"
+ "location": "/os/modules/hal/hal_flash/hal_flash_int/#examples",
+ "text": "The Nordic nRF52 bsp implements the hal_flash_int API as seen in hal_bsp.c const struct hal_flash *\nhal_bsp_flash_dev(uint8_t id)\n{\n /*\n * Internal flash mapped to id 0.\n */\n if (id != 0) {\n return NULL;\n }\n return nrf52k_flash_dev;\n}",
+ "title": "Examples"
},
{
"location": "/os/modules/hal/hal_gpio/hal_gpio/",
- "text": "hal_gpio\n\n\nThis is the hardware independent GPIO (General Purpose Input Output) Interface for Mynewt.\n\n\nDescription\n\n\nContains the basic operations to set and read General Purpose Digital I/O Pins\nwithin a Mynewt system.\n\n\nIndividual GPIOs are referenced in the APIs as \npins\n. However, in this interface the \npins\n are virtual GPIO pins. The MCU hal driver maps these virtual \npins\n to the physical GPIO ports and pins.\n\n\nTypically, the BSP code may define named I/O pins in terms of these virtual \npins\n to describe the devices attached to the physical pins.\n\n\nHere's a brief example so you can get the gist of the translation.\n\n\nSuppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 an
d so on. The exact number of physical port (and virtual\nport pins) depends on the specific variant of the stm32F4xx. \n\n\nSo if I want to turn on port B pin 3, that would be virtual pin 1*16 + 3 = 19.\nThis translation is defined in the MCU implementation of\n\nhal_gpio.c\n\nfor the stmf32F4xx. Each MCU will typically have a different translation method\ndepending on its GPIO architecture.\n\n\nNow, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin. For example\n\n\n#define SYSTEM_LED (37)\n#define FLASH_SPI_CHIP_SELECT (3)\n\n\n\n\n\nwould map the system indicator LED to virtual pin 37 which on the stm32F4xx would be Port C pin 5 and the chip select line for the external SPI flash to virtual pin 3 which on the stm32F4xxis port A pin 3.\n\n\nSaid another way, in this specific system we get\n\n\nSYSTEM_LED --\n hal_gpio virtual pin 37 --\n port
C pin 5 on the stm34F4xx\n\n\n\n\n\nDefinition\n\n\nhal_gpio.h\n\n\nExamples\n\n\nBlinky\n\n\nBlinky uses the hal_gpio to blink the system LED. The blinky source code is available\n\nhere\n.\nExamine how \ntask1_handler\n initializes and toggles the GPIO to control the LED.",
+ "text": "hal_gpio\n\n\nThis is the hardware independent GPIO (General Purpose Input Output) Interface for Mynewt.\n\n\nDescription\n\n\nContains the basic operations to set and read General Purpose Digital I/O Pins\nwithin a Mynewt system.\n\n\nIndividual GPIOs are referenced in the APIs as \npins\n. However, in this interface the \npins\n are virtual GPIO pins. The MCU header file maps these virtual \npins\n to the physical GPIO ports and pins.\n\n\nTypically, the BSP code may define named I/O pins in terms of these virtual \npins\n to describe the devices attached to the physical pins.\n\n\nHere's a brief example so you can get the gist of the translation.\n\n\nSuppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 a
nd so on. The exact number of physical port (and virtual\nport pins) depends on the specific variant of the stm32F4xx. \n\n\nSo if I want to turn on port B pin 3, that would be virtual pin 1*16 + 3 = 19.\nThis translation is defined in the MCU implementation of\n\nhal_gpio.c\n\nfor the stmf32F4xx. Each MCU will typically have a different translation method\ndepending on its GPIO architecture.\n\n\nNow, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin in the \nbsp.h\n header file for the BSP. For example,\n\n\n#define SYSTEM_LED (37)\n#define FLASH_SPI_CHIP_SELECT (3)\n\n\n\n\n\nwould map the system indicator LED to virtual pin 37 which on the stm32F4xx would be Port C pin 5 and the chip select line for the external SPI flash to virtual pin 3 which on the stm32F4xxis port A pin 3.\n\n\nSaid another way, in this specific system we get\n\n\nSYSTEM
_LED --\n hal_gpio virtual pin 37 --\n port C pin 5 on the stm34F4xx\n\n\n\n\n\nDefinition\n\n\nhal_gpio.h\n\n\nExamples\n\n\nBlinky\n\n\nBlinky uses the hal_gpio to blink the system LED. The blinky source code is available in the\n\nblinky repo\n.\nExamine how \nblinky_task_handler\n initializes and toggles the GPIO to control the LED.",
"title": "GPIO"
},
{
@@ -6432,7 +6402,7 @@
},
{
"location": "/os/modules/hal/hal_gpio/hal_gpio/#description",
- "text": "Contains the basic operations to set and read General Purpose Digital I/O Pins\nwithin a Mynewt system. Individual GPIOs are referenced in the APIs as pins . However, in this interface the pins are virtual GPIO pins. The MCU hal driver maps these virtual pins to the physical GPIO ports and pins. Typically, the BSP code may define named I/O pins in terms of these virtual pins to describe the devices attached to the physical pins. Here's a brief example so you can get the gist of the translation. Suppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on. The exact number of physical port (and virtual\nport pins) depends on the specific variant of the stm32F4xx. So if I want to turn on port
B pin 3, that would be virtual pin 1*16 + 3 = 19.\nThis translation is defined in the MCU implementation of hal_gpio.c \nfor the stmf32F4xx. Each MCU will typically have a different translation method\ndepending on its GPIO architecture. Now, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin. For example #define SYSTEM_LED (37)\n#define FLASH_SPI_CHIP_SELECT (3) would map the system indicator LED to virtual pin 37 which on the stm32F4xx would be Port C pin 5 and the chip select line for the external SPI flash to virtual pin 3 which on the stm32F4xxis port A pin 3. Said another way, in this specific system we get SYSTEM_LED -- hal_gpio virtual pin 37 -- port C pin 5 on the stm34F4xx",
+ "text": "Contains the basic operations to set and read General Purpose Digital I/O Pins\nwithin a Mynewt system. Individual GPIOs are referenced in the APIs as pins . However, in this interface the pins are virtual GPIO pins. The MCU header file maps these virtual pins to the physical GPIO ports and pins. Typically, the BSP code may define named I/O pins in terms of these virtual pins to describe the devices attached to the physical pins. Here's a brief example so you can get the gist of the translation. Suppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on. The exact number of physical port (and virtual\nport pins) depends on the specific variant of the stm32F4xx. So if I want to turn on port
B pin 3, that would be virtual pin 1*16 + 3 = 19.\nThis translation is defined in the MCU implementation of hal_gpio.c \nfor the stmf32F4xx. Each MCU will typically have a different translation method\ndepending on its GPIO architecture. Now, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin in the bsp.h header file for the BSP. For example, #define SYSTEM_LED (37)\n#define FLASH_SPI_CHIP_SELECT (3) would map the system indicator LED to virtual pin 37 which on the stm32F4xx would be Port C pin 5 and the chip select line for the external SPI flash to virtual pin 3 which on the stm32F4xxis port A pin 3. Said another way, in this specific system we get SYSTEM_LED -- hal_gpio virtual pin 37 -- port C pin 5 on the stm34F4xx",
"title": "Description"
},
{
@@ -6447,12 +6417,12 @@
},
{
"location": "/os/modules/hal/hal_gpio/hal_gpio/#blinky",
- "text": "Blinky uses the hal_gpio to blink the system LED. The blinky source code is available here .\nExamine how task1_handler initializes and toggles the GPIO to control the LED.",
+ "text": "Blinky uses the hal_gpio to blink the system LED. The blinky source code is available in the blinky repo .\nExamine how blinky_task_handler initializes and toggles the GPIO to control the LED.",
"title": "Blinky"
},
{
"location": "/os/modules/hal/hal_i2c/hal_i2c/",
- "text": "hal_i2c\n\n\nThe hardware independent interface to I2C Devices.\n\n\nDescription\n\n\nAn Inter-Integrated Circuit (I\u00b2C ] I-squared-C) bus is a multi-master,\nmulti-save serial interface used to connect components on a circuit board\nand often peripherals devices located off the circuit board.\n\n\nI2C is often though of as a 2-wire protocol because it uses two wires (SDA, SCL)\nto send data between devices. \n\n\nFor a detailed description of I2C, see the \nI\u00b2C wikipedia page\n\n\nDefinition\n\n\nhal_i2c.h\n\n\nHAL_I2C Theory Of Operation\n\n\nAn I\u00b2C transaction typically involves acquiring the bus, sending and/or receiving\ndata and release the bus. The bus acquisition portion is important because\nthe bus is typically multi-master so other devices may be trying to read/write\nthe same peripheral. \n\n\nHAL_I2C implements a master interface to the I\u00b2C bus. Typical usage of the \ninterface would involve the following steps.\n\n\n\n\niniti
alize an I\u00b2C device using \nhal_i2c_init\n\n\nwhen you want to perform an I\u00b2C transaction:\n\n\nIssue the \nhal_i2c_begin()\n command. \n\n\nIssue one or more \nhal_i2c_read\n and/or \nhal_i2c_write\n commands\n\n\nIssue the \nhal_i2c_end()\n command.\n\n\n\n\n\n\n\n\nAn addition API was added called \nhal_i2c_probe\n. This command combines\n\nhal_i2c_begin()\n, \nhal_i2c_read\n, and \nhal_i2c_end()\n to try to read 0-bytes\nfrom a specific bus address. its intended to provide an easy way to probe\nthe bus for a specific device. NOTE: if the device is write-only, it will \nnot appear with this command.\n\n\nHAL_I2C Data\n\n\nData to read/write is passed to the hal_i2c APIs via the \n\n\nstruct hal_i2c_master_data {\n uint8_t address; /* destination address */\n uint16_t len; /* number of bytes to transmit or receive */\n uint8_t *buffer; /* data buffer for transmit or receive */\n};\n\n\n\n\n\nbuffer\n is a pointer to the data to send. \nlen\n
is the number of bytes\nto send over the bus. \naddress\n is a 7-bit bus address of the device.\n\n\nWhen I\u00b2C builds its address, it uses the 7-bit address plus a 1-bit R/W \n(read/write) indicator to identify the device and direction of the \ntransaction. Thus when using this API, you should use a 7-bit address\nin the data structure and ensure that address is a value between 0-127.\n\n\nAs an example, consider an I\u00b2C device address that looks like this:\n\n\n\n\n\n\n\n\nB7\n\n\nB6\n\n\nB5\n\n\nB4\n\n\nB3\n\n\nB2\n\n\nB1\n\n\nB0\n\n\n\n\n\n\n\n\n\n\n1\n\n\n0\n\n\n0\n\n\n0\n\n\n1\n\n\n1\n\n\n0\n\n\nR/W\n\n\n\n\n\n\nMSB\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nLSB\n\n\n\n\n\n\n\n\nIn the HAL_I2C API you would communicate with this device with address \n\n0b1000110\n, which is hex 0x46 or decimal 70. The I\u00b2C drive would add the R/W bit\nand transmit it as hex 0x8D or 0x8D depending whether it was a read or\nwrite command.",
+ "text": "hal_i2c\n\n\nThe hardware independent interface to I2C Devices.\n\n\nDescription\n\n\nAn Inter-Integrated Circuit (I\u00b2C ] I-squared-C) bus is a multi-master,\nmulti-save serial interface used to connect components on a circuit board\nand often peripherals devices located off the circuit board.\n\n\nI2C is often though of as a 2-wire protocol because it uses two wires (SDA, SCL)\nto send data between devices. \n\n\nFor a detailed description of I2C, see the \nI\u00b2C wikipedia page\n\n\nDefinition\n\n\nhal_i2c.h\n\n\nHAL_I2C Theory Of Operation\n\n\nAn I\u00b2C transaction typically involves acquiring the bus, sending and/or receiving\ndata and release the bus. The bus acquisition portion is important because\nthe bus is typically multi-master so other devices may be trying to read/write\nthe same peripheral. \n\n\nHAL_I2C implements a master interface to the I\u00b2C bus. Typical usage of the \ninterface would involve the following steps.\n\n\nInitializ
e an i2c device with:\n hal_i2c_init()\n\n\nWhen you wish to perform an i2c transaction, you call one or both of:\n hal_i2c_master_write();\n hal_i2c_master_read();\n\n\nThese functions will issue a START condition, followed by the device's\n7-bit I2C address, and then send or receive the payload based on the data\nprovided. This will cause a repeated start on the bus, which is valid in\nI2C specification, and the decision to use repeated starts was made to\nsimplify the I2C HAL. To set the STOP condition at an appropriate moment,\nyou set the \nlast_op\n field to a \n1\n in either function.\n\n\nFor example, in an I2C memory access you might write a register address and\nthen read data back via:\n hal_i2c_write(); -- write to a specific register on the device\n hal_i2c_read(); --- read back data, setting 'last_op' to '1'\n\n\nAn addition API was added called \nhal_i2c_probe\n. This command combines\n\nhal_i2c_begin()\n, \nhal_i2c_read\n, and \nhal_i2c_end()\n to try
to read 0-bytes\nfrom a specific bus address. its intended to provide an easy way to probe\nthe bus for a specific device. NOTE: if the device is write-only, it will \nnot appear with this command.\n\n\nA slave API is pending for further release.\n\n\nHAL_I2C Data\n\n\nData to read/write is passed to the hal_i2c APIs via the \n\n\nstruct hal_i2c_master_data {\n uint8_t address; /* destination address */\n uint16_t len; /* number of bytes to transmit or receive */\n uint8_t *buffer; /* data buffer for transmit or receive */\n};\n\n\n\n\n\nbuffer\n is a pointer to the data to send. \nlen\n is the number of bytes\nto send over the bus. \naddress\n is a 7-bit bus address of the device.\n\n\nWhen I\u00b2C builds its address, it uses the 7-bit address plus a 1-bit R/W \n(read/write) indicator to identify the device and direction of the \ntransaction. Thus when using this API, you should use a 7-bit address\nin the data structure and ensure that address is a val
ue between 0-127.\n\n\nAs an example, consider an I\u00b2C device address that looks like this:\n\n\n\n\n\n\n\n\nB7\n\n\nB6\n\n\nB5\n\n\nB4\n\n\nB3\n\n\nB2\n\n\nB1\n\n\nB0\n\n\n\n\n\n\n\n\n\n\n1\n\n\n0\n\n\n0\n\n\n0\n\n\n1\n\n\n1\n\n\n0\n\n\nR/W\n\n\n\n\n\n\nMSB\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nLSB\n\n\n\n\n\n\n\n\nIn the HAL_I2C API you would communicate with this device with address \n\n0b1000110\n, which is hex 0x46 or decimal 70. The I\u00b2C drive would add the R/W bit\nand transmit it as hex 0x8C (binary 10001100) or 0x8D (binary 10001101) depending whether it was a read or\nwrite command.",
"title": "I2C"
},
{
@@ -6472,42 +6442,42 @@
},
{
"location": "/os/modules/hal/hal_i2c/hal_i2c/#hal_i2c-theory-of-operation",
- "text": "An I\u00b2C transaction typically involves acquiring the bus, sending and/or receiving\ndata and release the bus. The bus acquisition portion is important because\nthe bus is typically multi-master so other devices may be trying to read/write\nthe same peripheral. HAL_I2C implements a master interface to the I\u00b2C bus. Typical usage of the \ninterface would involve the following steps. initialize an I\u00b2C device using hal_i2c_init when you want to perform an I\u00b2C transaction: Issue the hal_i2c_begin() command. Issue one or more hal_i2c_read and/or hal_i2c_write commands Issue the hal_i2c_end() command. An addition API was added called hal_i2c_probe . This command combines hal_i2c_begin() , hal_i2c_read , and hal_i2c_end() to try to read 0-bytes\nfrom a specific bus address. its intended to provide an easy way to probe\nthe bus for a specific device. NOTE: if the device is write-only, it will \nnot appear with this co
mmand.",
+ "text": "An I\u00b2C transaction typically involves acquiring the bus, sending and/or receiving\ndata and release the bus. The bus acquisition portion is important because\nthe bus is typically multi-master so other devices may be trying to read/write\nthe same peripheral. HAL_I2C implements a master interface to the I\u00b2C bus. Typical usage of the \ninterface would involve the following steps. Initialize an i2c device with:\n hal_i2c_init() When you wish to perform an i2c transaction, you call one or both of:\n hal_i2c_master_write();\n hal_i2c_master_read(); These functions will issue a START condition, followed by the device's\n7-bit I2C address, and then send or receive the payload based on the data\nprovided. This will cause a repeated start on the bus, which is valid in\nI2C specification, and the decision to use repeated starts was made to\nsimplify the I2C HAL. To set the STOP condition at an appropriate moment,\nyou set the last_op field to
a 1 in either function. For example, in an I2C memory access you might write a register address and\nthen read data back via:\n hal_i2c_write(); -- write to a specific register on the device\n hal_i2c_read(); --- read back data, setting 'last_op' to '1' An addition API was added called hal_i2c_probe . This command combines hal_i2c_begin() , hal_i2c_read , and hal_i2c_end() to try to read 0-bytes\nfrom a specific bus address. its intended to provide an easy way to probe\nthe bus for a specific device. NOTE: if the device is write-only, it will \nnot appear with this command. A slave API is pending for further release.",
"title": "HAL_I2C Theory Of Operation"
},
{
"location": "/os/modules/hal/hal_i2c/hal_i2c/#hal_i2c-data",
- "text": "Data to read/write is passed to the hal_i2c APIs via the struct hal_i2c_master_data {\n uint8_t address; /* destination address */\n uint16_t len; /* number of bytes to transmit or receive */\n uint8_t *buffer; /* data buffer for transmit or receive */\n}; buffer is a pointer to the data to send. len is the number of bytes\nto send over the bus. address is a 7-bit bus address of the device. When I\u00b2C builds its address, it uses the 7-bit address plus a 1-bit R/W \n(read/write) indicator to identify the device and direction of the \ntransaction. Thus when using this API, you should use a 7-bit address\nin the data structure and ensure that address is a value between 0-127. As an example, consider an I\u00b2C device address that looks like this: B7 B6 B5 B4 B3 B2 B1 B0 1 0 0 0 1 1 0 R/W MSB LSB In the HAL_I2C API you would communicate with this device with address 0b1000110 , which is h
ex 0x46 or decimal 70. The I\u00b2C drive would add the R/W bit\nand transmit it as hex 0x8D or 0x8D depending whether it was a read or\nwrite command.",
+ "text": "Data to read/write is passed to the hal_i2c APIs via the struct hal_i2c_master_data {\n uint8_t address; /* destination address */\n uint16_t len; /* number of bytes to transmit or receive */\n uint8_t *buffer; /* data buffer for transmit or receive */\n}; buffer is a pointer to the data to send. len is the number of bytes\nto send over the bus. address is a 7-bit bus address of the device. When I\u00b2C builds its address, it uses the 7-bit address plus a 1-bit R/W \n(read/write) indicator to identify the device and direction of the \ntransaction. Thus when using this API, you should use a 7-bit address\nin the data structure and ensure that address is a value between 0-127. As an example, consider an I\u00b2C device address that looks like this: B7 B6 B5 B4 B3 B2 B1 B0 1 0 0 0 1 1 0 R/W MSB LSB In the HAL_I2C API you would communicate with this device with address 0b1000110 , which is h
ex 0x46 or decimal 70. The I\u00b2C drive would add the R/W bit\nand transmit it as hex 0x8C (binary 10001100) or 0x8D (binary 10001101) depending whether it was a read or\nwrite command.",
"title": "HAL_I2C Data"
},
{
- "location": "/os/modules/hal/hal_pwm/hal_pwm/",
- "text": "hal_pwm\n\n\nThe hardware independent interface to Pulse Width Modulators\n\n\nDescription\n\n\nPulse Width Modulators (PWMs) are hardware devices that output digital waveforms\nwith programmable duty cycle and frequency. They use a digital waveform\nbut can contiuously adjust the amount of power delivered to their load via\nduty cycle. They are often used to create analog waveforms via low pass filter, \ndrive LEDs at various intensities, and control DC or servo motors.\n\n\nFor a description of PSM, see \nwikipedia\n\n\nDefinition\n\n\nhal_pwm.h\n\n\nHAL_PWM Theory Of Operation\n\n\nThe HAL_PWM interface was designed with some specific use cases in mind. It\nwas also designed to exploit a subset of the functionality provided by \ncommon PWM controllers.\n\n\nFundamentally, a PWM has at it root an N-bit COUNTER, a CLOCK source, one or \nmore CAPTURE registers, and sometimes a TOP register.\n\n\nThe clock source feeds the COUNTER register which is continuousl
y counting\n(up or down), When the COUNTER is less than the value of the CAPTURE\nregister, the PWM outputs a logic HIGH. When the counter is greater than\nthe CAPTURE register the PWM outputs logic LOW. When the counter reaches the TOP\nregister, it wraps back to zero. If the PWM has no TOP register, it simply\nwraps back to zero after reaching 2^N-1.\n\n\nThe HAL_PWM abstracts this implementation and provides methods to set the\nPWM frequency and duty cycle. The frequency is the rate at which the counter\nwraps back to zero. The duty cycle is the fraction of time the PWM is in \nlogic HIGH state.\n\n\nThe HAL_PWM API provides a few methods to get information on the PWM.\n\n\n\n\n\n\n\n\nMethod Name\n\n\n Description \n\n\n\n\n\n\n\n\n\n\nhal_pwm_get_source_clock_freq\n\n\ngets the frequency of the CLOCK that is driving the COUNTER\n\n\n\n\n\n\nhal_pwm_get_resolution_bits\n\n\ngets the number of bits in the COUNTER\n\n\n\n\n\n\n\n\nTo use a PWM via HAL_PWM, follow these simple
steps.\n\n\n1) initialize a PWM using \nhal_pwm_init\n -- this binds the driver to the device\nfor the specific PWM you are using\n2) Optionally set the frequency of the PWM using \nhal_pwm_set_frequency\n\n-- PWMs that support a TOP register have fine control over their frequency \nsettings. If this command is not supported by the PWM it will return an error \nand its likely that there is no TOP register; the frequency resolution is not \nfinely adjustable. See the BSP for coarse adjustment of the PWM frequency.\n\n3) Enable the PWM to output a specific duty cycle using the \n\nhal_pwm_enable_duty_cycle\n API\n\n\nTo change the duty cycle dynamically, just issue another \n\nhal_pwm_enable_duty_cycle\n command.\n\n\nTo disable the PWM waveform, use \nhal_pwm_disable\n.",
- "title": "PWM"
+ "location": "/os/modules/hal/hal_os_tick/hal_os_tick/",
+ "text": "hal_os_tick\n\n\nThe hardware independent interface to set up interrupt timers or halt CPU in terms of OS ticks.\n\n\nDescription\n\n\nSet up the periodic timer to interrupt at a frequency of 'os_ticks_per_sec' using the following function call where 'prio' is the cpu-specific priority of the periodic timer interrupt. \n\n\nvoid\n \nos_tick_init\n(\nuint32_t\n \nos_ticks_per_sec\n, \nint\n \nprio\n);\n\n\n\n\n\nYou can halt CPU for up to \nn\n ticks:\n\n\nvoid\n \nos_tick_idle\n(\nos_time_t\n \nn\n);\n\n\n\n\n\nThe function implementations are in the mcu-specific directories such as \nhw/mcu/nordic/nrf51xxx/src/hal_os_tick.c\n.\n\n\nDefinition\n\n\nhal_os_tick.h\n\n\nExamples\n\n\nAn example of the API being used by the OS kernel for the Cortex M0 architecture to initialize and start the system clock timer can be seen in \nkernel/os/src/arch/cortex_m0/os_arch_arm.c\n.",
+ "title": "OS Tick"
},
{
- "location": "/os/modules/hal/hal_pwm/hal_pwm/#hal_pwm",
- "text": "The hardware independent interface to Pulse Width Modulators",
- "title": "hal_pwm"
+ "location": "/os/modules/hal/hal_os_tick/hal_os_tick/#hal_os_tick",
+ "text": "The hardware independent interface to set up interrupt timers or halt CPU in terms of OS ticks.",
+ "title": "hal_os_tick"
},
{
- "location": "/os/modules/hal/hal_pwm/hal_pwm/#description",
- "text": "Pulse Width Modulators (PWMs) are hardware devices that output digital waveforms\nwith programmable duty cycle and frequency. They use a digital waveform\nbut can contiuously adjust the amount of power delivered to their load via\nduty cycle. They are often used to create analog waveforms via low pass filter, \ndrive LEDs at various intensities, and control DC or servo motors. For a description of PSM, see wikipedia",
+ "location": "/os/modules/hal/hal_os_tick/hal_os_tick/#description",
+ "text": "Set up the periodic timer to interrupt at a frequency of 'os_ticks_per_sec' using the following function call where 'prio' is the cpu-specific priority of the periodic timer interrupt. void os_tick_init ( uint32_t os_ticks_per_sec , int prio ); You can halt CPU for up to n ticks: void os_tick_idle ( os_time_t n ); The function implementations are in the mcu-specific directories such as hw/mcu/nordic/nrf51xxx/src/hal_os_tick.c .",
"title": "Description"
},
{
- "location": "/os/modules/hal/hal_pwm/hal_pwm/#definition",
- "text": "hal_pwm.h",
+ "location": "/os/modules/hal/hal_os_tick/hal_os_tick/#definition",
+ "text": "hal_os_tick.h",
"title": "Definition"
},
{
- "location": "/os/modules/hal/hal_pwm/hal_pwm/#hal_pwm-theory-of-operation",
- "text": "The HAL_PWM interface was designed with some specific use cases in mind. It\nwas also designed to exploit a subset of the functionality provided by \ncommon PWM controllers. Fundamentally, a PWM has at it root an N-bit COUNTER, a CLOCK source, one or \nmore CAPTURE registers, and sometimes a TOP register. The clock source feeds the COUNTER register which is continuously counting\n(up or down), When the COUNTER is less than the value of the CAPTURE\nregister, the PWM outputs a logic HIGH. When the counter is greater than\nthe CAPTURE register the PWM outputs logic LOW. When the counter reaches the TOP\nregister, it wraps back to zero. If the PWM has no TOP register, it simply\nwraps back to zero after reaching 2^N-1. The HAL_PWM abstracts this implementation and provides methods to set the\nPWM frequency and duty cycle. The frequency is the rate at which the counter\nwraps back to zero. The duty cycle is the fraction of time the PWM is in \nlogic HIGH sta
te. The HAL_PWM API provides a few methods to get information on the PWM. Method Name Description hal_pwm_get_source_clock_freq gets the frequency of the CLOCK that is driving the COUNTER hal_pwm_get_resolution_bits gets the number of bits in the COUNTER To use a PWM via HAL_PWM, follow these simple steps. 1) initialize a PWM using hal_pwm_init -- this binds the driver to the device\nfor the specific PWM you are using\n2) Optionally set the frequency of the PWM using hal_pwm_set_frequency \n-- PWMs that support a TOP register have fine control over their frequency \nsettings. If this command is not supported by the PWM it will return an error \nand its likely that there is no TOP register; the frequency resolution is not \nfinely adjustable. See the BSP for coarse adjustment of the PWM frequency. \n3) Enable the PWM to output a specific duty cycle using the hal_pwm_enable_duty_cycle API To change the duty cycle dynamically, just issue another hal_pwm_
enable_duty_cycle command. To disable the PWM waveform, use hal_pwm_disable .",
- "title": "HAL_PWM Theory Of Operation"
+ "location": "/os/modules/hal/hal_os_tick/hal_os_tick/#examples",
+ "text": "An example of the API being used by the OS kernel for the Cortex M0 architecture to initialize and start the system clock timer can be seen in kernel/os/src/arch/cortex_m0/os_arch_arm.c .",
+ "title": "Examples"
},
{
"location": "/os/modules/hal/hal_spi/hal_spi/",
- "text": "hal_spi\n\n\nSPI (Serial Peripheral Interface) is a synchronous 4-wire serial interface\ncommonly used to connect components in embedded systems.\n\n\nFor a detailed description of SPI, see \nWikipedia\n.\n\n\nDescription\n\n\nThe Mynewt HAL interface supports the SPI master functionality only. Future\nversion will support SPI slave functionality.\n\n\nDefinition\n\n\nhal_spi.h\n\n\nHAL_SPI Theory Of Operation\n\n\nSPI is called a 4-wire interface because of the 4 signals, MISO, MOSI, CLK, \nand SS. The SS signal (slave select) is an active low signal that activates\na SPI slave device. This is how a master \"addresses\" a particular slave\ndevice. Often this signal is also referred to as \"chip select\" as it\nselects particular slave device for communications.\n\n\nThe Mynewt SPI HAL has blocking transfers. This means that the API call\nto transfer a byte will wait until the byte completes transmissions before\nthe function returns.\n\n\nSince SPI is gene
rally a shared communications bus, the hal_spi API allows\nSPI runtime configuration to be compatible with the data format and speed of the \nslave device. See the \nhal_spi_config\n method in the API above for a \ndescription of the available settings. These settings are critical to the\noperation of the slave device.\n\n\nThe Mynewt SPI HAL does not include built-in SS signaling. Its up to the \nhal_spi user to control their own SS pins. Typically applications will do \nthis with GPIO.\n\n\nAn example of this would look like this (error handling excluded for brevity):\n\n\n /* each device may have different settings */\n extern struct hal_spi_settings dev1; \n extern struct hal_spi_settings dev2;\n\n gpio_init_out(SS_DEV_1, 1);\n gpio_init_out(SS_DEV_2, 1);\n hal_spi *pspi = hal_spi_init(SPI0);\n\n ...\n /* write a single byte (0) to device 1 */\n hal_spi_config(pspi, \ndev1);\n gpio_clear(SS_DEV_1)\n
rc = hal_spi_transfer(pspi, 0)\n gpio_set(SS_DEV_1)\n\n /* read a single byte from device 2 */\n hal_spi_config(pspi, \ndev2);\n gpio_clear(SS_DEV_2)\n val = hal_spi_transfer(pspi, 0)\n gpio_set(SS_DEV_2)\n\n\n\n\n\nDepending on the device's operation, it may be necessary or more efficient\nto write or read multiple bytes in a single transaction. An example is\nshown below\n\n\n```no-highlight\n\n\nvoid spi_write_buf(struct hal_spi *pspi, uint8_t *buf, int len) {\n char *ptr = buf;\n\n hal_spi_config(pspi, \ndev2);\n gpio_clear(SS_DEV_2)\n while(len-- \n 0) {\n val = hal_spi_transfer(pspi, (uint16_t) *ptr++)\n }\n gpio_set(SS_DEV_2)\n}",
+ "text": "hal_spi\n\n\nSPI (Serial Peripheral Interface) is a synchronous 4-wire serial interface\ncommonly used to connect components in embedded systems.\n\n\nFor a detailed description of SPI, see \nWikipedia\n.\n\n\nDescription\n\n\nThe Mynewt HAL interface supports the SPI master functionality with both blocking and non-blocking interface. SPI slave functionality is supported in non-blocking mode.\n\n\nDefinition\n\n\nhal_spi.h\n\n\nHAL_SPI Theory Of Operation\n\n\nSPI is called a 4-wire interface because of the 4 signals, MISO, MOSI, CLK, \nand SS. The SS signal (slave select) is an active low signal that activates\na SPI slave device. This is how a master \"addresses\" a particular slave\ndevice. Often this signal is also referred to as \"chip select\" as it\nselects particular slave device for communications.\n\n\nThe Mynewt SPI HAL has blocking and non-blocking transfers. Blocking means that the API call\nto transfer a byte will wait until the byte completes
transmissions before\nthe function returns. Blocking interface can be used for only the master slave SPI type.\nNon-blocking means he function returns control to the execution environment immediately after the API call and a callback function is executed at the completion of the transmission. Non-blocking interface can be used for both master and slave SPI types.\n\n\nThe \nhal_spi_config\n method in the API above allows the SPI to be configured with appropriate settings for master or slave. It Must be called after the spi is initialized (i.e. after hal_spi_init is called) and when the spi is disabled (i.e. user must call hal_spi_disable if the spi has been enabled through hal_spi_enable prior to calling this function). It can also be used to reconfigure an initialized SPI (assuming it is disabled as described previously).\n\n\nint\n \nhal_spi_config\n(\nint\n \nspi_num\n, \nstruct\n \nhal_spi_settings\n \n*psettings\n);\n\n\n\n\n\nThe SPI settings consist of the following:\n\n\nst
ruct\n \nhal_spi_settings\n {\n \nuint8_t\n \ndata_mode\n;\n \nuint8_t\n \ndata_order\n;\n \nuint8_t\n \nword_size\n;\n \nuint32_t\n \nbaudrate\n; \n/* baudrate in kHz */\n\n};\n\n\n\n\n\nThe Mynewt SPI HAL does not include built-in SS (Slave Select) signaling. It's up to the \nhal_spi user to control their own SS pins. Typically applications will do \nthis with GPIO.",
"title": "SPI"
},
{
@@ -6517,7 +6487,7 @@
},
{
"location": "/os/modules/hal/hal_spi/hal_spi/#description",
- "text": "The Mynewt HAL interface supports the SPI master functionality only. Future\nversion will support SPI slave functionality.",
+ "text": "The Mynewt HAL interface supports the SPI master functionality with both blocking and non-blocking interface. SPI slave functionality is supported in non-blocking mode.",
"title": "Description"
},
{
@@ -6527,17 +6497,62 @@
},
{
"location": "/os/modules/hal/hal_spi/hal_spi/#hal_spi-theory-of-operation",
- "text": "SPI is called a 4-wire interface because of the 4 signals, MISO, MOSI, CLK, \nand SS. The SS signal (slave select) is an active low signal that activates\na SPI slave device. This is how a master \"addresses\" a particular slave\ndevice. Often this signal is also referred to as \"chip select\" as it\nselects particular slave device for communications. The Mynewt SPI HAL has blocking transfers. This means that the API call\nto transfer a byte will wait until the byte completes transmissions before\nthe function returns. Since SPI is generally a shared communications bus, the hal_spi API allows\nSPI runtime configuration to be compatible with the data format and speed of the \nslave device. See the hal_spi_config method in the API above for a \ndescription of the available settings. These settings are critical to the\noperation of the slave device. The Mynewt SPI HAL does not include built-in SS signaling. Its up to the \nhal_spi user to control their
own SS pins. Typically applications will do \nthis with GPIO. An example of this would look like this (error handling excluded for brevity): /* each device may have different settings */\n extern struct hal_spi_settings dev1; \n extern struct hal_spi_settings dev2;\n\n gpio_init_out(SS_DEV_1, 1);\n gpio_init_out(SS_DEV_2, 1);\n hal_spi *pspi = hal_spi_init(SPI0);\n\n ...\n /* write a single byte (0) to device 1 */\n hal_spi_config(pspi, dev1);\n gpio_clear(SS_DEV_1)\n rc = hal_spi_transfer(pspi, 0)\n gpio_set(SS_DEV_1)\n\n /* read a single byte from device 2 */\n hal_spi_config(pspi, dev2);\n gpio_clear(SS_DEV_2)\n val = hal_spi_transfer(pspi, 0)\n gpio_set(SS_DEV_2) Depending on the device's operation, it may be necessary or more efficient\nto write or read multiple bytes in a single transaction. An example is\nshown below ```no-highlight void spi_writ
e_buf(struct hal_spi *pspi, uint8_t *buf, int len) {\n char *ptr = buf;\n\n hal_spi_config(pspi, dev2);\n gpio_clear(SS_DEV_2)\n while(len-- 0) {\n val = hal_spi_transfer(pspi, (uint16_t) *ptr++)\n }\n gpio_set(SS_DEV_2)\n}",
+ "text": "SPI is called a 4-wire interface because of the 4 signals, MISO, MOSI, CLK, \nand SS. The SS signal (slave select) is an active low signal that activates\na SPI slave device. This is how a master \"addresses\" a particular slave\ndevice. Often this signal is also referred to as \"chip select\" as it\nselects particular slave device for communications. The Mynewt SPI HAL has blocking and non-blocking transfers. Blocking means that the API call\nto transfer a byte will wait until the byte completes transmissions before\nthe function returns. Blocking interface can be used for only the master slave SPI type.\nNon-blocking means he function returns control to the execution environment immediately after the API call and a callback function is executed at the completion of the transmission. Non-blocking interface can be used for both master and slave SPI types. The hal_spi_config method in the API above allows the SPI to be configured with appropriate settings
for master or slave. It Must be called after the spi is initialized (i.e. after hal_spi_init is called) and when the spi is disabled (i.e. user must call hal_spi_disable if the spi has been enabled through hal_spi_enable prior to calling this function). It can also be used to reconfigure an initialized SPI (assuming it is disabled as described previously). int hal_spi_config ( int spi_num , struct hal_spi_settings *psettings ); The SPI settings consist of the following: struct hal_spi_settings {\n uint8_t data_mode ;\n uint8_t data_order ;\n uint8_t word_size ;\n uint32_t baudrate ; /* baudrate in kHz */ \n}; The Mynewt SPI HAL does not include built-in SS (Slave Select) signaling. It's up to the \nhal_spi user to control their own SS pins. Typically applications will do \nthis with GPIO.",
"title": "HAL_SPI Theory Of Operation"
},
{
"location": "/os/modules/hal/hal_system/hal_sys/",
- "text": "",
+ "text": "hal_system\n\n\nA hardware independent interface for starting and resetting the system.\n\n\nDescription\n\n\nThe API allows the user to detect whether a debugger is connected, sissue a soft reset, and enumerate the reset causes. The functions are implemented in the MCU specific directories e.g. \nhal_reset_cause.c\n, \nhal_system.c\n, and \nhal_system_start.c\n in \n/hw/mcu/nordic/nrf52xxx/src/\n directory for Nordic nRF52 series of chips.\n\n\nDefinition\n\n\nhal_system.h\n\n\nExamples",
"title": "System"
},
{
+ "location": "/os/modules/hal/hal_system/hal_sys/#hal_system",
+ "text": "A hardware independent interface for starting and resetting the system.",
+ "title": "hal_system"
+ },
+ {
+ "location": "/os/modules/hal/hal_system/hal_sys/#description",
+ "text": "The API allows the user to detect whether a debugger is connected, sissue a soft reset, and enumerate the reset causes. The functions are implemented in the MCU specific directories e.g. hal_reset_cause.c , hal_system.c , and hal_system_start.c in /hw/mcu/nordic/nrf52xxx/src/ directory for Nordic nRF52 series of chips.",
+ "title": "Description"
+ },
+ {
+ "location": "/os/modules/hal/hal_system/hal_sys/#definition",
+ "text": "hal_system.h",
+ "title": "Definition"
+ },
+ {
+ "location": "/os/modules/hal/hal_system/hal_sys/#examples",
+ "text": "",
+ "title": "Examples"
+ },
+ {
+ "location": "/os/modules/hal/hal_timer/hal_timer/",
+ "text": "hal_timer\n\n\nThe hardware independent timer structure and API to configure, initialize, and run timers.\n\n\nDescription\n\n\nThe HAL timer structure is shown below. The user can declare as many of these structures as required. They are enqueued on a particular HW timer queue when the user calls the hal_timer_start or hal_timer_start_at API. The user must have called hal_timer_set_cb before starting a timer.\n\n\nNOTE: the user should not have to modify/examine the contents of this structure; the hal timer API should be used.\n\n\nstruct\n \nhal_timer\n\n{\n \nvoid\n \n*bsp_timer\n; \n/* Internal platform specific pointer */\n\n \nhal_timer_cb\n \ncb_func\n; \n/* Callback function */\n\n \nvoid\n \n*cb_arg\n; \n/* Callback argument */\n\n \nuint32_t\n \nexpiry\n; \n/* Tick at which timer should expire */\n\n \nTAILQ_ENTRY\n(\nhal_timer\n) \nlink\n; \n/* Queue linked list structure */\n
\n};\n\n\n\n\n\nDefinition\n\n\nhal_timer.h\n\n\nExamples",
+ "title": "Timer"
+ },
+ {
+ "location": "/os/modules/hal/hal_timer/hal_timer/#hal_timer",
+ "text": "The hardware independent timer structure and API to configure, initialize, and run timers.",
+ "title": "hal_timer"
+ },
+ {
+ "location": "/os/modules/hal/hal_timer/hal_timer/#description",
+ "text": "The HAL timer structure is shown below. The user can declare as many of these structures as required. They are enqueued on a particular HW timer queue when the user calls the hal_timer_start or hal_timer_start_at API. The user must have called hal_timer_set_cb before starting a timer. NOTE: the user should not have to modify/examine the contents of this structure; the hal timer API should be used. struct hal_timer \n{\n void *bsp_timer ; /* Internal platform specific pointer */ \n hal_timer_cb cb_func ; /* Callback function */ \n void *cb_arg ; /* Callback argument */ \n uint32_t expiry ; /* Tick at which timer should expire */ \n TAILQ_ENTRY ( hal_timer ) link ; /* Queue linked list structure */ \n};",
+ "title": "Description"
+ },
+ {
+ "location": "/os/modules/hal/hal_timer/hal_timer/#definition",
+ "text": "hal_timer.h",
+ "title": "Definition"
+ },
+ {
+ "location": "/os/modules/hal/hal_timer/hal_timer/#examples",
+ "text": "",
+ "title": "Examples"
+ },
+ {
"location": "/os/modules/hal/hal_uart/hal_uart/",
- "text": "hal_uart\n\n\nThe hardware independent UART interface for Mynewt.\n\n\nDescription\n\n\nContains the basic operations to send and receive data over a UART\n(Universal Asynchronous Receiver Transmitter).\n\n\nDefinition\n\n\nhal_uart.h\n\n\nExamples\n\n\nThis example shows a user writing a character to the uart\n\n\n/* write to the console with blocking */\n{\n char *str = \nHello World!\n;\n char *ptr = str;\n\n while(*ptr) {\n hal_uart_blocking_tx(MY_UART, *ptr++);\n }\n hal_uart_blocking_tx(MY_UART, \n\\n\n);\n}",
+ "text": "hal_uart\n\n\nThe hardware independent UART interface for Mynewt.\n\n\nDescription\n\n\nContains the basic operations to send and receive data over a UART\n(Universal Asynchronous Receiver Transmitter). It also includes the API to apply settings such as speed, parity etc. to the UART. The UART port should be closed before any reconfiguring. \n\n\nDefinition\n\n\nhal_uart.h\n\n\nExamples\n\n\nThis example shows a user writing a character to the uart in blocking mode where the UART has to block until character has been sent.\n\n\n/* write to the console with blocking */\n{\n char *str = \nHello World!\n;\n char *ptr = str;\n\n while(*ptr) {\n hal_uart_blocking_tx(MY_UART, *ptr++);\n }\n hal_uart_blocking_tx(MY_UART, \n\\n\n);\n}",
"title": "UART"
},
{
@@ -6547,7 +6562,7 @@
},
{
"location": "/os/modules/hal/hal_uart/hal_uart/#description",
- "text": "Contains the basic operations to send and receive data over a UART\n(Universal Asynchronous Receiver Transmitter).",
+ "text": "Contains the basic operations to send and receive data over a UART\n(Universal Asynchronous Receiver Transmitter). It also includes the API to apply settings such as speed, parity etc. to the UART. The UART port should be closed before any reconfiguring.",
"title": "Description"
},
{
@@ -6557,22 +6572,47 @@
},
{
"location": "/os/modules/hal/hal_uart/hal_uart/#examples",
- "text": "This example shows a user writing a character to the uart /* write to the console with blocking */\n{\n char *str = Hello World! ;\n char *ptr = str;\n\n while(*ptr) {\n hal_uart_blocking_tx(MY_UART, *ptr++);\n }\n hal_uart_blocking_tx(MY_UART, \\n );\n}",
+ "text": "This example shows a user writing a character to the uart in blocking mode where the UART has to block until character has been sent. /* write to the console with blocking */\n{\n char *str = Hello World! ;\n char *ptr = str;\n\n while(*ptr) {\n hal_uart_blocking_tx(MY_UART, *ptr++);\n }\n hal_uart_blocking_tx(MY_UART, \\n );\n}",
+ "title": "Examples"
+ },
+ {
+ "location": "/os/modules/hal/hal_watchdog/hal_watchdog/",
+ "text": "hal_watchdog\n\n\nThe hardware independent interface to enable internal hardware watchdogs.\n\n\nDescription\n\n\nThe \nhal_watchdog_init\n interface can be used to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds. \n\n\nint\n \nhal_watchdog_init\n(\nuint32_t\n \nexpire_msecs\n);\n\n\n\n\n\nWatchdog needs to be then started with a call to \nhal_watchdog_enable()\n.\nWatchdog should be tickled periodically with a frequency smaller than 'expire_secs' using \nhal_watchdog_tickle()\n.\n\n\nDefinition\n\n\nhal_watchdog\n\n\nExamples\n\n\nThe OS initializes and starts a watchdog timer and tickles it periodically to check that the OS is running properly. This can be seen in \n/kernel/os/src/os.c\n.",
+ "title": "Watchdog"
+ },
+ {
+ "location": "/os/modules/hal/hal_watchdog/hal_watchdog/#hal_watchdog",
+ "text": "The hardware independent interface to enable internal hardware watchdogs.",
+ "title": "hal_watchdog"
+ },
+ {
+ "location": "/os/modules/hal/hal_watchdog/hal_watchdog/#description",
+ "text": "The hal_watchdog_init interface can be used to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds. int hal_watchdog_init ( uint32_t expire_msecs ); Watchdog needs to be then started with a call to hal_watchdog_enable() .\nWatchdog should be tickled periodically with a frequency smaller than 'expire_secs' using hal_watchdog_tickle() .",
+ "title": "Description"
+ },
+ {
+ "location": "/os/modules/hal/hal_watchdog/hal_watchdog/#definition",
+ "text": "hal_watchdog",
+ "title": "Definition"
+ },
+ {
+ "location": "/os/modules/hal/hal_watchdog/hal_watchdog/#examples",
+ "text": "The OS initializes and starts a watchdog timer and tickles it periodically to check that the OS is running properly. This can be seen in /kernel/os/src/os.c .",
"title": "Examples"
},
{
"location": "/os/modules/hal/hal_in_libraries/",
- "text": "Using HAL in Your Libraries\n\n\nThis page describes the recommended way to implement libraries that \nutilize HAL functionality.\n\n\nConsider the light switch example from the \nHAL overview\n page.\n\n\nThe light switch module needs a GPIO pin to set\nthe light switch to on or off. The module declares that the GPIO to \ncontrol the light switch is declared elsewhere in one of two methods.\n\n\n extern const int light_switch_gpio;\n\n\n\n\n\nor\n\n\n extern int bsp_light_app_get_light_gpio();\n\n\n\n\n\nWhich method a library uses \n(extern const versus function) depends on what functionality the library\nmight wish to declare. The \nextern const\n model uses the smallest code \nfootprint, but since its constant cannot be changed at runtime (based on \nthe configuration of the device say). The \nextern function\n call requires\nthe BSP to implement a function which allows flexibility to assign the \nGPIO for the light switch to be determined at runtime
with a small expense of\nslightly more code.\n\n\nThen the \nlibs/light\n would go on to use the specified GPIO during its runtime\nexecution. For example this shows both ways the library could interface to the \nbsp to get the right GPIO:\n\n\n void light_on(void) {\n . . .\n /* finally time to turn the light on */\n hal_gpio_set(light_switch_gpio);\n }\n\n void light_on(void) {\n . . .\n int pin = bsp_light_app_get_light_gpio();\n /* finally time to turn the light on */\n hal_gpio_set(pin);\n }\n\n\n\n\n\nWhen you library user includes \nlibs/light\n as a dependency and then builds\nwith \nnewt\n, they will get an unresolved external for either \nlight_switch_gpio\n \nor \nbsp_light_app_get_light_gpio()\n and will need to add to their BSP.\n\n\nIn their BSP, they can add \n\n\n const int light_switch_gpio = 5;\n\n\n\n\n\nor\n\n\n int bsp_light_app_get_light_gpio(void) {\n return my_configured_lightswitch_io()
;\n }\n\n\n\n\n\nSo where did the number \n5\n come from. Their BSP already includes the specific\nMCU that they are using. And their \nmcu/xxx/hal_gpio.c\n already defines \nthe mapping between physical pins and the virtual device ids. \n\n\nThe user can determine (when writing code) from their boards physical pinmap \nand from the \nhal_gpio.c\n MCU mapping which virtual device_id corresponds \nto the correct physical pin in their system.",
+ "text": "Using HAL in Your Libraries\n\n\nThis page describes the recommended way to implement libraries that \nutilize HAL functionality.\n\n\nAn example of the GPIO HAL being used by a driver for a UART bitbanger that programs the start bit, data bits, and stop bit can be seen in \nhw/drivers/uart/uart_bitbang/src/uart_bitbang.c\n\n\nAn example of the flash HAL being used by a file sytem can be seen in \nfs/nffs/src/nffs_flash.c\n.",
"title": "Using HAL"
},
{
"location": "/os/modules/hal/hal_in_libraries/#using-hal-in-your-libraries",
- "text": "This page describes the recommended way to implement libraries that \nutilize HAL functionality. Consider the light switch example from the HAL overview page. The light switch module needs a GPIO pin to set\nthe light switch to on or off. The module declares that the GPIO to \ncontrol the light switch is declared elsewhere in one of two methods. extern const int light_switch_gpio; or extern int bsp_light_app_get_light_gpio(); Which method a library uses \n(extern const versus function) depends on what functionality the library\nmight wish to declare. The extern const model uses the smallest code \nfootprint, but since its constant cannot be changed at runtime (based on \nthe configuration of the device say). The extern function call requires\nthe BSP to implement a function which allows flexibility to assign the \nGPIO for the light switch to be determined at runtime with a small expense of\nslightly more code. Then the libs/light would
go on to use the specified GPIO during its runtime\nexecution. For example this shows both ways the library could interface to the \nbsp to get the right GPIO: void light_on(void) {\n . . .\n /* finally time to turn the light on */\n hal_gpio_set(light_switch_gpio);\n }\n\n void light_on(void) {\n . . .\n int pin = bsp_light_app_get_light_gpio();\n /* finally time to turn the light on */\n hal_gpio_set(pin);\n } When you library user includes libs/light as a dependency and then builds\nwith newt , they will get an unresolved external for either light_switch_gpio \nor bsp_light_app_get_light_gpio() and will need to add to their BSP. In their BSP, they can add con
<TRUNCATED>