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 23:53:08 UTC
[2/6] incubator-mynewt-site git commit: modifications to hal
documentation, addition of driver overview
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_flash/hal_flash.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_flash/hal_flash.md b/docs/os/modules/hal/hal_flash/hal_flash.md
index e69de29..821e849 100644
--- a/docs/os/modules/hal/hal_flash/hal_flash.md
+++ b/docs/os/modules/hal/hal_flash/hal_flash.md
@@ -0,0 +1,18 @@
+# hal_flash
+
+The hardware independent interface to flash memory that is used by applications.
+
+###Description
+
+The API offers basic initialization, read, write, erase, sector erase, and other operations.
+
+###Definition
+
+[hal_flash.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_flash.h)
+
+###Examples
+
+
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_flash/hal_flash_int.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_flash/hal_flash_int.md b/docs/os/modules/hal/hal_flash/hal_flash_int.md
index e69de29..0696482 100644
--- a/docs/os/modules/hal/hal_flash/hal_flash_int.md
+++ b/docs/os/modules/hal/hal_flash/hal_flash_int.md
@@ -0,0 +1,33 @@
+# hal_flash_int
+
+The API that flash drivers have to implement.
+
+###Description
+
+The BSP for the hardware will implement the structs defined in this API.
+
+###Definition
+
+[hal_flash_int.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_flash_int.h)
+
+###Examples
+
+The Nordic nRF52 bsp implements the hal_flash_int API as seen in [hal_bsp.c](https://github.com/apache/incubator-mynewt-core/blob/master/hw/bsp/stm32f4discovery/src/hal_bsp.c)
+
+```
+const struct hal_flash *
+hal_bsp_flash_dev(uint8_t id)
+{
+ /*
+ * Internal flash mapped to id 0.
+ */
+ if (id != 0) {
+ return NULL;
+ }
+ return &nrf52k_flash_dev;
+}
+
+```
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_flash/hal_flash_map.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_flash/hal_flash_map.md b/docs/os/modules/hal/hal_flash/hal_flash_map.md
deleted file mode 100644
index e69de29..0000000
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_gpio/hal_gpio.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_gpio/hal_gpio.md b/docs/os/modules/hal/hal_gpio/hal_gpio.md
index a8d6af6..503f374 100644
--- a/docs/os/modules/hal/hal_gpio/hal_gpio.md
+++ b/docs/os/modules/hal/hal_gpio/hal_gpio.md
@@ -8,7 +8,7 @@ This is the hardware independent GPIO (General Purpose Input Output) Interface f
Contains the basic operations to set and read General Purpose Digital I/O Pins
within 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.
+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.
@@ -23,7 +23,7 @@ This translation is defined in the MCU implementation of
for the stmf32F4xx. Each MCU will typically have a different translation method
depending 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
+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,
```no-highlight
#define SYSTEM_LED (37)
@@ -40,15 +40,15 @@ SYSTEM_LED --> hal_gpio virtual pin 37 --> port C pin 5 on the stm34F4xx
### Definition
-[hal_gpio.h](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_gpio.h)
+[hal_gpio.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_gpio.h)
### Examples
#### Blinky
-Blinky uses the hal_gpio to blink the system LED. The blinky source code is available
-[here](https://github.com/apache/incubator-mynewt-core/blob/master/apps/blinky/src/main.c).
-Examine how `task1_handler` initializes and toggles the GPIO to control the LED.
+Blinky uses the hal_gpio to blink the system LED. The blinky source code is available in the
+[blinky repo](https://github.com/apache/incubator-mynewt-blinky/blob/master/apps/blinky/src/main.c).
+Examine how `blinky_task_handler` initializes and toggles the GPIO to control the LED.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_i2c/hal_i2c.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_i2c/hal_i2c.md b/docs/os/modules/hal/hal_i2c/hal_i2c.md
index 3b713c5..10f8bb3 100644
--- a/docs/os/modules/hal/hal_i2c/hal_i2c.md
+++ b/docs/os/modules/hal/hal_i2c/hal_i2c.md
@@ -1,6 +1,5 @@
# hal_i2c
-
The hardware independent interface to I2C Devices.
###Description
@@ -16,7 +15,7 @@ For a detailed description of I2C, see the [I�C wikipedia page](https://en.wiki
###Definition
-[hal_i2c.h](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_i2c.h)
+[hal_i2c.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_i2c.h)
###HAL_I2C Theory Of Operation
@@ -28,11 +27,24 @@ the same peripheral.
HAL_I2C implements a master interface to the I�C bus. Typical usage of the
interface would involve the following steps.
-1. initialize an I�C device using `hal_i2c_init`
-2. when you want to perform an I�C transaction:
- 1. Issue the `hal_i2c_begin()` command.
- 2. Issue one or more `hal_i2c_read` and/or `hal_i2c_write` commands
- 3. Issue the `hal_i2c_end()` command.
+Initialize an i2c device with:
+ hal_i2c_init()
+
+When you wish to perform an i2c transaction, you call one or both of:
+ hal_i2c_master_write();
+ hal_i2c_master_read();
+
+ These functions will issue a START condition, followed by the device's
+7-bit I2C address, and then send or receive the payload based on the data
+provided. This will cause a repeated start on the bus, which is valid in
+I2C specification, and the decision to use repeated starts was made to
+simplify the I2C HAL. To set the STOP condition at an appropriate moment,
+you 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
+then read data back via:
+ hal_i2c_write(); -- write to a specific register on the device
+ 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
@@ -40,6 +52,8 @@ from a specific bus address. its intended to provide an easy way to probe
the bus for a specific device. NOTE: if the device is write-only, it will
not appear with this command.
+A slave API is pending for further release.
+
###HAL_I2C Data
Data to read/write is passed to the hal_i2c APIs via the
@@ -70,7 +84,7 @@ As an example, consider an I�C device address that looks like this:
In the HAL_I2C API you would communicate with this device with address
`0b1000110`, which is hex 0x46 or decimal 70. The I�C drive would add the R/W bit
-and transmit it as hex 0x8D or 0x8D depending whether it was a read or
+and transmit it as hex 0x8C (binary 10001100) or 0x8D (binary 10001101) depending whether it was a read or
write command.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_in_libraries.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_in_libraries.md b/docs/os/modules/hal/hal_in_libraries.md
index 6065dbf..fb17270 100644
--- a/docs/os/modules/hal/hal_in_libraries.md
+++ b/docs/os/modules/hal/hal_in_libraries.md
@@ -4,73 +4,10 @@
This page describes the recommended way to implement libraries that
utilize HAL functionality.
-Consider the light switch example from the [HAL overview](hal.md) page.
-The light switch module needs a GPIO pin to set
-the light switch to on or off. The module declares that the GPIO to
-control the light switch is declared elsewhere in one of two methods.
+An 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 [hw/drivers/uart/uart_bitbang/src/uart_bitbang.c](https://github.com/apache/incubator-mynewt-core/blob/master/hw/drivers/uart/uart_bitbang/src/uart_bitbang.c)
-```no-highlight
- extern const int light_switch_gpio;
-```
-or
+An example of the flash HAL being used by a file sytem can be seen in [fs/nffs/src/nffs_flash.c](https://github.com/apache/incubator-mynewt-core/blob/master/fs/nffs/src/nffs_flash.c).
-```no-highlight
- extern int bsp_light_app_get_light_gpio();
-```
-Which method a library uses
-(extern const versus function) depends on what functionality the library
-might wish to declare. The `extern const` model uses the smallest code
-footprint, but since its constant cannot be changed at runtime (based on
-the configuration of the device say). The `extern function` call requires
-the BSP to implement a function which allows flexibility to assign the
-GPIO for the light switch to be determined at runtime with a small expense of
-slightly more code.
-
-Then the `libs/light` would go on to use the specified GPIO during its runtime
-execution. For example this shows both ways the library could interface to the
-bsp to get the right GPIO:
-
-```no-highlight
- void light_on(void) {
- . . .
- /* finally time to turn the light on */
- hal_gpio_set(light_switch_gpio);
- }
-
- void light_on(void) {
- . . .
- int pin = bsp_light_app_get_light_gpio();
- /* finally time to turn the light on */
- hal_gpio_set(pin);
- }
-```
-
-When you library user includes `libs/light` as a dependency and then builds
-with **newt**, they will get an unresolved external for either `light_switch_gpio`
-or `bsp_light_app_get_light_gpio()` and will need to add to their BSP.
-
-In their BSP, they can add
-
-```no-highlight
- const int light_switch_gpio = 5;
-```
-
-or
-
-```no-highlight
- int bsp_light_app_get_light_gpio(void) {
- return my_configured_lightswitch_io();
- }
-```
-
-So where did the number `5` come from. Their BSP already includes the specific
-MCU that they are using. And their `mcu/xxx/hal_gpio.c` already defines
-the mapping between physical pins and the virtual device ids.
-
-The user can determine (when writing code) from their boards physical pinmap
-and from the `hal_gpio.c` MCU mapping which virtual device_id corresponds
-to the correct physical pin in their system.
-
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_os_tick/hal_os_tick.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_os_tick/hal_os_tick.md b/docs/os/modules/hal/hal_os_tick/hal_os_tick.md
new file mode 100644
index 0000000..216cccc
--- /dev/null
+++ b/docs/os/modules/hal/hal_os_tick/hal_os_tick.md
@@ -0,0 +1,28 @@
+# hal_os_tick
+
+The hardware independent interface to set up interrupt timers or halt CPU in terms of OS ticks.
+
+###Description
+
+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.
+
+```c
+void os_tick_init(uint32_t os_ticks_per_sec, int prio);
+```
+
+You can halt CPU for up to `n` ticks:
+
+```c
+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`.
+
+
+###Definition
+
+[hal_os_tick.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_os_tick.h)
+
+###Examples
+
+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](https://github.com/apache/incubator-mynewt-core/blob/master/kernel/os/src/arch/cortex_m0/os_arch_arm.c).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_pwm/hal_pwm.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_pwm/hal_pwm.md b/docs/os/modules/hal/hal_pwm/hal_pwm.md
deleted file mode 100644
index c8f929e..0000000
--- a/docs/os/modules/hal/hal_pwm/hal_pwm.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# hal_pwm
-
-The hardware independent interface to Pulse Width Modulators
-
-###Description
-
-Pulse Width Modulators (PWMs) are hardware devices that output digital waveforms
-with programmable duty cycle and frequency. They use a digital waveform
-but can contiuously adjust the amount of power delivered to their load via
-duty cycle. They are often used to create analog waveforms via low pass filter,
-drive LEDs at various intensities, and control DC or servo motors.
-
-For a description of PSM, see [wikipedia](https://en.wikipedia.org/wiki/Pulse-width_modulation)
-
-###Definition
-
-[hal_pwm.h](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_pwm.h)
-
-###HAL_PWM Theory Of Operation
-
-The HAL_PWM interface was designed with some specific use cases in mind. It
-was also designed to exploit a subset of the functionality provided by
-common PWM controllers.
-
-Fundamentally, a PWM has at it root an N-bit COUNTER, a CLOCK source, one or
-more CAPTURE registers, and sometimes a TOP register.
-
-The clock source feeds the COUNTER register which is continuously counting
-(up or down), When the COUNTER is less than the value of the CAPTURE
-register, the PWM outputs a logic HIGH. When the counter is greater than
-the CAPTURE register the PWM outputs logic LOW. When the counter reaches the TOP
-register, it wraps back to zero. If the PWM has no TOP register, it simply
-wraps back to zero after reaching 2^N-1.
-
-The HAL_PWM abstracts this implementation and provides methods to set the
-PWM frequency and duty cycle. The frequency is the rate at which the counter
-wraps back to zero. The duty cycle is the fraction of time the PWM is in
-logic HIGH state.
-
-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
-for the specific PWM you are using
-2) Optionally set the frequency of the PWM using `hal_pwm_set_frequency`
--- PWMs that support a TOP register have fine control over their frequency
-settings. If this command is not supported by the PWM it will return an error
-and its likely that there is no TOP register; the frequency resolution is not
-finely adjustable. See the BSP for coarse adjustment of the PWM frequency.
-3) 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`.
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_spi/hal_spi.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_spi/hal_spi.md b/docs/os/modules/hal/hal_spi/hal_spi.md
index 804d385..13a02bd 100644
--- a/docs/os/modules/hal/hal_spi/hal_spi.md
+++ b/docs/os/modules/hal/hal_spi/hal_spi.md
@@ -8,13 +8,12 @@ For a detailed description of SPI, see [Wikipedia](https://en.wikipedia.org/wiki
###Description
-The Mynewt HAL interface supports the SPI master functionality only. Future
-version will support SPI slave functionality.
+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.
###Definition
-[hal_spi.h](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_spi.h)
+[hal_spi.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_spi.h)
###HAL_SPI Theory Of Operation
@@ -24,60 +23,29 @@ a SPI slave device. This is how a master "addresses" a particular slave
device. Often this signal is also referred to as "chip select" as it
selects particular slave device for communications.
-The Mynewt SPI HAL has blocking transfers. This means that the API call
+The Mynewt SPI HAL has blocking and non-blocking transfers. Blocking means that the API call
to transfer a byte will wait until the byte completes transmissions before
-the function returns.
+the function returns. Blocking interface can be used for only the master slave SPI type.
+Non-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.
-Since SPI is generally a shared communications bus, the hal_spi API allows
-SPI runtime configuration to be compatible with the data format and speed of the
-slave device. See the `hal_spi_config` method in the API above for a
-description of the available settings. These settings are critical to the
-operation of the slave device.
-The Mynewt SPI HAL does not include built-in SS signaling. Its up to the
-hal_spi user to control their own SS pins. Typically applications will do
-this with GPIO.
-
-An example of this would look like this (error handling excluded for brevity):
-
-```no-highlight
-
- /* each device may have different settings */
- extern struct hal_spi_settings dev1;
- extern struct hal_spi_settings dev2;
-
- gpio_init_out(SS_DEV_1, 1);
- gpio_init_out(SS_DEV_2, 1);
- hal_spi *pspi = hal_spi_init(SPI0);
-
- ...
- /* write a single byte (0) to device 1 */
- hal_spi_config(pspi, &dev1);
- gpio_clear(SS_DEV_1)
- rc = hal_spi_transfer(pspi, 0)
- gpio_set(SS_DEV_1)
-
- /* read a single byte from device 2 */
- hal_spi_config(pspi, &dev2);
- gpio_clear(SS_DEV_2)
- val = hal_spi_transfer(pspi, 0)
- gpio_set(SS_DEV_2)
+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).
+```c
+int hal_spi_config(int spi_num, struct hal_spi_settings *psettings);
```
-Depending on the device's operation, it may be necessary or more efficient
-to write or read multiple bytes in a single transaction. An example is
-shown below
-
-```no-highlight
+The SPI settings consist of the following:
- void spi_write_buf(struct hal_spi *pspi, uint8_t *buf, int len) {
- char *ptr = buf;
+```c
+struct hal_spi_settings {
+ uint8_t data_mode;
+ uint8_t data_order;
+ uint8_t word_size;
+ uint32_t baudrate; /* baudrate in kHz */
+};
+```
- hal_spi_config(pspi, &dev2);
- gpio_clear(SS_DEV_2)
- while(len-- > 0) {
- val = hal_spi_transfer(pspi, (uint16_t) *ptr++)
- }
- gpio_set(SS_DEV_2)
- }
+The Mynewt SPI HAL does not include built-in SS (Slave Select) signaling. It's up to the
+hal_spi user to control their own SS pins. Typically applications will do
+this with GPIO.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_system/hal_sys.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_system/hal_sys.md b/docs/os/modules/hal/hal_system/hal_sys.md
index e69de29..54f8cb4 100644
--- a/docs/os/modules/hal/hal_system/hal_sys.md
+++ b/docs/os/modules/hal/hal_system/hal_sys.md
@@ -0,0 +1,13 @@
+# hal_system
+
+A hardware independent interface for starting and resetting the system.
+
+###Description
+
+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.
+
+###Definition
+
+[hal_system.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_system.h)
+
+###Examples
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_timer/hal_timer.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_timer/hal_timer.md b/docs/os/modules/hal/hal_timer/hal_timer.md
new file mode 100644
index 0000000..cc2be46
--- /dev/null
+++ b/docs/os/modules/hal/hal_timer/hal_timer.md
@@ -0,0 +1,27 @@
+# hal_timer
+
+The hardware independent timer structure and API to configure, initialize, and run timers.
+
+###Description
+
+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.
+
+```c
+struct hal_timer
+{
+ void *bsp_timer; /* Internal platform specific pointer */
+ hal_timer_cb cb_func; /* Callback function */
+ void *cb_arg; /* Callback argument */
+ uint32_t expiry; /* Tick at which timer should expire */
+ TAILQ_ENTRY(hal_timer) link; /* Queue linked list structure */
+};
+```
+
+###Definition
+
+[hal_timer.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_timer.h)
+
+###Examples
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_uart/hal_uart.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_uart/hal_uart.md b/docs/os/modules/hal/hal_uart/hal_uart.md
index a55eddb..8c56bc7 100644
--- a/docs/os/modules/hal/hal_uart/hal_uart.md
+++ b/docs/os/modules/hal/hal_uart/hal_uart.md
@@ -6,15 +6,15 @@ The hardware independent UART interface for Mynewt.
###Description
Contains the basic operations to send and receive data over a UART
-(Universal Asynchronous Receiver Transmitter).
+(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.
###Definition
-[hal_uart.h](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_uart.h)
+[hal_uart.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_uart.h)
###Examples
-This example shows a user writing a character to the uart
+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.
```no-highlight
/* write to the console with blocking */
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/docs/os/modules/hal/hal_watchdog/hal_watchdog.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_watchdog/hal_watchdog.md b/docs/os/modules/hal/hal_watchdog/hal_watchdog.md
new file mode 100644
index 0000000..d9ce4fe
--- /dev/null
+++ b/docs/os/modules/hal/hal_watchdog/hal_watchdog.md
@@ -0,0 +1,28 @@
+# hal_watchdog
+
+
+The hardware independent interface to enable internal hardware watchdogs.
+
+###Description
+
+The `hal_watchdog_init` interface can be used to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds.
+
+```c
+int hal_watchdog_init(uint32_t expire_msecs);
+```
+
+Watchdog needs to be then started with a call to `hal_watchdog_enable()`.
+Watchdog should be tickled periodically with a frequency smaller than 'expire_secs' using `hal_watchdog_tickle()`.
+
+
+###Definition
+
+[hal_watchdog](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_watchdog.h)
+
+
+###Examples
+
+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](https://github.com/apache/incubator-mynewt-core/blob/master/kernel/os/src/os.c).
+
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ac3ce34b/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 9f0baef..37598e8 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -281,25 +281,24 @@ pages:
- 'Other File Systems': 'os/modules/fs/otherfs.md'
- Hardware Abstraction Layer:
- toc: 'os/modules/hal/hal.md'
- - Architecture: 'os/modules/hal/hal_architecture.md'
- 'API':
- 'Summary': 'os/modules/hal/hal_api.md'
- - 'ADC': 'os/modules/hal/hal_adc/hal_adc.md'
- - 'CPU timer': 'os/modules/hal/hal_cputime/hal_cpu_timer.md'
- - 'DAC': 'os/modules/hal/hal_dac/hal_dac.md'
+ - 'BSP': 'os/modules/hal/hal_adc/hal_bsp.md'
- 'Flash memory':
- - 'Overview': 'os/modules/hal/hal_flash/hal_flash.md'
+ - 'flash API for apps': 'os/modules/hal/hal_flash/hal_flash.md'
- 'flash_int': 'os/modules/hal/hal_flash/hal_flash_int.md'
- - 'flash_map': 'os/modules/hal/hal_flash/hal_flash_map.md'
- 'GPIO': 'os/modules/hal/hal_gpio/hal_gpio.md'
- 'I2C': 'os/modules/hal/hal_i2c/hal_i2c.md'
- - 'PWM': 'os/modules/hal/hal_pwm/hal_pwm.md'
+ - 'OS Tick': 'os/modules/hal/hal_os_tick/hal_os_tick.md'
- 'SPI': 'os/modules/hal/hal_spi/hal_spi.md'
- 'System': 'os/modules/hal/hal_system/hal_sys.md'
+ - 'Timer': 'os/modules/hal/hal_timer/hal_timer.md'
- 'UART': 'os/modules/hal/hal_uart/hal_uart.md'
+ - 'Watchdog': 'os/modules/hal/hal_watchdog/hal_watchdog.md'
- 'Using HAL': 'os/modules/hal/hal_in_libraries.md'
- 'Creating HAL': 'os/modules/hal/hal_creation.md'
-
+ - Drivers:
+ - toc: 'os/modules/drivers/driver.md'
- Test Utilities:
- toc: 'os/modules/testutil/testutil.md'
- 'Functions/Macros':