今日のIchigoJam

IchigoJam-DDS with PTT。
周波数ステップは1KHz、Kで＋Lで－。
PでPTT-ON（455KHzダウン）、OでPTT-OFF（455KHzアップ）。
元のデータが初期値7000KHzのままなので、PTT押すと6545KHzになるはず。

10 'DDS-PTT
500 CLS:A=0:B=5079:C=8010
501 OUT4,1:OUT4,0:OUT2,1:OUT2,0:OUT3,1:OUT3,0:OUT5,0
502 K=7000:L=0
506 GOSUB2000
510 D=INKEY():IFD=0GOTO510
535 IFD=80GOSUB1500:GOSUB2000
540 IFD=75GOSUB1100:GOSUB2000
545 IFD=76GOSUB1600:GOSUB2000
550 GOTO 510
1100 IFC<8868C=C+23900
1110 IFC>8867ANDB<32767B=B+1
1120 IFC>8867ANDB>=32767A=A+1:B=0
1130 IFC>8867C=C-8867
1140 K=K+1
1150 RETURN
1500 X=A:Y=B:Z=C
1501 IFC>=28291C=C-28291
1510 IFC<28291ANDB>1B=B-1
1520 IFC<28291ANDB<1A=A-1:B=32767
1540 B=B-331
1550 GOSUB2007:OUT5,1:LED1
1555 A=X:B=Y:C=Z
1560 D=INKEY():IFD<>79GOTO1560
1570 OUT5,0:LED0:GOSUB2007:RETURN
1600 IFC>=23900C=C-23900
1610 IFC<23900ANDB>1B=B-1
1620 IFC<23900ANDB<1A=A-1:B=32767
1640 IFK>0K=K-1
1660 RETURN
2000 LOCATE0,0:?K;".";L/10;L%10
2007 OUT3,0:OUT2,0
2010 M=C:I=15:GOSUB3000
2011 M=B:I=15:GOSUB3000
2012 M=A:I=2:GOSUB3000
2013 M=1:I=8:GOSUB3000
2015 OUT3,1:OUT3,0
2020 RETURN
3000 FORJ=1TOI:OUT1,0
3020 IFM&1=1OUT1,1
3030 OUT2,1:OUT2,0:M=M>>1:NEXT:RETURN

96バイトの空き。

IchigoJam本体のストレージは四つあって、FILE0に保存すると起動時に自動的に読み込んでRUNするので、こいつをSAVE0しておけばよい。PC側のターミナルでコピペでも良い。

LCD表示はIchigoJamのシリアル通信機能を使ってもう一台のIchigoJam(SLAVE)に行わせればいけそうだ。表示プログラムもFILE0に書き込んでおけばいいだろう。DDS制御側（HOST）では冒頭にWAITをかける必要があるだろう。

通常PRINT出力はVIDEOとともにシリアルポートにも出力されるので、現在の単体での表示を改め、UPなら1，DOWNなら-1を表示する。これはシリアルポートにも出力されるので、SLAVEはINPUT文で受信し、起動時周波数7000KHzに加算してLCDを駆動する。

RXDとTXDを双方向に結線しておいて、SLAVEからACKが返るまでHOSTが待機するのが表示と実周波数のトラッキングエラーをなくす方法だが、HOSTが±1を表示してからDDSにデータを送ってやれば必要なさそうな気もする。

つまりDDSの周波数を変えるための40bitのデータ送信に時間がかかるのである。

とまぁ、ここまではすべて思考実験。週末にDDSとIchigoJam Uを入手するつもり。

なんとかなるかな？

今日のIchigoJam

IchigoJam一台で表示とDDSの制御を行うのは無理っぽいなぁ…
これはIchigiJam二台でDDS制御と表示に分けるしかないかなぁ？

諦めてAVRとかに切り替えるか…

今日のIchigoJam

まだ思考実験の段階だけど、先に紹介したLCDドライブサブルーチンを含んだ、サインスマートＡＤ９８５１使用ＤＤＳモジュールコントロールプログラム。容量の関係で1行8文字表示のみ。

現状ではビデオ出力をONにしたままだけど、これはOFFにした場合LCDに正常に表示できるかどうか不明なためで、もし可能ならビデオ出力はOFFにしたい。

変数の説明

A,B,C:AD9851に送るデータ
D:入力キー
K,L:表示用周波数カウンタ
M,I:サブルーチン渡しビットデータ、カウンタ
J:ビットデータ出力用カウンタ

キー入力は"O"と"P"をINKEY()で処理する様になってるけど、これはin(n)に変更予定。そうしないと組み込み用途にならないからね。


10 'DDS-LCD
500 A=0:B=5079:C=8010:CLS
501 OUT4,1:OUT4,0:OUT2,1:OUT2,0:OUT3,1:OUT3,0
502 K=7000:L=0
505 GOSUB2000:GOSUB800
510 D=INKEY():IF D=0 THEN GOTO 510
530 IFD=79GOSUB1000:GOSUB2000:GOTO510
535 IFD=80GOSUB1500:GOSUB2000:GOTO 510
550 GOTO510
800 POKE#700,64,0,2,#C0,57,17,#70,86,#6C,56,12
820 IFI2CW(62,#701,1,#704,5)?"E"
830 WAIT12
840 IFI2CW(62,#701,1,#709,2)?"E"
900 IFI2CW(62,#701,1,#702,1)+I2CW(62,#700,1,#900,8)?"E"
910 RETURN
1000 IFC<32527C=C+239
1010 IFC>32528ANDB<32767B=B+1
1020 IFC>32528ANDB>=32767A=A+1:B=0
1030 IFC>32528C=C-32528
1040 L=L+1:IFL>99K=K+1:L=0
1050 RETURN
1500 IFC>=239C=C-239
1510 IFC<239ANDB>1B=B-1
1520 IFC<239ANDB<1A=A-1:B=32767
1540 IFL>0L=L-1:RETURN
1550 IFL=0K=K-1:L=99
1560 RETURN
2000 LOCATE0,0:?K;".";L/10;L%10
2007 OUT3,0:OUT2,0
2010 M=C:I=15:GOSUB3000
2011 M=B:I=15:GOSUB3000
2012 M=A:I=2:GOSUB3000
2013 M=1:I=8:GOSUB3000
2015 OUT3,1:OUT3,0
2017 GOSUB900
2020 RETURN
3000 FORJ=1TOI:OUT1,0
3020 IFM&1=1OUT1,1
3030 OUT2,1:OUT2,0:M=M>>1:NEXT:RETURN
OK

だいぶ切りつめたんだけど、ここまでスペースを切りつめてまともに動くのかどうか？一応Syntax Errorは出てないようだけど…

空きが100バイトを切ってるので、現状では10Hz単位での+/-のみ。本当はキーを四つ付けて1KHzの+/-も付ける予定だったけど、LCDドライブサブルーチンを削らないとだめっぽい。おまけに送受信で455KHzか10.7MHzのオフセットを付けるのも無理っぽい。

符号付き16bit整数しか扱えないという制約から、1stepを10Hzと決めうちしたカウンターを別に用意。15bitの整数を10進数に変換するのを諦めました。

ここまでやって『やっぱり1KBじゃ無理でした』と認めるのも癪だなぁ。

今日のIchigoJam

イチゴジャムっつってもパンやクラッカーにのせるジャムじゃない。
ARMのBASICマシン。

入出力ポートがあるのでいろいろと使いみちが広がる。
昔ならPC-1255でマシン語を使ってやると所なんだけど、すでに鬼籍に入ってしまった。PC-1360Kは11ピンポートの使い方が今ひとつわからない。PC-1490UⅡはマシン語がわからない。

んでIchigoJamで遊ぼうかと。

今の所LCDディスプレイを繋いでモバイルIchigoJamができるらしいことは掴んでる。でもそこまでしなくてもI2Cで8桁x2のLCDを駆動できることもわかってる。

そして秋月のDDSがある。
これはシリアルでデータをセットできる。

I2CのLCD、DDSを繋いでも押ボタンを4つ使えそうだ。
つまりARMを直接使わないでIchigoJamでDDSを制御できないかな？ということ。1KBというプログラムの容量制限内でできるだろうか？±32767という整数の範囲も曲者だ。

でもちょっと面白そう。中期計画でやってみようかな。

今日のIchigoJam

BASICマシンのIchigoJamでCW用のキーヤーを作ってみました。

英語キーボードからの入力で、アルファベットと数字、"/","?"をCWで出力します。
必要最小限の機能に絞ったためBTとかARなどの連文字は打てません。

出力はLEDのON/OFFにしてあります。OUTを使ってもいいでしょう。
LED出力をCMOSロジックで引っ張り出すか、フォトカプラで絶縁して引っ張り、リレーを駆動することを想定しています。

"?"以外は一バイトで表現できるので、データ量の圧縮にいくらかの効果があると思います。"↑","↓"でキーイングの速度を変えられますが、リアルタイムには変えられません。

データ構造は頭の3bitがバー・ドットの数（"A"なら010=2）を表し、下位の5bitがバーかドットかを表します（1でバー0でドット）。このためバーとドットの要素は五個までに限られるので、"?"だけは別処理しています。

実はこれ、学生時代に作ったポケコンキーヤーとはデータ構造が異なります。拙者が作った後に発表されたポケコンキーヤーとほぼ同じ構造です。メリットはそのものズバリ、データ量の削減です。

一文字分のデータを32で割るとバー・ドットの数が得られます（整数の割り算ですから、小数点以下は切り捨てられます）。下位の5bitは&h1Fとの論理積で取り出してますが、実はこの操作は不要だと気づいてしまいました！上位3bitは読みとらないからです。

だもんで270行の『B=[A]＆＃1F』はいらないと思います。

バーかドットかはLSBが"1"か"0"かを取り出して処理します。そして必要な回数ビットシフト（B=B>>1）して繰り返します。このためデータパターンはCWのパターンと比べ反転します（"A"なら00001ではなくて00010になる）。

"?"だけは要素が6なので、上位3bitに相当する変数Cに110→6を代入し、下位5bitに相当する変数Bに001100→&hC=12を代入して出力ルーチン300行にとばします。

各文字コードに対応する配列変数に上記のような構造のデータを書き込み（110,120行）、"?"と"↑","↓"以外は対応する配列変数からデータを読み込みます。本来なら変数を全て初期化(0)するところですが、必要性がないので省いています。





データの作成に表計算ソフトを使うと間違いがない。