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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
がじぇるね岡宮です。
画像処理をするImageライブラリを評価バージョンE1.10として公開させていただきました。
大変すみませんが、プロデューサーの皆様から多く意見を反映したいため、スケッチリファレンスはまだ作成していません。(若干言い訳がましいですね・・・)。デフォルトのサンプルコードから、ある程度読み取っていただければありがたいです。サンプルでは動体検知しかしていませんが、人物検知用のライブラリは実装しています。
ちなみに、動体検知は写真3枚、人物検知は1枚で行います。
パラメータ(感度とか)の調整はまだ入れてません。ドライバとしては入ってますので、既存ライブラリの実装を参考にお試しいただければと思います。既に純正CCRXでのWebカメラサンプルでは感度調整など簡単にお試しできますが、普通の生活空間では結局デフォルトがちょうどいいと感じがしたので、日程を優先してE1.10を公開しました。
まだ動くことだけしか確認できていませんが、ファイルのタイムスタンプが2063年なのは何故だろうと思ってました。
FATのタイムスタンプの年が7bitで1980年スタートなので、
15 - 1980 = 0xf8530x53(83) + 1980 = 2063
となっている模様です。
なので、スケッチのdateTime()は以下とする必要がありますね。
*date = FAT_DATE((t.year+2000), t.mon, t.day);
※RTCの年カウンタは16bitなのに8bitしか使えないなんて。
RTCライブラリですが、GR-SAKURA スケッチV2.02も同様の仕様となっておりだいぶ混乱しました。
年データのコンバートには、HEX2BCD()と BCD2HEX() は16ビットへの拡張をされたらいかがでしょう。
digipontaさん、先ほどE1.11をアップしましたので、お手数ですがお試しいただけますでしょうか?
試しましたが、イーサネット周りは、状況は変わらないようです。GR-KAEDE側で送信が途中で戻ってきます。残りを送ろうとすると、戻ってこないです。ブラウザーを止めると、GR-KAEDE側は、エラーで返ってきて終わります。TCPセッションは、正常ですが、データ送信が途中でハングという状況です。
すみません、KAEDEを持ち帰り忘れまして確認できないのですが、SDのコメント外した場合、SD周りは動きますか?
今、動作確認したところ、Card failed, or not present.とでて、同じ症状のままでした。メモリ\利用の競合でしょうか?
ぱらぱら、ソース眺めていて、今回の問題とは関係ないかもしれないけど、Arduino系のヘッダファイルには「typedef unsigned int word;」とか、気持ち悪さがありますね(;^ω^) wordといえば16bitと思うんですけど。wordは使わないのが吉らしい。
そうですね。私の場合V850で育ったのでwordは32bitのイメージでした。今回のJPEGエンコードエンジンのアセンブルでも.wordはGNURXでは32bit、CCRXでは16bit扱いで若干嵌ったりしました。
私は、8bit世代なので、byte(8bit),word(16bit)ですね。マイクロソトも、歴史が古いんで、これと同じですね。
もう、大まかに実行トレースしてると思いますが、イーサとSDの両方を有効にすると、
gr_sketch.cpp → SD.begin(SS) → ... → Sd2Card.cpp → uint8_t Sd2Card::readData(uint32_t block, uint16_t offset, uint16_t count, uint8_t* dst) → uint8_t Sd2Card::waitStartBlock(void) → status_ = spiRec() → SD_CARD_ERROR_READ
上までみると、spiRec()の呼び出しでエラーになっているようで、深いところで、何か競合しているようです。
------- spiRecの呼び出しからのトレース -------Sd2Card.cpp→ status_ = spiRec()→ static uint8_t spiRec(void) {→ return SPI.transfer(0xFF); // here used→ SPI.h→ inline static uint8_t transfer(uint8_t data) ← この定義がありました(ミスリード訂正)
inline static uint8_t transfer(uint8_t data)が、ゼロを返しているようです。ここからは、MPUのレジスタをアクセスするステップが増えます。イーサと、何かハードリソースが、競合してるんでしょうか?
-------ただ、上記の問題が、SDを無効にして、イーサネットだけ有効にした時の不具合の原因と同じかどうかはわからなくなってきたので、念のための確認ですが、イーサネットのサーバの応答ですが、一度に送信できるデータサイズに、インプリ上の制限があったりしますか?ご参考
時間切れで検証まで出来てないんですが、リンカスクリプトで
._RX_DESC :{ . = ALIGN(32);} > RAM._TX_DESC :{ . = ALIGN(32);} > RAM
とありますが、これは32バイト分の領域を確保したいという意図でしょうか?であれば、これだと開始アドレスによってまちまちのサイズとなってしまうので(map参照)、
._RX_DESC :{ . += 32;} > RAM._TX_DESC :{ . += 32;} > RAM
とすべきなのではないでしょうか?(32bitアラインメントが必要かどうかがわかりませんが...)
セクションのアライメントが 32 の倍数というだけで、領域は
gr_common/lib/Ethernet/utility/driver/r_ether.c:
static descriptor_s rx_descriptors[EMAC_NUM_RX_DESCRIPTORS*2] __attribute__ ((section("._RX_DESC"))); //TODO static descriptor_s tx_descriptors[EMAC_NUM_TX_DESCRIPTORS*2] __attribute__ ((section("._TX_DESC"))); //TODO
で確保してるので、そこは大丈夫なんじゃないかと思います。
# コメントの //TODO は気になるな…
イーサーの方は、初回の送信は、途中で帰ってくるけどエラーではないので、トレースしても拾い難いと思うのですが、多分、残データを送りなおそうとすると、関数が戻ってこないので、この止まってるところがどこか分かると、原因が分かりそうな気がしてます。あと、TCPセッションは生き続けているので、デバッカでいきなり止めても、どっか別のとこで、正常に動いているようにしか見えない可能性が大きい。どちらかというと、厄介なバグ。printfデバックが、無難な領域になってるような(^_^;) あと、私は、GR-Sakuraとは別のライブラリを持ってきてるのかと思ってました。同じということは、特電さんのコードでしょうか?
現時点の推理は、送信にウェイトが入る要因は、なんだろうか?割り込み待ちになるんだろうか? でも、ブラウザを落とすと戻ってくることを考えると、ポーリングで待っているとも推定。送信が中断する条件は、どこかの変数を見ていると仮定するると、その変数が中断要因を維持している状態で、再送信すると、この変数が解除するまで、ポーリング待ち。セッションが切れると、それが解除されるか、別の変数の状態の変化で、再送信は戻ってくる。
tcp_api.cとか要所ようしょ、下記の分岐コンパイルがあるのですが、__GNUC__も、GRSAKURAも、未定義みたいです。GR-KAEDE用のマクロ定義は、これでOKでしょうか? あと、tcp_api.cで、Serial.printが使えないみたいです。何を、includeすれば使えるようになりますか?
#if defined(__GNUC__) || defined(GRSAKURA)
#include "t4define.h"
#endif
おっしゃる通りです。寝ぼけていたようで...。
どちらかというと、
#define EMAC_BUFSIZE (1536) /* Must be 32-byte aligned */
とあるので、._ETHERNET_BUFFERSにALIGN(32)をつけた方が良さそうですね。
Inomataさん、私の方でも再現しまして、原因が分かりました。Server.writeのサイズ指定がlong unsigned intであるにも関わらず、tcpのドライバの中でsint16になっっているようです。
具体的にはtcp_api.cの中の572行目にある下記で、本来は80000バイトぐらいの値が入るはずが65535を超えた分が代入され、およそ4分の1しかデータが書かれません。ただ、このサイズの型宣言がされているtcp.hだけ変更しても、状況は改善しませんでしたので、これについてはライブラリ開発者に聞いてみようと思います。
head_tcb[cepid-1].req.d.dr.dtsiz = len;
digipontaさんのソースを以下のようにとりあえず行うことで、すべての写真データがアップされることが確認できました。
Serial.println( Server.write( adr, 60000 ) ); // 途中で戻ってきてしまう(^_^;) int32_t rest_size = size - 60000; Serial.println( Server.write( adr+60000, rest_size ) ); // 途中で戻ってきてしまう(^_^;)
Okamiyaさん、Good Jobです。有難うございます。あとは、SDメモリとの競合ですね。
私も、修正して試してみました。データが最後までは、行けてないないようで、最後の方きれてますね。でも、何とか、ピント合わせに、使える状況になりました。ライブラリの対策版を待ちましょう。