Writeコマンドを送りつつ、5pin端子の右端をグランドに落としてBootloaderにリセットを掛けないと、チップが認識されないので、別途ジャンパー線を用意すること。
グランドラインはUSBシリアルの黒いグランド電位の端子に触れるのが一番簡単で安全な方法。 端子を離した時点でオレンジのLEDが点灯してリセットを確認できる。
2017年04月30日
HobbyTronics製UBB-MidiHostデバイスのファームウエアを書換える
USB-MidiHostのファームウエアの書換えを完了した。
Writeコマンドを送りつつ、5pin端子の右端をグランドに落としてBootloaderにリセットを掛けないと、チップが認識されないので、別途ジャンパー線を用意すること。
グランドラインはUSBシリアルの黒いグランド電位の端子に触れるのが一番簡単で安全な方法。 端子を離した時点でオレンジのLEDが点灯してリセットを確認できる。
Writeコマンドを送りつつ、5pin端子の右端をグランドに落としてBootloaderにリセットを掛けないと、チップが認識されないので、別途ジャンパー線を用意すること。
グランドラインはUSBシリアルの黒いグランド電位の端子に触れるのが一番簡単で安全な方法。 端子を離した時点でオレンジのLEDが点灯してリセットを確認できる。
posted by Yasuski at 19:37| H8/Midi
2015年09月26日
USB Host Controller Board V2.2 のデータを書換える
頻繁にファームウエアのアップデートが行われている Microchip 24FJ64GB002 がベースのPIC系USBHOSTデバイス、USB Host Controller Board V2.2 のデータ・アップローダーに関する備忘録。
専用のアプリケーション、ds30loader をダウンロードするために、まずは"フォーラム"に登録すること。
アプリケーション起動後、PCに接続されたFTDI製のUSB/シリアル・コンバーターを使って、ソフトウエアをアップロードする。
以下、サイトからメソッドの引用。
Downloading Software to the board
You can write your own software for the USB Host Board or you can download one of our free software applications. Downloading software to the board does not require a specialist programmer because it has a bootloader already installed.
New software is easily installed over a serial RX/TX connection, so you will need an appropriate connection to your computer. We recommend the FTDI Basic breakout board but there are many similar boards and cables available.
Connect up the power (5V) and GND lines, then connect the RX on the Host board to TX on the FTDI board and TX on the Host board to RX on the FTDI Board. You are now ready to install the new software.
To load the new software we use the free ds30loader application. This works with the bootloader on the Host board. Run the ds30loader application and...
Select the hex file you wish to upload
Set the device to be PIC24FJ and 64GB002
Set Baud rate to 115200
Set Port to your serial port connection
Once you have these setup we just need to click the Write button (just below the Commands menu) and the software will attempt to connect to the bootloader and upload the new software. In order to make the bootloader active though we need to reset the board by briefly connecting the reset pin to earth. The reset pin is the right hand pin on the 5-way header at the top of the board (next to the white triangle). Connect this to the centre (0V) pin and the device will reset.
This needs to be done as short time after clicking the Write button. The easiest way to do this is to put a short piece of wire into the GND and RESET pins, click the Write button, then remove the wire.
See the screenshot below for an example.
Xbeeとは端子配列が違うため書き換え用には治具の製作が必要となるが、簡易な方法としてジャンパー線接続で誤魔化す手もある。 ただし、繋ぎ間違いによる事故には要注意。
専用のアプリケーション、ds30loader をダウンロードするために、まずは"フォーラム"に登録すること。
アプリケーション起動後、PCに接続されたFTDI製のUSB/シリアル・コンバーターを使って、ソフトウエアをアップロードする。
以下、サイトからメソッドの引用。
Downloading Software to the board
You can write your own software for the USB Host Board or you can download one of our free software applications. Downloading software to the board does not require a specialist programmer because it has a bootloader already installed.
New software is easily installed over a serial RX/TX connection, so you will need an appropriate connection to your computer. We recommend the FTDI Basic breakout board but there are many similar boards and cables available.
Connect up the power (5V) and GND lines, then connect the RX on the Host board to TX on the FTDI board and TX on the Host board to RX on the FTDI Board. You are now ready to install the new software.
To load the new software we use the free ds30loader application. This works with the bootloader on the Host board. Run the ds30loader application and...
Select the hex file you wish to upload
Set the device to be PIC24FJ and 64GB002
Set Baud rate to 115200
Set Port to your serial port connection
Once you have these setup we just need to click the Write button (just below the Commands menu) and the software will attempt to connect to the bootloader and upload the new software. In order to make the bootloader active though we need to reset the board by briefly connecting the reset pin to earth. The reset pin is the right hand pin on the 5-way header at the top of the board (next to the white triangle). Connect this to the centre (0V) pin and the device will reset.
This needs to be done as short time after clicking the Write button. The easiest way to do this is to put a short piece of wire into the GND and RESET pins, click the Write button, then remove the wire.
See the screenshot below for an example.
Xbeeとは端子配列が違うため書き換え用には治具の製作が必要となるが、簡易な方法としてジャンパー線接続で誤魔化す手もある。 ただし、繋ぎ間違いによる事故には要注意。
posted by Yasuski at 21:51| H8/Midi
2015年04月30日
PIC系USBHOSTの製品を見つけた
USB Host Controller Board V2.2はMicrochip 24FJ64GB002がベースのPIC系USBHOSTデバイス。
デバイスクラスの実装はシングルレイヤーのみの対応。
http://www.hobbytronics.co.uk/usb-host-midi
他には、このような組み合わせの選択肢もある。
https://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-for-arduino-pro-mini
https://www.pjrc.com/store/teensy31.html
元ネタはここから漁った。
何れにしてもMIDI/USBHOSTのライブラリに問題がある場合には徒労に終わってしまう可能性あり。
デバイスクラスの実装はシングルレイヤーのみの対応。
http://www.hobbytronics.co.uk/usb-host-midi
他には、このような組み合わせの選択肢もある。
https://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-for-arduino-pro-mini
https://www.pjrc.com/store/teensy31.html
元ネタはここから漁った。
何れにしてもMIDI/USBHOSTのライブラリに問題がある場合には徒労に終わってしまう可能性あり。
posted by Yasuski at 18:22| H8/Midi
2013年12月29日
不調だった基板のバグ潰し
結局期日内に動かなかったH8/Tiny系のmidiBoardだったが、mixiに記録していた日記を漁って当時行っていた開発の経過を参照したところ、RXDのフロートが原因で動作不能に陥っていたことが判明した。
Midi受けに使っているPhotoCouplerの出力はOpenCollectorのものが多いが、これをH8に直結した場合にRXD端子がフローティングされて電気的に不安定な状態になった結果、動作不良が発生していたようだ。
基板の設計図を眺めてみると、該当箇所は経験を踏まえてちゃんと抵抗のプルアップで対処しているのだが、
実際の基板は、2枚とも見事にRが抜けていた。
多分この辺りの手当を行うとマトモに動くことになりそうなので、午後の作業で基板の復活を目指す。
Midi受けに使っているPhotoCouplerの出力はOpenCollectorのものが多いが、これをH8に直結した場合にRXD端子がフローティングされて電気的に不安定な状態になった結果、動作不良が発生していたようだ。
基板の設計図を眺めてみると、該当箇所は経験を踏まえてちゃんと抵抗のプルアップで対処しているのだが、
実際の基板は、2枚とも見事にRが抜けていた。
多分この辺りの手当を行うとマトモに動くことになりそうなので、午後の作業で基板の復活を目指す。
posted by Yasuski at 12:00| H8/Midi
2013年12月15日
Tiny系を実装したMiniMidiBoardの端子配置
cc inputs x 16： port5 & port8
cc start#： port7 MSB cc# start from 47,11,21,31,41,51,61,71
AD inputs x 8： portB
sw pattern： port1 #0,1 bit Pattern #00/06/02/03
Midi CH： port1 #4,5,6,7 bit
pgm start#： fixed to "1"
swaddr00:
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 0, 0, 0, 0
swaddr06:
.data.b 1, 1, 1, 1, 1, 1, 1, 1
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 1, 1, 1, 1
.data.b 1, 1, 1, 1, 0, 0, 0, 0
swaddr02:
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 1, 1, 1, 1, 1, 1, 1, 1
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 0, 0, 0, 0
swaddr03:
.data.b 0, 0, 0, 0, 1, 1, 1, 1
.data.b 1, 1, 1, 1, 1, 1, 1, 1
.data.b 0, 0, 0, 0, 0, 0, 0, 0
.data.b 0, 0, 0, 0, 0, 0, 0, 0
posted by Yasuski at 00:18| H8/Midi
2013年12月05日
H8/3052のファームウエアを更新した
既に生産が中止されているらしいH8/3052だが、このチップを実装した便利だがフットプリントがやたらでかいAKI-8の今後はどうなるのだろうか。
今回は、これを乗っける形の怪談スイッチ専用MidiBoardを新しくAllAccessに組み込むので、今まで実験用にアップロードしていたBaudRateConverterのFirmwareを書き換えることにした。
過去に試作したmidi通信システムは、WiPortとH8/3052を送受信のペアで使うという電力消費を含めて物凄くCPの悪いものであったが、WiPortの設定ミスというかEvaluationBoardの持つ性格を理解していなかったために、道半ばで失敗となった。 その後、有線でH8同士を繋いで実験した結果、ほぼ完璧な動作を確認できた時は、とても複雑な感慨を抱いたのものだが、時既に遅く、WiFi/midi通信プロジェクトのデバイス選定は安価でハンドリングが楽なXBeeに移行していた。
BaudRateConverterのFirmwareはその名残なのだが、最近WiPortを復活させたこともあるので、また必要になる時期が来る可能性がある。 使ってみて判ったのだが、XBeeの信頼性はイマイチ高くはないのだ。 信頼性で機器を遣い分ける場合が来ないとも限らないのだが、その時にまたH8にデータを焼きなおすのは億劫だ。
ということで、ノーマルモードは普通のmidiスイッチマトリックスを演じつつ、PowerOn時に起動を選択するとBaudRateConverterに変身する仕組みを追加することにした。
仕掛けは単純で、BaudRateを変換するために異なる周波数に設定したSciのプリセット値を、マイコン立ち上げ時の条件分岐によって読み替えるのだ。 途中でリセットが行えないこともないが、誤動作が発生する可能性があるので、やはり単純に立ち上げ時に処理ルーティンを選択する方式が正しいと思う。
必要な変更は、BaudRateConverterでは2つあったTx系を1つに減らしつつ、襷掛けにしていたRx系のハンドリングををMixier機能に戻して、送り先を一つにまとめるだけで良いのだが、今回は別関数を作って処理ループを切り替える構造をとった。 これは、無駄にデータ容量が増える間抜けなプログラミングだが、そもそも速度重視のために、プログラムをCで組まずにアセンブラを使用しているので、処理スピードに問題はないだろう。
今回は、これを乗っける形の怪談スイッチ専用MidiBoardを新しくAllAccessに組み込むので、今まで実験用にアップロードしていたBaudRateConverterのFirmwareを書き換えることにした。
過去に試作したmidi通信システムは、WiPortとH8/3052を送受信のペアで使うという電力消費を含めて物凄くCPの悪いものであったが、WiPortの設定ミスというかEvaluationBoardの持つ性格を理解していなかったために、道半ばで失敗となった。 その後、有線でH8同士を繋いで実験した結果、ほぼ完璧な動作を確認できた時は、とても複雑な感慨を抱いたのものだが、時既に遅く、WiFi/midi通信プロジェクトのデバイス選定は安価でハンドリングが楽なXBeeに移行していた。
BaudRateConverterのFirmwareはその名残なのだが、最近WiPortを復活させたこともあるので、また必要になる時期が来る可能性がある。 使ってみて判ったのだが、XBeeの信頼性はイマイチ高くはないのだ。 信頼性で機器を遣い分ける場合が来ないとも限らないのだが、その時にまたH8にデータを焼きなおすのは億劫だ。
ということで、ノーマルモードは普通のmidiスイッチマトリックスを演じつつ、PowerOn時に起動を選択するとBaudRateConverterに変身する仕組みを追加することにした。
仕掛けは単純で、BaudRateを変換するために異なる周波数に設定したSciのプリセット値を、マイコン立ち上げ時の条件分岐によって読み替えるのだ。 途中でリセットが行えないこともないが、誤動作が発生する可能性があるので、やはり単純に立ち上げ時に処理ルーティンを選択する方式が正しいと思う。
必要な変更は、BaudRateConverterでは2つあったTx系を1つに減らしつつ、襷掛けにしていたRx系のハンドリングををMixier機能に戻して、送り先を一つにまとめるだけで良いのだが、今回は別関数を作って処理ループを切り替える構造をとった。 これは、無駄にデータ容量が増える間抜けなプログラミングだが、そもそも速度重視のために、プログラムをCで組まずにアセンブラを使用しているので、処理スピードに問題はないだろう。
posted by Yasuski at 01:15| H8/Midi
2013年11月25日
フットコントローラーのWiFi化その他
何時も使っている7個組のフットコントローラーをWiFi化することにした。
前回のライブの体験でiPadからの操作は確実性に欠けることが判っているので、今回は出来るだけフィジカル・インターフェイスを増やすつもりだったのだが、11月も終盤となった今、そろそろ製作のタイムリミットが近付いて来た。 最終的にはmonomeを絡めたUSBHostの製作まで進みたいのだが、その前に手持ち機材のWiFi化の徹底だ。
フットコントローラーにはH8/Tiny系midiボードを組み込み、これの出力をXbeeで送信する。
H8/Tinyの採用は消費電力とサイズを勘案しての選択で、使用するポートは基本アナログのみとなる。緊急用に複数のSWを組み込むことも考えているが、まずはアナログ入力のハンドリングに専念する。
アセンブルコードはこちら。
二次電池にはAllAccessと同じく、LiPo4電池を使用する予定だ。
一方、AllAccessを２面スイッチマトリックスに改造する計画だが、
当初はCPLD基板の16bit出力にラッチを２系統用意して信号をH8の入力32chに分配し、ラッチからのフィードバックをCPLDスイッチマトリックスのプリセット入力に襷掛けで配線する回路を考えていた。 が、構造がややこしくなるうえに、切り替えるタイミングの設計が難しい。 そこで、ここは奮発して在庫のあるPGA版のCPLD基板を２個並列に実装し、構造の単純化を狙うことにした。
怪談スイッチ2台分のCPLD基板をAllAccess1台にハンドリングするわけで、なかなか豪勢な回路構成である。
昨晩は、このスイッチ・マトリックスにAllAccessの物理スイッチを分配する回路をCPLDで製作していたのだが、
XlinxのIDEとリンクしたピン配列を編集するセクションにバグが有り、その影響でファイルが壊れては造り直すという不毛な作業のループに陥っていた。
ピン配列を記述するファイルは.ucfという拡張子のついたテキストファイルで、これに自動的に記述されるテンプレートがバグの原因だった。 手動でファイル名を記述した結果バグは収まったが、これに気付くまで相当な時間を費やすことになった。
ピン配置は、
#PACE: Start of Constraints generated by PACE
#PACE: Start of PACE I/O Pin Assignments
NET "swInput<0>" LOC = "P11" ;
NET "swInput<10>" LOC = "P84" ;
NET "swInput<11>" LOC = "P83" ;
NET "swInput<12>" LOC = "P82" ;
NET "swInput<13>" LOC = "P81" ;
NET "swInput<14>" LOC = "P80" ;
NET "swInput<15>" LOC = "P79" ;
のようにテキスト形式で記述するのだが、これの " " 内の文字列が何故か自動で書き込まれない。以前使っていた旧いヴァージョンでは発生しなかったバグだが、現用のIDEも２年前のヴァージョン故、この問題は既にFixされている可能性が高い。 XlinxのIDEはヴァージョン違いでインプリメンテーションが行えないことがあるので、ヴァージョンアップには注意が必要だ。 8年前よりも便利になったところは、回路図をそのままVHDLに起こせることで、忘却の彼方にあったVHDLの文法を掘り起こすこと無く、お気軽に回路設計を行えた。
今回使用するCPLDは9572という何時も使っている95144よりもゲートサイズの小さな仕様の違うチップなので、使い慣れた自作の書き込みマシンでは対応ができない。 以前購入していた9572専用の開発ボードはJTAG対応なので、それを使うことになるが、このボードは電源の極性がRoland系なので作業の前に極性変換を行う電源アダプタを新たに製作しなければならない。
前回のライブの体験でiPadからの操作は確実性に欠けることが判っているので、今回は出来るだけフィジカル・インターフェイスを増やすつもりだったのだが、11月も終盤となった今、そろそろ製作のタイムリミットが近付いて来た。 最終的にはmonomeを絡めたUSBHostの製作まで進みたいのだが、その前に手持ち機材のWiFi化の徹底だ。
フットコントローラーにはH8/Tiny系midiボードを組み込み、これの出力をXbeeで送信する。
H8/Tinyの採用は消費電力とサイズを勘案しての選択で、使用するポートは基本アナログのみとなる。緊急用に複数のSWを組み込むことも考えているが、まずはアナログ入力のハンドリングに専念する。
アセンブルコードはこちら。
二次電池にはAllAccessと同じく、LiPo4電池を使用する予定だ。
一方、AllAccessを２面スイッチマトリックスに改造する計画だが、
当初はCPLD基板の16bit出力にラッチを２系統用意して信号をH8の入力32chに分配し、ラッチからのフィードバックをCPLDスイッチマトリックスのプリセット入力に襷掛けで配線する回路を考えていた。 が、構造がややこしくなるうえに、切り替えるタイミングの設計が難しい。 そこで、ここは奮発して在庫のあるPGA版のCPLD基板を２個並列に実装し、構造の単純化を狙うことにした。
怪談スイッチ2台分のCPLD基板をAllAccess1台にハンドリングするわけで、なかなか豪勢な回路構成である。
昨晩は、このスイッチ・マトリックスにAllAccessの物理スイッチを分配する回路をCPLDで製作していたのだが、
XlinxのIDEとリンクしたピン配列を編集するセクションにバグが有り、その影響でファイルが壊れては造り直すという不毛な作業のループに陥っていた。
ピン配列を記述するファイルは.ucfという拡張子のついたテキストファイルで、これに自動的に記述されるテンプレートがバグの原因だった。 手動でファイル名を記述した結果バグは収まったが、これに気付くまで相当な時間を費やすことになった。
ピン配置は、
#PACE: Start of Constraints generated by PACE
#PACE: Start of PACE I/O Pin Assignments
NET "swInput<0>" LOC = "P11" ;
NET "swInput<10>" LOC = "P84" ;
NET "swInput<11>" LOC = "P83" ;
NET "swInput<12>" LOC = "P82" ;
NET "swInput<13>" LOC = "P81" ;
NET "swInput<14>" LOC = "P80" ;
NET "swInput<15>" LOC = "P79" ;
のようにテキスト形式で記述するのだが、これの " " 内の文字列が何故か自動で書き込まれない。以前使っていた旧いヴァージョンでは発生しなかったバグだが、現用のIDEも２年前のヴァージョン故、この問題は既にFixされている可能性が高い。 XlinxのIDEはヴァージョン違いでインプリメンテーションが行えないことがあるので、ヴァージョンアップには注意が必要だ。 8年前よりも便利になったところは、回路図をそのままVHDLに起こせることで、忘却の彼方にあったVHDLの文法を掘り起こすこと無く、お気軽に回路設計を行えた。
今回使用するCPLDは9572という何時も使っている95144よりもゲートサイズの小さな仕様の違うチップなので、使い慣れた自作の書き込みマシンでは対応ができない。 以前購入していた9572専用の開発ボードはJTAG対応なので、それを使うことになるが、このボードは電源の極性がRoland系なので作業の前に極性変換を行う電源アダプタを新たに製作しなければならない。
posted by Yasuski at 06:40| H8/Midi
2013年05月09日
備忘録＠怪談スイッチのPGMチェンジ設定の解説
過去に組み直した怪談スイッチの機能設定が忘却の彼方になってしまったことを反省して、いま一度過去のアーカイヴを掘り起こして記録するトピック。
現在KYMA上で設定しているスイッチ・アサインマップで、機能変更が可能な場所に配置出来るプログラム・チェンジ・ナンバーの数は8つ、それも図に示したポジションのプリセット、スイッチ・パターン#7に限られる。↓
呼び出せるプリセット数が8個とは少々寂しい感じがしたので、色々と考えた末「PGMチェンジのバンク切り替えを行なってスイッチをレイヤー化したら使い勝手が良さそうだ」との結論が出た。
普通のフットスイッチは皆似たような構造なので、やってみる価値はありそうだ。
具体的には
が、スイッチオンで
と切り替わるような仕組み。 これで16ch分の設定にアクセスすることができる
今回の改変は、プログラムチェンジの開始番号70番台（スイッチの見かけ上の番号、実効数は0〜69番となる）からは、リアルタイムにスイッチのバンクチェンジを受け付ける仕様に変更したこと。リモートコントロールには端子の増設が必要となるが、これを補うために殆ど使っていない（設計当時）空きスイッチ#30番を充てている。
#30番スイッチに当たる★をオンにすると、、、
が
の状態に切り替わる。
このオプション・プログラムは、PGMチェンジ設定番号が#70から#77で起動する。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;optional offset detector;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cmp.b #70,r3l ;preset number 70~79 call the offset generator routine.
bge offset_gen
bra pgstatus_out
設定番号が"0"の場合は1番をプリセットする。
offset_00:
mov.b #1,r3l ;when the input number is zero, preset #1
bra pgstatus_out
offset_gen:
sub.w r2,r2 ;clear
mov.b @outputs,r3h ;upload the program change sw group status and calc the magnitude on r2l
アウトプットのプリセットを呼び出し、、、
mov.b @ext_port,r2h
add.b r2h,r3h
cmp.b #0,r3h
beq pgstatus_out ;branch to pgm output
外部に接続したスイッチマトリックスのポートの状態をスキャン、
btst #0,r3h
beq port_B
port_A: inc.b r2l
port_B: btst #1,r3h
beq port_C
inc.b r2l
port_C: btst #2,r3h
beq port_D
inc.b r2l
port_D: btst #3,r3h
beq port_E
inc.b r2l
port_E: btst #4,r3h
beq port_F
inc.b r2l
port_F: btst #5,r3h
beq port_G
inc.b r2l
port_G: btst #6,r3h
beq port_H
inc.b r2l
port_H: btst #7,r3h
beq pgstatus_out
inc.b r2l
プログラムチェンジにアサインされたスイッチの総数をカウント。スイッチのプリセットは一列4個単位なので、プログラムチェンジのステイタス数×4でオフセットの総数が決定する。
calc_offset:
sub.b r3h,r3h
sub.b r2h,r2h
mov.b #4,r3h
mulxu.b r3h,r2
sub.b r2h,r2h
オフセット番号を記録した後、
mov.b r2l,@offset_numbers ;keep the offset numbers
プリセット番号に準じてオフセット値に分岐、
cmp.b #70,r3l
beq offset_01
cmp.b #71,r3l
beq offset_02
cmp.b #72,r3l
beq offset_03
cmp.b #73,r3l
beq offset_04
cmp.b #74,r3l
beq offset_05
cmp.b #75,r3l
beq offset_06
cmp.b #76,r3l
beq offset_07
cmp.b #77,r3l
beq offset_08
cmp.b #78,r3l
beq offset_09
cmp.b #79,r3l
beq offset_10
bra pgstatus_out
プリセット番号は2番から開始する。レイヤー切り替えスイッチの状態を調べた後、
offset_01:
mov.b #2,r3l ;preset #70 has the starting numbers from #002
mov.b @offset_flag,r2h ;sw #30 set the second stage pgm numbers
btst #0,r2h
bne oe_detected_01
bra pgstatus_out
該当するオフセット値を足してアウトプット。
oe_detected_01:
mov.b @offset_numbers,r3h
add.b r3h,r3l
bra pgstatus_out
以下同様に処理を行う。
5月10日追記：
プログラムをチェックしていた過程で、左バンクのスイッチ・マトリックス最上部のラインをプログラムチェンジにアサインした場合に、#30のスイッチをオンにするとバグが発生することが発覚。
ただし、現実的にこのラインをプログラムチェンジにアサインする可能性は低いので、用法で逃げられるレベルの不具合ではある。
何れにしても、使用時には注意が必要。
現在KYMA上で設定しているスイッチ・アサインマップで、機能変更が可能な場所に配置出来るプログラム・チェンジ・ナンバーの数は8つ、それも図に示したポジションのプリセット、スイッチ・パターン#7に限られる。↓
呼び出せるプリセット数が8個とは少々寂しい感じがしたので、色々と考えた末「PGMチェンジのバンク切り替えを行なってスイッチをレイヤー化したら使い勝手が良さそうだ」との結論が出た。
普通のフットスイッチは皆似たような構造なので、やってみる価値はありそうだ。
具体的には
が、スイッチオンで
と切り替わるような仕組み。 これで16ch分の設定にアクセスすることができる
今回の改変は、プログラムチェンジの開始番号70番台（スイッチの見かけ上の番号、実効数は0〜69番となる）からは、リアルタイムにスイッチのバンクチェンジを受け付ける仕様に変更したこと。リモートコントロールには端子の増設が必要となるが、これを補うために殆ど使っていない（設計当時）空きスイッチ#30番を充てている。
#30番スイッチに当たる★をオンにすると、、、
が
の状態に切り替わる。
このオプション・プログラムは、PGMチェンジ設定番号が#70から#77で起動する。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;optional offset detector;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cmp.b #70,r3l ;preset number 70~79 call the offset generator routine.
bge offset_gen
bra pgstatus_out
設定番号が"0"の場合は1番をプリセットする。
offset_00:
mov.b #1,r3l ;when the input number is zero, preset #1
bra pgstatus_out
offset_gen:
sub.w r2,r2 ;clear
mov.b @outputs,r3h ;upload the program change sw group status and calc the magnitude on r2l
アウトプットのプリセットを呼び出し、、、
mov.b @ext_port,r2h
add.b r2h,r3h
cmp.b #0,r3h
beq pgstatus_out ;branch to pgm output
外部に接続したスイッチマトリックスのポートの状態をスキャン、
btst #0,r3h
beq port_B
port_A: inc.b r2l
port_B: btst #1,r3h
beq port_C
inc.b r2l
port_C: btst #2,r3h
beq port_D
inc.b r2l
port_D: btst #3,r3h
beq port_E
inc.b r2l
port_E: btst #4,r3h
beq port_F
inc.b r2l
port_F: btst #5,r3h
beq port_G
inc.b r2l
port_G: btst #6,r3h
beq port_H
inc.b r2l
port_H: btst #7,r3h
beq pgstatus_out
inc.b r2l
プログラムチェンジにアサインされたスイッチの総数をカウント。スイッチのプリセットは一列4個単位なので、プログラムチェンジのステイタス数×4でオフセットの総数が決定する。
calc_offset:
sub.b r3h,r3h
sub.b r2h,r2h
mov.b #4,r3h
mulxu.b r3h,r2
sub.b r2h,r2h
オフセット番号を記録した後、
mov.b r2l,@offset_numbers ;keep the offset numbers
プリセット番号に準じてオフセット値に分岐、
cmp.b #70,r3l
beq offset_01
cmp.b #71,r3l
beq offset_02
cmp.b #72,r3l
beq offset_03
cmp.b #73,r3l
beq offset_04
cmp.b #74,r3l
beq offset_05
cmp.b #75,r3l
beq offset_06
cmp.b #76,r3l
beq offset_07
cmp.b #77,r3l
beq offset_08
cmp.b #78,r3l
beq offset_09
cmp.b #79,r3l
beq offset_10
bra pgstatus_out
プリセット番号は2番から開始する。レイヤー切り替えスイッチの状態を調べた後、
offset_01:
mov.b #2,r3l ;preset #70 has the starting numbers from #002
mov.b @offset_flag,r2h ;sw #30 set the second stage pgm numbers
btst #0,r2h
bne oe_detected_01
bra pgstatus_out
該当するオフセット値を足してアウトプット。
oe_detected_01:
mov.b @offset_numbers,r3h
add.b r3h,r3l
bra pgstatus_out
以下同様に処理を行う。
5月10日追記：
プログラムをチェックしていた過程で、左バンクのスイッチ・マトリックス最上部のラインをプログラムチェンジにアサインした場合に、#30のスイッチをオンにするとバグが発生することが発覚。
ただし、現実的にこのラインをプログラムチェンジにアサインする可能性は低いので、用法で逃げられるレベルの不具合ではある。
何れにしても、使用時には注意が必要。
posted by Yasuski at 05:36| H8/Midi
2013年02月28日
ジャンクなミニ鍵盤をXBeeを使って有効活用する話
このミニ鍵盤は大昔に買ったMac用ソフトウエア音源（OS9時代）のオマケで付いてきたものだった。
Pressureが出力されないプアな性能のキーボードではあるが、自作midiボードを追加してAD8chと16個のスイッチポートを実装すれば、それなりの機能を持ったリモコンデバイスに変身させられそうだ。
Serial直受けで何故かエラーが頻発したので、USB/midiに接続して状態を観察した。信号をモニターして見たところ、何故か怪しげな信号を吐き続けている。
対策として自作midiボードをキーボードの下流に接続してゴミデータを堰き止めた。
折角なので電池駆動を目指すが、追加のマイコンパーツの消費電流を考えると単三電池系の選択肢は無謀。結局Li-Ion系の電池一択となってしまうが、容量次第では格納が難しくなってくる。 パーツケースから発掘した携帯電話用のバルクな電池はほぼ全滅だった。 パソコンの電源パックから回収したLi-Ion電池は少々オーヴァーサイズ気味だったので、新たにSwitchScienceからLi-Poly電池を購入することにした。
MidiKeyboard改造の過程で追加したいのがpitchBend機能だが、データの扱い方が解らない。
pitchBendはヘッダーがEnH、データバイトが14ビット扱いで、デフォルトとなる中間値が#０ではなく#６４とハンドリングが難しい。
市販品は14bitもの高分解能のADを使っているとは考えにくく、8ビットが精々だと思われる。 自製midiBoardのファームをキーボード用に書き換える場合、MSB/7bitの送信で誤魔化すか、下3桁（H8のADは10bit、精度保障は8bit）もしくは下1桁を追加するかどうかの判断が難しい。
プログラム上のAD変換のループで得られたデータの扱いは8bitで出た結果を７bitに桁をシフトしているので、この過程で失われたデータをLSBの最上位bitに追加する作業が必要となる。 通常、ADの結果はccデータとして吐かせているので、EnHを扱う場合、プログラムのAD変換のループからAD１ｃｈ分を分離しなければならない。 データのエントリーはLSB/MSBの順番になることに注意。 また、先に書いた中間値の扱いをアナログ的に処理するか、AD２ch分を使ってデジタル的に処理するかが判断の別れるところとなる。
丁度手元に親指で動作させるゲームコントローラー用のデバイスがあったので、部品のアナログ的な仕様を確認して簡易タイプのプリ・アンプを試作した。上の写真はその内部構造。
オフセットコントロールを備えた単純な非反転増幅回路なので何のヒネリもないが、まずはブレッドボード上でピッチ・ベンダー用の電圧発生回路を組んだ。
64bitの定常出力を想定してVRの中間値のオフセットを2.5Vに設定。VRの構造上、片方を5V＝フルビット・ドン付きに調整すると、もう一方は1.1~1.2Vと32bitあたりまで下げるのが限界の模様。 ダイオードでアンチログを組むことも可能だが、OPAMPを二段構成にする必要があるので、とりあえずは簡易な回路で妥協することにした。 使用時に不具合を感じたら逐次改良を行なっていく予定。
その後、ゴミデータ対策のためOP-Ampの帰還回路に0.1uのコンデンサーを追加して、安定を確保した。
部品の配置：トップカバー センサー類は基本的にこちら側に実装する。
部品の配置：ベース H8やXBee等のハードウエアを実装する。
使用したスイッチはリモコンなどに使われているソフトスイッチ。その他、VR、midiチャンネル設定用のデジタルスイッチ、それとベンダー用のVRを取り付けている。 ただし、ベンダー用のVRは実装が難しく、現在の状態はペンディング。 スイッチ類は多少増えるかもしれない。
H8への新たなファームウエアの書き込みが以前使っていたGCCで行えないという案件が発生していたが、これをH8Wに変えてトライしたところ、なんとか書き込めた模様。
MiniKeyboardの荒組みを完了後に送受信のテストを行ったところ、結果は予想通りAD周りが壊滅していた。
病気の症状は一旦VRノブにアクセスした途端、USB/midiがハングする謎のコードを吐いてしまう。 ハング後にXBeeの受信表示LEDが点滅しているのでUSB/midi特有 の問題と思われるも、H8側がバグを誘発するへんてこなコードを吐いている事に変わりはない。 ちなみに、SW関連は問題なく送信できていたのでAD_Check周りのコードを失敗している。 ハード側に解決できない問題もあったことから、最終的に改造前のCCを吐くだけのファームウエアに戻すことになった。
本来pitchBendにアサインするはずだったBender用VRは中点が全く安定せず、出力を変更した。現時点でBenderVRはcc#107/108でX/Yの座標を出力するジョイスティック扱いとなっている。 KymaではccをそのままOscのPitchBend情報にアサイン出来るので、現状でも問題はない。
Pressureが出力されないプアな性能のキーボードではあるが、自作midiボードを追加してAD8chと16個のスイッチポートを実装すれば、それなりの機能を持ったリモコンデバイスに変身させられそうだ。
Serial直受けで何故かエラーが頻発したので、USB/midiに接続して状態を観察した。信号をモニターして見たところ、何故か怪しげな信号を吐き続けている。
対策として自作midiボードをキーボードの下流に接続してゴミデータを堰き止めた。
折角なので電池駆動を目指すが、追加のマイコンパーツの消費電流を考えると単三電池系の選択肢は無謀。結局Li-Ion系の電池一択となってしまうが、容量次第では格納が難しくなってくる。 パーツケースから発掘した携帯電話用のバルクな電池はほぼ全滅だった。 パソコンの電源パックから回収したLi-Ion電池は少々オーヴァーサイズ気味だったので、新たにSwitchScienceからLi-Poly電池を購入することにした。
MidiKeyboard改造の過程で追加したいのがpitchBend機能だが、データの扱い方が解らない。
pitchBendはヘッダーがEnH、データバイトが14ビット扱いで、デフォルトとなる中間値が#０ではなく#６４とハンドリングが難しい。
市販品は14bitもの高分解能のADを使っているとは考えにくく、8ビットが精々だと思われる。 自製midiBoardのファームをキーボード用に書き換える場合、MSB/7bitの送信で誤魔化すか、下3桁（H8のADは10bit、精度保障は8bit）もしくは下1桁を追加するかどうかの判断が難しい。
プログラム上のAD変換のループで得られたデータの扱いは8bitで出た結果を７bitに桁をシフトしているので、この過程で失われたデータをLSBの最上位bitに追加する作業が必要となる。 通常、ADの結果はccデータとして吐かせているので、EnHを扱う場合、プログラムのAD変換のループからAD１ｃｈ分を分離しなければならない。 データのエントリーはLSB/MSBの順番になることに注意。 また、先に書いた中間値の扱いをアナログ的に処理するか、AD２ch分を使ってデジタル的に処理するかが判断の別れるところとなる。
丁度手元に親指で動作させるゲームコントローラー用のデバイスがあったので、部品のアナログ的な仕様を確認して簡易タイプのプリ・アンプを試作した。上の写真はその内部構造。
オフセットコントロールを備えた単純な非反転増幅回路なので何のヒネリもないが、まずはブレッドボード上でピッチ・ベンダー用の電圧発生回路を組んだ。
64bitの定常出力を想定してVRの中間値のオフセットを2.5Vに設定。VRの構造上、片方を5V＝フルビット・ドン付きに調整すると、もう一方は1.1~1.2Vと32bitあたりまで下げるのが限界の模様。 ダイオードでアンチログを組むことも可能だが、OPAMPを二段構成にする必要があるので、とりあえずは簡易な回路で妥協することにした。 使用時に不具合を感じたら逐次改良を行なっていく予定。
その後、ゴミデータ対策のためOP-Ampの帰還回路に0.1uのコンデンサーを追加して、安定を確保した。
部品の配置：トップカバー センサー類は基本的にこちら側に実装する。
部品の配置：ベース H8やXBee等のハードウエアを実装する。
使用したスイッチはリモコンなどに使われているソフトスイッチ。その他、VR、midiチャンネル設定用のデジタルスイッチ、それとベンダー用のVRを取り付けている。 ただし、ベンダー用のVRは実装が難しく、現在の状態はペンディング。 スイッチ類は多少増えるかもしれない。
H8への新たなファームウエアの書き込みが以前使っていたGCCで行えないという案件が発生していたが、これをH8Wに変えてトライしたところ、なんとか書き込めた模様。
MiniKeyboardの荒組みを完了後に送受信のテストを行ったところ、結果は予想通りAD周りが壊滅していた。
病気の症状は一旦VRノブにアクセスした途端、USB/midiがハングする謎のコードを吐いてしまう。 ハング後にXBeeの受信表示LEDが点滅しているのでUSB/midi特有 の問題と思われるも、H8側がバグを誘発するへんてこなコードを吐いている事に変わりはない。 ちなみに、SW関連は問題なく送信できていたのでAD_Check周りのコードを失敗している。 ハード側に解決できない問題もあったことから、最終的に改造前のCCを吐くだけのファームウエアに戻すことになった。
本来pitchBendにアサインするはずだったBender用VRは中点が全く安定せず、出力を変更した。現時点でBenderVRはcc#107/108でX/Yの座標を出力するジョイスティック扱いとなっている。 KymaではccをそのままOscのPitchBend情報にアサイン出来るので、現状でも問題はない。
posted by Yasuski at 04:17| H8/Midi
2013年02月26日
H8シリーズへの書込み手順
H8の入門用としては秋月のキットが有名だが、購入すると A38H.EXE、L38H.EXE、C38H.EXE という実行ファイルが入ったCD-ROMが付属してくる。
これらはアセンブル・コードをMOTファイルに変換してくれるツールだが、実行ファイルを操作するには不慣れな「DOS窓」を開かなくてはならない。 コマンド打ちのインターフェイスは一般ユーザーにとっては少々敷居が高そうだが、今回行う作業量は「頑張れば何とかなる」レベルだろう。
出版されている旧いハウツー本には「フロッピーにデータを格納して作業をしましょう〜」などと書いてあるが、HDDに直接ファイルを置いて操作しても問題はない。 作業に入ったら、まずは最初にアセンブルコードを格納するフォルダを作ろう。次にフォルダーの中に、前述した実行ファイルと、コマンド・プロンプトのショートカットを作成しておく。
DOS窓を開ける前に、ショートカットを右クリックして作業フォルダの指定を行う。OKをクリックした後にDOSプロンプトを立ち上げると黒バックの不穏な雰囲気の画面が現れる。
指定したフォルダの階層にアクセスしていることを確認した後、A38H.EXE XXX.src -CPU=300HA:20 といった風にDOS窓にコマンドを打ち込んでいく。(Tinyシリーズを使用する場合、CPU設定が -CPU=300HN となることに注意。）
この例では、関数の記述ミスをやらかしてエラーが頻発している様子が判る。エラー箇所の表示はオリジナルの行数とは異なり、新たに生成されたlistファイルに準拠している。 アセンブルが通るまでは次のステップには進めない。
アセンブル終了後、L38H.EXEでリンクを張り、C38H.EXEでコンパイルを完了すると、MOT（モトローラ）ファイルが完成する。これをH8WriteTurbo等のツールを使ってマイコンに書き込み、とりあえず作業は完了する。
3694等の"Tinyシリーズ"は秋月ROMに添付されている焼込みツールの対応機種から外れている場合がある。
参考画像のツールはTinyシリーズに対応している"H8W".
書込み時には基盤上のピンヘッダ2箇所を接続して "BootMode" に設定すること。
これらはアセンブル・コードをMOTファイルに変換してくれるツールだが、実行ファイルを操作するには不慣れな「DOS窓」を開かなくてはならない。 コマンド打ちのインターフェイスは一般ユーザーにとっては少々敷居が高そうだが、今回行う作業量は「頑張れば何とかなる」レベルだろう。
出版されている旧いハウツー本には「フロッピーにデータを格納して作業をしましょう〜」などと書いてあるが、HDDに直接ファイルを置いて操作しても問題はない。 作業に入ったら、まずは最初にアセンブルコードを格納するフォルダを作ろう。次にフォルダーの中に、前述した実行ファイルと、コマンド・プロンプトのショートカットを作成しておく。
DOS窓を開ける前に、ショートカットを右クリックして作業フォルダの指定を行う。OKをクリックした後にDOSプロンプトを立ち上げると黒バックの不穏な雰囲気の画面が現れる。
指定したフォルダの階層にアクセスしていることを確認した後、A38H.EXE XXX.src -CPU=300HA:20 といった風にDOS窓にコマンドを打ち込んでいく。(Tinyシリーズを使用する場合、CPU設定が -CPU=300HN となることに注意。）
この例では、関数の記述ミスをやらかしてエラーが頻発している様子が判る。エラー箇所の表示はオリジナルの行数とは異なり、新たに生成されたlistファイルに準拠している。 アセンブルが通るまでは次のステップには進めない。
アセンブル終了後、L38H.EXEでリンクを張り、C38H.EXEでコンパイルを完了すると、MOT（モトローラ）ファイルが完成する。これをH8WriteTurbo等のツールを使ってマイコンに書き込み、とりあえず作業は完了する。
3694等の"Tinyシリーズ"は秋月ROMに添付されている焼込みツールの対応機種から外れている場合がある。
参考画像のツールはTinyシリーズに対応している"H8W".
書込み時には基盤上のピンヘッダ2箇所を接続して "BootMode" に設定すること。
posted by Yasuski at 15:36| H8/Midi
2012年10月02日
H8/3052版BaudRateConverterの追試
WiFi/MidiKeyboard、XBee使用のWiFi/MidiReceiver、FT232RのUSB/Serial、それと通常のUSB/Midiデバイスを使って、H8の通信環境を検証してみたところ、ご覧のように全く問題なく動作していることを確認できた。
テストの手順は最初にHairlessMidiserialを起動し、Serial/38400baudとWiFi/Midiをブリッジ、ソフトウエア内でBaudRateの変換を行う。
次に、コンバートされたmidiDataの入出力を、USB/SerialインターフェイスFT232Rを使って、H8/3052の入出力 sci_0 と接続する。 H8にはsci（シリアルインターフェイス）が2基搭載されており、個別にBaudRateを設定できる。今回の製作では、sci_0を34800baud、sci_1を31250baudにセットしている。
一方、2つ目の入出力 sci_1 の出力をUSB/Midiデバイス、MidiSport2X2 の Midi入力/B に接続、38400baud で送信されたMidiDataが 31250baud に再変換されたことをモニターする。
midi入力（31250baud）のモニターは、midiケーブルを作るのが邪魔臭かったので割愛した。
画像から判るように、シリアル通信を介在してmidiDataの送受信が問題なく行われている。
参考までに、MidiDataStreamのCH10はH8から、CH1/CH3はWiFiMidiKeyboardから送信されている。
VRの操作で連続的に発生するcc#100番台のADデータを受けても、ボトルネックの発生は見られない。
以上のことから、問題はWiPortとデータのハンドリングを行う段階で発生していたことが確認された。
WiPort側の故障も考えられるが、EVAL Boardを使ってPCのターミナルソフトウエアからシリアル通信が行えているので、その可能性は低い。
ちなみに、midiデータの送信はHairless Midiserialを使って既に試みている。
WiPort手前のEvalBoardまでの信号はLEDのBlinkで確認できたが、その先のWiFi送信には至っていない。 従って、WiPortの設定を失敗している可能性が濃厚となった。
問題点をクリアすべく今後も調査を継続する予定。
2013年5月5日追記：
後日、「評価ボードにWiPortを乗っけると強制的に9800bpsに通信レートが変更される」という驚愕の仕様が発覚した。
道理で通信が繋がらないわけだが、もう一度WiPort周りの基盤を作りなおして実験をやり直さねばならなくなった。
テストの手順は最初にHairlessMidiserialを起動し、Serial/38400baudとWiFi/Midiをブリッジ、ソフトウエア内でBaudRateの変換を行う。
次に、コンバートされたmidiDataの入出力を、USB/SerialインターフェイスFT232Rを使って、H8/3052の入出力 sci_0 と接続する。 H8にはsci（シリアルインターフェイス）が2基搭載されており、個別にBaudRateを設定できる。今回の製作では、sci_0を34800baud、sci_1を31250baudにセットしている。
一方、2つ目の入出力 sci_1 の出力をUSB/Midiデバイス、MidiSport2X2 の Midi入力/B に接続、38400baud で送信されたMidiDataが 31250baud に再変換されたことをモニターする。
midi入力（31250baud）のモニターは、midiケーブルを作るのが邪魔臭かったので割愛した。
画像から判るように、シリアル通信を介在してmidiDataの送受信が問題なく行われている。
参考までに、MidiDataStreamのCH10はH8から、CH1/CH3はWiFiMidiKeyboardから送信されている。
VRの操作で連続的に発生するcc#100番台のADデータを受けても、ボトルネックの発生は見られない。
以上のことから、問題はWiPortとデータのハンドリングを行う段階で発生していたことが確認された。
WiPort側の故障も考えられるが、EVAL Boardを使ってPCのターミナルソフトウエアからシリアル通信が行えているので、その可能性は低い。
ちなみに、midiデータの送信はHairless Midiserialを使って既に試みている。
WiPort手前のEvalBoardまでの信号はLEDのBlinkで確認できたが、その先のWiFi送信には至っていない。 従って、WiPortの設定を失敗している可能性が濃厚となった。
問題点をクリアすべく今後も調査を継続する予定。
2013年5月5日追記：
後日、「評価ボードにWiPortを乗っけると強制的に9800bpsに通信レートが変更される」という驚愕の仕様が発覚した。
道理で通信が繋がらないわけだが、もう一度WiPort周りの基盤を作りなおして実験をやり直さねばならなくなった。
posted by Yasuski at 03:40| H8/Midi
2012年10月01日
H8関連の備忘録２：
BaudRateConverter機能を持たせたH8/3052ボードで使用するアセンブルプログラムについて。
送信データの不具合を解決するために、Main内のloopを以下のように改変した。
tx_midi_checkルーティンを各データ入力ルーティンの直後に挿入することで、スタック領域へのデータ退避・復旧プロセスによって生じる送信データの混乱を回避している。
@rx_midi_checkでは周波数の異なるSCIを襷掛けにしてBaudRateの変換を行なっている。 受け：31250baud 送り：34800baud にBaudRateを設定している。
loop:
jsr @rx_midi_check
jsr @tx_midi_check2
jsr @sampling_00
jsr @sampling_01
jsr @sampling_02
jsr @sampling_03
jsr @analog_check
jsr @tx_midi_check
jsr @digital_check
jsr @tx_midi_check
jsr @wdt_start
jsr @program_change_signal_check
jsr @pgm_number_set
jmp @loop
送信データの不具合を解決するために、Main内のloopを以下のように改変した。
tx_midi_checkルーティンを各データ入力ルーティンの直後に挿入することで、スタック領域へのデータ退避・復旧プロセスによって生じる送信データの混乱を回避している。
@rx_midi_checkでは周波数の異なるSCIを襷掛けにしてBaudRateの変換を行なっている。 受け：31250baud 送り：34800baud にBaudRateを設定している。
loop:
jsr @rx_midi_check
jsr @tx_midi_check2
jsr @sampling_00
jsr @sampling_01
jsr @sampling_02
jsr @sampling_03
jsr @analog_check
jsr @tx_midi_check
jsr @digital_check
jsr @tx_midi_check
jsr @wdt_start
jsr @program_change_signal_check
jsr @pgm_number_set
jmp @loop
posted by Yasuski at 01:11| H8/Midi
2012年08月03日
H8関連の備忘録：
H8関連の備忘録：
今回の改変ではデータレートコンバートのため不使用だったsci1の出力を復活させたが、その影響で必要となったデータロード用のアドレス指定ポインタに使うレジスタが足りなくなった。
開発過程で発生した諸々の問題は新たに組み直したレジスタの使い回しルーティンを失敗していたことが原因。 従来はスピードアップを目指し、特定のレジスタをsciへのデータ転送に専有させていたが、このデータをRAM領域に退避させることで、Txポインタ専用レジスタ r0 を確保した。
以下、レジスタの使用用途を整理しておく。
r0 Tx2用ポインタ
r1 汎用レジスタ/主にデータ読み出し用に使用
r2 汎用レジスタ/バッファーへのデータ転送に使用
r3 汎用レジスタ/プリセットデータ読み出しに使用
r4 Rx1用ポインタ
r5 Rx2用ポインタ
r6 Tx1用ポインタ
r7 スタックポインタ
特に問題が発生していたスイッチ・ポートの状態をセンスする部分に新設したバッファーは、 sw_status8、 bit_counter、 tx_buf、 tx2_buf、 の4種。 これらのバッファーとレジスタ/R2でデータのやりくりを行っている。
以下、該当するコードの改変部分の説明を：
_dc_loop_4:
4番ポートのデータセンシングを行うループ。
mov.b @pdat4,r3h ; r3h is current port data
mov.b @(ports_01,er1),r2l ; r2l is previous port data
mov.b r3h,@(ports_01,er1)
xor.b r3h,r2l ; r2l is now update flag
mov.b r2l,@sw_status8
メモリにステータス・データをコピー
mov.b #0,r2h
mov.b r2h,@bit_counter ; r2h is a counter
各ビットを順送りでセンスするカウンターの値を記憶させる
bra _check_bits
;>>>>> inner loop top
_check_bits:
mov.b @sw_status8,r2l
ループ内で上書きされて失われたレジスタの初期値を転送。
mov.b @bit_counter,r2h
ループ内でカウントアップされたアドレスをレジスタに転送。
btst r2h,r2l ; checking the update flag
beq _next_bit
変化がなければ、カウンタを回して次のビット判定に移動。
sub.l er3,er3
mov.b @bit_counter,r2h
mov.b r2h,r3l
mov.b @port_counter,r2h
add.b r2h,r3l
mov.b @(setsw,er3),r2h ; uploading sw setting
スイッチのセッティングをプリセットデータから読み出す。
cmp.b #0,r2h ; checking the data flag
bne _program_cng ; branch when z flag = zero
bra _control_cng
結果を判定して、送信するデータのタイプを選択。
_control_cng:
mov.b @cc,r2l ; sending controll change status
mov.b r2l,@tx_buf
送信バッファーにデータをストレージ。
jsr @tx_fifo_set
mov.b @(setcnt,er3),r2l ; uploading control change default number
mov.b @ccnum,r2h ; uploading preset cc number
add.b r2h,r2l ; plus offset preset number
mov.b r2l,@tx_buf
jsr @tx_fifo_set
#CCを送信バッファーに格納。
mov.b @(ports_01,er1),r2l
mov.b @bit_counter,r2h
btst r2h,r2l ; checking the bit"n" sw status
beq __set_off
mov.b #h'7f,r2l ; set 127 value
bra __set_st
__set_off:
mov.b #h'00,r2l ; set 0 value
スイッチの状態を判定して、オンオフの値を入力。
__set_st:
mov.b r2l,@tx_buf
jsr @tx_fifo_set
bra _next_bit
送信バッファーに値を入力して、次のビット判定に。
以下、プログラムチェンジの送信。
_program_cng:
mov.b @pgm,r2l ; sending program change status
mov.b r2l,@tx_buf
jsr @tx_fifo_set
mov.b @(setcnt,er3),r2l ; sending program change number
mov.b @pgnum,r2h
dec.b r2h
add.b r2h,r2l ; plus offset preset number
mov.b r2l,@tx_buf
jsr @tx_fifo_set
_next_bit:
mov.b @bit_counter,r2h
add.b #1,r2h ; counter plus 1
mov.b r2h,@bit_counter
カウンターを1繰り上げて、バッファーにデータを再収納。
cmp.b #8,r2h ; detecting full count
bne _check_bits
8ビット分の状態を判定＆送信し終えたら、次のポートに移動する。
;>>>>> inner loop end
_next_port:
mov.b @port_counter,r3h
add.b r3h,r2h
mov.b r2h,>@port_counter
sub.b r2h,r2h
add.l #4,er1
cmp.l #4,er1
beq _dc_loop_2
cmp.l #8,er1
beq _dc_loop_3
cmp.l #12,er1
beq _dc_loop_4
;<<< outer loop end
rts
今回の改変ではデータレートコンバートのため不使用だったsci1の出力を復活させたが、その影響で必要となったデータロード用のアドレス指定ポインタに使うレジスタが足りなくなった。
開発過程で発生した諸々の問題は新たに組み直したレジスタの使い回しルーティンを失敗していたことが原因。 従来はスピードアップを目指し、特定のレジスタをsciへのデータ転送に専有させていたが、このデータをRAM領域に退避させることで、Txポインタ専用レジスタ r0 を確保した。
以下、レジスタの使用用途を整理しておく。
r0 Tx2用ポインタ
r1 汎用レジスタ/主にデータ読み出し用に使用
r2 汎用レジスタ/バッファーへのデータ転送に使用
r3 汎用レジスタ/プリセットデータ読み出しに使用
r4 Rx1用ポインタ
r5 Rx2用ポインタ
r6 Tx1用ポインタ
r7 スタックポインタ
特に問題が発生していたスイッチ・ポートの状態をセンスする部分に新設したバッファーは、 sw_status8、 bit_counter、 tx_buf、 tx2_buf、 の4種。 これらのバッファーとレジスタ/R2でデータのやりくりを行っている。
以下、該当するコードの改変部分の説明を：
_dc_loop_4:
4番ポートのデータセンシングを行うループ。
mov.b @pdat4,r3h ; r3h is current port data
mov.b @(ports_01,er1),r2l ; r2l is previous port data
mov.b r3h,@(ports_01,er1)
xor.b r3h,r2l ; r2l is now update flag
mov.b r2l,@sw_status8
メモリにステータス・データをコピー
mov.b #0,r2h
mov.b r2h,@bit_counter ; r2h is a counter
各ビットを順送りでセンスするカウンターの値を記憶させる
bra _check_bits
;>>>>> inner loop top
_check_bits:
mov.b @sw_status8,r2l
ループ内で上書きされて失われたレジスタの初期値を転送。
mov.b @bit_counter,r2h
ループ内でカウントアップされたアドレスをレジスタに転送。
btst r2h,r2l ; checking the update flag
beq _next_bit
変化がなければ、カウンタを回して次のビット判定に移動。
sub.l er3,er3
mov.b @bit_counter,r2h
mov.b r2h,r3l
mov.b @port_counter,r2h
add.b r2h,r3l
mov.b @(setsw,er3),r2h ; uploading sw setting
スイッチのセッティングをプリセットデータから読み出す。
cmp.b #0,r2h ; checking the data flag
bne _program_cng ; branch when z flag = zero
bra _control_cng
結果を判定して、送信するデータのタイプを選択。
_control_cng:
mov.b @cc,r2l ; sending controll change status
mov.b r2l,@tx_buf
送信バッファーにデータをストレージ。
jsr @tx_fifo_set
mov.b @(setcnt,er3),r2l ; uploading control change default number
mov.b @ccnum,r2h ; uploading preset cc number
add.b r2h,r2l ; plus offset preset number
mov.b r2l,@tx_buf
jsr @tx_fifo_set
#CCを送信バッファーに格納。
mov.b @(ports_01,er1),r2l
mov.b @bit_counter,r2h
btst r2h,r2l ; checking the bit"n" sw status
beq __set_off
mov.b #h'7f,r2l ; set 127 value
bra __set_st
__set_off:
mov.b #h'00,r2l ; set 0 value
スイッチの状態を判定して、オンオフの値を入力。
__set_st:
mov.b r2l,@tx_buf
jsr @tx_fifo_set
bra _next_bit
送信バッファーに値を入力して、次のビット判定に。
以下、プログラムチェンジの送信。
_program_cng:
mov.b @pgm,r2l ; sending program change status
mov.b r2l,@tx_buf
jsr @tx_fifo_set
mov.b @(setcnt,er3),r2l ; sending program change number
mov.b @pgnum,r2h
dec.b r2h
add.b r2h,r2l ; plus offset preset number
mov.b r2l,@tx_buf
jsr @tx_fifo_set
_next_bit:
mov.b @bit_counter,r2h
add.b #1,r2h ; counter plus 1
mov.b r2h,@bit_counter
カウンターを1繰り上げて、バッファーにデータを再収納。
cmp.b #8,r2h ; detecting full count
bne _check_bits
8ビット分の状態を判定＆送信し終えたら、次のポートに移動する。
;>>>>> inner loop end
_next_port:
mov.b @port_counter,r3h
add.b r3h,r2h
mov.b r2h,>@port_counter
sub.b r2h,r2h
add.l #4,er1
cmp.l #4,er1
beq _dc_loop_2
cmp.l #8,er1
beq _dc_loop_3
cmp.l #12,er1
beq _dc_loop_4
;<<< outer loop end
rts
posted by Yasuski at 06:54| H8/Midi
2006年01月18日
H8系マイコンをMIDIに活用する
Tinyシリーズはコンパクトな造りが魅力だが、Web上にはMIDI工作に関する情報が意外とアップされていない。 TinyシリーズはSCIやタイマー系の構造が若干異なるために、既存のH8用プログラムをTinyに移行するにはその辺りの修正が必要だ。
Tiny導入の過程で不安定だったAD入力を改良した。
以下に示すコードを1ユニットとして4サンプリング分のデータを取得する。
sampling_00:
sub.l er1,er1
sub.l er2,er2
sub.l er3,er3 ; AD port counter (r3l)
mov.l #adda,er2 ; vector addr of adah
_samp00_loop:
bclr #5,@adcsr
mov.b r3l,@adcsr ; preset the AD control register
bset #5,@adcsr ; start convert
_wait_samp00:
btst #7,@adcsr ; wait for AD complete
beq _wait_samp00
bclr #7,@adcsr ; clear the AD complete flag
mov.b @er2,r1l ;uploading AD data
extu.w r1
mov.w r1,e1
sub.w r1,r1
mov.b @(samp_00,er3),r1l ;old AD data
extu.w r1
add.w r1,e1 ;add all data and div by 2
sub.w r1,r1 ;clr
mov.b #2,r1l
divxu.b r1l,e1 ;r1 contains meaned ad data
mov.w e1,r1
mov.b r1l,@(samp_00,er3) ;stock the latest data
inc.b r3l ; AD port counter
cmp.b #8,r3l
beq samp00_end
add.l #2,er2
cmp.l #addd,er2 ; vector addr for addh
ble _samp00_loop
mov.l #adda,er2 ; vector addr for adah
bra _samp00_loop
samp00_end
rts
ADデータを送信する前に取得した4サンプル分を平均化する。以下、AD送信ループからの抜粋。
_ad_loop:
mov.b @(samp_00,er3),r1l ;uploading AD data buffer
extu.w r1
mov.w r1,e1
sub.w r1,r1
mov.b @(samp_01,er3),r2l
extu.w r2
mov.w r2,e2
sub.w r2,r2
mov.b @(samp_02,er3),r1l
extu.w r1
mov.b @(samp_03,er3),r2l
extu.w r2
add.w e1,e2 ;add all data and div by 4
add.w e2,r2
add.w r2,r1
sub.w r2,r2
mov.b #4,r2l
divxu.b r2l,r1 ;r1 contains meaned ad data
sub.b r1h,r1h
mov.b @(ad_old,er3),r1h
mov.b r1l,@(ad_old,er3)
この機能を実装した後は、ライブが随分と楽になった。
posted by Yasuski at 02:13| H8/Midi
