090123

DRO試作一号機のソフトをホスト、クライアントともに更新。ソースの切り分け に手間がかかってしまった。もう既にターゲットがAKI-H8 M/B(aki)、DRO 試作 一号機(dro01)、DRO試作二号機(dro02)、開発機(ud01)、8KBに収まる開発機用 (ud01_minkernel)と、色々あるのでちょっとまじめにやらないと破綻します。
既にコンパイルオプションが破綻気味。

THREAD_DISABLE
スレッド機能なし。
BUFFERD_CONSOLE_DISABLE
バッファコンソールなし。これはスレッド機能が必要。
SHELL_DISABLE
シェルなし。
PROMPT_BUFFER_SIZE	32
プロンプトバッファの最大入力
PROMPT_HISTORY_CONF	2
ヒストリの最大数。1 << PROMPT_HISTORY_CONFになる。
PROMPT			">"
プロンプト。
SHELL_CMDARG_MAX	4
シェルコマンドの最大引数。
THREAD_STACKSIZE_DEFAULT	512
スレッドのスタックサイズのデフォルト。ほとんどこれを参照している。
THREAD_PRIORITY_MAX	4
プライオリティの数。増減するにはまだ要改造。

SCI_FIFO_SIZE		32
スレッド間のリングバッファ及び、割りこみハンドラ間のリングバッファのサイズ。
SCI_STACK_SIZE		THREAD_STACKSIZE_DEFAULT
受信、送信スレッドのスタックサイズ。
SCI_SPEED_BRR
ボードレートを直指定。

CALIPER_SHELL_COMMAND
ノギス用のシェルコマンドを有効にする。

LCD_DISABLE
ボード内蔵LCDモジュールを無効にする。

なんとか終了。レスポンスは以前のよりあがってます。しかしいずれこれも7セグLED にしたい。テカって見にくいんだ。

DRO試作一号機の新しいソフトでは、Tcl/Tkのクライアントから直接シリアルでシェル コマンドを呼ぶことにしました。

    puts $fd [format "caliper_power %d" $axis];
    if {[catch {flush $fd}]} {
	puts "I/O error $fd"
    }

こんな感じで。ここで問題にあたった。H8のSCIでとりこめないのだ。SCIは FIFOがないので、ストップビットまできたら割り込みが入る。115200bpsだと 1/115200*10秒(10=8bit+start+stop)、87usecごとに割り込みが入ってしまう。 これは無理。割り込み突入だけで10-30usecかかるのに。DMA連携はSCI0だけな ので使えない。
ので、割りこみハンドラと割りこみスレッドのあいだにもリングバッファを入 れました。

できる限り早くデータをとって次がとりこめるようにします。時間的に余裕がないので
この割りこみではスケジューリングの変更をしません。

	.globl _sci1_rxi
_sci1_rxi:
	mov.l	er0, @-sp
	mov.b	@0xbd:8, r0l	; r0l = *SCI1_RDR
	bclr	#6,@0xbc:8	; *SCI1_SSR &= ~SSR_RDRF
	mov.l	er1, @-sp
	mov.l	er2, @-sp
	mov.l	er3, @-sp
	jsr	@_c_sci1_rxi	; c_sci_rxi (r0l)
	mov.l	@sp+,er3
	mov.l	@sp+,er2
	mov.l	@sp+,er1
	mov.l	@sp+,er0
	rte

void
c_sci1_rxi (uint8_t c)
{

  if (rbuf_nolock_write (ibuf, &c, 1) != 1) これは割り込み用でロックしません。
    {
      iprintf ("overflow\n");
    }

  受信スレッドの起床をタイマでとっておきます。
  timer_schedule_func ((void (*)(void *))thread_wakeup_once, sci_recv.th, 2170);
}
/*
  1/115200 1bit.
  1/115200*10 (8bit + start bit + stop bit) = .0000868 sec. (86.8usec)
  86.8 * 8 = 694usec (8byte)

  694/0.32 = 2170 (0.32us: 25MHz/8)
 */

694usec以降に割り込みスレッドが起動されることで、それまでに8byteはバッ
ファにたまることを期待しています。これで受信スレッドの起床回数を減らし
てとりこぼしを減らそうという目論見。

これでなんとか大丈夫になりました。延々と流しこまれるとだめだけど、それ はもうハード的に限界なので、そういう時は明示的にポーリングして受けるし かないね。

named[2041]: client 63.217.28.226#32575: query (cache) './NS/IN' denied

がひどいです...。http://isc1.sans.org/dnstest.htmlで.を外部から再帰クエ リしにいかないかテストできます。