基本的にこちらのマイコン徹底入門を参考に進めていき、Mac(というかUNIX)特有の変更点に重点を置いて解説していきます。

これらのセットアップをする前にMac OSXのセットアップディスクからXCode(開発ツール)を事前にインストールしておいてください。

Mac OSXではDFU経由での書き込みはできません。JTAG経由のみの書き込みとなるのでJTAGデバッガが必要です。

セットアップする環境一覧

• GCCによるARMのクロスコンパイル環境
• Eclipseを用いた統合開発環境
• OpenOCDとJTAGを用いたデバッグ

セットアップ手順

GCCによるARMのクロスコンパイル環境

まずはコードをARMプロセッサで実行するためのバイナリにコンパイルするツールをインストールします。

本来はGCCを一からコンパイルしてセットアップするのですが、Mac上でARMのクロスコンパイルをするためのバイナリが用意されているのでそれをダウンロードしてきます。

• http://sourceforge.net/projects/devkitpro/files/

上記のサイトにアクセスし、リストの中からdevkitARMのMac版の最新バージョンをダウンロードして下さい。執筆当時はdevkitARM_r31-osx.tar.bz2でした。

ダウンロード後は解凍し、解凍してできたディレクトリを/usr/local/devkitARMにコピーしてください。

そして、PATHを通すために~/.bash_profileファイル(無ければ新規作成し)、次の一行を加えてください。

export PATH=$PATH:/usr/local/devkitARM/bin

これでgccのセットアップは完了です。ターミナルで、

arm-eabi-gcc -v

とコマンドを実行すると次のスクリーンショットのようにGCCのバージョンが表示されれば成功です。

arm-eabi-gcc -v

Eclipseのセットアップ

Eclipse CDTのセットアップ

実は以上でSTM32向けのコードをコンパイルすることはできるのですが、統合開発環境があると作業が進めやすいのでEclipse(CDT)を用いた統合開発環境を構築します。

まずはEclipse CDTをインストールします。

Eclipse CDTのダウンロードページからCDT 7.0 for Eclipse Heliosをダウンロードします。(執筆当時の最新バージョンです)

Eclipse packageのリンクをクリックすると、

Eclipse CDT ダウンロードページへのリンク

次のようにプラットフォームの選択画面が出ます。ここで、もし64bit対応のMac本体であればMac OSX(Cocoa 64bit)を、そうでなければ32bitを選んでダウンロードしてください。

Eclipse CDT プラットフォームの選択

ダウンロードし、解凍してできたeclipseディレクトリをApplicationフォルダにコピーします。

そして、コピーした先のEclipse.appを実行してください。

起動時にworkspaceの場所を聞かれますがデフォルトのままで構いません。ここで指定したディレクトリにソースコード等が保存・配置されることになります。

Embedded CDTのインストール

それでは次に組み込み開発向けのプラグインをインストールします。

EclipseのHelpメニューから….となるのですが、あまりにも前述のマイコン徹底入門とかぶるので作業の必要なページを列挙しておきます。

ただ、どうやらEclipseからRxtxをインストールするとエラーでうまく行かないので、Rxtxの公式ダウンロードページからrxtx-2.1-7r2のソースコードをダウンロードして、configure と make 、sudo make installを実行して手動でインストールしてください。

• 4.1.2.4. Embedded CDTのインストール
• 4.1.2.5. ターミナルソフトウェアのインストール
• 4.1.2.6. バイナリエディタのインストール
• 4.1.2.7. ファイルタイプの追加

OpenOCDとJTAGを用いたデバッグ

FTDIのライブラリのインストール

以下、鋭意執筆中…

工場出荷時に規定の周波数(基本的に8MHz)になるように校正されていますが、データシートによると10%までの誤差がある可能性があり、シリアル通信では致命傷になります。

そこで、個別に調整できるようにOSCCAL(発振校正レジスタ)が存在します。このレジスタをプログラム実行時に書き換えることで発振周波数を変更できます。OSCCALが大きいほど高い周波数で、小さいほど低い周波数で動作します。

AVRはヒューズビットのCKOUTをプログラム(0)することにより、CLK0端子からシステムクロックが出力されます。これを測定機器で観測しながらOSCCALレジスタを操作することによりクロックを調整します。

校正

手元にあったATmega88を8Mhzに校正してみました。今回は周波数の測定には周波数カウンタを利用しました。もちろんオシロスコープで周波数を算出しても構いません。

工場出荷時の校正値はAVR ISP mkⅡを利用して読み出せます。この個体は0xbbになっていました。この状態での発振周波数はこのようになりました。

工場出荷時(0xbb) 8.09MHz

8.09MHzと少し高い周波数になっていました。誤差は+1.3%とデータシートの許容範囲10%に比べるとかなりよい精度です。が、少し高いので0xbaにしてみました。

OSCCAL = 0xba 8.03MHz

0xbaにしたところ8.03MHz。これでもまだ高いので、0xb9にしてみます。

OSCCAL = 0xb9 7.99MHz

0xb9にすると7.99MHzと誤差は-0.13%とかなり高精度にできました。しかし、残念ながらCR発振は気温等に影響されるので常にこの精度を維持することはできません。あくまでも「今の環境」での周波数です。

実験

試しにどこまでいけるのか、CLK0端子を周波数カウンタに接続しながらいろいろとOSCCALを操作して動作周波数を見てみます。

OSCCALを0×00にしてみると、3.92MHz。

OSCCAL = 0x00 3.93MHz

半分の0x7fでは、8.08MHz。あれ？0xb9の時より高い？

OSCCAL = 0x7f 8.08MHz

そこで、0x8fにしてみると、6.53MHz。データシートを読んでみると、最上位ビットは高周波範囲(1)か低周波範囲(0)かの選択になっているようで、この２つの範囲は重なっており、0x7fの時の方が0×80のときより高い周波数になっているようです。

OSCCAL = 0x8f 6.53MHz

最後にもっとも大きい0xffにしてみると、12.97MHzとなりました。

OSCCAL = 0xff 12.97MHz

これほど範囲が広いのであれば無理矢理でよければ内蔵CRである程度の速度まで動かすことができそうです。

おまけ

周波数カウンタに接続したブローブをどこにもつながないと、商用電源のノイズを広うようで、60Hz近辺の周波数が表示されました。

商用電源のノイズ 60hz

ソフトウエアの場合(関数呼び出し等のオーバーヘッドは考慮しない)

データセット　クロックHi　クロックLo　がそれぞれ　8回
ラッチクロックLo　ラッチクロックHi　がそれぞれ　1回
なので、最低でも26クロックの動作時間が必要です、が、実際には関数呼び出しのオーバヘッドやif文、データのビット操作等でもっと時間がかかる(前回のプログラムの場合追加で17クロック程度)と思われます。

ハードウエア処理の場合(初期化等は除く)

SPDRレジスタへのデータセットをするだけで送信が開始されます。
送信は最速で1bitの送信に2クロックかかるので8bitで16クロック分
最後にラッチの操作で2クロック
よって20クロックで完了します。6クロックだけの差のようにみえますが、こちらはオーバーヘッド等の余分に必要な時間はないため実際にはソフトウエアよりももっと短時間でできると考えられます(実際には31クロック(約50%)の削減)。なによりコードサイズが大きくちがうはずです。

回路図

変更点はクロックとデータ線をUSCKとMOSIに移動させました。電源等は省略されています。以前利用したATtiny2313にはSPI機能が搭載されていないので手元にあったATmega88を利用しました。SPI機能を他のSPI接続のADコンバーター等と併用していても74HC595のラッチクロックがCSの代わりとして機能し、正しく個別に操作できます。

74HC595実験回路図(SPI利用)

AVRのプログラム

2010年5月15日訂正：なんと大変なことにSPCRレジスタの設定を間違えていました。
マスター動作に設定しないといけないのにスレーブになっていました。
自分で動作確認したのにいつの間にそうなってしまったのか…

#include <avr/io.h>
#include <util/delay.h>

#define SHIFT_PORT PORTB
#define SHIFT_RCK PB1

void delay_ms(uint16_t ms){
	while(ms--){
		_delay_ms(1);
	}
}

void _shift_rck(){	//ラッチクロックを一つ送信
	SHIFT_PORT &= ~(1<<SHIFT_RCK);
	SHIFT_PORT |= (1<<SHIFT_RCK);
}

void shift_out(uint8_t data){
	int8_t i;
	SPDR = data;	 //データセットで送信開始
	while(!(SPSR & (1<<SPIF)));	 //転送完了まで待機
	_shift_rck();	//ラッチを更新
}

void init_spi(){
	//SPIクロックは最速のfOSC/2
	SPCR = 0b01010000;
	SPSR = 0b00000001;
}

int main(){
	uint16_t i;
 	uint8_t t;
 	DDRB = 0b00101111;	//入出力設定(SSはSPIの動作時は出力にしておく)
 	init_spi(); 	//SPI初期設定
 	while(1){
 		//0から255までをカウントアップして出力
 		for(i=0;i<=0xff;i++){
 			shift_out(i);
 			delay_ms(30);
 		}

 		//バーを延ばしたり縮めたり
 		for(t=0;t<5;t++){
 			for(i=0;i<9;i++){
 				shift_out((0xff>>(8-(i%9))));
 				delay_ms(70);
 			}
 			for(i=0;i<9;i++){
 				shift_out((0xff>>(i%9)));
 				delay_ms(70);
 			}
 		}

 		//左右にスクロール
 		for(t=0;t<5;t++){
 			for(i=0;i<8;i++){
 				shift_out((1<<(i%8)));
 				delay_ms(70);
 			}
 			for(i=0;i<8;i++){
 				shift_out((0x80>>(i%8)));
 				delay_ms(70);
 			}
 		}

 	}
 	return 0;
}

どうですか？ソフトウエアの場合と比較してみてください。プログラムの行数では少しの削減に見えるかもしれません。ですが、前回のfor構文等を展開すると莫大な削減になっているとわかると思います。

動作実験

それでは実際に動作している映像を…と行きたいところですが、前回の映像との違いはありませんので、写真だけ載せます。

74HC595 with SPI

比較実験

コードサイズ

次のような延々とシフトレジスタにデータを送りつけるプログラムをIOポートを直接叩く方法とSPIで操作する方法のそれぞれの関数とともにコンパイルしたときのコードサイズを比較します。

uint8_t tmp;
while(1){
 	shift_out(tmp++);
}

結果、IOポートを叩く場合 188bytes、SPIを利用する場合 148bytes となり、40bytesの削減になりました。

空のプログラムをコンパイルした時のコードサイズが80bytesだったので、シフトレジスタ操作部分だけを計算すると、108bytesから68bytesと37%の削減になりました。

動作速度

先程のプログラムをそれぞれ実行し、74HC595のRCK端子に出力されるパルスの周波数、パルスの間隔を測定することにより動作速度を検証します。

今回はRCKを周波数カウンタに入力し周波数を調べました。

IOポートを叩いた時のRCK周波数(334kHz)

SPIを用いた時のRCK周波数(653kHz)

結果、I/Oポートを叩いた場合334kHz、SPIを使った場合653kHzと、ほぼ試算通り約49%の削減となりました。

ATTinyで作りたかったんですが、赤外線送信機能もつけるためにタイマーとROMのサイズの関係でATmegaを利用することに。

2009年7月9日現在設計段階です

特徴としてはモーター制御と同じ回路を用いることにより大電流を必要とするポイント(TOMIXのポイント等)の駆動や、モーター式のポイントも制御できます。

電源はレールから取ることも可能ですし、外部のACアダプターも選択できます。

ちょっと設計をミスったのでジャンパで修正しています。量産するときには修正しないと…

2線式ポイントデコーダ

仕様

• コイル、モータータイプのポイントを４つ制御可能
• CV値の設定により通電時間が選択可能
• 設定によってはc,tで方向ではなく出力のON,OFFも制御できるので車輪クリーナーのON,OFF等にも利用可能
• 電源はACアダプター、レールからのいずれかを選択可能

CV値

動作モードは0,1:一定時間通電モード、255:電源制御モードの２つから選択

一定通電モードはThrownあるいはClosedで指定された方向に設定された動作時間だけ電流を流す。ポイントの制御はこちら。通電時間は次の通り。

• モード0のとき

(動作時間CV値)*5ミリ秒　　　最大1275ミリ秒

• モード1のとき

(動作時間CV値)*100ミリ秒　　最大25.5秒

電源制御モードはThrownなら電流ON、Closedなら電流OFF。車輪クリーナー等の電源のON,OFFに使います。

• CV1　　ポイント1のポイント番号の下位バイト
• CV2　　ポイント1のポイント番号の上位バイト
• CV3　　ポイント2のポイント番号の下位バイト
• CV4　　ポイント2のポイント番号の上位バイト
• CV5　　ポイント3のポイント番号の下位バイト
• CV6　　ポイント3のポイント番号の上位バイト
• CV7　　ポイント4のポイント番号の下位バイト
• CV8　　ポイント4のポイント番号の上位バイト
• CV9　　9を書き込みでオールリセット
• CV20　 ポイント1の動作モード
• CV21　 ポイント1の動作時間
• CV22　 ポイント2の動作モード
• CV23　 ポイント2の動作時間
• CV24　 ポイント3の動作モード
• CV25　 ポイント3の動作時間
• CV26　 ポイント4の動作モード
• CV27　 ポイント4の動作時間

DCCのサービスモードについての規格はNMRA DCC StandardsのRecommended Practice RP-9.2.3 “DCC Service Mode”に書かれているのでそちらも参照してください。また、誤解している可能性があるので利用する場合は十分検証してください。

サービスモードとは、コマンドステーション等のプログラミング線路にデコーダを接続し、内部の設定(CV値)を書き換えるためのモードです。

とはいえ普通のパケットと通信規格に特別違いはないので(プリアンプル数がほんとは多い20個以上なのですが)既存のDCCパケット受信プログラムがそのまま使えます。

サービスモードへ入るには

デコーダはサービスモードパケットを電源投入後100ms以内に受信する事によってサービスモードに入ることができます。
またサービスモードはサービスモードパケット(0xffから始まるアイドルパケット等)でないパケットを受信するか、最後の受信から20ms経過したときに抜けます。

アイドルパケットを受信したらサービスモードに入ってはいけません。これを忘れると車両番号124番の列車へのパケットがDirモードのプログラミングパケットと重なるので誤動作を起こします。

ちなみにリセットパケットは全てが0×00の3バイトのパケットのことです。

またデコーダが応答する必要がある場合があります。そのときはデコーダは60mA以上の電流を6ms(+/-1ms)消費することによって応答とします。

サービスモードパケット

一般的なパケットは一バイト目にデコーダのアドレス情報がありますが、サービスパケットにはデコーダアドレスは存在しません。デコーダが受信したデータはすべてそのデコーダ向けのパケットとなります。

サービスパケットは１バイト目の上位４ビットが二進数で0111であるパケットです。

今回はいくつかプログラム方式のうちページモード(PAGE)とダイレクトモード(DIR)についてまとめます。

ページモードよりダイレクトモードのほうが簡単です。

その他には物理モード(PHYS)、アドレス設定専用モードとオペレーションモード(OPS)があります。が、物理モードは一部のCV値のみ、アドレス専用モードは名前の通りアドレスのみしかプログラミングできませんので普通は利用しないと思われます。またOPSモードはサービスモードではなく標準のパケットなのでとりあえず割愛します。

ダイレクトモード(Direct Mode)

ダイレクトモードはパケット一つだけで読み込みあるいは書き込みを行います。動作手順は次のようになります。

1. 電源投入
2. ３回以上のリセットパケット
3. ダイレクトモードパケット(誤動作防止のため同じパケットを５回以上)
4. ６回以上のリセットパケット(デコーダが処理するための時間稼ぎ)
5. 電源切断

となります。なので説明するのはプログラミングパケットだけです。ダイレクトモードパケットは次のような４バイト構成です。プリアンプルは通常よりも多く20個以上です。

0 0111CCAA 0 AAAAAAAA 0 DDDDDDDD 0 EEEEEEEE 1

• C　動作モード指定　（01でベリファイ(読み込み)、11で書き込み、10ビット操作)
• A　操作するCV値の番号
• D　書き込んだりベリファイ(一致確認)するデータの中身,ビット操作の場合その内容
• E　エラー検知用バイト

ベリファイのときは送られて来たデータとCV値が一致したときにのみ応答します。それによりコマンドステーションはCV値を読み込んだことになります。

(ビット操作については執筆中…気が向いたら（笑）)

ページモード(Paged CV Addressing)

ページモードは少し複雑でダイレクトモードのように一回ののパケットでというわけにはいきません。

ちょっと説明が大変なので執筆中….実装したコードサンプルが下にあります。

実装

実際にサービスパケット受信をC言語でAVRに実装した例です。ただ以下の例は基本のサンプルであって必要な処理をすべて満たしている訳ではありません。例えばサービスモードに入ってはいけないかどうかの確認をしていない、連続で同じパケットを受信せずに一回だけで実行してしまう点など…
しかも実際に実装する時はswitchを使わずに書いた方がプログラムサイズを小さくできます。
あくまでも参考資料という事で許してください。

ダイレクトモード(Direct Mode)

		if(size==4)
		switch(packet[0]&0xfc){
		  case 0x74: //Verify
			cv = packet[1] + ((packet[0]&0x03)<<8); //CV値番号
			//ここでデコーダが保持しているCV値とpacket[2]の内容が一致したら電流を消費し応答
			//応答　60mA以上を5から7ミリ秒消費
			break;
		  case 0x7C: //Write
			cv = packet[1] + ((packet[0]&0x03)<<8) + 1; //CV値番号」
			//ここでデコーダはpacket[2]の内容をCV値として保存処理
			//応答　60mA以上を5から7ミリ秒消費
			break;
		  case 0x78: //Bit操作
			//未対応
			break;
		}

ページモード(Paged CV Addressing)

page_r変数はグローバル

		if(size==3)
		switch(packet[0]){
			//ベリファイあるいは書き込み動作
		  case 0b01111000:
		  case 0b01111001:
		  case 0b01111010:
		  case 0b01111011:
		  case 0b01110000:
		  case 0b01110001:
		  case 0b01110010:
		  case 0b01110011:
			data_r=packet[0]&0x03; //データレジスタの内容
			rw = (packet[0]&0b00001000)>>3; //1なら書き込み、0ならベリファイ
			cv = (page_r-1)*4 + data_r+1; //CV値

			//ここでベリファイあるいは書き込み動作を行う
			//ベリファイ時の動作は上と同じ
			break;
		  case 0b01111101:
		  case 0b01110101:
			page_r=packet[1]; //ページレジスタの内容を保管
			break;
		}

また、基板サイズも大分小さくできます。ただし、LEDの駆動回路を省略しているので思いっきり明るくは光らせられません。

接続端子がまだ一部ハンダ付けされてませんが、動作確認済み。初めてダイナミック点灯をやってみました。

苦労した点

• 全ての動作とシリアル送信関数をいれるとメモリが足りないのでデバッグするのが大変だった
• シフトレジスタの操作に大変時間がかかる(20マイクロ秒以上)のでDCCパケットを割り込みで受信しないといけない
• 根本的にFLASHメモりが少ないから無駄を省くのが大変
• 最終的にぴったり100%(笑)。おかげでPAGEモードが入らなかった。
• 構造体のビットフィールドはRAMは節約できるが、ROMは圧迫される
• RAMは20byte以上残して置かないとスタック領域が不足しオーバーフローが起きる(一番わかりにくいバグ)

仕様

• ２から４灯式の信号機を16本制御
• １ブロックの端子ごとに信号機の種類を選択可能(DIRモードのプログラム対応)
• １本の信号機の点灯状態は2灯式なら1つ,3灯式なら2つ,4灯式なら3つの連続したアクセサリー番号で選択
• 電源はレールからあるいはACアダプターを選択可能

点灯パターン

例：アクセサリ番号1~3が振り当てられた信号機の点灯パターン

信号点灯パターン

CV値

動作モードは０が2灯式、1が3灯式、2が4灯式

• CV1 　アクセサリ番号下位８ビット
• CV2 　アクセサリ番号上位８ビット
• CV20　ブロックA1 – 1 動作モード
• CV21　ブロックA1 – 2 動作モード
• CV22　ブロックA2 – 1 動作モード
• CV23　ブロックA2 – 2 動作モード
• CV24　ブロックB1 – 1 動作モード
• CV25　ブロックB1 – 2 動作モード
• CV25　ブロックB2 – 1 動作モード
• CV26　ブロックB2 – 2 動作モード
• CV27　ブロックC1 – 1 動作モード
• CV28　ブロックC1 – 2 動作モード
• CV29　ブロックC2 – 1 動作モード
• CV30　ブロックC2 – 2 動作モード
• CV31　ブロックD1 – 1 動作モード
• CV32　ブロックD1 – 2 動作モード
• CV33　ブロックD2 – 1 動作モード
• CV34　ブロックD2 – 2 動作モード

動作ビデオ

鋭意制作中

タイマー１を時間(パケットのパルス幅)計測に使うためタイマー１を他の事に利用する場合は修正が必要です。

回路図

電源周りのコンデンサ等は省略しています。別途確認用のLEDやシリアルを接続して動作確認してください。
またレールとの接続はフォトカプラで電気的に絶縁することも可能です。

AVRでDCCパケットを受信

プログラム

//AVRのピン変化割り込みでDCCパケットの受信
//dcc_poll関数は割り込み専用ではないのでポーリング動作も可能
// Copyright chibiegg 2009 All rights reserved.
// http://www.chibiegg.net/
#include <avr/io.h>
#include <avr/interrupt.h>

//パケットを受信したときにコールされる関数
//割り込みの中でコールされることに注意！
//時間のかかる処理はここでフラグを立ててメインで実行することをおすすめします
void dcc_exec(uint8_t*,uint8_t){

	//ここで受信時の動作を行う

}

//ピン変化割り込み起動時の動作
ISR(PCINT_vect){
uint8_t sreg_tmp = SREG; //多重割り込みできるようにSREGの内容を退避
uint8_t bit1,bit2;
		bit1 = (PINB & 0x01);
		bit2 = 1-((PINB & 0x02)>>1);
		dcc_poll(bit1,bit2); //DCCパケット処理関数のコール
SREG = sreg_tmp; //SREGの内容を戻す
}

//メイン関数でやることは初期化だけ
//DCCパケットの受信については割り込みで全て処理される
//なので、その他の処理は時間がかかる物でもメインで自由にできます
int main(){
	//ピン変化割り込み
	PCMSK = 0x03; //レールに接続された端子のみ割り込み許可
	GIMSK = 0x20; //ピン変化割り込みの許可

	sei();//割り込み許可
	while(1){
		//何もしない
		//その他の処理が自由にできます
	}
}

//これより先DCCパケット受信用関数
//別ファイルにするほうがすっきりするかも
//その場合は
//				extern void dcc_exec(uint8_t*,uint8_t);
//と宣言しておく。

volatile uint16_t _dcc_timer=0;
uint8_t _dcc_portbefore[2]={0,0};
uint8_t _dcc_now=0,_dcc_before=0,_dcc_precount=0,_dcc_bitcount=0,_dcc_bytecount=0;
uint8_t _dcc_packet[12],_dcc_errbyte;

void _dcc_timer_start(){
	//カウンタをクリアし、計測を開始する
	TCCR1B = 0;
	TCNT1 = 0;
	TCCR1B = 0x02;
	//8分周
	//ワンカウント　0.4us@20MHz
}
uint16_t _dcc_timer_stop(){
	//タイマーを停止し計測したカウントを返す
	TCCR1B = 0;
	return TCNT1;
}

void dcc_poll(uint8_t bit1,uint8_t bit2){
	//入力変化検知
	//どちらも同じ変化の場合
	if(bit1!=_dcc_portbefore[0] && bit1==bit2){
		_dcc_portbefore[0] = bit1;
		_dcc_portbefore[1] = bit2;
	}else{
		return; //変化なしあるいは片側だけの変化
	}

	if(!bit1){	//立ち上がりエッジ
		//ビット幅計測開始
		_dcc_timer_start();
	}else{		//立ち下がりエッジ
		//計測終了
		_dcc_timer = _dcc_timer_stop();
		//ワンカウント　0.4us
		if(_dcc_timer>=110&&_dcc_timer<=200){ //ビット1  55us - 61us
			_dcc_now=1;//今処理しているビットの種類「１」(以降の処理で利用するため)
			_dcc_precount++; //プリアンプル数計測用
			//現在受信しているバイトにデータを追加
			_dcc_packet[_dcc_bytecount]=(_dcc_packet[_dcc_bytecount]<<1)+1;
		}else if(_dcc_timer>=225&&_dcc_timer<=25000){ //ビット0 95us - 9900us
			_dcc_now=0;//今処理しているビットの種類「０」(以降の処理で利用するため)
			if(_dcc_precount>=14){ //スタートビット(１４回以上の「１」の後の「０」)
				//変数たちを初期化
				_dcc_bitcount=1;
				_dcc_packet[0]=0;
				_dcc_bytecount=0;
				_dcc_errbyte=0;
				_dcc_precount=0;
				return;
			}
			_dcc_precount=0;//プリアンプル数計測リセット
			//現在受信しているバイトにデータを追加
			_dcc_packet[_dcc_bytecount]=(_dcc_packet[_dcc_bytecount]<<1);
		}else{return;} //規格外の長さ

		if(_dcc_bytecount>=10){	return;}//今受信しているパケットを無視する場合
		_dcc_bitcount++;
		if(_dcc_bitcount==1){
			if(_dcc_now==1){//ストップビット
				if(_dcc_bytecount!=10){ //無視する予定のパケットで無い場合
					//ここでエラーバイトの確認し、実際の動作にうつる
					if(_dcc_errbyte==0){
						dcc_exec(_dcc_packet,_dcc_bytecount); //受信完了時の関数のコール
					}
					_dcc_bytecount=10; //エラーバイトが一致しないので今回のパケットは無視
				}
			}
		}
		if(_dcc_bitcount==9){//バイトの終わり
			//今受信が終わったバイトが一バイト目で0xffならアイドルパケットなので
			//今受信しているパケットは無視する(_dcc_bytecountを10にすることにより無視化)
			if(_dcc_bytecount==0&&_dcc_packet[0]==0xff){_dcc_bytecount=10;return;}
			_dcc_errbyte^=_dcc_packet[_dcc_bytecount]; //エラーバイト比較用の計算
			_dcc_bitcount=0;
			_dcc_bytecount++;
		}

	}
}

説明

ピン変化割り込みによってDCCパケット解析(dcc_poll)関数を呼び出します。
この関数では立ち上がりエッジから立ち下がりエッジまでのパルス幅を計測し、立ち下がりエッジで計測が終わるごとに、プリアンプル部の検出、バイトの受信等の処理を行います。
さらに、ストップビットを受信し、エラーバイトとの比較も一致すると、dcc_exec関数をパケットのバイト列へのポインタとパケットのバイト数を引数としてコールします。
実際にDCCパケットについて処理したい内容はこのdcc_exec関数に記述することによって実現できます。
ただし、dcc_exec関数は割り込みの動作中でコールされるので、長い時間のかかる処理などはできません。そのような処理が必要であればこの関数でフラグを立ててメインのスレッドで処理をするべきです。

ちなみに、dcc_poll関数さえ遅滞なくコールできるのであればピン変化割り込みを利用しなくてもポーリング動作させることができます。

原因は以前の記事にも書きましたがMacおよびVistaはシリアルの通信速度がLocoNetの16600bpsに対応していないというのが原因です。

そこで、USB（パソコン)側とLocoNetの間にマイコンを挟み、そいつで速度変換をさせることによってMacおよびVistaに対応させたLocoUSB Ver.2を開発しました。

LocoUSB Ver.2

以前の予告ではRev.2を予告しましたがそのときは機能面の変化はないだろうと思っていたからです。が、機能的に大幅な追加がでたためVer.2としました。

思想はいたって簡単で、以前のLocoUSB Rev.1のFT232RLとLocoNetの間にAVRを挟んだだけです。

機能的にはたぶんLocoBufferと同じだろうと思われるのですが（実物を持っていないのでわかりません）、JMRIの設定ではLocoBufferを選択することで利用できます。LocoBufferと同じく19200bpsと57600bpsの両方に対応しています。

当方ではMacOSX LeopardとLocoNetを接続できました。

ソフトウエアの動作検証がしっかりできればこのサイトで頒布できればなぁ、と思っています。在庫も2つ余分にあるので…

追記：友人等とサークルを作ることになったのでそちらで運営する予定の通販サイトで頒布するよていです。開店時にはこのサイトで紹介します。

バンダイの車両を短くデフォルメしたBトレインショーティーというシリーズがあるのですが、それをNゲージで走らせるための動力ユニットにデコーダを搭載しようとおもいます。

急行電車1 DCC加工済

加工後の写真がこちらです、少し中の配線が見えています。デコーダがユニットの内部に収まるように努力しました。

インターネットでは、内部に収めている加工を見つけることができなかったので適当に試行錯誤しながらやってみました。

随１　急行電車1 分解(1)

まず分解していきます。

白いカバーを外し、モーターを取り外した状態が図１です。

図２　急行電車1 分解(2)

そして、真ん中のプリント基板および、集電板とモーターへの金属板も取り外したものが、図２です。

このプリント基板の代わりにDCCデコーダEM13を載せるイメージで進めます。

デコーダEM13の加工

次に、デコーダを加工していきます。今回はできるだけコンパクトにする必要があるため足は全てカットしました。

そして幅もできるだけ小さくなるようにヤスリで少しずつ削っていきます。

このときどんなにがんばっても動力ユニットのプリント基板より幅を小さくすることはできないため、デコーダのプリントパターンの配線を削り落としてしまわないぎりぎりまで丁寧に削ります。

このときレール側のプリントパターンは削ってもかまいません。

モーターへの配線は写真を参考にハンダ付けしてください。黒と紫のケーブルです。

デコーダを載せる

次に加工したデコーダを載せますが、その前に集電板を元に戻します。このときクッション付きの分厚めの両面テープを真ん中に貼り、集電板を浮き上がらせます。

そうすることによってデコーダのレール側電極と接触させます。

また、駆動輪側近くのプリント基板を固定するための出っ張りも削ります。

少しきついですがデコーダを写真のようにはめます。

モーターの取り付け

最後にモーターへ配線をハンダ付けし、元に戻していきます。

ただそのまま戻すと駆動軸がデコーダのICに接触するため少しクッションを挟みモーターを持ち上げることと、モーターの周りをビニールで囲み絶縁しました。

最後に、白いカバーを戻せば完成です。ただ、白いカバーの真ん中の爪をしっかりはめるように押し付けると軸と接触し回らないため両端だけで固定しています。

見た目を考えてこのままにするか、しっかり止めるために天井をくりぬくのもよいかもしれません。

ただすごく狭いので集電もしっかりできるように搭載するのは大変です。なんどか集電板の位置を微調整し、白いカバーの出っ張りを削ってみたり、細かな加工が必要です。