2019/09/28

gitのrebase

gitを使っている。

gitの説明って、だいたいコマンドラインで行われている。
コマンドを覚えるのが面倒なのでツールで済ませてしまいたいのだが、ずっと使っていてわかった。
なんだかんだで、コマンドラインでやらないと細かいことがやりづらいのだ。

いつか「gitの困ったときだけ使うGUIツール」みたいなのを作ろうかと考えていたのだけど、コマンドラインには叶わんのだよなぁ。。。

 

さて、gitを自分だけで使う分にはそこまで気を配らないのだが、チームで使うとなるとそうもいかん。
気にするのは、こんなところだろうか。

  • 自分に変なことが起きないようにする
  • 相手に変なことが起きないようにする

まあ、他に何があるんだっていわれそうだが、まずはこの2点に気を配るだろう。

 

GitHubでgitを使っているので、本体のリポジトリをforkして、branchを作って作業して、pull requestして本体にマージ、という流れにしている。
作業しているbranchは自分のものだから、好き勝手にいじっても問題が無い。
これで「相手に変なことが起きないようにする」は解決だ。
Pull Requestしてコンフリクトすることもあるだろうけど、そこはそこで解決すればいいだけのことだ。

 

ああ、「相手に」という意味では、commit履歴というものがある。
branchをつくって、今日の分、みたいな感じでcommitしていると、本体にマージしたときもその履歴が残ってしまう。
まあ、Pull RequestのマージでSquashというやり方もあるのだろうけど、1つにまとめていいかどうかPull Requestする人が悩むこともあるだろう。
そうならないように、Pull Requestする段階できれいな履歴にしておきたい。

 

で、ここからが本題だ。

いままで、私はbranchで作業したcommit履歴をまとめるために、別のbranchを作ってsquashさせていた。
これでよいときもあるのだが、単にこことここだけまとめたい、という場合もある。

そうなると、たぶんrebaseを使うはずだ。
rebaseすると、pushするときにforceで行うことになるが、まあ自分のbranchだから問題なかろう。
一度Pull Requestして修正するときも、rebaseしてpush forceしてしまえば履歴がきれいだし。


git rebase HEAD~2 と指定すると、直近のcommit履歴2つが出てくる。
上から古い順番で並んでいる。

ここでpickのところをsquashとかsとか書き換えると、commitがまとめられる。
では、sにした行の上にまとめられるのか、下にまとめられるのか。

試そう。

$ git log --oneline
741e4b2 (HEAD -> master) second
48697ff first

$ git rebase master
Current branch master is up to date.

あれ?? ダメなの??
じゃあ、branchを作って。。。

$ git checkout –b rb
$ 編集
$ git add xxxx
$ git commit
$ 編集
$ git add xxxx
$ git commit
$ git log --oneline
12d8146 (HEAD -> rb) forth
3ef2f57 third
741e4b2 (master) second
48697ff first

$ git rebase HEAD~2
Current branch rb is up to date.

うーん、rebase、つまりre-baseで、基点を変更するコマンドだ。
だから、masterが最新で、そこから延びただけだったら使えないのだろうか?

$ git rebase –i HEAD~2

あ、出てきた。

pick 3ef2f57 third
pick 12d8146 forth

これを、こうする。

s 3ef2f57 third
pick 12d8146 forth

You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.

怒られた。

pick 3ef2f57 third
s 12d8146 forth

これはOKで、続けてcommit logの入力を促す画面になる。

$ git log --oneline
354f949 (HEAD -> rb) third and forth
741e4b2 (master) second
48697ff first

 

つまり、上にまとめられる、と覚えておけば良かろうか。
よくないのかもしれないが、私にはそれで事足りそうだ。

2019/09/14

[thingy:91]いろいろ調べる

勢いでThingy:91を買ったものの、詳細を全然知らない。
ユーザーズガイドで調べよう。


構成

nRF9160とnRF52840が載っている。

nRF9160 : LTE-M/NB-IoTモデム

  • Cortex-M33
  • FLASH : 1MB
  • RAM : 256KB

nRF52840 : BLE / NFC

  • Cortex-M4F
  • FLASH : 1MB
  • RAM : 256KB
  • USB

 

なるほど、だからSWDのスイッチがあるのか。
firmwareも、モデムとApplicationに分かれていたが、nRF9160とnRF52840だろう。

ちなみに、Applicationのzipを解答すると、hexファイルたちとzipファイルが入っていた。
zipファイルはモデムのfirmwareだ。

firmwareの焼き方もnrfjprogでやる方法が書かれているのだが、ファイルは<hex>としか書かれていない。
全部焼けば良いのだろうか?
ちょっと怖いので、もう少し後にしよう。


user-programmable LED

たぶん、一番目だって光っているLEDのことだろう。
どういう光り方をしているのか気になる。

  • オレンジ点滅 : 電源ON直後?
  • シアン点滅 : SIMで接続済み?
  • 紫点滅 : GPS検索中
  • 緑点滅 : GPS確定

 

うーん。
いま、青点滅しているように見える。
これがシアンか?
白色のように点滅しているときもあるが、これが紫だろうか。

nRF ConnectでLTEを見ているのだが、アンテナ4本中1本しか立っていない。
室内で窓から遠いので、弱いのか。
だったら、GPSはとても無理だろう。

 

ちなみに、ここでは「点滅」と書いたが、英語ではbreathingになっている。
点滅というよりも、ぼわぼわした明滅だな。


書かれているのは、このくらいだ。

あとはハードウェアの細かいところとか。

[thingy:91]やはりJ-Linkじゃないとだめなのか

nRF Connectのv3.2.0を立ち上げると、Programmerというものがあった。

image

 

こいつならfirmwareを焼くことができる!と思ったのだが・・・

image

 

LTE Monitorは使えるから、Thingy:91をUSB接続してCOMポート経由でアクセスすることはできている。
ということは、やはりJ-Linkじゃないとダメなのか・・・。

 

まだnrfjprogで焼くという手段は残っているので、あきらめるのはもう少し先だ。

[thingy91]LPC-Link2が使えそうだ

さて、私が持っているJ-Link LITE CortexMはThingy:91につなげそうにない。
ならば、J-Link Baseを購入するしかないか。。。

 

とJ-Link Baseの情報を探していると、こちらのサイトが見つかった。

超便利 最強デバッガ J-Link
http://idken.net/posts/2017-08-31-jlink/

この記事の下の方に「各種評価ボードのデバッガをJ-Link OB(On Board)化する」という章がある。
評価ボードをJ-Link OBなるものにできるとか。
そういえば、昔NXPのLPC-Link2を買った記憶がある。

 

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/lpc-link-2/

書いてある通りに、LPCScryptをダウンロードしてインストールし、Firmwareのbinファイルをダウンロードし、インストールしたディレクトリのprobe_firmware/LPCLink2のbinファイルを置き換え、scripts/program_JLink.cmdを実行した。
LCP-Link2はJP1を外してUSBに接続すれば良い。
指示通りにやると焼けた。

 

あとは、Thingy:91とLPC-Link2のJ7を接続し、nrfjprogを実行。

nrfjprog --memrd 0 --n 1024 -f nrf91

おー、でてきたでてきた。

 

さて、firmwareを焼いてみたいものの、どれを焼くと良いのだろうか?
mfwnrf9160101.zipとthingy91fwv022.zipがダウンロードできて、前者はModem Firmware and modem DFU tool (nRF9160 LTE-M/NB-IoT/GPS modem)、後者は単にFirmware for Thingy:91と紹介されている。

展開すると、HEXやらBINが複数あるのだ。
アップデートの説明に飛んだが、よくわからん。

ユーザーズガイドのPDFを読むか。

[thingy91]LTE Deviceの登録

Thingy:91には手持ちのJ-Link LITEが使えなさそうだったので、先にeSIMのアクティベートをやることにした。

https://www.nordicsemi.com/Software-and-Tools/Prototyping-platforms/Nordic-Thingy-91/GetStarted

YouTubeで手順を紹介してくれているようだが、英語が聞き取れないのでUnboxing step by stepの方を読む。

 

 

nRF Cloudのサイトを開いて、私はNordic Devのアカウントを持っていたのでそれでSIGN IN。
プラスアイコンをクリックして、LTE deviceを選択。
SIMの表面に3行の文字列があるが、上2行がICCID。PUKはeSIMの台紙に波線っぽいスクラッチがあるので削ると出てくる。

それを入力して、チェックボックスをONにしてボタンをクリック(チェックボックスに気付かず、ずっと失敗していた・・・)。
うまくいくと住所などの入力になるので、適当に打ち込む。

 

その後に、IMEIとPINを入力してデバイスを登録するらしいのだが・・・うまくいかない。

・・・あれ? Thingy:91のLEDが青点滅から緑点滅に変わっている?
もう一度IMEIとPINを入力してボタンを押すとうまくいった。

青点滅の時

image

 

緑点滅のとき

image

 

単に時間が足りてなかったとかか。

 

もしかしたら日本向けにFirmwareのアップデートがいるのかと思ってあせった。
どうやらFirmwareのアップデートにはJTAGデバッガが必要っぽいからねぇ。

J-Linkの限界

Thingy:91も届いたことだし、JLinkでつないでみよう。
J-Linkといっても、J-Link LITEだがね。

最初はnrfjprogのバージョンが古くてfamilyオプションのnrf91に対応できなかった。
バージョンを上げてつないでみると。。。

 

image

 

えっ?
J-Linkってそんな制限があるの??

 

Firmwareの更新で済めば良いのだが・・・ダメだった。。。

image

 

J-Linkのサポートするデバイスとしては、nRF9610も入っている。

https://www.segger.com/downloads/supported-devices.php

ということは、J-LinkじゃなくてJ-Link LITEがサポートしていないのだろうか。
Thingy:91にはSWD Selectというスイッチがあって、nRF91とnRF52が選べるようだ(今はnRF91)が、せっかくだからnRF91で使えるようになっておきたいじゃないか。

先にeSIMのアクティベートをやるか。

Nordic Thingy:91到着

NordicのThingy:91が届いた。

箱は小さい。

image

 

SIMが入ってるんだ!
eSIMで、フルサイズのように見えるけど内側に切れ目のようなものが入っていて、nano SIMサイズまで小さくできるようだ。この方式はいいですな。

image

image

 

 

一応、搭載されているnRF9160の技適を確認。
よし。

image 

2019/09/07

Zephyr v2.0.0

Zephyrのv2.0.0がリリースされたようだ。

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.0.0

rc2まで動かしていたのだが、CCCD定義用マクロの引数の数が変わっていたのだけ気付いた。

そんな感じで、v1とは互換がないところがあるかもしれないので、アップデートの際はご注意を。

2019/09/01

[zephyr?]%lluがうまくいかない

Zephyrでuint64_tを扱うことがあった。

64bitの値を文字列にして渡したい。
あまり考えず、

char str[20];
snprintf(str, sizeof(str), “%” PRIu64, val64);

みたいな感じで書いた。

そうするとですな、文字列で”%lu”になってしまうのだ。

 

gccは、gcc-arm-none-eabi-8-2019-q3-updateを使っている。
ターゲットはnRF51822なので、Cortex-M0だ。

ここら辺を見ると%lluのようだから、最初のlだけ消えている・・・?
%luはうまくいくので、全部がダメなわけではないのだよなぁ。
コンパイラかと思っていたのだが、sprintf.cがあるのでZephyrの方かもしれない。

 

CONFIGを見ていると、CONFIG_MINIMAL_LIBC_LL_PRINTFというのがあった。
これをyesにすると、64bitも扱えるようになった。
まあ、普通はいらないよねぇ。。。今回も64bitで扱うけど、実際は32bitも使わないし。。。