2009年09月11日

V-USBのライセンス

V-USBのライセンス
V-USBのライセンスについて少し調べてみた
個人や商用で使うときにライセンス料が必要かどうか。

まずV-USBのトップページから見てみた

点線内は"部分引用"と訳
----------------------------------------------------------------------
1.
http://www.obdev.at/products/vusb/index.html

V-USB can be licensed freely under the GNU General Public License 
or alternatively under a commercial license.

V-USBは「GPLライセンス」と「商用ライセンス」のどちらかでライセンスされる。


2.
http://www.obdev.at/products/vusb/license.html

Commercial Licenses for V-USB
商用ライセンスとは

If the terms and conditions of the GPL are unsuitable for you, 
e.g. because you don't want to publish the source code of your firmware, 
you can simply pay money for a commercial V-USB license.

GPLの条項があなたにとって適切でない場合-
例えば、「ファーム」のソースコードを開示したくない場合は
お金を払えば商用ライセンスとすることができる。
-----------------------------------------------------------------------
上記1.は「デュアルライセンス」であることを明示している。 以下の方のページが非常に分かり易い。デュアルライセンスとGPL ここでGPLを選択すればファーム書込み済みの機器を何台販売しようと V-USBのライセンス料を払う必要はない。 これは例えばLinuxカーネルを内蔵したルータ機器がLinus氏やGPLソフトの著作者に ライセンス料を払っていないのと同じ形態だといえる。 当然GPLの下で「ファーム」のソースコード開示が必要。 企業の場合、改変内容を含めたV-USBのソースコードは大抵公開したくないはずで、 販売後にソースコードを開示できないとGPL違反になってしまうので それを避ける選択支として「商用ライセンス」を用意してあることになる。 これが上記2.だ。(他にもメリットがあると書いてあるが) 以上のようにV-USBの場合 GPLを選択してソースコードを開示すればファーム書込み済みの機器を何台販売しようと V-USBのライセンス料を払う必要はない。 当然、商用ライセンスで得られるメリットに魅力を感じるなら予算に応じて ライセンスを購入してもよいだろう。 重要: 追加事項に注意: 開示の範囲・方法 V-USBに同梱されている「License.txt」の冒頭には追加事項がある。 この追加事項がかなりあやしい雰囲気を醸(かも)し出している。 以下一部を抜粋(さらにその一部を訳す)
In addition to the requirements in the GPL,
we STRONGLY ENCOURAGE you to do the following:
GPLの要求事項に加えて以下を行うことを"強く推奨"する。

(1) Publish your entire project on a web site and drop us a note with the URL.
Use the form at http://www.obdev.at/vusb/feedback.html for your submission.

(2) Adhere to minimum publication standards. Please include AT LEAST:
    - a circuit diagram in PDF, PNG or GIF format
    - full source code for the host software
    - a Readme.txt file in ASCII format which describes the purpose of the
      project and what can be found in which directories and which files
    - a reference to http://www.obdev.at/vusb/

(3) If you improve the driver firmware itself, please give us a free license
to your modifications for our commercial license offerings.
まず「License.txt」などという仰々(ぎょうぎょう)しい名前のファイルの中に 「強く推奨する」などと腰の引けた表現を用いるのはなぜか。 それはさておき(オイ (1)はいいとして(2)の太字の部分は 「ホスト側(通常PC側)のソフトのソースコードを公開しろ」 といっている。(あくまで"強い推奨"だが) まぁ、ソースコードを公開すればいいと。 ここで気になる点がある。例えば V-USBを利用した「プロジェクトH」は「Hさん」が開発し、 「ハードウエアH」の回路図、「V-USBの改変ファーム」(「ファームH」)を含み GPLと上記追加事項を満たしているとする。(「ハードウエアH」は「ファームH」を含む) さらに「PC(ホスト)側のソフト」(「PCソフトH」)も独自開発して完備している。 ケース1: 全然関係ない北海道在住の「Rさん」が「プロジェクトH」の「ハードウエアH」を 制御する「PC(ホスト)側のソフト」(「PCソフトR」)をスクラッチから開発し 「PCソフトR」のみを公開や販売した場合、 「PCソフトR」のソース開示は必要なのか? この場合はV-USBのライセンス及びソースコードと全く関係ない。 100歩ゆずって、強(し)いて関係あるとすれば。。。 やっぱり関係ない(爆 なので「PCソフトR」のソース開示は必要ない。 ケース2: さらに「Rさん」。自分で「プロジェクトH」の基板を起こして「ファームH」書込み済みで 「PCソフトR」と"あわせて"パッケージ販売したい場合。 当然ライセンス料無料のGPLを選択する。 この場合「プロジェクトR」が発生したと考える。なぜなら「Rさん」は「プロジェクトH」 のGPLライセンスに基づきバイナリファイル(基板上のファームH)を 配布(販売)することになるからだ。すなわち上記「License.txt」内の追加事項も適用される。 そこでまず 追加事項を満たすため「プロジェクトH」のサイトにリンクを貼っておき 「OBJECTIVE DEVELOPMENT」に通知する。 「プロジェクトH」はGPLプロジェクトなので「Rさん」のサイトに「プロジェクトH」の ファイル群を置くのが正しい方法だ。(GPL2参照) この場合「PC側のソフトR」のソース開示の推奨度は大きいといえるだろう。 ケース3: さらに全然関係ないアキバ系の「Aさん」。 「プロジェクトH」の成果を利用し「ファームH」を書き込んだ「ハードウエアA」だけを販売する。 当然ライセンス料無料のGPLを選択する。 やはり「プロジェクトH」のサイトにリンクを貼り 「OBJECTIVE DEVELOPMENT」に通知する。 「プロジェクトH」はGPLプロジェクトなので「Aさん」のサイトに「プロジェクトH」の ファイル群を置くのが正しい方法だ。(GPL2参照) このパターンが一番簡単に低コストで商売ができる。 ケース4: これが最大のヤマ場。 ケース1の「PCソフトR」(ソース未公開)をケース3のAさんのホームページから 購入できるようにした。ただし秋月電子のページのようにそれぞれの商品は個別に ページを持ち相互にリンクされ関係が簡単に説明されている。 この場合「PCソフトR」のソースコード開示の有無は? 逃げ切れると思う(オイ というか、やはり「Rさん」はV-USBのバイナリを配布していないので関係ない。 Aさんに対して「PCソフトR」のソース開示要求(推奨)が発生するかどうかだが。 さらに 完全オリジナルの「PCソフトX」を「強い推奨」に従って公開するとする。 ところがこのときの「ソース・ライセンスの指定がない」のだ。 従って公開はするが「ガチガチのライセンス」にすることも可能である。 と、いうわけでいろんなケースがあるにはある。 追加事項の表現ではカバーできない状況といえる。 では最後の追加事項
(3) If you improve the driver firmware itself, please give us a free license
to your modifications for our commercial license offerings.
ファームを改良したら我々が提供する「商用ライセンス」で使えるように
修正部分の使用ライセンスを無償提供して下さい。
最初これは何を言いたいのかさっぱり不明だった。(日本語もアレだけど(^^; さらに「Please」(プリーズ)などと場違いな単語。これは何かある。 ある時突然ひらめいた。 これもケーススタディで。 ケース5: 「Qさん」はV-USBのソースを使った「プロジェクトQ」を 「商用ライセンス」(ソース非公開)の予定で開始した。 しかし技術的な問題が解決できず停滞。偶然、上記「プロジェクトH」が開発した 関数群を使えば簡単に解決できることがわかりそのままの形でとり込んだ。 「プロジェクトH」はGPLプロジェクトなのでそのソースを取り込んだ「プロジェクトQ」も GPLになりソース開示が必要で「商用ライセンス」(ソース非公開)が 成立しなくなるのだ。 これを回避できるのが上記(3)の追加事項なのだ。 そう思って(3)を読むと"たちどころに"理解できるだろう。 ただこれGPLの根幹が崩れ去っているような気がする。 と、いうか、これがデュアルライセンスのキモになるところか。 この矛盾がアレなのでMySQLなんかでは貢献度の大きな人を雇い入れているという 話もあるらしい。 確かCygwinもデュアルライセンスで「ソースを出せないなら金をだせ」だっけ? (オイ 以下まとめ
選択したライセンス ライセンス料 ソース開示 備考
V-USB V-USB PC(Host)側
GPL 無料 必要 必要(*1) 商用目的でも無料。"追加事項"に従う
商用ライセンス 有料 不要 不要 追加メリットあり
(*1):本文参照 また以下の文書には無料で提供され無料で使用できるUSB IDをうまく 共有するための注意点やUSBロゴなどの注意点等々が書いてある。 USB-ID-FAQ.txt USB-IDs-for-free.txt 参考リンク: GPLに対するオトコの個人的見解 http://nippondanji.blogspot.com/2009/04/gpl.html Redhatの反撃:まずは自社株買い戻し (サブスクリプションで検索) http://blog.sasapurin.com/archives/cat2/unix/linux/redhat/ Red Hatサブスクリプションのからくり Red Hatが反撃体制、3億2500万ドルの株式・転換社債の買い戻し http://slashdot.jp/linux/comments.pl?sid=338431&op=&threshold=1&commentsort=3&mode=thread&pid=1048603#1048656
posted by Copyright (C) avrin All Rights Reserved. at 01:40| Comment(0) | TrackBack(0) | AVR系 | このブログの読者になる | 更新情報をチェックする

2009年06月06日

AVRアセンブラ(2):アセンブラでEEPROMを読み書きするマクロ

AVRアセンブラ(2):アセンブラでEEPROMを読み書きするマクロ
avrasm2.exeのマクロでEEPROMを1バイト読み出すマクロを書いてみた。
まずはレジスタ変数を定義
.def accA        =    r16  ; アキュムレータA
.def accB        =    r17
.def rtempA      =    r18  ; テンポラリ用
.def rtempB      =    r19 
使い方はaccBに読み出したいEEPROMのアドレスを入れる。 読んだデータはaccAに得る。
;EEPROM  0番地のデータをaccAに得る
    ldi accB,$00          ; EEPROMアドレスをaccBに設定
    readep accA,accB      ; accAにデータを得る。
という感じで 特定の1バイト読むだけなら「見た目、2行で書けるマクロ」 accBは8ビットなのでアドレスは256バイトまで。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;* EEPROM mReadep/mWriteep    EEPROMから1バイト読む
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.macro mReadep ; @0: register read data  @1: register EEPROM address
    mWhileTruei EEWE,EECR    ; 書込み中でないことを確認
    out EEAR,@1              ; 読出しアドレス設定
    mSetBit EERE,EECR        ; 読出し
    in @0,EEDR               ; 結果をレジスタにコピー
.endmacro 
上の1行目のEECRレジスタのEEWEビットが1の間ループするマクロmWhileTrueiは さらに
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;* mWhileTruei ioレジスタのbitno=1の間ループ 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    
.macro mWhileTruei ; @0:bitno, @1:io
lp0:
    mifTruei @0,@1
    rjmp lp0
.endmacro 
となっていて、上のmifTrueiマクロはさらに
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;* mifTruei bit=1で直下を実行 for io
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    
.macro mifTruei ; @0:bitno, @1:io
    .if @1<$20
        sbic @1,@0
    .else
        in rtempA,@1
        mif0skipr @0,rtempA 
    .endif
.endmacro 
と書ける。IOアドレスが$1F以下ならsbic命令が使えるが $20以上だと一旦IOデータをレジスタに読むのでsbrc命令 が必要になるが、そんなこと覚えたくないので以下のようにマクロ化する。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;* mif0skipr bit=1で直下を実行 for io
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;    
.macro mif0skipr ; @0:bitno, @1:reg
    sbrc @1,@0
.endmacro 
上のマクロもなんだか意味不明だがマクロの中でしか使わないので覚える必要もない。 最初のmReadepマクロの中には以下のビットセットマクロがある。
    mSetBit EERE,EECR 
これはEECRレジスタのEEREビット目を1にセットするマクロ。 中身はこう
;;;;;;;;;;;;;;;;;;
;* ビットセット mSetBit    //io,sram (レジスタ以外)
;;;;;;;;;;;;;;;;;;;
.macro mSetBit ; bitno:@0 , io:@1
    .if @0>7
        .message "error: ビット番号が不正"
    .endif
    .if @1>$3F                        ; $40番地以上なら、
        lds    rtempA,@1                    
        ori    rtempA,1<<@0        
        sts @1,rtempA
    .elif @1<$20
        sbi @1,@0
    .else
        in rtempA,@1
        ori rtempA, 1<<@0
        out @1,rtempA
    .endif
.endmacro 
このビットセットマクロはよく使うのでエイリアスとして
#define setBit(bitno,io)    mSetbit bitno,io 
と定義すると、
setBit(EERE,EECR) 
のようにC言語風に書ける。これでもアセンブラ行ですよと。 #defineで定義すると「大文字、小文字を急に区別するようになる」ので 注意が必要。「.macro ... .endmacro」は大文字、小文字は無視するが、 #define文では区別されるのでいい加減に書いてエラーが頻発して悩んだ。orz さらに「.macro ... .endmacro」マクロ中で「#define」で定義したものは使えないのだった。 などと、長々とアレだけど実際に「mReadep」ではき出されるコードはたったの5ステップ(5word、10byte)しかないので マクロ化でOKでしょう。 5ステップくらいなら「書けよ」という話ではなく、 「いかにアセンブラ命令を覚えないで、アセンブラを使うか」 という趣旨なのでこれでOKなのだった. 次はEEPROM書込みマクロ。
.macro mWriteep ; @0: register write data  @1: register EEPROM address
    mWhileTruei EEWE,EECR    ; 書込み中でないことを確認
    m_di                     ; 全割り込み禁止
    out EEAR,@1              ; 書込みアドレス設定
    out EEDR,@0              ; 書込みデータ設定
    mSetBit EEMWE,EECR       ; 書込みマスター許可
    mSetBit EEWE,EECR        ; 書込み開始
    m_ei                     ; 全割り込み許可
                             ; 8.3msecの書込み時間が必要
.endmacro 
使うときはaccAに書込みデータ、accBにアドレスを入れて
        ldi accA,$78
        ldi accB,$0A
        mWriteep accA,accB 
mWriteepで実際にはき出されるコードは8ステップ(8word,16byte)なので複数箇所で呼び出すときは 当然サブルーチン化したほうが良い。
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;* m_ei/m_di    enable/disable all interrupt
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
.macro m_ei 
    sei
.endmacro
.macro m_di
    cli
.endmacro 
*ソフトからEEPROMを書き込む時の注意点* AVR本体のプロクラム内からEEPROMの書込みができるわけだが、 ソフトがバグって最短書込み時間である8.3msecで延々と特定の1バイトを 書き続けることになった場合、 EEPROMの書き換え寿命は10万回なので 10万回 x 8.3msec = 約14分 たったの14分でEEPROMが壊れることになるのだ。 くれぐれも気をつけるべし
posted by Copyright (C) avrin All Rights Reserved. at 17:58| Comment(0) | TrackBack(0) | AVR系 | このブログの読者になる | 更新情報をチェックする

2009年05月27日

AVRアセンブラ(1): avrasm2.exeをふまじめに使う

AVRアセンブラ(1): avrasm2.exeをふまじめに使う
AVRアセンブラのavrasm2.exeを使ってみた。
これはAVR-Studioをインストールするともれなく付いてくる。

AVRのアーキテクチャは素直でいい子だって話なのでアセンブラも
そうらしい。

汎用レジスタが32個ありますなどというが実際は全部
8ビット幅のレジスタなのはがく然としてしまうのだった。

8ビットマイコンなんだなぁ

今まではavr-gccが吐いたASMコードを「ざっと」(詳細不明のまま)ながめて
冗長なところをやっつけてコードサイズを削る手法だったが
ちょっとアセンブラで遊んでみる。

ところで、avr-gccの「インライン・アセンブラ」の仕様はひどすぎると思う。
見にくすぎ。

mikroCが吐いたPIC用のASMコードを以前見てみたがPICのASMには
関わりたくない感じがした。

で、AVRのavrasm2.exe。
全体的には素直でいい子なんだけど
実は、
R0〜R15 と
R16〜R31
でレジスタに一部対称性がない。アーキテクチャの仕様なわけで
まぁいんだけど変なところでケチってる感じ。

*ビット操作がやりにくい*
そもそもRISC風なんでアレだけど。
1.R0〜R31のビット操作命令。例の非対称性により
    R0〜R15まではビット操作命令がないのだ。
    R16〜R31にはある。(ORI,ANDI相当)
    なのでR0のビット3を1にしたい場合、R16のビット3を1にして
    R0にコピーするなどの行為が必要になる。
2.i/oレジスタも0〜$1F番地のものにはビット操作命令使えるが
    $20以降のものには使えない。orz
3.当然SRAMを直接イジル命令はない。

x=R27:R26,y=R29:R28,z=R31:R30
という16ビット長のレジスタになるので
結局100%力を発揮できるのは
R16〜R25の10個となる。が、
10個もあれば  十分、十分。つかR0〜R15も80%くらいの力で
使えるわけで。

あ。どうせアセンブラをまじめに覚える気はサラサラなくて。
なぜなら、覚えてもPICや違うマイコンに使えるわけじゃなし。

したがって、

マクロ命令を使いまくって、まるでアセンブラに見えないような
ソースコードにしちゃうのが目的の一つなのだ。

例えば
rjmp  label  →  goto  label
rcall label  →  gsub  label
ret          →  return
とマクロ化すれば、「rjmp,rcall」などというデバイス固有の 命令を覚える必要もないのだ。 avrasm2.exeはC言語のプリプロセッサに対応したので、
#define func() gsub func
と定義すると、アセンブラのソースコードは
main:
    bar();
    func(); 関数を実行
    foo();    
    return;
などと書けるのだ。「;」以降はコメントなので完璧。 「うっ! まるでC言語!!」 *アキュムレータの定義* 実際、ASM文を書き始めるとテンポラリ的なレジスタを頻繁に 使うことになるのでこれを
.def accA = R16
.def accB = R17
とアキュムレータA,Bと定義する。チカラ100%の R16以降を割り当てるのが必須でしょう。 *割込み処理では必ずSREGを保存する* 割込み処理を適当に書いて実行させたらどうも 挙動不審ギミ 結局原因はSREGの保存忘れだった。(基本中の基本) SREGをほかのレジスタに保存、復帰するやり方を見かけるが、 それは激しく非推奨。
.def save = r2
として
int_timer0_ovf:
    mov save,sreg
    〜
    割込み処理
    〜
    mov sreg,save
    reti
上は非推奨。上が正しく動くのは多重割り込みをしないときだけ。 将来、多重割り込みを許可した途端、かなり挙動不審になる。 つか、バグの温床。 正しくは
int_timer0_ovf:
    push accA
    in accA,sreg
    push accA
    〜
    割込み処理
    〜
    pop accA
    out sreg,accA
    pop accA
    reti
とする、「push sreg」と素直にできないのもちょっとorzだが。 割込み中でSREGを保存しないのは 論外*ビットセットマクロ* 結局、マイコンはビットセット命令がいかに簡単に短く高速にできるかに かかっている。(ホントカヨ 78k0なんてビットセットをアセンブラで3バイト命令で6クロックかかるけど
set1 mem.bit 
と書ける。(メモリのbitを1にセットする命令) memは160バイトの高速RAM空間, SRAMにじかにビットセットできるです。 これは強力78k0。 「人間」がアセンブラ使うときはこうでなきゃだめっしょ。
set1 sfr.bit
set1 a.bit
[HL].bit
てのもある。2バイト命令で10クロックかかる。 良い点は命令が統一されていて非常に書きやすい。 78k0はRISCじゃくてCISCだな。 RISCってのは「人間」を切り捨てたってことだな。 それに比べてAVRはRISCなのでorz. なので自分用にビットセットマクロ作った。 作ったあとでHEROさんとこのアセンブラ資料を見てみると AVRdvtl.ZIP AVR000 AVRマイクロ コントローラ用のレジスタとビット名定義 AVR001 条件付アセンブルと可搬性マクロ の中にmacros.incてのがあって汎用に使えるビットセットマクロが ある。これを自分用にアレンジするのがよい。 ほかにもビットチェックジャンプなんかある。 自分用には全部作成済みだったので先にHEROさんページ見れば よかったorz. *オペランドの判別ができない* マクロを作るとわかるけど、オペランドとして レジスタ(r0〜r31)と「i/o,sram」の区別ができないのだ。 これらのオペランドを「全て指定可能」なマクロを作るのは不可能なのだ。 78k0は命令レベルで全てのオペランドが取れるがAVRはマクロ化しても 実現できないorz. まぁ、分ければいいんだが。 SRAMに対するビットセット命令を見てみると
78k0:  
set1 mem.bit 3バイト6クロック
AVR:
lds r16,mem         4バイト2クロック
ori r16,(1<<bit)    2バイト1クロック
sts mem,r16         4バイト2クロック
               合計10バイト5クロック
78K0は3バイトで済むのにAVRは10バイト食って 「レジスタが1個犠牲」になる。orz それでも1クロックぽっち速いが。 「レジスタが1個犠牲」を許してはいけない。フェア?に比較するために r16は保存すべき。
AVR:
push r16            2バイト2クロック
lds r16,mem         4バイト2クロック
ori r16,(1<<bit)    2バイト1クロック
sts mem,r16         4バイト2クロック
pop r16             2バイト2クロック  
               合計14バイト9クロック
実は78k0も高速RAM使用なので汎用SRAMにすると。。。
78k0:
mov a,!mem          3バイト8クロック
set1 a.bit          2バイト4クロック
mov !mem,a          3バイト8クロック
                合計8バイト20クロック
AVRは14バイト9クロックなので圧勝! つか78k0の高速SRAM系のアクセスは強力だ。 お粗末でした(^^; やはりRISCは「人間」向きじゃぁないな。 リンク: AVRのアーキテクチャ解説ページ(日本語) AVR Goes On http://homepage2.nifty.com/sampodo/craft/avr.html 上のページ、メチャメチャ分かり易い解説。
posted by Copyright (C) avrin All Rights Reserved. at 00:48| Comment(2) | TrackBack(0) | AVR系 | このブログの読者になる | 更新情報をチェックする

2009年04月08日

AVRライタ:MOSIとMISOの接続メモ

AVRライタ:MOSIとMISOの接続メモ

*はじまり*
*AVRライタの「コネクタ端子」は同名のターゲット端子につなぐ*
*AVRライタの「コネクタ端子」の信号方向*
*AVRライタの「コネクタ端子」と「ターゲット端子」の接続図*
*HIDaspxライタの「コネクタ端子」と「ターゲット端子」の接続図*
*HIDaspxライタ#216基板のファームアップデート接続図*
*HIDaspxライタ#214基板のファームアップデート接続図*
*USBaspライタ#185基板の接続図*
*COM-SPI Bridgeライタ#173基板の接続図*
*HIDaspxライタ#216基板の回路図?*
*補足(1)2010年*

*ジャンパー設定  #216 基板*
*ジャンパー設定  #214 基板*


*はじまり*
AVRライタとターゲットをつなぐときの接続方法が実はよく分かってなくて
MOSIとMISOをよく間違えるのだった。

これは最初にブレッドボードでHIDaspxを作ったとき配線ミス多発で時間がかかったが
最後に残ったのがこの「MOSI、MISO逆接続問題」だったのだ。
「HIDaspxのTiny2313のMISO端子をターゲットのMISO端子につなぐ」と思いこんで
いたのだった。
その後も何度か間違えたので結局「よく分かってない状態」(^^;

HIDaspxの回路図のコネクタに端子名がないので思わず配線を追っかける。
見つけた信号名をターゲットの同じ信号名につなげてしまうというミスだ。

さらに「ISP用のMISO、MOSIはクロス接続となる」という記述の意味も
今ひとつ理解できなかった。これは、
「クロス配線が追加で必要」なのか
「単に回路の状態を指し示している」のか
「クロスという以上、クロスでない何かって何?」
と周辺知識が乏しいとなかなか難しい。

「WSNAK準拠」端子と回路図との対応も今ひとつ不明だった。

HIDaspxの場合回路図通りに配線したあと「WSNAK準拠」の端子を
同名のターゲット端子につなぐのが正解。

下の図はHIDaspxのコネクタの部分。


オリジナルはこちら。senshuさんのページ  HIDaspxの回路図と製作例

上の回路図のコネクタに「信号名と方向」を書き入れたものが以下の図。
ISP用のコネクタのみを示す。

「回路側」の信号名はTiny2313の端子名。
「ISP用のMISO、MOSIはクロス接続となる」という説明は上図の
*MISO → MOSI
*MOSI←MISO 
の部分をさす。
従ってライタとして使うときはCN2にストレートケーブルをつなぐ。
(CN2以降にクロス接続は発生しない)

上の図を見ると
回路側のMISO信号をターゲットのMISOにつなげていけないのは明らか。



ということで調査してみた。

*AVRライタの「コネクタ端子」は「同名のターゲット端子」につなぐ*
これは当然のような感じだが実際にこう書いてある記述は少ない。(ホントカヨ
「ライタの回路単独の図」、「コネクタだけの図」がほとんどなのだ。
データシートには端子名が出てくるがライタやコネクタは出てこない。
ということは当然書くまでもないことで

「ライタのコネクタ端子は同名のターゲット端子につなぐ」

でよいと思われる。
(一部例外があるのでデータシート参照のこと)

a. ATMELが発行しているAVR910.pdfという文書に図と説明がある。
b. デジット/共立の「AVRWRT」説明書の最後のページに接続図がある。


*AVRライタの「コネクタ端子」の信号方向*
これも直感的には「MOSIが出力、MISOが入力」で実際その通りだ。
SPIについてはデータシートにもあるが以下のChaNさんの図が分かり易い。
SPIのアーキテクチャ
AVRライタはライタ側がマスタになる。(あたりまえか(^^;)
従って
HIDaspxの回路図にある「ISP用のMISO、MOSIはクロス接続となる」
という説明は上のSPI通信のMOSI-MOSI、MISOーMISO接続に対して
「クロス」という意味になる。(データシートも参照のこと)

コネクタの端子名というのは「信号の方向が分からない」と
分かりにくい場合もあるのだ。

なので以降の図はしつこく信号の方向を示してある。

下の図がAVRライタの「書き込み用コネクタと信号名称と方向」の例である。
青い部分が「ISP方式のAVRライタのコネクタ」
黄色い部分がターゲットコネクタ(=ターゲットデバイスの同名ピン)
VCCは状況に応じた接続が必要。

これがWSNAK準拠という配列である。
「ライタ側のコネクタ端子名と、同名のターゲット(デバイス)端子」を接続する。
(mega系で例外あり。データシート参照のこと)

ここで重要なのは「コネクタの端子名称」が

ライタに内蔵されているデバイスの”端子名称"と一致するとは限らない

ということである。

例えばChaNさんの以下のライタの回路図でMOSI端子をみると
COMポート用ISPアダプタ回路図
「出力であるMOSI端子の機能を持った端子」
であることがわかる。これは例えばただのポートでも何でも
「MOSI相当の機能を実現した"何か"(出力信号線)」であればよいのである。
(3線同期式シリアル通信のマスタ側のデータ出力相当機能)

*AVRライタの「コネクタ端子」と「ターゲット端子」の接続図*

上の図が実際の接続状態を表す。
「ライタ内部のMOSI」は「出力であるMOSI機能を実現した何か」を表している。
このMOSI線が「ライタのコネクタ端子MOSIにつながっている」のである。


*HIDaspxライタの「コネクタ端子」と「ターゲット端子」の接続図*

ライタ内部の端子名は内蔵されているTiny2313の「実際の端子名」を
示している。
HIDaspxライタの場合
「MOSI信号線の機能をTiny2313のMISO端子で実現している」
のである。
内容についてはirukaさんのページにありました。


*HIDaspxライタ#216基板のファームアップデート接続図*

上の図はwS*Nakさんで販売している#216基板のファームを書き換える時の
接続図である。
この場合#216内のTiny2313はターゲットデバイスになるので
右側の(青色)AVRライタの「コネクタのMOSI端子」と
「ターゲットであるTiny2313のMOSI端子」がつながる配線となる。
(データシート通りの接続になる)
そのため上図のようにクロスケーブルを使う。

#216基板を作った時にもMOSI、MISOを間違えてしまったのである。
原因はwS*Nakさんの回路図にもあるのだった。←人のせい(オイ
この内容は後に記述する。


上の図は右側のライタをHIDaspxライタにした時の図である。


*HIDaspxライタ#214基板のファームアップデート接続図*

上の図はwS*Nakさんの#214基板のファームを書き換える時の図である。
この基板には「ファーム書き換え専用端子」があるので図のようにストレートケーブルで
書き込む。(基板内でクロスになっている)


上図は右側のライタをHIDaspxにしたものである。


*USBaspライタ#185基板の接続図*

この#185ライタは内蔵されているATmegaのMOSI端子そのものがライタのコネクタに
つながっている。


従って上のようにファームアップ時も同じコネクタ端子でしかも
「ストレートケーブル」で書けてしまう。

このライタを作ったときもMOSI、MISO接続わかってなかったので
「あれー?」
「何でこのライタは同じコネクタで」
「しかもストレートケーブルでファームアップできるんだ?」
↑
全然わかってないヤツ(^^;


*COM-SPI Bridgeライタ#173基板の接続図*

この#173ライタも
Tiny2313のMOSI端子が直接ライタのコネクタに出ているタイプ。


なので上のようにストレートケーブルでファームアップする。


ここまでわかれば「MOSI、MISOスレーブ間違いなし」
マスターだろっ!(バキッ





*HIDaspxライタ#216基板の回路図?*


上はwS*Nakさんのところにある回路図のコネクタ部分である。
たとえば左端の信号名「MISO」はTiny2313の「MISO端子」に直接つながっている。
この線はCN2コネクタの「MOSI端子」につながっているので上で調べた内容により
このコネクタCN2で「ストレートケーブル」を使うと
「#216基板がAVRライタとして動作する」ときの図になる。(B図)
ところがコネクタの下には
「PRG時は外部でMISOとMOSIを入れ替える」とある。
「PRG」は「Programmer=Writer」すなわちライタとして動作する時である。

自分が作った時は素直に(^^;書いてある通りに「外部でクロス」したので
ライタとして動かなかった。←MOSI、MISO問題発生

これは回路図のコネクタに「端子名称」と「説明(??)」が書いてあるので、
ある意味
「非常に分かり易い説明を見て、"誤配線"してしまうんです」 orz

さらにこのページには
「AVRライタとして利用する場合には、
ターゲットとの接続にはストレート・ケーブルを使用します。。。」
とあったりして回路図中の記述と矛盾した内容。←MOSI、MISO混乱中


「もう どっちでもいいや 動いたほうが正解だっ!!」

ていうのが当時の状態(^^;

orz

wsnakさんも回路図を書いた時点(人?)では自分と同じように勘違い
していたんじゃないかと妄想します、


で、
正常に動作するとライタを使い始めるのでMOSI、MISOがどーだのって
忘れてしまいがちなのだった。


*補足(1)2010年1月*

上記の表記ミスは現在wsnakさんで修正済みになっています。
修正は2009年9月くらい。



*ジャンパー設定  #216 基板*
hidaspx-216pwb-switch.jpg


*ジャンパー設定  #214 基板*
hidaspx-214pwb-switch.jpg

posted by Copyright (C) avrin All Rights Reserved. at 23:12| Comment(2) | TrackBack(0) | AVR系 | このブログの読者になる | 更新情報をチェックする

2009年04月05日

AVR: 鶏と卵ライタでLED ON/OFF実験





AVR: 鶏と卵ライタでLED ON/OFF実験




「鶏と卵ライタ」でAVRにLEDチカチカソフトを焼いて「チカチカ」させる実験である。

「鶏と卵ライタ」というのはライタ用のAVRなしでAVRにプログラムを書き込める
ライタなのだ。

「鶏と卵ライタ」の詳しい内容についてはsenshuさんのページを参照してください。
AVRライタなしでHIDaspx用のファームを書き込む方法

上のページでは「HIDaspx」ファームを書く説明ですがここでは
作った「鶏と卵ライタ」が正常に動作しているかをまず確認することにします。

実際に作った回路は上で紹介されている回路や定数を手持ちのアバウトな部品に
変更してあります。

この「鶏と卵ライタ」のウイークポイントはベリファイができない点である。
COMポートの先に何もつながっていなくても、ライタの回路配線を間違って作っても
正常に書き込めたかのように見えるのである。

正しく書けたのか、書けなかったのか確認が必要である。

そこで最低限、
「ぜんぜんダメ」なのか「何とか書けてそうだ」
というのを見分けるために「LEDをチカチカ」させて確かめようという話である。


たいした話じゃないけれど、結構確実なのである。



改造点:
1.電源用のLEDを電源用に使いつつLED点滅にも使えるように抵抗を1個追加して
  PD6に接続。
  (電源用のLEDをはずしてPD6につなげた方が簡単だった(^^;)
  もっと省略すればLEDなしでPD6にテスターつなげて見ると言う手もある。
  その場合点滅時間は1秒以上にした方がよい。
2.抵抗やコンデンサの値は手持ちで近い値を採用。
  5V電源の場合R3,R5は680Ωくらいが良いと思う。
680Ωのままで3.3V電源でも十分確認できた。
3.水晶発振器は回路にないが必要ならLED点滅が成功してから付ける。
  (何を書き込むかによる)

(ATtiny2313は新品相当のものを使用)

回路:
egg-chikken-led.gif



LED点滅ソフト:
1.BASCOM-AVRで以下のソースをコンパイルした。

$regfile = "attiny2313.dat"

$crystal = 1000000
Config Portd = &B01000000

Do
Portd.6 = 1
Waitms 500
Portd.6 = 0
Waitms 500
Loop

End


2.このHEXファイルをhidspxで書き込みます。
T2313-LED.zip

書き込み方法:
コマンドラインで
> hidspx -pf1 -ttiny2313 T2313-LED.hex 

と実行する。
「-pf1」はポート番号1なので各自のCOMポートに合わせて「-pf2」などとする。


動作確認:
書き込みが終わったら「Push SW」を押し続けると
「LEDがチカチカ」します。



実際のところの話:
Push SW持ってないのでワニクチワイヤで代用。

LEDが点滅するはずなのに、しない。(^^;

「この程度の配線間違うカヨ」というのはあるが

導通を確認すると「DSUB-9pin基板上」の配線がつながっていなかった。
な、なんと両面プリント基板なのにスルーホールになっていなかった。
かんべんしてよ(^^;

というか基板の使い方が裏表逆なんだろな(^^;
ワイヤリングして再度書き込みしたらチカチカした。 


十分役立だったってことか (オーーーイ


egg-chikken-hardware.jpg

posted by Copyright (C) avrin All Rights Reserved. at 13:38| Comment(1) | TrackBack(0) | AVR系 | このブログの読者になる | 更新情報をチェックする