哈爸陪你問 - 如何成為 open hardware maker (LinkIt Smart 7688篇) - Q&A
編輯歷史
| 時間 | 作者 | 版本 |
|---|---|---|
| 2015-12-25 14:49 – 14:52 | r3888 – r3941 | |
顯示 diff（121 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
+ *真的，有貨就要趕快先買起來，不然 Seeed 總是在 out of stock XD
*如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是需要的
*
（31 行未修改）
*
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+ upm 有打算在 0.5 版本支援 (目前是 0.4.1)，屆時我們可以看看
（92 行未修改）
|
||
| 2015-12-25 14:07 – 14:07 | r3873 – r3887 | |
顯示 diff（249 行未修改）
Q3: (果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去。
+ 外差 usb 做法可參考上面的：https://gist.github.com/iamblue/00f0c5cf6e987f1b7834
|
||
| 2015-12-25 14:01 – 14:01 | r3865 – r3872 | |
顯示 diff（247 行未修改）
應該是不支持此功能，請問大概在什麼樣的場景下面使用呢？（不然就是再插一個wi-fi dongle....）
- Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ Q3: (果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去。
|
||
| 2015-12-25 13:52 – 13:54 | r3837 – r3864 | |
顯示 diff（190 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好幫手1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ *iCShop真是maker好幫手1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（42 行未修改）
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
by the way,即時不等於throughput.我是認為先用UART,真的沒有辦法了再換
+ *好的，我只是之前有些誤會了。
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3836 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,真的沒有辦法了
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有辦法了再換
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3835 | |
顯示 diff（238 行未修改）
by the way,即時不等於throughput.我是認為先用UART,真的沒有辦法了
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
-
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（8 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3833 – r3834 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,真的沒有半
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有辦法了
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
（10 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3831 – r3832 | |
顯示 diff（251 行未修改）
|
||
| 2015-12-25 13:52 | r3830 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,真的沒有辦喇
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有半
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
（10 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3828 – r3829 | |
顯示 diff（238 行未修改）
by the way,即時不等於throughput.我是認為先用UART,真的沒有辦喇
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
- Ｄ月
+
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（8 行未修改）
|
||
| 2015-12-25 13:52 | r3827 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,真的沒有半ㄌㄚ
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有辦喇
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
Ｄ月
（10 行未修改）
|
||
| 2015-12-25 13:52 | r3826 | |
顯示 diff（238 行未修改）
by the way,即時不等於throughput.我是認為先用UART,真的沒有半ㄌㄚ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
- Ｄ
+ Ｄ月
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（8 行未修改）
|
||
| 2015-12-25 13:52 | r3825 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,真的沒有半
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有半ㄌㄚ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
Ｄ
（10 行未修改）
|
||
| 2015-12-25 13:52 | r3824 | |
顯示 diff（238 行未修改）
by the way,即時不等於throughput.我是認為先用UART,真的沒有半
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
-
+ Ｄ
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（8 行未修改）
|
||
| 2015-12-25 13:52 | r3823 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為先用UART,
+ by the way,即時不等於throughput.我是認為先用UART,真的沒有半
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
（10 行未修改）
|
||
| 2015-12-25 13:52 | r3822 | |
顯示 diff（238 行未修改）
by the way,即時不等於throughput.我是認為先用UART,
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
+
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（8 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3815 – r3821 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為
+ by the way,即時不等於throughput.我是認為先用UART,
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3814 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去‧
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去。
|
||
| 2015-12-25 13:52 | r3813 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.我是認為ㄖㄩㄥˋ
+ by the way,即時不等於throughput.我是認為
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3812 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去‧
|
||
| 2015-12-25 13:52 – 13:52 | r3807 – r3811 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.
+ by the way,即時不等於throughput.我是認為ㄖㄩㄥˋ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3805 – r3806 | |
顯示 diff（250 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3802 – r3804 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.nji3u3
+ by the way,即時不等於throughput.
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3801 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享ＥＥＩ
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享出去
|
||
| 2015-12-25 13:52 | r3800 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.n
+ by the way,即時不等於throughput.nji3u3
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3799 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享ＥＥＩ
|
||
| 2015-12-25 13:52 | r3798 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.
+ by the way,即時不等於throughput.n
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3795 – r3797 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分熟
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分享
|
||
| 2015-12-25 13:52 | r3794 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput..
+ by the way,即時不等於throughput.
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3791 – r3793 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，ＢＮ
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，分熟
|
||
| 2015-12-25 13:52 | r3790 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput.
+ by the way,即時不等於throughput..
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3789 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，ＢＮ
|
||
| 2015-12-25 13:52 | r3788 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於throughput
+ by the way,即時不等於throughput.
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3787 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一張USB網卡
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡，
|
||
| 2015-12-25 13:52 | r3786 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等於
+ by the way,即時不等於throughput
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3782 – r3785 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一ＱＥ
+ 目前看到的做法是自已連別的AP，然後再裝一張USB網卡
|
||
| 2015-12-25 13:52 | r3781 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時不等
+ by the way,即時不等於
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3780 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝一
+ 目前看到的做法是自已連別的AP，然後再裝一ＱＥ
|
||
| 2015-12-25 13:52 – 13:52 | r3778 – r3779 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時補等
+ by the way,即時不等
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3777 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再裝
+ 目前看到的做法是自已連別的AP，然後再裝一
|
||
| 2015-12-25 13:52 | r3776 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時補ㄉ
+ by the way,即時補等
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3775 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後再
+ 目前看到的做法是自已連別的AP，然後再裝
|
||
| 2015-12-25 13:52 – 13:52 | r3773 – r3774 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時
+ by the way,即時補ㄉ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3772 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後ＥＮ
+ 目前看到的做法是自已連別的AP，然後再
|
||
| 2015-12-25 13:52 | r3771 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時1j
+ by the way,即時
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3770 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，然後
+ 目前看到的做法是自已連別的AP，然後ＥＮ
|
||
| 2015-12-25 13:52 – 13:52 | r3768 – r3769 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,即時
+ by the way,即時1j
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3766 – r3767 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做法是自已連別的AP，
+ 目前看到的做法是自已連別的AP，然後
|
||
| 2015-12-25 13:52 | r3765 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way,
+ by the way,即時
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3758 – r3764 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做ＷＹ
+ 目前看到的做法是自已連別的AP，
|
||
| 2015-12-25 13:52 | r3757 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the way
+ by the way,
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3756 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的做
+ 目前看到的做ＷＹ
|
||
| 2015-12-25 13:52 | r3755 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the w
+ by the way
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3754 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前看到的
+ 目前看到的做
|
||
| 2015-12-25 13:52 | r3753 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by the
+ by the w
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3751 – r3752 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前ＨＭＯ
+ 目前看到的
|
||
| 2015-12-25 13:52 | r3750 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- by t
+ by the
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3749 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目前
+ 目前ＨＭＯ
|
||
| 2015-12-25 13:52 | r3748 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- b
+ by t
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3747 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目ＢＥＵ
+ 目前
|
||
| 2015-12-25 13:52 | r3746 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- bt
+ b
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3745 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- 目
+ 目ＢＥＵ
|
||
| 2015-12-25 13:52 | r3744 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- b
+ bt
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 | r3743 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ 目
|
||
| 2015-12-25 13:52 | r3742 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- bt
+ b
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:52 | r3741 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- M
|
||
| 2015-12-25 13:52 | r3740 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- bty
+ bt
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:52 – 13:52 | r3738 – r3739 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- MO B
+ M
|
||
| 2015-12-25 13:51 | r3737 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
- b
+ bty
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3736 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- M
+ MO B
|
||
| 2015-12-25 13:51 | r3735 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
-
+ b
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3734 | |
顯示 diff（247 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ M
|
||
| 2015-12-25 13:51 | r3733 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
+
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 | r3732 | |
顯示 diff（248 行未修改）
|
||
| 2015-12-25 13:51 | r3731 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上76
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7688
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 | r3730 | |
顯示 diff（248 行未修改）
|
||
| 2015-12-25 13:51 | r3729 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上76
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 | r3728 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- Ｒ
|
||
| 2015-12-25 13:51 – 13:51 | r3726 – r3727 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接ㄐ
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接接上7
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3725 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ Ｒ
|
||
| 2015-12-25 13:51 | r3724 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議ㄓ
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議直接ㄐ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 – 13:51 | r3722 – r3723 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- Ｋ
|
||
| 2015-12-25 13:51 | r3721 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議ㄓ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3720 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ Ｋ
|
||
| 2015-12-25 13:51 | r3719 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會ㄐ
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會建議
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 | r3718 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- Ｉ二
|
||
| 2015-12-25 13:51 | r3717 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會ㄐ
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3716 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
- Ｉ
+ Ｉ二
|
||
| 2015-12-25 13:51 | r3715 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,我會
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（9 行未修改）
|
||
| 2015-12-25 13:51 | r3714 | |
顯示 diff（246 行未修改）
Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
+ Ｉ
|
||
| 2015-12-25 13:51 – 13:51 | r3712 – r3713 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要回傳的話,
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:51 | r3711 | |
顯示 diff（248 行未修改）
|
||
| 2015-12-25 13:51 – 13:51 | r3708 – r3710 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去,而且有那麼大量的資料要
另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（8 行未修改）
|
||
| 2015-12-25 13:47 – 13:49 | r3658 – r3707 | |
顯示 diff（244 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
應該是不支持此功能，請問大概在什麼樣的場景下面使用呢？（不然就是再插一個wi-fi dongle....）
+
+ Q3: ()不確定是否Q29問錯問題如果想7688要像小米Mini AP那樣，透過Wifi連上別的AP，然後自己再當AP分享出來，要怎麼做呢？
|
||
| 2015-12-25 13:46 – 13:46 | r3649 – r3657 | |
顯示 diff（243 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問大概在什麼樣的場景下面使用呢？
+ 應該是不支持此功能，請問大概在什麼樣的場景下面使用呢？（不然就是再插一個wi-fi dongle....）
|
||
| 2015-12-25 13:42 – 13:46 | r3584 – r3648 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
- 走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ 走UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃throughput,而且即時反應應該是MCU端就要處裡那些Data,而不是往後送給7688處裡再丟回去
+ 另外還有占用SPI對Flash的問題..基本上這張板子的接線方式是SPI Slave接到MCU,所以MCU要回傳資料...用SPI會有點麻煩
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 – 13:42 | r3574 – r3583 | |
顯示 diff（239 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500mA了
+ 建議要外接電源，我有看過OTG一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500mA了
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問大概在什麼樣的ㄔ
+ 應該是不支持此功能，請問大概在什麼樣的場景下面使用呢？
|
||
| 2015-12-25 13:42 | r3573 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃CPx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3572 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問大概在什麼樣的賞獎
+ 應該是不支持此功能，請問大概在什麼樣的ㄔ
|
||
| 2015-12-25 13:42 | r3571 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃CPUx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃CPx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3570 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問大概在什麼樣的賞
+ 應該是不支持此功能，請問大概在什麼樣的賞獎
|
||
| 2015-12-25 13:42 | r3569 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃Cx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃CPUx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3568 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問大概在什麼樣的
+ 應該是不支持此功能，請問大概在什麼樣的賞
|
||
| 2015-12-25 13:42 | r3567 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃Cx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3566 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，請問
+ 應該是不支持此功能，請問大概在什麼樣的
|
||
| 2015-12-25 13:42 – 13:42 | r3562 – r3565 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那應該也x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那會很吃x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3561 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 應該是不支持此功能，
+ 應該是不支持此功能，請問
|
||
| 2015-12-25 13:42 – 13:42 | r3559 – r3560 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,那x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那應該也x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 – 13:42 | r3556 – r3558 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
+ 應該是不支持此功能，
|
||
| 2015-12-25 13:42 | r3555 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,那x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3554 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- ㄧ
|
||
| 2015-12-25 13:42 – 13:42 | r3552 – r3553 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3551 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
+ ㄧ
|
||
| 2015-12-25 13:42 | r3550 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度<x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3549 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
- 惡
|
||
| 2015-12-25 13:42 | r3548 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用到那麼快的速度<jx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度<x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:42 | r3547 | |
顯示 diff（242 行未修改）
Q29: 7688 同時 AP / Station Mode有時程表嗎？
+ 惡
|
||
| 2015-12-25 13:42 – 13:42 | r3534 – r3546 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
- UART就好,這速度也不慢,如果真的要用這種x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用到那麼快的速度<jx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3533 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩了
走
UART就好,這速度也不慢,如果真的要用這種x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 | r3532 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩
走
- UART就好,這速度也不慢,如果真的要用這ㄓㄨㄥx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用這種x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3531 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻煩
走
UART就好,這速度也不慢,如果真的要用這ㄓㄨㄥx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 | r3530 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻
走
- UART就好,這速度也不慢,如果真的要用ㄓx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用這ㄓㄨㄥx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3529 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要麻
走
UART就好,這速度也不慢,如果真的要用ㄓx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 | r3528 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要
走
- UART就好,這速度也不慢,如果真的要x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要用ㄓx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3527 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必要
走
UART就好,這速度也不慢,如果真的要x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 | r3526 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必
走
- UART就好,這速度也不慢,如果真的x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的要x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3525 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必脫
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必
走
UART就好,這速度也不慢,如果真的x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 – 13:42 | r3523 – r3524 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必脫
走
- UART就好,這速度也不慢,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,如果真的x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 – 13:42 | r3521 – r3522 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒必脫
走
UART就好,這速度也不慢,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 – 13:42 | r3517 – r3520 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒
走
- UART就好,這速度也x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也不慢,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3516 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實ＷＲ
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實沒
走
UART就好,這速度也x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:42 | r3515 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實ＷＲ
走
- UART就好,這素ㄉx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這速度也x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:42 | r3514 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＭ
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其實ＷＲ
走
UART就好,這素ㄉx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3513 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＭ
走
- UART就好,這x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這素ㄉx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3512 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＭ
走
UART就好,這x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3511 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其
走
- UART就好,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,這x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3509 – r3510 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＢＭ
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其
走
UART就好,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3508 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＢＭ
走
- UART就好x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好,x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3506 – r3507 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，其ＮＯＢＭ
走
UART就好x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3504 – r3505 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，
走
- UARTx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UART就好x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3503 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發，
走
UARTx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3502 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發
走
- UAx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UARTx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3501 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開發
走
UAx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3500 | |
顯示 diff（236 行未修改）
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開
走
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ UAx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3498 – r3499 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDU
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDUINO開
走
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
（5 行未修改）
|
||
| 2015-12-25 13:41 | r3497 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDU
+ 走
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3496 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用A
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用ARDU
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3495 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用A
- yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3494 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以用
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用A
yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3493 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以用
- y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3492 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可以
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以用
y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3491 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可以
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3490 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO可
+ 所以SPI可能才是最快的選擇，哈，不過DUO可以
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3489 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO可
- 有x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3488 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過DUO
+ 所以SPI可能才是最快的選擇，哈，不過DUO可
有x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3487 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過DUO
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ 有x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3486 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過D
+ 所以SPI可能才是最快的選擇，哈，不過DUO
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3485 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過D
- yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3484 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不過
+ 所以SPI可能才是最快的選擇，哈，不過D
yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3483 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不過
- y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ yx另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 | r3482 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
- 所以SPI可能才是最快的選擇，哈，不
+ 所以SPI可能才是最快的選擇，哈，不過
y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3481 | |
顯示 diff（235 行未修改）
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
所以SPI可能才是最快的選擇，哈，不
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
+ y.x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（3 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3460 – r3480 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
-
+ 所以SPI可能才是最快的選擇，哈，不
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3459 | |
顯示 diff（243 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3452 – r3458 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是
+ 謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是High Speed Operation (fXCKmax = fCK/2)
+
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3451 | |
顯示 diff（242 行未修改）
|
||
| 2015-12-25 13:41 – 13:41 | r3439 – r3450 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了DATASHEET，我
+ 謝謝，剛剛K完了DATASHEET，我發現走SPI最高可以是
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3438 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500mA
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500mA了
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:41 | r3437 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了DATASHEET，後
+ 謝謝，剛剛K完了DATASHEET，我
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3436 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500m
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500mA
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:41 | r3435 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了DATASHEET，Ｉ
+ 謝謝，剛剛K完了DATASHEET，後
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3434 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近5
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近500m
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:41 | r3433 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了DATASHEET，事
+ 謝謝，剛剛K完了DATASHEET，Ｉ
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:41 | r3432 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近5
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 – 13:41 | r3419 – r3431 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了
+ 謝謝，剛剛K完了DATASHEET，事
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3418 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接ㄒㄧ
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接近
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3417 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了，
+ 謝謝，剛剛K完了
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3416 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接ㄒㄧ
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3415 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K完了
+ 謝謝，剛剛K完了，
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3414 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3413 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛KＮＲ
+ 謝謝，剛剛K完了
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3412 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接信
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3411 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛K
+ 謝謝，剛剛KＮＲ
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3410 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接信
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3409 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛剛
+ 謝謝，剛剛K
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3408 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接信
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3407 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛
+ 謝謝，剛剛
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3406 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到街ㄒㄧㄣ
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到接信
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3405 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛N
+ 謝謝，剛
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3404 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到街ㄒㄧㄣ
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3403 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛NBER
+ 謝謝，剛N
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3402 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會到
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3401 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛NBER
+ 謝謝，剛NBER
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3400 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就ㄏㄨ
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就會
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3399 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛
+ 謝謝，剛NBER
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3398 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就ㄏㄨ
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3397 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，剛ＮＥＲ
+ 謝謝，剛
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 – 13:40 | r3395 – r3396 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身p
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身peak就
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3394 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝謝，ＮＢ
+ 謝謝，剛ＮＥＲ
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3393 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身p
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 – 13:40 | r3391 – r3392 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝
+ 謝謝，ＮＢ
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3390 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688本身
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3389 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝小
+ 謝
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3388 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7688
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3387 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- 謝
+ 謝小
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3386 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟7
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3385 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
-
+ 謝
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3384 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。ㄅㄧ
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。畢竟
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3383 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- NBE
+
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3382 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。ㄅㄧ
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3381 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- NBER NBE
+ NBE
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3380 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的。
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3379 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- NBER N
+ NBER NBE
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3378 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源盡
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源進去的
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3377 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- NB
+ NBER N
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3376 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源盡
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3375 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
-
+ NB
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 | r3374 | |
顯示 diff（237 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有看過OTA一接三，然後有留一個孔
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔可以從外面灌電源
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3373 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
+
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
（4 行未修改）
|
||
| 2015-12-25 13:40 – 13:40 | r3368 – r3372 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我有ㄎㄢ
+ 建議要外接電源，我有看過OTA一接三，然後有留一個孔
Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 | r3367 | |
顯示 diff（238 行未修改）
建議要外接電源，我有ㄎㄢ
- Q29: 7688 同時 AP / Station Mode有時程表嗎
+ Q29: 7688 同時 AP / Station Mode有時程表嗎？
|
||
| 2015-12-25 13:40 – 13:40 | r3363 – r3366 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我ㄩㄥ
+ 建議要外接電源，我有ㄎㄢ
Q29: 7688 同時 AP / Station Mode有時程表嗎
|
||
| 2015-12-25 13:40 | r3362 | |
顯示 diff（238 行未修改）
建議要外接電源，我ㄩㄥ
- Q29: 7688 同時 AP / Station Mode有時程表
+ Q29: 7688 同時 AP / Station Mode有時程表嗎
|
||
| 2015-12-25 13:40 | r3361 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我ㄧ
+ 建議要外接電源，我ㄩㄥ
Q29: 7688 同時 AP / Station Mode有時程表
|
||
| 2015-12-25 13:40 | r3360 | |
顯示 diff（238 行未修改）
建議要外接電源，我ㄧ
- Q29: 7688 同時 AP / Station Mode有時程
+ Q29: 7688 同時 AP / Station Mode有時程表
|
||
| 2015-12-25 13:40 | r3359 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源，我
+ 建議要外接電源，我ㄧ
Q29: 7688 同時 AP / Station Mode有時程
|
||
| 2015-12-25 13:40 | r3358 | |
顯示 diff（238 行未修改）
建議要外接電源，我
- Q29: 7688 同時 AP / Station Mode有
+ Q29: 7688 同時 AP / Station Mode有時程
|
||
| 2015-12-25 13:40 | r3357 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接電源
+ 建議要外接電源，我
Q29: 7688 同時 AP / Station Mode有
|
||
| 2015-12-25 13:40 | r3356 | |
顯示 diff（238 行未修改）
建議要外接電源
- Q29: 7688 同時 AP / Station Mode
+ Q29: 7688 同時 AP / Station Mode有
|
||
| 2015-12-25 13:40 – 13:40 | r3354 – r3355 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接店元，
+ 建議要外接電源
Q29: 7688 同時 AP / Station Mode
|
||
| 2015-12-25 13:40 | r3353 | |
顯示 diff（238 行未修改）
建議要外接店元，
- Q29: 7688 同時 AP / Station M
+ Q29: 7688 同時 AP / Station Mode
|
||
| 2015-12-25 13:40 | r3352 | |
顯示 diff（236 行未修改）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
- 建議要外接店元
+ 建議要外接店元，
Q29: 7688 同時 AP / Station M
|
||
| 2015-12-25 13:40 | r3351 | |
顯示 diff（238 行未修改）
建議要外接店元
- Q29: 7688 同時 AP / Station
+ Q29: 7688 同時 AP / Station M
|
||
| 2015-12-25 13:40 – 13:40 | r3349 – r3350 | |
顯示 diff（235 行未修改）
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
-
+ 建議要外接店元
Q29: 7688 同時 AP / Station
|
||
| 2015-12-25 13:40 | r3348 | |
顯示 diff（238 行未修改）
- Q29: 7688 同時 AP / Station
+ Q29: 7688 同時 AP / Station
|
||
| 2015-12-25 13:40 – 13:40 | r3344 – r3347 | |
顯示 diff（241 行未修改）
|
||
| 2015-12-25 13:40 | r3343 | |
顯示 diff（238 行未修改）
- Q29: 7688 同時AP / Station
+ Q29: 7688 同時 AP / Station
|
||
| 2015-12-25 13:40 | r3342 | |
顯示 diff（235 行未修改）
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
+
（1 行未修改）
|
||
| 2015-12-25 13:40 | r3341 | |
顯示 diff（237 行未修改）
- Q29: 7688 AP / Station
+ Q29: 7688 同時AP / Station
|
||
| 2015-12-25 13:40 | r3340 | |
顯示 diff（235 行未修改）
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
+
Q29: 7688 AP / Station
|
||
| 2015-12-25 13:39 – 13:39 | r3326 – r3339 | |
顯示 diff（235 行未修改）
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
+
+ Q29: 7688 AP / Station
|
||
| 2015-12-25 13:39 – 13:39 | r3321 – r3325 | |
顯示 diff（237 行未修改）
|
||
| 2015-12-25 13:38 – 13:38 | r3310 – r3320 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guide http://labs.mediatek.com/fileMedia/download/87c801b5-d1e6-4227-9a29-b5421f2955ac#page=68
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART，還有幾隻GPIO接著。可以參照Developer's Guide http://labs.mediatek.com/fileMedia/download/87c801b5-d1e6-4227-9a29-b5421f2955ac#page=68
*好的謝謝
m
（10 行未修改）
|
||
| 2015-12-25 13:38 – 13:38 | r3305 – r3309 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
- !Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的
+ !Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的OTA線能用嗎？
|
||
| 2015-12-25 13:37 – 13:37 | r3301 – r3304 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡ISR（但這樣比較容易搞爛系統...）
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux kernel driver來佔用ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的
|
||
| 2015-12-25 13:37 | r3300 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡ISR（但這樣比較容易搞爛系統...）
- !Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三
+ !Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三的
|
||
| 2015-12-25 13:37 | r3299 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR（但這樣比較容易搞爛系統...）
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡ISR（但這樣比較容易搞爛系統...）
!Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三
|
||
| 2015-12-25 13:37 – 13:37 | r3288 – r3298 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR（但這樣比較容易搞爛系統...）
- !Q28: 7688的USB Host若要接一個以上的device，是否大部分要外接電源
+ !Q28: 7688的USB Host若要接一個以上的device，是否大部分要接有外接電源hub? 市面上有看到一接三
|
||
| 2015-12-25 13:37 – 13:37 | r3277 – r3287 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外接電源
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR（但這樣比較容易搞爛系統...）
+ !Q28: 7688的USB Host若要接一個以上的device，是否大部分要外接電源
|
||
| 2015-12-25 13:37 – 13:37 | r3275 – r3276 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外ㄐㄧ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外接電源
|
||
| 2015-12-25 13:37 | r3274 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住I!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外ㄐㄧ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住ISR!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外ㄐㄧ
|
||
| 2015-12-25 13:37 | r3273 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住I!Q28: 7688的USB Host若要接一個以上的device，是否大部分要
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住I!Q28: 7688的USB Host若要接一個以上的device，是否大部分要外ㄐㄧ
|
||
| 2015-12-25 13:37 – 13:37 | r3271 – r3272 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來ㄎㄚ!Q28: 7688的USB Host若要接一個以上的device，是否大部分要
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來卡住I!Q28: 7688的USB Host若要接一個以上的device，是否大部分要
|
||
| 2015-12-25 13:37 | r3270 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來ㄎㄚ!Q28: 7688的USB Host若要接一個以上的device，是否大部分
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來ㄎㄚ!Q28: 7688的USB Host若要接一個以上的device，是否大部分要
|
||
| 2015-12-25 13:37 | r3269 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來!Q28: 7688的USB Host若要接一個以上的device，是否大部分
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來ㄎㄚ!Q28: 7688的USB Host若要接一個以上的device，是否大部分
|
||
| 2015-12-25 13:37 – 13:37 | r3266 – r3268 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來!Q28: 7688的USB Host若要接一個以上的device，是否大
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來!Q28: 7688的USB Host若要接一個以上的device，是否大部分
|
||
| 2015-12-25 13:37 | r3265 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver!Q28: 7688的USB Host若要接一個以上的device，是否大
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver來!Q28: 7688的USB Host若要接一個以上的device，是否大
|
||
| 2015-12-25 13:37 – 13:37 | r3263 – r3264 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver!Q28: 7688的USB Host若要接一個以上的device，是ㄈㄡ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver!Q28: 7688的USB Host若要接一個以上的device，是否大
|
||
| 2015-12-25 13:37 | r3262 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel d!Q28: 7688的USB Host若要接一個以上的device，是ㄈㄡ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel driver!Q28: 7688的USB Host若要接一個以上的device，是ㄈㄡ
|
||
| 2015-12-25 13:37 | r3261 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel d!Q28: 7688的USB Host若要接一個以上的device，是
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel d!Q28: 7688的USB Host若要接一個以上的device，是ㄈㄡ
|
||
| 2015-12-25 13:37 | r3260 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kern!Q28: 7688的USB Host若要接一個以上的device，是
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kernel d!Q28: 7688的USB Host若要接一個以上的device，是
|
||
| 2015-12-25 13:37 | r3259 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kern!Q28: 7688的USB Host若要接一個以上的device，ㄕ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kern!Q28: 7688的USB Host若要接一個以上的device，是
|
||
| 2015-12-25 13:37 – 13:37 | r3256 – r3258 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫!Q28: 7688的USB Host若要接一個以上的device，ㄕ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫Linux Kern!Q28: 7688的USB Host若要接一個以上的device，ㄕ
|
||
| 2015-12-25 13:37 | r3255 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫!Q28: 7688的USB Host若要接一個以上的device，
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫!Q28: 7688的USB Host若要接一個以上的device，ㄕ
|
||
| 2015-12-25 13:37 – 13:37 | r3252 – r3254 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要職ㄧ!Q28: 7688的USB Host若要接一個以上的device，
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要直接去寫!Q28: 7688的USB Host若要接一個以上的device，
|
||
| 2015-12-25 13:37 | r3251 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要職ㄧ!Q28: 7688的USB Host若要接一個以上的device
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要職ㄧ!Q28: 7688的USB Host若要接一個以上的device，
|
||
| 2015-12-25 13:37 | r3250 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要!Q28: 7688的USB Host若要接一個以上的device
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要職ㄧ!Q28: 7688的USB Host若要接一個以上的device
|
||
| 2015-12-25 13:37 | r3249 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要!Q28: 7688的USB Host若要接一個以上的devic
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要!Q28: 7688的USB Host若要接一個以上的device
|
||
| 2015-12-25 13:37 | r3248 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就!Q28: 7688的USB Host若要接一個以上的devic
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就要!Q28: 7688的USB Host若要接一個以上的devic
|
||
| 2015-12-25 13:37 | r3247 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就!Q28: 7688的USB Host若要接一個以上的
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就!Q28: 7688的USB Host若要接一個以上的devic
|
||
| 2015-12-25 13:37 | r3246 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是!Q28: 7688的USB Host若要接一個以上的
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是就!Q28: 7688的USB Host若要接一個以上的
|
||
| 2015-12-25 13:37 | r3245 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是!Q28: 7688的USB Host若要接一個以上
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是!Q28: 7688的USB Host若要接一個以上的
|
||
| 2015-12-25 13:37 | r3244 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端!Q28: 7688的USB Host若要接一個以上
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端，或是!Q28: 7688的USB Host若要接一個以上
|
||
| 2015-12-25 13:37 – 13:37 | r3242 – r3243 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端!Q28: 7688的USB Host若要接一個
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端!Q28: 7688的USB Host若要接一個以上
|
||
| 2015-12-25 13:37 | r3241 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要接一個
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是做在MCU端!Q28: 7688的USB Host若要接一個
|
||
| 2015-12-25 13:37 – 13:37 | r3239 – r3240 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要接
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要接一個
|
||
| 2015-12-25 13:36 – 13:36 | r3236 – r3238 | |
顯示 diff（236 行未修改）
|
||
| 2015-12-25 13:36 | r3235 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要街
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要接
|
||
| 2015-12-25 13:36 | r3234 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU!Q28: 7688的USB Host若要街
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU端!Q28: 7688的USB Host若要街
|
||
| 2015-12-25 13:36 – 13:36 | r3232 – r3233 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU!Q28: 7688的USB Host若要
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU!Q28: 7688的USB Host若要街
|
||
| 2015-12-25 13:36 – 13:36 | r3230 – r3231 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在!Q28: 7688的USB Host若要
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在MCU!Q28: 7688的USB Host若要
|
||
| 2015-12-25 13:36 | r3229 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在!Q28: 7688的USB Host
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在!Q28: 7688的USB Host若要
|
||
| 2015-12-25 13:36 – 13:36 | r3221 – r3228 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合!Q28: 7688的USB Host
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合乎即時的需求。建議還是坐在!Q28: 7688的USB Host
|
||
| 2015-12-25 13:36 | r3220 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合!Q28: 7688的USB Ho
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合!Q28: 7688的USB Host
|
||
| 2015-12-25 13:36 | r3219 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不ㄏㄜ!Q28: 7688的USB Ho
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不合!Q28: 7688的USB Ho
|
||
| 2015-12-25 13:36 | r3218 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不ㄏㄜ!Q28: 7688的USB
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不ㄏㄜ!Q28: 7688的USB Ho
|
||
| 2015-12-25 13:36 | r3217 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅㄨ!Q28: 7688的USB
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能不ㄏㄜ!Q28: 7688的USB
|
||
| 2015-12-25 13:36 | r3216 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅㄨ!Q28: 7688的US
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅㄨ!Q28: 7688的USB
|
||
| 2015-12-25 13:36 | r3215 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅ!Q28: 7688的US
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅㄨ!Q28: 7688的US
|
||
| 2015-12-25 13:36 | r3214 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅ!Q28: 7688的
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅ!Q28: 7688的US
|
||
| 2015-12-25 13:36 | r3213 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可!Q28: 7688的
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可能ㄅ!Q28: 7688的
|
||
| 2015-12-25 13:36 | r3212 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可!Q28: 7688ㄉㄜ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可!Q28: 7688的
|
||
| 2015-12-25 13:36 | r3211 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也!Q28: 7688ㄉㄜ
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也可!Q28: 7688ㄉㄜ
|
||
| 2015-12-25 13:36 | r3210 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也!Q28: 7688
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也!Q28: 7688ㄉㄜ
|
||
| 2015-12-25 13:36 – 13:36 | r3208 – r3209 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，late!Q28: 7688
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，latency也!Q28: 7688
|
||
| 2015-12-25 13:36 – 13:36 | r3206 – r3207 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，late!Q28: 7
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，late!Q28: 7688
|
||
| 2015-12-25 13:36 | r3205 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，l!Q28: 7
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，late!Q28: 7
|
||
| 2015-12-25 13:36 | r3204 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，l!Q28:
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，l!Q28: 7
|
||
| 2015-12-25 13:36 | r3203 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，!Q28:
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，l!Q28:
|
||
| 2015-12-25 13:36 – 13:36 | r3197 – r3202 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，!
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，!Q28:
|
||
| 2015-12-25 13:36 | r3196 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠!
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠，!
|
||
| 2015-12-25 13:36 | r3195 | |
顯示 diff（236 行未修改）
|
||
| 2015-12-25 13:36 | r3194 | |
顯示 diff（236 行未修改）
|
||
| 2015-12-25 13:36 | r3193 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠!
|
||
| 2015-12-25 13:36 – 13:36 | r3186 – r3192 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，t
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，就算throughput足夠
|
||
| 2015-12-25 13:36 | r3185 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead在那
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，t
|
||
| 2015-12-25 13:36 | r3184 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，t
|
||
| 2015-12-25 13:36 | r3183 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhea
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhead
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，
|
||
| 2015-12-25 13:36 | r3182 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhea
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，
|
||
| 2015-12-25 13:36 | r3181 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Over
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Overhea
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對
|
||
| 2015-12-25 13:36 | r3180 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Over
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對於
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對
|
||
| 2015-12-25 13:36 – 13:36 | r3178 – r3179 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆O
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆Over
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對於
|
||
| 2015-12-25 13:36 – 13:36 | r3176 – r3177 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆O
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響，對於
|
||
| 2015-12-25 13:36 | r3175 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆O
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響
|
||
| 2015-12-25 13:36 | r3174 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影響
|
||
| 2015-12-25 13:36 | r3173 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說一堆
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影
|
||
| 2015-12-25 13:36 – 13:36 | r3170 – r3172 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler的影
|
||
| 2015-12-25 13:36 | r3169 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用說
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
|
||
| 2015-12-25 13:36 | r3168 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
|
||
| 2015-12-25 13:36 – 13:36 | r3166 – r3167 | |
顯示 diff（236 行未修改）
|
||
| 2015-12-25 13:36 | r3165 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
|
||
| 2015-12-25 13:36 | r3164 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙ㄩㄥ
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙用
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
|
||
| 2015-12-25 13:36 | r3163 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙ㄩㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到sch
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到scheduler
|
||
| 2015-12-25 13:36 – 13:36 | r3161 – r3162 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄍㄥ
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,更不˙ㄩㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到sch
|
||
| 2015-12-25 13:36 | r3160 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄍㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到sch
|
||
| 2015-12-25 13:36 | r3159 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄊㄥ
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄍㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到
|
||
| 2015-12-25 13:36 – 13:36 | r3156 – r3158 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄊㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在user space
+ x另外要提醒一下，Linux端做處理，如果是寫在user space都會受到
|
||
| 2015-12-25 13:36 | r3155 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,ㄊㄥ
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在user space
|
||
| 2015-12-25 13:36 – 13:36 | r3153 – r3154 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x另外要提醒一下，Linux端做處理，如果是寫在
+ x另外要提醒一下，Linux端做處理，如果是寫在user space
|
||
| 2015-12-25 13:36 | r3152 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多,
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x另外要提醒一下，Linux端做處理，如果是寫在
|
||
| 2015-12-25 13:35 – 13:36 | r3147 – r3151 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
- x
- u
+ x另外要提醒一下，Linux端做處理，如果是寫在
|
||
| 2015-12-25 13:35 | r3146 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表ㄍㄜ
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表格
x
u
|
||
| 2015-12-25 13:35 | r3145 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表ㄍㄜ
x
- u/4j
+ u
|
||
| 2015-12-25 13:35 | r3144 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的ㄅㄧㄠ
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的表ㄍㄜ
x
u/4j
|
||
| 2015-12-25 13:35 | r3143 | |
顯示 diff（234 行未修改）
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的ㄅㄧㄠ
x
+ u/4j
|
||
| 2015-12-25 13:35 | r3142 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的ㄅㄧㄠ
x
|
||
| 2015-12-25 13:35 | r3141 | |
顯示 diff（236 行未修改）
|
||
| 2015-12-25 13:35 – 13:35 | r3139 – r3140 | |
顯示 diff（233 行未修改）
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的
+ x
|
||
| 2015-12-25 13:35 | r3138 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz的
|
||
| 2015-12-25 13:35 | r3137 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 – 13:35 | r3105 – r3136 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ請參閱Atmega32U4的Datasheet,其中Crystal找8Mhz
|
||
| 2015-12-25 13:35 | r3104 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔ㄑ
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔!ㄑ
|
||
| 2015-12-25 13:35 | r3103 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 | r3102 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 | r3101 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有115200喔
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔ㄑ
|
||
| 2015-12-25 13:35 – 13:35 | r3096 – r3100 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有
+ Atmega32U4的UART可以上1MBPS，不是只有115200喔
|
||
| 2015-12-25 13:35 – 13:35 | r3094 – r3095 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不是只有f奇ㄕˊ可ㄧ
+ Atmega32U4的UART可以上1MBPS，不是只有
|
||
| 2015-12-25 13:35 – 13:35 | r3092 – r3093 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不f奇ㄕˊ可ㄧ
+ Atmega32U4的UART可以上1MBPS，不是只有f奇ㄕˊ可ㄧ
|
||
| 2015-12-25 13:35 | r3091 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，不f奇ㄕˊㄎㄜ
+ Atmega32U4的UART可以上1MBPS，不f奇ㄕˊ可ㄧ
|
||
| 2015-12-25 13:35 | r3090 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，Ｂf奇ㄕˊㄎㄜ
+ Atmega32U4的UART可以上1MBPS，不f奇ㄕˊㄎㄜ
|
||
| 2015-12-25 13:35 | r3089 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，Ｂf奇ㄕ
+ Atmega32U4的UART可以上1MBPS，Ｂf奇ㄕˊㄎㄜ
|
||
| 2015-12-25 13:35 | r3088 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，f奇ㄕ
+ Atmega32U4的UART可以上1MBPS，Ｂf奇ㄕ
|
||
| 2015-12-25 13:35 | r3087 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，f
+ Atmega32U4的UART可以上1MBPS，f奇ㄕ
|
||
| 2015-12-25 13:35 – 13:35 | r3085 – r3086 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 | r3084 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPS，fㄑ
+ Atmega32U4的UART可以上1MBPS，f
|
||
| 2015-12-25 13:35 | r3083 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPfㄑ
+ Atmega32U4的UART可以上1MBPS，fㄑ
|
||
| 2015-12-25 13:35 | r3082 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBPfㄑㄘㄛ
+ Atmega32U4的UART可以上1MBPfㄑ
|
||
| 2015-12-25 13:35 | r3081 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBfㄑㄘㄛ
+ Atmega32U4的UART可以上1MBPfㄑㄘㄛ
|
||
| 2015-12-25 13:35 | r3080 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MBfㄑㄛ˙
+ Atmega32U4的UART可以上1MBfㄑㄘㄛ
|
||
| 2015-12-25 13:35 | r3079 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1Mfㄑㄛ˙
+ Atmega32U4的UART可以上1MBfㄑㄛ˙
|
||
| 2015-12-25 13:35 | r3078 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1Mfㄑ
+ Atmega32U4的UART可以上1Mfㄑㄛ˙
|
||
| 2015-12-25 13:35 | r3077 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MHfㄑ
+ Atmega32U4的UART可以上1Mfㄑ
|
||
| 2015-12-25 13:35 | r3076 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MHf
+ Atmega32U4的UART可以上1MHfㄑ
|
||
| 2015-12-25 13:35 | r3075 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MHZf
+ Atmega32U4的UART可以上1MHf
|
||
| 2015-12-25 13:35 | r3074 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 | r3073 | |
顯示 diff（235 行未修改）
|
||
| 2015-12-25 13:35 | r3072 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART可以上1MHZ
+ Atmega32U4的UART可以上1MHZf
|
||
| 2015-12-25 13:35 – 13:35 | r3062 – r3071 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
- Atmega32U4的UART
+ Atmega32U4的UART可以上1MHZ
|
||
| 2015-12-25 13:35 | r3061 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
+ *我的想法是，I2C可以做的比UART高速，減少延遲話I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
Atmega32U4的UART
|
||
| 2015-12-25 13:34 – 13:35 | r3053 – r3060 | |
顯示 diff（232 行未修改）
只是說中間兩個的通訊要自己來而已
*我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
+ Atmega32U4的UART
|
||
| 2015-12-25 13:34 – 13:34 | r3025 – r3052 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- *我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.
+ *我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.....400khz和1UART的1 mbps比起來真的慢很多
|
||
| 2015-12-25 13:34 | r3024 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.
+ *我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.
|
||
| 2015-12-25 13:33 – 13:34 | r3015 – r3023 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少延遲話說說,
+ 我的想法是，I2C可以做的比UART高速，減少延遲話說說,I2C是很慢的.
|
||
| 2015-12-25 13:33 – 13:33 | r3013 – r3014 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少延話說說,
+ 我的想法是，I2C可以做的比UART高速，減少延遲話說說,
|
||
| 2015-12-25 13:33 – 13:33 | r3011 – r3012 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少延話說ㄕㄨ
+ 我的想法是，I2C可以做的比UART高速，減少延話說說,
|
||
| 2015-12-25 13:33 | r3010 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少ＰＺ話說ㄕㄨ
+ 我的想法是，I2C可以做的比UART高速，減少延話說ㄕㄨ
|
||
| 2015-12-25 13:33 | r3009 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少ＰＺ話說
+ 我的想法是，I2C可以做的比UART高速，減少ＰＺ話說ㄕㄨ
|
||
| 2015-12-25 13:33 | r3008 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少話說
+ 我的想法是，I2C可以做的比UART高速，減少ＰＺ話說
|
||
| 2015-12-25 13:33 – 13:33 | r3004 – r3007 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減少話說<,板子上SPIㄕ
+ 我的想法是，I2C可以做的比UART高速，減少話說
|
||
| 2015-12-25 13:33 | r3003 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減Ｓ話說<,板子上SPIㄕ
+ 我的想法是，I2C可以做的比UART高速，減少話說<,板子上SPIㄕ
|
||
| 2015-12-25 13:33 | r3002 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，減Ｓ話說<,板子上SPI
+ 我的想法是，I2C可以做的比UART高速，減Ｓ話說<,板子上SPIㄕ
|
||
| 2015-12-25 13:33 | r3001 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＡＱＯ話說<,板子上SPI
+ 我的想法是，I2C可以做的比UART高速，減Ｓ話說<,板子上SPI
|
||
| 2015-12-25 13:33 | r3000 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＡＱＯ話說<,板子上S
+ 我的想法是，I2C可以做的比UART高速，ＷＡＱＯ話說<,板子上SPI
|
||
| 2015-12-25 13:33 | r2999 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，話說<,板子上S
+ 我的想法是，I2C可以做的比UART高速，ＷＡＱＯ話說<,板子上S
|
||
| 2015-12-25 13:33 | r2998 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，話說<,板子上
+ 我的想法是，I2C可以做的比UART高速，話說<,板子上S
|
||
| 2015-12-25 13:33 | r2997 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，浬話說<,板子上
+ 我的想法是，I2C可以做的比UART高速，話說<,板子上
|
||
| 2015-12-25 13:33 – 13:33 | r2995 – r2996 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，浬話說<,版ㄗ
+ 我的想法是，I2C可以做的比UART高速，浬話說<,板子上
|
||
| 2015-12-25 13:33 | r2994 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版ㄗ
+ 我的想法是，I2C可以做的比UART高速，浬話說<,版ㄗ
|
||
| 2015-12-25 13:33 | r2993 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版ㄗ
|
||
| 2015-12-25 13:33 – 13:33 | r2991 – r2992 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，渦話說<,版
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版
|
||
| 2015-12-25 13:33 | r2990 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，渦話說<,版呀ㄕ
+ 我的想法是，I2C可以做的比UART高速，渦話說<,版
|
||
| 2015-12-25 13:33 | r2989 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版呀ㄕ
+ 我的想法是，I2C可以做的比UART高速，渦話說<,版呀ㄕ
|
||
| 2015-12-25 13:33 | r2988 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版呀
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版呀ㄕ
|
||
| 2015-12-25 13:33 | r2987 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，話說<,版呀
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版呀
|
||
| 2015-12-25 13:33 | r2986 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，話說<,版ㄗ
+ 我的想法是，I2C可以做的比UART高速，話說<,版呀
|
||
| 2015-12-25 13:33 | r2985 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，Ｗ話說<,版ㄗ
+ 我的想法是，I2C可以做的比UART高速，話說<,版ㄗ
|
||
| 2015-12-25 13:33 | r2984 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，Ｗ話說<,版ㄗㄧ
+ 我的想法是，I2C可以做的比UART高速，Ｗ話說<,版ㄗ
|
||
| 2015-12-25 13:33 | r2983 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版ㄗㄧ
+ 我的想法是，I2C可以做的比UART高速，Ｗ話說<,版ㄗㄧ
|
||
| 2015-12-25 13:33 – 13:33 | r2981 – r2982 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,版ㄗㄧ
|
||
| 2015-12-25 13:33 | r2980 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，Ｗ話說<,
+ 我的想法是，I2C可以做的比UART高速，ＷＱ話說<,
|
||
| 2015-12-25 13:33 | r2979 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，Ｗ話說<
+ 我的想法是，I2C可以做的比UART高速，Ｗ話說<,
|
||
| 2015-12-25 13:33 | r2978 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，話說<
+ 我的想法是，I2C可以做的比UART高速，Ｗ話說<
|
||
| 2015-12-25 13:33 | r2977 | |
顯示 diff（234 行未修改）
|
||
| 2015-12-25 13:33 | r2976 | |
顯示 diff（234 行未修改）
|
||
| 2015-12-25 13:33 | r2975 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我的想法是，I2C可以做的比UART高速，
+ 我的想法是，I2C可以做的比UART高速，話說<
|
||
| 2015-12-25 13:33 – 13:33 | r2957 – r2974 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
- 我
+ 我的想法是，I2C可以做的比UART高速，
|
||
| 2015-12-25 13:33 | r2956 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *技術即時問與聊天室： https://gitter.im/MakerCup/linkit-7688
+ *技術即時問與答聊天室： https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
*文章
（155 行未修改）
|
||
| 2015-12-25 13:33 | r2955 | |
顯示 diff（231 行未修改）
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
+ 我
|
||
| 2015-12-25 13:33 | r2954 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *技術即時聊天室： https://gitter.im/MakerCup/linkit-7688
+ *技術即時問與聊天室： https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
*文章
（154 行未修改）
|
||
| 2015-12-25 13:33 – 13:33 | r2951 – r2953 | |
顯示 diff（233 行未修改）
|
||
| 2015-12-25 13:33 – 13:33 | r2945 – r2950 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guide
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guide http://labs.mediatek.com/fileMedia/download/87c801b5-d1e6-4227-9a29-b5421f2955ac#page=68
*好的謝謝
m
（6 行未修改）
|
||
| 2015-12-25 13:33 – 13:33 | r2940 – r2944 | |
顯示 diff（223 行未修改）
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guide
+ *好的謝謝
m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（5 行未修改）
|
||
| 2015-12-25 13:33 | r2939 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
+
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
只是說中間兩個的通訊要自己來而已
|
||
| 2015-12-25 13:32 – 13:32 | r2937 – r2938 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *即時聊天室 https://gitter.im/MakerCup/linkit-7688
+ *技術即時聊天室： https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
*文章
（152 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2934 – r2936 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guidm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guide
+ m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2933 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己來而
+ 只是說中間兩個的通訊要自己來而已
|
||
| 2015-12-25 13:32 | r2932 | |
顯示 diff（73 行未修改）
*Others
*社群資源
- *臉書ㄐ
+ *臉書
*即時聊天室 https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
（152 行未修改）
|
||
| 2015-12-25 13:32 | r2931 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己來
+ 只是說中間兩個的通訊要自己來而
|
||
| 2015-12-25 13:32 | r2930 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Gum
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Guidm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2929 | |
顯示 diff（73 行未修改）
*Others
*社群資源
- *臉書
+ *臉書ㄐ
*即時聊天室 https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
（152 行未修改）
|
||
| 2015-12-25 13:32 | r2928 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer'm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer's Gum
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2927 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己來就
+ 只是說中間兩個的通訊要自己來
|
||
| 2015-12-25 13:32 | r2926 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develom
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Developer'm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2925 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己來就ㄕ
+ 只是說中間兩個的通訊要自己來就
|
||
| 2015-12-25 13:32 | r2924 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develoerm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develom
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2923 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己來
+ 只是說中間兩個的通訊要自己來就ㄕ
|
||
| 2015-12-25 13:32 | r2922 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develoerpm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develoerm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2921 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自己ㄌ
+ 只是說中間兩個的通訊要自己來
|
||
| 2015-12-25 13:32 | r2920 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develoerpm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2919 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要自
+ 只是說中間兩個的通訊要自己ㄌ
|
||
| 2015-12-25 13:32 | r2918 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Dem
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Develm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2917 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要
+ 只是說中間兩個的通訊要自
|
||
| 2015-12-25 13:32 – 13:32 | r2915 – r2916 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以餐ㄓㄠm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以參照Dem
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2914 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要ㄗㄧˋ
+ 只是說中間兩個的通訊要
|
||
| 2015-12-25 13:32 | r2913 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以m
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以餐ㄓㄠm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2912 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的通訊要
+ 只是說中間兩個的通訊要ㄗㄧˋ
|
||
| 2015-12-25 13:32 | r2911 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。可以m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2909 – r2910 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的ㄊㄨ
+ 只是說中間兩個的通訊要
|
||
| 2015-12-25 13:32 | r2908 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6m
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2907 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的ㄊ翁
+ 只是說中間兩個的ㄊㄨ
|
||
| 2015-12-25 13:32 | r2906 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6fu/6m
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2905 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的ㄊ翁ㄒㄩ
+ 只是說中間兩個的ㄊ翁
|
||
| 2015-12-25 13:32 | r2904 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6fm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6fu/6m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2903 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
- 只是說中間兩個的ㄊ
+ 只是說中間兩個的ㄊ翁ㄒㄩ
|
||
| 2015-12-25 13:32 | r2902 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vm
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vu;6fm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2901 | |
顯示 diff（227 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
+ 只是說中間兩個的ㄊ
|
||
| 2015-12-25 13:32 | r2900 | |
顯示 diff（222 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請Duo可以使用Arduino IDE寫程式。
- Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。vm
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2896 – r2899 | |
顯示 diff（229 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2893 – r2895 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *聊天室
+ *即時聊天室 https://gitter.im/MakerCup/linkit-7688
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2892 | |
顯示 diff（229 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2890 – r2891 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *級時聊天室
+ *聊天室
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2887 – r2889 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過7688
|
||
| 2015-12-25 13:32 – 13:32 | r2884 – r2886 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *級時
+ *級時聊天室
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2883 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經過
|
||
| 2015-12-25 13:32 | r2882 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *級
+ *級時
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2881 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用經
|
||
| 2015-12-25 13:32 | r2880 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *
+ *級
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2879 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,而不用
|
||
| 2015-12-25 13:32 – 13:32 | r2877 – r2878 | |
顯示 diff（221 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDE寫成ㄕ
+ *打錯，已修正請Duo可以使用Arduino IDE寫程式。
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2876 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣,
|
||
| 2015-12-25 13:32 | r2875 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
- *ㄎ
+ *
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2874 | |
顯示 diff（226 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一樣
|
||
| 2015-12-25 13:32 | r2873 | |
顯示 diff（221 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDE寫
+ *打錯，已修正請Duo可以使用Arduino IDE寫成ㄕ
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2871 – r2872 | |
顯示 diff（74 行未修改）
*社群資源
*臉書
+ *ㄎ
*[ 請協助加入 ]
*文章
（150 行未修改）
|
||
| 2015-12-25 13:32 | r2870 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDEㄒㄧ
+ *打錯，已修正請Duo可以使用Arduino IDE寫
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2869 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上一
|
||
| 2015-12-25 13:32 | r2868 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDE變
+ *打錯，已修正請Duo可以使用Arduino IDEㄒㄧ
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2867 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子上
|
||
| 2015-12-25 13:32 | r2866 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDE變ㄔㄥ
+ *打錯，已修正請Duo可以使用Arduino IDE變
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2865 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在ㄅㄢ
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在板子
|
||
| 2015-12-25 13:32 | r2864 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino IDE
+ *打錯，已修正請Duo可以使用Arduino IDE變ㄔㄥ
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2863 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在ㄅㄢ
|
||
| 2015-12-25 13:32 | r2862 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用Arduino
+ *打錯，已修正請Duo可以使用Arduino IDE
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2861 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo在
|
||
| 2015-12-25 13:32 – 13:32 | r2858 – r2860 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用ㄐ
+ *打錯，已修正請Duo可以使用Arduino
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2857 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaod
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaodo
|
||
| 2015-12-25 13:32 | r2856 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以使用
+ *打錯，已修正請Duo可以使用ㄐ
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2855 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonao
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonaod
|
||
| 2015-12-25 13:32 | r2854 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo可以
+ *打錯，已修正請Duo可以使用
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2853 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leona
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leonao
|
||
| 2015-12-25 13:32 | r2852 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo
+ *打錯，已修正請Duo可以
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2851 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leon
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leona
|
||
| 2015-12-25 13:32 | r2850 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請D
+ *打錯，已修正請Duo
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 | r2849 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個Leo
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leon
|
||
| 2015-12-25 13:32 | r2848 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請
+ *打錯，已修正請D
Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（3 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2846 – r2847 | |
顯示 diff（225 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega32U4自己做處裡,就像是有個LK
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個Leo
|
||
| 2015-12-25 13:32 | r2845 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請
+ Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:32 – 13:32 | r2838 – r2844 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega3
+ 你當然可以讓Atmega32U4自己做處裡,就像是有個LK
|
||
| 2015-12-25 13:32 | r2837 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo的ATMega32上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo的ATMega32U4上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:32 | r2836 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atmega
+ 你當然可以讓Atmega3
|
||
| 2015-12-25 13:32 – 13:32 | r2834 – r2835 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo的ATM上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo的ATMega32上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:32 | r2833 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓Atme
+ 你當然可以讓Atmega
|
||
| 2015-12-25 13:32 | r2832 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo的A上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo的ATM上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:31 | r2831 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓At
+ 你當然可以讓Atme
|
||
| 2015-12-25 13:31 | r2830 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo的上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo的A上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:31 | r2829 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓A
+ 你當然可以讓At
|
||
| 2015-12-25 13:31 | r2828 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請Duo上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo的上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:31 | r2827 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以讓
+ 你當然可以讓A
|
||
| 2015-12-25 13:31 | r2826 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請D上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請Duo上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:31 | r2825 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- 你當然可以
+ 你當然可以讓
|
||
| 2015-12-25 13:31 | r2824 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請D上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
（2 行未修改）
|
||
| 2015-12-25 13:31 – 13:31 | r2822 – r2823 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
- s
+ 你當然可以
|
||
| 2015-12-25 13:31 | r2821 | |
顯示 diff（227 行未修改）
|
||
| 2015-12-25 13:31 – 13:31 | r2819 – r2820 | |
顯示 diff（224 行未修改）
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
+ s
|
||
| 2015-12-25 13:31 – 13:31 | r2800 – r2818 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要ＴＮ
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要通過UART回到7688再決定，就慢了。
|
||
| 2015-12-25 13:31 | r2799 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以
+
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要ＴＮ
|
||
| 2015-12-25 13:31 | r2798 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要ＴＮ
|
||
| 2015-12-25 13:31 | r2797 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用Arduino Leonar
+ 可以
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要
|
||
| 2015-12-25 13:31 | r2796 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用Arduino Leonar
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料要
|
||
| 2015-12-25 13:31 – 13:31 | r2794 – r2795 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用Arduino Leo
+ 可以直接用Arduino Leonar
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料
|
||
| 2015-12-25 13:31 | r2793 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用Arduino Leo
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資ＭＤＪ
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資料
|
||
| 2015-12-25 13:31 | r2792 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用Arduino
+ 可以直接用Arduino Leo
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資ＭＤＪ
|
||
| 2015-12-25 13:31 | r2791 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用Arduino
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資Ｍ
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資ＭＤＪ
|
||
| 2015-12-25 13:31 | r2790 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用Ardui
+ 可以直接用Arduino
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資Ｍ
|
||
| 2015-12-25 13:31 | r2789 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用Ardui
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的ＲＩＭ
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的資Ｍ
|
||
| 2015-12-25 13:31 | r2788 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用A
+ 可以直接用Ardui
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的ＲＩＭ
|
||
| 2015-12-25 13:31 | r2787 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用A
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的ＲＩＭ
|
||
| 2015-12-25 13:31 | r2786 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接用
+ 可以直接用A
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的
|
||
| 2015-12-25 13:31 | r2785 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接用
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所有的
|
||
| 2015-12-25 13:31 | r2784 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直接ㄩㄥ
+ 可以直接用
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所
|
||
| 2015-12-25 13:31 – 13:31 | r2782 – r2783 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直接ㄩㄥ
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而不是所
|
||
| 2015-12-25 13:31 | r2781 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以
+ 可以直接ㄩㄥ
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而
|
||
| 2015-12-25 13:31 | r2780 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，而
|
||
| 2015-12-25 13:31 – 13:31 | r2771 – r2779 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直
+ 可以
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，
|
||
| 2015-12-25 13:31 | r2770 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定，
|
||
| 2015-12-25 13:31 | r2769 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以直ㄐ
+ 可以直
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定
|
||
| 2015-12-25 13:31 | r2768 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以直ㄐ
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決ＮＥ
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決定
|
||
| 2015-12-25 13:31 | r2767 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 可以
+ 可以直ㄐ
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決ＮＥ
|
||
| 2015-12-25 13:31 | r2766 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
可以
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決ＮＥ
|
||
| 2015-12-25 13:31 | r2765 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
-
+ 可以
我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決
|
||
| 2015-12-25 13:31 | r2764 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和決
|
||
| 2015-12-25 13:31 – 13:31 | r2760 – r2763 | |
顯示 diff（226 行未修改）
|
||
| 2015-12-25 13:31 – 13:31 | r2757 – r2759 | |
顯示 diff（223 行未修改）
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 我所謂的即時是，ATMega32U4在內部自已處理IO，判
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判斷和
|
||
| 2015-12-25 13:31 | r2756 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
+
我所謂的即時是，ATMega32U4在內部自已處理IO，判
|
||
| 2015-12-25 13:31 | r2755 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
- 我所謂的即時是，ATMega32U4在內部自已處理IO，
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，判
|
||
| 2015-12-25 13:31 | r2754 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的M
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的MCU
我所謂的即時是，ATMega32U4在內部自已處理IO，
|
||
| 2015-12-25 13:31 | r2753 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的M
- 我所謂的即時是，ATMega32U4在內部自已處理IO，弊
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，
|
||
| 2015-12-25 13:31 | r2752 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的M
我所謂的即時是，ATMega32U4在內部自已處理IO，弊
|
||
| 2015-12-25 13:31 – 13:31 | r2750 – r2751 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的
- 我所謂的即時是，ATMega32U4在內部自已處理IO，
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，弊
|
||
| 2015-12-25 13:31 – 13:31 | r2746 – r2749 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo所使用的
我所謂的即時是，ATMega32U4在內部自已處理IO，
|
||
| 2015-12-25 13:31 | r2745 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo
- 我所謂的即時是，ATMega32U4在內部自已處理I
+ 我所謂的即時是，ATMega32U4在內部自已處理IO，
|
||
| 2015-12-25 13:31 | r2744 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leona
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leonardo
我所謂的即時是，ATMega32U4在內部自已處理I
|
||
| 2015-12-25 13:31 | r2743 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leona
- 我所謂的即時是，ATMega32U4在內部自已處理
+ 我所謂的即時是，ATMega32U4在內部自已處理I
|
||
| 2015-12-25 13:31 | r2742 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leo
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leona
我所謂的即時是，ATMega32U4在內部自已處理
|
||
| 2015-12-25 13:31 | r2741 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leo
- 我所謂的即時是，ATMega32U4在內部自已處
+ 我所謂的即時是，ATMega32U4在內部自已處理
|
||
| 2015-12-25 13:31 | r2740 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Le
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Leo
我所謂的即時是，ATMega32U4在內部自已處
|
||
| 2015-12-25 13:31 | r2739 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Le
- 我所謂的即時是，ATMega32U4在內部自已
+ 我所謂的即時是，ATMega32U4在內部自已處
|
||
| 2015-12-25 13:31 – 13:31 | r2736 – r2738 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是A
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是Arduino Le
我所謂的即時是，ATMega32U4在內部自已
|
||
| 2015-12-25 13:31 | r2735 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是A
- 我所謂的即時是，ATMega32U4在內部自
+ 我所謂的即時是，ATMega32U4在內部自已
|
||
| 2015-12-25 13:31 | r2734 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是A
我所謂的即時是，ATMega32U4在內部自
|
||
| 2015-12-25 13:31 | r2733 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就是
- 我所謂的即時是，ATMega32U4在內
+ 我所謂的即時是，ATMega32U4在內部自
|
||
| 2015-12-25 13:31 | r2732 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4就
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就是
我所謂的即時是，ATMega32U4在內
|
||
| 2015-12-25 13:31 | r2731 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4就
- 我所謂的即時是，ATMega32U4在
+ 我所謂的即時是，ATMega32U4在內
|
||
| 2015-12-25 13:31 | r2730 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega32U4
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4就
我所謂的即時是，ATMega32U4在
|
||
| 2015-12-25 13:31 | r2729 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega32U4
- 我所謂的即時是，ATMega32U4
+ 我所謂的即時是，ATMega32U4在
|
||
| 2015-12-25 13:31 – 13:31 | r2726 – r2728 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmega
+ 用I2C就已經是不即時的Protocal了,而且Atmega32U4
我所謂的即時是，ATMega32U4
|
||
| 2015-12-25 13:31 | r2725 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmega
- 我所謂的即時是，
+ 我所謂的即時是，ATMega32U4
|
||
| 2015-12-25 13:31 | r2724 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmegas
+ 用I2C就已經是不即時的Protocal了,而且Atmega
我所謂的即時是，
|
||
| 2015-12-25 13:31 | r2723 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmegas
- 我所謂的即時是
+ 我所謂的即時是，
|
||
| 2015-12-25 13:31 | r2722 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且Atmeg
+ 用I2C就已經是不即時的Protocal了,而且Atmegas
我所謂的即時是
|
||
| 2015-12-25 13:31 | r2721 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且Atmeg
- 我所謂的即時
+ 我所謂的即時是
|
||
| 2015-12-25 13:31 | r2720 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且At
+ 用I2C就已經是不即時的Protocal了,而且Atmeg
我所謂的即時
|
||
| 2015-12-25 13:31 | r2719 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且At
- 我所謂的即
+ 我所謂的即時
|
||
| 2015-12-25 13:31 – 13:31 | r2717 – r2718 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而且
+ 用I2C就已經是不即時的Protocal了,而且At
我所謂的即
|
||
| 2015-12-25 13:31 – 13:31 | r2712 – r2716 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且
- 我所課的
+ 我所謂的即
|
||
| 2015-12-25 13:31 | r2711 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。你m
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且
我所課的
|
||
| 2015-12-25 13:30 – 13:31 | r2708 – r2710 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。你m
用I2C就已經是不即時的Protocal了,而且
- 我
+ 我所課的
|
||
| 2015-12-25 13:30 | r2707 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。你m
用I2C就已經是不即時的Protocal了,而且
我
|
||
| 2015-12-25 13:30 | r2706 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而且
+ 我
|
||
| 2015-12-25 13:30 | r2705 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而ㄑ
+ 用I2C就已經是不即時的Protocal了,而且
|
||
| 2015-12-25 13:30 | r2704 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而ㄑ
- ＩＸ
|
||
| 2015-12-25 13:30 | r2703 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,而
+ 用I2C就已經是不即時的Protocal了,而ㄑ
ＩＸ
|
||
| 2015-12-25 13:30 | r2702 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,而
- ＩＸ我
+ ＩＸ
|
||
| 2015-12-25 13:30 | r2701 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,ㄦ
+ 用I2C就已經是不即時的Protocal了,而
ＩＸ我
|
||
| 2015-12-25 13:30 – 13:30 | r2699 – r2700 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,ㄦ
- 我
+ ＩＸ我
|
||
| 2015-12-25 13:30 | r2698 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,
+ 用I2C就已經是不即時的Protocal了,ㄦ
我
|
||
| 2015-12-25 13:30 – 13:30 | r2696 – r2697 | |
顯示 diff（225 行未修改）
|
||
| 2015-12-25 13:30 | r2695 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
- 用I2C就已經是不即時的Protocal了,=
+ 用I2C就已經是不即時的Protocal了,
我
|
||
| 2015-12-25 13:30 | r2694 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UART。m
用I2C就已經是不即時的Protocal了,=
我
|
||
| 2015-12-25 13:30 | r2693 | |
顯示 diff（222 行未修改）
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UARTm
用I2C就已經是不即時的Protocal了,=
+ 我
|
||
| 2015-12-25 13:30 – 13:30 | r2691 – r2692 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UARTm
- 用I2C就已經是不即時的Protocal了,ㄦ
+ 用I2C就已經是不即時的Protocal了,=
|
||
| 2015-12-25 13:30 – 13:30 | r2687 – r2690 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATM中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATMega32U4中間通道是UARTm
用I2C就已經是不即時的Protocal了,ㄦ
|
||
| 2015-12-25 13:30 | r2686 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATM中間通道是UARTm
- 用I2C就已經是不即時的Protocal了,
+ 用I2C就已經是不即時的Protocal了,ㄦ
|
||
| 2015-12-25 13:30 – 13:30 | r2684 – r2685 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟AT中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟ATM中間通道是UARTm
用I2C就已經是不即時的Protocal了,
|
||
| 2015-12-25 13:30 | r2683 | |
顯示 diff（224 行未修改）
|
||
| 2015-12-25 13:30 – 13:30 | r2679 – r2682 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN跟AT中間通道是UARTm
用I2C就已經是不即時的Protocal了,
|
||
| 2015-12-25 13:30 | r2678 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN中間通道是UARTm
- 用I2C就已經是不即時的Protocal了,奇
+ 用I2C就已經是不即時的Protocal了,
|
||
| 2015-12-25 13:30 | r2677 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT768中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT7688AN中間通道是UARTm
用I2C就已經是不即時的Protocal了,奇
|
||
| 2015-12-25 13:30 | r2676 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT768中間通道是UARTm
- 用I2C就已經是不即時的Protocal了,ㄑ
+ 用I2C就已經是不即時的Protocal了,奇
|
||
| 2015-12-25 13:30 | r2675 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT768中間通道是UARTm
用I2C就已經是不即時的Protocal了,ㄑ
|
||
| 2015-12-25 13:30 | r2674 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT中間通道是UARTm
- 用I2C就已經是不即時的Protocal了,
+ 用I2C就已經是不即時的Protocal了,ㄑ
|
||
| 2015-12-25 13:30 – 13:30 | r2672 – r2673 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。MT中間通道是UARTm
用I2C就已經是不即時的Protocal了,
|
||
| 2015-12-25 13:30 | r2671 | |
顯示 diff（221 行未修改）
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm
- 用I2C就已經是不即時的Protocal了
+ 用I2C就已經是不即時的Protocal了,
|
||
| 2015-12-25 13:30 – 13:30 | r2668 – r2670 | |
顯示 diff（220 行未修改）
*要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART - m
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm
用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2667 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
- *=要找Android or iOS AP Mode Port forwarding解決方案
+ *要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART - m
（1 行未修改）
|
||
| 2015-12-25 13:30 | r2666 | |
顯示 diff（220 行未修改）
*=要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART -m
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART - m
用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2665 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
- *=>要找Android or iOS AP Mode Port forwarding解決方案
+ *=要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART -m
（1 行未修改）
|
||
| 2015-12-25 13:30 | r2664 | |
顯示 diff（220 行未修改）
*=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UART -m
用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2663 | |
顯示 diff（220 行未修改）
*=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm用I2C就已經是不即時的Protocal了
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm
+ 用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2662 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
- =>要找Android or iOS AP Mode Port forwarding解決方案
+ *=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
*打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 – 13:30 | r2657 – r2661 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是I2m用I2C就已經是不即時的Protocal了
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是UARTm用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2656 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是I2m用I2C就已經是不即時的Protocal
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是I2m用I2C就已經是不即時的Protocal了
|
||
| 2015-12-25 13:30 | r2655 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是m用I2C就已經是不即時的Protocal
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是I2m用I2C就已經是不即時的Protocal
|
||
| 2015-12-25 13:30 | r2654 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是m用I2C就已經是不即時的Protoca
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是m用I2C就已經是不即時的Protocal
|
||
| 2015-12-25 13:30 | r2653 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Protoca
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道是m用I2C就已經是不即時的Protoca
|
||
| 2015-12-25 13:30 | r2652 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Proto
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Protoca
|
||
| 2015-12-25 13:30 – 13:30 | r2650 – r2651 | |
顯示 diff（223 行未修改）
|
||
| 2015-12-25 13:30 | r2649 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Prot
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Proto
|
||
| 2015-12-25 13:30 | r2648 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通m用I2C就已經是不即時的Prot
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通道m用I2C就已經是不即時的Prot
|
||
| 2015-12-25 13:30 | r2647 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通m用I2C就已經是不即時的Pro
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通m用I2C就已經是不即時的Prot
|
||
| 2015-12-25 13:30 | r2646 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中ㄐㄧㄢm用I2C就已經是不即時的Pro
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中間通m用I2C就已經是不即時的Pro
|
||
| 2015-12-25 13:30 | r2645 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中ㄐㄧㄢm用I2C就已經是不即時的P
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中ㄐㄧㄢm用I2C就已經是不即時的Pro
|
||
| 2015-12-25 13:30 | r2644 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的P
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。中ㄐㄧㄢm用I2C就已經是不即時的P
|
||
| 2015-12-25 13:30 | r2643 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的P
|
||
| 2015-12-25 13:30 – 13:30 | r2639 – r2642 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。ajm用I2C就已經是不即時的
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的
|
||
| 2015-12-25 13:30 | r2638 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。ajm用I2C就已經是不即時的了
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。ajm用I2C就已經是不即時的
|
||
| 2015-12-25 13:30 | r2637 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的了
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。ajm用I2C就已經是不即時的了
|
||
| 2015-12-25 13:30 – 13:30 | r2625 – r2636 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。m用I2C就已經是不即時的了
|
||
| 2015-12-25 13:30 – 13:30 | r2623 – r2624 | |
顯示 diff（223 行未修改）
|
||
| 2015-12-25 13:29 – 13:29 | r2620 – r2622 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。
+ *打錯，已修正請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。
|
||
| 2015-12-25 13:29 | r2619 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已修請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
+ *打錯，已修請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program。
|
||
| 2015-12-25 13:29 | r2618 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已ＰＩＰ請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
+ *打錯，已修請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
|
||
| 2015-12-25 13:29 | r2617 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已ＰＩＰ請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program>
+ *打錯，已ＰＩＰ請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
|
||
| 2015-12-25 13:29 | r2616 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program>
+ *打錯，已ＰＩＰ請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program>
|
||
| 2015-12-25 13:29 – 13:29 | r2613 – r2615 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，已請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program >
+ *打錯，已請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program>
|
||
| 2015-12-25 13:29 | r2612 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program >
+ *打錯，已請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program >
|
||
| 2015-12-25 13:29 | r2611 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯，請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
+ *打錯，請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program >
|
||
| 2015-12-25 13:29 | r2610 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
+ *打錯，請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
|
||
| 2015-12-25 13:29 | r2609 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打錯請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去progr
+ *打錯請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去program
|
||
| 2015-12-25 13:29 | r2608 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去progr
+ *打錯請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去progr
|
||
| 2015-12-25 13:29 | r2607 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *打請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去p
+ *打請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去progr
|
||
| 2015-12-25 13:29 | r2606 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去p
+ *打請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去p
|
||
| 2015-12-25 13:29 – 13:29 | r2604 – r2605 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- *請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE
+ *請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE去p
|
||
| 2015-12-25 13:29 | r2603 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- 請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE
+ *請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE
|
||
| 2015-12-25 13:29 – 13:29 | r2599 – r2602 | |
顯示 diff（220 行未修改）
=>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
- 請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader
+ 請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader沒錯，可以使用Arduino IDE
|
||
| 2015-12-25 13:29 | r2598 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?
+ 請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader
|
||
| 2015-12-25 13:29 – 13:29 | r2585 – r2597 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預載是Arduino bootloader
|
||
| 2015-12-25 13:29 | r2584 | |
顯示 diff（222 行未修改）
|
||
| 2015-12-25 13:29 | r2583 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預設
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預
|
||
| 2015-12-25 13:29 | r2582 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預設
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的ATMega32U4也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預設
|
||
| 2015-12-25 13:29 – 13:29 | r2579 – r2581 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 他上面預設
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 它上面預設
|
||
| 2015-12-25 13:29 | r2578 | |
顯示 diff（222 行未修改）
|
||
| 2015-12-25 13:29 – 13:29 | r2574 – r2577 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？ 他上面預設
|
||
| 2015-12-25 13:29 | r2573 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接ATMega32U4時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？
|
||
| 2015-12-25 13:29 – 13:29 | r2560 – r2572 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?請問328是指AtTMega32U4嗎？
|
||
| 2015-12-25 13:28 – 13:28 | r2530 – r2559 | |
顯示 diff（219 行未修改）
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode Port forwarding解決方案
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，還是DUO的328也可以用ARDUINO環境開發呢?
|
||
| 2015-12-25 13:27 – 13:28 | r2517 – r2529 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
- =>要找Android or iOS AP Mode P
+ =>要找Android or iOS AP Mode Port forwarding解決方案
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2516 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類的
=>要找Android or iOS AP Mode P
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2515 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類
- =>要找Android or iOS AP Mode
+ =>要找Android or iOS AP Mode P
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2514 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之ＭＡ
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之類
=>要找Android or iOS AP Mode
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2512 – r2513 | |
顯示 diff（222 行未修改）
|
||
| 2015-12-25 13:27 | r2511 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示Ａ
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示之ＭＡ
=>要找Android or iOS AP Mode
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2510 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示Ａ
- =>要找Android or iOS AP Mod
+ =>要找Android or iOS AP Mode
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2509 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯Ｒ
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯示Ａ
=>要找Android or iOS AP Mod
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2508 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯Ｒ
- =>要找Android or iOS AP
+ =>要找Android or iOS AP Mod
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2507 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來ＤＷＷ
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來顯Ｒ
=>要找Android or iOS AP
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2506 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來ＤＷＷ
- =>要找Android or iOS
+ =>要找Android or iOS AP
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2505 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來ＤＷＷ
=>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2504 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來
- =>要找Android or iOS
+ =>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2503 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一來
=>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2502 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一
- =>要找Android or iOS por
+ =>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2501 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串Ｌ
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串一
=>要找Android or iOS por
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2500 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串Ｌ
- =>要找Android or iOS port
+ =>要找Android or iOS por
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2499 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串Ｌ
=>要找Android or iOS port
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2498 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串
- =>要找Android or iOS por
+ =>要找Android or iOS port
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2497 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字串
=>要找Android or iOS por
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2496 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
- =>要找Android or iOS po
+ =>要找Android or iOS por
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2495 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字蟲
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
=>要找Android or iOS po
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2494 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字蟲
- =>要找Android or iOS p
+ =>要找Android or iOS po
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2493 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字蟲
=>要找Android or iOS p
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2492 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
- =>要找Android or iOS
+ =>要找Android or iOS p
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2491 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字久
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
=>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2490 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字久
- =>要找Android or iOS
+ =>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2488 – r2489 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字久
=>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2486 – r2487 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
- =>要找Android iOS
+ =>要找Android or iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2484 – r2485 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以送字
=>要找Android iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2481 – r2483 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以
- =>要找Android
+ =>要找Android iOS
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2480 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可以
=>要找Android
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2479 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可
- =>要找Android
+ =>要找Android
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2478 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家可
=>要找Android
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2477 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家
- =>要找And
+ =>要找Android
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2476 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大家
=>要找And
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2475 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大
- =>要找Ad
+ =>要找And
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2474 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，大
=>要找Ad
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2473 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，
- =>要找A
+ =>要找Ad
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2472 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆，
=>要找A
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2471 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆
- =>要找
+ =>要找A
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2470 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈牆
=>要找
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2468 – r2469 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈
- =
+ =>要找
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2463 – r2467 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
- 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED燈
=
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 | r2462 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED
-
+ =
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:27 – 13:27 | r2460 – r2461 | |
顯示 diff（222 行未修改）
|
||
| 2015-12-25 13:27 – 13:27 | r2458 – r2459 | |
顯示 diff（222 行未修改）
|
||
| 2015-12-25 13:26 – 13:27 | r2376 – r2457 | |
顯示 diff（217 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
+ 我有個想法，就是7688架一個SERVER，走到那帶到那，手機開AP模式給他連，然後其他人可以連進來看資料，或是修改資料，像是：有個LED
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 – 13:25 | r2373 – r2375 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的配置呢？
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 | r2372 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，。
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 – 13:25 | r2368 – r2371 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下你的網路環境的
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，。
|
||
| 2015-12-25 13:25 | r2367 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性，。
|
||
| 2015-12-25 13:25 – 13:25 | r2362 – r2366 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 -
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 - 能否再詳述一下
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 | r2361 | |
顯示 diff（221 行未修改）
|
||
| 2015-12-25 13:25 – 13:25 | r2357 – r2360 | |
顯示 diff（221 行未修改）
|
||
| 2015-12-25 13:25 | r2356 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 -
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 – 13:25 | r2354 – r2355 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能 -
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
|
||
| 2015-12-25 13:25 | r2353 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
|
||
| 2015-12-25 13:25 | r2352 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的工
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的功能
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 | r2351 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的工
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性。
|
||
| 2015-12-25 13:25 | r2350 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxyㄉㄜ
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy的工
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
|
||
| 2015-12-25 13:25 | r2349 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxyㄉㄜ
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時性
|
||
| 2015-12-25 13:25 | r2348 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxyㄉㄜ
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時
|
||
| 2015-12-25 13:25 | r2347 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即時
|
||
| 2015-12-25 13:25 | r2346 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是p
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是proxy
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即
|
||
| 2015-12-25 13:25 | r2345 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是p
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很ＤＵＰ
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很即
|
||
| 2015-12-25 13:25 | r2344 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是p
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很ＤＵＰ
|
||
| 2015-12-25 13:25 | r2343 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很ＤＵＰ
|
||
| 2015-12-25 13:25 | r2342 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding或是
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很
|
||
| 2015-12-25 13:25 | r2341 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒ＭＩＤ
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒很
|
||
| 2015-12-25 13:25 | r2340 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding貨
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒ＭＩＤ
|
||
| 2015-12-25 13:25 | r2339 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding貨
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒ＭＩＤ
|
||
| 2015-12-25 13:25 | r2338 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding貨
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒
|
||
| 2015-12-25 13:25 | r2337 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實沒
|
||
| 2015-12-25 13:25 – 13:25 | r2330 – r2336 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gateway
+ 這跟7688就比較沒關，而是7688所屬網路的gateway本身如何做到port forwarding
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實
|
||
| 2015-12-25 13:25 | r2329 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gateway
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其實
|
||
| 2015-12-25 13:25 | r2328 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的gat
+ 這跟7688就比較沒關，而是7688所屬網路的gateway
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其
|
||
| 2015-12-25 13:25 | r2327 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的gat
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，Ｋ
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，其
|
||
| 2015-12-25 13:25 | r2326 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688所屬網路的ga
+ 這跟7688就比較沒關，而是7688所屬網路的gat
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，Ｋ
|
||
| 2015-12-25 13:25 | r2325 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688所屬網路的ga
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，ＮＯＢＭ
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，Ｋ
|
||
| 2015-12-25 13:25 – 13:25 | r2320 – r2324 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688ㄙ
+ 這跟7688就比較沒關，而是7688所屬網路的ga
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，ＮＯＢＭ
|
||
| 2015-12-25 13:25 | r2319 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688ㄙ
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，ＮＯＢＭ
|
||
| 2015-12-25 13:25 | r2318 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7688
+ 這跟7688就比較沒關，而是7688ㄙ
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，
|
||
| 2015-12-25 13:25 – 13:25 | r2316 – r2317 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7688
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328時，
|
||
| 2015-12-25 13:25 | r2315 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是7
+ 這跟7688就比較沒關，而是7688
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328
|
||
| 2015-12-25 13:25 | r2314 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是7
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接32
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接328
|
||
| 2015-12-25 13:25 | r2313 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而是
+ 這跟7688就比較沒關，而是7
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接32
|
||
| 2015-12-25 13:25 – 13:25 | r2310 – r2312 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而是
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接23
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接32
|
||
| 2015-12-25 13:25 | r2309 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688就比較沒關，而ㄕ
+ 這跟7688就比較沒關，而是
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接23
|
||
| 2015-12-25 13:25 | r2308 | |
顯示 diff（218 行未修改）
這跟7688就比較沒關，而ㄕ
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接2
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接23
|
||
| 2015-12-25 13:25 | r2307 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這跟7688
+ 這跟7688就比較沒關，而ㄕ
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接2
|
||
| 2015-12-25 13:25 | r2306 | |
顯示 diff（218 行未修改）
這跟7688
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接2
|
||
| 2015-12-25 13:25 – 13:25 | r2301 – r2305 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這ep
+ 這跟7688
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接
|
||
| 2015-12-25 13:25 | r2300 | |
顯示 diff（218 行未修改）
這ep
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去接
|
||
| 2015-12-25 13:25 | r2299 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這
+ 這ep
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去
|
||
| 2015-12-25 13:25 | r2298 | |
顯示 diff（218 行未修改）
這
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688去
|
||
| 2015-12-25 13:25 | r2297 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這E
+ 這
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688
|
||
| 2015-12-25 13:25 | r2296 | |
顯示 diff（218 行未修改）
這E
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7688
|
||
| 2015-12-25 13:25 | r2295 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這
+ 這E
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7
|
||
| 2015-12-25 13:25 | r2294 | |
顯示 diff（218 行未修改）
這
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用7
|
||
| 2015-12-25 13:25 | r2293 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這e
+ 這
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
|
||
| 2015-12-25 13:25 | r2292 | |
顯示 diff（218 行未修改）
這e
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
|
||
| 2015-12-25 13:25 | r2291 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這
+ 這e
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
|
||
| 2015-12-25 13:25 | r2290 | |
顯示 diff（218 行未修改）
這
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用JOD
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
|
||
| 2015-12-25 13:25 | r2289 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這ㄍ恩
+ 這
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用JOD
|
||
| 2015-12-25 13:25 | r2288 | |
顯示 diff（218 行未修改）
這ㄍ恩
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用JOD
|
||
| 2015-12-25 13:25 | r2287 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 這ㄍ
+ 這ㄍ恩
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
|
||
| 2015-12-25 13:25 | r2286 | |
顯示 diff（218 行未修改）
這ㄍ
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用J
|
||
| 2015-12-25 13:25 | r2285 | |
顯示 diff（215 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
-
+ 這ㄍ
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
|
||
| 2015-12-25 13:25 | r2284 | |
顯示 diff（218 行未修改）
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，用
|
||
| 2015-12-25 13:25 – 13:25 | r2280 – r2283 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 5k4
+
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，
|
||
| 2015-12-25 13:25 | r2279 | |
顯示 diff（218 行未修改）
5k4
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE說，
|
||
| 2015-12-25 13:25 | r2278 | |
顯示 diff（216 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
- 5
+ 5k4
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE
|
||
| 2015-12-25 13:25 | r2277 | |
顯示 diff（218 行未修改）
5
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BL
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BLUE
|
||
| 2015-12-25 13:25 | r2276 | |
顯示 diff（215 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
-
+ 5
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BL
|
||
| 2015-12-25 13:25 – 13:25 | r2266 – r2275 | |
顯示 diff（218 行未修改）
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為我聽BL
|
||
| 2015-12-25 13:25 | r2265 | |
顯示 diff（215 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
+
（1 行未修改）
|
||
| 2015-12-25 13:25 | r2264 | |
顯示 diff（217 行未修改）
- Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因為
|
||
| 2015-12-25 13:25 | r2263 | |
顯示 diff（215 行未修改）
Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
+
Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因
|
||
| 2015-12-25 13:18 – 13:25 | r2205 – r2262 | |
顯示 diff（214 行未修改）
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
- Q26:7688如果做到用192.168的IP，或
+ Q26:7688當SERVER的娮，如何做到用192.168的IP或用手機架的網路，然後外網可以連到的方法呢?
+
+ Q27:其實我想自已做一個底板，用I2C接，ARDUINO，然後ARDUINO用原本的IDE來寫，這樣MCU反應可以比較即時，有必要這樣做嗎?因
|
||
| 2015-12-25 13:18 | r2204 | |
顯示 diff（207 行未修改）
Q24: 有睡眠模式嗎?
- 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由SW命令降壓的機制。
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由SW命令HW降壓的機制。
Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
（5 行未修改）
|
||
| 2015-12-25 13:18 – 13:18 | r2202 – r2203 | |
顯示 diff（214 行未修改）
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
- Q26:7688如果做到用192.168的I
+ Q26:7688如果做到用192.168的IP，或
|
||
| 2015-12-25 13:18 | r2201 | |
顯示 diff（207 行未修改）
Q24: 有睡眠模式嗎?
- 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由命令降壓的機制。
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由SW命令降壓的機制。
Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
（5 行未修改）
|
||
| 2015-12-25 13:18 | r2200 | |
顯示 diff（214 行未修改）
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
- Q26:7688如果做到用192.168的
+ Q26:7688如果做到用192.168的I
|
||
| 2015-12-25 13:18 | r2199 | |
顯示 diff（207 行未修改）
Q24: 有睡眠模式嗎?
- 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是命令降壓的機制。
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由命令降壓的機制。
Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
（5 行未修改）
|
||
| 2015-12-25 13:18 – 13:18 | r2195 – r2198 | |
顯示 diff（214 行未修改）
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
- Q26:7688如果做到用192
+ Q26:7688如果做到用192.168的
|
||
| 2015-12-25 13:18 | r2194 | |
顯示 diff（207 行未修改）
Q24: 有睡眠模式嗎?
- 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由命令降壓的機制。
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是命令降壓的機制。
Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
（5 行未修改）
|
||
| 2015-12-25 13:18 | r2193 | |
顯示 diff（214 行未修改）
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
- Q26:7688如果做到用1
+ Q26:7688如果做到用192
|
||
| 2015-12-25 13:18 | r2192 | |
顯示 diff（207 行未修改）
Q24: 有睡眠模式嗎?
- 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是命令降壓的機制。
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是由命令降壓的機制。
Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
（5 行未修改）
|
||
| 2015-12-25 13:17 – 13:18 | r2169 – r2191 | |
顯示 diff（213 行未修改）
Here.
https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
+
+ Q26:7688如果做到用1
|
||
| 2015-12-25 13:14 – 13:17 | r2126 – r2168 | |
顯示 diff（204 行未修改）
但20
- ~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+ ~300這個等級，真的只能做gateway，一直插著電
+ Q24: 有睡眠模式嗎?
+ 就我所知沒有特別的low power / power domain的設計，Chipset本身會在idle的時候降頻，不過不像手持裝置會特別切割出可以獨立關閉的domain，或是命令降壓的機制。
- Q24: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
+ Q25: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
Here.
（1 行未修改）
|
||
| 2015-12-25 13:13 – 13:14 | r2115 – r2125 | |
顯示 diff（182 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- QOpenWrt 可以使用 bluez package 1217688做為零件包的話，何時可以普及化?
+ QOpenWrt 可以使用 bluez package .1217688做為零件包的話，何時可以普及化?
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
（21 行未修改）
Q24: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
+
+ Here.
+ https://github.com/MediaTek-Labs/linkit-smart-7688-uboot
|
||
| 2015-12-25 13:13 | r2114 | |
顯示 diff（207 行未修改）
- Q14: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
+ Q24: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
|
||
| 2015-12-25 13:13 – 13:13 | r2112 – r2113 | |
顯示 diff（182 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- QOpenWrt 可以使用 bluez packa1217688做為零件包的話，何時可以普及化?
+ QOpenWrt 可以使用 bluez package 1217688做為零件包的話，何時可以普及化?
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
（23 行未修改）
|
||
| 2015-12-25 13:13 | r2111 | |
顯示 diff（205 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+
+
+ Q14: bootloader 有釋放源碼嗎? 是否有保護，可否修改?
|
||
| 2015-12-25 13:13 – 13:13 | r2108 – r2110 | |
顯示 diff（182 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- QOpenWrt 可以使用 bluez 1217688做為零件包的話，何時可以普及化?
+ QOpenWrt 可以使用 bluez packa1217688做為零件包的話，何時可以普及化?
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
（20 行未修改）
|
||
| 2015-12-25 13:13 – 13:13 | r2106 – r2107 | |
顯示 diff（207 行未修改）
|
||
| 2015-12-25 13:07 – 13:13 | r1980 – r2105 | |
顯示 diff（138 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其餘並沒有什麼外星科技。
+
+ Nodejs 不太需要在 linux 上做什麼最佳化，就 follow Node.js 社群架構成長即可。
（27 行未修改）
- *是因為需要多個 wifi interface 嗎? 否則板子本身就支援 WiFi 了Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+ *是因為需要多個 wifi interface 嗎? 否則板子本身就支援 WiFi 了Q
+ 基本上市面上 USB wifi adapter 大多都是 Ralink 5350 系列（特別是Edimax公司出的）確定一下就可以了，至於怎麼做可以參考這個 config: https://gist.github.com/iamblue/00f0c5cf6e987f1b7834
+ 19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
1) 7688自己就有兩組UART可以使用了
（4 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q1217688做為零件包的話，何時可以普及化?
+ QOpenWrt 可以使用 bluez 1217688做為零件包的話，何時可以普及化?
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
（20 行未修改）
|
||
| 2015-12-25 13:03 – 13:06 | r1956 – r1979 | |
顯示 diff（195 行未修改）
另
- 外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
+ 其他scenario Developer's Guide裡面有：
+ http://labs.mediatek.com/fileMedia/download/87c801b5-d1e6-4227-9a29-b5421f2955ac#page=13外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
（2 行未修改）
|
||
| 2015-12-25 13:03 | r1955 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是需要
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是需要的
+ *
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1954 | |
顯示 diff（193 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
+ 另
+ 外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
（2 行未修改）
|
||
| 2015-12-25 13:03 – 13:03 | r1952 – r1953 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是需要
Q8: 有什麼配合的周邊？
（75 行未修改）
|
||
| 2015-12-25 13:03 | r1951 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- 補沖一下
|
||
| 2015-12-25 13:03 – 13:03 | r1949 – r1950 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是難的
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1948 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- 補沖一下，
+ 補沖一下
|
||
| 2015-12-25 13:03 | r1947 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是ＲＣ
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是難的
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1946 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- 補衝一ㄒㄧ
+ 補沖一下，
|
||
| 2015-12-25 13:03 | r1945 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是ＲＣ
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1944 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- 補
+ 補衝一ㄒㄧ
|
||
| 2015-12-25 13:03 | r1943 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo是
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1942 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+ 補
|
||
| 2015-12-25 13:03 | r1941 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實d
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實duo
Q8: 有什麼配合的周邊？
（75 行未修改）
|
||
| 2015-12-25 13:03 | r1940 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- ㄅ
|
||
| 2015-12-25 13:03 | r1939 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實d
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1938 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+ ㄅ
|
||
| 2015-12-25 13:03 | r1937 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其Ｎ
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其實
Q8: 有什麼配合的周邊？
（75 行未修改）
|
||
| 2015-12-25 13:03 | r1936 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- ㄅ
|
||
| 2015-12-25 13:03 | r1935 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其Ｎ
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1934 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- ㄅㄨˇㄔ
+ ㄅ
|
||
| 2015-12-25 13:03 | r1933 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，其
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 – 13:03 | r1931 – r1932 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- ㄅㄨ
+ ㄅㄨˇㄔ
|
||
| 2015-12-25 13:03 | r1930 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
- *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體，
Q8: 有什麼配合的周邊？
（76 行未修改）
|
||
| 2015-12-25 13:03 | r1929 | |
顯示 diff（198 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+ ㄅㄨ
|
||
| 2015-12-25 13:02 – 13:03 | r1885 – r1928 | |
顯示 diff（120 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
*有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
+ *如果自已有做板子的能力，7688就夠了，沒有，又不太會硬體
Q8: 有什麼配合的周邊？
（75 行未修改）
|
||
| 2015-12-25 13:01 – 13:01 | r1870 – r1884 | |
顯示 diff（148 行未修改）
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
*這只是reset而已吧，平常好像是幾百個ns
+ *不過這樣的 timming 就不能用 Linux 了
*
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（46 行未修改）
|
||
| 2015-12-25 12:58 – 12:59 | r1852 – r1869 | |
顯示 diff（165 行未修改）
Q18-1:有沒有大神已經用過確定可以的呢?
- Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+
+ *是因為需要多個 wifi interface 嗎? 否則板子本身就支援 WiFi 了Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
1) 7688自己就有兩組UART可以使用了
（27 行未修改）
|
||
| 2015-12-25 12:56 – 12:56 | r1849 – r1851 | |
顯示 diff（197 行未修改）
|
||
| 2015-12-25 12:54 – 12:54 | r1838 – r1848 | |
顯示 diff（197 行未修改）
|
||
| 2015-12-25 12:53 – 12:53 | r1827 – r1837 | |
顯示 diff（160 行未修改）
*學到了
- Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+ 所以duo才是王道，哈Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
（32 行未修改）
|
||
| 2015-12-25 12:53 – 12:53 | r1817 – r1826 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是個
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是各買一個。XD
+
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（72 行未修改）
|
||
| 2015-12-25 12:53 | r1816 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是幾百個nds
+ *這只是reset而已吧，平常好像是幾百個ns
*
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:52 – 12:53 | r1811 – r1815 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，當然是個
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（72 行未修改）
|
||
| 2015-12-25 12:52 | r1810 | |
顯示 diff（147 行未修改）
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
*這只是reset而已吧，平常好像是幾百個nds
+ *
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1809 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了，
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1808 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是幾百個
+ *這只是reset而已吧，平常好像是幾百個nds
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1807 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜ㄌ
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜了
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1806 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是幾百
+ *這只是reset而已吧，平常好像是幾百個
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1805 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜ㄉ
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜ㄌ
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1804 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是幾
+ *這只是reset而已吧，平常好像是幾百
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1803 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜ㄉ
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1802 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是ＷＷＡ
+ *這只是reset而已吧，平常好像是幾
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1801 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼ㄆ
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼便宜
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1800 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像是
+ *這只是reset而已吧，平常好像是ＷＷＡ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1796 – r1799 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是:
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是: 都這麼ㄆ
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1795 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好像
+ *這只是reset而已吧，平常好像是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1794 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是:
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是:
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1793 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好
+ *這只是reset而已吧，平常好像
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1792 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是:
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1791 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好是
+ *這只是reset而已吧，平常好
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1790 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺是
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1789 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平常好Ｊ
+ *這只是reset而已吧，平常好是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1787 – r1788 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己ㄉㄜ
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己的感覺
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1786 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平ＳＮＯ
+ *這只是reset而已吧，平常好Ｊ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1785 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個，我自
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自己ㄉㄜ
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1784 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，平
+ *這只是reset而已吧，平ＳＮＯ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1783 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買哪一個
+ *有很多人在問 7688 和 7688 Duo 該買哪一個，我自
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1782 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而已吧，
+ *這只是reset而已吧，平
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1779 – r1781 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該買
+ *有很多人在問 7688 和 7688 Duo 該買哪一個
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1777 – r1778 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset而
+ *這只是reset而已吧，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1776 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 該
+ *有很多人在問 7688 和 7688 Duo 該買
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1775 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是reset
+ *這只是reset而
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1774 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo
+ *有很多人在問 7688 和 7688 Duo 該
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1773 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只是rese
+ *這只是reset
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1772 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo 改
+ *有很多人在問 7688 和 7688 Duo
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1770 – r1771 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這只
+ *這只是rese
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1769 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo
+ *有很多人在問 7688 和 7688 Duo 改
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1768 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *這
+ *這只
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 | r1767 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 Duo
+ *有很多人在問 7688 和 7688 Duo
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1766 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
- *
+ *這
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1764 – r1765 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *有很多人在問 7688 和 7688 D
+ *有很多人在問 7688 和 7688 Duo
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:52 | r1763 | |
顯示 diff（146 行未修改）
*
*To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
+ *
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:52 – 12:52 | r1746 – r1762 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
- *
+ *有很多人在問 7688 和 7688 D
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（70 行未修改）
|
||
| 2015-12-25 12:52 | r1745 | |
顯示 diff（192 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
- 目前看起來是沒有
|
||
| 2015-12-25 12:52 | r1744 | |
顯示 diff（119 行未修改）
如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
-
+ *
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（71 行未修改）
|
||
| 2015-12-25 12:51 – 12:52 | r1737 – r1743 | |
顯示 diff（192 行未修改）
但20
~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
+ 目前看起來是沒有
|
||
| 2015-12-25 12:48 – 12:50 | r1726 – r1736 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶佔的問題
- *可是 1-wire data 是跟 clock latch 有關，
+ *
+ *To send a "1", the bus master sends a very brief (1–15 µs) low pulse. To send a "0", the master sends a 60 µs low pulse.
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1725 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶佔的問ㄊㄧ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶佔的問題
*可是 1-wire data 是跟 clock latch 有關，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1724 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶佔的問ㄊㄧ
- *可是 1-wire data 是跟 clock latch 有關
+ *可是 1-wire data 是跟 clock latch 有關，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1723 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶ㄓ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶佔的問ㄊㄧ
*可是 1-wire data 是跟 clock latch 有關
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1722 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶ㄓ
- *可是 1-wire data 是跟 clock latch
+ *可是 1-wire data 是跟 clock latch 有關
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1721 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有搶ㄓ
*可是 1-wire data 是跟 clock latch
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1720 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有
- *可是 1-wire data 是跟 clock latch
+ *可是 1-wire data 是跟 clock latch
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1719 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會ㄧ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會有
*可是 1-wire data 是跟 clock latch
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1718 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會ㄧ
- *可是 1-wire data 是跟 clock latc
+ *可是 1-wire data 是跟 clock latch
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1717 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會ㄧ
*可是 1-wire data 是跟 clock latc
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 – 12:48 | r1714 – r1716 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會
- *可是 1-wire data 是跟 clock la
+ *可是 1-wire data 是跟 clock latc
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1713 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler也會
*可是 1-wire data 是跟 clock la
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 – 12:48 | r1711 – r1712 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler
- *可是 1-wire data 是跟 clock
+ *可是 1-wire data 是跟 clock la
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1710 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime schedul
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime scheduler
*可是 1-wire data 是跟 clock
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1709 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime schedul
- *可是 1-wire data 是跟 clo
+ *可是 1-wire data 是跟 clock
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1708 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sch
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime schedul
*可是 1-wire data 是跟 clo
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1707 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sch
- *可是 1-wire data 是跟
+ *可是 1-wire data 是跟 clo
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1706 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sch
*可是 1-wire data 是跟
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1705 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
- *可是 1-wire data 是跟
+ *可是 1-wire data 是跟
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1704 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sh
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
*可是 1-wire data 是跟
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1703 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sh
- *可是 1-wire data
+ *可是 1-wire data 是跟
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1702 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime she
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime sh
*可是 1-wire data
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 – 12:48 | r1700 – r1701 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime she
- *可是 1-wire
+ *可是 1-wire data
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 – 12:48 | r1696 – r1699 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime she
*可是 1-wire
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1695 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
- *可是 1-wi
+ *可是 1-wire
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1694 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime s
*可是 1-wi
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1693 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime
- *可是 1-
+ *可是 1-wi
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1692 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Real
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Realtime
*可是 1-
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1691 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Real
- *可是 1
+ *可是 1-
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 – 12:48 | r1688 – r1690 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是R
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是Real
*可是 1
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1687 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是R
- *可是 2
+ *可是 1
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1686 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是R
*可是 2
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1685 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是
- *可是
+ *可是 2
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1684 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算是
*可是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1683 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算
- *可是
+ *可是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:48 | r1682 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就算
*可是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:48 | r1681 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就
- *可
+ *可是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 | r1680 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就ㄕ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就
*可
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1679 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就ㄕ
- *
+ *可
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 | r1678 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 -
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - 就ㄕ
*
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 – 12:47 | r1676 – r1677 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 -
- *ㄎㄜㄕ
+ *
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 | r1675 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - r
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 -
*ㄎㄜㄕ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1674 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - r
- *ㄎㄜ
+ *ㄎㄜㄕ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 | r1673 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - ru
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - r
*ㄎㄜ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1672 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - ru
- *
+ *ㄎㄜ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 – 12:47 | r1669 – r1671 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - R
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - ru
*
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1668 | |
顯示 diff（144 行未修改）
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - R
-
+ *
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（44 行未修改）
|
||
| 2015-12-25 12:47 – 12:47 | r1647 – r1667 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面ㄧㄠ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面要穩定驅動1-wire是比較困難的 - R
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1646 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *我會加油的
+ *我會加油的!
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 – 12:47 | r1644 – r1645 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux上面ㄧㄠ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1643 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *我會加油
+ *我會加油的
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1642 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linu
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linux
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1641 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *我會加
+ *我會加油
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1640 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，L
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，Linu
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1639 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *我會
+ *我會加
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1638 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，L
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1637 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *我
+ *我會
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1636 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來看，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1635 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *
+ *我
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1634 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗來
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1633 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *Ｉ有
+ *
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1632 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就驚
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就經驗
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1631 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *Ｉ有ＤＯ
+ *Ｉ有
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1630 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就ㄐㄧㄥ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就驚
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1629 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *Ｉ
+ *Ｉ有ＤＯ
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 | r1628 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但ㄐㄧ
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但就ㄐㄧㄥ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1627 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
- *
+ *Ｉ
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:47 – 12:47 | r1625 – r1626 | |
顯示 diff（143 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，但ㄐㄧ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:47 | r1624 | |
顯示 diff（127 行未修改）
LASS 正在上 7688, 請期待
*我想吃
+ *
Q13: 問目前有沒有已經完成的專案?
（61 行未修改）
|
||
| 2015-12-25 12:46 – 12:47 | r1607 – r1623 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解，如果是說
+ 了解，如果是說1-wire要使用的話，那麼跟node.js就比較沒有關係，主要是系統的schedule latency，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 – 12:46 | r1605 – r1606 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好幫1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好幫手1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1604 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了姐，如果是說
+ 了解，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1603 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好ＹＹＡ1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好幫1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1602 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了，如果是說
+ 了姐，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1601 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好ＹＹＡ1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1600 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了姐，如果是說
+ 了，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1599 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好封1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1598 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了，如果是說
+ 了姐，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1597 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker好1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好封1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1596 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了姐，如果是說
+ 了，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1595 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是maker1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker好1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1594 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不起的想ㄈㄚ
+ *了不起的想法
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1593 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是mak1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是maker1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1592 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不起的ㄒㄧ
+ *了不起的想ㄈㄚ
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1591 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真是1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是mak1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1590 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了姐，如果ㄕ
+ 了姐，如果是說
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1589 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不起
+ *了不起的ㄒㄧ
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1588 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop真1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真是1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1587 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了姐，如
+ 了姐，如果ㄕ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1586 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不
+ *了不起
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1585 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了解
+ 了姐，如
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1584 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShopＪＭＥ1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop真1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1583 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不ㄑㄧㄥ
+ *了不
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1582 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- iCShop1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShopＪＭＥ1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1581 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- 了
+ 了解
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1580 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了不
+ *了不ㄑㄧㄥ
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1579 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- i1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ iCShop1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1578 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄌ
+ 了
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1577 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *了
+ *了不
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1576 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- ic1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ i1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1575 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄌㄧ
+ ㄌ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1574 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *
+ *了
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1573 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄌㄧㄌㄧㄠˇ
+ ㄌㄧ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1572 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *ㄌㄧ拗
+ *
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1571 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄌㄧㄌㄧㄠˇ解
+ ㄌㄧㄌㄧㄠˇ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1570 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *ㄌㄧ
+ *ㄌㄧ拗
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1569 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄌㄧㄌㄧㄠˇ
+ ㄌㄧㄌㄧㄠˇ解
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1568 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *
+ *ㄌㄧ
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1567 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄧ
+ ㄌㄧㄌㄧㄠˇ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1566 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *xu
+ *
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1565 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
- ㄧㄠ
+ ㄧ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1564 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *x
+ *xu
（82 行未修改）
|
||
| 2015-12-25 12:46 | r1563 | |
顯示 diff（142 行未修改）
ds18b20的需求延遲是us等級的，可以試看看
一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
-
+ ㄧㄠ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（45 行未修改）
|
||
| 2015-12-25 12:46 | r1562 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- *
+ *x
（82 行未修改）
|
||
| 2015-12-25 12:46 – 12:46 | r1560 – r1561 | |
顯示 diff（176 行未修改）
iCShop 我昨天下單，已經寄出了
Q
- 1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ ic1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（11 行未修改）
|
||
| 2015-12-25 12:46 | r1559 | |
顯示 diff（105 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
-
+ *
（82 行未修改）
|
||
| 2015-12-25 12:46 – 12:46 | r1537 – r1558 | |
顯示 diff（175 行未修改）
iCShop 我昨天下單，已經寄出了
- Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ Q
+ 1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（8 行未修改）
但20
- ~300這個等級，真的只能做gateway，一直插著電，
+ ~300這個等級，真的只能做gateway，一直插著電，他有睡眠模式嗎?
|
||
| 2015-12-25 12:46 – 12:46 | r1535 – r1536 | |
顯示 diff（98 行未修改）
常見的相關參考資料，發問前，請先參考 - FAQ
-
-
-
- Ｑ1 : 如何入門？
（89 行未修改）
|
||
| 2015-12-25 12:45 – 12:46 | r1507 – r1534 | |
顯示 diff（189 行未修改）
另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
+
+
+ 但20
+ ~300這個等級，真的只能做gateway，一直插著電，
|
||
| 2015-12-25 12:45 | r1506 | |
顯示 diff（114 行未修改）
Q5 : 有沒有什麼人在教？
-
+ 課程滿多的
Q7 : LinkIt Smart 7688 和 7688 Duo 有什麼差別？
（72 行未修改）
|
||
| 2015-12-25 12:45 | r1505 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
（78 行未修改）
|
||
| 2015-12-25 12:45 | r1504 | |
顯示 diff（114 行未修改）
Q5 : 有沒有什麼人在教？
+
Q7 : LinkIt Smart 7688 和 7688 Duo 有什麼差別？
（72 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1498 – r1503 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套
+
（76 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1496 – r1497 | |
顯示 diff（110 行未修改）
我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
- Q4 : 人多學得快，該去參加哪些臉書群組？哪裏找同好？
（75 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1490 – r1495 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch
-
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch出自己一套SW Stack。
Q4 : 人多學得快，該去參加哪些臉書群組？哪裏找同好？
（77 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1488 – r1489 | |
顯示 diff（115 行未修改）
Q5 : 有沒有什麼人在教？
-
-
- Q6 : 用LinkIt Smart做什麼好玩？
Q7 : LinkIt Smart 7688 和 7688 Duo 有什麼差別？
（72 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1482 – r1487 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版，
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的Wi-Fi開發版，大多會自己branch
（81 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1480 – r1481 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packe
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 | r1479 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版，
（82 行未修改）
|
||
| 2015-12-25 12:45 | r1478 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packet l
+ packe
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 | r1477 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版為ㄌㄜ
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版
（82 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1475 – r1476 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packet latency
+ packet l
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 – 12:45 | r1473 – r1474 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發版為ㄌㄜ
（82 行未修改）
|
||
| 2015-12-25 12:45 | r1472 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packet latency del
+ packet latency
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 | r1471 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的開發
（82 行未修改）
|
||
| 2015-12-25 12:45 | r1470 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packet latency delay.
+ packet latency del
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 | r1469 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙，而不像一般的
（82 行未修改）
|
||
| 2015-12-25 12:45 | r1468 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
- packet latency delay.
+ packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
（44 行未修改）
|
||
| 2015-12-25 12:45 | r1467 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙。
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1464 – r1466 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的 delay 沒有關係
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1463 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙。
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1460 – r1462 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 nod
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 node.js 的
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1459 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來ㄅㄤ
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來幫忙
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1458 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 n
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 nod
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1457 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來ㄅㄤ
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1456 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟 n
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1455 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士來
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1454 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟
（41 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1452 – r1453 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群人士
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1450 – r1451 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，跟
（41 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1446 – r1449 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社群
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1444 – r1445 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處理的，
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1443 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的社
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1442 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local 處
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1441 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的人來
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1440 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 loca
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 local
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1439 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的人
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的人來
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1438 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 l
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 loca
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1437 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt的人
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1436 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分都是
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是 l
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1435 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWr
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWrt
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1434 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分ㄉㄡ
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分都是
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1433 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找Open
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找OpenWr
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1432 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 的部分
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分ㄉㄡ
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1431 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找Open
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1430 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware
+ 一般講 packet delay 都是 ms 等級的。hardware 的部分
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1429 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找上
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1428 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware 呃
+ 一般講 packet delay 都是 ms 等級的。hardware
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1427 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會ㄓㄠ
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會找上
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1426 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hardware
+ 一般講 packet delay 都是 ms 等級的。hardware 呃
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1425 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會ㄓㄠ
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1423 – r1424 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。hard
+ 一般講 packet delay 都是 ms 等級的。hardware
（41 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1421 – r1422 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack來使用，所以才會
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1419 – r1420 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級的。
+ 一般講 packet delay 都是 ms 等級的。hard
（41 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1406 – r1418 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi開發版盡量以符合community的SW stack
（82 行未修改）
|
||
| 2015-12-25 12:44 – 12:44 | r1404 – r1405 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等級ㄉㄜ
+ 一般講 packet delay 都是 ms 等級的。
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1403 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi-Fi
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1402 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms 等ㄐ
+ 一般講 packet delay 都是 ms 等級ㄉㄜ
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1401 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux Wi
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1400 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 ms
+ 一般講 packet delay 都是 ms 等ㄐ
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1399 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓L
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓Linux
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1398 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是 m
+ 一般講 packet delay 都是 ms
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1397 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓L
（82 行未修改）
|
||
| 2015-12-25 12:44 | r1396 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
- 一般講 packet delay 都是
+ 一般講 packet delay 都是 m
（41 行未修改）
|
||
| 2015-12-25 12:44 | r1395 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是盡量
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是讓
（82 行未修改）
|
||
| 2015-12-25 12:43 – 12:44 | r1388 – r1394 | |
顯示 diff（149 行未修改）
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
ds18b20的需求延遲是us等級的，可以試看看
+ 一般講 packet delay 都是
（41 行未修改）
|
||
| 2015-12-25 12:43 – 12:43 | r1380 – r1387 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 768
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 7688的主要想法是盡量
（81 行未修改）
|
||
| 2015-12-25 12:43 | r1379 | |
顯示 diff（161 行未修改）
* or 800khz
*學到了
-
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 | r1378 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smar
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smart 768
（82 行未修改）
|
||
| 2015-12-25 12:43 | r1377 | |
顯示 diff（161 行未修改）
* or 800khz
*學到了
- *
+
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 – 12:43 | r1375 – r1376 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而Link
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而LinkIt Smar
（82 行未修改）
|
||
| 2015-12-25 12:43 | r1374 | |
顯示 diff（161 行未修改）
* or 800khz
*學到了
+ *
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 | r1373 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而L
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而Link
（81 行未修改）
|
||
| 2015-12-25 12:43 | r1372 | |
顯示 diff（160 行未修改）
*有喔,尤其是WS2812,這通訊速度很快的 4
* or 800khz
- *
+ *學到了
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 | r1371 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN主要長處
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而L
（81 行未修改）
|
||
| 2015-12-25 12:43 | r1370 | |
顯示 diff（160 行未修改）
*有喔,尤其是WS2812,這通訊速度很快的 4
* or 800khz
+ *
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 – 12:43 | r1367 – r1369 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN主
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN主要長處
（80 行未修改）
|
||
| 2015-12-25 12:43 | r1366 | |
顯示 diff（158 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的4
+ *有喔,尤其是WS2812,這通訊速度很快的 4
* or 800khz
（30 行未修改）
|
||
| 2015-12-25 12:43 | r1365 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN主
（80 行未修改）
|
||
| 2015-12-25 12:43 | r1364 | |
顯示 diff（158 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的~4
+ *有喔,尤其是WS2812,這通訊速度很快的4
* or 800khz
（30 行未修改）
|
||
| 2015-12-25 12:43 – 12:43 | r1353 – r1363 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器中間的seg
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的segment，當然在這個區段也有很多開發版，而MT7688AN
（80 行未修改）
|
||
| 2015-12-25 12:43 | r1352 | |
顯示 diff（159 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- * or800khz
+ * or 800khz
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:43 – 12:43 | r1350 – r1351 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟微控制器
+ 我想特色主要在於這是一個介於單板電腦跟微控制器中間的seg
（80 行未修改）
|
||
| 2015-12-25 12:43 | r1349 | |
顯示 diff（159 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- *or800khz
+ * or800khz
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1346 – r1348 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟為控制器
+ 我想特色主要在於這是一個介於單板電腦跟微控制器
（80 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1343 – r1345 | |
顯示 diff（159 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- *or800
+ *or800khz
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1342 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟為控制
+ 我想特色主要在於這是一個介於單板電腦跟為控制器
（80 行未修改）
|
||
| 2015-12-25 12:42 | r1341 | |
顯示 diff（159 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- *or8
+ *or800
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1340 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟為空
+ 我想特色主要在於這是一個介於單板電腦跟為控制
（80 行未修改）
|
||
| 2015-12-25 12:42 | r1339 | |
顯示 diff（159 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- *or
+ *or8
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1338 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟ㄨㄟ
+ 我想特色主要在於這是一個介於單板電腦跟為空
（80 行未修改）
|
||
| 2015-12-25 12:42 | r1337 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，可以試看Ｈ
+ ds18b20的需求延遲是us等級的，可以試看看
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1336 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦跟
+ 我想特色主要在於這是一個介於單板電腦跟ㄨㄟ
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1335 | |
顯示 diff（158 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的~4
- *
+ *or
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1334 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，可以試
+ ds18b20的需求延遲是us等級的，可以試看Ｈ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1333 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦
+ 我想特色主要在於這是一個介於單板電腦跟
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1332 | |
顯示 diff（192 行未修改）
|
||
| 2015-12-25 12:42 | r1331 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，可以Ｉ
+ ds18b20的需求延遲是us等級的，可以試
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1330 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦
+ 我想特色主要在於這是一個介於單板電腦
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1329 | |
顯示 diff（192 行未修改）
|
||
| 2015-12-25 12:42 | r1328 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，可
+ ds18b20的需求延遲是us等級的，可以Ｉ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1327 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦
+ 我想特色主要在於這是一個介於單板電腦
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1326 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的~
+ *有喔,尤其是WS2812,這通訊速度很快的~4
*
（30 行未修改）
|
||
| 2015-12-25 12:42 | r1325 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，
+ ds18b20的需求延遲是us等級的，可
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1323 – r1324 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦
+ 我想特色主要在於這是一個介於單板電腦
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1322 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的
+ *有喔,尤其是WS2812,這通訊速度很快的~
*
（30 行未修改）
|
||
| 2015-12-25 12:42 | r1321 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，這
+ ds18b20的需求延遲是us等級的，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1320 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板電腦
+ 我想特色主要在於這是一個介於單板電腦
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1319 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級的，
+ ds18b20的需求延遲是us等級的，這
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1318 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的*
+ *有喔,尤其是WS2812,這通訊速度很快的
*
（30 行未修改）
|
||
| 2015-12-25 12:42 | r1317 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等級
+ ds18b20的需求延遲是us等級的，
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1316 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快的
+ *有喔,尤其是WS2812,這通訊速度很快的*
*
（30 行未修改）
|
||
| 2015-12-25 12:42 | r1315 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us等
+ ds18b20的需求延遲是us等級
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1314 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板店
+ 我想特色主要在於這是一個介於單板電腦
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1313 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是us
+ ds18b20的需求延遲是us等
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1312 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單板
+ 我想特色主要在於這是一個介於單板店
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1311 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是u
+ ds18b20的需求延遲是us
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1310 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於單
+ 我想特色主要在於這是一個介於單板
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1309 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲是
+ ds18b20的需求延遲是u
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1308 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個介於
+ 我想特色主要在於這是一個介於單
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1307 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延遲
+ ds18b20的需求延遲是
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1306 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一個ㄐㄧ
+ 我想特色主要在於這是一個介於
（79 行未修改）
|
||
| 2015-12-25 12:42 | r1305 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延ＣＷ
+ ds18b20的需求延遲
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（39 行未修改）
|
||
| 2015-12-25 12:42 | r1304 | |
顯示 diff（158 行未修改）
*1-wire 沒有 timing 的問題啊
*有喔,尤其是WS2812,這通訊速度很快的
+ *
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1303 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於這是一
+ 我想特色主要在於這是一個ㄐㄧ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1302 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延Ｃ
+ ds18b20的需求延ＣＷ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1301 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很快ㄉㄜ
+ *有喔,尤其是WS2812,這通訊速度很快的
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1300 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於
+ 我想特色主要在於這是一
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1299 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度很ㄎㄨ
+ *有喔,尤其是WS2812,這通訊速度很快ㄉㄜ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1298 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於他
+ 我想特色主要在於
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1297 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊速度ㄏ
+ *有喔,尤其是WS2812,這通訊速度很ㄎㄨ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1296 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於他是
+ 我想特色主要在於他
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1295 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通迅速ㄉㄨ
+ *有喔,尤其是WS2812,這通訊速度ㄏ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1294 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延ＣＳＷ
+ ds18b20的需求延Ｃ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1293 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於ㄊ
+ 我想特色主要在於他是
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1292 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通訊ㄙ
+ *有喔,尤其是WS2812,這通迅速ㄉㄨ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1291 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要在於
+ 我想特色主要在於ㄊ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1290 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這通
+ *有喔,尤其是WS2812,這通訊ㄙ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1289 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延Ｃ
+ ds18b20的需求延ＣＳＷ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1288 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這ㄊㄨ
+ *有喔,尤其是WS2812,這通
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1287 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特色主要
+ 我想特色主要在於
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1286 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求延
+ ds18b20的需求延Ｃ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1285 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,這
+ *有喔,尤其是WS2812,這ㄊㄨ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1283 – r1284 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想特
+ 我想特色主要
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1282 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求Ｐ
+ ds18b20的需求延
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1281 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我想
+ 我想特
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1280 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,ㄓㄜ
+ *有喔,尤其是WS2812,這
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1279 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單，已經寄出
+ iCShop 我昨天下單，已經寄出了
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1278 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求ＺＰＷ
+ ds18b20的需求Ｐ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1277 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 我
+ 我想
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1276 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812,
+ *有喔,尤其是WS2812,ㄓㄜ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1275 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單，以經濟ㄔㄨ
+ iCShop 我昨天下單，已經寄出
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1274 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ 我
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1273 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求Ｚ
+ ds18b20的需求ＺＰＷ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1272 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812ㄝ
+ *有喔,尤其是WS2812,
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1271 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單，以經濟
+ iCShop 我昨天下單，以經濟ㄔㄨ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1270 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜ
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1269 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求ＰＡＷ
+ ds18b20的需求Ｚ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1268 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2812
+ *有喔,尤其是WS2812ㄝ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1267 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單，以ㄐㄧ
+ iCShop 我昨天下單，以經濟
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1266 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜˋ
+ ㄊㄜ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1265 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求ＰＡ
+ ds18b20的需求ＰＡＷ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1264 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單，
+ iCShop 我昨天下單，以ㄐㄧ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1263 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜ
+ ㄊㄜˋ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1262 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS281
+ *有喔,尤其是WS2812
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1261 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求ＰＡＷ
+ ds18b20的需求ＰＡ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1260 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下單
+ iCShop 我昨天下單，
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1259 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ ㄊㄜ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1258 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS21
+ *有喔,尤其是WS281
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1257 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天下
+ iCShop 我昨天下單
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1256 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求ＰＡ
+ ds18b20的需求ＰＡＷ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1255 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS2
+ *有喔,尤其是WS21
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1254 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜ
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1253 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我昨天
+ iCShop 我昨天下
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1252 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需求
+ ds18b20的需求ＰＡ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1251 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WSㄅㄚ
+ *有喔,尤其是WS2
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1250 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜˋ色
+ ㄊㄜ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1249 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我作
+ iCShop 我昨天
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1248 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的需
+ ds18b20的需求
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1247 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WSㄉ
+ *有喔,尤其是WSㄅㄚ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1246 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊㄜ
+ ㄊㄜˋ色
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1245 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop 我
+ iCShop 我作
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1244 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的Ｕ
+ ds18b20的需
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1243 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是WS
+ *有喔,尤其是WSㄉ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1242 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄐ
+ ㄊㄜ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1241 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCShop
+ iCShop 我
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1240 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的
+ ds18b20的Ｕ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1239 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是W
+ *有喔,尤其是WS
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1238 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄐ夜
+ ㄐ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1237 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iCS
+ iCShop
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1236 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的延
+ ds18b20的
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1235 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其是
+ *有喔,尤其是W
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1234 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ ㄐ夜
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1233 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- iC
+ iCS
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1232 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄧ
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1231 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- i
+ iC
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1230 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其
+ *有喔,尤其是
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1229 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄧㄐㄝ
+ ㄧ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1228 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的Ｐ
+ ds18b20的延
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1227 | |
顯示 diff（178 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～有更新的時候再update上來
+ i
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:42 | r1226 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,由其實
+ *有喔,尤其
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1225 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ ㄧㄐㄝ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1224 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20的
+ ds18b20的Ｐ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1223 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,尤其ㄕ
+ *有喔,由其實
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1222 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄐ業餘
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1221 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b20
+ ds18b20的
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1220 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,由
+ *有喔,尤其ㄕ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1219 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄐㄧ
+ ㄐ業餘
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1218 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,
+ *有喔,由
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1217 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 皆
+ ㄐㄧ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1216 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18b
+ ds18b20
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1215 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是比
+ *有喔,
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1214 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 皆逾
+ 皆
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1213 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds18
+ ds18b
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1212 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是比較
+ *有喔,只是比
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1211 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ds
+ ds18
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1210 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ 皆逾
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1209 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是比較鬆
+ *有喔,只是比較
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1207 – r1208 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
-
+ ds
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1205 – r1206 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是比較
+ *有喔,只是比較鬆
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1204 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- Ｎ
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1203 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是比
+ *有喔,只是比較
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1202 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
-
+ Ｎ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1201 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,只是
+ *有喔,只是比
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1200 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- 寫
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1199 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,ㄓ
+ *有喔,只是
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1198 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
-
+ 寫
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1197 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔,
+ *有喔,ㄓ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1195 – r1196 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ＮＧＮ
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1194 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有喔
+ *有喔,
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1192 – r1193 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ＮＧＮ四
+ ＮＧＮ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1191 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- ㄊ
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1190 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ＮＧＮ
+ ＮＧＮ四
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1189 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *有
+ *有喔
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1188 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ ㄊ
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1187 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
-
+ ＮＧＮ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1186 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *
+ *有
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1185 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- Ｎ
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1184 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *ㄧ
+ *
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1183 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ＮＧ寫
+ Ｎ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1182 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *ㄧˇ喔
+ *ㄧ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1181 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 1
+
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1180 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
- ＮＧ
+ ＮＧ寫
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1179 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *ㄧ
+ *ㄧˇ喔
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1178 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 1)
+ 1
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1177 | |
顯示 diff（172 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q2
+
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:42 | r1176 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
-
+ ＮＧ
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1175 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *u
+ *ㄧ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1174 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
- 1
+ 1)
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1173 | |
顯示 diff（172 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q20-1
+ Q2
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:42 | r1172 | |
顯示 diff（157 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *u.
+ *u
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 | r1171 | |
顯示 diff（108 行未修改）
Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
-
+ 1
（78 行未修改）
|
||
| 2015-12-25 12:42 | r1170 | |
顯示 diff（172 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q20-1: h
+ Q20-1
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:42 | r1169 | |
顯示 diff（148 行未修改）
packet latency delay.
目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（38 行未修改）
|
||
| 2015-12-25 12:42 | r1168 | |
顯示 diff（156 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
*1-wire 沒有 timing 的問題啊
- *
+ *u.
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1164 – r1167 | |
顯示 diff（171 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q20-1: hardware 有 BT4
+ Q20-1: h
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1162 – r1163 | |
顯示 diff（155 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
- *1-wire 沒有 timing 的問題啊\
+ *1-wire 沒有 timing 的問題啊
+ *
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1160 – r1161 | |
顯示 diff（170 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
- Q20-1: hardware 有 B
+ Q20-1: hardware 有 BT4
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:42 | r1159 | |
顯示 diff（155 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
- *1-wire 沒有 timing 的問題啊
+ *1-wire 沒有 timing 的問題啊\
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（29 行未修改）
|
||
| 2015-12-25 12:42 – 12:42 | r1146 – r1158 | |
顯示 diff（170 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
+ Q20-1: hardware 有 B
Q1217688做為零件包的話，何時可以普及化?
（14 行未修改）
|
||
| 2015-12-25 12:41 – 12:41 | r1138 – r1145 | |
顯示 diff（147 行未修改）
Q15-1:Delay function
packet latency delay.
- 目前
+ 目前spec上面並沒有這樣的數字，需要測試才能夠知道。能否推薦一個test case呢？
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（36 行未修改）
|
||
| 2015-12-25 12:41 | r1137 | |
顯示 diff（150 行未修改）
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
- 應
+
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
（33 行未修改）
|
||
| 2015-12-25 12:41 | r1136 | |
顯示 diff（147 行未修改）
Q15-1:Delay function
packet latency delay.
-
+ 目前
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（36 行未修改）
|
||
| 2015-12-25 12:41 – 12:41 | r1134 – r1135 | |
顯示 diff（150 行未修改）
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
- 應該行吧！
+ 應
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
（33 行未修改）
|
||
| 2015-12-25 12:41 – 12:41 | r1130 – r1133 | |
顯示 diff（188 行未修改）
|
||
| 2015-12-25 12:41 | r1129 | |
顯示 diff（155 行未修改）
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
- *1-wire 沒有 timing
+ *1-wire 沒有 timing 的問題啊
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（28 行未修改）
|
||
| 2015-12-25 12:41 | r1128 | |
顯示 diff（147 行未修改）
Q15-1:Delay function
packet latency delay.
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（36 行未修改）
|
||
| 2015-12-25 12:40 – 12:41 | r1106 – r1127 | |
顯示 diff（149 行未修改）
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+ 應該行吧！
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
+ *1-wire 沒有 timing
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（28 行未修改）
|
||
| 2015-12-25 12:40 | r1105 | |
顯示 diff（145 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- *Q15-1:Delay function
+ Q15-1:Delay function
packet latency delay.
（35 行未修改）
|
||
| 2015-12-25 12:40 – 12:40 | r1091 – r1104 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
*Q15-1:Delay function
- packet l
+ packet latency delay.
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（34 行未修改）
|
||
| 2015-12-25 12:40 | r1090 | |
顯示 diff（145 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Q15-1:Delay function
+ *Q15-1:Delay function
packet l
（35 行未修改）
|
||
| 2015-12-25 12:40 – 12:40 | r1085 – r1089 | |
顯示 diff（146 行未修改）
請問這邊指的延遲時間是指？
Q15-1:Delay function
-
+ packet l
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（34 行未修改）
|
||
| 2015-12-25 12:40 | r1084 | |
顯示 diff（144 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
- *請問這邊指的延遲時間是指？
+ 請問這邊指的延遲時間是指？
Q15-1:Delay function
（36 行未修改）
|
||
| 2015-12-25 12:40 | r1083 | |
顯示 diff（146 行未修改）
*請問這邊指的延遲時間是指？
Q15-1:Delay function
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（34 行未修改）
|
||
| 2015-12-25 12:40 | r1082 | |
顯示 diff（144 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
- 請問這邊指的延遲時間是指？
+ *請問這邊指的延遲時間是指？
Q15-1:Delay function
（35 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1078 – r1081 | |
顯示 diff（171 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理
+ 這個我目前沒有答案～有更新的時候再update上來
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1077 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- LASS 正在上 7688, 請其
+ LASS 正在上 7688, 請期待
*我想吃
（47 行未修改）
|
||
| 2015-12-25 12:39 | r1076 | |
顯示 diff（171 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理商方
+ 這個我目前沒有答案～代理
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1075 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- LASS 正在上 7688,
+ LASS 正在上 7688, 請其
*我想吃
（47 行未修改）
|
||
| 2015-12-25 12:39 | r1074 | |
顯示 diff（171 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理商方面
+ 這個我目前沒有答案～代理商方
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1062 – r1073 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *我ㄒ
+ LASS 正在上 7688,
+ *我想吃
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1061 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理商方ㄇㄧㄢ
+ 這個我目前沒有答案～代理商方面
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1060 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *我ㄒ養吃
+ *我ㄒ
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1059 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理商ㄈ
+ 這個我目前沒有答案～代理商方ㄇㄧㄢ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1058 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *我ㄒ養
+ *我ㄒ養吃
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1057 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理商
+ 這個我目前沒有答案～代理商ㄈ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1056 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *我ㄒ
+ *我ㄒ養
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1055 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～代理
+ 這個我目前沒有答案～代理商
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1054 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *
+ *我ㄒ
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1053 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～ㄉㄞ
+ 這個我目前沒有答案～代理
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1052 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *ji3v
+ *
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1051 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案～
+ 這個我目前沒有答案～ㄉㄞ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1049 – r1050 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *ji
+ *ji3v
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1048 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有答案
+ 這個我目前沒有答案～
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1047 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
- *
+ *ji
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 | r1046 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個我目前沒有
+ 這個我目前沒有答案
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1045 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
-
+ *
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1041 – r1044 | |
顯示 diff（170 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這個沃穆
+ 這個我目前沒有
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1040 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
KitchBot打算拿來煮牛排，但還在開發中
+
Q13: 問目前有沒有已經完成的專案?
（46 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1038 – r1039 | |
顯示 diff（169 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這ㄍㄜ
+ 這個沃穆
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1036 – r1037 | |
顯示 diff（179 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降
+ 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降低
|
||
| 2015-12-25 12:39 – 12:39 | r1034 – r1035 | |
顯示 diff（169 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這ㄍㄜ˙
+ 這ㄍㄜ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1033 | |
顯示 diff（179 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會在ㄐㄧ
+ 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會再降
|
||
| 2015-12-25 12:39 | r1032 | |
顯示 diff（169 行未修改）
是Q21-1:的，何時在台灣可以容易買到
- 這ㄍㄜ
+ 這ㄍㄜ˙
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 | r1031 | |
顯示 diff（179 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會在
+ 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會在ㄐㄧ
|
||
| 2015-12-25 12:39 | r1030 | |
顯示 diff（168 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
是Q21-1:的，何時在台灣可以容易買到
-
+ 這ㄍㄜ
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（8 行未修改）
|
||
| 2015-12-25 12:39 – 12:39 | r1027 – r1029 | |
顯示 diff（179 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,
+ 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,耗電量會在
|
||
| 2015-12-25 12:39 | r1026 | |
顯示 diff（168 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
是Q21-1:的，何時在台灣可以容易買到
+
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（9 行未修改）
|
||
| 2015-12-25 12:38 – 12:39 | r1001 – r1025 | |
顯示 diff（178 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另ㄨ愛
+ 另外我想補充的是,這測試是經過內部的LDO把5V降成3.3V,所以如果你用比較好一點的Switching power supply,
|
||
| 2015-12-25 12:38 | r1000 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在開發
+ KitchBot打算拿來煮牛排，但還在開發中
Q13: 問目前有沒有已經完成的專案?
（45 行未修改）
|
||
| 2015-12-25 12:38 | r999 | |
顯示 diff（178 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- 另ㄨ
+ 另ㄨ愛
|
||
| 2015-12-25 12:38 | r998 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在開發ＩＸ
+ KitchBot打算拿來煮牛排，但還在開發
Q13: 問目前有沒有已經完成的專案?
（45 行未修改）
|
||
| 2015-12-25 12:38 | r997 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
+
+ 另ㄨ
|
||
| 2015-12-25 12:38 | r996 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在開發
+ KitchBot打算拿來煮牛排，但還在開發ＩＸ
Q13: 問目前有沒有已經完成的專案?
（43 行未修改）
|
||
| 2015-12-25 12:38 | r995 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
-
- ㄏ
|
||
| 2015-12-25 12:38 | r994 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在開
+ KitchBot打算拿來煮牛排，但還在開發
Q13: 問目前有沒有已經完成的專案?
（45 行未修改）
|
||
| 2015-12-25 12:38 | r993 | |
顯示 diff（178 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ㄏㄌ
+ ㄏ
|
||
| 2015-12-25 12:38 | r992 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在ＭＫ
+ KitchBot打算拿來煮牛排，但還在開
Q13: 問目前有沒有已經完成的專案?
（45 行未修改）
|
||
| 2015-12-25 12:38 | r991 | |
顯示 diff（178 行未修改）
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ㄏ
+ ㄏㄌ
|
||
| 2015-12-25 12:38 | r990 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在Ｍ
+ KitchBot打算拿來煮牛排，但還在ＭＫ
Q13: 問目前有沒有已經完成的專案?
（45 行未修改）
|
||
| 2015-12-25 12:38 | r989 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
+
+ ㄏ
|
||
| 2015-12-25 12:38 | r988 | |
顯示 diff（179 行未修改）
|
||
| 2015-12-25 12:38 | r987 | |
顯示 diff（179 行未修改）
|
||
| 2015-12-25 12:38 | r986 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在ＭＫ
+ KitchBot打算拿來煮牛排，但還在Ｍ
Q13: 問目前有沒有已經完成的專案?
（43 行未修改）
|
||
| 2015-12-25 12:38 | r985 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,但
|
||
| 2015-12-25 12:38 | r984 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還在
+ KitchBot打算拿來煮牛排，但還在ＭＫ
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r983 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,但是ㄖ
+ ,但
|
||
| 2015-12-25 12:38 | r982 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但還
+ KitchBot打算拿來煮牛排，但還在
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r981 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,但是
+ ,但是ㄖ
|
||
| 2015-12-25 12:38 | r980 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛排，但
+ KitchBot打算拿來煮牛排，但還
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r979 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,
+ ,但是
|
||
| 2015-12-25 12:38 – 12:38 | r974 – r978 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮牛
+ KitchBot打算拿來煮牛排，但
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r973 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
+ ,
|
||
| 2015-12-25 12:38 – 12:38 | r971 – r972 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮綷
+ KitchBot打算拿來煮牛
Q13: 問目前有沒有已經完成的專案?
（43 行未修改）
|
||
| 2015-12-25 12:38 | r970 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,
|
||
| 2015-12-25 12:38 | r969 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮Ｓ
+ KitchBot打算拿來煮綷
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r968 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基
+ ,
|
||
| 2015-12-25 12:38 | r967 | |
顯示 diff（131 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮Ｒ
+ KitchBot打算拿來煮Ｓ
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r966 | |
顯示 diff（177 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本
+ ,基
|
||
| 2015-12-25 12:38 | r965 | |
顯示 diff（129 行未修改）
Q8: 有什麼配合的周邊？
MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
-
Q9: 有什麼特別的應用？
（47 行未修改）
|
||
| 2015-12-25 12:38 | r964 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來煮
+ KitchBot打算拿來煮Ｒ
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r963 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上
+ ,基本
|
||
| 2015-12-25 12:38 | r962 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算拿來
+ KitchBot打算拿來煮
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 – 12:38 | r960 – r961 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這個感應ㄕ
+ ,基本上
|
||
| 2015-12-25 12:38 | r959 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打算
+ KitchBot打算拿來
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r958 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這個感應ㄕㄧˋ
+ ,基本上這個感應ㄕ
|
||
| 2015-12-25 12:38 | r957 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBot打Ｚ
+ KitchBot打算
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r956 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
+ MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊。
（48 行未修改）
|
||
| 2015-12-25 12:38 | r955 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這個感應
+ ,基本上這個感應ㄕㄧˋ
|
||
| 2015-12-25 12:38 | r954 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBotＪ
+ KitchBot打Ｚ
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r953 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這個感
+ ,基本上這個感應
|
||
| 2015-12-25 12:38 | r952 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchBot
+ KitchBotＪ
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r951 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊～
+ MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
（48 行未修改）
|
||
| 2015-12-25 12:38 | r950 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這個
+ ,基本上這個感
|
||
| 2015-12-25 12:38 | r949 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- KitchB
+ KitchBot
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r948 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
+ MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊～
（48 行未修改）
|
||
| 2015-12-25 12:38 | r947 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上這
+ ,基本上這個
|
||
| 2015-12-25 12:38 | r946 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- Kitch
+ KitchB
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r945 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上ㄓ
+ ,基本上這
|
||
| 2015-12-25 12:38 | r944 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- Kit
+ Kitch
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r943 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,基本上
+ ,基本上ㄓ
|
||
| 2015-12-25 12:38 – 12:38 | r941 – r942 | |
顯示 diff（132 行未修改）
Q9: 有什麼特別的應用？
- K
+ Kit
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r940 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼周邊，但
- Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
+ MTK並沒有做什麼周邊，但Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
（48 行未修改）
|
||
| 2015-12-25 12:38 | r939 | |
顯示 diff（133 行未修改）
Q9: 有什麼特別的應用？
-
+ K
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r938 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼周邊，
+ MTK並沒有做什麼周邊，但
Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
（49 行未修改）
|
||
| 2015-12-25 12:38 – 12:38 | r936 – r937 | |
顯示 diff（179 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,機
+ ,基本上
|
||
| 2015-12-25 12:38 | r935 | |
顯示 diff（133 行未修改）
Q9: 有什麼特別的應用？
+
Q13: 問目前有沒有已經完成的專案?
（44 行未修改）
|
||
| 2015-12-25 12:38 | r934 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
- ,
+ ,機
|
||
| 2015-12-25 12:38 | r933 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
- MTK並沒有做什麼
+ MTK並沒有做什麼周邊，
Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
（48 行未修改）
|
||
| 2015-12-25 12:38 | r932 | |
顯示 diff（178 行未修改）
Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
+ ,
|
||
| 2015-12-25 12:37 – 12:38 | r891 – r931 | |
顯示 diff（128 行未修改）
Q8: 有什麼配合的周邊？
+ MTK並沒有做什麼
+ Seeed Studio有出三張Breakout Board可以轉接Grove系列的周邊
+
Q9: 有什麼特別的應用？
（4 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其餘並沒有什麼外星科技。
（36 行未修改）
|
||
| 2015-12-25 12:37 – 12:37 | r888 – r890 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Q15Delay function
+ Q15-1:Delay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 | r887 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於
（36 行未修改）
|
||
| 2015-12-25 12:37 | r886 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- QDelay function
+ Q15Delay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 | r885 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於ㄅ
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其
（36 行未修改）
|
||
| 2015-12-25 12:37 | r884 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Delay function
+ QDelay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 | r883 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於ㄅ
（36 行未修改）
|
||
| 2015-12-25 12:37 | r882 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- !Delay function
+ Delay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 | r881 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk）。其於
（36 行未修改）
|
||
| 2015-12-25 12:37 | r880 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Delay function
+ !Delay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 – 12:37 | r878 – r879 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWr
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWrt Trunk
（36 行未修改）
|
||
| 2015-12-25 12:37 | r877 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Delay funct
+ Delay function
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 | r876 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到Open
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OpenWr
（36 行未修改）
|
||
| 2015-12-25 12:37 | r875 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- Delay fu
+ Delay funct
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:37 – 12:37 | r873 – r874 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OO
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到Open
（36 行未修改）
|
||
| 2015-12-25 12:36 – 12:37 | r871 – r872 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- De
+ Delay fu
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r870 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到O
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到OO
（36 行未修改）
|
||
| 2015-12-25 12:36 | r869 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- D
+ De
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r868 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到O
（36 行未修改）
|
||
| 2015-12-25 12:36 | r867 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DE
+ D
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r866 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓他ㄏㄨㄟ
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓它回到
（36 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r864 – r865 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DEL
+ DE
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r863 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓ㄊㄚ
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓他ㄏㄨㄟ
（36 行未修改）
|
||
| 2015-12-25 12:36 | r862 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY
+ DEL
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r861 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且ㄖㄤ
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且讓ㄊㄚ
（36 行未修改）
|
||
| 2015-12-25 12:36 | r860 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY F
+ DELAY
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r857 – r859 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持（並且ㄖㄤ
（36 行未修改）
|
||
| 2015-12-25 12:36 | r856 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY FUBN
+ DELAY F
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r855 | |
顯示 diff（136 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的ㄓ
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的支持
（36 行未修改）
|
||
| 2015-12-25 12:36 | r854 | |
顯示 diff（141 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY FU
+ DELAY FUBN
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r853 | |
顯示 diff（133 行未修改）
Q13: 問目前有沒有已經完成的專案?
https://hackaday.io/project/8623-lightsaber-stand-for-hackers
+
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（39 行未修改）
|
||
| 2015-12-25 12:36 | r852 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面的ㄓ
（36 行未修改）
|
||
| 2015-12-25 12:36 | r851 | |
顯示 diff（140 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY
+ DELAY FU
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r850 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt上面
（36 行未修改）
|
||
| 2015-12-25 12:36 | r849 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
-
+ https://hackaday.io/project/8623-lightsaber-stand-for-hackers
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（39 行未修改）
|
||
| 2015-12-25 12:36 | r848 | |
顯示 diff（140 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- DELAY
+ DELAY
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r844 – r847 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package再
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package在OpenWrt
（36 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r841 – r843 | |
顯示 diff（140 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
- D
+ DELAY
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r840 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package再
（36 行未修改）
|
||
| 2015-12-25 12:36 | r839 | |
顯示 diff（140 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
-
+ D
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 | r838 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的packag
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的package
（36 行未修改）
|
||
| 2015-12-25 12:36 | r837 | |
顯示 diff（140 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
請問這邊指的延遲時間是指？
+
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（31 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r824 – r836 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在於
+ 主要還是在於RAM/Flash空間，另外打通了Node.js一小部分我們覺得比較重要的packag
（35 行未修改）
|
||
| 2015-12-25 12:36 | r823 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過確定可以的呢
+ Q18-1:有沒有大神已經用過確定可以的呢?
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r822 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還是在
+ 主要還是在於
（35 行未修改）
|
||
| 2015-12-25 12:36 | r821 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過確定可以
+ Q18-1:有沒有大神已經用過確定可以的呢
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r820 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要還ㄕ
+ 主要還是在
（35 行未修改）
|
||
| 2015-12-25 12:36 | r819 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過確定ＴＯ
+ Q18-1:有沒有大神已經用過確定可以
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r818 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主要
+ 主要還ㄕ
（35 行未修改）
|
||
| 2015-12-25 12:36 | r817 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過確ＮＥ
+ Q18-1:有沒有大神已經用過確定ＴＯ
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r816 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主
+ 主要
（35 行未修改）
|
||
| 2015-12-25 12:36 | r815 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過確
+ Q18-1:有沒有大神已經用過確ＮＥ
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r814 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主ㄧㄠ
+ 主
（35 行未修改）
|
||
| 2015-12-25 12:36 | r813 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過ＬＯ
+ Q18-1:有沒有大神已經用過確
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r812 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主ㄧㄠˋ
+ 主ㄧㄠ
（35 行未修改）
|
||
| 2015-12-25 12:36 | r811 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用過
+ Q18-1:有沒有大神已經用過ＬＯ
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r810 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
- 主ㄧㄠ
+ 主ㄧㄠˋ
（35 行未修改）
|
||
| 2015-12-25 12:36 | r809 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有大神已經用
+ Q18-1:有沒有大神已經用過
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r808 | |
顯示 diff（135 行未修改）
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
-
+ 主ㄧㄠ
（35 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r802 – r807 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有沒有
+ Q18-1:有沒有大神已經用
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r801 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
- L
+
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 | r800 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:有
+ Q18-1:有沒有
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r799 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
-
+ L
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r795 – r798 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1:
+ Q18-1:有
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r794 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
- 真ㄎ
+
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 | r793 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-1
+ Q18-1:
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r791 – r792 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
- 真ㄎㄨㄥ
+ 真ㄎ
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 | r790 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18-
+ Q18-1
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r789 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
-
+ 真ㄎㄨㄥ
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 | r788 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q18
+ Q18-
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r787 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
- 5
+
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 | r786 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
- Q
+ Q18
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:36 | r785 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
-
+ 5
Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（38 行未修改）
|
||
| 2015-12-25 12:36 – 12:36 | r783 – r784 | |
顯示 diff（150 行未修改）
可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
+ Q
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（20 行未修改）
|
||
| 2015-12-25 12:35 – 12:36 | r766 – r782 | |
顯示 diff（139 行未修改）
Q15:7688使用node.js，最小的延遲時間是多長?
-
+ 請問這邊指的延遲時間是指？
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（1 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有thread被搶佔時間
+ 我想應該會跟Galileo初代一樣，會有thread被搶佔時間的問題。1-wire相關的應用還是透過獨佔MCU來做會比較保險些。
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（24 行未修改）
|
||
| 2015-12-25 12:35 | r765 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大狀態概200~300mA,w
+ Wifi打開7688待機大狀態概200~300mA,
ifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r764 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有thread被強佔時間
+ 我想應該會跟Galileo初代一樣，會有thread被搶佔時間
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（24 行未修改）
|
||
| 2015-12-25 12:35 – 12:35 | r761 – r763 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大壯代概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大狀態概200~300mA,w
+ ifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r760 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有thread被強佔
+ 我想應該會跟Galileo初代一樣，會有thread被強佔時間
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 | r759 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大狀ㄉㄞ概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大壯代概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r758 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有thread被ㄑ
+ 我想應該會跟Galileo初代一樣，會有thread被強佔
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 | r757 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大狀ㄉㄞ概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r756 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有thread
+ 我想應該會跟Galileo初代一樣，會有thread被ㄑ
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 | r755 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大壯ㄉ概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r754 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有t
+ 我想應該會跟Galileo初代一樣，會有thread
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 | r753 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大壯概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大壯ㄉ概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 | r752 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- 我想應該會跟Galileo初代一樣，會有
+ 我想應該會跟Galileo初代一樣，會有t
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 – 12:35 | r750 – r751 | |
顯示 diff（170 行未修改）
Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
+ Wifi打開7688待機大壯概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:35 – 12:35 | r737 – r749 | |
顯示 diff（144 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
+
+ 我想應該會跟Galileo初代一樣，會有
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（23 行未修改）
|
||
| 2015-12-25 12:35 – 12:35 | r735 – r736 | |
顯示 diff（160 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
- 是Q21-的，何時在台灣可以容易買到
+ 是Q21-1:的，何時在台灣可以容易買到
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（6 行未修改）
|
||
| 2015-12-25 12:35 | r734 | |
顯示 diff（147 行未修改）
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
- 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用ㄋㄜ
+ 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用呢？
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（19 行未修改）
|
||
| 2015-12-25 12:35 | r733 | |
顯示 diff（160 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
- 是Q21的，何時在台灣可以容易買到
+ 是Q21-的，何時在台灣可以容易買到
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（6 行未修改）
|
||
| 2015-12-25 12:35 – 12:35 | r730 – r732 | |
顯示 diff（147 行未修改）
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
- 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於
+ 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於哪種應用ㄋㄜ
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（19 行未修改）
|
||
| 2015-12-25 12:35 | r729 | |
顯示 diff（160 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
- 是Q的，何時在台灣可以容易買到
+ 是Q21的，何時在台灣可以容易買到
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（6 行未修改）
|
||
| 2015-12-25 12:35 | r728 | |
顯示 diff（147 行未修改）
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
- 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle
+ 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle的目的是要用於
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（19 行未修改）
|
||
| 2015-12-25 12:35 | r727 | |
顯示 diff（160 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
- 是的，何時在台灣可以容易買到
+ 是Q的，何時在台灣可以容易買到
Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（6 行未修改）
|
||
| 2015-12-25 12:34 – 12:34 | r691 – r726 | |
顯示 diff（147 行未修改）
Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+ 可能還是要回到OpenWrt支援哪些Wi-Fi USB dongle來看，不過想請問需要在Wi-Fi開發版上面再插USB Wi-Fi dongle
Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
（4 行未修改）
Q2:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，，待有心人士來補完
Q1217688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:34 – 12:34 | r688 – r690 | |
顯示 diff（165 行未修改）
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
- Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
+ Q1237688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:33 – 12:33 | r686 – r687 | |
顯示 diff（170 行未修改）
|
||
| 2015-12-25 12:33 – 12:33 | r681 – r685 | |
顯示 diff（156 行未修改）
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，
- Q10:7688做為零件包的話，何時可以普及化?
+ Q1217688做為零件包的話，何時可以普及化?
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
是的，何時在台灣可以容易買到
- Q11:7688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+ Q1227688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
（4 行未修改）
|
||
| 2015-12-25 12:33 | r680 | |
顯示 diff（154 行未修改）
Q2:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
-
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r679 | |
顯示 diff（171 行未修改）
|
||
| 2015-12-25 12:33 | r678 | |
顯示 diff（155 行未修改）
Q2:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該是
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前
Q10:7688做為零件包的話，何時可以普及化?
（11 行未修改）
|
||
| 2015-12-25 12:33 | r677 | |
顯示 diff（153 行未修改）
2) USB-Serial device有kmod-usb-serial可以試試看，我沒有試過～
- Q:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
+ Q2:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該是
（13 行未修改）
|
||
| 2015-12-25 12:33 | r676 | |
顯示 diff（155 行未修改）
Q:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該是
Q10:7688做為零件包的話，何時可以普及化?
（11 行未修改）
|
||
| 2015-12-25 12:33 | r675 | |
顯示 diff（153 行未修改）
2) USB-Serial device有kmod-usb-serial可以試試看，我沒有試過～
- Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
+ Q:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該
（13 行未修改）
|
||
| 2015-12-25 12:33 – 12:33 | r672 – r674 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通，目前應該
Q10:7688做為零件包的話，何時可以普及化?
（11 行未修改）
|
||
| 2015-12-25 12:33 | r671 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
+
Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:33 | r670 | |
顯示 diff（148 行未修改）
- Q1:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+ Q19:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
1) 7688自己就有兩組UART可以使用了
（17 行未修改）
|
||
| 2015-12-25 12:33 | r669 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要打通
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r668 | |
顯示 diff（148 行未修改）
- Q:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+ Q1:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
1) 7688自己就有兩組UART可以使用了
（17 行未修改）
|
||
| 2015-12-25 12:33 | r667 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會有一些問ㄊㄧ
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問題要
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r666 | |
顯示 diff（148 行未修改）
- Q8:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+ Q:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
1) 7688自己就有兩組UART可以使用了
（17 行未修改）
|
||
| 2015-12-25 12:33 – 12:33 | r662 – r665 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道會ㄧ
+ OpenWrt本身有bluetooth的支持，不過就我知道會有一些問ㄊㄧ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r661 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- Q:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+ Q18:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（20 行未修改）
|
||
| 2015-12-25 12:33 | r660 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我知道
+ OpenWrt本身有bluetooth的支持，不過就我知道會ㄧ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r659 | |
顯示 diff（145 行未修改）
Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
- Q7:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+ Q:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（20 行未修改）
|
||
| 2015-12-25 12:33 – 12:33 | r657 – r658 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我ㄓㄨ
+ OpenWrt本身有bluetooth的支持，不過就我知道
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r656 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500m
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500mA
|
||
| 2015-12-25 12:33 | r655 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過就我
+ OpenWrt本身有bluetooth的支持，不過就我ㄓㄨ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r654 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概5
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概500m
|
||
| 2015-12-25 12:33 | r653 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，不過
+ OpenWrt本身有bluetooth的支持，不過就我
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r652 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概5
|
||
| 2015-12-25 12:33 | r651 | |
顯示 diff（143 行未修改）
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
- Q:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
+ Q17:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
Q7:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（22 行未修改）
|
||
| 2015-12-25 12:33 | r650 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)大概
|
||
| 2015-12-25 12:33 | r649 | |
顯示 diff（143 行未修改）
Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
- Q6:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
+ Q:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
Q7:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
（22 行未修改）
|
||
| 2015-12-25 12:33 | r648 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSecond)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSeconds)
|
||
| 2015-12-25 12:33 | r647 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持，ㄅㄨ
+ OpenWrt本身有bluetooth的支持，不過
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r646 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSec)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSecond)
|
||
| 2015-12-25 12:33 | r645 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的支持
+ OpenWrt本身有bluetooth的支持，ㄅㄨ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r644 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾micro)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾microSec)
|
||
| 2015-12-25 12:33 | r643 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的ㄓ
+ OpenWrt本身有bluetooth的支持
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r642 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾micr)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾micro)
|
||
| 2015-12-25 12:33 | r641 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth的
+ OpenWrt本身有bluetooth的ㄓ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r640 | |
顯示 diff（141 行未修改）
- Q1:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+ Q16:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
Q6:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
（24 行未修改）
|
||
| 2015-12-25 12:33 | r639 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾mic)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾micr)
|
||
| 2015-12-25 12:33 | r638 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有bluetooth
+ OpenWrt本身有bluetooth的
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r637 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾m)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾mic)
|
||
| 2015-12-25 12:33 | r636 | |
顯示 diff（141 行未修改）
- Q:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+ Q1:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
Q6:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
（24 行未修改）
|
||
| 2015-12-25 12:33 | r635 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有blue
+ OpenWrt本身有bluetooth
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r634 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾m)
|
||
| 2015-12-25 12:33 | r633 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有b
+ OpenWrt本身有blue
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r632 | |
顯示 diff（141 行未修改）
- Q5:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+ Q:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
Q6:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
（24 行未修改）
|
||
| 2015-12-25 12:33 | r631 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身有
+ OpenWrt本身有b
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r630 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<ㄐ)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<幾)
|
||
| 2015-12-25 12:33 | r629 | |
顯示 diff（138 行未修改）
- Q:7688使用node.js，最小的延遲時間是多長?
+ Q15:7688使用node.js，最小的延遲時間是多長?
（27 行未修改）
|
||
| 2015-12-25 12:33 | r628 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<ㄐ)
|
||
| 2015-12-25 12:33 | r627 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本身ㄧ
+ OpenWrt本身有
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r626 | |
顯示 diff（138 行未修改）
- Q4:7688使用node.js，最小的延遲時間是多長?
+ Q:7688使用node.js，最小的延遲時間是多長?
（27 行未修改）
|
||
| 2015-12-25 12:33 | r625 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<ㄍ)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<)
|
||
| 2015-12-25 12:33 | r624 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt本ㄕ
+ OpenWrt本身ㄧ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r623 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<)
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<ㄍ)
|
||
| 2015-12-25 12:33 | r622 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt
+ OpenWrt本ㄕ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r621 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間()
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間(<)
|
||
| 2015-12-25 12:33 | r620 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWr
+ OpenWrt
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r619 | |
顯示 diff（134 行未修改）
- Q1 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
+ Q14 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（31 行未修改）
|
||
| 2015-12-25 12:33 | r618 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrㄔ
+ OpenWr
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r617 | |
顯示 diff（134 行未修改）
- Q : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
+ Q1 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（31 行未修改）
|
||
| 2015-12-25 12:33 | r616 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWr
+ OpenWrㄔ
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r615 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間()
|
||
| 2015-12-25 12:33 | r614 | |
顯示 diff（134 行未修改）
- Q3 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
+ Q : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
（31 行未修改）
|
||
| 2015-12-25 12:33 | r613 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrtu3
+ OpenWr
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r612 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的ㄕㄨㄣ
+ Wifi打開7688待機大概200~300mA,wifi打訊號的瞬間
|
||
| 2015-12-25 12:33 | r611 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrtu
+ OpenWrtu3
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 | r610 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
- Wifi打開7688待機大概200~300mA,wifi打訊號的
+ Wifi打開7688待機大概200~300mA,wifi打訊號的ㄕㄨㄣ
|
||
| 2015-12-25 12:33 | r609 | |
顯示 diff（155 行未修改）
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
- OpenWrt
+ OpenWrtu
Q10:7688做為零件包的話，何時可以普及化?
（10 行未修改）
|
||
| 2015-12-25 12:33 – 12:33 | r580 – r608 | |
顯示 diff（167 行未修改）
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
+ Wifi打開7688待機大概200~300mA,wifi打訊號的
|
||
| 2015-12-25 12:32 – 12:32 | r557 – r579 | |
顯示 diff（160 行未修改）
不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
+ 是的，何時在台灣可以容易買到
Q11:7688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
（4 行未修改）
|
||
| 2015-12-25 12:20 – 12:32 | r469 – r556 | |
顯示 diff（135 行未修改）
Q3 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
+
+
Q4:7688使用node.js，最小的延遲時間是多長?
+
Q5:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
（2 行未修改）
Q7:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+
Q8:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+
+ 1) 7688自己就有兩組UART可以使用了
+ 2) USB-Serial device有kmod-usb-serial可以試試看，我沒有試過～
Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
+
+ OpenWrt
Q10:7688做為零件包的話，何時可以普及化?
+
+ 不是很確定這問題要問的是什麼呢？ 是說目前供貨的區域嗎？
Q11:7688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+
+ 電池可以自己使用穩壓電路即可，不過7688本身是作為Gateway來設計的，功耗並不低，所以在使用時間上面應該會受限。
Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
|
||
| 2015-12-25 12:14 – 12:14 | r467 – r468 | |
顯示 diff（132 行未修改）
Q13: 問目前有沒有已經完成的專案?
+
+
+ Q3 : 因為之前一直強調 7688 有很完善的 node.js 執行環境。想請問是指你們提供比較大的 RAM/FLASH 空間 (相對於目前市面上的 Yun 等等)。使得 node.js 的服務可以在 7688 上有空間發揮。還是說其實你們有針對 node.js 做一些神秘的最佳化?
+
+ Q4:7688使用node.js，最小的延遲時間是多長?
+
+ Q5:7688使用DS18B20溫度感測器，除用使用DUO外，直接上7688的可能性高嗎?
+
+ Q6:7688使用WS2812燈條，除用使用DUO外，直接上7688的可能性高嗎?
+
+ Q7:目前要將7688外接WIFI USB卡的話，有沒有推薦的?
+
+ Q8:7688外接USB UART(FT232RL)來控制UART，目前可行嗎?還是待擴充?
+
+ Q9:7688可否接USB BT4.0的裝置呢，目前可行嗎?還是待擴充?
+
+ Q10:7688做為零件包的話，何時可以普及化?
+
+ Q11:7688是LINKIT系統少數沒有電池支援的系統，是否有電池系統相關開發板可以擴充呢?
+
+ Q12:7688目前都沒提到的功率方面，如果做為一個感測器節點，是否有測量它的功耗了呢?
|
||
| 2015-12-25 03:35 – 03:40 | r278 – r466 | |
顯示 diff（119 行未修改）
Q6 : 用LinkIt Smart做什麼好玩？
- Q7 : LinkIt Smart 7688 和 7688 Due 有什麼差別？
+ Q7 : LinkIt Smart 7688 和 7688 Duo 有什麼差別？
+ Smart 7688上面有MT7688AN，從MT7688AN拉出USB/Ethernet，I2S(Audio)，I2C，SPI（跟SPI Flash共用），不支持Analog Input。
+ 而7688 Duo多加了一顆ATMega32U4，拉出I2C/SPI/Analog Input。USB/Ethernet同樣從MT7688AN拉出來。沒有拉出I2S介面。
+
+ 所以，如果你習於使用Arduino來連接I2C/SPI/ADC，或是你需要一個可以完全獨佔的MCU，Smart 7688 Duo會是比較好的選擇。
+ 如果你有透過I2S播放Audio的需求，或是你並不需要一個獨立的MCU，只想要用Linux做事情，Smart 7688會是比較好的選擇。
Q8: 有什麼配合的周邊？
（4 行未修改）
|
||
| 2015-12-24 13:27 – 13:51 | r90 – r277 | |
顯示 diff- 哈爸陪你問 - 如何成為 open hardware maker (MTK7688篇) - Q&A
+ 哈爸陪你問 - 如何成為 open hardware maker (LinkIt Smart 7688篇) - Q&A
活動大綱
時間：12/25 20:30 - 22:00
方式：臉書線上聊天討論
- 活動主旨：陪伴新手聊 - 如何成為 open hardware maker (MTK7688篇)
+ 活動主旨：陪伴新手聊 - 如何成為 open hardware maker (LinkIt Smart 7688篇)
發起人：哈爸
主答顧問：
- 顧問團：
+ 顧問團：賴建宏, 曾吉弘, Yu-Hsian Sun, 陳柏儒, Vincent Hsu, Michael Huang, 黃傑, 郭長祐, Smallp Tsai, Powerbear Wang, Horng-Yih Lai, Polo Wu, Bang Min Shiue, 黃正全, Ozzy Chiu, 黃偉峻
活動內容：翻轉教育，沒有教學，陪你聊天，給你問
（52 行未修改）
參考
*官方資源
- *[ 請協助加入 ]
+ *LinkIt Smart 7688
*購買資訊
- *[ 請協助加入 ]
+ *iCShop
+ *LinkIt Smart 7688 Duo
+ *LinkIt Smart 7688
+ *LinkIt Others
+ *Cavedu
+ *LinkIt Smart 7688 Duo
+ *Others
*社群資源
+ *臉書
*[ 請協助加入 ]
*文章
+ *[物聯網震撼彈] LinkIt Smart 7688與7688 Duo，超低價重拳出擊
+ *LinkIt Smart 7688 Duo安裝與韌體升級指引
+ *【加速上手】LinkIt Smart 7688學習地圖
+ *【齊頭比較】LinkIt Smart Duo VS. Arduino Yun
+ *有沒有 Duo，重要嗎？
*[ 請協助加入 ]
+ *Video
+ *LinkIt Smart 7688 與 Wio Link（ESP8266）技術沙龍 - mokoversity - 20151223 - DoIT共創公域
+ *LinkIt™ Smart 7688 與 Node.js 的邂逅 - part 1- Maker Cup - 20151210 - #1
*分享
+ *[ Linkit Smart 7688 ] GP 晶片迷你四驅車（Mini 4WD）
+ *[MTK文1/3] LinkIt Smart 7688小案 - WiFi工程車
*[ 請協助加入 ]
*
（9 行未修改）
- Ｑ1 : 有什麼特色？
- A1 :
+ Ｑ1 : 如何入門？
- Q2: 哪些有趣的應用？
+
+ Q2 : 那麼多種 Maker 可以做，為何要做 Open Hardware Maker?
+ A2 : 參考以前哈爸給你問
+
+ Q3 : 有那麼多 Open Hardware, LinkIt Smart 有什麼特色？
+
+
+
+ Q4 : 人多學得快，該去參加哪些臉書群組？哪裏找同好？
+
+
+ Q5 : 有沒有什麼人在教？
+
+
+ Q6 : 用LinkIt Smart做什麼好玩？
+
+ Q7 : LinkIt Smart 7688 和 7688 Due 有什麼差別？
+
+
+ Q8: 有什麼配合的周邊？
+
+ Q9: 有什麼特別的應用？
+
+ Q13: 問目前有沒有已經完成的專案?
|
||
| 2015-12-06 00:59 – 01:02 | r16 – r89 | |
顯示 diff（60 行未修改）
請參與者，有再做東西的，可以分享一下。比較容易找到同好，也容易得到別人的幫助
[ 分享在這裡 ]
+
+ 參考
+ *官方資源
+ *[ 請協助加入 ]
+ *購買資訊
+ *[ 請協助加入 ]
+ *社群資源
+ *[ 請協助加入 ]
+ *文章
+ *[ 請協助加入 ]
+ *分享
+ *[ 請協助加入 ]
+ *
+ *
問與答
為方便追蹤與解答，發問時請直接在此文件中加入新的提問，之後，可將同一個問題發到聊天區，提醒大家已提問。
（3 行未修改）
常見的相關參考資料，發問前，請先參考 - FAQ
- Ｑ1 :
+
+
+ Ｑ1 : 有什麼特色？
A1 :
+
+ Q2: 哪些有趣的應用？
|
||
| 2015-12-05 23:57 – 23:59 | r1 – r15 | |
顯示 diff- Untitled
+ 哈爸陪你問 - 如何成為 open hardware maker (MTK7688篇) - Q&A
- This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!
+ 活動大綱
+ 時間：12/25 20:30 - 22:00
+ 方式：臉書線上聊天討論
+ 活動主旨：陪伴新手聊 - 如何成為 open hardware maker (MTK7688篇)
+ 發起人：哈爸
+ 主答顧問：
+ 顧問團：
+ 活動內容：翻轉教育，沒有教學，陪你聊天，給你問
+
+
+ 聊天 Agenda
+ *20:30 - 20:45 : 大家打打招呼，互相認識認識
+ *20:45 - 21:45 : 隨便大家問答，共筆時間
+ *21:45 - 22:00 : 收攤，結論，看未來要不要再開一次，什麼主題
+ *
+ 聊天規則
+ 進門請禮貌打招呼，離開也請打招呼再離開，線上活動，不介意大家隨時離開
+ 請先報到，如果有正在做東西，可分享的，請跟大家分享
+ 很多人一起聊天，容易混亂，聊完也無法有效收集成果。
+ 所以嘗試用共筆的方式，看看能不能聊出點花樣。
+ 所有地方都是開放大家隨意編輯，請大家多多貢獻與分享，相信來的能人很多，請大家一同幫助 Maker 的新手
+ 覺得這樣聊天對您有幫助，立即邀請您線上好友參與。也可分享 hackpad 資訊，方便大家參與
+
+ 共筆注意事項
+ 請注意，此為公開的紀錄，可公開分享的才寫在這裡。其他在臉書閒聊就好
+ 為減少可能的爭議，本共筆著作係採用 創用 CC 姓名標示-相同方式分享 4.0 國際 授權條款授權。
+
+ 文件生命週期
+ 準備期：會前
+ *公開討論前由顧問團準備常用問題與參考資料。
+ 線上共筆期：會中
+ *活動當下，所有參與人一起共筆。所有想提問的，請於此時期提問完畢
+ 會後整理期：會後一星期
+ *共筆目前的結果會於隔天發布，提供給有興趣的人參考。
+ *針對尚未完成解答的問題，以及想更正補充的問題，於會後一個星期內，繼續整理，煩請大家能繼續共筆，讓解答性更完整。整理期不可提問。
+ 結束封存期：會後一星期之後
+ *文件將封存，不可更改，提供查詢。歡迎另外複製到另外文件中繼續討論。
+ *
+ 顧問準備事項
+ 在當天討論之前，本篇主要是給顧問團提前準備相關的 Q&A, 以及互相認識，聯絡感情之用，希望在當天之前，只有顧問才能看到內容（準備時期，保持點神秘感）。當討論開始，就會開啟權限給所有人可讀寫
+
+ 顧問白板
+ 此區讓大家認識這次的顧問團，請顧問們自行填寫。建議列上正在做的東西，推薦的臉書討論區等
+ [ 顧問在這裡分享 ]
+
+ 哈爸
+ *臉書 自我介紹
+ *開源公益的環境感測系統(LASS)
+
+
+ 參與人員報到區
+ 請報到，歡迎提供聯絡方式（臉書，Email），需要保持神秘感，可用綽號
+
+ [ 在這裡報到 ]
+ Maker1
+ *聯絡方式
+ *
+ Maker 的玩具
+ 請參與者，有再做東西的，可以分享一下。比較容易找到同好，也容易得到別人的幫助
+ [ 分享在這裡 ]
+
+ 問與答
+ 為方便追蹤與解答，發問時請直接在此文件中加入新的提問，之後，可將同一個問題發到聊天區，提醒大家已提問。
+
+ 本問答為個人淺見，僅提供參考。由於是共筆型態，也歡迎大家持續補充與修正
+
+ 常見的相關參考資料，發問前，請先參考 - FAQ
+
+ Ｑ1 :
+ A1 :
|
||
| 2015-12-05 23:57 | r0 | |
顯示 diff+ Untitled
+ This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!
|
||