全力でダイナミックスキャン！

○横INNで貰った時計の水晶発振子は見事に32.768KHz。
32.868KHzはTimer1の65536分周では1/2HzになるのでTimer1のソースにすると秒単位の計時ができない。外部回路なしで256分周で使えるTimer0に32.768を入れるためにはCPUクロックを32.768KHzにしなければならない。
32.768KHzで動作させてみたものの、このCPU速度では、全力でダイナミックスキャンしてもちらつきます。ちらつくというより、数字が流れるのが見えます(笑)

というわけで、32.768KHzのCPU速度でのLEDダイナミックスキャン型のデジタル時計は無理と判断。PIC二つ構成で、一つを計時用、もう一つを表示用にすればできるな。でも、これ以上このクロックは追求しないようにします。

時計を分解

先週出張に行ったときに泊まった某ビジネスホテルチェーンのインターネット予約特典でもらった時計があったので分解した。それらしい水晶発振子を発見。これは32.768KHzじゃないか？早速組み込んでみよう。

水晶の精度が大きく疑問ではあるが・・・

完成

割り込みルーチンを修正。３時間くらい動かしているけどNTT時報にぴったり。これで完成でいいか。

回路図、ソース、バイナリ

遅れ対策

TMR1L TMR1Hレジスタ書き換えでプリスケーラーがリセットされるのが問題なら、60K/4M=66クロック以内にTMR1L/TMR1Hレジスタを再設定すれば良さそう。(533クロックの余裕はない)

現状LEDのダイナミックスキャンをTMR0割り込みでやっている。Simulator Traceで測定したところ、割り込みルーチンの所用クロックはおよそ85だった。TMR1割込発生後、カウンタをリセットするまでは数クロックでできるが、TMR0を契機にした割り込みが発生している間にTMR1が発生した場合、割り込み禁止状態なので、60KHz周期内にレジスタ書き換えを完了できないことになる。

割り込みルーチン内のダイナミックスキャン部分でも割り込みを有効にして対応しよう。再入防止はフラグで制御を予定。

時計できた

けど遅れる
エミュレーターで実験したらTMR1レジスタ書き込みでプリスケーラーがリセットされるっぽい。

このままだと正確に計時できないな。

補正を入れる(邪道)
60KHzをメインクロックにして256カウントのTimer0で処理(処理おいつくか)
もっと速いクロックにする

どれにしょう＾＾；

明るさ比較

アノードコモン側をドライブする2SA1015のベースの抵抗は470Ω(ベース電流10mA)にした。左から4.7k/1k/470/220。1Kは許せる程度の明るさだが470と並べると暗い感じ。470と220はほとんどかわらなかった。

一応時計にはなった

時刻合わせ機能がないが、ブレッドボード上で分秒を(本当は時分だけど、時分だと１分待たないと動きが見えないので)7セグに表示するまでになった。7セグが暗い。LEDが二つしか点灯しない1はまあいい。他は暗い。ベースに入れいている抵抗を調整してみよう。

左上のLEDは通電表示、右上のLEDは割り込み動作確認用に1秒点滅。

LEDのセグメントドライブ側の電流考

(以下大間違い)
7セグのコモン側をきちんとスキャンして一つだけの7セグにだけ電流がながれていっれば問題ないのだが、複数の７セグLEDを同時にアクティブにしてしまった場合、カソード側のシンクになるポートにLED4本分の電流が流れ込むことに気が付いた。このとき、最大40mAとなり最大定格(25mA)を大きく超える。

開発中の安全のため、各LEDに流れる電流を最大6.25mAに制限するか思案中。ソフト的に間違えなければ破壊しないはずなんだが・・・
(5V-1.7V-0.1)/0.00625=512Ω (-0.1されてるのは2SA1015の電圧降下)
抵抗E12系列680Ωで4.7mA、E24系列560Ωで5.7mAそれをダイナミックスキャンは暗いか？


ブレッドボードで実験してみるか。

ブレッドボードで実験というか回路図をちゃんと書いてみて解った。カソード側は結線されて一つの制限抵抗を介してPICにはいる。プログラムミスで複数点灯させてしまったとしても、PICに流れ込む電流は変わらない。上で書いたことは全くの間違い。よって制限抵抗は予定通り330ΩでOK。

PICに手を出してしまい・・・

PICライターとPIC12F629(練習用)、PIC16F818を購入。まずは簡単なところでデジタル時計作成を視野にPICプログラミング研究中。いままでわかったこと。

７セグ表示：
8080時代のマイコンよろしくダイナミック表示にせざるをえまい。この方式、中学生の頃見たときはなんて面倒なことするのだと驚いていたのだが(キーボードマトリクスもね)、長生きしていろいろな物を見てきたおかげで、まあ普通じゃんって感じです(笑)

LEDに10mAを流した場合、コモン側は最大70mAになる。PIC16F818のPORTA, PORTBのソース・シンク最大電流(Maximum current sunk/sourced by PORTA/B) 100mAには余裕があり、トランジスタ等ははさまなくて済む。100mAは各ポートの合計のようだ。Maximum output current sourced by any I/O pin = 25mA なので無理。要増幅。

7セグLEDはGL9A040Gを購入。
VF=1.7(TYP) IF=10mA
電源電圧5Vより、制限抵抗=(5.0V-1.7V)*0.010A=330Ω

計時：

当初はAKI-H8 3048Fでコントロールした実績があるRTCモジュールを使う予定だったが、200円のPICに500円のRTC？と疑問になり、RTCは使わない方向に。

PICのデータシートにかかれているように、32.768KHzのクリスタルを使えば簡単だが(タイマー割り込みの整数倍が１秒になる)、なかなか安く手に入らない。

そこで60KHzのクリスタルを購入(100円＠秋月)。これを非同期カウンタで入力し、割り込み毎にタイマーレジスタを調整する方式とする。

PIC自体は内蔵オシレーターで4MHz動作させる。
クリスタル発振60KHzをプリスケーラで1/8分周して7500Hzで使う。
4MHz動作のコアからみた7500Hzは非常に遅い。
CPUの533クロック(4000000÷7500=533.333…)で非同期カウンタが１進む。
タイマーレジスタオーバーフローの割り込みから非同期カウンタが1進む前にタイマーレジスタを再設定すればレジスタ書き換えの遅延の影響をうけずに計時できる。
533クロックあれば大余裕。
割り込み毎のタイマーレジスタの初期値は 65536-7500=58036=0xE2b4

クリスタルに付けるコンデンサの容量：
Capacitive Loading Specs on Output Pins: OSC2 15pF
60KHzクリスタルの負荷容量 12.5pF (秋月のホームページ)
外付けコンデンサなしでいけるってことかな。むしろ容量減らしたいくらい。直列に75pFでもつないだほうがいいのかな。
実際、コンデンサ付けずにOSC1/OSC2にクリスタルをつないだだけで発振してる。
コンデンサなしでよさげ。

PIC書き込み

PICも面白そう

AKI-4038Fのマザーボードから12V、5Vを供給、適当なデータ線2本をブレッドボードに接続すればPICライターになるかな

開発環境更新

h8300-hws-ldの-mrelaxの件があったので開発環境を更新してみた。
binutils, newlibは現時点の最新版。gccは3.xの最終版を採用。cygwin上でコンパイル&インストール。あたらしめのbinutilsはh8300-hwsに対応していないがターゲットを h8300-elf にすれば問題なし。

binutils-2.18.tar.gz
configure --prefix=/usr/local/h8300-elf --target=h8300-elf

gcc-3.4.6.tar.gz
configure --prefix=/usr/local/h8300-elf --target=h8300-elf --with-newlib --enable-languages=c

newlib-1.16.0.tar.gz
configure --target=h8300-elf --prefix=/usr/local/h8300-elf


Makefileの h8300-hws-* のコマンドを h8300-elf-* に置換
リンカスクリプトのOUTPUT_FORMATを変更する
OUTPUT_FORMAT("elf32-h8300")

モニター＋htermを使う場合S Record形式にする必要がなくなった
ldの出力を .abs のファイル名にしてそのまま hterm で転送可
HPWでビルドしたときと同様、ソースを表示するかと言われるものの、CPUタイプが違うといわれてソースレベルのデバッグはできていない。

i2c

RTC8564が応答するようになった。ところがこれ、秒までしか返さない(そういう仕様)。タイマーカウンタを使えばもっと精度が出せそうだからそのうち工夫してみよう。

i2cを使う ダウンロード(gz)


RTCがうごいたのでEEPROMもボードに搭載。ところがスレーブアドレスが見事にバッティング。RTC8564は B'1010001*、AT24C1024は B'10100AP*。AはA1ラインH/Lに一致、Pはアドレス指定の最上位ビットで使う。AT24C1024のA1ラインの説明では、If the A1 pin is left floating, the A1 pin will be internally pulled down to GND. とあるので未接続で浮かせていたのだった。このままではA=0なのでP=0のときRTC8564と同じスレーブアドレスになってしまう。I2Cデバイスのスレーブアドレス空間って、128弱なので「こんなので足りるのかな～」と漠然と考えていたけど、自分で買ってきたたった二つのデバイスが見事にバッティングするとは思わなかった。まあ、ATC24C1024のA1をHにすればB'101001P*になるので回避できますがね。半田ごて取り出して追加配線。

一応、ジャンパピンつけてA1を浮かせることができるようにもしておいた。以下回路図。

H8 GNU LD -mrelax が変

暴走する～とおもったらリンク時 -mrelax を付けると相対ジャンプ(BNE等)のオフセットがずれることがあるようだ。原因不明だが-mrelaxを外して対処。

こういことがあるとソースから開発環境を作りたくなる。そういえばldで未解決の参照があってもエラーを出さないことがある。@付きでオペランドに指定した場合かな(条件未精査)。これは仕様かもしれないがこのへんも気に入らない。シンボル名のtypoがトレースかけるまで発見できないのはつらいわ。


オフセット異常の例

ソース

a:
		
		; SDA => 0/1
		shal.b	r0l
		bst		#I2C_BIT_SDA, r1l
		mov.b	r1l, @_I2C_DR
		_NOP_nSEC 1300			; tLOW
		
		; SCL 0 => 1
		bset	#I2C_BIT_SCL, r1l
		mov.b	r1l, @_I2C_DR
		_NOP_nSEC 600			; tHIGH

		; SCL 1 => 0
		bclr		#I2C_BIT_SCL, r1l
		mov.b	r1l, @_I2C_DR

		dec.b	r2l
		bne		a

-mrelax なしでリンク。
最後のBNEの飛び先はFF28EのSHAL命令のアドレスになる=>OK

  FF28E   1088                  SHAL.B     R0L
  FF290   6729                  BST        #2:3,R1L
  FF292   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF298   0000                  NOP        
  FF29A   0000                  NOP        
                     
  FF29C   0000                  NOP        
  FF29E   0000                  NOP        
  FF2A0   0000                  NOP        
  FF2A2   0000                  NOP        
  FF2A4   7039                  BSET       #3:3,R1L
  FF2A6   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF2AC   0000                  NOP        
  FF2AE   0000                  NOP        
  FF2B0   0000                  NOP        
  FF2B2   7239                  BCLR       #3:3,R1L
  FF2B4   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF2BA   1A0A                  DEC.B      R2L
  FF2BC   46D0                  BNE        FF28E:8

-mrelax を付けたときの逆アセンブル。
最後のBNEの飛び先はFF286。MOV命令のオペランド内 => NG

  FF280   1088                  SHAL.B     R0L
  FF282   6729                  BST        #2:3,R1L
  FF284   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF28A   0000                  NOP        
  FF28C   0000                  NOP        
  FF28E   0000                  NOP        
  FF290   0000                  NOP        
  FF292   0000                  NOP        
  FF294   0000                  NOP        
  FF296   7039                  BSET       #3:3,R1L
  FF298   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF29E   0000                  NOP        
  FF2A0   0000                  NOP        
  FF2A2   0000                  NOP        
  FF2A4   7239                  BCLR       #3:3,R1L
  FF2A6   6AA9000FFFC6          MOV.B      R1L,@H'FFFC6:24
  FF2AC   1A0A                  DEC.B      R2L
  FF2AE   46D6                  BNE        FF286:8

GNU assembler 2.14
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `h8300-hms'.

GNU ld version 2.14 20030612
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

3069 NET

メモリーチェックは無事通過

BUSYハンドシェイクとか

BUSYハンドシェイク版LCDライブラリを書いてみた。はるかに速い。主観でいうとブロードバンドとパソコン通信ほどの差がある。

SRAM増設にチャレンジ：SOP 28pinをDIP28に変換するサブボードを作るってSRAMを乗せ、それをH8 I/O基板に配置する計画。ハーフピッチのユニバーサル基板にSOP 28pinのSRAMを半田付け。スズメッキ線ピン間をつなごうとして、SRAM全PINからスズメッキ線を立ち上げるところまではいけた。でも、それをDIPピッチのピンに持っていくところで配線が接触の恐れ有り。熱収縮チューブもないし被覆付きで配線し直す気力もない。一時中断。これ無理。被覆はがすのがめんどくさくて裸線なんかにしたのが敗因。熱収縮チューブの調達 OR サンハヤトのシール基板調達待ちとなった。

I2Cの動作確認：秋月のRTC-8564NBをつないでみた。コネクタ増設するのが面倒なのでLCDのポートに繋がるようにLCDみたいな形状のボードを製作。



これは1PIN-のLCDコネクタ配置です

アドレス書き込みに対してACKが帰ってくるところまでコーディングしてみた。見知らぬデバイスが応答してくれるとうれしいね。

1MのEEPROM AT24C1024 も用意してあるので、RTCを把握したらAT24C1024をいじる予定。

そうこうしているところに交換品の3069F NET到着。RAMチェックせねば。

3048をひっぱりだし

3069返送中。オモチャがなくなってしまった。しょうがないから開発環境の整備＆基礎的なライブラリでも作っておくかと3048Fを引っ張り出してきた。

まずはLCD周りのチューニングを始めたのだが、タイミングチャート通りにやっても正常に動作しない。おもいっきりウェイトかければ動くのだが遅い。

BUSYフラグを見ていないのがいけないようだ。サンプルプログラムでは、BUSYフラグを見ていない分、追加のウェイトをかけている。

データシートのタイミングチャートは、BUSYフラグをみて、BUSYじゃないことを確認した上での流れだった。AKI-H8 3048FのI/Oボードのデフォルトでは、RW端子がプルダウンされていて制御できないからLCDモジュールからの読み出しが出来ない仕組み。暇だし、LCDの5PINをCN3の13番につないだ。これでP36がR/W信号になって制御できるぞ。

開発環境的には定番のgcc+cygwinをダウンロードしてインストール。crt0と隣家スクリプトを作って、当面使うポートだけ(手抜き)定義しといた。

CRT0はこれだけ(笑)

		.h8300h
		.section .text

		.global _start
_start:	
		jsr	@_main
		
		sleep

リンカスクリプト(aki-h8-3048f.x)

OUTPUT_FORMAT("coff-h8300")
OUTPUT_ARCH(h8300h)
ENTRY("_start")

MEMORY {
	ram(rwx) : o = 0x00ff100, l = 0x00ff2ff
}

INCLUDE "3048f.x"
	
SECTIONS {
	.text : {
		*(.text)
		*(.strings)
		*(.rodata)
		_etext = .;
	} > ram
	
	_LCD_DDR	= _P3DDR;
	_LCD_DR		= _P3DR;

	_LED_DDR	= _P5DDR;
	_LED_DR		= _P5DR;

}

リンカスクリプト(3048f.x)

	_P1DDR	= 0xfffc0;
	_P2DDR	= 0xfffc1;
	_P1DR	= 0xfffc2;
	_P2DR	= 0xfffc3;
	_P3DDR	= 0xfffc4;
	_P4DDR	= 0xfffc5;
	_P3DR	= 0xfffc6;
	_P4DR	= 0xfffc7;
	_P5DDR	= 0xfffc8;
	_P6DDR	= 0xfffc9;
	_P5DR	= 0xfffca;
	_P6DR	= 0xfffcb;