本帖最后由 Simon21ic 于 2015-8-16 13:31 编辑
看来这个坛子里，还有人玩系统构架。我就来开开脑洞吧
大家是否有想过，从芯片的硬件角度，系统是如何运行的？
我的答案是，从硬件角度，系统都是事件驱动的，事件就是各种中断。那为什么不设计一个软件系统，完全由事件驱动？
系统模型：
系统只是响应各个中断，中断产生事件，发送给特定能够处理这个事件的模块，然后，模块可以发送多个事件给其他多个模块，直到所有产生的事件都被处理了，系统休眠。
main函数，可以认为是编译器产生的代码，自动处理了复位事件，初始化完运行环境后，调用main.c
在这个构架下，main函数就是这样的：
- int main(void)
- {
- vsf_leave_critical();
- vsfsm_init(&app.sm);
- while (1)
- {
- vsfsm_poll();
-
- vsf_enter_critical();
- if (!vsfsm_get_event_pending())
- {
- // sleep, will also enable interrupt
- core_interfaces.core.sleep(SLEEP_WFI);
- }
- else
- {
- vsf_leave_critical();
- }
- }
- }
- vsf_err_t vsfsm_poll(void)
- {
- struct vsfsm_t *sm;
-
- while (vsfsm_evt_count)
- {
- sm = vsfsm_evtq_head->sm;
- (vsfsm_evtq_head == &vsfsm_evtq[VSFSM_CFG_EVTQ_SIZE - 1]) ?
- vsfsm_evtq_head = &vsfsm_evtq[0] : vsfsm_evtq_head++;
- vsf_enter_critical();
- sm->evt_count--;
- vsfsm_evt_count--;
- vsf_leave_critical();
- vsfsm_dispatch_evt(sm, vsfsm_evtq_head->evt);
- }
- return VSFERR_NONE;
- }
既然有人能够看懂，那就多讲一些，其实非常简单。
这里是USB设备端协议栈里的事件处理函数的一小部分：- static struct vsfsm_state_t *
- vsfusbd_evt_handler(struct vsfsm_t *sm, vsfsm_evt_t evt)
- {
- struct vsfusbd_device_t *device =
- container_of(sm, struct vsfusbd_device_t, sm);
- vsf_err_t err = VSFERR_NONE;
-
- switch (evt)
- {
- case VSFSM_EVT_FINI:
- device->drv->fini();
- device->drv->disconnect();
- if (device->callback.fini != NULL)
- {
- device->callback.fini();
- }
- break;
- case VSFSM_EVT_INIT:
- {
看到这里，熟悉状态机的朋友，应该觉得情切了吧？这里是TCPIP协议栈里的TCP处理状态机的一小部分代码：
- static void vsfip_tcp_socket_input(void *param, struct vsfip_buffer_t *buf)
- {
- struct vsfip_socket_t *socket = (struct vsfip_socket_t *)param;
- struct vsfip_tcppcb_t *pcb = (struct vsfip_tcppcb_t *)socket->pcb.protopcb;
- struct vsfip_tcphead_t head = *(struct vsfip_tcphead_t *)buf->buf.buffer;
- bool release_buffer = true;
-
- pcb->rwnd = head.window_size;
- switch (pcb->state)
- {
- case VSFIP_TCPSTAT_INVALID:
- goto release_buf;
- case VSFIP_TCPSTAT_CLOSED:
- vsfip_tcp_sendflags(socket, VSFIP_TCPFLAG_RST);
- goto release_buf;
- case VSFIP_TCPSTAT_LISTEN:
- if ((VSFIP_TCPFLAG_SYN == head.flags) &&
- (socket->listener.accepted_num < socket->listener.backlog) &&
- !socket->listener.closing)
- {
单单用switch的方式实现系统功能是否相当麻烦？在传统的面向过程的阻塞代码，要移植到事件驱动可是相当麻烦的。
还好，瑞典人发明了PT协程（后面成为PT线程），我在构架里，实现了完全事件驱动的PT协程，一个协程的代码，差不多是这样的：
- vsf_err_t XXX_thread(struct vsfsm_pt_t *pt, vsfsm_evt_t evt)
- {
- struct user_data_t *user_data = (struct user_data_t *)pt->user_data;
-
- vsfsm_pt_begin(pt);
-
- while (1)
- {
- if (vsfsm_sem_pend(&user_data->sem, pt->sm))
- {
- vsfsm_pt_wfe(pt, user_data->sem.evt);
- }
-
- user_data->timer.evt = EVT_TIMEOUT;
- vsftimer_register(&user_data->timer);
- vsfsm_pt_wfe(pt, EVT_TIMEOUT);
-
- ....
- }
-
- vsfsm_pt_end(pt);
- return VSFERR_NONE;
- }
PT协程，虽然看似是阻塞的，但是，实际运行是非阻塞方式的，也就是说，多个PT协程，是可以“同时”运行的。
vsfsm_sem_pend是等待信号量，如果信号量不是立即可以得到的话，那么当别人发出信号量后，本协程会收到对应的事件。
后面的vsfsm_pt_wfe就是wait for event，等待事件了，当然，这里不是死等，而是退出程序，等别人发送了事件了，在重新进入程序，从之前的退出点继续运行。
再后面注册的定时器，也是类似，等待超时事件。
既然这里用到了信号量（semaphore），那也简单说一下吧，信号量是操作系统里，用于线程间同步的工具。实质上，信号量的这种用法就是事件的缓冲。
按照上面的例子，如果这个线程用于处理某个请求，而请求的处理过程，需要一定的时间（比如这里等待超时）。
如果不使用信号量，而是用等待请求处理事件的话，那么就可能在后面等待超时的时候，收到这个请求处理事件，这个时候就会出问题(因为当时在等待超时事件，而非请求处理事件)。
所以，使用了信号量，先把请求处理事件缓冲在信号量里，等到处理线程可以处理下一个请求时，再去调用vsfsm_sem_pend获得信号（如果当时无法获得，就等待信号的获得事件）。
一个关键，事件处理过程，需要是非阻塞的，这点是系统实现多任务的关键。PT线程里，当需要阻塞的时候（比如等待超时），函数会退出，直到收到相应的事件后，再重新进入，从之前的退出点继续运行。
一些CPU占用过多的任务，也需要在适合的地方，主动释放CPU资源，让系统处理其他事件，处理完后，再回到自己的程序，继续运行。
甚至，可以在某些位置，判断事件队列里是否有事件要处理，有的话才释放CPU资源，没有就继续处理自己的任务。这是不是就是 共 产 主 义 的按需分配？
这里只是从使用角度，说明了一下我的系统，内核怎么实现的，大家可以想一下，cortexM等级的处理器，根据系统配置，内核部分占用300多 - 600多字节，应该也算是一个微内核了吧。
状态机和操作系统就不讲了
| 
楼主
