続々・Propeller日記(3)

長嶋 洋一

Propeller日記(1)

Propeller日記(2)

Propeller日記(3)

Propeller日記(4)

Propeller日記(5)

続・Propeller日記(1)

続・Propeller日記(2)

続・Propeller日記(3)

続・Propeller日記(4)

続・Propeller日記(5)

続々・Propeller日記(1)

続々・Propeller日記(2)

続々・Propeller日記(4)

2013年2月4日(月)

「続々」もPart3である。放課後のアカペラをお休みにして、錯視の北岡先生の講演を聞く、という日である。 午後には、福祉関係の機器を個人的活動として製作している、R社の秋田さんが研究室に来訪して、力作を見せてもらって議論した。 これはぜひ、新学期に特別講義かHMACS勉強会の場で、皆んなにお披露目したい。 そしてこの日は、ここまでの「Propeller日記」「続・Propeller日記」「続々・Propeller日記」を全てザッと読む、という作業に終始した。 全部で10カ所ほどの修正を加えつつ、Propellerとの楽しい日々を反復するとともに、 実際には明日以降になる、アナログ入力のチェックに関する情報が既に書かれているところなどを確認した。 今日はこれでオシマイである。(^_^;)

2013年2月5日(火)

昨日の、錯視の北岡先生の講演はとても面白かった。帰宅せず遅くまで待った甲斐があった(^_^)。 とりあえず、記録としては このページ を残した。 さらに昨日はその前に、ザッとメディアデザインウイークの展示を見て回り、 このページ を作っておいた。 そして、まだ全部の資料は届いていないのでこれからだが、 このページ も増補しておいた。

さて今日であるが、2件も別々の医者に行く、という外出があったので、なんだか午前中は落ち着かなかった。 そして午後イチになると、一昨日から今シーズンも飲み始めた花粉症の薬が効いてきて、 ウトウトしつつ、4月まで続く生産性低下の時期のスタートとなった(^_^;)。 でもこの薬のおかげで、鼻がつまったりズルズルにならないので、ここはじっと我慢である。

SUAC基板の確認作業は、細かい宿題はいくつか残っているものの、A/Dコンバータのチェックのところで止まっていた。 そこで、過去の日記から このページ の「2012年11月5日(月)」のところで作っていた以下の4ジョイスティックボードを再利用することにした。

Propellerによるチェックプログラムは、 このページ の「2012年11月14日(水)」のところから進めていけばいい事になる。 SUACボードのA/D入力コネクタ(26ピン)は、AKI-H8とArduinoのアナログ入力8ビットに直結されている先頭8ビットに続いて、 2個のA/Dコンバータの8ビット入力が並んでいるので、4ピン2列という8ビット単位で抜き差しするようにして、 以下のように、基準電源の+5VとGNDは基板から別途に取り出した。

・・・そしてここから5時間、えらく悩むこととなった(^_^;)。 このページ の「2012年11月14日(水)」のところでは、A/DコンバータのAD7829のタイミングチャートにあるように、 「CONVST」を下げて上げて変換開始、そして「RD/CS」を下げてデータを取り込み、再び「RD/CS」を上げている。 これはつまり、データシートの通り、「CONVST」も「RD/CS」もアクティブLOW、つまり負論理という事である。

ところが、 このページ の「2013年1月6日(日)」のところで、 「しばし回路図を追いかけて発見したのは、138のG入力や245のG入力は負論理であるが、なんとAD7829の出力イネーブル(CS/RD)は正論理である、という事実だった」と書いていた。よく考えてみると、そんな筈は無いのである。なんという事か(^_^;)。

さきの実験ではAD7829単体で実験していたが、今回、納品されたSUAC基板には2個のAD7829も搭載している。 上記の「回路図」というのは、自分で入力したCADデータのことで、正論理というのは間違いで(^_^;)、バー記号が見えにくいものの、 CSもRDもちゃんと負論理だったのである。 しかし実験では、「outa[23..19] := %11111」と全ビットをHIGH(負論理ならdisable)にするとうまく動かず、 「outa[23..19] := %10011」とすると期待通りの動作をしたこともあり、「AD7829のCS/RDは正論理」と思い込んでしまったようである。

そこで改めて実験してみると、どうやっても「outa[23..19] := %10011」と設定しないと、これまでのライブラリもPropellerソフトも正常動作しない。 そして、当然ながら、これではA/Dコンバータの情報も正しく出てこない。 どこか確実におかしいのであるが、その現象と原因が不明なまま、あれこれやっているうちに数時間が経過したのである。 これを世間一般には「ドツボ」と言う。困った。(^_^;)

花粉症の薬は、次第に馴れてくるが、飲み始めたこの時期はとにかくサエないのである。 こういう時はあっさり諦めて、出直す方がいい場合もある。 明日は終日、院生の修了制作/修士論文発表会であるが、とりあえず、ここでオシマイという事にした。 明日は明日の風が吹く・・・かなぁ。(^_^;)

2013年2月6日(水)

メディアデザインウイークの展示が続き、院生の修了制作/修士論文発表会のあったこの日、またまた午後に1時間ほど、 研究室でウトウトする時間が襲ってきた。 花粉症の薬に身体が馴れるには、まだ1週間ほどかかりそうで、前日ドツボ入りしたSUAC基板のチェックにも、 なかなかヤル気が起きてこない。こういう場合には無理をせず、だらだら過ごすのも手である。 夜中にフト目覚めて攻略の手掛かりとなるアイデアに閃く、ということも無く、夜はずっと寝ているパターンとなった。

そんな中、とりあえずうとうとつらつらしつつも、可能性としてどうするか、以下のような候補が出て来た。 今日はこのメモを書き足すだけで、実際に行動に移ることもなさそうである。 明日は午前に卒展準備のアポで瞑想空間のWiFiチェック、そして午後には新年度の特別研究の学部長ヒアリングがあり、 集中して長時間の実験は出来ないかもしれない。 明後日から東京に3日間出かけるので、基板との勝負は来週になりそうだが、その頃までには身体のコンディションも改善されるだろう。

  • フラットパッケージICのハンダ付け信頼性確認のため新しい基板を作ってみる
  • その際、(1)出力574 → (2)入力245 → (3)1個目のAD7829 → (4)2個目のAD7829、と段階的にICを取り付けていく
  • 2・3列目が点灯しないのは、アドレスがずれたA/Dが1・2列目の信号を出しているから?
  • 抵抗を経由したバスファイトの可能性はオシロを当てて実際の電圧を確認すべし

2013年2月12日(火)

壁に当たったままの状態で、前回の日記(水曜日)から、ほぼ1週間が経過し、身体も花粉症の薬に馴れてきた。 木曜日は終日、芸文「メディアアーツ論」のレポートを読んで数十人の成績を付けていたら終わった。 金曜日から東京農工大での情報処理学会「教育とコンピュータ」研究会に行ったり、 土曜日・日曜日は京大合唱団の同窓会関係で遠き昔を振り返りつつ友人との再会を堪能して、終わった。 3日間にカラオケに4回も行ったというのは公然の秘密である(^_^;)。 昨日は祝日ということで、メイル整理やら体力回復やらに努めているうちに終わった。 そして今日、12時間の十分な睡眠を経て、「k+1」という謎のメモとともに、いよいよ再開である。

じっくり時間をかけて現象を明確にするために、まずは以下の「outport_check.spin」を走らせて、動作が確定していることを確認した。 一部、フラットパッケージのハンダが浮きかけているものも修正した。 これをFlash EEPROMにも書き込んで、PropellerStick上のResetスイッチで、いつでもこのパターンの点灯を再現できるようにした。 

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

PUB start | k
  port_initial(0)
  k := 0
  repeat
    k++
    if k == 20000
      port_initial($FF)
    elseif k == 40000
      port_initial($00)
    elseif k == 60000
      port_initial($55)
    elseif k == 80000
      port_initial($AA)
    elseif k == 100000
      k := 0
      port_initial($00)

PUB port_out(address, data)
  outa[15..8] := data
  outa[18..16] := address
  outa[19] := 0
  outa[19] := 1

PUB port_initial(data) | i
  dira[23..8]~~                 ' output
  outa[23..19] := %10011
  repeat i from 0 to 7
    port_out(i, data)
そして、「port_initial」にある「outa[23..19] := %10011」から、ビット2だけ0を1に戻して 「outa[23..19] := %10111」にすると、確かに、0からカウントした1列目と2列目が点灯しなくなった。 ただし現象としては、「1列目は必ず全て消えて、2列目は直前の状態がラッチされたまま更新されなくなる」 というものであった。 次にビット3だけ0を1に戻して「outa[23..19] := %11011」にすると、「1列目は必ず全て点灯して、2列目は必ず全て消える」という現象となった。 これは、何度もPropellerStick上のResetスイッチで全体点灯させた中で実験したので、完全に再現性のある、つまり理由が明確な現象であった。 そして、ビット2とビット3をつともに1にした「outa[23..19] := %11111」にすると、「1列目も2列目も必ず全て消える」という現象であった。

こうなると、ハンダ不良のような偶発性の無い、論理的に明確なバグであるのは確実である。 ヒントはこの2ビットの4状態によって、それぞれ起きる現象が異なっていて、しかもそれらは確実に再現される、という事である。 こんな楽しいパズルがあるだろうか(^_^;)。 かつて河合楽器でLSIを設計していた頃に、自分の脳細胞の端から端まで酷使して、数万トランジスタからなるLSI回路の動作を隅々まで追いかけて、 バグを発見して解決させた事があったが、給料をもらってこんな素晴らしいゲームをやっている自分が幸福だったのを思い出した。 僕が、他人が作ってその作った通りにしか展開しない「ゲーム」というものに、まったくヤル気が起きないのは、これが理由である。

・・・と、グッと回路図をあらためて眺めること30分、遂に、発見してしまった(^_^;)。 またやってもーた。まさに自分の責任、全ての現象が明確に説明できる大バグである。

上にあるように、138から64ビット出力の8個の574のCK入力に与えるラッチパルス出力のうち、1列目の信号がCS1、2列目の信号がCS2である。 ところが、outa[23..19]の、問題のビット2とビット3としてPropellerとAKI-H8から出ていて、2個のAD7829-1のRD・CSに行っている信号が、 なんと、同じ「CS1」「CS2」として、信号名が見事に重複していたのである。(^_^;)

現象としては、今回はPropellerからの信号なので最大でも3Vまでしか出ないので、 5V出力の138とバスファイトした場合には。なかなか微妙な喧嘩となるが、ファイトしたままであれば、 素子破壊の可能性もある、あまりに明瞭なバグであった。こりゃぁ参った。(^_^;)

理解できてしまえばあとは簡単である。 とりあえず、回路図としては、2個のA/DコンバータのRD・CSに行くチップセレクト信号に別の名前を付けて、 outa[23..19]のビット2とビット3としてPropellerとAKI-H8から出ている信号をこれに合わせる、という事である。 さらに、このチップセレクト信号はやっぱり負論理だったので(^_^;)、未搭載に対応してpull-downでなくpull-upとする、という事である。 以前の「次回に訂正すべきメモ」を、さっそく以下のように修正した。 

■SUAC board ver.0.5からの改善点リスト■

●バグなので次バージョンで必ず改訂する項目
・2個のA/DコンバータのRD・CSに行く2本のチップセレクト信号を「CCS1」「CCS2」に変更する
・PropellerとAKI-H8から出ている2本の信号を↑と対応して「CCS1」「CCS2」に変更する
・XBeeのDinとDoutが逆(^_^;)なので入れ替える
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
・↑そのpull-up先の電圧を+5Vとするか+3.3Vとするか、のジャンパが必要

●必須ではないが改訂することになれば盛り込みたい項目
・電源コネクタ
・電源給電表示LED
・半固定抵抗の穴を2mmφにする
・半固定抵抗の中央穴の位置を0.1インチ離す

●現行SUAC board ver.0.5の増産時に対応すること
・XBeeのDinとDoutが逆なので基板配線面をカットして修正する
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
	→そのpull-up先の電圧はホストに対応して+5Vまたは+3.3V
・Propellerの26ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする
・Propellerの27ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする

●その他メモ
そしてここからは、以下のように「基板を切った貼った」という、修正の手作業である。 LSIであればほとんど不可能であるが(実際にはやった事があるのでゼロでは無い)、4層といっても配線パターンが両面にあるこの基板であれば、 原理的には可能な作業である。 幸いなことに、「Propeller→AKI-H8→AD7829」というラインと、「Propeller→138→574」と行っているラインとが、 Propellerチップのピンから上下のブロックに分かれていたので、後者に行くラインをカッターで切るだけ、という最小限の作業となった。 これは今後の基板でも簡単に修正できるので、ライブラリの開発に新旧の2バージョンを用意する、という混乱は避けられた。

ようやく突破したが、ここからがまだ大変である。 これまでの実験で作ったPropellerプログラムとライブラリのうち、outa[23..19]が誤って「%10011」とされていたものは、 バグを修正した際には「%11111」となっていなければ、今度は本当に2個のA/D出力がバスファイトする(^_^;)。 そこで、手元にある全てのバージョンのPropellerプログラムをチェックして、修正する、という作業がなにより必要である。 まず最初に、「outport_check.spin」が「%11111」で正しく動作するのを確認した上で、修正を進めた。

そしてようやく、確認したかったA/Dコンバータのところにやってきたが、今度はあまりにもアッサリと、 以下のようなPropellerブログラム「board_011.spin」と、 そのA/D変換結果の出力情報をMIDI表示するMaxプログラム「SUACboard_test011.maxpat」とで、確認できた。 ここでは適当なインターバルとして、8チャンネルのA/D変換のたびに 「waitcnt(10000000+cnt)」 という、「1億クロックの無駄足」(^_^;)を踏ませてみたが、それでも毎秒10サンプル/チャンネル以上の性能があった。 

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

OBJ
  midiOut       : "MidiOut01"

PUB main | data, sel
  port_initial
  midiOut.start(25)
  midiOut.fifoset($C00000 + 127)
  sel := 0

  repeat
    sel := (sel+1) & 7
    outa[18..16] := sel
    outa[21]~
    data := ina[15..8]
    outa[21]~~
    midiOut.fifoset($D00000 + ((sel-1) & 7)<<16 + data/2)
    if sel == 0
      waitcnt(10000000+cnt)
    outa[23]~
    outa[23]~~

PUB port_initial
  dira[23..8]~~                 ' output
  outa[23..19] := %11111
  dira[15..8]~                  ' universal bus line : input

A/Dコンバータの性能としては、最大で2.5Vのダイナミックレンジであり、外付けの半固定抵抗によって、 出力が中央(127)となるセンター電圧を設定できる。 今回のジョイスティックではバネによりほぼ中央に戻るが、設定電圧により、ほぼ0からほぼ127(←これはMIDI送信のために2で割っているので、 実データとしては8ビットフルスケールの0-255)までちょうど振れる事、 入力電圧が2.5Vp-pを越えた場合には、奇麗にアナログ的に飽和してくれることも確認した。 これで、十分に色々なセンサと接続できそうである(^_^)。

さらに、Propellerのビット21をビット22に換えただけのプログラム「board_012.spin」で、2つ目のAD7829-1の動作も確認して、これで、 SUAC基板にPropeller、という組み合わせでのチェックは完了した。 こうなれば、次にはArduino、そしてGainer、さらに最後にAKI-H8?　と進むことになる。 とりあえずの区切りとして、今日はここまでとして、明日にさらに進めていくことにしよう。

2013年2月14日(木)

世間はバレンタインデーであるらしいが、そんなの関係ねぇ(^_^;)。 昨日の午前には卒展関係で4回生の奥山さんの支援、 昼休みには1回生の金重さんと ドラえもんラジオ を作り、午後には課題映像の録音で2回生の澤野さんの支援、総合演習の機材返却で3回生の望月さんの支援、 放課後には卒業する則兼クンとともにアカペラの最終回、 そして合間には、水面下で進むCQ関係の作業などで終わった。 今日は午前に卒展のオープニング、午後には卒展図録の納品アポ、学科の追いコン(僕は出席できないが)補助の相談アポ、 と入っているが、ようやくSUAC基板のチェックをArduinoに進められそうである。 順調に進んだ場合には、しばらく「Propeller日記」でなく「Arduino日記」となりそうだが、このまま続けて行こう。

ここまでのバグ情報から、現在の実験基板には2個のA/Dコンバータが載っているので、 この2つのチップセレクト信号をオープンにしていると、 拡張バスの制御信号とバスファイトする可能性があり、pull-upが必要である。 さらにArduinoの起動時にも不要のバスファイトを避けるために、 2個の138のG入力に行く、入力ポート(64ビット入力 : 8個の245)イネーブル信号「G」と、 出力ポート(64ビット出力 : 8個の574)ラッチ信号「CK」も、合わせてpull-upすることにした。

前回の日記にあるように、今回の試作基板では、2個のA/DコンバータへのCS信号が重複しているが、 ちょうどPropellerのピンからの配線が、「AKI-H8を経由してA/Dへ」というラインと、 「138や574へ」というラインとで分かれていて、後者をカットしたところだった。 そこで、このカット修正をしている基板では、Arduinoを挿すということはAKI-H8のソケットが空いているので、 このAKI-H8のソケットにある、以下のピンから4.7kΩで+5Vへpull-upすることにした。 もちろん空中配線であるが、良い子は真似しないように。(^_^;)

  • +5V : 1-35/36 : 35/36ピン
  • CK : 1-34 : 34ピン
  • G : 3-3 : 43ピン
  • CS1 : 3-4 : 44ピン
  • CS2 : 3-5 : 45ピン
この作業は比較的あっさりと、以下のように出来た。 AKI-H8の2列ピンヘッダソケットは、抵抗などの部品のリードより太いので、 きちんとピンヘッダを挿してハンダ付けした。 また、Arduinoのピンも何故か同じ太さのものだったので、丸ピンソケットに、 ピンヘッダソケットの内側ピンをカットして1列にしたものを間に入れてあるが、 高さが不自然に高くなっているだけで、接触の問題は解消されている。

そして次には、Arduinoまわりのジャンパの設定である。 Arduinoの関係するジャンパは3つであり、過去の日記から検索すると、 続々・Propeller日記(1) の「12月24日」、つまりクリスマスイブ(この日も「そんなの関係ねぇ」と書いていた(^_^;))に、以下のようにあった。
  • SW1 - ArduinoのD0端子をXBee受信にするか/245入力のGにするか
    • 回路図解析結果
      • 1ピン - XBee受信(Din : 3pin)
      • 2ピン - ArduinoのRX/D0(2pin)
      • 3ピン - 245入力のGを供給する138のG入力
    • 動作モードとジャンパの設定
      • ジャンパ[1-2]ON - ArduinoでXBeeから受信する(speedは19200以下、9600推奨)
      • ジャンパ[2-3]ON - Arduinoで8ビット8ポート・ディジタル入力を行うためのG信号出力
  • SW3 - MIDI出力をPropellerから出すか/AKI-H8またはArduinoから出すか
    • 回路図解析結果
      • 1ピン - PropStickのP25(34pin)
      • 2ピン - MIDI出力用74HC05のインバータ入力
      • 3ピン - 「AKI-H8の[CN1-25]シリアル出力」+「ArduinoのTX/D0(1pin)」を受けた74HC05反転出力
    • 動作モードとジャンパの設定
      • ジャンパ[1-2]ON - PropellerからのMIDI出力
      • ジャンパ[2-3]ON - AKI-H8またはArduinoからのMIDI出力(どちらか挿さっている方)
  • SW4 - ArduinoのD13端子を245入力のGにするか/574出力のCKにするか
    • 回路図解析結果
      • 1ピン - 574出力のCKを供給する138のG入力
      • 2ピン - ArduinoのD13(16pin)
      • 3ピン - 245入力のGを供給する138のG入力
    • 動作モードとジャンパの設定
      • ジャンパ[1-2]ON - Arduinoで8ビット8ポート・ディジタル出力を行うためのCK信号出力
      • ジャンパ[2-3]ON - Arduinoで8ビット8ポート・ディジタル入力を行うためのG信号出力
ArduinoはC言語でのソフトウェアではMIDIを受けきれない(取りこぼす)ことを確認しているので、 SUAC基板では、Arduinoが通信機能として対応しているのは、「MIDI送信」「XBee受信」「XBee送信」の3つである。 そして拡張バスラインを使っての64ビット・ディジタル入出力については、このジャンパの設定によって、 シリアルとの組み合わせで以下のように実現することになる。
  • ArduinoのTXからのMIDI出力は 「ジャンパSW3」 → ジャンパ[2-3]ON とする
    ※ XBeeが搭載されていると同時にXBeeからも送信される
  • ArduinoのTXからのXBee出力は、XBeeが搭載されていれば常に送信される
  • 拡張バスラインを使っての64ビット・ディジタル出力は 「ジャンパSW4」 → ジャンパ[2-3]ON とする
    ※ このとき 「ジャンパSW1」 → ジャンパ[1-2]ON だと同時にXBee受信も可能
  • 拡張バスラインを使っての64ビット・ディジタル入力は 「ジャンパSW4」 → ジャンパ[1-2]ON とする
    ※ このとき 「ジャンパSW1」 → ジャンパ[1-2]ON だと同時にXBee受信も可能
  • 拡張バスラインを使って64ビット・ディジタル入出力を行う場合にはXBee受信は出来ない
    ※ このとき 「ジャンパSW1」 → ジャンパ[2-3]ON としてRX(D1)をG信号として使う
    ※ このとき 「ジャンパSW4」 → ジャンパ[2-3]ON としてD13をCK信号として使う
まずはシリアル通信の前に、せっかく繋がれている64個のLEDと8個のジョイスティックと64個のディジタル入力ピンを チェックするという事で、ジャンパは以下のようにセットした。
  • 「ジャンパSW1」 → ジャンパ[2-3]ON としてRX(D1)をG信号として使う
  • 「ジャンパSW4」 → ジャンパ[1-2]ON としてD13をCK信号として使う

ここまで書いたところで、卒展オープニングの11時になった事に気付いて、慌ててデジカメを持って1階に走った。 なんとか学長の挨拶の途中から合流できて、今年も このように 記録を残すことが出来た。 そして午後は単発のアポに対応するだけなので、いよいよArduinoからのSUAC基板チェックである。 画面には以下のように、Arduino IDEとともに、「arduino.cc」のページも開いて、 すっかりPropellerとProcessingとゴッチャになっている言語の方は、 Arduinoサイトのreferenceページを参照しつつのプログラミングである。

プログラミングとしては、とりあえずは以下のように、8ポートの64ビットを全部クリアして、 あとは一定間隔ごとに、ランダムなポートにランダムなデータを書き込む、というプログラム「 SUACboard_test001.pde 」を作ってみた。 ところがここでさっそく問題が起きた。なんとArduinoにupload出来ないのであった(^_^;)。 
long previousMillis = 0;
int interval = 1000;

void setup() {
   for (int i=1; i <= 13; i++){
      pinMode(i, OUTPUT);    
   }
   digitalWrite(1, HIGH);
   digitalWrite(13, HIGH);
   port_initial();
}

void loop() {
  unsigned long currentMillis = millis(); 
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    port_data_out(random(0,8), random(256));
  }
}

void port_initial() {
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
   digitalWrite(13, LOW);
   digitalWrite(13, HIGH);
}
以下のように、Arduino Nano(328)もシリアルポート(tty USBserial)も正しいのに、 uploadで転送できないという現象である。 ただし、このArduinoをSUAC基板から外して、単体にするとupload出来るのである。 もっとも、単体で「upload done.」と出来たプログラムでも、SUAC基板のLEDは想定したように点灯していない。 ソフトとハードと、両方にバグの疑いがある、という、よくある難題である。(^_^;)

考えてみると、今回のSUAC基板に搭載するために、小さいからとArduino Nanoを選んで購入していたが、 ほとんど使ったことが無かったのであった。 「オンボードで書き込めないのに単体で書き込める」という現象は、AKI-H8で遭遇したことがあった。 そこで、あらためてArduinoサイトから「http://arduino.cc/en/Main/ArduinoBoardNano」を見てみると、 
Power:

The Arduino Nano can be powered via the Mini-B USB connection, 6-20V unregulated 
external power supply (pin 30), or 5V regulated external power supply (pin 27). 
The power source is automatically selected to the highest voltage source.
とあった。この基板では+5VをArduinoの27ピンに供給しているので、この点では問題なさそうである。 uploadのTroubleshootingには、USBハブを経由するとトラブる事があるのでPCのUSBに直結せよ、 などとも書かれていたが、単体で書き込めているのはUSBハブ経由なので(^_^;)、これも原因ではなさそうである。

・・・そして考えること10数分、基板にテスターを当てて検証すること10数分で、ようやく問題は解決した。 混乱するので上記の記述はバグを解消改訂してあるが、ジャンパピンの設定のリストのところで、 回路図からの解析結果は正しかったのに、これに続く「動作モードとジャンパの設定」のところを、 「G」と「CK」との対応を反対に書いていたために、「CK」が出ていなかった、というミスであった。 このため、RXピンが「G」に繋がった状態となり、そこにD13から「HIGH」が出ていたために、 ホストPCからのシリアルピン(RX)への書き込みも出来なくなった、という現象である。 これは、ハードにもソフトにも関係ない、ドキュメントの記載ミスというバグであるが、 仕様のミスでなく単にコピペで記述する際のミスで良かった。 仕様(設計)段階のミスとなれば、対応はタイヘンだからである。

とりあえず出力ポートの制御が出来た(邪魔する信号衝突も無い)ようなので、 ここでいったん、デジカメを持って学内に出て、ザッと卒展の様子を撮って回った。 これ である。 同時にその裏では、研究室の別のMacでは、届いた卒展図録の付録DVDから、 メディア造形学科学生の映像作品10作品を取り込んでMP4化する、という作業も並行して行った。

そして、とりあえず64ビットのLED点灯が出来たようなので、 このメインの時間管理やポートに8ビット単位でデータを書き込む関数を活用して、 Propeller版と同様に、以下のような、テストのためのプログラム「 SUACboard_test002.pde 」を作ってみた。 

long previousMillis = 0;
int interval = 500;
int mode = 0;

void setup() {
   for (int i=1; i <= 13; i++){
      pinMode(i, OUTPUT);    
   }
   digitalWrite(1, HIGH);
   digitalWrite(13, HIGH);
   port_initial();
}

void loop() {
  unsigned long currentMillis = millis(); 
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    mode = (mode+1) & 7;
    switch(mode){
      case 0:
        port_initial();
        break;
      case 1:
        for (int i=0; i < 8; i++){
          port_data_out(i, 255);    
        }
        break;
      case 2:
        port_initial();
        break;
      case 3:
        for (int i=0; i < 8; i++){
          port_data_out(i, B01010101);    
        }
        break;
      case 4:
        for (int i=0; i < 8; i++){
          port_data_out(i, B10101010);    
        }
        break;
      case 5:
        port_initial();
        break;
      case 6:
        for (int i=0; i < 4; i++){
          port_data_out(i*2, B01010101);    
          port_data_out(i*2+1, B10101010);    
        }
        break;
      case 7:
        for (int i=0; i < 8; i++){
          port_data_out(i, 1 << i);    
        }
        break;
    }
  }
}

void port_initial() {
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
   digitalWrite(13, LOW);
   digitalWrite(13, HIGH);
}
このプログラムも無事にちゃんと動いたところで、今日はオシマイである。 あと残ったのは、ディジタル入力、そしてArduinoに直結のアナログ入力、 さらにシリアル関係のテストである。 バグで足踏みしていた頃が嘘のように快調に進んだが、まぁ、こういう日もある。(^_^)

2013年2月15日(金)

今日はまず、以下のようにセッティングし直して、昨日のArduinoプログラム SUACboard_test002.pde での動作をmovie記録してYouTubeに上げた。

YouTube

そして午前には、メディア造形総合演習Iで発表直前のトラブルから完成形で展示発表できず、 再提出となった田中さんの作品のリベンジ展示に立ち会った。 作品は、 このように 見事に完成した。よかった。(^_^)

そして次に行うのは、ディジタル入力64ビットの拡張である。このためには、拡張バスラインの8ビットは、 入力と出力とで切り換えるたびにポートの入出力方向を設定し直すことになるので、 その部分はsetup()からメインに出ることになる。 まずArduinoのサイトから、ディジタル入力については、以下にあるように、 単に「pinMode(pin, INPUT);」とするのでなく、 内部pull-up抵抗をONにするために直後に「digitalWrite(pin, HIGH);」を指定する、 などという知らなかったノウハウを仕入れた(^_^;)。 

Pullup Resistors

Often it is useful to steer an input pin to a known state if no input is present. This can be 
done by adding a pullup resistor (to +5V), or a pulldown resistor (resistor to ground) on 
the input, with 10K being a common value.

There are also convenient 20K pullup resistors built into the Atmega chip that can be 
accessed from software. These built-in pullup resistors are accessed in the following manner.

pinMode(pin, INPUT);           // set pin to input
digitalWrite(pin, HIGH);        // turn on pullup resistors

Note that the pullup resistors provide enough current to dimly light an LED connected to 
a pin that has been configured as an input. If LED's in a project seem to be working, but 
very dimly, this is likely what is going on, and the programmer has forgotten to use 
pinMode() to set the pins to outputs.

Note also that the pullup resistors are controlled by the same registers (internal chip 
memory locations) that control whether a pin is HIGH or LOW. Consequently a pin that 
is configured to have pullup resistors turned on when the pin is an INPUT, will have the 
pin configured as HIGH if the pin is then swtiched to an OUTPUT with pinMode(). This 
works in the other direction as well, and an output pin that is left in a HIGH state will 
have the pullup resistors set if switched to an input with pinMode().
さらにArduinoのサイトを見ていたら、ArduinoのIDEのバージョンがだいぶ上がっている、 と気付いたので、これまでの「0022」から安定バージョンの「1.0.3」に上げた。 すると、実験中のArduinoプログラムの拡張子が「.pde」(これはProcessingと同じで混同する(^_^;))から、 「.ino」に書き換えられた。 中身としては、とりあえず上位互換のようだが、さすが、いろいろ進展しているようである。

そして、あれこれ事務仕事の合間に、午後のだいぶ長い時間を費やしながら、 なかなか「ディジタル入力をそのままディジタル出力としてLED表示」という、 単純である筈のプログラムがうまく出来ない・・・という状況に悩まされた。 とりあえず作ったプログラムは以下のようなもので、ポートの向きの反転も含めて、 こんなところで楽勝に動くだろう、と思っていたが、駄目なのであった。(^_^;) 

long previousMillis = 0;
int interval = 100;

void setup() {
  pinMode(1, OUTPUT);    
  for (int i=10; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(1, HIGH);
  digitalWrite(13, HIGH);
  portset_output();
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void loop() {
  unsigned long currentMillis = millis();
  int dd;
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    for (int i=0; i < 8; i++){
      portset_input();
      dd = port_data_in(i);
      portset_output();
      port_data_out(i, dd);
    }
  }
}

int port_data_in(int port){
  int data = 0;
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(1, LOW);
  for (int i=0; i < 8; i++){
    data = data + (digitalRead(i+2) << i);
  }
  digitalWrite(1, HIGH);
  return !data;
}

void portset_input() {
  for (int i=2; i <= 9; i++){
    pinMode(i, INPUT);    
    digitalWrite(i, HIGH);    
  }
}

void portset_output() {
  for (int i=2; i <= 9; i++){
    pinMode(i, OUTPUT);
    digitalWrite(i, LOW);    
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}
この後、 Atmelのサイト で ATmega328データシート を入手して、スレショルドレベルが違う・・・というヒントをつかみかけたが、 ロシアの隕石ニュースが舞い込んできたり、晩には1回生の映像作品披露パーティがあったり、 と尻切れになってしまった(^_^;)。 明日はマラソンなのでスキップ、まぁ続きは、来週に向けてぼちぼちである。

2013年2月18日(月)

月曜日、新しい週の始まりである。試験期間も終わり、学生はいよいよ長い春休みであるが、 大学は来週月火の国公立前期入試が、いわば年間で最大の山場である。 先週の金曜日には 1回生の映像作品鑑賞会 があり、国公立になって全国から優秀な学生がSUACメディア造形学科にやって来ている、 とまた今年も実感した。ワインも美味しかった(^_^)。 先輩の作品記録に触発されて後輩が伸びていき、優秀な後輩の出現に先輩も刺激を受ける、 というこのメディア造形の伝統は素晴らしいものである。 今年の入試でもメディア造形は6学科トップの倍率で、さらに優秀な学生が来る、と期待している。

土曜日には一転して、9時間マラソンカラオケを堪能し、日曜日にはその休養がてら、 NHK将棋がまたまた楽しかった。鈴木大介8段に圧倒的に勝っている屋敷9段が、 担当している来週の将棋講座のテーマ「穴熊」を、定番の居飛車穴熊として序盤に展開した。 ところが古典的四間飛車の鈴木8段が、香車の3段ロケットでこの穴熊を崩壊させてしまったのである。 来週の将棋講座はどうなるのだろうか(^_^;)。 そして日曜日の夕方に、先週からの懸案となっていた、Arduinoでのディジタル入力の問題が解決した、 というところで帰宅したのであった。今日はまず、ここから整理しての再開である。

2月15日のPropeller日記の最後に書いた「スレショルドレベルが違う」というのは、 以下のように、Atmelのデータシートの入力電圧の記載を見ての着想であった。 しかしこれはガセであった(^_^;)。 電源電圧+5Vでの入力Lレベルのスレショルドを「0.3V」、入力Hレベルのスレショルドを「0.6V」と勘違いしたが、 実際にはこれは「0.3Vcc」=「1.5V」、「0.6Vcc」=「3.0V」ということで、まったく問題ないのであった。

また、トラブルに対する試行錯誤の中で、 単に「pinMode(pin, INPUT);」とするのでなく、 内部pull-up抵抗をONにするために直後に「digitalWrite(pin, HIGH);」を指定する、 というのを発見していたが、これも、SUAC基板ではディジタル入力の245の入力側にpull-up抵抗を付けているので、 内部pull-upの指定は不要である、と確認できた。

問題の解決に至ったのは、入力の245のGが出て来ない、この信号はArduinoのRxと共用の1ピンだろう・・・と、 とりあえずArduinoArduinoのサイトの Reference で「 serial 」を引いたのがきっかけである。 ここに書かれていた、冒頭の以下を読んで、「あれ??」と引っかかったのである。 

Used for communication between the Arduino board and a computer or 
other devices. All Arduino boards have at least one serial port (also known 
as a UART or USART): Serial. It communicates on digital pins 
0 (RX) and 1 (TX) as well as with the computer via USB. Thus, if you use 
these functions, you cannot also use pins 0 and 1 for digital input or output.
Arduinoのチップのピン配置は、1ピンがTxで2ピンがRxであるが、上記はちょっと違う(^_^;)。 またピン定義のミスか??　と調べてみて、ArduinoNanoのデータシートを見てみると、 なんと以下のように、入出力ピンがビン番号と対応して並んでいると思ったら、 RxとTxだけは反対なのであった(^_^;)。

これで一気に謎が解けた。基板設計のためのArduinoのピン配置は間違っていないし、 基板の配線も間違っていないが、Arduinoのプログラムとして、ジャンパにより245を選択的にイネーブルする138のGに、 Rxラインから行っている信号を制御するのは、ビット1でなくビット0だったのである。 先週のディジタル出力の確認実験では、このビット0は定義せず「H」も出力していなかったが、 defaultではArduinoの端子はHi-Zの入力状態にあり、そこに手作業でpull-up抵抗を付けていたので、 拡張バスに信号を出すなど、何も悪さしなかったのであった。

そこで先週のプログラムを以下のように変更すると、 ちゃんと「ディジタル入力(GNDとショート)→LED点灯」という動作が実現できた。 YouTubeの動画で、PCとのUSBを外して、Arduinoが単体で動作しているところがポイントである。 先週のディジタル出力プログラムも、ビット0のところをビット1に改訂したものをzipとして再アップした。 あわせて、これまでの日記の中でこのビットを間違って記述していた場所を修正し再アップした。 

long previousMillis = 0;
int interval = 100;

void setup() {
  pinMode(0, OUTPUT);    
  for (int i=10; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(0, HIGH);
  digitalWrite(13, HIGH);
  portset_output();
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void loop() {
  unsigned long currentMillis = millis();
  int dd;
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    for (int i=0; i < 8; i++){
      portset_input();
      dd = port_data_in(i);
      portset_output();
      port_data_out(i, dd);
    }
  }
}

int port_data_in(int port){
  int dd, data;
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(0, LOW);
  data = 0;
  for (int i=0; i < 8; i++){
    data = data + (!digitalRead(i+2) << i);
  }
  digitalWrite(0, HIGH);
  return data;
}

void portset_input() {
  for (int i=2; i <= 9; i++){
    pinMode(i, INPUT);    
  }
}

void portset_output() {
  for (int i=2; i <= 9; i++){
    pinMode(i, OUTPUT);
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}

YouTube

これで64ビットのディジタル入出力が時分割的に同時処理可能、というところまでチェックが完了した。 次はA/D入力である。 Arduinoのピン数の制限から、Propellerで使った、2個の外部のA/Dコンバータは、 Arduinoからはアクセスできない。 その代わり、Arduino標準のアナログ入力が8チャンネル、直接にアナログ入力コネクタと接続されている。 Arduino UNOとかは6チャンネルだったが、ArduinoNanoは8チャンネル、というのは嬉しい(^_^)。

・・・実はこの部分では、既に「第3の大バグ」が発覚している(^_^;)。 Arduinoのチェックの際にテスターを当てていて発見したのだが、アナログ入力コネクタの0-7と、 Arduinoの入力のビット(A0-A7)とが、反対になっているのだ。 これは完全に、P板設計CADの登録作業でのミスで、Arduinoというチップを登録した際に、 信号名をビットの並びと逆に付けてしまったのである。 この対応法としては、

  • Arduinoというチップの信号名登録から全て直す
  • 次バージョンのCADで、Arduinoチップからのアナログ入力信号の対応だけ逆にする
という2つがある。 後者であっても、出来上がった改訂基板としてはまったく何の問題もない修正である。 前者の方がスッキリするが、既に定義した同じ部品を上書き的に改訂するのは、 なんだか別のトラブルの元となりそうで、どうも嫌な気配がするのである(^_^;)。

それはさておき、まずは「アナログ入力→LEDでバイナリ表示」という、もっとも基本的な動作の確認である。 以下のようなプログラムで、とりあえずメインルーチンのソフトタイマを10msecとして、 8チャンネルで80msecのA/D変換を回してみた。 ビットは見事に反対になっているが(^_^;)、きちんと動作が確認できた。 この SUACboard_test004.ino は当面、ソフトで反対並びに尻拭いせずに、このままにしておく事にする。 

long previousMillis = 0;
int interval = 10;
int phase = 0;

void setup() {
  for (int i=0; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(0, HIGH);
  digitalWrite(13, HIGH);
}
SUACboard_test003
void loop() {
  unsigned long currentMillis = millis();
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    phase = (++phase) & 7;
    switch (phase) {
      case 0:
        port_data_out(0, analogRead(A0)/4);
        break;
      case 1:
        port_data_out(1, analogRead(A1)/4);
        break;
      case 2:
        port_data_out(2, analogRead(A2)/4);
        break;
      case 3:
        port_data_out(3, analogRead(A3)/4);
        break;
      case 4:
        port_data_out(4, analogRead(A4)/4);
        break;
      case 5:
        port_data_out(5, analogRead(A5)/4);
        break;
      case 6:
        port_data_out(6, analogRead(A6)/4);
        break;
      case 7:
        port_data_out(7, analogRead(A7)/4);
        break;
    }
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}

YouTube

次バージョンに向けての改訂点のメモは、これを受けて以下のように追記された。 まぁ、ソフトで対応できるバグは、このように対応は容易なのである(^_^;)。 

■SUAC board ver.0.5からの改善点リスト■

●バグなので次バージョンで必ず改訂する項目
・2個のA/DコンバータのRD・CSに行くチップセレクト信号を「CCS1」「CCS2」に変更する
・PropellerとAKI-H8から出ている信号を↑と対応して「CCS1」「CCS2」に変更する
・XBeeのDinとDoutが逆(^_^;)なので入れ替える
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
・↑そのpull-up先の電圧を+5Vとするか+3.3Vとするか、のジャンパが必要
・ArduinoNanoのアナログ入力端子の番号が逆順なので信号を逆順に付け替える

●必須ではないが改訂することになれば盛り込みたい項目
・電源コネクタ
・電源給電表示LED
・半固定抵抗の穴を2mmφにする
・半固定抵抗の中央穴の位置を0.1インチ離す

●現行SUAC board ver.0.5の増産時に対応すること
・XBeeのDinとDoutが逆なので基板配線面をカットして修正する
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
	→そのpull-up先の電圧はホストに対応して+5Vまたは+3.3V
・Propellerの26ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする
・Propellerの27ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする
・ArduinoNanoのアナログ入力端子の番号が逆順なのでソフトで逆順に対応する

●その他メモ
さて、次にはシリアル関係である。 まずは、 ジャミネータと遊ぼう のサイトを確認して、ArduinoでのMIDI送信である。 せっかくなので、上記の「アナログ入力→LEDでバイナリ表示」のプログラムに加えて、 8チャンネルのボリューム情報を、MIDIブログラムチェンジで送ることにした。 ジャンパとしては、過去の資料から

SW3 - MIDI出力をPropellerから出すか/AKI-H8またはArduinoから出すか

  • 回路図解析結果
    • 1ピン - PropStickのP25(34pin)
    • 2ピン - MIDI出力用74HC05のインバータ入力
    • 3ピン - 「AKI-H8の[CN1-25]シリアル出力」+「ArduinoのTX/D0(1pin)」を受けた74HC05反転出力
  • 動作モードとジャンパの設定
    • ジャンパ[1-2]ON - PropellerからのMIDI出力
    • ジャンパ[2-3]ON - AKI-H8またはArduinoからのMIDI出力(どちらか挿さっている方)
とあったので、「ジャンパSW3を[2-3]ON」に、という事になる。 そして、Arduinoプログラミングを進めていくと、「ジャミネータと遊ぼう」の時の命令である、 「Serial.print(cmd, BYTE);」がエラーとなった(^_^;)。 
As of Arduino 1.0, the 'BYTE' keyword is no longer supported.
Please use Serial.write() instead.
とのことで、「Serial.write(cmd);」などと変更した。 確認の実験は以下のようにあっさりと成功して、これで SUACboard_test005.ino ということで、MIDI出力まで完了した。(^_^) 

long previousMillis = 0;
int interval = 10;
int phase = 0;

void setup() {
  Serial.begin(31250);
  for (int i=0; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(0, HIGH);
  digitalWrite(13, HIGH);
}

void loop() {
  unsigned long currentMillis = millis();
  int dd;
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    phase = (++phase) & 7;
    switch (phase) {
      case 0:
        dd = analogRead(A0);
        port_data_out(0, dd/4);
        pgmOut(0xc0, dd/8);
        break;
      case 1:
        dd = analogRead(A1);
        port_data_out(1, dd/4);
        pgmOut(0xc1, dd/8);
        break;
      case 2:
        dd = analogRead(A2);
        port_data_out(2, dd/4);
        pgmOut(0xc2, dd/8);
        break;
      case 3:
        dd = analogRead(A3);
        port_data_out(3, dd/4);
        pgmOut(0xc3, dd/8);
        break;
      case 4:
        dd = analogRead(A4);
        port_data_out(4, dd/4);
        pgmOut(0xc4, dd/8);
        break;
      case 5:
        dd = analogRead(A5);
        port_data_out(5, dd/4);
        pgmOut(0xc5, dd/8);
        break;
      case 6:
        dd = analogRead(A6);
        port_data_out(6, dd/4);
        pgmOut(0xc6, dd/8);
        break;
      case 7:
        dd = analogRead(A7);
        port_data_out(7, dd/4);
        pgmOut(0xc7, dd/8);
        break;
    }
  }
}

void pgmOut(char cmd, char data) {
  Serial.write(cmd);
  Serial.write(data);
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}

YouTube

・・・ここでお昼となった。なかなか順調に進んだ(^_^)。 こういう日もあるから、スケッチングは楽しいのである。

・・・そして午後には、XBeeのチェックである。 SUAC基板では、Arduinoのポート数の制限から、RxピンをXBee受信とディジタル入力ポートのイネーブルとで、 排他的にジャンパ設定する。 ただし、これまでディジタル出力のラッチパルスに使用してきたD13は、これまたジャンパの設定で、 ディジタル入力ポートのイネーブルにも排他的に設定できる。 つまり、XBee受信を使う場合には、ディジタル入力ポートとディジタル出力ポートまで同時に全てを使うことは出来ず、 「XBee受信とディジタル入力」または「XBee受信とディジタル出力」との二択となるのである。

また、TxビットはMIDI出力のジャンパ(PropellerからかArduino/AKI-H8か)と、XBee送信との両方に出ているので、 上記「XBee受信とディジタル入力」または「XBee受信とディジタル出力」との二択と同時にXBee送信は可能である。 ただし、シリアルのボーレート設定は送受信で共通なので、MIDI(31250)かXBee(ここでは38400)か、 というのは排他的な選択となり、「MIDI送信とXBee受信」などという事は出来ない。 ここがPropellerとは違うところであり、Propellerだけはなんでもアリである(^_^)。

アナログ入力ポートは常に使えるので、ここでのチェックとしては、以下の動作を行うこととした。

  • Arduinoで8系統のアナログ入力(ジョイスティック4個)を検出
  • そのデータをXBeeからMIDI類似形式でMaxにワイヤレス送信
  • MaxではこのXBee信号を受信して、LED表示パターンに変換してMIDI類似形式でXBee送信
  • ArduinoはこのXBee信号を受信して、ディジタル出力ポートからLED表示
「MIDI類似形式」というのは、これまでPropellerで行ってきたのと同様の形式(ステータスバイト+データバイト)、という事である。 ただしランニングステータスは混乱の元なので使用しない。 まず最初にジャンパの設定として、以下の資料を発掘して、 「ジャンパSW1を[1-2]ON」に、「ジャンパSW4を[1-2]ON」に、と設定した。
  • SW1 - ArduinoのD0端子をXBee受信にするか/245入力のGにするか
    • 回路図解析結果
      • 1ピン - XBee受信(Din : 3pin)
      • 2ピン - ArduinoのRX/D0(2pin)
      • 3ピン - 245入力のGを供給する138のG入力
    • 動作モードとジャンパの設定
      • ジャンパ[1-2]ON - ArduinoでXBeeから受信する(speedは19200以下、9600推奨)
      • ジャンパ[2-3]ON - Arduinoで8ビット8ポート・ディジタル入力を行うためのG信号出力
  • SW4 - ArduinoのD13端子を245入力のGにするか/574出力のCKにするか
    • 回路図解析結果
      • 1ピン - 574出力のCKを供給する138のG入力
      • 2ピン - ArduinoのD13(16pin)
      • 3ピン - 245入力のGを供給する138のG入力
    • 動作モードとジャンパの設定
      • ジャンパ[1-2]ON - Arduinoで8ビット8ポート・ディジタル出力を行うためのCK信号出力
      • ジャンパ[2-3]ON - Arduinoで8ビット8ポート・ディジタル入力を行うためのG信号出力
ところが、ここで発覚したのが、ジャンパSW1である。 Arduino UNOなどは、シリアル(USB)のところにジャンパがあり、 Arduinoがシリアル通信(受信)をする場合には、これをいちいち差し替えないといけない。 こちらのSUAC基板でも、上記のように「ジャンパSW1を[1-2]ON」としておくと、 ホストPCからArduino IDEがプログラムを書き込みたいのに、 そのラインにXBeeが受信信号を乗せようとしてくるので、 ハングアップして駄目・・・という現象が発覚した(^_^;)。

そしてここから、MIDI送信までは快調に進んだ午前中とうってかわって、 あれこれトラブって遅々として進まない・・・という午後になった。 とりあえず、XBee受信については、ホストのArduino IDEから書き込む時にはジャンパSW1を外しておき、 Arduinoを書き込んだら、Maxとシリアルポートの誤認を避けるためにUSBも外して、 その後、「ジャンパSW1を[1-2]ON」としてリセットしてスタンドアロン動作させる。 その後にXBeeモジュールをUSBに接続してMaxパッチを起動する、という手順が徐々に確立した。

しかし、あれこれ雑事も片付けながらの午後では、以下のようなソフト SUACboard_test006.ino で、とりあえずMaxからの情報を受信してLEDで表示するまでは行ったが、 1秒ごとにインクリメントしてLED表示するデータをMaxに送信する、というルートが成功しなかった。 まだ、どこかに何かある、という状態で、本日は終了ということである。 

long previousMillis = 0;
int interval = 1000;
int phase = 0;

void setup() {
  Serial.begin(38400);
  for (int i=2; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(13, HIGH);
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void loop() {
  unsigned long currentMillis = millis();
  int dd;
  if(currentMillis - previousMillis > interval) {
    previousMillis = currentMillis;  
    phase = (++phase) & 7;
    Serial.write(0xc0);
    port_data_out(0, phase);
    Serial.write(phase+0x30);
  }
  if(Serial.available() > 0) {
    dd = Serial.read();
    if(dd<128){
      port_data_out(1, dd);
    }
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}
明日の予定は教授会ぐらいであり、もう少し、Arduinoでの動作確認終了に向けて、進めていきたいところである。

2013年2月19日(火)

この日は、4回生の追いコンと卒展クロージングに関して、それぞれ学生から単発のアポがあったが、これは即決で対応した。 その他では、情報処理学会・音楽情報科学研究会が新年度から20周年を迎え、 5月には99回研究会、9月には100回研究会を開催する・・・というあたりで、 連日、運営委員の多数のメイルが行き来していたが、遂に99回研究会のCFPが完成して、 募集告知が始まった。 これ である。

100回研究会にはウイーン行きのため参加できないので、せめてこの99回研究会には参加したいのだが、 SUAC学生でこのテーマに興味ある学生と一緒に参加できないか、その作戦を検討中である。 せっかくなので、「ジャミーズ娘+」とか「SUACインスタレーション」とかのテーマでのポスター発表も、狙ってみたい。 あるいは1-2回生が参加することで、「音」「聞く」などをテーマとした、新しいデザイン領域に進むヒントが得られたら嬉しいと思う。

・・・などとあれこれしつつ、昨日の続きを、とSUAC基板のArduinoを立ち上げ、XBeeモジュールを立ち上げてUSBに繋ぎ、 Maxパッチを立ち上げてみると、なんと昨日の最後のソフト SUACboard_test006.ino が、なんの問題もなく正常に動作している、と確認できた(^_^)。 おそらく、昨日のトラブルは、ArduinoのUSBとMaxのXBee-USBとを抜き差しして、 OSがUSBポートを混乱して誤解したため(これは過去に何度か経験あり)、という事のようだった。 また、新しいArduinoファームウェアをロードした時には、Arduino上のリセットボタンだけでなく、 SUACボードの電源をいったん抜いて、再度入れるのが有効、という経験則も確認した。

そうなれば、昨日の実験予定だった、

  • Arduinoで8系統のアナログ入力(ジョイスティック4個)を検出
  • そのデータをXBeeからMIDI類似形式でMaxにワイヤレス送信
  • MaxではこのXBee信号を受信して、LED表示パターンに変換してMIDI類似形式でXBee送信
  • ArduinoはこのXBee信号を受信して、ディジタル出力ポートからLED表示
という動作の実現を目指すことになる。 ArduinoのA/Dコンバータ入力にはそこそこ時間がかかり、さらにそこからserialで送信するにも時間がかかるので、 メインルーチンのソフトタイマ待ち合わせを省略して、「Arduinoが最大限に頑張った速度」というのを設定したところ、 以下のように、 ソフト SUACboard_test007.ino によって、無事に希望する動作を確認できた。 

int phase = 0;
int old[8];
int ch;

void setup() {
  Serial.begin(38400);
  for (int i=2; i <= 13; i++){
    pinMode(i, OUTPUT);    
  }
  digitalWrite(13, HIGH);
  for (int i=0; i < 8; i++){
    port_data_out(i, 0);    
  }
}

void loop() {
  int dd;
  phase = (++phase) & 7;
  switch (phase) {
    case 0:
      dd = analogRead(A0)/8;
      if(dd != old[0]){
        old[0] = dd;
        Serial.write(0xc0);
        Serial.write(dd);
      }
      break;
    case 1:
      dd = analogRead(A1)/8;
      if(dd != old[1]){
        old[1] = dd;
        Serial.write(0xc1);
        Serial.write(dd);
      }
      break;
    case 2:
      dd = analogRead(A2)/8;
      if(dd != old[2]){
        old[2] = dd;
        Serial.write(0xc2);
        Serial.write(dd);
      }
      break;
    case 3:
      dd = analogRead(A3)/8;
      if(dd != old[3]){
        old[3] = dd;
        Serial.write(0xc3);
        Serial.write(dd);
      }
      break;
    case 4:
      dd = analogRead(A4)/8;
      if(dd != old[4]){
        old[4] = dd;
        Serial.write(0xc4);
        Serial.write(dd);
      }
      break;
    case 5:
      dd = analogRead(A5)/8;
      if(dd != old[5]){
        old[5] = dd;
        Serial.write(0xc5);
        Serial.write(dd);
      }
      break;
    case 6:
      dd = analogRead(A6)/8;
      if(dd != old[6]){
        old[6] = dd;
        Serial.write(0xc6);
        Serial.write(dd);
      }
      break;
    case 7:
      dd = analogRead(A7)/8;
      if(dd != old[7]){
        old[7] = dd;
        Serial.write(0xc7);
        Serial.write(dd);
      }
      break;
    }
  if(Serial.available() > 0) {
    dd = Serial.read();
    if(dd>127){
      ch = dd - 0xc0;
    }
    else{
      port_data_out(ch, dd);
    }
  }
}

void port_data_out(int port, int data){
  for (int i=0; i < 8; i++){
    digitalWrite(i+2, (data >> i) & 1);
  }
  for (int i=0; i < 3; i++){
    digitalWrite(i+10, (port >> i) & 1);
  }
  digitalWrite(13, LOW);
  digitalWrite(13, HIGH);
}

YouTube

これで、今回のSUAC基板でのホストは、Propellerに続いてArduinoについても動作確認OK、ということになった。 それぞれの拡張可能性の最大スペックを整理しておくと、以下のようになる。

  • Propeller
    • ディジタル入力　-　64ビット (8ビット * 8ポート)
    • ディジタル出力　-　64ビット (8ビット * 8ポート)　※個別PWM制御も可能(ライブラリ完備)
    • アナログ入力 - 16ビット　※外部A/D 8チャンネル * 2個
    • MIDI出力
    • MIDI入力
    • XBeeワイヤレス出力
    • XBeeワイヤレス入力
    • ビデオ出力　※最大2系統
  • Arduino
    • ディジタル入力　-　64ビット (8ビット * 8ポート) ★
    • ディジタル出力　-　64ビット (8ビット * 8ポート) ★
    • アナログ入力 - 8ビット
    • MIDI出力 または XBeeワイヤレス出力　※いずれか一方のみ
    • XBeeワイヤレス入力　※MIDI出力を使用の場合には不可 ★
    • ★ディジタル入力とディジタル入力とXBee入力は全てを同時動作できず、選択の組み合わせは以下のいずれかでのみOK
      • ディジタル入力+ディジタル出力　※XBee入力ナシ
      • ディジタル入力+XBee入力　※ディジタル出力ナシ
      • XBee入力+ディジタル出力　※ディジタル入力ナシ
これだけの機能があれば、単体のPropellerやArduinoに比べて、インスタレーション作品などへの活用の可能性は、 かなり大きく広がったと言えるだろう。なんせ、PC不要のスタンドアロンなのが大きい(^_^)。

4限には教授会があり、午後にわずかな時間が出来たので、 「音学シンポジウム2013」に関して、 こんなページ を作ってみた。 果たして、意欲あるメディア造形学生の応募があるかどうか、楽しみである。

2013年2月22日(金)

前の日記から2日が経過した。水曜日は毎年恒例の、メディア造形学科合宿(といっても今回は学内)であった。 SUACの他学科では無いらしいが、メディア造形学科では年に2度程度、全員が集まって終日あるいは丸2日、 ひたすら真面目に議論するだけの学科会議を行っている。 学生を伸ばすにはどうしたらいいか、メディア造形学科がさらに発展するにはどうしたらいいか、 などを学科全教員でひたすら真剣に議論する学科なんてのは、全国の大学を探してもなかなか無い。 少人数教育のSUACメディア造形学科の学生は、在学中にはあまり気付かないかもしれないが、とてつもなく幸せな学生なのである。

そして木曜日は、卒展の撤収関係のアポに対応し、午後は丸々、沖縄行きのミーティング、 それに続いて「メディア造形卒業生の軌跡」ということで、ひたすら映像を鑑賞する勉強会となった。 自分でもそこで気付いたのは、卒業制作の最終合評で観た作品から、 最後のDVDに入れるまでに納得いくまでブラッシュアップしていた、という多くの事例で、 初めて観たものも少なくなかった。 1回生にとって、十分な刺激となる先輩の仕事であった。(^_^)

そして金曜日である。午後からは入構禁止となり、明日の土曜日も入構禁止、 日曜日には大学院(文化政策研究科の方)の入試、そして月火はいよいよ、国公立の前期入試で、 5日間、関係者以外は入構禁止となる「静かな日々」である。 入試の監督をしている時間以外は、まったく邪魔の入らない、お仕事タイムが待っている。 この日は朝から、懸案だった今年のアルスエレクトロニカへの作品応募を、一気に片付けてしまった。 なんせ締め切りが3月8日であるが、入試の翌日から4日間(水-土)は沖縄行き、 そして翌週の火曜日はほぼ終日の予定で某Y社訪問、そして水曜日から金曜日(8日)までは、 情報処理学会全国大会の発表のために仙台に飛ぶので、あまり時間が無いことに気付いたからである。 過去にはVHSビデオテープを国際郵便で発送したり大変だったが、今は全てをオンラインで送れるようになり、 午前中で応募を完了することが出来た。

今回のSUAC基板の最初のバージョンについては、これまでに「Propeller」と「Arduino」の2つのホストについて、 動作確認を完了していた。 そこで、次はGainer miniである。Gainer miniだけはスタンドアロンでなくPCと繋がることになり、 ピン数と動作モードの制約のために、このSUAC基板に搭載するメリットがあるケースは限られる。 ただし過去の学生インスタレーション作品などの事例に照らしてみると、 この基板とGainer miniを使うことで、外部拡張の手間が大幅に低減するケースは少なくないだろう。

まず、改訂版ではpull-upすべき信号がopenとなっている場所に、 前回のArduinoの時に付加したpull-up抵抗が、以下のようにAKI-H8のソケットを利用した関係で、 Gainer miniの上空に邪魔になっているので(^_^;)、付け替える作業からスタートした。

まず最初に整理しておくと、このSUAC基板では、Gainer miniについては以下のような回路となっている。 8ビットのディジタル出力で拡張データバスに出力して、 さらに3ビットのアドレスを設定し、CKのラッチパルスを出す、という構成である。 従って、モード1などで使う場合にはまったく役に立たない。

SUAC基板でGainer miniを使うのは、64ビットディジタル出力に拡張する場合にだけメリットがあり、「モード6」専用である。 他のピンアサインのモードでは、SUAC基板でなく、従来のように拡張基板を手作りする事になる。 そして、まずはGainer miniのモード6のヘルプを呼び出し、以下のように、データバスの8ビットを適当に設定して、 アドレスも適当に入れて、CKのビットをH→L→Hとしてみた。

すると、ウンともスンとも言わなかった(^_^;)。治具基板のLEDは64個すべてが点灯したままである。 あれこれやっても状況が変わらないので、あらためて Gainer miniのサイト に行き、 質問掲示板 の中に、 Mac OS X＋MAX/MSPで不具合 というページを発見してしまった(^_^;)。 なんと、「Gainer miniはMaxではちゃんと動かない」(動作保証ナシ)というのであった。 これは衝撃的事実である。

過去に、学生が「Gainer miniがMaxでうまく動かない・・・」と持ってきた事があったが、 その時に研究室のMacでやったら動いたので、まさか動かないとは思ってもみなかった。 そこで、改めて授業用のPowerPCのPowerBookで実験してみると、 やはり、動かない。違いとしては、MaxウインドウにGainerのバージョンまで表示するので、 Gainerとの通信は出来ているようだが、しかし動作していない。これはヤラレタ(^_^;)。 今回、SUAC基板に普通のGainerでなくGainer miniを使おうと思ったのは、 単に基板サイズが小さいからだったが、どこかで小林さんが言っていたように、Gainer miniはGainer互換でなく、 「Gainerモドキ」なのだろう。

こうなれば、もう次回バージョンではGainer miniと決別して、正規のGainerを使うことになる。 基板サイズだけでなく、ピン間隔が互換でないために、スグにそのまま差し替えできないが、 まずは正しいGainerでの動作を確認する必要がある。 そこで以下のように、両面スルーホールのユニバーサル基板をカットして、シングルピンヘッダとGainerとを取り付けた。

そしてここからは、「良い子は真似してはイケナイ」といういつもの世界である(^_^;)。 というか、学生にこんなハンダ付けは到底、出来ない。 SUAC学生だけでなく、世の電気・電子系の工学系大学であっても、この程度のハンダ付けも出来ない学生が大多数である。 単なるピン間隔の変換ゲタなので、これで基板を起こすのもナンなので、ここは頑張るしかない。 1時間もかからずに、以下のように完成した。

そして以下のように、SUAC基板に搭載して、実験の再開である。 さきほどと同じMaxパッチが使えるので、まさに「そのまま再開」である。

すると、SUAC基板にGainerを挿してMaxパッチを呼び出すと、MaxウインドウにGainerバージョンが表示されないのに、 SUAC基板からGainerを抜いた状態だと、MaxウインドウにGainerバージョンが表示される、という明確な現象が確認できた。 これは、SUAC基板の方に問題がある、という事だ。 そして、さらに基板を調べていて判明したのは、openの筈の「RX」がGNDとショートしていた事で、 ここから最終的に見つけたのは、なんと「Gainerのピンの配線が、左右対称になっている」というバグであった(^_^;)。 こうなると、もしかするとGainer miniが動かない、というのも濡れ衣かも・・・という可能性も浮上する。

まずは原因解明、ということで、基板を設計していた11月あたりの日記を発掘して、 続・Propeller日記(5) の「2012年11月29日(木)」のあたりに、 この資料 と以下の図を見つけた。

しかし、こういう図は一般に「Top View」であり、敢えて断らない限り、これをBottom Viewと判断して左右を逆にする事はあり得ない。 続・Propeller日記(5) の「2012年12月10日(月)」にズラリと並んでいる、基板の各層の検図データを眺めてみると、確かにGainerだけ、 上下は合っているが左右が反対であり、「裏表が違う」というバグがあるが、 まぁ配線を設計していない身では、とても気付くことは無いだろう。 検図にOKを出しているので、これは「P板.com」に落ち度がある、という事ではないが、 また新しく改訂する事を考えると、このようなミスが起きた原因だけはハッキリさせておかないと安心できない。 そこで、まずは「P板.com」に、以下のように問い合わせのメイルを出してみた。 
P板.comサポート窓口 ○○○○　様

お世話になります、SUACの長嶋と申します。

> 下記案件、ご注文いただきまして誠に有難うございました。
>
> 　一括受付番号： 12112600071
> 　件名　　　　： SUACboard_ver0.5
>
> お届けいたしましたプリント基板の品質や、P板.comのサービス
> については、ご満足いただける内容でしたでしょうか。
> ぜひ、今後のP板.comサービス向上/改善に向けて、忌憚のなき
> ご意見、お気づきの点などお気軽にご連絡いただければ幸いです。

ということで、去年の12月に、初めて貴社に依頼した
基板をあれこれやってます。来年度(4月以降)に、この
基板の一部を改訂したバージョンを、また新たに発注
する計画となっています。

とても長いですしあれこれ寄り道してますが(^_^;)、
以下に、自分の備忘録と学生の教材として、貴社の
基板を初めて作った過程を記録していますので、
流し読みしていただくと、今回のメイルの話に繋がります。

スタートは
http://nagasm.org/ASL/Propeller2/index3.html
の中程、「2012年9月18日(火)」です。
そしてこれに続く
http://nagasm.org/ASL/Propeller2/index4.html
で回路の実験と設計を進めて、これに続く
http://nagasm.org/ASL/Propeller2/index5.html
の最後には、貴社に発注しました。(^_^)
そしてこれに続く
http://nagasm.org/ASL/Propeller3/index.html
の冒頭で基板が到着し、そこから部品の実装と
チェックの実験が始まりました。この基板では、
ホストとして4種類のマイコンを搭載するので、
まずは「Propeller」からです。これに続く
http://nagasm.org/ASL/Propeller3/index2.html
では、確認できた機能を活用して、実際に学生の
作品に最初のケースとして活用しました。(^_^)
こういう作品です。↓
http://www.youtube.com/watch?v=Af210cqoh5c
http://www.youtube.com/watch?v=991jm_JEWIQ
http://www.youtube.com/watch?v=Z4fgXdpbkmY
http://www.youtube.com/watch?v=ZC_pI9Q-O8Q
そしてこれに続く
http://nagasm.org/ASL/Propeller3/index3.html
で、2番目のホスト「Arduino」までチェックが
完了し、3番目のホスト「Gainer」に差し掛かった
ところが最新(最後)です。

そして、このいちばん下のところですが、
これまでにも細かい設計バグ(私のバグ)があって、
チェックして次バージョンで改訂するのですが、
なんと、「Gainerのピンが左右反対(^_^;)」
というバグに、本日、遭遇したところです。

つまり、図面で言えば、Top ViewとBottom View
を間違った状態で、現在の基板が出来ています。

これは、検図の時に気付かなかったので、100%、
私のミスで貴社には落ち度は無いのですが、
これまでの設計のやりとりのどこで、このミスが
起きたのかが分らないので、新年度に改訂する
際に、このままでは不安です。私の提出した資料
のどこに抜けがあったのでこうなったのか、
設計の担当の方に調べていただいて、仕様提出の
ミスの原因を教えていただきたい、というのが、
このメイルのお願いの主旨となります。

私の設計プロセスや、貴社に提出した資料、
貴社とやりとりしたメイルも、上記「日記」に
全て時系列で並んでいますので、余計な寄り道
をパスして(^_^;)、追いかけていただければ、
たぶん原因を指摘していただけるのでは、と
期待しています。

なお、来週には国公立前期入試があったり、
私も出かけたり学会出張があったり・・・と、
色々ある時期なので、回答はまったく急ぎません。
この春休みに全てのチェックをしてバグを出し切り、
新年度に貴社に発注する基板では全てを改良したい
という事ですので、ゆっくりと調べていただいて
結構です。
この基板自体のプロジェクトは完了しているので
恐縮ですが、このミスが自分のどういう不備で
起きたのか、を解明しておかないと、次の改良
に心配が残りますので、なにとぞ、回答を
お待ちしています。

以上、よろしくお願いいたします。
そして、左右反対ということは、基板の裏側にGainerを挿せばいいのだが(^_^;)、 現在の基板ではソケットが付いているので無理である。 ここはもう1個、「左右を反転させるゲタ」を作る必要が出て来た。 さらに、「Gainer miniは駄目だ」ということで、マルチメディア室のロッカーに、全てのGainer miniを戻してきたところだったが、 もしかするとこれは濡れ衣で、使えるのかもしれない。これもチェックする必要があり、再びマルチメディア室のロッカーから1106に持ってきた。

そして、1106研究室からマルチメディア室まで往復する間に、フト、うまい手を思いついた。 以下のように、Gainerのピン配置は、ほぼ左右対称である。 唯一、違うのは「Tx」「Rx」の端子で、反対側がともにGNDになっていて、 今回は、これによって「Tx」「Rx」が強制的にGNDとなって、ホストPCと通信出来ない、というトラブルの原因となった。

しかし考えてみれば、ホストPCとはGainer上のUSBコネクタで接続していて、「Tx」「Rx」のピンは共にopenなのである。 そこで、「左右を反転させるゲタ」を作るまでもなく、SUAC基板とGainerとの動作チェックについては、

  • 基板からGainerの「Tx」に行くピンを切る(接続しない)
  • 基板からGainerの「Rx」に行くピンを切る(接続しない)
  • ポートの番号は左右が反転している、と意識してMaxパッチの方で対応する
    (モード6は16ビットが全てディジタル出力なのでOK)
ということで、なんとか対策できるのであった。 そこでさっそく、せっかく付けた9-10ピンと19-20ピンの計4本をカットしてみると、 ちゃんとMaxパッチは「gainer_firmware_version: 1.1.0b01」と表示して、 試しにいくつかのポートにデータをラッチさせてみると、ちゃんと動くことが確認できた(^_^)。 とりあえず、現象の確認はここまでOKである。

そして再度、マルチメディア室からもってきたGainer miniを、基板に挿さずに接続してみると、 やはり、研究室のメインMac(Intel Mac)では、Gainerとして認識されなかった。 これで事態の究明と対策については、明確になった。 やはりGainer miniは使わずに、改訂版の設計では、正規のGainerを使うことになる。 ビン配置図のサイズが変更になるのと合わせて、左右反転のバグもここで解消すればよい。 「P板.com」からの連絡を待って、この改訂の際にはミスがないように仕様を出すことになる。 

■SUAC board ver.0.5からの改善点リスト■

●バグなので次バージョンで必ず改訂する項目
・2個のA/DコンバータのRD・CSに行くチップセレクト信号を「CCS1」「CCS2」に変更する
・PropellerとAKI-H8から出ている信号を↑と対応して「CCS1」「CCS2」に変更する
・XBeeのDinとDoutが逆(^_^;)なので入れ替える
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
・↑そのpull-up先の電圧を+5Vとするか+3.3Vとするか、のジャンパが必要
・ArduinoNanoのアナログ入力端子の番号が逆順なので信号を逆順に付け替える
・Gainer miniは非互換なのでGainerに改訂する

●必須ではないが改訂することになれば盛り込みたい項目
・電源コネクタ
・電源給電表示LED
・半固定抵抗の穴を2mmφにする
・半固定抵抗の中央穴の位置を0.1インチ離す

●現行SUAC board ver.0.5の増産時に対応すること
・XBeeのDinとDoutが逆なので基板配線面をカットして修正する
・2個の138のG入力の2本と、2個のAD7829の出力イネーブル(CS/RD)の2本にpull-up抵抗が必要
	→そのpull-up先の電圧はホストに対応して+5Vまたは+3.3V
・Propellerの26ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする
・Propellerの27ピンから上下に出ている配線のうち、上の基板端に向かうラインを残し、
	下の138に行っているラインだけをカットする
・ArduinoNanoのアナログ入力端子の番号が逆順なのでソフトで逆順に対応する
・Gainer miniは使わない(使えない)(^_^;)
・Gainerの9-10ピンと19-20ピンの計4本をカットして浮かす
	→Maxソフトでは「左右反転している」と理解して対応する

●その他メモ
今日はここまでとして、「次回に訂正すべきメモ」を、上のように修正した。 明日からの土日では、ソフトで尻拭いしながら、Gainerでどのくらいの「64ビット出力」制御が可能か、 その性能を調べてみたい。

2013年2月23日(土)

この日は朝から、米国から届いたメイルで盛り上がった。 キッカケはSketching in Hardwareを主宰している、Mike Kuniavsky氏からのコミュニティMLへのメイルである。 Sketchingコミュニティの仲間であり、世界先端のデザインスタジオIDEOのデザイナ、 Dave Vondle氏がkickstarterでプレゼンして出資者を募っていた プロジェクト に、なんと1ミリオンドル(100万ドル)、つまり1億円以上の出資が集まって開発がスタートした、 という凄いニュースである。 このページにある動画はYouTubeではないのでダウンしたが、 これ である。Daveはビデオの右側に出ている。 ちょうど、Appleが時計の特許を出して、いよいよ「iWatch」か、というニュースが盛り上がっているが、 まさにこの「世界でもっとも薄い時計」は「iWatch」である。 気付くのが遅くて、今から注文できないのが残念である。

ビデオに登場する右側のDaveは、去年のSketchingに行った時の レポート ページの冒頭の写真の左側に映っている。 つまり、「ジャミーズ娘+」を絶賛してくれた、Jaminatorを生み出したスタジオIDEOの、 ばりばり現役のデザイナなのである。 凄い友人を持っていることがとても嬉しい(^_^)。 Sketchingコミュニティの仲間から次々に「おめでとう」のメイルが届き、 もちろん僕も、SUAC基板とか学生インスタの近況を添えつつ、賛辞を送った。 するとさっそく、Dave本人から皆んなに、「This is super-exciting. I can't wait to share everything I'm learning at sketching '13!」 とのメイルが届いた。 今年のSketching2013では、このプロジェクトの内幕が全て、紹介されるのだろう。 こうなると、なんとしても今年も参加しないといけない、と再確認した。 Sketchingでは、全ての参加者が聴講だけでなく自分のプロジェクトを発表しなければならない。 つまり、常に最新に前進していなければならないのである。 Propellerとともに、さらに進展していこう。(^_^)

さて、SUAC基板の続きである。 昨日までに、PropellerとArduinoでの動作の確認に続いて、Gainerはピン配置が左右反転している、 というところまでチェックしていた。 Arduinoに入ってからというもの、まったく「Propeller日記」でなくなっているが(^_^;)、 いずれ戻ると信じて、このまま進んでいこう。

Arduinoのアナログ入力のビット番号が反転している、というバグも発見しているが、 まぁこれはビットごとに個別の注意点なので、とりあえずは放置であるが、 ここでのGainerのピン配置の左右反転バグについては、 64ビット・ディジタル出力のためのデータバスと、8ビット単位のラッチを指定する3ビットのアドレスと、 ラッチのCKパルスとで、ソフト的に対応できるとしても仕組みが一体となっているので、 「ソフトで対応」と簡単に切り捨てられない。 そこでまず最初に、モード6のサンプルパッチに、以下のような「尻拭い」対応のサブパッチを仕込んで、 ここで開発したバッチが、改定後にもそのまま使えるようにした。

上の「gainer_mode6.maxpat」の16ビットのディジタル出力のための16個のトグルの下に作った、 サブパッチ「bug_correct」が、右端の入力によって、「素通し」と「左右反転」を行う。 このパッチのdefaultは、loadbangにあるようにゼロなので左右ビットを反転させるが、 改訂して正常になった場合には、ゼロでなく1を入れれば「素通し」となる。 このサブパッチを、SUACボードでGainerを使うMaxパッチでは、標準のソフト部品とすればいいわけである。

まず最初は、「gainer_mode6.maxpat」を複製してリネームした以下の「SUACgainer_01.maxpat」で、 8ビット単位のデータをバイナリにデコードし、3ビットのアドレスもバイナリにデコードして、 ラッチパルスを出す、という「道具立て」を用意した。

次に、上の「SUACgainer_01.maxpat」複製してリネームした以下の「SUACgainer_02.maxpat」で、 64個のLEDを全て消したり点灯させたり、という基本パッチを作ってみた。 「uzi」とは、システムの最高速度で多数のトリガを出す、というものであるが、 これを走らせてみると、たまに点灯しなかったり消灯しなかったりする列が出た。 つまり、GainerドライバがGainerとポーリングしている速度に対して、ちょっとだけ早過ぎる、という事である。

そこで、この「uzi」を単純なインクリメントのループにバラして、 時間遅延を入れてテストしてみたのが、以下の「SUACgainer_03.maxpat」である。 これにより、10ミリ秒ではたまに書き込みミスが出るが、12ミリ秒にすればほぼ確実に64個のLEDを制御できる、 と確認できた。 こういうテストが簡単なのが、Maxの楽しいところである(^_^)。

こうなれば、あとはMaxのプログラミングによって、 簡単なパターン表示をさせるだけである。 以下の「SUACgainer_04.maxpat」では、最初に全体のON_OFFを繰り返した後で、 列ごとにパターンを送ってみたが、4列目あたりから、全ビットがちゃんと表示されなくなる、 という「いじわるテスト」である(^_^;)。 これは、ｄｅｌａyなしに、4つ以上のラッチのデータを一気にトリガしているからであり、 このあたりが、Gainerの速度の制限となってくる、という実験である。

YouTube

もちろん、インスタレーション作品など、人間とインタラクションするシステムであれば、 この反応速度は十分に速いもので、実用上は問題ない。 LEDをPWM連続制御するような場合には、Gainerを単体で使用して、そういうモードを活用すればよく、 要するに適材適所の使い分け、というのが重要である。 これで、Gainerまでの動作チェックは完了、Maxパッチをまとめたものは これ である。 SUAC基板でGainerを使うのは、ここで実験したように、最大64ビットのディジタル出力、 つまりLEDやランプ、ソレノイドやリレーやモータの制御、ということである。 過去の多くの作品で、手間ひまかけて基板を製作してきたが、今後はこれだけでも、 十分に簡略化することが出来るようになったのは大きい。(^_^)

2013年2月24日(日)

「浜松マラソン」があるというこの日は、いつもの日曜日のように遅めに出かけると、 自宅からSUACまでの通勤路の途中に約10カ所ほど、 「08:20-09:20は通れないので迂回せよ」という関門が登場することになるため、 平日と同様に朝7時過ぎには研究室に着いた。 そしてこの日は、この「続々・Propeller日記」にとっても大きな節目とする事を、昨夜のうちに決めていた。 とりあえず、今日でオシマイにする、という事である。(^_^;)

元々、この「Propeller日記」は、Propellerという素晴らしい(変態的な)チップと知り合ったことでスタートしたが、 その後の「続・Propeller日記」以降は、どちらかといえば自分の備忘録という意味合いが強かった。 途中からSUAC基板の開発という新しいテーマに継続してきたが、ベースとしては寄り道して日々の諸々も書きつつ、 やはり、後日に思い出すためのメモ資料集、という特性は一貫している。 あまり丁寧に書いていないので初学者には難しいかもしれないが、 実はマイクロエレクトロニクスや情報工学のテキストとしての意味合いも、内心は込めているのである。

SUAC基板についてはここまでのところで、PropellerとArduinoとGainerについて確認できて、 設計のバグは新年度(4月以降)の改訂版の開発まで、お預けという状況である。 ここでいったん区切りとする、という理由であるが、「SUAC基板ではAKI-H8は使わない」という新方針による。 これまで、数えきれないほどのシステムを秋月電子のAKI-H8で作ってきたが、AKI-H8は単体で、 つまりSUAC基板の拡張機能の助けナシに、多くの仕事を実現出来てしまうのである。 その一方で、当初の予想以上に、Propellerの能力が素晴らしく、かつては「AKI-H8でしか出来ない」 と判断していたシステム機能も、SUAC基板を使うことで、Propellerでほぼ全て、出来てしまう。 そこで、今後の新バージョンのSUAC基板では、 基板上のスペース確保(Gainer miniから通常のGainerに大きくなる余裕が必要)と、 ピン数の確保のためにも、ここは「AKI-H8を外す」という選択肢が重要である、 と確信するに至ったのである。

おそらく、今日でこの日記を終えて、「続々・Propeller日記」のシリーズは(3)までで終わりである。 追記があるとすれば、「P板.com」からのメイルが来たら、その情報を改訂のために追加するぐらいである。 ただし、もしかすると4月以降に「新・Propeller日記(^_^;)」というややこしい形で再スタートする可能性は少なくないが、 その時の主役は、間違いなくPropellerなのである。 そして今日は、このシリーズの最終回として、残された「AKI-H8」について、 備忘録・技術資料という意味も込めて、整理してみたいと思い立ったのである。 実際には、先週から待っていたNHK将棋講座(講師の屋敷9段の解説のテーマが[先週のNHK杯で得意の戦法として展開したのにボロ負けした]穴熊(^_^;))とか、色々と余計な寄り道もする。なんせ休日なので。

これまでにAKI-H8によって作ったシステム、というのは膨大であるが、 基本的には ここ に全てある、という事である。 2000年以降の、SUACでのインスタレーションについては、 ここ と ここ と ここ にある、という事である。 今日の作業は、根気が続いたとすればであるが(^_^;)、これらの作品/システムについて、 ラフな手描きで残っている資料(回路図)をスキャナで取り込んで残し、 対応するAKI-H8ソースプログラムもplain txtとしてリンクさせて置き、 上記のWebにある情報と関連付ける、というものである。 場合によっては、「SUACインスタレーション」のWebには、個々の作品の場所にリンクできるように、 アンカータグを付けて改訂することになる。 面倒な作業であるが、どこかでやらないといけない。 ちょうど、明日と明後日は前期入試、その翌日から4日間は沖縄行き、とインターバルが空くので、 今日は「区切り」日和なのである。

実はSUAC基板からAKI-H8を外す、という決断の理由には、「Windowsだから」というのもある。 正確に言えばWindowsではなくて「MS-DOS」なのだが、要するに「Macで開発できない」のが、 最大の欠点である。 「Propeller日記」が終了していたのも、「続・Propeller日記」として再開したのも、同じ理由である。 Windows環境でしか開発できないのでPropeller日記は終了した。 そして、Mac環境でPropellerが開発できるという「bst」と出会ったことで、再開したのである。 そこで、AKI-H8について整理するお話は、「1106研究室のWindowsパソコン」からのスタートである。

まずは、2013年2月24日現在、1106研究室にあるパソコンを数えてみた。 ちょうど、卒展とかで学生に貸し出していたパソコンが全て戻ってきていた。 すると、Macは全部で15台あったが、Windowsは以下の5台であった。 ここ数年で、かなりの数のMacを壊して捨てていたが、そこそこ残っていた。

上の写真の(1)は、東芝のリブレットでWindows95である。 秋葉原の中古ショップで見つけて、 このために 活用したが、最近ではKymaとともに、出番が無くなっている。 また写真の(2)は、パナソニックのノートでWindows98である。 上記リブレットの前までKymaのホストとして使っていたが、これもKymaとともに、出番が無くなっている。 いずれも、内蔵バッテリは干上がっていて、ACアダプタでないと動かない。(^_^;)

上の写真の(3)は、富士通のFMVノートでWindowsXPであるが、 ここ とか ここ とか ここ に登場した後に、AKI-H8開発のホストとしてずっと活躍している現役である。 写真の(4)は、「 未踏 」の時に購入したDELLのWindowsXPで、現在はDVD書き込み機として現役である。 また写真の(5)は、元々は「初音ミク」を買った時に、他のパソコンではスペックが不足するので購入したACERのWindowsXPであるが、 初音ミクとともに、出番が無くなっていた。 今回、基板の設計ソフトを走らせるのに現役復帰したところである。

まずは、(3)のパソコンを起動して、中にあった、AKI-H8関係の「MS-DOS」というディレクトリをそのまま、 このように 圧縮してMacに持ってきた。圧縮前のデータサイズはたった47MB(そのうちPDFのマニュアルが40MB以上)である。 その中身は以下のように、これまでに開発したAKI-H8(さらにZ80のAKI-80も!)の全てのソース、 さらに秋月電子のアランブラやコンパイラ、そして幻のDESMET-CというCコンパイラまで満載である。

ここで注目して欲しいのは、それぞれの開発ツール(アセンブラ、コンパイラ、リンカ等)のサイズである。 タイムスタンプを見ると分るように、1980年代後半から1990年代前半とはいえ、 驚異的にサイズが小さい。 それでいて、Windowsから「DOSプロンプト」を開いて起動してやれば、ちゃんとバグ無く動作してくれるのである。 比較のために、以下に、ちょっと古いがMacのXcodeという開発ツール(データサイズは10.42GB)を並べてみたが、 このサイズの違いは、まさにITの歴史そのままである。

ちなみに、これら現役のWindowsはもっとも新しいものでXPであるが、まったく不自由はない。 基板CADももちろんXPでOKである。 Windowsのことはよく知らないが、Vista? 7? 8? まで色々あるらしいが、多くの企業が継続しているように、 実際のところはXPを越えていないらしい。 まぁ、僕がMacOS7.5にお世話になったのは1990年代前半、そしてMacOS8.6にお世話になったのは1990年代後半、 MaxOS9.2にお世話になったのは2000年代前半なので、 いずれ数年後には、ようやくWindowsも「Windows 9」を経て、「Windows X」になるのかなぁ(^_^;)。使う気は無いが。

・・・ここでお楽しみの将棋タイムと昼食があり、午後になってようやく作業を始めることになった。 これまでにWebで回路図やAKI-H8ソースコードを公開しているものを除いて、 ロッカーから出て来た資料は10数件あった。これを全部、発掘してアップするというのは大変だが、行けるところまで行ってみよう。

まず最初にあったのは、SUACが開学した翌年の2001年に、技術造形学科の教員が共同で制作した、上の写真の「お掃除ロボット」である。 関連情報は ここ にあるが、ディファレンシャルGPSからの位置情報によって、SUACの周囲にある池の中を動き回って、 藻が発生するのを抑止しよう・・・というロボットである。 僕が担当したAKI-H8システムは、センサ(GPS)からの制御信号を受け取って、 モータ制御のリレーをコントロールするもので、 AKI-H8ソースプログラムは これ である。

実はこの半年前には、知人の富士通テンの技術者にカーナビ用の小型GPSモジュールを紹介してもらって、 AKI-H8とLCDモジュールとを接続して、SUACの「出会いの広場」を歩き回ると、その緯度と経度を小数点以下2桁まで刻々と表示する、 という以下のような実験装置を作っていた。 そのAKI-H8ソースプログラムは これ である。ごく初期にしかプログラム中に日本語は使っていない(秋月のサンプルを手直しした頃)が、 もし文字化けした場合には「シフトJIS」にすると正しく見える。

この2001年には MAF2001 があり、SUAC学生のインスタレーション作品のほぼ全てを支援した。 上の作品「 はち 」 に関しては、以下のような淡白な(^_^;)資料が残っていて、 AKI-H8ソースプログラムは これ である。

翌年の2002年には MAF2002 があり、SUAC学生のインスタレーション作品のほぼ全てを支援した。 手元にあったのは、以下のような超淡白な(^_^;)資料だけであり、回路図などはまったく描かずに製作している。 これだけで3作品の制作メモとなっている。

上の作品「 閃(きらめ)き 」 のAKI-H8ソースプログラムは これ である。

上の作品「 Chessでポン! 」 のAKI-H8ソースプログラムは これ である。

上の作品「 けつプッチン 」 のAKI-H8ソースプログラムは これ である。

2004年には NIME04 があったが、その対応で忙しい中、上のような Hand Roll Piano をMIDI化してみました というページを作っていた。忙中閑あり(ヤケクソ)、というやつである(^_^;)。 このページでは「詳細な回路図とAKI-H8のソースの公開はやめておきます」と書いていたが、 発掘した資料は以下であり、AKI-H8ソースプログラムは これ である。

2006年には、 SUACインスタレーション のページには載っていないものの、前年の2005年にあった MAS2005 から繋がって制作してきたいくつかの「光る系」の学生インスタレーション作品を、 オープンキャンパスにおいて瞑想空間で展示した。 あいにく写真は暗い空間での動作状態ではないが、以下にAKI-H8の資料の残っていた3作品を紹介する。

上の写真と資料は石川さんの作品で、来場者が近付くと、16個(4×4)のブルーLEDが色々なパターンで点滅する。 そのシステムのメイキングは これ であり、AKI-H8ソースプログラムは これ である。

残念ながら写真が無いが、上の資料は山口翔クンの作品(ぼんやり明滅し持ち上げると色が変わって点滅する小型の箱を10個)で、 AKI-H8ソースプログラムは これ であり、この他に、写真は無いが別に空間演出を目指した3人のインスタ作品のAKI-H8ソースプログラムは これ である。

上の写真と資料は岩見さんの作品で、来場者が近付くと、普段はゆっくり明滅している5本の柱が別のパターンで点滅する。 AKI-H8ソースプログラムは これ である。

2006年になると、 SUACインスタレーション(2) のページに載っている、 MAF2006 や卒展で発表された学生インスタレーション作品、あるいは僕がパフォーマンスするために制作した新楽器"Cyber Kendang"などに、 AKI-H8が活躍した。

上の写真と資料は山口翔くんの作品「 風見屏風(かざみびょうぶ) 」 であり、システムのメイキングは これ であり、AKI-H8ソースプログラムは これ である。

上の写真と資料は、Maxを究めたいと僕のところに弟子入り希望で大学院に来てくれた嶋田くんの作品「 電車で音を出すサウンドインスタレーション 」 であり、システムのメイキングは これ であり、AKI-H8ソースプログラムは これ である。

上の写真と資料は、翌年のNIME2007で゛入選してニューヨークで公演したComputer Music作品パフォーマンスのための新楽器と作品「 Cyber Kendang 」 であり、システムのクローズアップは ここ にあり、そのAKI-H8ソースプログラムは これ である。

上の写真と資料は河原崎くんの卒業制作インスタレーション作品「 Beat Box 」 であり、8×8=64個のスイッチが6面全てに配置された、計384個のディジタル入力を検出してMIDI出力するシステムのため、 一部の配線を河原崎くんにやってもらうために、異例の親切さで丁寧な資料となっている(^_^;)。 システムのメイキングは これ と これ であり、AKI-H8ソースプログラムは これ である。

これまでに製作してきたシステムの中には、学生インスタレーション作品などに使うものだけでなく、 顔も声も知らない相手に依頼されて製作・提供した、というシステムもいくつかある。 ネットで僕のサイトを見て、部品代に毛が生えた程度、という製作費で依頼してくるわけである。 相手が企業とかしっかりしている場合には、技術士として相応のコストを請求するのと違い、 モードとしてまったく相反する2つが混在しているのである(^_^;)。

上の資料(写真ナシ)は、音楽愛好家のSANOさんという人から依頼された内容と、 その回路図と仕様である。 システムのメイキングは これ と これ であり、AKI-H8ソースプログラムは これ である。

上の写真と資料は山田さんがインターカレッジ2007で発表したインスタレーション作品「 circles 」 であり、4個のスイッチと192個のLEDが並ぶ力作である。 Maxプログラミングを山田さんか自力で行うために、こちらも異例の親切さで丁寧な資料となっている(^_^;)。 システムのメイキングは これ と これ であり、AKI-H8ソースプログラムは これ である。 このシステムはマルチメディア室に動態保存しているので、MIDIをやりとりするMaxプログラミング次第で、 同じハードウェアでもまったく違った動作を行うインスタレーション作品に生まれ変わらせることが可能である。 誰か、挑戦したいという学生がいれば、いつでも貸し出すのに・・・。

上のあまりに淡白な回路図は、「RF-ID」タグを読み出すRF-IDリーダの情報をAKI-H8が読み込んで、 その状態をGainerに出す、というシンプルなシステムであり、AKI-H8ソースプログラムは これ である。 このシステムはSUACメディア造形学科の標準インターフェースとして、これまでの作品では、 大塚さんの「 白い絵本 」、松永さんの 「 無機の眼 」、野口さんの 「 はやくスシになりたい 」、山村さんの 「 おはなしパネル 」、野口さんの 「 二人はウラハラ 」、金子さんの 「 空からの贈り物 」、などの作品で活躍している。

上の写真と資料は、鈴木絢さんの修了制作「ネジマキニンゲン」に使用し、 さらにこれをベースに新しいプロジェクトとして MAF2009 で発表したインスタレーション作品「 ネジマキウォール 」 であり、システムのメイキングは これ と これ であり、AKI-H8ソースプログラムは これ である。

上の写真と資料は、見崎さんの修了制作「 OTOcakecco 」 であり、システムのメイキングは これ と これ と これ と これ と これ と これ と これ と これ と これ と これ と これ と これ と これ と これ である。 63個のLEDを個別連続値点灯制御するシステムの部分は、 「靄夜」(もや) のシステムを完全に再現したので、資料はそちらにある。 衝撃センサ21個のシステムの方のAKI-H8ソースプログラムは これ である。

上の写真と資料は、韓国・ホソ大学校からの交換留学生、柳　俊煕(リュ・ジュンヒー/Ryu Junhee)くんの作品 「 カラーオーケストラ 」 であり、システムのメイキングは これ と これ と これ と これ であり、AKI-H8ソースプログラムは これ である。

リュ君はこの半年のプロジェクトでサウンドインスタレーションやエレクトロニクスの面白さに目覚め、 8月の前期入試を受けて、SUAC大学院への進学を決めた。 新年度(もうあと1ヶ月ちょっと)から、僕のところに弟子入りして、さらに新しい世界に向けて成長していく。 僕としても、一緒にあれこれスケッチングを楽しみながら、全力で応援していきたい。

2013年2月26日(火)

国公立前期入試・2日目の朝07:00である。 昨日の1日目は、鉛筆デッサン実技の監督180分、ずっと座らずに立って、心の中で受験生を応援した。 今日の発想表現実技の監督も180分、ずっと座らずに立って、心の中で受験生を応援する予定である。 勝手に自分に科している、毎年の苦行である。来月の後期入試の実技は240分である。(^_^;)

完了した筈の日記に追記しておくのは、「P板.com」から届いたメイルである。 ミスをちゃんとミスと認める、この潔さは、気持ちいい。次回もまた、お願いしたいと思った。(^_^) 

静岡文化芸術大学 長嶋　洋一 様 

いつもお世話になっております。P板.comサポート窓口 ○○ ○○です。 
お問い合わせいただきまして、誠にありがとうございます。 

Gainer-Mini（U4）のピンが左右反対の件について、弊社内で確認をさせていただきました。

結果から申しますと長嶋様が資料にてご指示いただいたピン番号の振り方が正しく
弊社にて作成した部品のピン番号振りがミラーしており今回の
> 「Gainerのピンが左右反対(^_^;)」
> というバグ
に結びついてしまいました。
大変申し訳ございません。

今後、このような事が発生しない為に原因究明と対策を作成し
後日ご報告をさせていただきます。

大変申し訳ございませんが、少々お時間をいただけますようお願い申し上げます。

宜しくお願いいたします。
「安心しました。また新年度にお願いします」とメイルして、これでこの日記は本当に完結である。 今日の入試監督を頑張って、明日からは沖縄である。(^_^)

→ 続きはこちら

→ さらに続きはこちら

続々・Propeller日記(4) へ

「日記」シリーズ の記録