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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
WEBコンパイラの不具合か、どこからのメモリリークかの特定はできてないのですが、下記URLのソースコードで、22行目の「int sec, min, hour;」ですが、これを、「unsigned char sec, min, hour;」にすると、23行目の「unsigned int cnt = 0;」の変数が、何らかの条件で、汚されて、異常動作する症状を確認しました。
https://github.com/digiponta/RADIO-CLOCK4GR-KURUMI/blob/master/gr_sketch.cpp
ご一報、猪股
gr_sketch.cpp の
case 59: // Serial.print( val ); min = 10*(bit[2]*4 + bit[3]*2 + bit[4]) + bit[6]*8 + bit[7]*4 +bit[8]*2 + bit[9]; hour = 10*(bit[13]*2 + bit[14]) + bit[16]*8 + bit[17]*4 +bit[18]*2 + bit[19];
の箇所が、代入される変数 min と hour がそれぞれ 16bit の場合と 8bit の場合で生成されるコードが違いますが、
min と hour が 16bit の場合:
mov a, !_bit+2 sarw ax, 8 addw ax, ax movw r10, ax mov a, !_bit+3 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 addw ax, ax movw r10, ax mov a, !_bit+4 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 addw ax, ax movw r10, ax shlw ax, 2 movw r12, ax movw ax, r10 addw ax, r12 movw r10, ax mov a, !_bit+6 sarw ax, 8 shlw ax, 3 movw r12, ax movw ax, r10 addw ax, r12 movw r12, ax mov a, !_bit+7 sarw ax, 8 shlw ax, 2 movw r14, ax movw ax, r12 addw ax, r14 movw r12, ax mov a, !_bit+8 sarw ax, 8 addw ax, ax movw r10, ax movw ax, r12 addw ax, r10 movw r10, ax mov a, !_bit+9 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 movw !_min, ax mov a, !_bit+13 sarw ax, 8 addw ax, ax movw r10, ax mov a, !_bit+14 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 addw ax, ax movw r10, ax shlw ax, 2 movw r12, ax movw ax, r10 addw ax, r12 movw r10, ax mov a, !_bit+16 sarw ax, 8 shlw ax, 3 movw r12, ax movw ax, r10 addw ax, r12 movw r12, ax mov a, !_bit+17 sarw ax, 8 shlw ax, 2 movw r14, ax movw ax, r12 addw ax, r14 movw r12, ax mov a, !_bit+18 sarw ax, 8 addw ax, ax movw r10, ax movw ax, r12 addw ax, r10 movw r10, ax mov a, !_bit+19 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 movw !_hour, ax
min と hour が 8bit の場合:
mov a, !_bit+6 shl a, 3 mov l, a mov a, !_bit+9 add a, l mov r14, a mov a, !_bit+7 add a, a mov l, a mov a, !_bit+8 add a, l add a, a mov l, a mov a, r14 add a, l mov r14, a mov a, !_bit+2 sarw ax, 8 addw ax, ax movw r10, ax mov a, !_bit+3 sarw ax, 8 movw r12, ax movw ax, r10 addw ax, r12 addw ax, ax movw r10, ax mov a, r10 mov l, a mov a, !_bit+4 add a, l shl a, 1 mov r10, a shl a, 2 mov l, a mov a, r10 add a, l mov l, a mov a, r14 add a, l mov !_min, a mov a, !_bit+16 shl a, 3 mov l, a mov a, !_bit+19 add a, l mov r11, a mov a, !_bit+17 add a, a mov l, a mov a, !_bit+18 add a, l add a, a mov l, a mov a, r11 add a, l mov r11, a mov a, !_bit+13 shl a, 1 mov l, a mov a, !_bit+14 add a, l shl a, 1 mov r10, a shl a, 2 mov l, a mov a, r10 add a, l mov l, a mov a, r11 add a, l mov !_hour, a
その他のコードに違いはなく、異なるコードが生成された場合に他の領域を壊しているということもないので問題なさげな感じです。
フォロー有り難うございます。メモリリークは、adafruitのライブラリが怪しくなってきた感じですね。
自分が同じトラブル起こしたら、bit配列変数を疑いますかね。。とりあえずbitに書くとこを全部関数に変更して、その関数内では書き込み前に範囲チェックさせます。
症状からも、過ぎた範囲にwriteした場合の「間違って書かれる相手」が変わるって意味では、無くはないかなぁと。単純に考えすぎっすかね。。
特に60行目なんかは、変数phaseがどこで何されてるか判らない印象を受けます。
助言有り難うございます。初期化以外のbitに書き込んでるのは60行目だけなんで、直前のチェックで、オーバーはしないはずなんですが、もしかして、sizeofが正しい値を返してないとか(^_^;) 再確認してみます。
そういえば関係ないかもですが、以前adafruitのライブラリ(ST7735用)をSAKURAで使おうとした時に、ライブラリの問題?っぽいのにアタりました。pgm_read_byteってのが(*(const unsigned char *)(addr))とdefineされてるんですが、これの戻りにchar型を期待してコーディングされてるっぽいです。ところがSAKURAではshortintが返ってきていて、動きがおかしくなっていました。SAKURAが32bitだからかなとも思いましたが、32bitって意味では同じと思われるGenuino101ではcharが返るようで、なんだろなぁと。それ以上は探らず力技で対処しましたが。
GFX.cppにも似たような定義が書かれてそうなんで、ワルさしてないかなぁとちょい気になりました。
情報有り難うございます。ライブラリ持ってきたときに、そう言えばという気がしてきました。
怪しいとこ見つけました。GR-Kurumiのアドレス空間は16bitでしたっけ?
> GR-Kurumiのアドレス空間は16bitでしたっけ?
RL78 のアドレス空間は 20bit ですが、ポインタは指標する対象が __far 指定されて配置された定数でない限りは 16bit で問題ありません。
__far 指定は GNURL78 Toolchain では現在のところ C++ では使用できず C 専用であり、ユーザが特に指定しない限りは気にしなくて良いキーワードの筈です。
pgm_read_pointer() は RADIO-CLOCK4GR-KURUMI-master/Adafruit_GFX.cpp の中で Adafruit_GFX::setFont() を使用してカスタムフォントを設定したときのみ使用されるようであり、それを設定しない限りは問題なさそうです。
レス、ありがとうございます。ここじゃないのか(^_^;) 取り敢えず、現時点、githubで公開のソースコードで、症状は押されらてるようです。