忍者ブログ
ちょっとは人のためになる事をしないとインターネットコミュニティーの皆様に申し訳がないかと思いながら、自分の備忘録ていどでしかなく、実際の所たいした情報も提供できないでいるブログ
[1] [2] [3] [4] [5]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

○横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二つ構成で、一つを計時用、もう一つを表示用にすればできるな。でも、これ以上このクロックは追求しないようにします。
PR
先週出張に行ったときに泊まった某ビジネスホテルチェーンのインターネット予約特典でもらった時計があったので分解した。それらしい水晶発振子を発見。これは32.768KHzじゃないか?早速組み込んでみよう。

水晶の精度が大きく疑問ではあるが・・・
割り込みルーチンを修正。3時間くらい動かしているけど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はほとんどかわらなかった。
時刻合わせ機能がないが、ブレッドボード上で分秒を(本当は時分だけど、時分だと1分待たないと動きが見えないので)7セグに表示するまでになった。7セグが暗い。LEDが二つしか点灯しない1はまあいい。他は暗い。ベースに入れいている抵抗を調整してみよう。

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

(以下大間違い)
7セグのコモン側をきちんとスキャンして一つだけの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ライターとPIC12F629(練習用)、PIC16F818を購入。まずは簡単なところでデジタル時計作成を視野にPICプログラミング研究中。いままでわかったこと。

7セグ表示:
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のクリスタルを使えば簡単だが(タイマー割り込みの整数倍が1秒になる)、なかなか安く手に入らない。

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

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

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

暴走する~とおもったらリンク時 -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.

メモリーチェックは無事通過
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チェックせねば。
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;



忍者ブログ [PR]
カレンダー
02 2024/03 04
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
フリーエリア
最新CM
[02/07 @naoshi65536]
[02/07 忍]
[09/18 とおりすがり]
[06/26 ilmare]
[03/16 とおりすがり]
最新TB
プロフィール
HN:
naoshi
性別:
男性
職業:
ソフトウェア技術者
趣味:
料理
自己紹介:
@naoshi65536 で連絡がつくはずです。
バーコード
ブログ内検索
カウンター
アクセス解析
FX NEWS

-外国為替-