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':