[py]sqlite3のNoneは文字列のNone

久々のpythonで、ちょっとはまってしまった。
コードを先に示した方がよいだろう。

---

import sqlite3

dbconn = sqlite3.connect('dbtest.db')
dbcur = dbconn.cursor()
dbcur.execute('CREATE TABLE test(id1 INTEGER, id2 INTEGER)')
dbcur.execute('INSERT INTO test(id1) VALUES(?)', (1234,))
dbcur.execute('SELECT * from test')
items = dbcur.fetchall()

print 'item[0]=', str(items[0][0]).encode('hex')
print 'item[1]=', str(items[0][1]).encode('hex')

---

id1とid2というカラム(でよいのかな？)を作り、id1にだけ値を設定する。
そしてSELECTして、id1とid2をencode('hex')して見てみる、というだけだ。

encode('hex')だから、ASCII文字はASCIIコードで出力される。
id2には何も設定していないが、どうなるだろうか？

item[0]= 31323334
item[1]= 4e6f6e65

さあ、予想通りだっただろうか？

item[0]はよそうどおりだったけど、item[1]は「そうくるか！」というのが正直な感想だ。
まさか、"None"を文字列としてASCIIコードにするとはなぁ。。。。

 

おかげで、"None"と出てくるか、エラーになるだろうと思ってやっていたので、発見が遅れてしまった。。。

Bluetooth5.0 FAQ (1) - bandwidth

FAQって、発音の仕方に悩むよねぇ、というのはさておき、Bluetooth5.0のFAQがあったので眺めてみよう。

そういえば、もともとBluetooth4は、BLEだけじゃなく、今までのBR/EDRが入っていたのだが、それが5になってどうなったのだろうか？

変わらないのね。。。
共通になっている内容もあるのだけど、検索して読むと同じキーワードで使われ方が違ったりすることもあって、面倒なのよねぇ。

---

まず、increased bandwidth、ということが出てくる。
バンド幅が広がったということは、周波数帯が広がってチャネルが増えたのだろうか？

[Vol 6, Part B]1.4.1の表を見ると、少なくともBLEについては40chのままのようだ。

なんだ、Secondary Advertisingって？？
まあ、そういう細かいところは見ないようにしないと、終わらん。

 

そもそも、bandwidthと書いているが、出ているのは速度についてだ。
複数chを同時に使うことで、一度に転送できる量を増やすということだろうか？

[Vol 6, Part A]1.Scopeに「LE 2M」という言葉が出てくる。
1M sym/sのモジュレーションは、以下の2つがあり、LE 1Mの方はshallだから必須。

• LE 1M
• LE Coded

そして、2M sym/sのモジュレーションは、LE 2Mだけで、これは必須かどうかはここに書いていなさそうだ。

比較のためCore_v4.2の同じところを見てみたが、そもそもLE 1Mという用語がない。
"4.6 Reference Signal Definition"に、かろうじてBit Rate=1Mb/sという言葉が出てくる程度だ。
なお、Core_v5.0の4.6章には、LE 1MPHYが1Mb/sで、LE 2M PHYが2Mb/sとなっている。

雰囲気からすると、このLE 2Mというのが、bandwidthがx2になったというやつなんじゃなかろうか。
しかし、私は変調方式とかそういうのはさっぱりわからんのだ。。。

 

こういうときは、silexさんのブログを読むに限る。
Bluetooth 5 のはなし｜Wireless・のおと｜サイレックス・テクノロジー株式会社

このブログ自体は5.0が出る前なので情報をたどる形になっているが、速度2倍については、変調方式がPSK変調ではなくGFSK変調のままにすることで実現した、ということらしい。
なんとなく、PSK変調というのはGFSK変調の2倍大変だから、GFSK変調だったら2倍送れるやん、ということのように読み取ったのだが、どうだろうか。。

そしてCore_v5.0の4.6章の最初に、確かに「変調方式はGFSK」と書かれている！
・・・と思ったが、Core_v4.2にもGFSKと書いてあった。
3.1章には、1M sym/sの場合は185kHz以上で、2M sym/sの場合は375kHz以上でやらんといかんよ、と書いているようだが、何の条件なのかがわからん。。。

 

さすがに、GFSKとかのことが少しわからないとまずかろうと思い、検索すると出てきたのはやはりsilexさんのところだった。

変調のはなし(1)｜Wireless・のおと｜サイレックス・テクノロジー株式会社

周波数の違いで1/0を表すのがFSKで、その一種がGFSKらしい。
[Vol 6, Part A]3.1章に図があるが、なんかよくわからんね。
たぶん、A/D変換するときのように、プラスとマイナスが切り替わる瞬間、つまりゼロクロス間隔を見ることで1か0か見分けて、その間隔の監視周期が185kHzだの375kHzだのと言っているのではなかろうか。
無線やってると、ゼロクロスって言葉はよく聞くよねぇ。

 

まあ、あまり調べてないので上記は間違ってるかもしれないが、とにかくGFSKは周波数の違いで1/0を表す方式で、LE 2Mの場合は今までの倍の速度で変調を扱うから2倍の速度を出せる、ということじゃなかろうか。
2倍の速度を出したければ、2倍頑張れ、ということか。
そして、bandwidthがx2というのは、GFSK変調で1/0を表す周波数が倍まで許容されるようになったという意味か。

 

気になるのは、ここが倍の速度になることによる消費電力の増加と、転送時間が半分になることの省電力効果のどちらが大きいか、ということだ。
まあ、チップで違うのだろうけど。

それに、今までBLEで送っていた程度のデータ量を倍の速度で送りたいかというと、あんまりそういう気持ちがしないかもしれん。
どちらかといえば、電源はプラグから取っているからガンガン送るぜ！みたいなときに使うのかも。

CryptoCell

発表されたnRF52840に載っているCryptoCell-310。
CryptoCell-310なのか、CryptoCell-CC310なのかわからないが、長いのでCC310としよう。

ものとしては、ARMのCryptoCell-300シリーズというものがあるらしい。

---

これは、暗号化のコプロセッサらしい。
コプロセッサということは、データを突っ込めば、マイコン側は使わずに計算してくれるということだろう。

暗号化か。。。
JTAGデバッガなどで強引にデータを見られても大丈夫、というよりも、暗号化してデータ保存するのが容易になるよ、というところだろうか？
しかし、暗号化するキーを埋め込んでいたら、それを読み取られると意味がないしなぁ。

 

Nordicのサイトの方には、CC310が提供する特徴として「Key Management Infrastructure」という項目がある。
このKeyは、暗号化キーのことだろうか。

一覧にKey agreementという項目もあるが、この方面に詳しくないので、ぱっと見てわからん。
DHは鍵交換のやり方だったと思うので、これのことを指しているのか。。

 

 

【後藤弘茂のWeekly海外ニュース】ARMの新セキュリティアーキテクチャ「ARMv8-M TrustZone」 - PC Watch

【後藤弘茂のWeekly海外ニュース】ARMがセキュリティ機能を統合した新プロセッサ「Cortex-M23/M33」を発表 - PC Watch

この辺りを読むと、ARMv8-Mにならないとメモリの暗号化までは行かないようだ。
そこまでやりたければ、Cortex-M23/33を使ったマイコンの登場を待つしかないか。

[nrf52]nRF52840

まだnRF52832をあまり使っていないのだが、それに+8したnRF52840というチップがリリースされたようだ。

nRF52840 / Products / Home - Ultra Low Power Wireless Solutions from NORDIC SEMICONDUCTOR

Cortex-M4Fで64MHzというところは同じで、Flashが512KB→1MB、RAMが64KB→256KBと増えている。
電圧は、1.7～3.6V→1.7V～5.5Vと広がっている。

TrustZoneと書いてある。
無理やりデータを引っこ抜かれるときの対策をどうしようか？というときに話題として出てくるのだけど、最近Cortex-M23やM33が出てきたというくらいしか知らない。
一部の機能が使えるとかだろうか？

USBもちょっと気になる。
まあ、自分でUSB対応することはないだろうけど、USBシリアル変換のケーブル無しでデバッグできたりするとちょっと楽かもしれない。

そして、SoftDeviceだが、S140になるらしい。
いつの間にか、nRF5 SDKもv12.2.0がリリースされていたが、その中には入っていないようだ。

 

早くも、Preview-DKができている。

nRF52840 Preview DK / Products / Home - Ultra Low Power Wireless Solutions from NORDIC SEMICONDUCTOR

まあ、早くもというか、Preview-DKが無いとモジュールメーカーが困るからだろうかね。
nRF52832のときは買ったけど、やっぱり一般人が買うものではないな。チップもまだ1.0じゃないので、改版によってすぐ使えなくなるし。

[esp8266]esp-open-sdkのmake後

あれだけ時間がかかったesp-open-sdkのmakeだが、いったい何ができたのだろうか？
追いかけるつもりはないので、ディレクトリの中身だけ眺めておこう。

ああ・・・Non-OS SDKを取り込んでいたのね。

他にも、crosstool-NGやxtensa-lx-106-elfなどコンパイラっぽいディレクトリがあるが、make後に出てきたメッセージではsdkディレクトリ以下に-Iや-Lするディレクトリがあると書かれていた。

sdkディレクトリの中は、Non-OS版と同じようなフォルダ構成になっていた。
こういうときは、WinMergeで比較だ。
えいっ。

差分なし。

xtensa-lx-106-elfをビルドするためにNon-OS版が必要だったということもないと思うので、単にAPIが使えるようにしてあげているだけかもしれん。

 

esp-open-lwipは、lwipのESP版なのか。
lwIP - A Lightweight TCP/IP stack - Summary [Savannah]
lwIPは使ったことが無いのだが、keilで使えるライブラリの一覧で見たことがある。
どうやら、Non-OS版で使われているらしい。

が、使われているということは、ライブラリがあるということだ。
Non-OS版のlibを見ると、liblwip.aとliblwip_536.aが入っている。
sdkと比較して差分がなかったということは、ビルドしてまったく同じものができたか、単にNon-OS版のファイルをコピーしたかだ。
まあ、後者だろう。

では、一体なぜ・・・とmakefileを眺めて、理由が分かった。

lwip: toolchain sdk_patch
ifeq ($(STANDALONE),y)
    make -C esp-open-lwip -f Makefile.open install \
        CC=$(TOOLCHAIN)/bin/xtensa-lx106-elf-gcc \
        AR=$(TOOLCHAIN)/bin/xtensa-lx106-elf-ar \
        PREFIX=$(TOOLCHAIN)
    cp -a esp-open-lwip/include/arch esp-open-lwip/include/lwip esp-open-lwip/include/netif \
        esp-open-lwip/include/lwipopts.h \
        $(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/include/
endif

そう、デフォルトであるSTANDALONE=yの場合のみビルドされるものなのだ。

 

STANDALONE=nの場合は、バイナリ提供されているものはバイナリのまま使う方式だと思うから、気にせずよいということか。

[esp8266]esp-open-sdkのビルド(STANDALONE=n)

やる気が起きないので、久々に仕事と何の関係もなくESP8266のことをやろう。
特に目的が無いので、githubに移動したというRTOS版を動かすことにする。

espressif/ESP8266_RTOS_SDK: Latest ESP8266 SDK based on FreeRTOS

---

まずは、コンパイル環境を作るところから始めるようだ。
以前、Ubuntu on Windowsでやろうとして、提供されたコンパイラが32bit環境でしか動かないようだし、参照しようとしたコンパイル環境がEspressifから出ていなかったので止めた。

RTOS版のRequirementsで紹介されているページも結局は同じコンパイル環境なのだけど、Espressifが紹介しているから、お仕事で使うことになったとしても納得できるだろう。
仕事とは関係なく、といいつつも、やっぱり考えてしまうよねぇ。

pfalcon/esp-open-sdk: Free and open (as much as possible) integrated SDK for ESP8266/ESP8285 chips

今回は、Ubuntu on Windowsではなく、VMware上のXubuntu16.04(64bit)でやる。
普段立ち上げていることが多いのでね。

 

書いてあるとおりに、cloneして、apt-getして、makeする。
モードとして、STANDALONE版とそうでない版があるらしい。
デフォルトはSTANDALONE版になるのだけど、ライセンスがどうのとあるので、そういうグレーなところはなるべく持ち込まないよう、STANDALONE=nで行う。
リンクするくらいだから、なんかうまいことやってくれればうれしいのだがね。

 

VM環境とは言え、そこそこましなビルド環境だと思っているのだが、15分経ってもmakeが終わらない。。
20分くらいかかったようだ。
最後に、コンパイラへのPATHと、includeとライブラリへのパス(-Iと-L)が表示されるので、メモして置いた方がよいだろう。スクリプトにしておくとよいのではないかな。
たぶん、STANDALONE=yだと不要なんじゃなかろうか。

---

ここまでやっておいてなんだが、なぜRTOS版にはコンパイラが別途必要なのだろう？
Requirementsにxccでもgccでもよい、と書いてあるので、実はNon-OS版の環境を持っていれば不要なのだろうか。

いつもgen_misc.shを実行するだけなので、どういうコンパイラを使っているかすら把握してなかったのだな。

[hw]1.27mmシングルを2つ並べてもデュアルにはできなかった

デバッガとして、SEGGERのJ-Link Liteをしばしば使っている。
相手に1.27mmのソケットがある場合はよいのだが、たまにないときがある。
RedBearのBLE nanoなんかがそうだ(mbedとして使う場合が多いのだろうけど)。
前回は無理やりピンを曲げたり、ピンだけ挿したりしてつないだのだけど、どうにも見栄えが悪い。

別の用事で、1.27mmのシングルラインのピンヘッダを折る用事があって、ちょうど5ピンが2つ残っていた。
これを挿せば目的を達するのではないだろうか？

はい、ダメでした。
2.54mmだとできるけど、1.27mmだからか、買ったピンヘッダがそうなのかわからないけど、厚みがあるようだ。

 

こういうのがちょうどよいのだけど、わざわざこれだけ買うというのもなぁ。。。

SWD (2x5 1.27mm) Cable Breakout Board ID: 2743 - $1.95 : Adafruit Industries, Unique & fun DIY electronics and kits

 

あるいは、2列のピンヘッダを自分でハンダ付けして2.54mmで使えるようにするか。
それだったら、J-Link LITEの根っこから生やせばよいのだけどね。

ピンヘッダ　２×５（１０Ｐ）　表面実装用　１．２７ｍｍピッチ: パーツ一般 秋月電子通商 電子部品 ネット通販

[勉]meteorのclient非同期はセッション変数で対応できそう

http://hiro99ma.blogspot.com/2016/12/meteor.html
まさかの続き記事だ。

 

client側で、結果が非同期に戻ってくるので、returnした値を表示させることができない。
どうやって更新したらよいのだろう？というのが前回の疑問だった。

いろいろ調べたが、Meteorには値が更新されると自動的に表示まで更新される機能があるから、コールバックが戻ってきたときに値を更新すれば、無理して同期とか非同期とか考えなくてよいんじゃ無かろうか、というのが今のところの結論だ。

以前はsetInterval()などで監視していたよなぁ、という部分を隠蔽してくれていると思えばよいか。

 

Meteorで初めてのセッション変数 - Meteor Fan (日本語情報)
よくわからないながらも、こちらをまねしながらやると、コールバック関数内でSession.set()すると、その内容が画面に反映された。
うひゃっほう。

 

どうも「returnで値を返すように作り替えないと」と思っていて、Meteorの特徴とも言えるリアクティブというものが見えていなかったようだ。

[勉]Meteor? 非同期?

急きょ、お仕事でほんのちょっとだけ触ることになりそうなmeteorのことを調べておこう。
「めてお」と発音するようだ。
どうしても、CodeSourceryのMentor社が頭をよぎってしまう。。。

 

https://www.meteor.com/

ブラウザで見るサイトを作るときにはだいたいJavaScriptを使うが、そういうアプリを作るためのフレームワークらしい。
・・・済まん、この世界のことが分かっていないので、用語が正しいかすらわからん。

 

私がJavaScriptを使ったときは、動的なHTML画面を作る、という場合だけだった。
定期的に監視して、値が変わったら更新する、とか。
だから、クライアント側で動くJavaScriptと呼ぶことができるだろう。

Meteorの紹介を読むと、サーバサイドもクライアントサイドも両方書ける、というところが利点としてあげられていた。
むかーし、JavaScriptが導入されたときは、サーバで処理するとクライアント数に応じて負荷がかかるから、できることはクライアント側でやってあげましょう、みたいな話を聞いていた。
時代は変わったのね。

 

ともかく、このmeteorというのをインストールして、決まった場所にHTMLやらJavaScriptやらのファイルを置いておくと、自動的に閲覧用の構成を作ってくれるらしい。
ちょっと試したところでは、特にApacheなどもインストールしていないのに3000番ポートにブラウザでアクセスできた。

 

私は一から環境を作るわけでも、サイトを作るわけでもなく、気分転換したいときにサイトを見て不具合があったら修正してくれると助かる、という程度なのだ。
だから、それほど真面目に調べたいわけではない。

---

で、その不具合の1つで聞いているのが、値が非同期で返ってくる処理結果を画面に反映させる処理をまだ書いていない、というやつだった。
あまり分かってないが、JavaScript側に関数を書いておき、そのreturnで戻ってきた値をHTML側で{{value}}みたいな感じで参照することができるようなのだが、処理が非同期なのでreturn時には値がまだない、ということのようだ。

以前、結果が動的に変わる画面書いたときは、setInterval()とかで定期的に結果を監視して、画面表示が変更になりそうだったらelementなんとかに代入して更新させていたように思う。
今回の箇所はコールバックで結果が戻ってくるようだから、そのタイミングで同じようなことをやるのだろうか。

Meteorの説明を読むと、非同期のところを同期にすることでさっぱりさせた、という項目があった。
ならば、JavaScriptでなんとかするんじゃなくて、Meteorのしくみを使ってなんとかするのだろうか？

こういうフレームワークを使うと、解決するのにフレームワークでのやり方があるのか、一般的なやり方でよいのか、そこの見極めが難しいことがあるよなぁ。

 

ざっと検索すると、サーバ側に書いた処理が非同期だった場合のやり方が出てきた。
ただ、今回は、たぶんだけど、非同期なのはサーバ側の処理ではなさそうな気がしている。

Promiseというのを使う例も出てくるが、async/awaitをPromiseの代わりに使うという記事もあった。
Async.wrap()というのはサーバ側だけらしい。

なんとなく、Promiseというのはコールバックを連結して処理を行うようにするのを避けるためのやり方で、コールバックで得られた結果を画面反映させたいというのとはちょっと違うような気もする。

もしクライアント側だけで非同期だったとしても、それをサーバ側に持っていけば、サーバ側なら同期で返す方法があるらしいので、それで済ませてしまうものなのだろうか。。。

だいたい、非同期で処理するということはコンテキストが別になるということだから、コールバックされたコンテキストは関数で呼ばれたときと異なると思うのだ。
Linuxとかだとselect()で待たせる、みたいなやり方があるけど、関数が呼ばれた経路はHTMLのメインスレッドに相当するはずだから、returnせずにコールバックを待たせるとブラウザが固まってしまうんじゃないかと思う。

 

よくやりたいことのような気がするので、探し方が悪い気がしている。。。

→続き記事

[c/c++]strncatはあふれても\0付加しない

一番使っているのはC/C++だが、文字列を扱うことがあまりないので、標準関数が苦手だ。
特に、バッファがぎりぎりしかないときの扱いは、いつも不安なので事前にテストコードを書いている。

昨日書いていて、気付かないままバッファあふれしていたので、調べておこう。
cygwinのgcc 5.4だ。

---

#include 
#include 

int main(int argc, char *argv[])
{
    static char str[3];

    memset(str, '*', sizeof(str));
    snprintf(str, sizeof(str), "123456");
    printf("snprintf=[%s]\n", str);

    memset(str, '*', sizeof(str));
    strncpy(str, "123456", sizeof(str));
    printf("strncpy=[%s]\n", str);

    strncat(str, "123456", sizeof(str));
    printf("strncat=[%s]\n", str);

    return 0;
}

さて、結果はおわかりだろうか？

 

 

snprintf=[12]
strncpy=[123]
strncat=[123123]

strncpy()やstrncat()が\0を付加しないというのは覚えていたのだが、strncat()のnは追加する文字列に対してのもので、バッファ全体に対してのものじゃないのだな。。。
ポインタの先頭から\0を探して、そこから追加していくから、その時点でnに達していたら追加は行わないかと思っていた・・・。
危ないところだった。

 

その回避をしたい場合は、C11から追加された_s系の関数になる。
strncpy_s()やstrncat_s()だ。
こっちはsnprintf()のように、第2引数にバッファのサイズを指定するのだ。

試してみたかったのだが、このgccではc11オプションを付けてもダメだった。
strcpy, strcpy_s - cppreference.com
__STDC_WANT_LIB_EXT1__を1に定義してからコードを書き始めるのだが、__STDC_LIB_EXT1__が未定義だから、そもそも使用できないようだ。