mirror of
https://github.com/Fishwaldo/bl_mcu_sdk.git
synced 2025-07-13 08:18:36 +00:00
[feat][docs] add english docs
This commit is contained in:
qqwang
parent
0d9f65c145
commit
ac418d27a3
437 changed files with 52529 additions and 0 deletions
288
docs/development_guide_en/source/api_reference/api_overview.rst
Normal file
288
docs/development_guide_en/source/api_reference/api_overview.rst
Normal file
|
|
@ -0,0 +1,288 @@
|
|||
API Overview
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------
|
||||
|
||||
**bl_mcu_sdk** code hierarchy is divided into the following main layers.
|
||||
|
||||
- The application layer: codes written by users.
|
||||
- The component layer: some opensource components,the interface calls the HAL layer, while the wireless layer is used for wireless functions.
|
||||
- HAL layer and wireless layer for adaptation to different MCUs, where the HAL layer is divided into two layers
|
||||
- Device driver management: provides a standard set of interfaces, which are implemented by the peripheral driver adaptation layer
|
||||
- Peripheral driver adaptation layer: implements the standard interface of the device driver management and extends its own unique interface
|
||||
- Standard driver layer based on register packaging
|
||||
- Hardware layer, also known as the register layer
|
||||
|
||||
.. figure:: img/sw_arch.png
|
||||
:alt:
|
||||
|
||||
code structure
|
||||
|
||||
Device driver management layer
|
||||
---------------------------------
|
||||
|
||||
The realization of the device driver management layer adopts the object-oriented idea. First of all, we regard the peripheral as a device or a file, adhering to the concept of **everything is a file**, and files have standard calling interfaces: ``open``, ``close``, ``ctrl``, ``write``, ``read``, ``callback``. Different file types are different (such as serial device, ADC device, SPI device), and the way of opening is also different (such as polling, interrupt, DMA), from this, we can construct a base class (parent class) of an object.
|
||||
|
||||
**Base class**
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
struct device
|
||||
{
|
||||
char name[NAME_MAX]; /*name of device */
|
||||
dlist_t list; /*list node of device */
|
||||
enum device_status_type status; /*status of device */
|
||||
enum device_class_type type; /*type of device */
|
||||
uint16_t oflag; /*oflag of device */
|
||||
|
||||
int (*open)(struct device *dev, uint16_t oflag);
|
||||
int (*close)(struct device *dev);
|
||||
int (*control)(struct device *dev, int cmd, void *args);
|
||||
int (*write)(struct device *dev, uint32_t pos, const void *buffer, uint32_t size);
|
||||
int (*read)(struct device *dev, uint32_t pos, void *buffer, uint32_t size);
|
||||
void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event);
|
||||
void *handle;
|
||||
};
|
||||
|
||||
**Base class member: name**
|
||||
|
||||
Name the device and use ``device_find`` to find the device.
|
||||
|
||||
**Base class member: type**
|
||||
|
||||
``type`` records the category of the current device, and the ``type`` that can be selected are as follows.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum device_class_type
|
||||
{
|
||||
DEVICE_CLASS_NONE = 0,
|
||||
DEVICE_CLASS_GPIO,
|
||||
DEVICE_CLASS_UART,
|
||||
DEVICE_CLASS_SPI,
|
||||
DEVICE_CLASS_I2C,
|
||||
DEVICE_CLASS_ADC,
|
||||
DEVICE_CLASS_DMA,
|
||||
DEVICE_CLASS_TIMER,
|
||||
DEVICE_CLASS_PWM,
|
||||
DEVICE_CLASS_SDIO,
|
||||
DEVICE_CLASS_USB,
|
||||
DEVICE_CLASS_I2S,
|
||||
DEVICE_CLASS_CAMERA,
|
||||
DEVICE_CLASS_SEC_HASH,
|
||||
} ;
|
||||
|
||||
**Base class member: status**
|
||||
|
||||
``status`` is used to record the current status of the device and provides 4 statuses.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum device_status_type
|
||||
{
|
||||
DEVICE_UNREGISTER = 0,
|
||||
DEVICE_REGISTERED,
|
||||
DEVICE_OPENED,
|
||||
DEVICE_CLOSED
|
||||
} ;
|
||||
|
||||
**Base class member: oflag**
|
||||
|
||||
``oflag`` records the flag information filled in during registration and the ``oflag`` information filled in when using ``device_open``.
|
||||
|
||||
**Base class members: list**
|
||||
|
||||
The addition and deletion of equipment is stored in a doubly linked list, which saves memory.
|
||||
|
||||
**Base class members: standard function pointers**
|
||||
|
||||
Provides a standard function interface for different peripherals. When the peripheral implements this type of interface and assigns it to the member, the function of rewriting can be achieved.
|
||||
|
||||
Device driver management layer standard interface
|
||||
---------------------------------------------------
|
||||
|
||||
**device_register**
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_register`` is used to register the device and register the device information in the linked list.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_register(struct device *dev, const char *name);
|
||||
|
||||
- dev: device handle.
|
||||
- name: the name of the device.
|
||||
- return: return error code, 0 means registration is successful, others mean errors.
|
||||
|
||||
**device_unregister**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_unregister`` is used to delete the device and delete the device information from the linked list.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_unregister(const char *name);
|
||||
|
||||
- dev: device handle
|
||||
- name: the name of the device to be deleted
|
||||
- return: error code, 0 means delete, others mean error
|
||||
|
||||
**device_find**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_find`` is used to find the device from the linked list according to ``name``, and return the first address of the device handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
struct device *device_find(const char *name);
|
||||
|
||||
- dev: device handle
|
||||
- name: the name of the device to be searched
|
||||
- return: error code,! 0 means the device handle was found, NULL means the device was not found.
|
||||
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open the device, and ``oflag`` represents the opening method. Currently, there are 6 opening methods available. The bottom layer calls the ``open`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- dev: device handle
|
||||
- oflag: open method
|
||||
- return: error code, 0 means opening is successful, others mean errors
|
||||
|
||||
``oflag`` can write the following parameters:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close the device. The bottom layer calls the ``close`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
-dev: device handle
|
||||
-return: error code, 0 means closing is successful, others mean error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control the device and modify parameters according to commands. The bottom layer calls the ``control`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- dev: device handle
|
||||
- cmd: device control command
|
||||
- args: control parameters
|
||||
- return: Different control commands return different meanings.
|
||||
|
||||
``cmd`` provides the following standard commands. In addition, different peripherals also have their own commands
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_CTRL_SET_INT 0x01 /* set interrupt */
|
||||
#define DEVICE_CTRL_CLR_INT 0x02 /* clear interrupt */
|
||||
#define DEVICE_CTRL_GET_INT 0x03 /* get interrupt status*/
|
||||
#define DEVICE_CTRL_RESUME 0x04 /* resume device */
|
||||
#define DEVICE_CTRL_SUSPEND 0x05 /* suspend device */
|
||||
#define DEVICE_CTRL_CONFIG 0x06 /* config device */
|
||||
#define DEVICE_CTRL_GET_CONFIG 0x07 /* get device configuration */
|
||||
#define DEVICE_CTRL_ATTACH_TX_DMA 0x08
|
||||
#define DEVICE_CTRL_ATTACH_RX_DMA 0x09
|
||||
#define DEVICE_CTRL_TX_DMA_SUSPEND 0x0a
|
||||
#define DEVICE_CTRL_RX_DMA_SUSPEND 0x0b
|
||||
#define DEVICE_CTRL_TX_DMA_RESUME 0x0c
|
||||
#define DEVICE_CTRL_RX_DMA_RESUME 0x0d
|
||||
#define DEVICE_CTRL_RESVD1 0x0E
|
||||
#define DEVICE_CTRL_RESVD2 0x0F
|
||||
|
||||
**device_write**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_write`` is used to send data, and the sending mode can be polling, interrupt, dma. The bottom layer calls the ``write`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_write(struct device *dev, uint32_t pos, const void *buffer, uint32_t size);
|
||||
|
||||
- dev: device handle
|
||||
- pos: different devices have different meanings for pos
|
||||
- buffer: the buffer to be written
|
||||
- size: the length to be written
|
||||
- return: error code, 0 means writing is successful, others mean errors
|
||||
|
||||
**device_read**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_read`` is used to receive data, and the receiving mode can be polling, interrupt, dma. The bottom layer calls the ``read`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_read(struct device *dev, uint32_t pos, void *buffer, uint32_t size);
|
||||
|
||||
- dev: device handle
|
||||
- pos: different devices have different meanings for pos
|
||||
- buffer: the buffer to be read
|
||||
- size: the length to be read
|
||||
- return: error code, 0 means successful reading, others mean errors
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register interrupt callback function. The bottom layer calls the ``callback`` member in the ``dev`` handle.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- dev: device handle
|
||||
- callback: the interrupt callback function to be registered
|
||||
|
||||
|
||||
* dev: device handle
|
||||
* args: Different peripherals have different meanings
|
||||
* size: transmission length
|
||||
* event: interrupt event type
|
||||
|
||||
Peripheral driver adaptation layer
|
||||
---------------------------------------
|
||||
|
||||
**Subclass inherits from parent class**
|
||||
|
||||
The first member of different peripherals is ``struct device``, which is equivalent to the inheritance of the parent class, so that the subclass can be used to access the parent class member. When the subclass is used to modify the members of the parent class, it has its own functions. The realization principle is that the first address of different structures is the address of the first member in the structure.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct xxx_device
|
||||
{
|
||||
struct device parent;
|
||||
|
||||
} xxx_device_t;
|
||||
|
||||
**Rewrite standard interface**
|
||||
|
||||
Each peripheral has a ``xxx_register`` function, which is used to rewrite the standard interface.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
dev->open = xxx_open;
|
||||
dev->close = xxx_close;
|
||||
dev->control = xxx_control;
|
||||
dev->write = xxx_write;
|
||||
dev->read = xxx_read;
|
||||
|
|
@ -0,0 +1,708 @@
|
|||
.. _ble-index:
|
||||
|
||||
BLE
|
||||
==================
|
||||
|
||||
Introduction
|
||||
-------------------
|
||||
- Features
|
||||
+ HOST
|
||||
- GAP support peripheral and Central, Observer and Broadcaster
|
||||
- GATT support server and Client
|
||||
- Support pairing with the secure connection feature in Bluetooth 4.2
|
||||
- Support permanent storage of Bluetooth specific settings and data
|
||||
+ mesh
|
||||
- TODO
|
||||
|
||||
- The architecture of the BLE protocol stack:
|
||||
.. figure:: img/image1.png
|
||||
|
||||
+ There are 3 main layers, which together form a complete Bluetooth low power protocol stack
|
||||
- Host: Under the application program, it is composed of multiple (non-real-time) networks and transmission protocols, enabling the application program to communicate with peer devices in a standard and interoperable manner
|
||||
- Controller：The controller implements the link layer (LE LL), which is a low-level real-time protocol that provides standard interoperability for over-the-air communication with the radio. LL handles the reception and transmission of packets, guarantees the transfer of data, and handles all LL control procedures
|
||||
- Radio Hardware：Implement analog and digital baseband functions, allowing link layer firmware to transmit and receive in the 2.4GHz band of the spectrum
|
||||
|
||||
- Master Host:
|
||||
.. figure:: img/image2.png
|
||||
|
||||
* The Bluetooth Host layer implements all high-level protocols and configuration files, the most important thing is that it provides high-level APIs for applications
|
||||
- HCI: Host and controller interface
|
||||
- L2CAP: Logical Link Control and Adaptation Protocol
|
||||
- GATT: Generic Attribute Profile
|
||||
- GAP: Generic Access Profile
|
||||
- SMP: Security Manager Specification
|
||||
|
||||
- Application
|
||||
* The application layer contains the necessary protocol stack parameter settings and api reference. We analyze the two devices separately from the Bluetooth slave and the Bluetooth master
|
||||
* Bluetooth slave
|
||||
- Hardware and basic service initialization
|
||||
- Set broadcast parameters: broadcast data, broadcast interval, scan response, etc
|
||||
- Profile settings: add slave services, feature values, and set callback functions to receive host data, etc
|
||||
- Set pairing parameters (optional)
|
||||
- Start the broadcast, start running
|
||||
- Waiting for related events, and event processing, such as receiving data from the host, being linked, etc
|
||||
* Bluetooth host
|
||||
- Related hardware and basic service initialization
|
||||
- Set scan parameters
|
||||
- Set connection parameters
|
||||
- Set pairing parameters (optional)
|
||||
- Start the protocol stack and start running
|
||||
- Wait for related events, and event processing, such as scan events, Notify events from slaves, etc
|
||||
|
||||
API
|
||||
----------
|
||||
|
||||
- API introduction
|
||||
|
||||
``void ble_controller_init(uint8_t task_priority)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Controller layer initialization
|
||||
* @param[in] task_priority: task priority
|
||||
* @return None
|
||||
*/
|
||||
|
||||
``int hci_driver_init(void)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function HCI interface driver initialization
|
||||
* @param[in] None
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_enable(bt_ready_cb_t cb)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function BLE enable
|
||||
* @param[in] cb: Call the callback function if successful
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_adv_start(const struct bt_le_adv_param *param,const struct bt_data *ad, size_t ad_len,``
|
||||
``const struct bt_data *sd, size_t sd_len)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Turn on BLE broadcast
|
||||
*
|
||||
* @param[in] param: Pointer to broadcast configuration parameter
|
||||
* @param[in] ad: Pointer to the data in the broadcast packet
|
||||
* @param[in] ad_len: The length of the data in the broadcast packet
|
||||
* @param[in] sd: Pointer to scan response packet data
|
||||
* @param[in] sd_len: Scan response packet data length
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
|
||||
``int bt_le_adv_update_data(const struct bt_data *ad, size_t ad_len,const struct bt_data *sd, size_t sd_len)``
|
||||
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Update BLE broadcast data
|
||||
* @param[in] ad: Pointer to the data in the broadcast packet
|
||||
* @param[in] ad_len: The length of the data in the broadcast packet
|
||||
* @param[in] sd: Pointer to scan response packet data
|
||||
* @param[in] sd_len: Scan response packet data length
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_adv_stop(void)``
|
||||
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Stop BLE broadcast
|
||||
* @param[in] None
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
|
||||
``int bt_le_scan_start(const struct bt_le_scan_param *param, bt_le_scan_cb_t cb)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Turn on BLE scanning
|
||||
* @param[in] param: Pointer to scan parameter
|
||||
* @param[in] cb: Scan callback function
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_scan_stop(void)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Stop BLE scanning
|
||||
* @param[in] None
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_whitelist_add(const bt_addr_le_t *addr)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Add devices to the whitelist by address
|
||||
* @param[in] addr: Pointer to the address of the device that needs to be added
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_whitelist_rem(const bt_addr_le_t *addr)``
|
||||
|
||||
::
|
||||
|
||||
|
||||
/**
|
||||
* function Remove the device from the whitelist
|
||||
* @param[in] addr: Pointer to the address of the device that needs to be removed
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_whitelist_clear(void)``
|
||||
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Clear the whitelist list
|
||||
* @param[in] None
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_set_chan_map(u8_t chan_map[5])``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Set (LE) channel mapping
|
||||
* @param[in] chan_map: channel array
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_unpair(u8_t id, const bt_addr_le_t *addr)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Clear pairing information
|
||||
* @param[in] id: Local ID (mostly just the default BT ID)
|
||||
* @param[in] addr: Remote device address, NULL or BT_ADDR_LE_ANY to clear all remote devices
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_conn_get_info(const struct bt_conn *conn, struct bt_conn_info *info)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Get the information of the currently connected device
|
||||
* @param[in] conn: Pointer to the current connection
|
||||
* @param[in] info: Pointer to the information of the currently connected device
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
|
||||
``int bt_conn_get_remote_dev_info(struct bt_conn_info *info)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Get information about connected devices
|
||||
* @param[in] info: Pointer to the information of the currently connected device
|
||||
* @return Number of connected devices
|
||||
*/
|
||||
|
||||
``int bt_conn_le_param_update(struct bt_conn *conn,const struct bt_le_conn_param *param)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Update connection parameters
|
||||
* @param[in] conn: Pointer to the current connection
|
||||
* @param[in] param: Pointer to connection parameter
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_conn_disconnect(struct bt_conn *conn, u8_t reason)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Disconnect current connection
|
||||
* @param[in] conn: pointer to the current connection
|
||||
* @param[in] reason: the reason for disconnecting the current connection
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``struct bt_conn *bt_conn_create_le(const bt_addr_le_t *peer,const struct bt_le_conn_param *param)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Create connection
|
||||
* @param[in] peer: The pointer of the device address that needs to be connected
|
||||
* @param[in] param: Pointer to connection parameter
|
||||
* @return Success: a valid connection object, otherwise it fails
|
||||
*/
|
||||
|
||||
|
||||
``int bt_conn_create_auto_le(const struct bt_le_conn_param *param)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Automatically create and connect to devices in the whitelist
|
||||
* @param[in] param: pointer to connection parameter
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_conn_create_auto_stop(void)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Stop automatic creation and connect to devices in the whitelist
|
||||
* @param[in] None
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``int bt_le_set_auto_conn(const bt_addr_le_t *addr,const struct bt_le_conn_param *param)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Automatically create a connection to the remote device
|
||||
* @param[in] addr: Remote device address pointer
|
||||
* @param[in] param: Pointer to connection parameter
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``struct bt_conn *bt_conn_create_slave_le(const bt_addr_le_t *peer,const struct bt_le_adv_param *param)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Initiate a directed broadcast packet to the remote device
|
||||
* @param[in] peer: Remote device address pointer
|
||||
* @param[in] param: Pointer to broadcast parameters
|
||||
* @return Success: a valid connection object, otherwise it fails
|
||||
*/
|
||||
|
||||
``int bt_conn_set_security(struct bt_conn *conn, bt_security_t sec)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Set the connection security level
|
||||
* @param[in] conn: Pointer to the connection object
|
||||
* @param[in] sec: Security level
|
||||
* @return 0: success, !=0: fail
|
||||
*/
|
||||
|
||||
``bt_security_t bt_conn_get_security(struct bt_conn *conn)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Get the security level of the current connection
|
||||
* @param[in] conn: Pointer to the connection object
|
||||
* @return Security Level
|
||||
*/
|
||||
|
||||
|
||||
``u8_t bt_conn_enc_key_size(struct bt_conn *conn)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Get the size of the encryption key of the current connection
|
||||
* @param[in] conn: Pointer to the connection object
|
||||
* @return The size of the encryption key
|
||||
*/
|
||||
|
||||
|
||||
``void bt_conn_cb_register(struct bt_conn_cb *cb)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Register connection callback function
|
||||
* @param[in] cb: Connection callback function
|
||||
* @return None
|
||||
*/
|
||||
|
||||
``void bt_set_bondable(bool enable)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Set/clear the binding flag in the SMP pairing request/response to the data authentication request
|
||||
* @param[in] enable: 1: enable, 0: disable
|
||||
* @return None
|
||||
*/
|
||||
|
||||
``int bt_conn_auth_cb_register(const struct bt_conn_auth_cb *cb)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Register authentication callback function
|
||||
* @param[in] cb: Callback function pointer
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_conn_auth_passkey_entry(struct bt_conn *conn, unsigned int passkey)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Reply with the key
|
||||
* @param[in] conn: Connect object pointer
|
||||
* @param[in] passkey: the key entered
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_conn_auth_cancel(struct bt_conn *conn)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Cancel the authentication process
|
||||
* @param[in] conn: Connection object pointer
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_conn_auth_passkey_confirm(struct bt_conn *conn)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function If the password matches, reply to the other side
|
||||
* @param[in] conn: Pointer to connection object
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_conn_auth_pincode_entry(struct bt_conn *conn, const char *pin)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Reply with PIN code
|
||||
* @param[in] conn: Pointer to connection object
|
||||
* @param[in] pin: PIN code pointer
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_le_read_rssi(u16_t handle,int8_t *rssi)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Read the RSSI value of the opposite device
|
||||
* @param[in] handle: The handle value of the connection
|
||||
* @param[in] rssi: rssi pointer
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_get_local_address(bt_addr_le_t *adv_addr)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Read the address of the machine
|
||||
* @param[in] adv_addr: Pointer to address
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
``int bt_set_tx_pwr(int8_t power)``
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* function Set the transmit power of this device
|
||||
* @param[in] power: power value
|
||||
* @return 0: success, !=0: failure
|
||||
*/
|
||||
|
||||
Data structure reference
|
||||
-----------------------------
|
||||
|
||||
``bt_le_adv_param``\ data structure:
|
||||
|
||||
.. code:: c
|
||||
|
||||
/** LE Advertising Parameters. */
|
||||
struct bt_le_adv_param {
|
||||
/** Local identity */
|
||||
u8_t id;
|
||||
|
||||
/** Bit-field of advertising options */
|
||||
u8_t options;
|
||||
|
||||
/** Minimum Advertising Interval (N * 0.625) */
|
||||
u16_t interval_min;
|
||||
|
||||
/** Maximum Advertising Interval (N * 0.625) */
|
||||
u16_t interval_max;
|
||||
|
||||
#if defined(CONFIG_BT_STACK_PTS)
|
||||
u8_t addr_type;
|
||||
#endif
|
||||
};
|
||||
|
||||
This data structure is used to configure broadcast parameters, including local identification, broadcast option bit fields, broadcast gaps, etc. The broadcast option bit fields have the following enumerated type parameters to choose from:
|
||||
|
||||
.. code:: c
|
||||
|
||||
enum {
|
||||
/** Convenience value when no options are specified. */
|
||||
BT_LE_ADV_OPT_NONE = 0,
|
||||
|
||||
/** Advertise as connectable. Type of advertising is determined by
|
||||
* providing SCAN_RSP data and/or enabling local privacy support.
|
||||
*/
|
||||
BT_LE_ADV_OPT_CONNECTABLE = BIT(0),
|
||||
|
||||
/** Don't try to resume connectable advertising after a connection.
|
||||
* This option is only meaningful when used together with
|
||||
* BT_LE_ADV_OPT_CONNECTABLE. If set the advertising will be stopped
|
||||
* when bt_le_adv_stop() is called or when an incoming (slave)
|
||||
* connection happens. If this option is not set the stack will
|
||||
* take care of keeping advertising enabled even as connections
|
||||
* occur.
|
||||
*/
|
||||
BT_LE_ADV_OPT_ONE_TIME = BIT(1),
|
||||
|
||||
/** Advertise using the identity address as the own address.
|
||||
* @warning This will compromise the privacy of the device, so care
|
||||
* must be taken when using this option.
|
||||
*/
|
||||
BT_LE_ADV_OPT_USE_IDENTITY = BIT(2),
|
||||
|
||||
/** Advertise using GAP device name */
|
||||
BT_LE_ADV_OPT_USE_NAME = BIT(3),
|
||||
|
||||
/** Use low duty directed advertising mode, otherwise high duty mode
|
||||
* will be used. This option is only effective when used with
|
||||
* bt_conn_create_slave_le().
|
||||
*/
|
||||
BT_LE_ADV_OPT_DIR_MODE_LOW_DUTY = BIT(4),
|
||||
|
||||
/** Enable use of Resolvable Private Address (RPA) as the target address
|
||||
* in directed advertisements when CONFIG_BT_PRIVACY is not enabled.
|
||||
* This is required if the remote device is privacy-enabled and
|
||||
* supports address resolution of the target address in directed
|
||||
* advertisement.
|
||||
* It is the responsibility of the application to check that the remote
|
||||
* device supports address resolution of directed advertisements by
|
||||
* reading its Central Address Resolution characteristic.
|
||||
*/
|
||||
BT_LE_ADV_OPT_DIR_ADDR_RPA = BIT(5),
|
||||
|
||||
/** Use whitelist to filter devices that can request scan response
|
||||
* data.
|
||||
*/
|
||||
BT_LE_ADV_OPT_FILTER_SCAN_REQ = BIT(6),
|
||||
|
||||
/** Use whitelist to filter devices that can connect. */
|
||||
BT_LE_ADV_OPT_FILTER_CONN = BIT(7),
|
||||
};
|
||||
|
||||
If you need to send a broadcast packet, the configuration can be as follows:
|
||||
|
||||
.. code:: c
|
||||
|
||||
param.id = 0;
|
||||
param.options = (BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_USE_NAME | BT_LE_ADV_OPT_ONE_TIME);
|
||||
param.interval_min = 0x00a0;
|
||||
param.interval_max = 0x00f0;
|
||||
|
||||
``bt_data``\ data structure:
|
||||
|
||||
.. code:: c
|
||||
|
||||
struct bt_data {
|
||||
u8_t type;
|
||||
u8_t data_len;
|
||||
const u8_t *data;
|
||||
};
|
||||
|
||||
This data structure is used to fill the data in the broadcast packet, the specific data packet type can refer to the following:
|
||||
|
||||
.. code:: c
|
||||
|
||||
Service UUID
|
||||
Local Name
|
||||
Flags
|
||||
Manufacturer Specific Data
|
||||
TX Power Level
|
||||
Secure Simple Pairing OOB
|
||||
Security Manager OOB
|
||||
Security Manager TK Value
|
||||
Slave Connection Interval Range
|
||||
Service Solicitation
|
||||
Service Data
|
||||
Appearance
|
||||
Public Target Address
|
||||
Random Target Address
|
||||
Advertising Interval
|
||||
LE Bluetooth Device Address
|
||||
LE Role
|
||||
Uniform Resource Identifier
|
||||
LE Supported Features
|
||||
Channel Map Update Indication
|
||||
|
||||
Use this data structure to configure a broadcast packet data, as shown below:
|
||||
|
||||
.. code:: c
|
||||
|
||||
struct bt_data ad_discov[] = {
|
||||
BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
|
||||
BT_DATA(BT_DATA_NAME_COMPLETE, "BL602-BLE-DEV", 13),
|
||||
};
|
||||
|
||||
``bt_le_scan_param``\ data structure:
|
||||
|
||||
.. code:: c
|
||||
|
||||
/** LE scan parameters */
|
||||
struct bt_le_scan_param {
|
||||
/** Scan type (BT_LE_SCAN_TYPE_ACTIVE or BT_LE_SCAN_TYPE_PASSIVE) */
|
||||
u8_t type;
|
||||
|
||||
/** Bit-field of scanning filter options. */
|
||||
u8_t filter_dup;
|
||||
|
||||
/** Scan interval (N * 0.625 ms) */
|
||||
u16_t interval;
|
||||
|
||||
/** Scan window (N * 0.625 ms) */
|
||||
u16_t window;
|
||||
};
|
||||
|
||||
This data structure is used to fill scan parameters,
|
||||
type: There are two types of scan types: BT_LE_SCAN_TYPE_ACTIVE (0x01) and BT_LE_SCAN_TYPE_PASSIVE (0x00)
|
||||
filter_dup: 0x00, except for targeted advertisements, accept all broadcast and scan responses, 0x01, only receive broadcast and scan responses from devices in the whitelist
|
||||
interval: Scan interval
|
||||
window: Scan window
|
||||
|
||||
If the scan request is enabled, it can be configured as follows:
|
||||
|
||||
.. code:: c
|
||||
|
||||
scan_param.type = BT_LE_SCAN_TYPE_PASSIVE
|
||||
scan_param.filter_dup = 0x00
|
||||
interval=BT_GAP_SCAN_SLOW_INTERVAL_1
|
||||
window=BT_GAP_SCAN_SLOW_WINDOW_1
|
||||
|
||||
|
||||
``bt_le_conn_param``\ data structure:
|
||||
|
||||
.. code:: c
|
||||
|
||||
/** Connection parameters for LE connections */
|
||||
struct bt_le_conn_param {
|
||||
u16_t interval_min;
|
||||
u16_t interval_max;
|
||||
u16_t latency;
|
||||
u16_t timeout;
|
||||
|
||||
#if defined(CONFIG_BT_STACK_PTS)
|
||||
u8_t own_address_type;
|
||||
#endif
|
||||
};
|
||||
|
||||
This data structure is used to fill in the connection parameters, interval_min: the minimum value of the connection interval (0x0018), interval_max: the maximum value of the connection interval (0x0028),
|
||||
latency: The maximum slave latency allowed for connection events
|
||||
timeout: The time for the connection to time out
|
||||
|
||||
Configure the data structure as follows:
|
||||
|
||||
.. code:: c
|
||||
|
||||
interval_min=BT_GAP_INIT_CONN_INT_MIN(0x0018)
|
||||
interval_max=BT_GAP_INIT_CONN_INT_MAX(0x0028)
|
||||
latency=0
|
||||
timeout=400
|
||||
|
||||
``bt_conn``\ data structure:
|
||||
|
||||
.. code:: c
|
||||
|
||||
struct bt_conn {
|
||||
u16_t handle;
|
||||
u8_t type;
|
||||
u8_t role;
|
||||
|
||||
ATOMIC_DEFINE(flags, BT_CONN_NUM_FLAGS);
|
||||
|
||||
/* Which local identity address this connection uses */
|
||||
u8_t id;
|
||||
|
||||
#if defined(CONFIG_BT_SMP) || defined(CONFIG_BT_BREDR)
|
||||
bt_security_t sec_level;
|
||||
bt_security_t required_sec_level;
|
||||
u8_t encrypt;
|
||||
#endif /* CONFIG_BT_SMP || CONFIG_BT_BREDR */
|
||||
|
||||
/* Connection error or reason for disconnect */
|
||||
u8_t err;
|
||||
|
||||
bt_conn_state_t state;
|
||||
|
||||
u16_t rx_len;
|
||||
struct net_buf *rx;
|
||||
|
||||
/* Sent but not acknowledged TX packets with a callback */
|
||||
sys_slist_t tx_pending;
|
||||
/* Sent but not acknowledged TX packets without a callback before
|
||||
* the next packet (if any) in tx_pending.
|
||||
*/
|
||||
u32_t pending_no_cb;
|
||||
|
||||
/* Completed TX for which we need to call the callback */
|
||||
sys_slist_t tx_complete;
|
||||
struct k_work tx_complete_work;
|
||||
|
||||
|
||||
/* Queue for outgoing ACL data */
|
||||
struct k_fifo tx_queue;
|
||||
|
||||
/* Active L2CAP channels */
|
||||
sys_slist_t channels;
|
||||
|
||||
atomic_t ref;
|
||||
|
||||
/* Delayed work for connection update and other deferred tasks */
|
||||
struct k_delayed_work update_work;
|
||||
|
||||
union {
|
||||
struct bt_conn_le le;
|
||||
#if defined(CONFIG_BT_BREDR)
|
||||
struct bt_conn_br br;
|
||||
struct bt_conn_sco sco;
|
||||
#endif
|
||||
};
|
||||
|
||||
#if defined(CONFIG_BT_REMOTE_VERSION)
|
||||
struct bt_conn_rv {
|
||||
u8_t version;
|
||||
u16_t manufacturer;
|
||||
u16_t subversion;
|
||||
} rv;
|
||||
#endif
|
||||
};
|
||||
|
||||
This data structure is the current connection data structure, which includes the parameters related to the BLE connection. After the connection is successful, the data structure can be called by the user.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
BIN
docs/development_guide_en/source/api_reference/img/image1.png
Normal file
BIN
docs/development_guide_en/source/api_reference/img/image1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
BIN
docs/development_guide_en/source/api_reference/img/image2.png
Normal file
BIN
docs/development_guide_en/source/api_reference/img/image2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
BIN
docs/development_guide_en/source/api_reference/img/sw_arch.png
Normal file
BIN
docs/development_guide_en/source/api_reference/img/sw_arch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 224 KiB |
|
|
@ -0,0 +1,252 @@
|
|||
ADC
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
ADC (Analog-to-digital Converter) can convert continuous analog signals into discrete digital signals.
|
||||
|
||||
The ADC module in BL MCU series has the following characteristics:
|
||||
|
||||
- Support selecting 12/14/16 bits conversion result output
|
||||
- ADC maximum working clock is 2MHZ
|
||||
- Support 2.0V, 3.2V optional internal reference voltage
|
||||
- DMA support
|
||||
- Support four modes: single channel single conversion, continuous single channel conversion, single multi-channel conversion and continuous multi-channel conversion mode
|
||||
- Support both single-ended and differential input modes
|
||||
- 12 external analog channels
|
||||
- 2 DAC internal channels
|
||||
- 1 VBAT /2 channel
|
||||
|
||||
ADC Device Structure Definition
|
||||
---------------------------------
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct adc_device {
|
||||
struct device parent;
|
||||
adc_clk_div_t clk_div;
|
||||
adc_vref_t vref;
|
||||
bool continuous_conv_mode;
|
||||
bool differential_mode;
|
||||
adc_data_width_t data_width;
|
||||
adc_fifo_threshold_t fifo_threshold;
|
||||
adc_pga_gain_t gain;
|
||||
} adc_device_t;
|
||||
|
||||
- **parent** inherits the properties of the parent class
|
||||
- **clk_div** Partial frequency clock in ADC module
|
||||
- **vref** 2.0/3.2V reference voltage optional
|
||||
- **continuous_conv_mode** Whether to select continuous mode. If it is in continuous mode, once adc_start operation, ADC will continue to work until adc_stop. If it is not in continuous mode, adc will only convert the result once every adc_start.
|
||||
- **differential_mode** Whether it is in differential mode, if it is in differential mode, negative voltage can be measured.
|
||||
- **data_width** Measurement width selection, the actual accuracy of ADC is 12 bits, but the accuracy of 14bits / 16bits can be achieved by averaging multiple times through OSR. Note that when a higher data width is selected, the frequency will decrease due to averaging. For details, please refer to the enumeration information.
|
||||
- **fifo_threshold** This parameter affects the DMA handling threshold and ADC FIFO interrupt threshold
|
||||
- **gain** ADC gain selection for input signal
|
||||
- Others to be added
|
||||
|
||||
ADC Device Parameter Configuration Table
|
||||
------------------------------------------
|
||||
|
||||
Each ADC has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_adc.c``, so there is no need for the user to define it by himself . When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_ADC0`` to take effect, and at the same time, the ``ADC`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_ADC0)
|
||||
#ifndef ADC0_CONFIG
|
||||
#define ADC0_CONFIG \
|
||||
{ \
|
||||
.clk_div = ADC_CLOCK_DIV_32, \
|
||||
.vref = ADC_VREF_3P2V, \
|
||||
.continuous_conv_mode = DISABLE, \
|
||||
.differential_mode = DISABLE, \
|
||||
.data_width = ADC_DATA_WIDTH_16B_WITH_256_AVERAGE, \
|
||||
.fifo_threshold = ADC_FIFO_THRESHOLD_1BYTE, \
|
||||
.gain = ADC_GAIN_1 \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/*Variable definitions*/
|
||||
static adc_device_t adcx_device[ADC_MAX_INDEX] = {
|
||||
#ifdef BSP_USING_ADC0
|
||||
ADC0_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note:: The above configuration can be modified through ``ADC_DEV(dev)->xxx`` and can only be used before ``device_open``.
|
||||
|
||||
ADC Device Interface
|
||||
------------------------
|
||||
|
||||
ADC device interfaces all follow the interfaces provided by the standard device driver management layer.
|
||||
|
||||
**adc_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``adc_register`` is used to register an ADC device standard driver interface.Before registering, you need to open the macro definition of the corresponding ADC device. For example, define the macro ``BSP_USING_ADC0`` to use the ``ADC0`` device. After the registration is completed, other interfaces can be used. If no macro is defined, the ``ADC0`` device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int adc_register(enum adc_index_type index, const char *name);
|
||||
|
||||
- **index** device index to be registered
|
||||
- **name** device name to be registered
|
||||
|
||||
``index`` is used to select ADC device configuration, one index corresponds to one ADC device configuration, for example, ``ADC0_INDEX`` corresponds to ``ADC0_CONFIG`` configuration. ``index`` has the following optional types:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum adc_index_type
|
||||
{
|
||||
#ifdef BSP_USING_ADC0
|
||||
ADC0_INDEX,
|
||||
#endif
|
||||
ADC_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open an ADC device,this funtion calls ``adc_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** Error code, 0: open successfully, others: error
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in rotation sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in rotation receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close an ADC device,this funtion calls ``adc_close`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** Error code, 0: open successfully, others: error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control and modify the parameters of the adc device according to commands.This funtion calls ``adc_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** Device handle
|
||||
- **cmd** Device control commands
|
||||
- **args** Control parameter
|
||||
- **return** Different control commands return different meanings.
|
||||
|
||||
In addition to standard control commands, serial devices also have their own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_CTRL_ADC_CHANNEL_START 0x10
|
||||
#define DEVICE_CTRL_ADC_CHANNEL_STOP 0x11
|
||||
#define DEVICE_CTRL_ADC_CHANNEL_CONFIG 0x12
|
||||
#define DEVICE_CTRL_ADC_VBAT_ON 0x13
|
||||
#define DEVICE_CTRL_ADC_VBAT_OFF 0x14
|
||||
#define DEVICE_CTRL_ADC_TSEN_ON 0x15
|
||||
#define DEVICE_CTRL_ADC_TSEN_OFF 0x16
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_SET_INT
|
||||
- adc_it_type
|
||||
- Enable ADC device interrupt
|
||||
* - DEVICE_CTRL_CLR_INT
|
||||
- adc_it_type
|
||||
- Disable ADC device interrupt
|
||||
* - DEVICE_CTRL_CONFIG
|
||||
- ADC_param_cfg_t
|
||||
- Modify ADC configuration
|
||||
* - DEVICE_CTRL_ADC_CHANNEL_CONFIG
|
||||
- adc_channel_cfg_t
|
||||
- Modify ADC channel configuration
|
||||
* - DEVICE_CTRL_ATTACH_RX_DMA
|
||||
- struct device*
|
||||
- Link receiving DMA device
|
||||
* - DEVICE_CTRL_ADC_CHANNEL_START
|
||||
- NULL
|
||||
- Start/continue ADC conversion
|
||||
* - DEVICE_CTRL_ADC_CHANNEL_STOP
|
||||
- NULL
|
||||
- Stop ADC conversion
|
||||
* - DEVICE_CTRL_ADC_VBAT_ON
|
||||
- NULL
|
||||
- Turn on the internal VDD measurement circuit
|
||||
* - DEVICE_CTRL_ADC_VBAT_OFF
|
||||
- NULL
|
||||
- Turn off the internal VDD measurement circuit
|
||||
* - DEVICE_CTRL_ADC_TSEN_ON
|
||||
- NULL
|
||||
- Turn on the internal temperature measurement circuit (requires hardware support)
|
||||
* - DEVICE_CTRL_ADC_TSEN_OFF
|
||||
- NULL
|
||||
- Turn off the internal temperature measurement circuit (requires hardware support)
|
||||
|
||||
**device_read**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_read`` is used to receive the data of ADC device, the receiving mode can be polling, interrupt, dma.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_read(struct device *dev, uint32_t pos, void *buffer, uint32_t size);
|
||||
|
||||
- **dev** Dvice handle
|
||||
- **pos** No effect
|
||||
- **buffer** Buffer to read
|
||||
- **size** Length to read
|
||||
- **return** Error code, 0: open successfully, others: error
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register an ADC threshold interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** Device handle
|
||||
- **callback** The interrupt callback function to be registered
|
||||
|
||||
- **dev** Device handle
|
||||
- **args** Receive and send buffer, the data type is uint8_t*
|
||||
- **size** Transmission length
|
||||
- **event** Type of interrupt event
|
||||
|
||||
``event`` type is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum ADC_event_type
|
||||
{
|
||||
ADC_EVENT_FIFO_READY,
|
||||
ADC_EVENT_OVERRUN,
|
||||
ADC_EVENT_UNDERRUN,
|
||||
};
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
Clock tree
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
The BL series chips have a lot of clock source selection and provide a clock tree configuration table to facilitate user configuration. Users do not need to call the clock setting interface. Users only need to care about the final system clock and peripheral clock frequency. The clock configuration table is located in the ``clock_config.h`` file under the ``bsp/board/xxx_board`` directory.
|
||||
|
||||
Clock Frequency Acquisition Interface
|
||||
---------------------------------------
|
||||
|
||||
**system_clock_get**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``system_clock_get`` is used to get the system clock frequency.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
uint32_t system_clock_get(enum system_clock_type type);
|
||||
|
||||
- **type** the type of system clock frequency
|
||||
|
||||
``type`` provide the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum system_clock_type
|
||||
{
|
||||
SYSTEM_CLOCK_ROOT_CLOCK = 0,
|
||||
SYSTEM_CLOCK_FCLK,
|
||||
SYSTEM_CLOCK_BCLK,
|
||||
SYSTEM_CLOCK_XCLK,
|
||||
SYSTEM_CLOCK_32K_CLK,
|
||||
SYSTEM_CLOCK_AUPLL,
|
||||
};
|
||||
|
||||
|
||||
**peripheral_clock_get**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``peripheral_clock_get`` is used to get the peripheral clock frequency.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
uint32_t peripheral_clock_get(enum peripheral_clock_type type);
|
||||
|
||||
- **type** peripheral clock frequency type
|
||||
|
||||
``type`` provide the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum peripheral_clock_type
|
||||
{
|
||||
PERIPHERAL_CLOCK_UART = 0,
|
||||
PERIPHERAL_CLOCK_SPI,
|
||||
PERIPHERAL_CLOCK_I2C,
|
||||
PERIPHERAL_CLOCK_ADC,
|
||||
PERIPHERAL_CLOCK_DAC,
|
||||
PERIPHERAL_CLOCK_I2S,
|
||||
PERIPHERAL_CLOCK_PWM,
|
||||
PERIPHERAL_CLOCK_CAM,
|
||||
};
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
DAC
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
|
||||
DAC Structure Definition
|
||||
---------------------------
|
||||
|
||||
DAC Parameter Configuration Table
|
||||
------------------------------------
|
||||
|
||||
DAC Device Interface
|
||||
------------------------
|
||||
|
|
@ -0,0 +1,434 @@
|
|||
DMA
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
DMA is a memory access technology that can directly read and write system memory independently without processor intervention. Under the same degree of processor burden, DMA is a fast data transfer method. The DMA device in BL series MCU has the following characteristics:
|
||||
|
||||
- 8 independent dedicated channels
|
||||
- Four transmission directions: memory to memory, memory to peripheral, peripheral to memory, peripheral to peripheral
|
||||
- LLI linked list
|
||||
|
||||
DMA Device Structure Definition
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct dma_device
|
||||
{
|
||||
struct device parent;
|
||||
uint8_t id;
|
||||
uint8_t ch;
|
||||
uint8_t direction;
|
||||
uint8_t transfer_mode;
|
||||
uint32_t src_req;
|
||||
uint32_t dst_req;
|
||||
uint8_t src_burst_size;
|
||||
uint8_t dst_burst_size;
|
||||
uint8_t src_width;
|
||||
uint8_t dst_width;
|
||||
dma_lli_ctrl_t *lli_cfg;
|
||||
} dma_device_t;
|
||||
|
||||
- **parent** inherits the properties of the parent class
|
||||
- **id** DMA id number, default 0, currently there is only one DMA
|
||||
- **ch** channel number
|
||||
- **direction** transmission direction
|
||||
- **transfer_mode** transfer mode
|
||||
- **src_req** source request
|
||||
- **dst_req** destination request
|
||||
- **src_burst_size** source burst bytes
|
||||
- **dst_burst_size** destination number of burst bytes
|
||||
- **src_width** source transmission bit width
|
||||
- **dst_width** destination transmission bit width
|
||||
- **lli_cfg** used to store some information of the dma channel, the user does not need to worry about it
|
||||
|
||||
``direction`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef enum {
|
||||
DMA_MEMORY_TO_MEMORY = 0, /*!< DMA transfer tyep:memory to memory */
|
||||
DMA_MEMORY_TO_PERIPH, /*!< DMA transfer tyep:memory to peripheral */
|
||||
DMA_PERIPH_TO_MEMORY, /*!< DMA transfer tyep:peripheral to memory */
|
||||
DMA_PERIPH_TO_PERIPH, /*!< DMA transfer tyep:peripheral to peripheral */
|
||||
}dma_transfer_dir_type;
|
||||
|
||||
``transfer_mode`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_LLI_ONCE_MODE 0
|
||||
#define DMA_LLI_CYCLE_MODE 1
|
||||
|
||||
``src_req`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_REQUEST_NONE 0x00000000 /*!< DMA request peripheral:None */
|
||||
#define DMA_REQUEST_UART0_RX 0x00000000 /*!< DMA request peripheral:UART0 RX */
|
||||
#define DMA_REQUEST_UART0_TX 0x00000001 /*!< DMA request peripheral:UART0 TX */
|
||||
#define DMA_REQUEST_UART1_RX 0x00000002 /*!< DMA request peripheral:UART1 RX */
|
||||
#define DMA_REQUEST_UART1_TX 0x00000003 /*!< DMA request peripheral:UART1 TX */
|
||||
#define DMA_REQUEST_I2C0_RX 0x00000006 /*!< DMA request peripheral:I2C RX */
|
||||
#define DMA_REQUEST_I2C0_TX 0x00000007 /*!< DMA request peripheral:I2C TX */
|
||||
#define DMA_REQUEST_SPI0_RX 0x0000000A /*!< DMA request peripheral:SPI RX */
|
||||
#define DMA_REQUEST_SPI0_TX 0x0000000B /*!< DMA request peripheral:SPI TX */
|
||||
#define DMA_REQUEST_I2S_RX 0x00000014 /*!< DMA request peripheral:I2S RX */
|
||||
#define DMA_REQUEST_I2S_TX 0x00000015 /*!< DMA request peripheral:I2S TX */
|
||||
#define DMA_REQUEST_ADC0 0x00000016 /*!< DMA request peripheral:ADC0 */
|
||||
#define DMA_REQUEST_DAC0 0x00000017 /*!< DMA request peripheral:DAC0 */
|
||||
#define DMA_REQUEST_USB_EP0 0x00000018 /*!< DMA request peripheral:USB EP0*/
|
||||
#define DMA_REQUEST_USB_EP1 0x00000019 /*!< DMA request peripheral:USB EP1*/
|
||||
#define DMA_REQUEST_USB_EP2 0x0000001A /*!< DMA request peripheral:USB EP2*/
|
||||
#define DMA_REQUEST_USB_EP3 0x0000001B /*!< DMA request peripheral:USB EP3*/
|
||||
#define DMA_REQUEST_USB_EP4 0x0000001C /*!< DMA request peripheral:USB EP4*/
|
||||
#define DMA_REQUEST_USB_EP5 0x0000001D /*!< DMA request peripheral:USB EP5*/
|
||||
#define DMA_REQUEST_USB_EP6 0x0000001E /*!< DMA request peripheral:USB EP6*/
|
||||
#define DMA_REQUEST_USB_EP7 0x0000001F /*!< DMA request peripheral:USB EP7 */
|
||||
|
||||
``dst_req`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_REQUEST_NONE 0x00000000 /*!< DMA request peripheral:None */
|
||||
#define DMA_REQUEST_UART0_RX 0x00000000 /*!< DMA request peripheral:UART0 RX */
|
||||
#define DMA_REQUEST_UART0_TX 0x00000001 /*!< DMA request peripheral:UART0 TX */
|
||||
#define DMA_REQUEST_UART1_RX 0x00000002 /*!< DMA request peripheral:UART1 RX */
|
||||
#define DMA_REQUEST_UART1_TX 0x00000003 /*!< DMA request peripheral:UART1 TX */
|
||||
#define DMA_REQUEST_I2C0_RX 0x00000006 /*!< DMA request peripheral:I2C RX */
|
||||
#define DMA_REQUEST_I2C0_TX 0x00000007 /*!< DMA request peripheral:I2C TX */
|
||||
#define DMA_REQUEST_SPI0_RX 0x0000000A /*!< DMA request peripheral:SPI RX */
|
||||
#define DMA_REQUEST_SPI0_TX 0x0000000B /*!< DMA request peripheral:SPI TX */
|
||||
#define DMA_REQUEST_I2S_RX 0x00000014 /*!< DMA request peripheral:I2S RX */
|
||||
#define DMA_REQUEST_I2S_TX 0x00000015 /*!< DMA request peripheral:I2S TX */
|
||||
#define DMA_REQUEST_ADC0 0x00000016 /*!< DMA request peripheral:ADC0 */
|
||||
#define DMA_REQUEST_DAC0 0x00000017 /*!< DMA request peripheral:DAC0 */
|
||||
#define DMA_REQUEST_USB_EP0 0x00000018 /*!< DMA request peripheral:USB EP0*/
|
||||
#define DMA_REQUEST_USB_EP1 0x00000019 /*!< DMA request peripheral:USB EP1*/
|
||||
#define DMA_REQUEST_USB_EP2 0x0000001A /*!< DMA request peripheral:USB EP2*/
|
||||
#define DMA_REQUEST_USB_EP3 0x0000001B /*!< DMA request peripheral:USB EP3*/
|
||||
#define DMA_REQUEST_USB_EP4 0x0000001C /*!< DMA request peripheral:USB EP4*/
|
||||
#define DMA_REQUEST_USB_EP5 0x0000001D /*!< DMA request peripheral:USB EP5*/
|
||||
#define DMA_REQUEST_USB_EP6 0x0000001E /*!< DMA request peripheral:USB EP6*/
|
||||
#define DMA_REQUEST_USB_EP7 0x0000001F /*!< DMA request peripheral:USB EP7 */
|
||||
|
||||
``src_burst_size`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_BURST_1BYTE 0
|
||||
#define DMA_BURST_4BYTE 1
|
||||
#define DMA_BURST_8BYTE 2
|
||||
#define DMA_BURST_16BYTE 3
|
||||
|
||||
``dst_burst_size`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_BURST_1BYTE 0
|
||||
#define DMA_BURST_4BYTE 1
|
||||
#define DMA_BURST_8BYTE 2
|
||||
#define DMA_BURST_16BYTE 3
|
||||
|
||||
``src_width`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_TRANSFER_WIDTH_8BIT 0
|
||||
#define DMA_TRANSFER_WIDTH_16BIT 1
|
||||
#define DMA_TRANSFER_WIDTH_32BIT 2
|
||||
|
||||
``dst_width``: provide the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_TRANSFER_WIDTH_8BIT 0
|
||||
#define DMA_TRANSFER_WIDTH_16BIT 1
|
||||
#define DMA_TRANSFER_WIDTH_32BIT 2
|
||||
|
||||
DMA Device Parameter Configuration Table
|
||||
------------------------------------------------
|
||||
|
||||
Each DMA device has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_dma.c``, so there is no need for the user himself Define variables. When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_DMA0_CH0``, ``DMA0_CH0_CONFIG`` will take effect, and the DMA channel 0 device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_DMA0_CH0)
|
||||
#ifndef DMA0_CH0_CONFIG
|
||||
#define DMA0_CH0_CONFIG \
|
||||
{ \
|
||||
.id = 0, \
|
||||
.ch = 0,\
|
||||
.direction = DMA_MEMORY_TO_MEMORY,\
|
||||
.transfer_mode = DMA_LLI_ONCE_MODE, \
|
||||
.src_req = DMA_REQUEST_NONE, \
|
||||
.dst_req = DMA_REQUEST_NONE, \
|
||||
.src_width = DMA_TRANSFER_WIDTH_32BIT , \
|
||||
.dst_width = DMA_TRANSFER_WIDTH_32BIT , \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
|
||||
/*Variable definitions*/
|
||||
static dma_device_t dmax_device[DMA_MAX_INDEX] =
|
||||
{
|
||||
#ifdef BSP_USING_DMA0_CH0
|
||||
DMA0_CH0_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH1
|
||||
DMA0_CH1_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH2
|
||||
DMA0_CH2_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH3
|
||||
DMA0_CH3_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH4
|
||||
DMA0_CH4_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH5
|
||||
DMA0_CH5_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH6
|
||||
DMA0_CH6_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH7
|
||||
DMA0_CH7_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``DMA_DEV(dev)->xxx`` and can only be used before calling ``device_open``.
|
||||
|
||||
DMA Device Interface
|
||||
------------------------
|
||||
|
||||
The DMA device interface follows which provided by the standard device driver management layer. In order to facilitate the user to call, some standard interfaces are redefined using macros.
|
||||
|
||||
**dma_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_register`` is used to register a DMA device standard driver interface. Before registering, you need to open the channel macro definition of the corresponding DMA device. For example, after defining the macro ``BSP_USING_DMA_CH0``, the 0 channel of the ``DMA`` device can be used. After the registration is completed, other interfaces can be used. If the macro is not defined, the 0 channel of the ``DMA`` device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int dma_register(enum dma_index_type index, const char *name);
|
||||
|
||||
- **index** device index to be registered
|
||||
- **name** device name to be registered
|
||||
|
||||
``index`` is used to select the configuration of a certain channel of DMA, an index corresponds to a channel configuration of a DMA, for example, ``DMA_CH0_INDEX`` corresponds to the configuration of DMA channel 0, and ``index`` has the following optional types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum dma_index_type
|
||||
{
|
||||
#ifdef BSP_USING_DMA0_CH0
|
||||
DMA0_CH0_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH1
|
||||
DMA0_CH1_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH2
|
||||
DMA0_CH2_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH3
|
||||
DMA0_CH3_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH4
|
||||
DMA0_CH4_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH5
|
||||
DMA0_CH5_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH6
|
||||
DMA0_CH6_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_DMA0_CH7
|
||||
DMA0_CH7_INDEX,
|
||||
#endif
|
||||
DMA_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open a channel of a dma device,this funtion calls ``dma_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** Error code, 0 means opening is successful, other means error
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close a channel of a dma device,this funtion calls ``dma_close`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** error code, 0 means closing is successful, others mean error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control and modify the parameters of the dma device according to commands.This funtion calls ``dma_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** device handle
|
||||
- **cmd** device control command
|
||||
- **args** control parameters
|
||||
- **return** different control commands return different meanings
|
||||
|
||||
In addition to standard control commands, DMA devices also have their own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DMA_CHANNEL_GET_STATUS 0x10
|
||||
#define DMA_CHANNEL_START 0x11
|
||||
#define DMA_CHANNEL_STOP 0x12
|
||||
#define DMA_CHANNEL_UPDATE 0x13
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_SET_INT
|
||||
- NULL
|
||||
- Enable DMA transfer completion interrupt
|
||||
* - DEVICE_CTRL_CLR_INT
|
||||
- NULL
|
||||
- Disable DMA transfer completion interrupt
|
||||
* - DMA_CHANNEL_GET_STATUS
|
||||
- NULL
|
||||
- Get DMA channel completion status
|
||||
* - DMA_CHANNEL_START
|
||||
- NULL
|
||||
- Open dma channel
|
||||
* - DMA_CHANNEL_STOP
|
||||
- NULL
|
||||
- Close dma channel
|
||||
* - DMA_CHANNEL_UPDATE
|
||||
- NULL
|
||||
- Update dma transmission configuration
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register a DMA channel interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** Device handle
|
||||
- **callback** The interrupt callback function to be registered
|
||||
|
||||
- **dev** device handle
|
||||
- **args** unused
|
||||
- **size** unused
|
||||
- **event** interrupt event type
|
||||
|
||||
``event`` type definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum dma_event_type
|
||||
{
|
||||
DMA_EVENT_COMPLETE,
|
||||
};
|
||||
|
||||
|
||||
**dma_channel_start**
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_channel_start`` is used to open the DMA channel. It actually calls ``device_control``, where ``cmd`` is ``DMA_CHANNEL_START``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
dma_channel_start(dev)
|
||||
|
||||
- **dev** dma channel handle that needs to be opened
|
||||
|
||||
|
||||
**dma_channel_stop**
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_channel_stop`` is used to close the DMA channel. It actually calls ``device_control``, where ``cmd`` is ``DMA_CHANNEL_STOP``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
dma_channel_stop(dev)
|
||||
|
||||
- **dev** dma channel handle that needs to be closed
|
||||
|
||||
|
||||
**dma_channel_update**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_channel_update`` is used to update the DMA configuration. The actual call is ``device_control``, where ``cmd`` is ``DMA_CHANNEL_UPDATE``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
dma_channel_update(dev,list)
|
||||
|
||||
- **dev** dma channel handle that needs to be updated
|
||||
- **list** dma_lli_ctrl_t handle
|
||||
|
||||
|
||||
**dma_channel_check_busy**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_channel_check_busy`` is used to query whether the currently used DMA channel has completed the transfer. It actually calls ``device_control``, where ``cmd`` is ``DMA_CHANNEL_GET_STATUS``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
dma_channel_check_busy(dev)
|
||||
|
||||
- **dev** DMA channel handle to be queried
|
||||
- **return** return the current DMA status, 0 means the transfer is complete, 1 means the transfer is not complete
|
||||
|
||||
**dma_reload**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``dma_reload`` is used to update the configuration of a certain channel of DMA. Compared with ``dma_channel_update``, this function does not require the user to pass many parameters, but only needs to fill in the source address, destination address, and length. After this function is called, the DMA channel is not turned on. You need to manually call the ``dma_channel_start`` function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int dma_reload(struct device *dev, uint32_t src_addr, uint32_t dst_addr, uint32_t transfer_size);
|
||||
|
||||
- **dev** DMA channel handle to be queried
|
||||
- **src_addr** transmission source address
|
||||
- **dst_addr** transmission destination address
|
||||
- **transfer_size** the total length of transferred bytes. If the number of bits transferred is 16 bits or 32 bits, it needs to be converted into byte length here.
|
||||
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
GPIO
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
The full name of GPIO is General Purpose Input Output. The GPIO peripherals of BL series chips mainly have the following functions.
|
||||
|
||||
- General input and output pull-up and pull-down
|
||||
- Multiplex function pull-up and pull-down
|
||||
- Simulation function
|
||||
- External interrupt (rising edge, falling edge, high level, low level)
|
||||
- Hardware eliminate jitter
|
||||
- Drive capacity control
|
||||
|
||||
The pin configuration of bl mcu sdk is divided into two kinds.
|
||||
|
||||
- GPIO multiplexing function is through a special **pinmux table**, users only need to modify the functions of related pins in the table, and the program will automatically configure these pins. **pinmux table** is located in the ``pinmux_config.h`` file under the ``bsp/board/xxx_board`` directory.
|
||||
- Configure the pins through the standard GPIO device interface. The disadvantage is that only common input and output and interrupt functions can be configured. It is recommended to use the table to configure the multiplexing functions.
|
||||
|
||||
GPIO Device Interface
|
||||
------------------------
|
||||
|
||||
**gpio_set_mode**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_set_mode`` is used to configure the mode of gpio.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void gpio_set_mode(uint32_t pin, uint32_t mode);
|
||||
|
||||
- **pin** the pin to be configured
|
||||
- **mode** pin function to be configured
|
||||
|
||||
``mode`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define GPIO_OUTPUT_MODE 0
|
||||
#define GPIO_OUTPUT_PP_MODE 1
|
||||
#define GPIO_OUTPUT_PD_MODE 2
|
||||
#define GPIO_INPUT_MODE 3
|
||||
#define GPIO_INPUT_PP_MODE 4
|
||||
#define GPIO_INPUT_PD_MODE 5
|
||||
#define GPIO_ASYNC_RISING_TRIGER_INT_MODE 6
|
||||
#define GPIO_ASYNC_FALLING_TRIGER_INT_MODE 7
|
||||
#define GPIO_ASYNC_HIGH_LEVEL_INT_MODE 8
|
||||
#define GPIO_ASYNC_LOW_LEVEL_INT_MODE 9
|
||||
#define GPIO_SYNC_RISING_TRIGER_INT_MODE 10
|
||||
#define GPIO_SYNC_FALLING_TRIGER_INT_MODE 11
|
||||
#define GPIO_SYNC_HIGH_LEVEL_INT_MODE 12
|
||||
#define GPIO_SYNC_LOW_LEVEL_INT_MODE 13
|
||||
|
||||
**gpio_write**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_write`` is used to set pin level
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void gpio_write(uint32_t pin, uint32_t value);
|
||||
|
||||
|
||||
- **pin** the pin to be set
|
||||
- **value** the level to be set
|
||||
|
||||
**gpio_toggle**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_toggle``: is used to toggle pin level
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void gpio_toggle(uint32_t pin);
|
||||
|
||||
- pin: the pin to be toggled
|
||||
|
||||
**gpio_read**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_read`` is used to read pin level
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int gpio_read(uint32_t pin);
|
||||
|
||||
|
||||
- **pin** the pin to read the level
|
||||
- **return** 0 is low level, 1 is high level
|
||||
|
||||
**gpio_attach_irq**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_attach_irq`` is used to attache an interrupt callback function to the interrupt pin
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void gpio_attach_irq(uint32_t pin, void (*cbfun)(uint32_t pin));
|
||||
|
||||
- **pin** the pin to which the interrupt callback is attached
|
||||
- **cbfun** register interrupt callback
|
||||
|
||||
**gpio_irq_enable**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``gpio_irq_enable`` is used to enable gpio interrupt
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void gpio_irq_enable(uint32_t pin,uint8_t enabled);
|
||||
|
||||
- **pin** the pin to turn on or off the interrupt
|
||||
- **enabled** 0 is to close the interrupt, 1 is to open the interrupt
|
||||
|
|
@ -0,0 +1,160 @@
|
|||
I2C
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
I2C (Inter-Intergrated Circuit) is a serial communication bus that uses a multi-master-slave architecture to connect low-speed peripheral devices. Each device has a unique address identification, and can be used as a transmitter or receiver. Each device connected to the bus can set the address with software through a unique address and the always-existing relationship between master and slave, and the host can be used as a host transmitter or host receiver. If two or more hosts are initialized at the same time, data transmission can prevent data from being destroyed through conflict detection and arbitration. The I2C devices in the BL series MCU have the following characteristics:
|
||||
|
||||
- Flexible configuration of slave address ``slaveAddr``, register address ``subAddr``
|
||||
- Clock frequency that can be flexibly adjusted
|
||||
- Support polling, interrupt, DMA transfer
|
||||
|
||||
|
||||
I2C Device Structure Definition
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct i2c_device
|
||||
{
|
||||
struct device parent;
|
||||
uint8_t id;
|
||||
uint8_t mode;
|
||||
uint32_t phase;
|
||||
} i2c_device_t;
|
||||
|
||||
- **parent** inherit the properties of the parent class
|
||||
- **ch** i2c id, 0 means i2c0, 1 means i2c1
|
||||
- **mode** i2c transmission mode, 0 means using hardware i2c, 1 means using software i2c, current software i2c is temporarily invalid
|
||||
- **phase** i2c clock phase div, i2c_clk = i2c_source_clk/(4*(phase+1))
|
||||
- TODO
|
||||
|
||||
I2C Device Parameter Configuration Table
|
||||
--------------------------------------------
|
||||
|
||||
Each I2C device has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_i2c.c``, so the user does not need to define variable. When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_I2C0``, ``I2C0_CONFIG`` will take effect, and the ``I2C`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_I2C0)
|
||||
#ifndef I2C0_CONFIG
|
||||
#define I2C0_CONFIG \
|
||||
{ \
|
||||
.id = 0, \
|
||||
.mode = I2C_HW_MODE,\
|
||||
.phase = 15, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/*Variable definition*/
|
||||
static i2c_device_t i2cx_device[I2C_MAX_INDEX] =
|
||||
{
|
||||
#ifdef BSP_USING_I2C0
|
||||
I2C0_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``I2C_DEV(dev)->xxx`` and can only be used before calling ``device_open``.
|
||||
|
||||
I2C Device Interface
|
||||
------------------------
|
||||
|
||||
The I2C device standard interface currently only uses ``device_open``, and provides a standard data transceiver interface.
|
||||
|
||||
**i2c_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``i2c_register`` is used to register an I2C device standard driver interface. The macro definition of the corresponding I2C device needs to be opened before registration. For example, define the macro ``BSP_USING_I2C0`` to use the ``I2C0`` device. After the registration is completed, other interfaces can be used. If the macro is not defined, the ``I2C0`` device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int i2c_register(enum i2c_index_type index, const char *name);
|
||||
|
||||
- **index** device index to be registered
|
||||
- **name** device name to be registered
|
||||
|
||||
``index`` is used to select I2C device, one index corresponds to one I2C device configuration, for example, ``I2C0_INDEX`` corresponds to ``I2C0_CONFIG`` configuration, ``index`` has the following optional types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum i2c_index_type
|
||||
{
|
||||
#ifdef BSP_USING_I2C0
|
||||
I2C0_INDEX,
|
||||
#endif
|
||||
I2C_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open an i2c device, this funtion calls ``i2c_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** error code, 0 means opening is successful, others mean errors
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**i2c_transfer**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``i2c_transfer`` is used to transfer i2c msg. The member ``flags`` in ``i2c_msg_t`` structure indicates whether the direction of the transfer is writing or reading, and the length of the specified register address is 0, 1, 2.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int i2c_transfer(struct device *dev, i2c_msg_t msgs[], uint32_t num);
|
||||
|
||||
- **dev** device handle
|
||||
- **msgs** message to be transmitted
|
||||
- **num** the number of messages
|
||||
- **return** error code, 0 means opening is successful, others mean error
|
||||
|
||||
``i2c_msg_t`` structure is defined as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct i2c_msg
|
||||
{
|
||||
uint8_t slaveaddr;
|
||||
uint32_t subaddr;
|
||||
uint16_t flags;
|
||||
uint16_t len;
|
||||
uint8_t *buf;
|
||||
} i2c_msg_t;
|
||||
|
||||
- **slaveaddr** i2c slave device 7-bit slave address
|
||||
- **subaddr** i2c slave device register address
|
||||
- **flags** read and write mode and register address length
|
||||
- **len** transmission data length
|
||||
- **buf** data buffer
|
||||
|
||||
``flags`` definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Read and write mode*/
|
||||
#define I2C_WR 0x0000
|
||||
#define I2C_RD 0x0001
|
||||
|
||||
/*Register address length*/
|
||||
#define SUB_ADDR_0BYTE 0x0010
|
||||
#define SUB_ADDR_1BYTE 0x0020
|
||||
#define SUB_ADDR_2BYTE 0x0040
|
||||
|
|
@ -0,0 +1,283 @@
|
|||
PWM
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
PWM is a technology that implements analog voltage control in a digital way. It modulates the width of a series of pulses, equivalent to the required waveform (including shape and amplitude), and digitally encodes the analog signal level. That is to say, by adjusting the change of the duty cycle to adjust the change of the signal, energy, etc. The duty cycle refers to the percentage of the entire signal period when the signal is at a high level. For example, the duty cycle of a square wave is 50%. The DMA device in BL series MCU has the following characteristics:
|
||||
|
||||
- Support 5-channel PWM
|
||||
- Three clock sources can be selected (bus clock <bclk>, crystal oscillator clock <xtal_ck>, slow clock <32k>), with 16-bit clock divider
|
||||
- Double threshold domain setting, increase pulse flexibility
|
||||
|
||||
PWM Device Structure Definition
|
||||
---------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct pwm_device {
|
||||
struct device parent;
|
||||
uint8_t ch;
|
||||
uint8_t polarity_invert_mode;
|
||||
uint16_t period;
|
||||
uint16_t threshold_low;
|
||||
uint16_t threshold_high;
|
||||
uint16_t it_pulse_count;
|
||||
|
||||
} pwm_device_t;
|
||||
|
||||
- **parent** inherit the properties of the parent class
|
||||
- **ch** channel number, ch is 0 if PWM channel 0 is enabled, ch is 1 if PWM channel 1 is enabled, and so on
|
||||
- **polarity_invert_mode** polarity invert enable
|
||||
- **period** PWM period value
|
||||
- **threshold_low** PWM low threshold
|
||||
- **threshold_high** PWM high threshold
|
||||
- **it_pulse_count** The cycle count value that triggered the interrupt condition
|
||||
|
||||
.. note::
|
||||
PWM actual frequency = pwm_clock_source/frequency_division/period, period is not the actual PWM period,it just has the same name.
|
||||
|
||||
.. note:: PWM Duty cycle = (threshold_high-threshold_low)/period * 100%
|
||||
|
||||
PWM Device Parameter Configuration Table
|
||||
------------------------------------------
|
||||
|
||||
Each PWM device has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_pwm.c``, so the user does not need to define variable. When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_PWM_CH2``, and ``PWM_CH2_CONFIG`` will take effect, and at the same time, channel 2 of the ``PWM`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_PWM_CH2)
|
||||
#ifndef PWM_CH2_CONFIG
|
||||
#define PWM_CH2_CONFIG \
|
||||
{ \
|
||||
.ch = 2, \
|
||||
.polarity_invert_mode = DISABLE, \
|
||||
.period = 0, \
|
||||
.threshold_low = 0, \
|
||||
.threshold_high = 0, \
|
||||
.it_pulse_count = 0, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
|
||||
/*Variable definitions*/
|
||||
static pwm_device_t pwmx_device[PWM_MAX_INDEX] = {
|
||||
#ifdef BSP_USING_PWM_CH0
|
||||
PWM_CH0_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH1
|
||||
PWM_CH1_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH2
|
||||
PWM_CH2_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH3
|
||||
PWM_CH3_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH4
|
||||
PWM_CH4_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``PWM_DEV(dev)->xxx``, and can only be used before calling ``device_open``.
|
||||
|
||||
PWM device interface
|
||||
------------------------
|
||||
|
||||
The PWM device interfaces all follow the interfaces provided by the standard device driver management layer. And in order to facilitate the user to call, some standard interfaces are redefined using macros.
|
||||
|
||||
**pwm_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pwm_register`` is used to register a channel of the PWM device standard driver interface. Before registering, you need to open the macro definition of a certain channel of the corresponding PWM device. For example, define ``BSP_USING_PWM_CH0`` before you can use the ``PWM`` channel 0 device. After the registration is completed, other interfaces can be used. If no macro is defined, the PWM device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int pwm_register(enum pwm_index_type index, const char *name);
|
||||
|
||||
- **index** the index of the device to be registered
|
||||
- **name** name the registered device
|
||||
|
||||
``index`` is used to select the configuration of a certain channel of the PWM device. An index corresponds to a channel configuration of a PWM device. For example, ``PWM_CH0_INDEX`` corresponds to the configuration of PWM channel 0, and ``index`` has the following optional types:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum pwm_index_type
|
||||
{
|
||||
#ifdef BSP_USING_PWM_CH0
|
||||
PWM_CH0_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH1
|
||||
PWM_CH1_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH2
|
||||
PWM_CH2_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH3
|
||||
PWM_CH3_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_PWM_CH4
|
||||
PWM_CH4_INDEX,
|
||||
#endif
|
||||
PWM_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open a channel of a pwm device,this funtion calls ``pwm_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** error code, 0 means opening is successful, others mean errors
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close a channel of a pwm device.this funtion calls ``pwm_close`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** error code, 0 means closing is successful, others mean error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control and modify the parameters of the PWM device according to commands.This funtion calls ``pwm_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** device handle
|
||||
- **cmd** device control command
|
||||
- **args** control parameters
|
||||
- **return** different control commands return different meanings
|
||||
|
||||
In addition to standard control commands, PWM devices also have their own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEIVCE_CTRL_PWM_IT_PULSE_COUNT_CONFIG 0x10
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_RESUME
|
||||
- NULL
|
||||
- Enable the current PWM channel
|
||||
* - DEVICE_CTRL_SUSPEND
|
||||
- NULL
|
||||
- Disable the current PWM channel
|
||||
* - DEVICE_CTRL_PWM_FREQUENCE_CONFIG
|
||||
- uint32_t
|
||||
- Configure the current PWM channel period
|
||||
* - DEVICE_CTRL_PWM_DUTYCYCLE_CONFIG
|
||||
- pwm_dutycycle_config_t
|
||||
- Configure the current PWM channel duty cycle
|
||||
* - DEVICE_CTRL_PWM_IT_PULSE_COUNT_CONFIG
|
||||
- uint32_t
|
||||
- Configure the trigger PWM interrupt period value
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register a PWM channel interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** device handle
|
||||
- **callback** the interrupt callback function to be registered
|
||||
|
||||
- **dev** device handle
|
||||
- **args** unused
|
||||
- **size** unused
|
||||
- **event** interrupt event type
|
||||
|
||||
``event`` type definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum pwm_event_type
|
||||
{
|
||||
PWM_EVENT_COMPLETE,
|
||||
};
|
||||
|
||||
**pwm_channel_start**
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pwm_channel_start`` is used to start the PWM channel. It actually calls ``device_control``, where ``cmd`` is ``DEVICE_CTRL_RESUME``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
pwm_channel_start(dev)
|
||||
|
||||
- **dev** pwm channel handle that needs to be opened
|
||||
|
||||
|
||||
**pwm_channel_stop**
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pwm_channel_stop`` is used to close the PWM channel. It actually calls ``device_control``, where ``cmd`` is ``DEVICE_CTRL_SUSPEND``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
pwm_channel_stop(dev)
|
||||
|
||||
- **dev** pwm channel handle that needs to be closed
|
||||
|
||||
|
||||
**pwm_channel_update**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pwm_channel_update`` is used to update the frequency and duty cycle of the PWM channel. The actual call is ``device_control``, where ``cmd`` is ``DEVICE_CTRL_CONFIG``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
pwm_channel_update(dev,cfg)
|
||||
|
||||
- **dev** pwm channel handle that needs to be updated
|
||||
- **cfg** pwm_config_t handle
|
||||
|
||||
|
||||
**pwm_it_pulse_count_update**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pwm_it_pulse_count_update`` is used to update the count value of the PWM channel. The PWM interrupt needs to be enabled before it takes effect. When the PWM count reaches the set period count value, an interrupt will be generated. The actual call is ``device_control``, where ``cmd`` is ``DEIVCE_CTRL_PWM_IT_PULSE_COUNT_CONFIG``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
pwm_it_pulse_count_update(dev,count)
|
||||
|
||||
- **dev** pwm channel handle that needs to update the cycle count value
|
||||
- **count** cycle count value
|
||||
|
||||
|
|
@ -0,0 +1,363 @@
|
|||
SPI
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
Serial Peripheral Interface Bus (SPI) is a synchronous serial communication interface specification for short-range communication. The full-duplex communication mode is used between devices, which is a master-slave mode of one master and one or more slaves, and requires at least 4 wires. In fact, 3 wires are also available (when transmitting in one direction), including SDI (data input), SDO (data output), SCLK (clock), CS (chip select). The SPI devices in the BL series MCU have the following characteristics:
|
||||
|
||||
- It can be used as both SPI master and SPI slave.
|
||||
- The transmit and receive channels each have a FIFO with a depth of 4 words
|
||||
- Both master and slave devices support 4 clock formats (CPOL, CPHA)
|
||||
- Both master and slave devices support 1/2/3/4 byte transmission mode
|
||||
- Flexible clock configuration, up to 40M clock
|
||||
- Configurable MSB/LSB priority transmission
|
||||
- Receive filter function
|
||||
- Timeout mechanism under slave device
|
||||
- Support polling, interrupt, DMA transfer
|
||||
|
||||
SPI Device Structure Definition
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct spi_device
|
||||
{
|
||||
struct device parent;
|
||||
uint8_t id;
|
||||
uint32_t clk;
|
||||
uint8_t mode;
|
||||
uint8_t direction;
|
||||
uint8_t clk_polaraity;
|
||||
uint8_t clk_phase;
|
||||
uint8_t datasize;
|
||||
uint8_t fifo_threshold;
|
||||
void* tx_dma;
|
||||
void* rx_dma;
|
||||
} spi_device_t;
|
||||
|
||||
- **parent** inherit the properties of the parent class
|
||||
- **id** SPI id, 0 means SPI0
|
||||
- **clk** SPI clock frequency
|
||||
- **mode** master mode or slave mode
|
||||
- **direction** transmission first mode
|
||||
- **clk_polaraity** clock polarity
|
||||
- **clk_phase** clock phase
|
||||
- **datasize** data transmission bit width
|
||||
- **fifo_threshold** fifo threshold, the maximum is 4
|
||||
- **tx_dma** additional send dma handle
|
||||
- **rx_dma** dditional receive dma handle
|
||||
|
||||
``mode`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_SLVAE_MODE 0
|
||||
#define SPI_MASTER_MODE 1
|
||||
|
||||
``direction`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_LSB_BYTE0_DIRECTION_FIRST 0
|
||||
#define SPI_LSB_BYTE3_DIRECTION_FIRST 1
|
||||
#define SPI_MSB_BYTE0_DIRECTION_FIRST 2
|
||||
#define SPI_MSB_BYTE3_DIRECTION_FIRST 3
|
||||
|
||||
``clk_polaraity`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_POLARITY_LOW 0
|
||||
#define SPI_POLARITY_HIGH 1
|
||||
|
||||
``clk_phase`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_PHASE_1EDGE 0
|
||||
#define SPI_PHASE_2EDGE 1
|
||||
|
||||
|
||||
``datasize`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_DATASIZE_8BIT 0
|
||||
#define SPI_DATASIZE_16BIT 1
|
||||
#define SPI_DATASIZE_24BIT 2
|
||||
#define SPI_DATASIZE_32BIT 3
|
||||
|
||||
SPI Device Parameter Configuration Table
|
||||
------------------------------------------
|
||||
|
||||
Each SPI device has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_spi.c``, so the user does not need to define variable. When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_SPI0``, ``SPI0_CONFIG`` will take effect, and the ``SPI0`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_SPI0)
|
||||
#ifndef SPI0_CONFIG
|
||||
#define SPI0_CONFIG \
|
||||
{ \
|
||||
.id = 0, \
|
||||
.clk = 18000000,\
|
||||
.mode = SPI_MASTER_MODE, \
|
||||
.direction = SPI_MSB_BYTE0_DIRECTION_FIRST, \
|
||||
.clk_polaraity = SPI_POLARITY_LOW, \
|
||||
.clk_phase = SPI_PHASE_1EDGE, \
|
||||
.datasize = SPI_DATASIZE_8BIT, \
|
||||
.fifo_threshold = 1, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/*Variable definition*/
|
||||
static spi_device_t spix_device[SPI_MAX_INDEX] =
|
||||
{
|
||||
#ifdef BSP_USING_SPI0
|
||||
SPI0_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``SPI_DEV(dev)->xxx`` and can only be used before calling ``device_open``.
|
||||
|
||||
|
||||
SPI Device Interface
|
||||
------------------------
|
||||
|
||||
SPI device interface follows which provided by the standard device driver management layer.
|
||||
|
||||
**spi_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``spi_register`` is used to register an SPI device standard driver interface. Before registering, you need to open the macro definition of the corresponding SPI device. For example, define the macro ``BSP_USING_SPI0`` before you can use the SPI0 device. After the registration is completed, other interfaces can be used. If no macro is defined, the SPI device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int spi_register(enum spi_index_type index, const char *name);
|
||||
|
||||
- **index** device index to be registered
|
||||
- **name** device name to be registered
|
||||
|
||||
``index`` is used to select SPI device configuration, one index corresponds to one SPI device configuration, for example, ``SPI0_INDEX`` corresponds to ``SPI0_CONFIG`` configuration, and ``index`` has the following optional types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum spi_index_type
|
||||
{
|
||||
#ifdef BSP_USING_SPI0
|
||||
SPI0_INDEX,
|
||||
#endif
|
||||
SPI_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open the device,this funtion calls ``spi_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** error code, 0 means opening is successful, others mean errors
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close the device,this funtion calls ``spi_close`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** error code, 0 means closing is successful, others means error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control the device and modify parameters according to commands.This funtion calls ``spi_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** device handle
|
||||
- **cmd** device control command
|
||||
- **args** control parameters
|
||||
- **return** Different control commands return different meanings.
|
||||
|
||||
In addition to standard control commands, SPI devices also have their own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_CTRL_SPI_CONFIG_CLOCK 0x10
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_SET_INT
|
||||
- NULL
|
||||
- Enable spi device interrupt
|
||||
* - DEVICE_CTRL_CLR_INT
|
||||
- NULL
|
||||
- Disable spi device interrupt
|
||||
* - DEVICE_CTRL_RESUME
|
||||
- NULL
|
||||
- Resume spi device
|
||||
* - DEVICE_CTRL_SUSPEND
|
||||
- NULL
|
||||
- Suspend spi device
|
||||
* - DEVICE_CTRL_ATTACH_TX_DMA
|
||||
- NULL
|
||||
- Link to tx dma device
|
||||
* - DEVICE_CTRL_ATTACH_RX_DMA
|
||||
- NULL
|
||||
- Link to rx dma device
|
||||
* - DEVICE_CTRL_SPI_CONFIG_CLOCK
|
||||
- NULL
|
||||
- Modify SPI device clock
|
||||
* - DEVICE_CTRL_TX_DMA_SUSPEND
|
||||
- NULL
|
||||
- Suspend spi tx dma mode
|
||||
* - DEVICE_CTRL_RX_DMA_SUSPEND
|
||||
- NULL
|
||||
- Suspend spi rx dma mode
|
||||
* - DEVICE_CTRL_TX_DMA_RESUME
|
||||
- NULL
|
||||
- Resume spi tx dma mode
|
||||
* - DEVICE_CTRL_RX_DMA_RESUME
|
||||
- NULL
|
||||
- Resume spi rx dma mode
|
||||
|
||||
**device_write**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_write`` is used to send data. The sending mode can be polling, interrupt, dma according to the open mode.This funtion calls ``spi_write`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_write(struct device *dev, uint32_t pos, const void *buffer, uint32_t size);
|
||||
|
||||
- **dev** device handle
|
||||
- **pos** useless
|
||||
- **buffer** the buffer to be written
|
||||
- **size** the length to be written
|
||||
- **return** error code, 0 means writing is successful, others mean errors
|
||||
|
||||
**device_read**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_read`` is used to receive data, and the receiving mode can be polling, interrupt, dma according to the open mode.This funtion calls ``spi_read`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_read(struct device *dev, uint32_t pos, void *buffer, uint32_t size);
|
||||
|
||||
- **dev** device handle
|
||||
- **pos** useless
|
||||
- **buffer** the buffer to be read
|
||||
- **size** the length to be read
|
||||
- **return** error code, 0 means successful reading, others mean errors
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register an SPI device interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** device handle
|
||||
- **callback** the interrupt callback function to be registered
|
||||
|
||||
- **dev** device handle
|
||||
- **args** receive and send buffer, the data type is uint8_t*
|
||||
- **size** transmission length
|
||||
- **event** interrupt event type
|
||||
|
||||
``event`` type definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum spi_event_type
|
||||
{
|
||||
SPI_EVENT_TX_FIFO,
|
||||
SPI_EVENT_RX_FIFO,
|
||||
SPI_EVENT_UNKNOWN
|
||||
};
|
||||
|
||||
**spi_transmit**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``spi_transmit`` is used to send data from SPI devices.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int spi_transmit(struct device *dev, void *buffer, uint32_t size, uint8_t type);
|
||||
|
||||
- **dev** device handle
|
||||
- **buffer** send data buffer
|
||||
- **size** send length
|
||||
- **type** send bit width type
|
||||
|
||||
``type`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define SPI_TRANSFER_TYPE_8BIT 0
|
||||
#define SPI_TRANSFER_TYPE_16BIT 1
|
||||
#define SPI_TRANSFER_TPYE_24BIT 2
|
||||
#define SPI_TRANSFER_TYPE_32BIT 3
|
||||
|
||||
**spi_receive**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``spi_receive`` is used to receive data from SPI devices.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int spi_receive(struct device *dev, void *buffer, uint32_t size, uint8_t type);
|
||||
|
||||
- **dev** device handle
|
||||
- **buffer** receive data buffer
|
||||
- **size** receiving length
|
||||
- **type** bit width type
|
||||
|
||||
**spi_transmit_receive**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``spi_transmit_receive`` is used to send and receive data from SPI devices.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int spi_transmit_receive(struct device *dev, const void *send_buf, void *recv_buf, uint32_t length, uint8_t type);
|
||||
|
||||
- **dev** device handle
|
||||
- **send_buf** send data buffer
|
||||
- **recv_buf** receive data buffer
|
||||
- **length** send and receive length
|
||||
- **type** bit width type
|
||||
|
|
@ -0,0 +1,282 @@
|
|||
TIMER
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
The TIMER device in BL series MCU has the following characteristics:
|
||||
|
||||
- Multiple clock source options
|
||||
- 8-bit clock divider, the division factor is 1-256
|
||||
- Two 32-bit timers
|
||||
- Each timer can independently set three groups of alarm values
|
||||
- Support FreeRun mode and PreLoad mode
|
||||
- 16-bit watchdog
|
||||
- Support write protection to prevent system abnormalities caused by incorrect settings
|
||||
- Support two watchdog overflow modes, interrupt or reset
|
||||
|
||||
TIMER Device Structure Definition
|
||||
------------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct timer_device {
|
||||
struct device parent;
|
||||
uint8_t id;
|
||||
enum timer_cnt_mode_type cnt_mode;
|
||||
enum timer_preload_trigger_type trigger;
|
||||
uint32_t reload;
|
||||
uint32_t timeout1;
|
||||
uint32_t timeout2;
|
||||
uint32_t timeout3;
|
||||
} timer_device_t;
|
||||
|
||||
- **parent** inherit the properties of the parent class
|
||||
- **id** timer id
|
||||
- **cnt_mode** counting mode:FreeRun and preload
|
||||
- **trigger** source of preload comparator
|
||||
- **reload** reload value in preload mode
|
||||
- **timeout1** compare source 0 timout value ,unit is us
|
||||
- **timeout2** compare source 1 timout value ,unit is us
|
||||
- **timeout3** compare source 2 timout value ,unit is us
|
||||
|
||||
``ch`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum timer_index_type {
|
||||
TIMER0_INDEX,
|
||||
TIMER1_INDEX,
|
||||
TIMER_MAX_INDEX
|
||||
};
|
||||
|
||||
``cnt_mode`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum timer_cnt_mode_type {
|
||||
TIMER_CNT_PRELOAD,
|
||||
TIMER_CNT_FREERUN,
|
||||
};
|
||||
|
||||
``pl_trig_src`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum timer_preload_trigger_type {
|
||||
TIMER_PRELOAD_TRIGGER_NONE,
|
||||
TIMER_PRELOAD_TRIGGER_COMP0,
|
||||
TIMER_PRELOAD_TRIGGER_COMP1,
|
||||
TIMER_PRELOAD_TRIGGER_COMP2,
|
||||
};
|
||||
|
||||
TIMER Device Parameter Configuration Table
|
||||
---------------------------------------------
|
||||
|
||||
Each TIMER has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_timer.c``, so the user does not need to define the variable . When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_TIMER_CH0``, ``TIMER_CH0_CONFIG`` will take effect, and the ``TIMER_CH0_INDEX`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_TIMER0)
|
||||
#ifndef TIMER0_CONFIG
|
||||
#define TIMER0_CONFIG \
|
||||
{ \
|
||||
.id = 0, \
|
||||
.cnt_mode = TIMER_CNT_PRELOAD, \
|
||||
.trigger = TIMER_PRELOAD_TRIGGER_COMP2, \
|
||||
.reload = 0, \
|
||||
.timeout1 = 1000000, \
|
||||
.timeout2 = 2000000, \
|
||||
.timeout3 = 3000000, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#if defined(BSP_USING_TIMER1)
|
||||
#ifndef TIMER1_CONFIG
|
||||
#define TIMER1_CONFIG \
|
||||
{ \
|
||||
.id = 1, \
|
||||
.cnt_mode = TIMER_CNT_PRELOAD, \
|
||||
.trigger = TIMER_PRELOAD_TRIGGER_COMP0, \
|
||||
.reload = 0, \
|
||||
.timeout1 = 1000000, \
|
||||
.timeout2 = 2000000, \
|
||||
.timeout3 = 3000000, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/*Variable definitions*/
|
||||
static timer_device_t timerx_device[TIMER_MAX_INDEX] = {
|
||||
#ifdef BSP_USING_TIMER0
|
||||
TIMER0_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_TIMER1
|
||||
TIMER1_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``TIMER_DEV(dev)->xxx`` and can only be used before calling ``device_open``.
|
||||
|
||||
TIMER Device Interface
|
||||
------------------------
|
||||
|
||||
TIMER device interface follows which provided by the standard device driver management layer.
|
||||
|
||||
**timer_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``timer_register`` is used to register a TIMER device standard driver interface. Before registering, you need to open the macro definition of the corresponding TIMER device. For example, define the macro ``BSP_USING_TIMER_CH0`` to use the ``TIMER_CH0_INDEX`` device. After the registration is completed, other interfaces can be used. If the macro is not defined, the ``TIMER_CH0_INDEX`` device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int timer_register(enum timer_index_type index, const char *name);
|
||||
|
||||
- **index** the index of the device to be registered
|
||||
- **name** Name the device
|
||||
|
||||
``index`` is used to select TIMER device configuration, one index corresponds to a TIMER device configuration, for example, ``TIMER_CH0_INDEX`` corresponds to ``TIMER_CH0_CONFIG`` configuration, and ``index`` has the following optional types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum timer_index_type {
|
||||
#ifdef BSP_USING_TIMER0
|
||||
TIMER0_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_TIMER1
|
||||
TIMER1_INDEX,
|
||||
#endif
|
||||
TIMER_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open a TIMER device, this funtion calls ``timer_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open method
|
||||
- **return** error code, 0 means opening is successful, others mean error
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in polling receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close a TIMER device,this funtion calls ``timer_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** error code, 0 means closing is successful, others mean error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control and modify the parameters of the TIMER device according to commands.This funtion calls ``timer_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** device handle
|
||||
- **cmd** device control command
|
||||
- **args** control parameters
|
||||
- **return** different control commands return different meanings
|
||||
|
||||
In addition to standard control commands, TIMER device also has its own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_CTRL_TIMER_CH_START 0x80
|
||||
#define DEVICE_CTRL_TIMER_CH_STOP 0x81
|
||||
#define DEVICE_CTRL_GET_MATCH_STATUS 0x82
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_SET_INT
|
||||
- timer_it_type
|
||||
- Enable TIMER interrupt
|
||||
* - DEVICE_CTRL_CLR_INT
|
||||
- timer_it_type
|
||||
- Disable TIMER interrupt
|
||||
* - DEVICE_CTRL_GET_INT
|
||||
- NULL
|
||||
- Get TIMER interrupt status
|
||||
* - DEVICE_CTRL_RESUME
|
||||
- NULL
|
||||
- Enable TIMER
|
||||
* - DEVICE_CTRL_SUSPEND
|
||||
- NULL
|
||||
- Disable TIMER
|
||||
* - DEVICE_CTRL_GET_CONFIG
|
||||
- NULL
|
||||
- Get TIMER current count
|
||||
|
||||
**device_write**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_write`` is used to config timer device timeout value.This funtion calls ``timer_write`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_write(struct device *dev, uint32_t pos, const void *buffer, uint32_t size);
|
||||
|
||||
- **dev** device handle
|
||||
- **pos** unused
|
||||
- **buffer** timer_timeout_cfg_t handle
|
||||
- **size** the length of timer_timeout_cfg_t
|
||||
- **return** error code, 0 means writing is successful, others mean errors
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register a timer compare interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** device handle
|
||||
- **callback** the interrupt callback function to be registered
|
||||
|
||||
- **dev** device handle
|
||||
- **args** unused
|
||||
- **size** unused
|
||||
- **event** interrupt event type
|
||||
|
||||
``event`` type definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum timer_event_type {
|
||||
TIMER_EVENT_COMP0,
|
||||
TIMER_EVENT_COMP1,
|
||||
TIMER_EVENT_COMP2,
|
||||
TIMER_EVENT_UNKNOWN
|
||||
};
|
||||
|
|
@ -0,0 +1,308 @@
|
|||
UART
|
||||
=========================
|
||||
|
||||
Introduction
|
||||
------------------------
|
||||
|
||||
UART is a universal asynchronous transmitter-receiver, which provides a flexible way for full-duplex data exchange with external devices. The UART device in BL series MCU has the following characteristics:
|
||||
|
||||
- Data bit length can choose 5/6/7/8 bits
|
||||
- Stop bit length can be selected 0.5/1/1.5/2 bits
|
||||
- Support odd/even/no parity bit
|
||||
- Support hardware flow control (RTS/CTS)
|
||||
- Automatic baud rate detection
|
||||
- Support LIN protocol (transceive BREAK/SYNC)
|
||||
- Send/receive FIFO
|
||||
- Support polling, interrupt, DMA transfer
|
||||
- Unique rto interrupt
|
||||
|
||||
UART Device Structure Definition
|
||||
----------------------------------
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef struct uart_device
|
||||
{
|
||||
struct device parent;
|
||||
uint8_t id;
|
||||
uint32_t baudrate;
|
||||
uart_databits_t databits;
|
||||
uart_stopbits_t stopbits;
|
||||
uart_parity_t parity;
|
||||
uint8_t fifo_threshold;
|
||||
void* tx_dma;
|
||||
void* rx_dma;
|
||||
} uart_device_t;
|
||||
|
||||
- **parent** inherit the properties of the parent class
|
||||
- **id** serial port id, if serial port 0 is enabled, id is 0, if serial port 1 is enabled, id is 1, and so on
|
||||
- **baudrate** baud rate
|
||||
- **databits** data bits
|
||||
- **stopbits** stop bits
|
||||
- **parity** parity
|
||||
- **fifo_threshold** fifo threshold, the maximum value of different mcu is different
|
||||
- **tx_dma** additional send dma handle
|
||||
- **rx_dma** additional receive dma handle
|
||||
|
||||
``databits`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef enum
|
||||
{
|
||||
UART_DATA_LEN_5 = 0, /*!< Data length is 5 bits */
|
||||
UART_DATA_LEN_6 = 1, /*!< Data length is 6 bits */
|
||||
UART_DATA_LEN_7 = 2, /*!< Data length is 7 bits */
|
||||
UART_DATA_LEN_8 = 3 /*!< Data length is 8 bits */
|
||||
} uart_databits_t;
|
||||
|
||||
``stopbits`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef enum
|
||||
{
|
||||
UART_STOP_ONE = 0, /*!< One stop bit */
|
||||
UART_STOP_ONE_D_FIVE = 1, /*!< 1.5 stop bit */
|
||||
UART_STOP_TWO = 2 /*!< Two stop bits */
|
||||
} uart_stopbits_t;
|
||||
|
||||
``parity`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
typedef enum
|
||||
{
|
||||
UART_PAR_NONE = 0, /*!< No parity */
|
||||
UART_PAR_ODD = 1, /*!< Parity bit is odd */
|
||||
UART_PAR_EVEN = 2, /*!< Parity bit is even */
|
||||
} uart_parity_t;
|
||||
|
||||
UART Device Parameter Configuration Table
|
||||
-------------------------------------------
|
||||
|
||||
Each UART device has a parameter configuration macro, the macro definition is located in the ``peripheral_config.h`` file under the ``bsp/board/xxx`` directory, and the variable definition is located in ``hal_uart.c``, so the user does not need to define variable. When the user opens the macro of the corresponding device, the configuration of the device will take effect. For example, open the macro ``BSP_USING_UART0``, ``UART0_CONFIG`` will take effect, and the ``UART0`` device can be registered and used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/*Parameter configuration macro*/
|
||||
#if defined(BSP_USING_UART0)
|
||||
#ifndef UART0_CONFIG
|
||||
#define UART0_CONFIG \
|
||||
{ \
|
||||
.id = 0, \
|
||||
.baudrate = 2000000,\
|
||||
.databits = UART_DATA_LEN_8, \
|
||||
.stopbits = UART_STOP_ONE, \
|
||||
.parity = UART_PAR_NONE, \
|
||||
.fifo_threshold = 1, \
|
||||
}
|
||||
#endif
|
||||
#endif
|
||||
|
||||
/*Variable definitions*/
|
||||
static uart_device_t uartx_device[UART_MAX_INDEX] =
|
||||
{
|
||||
#ifdef BSP_USING_UART0
|
||||
UART0_CONFIG,
|
||||
#endif
|
||||
#ifdef BSP_USING_UART1
|
||||
UART1_CONFIG,
|
||||
#endif
|
||||
};
|
||||
|
||||
.. note::
|
||||
The above configuration can be modified through ``UART_DEV(dev)->xxx`` and can only be used before calling ``device_open``.
|
||||
|
||||
UART Device Interface
|
||||
------------------------
|
||||
|
||||
UART device interface follows which provided by the standard device driver management layer.
|
||||
|
||||
**uart_register**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``uart_register`` is used to register a UART device standard driver interface. Before registering, you need to open the macro definition of the corresponding UART device. For example, define the macro ``BSP_USING_UART0`` to use the ``UART0`` device. After the registration is completed, other interfaces can be used. If the macro is not defined, the ``UART0`` device cannot be used.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int uart_register(enum uart_index_type index, const char *name);
|
||||
|
||||
- **index** the index of the device to be registered
|
||||
- **name** device name
|
||||
|
||||
``index`` is used to select UART device configuration, one index corresponds to a UART device configuration, such as ``UART0_INDEX`` corresponds to ``UART0_CONFIG`` configuration, ``index`` has the following optional types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum uart_index_type
|
||||
{
|
||||
#ifdef BSP_USING_UART0
|
||||
UART0_INDEX,
|
||||
#endif
|
||||
#ifdef BSP_USING_UART1
|
||||
UART1_INDEX,
|
||||
#endif
|
||||
UART_MAX_INDEX
|
||||
};
|
||||
|
||||
**device_open**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_open`` is used to open a UART device, this funtion calls ``uart_open`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_open(struct device *dev, uint16_t oflag);
|
||||
|
||||
- **dev** device handle
|
||||
- **oflag** open mode
|
||||
- **return** error code, 0 means opening is successful, others mean errors
|
||||
|
||||
``oflag`` provides the following types
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_OFLAG_STREAM_TX 0x001 /* The device is turned on in polling sending mode */
|
||||
#define DEVICE_OFLAG_STREAM_RX 0x002 /* The device is turned on in rotation receiving mode */
|
||||
#define DEVICE_OFLAG_INT_TX 0x004 /* The device is turned on in interrupt sending mode */
|
||||
#define DEVICE_OFLAG_INT_RX 0x008 /* The device is turned on in interrupt receiving mode */
|
||||
#define DEVICE_OFLAG_DMA_TX 0x010 /* The device is turned on in DMA transmission mode */
|
||||
#define DEVICE_OFLAG_DMA_RX 0x020 /* The device is turned on in DMA receiving mode */
|
||||
|
||||
**device_close**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_close`` is used to close a UART device,this funtion calls ``uart_close`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_close(struct device *dev);
|
||||
|
||||
- **dev** device handle
|
||||
- **return** error code, 0 means closing is successful, others mean error
|
||||
|
||||
**device_control**
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_control`` is used to control and modify the parameters of the UART device according to commands.This funtion calls ``uart_control`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_control(struct device *dev, int cmd, void *args);
|
||||
|
||||
- **dev** device handle
|
||||
- **cmd** device control command
|
||||
- **args** control parameters
|
||||
- **return** different control commands return different meanings.
|
||||
|
||||
In addition to standard control commands, UART device also has its own special control commands.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
#define DEVICE_CTRL_UART_GET_TX_FIFO 0x10
|
||||
#define DEVICE_CTRL_UART_GET_RX_FIFO 0x11
|
||||
|
||||
``args`` input is different depending on ``cmd``, the list is as follows:
|
||||
|
||||
.. list-table:: table1
|
||||
:widths: 15 10 30
|
||||
:header-rows: 1
|
||||
|
||||
* - cmd
|
||||
- args
|
||||
- description
|
||||
* - DEVICE_CTRL_SET_INT
|
||||
- uart_it_type
|
||||
- Enable uart device interrupt
|
||||
* - DEVICE_CTRL_CLR_INT
|
||||
- uart_it_type
|
||||
- Disable uart device interrupt
|
||||
* - DEVICE_CTRL_CONFIG
|
||||
- uart_param_cfg_t*
|
||||
- Modify the serial port configuration
|
||||
* - DEVICE_CTRL_ATTACH_TX_DMA
|
||||
- NULL
|
||||
- Link to tx dma device
|
||||
* - DEVICE_CTRL_ATTACH_RX_DMA
|
||||
- NULL
|
||||
- Link to rx dma device
|
||||
* - DEVICE_CTRL_TX_DMA_SUSPEND
|
||||
- NULL
|
||||
- Suspend uart tx dma mode
|
||||
* - DEVICE_CTRL_RX_DMA_SUSPEND
|
||||
- NULL
|
||||
- Suspend uart rx dma mode
|
||||
* - DEVICE_CTRL_TX_DMA_RESUME
|
||||
- NULL
|
||||
- Resume uart tx dma mode
|
||||
* - DEVICE_CTRL_RX_DMA_RESUME
|
||||
- NULL
|
||||
- Resume uart rx dma mode
|
||||
* - DEVICE_CTRL_UART_GET_TX_FIFO
|
||||
- uint32_t*
|
||||
- Get the number of uart tx fifo
|
||||
* - DEVICE_CTRL_UART_GET_RX_FIFO
|
||||
- uint32_t*
|
||||
- Get the number of uart rx fifo
|
||||
|
||||
**device_write**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_write`` is used to send data. The sending mode can be polling, interrupt, dma according to the open mode.This funtion calls ``uart_write`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_write(struct device *dev, uint32_t pos, const void *buffer, uint32_t size);
|
||||
|
||||
- **dev** device handle
|
||||
- **pos** useless
|
||||
- **buffer** the buffer to be written
|
||||
- **size** the length to be written
|
||||
- **return** error code, 0 means writing is successful, others mean errors
|
||||
|
||||
**device_read**
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_read`` is used to receive data. The receiving mode can be polling, interrupt, dma according to the open mode.This funtion calls ``uart_read`` actually.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_read(struct device *dev, uint32_t pos, void *buffer, uint32_t size);
|
||||
|
||||
- **dev** device handle
|
||||
- **pos** useless
|
||||
- **buffer** the buffer to be read
|
||||
- **size** the length to be read
|
||||
- **return** error code, 0 means successful reading, others mean errors
|
||||
|
||||
**device_set_callback**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``device_set_callback`` is used to register a uart interrupt callback function.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
int device_set_callback(struct device *dev, void (*callback)(struct device *dev, void *args, uint32_t size, uint32_t event));
|
||||
|
||||
- **dev** device handle
|
||||
- **callback** the interrupt callback function to be registered
|
||||
|
||||
- **dev** device handle
|
||||
- **args** receive and send buffer, the data type is uint8_t*
|
||||
- **size** transmission length
|
||||
- **event** interrupt event type
|
||||
|
||||
``event`` type definition is as follows:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
enum uart_event_type
|
||||
{
|
||||
UART_EVENT_TX_END,
|
||||
UART_EVENT_TX_FIFO,
|
||||
UART_EVENT_RX_END,
|
||||
UART_EVENT_RX_FIFO,
|
||||
UART_EVENT_RTO,
|
||||
UART_EVENT_UNKNOWN
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
==============
|
||||
Peripheral
|
||||
==============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Clock Tree <api_clock>
|
||||
GPIO Device <api_gpio>
|
||||
UART Device <api_uart>
|
||||
PWM Device <api_pwm>
|
||||
DMA Device <api_dma>
|
||||
I2C Device <api_i2c>
|
||||
#I2S Device <api_i2s>
|
||||
SPI Device <api_spi>
|
||||
ADC Device <api_adc>
|
||||
DAC Device <api_dac>
|
||||
TIMER Device <api_timer>
|
||||
#USB Device <api_usb>
|
||||
76
docs/development_guide_en/source/conf.py
Normal file
76
docs/development_guide_en/source/conf.py
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file only contains a selection of the most common options. For a full
|
||||
# list see the documentation:
|
||||
# https://www.sphinx-doc.org/en/master/usage/configuration.html
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
# import os
|
||||
# import sys
|
||||
# sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = 'BL_MCU_SDK Development Guide'
|
||||
copyright = '2021, BouffaloLab Co., Ltd'
|
||||
author = 'BouffaloLab MCU Team'
|
||||
|
||||
version = '0.3'
|
||||
|
||||
# The full version, including alpha/beta/rc tags
|
||||
release = '0.3'
|
||||
|
||||
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'sphinx.ext.autodoc',
|
||||
'sphinx.ext.imgmath',
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
source_suffix = '.rst'
|
||||
|
||||
master_doc = 'index'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = 'en'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path.
|
||||
exclude_patterns = []
|
||||
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
#html_static_path = ['_static']
|
||||
|
||||
man_pages = [
|
||||
(master_doc, 'bl702', 'BouffaloLab Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
Linux OR WSL environment development guide
|
||||
============================================
|
||||
|
||||
This document introduces how to install and configure the software development tools needed for BL702 series MCUs in Linux. The installation and configuration method under WSL system is the same as under linux, please install WSL system by yourself. The difference is that one runs on a pure linux system and the other runs on windows. If you don't want to install a virtual machine or a linux system, you can choose WSL.
|
||||
|
||||
**Windows Subsystem for Linux** (WSL) is a compatibility layer that can run native Linux binary executable files (ELF format) on Windows 10. It was developed by Microsoft and Canonical in cooperation. Its goal is to enable the pure Ubuntu image to be downloaded and decompressed to the user's local computer, and the tools in the image can run on this subsystem. Therefore, the operation mode under WSL is exactly the same as the operation mode under linux.
|
||||
|
||||
Software and hardware environment
|
||||
------------------------------------
|
||||
|
||||
- A mini USB data cable
|
||||
- A USB-TTL serial port module
|
||||
- Several Dupont lines
|
||||
|
||||
Configure RISC-V toolchain
|
||||
-----------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
:emphasize-lines: 4-6
|
||||
|
||||
$ cd ~
|
||||
$ wget -c https://dev.bouffalolab.com/media/upload/download/riscv64-elf-x86_64-20210120.tar.gz
|
||||
$ mkdir -p riscv64-elf-20210120
|
||||
$ tar -zxvf riscv64-elf-x86_64-20210120.tar.gz -C riscv64-elf-20210120
|
||||
$ sudo cp -rf ~/riscv64-elf-20210120 /usr/bin
|
||||
$ echo "export PATH=\"$PATH:/usr/bin/riscv64-elf-20210120/bin\"" >> ~/.bashrc
|
||||
$ source ~/.bashrc
|
||||
|
||||
Configure cmake & make tools
|
||||
-------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
:emphasize-lines: 5-7
|
||||
|
||||
$ sudo apt update
|
||||
$ sudo apt install make
|
||||
$ cd ~
|
||||
$ wget -c https://cmake.org/files/v3.19/cmake-3.19.3-Linux-x86_64.tar.gz
|
||||
$ tar -zxvf cmake-3.19.3-Linux-x86_64.tar.gz
|
||||
$ sudo cp -rf ~/cmake-3.19.3-Linux-x86_64 /usr/bin
|
||||
$ echo "export PATH=\"$PATH:/usr/bin/cmake-3.19.3-Linux-x86_64/bin\"" >> ~/.bashrc
|
||||
$ source ~/.bashrc
|
||||
|
||||
|
||||
Hardware connection
|
||||
----------------------
|
||||
|
||||
- For the connection of the board, please refer to :ref:`connect_hardware`
|
||||
- Please make sure that the board is set correctly before proceeding to the following steps (Serial connection is recommended under Linux)
|
||||
|
||||
Get bl_mcu_sdk
|
||||
---------------------------
|
||||
|
||||
- Open the terminal and enter the following command to get bl_mcu_sdk
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
$ cd ~
|
||||
$ git clone https://gitee.com/bouffalolab/bl_mcu_sdk.git --recursive
|
||||
|
||||
|
||||
Test Hello World project
|
||||
------------------------------
|
||||
|
||||
Open Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- After obtaining the SDK, enter ``examples/hellowd/helloworld`` in the SDK, open ``main.c``, and then edit the related code of helloworld.
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
$ cd ~/bl_mcu_sdk/examples/hellowd/helloworld
|
||||
$ vi main.c
|
||||
|
||||
- After editing, save the changes and close the file, and then compile
|
||||
|
||||
Compile Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
$ cd ~/bl_mcu_sdk
|
||||
$ make build BOARD=bl706_iot APP=helloworld
|
||||
|
||||
|
||||
Program Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Please confirm the programming method first. If you use serial programming, please press and hold the ``boot`` key on the board and don't release it. At this time, press the ``rst`` key, and then release the two keys. The board enters the boot_rom state.
|
||||
- At this time, enter the following command in the terminal to program
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
$ cd ~/bl_mcu_sdk
|
||||
$ make download INTERFACE=uart COMx=/dev/ttyUSB1
|
||||
|
||||
- If the download fails, please check:
|
||||
|
||||
- 1. Whether the serial port is used for programming, whether the development board is powered, and whether the hardware connection is correct.
|
||||
- 2. Is the programming command executed in the ``bl_mcu_sdk`` directory
|
||||
- 3. Whether to enter boot_rom mode
|
||||
- 4. Whether the serial port is occupied, and whether your available serial port is selected correctly, if your serial port is not ``ttyUSB1``, then please specify the correct serial port
|
||||
|
||||
Run Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Open a new terminal, install and run the serial port tool
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
$ sudo apt install picocom # Ignore if it is already installed
|
||||
$ picocom -b 2000000 /dev/ttyUSB1 # Pay attention to your available serial port number (if you use the serial port of Sipeed RV-debugger Plus, it will be ``ttyUSB1``)
|
||||
|
||||
- Press the ``rst`` key on the board, you can see ``hello world!`` in the serial terminal.
|
||||
|
||||
.. figure:: img/linux1.png
|
||||
:alt:
|
||||
|
||||
helloworld!
|
||||
|
||||
|
||||
Debug Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
.. _windows_cdk_quick_start:
|
||||
|
||||
Guide to using CDK (like MDK Keil) under Windows
|
||||
===================================================
|
||||
|
||||
This document introduces the use of the CDK developed by `T-HEAD Semiconductor <https://www.t-heah.cn/about>`_ under Windows to complete the related software development of BL702 series MCU.
|
||||
|
||||
Regarding T-HEAD CDK, this is an integrated development environment developed by T-HEAD. It has operations and settings that are very similar to the traditional MCU development environment, and aims to fully access cloud development resources without changing user development habits, combined with graphical debugging and analysis tools such as OSTracer and Profiling, to accelerate user product development.
|
||||
|
||||
Software and hardware environment
|
||||
--------------------------------------
|
||||
|
||||
- T-HEAD CDK software
|
||||
- One USB Type-A data cable, one Type-C data cable
|
||||
- A CK-Link emulator or a Sipeed RV-Debugger Plus debugger
|
||||
- A USB-TTL serial port module
|
||||
- Several Dupont lines
|
||||
|
||||
|
||||
Download CDK
|
||||
-----------------------------
|
||||
|
||||
- `CDK <https://occ.t-head.cn/development/series/download?id=3864775351511420928&type=kind&softPlatformType=4#sticky>`_ software can be obtained from the official website of T-HEAD OCC
|
||||
|
||||
- After the download is complete, unzip, double-click ``setup.exe``, follow the prompts, and complete the software installation
|
||||
|
||||
Download bl_mcu_sdk
|
||||
----------------------------
|
||||
|
||||
- Download bl_mcu_sdk from the open source community.
|
||||
|
||||
- You can use ``git clone`` or directly ``download`` to download the SDK
|
||||
- Before using ``git clone``, please make sure that ``git`` has been installed correctly, open a terminal that supports ``git`` and enter the following command to get the latest SDK
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
:emphasize-lines: 1
|
||||
|
||||
$ git clone https://gitee.com/bouffalolab/bl_mcu_sdk.git --recursive
|
||||
|
||||
|
||||
Hardware connection
|
||||
-----------------------
|
||||
|
||||
- For specific connection methods, please refer to :ref:`connect_hardware`
|
||||
- Please make sure that the board is set up correctly before proceeding to the following steps
|
||||
|
||||
Test the Hello World project
|
||||
------------------------------
|
||||
|
||||
**When using Sipeed RV-Debugger Plus to debug a project, please follow the steps below:**
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Use Sipeed RV-Debugger <cdk_rv_debugger_plus>
|
||||
|
||||
**When using CK-Link to debug the project, please follow the steps below:**
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
Use CK-Link <cdk_ck_link>
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,170 @@
|
|||
Eclipse Development Guide under Windows
|
||||
==========================================
|
||||
|
||||
This document introduces the use of eclipse under Windows to build a software development environment for BL702 series MCU.
|
||||
|
||||
Software and hardware environment
|
||||
------------------------------------
|
||||
|
||||
- Eclipse free installation package
|
||||
- Serial port assistant software
|
||||
- A USB Type-A data cable
|
||||
- A j-link emulator
|
||||
- A USB-TTL serial port module
|
||||
- Several Dupont lines
|
||||
|
||||
|
||||
Download Eclipse
|
||||
-----------------------------
|
||||
|
||||
- Download the installation package with the RISC-V toolchain from the Bouffalo Lab developer community `Eclipse https://dev.bouffalolab.com/download <https://dev.bouffalolab.com/media/upload/download/BouffaloLab_eclipse_x86_64_win.zip>`_ .
|
||||
|
||||
Download bl_mcu_sdk
|
||||
-----------------------------
|
||||
|
||||
- Download from the open source community `bl_mcu_sdk <https://gitee.com/bouffalolab/bl_mcu_sdk.git>`_.
|
||||
|
||||
- You can use ``git clone`` or directly ``download`` to download the SDK
|
||||
- Before using ``git clone``, please make sure that ``git`` has been installed correctly. Open a terminal that supports ``git`` and enter the following command to get the latest SDK.
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
:emphasize-lines: 1
|
||||
|
||||
$ git clone https://gitee.com/bouffalolab/bl_mcu_sdk.git --recursive
|
||||
|
||||
|
||||
Configure eclipse
|
||||
----------------------------
|
||||
|
||||
- Copy the eclipse compressed package to the working directory, unzip the eclipse compressed package
|
||||
- Enter the eclipse directory, double-click ``eclipse.exe`` to start eclipse
|
||||
- Select your ``Workspace`` directory, click ``Launch`` to enter the workspace
|
||||
|
||||
.. figure:: img/pic1.png
|
||||
:alt:
|
||||
|
||||
- Click ``Window->preferences`` in the menu bar to open the environment configuration related page, ready to import the related configuration environment
|
||||
|
||||
|
||||
.. figure:: img/pic2.png
|
||||
:alt:
|
||||
|
||||
- Click the icon at "1" in the figure below to open the import configuration interface, follow the steps shown in the figure, and select the ``bflb_mcu_preferences.epf`` configuration file in the ``eclipse.exe`` directory.
|
||||
.. figure:: img/pic3.png
|
||||
:alt:
|
||||
|
||||
- After selecting the corresponding file, click ``Finish``, select and click ``cancel`` in the dialog box without restarting.
|
||||
|
||||
.. figure:: img/pic4.png
|
||||
:alt:
|
||||
|
||||
Import bl_mcu_sdk
|
||||
--------------------------
|
||||
|
||||
- Click on the menu bar ``File->Import`` to open the configuration interface of the imported project
|
||||
|
||||
.. figure:: img/pic5.png
|
||||
:alt:
|
||||
|
||||
- In the opened ``Import`` window, select ``General->Existing Projects into Workspace``, and then click ``Next``
|
||||
|
||||
.. figure:: img/pic6.png
|
||||
:alt:
|
||||
|
||||
- After loading the project path of bl_mcu_sdk, click ``Finsh`` to complete the import
|
||||
|
||||
.. figure:: img/pic7.png
|
||||
:alt:
|
||||
|
||||
- After the import is complete, close the ``Welcome`` window to see the imported project
|
||||
|
||||
.. figure:: img/pic8.png
|
||||
:alt:
|
||||
|
||||
.. figure:: img/pic9.png
|
||||
:alt:
|
||||
|
||||
- Expand ``Build Target``, you can see the three function buttons ``bl_clean``, ``bl_make``, and ``download``.
|
||||
|
||||
- Double-click the ``bl_clean`` button, it will clear the compilation cache in the ``build`` and ``out`` directories
|
||||
- Double-click the ``bl_make`` button, the set case will be compiled normally, if the default configuration is not modified, the ``helloworld`` project will be compiled
|
||||
- Double-click the ``download`` button, the code will be downloaded to the chip, if it is not compiled successfully, the default or last ``.bin`` file will be downloaded
|
||||
|
||||
Hardware connection
|
||||
----------------------
|
||||
|
||||
- For specific board connection, please refer to :ref:`connect_hardware`; (The eclipse environment recommends using ``j-link`` for programming and debugging)
|
||||
- Please make sure that the development board is set up correctly before proceeding to the following steps
|
||||
|
||||
Test the Hello World project
|
||||
-------------------------------
|
||||
|
||||
Open Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Open ``examples/hellowd/helloworld/main.c``, you can edit and modify the code of the ``helloworld`` test demo. If you modify it, please save it and execute the compilation
|
||||
|
||||
Compile Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Double click ``bl_make`` to compile the helloworld project
|
||||
|
||||
- After successful compilation, you can see the log information as shown in the figure below in the ``Console`` window
|
||||
|
||||
.. figure:: img/pic10.png
|
||||
|
||||
|
||||
Program Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Double-click ``download`` to program the helloworld project ``bin`` file to the chip
|
||||
|
||||
- After the download is successful, you can see the log information as shown in the figure below in the ``Console`` window
|
||||
|
||||
.. figure:: img/pic11.png
|
||||
|
||||
|
||||
Run Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Connect the ``TXD0``, ``RXD0`` and ``GND`` pins of the board to the USB-TTL serial port module with a DuPont cable, insert the serial port module into the PC, and use any serial port assistant software to open the serial port
|
||||
- After the programming is successful, press the ``rst`` button on the board. If the download is correct, you can see the log information as shown in the figure below in the serial port assistant software.
|
||||
|
||||
.. figure:: img/eclipse_run.png
|
||||
|
||||
|
||||
Debug Hello World
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Click the ``Debug`` button in the eclipse toolbar to enter the debug configuration window
|
||||
- Select ``GDB SEGGER J-Link Debugging->Jlink_bl_mcu_sdk``, select the ``.elf`` file that needs to be debugged in ``C/C++ Application:``
|
||||
- Click ``Apply`` first, then click ``Debug`` to start ``Debug``
|
||||
|
||||
.. figure:: img/pic14.png
|
||||
:alt:
|
||||
|
||||
- After entering the Debug interface, you can see that the program stops at ``main``, click the ``Step Over`` button in the upper toolbar to perform single-step debugging of the code project.
|
||||
|
||||
.. figure:: img/pic15.png
|
||||
:alt:
|
||||
|
||||
Eclipse Debugging
|
||||
|
||||
|
||||
Compile and program different target projects
|
||||
-------------------------------------------------
|
||||
|
||||
- When you right-click the ``bl_make`` button and click ``Edit``, the configuration interface for replacing the target project will pop up, as shown in the figure below
|
||||
|
||||
.. figure:: img/pic12.png
|
||||
:alt:
|
||||
|
||||
|
||||
- Where ``APP=xxx`` can be changed to the name of the target project that needs to be compiled and programmed. For example, if you want to compile and program the ``gpio/gpio_blink`` project, modify it to ``APP=gpio_blink``.
|
||||
- ``make BOARD=bl706_iot`` in ``Build command`` will specify different Board types to adapt to different types of boards.
|
||||
|
||||
- The ``Board`` type determines the corresponding ``borad`` header file when compiling. The default selection is ``make build BOARD=bl706_iot``
|
||||
|
||||
|
||||
|
||||
90
docs/development_guide_en/source/get_started/bl_dev_cube.rst
Normal file
90
docs/development_guide_en/source/get_started/bl_dev_cube.rst
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
.. _bl_dev_cube:
|
||||
|
||||
BLDevCube start guide
|
||||
===============================
|
||||
|
||||
This document mainly introduces the use of Bouffalo Lab Dev Cube for code programming. For more details, please refer to `BLDevCube user manual <https://dev.bouffalolab.com/media/upload/doc/DevCube%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8Cv1.2.pdf>`_
|
||||
|
||||
Download Bouffalo Lab Dev Cube
|
||||
------------------------------------
|
||||
|
||||
- Download the version suitable for your operating system from the developer community, download address:`https://dev.bouffalolab.com/download <https://dev.bouffalolab.com/download>`_
|
||||
|
||||
- For users who do not have a registered account, click on the guest portal
|
||||
|
||||
- After the download is complete, you can use it after decompression
|
||||
|
||||
|
||||
Configure tool download method
|
||||
----------------------------------
|
||||
|
||||
- Double-click ``BLDevCube.exe``, in the ``Chip Type`` drop-down box, select the corresponding chip model, click ``Finish`` to enter the ``Dev Cube`` interface
|
||||
- Enter the interface, select ``MCU`` under ``View`` in the menu bar to enter the MCU program download interface
|
||||
|
||||
.. figure:: img/dev_cube_view_mcu.png
|
||||
:alt:
|
||||
|
||||
select mcu
|
||||
|
||||
- Select the corresponding download method in the ``Interface`` column under ``Image``, and choose according to your actual physical connection
|
||||
- ``Image file`` configure the absolute path of the downloaded image, click ``Browse`` to select the **Bin** file
|
||||
- When you click ``click here to show advanced options``, the advanced mirroring configuration will be expanded, usually keep the default configuration; it should be noted that ``Flash Clock`` will affect the clock frequency of Flash and PSRAM at the same time , If you need to use PSRAM, you can increase the clock frequency to get better performance
|
||||
|
||||
Download with UART
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- ``COM Port`` is used for UART download, select the COM number connected to the chip, and click ``Refresh`` to refresh the COM number
|
||||
- When ``Uart Speed`` is used for UART download, configure the appropriate baud rate, the default is 2M
|
||||
|
||||
- Please make sure the hardware configuration is correct before downloading:
|
||||
|
||||
- Use ``Type-C USB`` or ``Mini USB`` to connect to the corresponding USB ``Type-C`` port or ``Mini`` port on the board.
|
||||
- Press the ``Boot`` key on the board, don't release it
|
||||
- Press the ``RST`` key on the board, now you have entered ``Boot ROM`` model, you can release the two keys
|
||||
- At this time, you can see the corresponding serial port ``COM`` number from the ``Bouffalo Lab Dev Cube``, if it does not appear, please click the ``Refresh`` button to refresh
|
||||
|
||||
- After completing the above configuration correctly, click the ``Create&Program`` button to download
|
||||
|
||||
- After the download is successful, you will see the status bar turn green and display ``Success``
|
||||
|
||||
.. figure:: img/dev_cube_download.png
|
||||
:alt:
|
||||
|
||||
download success!
|
||||
|
||||
Download with Openocd
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Download using openocd is basically the same as using serial port download option configuration, just switch ``Interface`` to ``Openocd``
|
||||
- The hardware connection needs to be changed to a debugger connection that supports Openocd (this tutorial takes Sipeed RV Debugger as an example):
|
||||
|
||||
- 1. Connect the RV debugger to the USB port of the computer, open the device manager, you will find that the debugger is recognized as two serial ports (note: not the serial port on the board)
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_1.png
|
||||
|
||||
- 2. Download the ``zadig-2.4`` replacement driver from sipeed. Download link: `http://dl.sipeed.com/MAIX/tools/sipeed-rv-debugger/zadig-2.4.exe <http://dl.sipeed.com/MAIX/tools/sipeed-rv-debugger/ zadig-2.4.exe>`_
|
||||
- 3. After downloading, double-click to open ``zadig-2.4.exe``, and check List All Devices in Options.
|
||||
- 4. Find JTAG Debugger (Interface 0), then select the replacement driver as WinUSB and click Replace Driver to replace
|
||||
- 5. Open the device manager again and see that one of the serial ports has been replaced with a universal serial bus device, indicating that the installation is successful
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_2.png
|
||||
|
||||
- 6. Connect the JTAG pins of the debugger with the JTAG pins of the board
|
||||
|
||||
- After completing the above configuration correctly, click the ``Create&Program`` button to download
|
||||
- After the download is successful, you will see the status bar turn green and display ``Success``
|
||||
|
||||
Download with Jlink
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- The tool configuration for downloading using Jlink and Openocd is basically the same, just switch ``Interface`` to ``Jlink``
|
||||
- The hardware connection needs to be changed to use Jlink connection (this tutorial takes Jlink V11 as an example, it is recommended to use Jlink V10 or later):
|
||||
|
||||
- 1. Download the appropriate Jlink driver from Segger official website and install it
|
||||
- 2. Connect the Jlink debugger to the USB port of the computer
|
||||
- 3. Connect the JTAG pins of the JLink debugger with the JTAG pins of the board
|
||||
|
||||
- After completing the above configuration correctly, click the ``Create&Program`` button to download
|
||||
|
||||
- After the download is successful, you will see the status bar turn green and display ``Success``
|
||||
|
||||
189
docs/development_guide_en/source/get_started/board.rst
Normal file
189
docs/development_guide_en/source/get_started/board.rst
Normal file
|
|
@ -0,0 +1,189 @@
|
|||
Board Configuration System User Guide
|
||||
=========================================
|
||||
|
||||
In order to implement the idea of **everything is a file**, we propose a Board configuration system for embedded applications with different hardware configuration requirements. The **Board configuration system** is mainly used for initializing the three basic elements of clock, GPIO, and peripheral default configuration in embedded applications.
|
||||
|
||||
**Board Configuration System** contains three configuration files, and a ``bl_config_wizard`` graphical configuration software
|
||||
|
||||
- **clock_config.h** Clock configuration Include file
|
||||
- **peripheral_config.h** Peripheral configuration Include file
|
||||
- **pinmux_config.h** Pin Function Configuration Include file
|
||||
- **bl_config_wizard** The graphical interface configures the above three types of files
|
||||
|
||||
The user only needs to modify three configuration files and the system will be initialized automatically, thus eliminating the need to call a series of complex and lengthy initialization functions in the user program. Boufflao Lab provides ``bl_config_wizard`` configuration software for users to quickly and easily generate configuration files for their projects.
|
||||
|
||||
`bl_config_wizard`_ supports PC-side online configuration, but currently does not support mobile terminal online configuration.
|
||||
|
||||
.. _bl_config_wizard: https://dev.bouffalolab.com/media/config/index.html
|
||||
|
||||
.. figure:: img/config_wizard.png
|
||||
:alt:
|
||||
|
||||
bl_config_wizard Preview
|
||||
|
||||
|
||||
The features of each file in the Board configuration system
|
||||
----------------------------------------------------------------
|
||||
|
||||
The board system is mainly used for different boards, different boards create different board files and put them in ``bsp/board`` directory, and a board file, in the case of **pins not conflicting**, can be shared to different demos, no need to create multiple projects and reduce the project file size.
|
||||
|
||||
.. error:: If there is a pin conflict and you have to use the same Board file, please modify the pins yourself
|
||||
|
||||
**board.c**
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``board.c`` Main initialization of clock and pins
|
||||
|
||||
**blxxx_config.h**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``blxxx_config.h`` Mainly contains some header files for the HAL layer driver.
|
||||
|
||||
.. hint:: The above two files do not need to be changed by the user, and the same MCU can be copied and pasted directly into your own board directory for use
|
||||
|
||||
**clock_config.h**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``clock_config.h`` Mainly configures the clock sources for the system and peripherals as well as the frequency division system.
|
||||
|
||||
**peripheral_config.h**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``peripheral_config.h`` It mainly contains the enablement of peripherals and the configuration of parameters.
|
||||
|
||||
.. warning:: Macros starting with ``#define BSP_USING_XXX`` are used to enable the configuration of the peripheral, if the macro is not enabled, all functions of the peripheral cannot be used
|
||||
|
||||
.. warning:: Macro starting with ``XXX_CONFIG``, used to initialize the configuration of the peripheral, which is later used by calling ``device_open``
|
||||
|
||||
|
||||
**pinmux_config.h**
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``pinmux_config.h`` Mainly configures the GPIO pin function of the peripheral.
|
||||
|
||||
.. warning:: In mcu sdk, all demos share this file, so some demos are not usable and require frequent changes to the pin function configuration in this file. If the user has already set the pin assignments, there is no need to modify them frequently.
|
||||
|
||||
Use of the Board configuration tool **bl_config_wizard**
|
||||
---------------------------------------------------------------
|
||||
|
||||
- The ``bl_config_wizard`` can be accessed by clicking on this link `https://dev.bouffalolab.com/media/config/index.html <https://dev.bouffalolab.com/media/config/index.html>`_ wizard in the online version. Chrome, Firefox, Microsoft Edge browsers are recommended.
|
||||
|
||||
Generate a new **pinmux_config.h** file
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
1. Select ``Pin & Peripheral Configuration`` in the window bar.
|
||||
#. Select MCU model, currently supports ``BL706 pin configuration``, ``BL704 pin configuration``, ``BL702 pin configuration``.
|
||||
#. Select the function of the pin, take ``BL706 pin configuration`` as an example, click on the drop-down box of **PAD_GPIO_XX** and select the desired function, as shown in the figure.
|
||||
|
||||
.. figure:: img/config_wizard_example1.png
|
||||
:alt:
|
||||
|
||||
Select pin function
|
||||
|
||||
|
||||
4. After configuring all the pin functions, click ``Export Configuration File`` and then you can select the path and modify the file name in the pop-up box, as shown in the figure.
|
||||
|
||||
.. figure:: img/config_wizard_example2.png
|
||||
:alt:
|
||||
|
||||
Exporting configuration files
|
||||
|
||||
Modify the original **pinmux_config.h** file
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Often in use, instead of generating a new **pinmux_config.h** file, we make changes to the original **pinmux_config.h** file, and ``bl_config_wizard`` supports such a need.
|
||||
|
||||
1. Select ``Pin & Peripheral Configuration`` in the window bar.
|
||||
#. Select MCU model, currently supports ``BL706 pin configuration``, ``BL704 pin configuration``, ``BL702 pin configuration``.
|
||||
#. Click on ``import configuration file`` and select the **pinmux_config.h** file in the pop-up box.
|
||||
#. Select the pin to be modified and click on its drop-down box to change the pin function
|
||||
#. When you are done, click ``Export Profile`` and then you can select the path and modify the file name in the pop-up box.
|
||||
|
||||
|
||||
Modify the **pinmux_config.h** file in the CDK tool
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- **pinmux_config.h** Also supports the use of graphical configuration wizards in the CDK for adjusting the corresponding pin functions
|
||||
- Drag the **pinmux_config.h** file directly into the CDK text editor interface, and you will see the ``Configuration Wizard`` tab at the bottom of the text editor
|
||||
|
||||
.. figure:: img/configuration_wizard_1.png
|
||||
:alt:
|
||||
|
||||
Configuration Wizard
|
||||
|
||||
- Click on the ``Configuration Wizard`` tab to open the graphical configuration wizard interface
|
||||
- The functions supported by the pin can be selected by selecting the drop-down box
|
||||
|
||||
.. figure:: img/configuration_wizard_2.png
|
||||
:alt:
|
||||
|
||||
Graphical configuration wizard to set pin functions
|
||||
|
||||
- Please refer to the Graphical Configuration Wizard section of CDK Help for more information on the specific functions and code rules of the Graphical Configuration Wizard.
|
||||
|
||||
|
||||
|
||||
Differences with STM32CUBEMX Configuration Tool
|
||||
--------------------------------------------------
|
||||
|
||||
STM32CUBEMX is also a tool to configure the clock, peripherals and GPIO initialization, eventually generating a complete project with initialization at the very beginning of ``main.c``, and the GPIO and peripheral initialization base will be called in ``stm32xxx_hal_msp.c``.
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
/* MCU Configuration--------------------------------------------------------*/
|
||||
|
||||
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
|
||||
HAL_Init();
|
||||
|
||||
/* USER CODE BEGIN Init */
|
||||
|
||||
/* USER CODE END Init */
|
||||
|
||||
/* Configure the system clock */
|
||||
SystemClock_Config();
|
||||
|
||||
/* USER CODE BEGIN SysInit */
|
||||
|
||||
/* USER CODE END SysInit */
|
||||
|
||||
/* Initialize all configured peripherals */
|
||||
MX_GPIO_Init();
|
||||
MX_USART1_UART_Init();
|
||||
MX_QUADSPI_Init();
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
void HAL_UART_MspInit(UART_HandleTypeDef* huart)
|
||||
{
|
||||
GPIO_InitTypeDef GPIO_InitStruct = {0};
|
||||
if(huart->Instance==UART5)
|
||||
{
|
||||
/* USER CODE BEGIN UART5_MspInit 0 */
|
||||
|
||||
/* USER CODE END UART5_MspInit 0 */
|
||||
/* Peripheral clock enable */
|
||||
__HAL_RCC_UART5_CLK_ENABLE();
|
||||
|
||||
__HAL_RCC_GPIOB_CLK_ENABLE();
|
||||
/**UART5 GPIO Configuration
|
||||
PB12 ------> UART5_RX
|
||||
PB13 ------> UART5_TX
|
||||
*/
|
||||
GPIO_InitStruct.Pin = GPIO_PIN_12|GPIO_PIN_13;
|
||||
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
|
||||
GPIO_InitStruct.Pull = GPIO_NOPULL;
|
||||
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
|
||||
GPIO_InitStruct.Alternate = GPIO_AF14_UART5;
|
||||
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
|
||||
|
||||
/* UART5 interrupt Init */
|
||||
HAL_NVIC_SetPriority(UART5_IRQn, 0, 0);
|
||||
HAL_NVIC_EnableIRQ(UART5_IRQn);
|
||||
/* USER CODE BEGIN UART5_MspInit 1 */
|
||||
|
||||
/* USER CODE END UART5_MspInit 1 */
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
.. hint:: The projects generated by stm32 all work for one project and cannot be compiled for more than one project at the same time. If you use more than one project, you have to generate more than one of these two files. When using multiple projects, it will indirectly increase the file size and add duplicate files.
|
||||
112
docs/development_guide_en/source/get_started/cdk_ck_link.rst
Normal file
112
docs/development_guide_en/source/get_started/cdk_ck_link.rst
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
Use CDK + CK-Link to compile and debug
|
||||
=========================================
|
||||
|
||||
|
||||
Open Hello World
|
||||
------------------------------
|
||||
|
||||
- After obtaining the SDK, enter the ``examples/hellowd/helloworld/cdk`` directory in the SDK, double-click ``helloworld.cdkproj``, and you can open the ``Helloworld`` project
|
||||
|
||||
Compile Hello World
|
||||
------------------------------
|
||||
|
||||
.. figure:: img/cdk1.png
|
||||
:alt:
|
||||
|
||||
helloworld.cdkproj
|
||||
|
||||
- In the drop-down menu, you can select the ``CK_Link_Debug`` or ``OpenOCD_Debug`` project, this tutorial is based on the ``CK_Link_Debug`` project
|
||||
|
||||
- In the CDK toolbar, click the compile icon to compile the project
|
||||
|
||||
- Click the icon ``Build Project`` at ``1`` to compile the currently selected project
|
||||
- Click the icon ``Clean Project`` at ``2`` to clear the result of the last compilation
|
||||
- Click the ``3`` icon ``Flash Download`` to download the compiled code to the chip
|
||||
- Click the icon ``Start/Stop Debug`` at ``4`` to perform debugging related operations (when using ``CK-Link``, you can load the code to flash first)
|
||||
- Click the ``5`` icon ``Start/Stop Debug whitout Download`` to debug directly without loading the current bin file
|
||||
- You can also right-click the project name in ``Project``, and compile the project through the options in the right-click menu
|
||||
|
||||
Program Hello World
|
||||
----------------------------
|
||||
|
||||
- Since our flash algorithm is not currently included in the CDK software, we need to put the flash algorithm in the CDK installation directory. The specific operations are as follows:
|
||||
|
||||
- Enter the ``tools\cdk_flashloader`` directory under the SDK directory
|
||||
- Copy the ``bl70x_flasher.elf`` file in the directory to the ``C-Sky\CDK\CSKY\Flash`` directory of the CDK tool
|
||||
|
||||
.. figure:: img/cdk7.png
|
||||
:alt:
|
||||
|
||||
CDK Flash Loader
|
||||
|
||||
|
||||
|
||||
.. figure:: img/cdk8.png
|
||||
:alt:
|
||||
|
||||
CDK Project Setting
|
||||
|
||||
- Click the project setting button in the ``Project View`` to open the ``Project Setting`` window, or open it through the ``Project`` menu bar
|
||||
|
||||
- In the opened ``Project Setting`` window, select the ``Flash`` tab to configure the required Flash algorithm
|
||||
|
||||
.. figure:: img/cdk9.png
|
||||
:alt:
|
||||
|
||||
CDK Project Flash setting
|
||||
|
||||
- In the ``Flash`` tab, click the ``Add`` button, select the ``bl70x_flash`` algorithm in the opened list, and click ``Add`` to add it to the project. Others in ``Flash`` configuration, as shown in the figure:
|
||||
|
||||
- After clicking OK, if the configuration is correct, click ``Flash Download`` to download the compiled code to the chip
|
||||
|
||||
|
||||
.. figure:: img/cdk5.png
|
||||
:alt:
|
||||
|
||||
CDK Flashdownload Success
|
||||
|
||||
- If the download fails, please check:
|
||||
|
||||
- 1. Whether the code is compiled correctly and generate files such as ``.elf``, ``.bin``, etc.
|
||||
- 2. Is the Flash algorithm correctly set?
|
||||
- 3. Whether the CK-Link and the board are properly connected
|
||||
- 4. Whether the development board is powered normally and whether the power indicator is on
|
||||
|
||||
Run Hello World
|
||||
----------------------------
|
||||
|
||||
- From the menu bar of the CDK ``View->Serial Pane``, open the serial port panel, right-click in the opened ``Serial Pane``, set the serial port, select your corresponding serial port number and baud rate
|
||||
|
||||
.. figure:: img/cdk4.png
|
||||
.. figure:: img/cdk3.png
|
||||
:alt:
|
||||
|
||||
CDK Serial Pane setting
|
||||
|
||||
- Press the ``RST`` key on the board, you can see the result of the code in the serial port
|
||||
|
||||
.. figure:: img/cdk6.png
|
||||
:alt:
|
||||
|
||||
HelloWorld！
|
||||
|
||||
|
||||
Debug Hello World
|
||||
----------------------------
|
||||
|
||||
- Click the ``Start/Stop Debugger`` button at the top of the toolbar to enter the debug interface, as shown in the figure below
|
||||
|
||||
.. figure:: img/cdk10.png
|
||||
:alt:
|
||||
|
||||
Debug HelloWorld！
|
||||
|
||||
- In the debug interface, the ``Register`` window can view the ``CPU`` internal register data; the ``Peripherals`` peripheral panel, you can view the corresponding peripheral register data, the top menu bar ``Peripherals-> System Viewer`` can select peripherals; click the relevant debugging button in the upper toolbar to perform operations such as breakpoint setting, single-step debugging, single-step instruction, and full-speed operation. Of course, these operations have corresponding shortcut keys and shortcut setting methods. For details, please refer to ``CDK Help``.
|
||||
|
||||
- We click the single step button to run the code, and we can see that the cursor moves to the next sentence of code, and we can see our output ``Hello World!`` displayed in the serial port panel.
|
||||
|
||||
.. figure:: img/cdk11.png
|
||||
:alt:
|
||||
|
||||
Debug HelloWorld！
|
||||
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
New Project Guide based on CDK
|
||||
==================================
|
||||
|
||||
This document will briefly explain how to create a new CDK project based on this SDK, please make sure that the CDK IDE is properly installed before following this tutorial.
|
||||
|
||||
Examples directory structure
|
||||
----------------------------------
|
||||
|
||||
There are two levels of subdirectories under ``bl_mcu_sdk/examples``, the first level is the folders of different peripherals. The second level is a specific test case of the peripheral, The second level directory usually also contains a directory named ``cdk`` and the source code associated with the case.
|
||||
The ``cdk`` directory usually contains a ``xxx.cdkproj`` file, which is a CDK project file. If the **CDK** IDE is properly installed, double-click the project to open it. The newly created project should be at the same level as the case level in the current ``examples`` directory.
|
||||
|
||||
|
||||
.. note:: The source file must contain the c program entry, usually the ``main`` function, the source file may not be called ``main.c``
|
||||
|
||||
- Create a new ``my_case`` folder under ``examples`` to store your case
|
||||
- Create a new folder that needs to be tested in the ``my_case`` directory, such as ``gpio_case``
|
||||
- Then add the ``main.c`` file and ``cdk`` directory in the ``gpio_case`` directory
|
||||
|
||||
|
||||
The directory structure is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
bl_mcu_sdk
|
||||
├── examples
|
||||
├── my_case
|
||||
├── gpio_case
|
||||
│ ├── cdk
|
||||
│ │ ├──gpio_case.cdkproj
|
||||
│ ├── CMakeLists.txt
|
||||
│ └── main.c
|
||||
└── xxxx_case
|
||||
|
||||
|
||||
Add cdk project related files
|
||||
--------------------------------
|
||||
|
||||
Since the current version of CDK does not support new pure ``Empty`` projects, please follow the steps below
|
||||
|
||||
- Copy ``helloworld.cdkproj`` from the cdk directory in the ``helloworld`` case to your own cdk directory
|
||||
- Change the file name to your case name, for example: ``gpio_case.cdkproj``
|
||||
- Open the ``gpio_case.cdkproj`` file with a text editor and change ``Project Name`` to your project name, for example: ``gpio_case``
|
||||
|
||||
|
||||
.. figure:: img/cdk_start_1.png
|
||||
:alt:
|
||||
|
||||
|
||||
- After editing, save the file and double-click ``gpio_case.cdkproj`` to open the project
|
||||
- Once you open the project, you can right-click on the appropriate folder and add the source code files you need
|
||||
|
||||
.. figure:: img/cdk_start_2.png
|
||||
:alt:
|
||||
|
||||
|
||||
- Right-click the project, open ``Project Settings``, select the Compiler tab, and add the corresponding header files needed for the new file in ``Include paths``.
|
||||
- Relative paths are recommended for header file paths
|
||||
- Click ``OK`` to save the edit
|
||||
|
||||
|
||||
.. figure:: img/cdk_start_3.png
|
||||
:alt:
|
||||
|
||||
|
||||
- In case of floating point printouts, you need to add the flag option ``-u _printf_float`` in the Linker tag, in ``Other flags``, otherwise you can't printf floating point properly
|
||||
|
||||
.. figure:: img/cdk_start_4.png
|
||||
:alt:
|
||||
|
||||
|
||||
- In the case of using different development boards, pay attention to choose different board file references, usually, the default configuration is **bl706_iot**
|
||||
|
||||
.. figure:: img/cdk_start_5.png
|
||||
:alt:
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
Use CDK + Sipeed RV-Debugger Plus to compile and debug
|
||||
==========================================================
|
||||
|
||||
Open Hello World
|
||||
------------------------------
|
||||
|
||||
- After obtaining the SDK, enter the ``examples/hellowd/helloworld/cdk`` directory and double-click ``helloworld.cdkproj`` to open the ``Helloworld`` project
|
||||
|
||||
Compile Hello World
|
||||
------------------------------
|
||||
|
||||
.. figure:: img/cdk1.png
|
||||
:alt:
|
||||
|
||||
helloworld.cdkproj
|
||||
|
||||
- Select the ``OpenOCD_Debug`` project in the drop-down menu. Since Sipeed RV-Debugger Plus uses OpenOCD for debugging, this tutorial is based on the ``OpenOCD_Debug`` project;
|
||||
- If Sipeed RV-Debugger Plus does not install the driver correctly, please refer to :ref:`sipeed_rv_debugger_plus`, set up the driver, and then proceed to the following steps
|
||||
|
||||
- In the CDK toolbar, click the compile icon to compile the project
|
||||
|
||||
- Click ``1`` ``Build Project`` to compile the currently selected project
|
||||
- Click ``2`` ``Clean Project`` to clear the results of the last compilation
|
||||
- Click ``3`` ``Flash Download`` to download the compiled code to the chip (**Flash download function cannot be used with OpenOCD Debug**)
|
||||
- Click ``5`` ``Start/Stop Debug whitout Download`` to debug directly without loading the current bin file
|
||||
- You can also right-click the project name in ``Project``, and compile the project through the options in the right-click menu
|
||||
|
||||
|
||||
Program Hello World
|
||||
----------------------------
|
||||
|
||||
- When using the OpenOCD mode debugging method in the CDK, it is not currently supported to directly use the CDK related ``flash`` tool to download the code, so please use the BL Dev Cube tool to program, please refer to :ref:`bl_dev_cube`
|
||||
- Use CDK to debug after the code is programmed
|
||||
|
||||
Run Hello World
|
||||
----------------------------
|
||||
|
||||
- From the menu bar of the CDK ``View->Serial Pane``, open the serial port panel, right-click in the opened ``Serial Pane``, set the serial port, select your corresponding serial port number and baud rate
|
||||
|
||||
.. figure:: img/cdk4.png
|
||||
.. figure:: img/cdk3.png
|
||||
:alt:
|
||||
|
||||
CDK Serial Pane setting
|
||||
|
||||
- Press the ``RST`` key on the board, you can see the result of the code in the serial port
|
||||
|
||||
.. figure:: img/cdk6.png
|
||||
:alt:
|
||||
|
||||
HelloWorld！
|
||||
|
||||
|
||||
Debug Hello World
|
||||
----------------------------
|
||||
|
||||
- Click the ``Start/Stop Debugger`` button at the top of the toolbar to enter the debug interface, as shown in the figure below
|
||||
|
||||
.. figure:: img/cdk10.png
|
||||
:alt:
|
||||
|
||||
Debug HelloWorld！
|
||||
|
||||
- In the debug interface, the ``Register`` window can view the ``CPU`` internal register data; the ``Peripherals`` peripheral panel, you can view the corresponding peripheral register data, the top menu bar ``Peripherals-> System Viewer`` can select peripherals; click the relevant debugging button in the upper toolbar to perform operations such as breakpoint setting, single-step debugging, single-step instruction, and full-speed operation. Of course, these operations have corresponding shortcut keys and shortcut setting methods. For details, please refer to ``CDK Help``.
|
||||
|
||||
- We click the single step button to run the code, and we can see that the cursor moves to the next sentence of code, and we can see our output ``Hello World!`` displayed in the serial port panel.
|
||||
|
|
@ -0,0 +1,207 @@
|
|||
New Project Guide based on cmake framework
|
||||
=============================================
|
||||
|
||||
This document will introduce how to create a new project based on this SDK.
|
||||
|
||||
Examples directory structure
|
||||
------------------------------------
|
||||
|
||||
There are two levels of subdirectories under ``bl_mcu_sdk/examples``, the first level is the folders of different peripherals. The second level is a specific test case of the peripheral, and the directory usually contains a ``CMakeList.txt`` and the source code related to the case.
|
||||
|
||||
|
||||
Add a single source file project
|
||||
-----------------------------------
|
||||
|
||||
.. note::
|
||||
The source file must contain the c program entry, usually the ``main`` function, the source file may not be called ``main.c``
|
||||
|
||||
- Create a new ``my_case`` folder under ``examples`` to store your case
|
||||
- Create a new folder that needs to be tested in the ``my_case`` directory, such as ``gpio_case``
|
||||
- Then add the ``main.c`` and ``CMakeLists.txt`` files in the ``gpio_case`` directory
|
||||
|
||||
|
||||
The directory structure is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
bl_mcu_sdk
|
||||
├── examples
|
||||
├── my_case
|
||||
├── gpio_case
|
||||
│ ├──CMakeLists.txt
|
||||
│ └──main.c
|
||||
└── xxxx_case
|
||||
|
||||
`CMakeLists.txt`:
|
||||
|
||||
.. code-block:: cmake
|
||||
:linenos:
|
||||
:emphasize-lines: 1-2
|
||||
|
||||
set(mains main.c)
|
||||
generate_bin()
|
||||
|
||||
- After writing the code in main.c, compile it in the bl_mcu_sdk directory. The compilation command is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
make BOARD=bl706_iot APP=gpio_case
|
||||
|
||||
|
||||
Add multiple source file projects
|
||||
-------------------------------------
|
||||
|
||||
.. note::
|
||||
One of the source files must contain the c program entry, usually the ``main`` function, the source file does not need to be called ``main.c``. This source file depends on other source files.
|
||||
|
||||
- The steps for adding a multi-source file project are the same as the basic steps for adding a single source file project
|
||||
- Add ``test1.c``, ``test1.h``, ``test2.c``, ``test2.h`` and other source files and header files that need to be relied on in the ``gpio_case`` directory
|
||||
|
||||
The directory structure is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
bl_mcu_sdk
|
||||
├── examples
|
||||
├── my_case
|
||||
├── gpio_case
|
||||
│ ├──CMakeLists.txt
|
||||
│ ├──test1.c
|
||||
│ ├──test1.h
|
||||
│ ├──test2.c
|
||||
│ ├──test2.h
|
||||
│ └──main.c
|
||||
└── xxxx_case
|
||||
|
||||
- At this time, the ``CMakeLists.txt`` file needs to add the corresponding dependent source file, the content is as follows:
|
||||
|
||||
`CMakeLists.txt`:
|
||||
|
||||
.. code-block:: cmake
|
||||
:linenos:
|
||||
:emphasize-lines: 2
|
||||
|
||||
set(mains main.c)
|
||||
set(TARGET_REQUIRED_SRCS test1.c test2.c)
|
||||
generate_bin()
|
||||
|
||||
- After writing the code, compile it in the bl_mcu_sdk directory. The compilation command is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
make BOARD=bl706_iot APP=gpio_case
|
||||
|
||||
|
||||
Add a new project with dependent libraries
|
||||
---------------------------------------------
|
||||
|
||||
- The steps for adding a new project with dependent libraries are the same as the basic steps for adding a single source file project
|
||||
- If the dependent library used already exists in this SDK, you only need to modify CMakeLists.txt
|
||||
|
||||
- If the dependent library does not exist, you need to add it yourself, please refer to the follow-up instructions for details
|
||||
|
||||
|
||||
If it already exists, the directory structure is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
bl_mcu_sdk
|
||||
├── examples
|
||||
├── my_case
|
||||
├── gpio_case
|
||||
│ ├──CMakeLists.txt
|
||||
│ └──main.c
|
||||
└── xxxx_case
|
||||
|
||||
- At this time, the ``CMakeLists.txt`` file needs to add the corresponding dependent library files. For example, we add the FreeRTOS component library, the content is as follows:
|
||||
|
||||
`CMakeLists.txt`:
|
||||
|
||||
.. code-block:: cmake
|
||||
:linenos:
|
||||
:emphasize-lines: 1
|
||||
|
||||
set(TARGET_REQUIRED_LIBS freertos)
|
||||
set(mains main.c)
|
||||
generate_bin()
|
||||
|
||||
- After writing the code, compile it in the bl_mcu_sdk directory. The compilation command is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
make BOARD=bl706_iot APP=gpio_case SUPPORT_FREERTOS=y
|
||||
|
||||
Add a new project and set the private compilation option (gcc option)
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
- The steps of adding a new project are basically the same as adding a single source file project
|
||||
- Mainly modify the CMakeLists.txt file and add private compilation options
|
||||
|
||||
`CMakeLists.txt`:
|
||||
|
||||
.. code-block:: cmake
|
||||
:linenos:
|
||||
:emphasize-lines: 2
|
||||
|
||||
set(mains main.c)
|
||||
set(TARGET_REQUIRED_PRIVATE_OPTIONS -Ofast)
|
||||
generate_bin()
|
||||
|
||||
- After writing the code, compile it in the bl_mcu_sdk directory. The compilation command is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
make BOARD=bl706_iot APP=gpio_case
|
||||
|
||||
|
||||
Add a new project and set up a private link script (ld)
|
||||
------------------------------------------------------------
|
||||
|
||||
- The steps of adding a new project are basically the same as adding a single source file project
|
||||
- Add a private link script file, such as ``gpio_test_case.ld``
|
||||
|
||||
The directory structure is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
bl_mcu_sdk
|
||||
├── examples
|
||||
├── my_case
|
||||
├── gpio_case
|
||||
│ ├──CMakeLists.txt
|
||||
│ ├──gpio_test_case.ld
|
||||
│ └──main.c
|
||||
└── xxxx_case
|
||||
|
||||
- Modify the CMakeLists.txt file and add private link script settings
|
||||
|
||||
`CMakeLists.txt`:
|
||||
|
||||
.. code-block:: cmake
|
||||
:linenos:
|
||||
:emphasize-lines: 1
|
||||
|
||||
set(LINKER_SCRIPT ${CMAKE_CURRENT_SOURCE_DIR}/gpio_test_case.ld)
|
||||
set(mains main.c)
|
||||
generate_bin()
|
||||
|
||||
- After writing the code, compile it in the bl_mcu_sdk directory. The compilation command is as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
:linenos:
|
||||
|
||||
make BOARD=bl706_iot APP=gpio_case
|
||||
|
||||
|
||||
Add a new project and its dependent source files and library files
|
||||
----------------------------------------------------------------------
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,194 @@
|
|||
.. _connect_hardware:
|
||||
|
||||
Hardware connection
|
||||
=======================
|
||||
|
||||
This document introduces how to connect the board of BL70x series MCU.
|
||||
|
||||
BL706_IOT
|
||||
-------------------------
|
||||
|
||||
Use CK-Link to Programming and debug
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Connect the CK-Link USB interface to the PC with a suitable USB data cable
|
||||
- Connect the standard ``JTAG`` pin of the ``HD3`` group of the Iot board with the ``JTAG`` pin of ``CK-Link`` using a DuPont cable
|
||||
- If you do not use CK-Link to power the board, you need to power the board separately
|
||||
|
||||
|
||||
::
|
||||
|
||||
bl706-iot board CK-Link
|
||||
-------------------------------
|
||||
JTAG_TDI <--> TDI
|
||||
JTAG_TDO <--> TDO
|
||||
JTAG_TCK <--> TCK
|
||||
JTAG_TMS <--> TMS
|
||||
VDD33 <--> VREF
|
||||
GND <--> GND
|
||||
|
||||
|
||||
.. figure:: img/ck_link_connect_bl706_iot.png
|
||||
:alt:
|
||||
|
||||
ck_link connect bl706-iot board
|
||||
|
||||
Use J-Link to Programming and debug
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Connect the USB interface of j-link to the PC with a USB data cable
|
||||
- Connect the standard ``JTAG`` pins of the ``HD3`` group of the Iot board with the ``JTAG`` pins of the ``j-link`` using DuPont wires
|
||||
- In the case of j-link connection, the board needs to be independently powered, and the power supply of the board is connected to the ``VTref`` pin of j-link
|
||||
|
||||
::
|
||||
|
||||
bl706-iot board j-link
|
||||
-------------------------------
|
||||
JTAG_TDI <--> TDI
|
||||
JTAG_TDO <--> TDO
|
||||
JTAG_TCK <--> TCK
|
||||
JTAG_TMS <--> TMS
|
||||
VDD33 <--> VTref
|
||||
GND <--> GND
|
||||
|
||||
|
||||
.. figure:: img/jlink_connect_bl706_iot.png
|
||||
:alt:
|
||||
|
||||
jlink connect bl706-iot board
|
||||
|
||||
|
||||
Use serial port to Programming
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Before using the serial port to Programming, please make sure that ``Bouffalo Lab Dev Cube`` or the command programming tool is installed correctly
|
||||
|
||||
- Use ``Type-C USB`` data cable or ``Mini USB`` data cable to connect to the ``Type-C`` interface or ``Mini`` interface on the board.
|
||||
- Press the ``Boot`` key on the board, don't release it.
|
||||
- Press the ``RST`` key on the board, now you have entered ``Boot ROM``, you can release the two keys.
|
||||
- At this time, you can see the corresponding serial port ``COM`` number from the ``Bouffalo Lab Dev Cube``, if it does not appear, please click the ``Refresh`` key to refresh.
|
||||
|
||||
|
||||
- If you don't have a suitable data cable, you can also use some common ``USB-TTL`` modules to connect to the UART0 port of the development board for programming. ``UART0`` is on the ``HD1`` group, the connection method is as follows:
|
||||
|
||||
::
|
||||
|
||||
USB-TTL BL702_IoT
|
||||
----------------------
|
||||
3V3 <--> VDD
|
||||
TXD <--> RX0
|
||||
RXD <--> TX0
|
||||
GND <--> GND
|
||||
|
||||
- The programming step is the same as above
|
||||
|
||||
BL706_AVB
|
||||
--------------------------
|
||||
|
||||
.. important::
|
||||
BL706_AVB has multiple multiplexed pins, please check carefully whether the required function pins are multiplexed; FUNC1: "Default: PIX; Connect: I2S/JTAG", FUNC2: "Default: I2S; Connect: SPI" ; **If you need to debug, please remember to connect the FUNC1 jumper**
|
||||
|
||||
Use Sipeed RV-Debugger Plus to programming and debug
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Powering the BL706_AVB
|
||||
- Connect the RV-Debugger Plus debugger to the USB port of the computer. If the driver is not installed correctly, please refer to :ref:`sipeed_rv_debugger_plus`, set the driver, and proceed to the following steps
|
||||
- Connect the debugger and the BL706_AVB with a cable (as shown in the figure below)
|
||||
|
||||
.. important::
|
||||
The FUNC1 jumper must be connected when debugging, otherwise the pins will be multiplexed with other functions and the JTAG function cannot be used; the serial port function can be used normally
|
||||
|
||||
.. figure:: img/bl706_avb_rv_debugger_plus.png
|
||||
:alt:
|
||||
|
||||
RV-Debugger connect bl706_avb board
|
||||
|
||||
Use CK-Link to programming and debug
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Connect the CK-Link USB interface to the PC with a suitable USB data cable
|
||||
- Connect the FUNC1 jump caps of the bl706_avb
|
||||
- Connect the pins of the ``HD8`` group to the adapter board using a flat cable
|
||||
- Connect the ``JTAG`` pin of the adapter board with the corresponding ``JTAG`` pin of ``CK-Link`` using a Dupont wire
|
||||
- If you do not use CK-Link to power the board, you need to power the board separately
|
||||
|
||||
::
|
||||
|
||||
bl706-avb board CK-Link
|
||||
-------------------------------
|
||||
JTAG_TDI <--> TDI
|
||||
JTAG_TDO <--> TDO
|
||||
JTAG_TCK <--> TCK
|
||||
JTAG_TMS <--> TMS
|
||||
VDD33 <--> VREF
|
||||
GND <--> GND
|
||||
|
||||
|
||||
.. figure:: img/bl706_avb_ck_link.png
|
||||
:alt:
|
||||
|
||||
ck_link connect bl706_avb board
|
||||
|
||||
Use serial port to programming
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Before using the serial port to programming, please make sure that ``Bouffalo Lab Dev Cube`` or the command programming tool is installed correctly
|
||||
|
||||
- Use the ``Type-C USB`` or ``Mini USB`` data cable to connect to the corresponding ``Type-C`` port or ``Mini`` port on the board.
|
||||
- Press the ``Boot`` key on the board, don't release it.
|
||||
- Press the ``RST`` key on the board, now you have entered ``Boot ROM``, you can release the two keys.
|
||||
- At this time, you can see the corresponding serial port ``COM`` number from the ``Bouffalo Lab Dev Cube``, if it does not appear, please click the ``Refresh`` button to refresh.
|
||||
|
||||
|
||||
- If you don't have a suitable data cable, you can also use some common ``USB-TTL`` modules to connect to the UART0 port of the development board for programming. ``UART0`` on the ``HD12`` group, the connection method is as follows:
|
||||
|
||||
- If you use Sipeed RV-Debugger Plus to connect BL706_AVB through a flat cable, you can also use the serial port of Sipeed RV Debugger Plus
|
||||
|
||||
::
|
||||
|
||||
USB-TTL BL706_AVB
|
||||
----------------------
|
||||
TXD <--> RX0
|
||||
RXD <--> TX0
|
||||
GND <--> GND
|
||||
|
||||
|
||||
Connect BL706 AVB sub-modules
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- This section describes how to connect the BL706_AVB board with other modules, mainly including camera connection, Audio Codec module connection, and SPI screen connection.
|
||||
|
||||
**BL706_AVB Connects to GC0308 Camera Module**
|
||||
|
||||
- 1. First, take the black locking part of the ``J5`` drawer type FPC cable holder on the back of the BL706_AVB development board and pull it out from the edge
|
||||
|
||||
.. figure:: img/connect_camera_1.png
|
||||
:alt:
|
||||
|
||||
|
||||
- 2. When fully disconnected, as shown in the figure below.
|
||||
|
||||
.. figure:: img/connect_camera_2.png
|
||||
:alt:
|
||||
|
||||
|
||||
- 3. The FPC cable holder is a drawer down type, so next insert the camera with the side without metal contact points facing upwards into the FPC cable holder
|
||||
|
||||
.. figure:: img/connect_camera_3.png
|
||||
:alt:
|
||||
|
||||
|
||||
- After inserting the camera, press the black latch tightly
|
||||
|
||||
.. figure:: img/connect_camera_4.png
|
||||
:alt:
|
||||
|
||||
|
||||
**BL706_AVB Connecting Audio Codec Modules**
|
||||
|
||||
- Insert the ``HD19`` group of pins of Audio Codec module into the ``HD11`` row female socket of BL706_AVB development board; note that the module is extended outward.
|
||||
- The schematic diagram is as follows：
|
||||
|
||||
.. figure:: img/connect_codec_1.png
|
||||
:alt:
|
||||
|
||||
118
docs/development_guide_en/source/get_started/get_started.rst
Normal file
118
docs/development_guide_en/source/get_started/get_started.rst
Normal file
|
|
@ -0,0 +1,118 @@
|
|||
Preparation
|
||||
=============================
|
||||
|
||||
Hardware environment
|
||||
-----------------------------
|
||||
|
||||
- At least one board for BL702 series MCU:
|
||||
|
||||
- BL706_IOT
|
||||
- BL706_AVB
|
||||
|
||||
BL706_Iot as shown in the figure below
|
||||
|
||||
.. figure:: img/bl706_iot.png
|
||||
:alt:
|
||||
|
||||
BL706_IoT
|
||||
|
||||
BL706_AVB as shown in the figure below
|
||||
|
||||
.. figure:: img/bl706_avb.png
|
||||
:alt:
|
||||
|
||||
BL706_AVB
|
||||
|
||||
- A debugger that supports standard JTAG, just choose one of the following debuggers:
|
||||
|
||||
- CK-Link
|
||||
- Jlink V11
|
||||
- Sipeed RV-Debugger Plus
|
||||
- Bouffalo Lab Debugger
|
||||
|
||||
- One PC host (Windows or Linux system)
|
||||
|
||||
Software Environment
|
||||
--------------------------------
|
||||
|
||||
In order to better use the BL702 series MCU, it is recommended that you have at least one of the following development environments:
|
||||
|
||||
- Use `CDK <Windows_quick_start_cdk.html>`_ for Windows (Windows 7 or above is recommended)
|
||||
- `Windows <Windows_quick_start_eclipse.html>`_ Use Eclipse (Windows 7 or above is recommended)
|
||||
- `Linux <Linux_quick_start_ubuntu.html>`_ (LTS version above Ubuntu 18 is recommended)
|
||||
|
||||
.. _sipeed_rv_debugger_plus:
|
||||
|
||||
Sipeed RV-Debugger Plus driver installation settings
|
||||
---------------------------------------------------------
|
||||
|
||||
- This section mainly introduces the driver installation settings of the **Sipeed RV-Debugger Plus** debugger. ``If you use **CK-Link** or **J-Link**, you don’t need to read this section.``
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_plus.png
|
||||
:alt:
|
||||
|
||||
Sipeed RV-Debugger plus
|
||||
|
||||
**Windows**
|
||||
|
||||
- To use the Sipeed RV-Debugger Plus debugger on Windows we need to change the driver to the ``Win USB`` driver
|
||||
|
||||
- 1. First, connect the Type-C USB interface of the debugger to the PC with a USB data cable, open the device manager of the PC, and you can see that the debugger is recognized as two serial ports in the port column (*Note: not the Serial port of the board's Boot interface*), or in the ``Universal Serial Bus Controller``, you see ``USB Serial Converter A`` and ``USB Serial Converter B``
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_1.png
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_4.png
|
||||
|
||||
.. important:: 1. The debugger port number must start with ``usb serial port``, if you plug in more than one similar device, please leave only one, confirm the debugger port number
|
||||
.. important:: 2. If you see "USB Serial Device (COM*)" in the Device Manager, it means that the debugger has entered the "Boot" mode. Please power off the debugger and power it on again, and be careful not to connect the debugger to the target board; at this time, go to the device manager to see if it is normal
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_7.png
|
||||
|
||||
.. important:: 3. If the serial port is not shown in the device manager, only other devices are shown, or if you only see ``USB Serial Converter A`` and ``USB Serial Converter B`` in the Universal Serial Bus Controller, please go to the `FTDI official website <https://ftdichip.com/drivers/vcp-drivers/>`_ Download the driver that matches your system
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_6.png
|
||||
|
||||
- 2. Download the ``zadig-2.4`` replacement driver from the sipeed website. Download : `http://dl.sipeed.com/MAIX/tools/sipeed-rv-debugger/zadig-2.4.exe <http://dl.sipeed.com/MAIX/tools/sipeed-rv-debugger/ zadig-2.4.exe>`_
|
||||
- 3. After downloading, double-click to open ``zadig-2.4.exe``, select ``Options`` and check ``List All Devices``.
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_3.png
|
||||
|
||||
- 4. Find JTAG Debugger (Interface 0), then select the replacement driver as ``WinUSB`` and click ``Replace Driver`` to replace
|
||||
- 5. Open the device manager again and see that one of the serial ports has been replaced with a universal serial bus device, indicating that the installation is successful
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_2.png
|
||||
|
||||
- 6. At this point, the device driver of Sipeed RV-Debugger Plus has been replaced, and then you can play happily~
|
||||
|
||||
|
||||
**Possible problems:**
|
||||
|
||||
.. caution:: 1. There are no two serial ports when the debugger is connected, and an LED on the debugger is always on, then it should be in Boot mode. Please power off the debugger and power it on again. Be careful not to connect the debugger to the target board; after the debugger is powered on, the two LED lights will flicker and go out under normal circumstances; at this time, check whether the device in the task manager is correct.
|
||||
|
||||
.. caution:: 2. If you still can’t use it normally after the above operations, and there is no correct phenomenon, it is recommended to download from the official Sipeed repository `GitHub <https://github.com/sipeed/RV-Debugger-BL702>`_ obtain the firmware and re-write; press and hold the ``Boot`` button on the debugger without releasing it, insert the debugger into the computer and power on, make the debugger enter the Boot mode, and flash the firmware again; power off and restart
|
||||
|
||||
**Linux**
|
||||
|
||||
- First, connect the Type-C USB interface of the debugger to the PC host using the USB cable, open Terminal, and enter the command ``lsusb`` in the terminal to see the device with the following information
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ lsusb
|
||||
...
|
||||
Bus 001 Device 003: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
|
||||
...
|
||||
|
||||
.. figure:: img/sipeed_rv_debugger_8.png
|
||||
|
||||
- If the above diagram does not show the ``FT2232C``, you need to install the ftdi driver
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo apt install libusb-dev libftdi-dev libhidapi-dev
|
||||
|
||||
- Re-plug the debugger to make the changes take effect
|
||||
|
||||
- Debugging code requires openocd to be installed, using openocd version 0.11
|
||||
|
||||
.. note:: In Linux system, /dev/ttyUSB1 is used for serial port, /dev/ttyUSB0 is used for debug port, if /dev/ttyACM0 is displayed, it means boot mode is entered.
|
||||
|
||||
BIN
docs/development_guide_en/source/get_started/img/Linux_logo.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/Linux_logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
docs/development_guide_en/source/get_started/img/bl706_avb.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/bl706_avb.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.7 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 302 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 259 KiB |
BIN
docs/development_guide_en/source/get_started/img/bl706_iot.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/bl706_iot.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.7 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk1.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk10.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk11.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk11.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 114 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk2.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 148 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk3.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk4.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk5.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk5.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.7 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk6.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk6.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk7.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk7.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk8.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk8.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk9.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk9.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk_start_1.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk_start_1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk_start_2.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk_start_2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk_start_3.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk_start_3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk_start_4.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk_start_4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
docs/development_guide_en/source/get_started/img/cdk_start_5.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/cdk_start_5.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 128 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 352 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 306 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 754 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 715 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 504 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 731 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 568 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
docs/development_guide_en/source/get_started/img/eclipse_run.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/eclipse_run.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 7.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.5 MiB |
BIN
docs/development_guide_en/source/get_started/img/linux1.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/linux1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 187 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic1.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic10.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 126 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic11.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic11.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic12.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic12.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic13.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic13.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic14.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic14.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic15.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic15.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 95 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic2.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 178 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic20.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic20.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 112 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic3.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic4.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic4.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic5.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic5.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic6.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic6.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic7.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic7.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic8.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic8.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic9.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic9.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
docs/development_guide_en/source/get_started/img/pic99.png
Normal file
BIN
docs/development_guide_en/source/get_started/img/pic99.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 188 KiB |
311
docs/development_guide_en/source/get_started/img/sw_arch.svg
Normal file
311
docs/development_guide_en/source/get_started/img/sw_arch.svg
Normal file
|
|
@ -0,0 +1,311 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="210mm"
|
||||
height="297mm"
|
||||
viewBox="0 0 210 297"
|
||||
version="1.1"
|
||||
id="svg8"
|
||||
inkscape:version="1.0.1 (3bc2e813f5, 2020-09-07)"
|
||||
sodipodi:docname="sw_arch.svg">
|
||||
<defs
|
||||
id="defs2">
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="Arrow1Lstart"
|
||||
refX="0.0"
|
||||
refY="0.0"
|
||||
orient="auto"
|
||||
inkscape:stockid="Arrow1Lstart"
|
||||
inkscape:isstock="true">
|
||||
<path
|
||||
transform="scale(0.8) translate(12.5,0)"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt"
|
||||
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
|
||||
id="path1582" />
|
||||
</marker>
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.979899"
|
||||
inkscape:cx="164.86583"
|
||||
inkscape:cy="237.36991"
|
||||
inkscape:document-units="mm"
|
||||
inkscape:current-layer="layer1"
|
||||
inkscape:document-rotation="0"
|
||||
showgrid="false"
|
||||
inkscape:window-width="1629"
|
||||
inkscape:window-height="1040"
|
||||
inkscape:window-x="103"
|
||||
inkscape:window-y="20"
|
||||
inkscape:window-maximized="0" />
|
||||
<metadata
|
||||
id="metadata5">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="图层 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1">
|
||||
<rect
|
||||
style="opacity:1;fill:#fcfcfc;fill-opacity:1;stroke:#010101;stroke-width:0.273592;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect717"
|
||||
width="124"
|
||||
height="83.169548"
|
||||
x="0.15000001"
|
||||
y="16.980453"
|
||||
rx="3"
|
||||
ry="2.4950864"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#ffb380;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7"
|
||||
width="120"
|
||||
height="16"
|
||||
x="2.149961"
|
||||
y="82.715889"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#ffeeaa;fill-opacity:1;stroke:#010101;stroke-width:0.209444;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-4"
|
||||
width="60"
|
||||
height="16"
|
||||
x="2.149961"
|
||||
y="50.715893"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#80ffb3;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7-2"
|
||||
width="90"
|
||||
height="16"
|
||||
x="2.149961"
|
||||
y="66.715889"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#aaccff;fill-opacity:1;stroke:#010101;stroke-width:0.209444;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-4-5"
|
||||
width="60"
|
||||
height="32"
|
||||
x="62.14996"
|
||||
y="34.715893"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#ffd42a;fill-opacity:1;stroke:#010101;stroke-width:0.209444;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-4-8"
|
||||
width="60"
|
||||
height="16"
|
||||
x="2.1499598"
|
||||
y="34.715893"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#00ffff;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7-2-8"
|
||||
width="120"
|
||||
height="16"
|
||||
x="2.1499598"
|
||||
y="18.715893"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:7.05556px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="42.977337"
|
||||
y="29.266012"
|
||||
id="text1995"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993"
|
||||
x="42.977337"
|
||||
y="29.266012"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.05556px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583">Application </tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:7.05556px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="36.370693"
|
||||
y="77.034882"
|
||||
id="text1995-0"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993-8"
|
||||
x="36.370693"
|
||||
y="77.034882"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.05556px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
id="tspan2069">STD</tspan></tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:7.05556px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="51.113491"
|
||||
y="93.471962"
|
||||
id="text1995-07"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993-13"
|
||||
x="51.113491"
|
||||
y="93.471962"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.05556px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583">Hardware</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:5.29167px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="4.5666533"
|
||||
y="60.953209"
|
||||
id="text1995-0-6"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993-8-1"
|
||||
x="4.5666533"
|
||||
y="60.953209"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5.29167px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5.29167px;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
id="tspan2069-1">HAL</tspan><tspan
|
||||
style="font-size:3.175px"
|
||||
id="tspan57">(Peripheral driver adaptation )</tspan></tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:5.29167px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="4.6949158"
|
||||
y="44.516132"
|
||||
id="text1995-0-2"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993-8-15"
|
||||
x="4.6949158"
|
||||
y="44.516132"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5.29167px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:5.29167px;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
id="tspan2069-3">HAL<tspan
|
||||
style="font-size:3.175px"
|
||||
id="tspan51">(</tspan></tspan><tspan
|
||||
style="font-size:3.175px"
|
||||
id="tspan43">Device driver management )</tspan></tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:7.05556px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="74.313263"
|
||||
y="52.801487"
|
||||
id="text1995-0-6-8"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan1993-8-1-1"
|
||||
x="74.313263"
|
||||
y="52.801487"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7.05556px;font-family:'MS Outlook';-inkscape-font-specification:'MS Outlook';fill:#000000;stroke-width:0.264583"><tspan
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Consolas;-inkscape-font-specification:Consolas"
|
||||
id="tspan2069-1-8">Wireless</tspan></tspan></text>
|
||||
<rect
|
||||
style="fill:#5599ff;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7-2-9"
|
||||
width="10"
|
||||
height="16"
|
||||
x="92.149963"
|
||||
y="66.715889"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#dedbe3;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7-2-9-9"
|
||||
width="10"
|
||||
height="16"
|
||||
x="102.14996"
|
||||
y="66.715889"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<rect
|
||||
style="fill:#80ff80;fill-opacity:1;stroke:#010101;stroke-width:0.299922;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect1860-7-2-9-9-4"
|
||||
width="10"
|
||||
height="16"
|
||||
x="112.14996"
|
||||
y="66.715889"
|
||||
rx="3"
|
||||
ry="3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:3.52778px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="94.47979"
|
||||
y="75.77092"
|
||||
id="text2206"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2204"
|
||||
x="94.47979"
|
||||
y="75.77092"
|
||||
style="font-size:3.52778px;stroke-width:0.264583">BLE</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:3.52778px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="103.48456"
|
||||
y="75.827522"
|
||||
id="text2206-3"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2204-5"
|
||||
x="103.48456"
|
||||
y="75.827522"
|
||||
style="font-size:3.52778px;stroke-width:0.264583">Wifi</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:2.82222px;line-height:1.25;font-family:Consolas;-inkscape-font-specification:Consolas;stroke-width:0.264583"
|
||||
x="112.57171"
|
||||
y="75.426605"
|
||||
id="text2206-8"
|
||||
inkscape:export-xdpi="600"
|
||||
inkscape:export-ydpi="600"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan2204-8"
|
||||
x="112.57171"
|
||||
y="75.426605"
|
||||
style="font-size:2.82222px;stroke-width:0.264583">ZigBee</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.9 KiB |
35
docs/development_guide_en/source/get_started/index.rst
Normal file
35
docs/development_guide_en/source/get_started/index.rst
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
|
||||
.. _get_started_index:
|
||||
|
||||
=======================================
|
||||
Development environment setup guide
|
||||
=======================================
|
||||
|
||||
Before the formal development, please set up a suitable development environment. The specific steps are as follows:
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
Windows_CDK <Windows_quick_start_cdk>
|
||||
Windows_eclipse <Windows_quick_start_eclipse>
|
||||
Linux <Linux_quick_start_ubuntu>
|
||||
|
||||
+-------------------+--------------------+-------------------+
|
||||
| |cdk-logo| | |eclipse-logo| | |linux-logo| |
|
||||
+-------------------+--------------------+-------------------+
|
||||
| `Windows_CDK`_ | `Windows_eclipse`_ | `Linux`_ |
|
||||
+-------------------+--------------------+-------------------+
|
||||
|
||||
.. |cdk-logo| image:: img/windows_cdk_logo.png
|
||||
:target: Windows_quick_start_cdk.html
|
||||
|
||||
.. |eclipse-logo| image:: img/windows_eclipse_logo.png
|
||||
:target: Windows_quick_start_eclipse.html
|
||||
|
||||
.. |linux-logo| image:: img/Linux_logo.png
|
||||
:target: Linux_quick_start_ubuntu.html
|
||||
|
||||
.. _Windows_CDK: Windows_quick_start_cdk.html
|
||||
.. _Windows_eclipse: Windows_quick_start_eclipse.html
|
||||
.. _Linux: Linux_quick_start_ubuntu.html
|
||||
|
||||
69
docs/development_guide_en/source/index.rst
Normal file
69
docs/development_guide_en/source/index.rst
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
.. bl_mcu_sdk_development_guide documentation master file, created by
|
||||
sphinx-quickstart on Fri Mar 12 16:32:56 2021.
|
||||
You can adapt this file completely to your liking, but it should at least
|
||||
contain the root `toctree` directive.
|
||||
|
||||
========================================================
|
||||
BL MCU SDK development guide
|
||||
========================================================
|
||||
|
||||
The `BL702 <https://www.bouffalolab.com/bl70X>`_ series products are general-purpose microcontrollers based on "SiFive E24 Core" `RISC-V <https://en.wikipedia.org/wiki/RISC-V>`_ , with network functions such as BLE 5.0, zigbee and Ethernet, as well as other rich peripherals.
|
||||
It can be used in a wide range of `IoT <https://en.wikipedia.org/wiki/Internet_of_things>`_ and other low-power applications.
|
||||
Supports programming and debugging of the chip through `JTAG <https://en.wikipedia.org/wiki/JTAG>`_ , and also supports through `UART <https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter>`_ programming.
|
||||
BL MCU SDK will provide users with comprehensive support for BL70X series MCU development.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Quick Development Guide
|
||||
:numbered: 3
|
||||
|
||||
get_started/get_started
|
||||
get_started/connecting_hardware
|
||||
get_started/index
|
||||
get_started/cmake_quick_start
|
||||
get_started/cdk_new_project_quick_start
|
||||
get_started/bl_dev_cube
|
||||
get_started/board
|
||||
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: API Manuals
|
||||
:numbered:
|
||||
|
||||
api_reference/api_overview
|
||||
api_reference/peripheral/index
|
||||
#api_reference/shell/api_shell
|
||||
#api_reference/usb stack/api_usb_stack
|
||||
api_reference/bluetooth/api_ble
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Basic Peripheral Samples
|
||||
:numbered:
|
||||
|
||||
samples/basic samples/gpio/index
|
||||
samples/basic samples/uart/index
|
||||
samples/basic samples/pwm/index
|
||||
samples/basic samples/mtimer/index
|
||||
samples/basic samples/dma/index
|
||||
samples/basic samples/spi/index
|
||||
samples/basic samples/i2c/index
|
||||
#samples/basic samples/i2s/index
|
||||
samples/basic samples/adc/index
|
||||
samples/basic samples/timer/index
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Advance Samples
|
||||
:numbered:
|
||||
|
||||
samples/advance samples/shell_demo
|
||||
samples/advance samples/fatfs_demo
|
||||
#samples/advance samples/usb/index
|
||||
samples/advance samples/lowpower_demo
|
||||
samples/advance samples/boot2_iap_info
|
||||
samples/advance samples/ble_scan_demo
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue