翻译的是这个文档。
它介绍了整个系统架构，组件，应用程序编程接口（API）以及开发工具链，环境和过程。
问题点请在评论中留言，我看到了回去改正。
7 System Software
DA1458x SDK的系统软件包含以下模块：
●应用程序的主要功能和主要循环。
●睡眠和电源管理软件。
●BLE事件IRQ处理程序。
●ROM代码的修补功能。
●BLE堆栈和系统配置。
●最后，系统软件将许多API导出到应用程序代码，以方便控制睡眠模式，在主循环中执行应用程序软件并提供开发/调试功能。
7.1 Main Loop and Sleep Modes
7.1.1 Sleep Modes
Extended Sleep mode,
保持供电的有
SysRAM，retention RAMs ，wakeup timer, quadrature decoder and the BLE timer.
关闭的有
radio domain and the peripheral domain are powered down and the XTAL16M clock is stopped.
Deep Sleep mode
在Extended Slee基础上，再关闭SysRAM。
7.1.2 Wake-Up Events
不管是Extended Sleep 还是Deep Sleep，都可以按照下面两种方式唤醒。
-
Synchronously, via the BLE timer which can be programmed to wake up the system in order to
serve a BLE event
同步地，通过BLE定时器，可以将其编程为唤醒系统以处理BLE事件 -
Asynchronously, via the Wakeup Timer and Quadrature Decoder if triggered by an external event(input).
异步，经由唤醒定时器和正交解码器，如果由外部事件（输入）来触发。
在BLE应用中，可以将DA14580 / 581/583设置为上述任何一种睡眠模式。对于广告事件，连接事件或其他无线通信事件，需要唤醒DA14580 / 581并进入活动模式，以便通过BLE无线发送/接收数据包关联。由于这些事件是基于时间的，因此BLE定时器用于唤醒系统，包括BLE内核，无线电，ARM处理器和其余模块。在这种情况下，使用以下约定：“系统与BLE内核同步唤醒”。
理解，这个BLE core是一个单独跑的逻辑，里面有BLE timer，会时基（Since these events are time based）的去唤醒。时基理解的就是连接里面的周期性的通讯连接。
所以问题来了，ROM里面的代码，是不是就是给BLE core在跑？M0会不会跑ROM代码？不知道！
在扩展/深度睡眠模式下，DA14580 / 581/583也可以通过外部事件唤醒，并且在唤醒后，ARM处理器可以执行某些功能。 但是，在那一刻可能还不是BLE通信事件的时间，例如 连接事件，因此BLE和无线电可以保持断电状态。 在这种情况下，将使用以下约定：“使用BLE内核异步唤醒系统”。
理解，这里就是说外部唤醒，时间上和BLE通信的实践不同步。
如果系统被异步唤醒，则任何将消息传输到内核任务的请求（最终通过蓝牙无线链路）都无法立即执行，必须将其同步到BLE内核。 这是因为堆栈的构建方式使得消息事件的处理要求BLE内核处于活动状态，以便BLE内核的定时信息可用。 当BLE内核掉电时，此时序信息不可用。
理解，唤醒后kernal task想立即传消息，不行，这是由于消息事件的处理，需要BLE core完成，需要先保证BLE core active.
7.1.3 Main Loop
在SDK版本5.0.2（或更高版本）中，对主循环进行了重构，以使程序员更容易理解。 尽管应用程序程序员不应更改主循环，因为它是作为SDK的一部分，大多数程序员都希望通过主循环执行来了解应用程序流程。
主循环程序的第一部分会一直执行，只要内核 kernel或者应用application需要CPU跑起来。主循环的第二部分就是在尝试进入低功耗模式，并从低功耗模式下恢复。
第一部分，通过调用rwip_schedule()授权kernel控制，只要有消息事件处理，就会保持控制。只要内核需要BLE硬件运行去处理消息，rwip_schedule()通过schedule_while_ble_on()的调用实现。
在schedule_while_ble_on()函数中，应用通过ser_app_main_loop_callbacks.app_on_ble_powered函数指针被授权控制。根据返回值为app_on_ble_powered，BLE依旧保持激活，应用可以强制main loop保持一直运行schedule_while_ble_on() 函数。
第二部分，如果应用和内核允许scheduler_while_ble_on() 返回，通过app_asynch_proc()函数和user_app_main_loop_callbacks.app_on_system_powered函数指针，控制权将再次交由应用。
这种情形往往发生在，当BLE关闭的时候，应用依旧希望main loop处于运行状态。
app_on_system_powered 的返回值对while 循环的控制是同样的方式。
应用决定没事做了，软件才会尝试进入power down低功耗模式。
在进入power down低功耗模式模式前，application 被授权三次控制：
第一次，启动power down sequence 的函数(user_app_main_loop_callbacks.app_before_sleep),
第二次，函数user_app_main_loop_callbacks.app_before_sleep在关闭外设前验证sleep
第三次，在WFI()被调用前，执行函数user_app_main_loop_callbacks. app_going_to_sleep完成最终的housekeeping jobs 工作。
通过user_app_main_loop_callbacks.app_resume_from_sleep对main loop进行恢复，进而application 能够被调用。软件返回main loop的第一部分并再次循环运行。
7.2 System API
7.2.1 Main Loop Callbacks
The system software API exports a number of application callback functions called in the main
function of SDK projects.
在主函数的SDK工程中，system software API 导出许多application callback functions 。
The application callback functions are defined by struct
arch_main_loop_callbacks type variable user_app_main_loop_callbacks in the
user_callbacks_config.h header file.
application 的回调函数在user_callbacks_config.h 头文件中，通过结构体类型 arch_main_loop_callbacks定义的变量user_app_main_loop_callbacks 。
在任何结构体回调函数中，以防无application 任务，回调项应该被分派为NULL。
在程序中找到的arch_main_loop_callbacks定义的结构体成员和上图的不太一致，SDK版本问题？？
题外话，程序中很多函数指针，本质是指针，指向某种类型的函数。
例如 return user_app_main_loop_callbacks.app_on_ble_powered();
这里就发生了一次函数调用，结构体变量user_app_main_loop_callbacks中的函数指针(*app_on_ble_powered)()肯定指向了某个函数，这个函数在return这里发生了一次调用。
至于这里说的函数指针(*app_on_ble_powered)()肯定指向了某个函数，我也不知道是在哪里赋值的，或许是对用户没开放的内核调度里面？？
7.2.2 Sleep API
系统软件对应用提供Sleep API ，去修改运行模式(Active,Extended sleep, Deep sleep). 这些API是在arch_sleep.h 头文件中定义，提供的接口如下：
void arch_ble_ext_wakeup_off(void)
In this mode, the BLE core will wake up every 10sec even if no BLE events are scheduled.
注意，arch_sleep.c 模块检测函数 arch_force_active_mode() (the counter is incremented) and to arch_restore_sleep_mode() (the counter is decremented)的调用次数。
为了函数arch_restore_sleep_mode()真是使能sleep模式，计数器必须清零。
这就要求应用需要确保函数arch_restore_sleep_mode()和的调用次数不比函数arch_force_active_mode()的调用次数少。如果应用有不同的模块，这个规则适用于每一个模块。
最后，值得注意，在sleep modes下，Debugger 调试器不可用，能理解的吧。
7.2.3 Serial Logging Interface API
rch_console.h头文件中的这些API接口，提供串行话的日志接口，
在应用这些串口日志API前，define声明CFG_PRINTF标志。同时，在应用前，声明CFG_PRINTF_UART2 标志，且在工程文件中假如合适的SDK驱动文件。
7.2.4 BLE Statistics API
The system software provides a simple API to collect statistics about a given connection. When
enabled with the CFG_BLE_METRICS, code is added in the receive interrupts that counts the errors during the communication of the device with a remote peer. The data are kept in a global structure of the following type:
系统软件提供简洁API去收集特定连接的统计数据。通过使能CFG_BLE_METRICS，通信时候的接受中断的错误计数代码激活，统计数据保存在如下结构体中。
typedef struct
{
uint32_t rx_pkt;
uint32_t rx_err;
uint32_t rx_err_crc;
uint32_t rx_err_sync;
}arch_ble_metrics_t;
通过调用函数arch_ble_metrics_get()得到结构体指针，通过arch_ble_metrics_reset()函数清空结构体。
7.2.5 Development Mode API
为了去跟踪普通错误或者更好的开发，SDK软件提供一个CFG_DEVELOPMENT_DEBUG标志位轻松进入开发者调试模式。量产软件中需要关闭该标志位，是因为开启后以下功能将会被使能
● SysRAM 即便在Deep sleep mode也无法被powered down，目的是允许开发者在Deep sleep mode也能跑应用，而不必去OTP编程。这个能理解，还是很有必要的。
●可验证GPIO是否配置超过一个以上的功能。
● Hard Fault, NMI and assert conditions的断点会自动发出，以帮助开发人员连接调试器并跟踪错误原因。
###7.2.5.1 GPIO Reservation
在开发调试模式下，在通过GPIO驱动程序发出操作之前，应用程序应使用RESERVE_GPIO（name，port，pin，func）函数保留GPIO引脚。
尝试保留已保留的引脚或尝试使用未保留的引脚将使应用程序出现断点而中断。
通过定义GPIO_DRV_PIN_ALLOC_MON_DISABLED标志来保留内存资源，即使在开发调试模式下，也可以禁用GPIO保留功能。
###7.2.5.2 Assert, NMI and Hard Fault Handlers
在开发调试模式下，将ASSERT_ERROR（）和ASSERT_WARNING（）宏定义为断点。一旦检测到错误情况，程序将停止运行，用户可以连接调试器并找出导致错误的原因。
在生产模式下（未定义CFG_DEVELOPMENT_DEBUG），ASSERT_WARNING（）不执行任何操作，而ASSERT_ERROR（）将使程序停留在while（1）循环中，以等待看门狗复位。
与ASSERT逻辑类似，硬故障和NMI处理程序都在开发模式下设置为断点，并且将在生产模式下进行重置。在开发模式下，两个处理程序都将在发出断点之前将处理器状态的副本保留在保留RAM中。保存的状态信息包括以下内容寄存器值R0-R3，R12，LR，PC，PSR，SP，CFSR，HFSR，AFSR，MMAR，BFAR。用户可以查看状态信息以尝试跟踪哪个命令已发出NMI或硬故障。
NMI处理程序将状态保存在地址0x81850中，硬故障处理程序将保存在地址0x81800中。
7.2.6 Advanced Features API
详细情况，参考附录E.
###7.2.6.1 Wake-Up and External Processor Configuration
采用外部处理器架构下，唤醒的处理配置。
GTL在Figure 7: External Processor HW Configuration中有描述。
###7.2.6.2 True Random Number Generator (TRNG)
如何配置去生成随机数。系统初始化时会生成一个随机数，并将其用作C标准库随机数生成器的种子。
###7.2.6.3 Boost Output Voltage (DCDC_VBAT3V)
控制BOOST的升压具体是多少。
###7.2.6.4 Near Field Control
控制Near Field mode的使能，降低发射功耗。
###7.2.6.5 AES Crypto
DA1458x SoC带有AES加密硬件引擎。 该引擎是从堆栈中使用的，但是如果需要，也可以从用户中调用。 必须通过同步（通过消息）方式进行通信，以确保API的使用不会与从堆栈调用的操作冲突。还提供了AES的纯软件实现，程序员可以将其用作替代方案。 有关更多信息，请参阅附录E.5。
###7.2.6.6 Co-Existence
提供了一组用于处理WLAN共存的功能。 支持两个WLAN 的incoming输入和BLE优先级输出。 提供的功能可处理每个连接的优先级和蓝牙状态。 有关更多信息，请参阅附录E.6。
incoming不知道怎么翻译好。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
