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を数えなくても良いので、ちょっとだけ処理が楽になります。
二重書き込みになっちゃった。
1m 秒は精度の高い RTC 用の 32.768kHz のサブクロックをソースにしているので割り込み間隔の精度は高いです。
但し、33/32768 秒を 1m 秒ということにしているので時計的な用途にはそのまゝでは使い物になりませんが。
精度の件は了解です。
ただ1秒割り込みとか便利なので、実現して欲しいなぁ。
今はハンドラの中で経過時間に補正を掛けるロジックを追加しています。
RLduino78_basic.cpp の中の周期起動コールバック関数を呼び出す関数
void execCyclicHandler() { int i; for (i = 0; i < MAX_CYCLIC_HANDLER; i++) { if (g_afCyclicHandler[i] != NULL) { if (g_u32timer_millis >= g_au32CyclicHandlerPerformTime[i]) { g_au32CyclicHandlerPerformTime[i] = g_au32CyclicTime[i] + g_u32timer_millis; (*g_afCyclicHandler[i])(g_u32timer_millis); } } } }
g_au32CyclicHandlerPerformTime[i] についてオーバーフローが考慮されてないので 42億ミリ秒とちょっと(約49.7日)でおかしくなる感じ。
RLduino78_basic.cppにある↓関数は、修正されないのでしょうか?
* @attention 温度センサの精度(あるいは変換式)に問題があるため正しい温度になりません。
ちゃんとした値が返ってこないし、float使う必要もないと思う。
/** * MCUに内蔵されている温度センサから温度(摂氏/華氏)を取得します。 * * @param[in] u8Mode 摂氏/華氏を指定します。 * @arg TEMP_MODE_CELSIUS : 摂氏 * @arg TEMP_MODE_FAHRENHEIT : 華氏 * * @return 温度を返却します。 * * @attention 温度センサの精度(あるいは変換式)に問題があるため正しい温度になりません。 ***************************************************************************/int getTemperature(uint8_t u8Mode){ int s16Result; float fResult;
FUNC_MUTEX_LOCK; s16Result = _analogRead(ADS_TEMP_SENSOR);
// 取得したアナログ値を摂氏へ変換 // 温度 = (温度センサの出力電圧 - 1140 mV) / 温度係数(-3.6mV) // 温度センサ出力電圧 = A/D変換結果 / 1024 * 基準電圧(Vdd) // // ∴ 温度 = ((A/D変換結果 / 1024 * 5V) - 1140mV) / -3.6mV // fResult = (((float)s16Result / 1024 * 5) - 1.140) / -0.0036; if (u8Mode == TEMP_MODE_FAHRENHEIT) { // 摂氏を華氏へ変換 fResult = (fResult * 5 / 9 + 32) + 0.5; } FUNC_MUTEX_UNLOCK; return (int)fResult;}