Perl連想配列の入れ子

Perlの連想配列が入れ子に出来るかもって話を仕入れた。

具体的には、

%hoge = (x => y, ...);

と書くと hoge には連想配列の実体が格納されるが、

$hoge = {x => y, ...}

と書くと hoge には連想配列の参照が格納されるという話。違いは、丸括弧か中括弧かということである。

まだ実際にコードを書いて試してみたわけではないが、備忘録代わりに書いておくことに。

非同期

PIC16のアセンブラをIDEでデバッグしててハマった。

ステップ実行しているのにサブルーチンに何故かジャンプ･インしない・・・と思って悪戦苦闘していたのだけれど、実はマシン語にアセンブルされたバージョンのアセンブラコードと、IDEのビューアでデバッグ用に見ていたアセンブラコードのバージョンが違ったというお粗末なミス・・・orz つまり、アセンブラコードとマシン語の実行コードが同期していなかったんですわ。

IDEが新しいバージョンのアセンブラソースをリロードしてくれるのに、マシン語への再ビルドはしてくれないのです。ちょっと不親切だな～とも思うんですが、ともあれミスはミスですわ。

寝る前に解決してくれて嬉しいんだけれど、しょーも無い話で1時間以上無駄にした感がある。ちょっと勿体無かった。まぁ、何事も経験と言えば経験なのですが。

今度はPICマイコン

8ビットPICマイコン (PIC16F874) 向けのコードを書いています。人生初PIC体験です。

と言いつつ、昨年まで書いていたH8 3069向けのコードでGPIOを使っていたので、そういった意味での敷居は高くありませんでした。

敷居が高いのは、アセンブラ！人生初アセンブラです。H8向け開発でもアセンブラコードを読む機会がありましたが(TOPPERS/JSPのモニタプログラムとか)、今回はまさに開発対象がアセンブラです。一応、Cライクな独自言語を書いてそれをコンパイラに掛けるというスタイルで開発しているんですが、出力されたアセンブラをPICベンダの配っているアセンブラ向けIDEでデバッグしてます。

う～む、どんどんとプリミティブになってきた。。。

それにしても、アセンブラ読むの大変です。かなり大変です。

Perl

なんか、久々にPerlを書こうとすると色々と敷居が高い。
連想配列の値に連想配列を入れる、という初期化の仕方が出来ないらしい。
つまり、

my %hoge = ("key1" => ("key11" => "val11", "key12" => "val12"), ...);

みたいな感じのコードが書けない。
う～、じれったい！

Perlは連想配列があるので構造体は無いらしい。
うぅぅ・・・クラスを作ってオブジェクト指向しろと、そういうことですか・・・。

あ、ちなみに処理系はCygwinのPerl 5.10.0です。。。

PHPのinclude_pathで

paperboy & co.のHeteml (ヘテムル) というホスティングサービスを個人的に契約して使っているのですが、ここのPHPがイマイチ使いにくい。とは言ってもPHPはPHPなのでどこで使おうが一緒なのだけれど、問題は各ユーザが個別にinclude_pathを設定できない点。

通常、.htaccessでphp_valueディレクティブを使ってinclude_pathを設定すれば、各ユーザが個別にinclude_pathの設定が出来るのだと思われるが、これが出来ない為にrequireやincludeに指定するパスをどうすれば良いのか、非常に悩ましいのだ。

ちなみに、今はrequire / include対象のファイルを絶対パスで指定することでこの問題を避けているが、これははっきり言ってダサい。あまりにもダサい。

もっとスマートにどうにか出来ないものかなあ。

久々のJava

久しぶりにプライベートでJavaコードを書いています。

ところが、Java SE 5を前提としたサンプルコードで未知のノーテーションを発見！

for(Folder f : fol.list()){
}

これって、いわゆるPerlやPHPのforeachなんだと思うんですが、Javaでは初めて見ました。ああ、私の知識はJ2SE 1.4で止まっている・・・orz 仕事でJavaのコードを読んでいたのは3年以上前なので、仕方のない事かも知れませんが。。。

それにしても、Javaはまだまだ進化し続ける言語なんですね。あらためて実感しました。

TOPPERS/JSP for秋月電子H8 3069 LANボード (6)

前回からだいぶ間が空いてしまいました。

ブレーク信号を受信するとTOPPERS/JSPカーネルがハングしてしまっていたのですが、これは受信割込ハンドラだけでなくエラー受信割込ハンドラを有効にすることで回避できました。また、実際はブレーク受信時の処理を書く必要はなかったのです・・・まったく、一体何のためにあれだけ苦労したのかと。

ちなみに、今回この問題が起きたわけは、もっと深いところにありました。深いとは言ってもソフトではなく、ハードです。

実は、H8 3069 LANボードに載っているH8 3069には3チャネルのシリアルコントローラが載っているんですが、チャネル0とチャネル1はRS-232C用に信号レベルの変換を行うチップが接続され、そのチップ経由でチャネル1がD-sub 9ピンの雌コネクタに接続されています。このチャネル1をシリアルコンソールとして利用するわけです。

ところで、今回はまっていたのはこのRS-232C向けに出力されているチャネル0を使った通信だったのですが、RS-232C用に信号レベルを変換されてしまうと都合の悪いデバイスに接続をしなければならなかったので、このH8からレベルシフタへの配線パターンをカットして、そこからリード線を引き出す様な使い方をしていたんですね。

ちなみに、RS-232Cとはシリアル通信に対してHIGHとLOWの電圧を定めたもので、HIGHが+12V、LOWが-12Vで作動します。通常のシリアル通信(UART)にはHIGHレベルの電圧についての規定はなく、LOWレベルはグラウンドで動作します。

TOPPERS/JSPのシリアルドライバは、チャネル0のUARTがレベルシフタに直結している事を想定していた為に、今回の問題が起こった様でした。

ま、基板に直接手を入れる様な事をすれば、この様な想定外の事態が起こる、ということなんでしょうな。ともかく良い勉強になりました。