GR-SAKURAが発売されたのは2011年末頃で、その当時はWebコンパイラかRenesasのe2 studioあたりを使うしかなかった。 Arduino類似のライブラリが公開されていなかったため、ローカルでビルド環境を整えるのは面倒であったが、 Arduinoから派生したIDE4GRという簡単な開発環境が作られ、ローカルでArduinoと同じ使用感で開発出来るようになった。 このIDE4GRの最新バージョンには、GR-PEACH(RZ/A1H (R7S721001VCBG, 外部FLASH 8MB/内蔵RAM 10MB)及びGR-LYCHEE(RZ/A1LU (R7S721030VCFP), 外部FLASH 8MB/内蔵RAM3MB) 向けのOpenCVライブラリが統合されており、これらのマイコン単体ではOpenCVによる画像処理ができる。
SW3がRUN側の時、初めの電源ONで、書き込まれたファームウエアが開始し、一回リセットするとUSB Mass storageでファームウエア書き込み可能なモードになる。 ここで書き込むと、書き込んだファームウエアが自動的に開始される。SW3がRUNと反対側の時はGeneric Boot Deviceで、RenesasのFDTでファームウエア・ブート路だ書き込みができる。
ボード上の4つあるLEDは使用できる。サンプルの初期コードはGR-KURUMI用にled = 23になっているが、GR-SAKURAではPIN_LED0、PIN_LED1、PIN_LED2、PIN_LED3で 定義されている。
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.
This example code is in the public domain.
*/
// Pin 23 has an green LED connected on most KURUMI boards.
// give it a name:
int led = PIN_LED0;
// the setup routine runs once when you press reset:
void setup() {
// initialize the digital pin as an output.
pinMode(led, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
Ethernetについては、執筆時点のIDE4GR 1.03では、 GR-KURUMIはWIZ550ioモジュールを使用した上での対応、GR-SAKURA(RX63N)のみ内蔵ペリフェラル対応となっており、GR-KAEDE(RX64M)、GR-PEACH(RZ/A1H)については未対応のようであり、 IDE4GRで開発する時は、ネットワーク・画像処理等の用途によって使い分けるのが良いだろう。あるいは以前通りWebコンパイラかe2 studioを使うことになる。 GR-SAKURAのEthernetライブラリには、Renesasのスタックが組み込まれているので、ArduinoのEthernetシールドを使う要領で使用できるが、もちろんシールドは必要ない。 シリアルは、CDCのVCOMドライバを入れる必要があり、配布されているinfを使ってインストールすると良い。 このファイルは特殊電子回路謹製であるが、そのサイトによると、RX621のEthernetは100Mbpsだが、 スループットはそれほど良くなく、せいぜい40Mbpsとのことである。 COMポートを表示しながらサンプルのWebServerを走らせると、シリアルが遅いため応答に詰まりが見られる。
Let's start by acknowledging one external factor that does affect the
popularity of a programming language. To become popular, a programming
language has to be the scripting language of a popular system. Fortran and
Cobol were the scripting languages of early IBM mainframes. C was the
scripting language of Unix, and so, later, was Perl. Tcl is the scripting
language of Tk. Java and Javascript are intended to be the scripting languages
of web browsers.
Lisp is not a massively popular language because it is not the scripting
language of a massively popular system. What popularity it retains dates back
to the 1960s and 1970s, when it was the scripting language of MIT. A lot of
the great programmers of the day were associated with MIT at some point. And
in the early 1970s, before C, MIT's dialect of Lisp, called MacLisp, was one
of the only programming languages a serious hacker would want to use.
-- Paul Graham
-- Being Popular ( http://www.paulgraham.com/popular.html )
Writing code in a compiled language is one of the last things that still can't
be done instantly on a garden variety home computer. If your compilation
process takes more than a few seconds, getting the latest and greatest
computer is going to save you time. If compiling takes even 15 seconds,
programmers will get bored while the compiler runs and switch over to reading
The Onion, which will suck them in and kill hours of productivity.
Debugging GUI code with a single monitor system is painful if not impossible.
If you're writing GUI code, two monitors will make things much easier.
Most programmers eventually have to manipulate bitmaps for icons or toolbars,
and most programmers don't have a good bitmap editor available. Trying to use
Microsoft Paint to manipulate bitmaps is a joke, but that's what most
programmers have to do.
At my last job, the system administrator kept sending me automated spam
complaining that I was using more than ... get this ... 220 megabytes of hard
drive space on the server. I pointed out that given the price of hard drives
these days, the cost of this space was significantly less than the cost of the
toilet paper I used. Spending even 10 minutes cleaning up my directory would
be a fabulous waste of productivity.
-- Joel Spolsky
-- "The Joel Test: 12 Steps to Better Code" ( http://www.joelonsoftware.com/articles/fog0000000043.html )