CC3200做节点的web服务：1、体系简介（generic）

freebsder写在EEWorld，如需转载可以找 @soso 商量。

CC3200做节点的web服务：2、CC3200环境
CC3200做节点的web服务：3、CC3200 HttpServer

0、 startup

可能EEWorld中大部分电子工程师并不了解单片机之上的技术，以前可以不闻不问不了解，但是面对现在的智能硬件、物联网IoT、大数据、移动互联网、工业4.0、互联网+等大的软硬融合趋势，如果还是只把自己定在一亩三分地上，可能会错过很多机会。这里只是简单介绍，而我个人看法是可以不精通可以不深入，但是要知道要了解，只有了解了才有在需要时按照正确的方向进一步深入的可能。

下面的字没检查正确性，也没过多的考虑完整性，web服务是一个庞大的系统工程，所以这里只是简介，也只能是简介，当吹牛唠嗑吧，轻松一些，有疏忽的地方请见谅。

1、 Node、CC3200

虽然浓缩简写到三个字母的IoT如此火热，可也是建立在整个体系中的采集层与网络层功能上。很明显CC3200是一颗很优秀的网络层节点，同时提供大量外设支持数据采集和反馈。CC3200虽归类到嵌入式、单片机中有它特殊的处理形式和资源配置，但它毕竟是整个IoT技术框架中的一环，一个小角色，它无力改变世界，so它只能适应这个体系而无法改变这个体系。

CC3200应用的核心是那颗协处理器、ROM和功耗控制，如果把那颗coprocessor砍掉之后，CC3200也就是一颗CortexM4，好吧，对一个合格的单片机工程师，也就只剩下coprocessor和它提供的API需要了解一下了。具体的可以参考手册，我就不搬大自然了。

最下层结构：NodeCC3200<----(ADC、I2C、SPI…)---->Sensor/actor

|---->i2c、pwm---->Actor

2、 http、httpserver、webserver、server page

http最基本的模型是客户端发起的无状态协议文本，无状态的意思是server在没有其他技术的帮助下（如session、cookie等）无法区分对面访问它的是人还是猴子，前后两次访问的状态也无法在server中保持；协议指rfc2616族；文本指协议内容，为什么要设计成文本？客户端指browser等根据rfc2616协议族和httpserver交互的客户端；发起是说基本交互模型是一问一答，不问不答，主动沉默。

httpserver、webserver、server page虽然有不小的差异，但指的差不多都是一个玩意：接收http请求，解析请求识别http协议中乱七八糟的参数，根据参数调整状态机、action、response，根据POST和GET请求来填充response body，最后把这些东西填充成http协议再以文本的形式返回给客户端。区别在服务端变量需要调用其他外部应用来处理（如php）的，简单的说是httpserver，如apache，nginx；server page不严格的指java，aspnet这种打包成一个大平台的东西，单独也可以运行，但打包起来自己是一个技术体系；webserver不单纯处理html偏向于把http作为资源处理工具，提供server服务，比如这里的主角CC3200httpserver。

CC3200在这个体系中自然是作为webserver来使用，提供action服务。

现在的结构：

NodeCC3200<----(ADC、I2C、SPI…)---->Sensor

| rom or host |---->i2c、pwm---->Actor

webserver

3、 URI、restful

上面说webserver作为资源处理工具，而http又是主动沉默，所以需要资源的发现机制、发布机制、注册机制、标识机制。URI就是一种资源标识机制。URL是URI的一种实例，另外如果翻看一下CC3200的手册，会发现URN，这也是一种URI实例。具体可以看：http://zh.wikipedia.org/wiki/统一资源标志符 。这些名字的核心是R，resource，资源，也就是说在针对webserver的处理过程中，对服务器的访问，都抽象成对一种资源的访问，这种资源可以是实体资源如一个html文件一个image文件（返回后由浏览器渲染成我们常见的网页），也可以是虚拟资源。需要注意的是虚拟资源在webserver的构架中占据很重要的角色：我们可以拦截资源的访问，动态的处理这种请求。如果观察CC3200 OOB中闪灯的地方会看到它发出的请求是POST http://192.168.1.1/No_content， request body是__SL_Uxxx。你在生成的镜像中找不到No_content这个html页面，而手册中给出的ROM中保留的html也没有，这里就是使用的虚拟资源的概念（文字后面的实例中还会涉及）。

以上对资源的访问形式可以归类为Restful。Restful是一种构架风格，也可以看成是一种RPC，类比于SOAP和XML-RPC。他用标准的http 方法GET，POST，PUT，DELETE访问资源，这不就是对资源最基本的增删查改操作吗？没有错PUT，DELETE只是我们一般在显示html的时候用的很少罢了。简单的说，当我们用http的GET方法访问资源的时候，语义，这里语义很重要，是查找一个资源（和它的内容），用http的POST方法访问资源的时候，是修改一个资源；对应的PUT和DELETE是增加和删除资源。

常见有两种形式使用Restful（只是一种构架风格，所以没有模版格式来限定），一是上面No_content的http request body的形式，一种形式是整个都放在URI里面，如POST http://192.168.1.1/Lighting/LED/1/on，语义是用http协议访问192.168.1.1上的Lighting应用。对这个Web Application的LED资源（虚拟的或实体的），用POST方法访问第1个LED实例，参数是on。这里是否看出一点面向对象编程中应用、抽象、实体的模式？Lighting/LED/1/on这样的行为，在web server中进行解析识别。

好了，这里可以看到CC3200作为一种服务提供者，在它里面如果使用webserver的话，restful的设计模式是最简单也最方便的，因为它是标准http，又是文本解析，又可以过防火墙（一般说来），还可以方便的人工观察和调试，还可以保存到日志备查等等，这也是为什么你在CC3200SDK中浏览的话，会发现它也是按照Resource，Rest的方式构建。

现在的结构：

NodeCC3200<----(ADC、I2C、SPI…)---->Sensor

URI | rom or host |---->i2c、pwm---->Actor

Webserver---->resource actor

4、 html、browser

浏览器和html大家见的多了，就不多说，有一点需要注意的是html是一种语言，用来描述在浏览器中的展示。而浏览器可以简单看着一个功能异常强大的客户端。常见的很多爬虫是简单客户端的例子，它不需要显示界面，只需要依据http协议构造访问，获取response后解析需要爬的材料。

现在的结构：

NodeCC3200<----(ADC、I2C、SPI…)---->Sensor

URI | rom or host |---->i2c、pwm---->Actor

Browser-----(http)---> Webserver---->resource actor

render | | response

<- html <-

5、 javascript

javascript本身就是很庞大的一个技术体系，图书网上搜搜资料的多寡就知道它的量级。所以这里只能涉及可能用到的功能点。

前面说webserver作为资源处理工具，而http又是主动沉默，当你对资源进行处理的时候又不希望把整个html页面做刷新，也就是常说的局部刷新，这时候需要js来处理。当然js自己完成不了这个行为。IE4.0的时候引入的一种叫ajax的机制，就是宿主浏览器暴露一个(组)js对象httprequest，用来填充http协议（注意不一定是按照html来添），访问、解析后返回给js端继续处理。10年前的时候大量的充斥httprequest，而现在更多的是用封装之后的对象，如jquery。你如果查看CC3200 OOB例子的镜像的话，在js目录下可以看到jquery这个工具包，而OOB中刷温度那个例子，也是用jquery来构造。jquery本身也是一个技术，图书网上搜搜资料的多寡也差不多能体会到它的量级。当然也有其他封装，但是jquery用的最多。

现在的结构：

js NodeCC3200<----(ADC、I2C、SPI…)---->Sensor

| < ajax > URI | rom or host |---->i2c、pwm---->Actor

Browser-----(http)---> Webserver---->resource actor

render | | response

<- html <-

6、 other

一般的WebApplication后面是database做业务支撑。然而前面我们看到了Restful的GET，POST，PUT，DELETE，在数据库中对应的操作是SELECT，ALTER，ADD，DELETE四个基本操作。这里再一次看出Resource这个概念的重要性，也可以看出一种情况：虽然我们上了一个CC3200这种高级货，可是它并没有特殊的地方。

现在的结构：

js NodeCC3200<----(ADC、I2C、SPI…)---->Sensor

| < ajax > URI | rom or host |---->i2c、pwm---->Actor

Browser-----(http)---> Webserver---->resource actor

render | | response |----> database

<- html <-

多说一句题外，哪些只搞单片机不过瘾觉得java，andriod工资高的可以看看以上东西了解多少（何况这些东西还只是泛泛而谈，很多还没覆盖）？对java，andriod技术员来说，可能只是不熟悉单片机。

补充一下，还有一种很重要的东西的忘记说了，json，javascript里的一种交互格式，可以看作简单的文本化的map映射，特点是简单，机器好解析，人好看，序列化和反序列化成本低，浏览器端很自然的支持javascript（json就是从javascript中发展出来的），可以把返回的json作为javascript表达式进行直接evaluation，无限的扩展性，良好清晰的内容描述，在大量的形式化验证不严格的场合替代xml作为信息交互格式。CC3200的SDK中有json支持，因为以上说的特点，对于简单的场合可以使用restful，而其他场合推荐使用json交互（作为RPC的交互机制）。太简单了以至于一看就会。

对android有兴趣的同学，json，javascript，URI和webserver也是设计有后台交互能力的android应用基础之一，微信应用开发也是如此，当然你也可以使用原始的二进制通讯，这也可以，只是一个问题的两面。

欣赏

膜拜一下，感觉要学要了解的东西好多。

学习学习