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 コンパイラで提供されている GR-CITRUS 用のテンプレート GR-CITRUS-Sketch_V1.00.zip は GR-SAKURA のテンプレート GR-SAKURA_Sketch_V2.12.zip を基に作成されているようですが、現在 GR-SAKURA 用に提供されているテンプレートの最新は GR-SAKURA_Sketch_V2.13.zip であり、更新が追い付いていないようです。
GR-CITRUS-Sketch_V1.00.zip と GR-SAKURA_Sketch_V2.12.zip の差分を見てみると
ペリフェラル(SCI)の割り当てであるとか、
62d61 < {IER_SCI6_TXI6, 1, IER_SCI6_RXI6, 0, IR_SCI6_TXI6, IR_SCI6_RXI6, IPR_SCI6_TXI6, IPR_SCI6_RXI6, 6}, 64,65c63 < {IER_SCI3_TXI3, 0, IER_SCI3_RXI3, 7, IR_SCI3_TXI3, IR_SCI3_RXI3, IPR_SCI3_TXI3, IPR_SCI3_RXI3, 3}, < {IER_SCI5_TXI5, 6, IER_SCI5_RXI5, 5, IR_SCI5_TXI5, IR_SCI5_RXI5, IPR_SCI5_TXI5, IPR_SCI5_RXI5, 5}, --- > {IER_SCI6_TXI6, 1, IER_SCI6_RXI6, 0, IR_SCI6_TXI6, IR_SCI6_RXI6, IPR_SCI6_TXI6, IPR_SCI6_RXI6, 6}, 67a66,67 > {IER_SCI3_TXI3, 0, IER_SCI3_RXI3, 7, IR_SCI3_TXI3, IR_SCI3_RXI3, IPR_SCI3_TXI3, IPR_SCI3_RXI3, 3}, > {IER_SCI5_TXI5, 6, IER_SCI5_RXI5, 5, IR_SCI5_TXI5, IR_SCI5_RXI5, IPR_SCI5_TXI5, IPR_SCI5_RXI5, 5},
ピン番号の違いであるとか
770c774 < HardwareSerial Serial1(1, &SCI0, MstpIdSCI0, PIN_IO1, PIN_IO0); --- > HardwareSerial Serial1(1, &SCI0, MstpIdSCI0, PIN_IO0, PIN_IO1);
どうでもいい書き換えであるとか
150c150 < inline int _store_char(unsigned char c); --- > inline bool _store_char(unsigned char c);
凡そそんなのばかりであり、fork する理由が見当たりません。
ペリフェラルやピンの違いであれば
#if GRSAKURA #define Serial0SCI SCI6 #define Serial0Tx PIN_IO1 #define Serial0Rx PIN_IO0 ~ #elif GRCITRUS #define Serial0SCI SCI6 #define Serial0Tx PIN_IO0 #define Serial0Rx PIN_IO1 ~ #endif
等と定義してライブラリ中ではそれを使用すれば fork は避けられる筈なので、早期の内に軌道修正していただきたいです。
GR-CITRUS のライブラリに GR-SAKURA の最新の修正が適用されていない現時点で既に問題は生じています。
> 同様な統合化を実施しようと思っています。5月中旬着手の6月末完了ぐらいでいきたいと思ってます。 GR-KAEDE のライブラリも SAKURA の 2.12 ベースの様ですが、こちらも併せて作業していただきたいですね。
GR-SAKURA_Sketch_V2.12 → GR-CITRUS_Sketch_V1.00 の差分 約60kB
GR-SAKURA_Sketch_V2.12 → GR-KAEDE_Sketch_V1.21 の差分 約100kB
と変更点は多い模様。
> GR-CITRUSにはEthernetがなく、ライブラリファイル(45個)を削除しているのですが、
> ①統合化したときにライブラリファイルをGR-CITRUSのプロジェクトに含めたくないことと、
> ②GR-SAKURAではmain ループ内でEthernetのAPIがコールされており、Ethernetライブラリだけ分離するのが難しい
① については含めなければ良いだけでは?
② は GR-SAKURA の V2.14 main() が
int main(void) { //init(); //moved to reset_program.asm #if defined(__T4__) Ethernet.maininit(); #endif #if defined(USBCON) USBDevice.attach(); #endif setup(); for (;;) { loop(); //if (serialEventRun) serialEventRun(); #if defined(__T4__) Ethernet.mainloop(); #endif } return 0; }
なのに対して CITRUS の V1.00 のそれが
int main(void) { setup(); for (;;) { loop(); //if (serialEventRun) serialEventRun(); } return 0; }
となっていて内容が異なっていますが、条件コンパイルを使用するなり、ライブラリの有無でリンクするかしないかの関数は
void func(void) __attribute__((weak));
等とプロトタイプ宣言し、呼び出し部分は
if (func != NULL) { func(); }
等とすれば、該当の関数がリンクされゝば実行され、リンクされなければ実行されないという動作にできるので、main() を共通化することも難しいことではない筈です。
オブジェクト Ethernet に weak 属性を付けて
if (&Ethernet) { Ethernet.maininit(); }
等としても、Ethernet が不在でもメンバ関数(この場合 maininit())呼び出しのために関連のコード等はリンクが必要となってしまうので、それを避ける方法として、
オブジェクト Ethernet を定義している gr_common/core/Ethernet.cpp に
void EthernetMaininit() { Ethernet.maininit(); } void EthernetMainloop() { Ethernet.mainloop(); }
を追加、gr_common/core/Ethernet.h に
void EthernetMaininit() __attribute__((weak)); void EthernetMainloop() __attribute__((weak));
を追加、gr_common/core/main.cpp の
Ethernet.maininit();
を
if (EthernetMaininit) { EthernetMaininit(); }
に変更、同ファイルの
Ethernet.mainloop();
if (EthernetMainloop) { EthernetMainloop(); }
に変更すれば、main() との接点は EthernetMaininit() と EthernetMainloop() だけとなるので、makefile の OBJFILES から
gr_common/core/Ethernet.o gr_common/core/utility/driver/phy.o gr_common/core/utility/driver/r_ether.o gr_common/core/utility/driver/t4_driver.o gr_common/core/utility/T4_src/IPAddress.o gr_common/core/utility/T4_src/config_tcpudp.o gr_common/core/utility/T4_src/ether.o gr_common/core/utility/T4_src/ip.o gr_common/core/utility/T4_src/r_dhcp_client.o gr_common/core/utility/T4_src/r_dns_client.o gr_common/core/utility/T4_src/T4_Version.o gr_common/core/utility/T4_src/tcp.o gr_common/core/utility/T4_src/tcp_api.o gr_common/core/utility/T4_src/udp.o gr_common/core/utility/T4_src/checksum/rx/cksum_rx_little.o
を外してもリンクは通るようなります(動作は未確認)。
Ethernet 等オブジェクトの他クラスのメンバ関数にも weak 属性は付けられるようなので、gr_common/core/Ethernet.h の Ethernet の宣言を
extern class EthernetClass Ethernet __attribute__((weak));
に変更、EthernetClass::mainloop() の定義を gr_common/core/Ethernet.cpp に移動し、gr_common/core/Ethernet.h の EthernetClass の maininit() と mainloop() の宣言を
void maininit(void) __attribute__((weak)); void mainloop(void) __attribute__((weak));
と変更すれば、gr_common/core/main.cpp のそれぞれの呼び出し箇所は
と
if (&Ethernet) { Ethernet.mainloop(); }
とできるので、先の例より余計な関数を作らない分良い気がします(動作は未確認)。
ご説明ありがとうございました。
理解しようと努力したのですが結局条件コンパイルでいけない理屈がサッパリ理解できなかったのですが、この件については自分にはわからないものとしてこれ以上の追求は諦めます。