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関連
女子美コラボ
その他
※プロデューサミーティング中
作り方使い方資料
イベント関連
作品記事
体験記事
ライブラリ
ツール
その他・過去ファイル
生地に練りこんで焼き上げたクルミパン、すり鉢ですって野菜と和えたクルミ和え、冷たいお蕎麦にクルミだれ、クルミ饅頭、クルミ豆腐、クルミ餅。クルミは私たちの毎日の食卓に欠かすことができません。そんな私たちの生活と切っても切り離せないクルミについて研究をしてみることにしました。
クルミ(胡桃、山胡桃、漢語:胡桃(ことう)、英語:Walnut、学名:Juglans)は、クルミ科クルミ属の落葉高木の総称。また、食用に利用されるその実を指す。夏の季語としては花を、秋の季語としては実を表す。木工材料としての用途ではウォールナットと英名で呼ばれる。
原産地はヨーロッパ南西部からアジア西部とされる。北半球温帯地域のやや冷涼な気候を好み、降雨量の少ない地方に分布する。葉は羽状複葉、雌雄同株で樹高は20mにも及ぶ。春頃に葉の脇から雄花の穂が垂れ、雌花が直立した後、夏頃に3~4cmほどの球形の実をつける。
仮果と呼ばれる実は緑色をした肉質の外果皮に包まれており、その中に堅い内果皮(=殻)を持つ核果がある。核果の中の子葉部分(=仁)を食用にする。木の実の中では脂肪分が豊富であり、子葉全体の約65%を占めている。またビタミンEやビタミンB群、ミネラル類を豊富に含み、非常に栄養価の高い食品として知られる。子葉部分を圧搾して採られる油は食用の他、空気にさらされて酸化し固まる性質があるため木工製品の仕上げや油絵具の材料としても利用される。
食用のクルミの生産は中国が世界の生産量の約半分を占め、以下、イラン、アメリカと続く。日本では長野県での栽培が多い。
人類に利用された木の実としては最古のもののひとつとして挙げられ、その歴史は紀元前7000年にまで遡るといわれる。古代ローマ人は "Juglans regia"、「ユピテルの聖なる木の実」と呼び珍重した。学名の 'Juglans' はこれに由来する。
日本では縄文時代の遺跡から核果の出土事例がある。また、「縄文クッキー」の名で知られる長野県の曽利遺跡においてはじめて発見されたクッキー状炭化物の材料のひとつと考えられている。日本の律令制下での租税制度であった租庸調(そようちょう)のなかで、甲斐国(現在の山梨県)からの調としてクルミが含まれていたことが平城京から出土した木簡の記録で確認できる。
シナノクルミ
現在日本でもっとも多く栽培される品種。現在の日本で一般にクルミというとこの種を指すことが多い。近代になって日本に移入された中国原産のテウチクルミ(カシクルミ)とイラン原産のペルシャクルミとの交雑種と考えられている。
まだ中国でのクルミブームが継続してるのかわかりませんが、過去にオランダで起こったという『チューリップ・バブル』のような結末は目に見えているので行く末が気になるところです。
www.taobao.com/淘宝で「文玩核桃」を探すと200円(10元)程度から30万円(15800元)まで色々な価格帯があるみたいですね。 文玩核桃だけあって、どれも2個セットみたいです。
高級品はこんな通販ではなくて、怪しげなブローカーが扱っているんでしょうねー。
どうやらこの画像はクルミの萎びた外果皮を剥かずにノギスで計っているところらしい。この動画『20141023 《财富故事》 文玩大集 火遍京城』を見ると記事中での「写真は北京近郊の市場でクルミの大きさを計る業者」という状況も良くわかる。
「よく使い込まれて年季が入ったようクルミ加工するマシーン」とか平気でありそうですがやはり高級品は人の手で使い込まれたものなのでしょうか。30万円(15800元)とはちょっとした貴金属品並みですね。
関連ニュース 『「幻のキン消し」がヤフオクで30万円超え!屁のツッパリはいらんですよ!』
動画を見ればだいたい内容を想像することができますけれども、 クルミファンを増やすためにナレーションを日本語化してみました!
露店では青い実のまま販売しているみたいで、買ってから中のクルミを取り出すので 1対(2個)のクルミの大きさが同じになるかどうかでドキドキするようですね。北京に行った際はぜひ露店市に寄って極上のクルミを格安にゲットしてきましょう。
日本語訳
中国語原文
2万で買って、使い込んだら30万円になるんでしょうかねー。キン消しも興味のない人から見るとまったく無駄ですよねー^^;
青い実のまま販売して2個セットの中身の大きさにドキドキするってトレーディングカード売るみたいな商売ですね。
カード同様に交換市場とかもありそうな気がします。
大きさが一番大切らしいので、52ミリのクルミを2個で、53ミリ1個分の価値があるとかみたいな雰囲気かもですねー。
動画で「中毒」ってキーワードが出てきましたけれども、結構みんな真剣にハマっていて、 どうやったら「青い実」を見て中の種の大きさを推測できるか研究しているみたいです。 好きな人は一日中、露店のやりとりを見ているたけで暇つぶしてきてしまうようですね。
動画を見ているうちに、なんだか、クルミって何だろうと逆にわからなくなってしまいました。桃の種もクルミになるのかなとか^^;
よくよく考えたら「桃」って付く植物はいろいろありましたねー。
ちなみに「胡」は春秋時代の中国で北狄に位置する胡国のことで胡国原産のクルミは桃の種に似ていたので「胡桃」と呼ばれるようになったそうです。胡瓜とか胡椒とかも、クルミと同様、胡国からの伝来してきたようですね。
クルミはモモに似ているけれども、モモはクルミではない!
HIMEKURUMI(仮)用のGR-KURUMIライブラリ改変の孤独な作業にも飽きてきたので途中経過として上げておきます。
GR-KURUMIの素のスケッチをビルドして、オリジナルでは kurumi_sketch.bin のサイズが約53kBだったのを、様々なテクニック(後述)を駆使して 約22kBとスリムになっています。オリジナルの約53kBのサイズはフラッシュROMの容量が64kBしかないHIMEKURUMI(仮)には重荷だったのですが、これくらい削れればいろいろできることと思います。
今んところデジタル出力とシリアル入出力と温度計測くらいしか動作確認してません。
先の投稿に書いた「様々なテクニック」について、忘れないうちに解説しておきます。
HIMEKURUMI(仮)のライブラリはGR-KURUMIのライブラリを基にしていますが、GR-KURUMIと比べてHIMEKURUMI(仮)のROM容量が少ないことから、生成されるROMイメージが小さくなるよう工夫をしています。
行っている工夫の内容は複数あり、それらは以下の3つのいずれかに分類できます。
この内の前2つに分類される方法はGR-KURUMIにも応用が可能です。
リンク方法の工夫
現在のGNURL78 Tool chainでは、参照されないオブジェクトをリンク時に削除する機能が十分に働かず、生成されるROMイメージファイルが無駄に肥大化するという問題がありますが、これを避けるため、リンクするオブジェクトファイルを一旦 ar にてアーカイブし、それをリンクするという方法を採っています。
これはGNURL78 Tool chainの不具合を避けるための方法であり、将来的にGNURL78 Tool chainが修正されれば必要のなくなるものですが、現状ではGR-KURUMIでも有効な方法と思われます。
ライブラリからの浮動小数点演算の削除
周囲の温度を取得する getTemperature()という関数がGR-KURUMIライブラリのなかで唯一浮動小数点演算を行っており、GR-KURUMIのデフォルトスケッチがこの関数を使用しているため、浮動小数点演算ルーチンがリンクされ、生成される kurumi_sketch.bin が大きいものとなっています。
これへの対策として、getTemperature() の内部の計算を整数演算に書き換え、デフォルトスケッチをビルドした際に浮動小数点演算ルーチンがリンクされないよう変更しています。
勿論、getTemperature() 以外でもユーザーがスケッチのなかで浮動小数点演算を使用すればリンクされる浮動小数点演算ルーチンのサイズに従い生成される ROM イメージファイルのサイズも大きくなりますが、標準のライブラリで暗黙的に浮動小数点演算が使用されるのとユーザーが自ら書いたスケッチのなかで浮動小数点演算を使用されるのとでは意味が異なります。
この方法はGR-KURUMIにも有効です。
.lowtextの利用
GR-KURUMI では mirror 領域(03000H~)に読み出し専用のデータ .rodata セクションを配置する関係で生成される ROMイメージの ~02FFFH までに大きな未使用領域が存在しますが、HIMEKURUMI(仮)ではこの領域を積極的に使用することにより生成される ROM イメージの密度を高めています。
具体的には、ライブラリやスケッチのコードが配置される .text.* セクションを .lowtext.* セクションと改名し、HIMEKURUMI(仮)の mirror 領域の開始アドレス(02000H)以前に配置することで .lowtext セクションと .rodata セクションの隙間を解消しています。
この方法は、ROMの容量が 256kB あり、.text セクションのサイズが 64kB を超えることが可能性として予想される GR-KURUMI では難しいでしょう。
.pltの削除
GNUTL78 Tool chain では 64kB を超えたアドレスに配置された関数を 16bit サイズの関数ポインタで呼び出すための仕組みとして PLT(Procedure Linkage Table)という仕組みを用意しており、前述の .lowtext セクションの直前に .plt セクションを用意し、各関数へのジャンプ命令を配置します。
これは、ROM の容量が 64kB である HIMEKURI(仮) では不要な仕組みであり、.plt セクションは容量の無駄にしかならないので削除しています。
この方法は、関数が 10000H 以降に配置される可能性のある GR-KURUMI では難しいでしょう。
オプティマイザの使用
現在の GNURL78 Tool chain の出力するコードは洗練されているとは言い難く、特にコードサイズについては大きな欠点となっています。
そのための対策として、コンパイラが出力したアセンブリコードをアセンブラが処理する前に簡単な最適化を行うスクリプトを作成し最適化を施しています。このスクリプトは Perl で書かれており、主に分岐命令とアドレッシングの冗長なところを改善する動作をしています。GNURL78 Tool chain にはコンパイル/リンク時に同等の処理を行うコンパイラオプション -mrelax という機能が用意されていますが、現在 GR-KURUMI の web コンパイラで使用されている GNURL78 v14.03 ではこの機能がうまく動作せず、それを補う形となっています。
GNURL78 tool chain の現在の最新版である GNURL78 v15.01 ではこの機能は修正されており、将来的に GNURL78 v15.01 以降を使用するのであれば現在のスクリプトの内容の大半は意味がなく、また GNURL78 Tool chain の出力するコードの冗長な箇所はこれ以外にも判明しているため、この最適化スクリプトの内容は今後も流動的に修正していく予定です。
optlib の試用
GNURL78 Tool chain は C の標準のライブラリとして newlib の libc と libm を採用していますが、これ以外にKPIT による optlib という最適化ライブラリが提供されており、HIMEKURUMI(仮)ではこれを試用しています。
optlib はいわゆるオープンソース製品ではなく、折角オープンソースなプログラムで構成されていた GR-KURUMI のライブラリに非オープンソースな製品を混ぜるのはいかがなものかという葛藤もあるため、今後は元の libc と libm に戻したり、あるいは他のライブラリに移行するかもしれません。
saddrの活用
GR-KURUMI の EEPROM ライブラリは内部でデータ・フラッシュ・ライブラリ Type04を使用していますが、このライブラリの制限として
にスタックやデータバッファは配置できないという制限があります。
このため、この領域は通常の .bss セクションや .data セクションには使用が難しく除外する必要がありますが、もったいないので
という使い方をしています。FFE20H~FFEDFH の領域は他の領域と比べて短い長さの命令でアクセス可能なため、ライブラリのサイズの短縮に僅かながら効果があります。
以上の方法の中の
GR-KURUMI のライブラリに適用してみました。
ビルドすると kurumi_sketch.bin のサイズがオリジナルの約 53kB から約 38kB に縮小されるのが確認できます。
これに更に
を使用すると kurumi_sketch.bin のサイズは約 26kB になりますが、オプティマイザの動作や optlib の動作の差異がまだ確認とれていないため今回は外しています。
EEPROMライブラリに間違いがあったので差し替えお願いします。
GR-KURUMI_Sketch_V1.09diet.zip の RLduino78_main.cpp のみ差し替え。
38kB → 27kB に縮小。
RTTI 削って RLduino78_main.cpp も纏めた。
27kB → 21kB に縮小。
2015/5/10 22:11 の投稿 の続き
終了関数の独自実装
libc.a と libstdc++.a で提供される abort()、exit()、std::terminate() の終了関数が必要以上に複雑で大きくかったため、RLduino78_main.cpp の中に
#include <stdlib.h> void abort(void) { for(;;); } void exit(int) __attribute__ ((weak, alias ("abort"))); #include <exception> void std::terminate() __attribute__ ((weak, alias ("abort")));
以上の実装をしています。
いずれも呼ばれたらただ無限ループで停止する動作になりますが、HIMEKURUMI(仮) や GR-KURUMI の用途ではこれらの関数は通常呼び出されないため、問題ないという判断です。
RTTI 削除
GNU の g++ では標準で RTTI が有効としてコンパイルされるため、RTTI サポートの関数がリンクされ、生成されるプログラムのサイズを大きくしています。
HIMEKURUMI(仮) や GR-KURUMI の用途では RTTI は要らんだろうという判断から、コンパイラのコマンドラインオプションに ‘-fno-rtti’ を指定してこれを削除しています。
今まで HIMEKURUMI(仮) について、RL78/G13 の 20pin LSSOP の製品の採用を想定していたのだけれども、電子工作用途には使いづらい部分があるのではないか? という疑問も生じてきたので以下にまとめる。
20pin LSSOP 版の製品の採用を想定していたのは
という理由からで、いづれも試作が楽という観点からのものだった。しかし、いざ基板のパターンを起こし実装を外注するとなると上記のメリットはほぼ意味がなくなる。対して、電子工作用途を考えた場合、20pin LSSOP 版の製品では欠点も見えてきた。
以上の考えにより、RL78/G13 の 20pin LSSOP 版以外のパッケジも検討してみることとした。
300mil 幅の基板に実装できそうな RL78/G13 の製品はおよそ以下のパッケジのものに限られる。
LSSOP とは このようなパッケジ であり、今までの HIMEKURUMI(仮) の試作に使用していたもののそれである。工作はし易いがピン数が少なくフットプリント辺りのピン密度は低い。
HWQFN とは このようなパッケジ である。手作業による実装は厳しそうだが、ハンダ付けの良/不良が外観からある程度確認できそうなので安心感がある。
WFLGA とは このようなパッケジ である。ハンダ付けされる箇所がチップと基板との間に完全に隠れるため、問題が発生した場合何が起こってるかわかり辛い。これは避けたほうが無難な気がする。
そんなわけで、HWQFN の製品を検討してみたい。
RL78/G13 の 24pin HWQFN の製品のピン内容を以下に示す。
この内の 1.~3. は入力専用のピン、4. は外部にコンデンサを接続するだけのピン、14.~16.は流せる電流が小さいピンなのでそれぞれ積極的に HIMEKURUMI(仮) の外部に出したいピンではなく、以上を除くと残りのピン数は 17 であり、外部 20pin を想定している HIMEKURUMI(仮) にはピン数が少ないようだ。
RL78/G13 の 32pin HWQFN の製品のピン内容を以下に示す。
この内の 3.~5. は入力専用のピン、6. は外部にコンデンサを接続するだけのピン、26.~28.は流せる電流が小さいピンなのでそれぞれ HIMEKURUMI(仮) の外部に使いたいものではなく、以上を除くと残りのピン数は 25 であり、外部 20pin を想定している HIMEKURUMI(仮) にはピン数的には余裕がある。この製品の使用を検討したい。
RL78/G13 の 32pin HWQFN の製品を HIMEKURUMI(仮) に使用した場合のピンの使用を考える。
仮に
以上のピン 20 本を基板外側2列にスルーホールに使用し、残りの
をプログラム書き込み用ピンとして VSS と VDD と一緒に基板上に別にスルーホールを用意する。
は基板上で 0.47~1.0uF のコンデンサを接続、
は GR-KURUMI 同様に基板上で LED(2色) を接続、残りの
は未使用もしくは基板上にサービスピンを用意、くらいが適当なところか。
マイコンの採用を決めるに当たって、実際にその製品が入手可能かは絶対に確認しなければならない条件である。
RL78/G13 のフラッシュ ROM の容量が 64kB で 32pin HWQFN の製品の少量購入が可能かを プロダクトセレクタ で確認すると、とりあえずは この投稿をしている時点では入手可能 のようだ。マルツでは謎の スペシャルプライスキャンペーン対象商品 となっており、今すぐ注文すべきかは悩ましいところである。
以上のようなことをウスラボンヤリと考えてます。
そーいや RL78/G13 の LSSOP 版のフラッシュメモリが 64kBが上限だったのでなんとなくそれで考えていたのだけど、32pin HWQFN を条件として考えると、もちょっとメモリ容量の選択肢が広がるんだなあ、
と思って プロダクトセレクタ 見てみたら、マルツで
64kB の民生用途のが360円(スペシャルプライス) 、
96kB の民生用途のが400円、
128kB の民生用途のが440円(スペシャルプライス)、
128kB で動作可能条件の広い信頼性の高い産業用途のが300円(スペシャルプライス)か。ワケわからんな。