今天是拿到 Arduino 的第一天.. 研究了一晚上这玩意儿，基本上是读这篇文章学来的，重新把写的程序解释一遍，整理下思路。

#include <avr/io.h>
#include <avr/interrupt.h> 
#include "Arduino.h"

#define LED_PIN LED_BUILTIN

void setup() {  
    pinMode(LED_PIN, OUTPUT);

    // set timer interrupts
    cli();

解释一下 cli() ，以及下面的 sei()。

在 Interrupt.h 的注释中，可以看到这两个函数是直接被编译成汇编命令的，字面意思是启用或禁用定时器中断这功能，但是根据在这个帖子的讨论来看，作用应该是防止在设定定时器参数的过程中，其他的线程(?)来干扰设置，姑且我理解成了一种锁之类的东西(不确定对不对)。

    TCCR1A = 0;
    TCCR1B = 0;

TCCRxA 和 TCCRxB 分别控制编号为 x 的定时器的选项。一般的 Arduino 会有 3 个定时器，不过据说一些 AVR 定时器会有额外的三个 16bit 的定时器。

顺便说下几个定时器的用处：

• 0 号定时器是系统默认使用的定时器，loop() 和 millis() 都依赖这个定时器的运转。所以最好不要动 0 号定时器.. 除非你想干一些什么奇怪的事情。啊对了，这个定时器是 8bit 的，也就是说它的最大值是 255 (2^8 - 1)。
• 1 号定时器是 16bit 的，最大值就是 65535 了。这个定时器就是一般供开发者使用的了。
• 2 号定时器基本和 0 号定时器是差不多的，Arduino 的 tone() 函数依赖于这个定时器。

    OCR1A = 15624;

OCR1A 是 CTC 模式下的一个重要参数，不过要先说一下在没有启用 CTC 模式下的运行情况。

在 CTC 模式未启用的情况下，ISR (Interrupt Service Routine 就是处理各种中断事件的服务）只会对定时器触发一个溢出的中断事件。至于溢出，就是上面提到的 8bit 和 16bit 的问题了，每个时钟周期，这些寄存器的值会自增，当自增到满的时候 (255/65535) ，ISR 会触发一个 TIMER1_OVF_vect 的事件，不过，在频率为 16MHz 芯片的运行中，每时钟周期自增一，即使是 16bit 的寄存器，也仅仅需要约 0.0041 秒即可跑完一个定时器周期，触发一次溢出中断。这样的时间太短，远远无法满足现实需要。

为了解决上面的问题，于是引入了 prescaler 这玩意儿，效果就是感觉上像是放慢芯片的运行频率，导致一单位定时器周期变成了原有的 8/64/256/1024 倍(具体如何实现的暂时不明)，这样每定时器周期花费的时间就会变成原先的 8 倍，64 倍，256 倍，1024 倍。也就是说，一单位定时器周期最慢可以达到约 4.194 秒。

但是，在实际应用中，极少的情况下会需要用到 4.194 一秒的定时器，CTC 就是为了解决这个问题，获得更自由的定时器而被引入的。

CTC 的原理很简单，就是每时钟周期比较一下寄存器内的值，看是不是设定的那个值，如果是，则触发一次定时器中断。

但是，我们需要计算寄存器内的值是什么的时候才触发这个中断，计算公式如下：

(目标时间) = (定时器频率) * (定时器计数 + 1)

目标时间：我们这里设置为 1 秒。

定时器频率：在 16 MHz 的芯片中，应该是 1 / (16 * 10^6)，但是在这里设置了 prescaler ，所以需要在此基础上再放慢 1024 倍，即为 1 / (16 * 10^6 / 1024) (6.4e-5 秒)。

所以结果很简单：

(定时器计数) = (目标时间) / (定时器频率) - 1

15624 = 1 / 6.4e-5 - 1

所以，在上面的代码里，我们把 OCR1A 设置为 15624 。

至于为什么要减去一，因为，在 CTC 发现达到预定的值的时候，会把寄存器重设为 0 。虽然在一般情况下，在这里多一少一十分之不明显，但是如果你在做什么十分重视时间的东西的情况下，这个一，就显得会很重要了。

    TCCR1B |= (1 << WGM12);
    TCCR1B |= (1 << CS10);
    TCCR1B |= (1 << CS12);
    TIMSK1 = (1 << OCIE1A);

WGM12 表示设置为 CTC 模式运行。

CS10 和 CS12 一起设置之后表示 prescaler 为 1024 倍。

TIMSKx 似乎是控制了中断事件的触发情况，这个暂时没有了解，OCIE1A 表示了启用 CTC 模式的中断。

    sei();

    Serial.begin(9600);

    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
}

ISR(TIMER1_COMPA_vect)  
{
    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
    Serial.println("triggered!\n");
}

ISR 就是上面提到的 Interrupt Service Routine。

TIMER1_COMPA_vect 表示这个函数是处理定时器一的 CTC 中断事件的。

另外，TIMER1_OVF_vect 是表示处理定时器一的溢出中断事件。

void loop() {  
}

大概是解释清楚了吧，不负责差评不负责退货 XD~

* Cover 照片来自 Arnaud Boudou 的照片，遵循 CC-BY-SA 协议使用。

写入:

nameserver 199.91.73.222

或者

nameserver 178.79.131.110

（根据你的网络 ping 下看看速度..）

设置之后：

sudo killall -HUP mDNSResponder

重启 DNS 服务，即可生效。

基本思路就是在仓库 A 执行 git format-patch <from_sha>...<to_sha> ，然后把得到的 patch 文件再在仓库 B 中通过 git am 进行合并。

然后需要说的一个点是，当进行 git am 的时候，如果发生冲突的解决方法：

在发生冲突的时候， git am 会提示 Patch failed ，并提示把 patch 文件放到了 .git/rebase-apply/patch 中，这时候就需要手工来解决冲突了。

执行 git apply --reject .git/rebase-apply/patch 通过 --reject 选项使在合并冲突的时候自动生成以 .rej 结尾的 patch 文件，里面仅包含了合并冲突时的 diff 信息，通过查看这个文件可以知道哪几处出了问题，手工解决它，然后 git add。

这里有一个小坑就是在解决完冲突之后记得检查下 git status 中的其他文件，成功被合并的文件不会生成 .rej 文件，但是也不会被自动添加到 Stage Area ，所以要记得把这些文件也 add 进去。

搞定冲突之后，git am --resolved 就完整的把 Commit 给转过来了~