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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
GR-CITRUSとWA-MIKANを繋いで、インターネットプログラムを書き始めたところで、Rubicからプログラム転送をしてみようとしたら、転送に失敗してしまっているようです。
何が原因なのでしょうか?その時のログを添付します。
プログラムは、サンプルそのままです。
#!mruby
digitalWrite(5,1)pinMode(5,1)
usb = Serial.new(0,115200)esp = Serial.new(3,115200)
usb.println "GR-CITRUS & WA-MIKAN"c = 0while(true) do delay(0) while(usb.available() > 0)do esp.print usb.read() c += 1 if(c > 20)then esp.bps 115200 c = 0 end end while(esp.available() > 0)do usb.print esp.read() endend
Eguchiさん、岡宮さん、
お疲れ様です。木村です。
手元のMac (El Capitan)とWin 10 Proで同一スケッチ転送のUSBキャプチャを取り再現実験したところ、
Macのみで再現しました。
キャプチャデータ:
www.dropbox.com/.../20160703_readerror_citrus.7z
※使ったCITRUSのファームバージョンがEguchiさんのと違うことに後で気付きました…。
この手のエラーは以前にもあって、その時はCITRUS側の修正を行いましたが、
今回はPC(Rubic)側で何らかの不具合が起きているようです。
Macでは 00.27:942:341:733 ~ 00.27:943:275:266 がRubicからCITRUSへの転送期間です。
すべてのデータを送り切れず、ちょうど1024バイト送った後、PCからのデータ送信が滞っているように見えます。
Rubicがシリアル通信に投げたデータは1258バイトなので、後ろが少し切れていることになります。
ちょうど2秒後の 00.29:944:375:716 からCITRUS→Rubicへ"Read Error"のエラーメッセージ返却が始まりますが、
この振る舞いは現状のCITRUS側データ受信部のタイムアウトで、実装通りの振る舞いですね。
引き続き調査します。
>きむしゅさん
パケット確認をいただきありがとうございます。以前に発生していたZLPが原因ではないというkとですね。
>Eguchiさん
修正のまでの間、WebコンパイラのmRubyテンプレートで\gr_common\core\HardwareSerial.hの以下の行を2048などにして試していただけないでしょうか?
#define SERIAL_BUFFER_SIZE 1024
岡宮さん
WebコンパイラーのmRubyテンプレートは、GitHubに上がっている最新のソースコードじゃないので、浮動小数点のサポートとか抜けているファームウェアなので、もし可能であれば、GitHubに上がっている最新のソースコードをWebコンパイラーでコンパイルする方法を教えてもらえると助かります。
Eguchiさん、失礼しました。Webコンパイラには最新レポジトリを反映したE1.00aをアップしましたが、ヘッダーを変えると全コンパイルが走って遅いため、こちらでバッファを2048にしてビルドしたbinを添付します。宜しくお願いいたします。
Eguchiさん、
お手数ですが、Rubic起動後、スケッチを転送するより前に、Developer Toolsのコンソールから以下の一文を実行していただけませんか。
Rubic.GrCitrusBoard.WRBB_SEND_BYTES = 256
まだ原因は判明していなものの、Macからの転送に場合一気に多量のデータを送るとどこかで
詰まってしまうようです。上記の設定は256バイトずつ切って送るための指定です。
Rubicとの専用通信仕様(Emboc)が完成すればこの手の問題は発生しなくなるはずですが、それまでの間、
上記のワークアラウンドで回避できるかを確認したいです。
なお、私の環境(下記)では最大サイズ4096バイトまで転送可能になりました。
Rubic/0.2.4 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
頂いたのをいれて確認してみましたが、NGでした。
今回のバージョンを見ると、GitHubに上がっているのより古いファームウェアです。
1.95(2016/5/30)、GitHubのは1.99です!
はい、これであれば、書き込みができました!
4096バイトを超えないプログラムを書けばいいんですね!
きむしゅさん、たろサです。
今、缶サット甲子園でGR-CITRUSを打ち上げるべく、Rubyでプログラムを書いています。
結構、プログラムサイズも大きくなり、4096バイトの壁で悩んでいます・・・(^_^; ぉぃぉぃ。
コンソールからの設定でいいので、-gオプションをはずすことができるようになりませんでしょうか。
デバッグオプションをはずすと、バイトコードがずいぶんスリムになると思います。
よろしくお願いします。
Eguchiさん、すみません、wrbb.hを書き換えてませんでした。けしからんミスをしてすみません。
バッファ2048でダメなのはがっくりでしたが、きむしゅさんの対策でOKということで安心しました。
たろサさん、
ああ、結構容量オーバーの例はあるんですね。とすると、いっそ標準で-gを外してしまいましょうか?
-gを付け始めた経緯が思い出せないんですが、あまり容量のことを考えず、折角デバッグ情報付けられるなら
つけておこう、という程度だった気がします。
-gを付けておくと、実行時エラーの情報が詳しく出てくるので(エラー行など)、デバッグしているときは、とても便利です。
デバッグが終了して、リリースしたいときなどは、-g無しでコンパイルできると、コードが小さくなるので、うれしいです。
両方できる環境がありがたいです。
あと、4KBしばりはもう少し大きくしてもいいと思いますが、どれくらいが適当か、見えていない状況です。CITRUSでRAMは倍になっているのですが。
なるほど。実行時エラーにおける行番号は重要ですね。
で、デバッグオプションの切り替えについてですが、現バージョンでも対応しているのを今の今まで失念していました ^^;
GUI上からの切り替えはまだ出来ませんが、スケッチのファイルをテキストエディタで編集するとコンパイルオプションを変更できます。
sketch.jsonを
{"bootFile":"main.rb","sketch":{"files":{"main.rb":{}},"downloadAll":false,"rubicVersion":"0.2.4","board":{"class":"GrCitrusBoard"}},"board":{"class":""}}
から、
{"bootFile":"main.rb","sketch":{"files":{"main.rb":{"build_options":{"flags":[]}}},"downloadAll":false,"rubicVersion":"0.2.4","board":{"class":"GrCitrusBoard"}},"board":{"class":""}}
に変更してスケッチを開き直してください。
ビルド時に-gが付かなくなり、mrbのサイズがいくらか削減されます。
-gオプションはずし、できました。
ありがとうございます。
3.7KBくらいだったのが、2.8KBくらいに落ちました。サイズを気にしなくてRUNできるようになりました。
便乗質問ですみません。4.0KB上限、厳しいです。
クラス分割をしながらコードを書くと、-gオプションを外してもすぐに4.0KBを超えてしまいます。
これは現在のRubicの制限なのでしょうか?
これは、GR-CITRUSのrubyの制限です。メモリ128kBのGR-SAKURA上で動かしていた条件を引きずっています。
あまり大きくするとスタックあふれが頻発するかなと思って、4KBのままにしています。
大きくするには、wrbb.hの
#define RUBY_CODE_SIZE (1024 * 4) //4kBまで実行可能とする
を変更すれば、変更できます。
また、rubyプログラムをうまく分離できそうであれば、System.setrunを使って、順次実行させることもできます。Rubicから転送した場合、main.mrbとなってしまうので、
プログラムの先頭に、
MemFile.cp("main.mrb","foo.mrb")
と書いておけば、foo.mrbファイルが無ければ、上書きします。
System.setrun("foo.mrb")で、今走っているRubyプログラムが終了したら、次にfoo.mrbが走ります。
System.setrun("foo.mrb")
System.exit
と書いておけばすぐに実行します。
ただし、変数はすべて消えてしまうので、必要なものは、フラッシュに保持しておく必要があります。
Rubic側は、(以前別のスレッドであったように)極端に複雑な式は解析途中にブラウザのメモリが足りなくなることがあるものの、
トータルのmrbサイズに対して特に制限を設けていません。
コードサイズが大きくなると変更時の転送時間も長くなってしまいますので、
モジュール分割して書けるようにしたいなあとは私も思っています。
(1) 次のRubicメジャーバージョンアップで対応予定の、複数ファイル編集機能
(2) 別のmrbファイルをrequireする仕組み (おそらく mattn氏のmruby-requireで出来ると思われる)
の両方が揃うと、
クラス(1ファイル1クラス)に分けて書き、原則変更のあったファイルだけRubicからボードにコンパイル&転送する、
というスタイルで開発できるようになり、作業効率がupしそうです。
wrbb.hの RUBY_CODE_SIZE を変更することで解決できました。ありがとうございます。
複数モジュール分割、熱望します!
ファイル分割ができないのは辛いので・・・