PSoC5LP で いまさら mruby/c を試してみる その３ (お試し編) (PSoC AdventCalendar2019)

さて。
PSoC Advent Calendar 2019 での ３つめですね。

mruby/c 2.0 でうごく、サンプルはできたので
いろいろできそうだけど。

で、ちょっと気になったのは最初によんだ
利用説明書
の記述。

内蔵デバイスをいろいろ、使えるようにしてくれてるん
だろうなぁ、とか思いつつ、 読み進めていったんだけど

こういう記述があつまってるところはないかしら？

まぁ、
mutex、sleep()、relinquish()
があればタスク管理上はほぼ問題なくなるだろうし
いいんだけれど。
mruby/c で
『あれ、どう記述したらいいんだろう？？？』
ってのに対応できる資料がないのはイタイからね。


で、微妙に気になったのが、UARTについての記述。










PSoC5だと UDBの分だけ、 UARTつかえるよ！っていうのは
いいとして、PSoC5LP PrototypingKit の UART部は
KitProg2(デバッガ部)のPSoCに直結されて
PCからは、USB-CDC そのものだから、本来は
デバッグ出力用の　hal_write()  のほうに割り付けて
しまうほうがうれしいとおもんだけどなぁ。
まぁ、uartクラス的に書くのかは勉強になる。
ただ、気になるのは、
『PSoC5LP開発環境の仕様により、ボーレートの変更がソフトウェアでできません。
   標準で、19200bps固定です。』
っていう記述。

うっそーん！  できるよ、あたりまえじゃん！
これは
PSoCのこと、わかってないんじゃないの？
ってタイミングでかかれたんだろうなぁ。

たしかに、PSoC の UARTコンポーネントでは
速度を指定するAPIは生成されないですね。
ただ、できないわけではないよ。

2017年版の Advent Calendarでも 書いたので
詳細は そちらを参照してもらえばいいけれど、
要は、UARTも基準となっている、IMOのクロックに
同期してうごいているので、これを正しい分周比に
かえてやれば、好きな周波数なんて簡単に設定できますよ、
ってことですね。

=========

=========
こんなかんじですかね。

PSoC Creater で生成したプロジェクトを利用すると
利用するマスタークロックは  cyfitter.h というファイルに

BCLK__BUS_CLK__HZ


として定義されています。

IMO を 48MHz で定義した プロジェクト の場合であれば

#define BCLK__BUS_CLK__HZ 48000000U
ですね。
欲しい速度（bitrate）を ８倍することで Byte/Secの単位とし
それを分周比として
UART_1_IntClock_SetDividerRegister()
という関数に引き渡してやればいいだけですね。

問題は、与える分周比をどうやって算出するのか、 だけど
たとえば 115200bps がほしいのなら
  115200bps = 115.2kHz
で、１バイト分のサンプリング =　８倍 が欲しい周波数なわけです。

サンプリングを８倍した 921.6kHz が与えられれば、いいわけです。
ここまでくれば簡単で、
この921.6kHzを生成するのに、48MHzを52分周すると
近似として  923.076kHz 得られるじゃない？ってことですね。

式にすると
 52 = 48000000 / (115200 * 8)
ですね。

というわけで、この関数をmruby/c から呼べるように
用意すればいいだけです。

=========

=========
c_setBitRate関数が 実際にmrubyから呼び出しされる
関数ですね。

このプログラムでは UARTを
hal_uart
というコンポーネント名で登録したので、上記のように
なっています。
mruby から
setBitRate( 115200 )
みたいによべばいいですね。

=====================================
いろいろつかってみると、結局のところ
デバッグができるのが、PSoC 版のいいところ
なのかも。

肝心のmrubyでは、デバッグできないもん。
実際、前回のように、
いま、なぜ動かないのか？
を確認できないのはつらい。

じゃ、結局『ぜんぶCでかきゃ、いいじゃん！』ってなりそうなものだけど、
マルチタスク的にコンパクトにいろいろやりたいとなると
案外Cだと骨が折れるんですよ。
基本になる挙動は、 Cで関数単位で記述しておいて
タスク起動と同期を mruby で制御、ってのが
もっともお手軽なのかもしれません。
実装サイズがコンパクトなRTOS的につかう！
のが最適なのか、とおもいますね。

さて、ちょっとmruby の文法、勉強しないと。。。

PSoC5LP で いまさら mruby/c を試してみる その２ (テスト編) (PSoC AdventCalendar2019)

前回、見事に撃沈したので、リベンジ に勤しんでみる。

要は、mruby/c もわからんのに、IDEをつかうのがまずい？
ってのがあるので、本筋に従って、きちんとすすめてみるのが吉なのだね。
そもそも、ほかのマイコンと違って、ペリフェラルが可変のPSoCでは
PSoC Createrから切り離して、どうやってIDEするつもりだったのか
よくわからないって段階で、踏み込む必要がなかったわけだ。

先日の Embedded Technology 2019 で、某きむしゅさんから
rubyへの『愛がたらない』と言われたしなぁ（笑

てわけで、環境を構築してみる。

mruby/c チュートリアル
https://www.s-itoc.jp/activity/research/mrubyc/mrubyc_tutorial/

田中せんせのQiita
https://qiita.com/kazuaki_tanaka/items/daff64b84c4108a6dfc3

という二つのコースがあるけれど、田中せんせのやつは、
あとからみればしっくりくるけれど、最初にやると？？？となりそうなので
チュートリアルの１と２を、取り纏めながら進める。

PSoC Createrで PSoC5LPを選んで作り始める。
 後々のために
-----
Project > Build Settings にて
ARM GCC -> Compiler -> General     Use newlib-nano Float Formatting = True
にして実数利用を許容dwrのSystemタブで   HeapSizeを0x400に拡張   
-----
しておきます。
回路図入力で、Clockを1kHz で interrupt として取り出しておきます。
システムのTickとして利用するので、isr_mrbcTickと命名しました。

SouceFiles のところに
src
フォルダを追加しておく。

ファイルマネージャでソースファイルのフォルダに
mrubyc-release2.0 の srcフォルダをそのままコピーする。

フォルダ構成はこんなかんじですね。
-----

├─src
│ ├─hal_org
│ └─hal
└─TopDesign

-----

src フォルダ内の hal フォルダを hal_org にリネームして
hal_psoc5lp  を  hal  にリネームする


PSoC Creator に追加作成した  srcフォルダを選択したうえで
右クリックで、Add > Existing Item を選びます。

さきほど、コピーした srcフォルダ内のファイルをすべて追加します。


これで、準備完了ですね。

https://www.s-itoc.jp/activity/research/mrubyc/mrubyc_tutorial/735
に記載されている、mrubyc のサンプル をそのままつかいます。



このコードを sample1.rb という名前で、
main.cのあるフォルダにコピーしておきます。
ついでに、mrbc.exe も ここにコピーしておきましょうか。
      （ここでmruby IDEのなかのmrbc.exeをつかって悲劇を呼ぶのだが。。。）
cmdプロンプトから

mrbc.exe -E -Bsample1 sample1.rb

とすれば、　main.c とおなじフォルダに
sample1.c
が生成されます。
試しに sample1.c をエディタで開いてみると

こんなかんじになります。
どうやら、mrbc は mrubyのソースコードを バイナリの配列に入れてくれる
プログラムってわけですね。
試しに
mrbc.exe -E -Barry sample1.rb
とすると、 sample1.rb の中の配列名が
arry[] =
となることから
mrbcでの 　引数 -Bの後の文字列が配列名であることはわかりますね。


で、PSoCのサンプルソースコードはこんなかんじになります。
躓き処が満載ではあるんだけど、いまはこれが全容かな。
    mrbc_create_task( sample1, 0 );
の行で、タスクとなるmrubyコードが呼ばれるのはわかりますねぇ。

--------



--------

なんとなく、全容がみえてきた(≧▽≦)

さて、ここから、いろいろやってみましょうか。
mruby自体のデバッグってどうやるのか、とおもったら
PSoC Createrのデバッグ機能がつかえるから、
mrubyはタスクスイッチャとしてつかうのなら
おおむねデバッグはできそう。

さて、で、実際デバッグ実行してみると、うごかない。。。

はぁ？

ブレイクかけながら追いかけてみると、関数がよばれず、
そもそも mruby コードがうごいていない？疑惑浮上。。。
適当にブレイクかけながら試していると

class.c の mrbc_load_mrb関数内で  mrubyのバイナリチェックを行う

  static int load_header(struct VM *vm, const uint8_t **pos)

という関数がエラーを返している。

  if( memcmp(p, "RITE0006", 8) != 0 ) {

となっていて、mrubyのバイナリバージョンが 0006 であることを
想定しているけれど、
今回得られてる、sample1[] の内容は
0x52,0x49,0x54,0x45,0x30,0x30,0x30,0x34　= RITE0004
だから、はねられてる、ってとこかな。

は！ そうか！ mrbc コンパイラが生成するバイナリ自体もちがうのか。

そんなんしらんがな。

なるほど、サイトをよくみると、

mruby Stable版v2.0.1 Windows版（コンパイル済バイナリ）
「mrubyコンパイラ2.0」（ZIP：1.5MB）

が必要なのね。

これで、再度mrbcかけて、再コンパイルしたら、うごいた！
Ｌチカ！ 完了。 

ううむ。そういうことなら、気色わるいので
mrbcフォルダをつくって、そのなかに、mruby Stable版v2.0.1一式を解凍して
mrbc.bat だけを、ソースフォルダのなかに置いた。
フォルダが変わったので、このbatファイルの中で

set MRBC=.\mrbc\mrbc.exe

に変更したけれど。

これで、コマンドプロンプトから
mrbc
ってやるだけで、rbファイルが一括コンパイルできるようになったよ。

しかし！。

まぁ、もうちょっと、わかりやすく手順を説明してほしいなぁ。サイトも統一感なさすぎる。


なるほど、こりゃ流行らんよねぇ。。。



<つづく>

PSoC5LP で いまさら mruby/c を試してみる その１ (失敗編) (PSoC AdventCalendar2019)

あー、さぼり気味なのにもほどがあるな（笑
最終書き込みから２年とは。。。

ほんとうは、昨年のAdventCalender 2018での記事の予定だったんだが
多忙になったのにかまけて、お蔵入りになった。

というわけで、１年越しのリベンジということで。。。(≧▽≦)
詳しくは
PSoC Advent Calendar 2019
をみてね
ではさっそく。

私的には、
  BASIC -> Pascal ->C/C++ -> C# -> Python
といろんなのをやってきたわけだけど、 Web系では ruby と PHP が競っていたときに
PHPに行ったわけですよ。
で、 ruby  、なんだか小難しいなぁ、とおもっているうちに、マイコン用に
mruby 登場！となった経緯は知ってはいたし、ちょろっとかじったりもしたけれど
言語の資料もほぼないし、情報もないし、ってのが続いていて今に至るわけです。

毎年恒例の 横浜で行われる、Embedded Techology 展で
ruby フォーラム の 面々から、脅迫？めいた勧誘に耐え兼ねて、
ちょっとやってみようかと。
ちょうど、島根の田中先生が、 PSoC5でうごく、mruby/c というのを
開発したところだったので、いいタイミングかな～と思ったわけです。

ruby はよく知らないけれど、
mruby は
『マイコンでも動くように機能を絞ったバージョン』
ということです。（しらんけど

じゃ、
mruby/c って なに？
というのは、実はよくわからない。
まぁ、誤解をおそれずにいえば、

1)インタープリタな部分を排除、rubyVMだけにして、コンパクトな実行サイズにする
2)rubyコードは予めPC上でバイナリにしておいて、VMにこのバイナリを食わせる
3)食わせる部分は、ターゲットマイコンのC/C++で記述

ということかな。

ということで、まずは、お手軽？らしく見える、IDEから、ちょろっと遊んでみよう。


しまねソフト研究開発センターのHPに mruby/c が纏めてある。

トップからは分かりにくいが
トップ / 活動内容 / 研究活動
という中に存在する。
できれば、トップにmruby/cのバナーがあるんだから
そこにリンクくらい張ってくれてもよさそうなものなのに（笑

まずはダウンロードページで、それらしいのを全部手元に取っておく。

おお～、

利用説明書

ってのがあるじゃん。
mruby/c IDEなるものがあれば、簡単じゃね？

最初のとっつきにはよさそうなので、まずはこれに沿って、やってみる。

ふむふむ。IDEから mrbc.exe と mrbwrite.exe を指定するのね。
よくわからんけど、一応、フォルダ内に同名ファイルがあるから登録してみる。

適当に読み進めていくと
デバグ用コンソールの起動（任意）
基板左サイドのUSB端子から、デバッグ用メッセージが表示されますので、開発時は接続しておくと便利です。
任意のターミナルソフトを利用して、ボーレート57600bpsで接続します。』

へ？  PSoC5の USBポートだよね？
USB-CDC だし、PC側の通信速度、ってなんでもよくね？    ( ,,`･ω･´)ﾝﾝﾝ？

てか、そもそもファーム、どれ？

ということで、この方法は一番にひらいちゃダメなところだったようだ。。。

mruby/cとは というリンクの中にある、田中せんせのQiitaをベースに
やってみないとダメなようだ。
よくみると、
チュートリアル
というページも、概ね同内容？的。
ふむふむ。そういうことか。
でも
初心者がどこから入ればいいのか、迷うのはいただけないよねぇ。。。orz

というわけで、別の方法を試してみる。。。orz 


＜つづく＞

PSoC5LP で USB-HIDデバイスでもしてみるか。。。( PSoC Advent Calender2017 )

PSoC Advent Calender 2017 の 記事の２こめです。

PSoC5LPにはUSB がついています。
これ、案外USB UARTくらいしかつかっていないんですが
普通にHIDデバイスとしても作ることができます。

今回はMouseにしてみます。
といっても、マウスなら、ちゃんとサンプルが用意されているんですよね。

スケマティックにUSBFSを配置して、右クリックメニューから出る
Find Code Example ...
を実行します。

すでにUSBFSが選ばれているので、関連するものがでてますね。
今回はとりあえず
USBFS_HID
を選択します。

3-Button mouseって書いてあるので、大丈夫そうですね。
よければ、Create Project を押します。

ん！エラー？ はぁ？？？
このメッセージわかりにくいよね。まったく。
要はこれは
『そのままではインポートされていないので、Webからとってきてね！』
というメッセージ。じゃ、どうするの？ってなるんだけど、
左はしの地球のアイコンをクリックすると、勝手にダウンロードされてくるので
そのままプロジェクトをつくります。

できたプロジェクトはデバイスが PSoC3になっているので
利用するPSoC5の型番に変更します。
PrototypingKitでは、CY8C5888LTI-LP097ですね。

WorkSpace Explorerの Project部で右クリックして
Device Selecter
を出し、ここで選択しなおします。

 できたら、ビルドします。
 スケマティックをみても、USBFSしか配置されていないので、基本は
これでエラーもでないはずです。
自動でピン配置もUSBピンはセレクトされているはずなので
大丈夫なはず。

添付のPDFの最後のところに
================================
Expected Results
You should see that the device is recognized as a 3-button mouse. The mouse is continuously moving back and forth horizontally.
================================
ってなっているので、マウスになってカーソルを水平移動でうごかすよ。
ってよめますね。

うごきましたか？
で、この設定、どこできまるんだ？ってことなんですが
一番わかりにくいのは HID Report Descriptersなんですよね。

なんじゃそら、と。

Device Class Definition for HID 1.11 (PDF)

を参照してみてください。
page81 (表題ページ番号71)にマウスの定義サンプルが挙げられています。

ね、このとおりの定義を書いてるだけですね。

あとは ３バイト用意して、一定のタイミングで
値をセットしておくりかえせばいいんですね。

このやりかたをしっておくと、JoyStickもキーボードもつくれますね！

Uartのボーレートチェンジを実装してみる( PSoC Advent Calender2017 )

とうとうこんな季節になってしまった。
いまだに炎上案件抱えてひーひーゆうてるのに。

PSoC Advent Calender 2017 の 記事を！って頼まれたのでそれをば。

さて、PSoC のUARTってコンポーネント、ポンっ！ってかんじで
いいので、とっても簡単なんですがね、ほかのマイコンなら
途中でボーレートチェンジ！なんて簡単にできるのに

この部分はAPIとしてはParityは公開されているけれど、
肝心の速度は公開されてないので、なんともならない。


きっかけは MonoWirelessのTWELiteの書き込みがPSoCからしたいよね！的な
ところから始まったんだけど。

 PC <--USB--> PSoC <--UART-->TWELite

っていう感じでつかって、モード変更で書き込み対応したいとか。


で、やってみた。

Design Wide Resources (.cydwr)をひらいて Clockタブを見てみる。

やっぱり、UART_1_IntClockを引き込んでいる。
今回は115200bps = 115.2kHzがほしい設定なので
サンプリングを８倍した 921.6kHzを生成してるわけですね。（最下行）
この921.6kHzを生成するのに、64MHzを69分周して近似の
927.536kHzを出してるというのはわかる。
ということなら

このDividerを変更したらよくね？
UART_1のコードの下に、UART_1_IntClock.cというのができてる。

このなかに SetDividerRegister()関数という、もうそのままのネーミングの
関数あるじゃんと。
これをよべばよさげですよね。

===================================



===================================
ぼくの場合だと
#define  HS115200    69
#define  HS57600    139
#define  HS38400    208
#define  HS19200    417
#define  HS9600     833
ってかんじですかね。
ここらは計算でする方法もあるし、あるていど決め打ちでもいいかも
ですね。
 64000(kHz) / (欲しい周波数(kHz) * 8) = divider
ってかんじですね。

TWELite-RED

久々に更新。

MonoWirelessのTWELiteに高出力版のREDが追加されました。

うちもいろいろと使っているので、
『どのくらい変化するんかな？』
というのが、気になるところ。

うちの場合、双方向でバリバリ通信したい！ってのは少なくて
デバイス側からデータをとにかく送りたい！的な用途なので
距離が伸びてくれるのはありがたいんだけど、
まだ、TWELiteのチップだけ、ってのは発売されてない。
とりあえず、TWELiteDIPでテストしてみた。

MonoStick-RED  <---- TWELiteDIP-RED 　　　　ざっくり50mくらい
MonoStick-RED  <---- TWELite(CHIP) + BLUE    ざっくり20mくらい

MonoStick-BLUE  <---- TWELite(CHIP) + BLUE    ざっくり15mくらい

という印象。
REDxREDの組み合わせで、おおお！ってなるくらい飛ぶのは
ある意味予測していたけれど、スティック側だけREDにしても5～６mは
距離が延びるのはちょっと意外。
しかも、RED自体の処理が安定している印象で、
BLUEだと離れるにしたがって受信がギコギコするような感じになるのに
REDだとほぼ安定状態が継続する、というかんじで、安心感がある。

すくなくとも、MonoStick側だけでもREDにする価値はありそう。

で、REDがラインナップに追加されたのにともない、
開発ツール類も TWESDKからMWSDKに変更になっている。
まぁ、TWEってのをMWにしたくらいしか見た目は変わりない。

ただ、問題は、MWSDKで提供されるファーム群のコンパイルは
そのままではTWESDKとなんら変わりなく、RED用にはならないこと。

ぼくのばあいは、ほとんど独自にファームを改変しているので
これは結構困る。。。

で、M社のO氏に教えてもらって、なんとかRED用ファームを
つくることができるようになったので、その備忘録として、
記録しておく。

１．Eclipseは
      c:\MWSDK\ECLIPSE.cmd
    を実行することで、おこなう！（これ重要）
２．Wks_TWELITEフォルダをワークスペースにする。
３．生成したいプロジェクトをひらく。
４．生成したいプロジェクトの右クリックでプロパティをひらき
     (1) C/C++ ビルド => ビルドコマンド[ビルダー設定]を
                 make TWELITE=RED APP_UART_CONFIG=CONFIG_NORMAL
         にする。BLUEの場合は
                 make TWELITE=BLUE APP_UART_CONFIG=CONFIG_NORMAL

     (2) C/C++ ビルド => ビルドコマンド[振る舞い]で
                 Enable parallel build
         のチェックをはずす。

     (3) C/C++ ビルド => 環境  で
             PATH
          をえらんで、削除ボタンをおす。
          すると、値の部分が新たに設定される。

ここまでできていればOKなのであとは、プロジェクトにもどって
ビルドすれば、xxx-REDというバイナリ（BLUEの場合はそれなり）が生成される。

ねー。めんどくさい。

モノワイヤレスさん、もうすこし、親切にしてほしいなぁ(笑)

ToF型測距センサ VL53L0Xをつかってみる。

ちょうど、仕事で STマイクロの　ToF型測距センサ VL53L0Xをつかう機会が
あったので、その報告をば。

昨年ＥＴのときかな？にＳＴマイクロのブースでみつけて
いいなー、と思っていたデバイスなんで、
ことしのET Westで、これのNUCLEO Packをもらってきたん。

たしかに、応答性がよくて、取り回しも便利。
自分で実装できるパッケージじゃないのと、内部用に2.8Vが必要という
めんどくささ、も我慢できるかなーー、というのはあったんだけど
問題は、I2Cデバイスであるにも関わらず、利用するための
内部のアドレス情報がまーーーったく開示されておらず
STM32のNUCLEO用のサンプルから自分用にポーティングしないとどうしようもない
というイケてないデバイスで、つかうのを躊躇してたんですよね。

今年のETで、STの担当者にこの件、きいてみたら
『これの前のデバイスで、アドレス情報など、サポートにじゃんじゃん質問がきたから
データシートへの記載、やめてるんですよねー』
とか。
それ、あかんやろ(>_<)



で、躊躇してたんだけど、Pololuで、このデバイスボードを発見！
https://www.pololu.com/product/2490
 
しかも、だいぶ簡素化された状態で、Arduino用のライブラリもgitに上がっているという
なんとまぁ、うれしい状態。

で、これをPSoCでつかいたいので、これをCの形式に変換しなおしてつかってみた。
PSoCもGCCをつかっているので、本来C++が使えるはずなんだけど
現状ではCオンリーなので、しかたない。

ソースはここ。
VL53L0X.C
VL53L0X.H


[<====ソース抜粋====>]

[<====  ここまで  ====>]

VL53L0Xの先頭部でI2Cへのアクセス関数部を別名定義してる。
PSoCの場合 PSoC5やPSoC4で、I2Cへのアクセス関数名がそれなりに変化しちゃって
固定してると、結構めんどくさい感じになりやすいので
VL53L0XでつかうI2Cの関数を、指定できるようにしてみた。

ほんとはClassがつかえれば、いいだろうし、Cであっても
関数ポインタつかえばできるのも理解してるけど、
なんとなく可読性がおちちゃうのが気になって、こういうベタなやり方にしてみた。

あと、タイムアウトを判定するために外部で
uint32_t timeout_start_ms ;    // 経過時間の観測変数
を減算してやる必要があります。

main.cなどでタイマーを利用してるソースの先頭に

     extern uint32_t timeout_start_ms ;

を定義して、1msのタイマーの中で

     if ( timeout_start_ms ) timeout_start_ms--;

としてください。


[<====ソースサンプル====>]

[<====  ここまで  ====>]

みたいなかんじかな。
標準状態だとサンプルが30ms間隔で行われるので、
それ以上は待ってやったほうが、いい、ってかんじですね。
観測早いし確実なのはいいなぁ。

超音波はつかいにくいし。