【LPC54114双核使用指南翻译】+任务八

feixiang20 · 发表于 2017-6-8 18:30:02

本帖最后由 feixiang20 于 2017-7-9 22:56 编辑

advanced Inter-coreoperations
高级Intel Core操作

Shared data implementation

共享数据的实现

Share the same RAM range between two cores.
User code define and interpret the data structure
Define the “shared data” struct and put in a “.h” file.
Both projects need to include this header.
Both project define exactly one instance of this struct
Must make sure the address of the shared object is manually set
Need to configure linker to put the shared data to designated place.
(LPC541xx): Can use IRQ0/1 registers to pass the address of shared data.
Code can poll the shared data periodically, or send IRQ to the other when the code update some fields in the shared data.
Don’t forget “volatile” keyword to ensure compiler always access true variable.

在两个内核之间共享相同的RAM范围。
用户代码定义和解释数据结构
定义这个“共享数据”结构并放入“h”文件中。
这两个项目都需要包含此头文件。
这两个项目都确切地定义了这个结构的一个情况。
必须确保共享对象的地址是手动设置的。
需要配置链接器将共享数据放到指定的位置。
（lpc541xx）：可以使用IRQ0 / 1寄存器来传递共享数据的地址。
代码可以共享数据的定期调查，或发送IRQ的其他当代码更新共享数据等。
不要忘记“易失”关键字，以确保编译程序总是获取正确的变量。

Extension of mailbox: Software Message pool

邮箱扩展：软件消息池

Each item in pool is a message
Message items have fixed length.
Item has 3 status: New, Idle, Preprocessed
Sender traverses the pool to scan idle item
Write message data to idle item and update item to “new”
Receiver side:
ISR traverses the pool to scan new items, and do first step processing.
If ISR can process it completely, update the item status to “idle” again.
If ISR can’t do all job, mark a “new” item to “preprocessed”
RTOS can then dispatch preprocessed items to tasks
Drawbacks：
Message items can’t be too many to make traverse time too long.
Risk: Insufficient items when messages are flooding.

池中的每个项目都是一个信息
消息项有固定长度。
项目有3个状态：新的，空闲的，预处理
发送者通过池扫描空闲项
将消息数据写入空闲项并将项目更新为“新的”
接收端：
ISR通过池扫描新项目，并进行第一步处理。
如果ISR可以完全处理，更新项目状态为“空闲”。
如果ISR不能做所有的工作，标记一个“新的”项目到“预处理”
RTOS随后可以将预处理的项目分派给任务。
缺点：
消息项不能太多，使通过时间过长。
风险：消息超出范围时项目不足。

From store structure view, message pool is simplified message queue and they are based on array structure, they don’t have the indces for read and write. Each element in pool corresponds to a message, and it has one byte to show its state: Idle(processed), new, preprocessed. When sender writes message, it scans the array to check the first idle element; when receiver reads message, it also scans the array for all non idle elements.
Message pool can be scanned in parallel without the risk of race condition, because sender and receiver do not compete. Furthermore, elements can be processed in two passes. The first pass is in IRQ context to handle real-time part. If IRQ context part completes the element then mark it as idle, else mark it as preprocessed. Then in background context or task context if RTOS is used, continue processing the preprocessed message.
There is a major drawback of message pool: The capacity of pool can’t be too high, otherwise it will take too much time to scan the array.

从存储结构来看，消息池简化消息队列，它们是基于阵列结构，他们没有读写的indces。池中的每个元素对应一条消息，它有一个字节来显示它的状态：空闲（处理）、新的、预处理的。当发送方写入消息时，它会扫描数组以检查第一个空闲元素；当接收方读取消息时，它也将扫描所有非空闲元素的数组。
消息池可以并行扫描而不受比赛条件的影响，因为发送方和接收方不竞争。此外，元素可以在两个通行证处理。第一关是在中断上下文处理实时部分。如果中断上下文部分完成的元素，将其标记为空闲，其他标记为预处理。然后在后台上下文或任务上下文中使用RTOS，继续处理预处理消息。
消息池的主要缺点是：池的容量不能太高，否则要花费太多的时间扫描数组。

Alternate inter-core messaging: unidirectional ring queue pair

交替inter-core队列：单向环队列对

As an alternative of Software messaging pool
Two unidirectional ring queues, one is M4 to M0, the other is M0 to M4,
Sender core is write-only, receiver core is read-only.
Sender to judge when queue is full, receiver to judge when queue is empty
Both sender and receiver update write/read indexes after they processed the item.
Queues have fixed size items or work as byte streams (Special case when item size is 1 byte).
Queues have write index and read index and they rollback to form ring structure.
If capacity is 2**n (8,16,32,…), rollback can be simplified as “index = (index + 1) & (cap - 1)”
Queues can also have “count” field to ease judging empty and full conditions.
Or Just omit “count” field by wasting one item space:
When read == write means empty, When (write+1)%capacity == read means full
If capacity is 2**n (8,16,32,…), “%” can be converted to “&” ---- Makes M0+ happy.
Sender can send IRQ to receiver after it produces new item(s), and vice versa.
May use additional s/w IRQ flags to specify the reason of IRQs.

作为软件消息池的另一种选择
两单向环形队列，一个是M4 M0，其他是M0到M4，
发送方核心只写，接收方核心为只读。
发送方判断队列是否满时，接收方判断队列是否为空
发送方和接收方在处理该项目后更新写/读索引。
队列有固定大小的项目或工作字节流（特殊情况下，当项目大小为1字节）。
队列有写索引和读索引，它们回滚形成环结构。
如果容量是2×N（8,16,32，…），回滚可以简化为“指数=（指数+ 1）和（第1）”
队列也可以有“计数”字段以便于判断空和满条件。
或省略“计数”字段浪费一个项目空间：
当读=写的意思是空的，当（写+ 1）%的能力=阅读意味着充分
如果容量是2×N（8,16,32，…），“%”可以转化为“&”----让M0 +快乐。
发送者可以产生以后新项目接收发送IRQ（S），反之亦然。
可以使用附加的S / W的IRQ标志指定IRQ的原因。

Further Mutual exclusion besides hardware MUTEX
进一步互斥除硬件互斥

For shared ring buffer/queue structures, enforce below constraints:
Only sender is allowed to modify write index
Only receiver is allowed to modify read index
For message pool:
Only sender is allowed to change “idle” state to “new” state
Only receiver is allowed to change “new” state to “preprocessed” or “idle” state.
When pointers are involved：Only one core is allowed to modify pointer
The other core can set some flags to ask pointer owner to modify pointer
Note: LPC4300 does not support hardware MUTEX, above are only choices.

对于共享环缓冲/队列结构，强制执行以下约束：
只有发送方允许修改写入索引
只允许修改读索引
用于消息池：
只有发送方允许将“空闲”状态更改为“新”状态
只有接收方允许将“新”状态改为“预处理”或“空闲”状态。
当涉及到指针时，只允许一个内核修改指针。
另一个核心可以设置一些标志，要求指针所有者修改指针
注：lpc4300不支持硬件互斥，以上只是选择。

阅读全文