GR-SAKURA
GR-KURUMI
GR-COTTON
GR-CITRUS
GR-PEACH
GR-KAEDE
GR-ADZUKI
GR-LYCHEE
GR-ROSE
GR-MANGO(*)
SNShield
Web Compiler
IDE for GR
TOPPERS関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
折角なので、Rubyを使ってプログラミングをやろうと、I2Cのインターフェースを使おうと思ってしまいますが、Rubicで下記のソースを動かそうとすると、クルクル回ったまま止まってしまいます。
CITRUSのファームは、CITRUS-1.97(2016/6/12)f3(256KB)です。
sensor.write()部分をコメントアウトすると、動くので、何かおまじないが必要なのでしょうか?
#!mruby
usbout=Serial.new(0)
sensor = I2c.new(1)
sensor.write(0x7c,0x80,0x38)
Eguchiさん、こんにちは、たろサです。
クルクル回るというのは、Rubicが転送から復帰しないということかなと思いますが、Rubicとの転送中の問題か、mruby-VMの動作中の問題か、切り分けるために、usbout.println "Hello"をusbout=Serial.new(0)の後に入れてもらえませんでしょうか。
これで、Helloが返ってきたら、Rubyファームの問題です。クルクルのままだと、main.mrbを転送中にずっこけています。
あと、sensorがnilで返っているかもしれません。
usbout.println "sensor is nil" if sensor.nil?
とか、入れてみてもらえませんでしょうか?
たろサさん
返信ありがとうございます!
はい、Rubicからの転送から復帰しないというのが症状です。
Windowsマシンでやってみたところ、今朝は動作させることができました。
ですが、MacBookの場合はうまくいかないです。
プログラムサイズが大きくなると、転送に失敗するみたいです。
もうちょっと調べてみます!
今は、Buildでも、クルクルのままになってしまいました。
コンパイルってサーバ越しで行っているんでしたっけ?
いえ、Rubicの場合、コンパイルはオフラインで行っています。
保存(Save)は問題なく実行できますか?
はい、saveはできます。
Buildでクルクルしてしまうプロジェクトを添付します。
USB.printlnの前のコメントを外すとクルクルします。
コメント付けたままだと、コンパイル出来ます。
サンプルソースが間違っていました。すみません。
setDateTimeではなく、setTimeです。くるくるが止まらないのは、mrubyVMが吐いたエラーをRubicが受け取れていないのかもしれません。
ただ、エラーを吐いた後は、コマンド受付状態に戻るので、そうなったときは、クルクルが止まるはずなので、別の要因かもしれません。
USB = Serial.new(0, 115200) #USBシリアル通信の初期化
Rtc.init
Rtc.setTime([2016,4,16,17,0,0])
15.times do|i|
led(i % 2)
year,mon,da,ho,min,sec = Rtc.getTime()
USB.println(year.to_s + "/" + mon.to_s + "/" + da.to_s + " " + ho.to_s + ":" + min.to_s + ":" + sec.to_s)
delay(500)
end
重複投稿でしたので削除しました。
Buildだけでクルクルなので、ボードへの書き込み前なので、Rubicだけの問題のはずです。
頂いたソースをBuildするだけでクルクルです。
私の環境ですが、Rubicのバージョンは、0.2.3で,Windows 10(64Bit)です。
クルクルは私だけの現象????
横から失礼します。全然関係ないかもですが、こちらの環境で100%クルクル発生する手法を書いときます。Win7x64。CITRUSとか全く繋いでないPCで現象出ます。繋いでても多分でる。
Rubic起動、ボードをGR-CITRUS選択、Portを何でもいいからCITRUSじゃないやつを選択。するとinfoが有効になりますが、info押すと帰ってこない。強制終了しかできない。保存してないソースがどうなるかとかもう。。ボードが壊れてたりしても同様の症状になるかなとも。
関係があるかどうかはともかく、無限ループ(無反応)が存在する時点で少々色々気掛かりです。対策して戴けるとありがたいです。
各位、ご報告ありがとうございます。
現状のRubicは期待しない応答が来るまで待つため、無限ループが発生しやすいです。
7月のメジャーバージョンアップで修正する予定です。
>Kazuyuki Eguchi さん
当方(Rubic 0.2.3、Windows 10 x86_64)では再現できませんでした。ただ、山本さんもおっしゃっていた通り、
コンパイルエラーでは無限ループにならずエラーを検出して編集画面に戻るはずです。
Rubicの動作ログを収集していただけませんでしょうか。
(1) Chromeの拡張機能(chrome://extensions)
(2) 右上「デベロッパーモード」にチェック
(3) Rubicを拡張機能リストから探し、window.html#のビュー検証を開く (Rubicをまだ起動していないなら、この時点で起動しておく)
(4) Consoleタブを開く
(5) Rubic上で、不具合の発生する作業を行い、再現させる
(6) Consoleタブのウィンドウ内で右クリック→Save as...
私だけの現象だったのですが・・・
ログ取ってみました。(オリジナルは添付してあります)
どうやら、スタックオーバーフローみたい!?です。
exception thrown: RangeError: Maximum call stack size exceeded,RangeError: Maximum call stack size exceeded at _codegen (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:108115:18) at _gen_call (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:125564:2) at _codegen (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:113166:4) at _gen_call (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:125564:2) at _codegen (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:113166:4) at _gen_call (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:125564:2) at _codegen (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:113166:4) at _gen_call (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:125564:2) at _codegen (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:113166:4) at _gen_call (chrome-extension://mgbcgagfggopcpbbfgididddbnhhnhjp/lib.js:125564:2)Uncaught RangeError: Maximum call stack size exceeded
あ。ウチでも発生しますね。。たろサさんの6/21 20:22のソースをコピペると同じエラー吐いて止まるみたいです。でもEguchiさんのRTC2.zipは全然問題なくBuildできます。
保存フォルダ名に全角だのスペースだの半角マイナスだの入れてみたけど変わらないっすね。
fluxさん
あのプロジェクトファイルは、#を外すと、クルクルする現象になりますので、そのままは、Buildできて正解です。
私と同様の現象が発生する方が居て良かったです。
きむしゅさん
USB.println(year.to_s + "/" + mon.to_s + "/" + da.to_s + " " + ho.to_s + ":" + min.to_s + ":" + sec.to_s) みたいに
演算子が多いと、スタックオーバーフローするようです。スタック用の配列の数が少ない???
USB.println(year.to_s + "/" + mon.to_s + "/" + da.to_s)
少ない場合は、buildできます。
うーむ、何故だろう。スタックのサイズが小さい環境がある?
お手数ですが、Rubic window.html#のビュー検証画面で、Consoleに次の1行を入れて、反応を見ていただけませんか。
var i = 0; function inc() { ++i; inc(); } try { inc(); } catch(e) { console.log(i, navigator.userAgent); }
実際にスタックを溢れさせて、深さがどれくらいあったかを見るコードです。
うちでは、
41816 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
でした。
半分ですね。
20824 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
Kazuyuki Eguchi さん、ありがとうございます。
こちらもprintlnの中の式を2倍のボリュームにすると再現できました。
JavaScriptに変換されているmrubyのコードに一部最適化がかかっておらず、スタックを大量消費していたようです。ご迷惑をおかけしました。
最適化をかけて更新をアップロードしましたので、Chromeウェブストアからの配信開始まで少々お待ちください。
新バージョンは 0.2.4 になります。
なお、新バージョンでは、以下のように極端なパターンでも正常にコンパイルできています。
分量をさらに倍にするとさすがにNGでしたが、下記コードだけでもCITRUSが扱えるmrbの最大サイズ(4kB)に到達していますので、
とりあえずはここまでの対応とさせてください。
(本当は正しくエラーハンドリングして、編集画面に返ってくるようにすべき、というのは重々承知しております…)
USB.println(
year.to_s + "/" + mon.to_s + "/" + da.to_s + " " + ho.to_s + ":" + min.to_s + ":" + sec.to_s +
:
: 同一行×20行繰り返し
year.to_s + "/" + mon.to_s + "/" + da.to_s + " " + ho.to_s + ":" + min.to_s + ":" + sec.to_s)
41814 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"