# 卒研経過報告(Eチーム) #7
タンジブルなプログラミングデバイスCU-Brick(キューブリック)に関する研究
team member : 子安，鈴木，堀
GitHub : https://github.com/KoyasuJunya/cu-brick-tangible-master
次週：https://hackmd.io/hSUV1xX3RdaSHrx_FCKmcw
## 心得
* 得た結果に付随する根拠を記録する．
* 日々，どんな活動をしたのかを記録した「実験ノート」をつくる．
* 思い付きで発表しない(結果には原因がある．推測するんじゃなくて，それをしっかり調査する)．
* 問題を筋道立てて考える．
* 客観的に文章を書く(感想文はNG)．

# 実験日:6月13日(日),14(月)
6月15日発表分
## 前回までと今回の目標
v2のソースを用いて動作確認をしたが，期待した動作をしなかった．そのため何かしらの原因があると見て，原因をいくつか推測し，実験して確かめる．加えて，原因が分かったらその解決策も探す．
## 推測される原因と手段
* ソースをv2に更新した時に何か問題が生じた可能性がある．したがってv1のソースで動作確認を行う．正常に動作したならば，v2に更新する過程で何かしら問題が起こったという事が分かる．また，TeraTermを用いてボードの抵抗値を測り，v1とv2でボードの読み取り具合に違いが生じているかも調べる．(役割１)
* ソースの中にprint文を挿入し，デバッグ作業を行う．挿入する位置を変える事でどこまでプログラムが正常に動作しているのかについて調べ，ソースの修正点を調査する．表示されなくなれば，その部分のソースが正常に動作していないという事が分かるので，その部分のソースを読み，修正箇所を探す．(役割２)
## 役割
1. v1の動作確認と，V1とV2での抵抗値の確認(1人)
2. プログラムの修正箇所の調査(2人)
* 送信側，受信側で各1人
* それぞれが独立した調査を行う．

## 1. v1の動作確認と，V1とV2での抵抗値の確認<鈴木海岬>
#### 実行環境
No.1からNO.7までの抵抗値を確認したところNO.6が一番安定した数値が出ていたため以降はとりあえずNO.6を使用する．

環境
図のような配置で抵抗値を図る．
また，hexファイルの作成手順は変えるが，使用するプログラムはどちらも全く同じプログラムを使用することとする．

なるべき抵抗値
プログラムの中にスタートブロックは64を，〇を表示するブロックは3を返すとあるため，左上が64，そこから3,3,3,3,3,3と続き他はすべて0と表示される．

#### 結果
* V1の場合
上の図のように理想どうりの抵抗値が出たことが分かる．
しかし，抵抗値の確認をしているとプログラムの容量が大きいようで，0→2→0と，マイコンに表示され動かなくなってしまうことが分かった．

* V2の場合
この図からV1のときとは違い，抵抗値がおかしくなっていることが分かる．
正しいと思われるのが左上のスタートのブロックだけであり，他の抵抗値はすべておかしくなってしまっている．
しかしV2は書き込むことのできる容量が多いのか0→2→0という容量がパンクした時に表示される信号は表示されなかった．

#### まとめ
全く同じプログラムを使用したにも関わらずV2の場合でのみ抵抗値がおかしくなっていることがわかった．
また，V1での場合では求めている結果が表示されていた．
このことから，原因はハードウェアではないことが分かった．
自分の予想としては，hexファイルへの変換部分で何かおかしくなってしまっているか，V1では機能していたプログラムがV2では機能しなくなっているではないかと考えた．

## 2-1. プログラムの修正箇所の調査<堀康介>6/15欠席(就活)
### send側のソースのmainの調査
send側(ボードに差す側)のソースがどこかで正常に実行されず，プログラムが途中で止まっている可能性があるため，プログラムの各所に数字の7をLEDで表示する命令文を差し込み，段階的に実行状況を調べることにした．以下は差し込んだプログラムである．

uBit.display.print(7);

このプログラムをmainに挿入し，一行一行プログラムが実行されているかどうかを確認した．その際，microbitはボードに接続してあり，また，rec側のmicrobitも用意した状態で実行した．以下の画像はmain部分のソースと，実行結果のLEDである．
その結果，mainにある命令文は全て実行されていることが分かった．この事から，ボードの読み取りや読み取ったデータの送信などの処理をしていない状態を維持している場合，send側のソースは問題なく動作しているという事が言える．

## 2-2. プログラムの修正箇所の調査<子安潤弥>
受信側のmicro-bitプログラム(micro-rec)のデバッグ作業を行う

#### 前回までの内容とその考察
* ~~2つのマイクロビットの通信を確認した~~
→　通信できていたという根拠を示す．
→　受信側micro:bit側に表示されたsmileマークについての調査
→　正常に動作しない原因を探る

#### 実験内容
* デバッグ作業
受信側micro:bitで動作確認を行うため，以下のソースを挿入し，問題のある部分を探る．

uBit.display.print(7);

1. main()内
2. Start()内 (プログラム実行ルーチン)
3. Decode()内 (識別番号に対応した動作を実行した後,現在位置を更新する)
4. Exec()内 (通常ブロックの動作)

受信側のソース(micro-rec)は全て正常に動作していることを確認した．

* シリアル通信
ブロックの通りmicro:bit側に伝わっているか，シリアル通信を用いて検証を行う．

| ブロック名 | ブロック値 |
| -------- | -------- |
| 開始ブロック | 64 |
| ハート表示 | 1 |
| 小ハート表示 | 2 |

**1回目(成功)**
ボードの問題により1列目は認識されていないが，正常に動作している．
**2回目(失敗)**
ハート表示(1)が，小ハートが表示(2)と誤認識されている．
**3回目(失敗)**
開始ブロック(64)が，小ハートが表示(2)と誤認識されている為，実行可能状態に移行しない．

## まとめ
1. **ハード面での問題**
あらゆるボードで実験を行ったが，個体差があり認識されない場所が多く存在する．

2. **実行可能状態(smileマーク)に高確率で移行しない原因**
実験の通りv2はブロックの値が頻繁に変動する為，開始ブロックも認識されていない事が頻繁にある．v1とv2で挙動が異なる事を確認した．

3. **ブロックの通り動作しない原因**
micro-recのソースで該当箇所を調べた結果，smileマークは実行可能状態であり，実行状態にする為にはaボタンを押す必要があった．最初からデバック作業を行う中で判明．また2.より毎回受け取る値が異なるため，他のブロックと認識されてしまい，動作ができていない．

4. **音が出ない原因**
そもそもv1にはスピーカーが内蔵されておらず，外部機器を取り付ける必要があったが，v2はスピーカーが内蔵されているためソースを改良する必要がある．

## 次回の目標
* v2で受け取る値(抵抗値)が変動する原因究明と改善
[](抵抗値を変換する変数に問題がないか)
* スピーカー動作箇所をマイコン本体からの再生が可能になるように修正