0%

一直想入手一个智能手表,可惜Apple Watch需要连接苹果手机,遂未能如愿。最近小米终于发布一款智能手表,支持ESIM,使用Wear OS,果断入手。

实际使用发现Bug不少,软件不多。Bug可以等系统更新来解决。不过软件不多是生态链的问题,等生态链慢慢建起来实在太慢。Wear OS是Android的一个分支,理论上应该支持安装安卓应用才对。翻了下小米手表的设置,也是有看到可以做ADB调试,因此理应可以用ADB安装Android应用。

Read more »

本文介绍和Zephyr线程的数据结构,及相应的API。

数据结构

Zephyr数据结构使用k_thread定义,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
struct k_thread {
struct _thread_base base;
struct _callee_saved callee_saved;
void *init_data;
void (*fn_abort)(void);

#if defined(CONFIG_THREAD_MONITOR)
struct __thread_entry entry;
struct k_thread *next_thread;
#endif
#if defined(CONFIG_THREAD_NAME)
char name[CONFIG_THREAD_MAX_NAME_LEN];
#endif
#ifdef CONFIG_THREAD_CUSTOM_DATA
void *custom_data;
#endif
#ifdef CONFIG_THREAD_USERSPACE_LOCAL_DATA
struct _thread_userspace_local_data *userspace_local_data;
#endif
#ifdef CONFIG_ERRNO
#ifndef CONFIG_USERSPACE
int errno_var;
#endif
#endif

#if defined(CONFIG_THREAD_STACK_INFO)
struct _thread_stack_info stack_info;
#endif /* CONFIG_THREAD_STACK_INFO */
#if defined(CONFIG_USERSPACE)
struct _mem_domain_info mem_domain_info;
k_thread_stack_t *stack_obj;
#endif /* CONFIG_USERSPACE */
#if defined(CONFIG_USE_SWITCH)
int swap_retval;
void *switch_handle;
#endif
struct k_mem_pool *resource_pool;
struct _thread_arch arch;
};
Read more »

前言

一直想写一些RTOS的技术资料,算作对自己之前一些相关技术调研的总结。无奈懒癌发作,一拖再拖。然今日灌上鸡血,笃定主意,从最基本的调度相关内容开始。

简单讲,Zephyr是一个开源实时操作系统。相较Linux,其对系统资源的使用量更小,当然也牺牲了许多复杂且完善的功能(如,系统Debug易用性,线程的堆栈保护)。与此同时,因其是开源社区开发,也多少继承和保留了许多Linux系统的优秀思想和功能(例如,Workqueue、设备树等)。其定位为万物互联时代各种各样的嵌入式设备,目光长远。

Read more »

一直使用ZoC做阿里云ECS管理,方便好用。不过经常会License过期。
收集几个备用,之后过期可以来这里拿:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Part A: 55834/01027/59600
Part B: 43010

Part A: 11370/01027/29134
Part B: 51686

Part A: 61298/01028/48550
Part B: 00985

Part A: 51698/01027/34713
Part B: 00937

Part A: 50866/01027/47775
Part B: 57341

Part A: 53866/01028/18861
Part B: 45757

Part A: 03754/01029/23239
Part B: 50179

从长假回公司已经有一个月了,慢慢也进入到工作状态。
这次回来,还是有蛮多感触。看到晚几年进公司的同事,一步步承担更重的任务。深觉须时时努力,不断进步。方能担负得起自己所承担的任务。
今年运气欠佳,也希望努力可以带来更好的运气。

一直希望使用Markdown来写博客,无奈Wordpress对Markdown的原生支持太差。而且受不了Wordpress程序执行的龟速。

因此趁着国庆把博客程序作了更换成了Hexo,托管网站也换成了Github。

简单说明一下转移作了哪些事情:

  • 申请Github Pages 并绑定域名
  • 安装Hexo,并下载相应所需插件。没想到有Wordpress转Hexo插件,真是帮了大忙
  • 把之前上传在网站空间的图片,全部下载并转存到七牛云存储上(这里有点小技巧,用Notepad++的正则表达式查找替换,节省时间,事半功倍)
  • 使用NeXT主题,自带很多需要的功能,包括可以显示属性公式的Mathjax,原Wordpress博客的数学公式,也并没有受到影响(当然也要做一些非常简单的文本替换,同样Notepad++搞定)
  • 因为博客是使用Hexo生成静态页面上传到Github Pages。特意申请了一个Github私有项目保存保存源码,方便多机编辑(这也是Hexo唯一的不方便,每个机子都要重新建环境)
  • 另外一些原博客需要的一些小修改,不表。
Read more »

回顾下操作系统概念:现代计算机往往都是“同时”运行多个任务。系统若只有一个处理器,那么给定时刻只可能有一个任务在执行。而操作系统通过进程管理和调度,切换正在执行的任务,是用户在感官上认为计算机是并行执行多个任务。当然,若是多处理器系统,真正同时执行的任务可以达到处理器的数目。

内核进行进程管理的主要解决的问题:

Read more »

刚刚给Mac更新了系统,发现多了一项功能,即修改屏幕主题色。有浅色和深色两种选择。深色的还蛮酷的。修改方法:

系统偏好设置->通用->外观

选择你喜欢的主题色即可

内存管理是Linux内核最为复杂且最为重要的部分,本文从原理及代码角度对Linux内存管理机制进行分析。

内存的划分

Linux将内存从大到小依次划分为Node(节点)->Zone(内存域)->Page(页):

  • 节点:在大型结算及系统中,内存有不同的簇,依据对处理器距离的不同,访问这些簇有不同的代价。而这些簇就可以成为节点。例:在PC系统中可以理解为实际挂载的物理内存;在嵌入式系统中,有两块内存芯片A和B,分别代表一个节点。
  • 内存域:内存域并不是物理存在的概念,是Linux系统对每个内存节点进行管理的单位,每个节点的内存域表示的是对该节点不同地址范围的划分。一般内存域有三种,分别为Normal、DMA和HighMem。
  • 页:在每个内存域中,内存被划分为大小固定的块(32位系统一般为4K大小),为内核进行内存分配的基本单位(当然内核内存管理机制其实更为复杂,“基本单位”不代表每次分配内存最小就要分到4K。后边可以看到,当需要获取小于4K大小的内存时,内核有Slab分配器来满足要求)
Read more »

为什么需要MTD子系统

嵌入式系统使用Flash作为存储设备,Flash类别有Nand、Nor等。Flash的上层是文件系统。直觉上,系统中使用这些Flash时,我们需要为每种Flash编写驱动。同时在调用Flash的文件系统做接口对接。这样,每使用一种新的Flash类型甚至型号,都得修改文件系统的编码来做适配。显然,这会造成代码的爆炸,同时也不方便大家各司其职(例如:厂商A做Flash,添加一个新的Flash需要厂商A的驱动开发人员去改写所有文件系统的接口,这显然不现实)。

Read more »