一、Mico开发环境的搭建

Mico开发环境由三部分组成，

1. Mico Cube ： 用于在命令行下对mico-os 编译链接下载，以及对mico-os进行版本管理的工具， 这是个python工具，所以需要使用pip install mico-cube 进行安装，并且需要在环境中安装git，以用于版本管理和os的import。

2. Micoder：用于编译链接的组件，提供的gcc、gdb等交叉编译调试工具链： 这个需要和mico Cube配合使用，下载解压后， 需要使用 mico config --global micoder D:\MXCHIP\MiCO_SDK\MiCO\MiCoder 进行配置，使得mico可以调用micoder，进行编译，链接，下载。 否则会报错[mico]: can not found micoder

3. Micoder IDE：用于在图形环境下进行版本管理，开发，还可以进行调试。 需要java运行环境，并且设置好path系统环境参数。 在安装Micoder IDE时会自动附带安装一个mico-os的sdk，

二、AZ3166对应mico-os的配置

在你的项目文件夹下通过命令 mico import mico-demos 从aliyun的git上下载一最新的demos和os

从eclipse中导入mico-demos， 右键根项目(mico-demos) Team->Switch To->Other : Remote Tracking->origin/experiment 右键mico-os：Team->Switch To->Other : Remote Tracking->origin/mico-os-4.0

三、Build Targets

添加编译命令可编译运行下载：

application.wifi_uart@AZ3166 total download run JTAG=stlink-v2-1

这里对解释一下编译命令：

@前面的部分代表要编译的程序所在文件夹，用.代替\表示文件目录的结构层次。

@后面的部分代表要编译使用的板子库型号。

最后，Eclipse IDE，会组合成命令：

mico make application.wifi_uart@AZ3166 total download run JTAG=stlink-v2-1

并在因为只有在根目录中，才能同时相对的找到mico-os和其相关的库文件和程序，否则会报找不到mico-os等等编译错误。

四、添加AZ3166驱动组件

在一个现有的MiCO项目中添加AZ3166组件，并运行附带的示例程序。在进行以下操作之前，先确保MiCO Cude已经正确安装。 导入AZ3166组件

进入一个MiCO项目的根目录，例如：cd helloworld。（如果本地没有现成的MiCO项目，可以使用mico new xxx创建一个项目,或者使用mico import xxx从版本库导入一个项目），
执行指令：mico add https://code.aliyun.com/mico/drv_AZ3166.git，从远程版本库中下载组件并且添加到当前项目。

运行AZ3166示例

1.组件中内置示例程序：drv_AZ3166/demo，执行编译命令。

例如在MXCHIP Microsoft Azure IoT Developer Kit平台AZ3166上：

mico make drv_AZ3166.demo@AZ3166@RTX total download JTAG=stlink-v2-1 run

详细的编译选项参考MiCO Cude

2.程序运行后，在设备OLED显示屏上显示传感器信息，并且在设备串口终端上显示传感器信息，例如：

50885 humidity = 52.90%, temp = 31.30C
50892 magnet =     84,    193,   -207
50899 lps22hb tmep = 32.00C, press = 1010.00hPa
50907 LSM6DSL [acc/mg]:       26,    -104,    1011
50915 LSM6DSL [gyro/mdps]:        0,   -1680,    1260

午睡的时候，朋友发来个题，反正闲也闲着，来练练手。

#1 查壳

拿到程序先确认使用的是什么编译器，什么环境下运行，以决定用何种工具。

程序无花无壳，直接上IDA静态了，CTF的题在实机调比较方便。

在CMS中，tag和categoly的实现方式虽大体相同，但功能和用途却不同。

而当前各种Pages服务仅支持有限的官方插件，自定义插件功能更是可望而不可及，要满足文章自动分类功能实在要用插件完成，之前一直通过本地生成jekyll的方式进行部署。

近日在开发awesom-weblog的时候发现一种不用插件的方法来生成不同的分类的页面。

在不使用自定义插件的情况下，让Jekyll支持文章分类

一、分类页渲染模版(Layout)

由插件版到无插件的迁移会比较简单，已经有存在了分类页文章渲染模版(Layout)，无模块的可以参考首页模版进行修改。

示例（categoly.html）如下：

<div id="content">
	  <div class="box archive-meta">
        <h3 class="title-meta"></h3>
      </div>
    

</div>

这里用到的是site全局中的categories属性，该属性以字典的形式存储了所有分类，以及该分类下的post。

比如：我们只需要通过调用site.categories['Linux']便可以拿到该分类下的所有文章。

二、为分类创建分类页而

在layout已经创建好之后， 我们只需要通过该Layout对每个分类进行渲染，而渲染的方法，就是通过创建多个Layout的实现，使其传入不同的page.cat参数，便可生成不同的分类页面了。

一个Layout的实现如下：

添加categories目录，并在目录下创建一个名为Linux.html的文件：

---
layout: category
cat: Linux
---

此实现只需传入分类名无需带任何content，其它分类同样创建不同分类名文件，并传入分类名。

此外，可通过添加permalink:参数自定义目录生成的链接位置。

三、自动创建分类页面

由于分类页面实在简单，但如果分类较多的话，可能通过批量命令的方式，创建页面。

首先获取到博客的分类列表，形成txt文档，每行一个。

在categories目录下创建bash程序autogencat.sh：

#!/bin/bash

while read catname
do
	cp Linux.html $catname.html
	sed -i "s/Linux/${catname}/g"  ${catname}.html
done

添加执行权限并且执行：

chmod +x autogencat.sh
./autogencat.sh < catlist.txt

程序会将Linux.html做为生成模板，复制生成其它分类文件，以后新增分类只需要更新catlist.txt目录列表，运行脚本即可。

每次程序启动之后，可以正常运行，但reset之后，会运行out of box 程序

通过uniflash工具，删除 /sys/下的bin文件 参考 https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/625681

provisioning的时候，可以连上simplelink的wifi，但是在checking if device is simplelink的时候显示失败，原因不明。

通过在安卓手机上使用logcat显示smartconfig日志，发现程序访问了，mysimplelink.net这个域名，并且无法解析这个域名。

所以恍然大悟发现自己使用了影梭vpn，将会使用我的代理进行DNS解析，由于这是个本地域名，需要使用板载dns服务器。

此外，还发现,板载的HTTP服务器还提供，RESTful API接口，可以对通过POST对芯片配网等参数进行修改。

让cc3220自动连接Wifi。

成功配网后，串口调试信息显示： [Provisioning] Profile Added: SSID: LanBing’s_Wiki-Free [Provisioning] Profile confirmation: WLAN Connected! [Provisioning] Profile confirmation: IP Acquired!

但reset之后，设备不会自动使用保存的密码进行连接。

原因是cc3220的连接策略有四种选项组合：

1. Auto
2. Fast
3. AnyP2P
4. Auto Provisioning

其中Auto Provisioning就是在设备启动之后自己进行连接。

详见文档SWRU455E3.3.3.1节。

这里有三种方式可以对策略进行修改：

1. 调用库函数： sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION,SL_WLAN_CONNECTION_POLICY(1,1,0,1),NULL,0);
2. POST RESTful API： POST /api/1/wlan/policy_set HTTP/1.1 Host: mysimplelink.net Content-Type: application/x-www-form-urlencoded __SL_P_P.E=&__SL_P_P.F= 详见文档 SWRU455E 节8.4.7
3. 通过SimpleLink Uniflash工具设置。

github pages服务由于安全性的考虑，对其原生jekyll的支持插件进行了过滤。使得只能使用其有限的插件，而且无法使用自定义的插件。这导致了很多问题，比如不能按自己的规则生成归档文件或者分类目录，甚至部署爬虫之类等等。

具体详见: https://pages.github.com/versions/

而国内几大git服务商（Coding，码市之类），也对支持的插件进行了限制，所以在多数情况下，还是选择在本地搭建Jekyll环境，生成静态页面直接上传。

但这极大限制了Jekyll的Markdown in Anywhere便利性，需要在不同的系统上都装上Jekyll的开发环境。

##　现在讨论一种利用中间生产服务器代替本地发布过程的方法。

依赖：一台部署gh-hooks-server的VPS

既然选择不使用git的原生jekyll，也那么需要两个branch， 一个用于jekyll源码的存放， 一个用于托管静态代码

通过一台中间服务器，当源branch进行了更新，则通过webhook自动通知gh-hooks-server，使其执行pull、push操作。

VPS的jekyll环境的搭建不再赘述【首先安装rvm，ruby, 再装jekyll以及插件比如jekyll-paginate】

下面演示安装gh-hooks-server并启动

git clone https://github.com/c834606877/gh-hooks-server.git
cd gh-hooks-server
python setup.py install

ghhooks -a updatemypre:/home/lanbing/updatemypre.sh --secret s3cret

 

程序启动后会侦听8011端口，处理http://0.0.0.0:8011/ghhooks/updatemypre的请求信息，当请求密码通过后，执行对应的bash脚本。

故，我们只需要对源Branch的push消息发送webhook，当gh-hooks-server接收收post消息后，pull 源 Branch，jekyll编译，然后push到Pages Branch。

为了兼容手动发布，编写了一个makefile，用于本地自动发布的脚本：

temp-folder = /tmp/jekyll-temp-site/
repo = git@git.coding.net:iziy/iziy.git

JEKYLL = jekyll

s:
        ${JEKYLL} server
build:
        ${JEKYLL} build -d ${temp-folder}

deploy: build
        cd ${temp-folder} ;\
        git init ${temp-folder} ;\
        git checkout -b coding-pages ;\
        git remote add origin ${repo} ;\
        git add -A ${temp-folder} ;\
        git commit -m "deployed by make" ;\
        git push origin coding-pages --force

push:
        git add -A
        git commit -m "pushed by make"
        git push


clean:
        rm -rf ${temp-folder}

而对于webhook响应的脚本为updatemypre.sh:

#!/usr/bin/bash

echo "webhook enter!"

source /usr/local/rvm/scripts/rvm

cd iziy
git pull
make deploy

自从换上轻量级的桌面管理器DWM之后，屏幕利用率得到了提升。但是，由于在dwm仅仅是一个桌面管理器，并不具备其它一些实用功能，比如Ubuntu的NightMode，控制中心等，只有在Gnome环境下才能使用。

之前使用 CustomXSession,调用/etc/X11/Xsession，接着调用~/.xsesseion脚本启动dwm，比如ibus,gtk,相关的配置均在用户目录下的.xsession脚本中完成。

而现在通过gnome-session --session=dwm-gnome方式调用dwm-gnome脚本，由dwm-gnome调用dwm启动，此外，在 /usr/share/gnome-session/sessions/下建立同名session文件，模仿gnome.session，填写RequiredComponents，并且去除org.gnome.Shell，这些组件的启动将会由Gnome-Session进行统一启动管理。

自动安装方案在ArchLinux下有相应关的包可供下载:

pacman -S dwm-gnome

Ubuntu 可以通过Makefile进行安装:

dwm-gnome: https://github.com/palopezv/dwm-gnome

由于Ubuntu非LTS版，官方维护周期为9个月，遂更新了Ubuntu从17.04到17.10。

然而更新之后Gnome的桌面管理器（GDM），主题被修改成了类Ubuntu风格橘红色。

这种奇葩的风格，也许只有Ubuntu的创始者们才喜欢吧。

最初想法是寻找到gnome-look上找到原版gdm主题，果然发现了很多好看的主题，类XP，类WIN789，类osx。但花虽美，却不是我想要的。

随着google一通之后，发现解决方案也简单，

sudo update-alternatives --config gdm3.css
There are 2 choices for the alternative gdm3.css (providing /usr/share/gnome-shell/theme/gdm3.css).

  Selection    Path                                          Priority   Status
------------------------------------------------------------
* 0            /usr/share/gnome-shell/theme/ubuntu.css        10        auto mode
  1            /usr/share/gnome-shell/theme/gnome-shell.css   5         manual mode
  2            /usr/share/gnome-shell/theme/ubuntu.css        10        manual mode

Press <enter> to keep the current choice[*], or type selection number:

GDM在/etc/alternatives/目录下有设置了一些可选项，其中就包括了控制gnome-shell主题的配置选项，而更新的Ubuntu只是新增了该选项，并增加了优先级。

如此，可以比较方便的通过update-alternatives命令来修改gdm主题了。

参考

Ubuntu GNOME Shell in Artful: Day 11