型番について

• STM32F103 シリーズ
  • http://www.st.com/web/jp/jp/catalog/mmc/FM141/SC1169/SS1031/LN1565
• STM32F103C8
  • http://www.st.com/web/jp/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164476
• リファレンスマニュアル
  • http://www.st.com/web/jp/resource/technical/document/reference_manual/CD00171190.pdf

STM32F103 C8 T6 という型番の読みかた

• C: 48pins
• 8: 64kbytes Flash
• T: LQFP パッケージ
• 6: -40〜85°C

をあらわしています。STM32F103x8 (64k) や STM32F103xB (128k) はスペックシート共通になっています。 (ピン数とFlashのサイズの違いのみなので)

特徴

以下個人的に良さそうと思った点です。

• STM32F103 は USB 1.1 FS (フルスピード=12Mbps) に対応している
• ADC が2つある (チャンネル数は10)
  • 同時サンプリングができそう

Cortex-M3 なので M0 よりはパフォーマンスが良さそうです。一方 FPU や DSP 関係の命令 (SIMDとか) は M0 同様ありません。

クロック

SYSCLK (システムクロック) は

• HSI
  • High Speed Internal ?
• HSE
  • High Speed External ?
• PLL

の3種類のクロックソースがあります。

HSE はさらに HSE バイパスと HSE クリスタルとに別れています。バイパスは発振器のクロックを直接入れるモードです。

PLL のクロックソースにはHSIとHSEがどちらも使えるようになっています。

書きこみ (Lチカ)

例によって環境を整える部分は platformio でやります。

platformio.ini は以下のようにします。nucleo_f103rb は型番違いですが、ほぼほぼ互換性があります。nucleo_f103rb の外部水晶も 8MHz のようで、この場合 mbed の初期化コードは一切変更なしでいけそうです。

本来 boards の追加をもっと簡単にできたらいいのですが、現状の platfromio だとそういうことはできなそうです。

# platformio.ini
# nucleo_f103rb は f103c8t6 とフラッシュサイズとピン数以外は互換
# 外部クロックも 8MHz で同じのためそのまま使える
[env:stm32f103c8t6]
platform = ststm32
framework = mbed
board = nucleo_f103rb

Lチカはこのようにしました

#include "mbed.h"


DigitalOut led(PC_13);
// Serial serial(USBTX, USBRX);


int main() {
	for (;;) {
		led = 1;
		wait(0.5);
		led = 0;
		wait(0.5);
	}
}

PC_13 はボード上のLEDに繋がっています。nucleo_f103rb だと LED1 は PA_5 のようなので、ジェネリック名ではなくピン名で直接指定しています。

書きこみはこれまた ebay で購入した st-link2 を使いました (約400円)。Mac の USB ポートに繋ぐと特に何もしなくても認識するようでした。

ボードと st-link を接続して、USB 接続すると、基板上にも電源供給されます (別途電源供給はいらないようです)

書きこむためまず st-util を起動します。platformio で ststm32 環境をセットアップしておくと st-util もインストール済みのため楽です。

$ ~/.platformio/packages/tool-stlink/st-util
2016-04-14T00:48:41 INFO src/stlink-common.c: Loading device parameters....
2016-04-14T00:48:41 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2016-04-14T00:48:41 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Target voltage is 3254 mV.
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Listening at *:4242...

こんな感じで gdb server として立ちあがります。

別のターミナルから gdb server に接続してバイナリを送りこみます。

$  ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gdb .pioenvs/stm32f103c8t6/firmware.elf 
> target extended-remote localhost:4242
> load
> cont

これでLチカできました。

ref

• USB サンプル
  • http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/CD00158241.pdf
  • http://www2.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries-expansions/stsw-stm32121.html
• mbed の初期化コード
  • mbed-src/targets/cmsis/TARGET_STM/TARGET_STM32F1/TARGET_NUCLEO_F103RB
• mbed ピン名定義
  • mbed/TARGET_NUCLEO_F103RB/TARGET_STM/TARGET_STM32F1/TARGET_NUCLEO_F103RB

割の合わなさ

「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。

フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。

将来性のなさ

「あ、これはただの流行だな」みたいな、5年後には消滅してるなというものは筋が悪い。

標準にそういう機能入るよ、みたいなのを全然違うインターフェイスで実装してたりするのとかがあてはまる。標準で議論されている機能なら、ポリフィルにするのが最も将来無駄にならない。

HTTP2 に向けてキャッシュフレンドリーなリソース構成にしていこうな、という昨今で、何でもかんでもパックや!みたいなのも、今はぎりぎりいいかもしれないけど、既に筋悪い感じがする。

プログラムの見方を変えないラッパー

たとえば Promise はコールバックのちょっとしたラッパーぐらいの機能しかないが、プログラムの見方を変えるという重要な役割を持っているので、意味がある。

しかし単にシンタックスシュガー的なものしか提供していないとかで、何もプログラムの見方が変わっていないのにラッパーがかぶさっているのは、ライブラリとしての意味がない。

「プログラムの理解を助ける」という役割はとても重要だけど、そういう視点で作られているライブラリかどうか、それが割に合うかは難しい。

しかし最悪なのは書き手にとってしかメリットがないというもの。特に実装を全て読まないと使えない系は要注意で、そういう書き手のオナニーで変なラッパーが挟まってるみたいなのは読み手がとても苦労する。これはメリットがないというよりも明確に将来にわたって害となる。

ただし実装を全て読まないといけないものが全てだめかというとそういうわけでもない。実装は読まないと危険だけど可読性はあがるので割に合うこともある。

フルスタック

フレームワークのレールから外れた瞬間アホみたいなマジカルコードを書くことになる。レールから脱線すると必ずハマる。そしてフレームワークの枠組み内で収まるようなアプリケーションはない 。

もし使う場合コピペで実装できる以外のことをしないことがポイントで、「ここはこう書きたいんだ！」という自我を捨ててコピペする機械として生きなければならない。

実際のフルスタックというのは検索して出てきたstackoverflowのコピペで全部やりますよという意味で、なんでもできるという意味ではない。

CSS は必ずプッシュ・JSは場合による

サイトの構成によりますが、ページの表示に必要なものは全てプッシュするべきのようです。

• CSS の全て
• ページの根幹に関わるJSの全て

サーバプッシュの目的

まずサーバプッシュの目的を改めて確認しておくと、これはクリティカルレンダリングパスを削減するためです。

クリティカルレンダリングパスについては クリティカル レンダリング パスのパフォーマンスを分析する | Web Fundamentals - Google Developers がわかりやすいです。

サーバープッシュなしの場合 HTML+CSS 構成のページはクリティカルレンダリングパスが必ず2以上になります。つまり最低でもRTTの2倍の時間がページ表示に加算されます。

これをサーバプッシュで行う場合、HTML+CSSを一度に送り返すので、クリティカルレンダリングパスは1になります。

イメージとしてはHTML内の外部CSSが全てインライン style 要素にしてある場合に似ています。ただしサーバプッシュの場合、適切なキャッシュを効かせることができるケースがあるので、インライン style 要素よりも効率的です。

理想のサーバープッシュ

理想のサーバープッシュを考えるにあたって、ロードされるリソースの分類をしてみます。

負荷がコイルの場合は？

このシミュレーションの負荷は、伝送線路的トランスによる 4:1 (または9:1) のインピーダンス変換器になっている。出力側が50Ωになっているので、増幅器の負荷は200Ω (450Ω) になる。つまり増幅率があがる。

このシミュレーションの場合 450Ω 負荷だと頭うちになっていてあまり意味がないように見える。

なぜエミッタ接地なのか？

電圧増幅+エミッタフォロワみたいな形にしないのは、電圧増幅を伴なう場合エミッタフォロワの意味が薄いから？

を十分流す必要がある以上、負荷抵抗を大きくできない。逆にいうと出力インピーダンスは低くならざるを得ない。出力インピーダンスを直接50Ωとかにマッチングさせるなら、エミッタフォロワを使う意味はない。

ベース接地・エミッタフォロワ

いずれも電流増幅率が1だったり、電圧増幅率が1だったりするので電力増幅に向いてない。

カスコード接続

エミッタ接地の負荷にベース接地をつける形のもの。ミラー効果がなくなるので高い周波数まで増幅できるようになる。ただしトランジスタを2つ縦に繋げるので電源電圧をその分上げる必要がある。

依存の整理

もはや jQuery なしでも簡単に書けそうなスクリプト部分から jQuery 依存を抜きました。また、JSDeferred を Promise で置き換えました。

script 要素の async / defer

script 要素については必要に応じて async や defer をつけるようにし、基本的に外部スクリプトでブロックする可能性を排除しました。

async は script 要素同士で独立している場合無条件につけられます (非シーケンシャル)。defer はページのDOMが構築されたあとに実行されるように遅延されます (シーケンシャル)

defer は DOMContentLoaded 直前にまとめて呼ばれるようです。

外部ライブラリを自分でホスト

外部ライブラリをCDN経由でロードしている部分がありましたが、TLS セッションの無駄遣いな気がするので、自分でホストするように変えました。自分のホストであれば HTTP2 のセッションが生きているので無駄な処理が減りそうです。

動的圧縮から静的圧縮に

h2o で compress: ON とすると accept-encoding に応じて gzip か br で動的に圧縮してクライアントに返却してくれます。

しかし殆ど変更されないライブラリみたいなものは動的にやるのがもったいないので、静的に圧縮するようにしました。特に brotli は圧縮処理が遅い感じなので意味がありそうです。

h2o 的には file.send-compressed: ON にしって、filename.js.gz と filename.js.brを置くようにします。

#!/bin/sh

for f in "$@"
do
        echo "$f"
        gzip --best < "$f"  > "$f".gz
        bro --quality 10 --input "$f" --output "$f".br
done

ブログシステムでのキャッシュ

今まで表示のたびに DB からひいてきてテンプレート処理を行っていましたが、キャッシュするようにしました。もともとそこまで遅いわけではないのですが 、一応これも効果がありました。

ただ、キャッシュを入れるとキャッシュ無効化の処理のために考えることが大変増えます。今のところあまり筋の良い実装ではないのですが、一応動いています。

MathJax のサーバサイド化

[tech] サーバーサイド MathJax で数式表示を高速化する | Fri, Apr 8. 2016 - 氾濫原 別エントリにしました。

いろいろやった結果

キャッシュなしの状態でロードして、DOMContentLoaded まで 300ms を切るぐらいにできました。ただし onload までは2秒〜3秒かかっています。onload まで遅いのは画像のサイズが大きいというのと、あとは主にアドセンスのせいです。

同じ環境で www.google.co.jp のDOMContentLoaded を測ると 170ms ぐらいでしたので、要素数などを比較するといい線まできている気がします。

さらにできることは？

いわゆる minify をやっていないので、これをやる余地がまだあります。しかし結構面倒です。そしてたとえ削れても数kBなので、意味があるのか疑問を持っています。

HTML の断片をうけとって MathJax にかける HTTP サーバ

• https://github.com/mathjax/MathJax-node

幸い MathJax-node という node.js 上で動かせる MathJax があったので、これをそのまま使い、http.Server でラップして、ブログシステムとは別に API サーバを立ち上げました。

#!/usr/bin/env node

var mjAPI = require("mathjax-node/lib/mj-page.js");


mjAPI.start();
mjAPI.config({
	tex2jax: {
		inlineMath: [["\\(","\\)"]],
		displayMath: [ ["$$", "$$"] ]
	},
	extensions: ["tex2jax.js"]
});

var http = require('http');
http.createServer(function (req, res) {
	var html = [];
	req.on('readable', function () {
		var chunk = req.read();
		console.log('readable');
		if (chunk) html.push(chunk.toString('utf8'));
	});
	req.on('end', function() {
		console.log('end');
		console.log('html', html);

		mjAPI.typeset({
			html: html.join(""),
			renderer: "SVG",
			inputs: ["TeX"],
			ex: 6,
			width: 40
		}, function (result) {
			console.log('typeset done');
			console.log(result);

			res.writeHead(200, {'Content-Type': 'text/plain; charset=utf-8'});
			res.end(result.html);
		});
	});
}).listen(13370, '127.0.0.1');
console.log('Server running at http://127.0.0.1:13370/');

ブログシステムからは保存時にこのAPIを呼んでHTMLをフィルタしてDBに保存するようにしました。

ハマりどころ

動的な MathJax だと、ページのコンテナサイズから適切な幅を計算してくれるのですが、サーバサイドだとそれができませんので、適切な横幅を自分で指定する必要がありました。

スマートフォンでの閲覧を考えると、width: 40 ぐらいにして、念のため CSS で svg { max-width: 100% } とかを入れておくとよさそうです。width が大きいと、数式ごとのフォントサイズが変わりまくって大変うっとおしいです。

MathJax-node の速度

MathJax-node はなぜかものすごく遅いです。ライブラリロード済みでも10秒ぐらいかかります。そもそも起動も遅いです。オンデマンドでやるのは無理そうなレベルです。

MathJax の JS のロードを抑制

これに伴なって、MathJax を使わなくても良さそうな場合、JSのロードすらやめるようにしました。

所感

MathJax の JS は2段階ぐらいでロードされるので RTT が長いほど不利になります。サーバサイドでやってしまえばJSを転送する必要も実行する必要もなくなるのでエコです。おかげでロードが結構早くなりました。

しかもページロード直後から数式が完全な形で表示されるので、ページに数式がある場合、体感的な速度は数倍に感じます。

h2o の設定

sudo mkdir /var/log/h2o
sudo chown www-data:adm /var/log/h2o/

YAML の参照を使うとログフォーマットを使いまわせてよいです。まず global に

access-log: &ACCESSLOG
  path: /dev/null
  format: "..."

と書いて、あとは各ホストで path を上書きする形で設定します。

access-log:
  <<: *ACCESSLOG
  path: /var/log/h2o/host.access.log

なおこのYAML参照は h2o 2.0.0 からのサポートのようです。

logrotate の設定

# /etc/logrotate.d/h2o

/var/log/h2o/*.log {
    daily
    missingok
    rotate 90
    compress
    delaycompress
    notifempty
    create 0640 www-data adm 
    sharedscripts
    postrotate
        svc -h /service/h2o
    endscript
}

h2o は daemontools で管理しているので、postrotate では svc を呼んで SIGHUP を送っています。

一旦状態を確認します

sudo logrotate -dv /etc/logrotate.d/h2o

全ログファイルが log does not need rotating になってるはずです。実際に一度実行します

 sudo logrotate -v /etc/logrotate.d/h2o 

/var/lib/logrotate/status を見ると該当するログファイルが記録されているはずです。日付を一日戻して再度実行するとローテートされることが確認できます。

証明書以外にやったこと

一応 mixed content を回避したり、push してみたりしたくていろいろやりました

• はてなスターのスキーム変更
• スター画像のホスト元 (フォトライフ) のドメイン変更 (cdn-akナントカに)
• tumblr のスキーム変更
• facebook ボタン廃止
• twitter ボタンのスキーム変更
• Amazon 画像のドメイン変更 (過去に遡ってエントリ内の画像URLを変更)
• バックエンドアプリケーション (ブログシステム) へ Link: rel=preload を簡単に吐ける機能を追加

h2o での server push の確認方法

h2o は server push したコンテンツのヘッダに x-http2-push: pushed を含めてくれるので、ちゃんと push されてるか確認する一番簡単な方法はこれを見ることっぽいです。

mruby.handler

    paths:
      "/":
        proxy.reverse.url: http://localhost:5001
        proxy.preserve-host: ON
        mruby.handler: |
          require "/srv/www/rewrite_rules.rb"
          lambda do |env|
            RewriteRules.rewrite(env) do
              rewrite '/favicon.ico', '/images/favicon.ico', :break
              rewrite '/apple-touch-icon.png', '/images/apple-touch-icon.png', :break

              rewrite %r{^/2005/colors-canvas\.xhtml$}, '/2005/colors-canvas.html', :permanent
              rewrite %r{^/2005/colors-canvas$}, '/2005/colors-canvas.html', :permanent

              rewrite %r{^/logs/latest$}, '/', :permanent
              rewrite %r{^/logs/latest.rdf$}, '/feed', :permanent
              rewrite %r{^/logs/latest.atom$}, '/feed', :permanent
              rewrite %r{^/latest\.rdf$}, '/feed', :permanent
              rewrite %r{^/blog/index\.(rdf|atom)$}, '/feed', :permanent
              rewrite %r{^/logs(/.+?)(\.(rdf|atom))$}, '/feed', :permanent

              rewrite %r{^/logs(/.+?)(\.(x?html|xml|txt))?$}, '\1', :permanent
              rewrite %r{^/blog(/.+?)(\.(x?html|xml|txt))?$}, '\1', :permanent
              rewrite %r{^/photo$}, '/photo/', :permanent

              rewrite %r{^/(\d\d\d\d/\d\d(/\d\d)?)$}, '/\1/', :permanent
              rewrite %r{^/\d\d\d\d/$}, '/', :redirect

              rewrite %r{^/view-img(/.+?)$}, '\1', :permanent
            end
          end

h2o の path はディレクトリの指定しかできないみたいなので (自動的に末尾スラッシュがついたりする)、rewrite で同時にパス決め打ちのディスパッチも行っています。

rewrite_rules.rb

class RewriteRules
	class RewriteRulesException < Exception
		attr_reader :response
		def initialize(response)
			@response = response
		end
	end

	attr_reader :env
	attr_reader :path

	def self.rewrite(env, &block)
		self.new(env).run(&block)
	end

	def initialize(env, &block)
		@env = env
		@path_orig = "#{env['SCRIPT_NAME']}#{env['PATH_INFO']}"
		@path = @path_orig.dup
	end

	def run(&block)
		begin
			instance_eval(&block)
			if @path != @path_orig
				return [ 307, { 'x-reproxy-url' => path }, [ ] ]
			else
				return [ 399, {}, [ ] ]
			end
		rescue RewriteRulesException => e
			return e.response
		end
	end

	def rewrite(regexp, replace, flag=:continue)
		if @path.gsub!(regexp, replace)
			case flag
			when :redirect
				raise RewriteRulesException.new([ 302, { 'Location' => @path }, [ ] ])
			when :permanent
				raise RewriteRulesException.new([ 301, { 'Location' => @path }, [ ] ])
			when :break
				raise RewriteRulesException.new([ 307, { 'x-reproxy-url' => @path }, [ ] ])
			when :continue
				# nothing
			else
				raise "unsupported flag: #{flag}"
			end
		end
	end
end

require 'rspec'

describe RewriteRules do
	it "should treat :permanent as 302 redirect" do
		env = {
			'PATH_INFO' => '/logs/latest'
		}
		expect(RewriteRules.rewrite(env) {
			rewrite %r{^/logs/latest$}, '/', :permanent
			rewrite %r{^/logs(/.+?)(\.(x?html|xml|txt))?$}, '\1', :permanent
			rewrite %r{^/foobar/}, '/bazbaz/'
		}).to eq( [301, {"Location"=>"/"}, []])
	end

	it "should treat :redirect as 301 redirect" do
		env = {
			'PATH_INFO' => '/logs/piyo.html'
		}
		expect(RewriteRules.rewrite(env) {
			rewrite %r{^/logs/latest$}, '/', :permanent
			rewrite %r{^/logs(/.+?)(\.(x?html|xml|txt))?$}, '\1', :redirect
			rewrite %r{^/foobar/}, '/bazbaz/'
		}).to eq([302, {"Location"=>"/piyo"}, []])
	end

	it "should treat as internal proxy by default" do
		env = {
			'PATH_INFO' => '/foobar/baz'
		}
		expect(RewriteRules.rewrite(env) {
			rewrite %r{^/logs/latest$}, '/', :permanent
			rewrite %r{^/logs(/.+?)(\.(x?html|xml|txt))?$}, '\1', :permanent
			rewrite %r{^/foobar/}, '/bazbaz/'
		}).to eq([307, {"x-reproxy-url"=>"/bazbaz/baz"}, []])
	end

	it "can write logic in dsl" do
		env = {
			'PATH_INFO' => '/foobar/baz',
			'XXX' => true,
		}
		expect(RewriteRules.rewrite(env) {
			if env['XXX']
				rewrite %r{^/foobar/}, '/bazbaz/'
			end
		}).to eq([307, {"x-reproxy-url"=>"/bazbaz/baz"}, []])

		env = {
			'PATH_INFO' => '/foobar/baz',
			'XXX' => false
		}
		expect(RewriteRules.rewrite(env) {
			if env['XXX']
				rewrite %r{^/foobar/}, '/bazbaz/'
			end
		}).to eq([399, {}, []])
	end
end

ところで

rewrite ルールが ruby で書けるということは、すなわち自由にテスト可能であることを意味します。Apache の RewriteRule や nginx の rewrite をテストするのはかなり面倒なので、かなり強力で嬉しい感じがします。

位相反転回路

GND のとりかたが入力側と出力側で逆なので位相が反転します。

この回路、L1 と L2 が結合しているため、これらで1つのコモンモードチョークとして働いてアイソレーションされるために位相反転ができているのですが、なんとかく不思議な感じがします。

自分の中では「コモンモードチョーク」はノーマルモードに影響を与えないイメージなのですが、「コモンモードチョーク」があるおかげでノーマルモードの位相反転ができているのです。ぱっと見だと結線されていない GND 経由 の電流 (すなわちコモンモード) が阻止されることを強くイメージする必要があります。

ところで、結合係数を減らすとどうなるか見てみます。

これはつまりコモンモードチョークとしての機能が失われている場合です。高い結合が得られていない限り機能しなくなくなることがわかりました。

インピーダンス変換器

1:4 のインピーダンス変換器もシミュレーションしてみました。

通常のトランスとの違い

通常のトランスは、一旦電気エネルギーを磁気エネルギーに変換して再度電気エネルギーに変換するという動作をします。なので、高い結合係数と低いコア損失を同時に実現できなければいけません。

伝送線路トランスはコモンモードのアイソレーションによって実現されており、磁気エネルギーはメインのエネルギー伝達に使われていないので、結合係数が高ければコア損失が多少あっても問題になりません。