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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
まとめておくとそのうち修正されたりされなかったりするんじゃないかという期待を込めて立てました。
サイズ縮小の要望
いまのライブラリで生成されるROMイメージファイルは無駄にでかいので、改善していただきたい。
『クルミの研究』 の投稿に改善案として修正したものを添付しています。
GR-SAKURA ライブラリ V2 と同様に bitbucket 等でリポジトリを公開して pull req とかできるようなってると良いですね。
Fujitaさん、ありがとうございます。ようやくSAKURAとか7/11ネタがひと段落しまして、KURUMIもFujitaさんの貴重な情報を反映していきたいと思います。
KURUMIのは以下で公開していますが、pull requestはできないんですね。。
bitbucket.org/.../kurumi_sketch
五月雨式に pull req されると確認する側も大変だと思うので、フォーラムに投稿すれば誰か暇で親切な人が見てくれるんじゃないかという考えもありますがどういうスタイルが最適かは悩ましいところですね。
Software PWM の修正(ピン可変と不具合修正)作業をしていたのだけれど、作業してた PC がお亡くなりになったので中断中。復帰したら投稿します。
それはそれですごい嬉しいですし、運営人員を増やすきっかけになればいいとは思いますね。
PCが復帰されることを心からお祈りしています。
GR-KURUMIへの要望として、シリアルの送受信バッファサイズを調整できる様にできませんか?
送受別に設定します。
ヘッダファイル書き換えでいいと思っていましたが、APIとして用意した方がいいですか?どっちでもいいですか?
あまりC++判らないのですが、バッファ自体はインスタンス生成時に動的に生成されるのですよね?
ならbeginの引数にボーレート以外にオーバーライドでバッファサイズの指定をできるようにならないのかなぁ?って思いです。
応用によっては送信バッファが必要無い!とか受信バッファが必要無いとかもありえますし。
バッファは、HardwareSerial.cpp の中でサイズが
#define SERIAL_BUFFER_SIZE 64
となってて、リングバッファの定義が
struct ring_buffer { unsigned char buffer[SERIAL_BUFFER_SIZE]; volatile unsigned int head; volatile unsigned int tail; };
で、あとはチャンネルごとに受信と送信のバッファが
ring_buffer rx_buffer = { { 0 }, 0, 0}; ring_buffer tx_buffer = { { 0 }, 0, 0};
みたいな感じで(現在は)静的に確保されてますね。
静的でいいとは思ってますが使わないチャネルも一律に確保されているので、そこは変更した方がいいかもしれませんね。
RTCに定周期割り込みのハンドラーの登録機能が欲しい。
RTCに定周期割り込みのハンドラーの登録機能
↓辺りとはまた別に、ということでしょうか?
attachIntervalTimerHandler() attachMicroIntervalTimerHandler() attachCyclicHandler()
サイクリックハンドラの場合はloop関数内で処理されていますが、実はloop関数を使用していません(笑)。
他の1ms周期のやつはベースのクロックがシステムクロックになると思われるので、RTCの32768Hzのクロックよりか精度が落ちそうな気がしないでもない。
精度の高い1秒周期で割り込みハンドラが使えると、1000を数えなくても良いので、ちょっとだけ処理が楽になります。