自作回路でUSB EndPoint5 [無断転載禁止]©2ch.net
>>107
>「SV2、SV3はともにオープンにします」の誤記?
失礼しました、その通りです。
>そこを切り離したらダメですよ。グランドは繋がないと。
ダメと言われても、お蔭様で期待通りに動いています。
>これぐらいでも動くのですね…。
GNDについては配線が複雑になるので、ご指摘の通り手を抜いてます。
>FT245のリードライトピンって受け付けるスピードが速いので、遅いTTLの感覚で
遅いTTLですので仮想COMモードでTTL側のタイミングで動かしてます。ビットバングモードでは判りません。
>>109
貴君の素晴らしい基板の例を公開して下さい、参考にしますので。 >>109
とりあえず繋げましたーってだけのパターンだね
>>110
・電源線や電流が流れるラインは太く
・GNDはできるだけ広く
・同一面で引けるならできるだけ同一面
をやるだけでもだいぶマシになると思います >>110
ググれば山ほど出てくるから少しは考えてやってみ
本も2,3冊買って読め >>111
>・電源線や電流が流れるラインは太く
判りました、この基板の改訂版で太くしてます(既に太くしてます)。
現在は初期値の4倍の太さにしてますが初期値の太さでも外部電源だと安定してます。
>・GNDはできるだけ広く
結局、最初の内容と同じですよね?
電流の流れは電子の流れを便宜的に逆にしたものと定義してますので。
KiCADではGNDは広くするオプションがあるようですけどeagleで見つけられなくて。
>・同一面で引けるならできるだけ同一面
eagleにある自動配線で最初の配線図は作っていますけどピッチ間に3本あると
流石に気持ち悪くて「via」にして最大でも2本にしてますけど骨折損でしたか。
昔、回路図が判らなくて業者に製作代行を頼んだ基板は同規模の回路で
「via」が40個あっても動いたので「via」が、この程度あっても支障ないと考えてました。
因みに貴方は自分が誰なのか検討付いてますよね?
そのうちブログに時期を見てお邪魔します(荒らしに行くと言う意味ではないです) >>111
>・電源線や電流が流れるラインは太く
判りました、この基板の改訂版で太くしてます(既に太くしてます)。
現在は初期値の4倍の太さにしてますが初期値の太さでも外部電源だと安定してます。
>・GNDはできるだけ広く
結局、最初の内容と同じですよね?
電流の流れは電子の流れを便宜的に逆にしたものと定義してますので。
KiCADではGNDは広くするオプションがあるようですけどeagleで見つけられなくて。
>・同一面で引けるならできるだけ同一面
eagleにある自動配線で最初の配線図は作っていますけどピッチ間に3本あると
流石に気持ち悪くて「via」にして最大でも2本にしてますけど骨折損でしたか。
昔、回路図が判らなくて業者に製作代行を頼んだ基板は同規模の回路で
「via」が40個あっても動いたので「via」が、この程度あっても支障ないと考えてました。 済みません、ちょうど訪問客が来て同じことを2度書きました。 >>110
> >そこを切り離したらダメですよ。グランドは繋がないと。
> ダメと言われても、お蔭様で期待通りに動いています。
え?切り離したときに動いているんですか?
>>105を見る限りは、切り離したときにちゃんと動作していないように見えます。
>FT245RLのJ2をオープンにしてSV2、SV2はともにショートさせ安定動作してます。
>J2はショートにし、SV2、SV2はともにオープンにします。このケースで誤動作が生じます。
上の二つの行の中の「SV2、SV2」が両方とも「SV2、SV3」という解釈をしたら、
SV3がオープンの状態、つまりグランドを切り離したときに誤動作しているように見えますよ。
切り離していたら「必ず動作しない」とは限らず、なんとなく動作することもあるのです。
要するにグランドが切り離されたふたつの回路のグランドがある電圧に収まっていれば
いいわけで、一方の出力のどれかがLであれば、そのピンを通じてグランド電位がある
程度の範囲に収まってしまうこともあります。
>遅いTTLですので仮想COMモードでTTL側のタイミングで動かしてます。ビットバングモードでは判りません。
あー。そうではなくて、
FT245のRD、WRにグリッチなどの短いノイズ状パルスが入るとFIFOが誤動作しますよ。
グランドがしっかりしていないとありうるよ、ということです。
これは仮想COMかダイレクトドライバかは関係がありません。
(ビットバンモードの方が鈍感に使えるとは思いますが) >>113
>KiCADではGNDは広くするオプションがあるようですけどeagleで見つけられなくて。
最近のEagleのユーザーインタフェースがどうなってるのか分からないけれど、
https://www.youtube.com/watch?v=NOKgwPF91Ow
参考になるだろか。 当たり前だけど、FT245もその秋月のモジュールも、USBからの電源供給でちゃんと動作しますよ。
供給可能な電流を超えない範囲、というのはもちろんですが。 >>167
貴方の「そこ」と言う部部を9ピンのグランドと勘違いしました。
>「SV2、SV2」が両方とも「SV2、SV3」という解釈をしたら、
「SV2、SV2はともに」は(1)も(2)も間違いで「SV2、SV3はともに」が正解です。
(1)の前提が外部電源で安定すると言ってますので「SV2、SV3はともにショート」です。
>>117
ありがとうございます。のちほど参考にします。
>>118
>USBからの電源供給でちゃんと動作しますよ。
具体的な回路次第で違うと考えます。GNDを共通にしない別電源で惨々誤動作してましたので。
別電源ならGNDを共通にする必要があると認識してます。
自分の基板では次の実験ができますが、とりあえず(3)で安定してるので良いかなと言う心境です。
(1)TTL回路とFT245RL(USB)を別電源にしてGNDは共通にすること(実験してません)
(2)TTL回路とFT245RL(USB)を別電源にし双方のGND、VCCは遮断すること(誤動作することを確認済み)
(3)外部電源にして同一のGND、VCCをTTL回路とFT245RLに接続すること(安定動作を確認済み) >GNDを共通にしない別電源で惨々誤動作
それは当たり前のことなのです。
アイソレータを使わない限り、信号グランドを接続せずに動作させるものではありません。
>具体的な回路次第で違う
いろいろな回路はあると思いますが、グランドを接続しない回路は除外して良いのです。
でも、あなたは「グランドを接続しないと何がそんなにいけないのだろう」と今でも思っているのかな? >>121
>それは当たり前のことなのです。
4ヶ月前に、その御言葉が欲しかった。
今は巡り合わせで仕方ないと気持ちは整理できてますけど。
自分の誤動作の原因は既に>>100と>>102で言ってます。 > 自分の誤動作の原因は既に>>100と>>102で言ってます。
これは失礼。くどくなってしまいました。 電源のグランドを共通にするとは
・グランド同士を電気的につなぐ → 回路によってはつながないと動かない
・グランド同士をつないでから1本の線で接続する → 外れたら怖い 色々批判はあるけどネットで公開されてるFT245RLの使用例は大半がLチカ等で有難味が薄いと感じてました。
なので今回のような基本を抑えるためにも建設的なレスの応酬はかなり役に立ったと思います。
自分にとっては既に決着が付いていたので、めんどーと感じながらも役に立つ情報が提供されて有り難かった。
因みにFT245RLの取扱説明書には恐らく間違いだろうと言う箇所はあるけど未だ訂正されていません。
http://akizukidenshi.com/catalog/g/gK-01799/
PDF取扱説明書
http://akizukidenshi.com/download/kairo/データ/RS232・USB関係/L025_FT245RL USBパラレル.pdf
「ライト」時の「WR to RD Pre-charge Time」では意味が判らない。「WR to WR Pre-charge Time」の誤植でしょう。
(本家の英文マニュアルでは「WR to WR Pre-charge Time」となっています)
更にはUSB電源と外部電源の使い方の説明はあるけど取扱説明書には別電源にした時にGNDを共通化する説明はないです。
別電源でGNDを共通にした場合のトラブル発生で対応の煩雑性を懸念し、あえてこの使い方は触れなかった可能性もあり。
そう言う状況を勘案すれば今回のやりとりは、ある意味で取扱説明書を超えた内容だとも、とらえることができます。 >別電源にした時にGNDを共通化する説明はないです。
いや。だからそれは前提だし。
別電源にした時にGNDを共通化しないってことは原則的にないので、言及する必要がないのです。
グランドの接続については初心者スレで続きをやりませんか。USBの話題でもないので。 各社のUSB内蔵マイコンでUSBイーサネットアダプタとして
動作するようなフレームワークを提供しているベンダーは
ありますか? github のstm32ecm ですね。ありがとうございます。 だれかOSXなりWindowdで実際に動いてるCDC-ECMデバイスの
接続後のUSBパケットダンプを晒してくれたら神 既製品のクローン(ホストから見た基本的な動作は同じ)を作って同人ハードとして売ったらヤバイよなぁ オリジナルのソフトウェアと組み合わせ使うなら完全にアウトだろうけど
そうじゃないならワンチャン もちろんオリジナルのソフトウェアで使う。ぶっちゃけゲーム機のコントローラのクローン
同じ事を考えている人は他にもいると思うが それが問題になるなら任天堂非公認コントローラーとか全部アウトだろ
情報の入手方法と特許に気を付ければ大丈夫だと思うが なるほど、コントローラーで同人ならまあ逃げ切れるだろ
てっきりSaleaeのロジアナみたいな物をイメージしてた 国内のサードパーティで非ライセンスのコントローラを売っているところってあったっけ?
Amazonとかで聞いたことのないメーカー製は見かけるけど
今のところ考えつく問題点は
1.互換性のためには純正コントローラのクローンが好ましいが、PID/VIDはもちろんディスクリプタに
含まれる文字列も使い回す必要がある(対象となる機器の会社名等を含む)
2.公式は見逃してくれるかもしれんが、他の脅威として自称正義の味方ちゃんがいる
3.ライセンスされているコントローラを乗っ取ればこの辺は解消するが信頼性が低下する上に単価は上がる
ググると出てくる自作コントローラはこの方式か。しかし売り物になるレベルで信頼性を確保するのは難しそう・・・
あたりか。既成のコントローラにない物理的なUIを追加する都合上MCUは必須。既成のコントローラを使う場合は
基板が2枚以上の構成になる。根本的なところで同人ハードの頒布はいろいろ負担が大きいというのもあるし
>>136,137
情報ソースはネットで出てくる解析記事とパケットのキャプチャになるかな。それで十分かは未確認だけど
特許は・・・どう調べれば良いんだろうか。個人や零細レベルで精査する方法とか思いつかない >>138
有名なところだとサイバーガジェットじゃないかな
あそこはチートソフトも扱うようなゴロだし というか他人様のディスクリプタを使い回してもめたとかの前例はあるんだろうか
>>139
確かに少ないながらコントローラなども扱っているようですね
製品のディスクリプタってどうなっているんだろうな >>140
SCSIだけどNECプロテクトって言うのがあった
すぐ回避策が出たけど
https://www.wdic.org/w/TECH/NECプロテクト USB-TTLのPL2303コピー品は有名だなhttps://www.amazon.co.jp/-/dp/B075M766MW/とか
最新ドライバでははじかれるコード10エラー
回避策はあるあが どうして単純バルク転送を標準クラスに含めなかったんだろう シリアルは標準クラスじゃね?
Windowsの標準ドライバは10まで無かったけど 同人でUSBデバイスを売っている人ってベンダーIDどうしてんだろうな なんかその話前にもしたな
使ってるチップメーカーからPIDだけもらうか
失効してて再割り当てがないであろうVIDをこっそり使うしかってところ チップメーカーのペリフェラルIDをもらうのは使うマイコンが限定されちゃうよな
失効しているベンダーIDってどうやって調べれば良いんだ
PC周辺機器メーカーでUSBデバイスを作っていてかつ倒産したところか
すぐ上の人が話しているような現役メーカーのIDを使う勇者はおらんのか?w 家の中でだけ使って、公開もせず、完成HWの頒布もせず。
なので好きにしている。 勝手に使う用の PID なんかもあるみたいね。
勝手に使うことを公言してるから、無理やり避けさせてる、みたいな。
もちろん、全くもってまともな方法ではないけど。 >>144
> どうして単純バルク転送を標準クラスに含めなかったんだろう
ちょっと実装規模が大きいけど SCSI Bulk only かな
Windows 8, 10 以降だけと winusb microsoft os descriptors と言うのが使えて
inf ファイルなして winusb.sys が当たる。libusb で扱えるようになるので、
プロトコルは bulk, interrupt なら好きに作れるはず。isoc は少し難しいかもしれない。 ドライバ書くのは良いけど署名めんどかったし良さそうだねぇ VIDはコンソーシアムの認定を取るには必須だけど、他人のVIDを勝手に使ったからといって
法的な問題になるかは微妙だと思う。恐らく問題ないんじゃないか
>>144
そもそもデバイスクラスが定義するのはOSI階層モデル的な意味でもっと上位の階層だと思うんだけど
まあ、FTDIのD2XXみたいな生のエンドポイントのread/writeに近いようなAPIが
あってもよかったはずとは思うけど そういうのは避けたかったんじゃないかな…
従来のシリアルやパラレルとの差別化的にも
PnP的にも
アプリケーションが判断しなきゃならないデバイスになっちゃうし ハード自作の話じゃないんだがWindowsでHIDのゲームパッドをCreateFileで開いて
ReadFile、WriteFileで読み書きできないのだろうか
これが出来ればPS3のコントローラなどを野良ドライバ無しで使えそうなんだが
普通?のHIDデバイスと同じようにやってみたらCreateFileで開けるものの
WriteFileが成功せずGetLastError()=87になってしまった コントローラの類は触ったことないけど
HIDデバイス扱うなら、HidD_SetFeatureとかHidD_GetFeatureとかじゃないっけ ありがとう。そんな物もあるのか。ググっていたらHidD_SetOutputReportというのもあるらしいですね
試してみます。入力ならRaw Inputとかも使えそうなんですけどね USB同人ハードを細々と売ってるけど、VID/PIDはEEPROMの設定を読むようにして
売るときは0x0000にしてるわ。
「設定ツール使って好き勝手に設定してね。なおXXX社のXXXのVID/PIXは
XXXらしいよ。でも勝手に設定する分には自分で責任持ってね」 Xboxの社外品コントローラーには純正品を接続する端子付きのものがあって、
どうやら本体との接続時にその純正品のVID/PIDで接続させたあと、
それ以降の通信を乗っ取っていたようだ。 USB4.0はThunderbolt3ベースぽいね >>161
PS4みたいに強固な認証機構を持ったプラットフォームでもその方法を使えばライセンス上の問題も回避しつつ作れそうだな
純正のコントローラーをディージーチェーンする故に何でもというわけにはいかないだろうけど
最近のマイコンはホスト機能付きUSBコントローラーが2個載っていたりするし結構簡単に作れそう >>163
意欲さえあるんなら壁なんか少しづつ壊して行けばいい。
今週は電子回路、来週は半田付け、再来週はマイコンってな感じに。 というか>>163じゃ何が判らないのか判らないからアドバイスのしようがない アドバイスくれと言ってるわけじゃなく愚痴を言ってるだけだと思うけどw
USBそのものが結構複雑だし、加えてマイコンとUSBコントローラの
使い方も覚えるとか、まあ年単位の時間が掛かるよねたぶん 電子工作初心者で市販できるレベルを目指すなら年単位でかかるかもしれないけど
ある程度マイコンを含む電子工作が出来て自分が使うだけだったらそんなにかからないだろう
ゲームコントローラーだったら既製品を解析して参考にするのがおすすめ
※既製品といえども適切に実装されているとは限らないので盲目的にパクるのはおすすめしない cypress買収されたみたいだけど、EZ-USB FXシリーズは大丈夫かなw 富士通スパンションサイプレスインフィニオン
FROM使ってる・・・・ \(^o^)/ヲワタ 既存のスイッチをUSB化??ビット・トレード・ワン、「USB DELEGATER B」を発売へ | fabcross
https://fabcross.jp/news/2019/20190614_bit_trade_one.html FTDIのFT245RLをLinuxから使っていてwindowsに移植したけど
windowsのドライバよりカーネルに組み込まれてるLinuxのドライバが使い易い。
同じICでもドライバで微妙に違う。それともコンソール用のサンプルコードが雑なのか。 ブログは直リンクしないけどFTDIのwindows用ドライバを使った時の様子
https://imgur.com/a/gEcv6VJ
以前、貼ったリンク先からブログを突き止められたことがあるけど
自分もブログを突き止めた人も悪事を働いてる訳ではないので気にしてない。
今日は用事を済ませば画像サイトに貼った内容の説明をブログでする予定。 >>175
画面が意味するところが分からない。
C#のSerialPortで使ってるのだけど、115200bps以下の通信で、
あからさまなトラブルに遭遇していない。
Windows用のコンソールプログラムの問題?
TeraTermみたいなターミナルソフトでも問題は発生しますか? >>176
操作は中段の画像からが始まり、中段 → 下段 → 上段の順
1)windowsのフォルダー(ディレクトリー)にあるファイルを
読み込み通信相手に送信を始める。送信バッファが満杯になり停止。
(諸般の事情で1バイトを上位7ビット、下位7ビットに分割して
2バイトにして送信してる)
2)windowsと通信してる側で受信を始めたのでwindows側では
全データを送信した状態になる。またwindowsと通信してる側では
全データを受信したことを確認してる(下段の画像)
3)上段の画像は今度は逆にwindowsと通信してる側でデータを
windows側に送信し、windows側は受信したデータを表示してる。
このシーケンスはC++のサンプルコードと同じ。
因みにトラブルがあったとは言ってない、それぞれ固有のクセがあるけど。 Visual C++ のサンプルコードでも下のようになってるから
dcb.BaudRate = 115200;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
fSuccess = SetCommState(hCommPort, &dcb);
115200bps以下の通信が推奨なのかな。できればもう少し速くしたい。 すみません。176です。
誤解を与えるようなことを書いてしまいましたが、こちらの経験の範囲で
115200bpsを超えるビットレートでトラブルがあるというわけじゃありません。
.NETのSerialPortクラスと一緒に使ったとき、特定の文字コードを受けると
取りこぼしが発生する、みたいな話を昔の同僚から聞いたことがあるぐらいです。
その同僚がやっていたアプリは500kbps以上だったはず。 >>180
レス有難う。速度的な限界値は dcb.BaudRate を調整すれば
簡単にできるので確かめてみる。
理論値は VCP モードでも300Kバイト/sだけど100Kバイト/sでも御の字だし。 >>181
あ。すみません。デバイスはFT245でしたね。
>>180の同僚のアプリは、FT2232H のUARTモードのハンドシェークなし。
そのため、パソコンとFT2232H間が渋滞すると、UARTからの受信で取りこぼしが発生します。
FT245なら、パラレルI/Fの読み書きはハンドシェークが前提になるはずなので
全然事情がことなるかと思います。 >>182
丁寧な補足ありがとうございます。
自分は通信関係も詳しくないのですがハンドシェークとかフロー制御とか言う仕組みですか。
他の目的でも貼ってますけど回路図があると分かり易いと思うので貼っておきます。
https://imgur.com/a/ulNjzuD
下にあるロジアナの波形はハードに詳しい方から提供して頂いた画像です。
最初の基板が電源周り等も含めて稚拙だったので半田で補強してる状態です。
自分からすれば半田は上手いと思うのですけど言う人は「下手クソ」と酷評してます。
それで話しを戻しますがwindows側から送信したデータで取りこぼしはないです。
と言うのはwindowsと通信してる側で受信のタイミングを決定できますので
windows側はバッファに貯めている状況のまま相手が受信しなければ先に進みません。
また受信のタイミングはFT245RLのRXF#のフラグを見て決めますので受信データの
1ビット分を、このフラグの監視に転用してます。>>178の諸般の事情とはこの事です。
逆に通信相手からwindowsに送信する時は専用フラグTXE#を見ないで随時送信してます。
最初の基板では、そのフラグを見てたのですけどロジアナ波形から省略できると判断しました。
ただwindows用ドライバだと32バイトなりで連続受信してると32バイトの倍数では余る最後の
16バイト分弱の取り零しが発生してます。Linux用ドライバでは取り零しは発生してません。
今の所自分が使う環境での結論ですが、その他で大きな不都合はありません。
スレの目的が自作回路でUSBを使うための情報交換の場と認識してますので書きました。 △)自分からすれば半田は上手いと思うのですけど
○)自分からすれば半田が上手い人だと思うのですけど >>183
取りこぼすのが、Windowsのドライバの問題と結論付けるのは同意しかねる。
FT245は、もう古くて相当実績の多いデバイスだし、Windowsでも散々使われてるから、
今さらそんなに大きな不具合を初心者が簡単に見つけるとは思えない。 >>186
だよな。あと、ユーザーの方もLinuxよりWinで使っている奴が多いだろうし
Win用ドライバーはちょっと使うレベルでさえすら不具合発生する品質のものじゃないだろうな >>186
FT245Rには中国製のfakeがあるから、まず、純正のチップかどうかを確認するのが先。 正確には「取りこぼし」と言うよりカーネルにあるLinuxドライバとの違いかな。
クセを知った使い方をすれば「取りこぼし」はない。実際にハードとソフトを
製作すれば、どのようなことかは判るけど製作しない人には判らないと思う。 >逆に通信相手からwindowsに送信する時は専用フラグTXE#を見ないで随時送信してます。
>最初の基板では、そのフラグを見てたのですけどロジアナ波形から省略できると判断しました。
>ただwindows用ドライバだと32バイトなりで連続受信してると32バイトの倍数では余る最後の
OSの負荷が高いときは、USBのバルク転送は優先度が下がることがあるはずです。
FT245を使った周辺からPCへの転送であれば、FT245の内部のFIFOがいっぱいになることが
あるんじゃないですかね。
取りこぼしのないときのロジアナ波形を見て、TXE#を監視しなくても良いと判断されたのでしょうか。
この実験のように、大量のデータを連続して転送するような場合に、このフラグを監視せずに、
FT245への書き込みをするのは、ありえない気がします。 >>190
ご指摘は理解します。ただ運用方法・環境も関係すると考えます。
自分の環境では通信相手が低速なので今時のPCであれば取り零しは発生してません。
ですので通信相手が高速であれば当然TXE#の監視は欠かせません。
リンク先の「ロジアナ波形2」から理解できると思いますけど? >>190
普通のバルクINは、アプリから取りに行かないと転送されないから、
アプリのつくりが悪いとパソコンの性能がいくら高くても、確かにFIFOフルになる可能性はある。
でもこれアプリからは、COMポートに見えるインターフェースのようだから、
おそらく、そういう問題じゃないでしょう。 簡単設定でオリジナルUSBデバイスを製作??ビット・トレード・ワン、USB入力デバイス製作用モジュール「REVIVE USB Micro」発売 | fabcross
https://fabcross.jp/news/2019/20190620_bittradeone_riviveusbmicro.html >>185
俺も?なんだが、いまの5chはコミュ障な奴が多いから
読み手はエスパー能力が高くないと駄目だからな。
スタートが>>174のような独り言・愚痴(本人はこれで質問しているつもりなのかもしれないが)
ではコミュ取るの大変な感じがする >>191
>自分の環境では通信相手が低速なので今時のPCであれば取り零しは発生してません。
自分の環境では取りこぼしが発生していなくて、ある環境で、
↓のような取りこぼしが発生している、ということでしょうか。
>ただwindows用ドライバだと32バイトなりで連続受信してると32バイトの倍数では余る最後の
>16バイト分弱の取り零しが発生してます。
>リンク先の「ロジアナ波形2」から理解できると思いますけど?
いや。ぜんぜんそれでは分かりません。
それは取りこぼしが発生していないときですよね?
うまくいっているときの波形を見て、うまくいかないときの状況を想像してはいけないと思います。
とりあえず、この問題が発生しているときの状態を観察するべきかと思います。
転送バイト数が32の倍数よりも余るぶんで発生しているということですが、全体ではどれぐらいの
サイズなんでしょうか。たとえばゼロの状態からスタートして全体が45バイトの転送でも取りこぼしが
発生しますか? 既視感があるなあと思ったら >>99-128 あたりの人ですかね?
FT245RのモジュールのGND(SV3)は接続されているでしょうか。
読むとわかりますが、このときの方は、実験でうまくいったらうまくいくものだ、って感じ
の方でした。 >>195
あなたは>>117氏ですか? そうなら先ずはお礼を言います。
動作確認はしてませんけど、お陰様で基板の完成度が一皮むけた感じになりました。
(実際は一皮被せた感じですけど)
それで
・回路は公開してますから基本的には基板を製作すれば判ると考えてます。
・ある環境で、
汎用性品を目指してる訳ではないので自分の環境で動けば十分でしょう。
既に2名の方がパターン基板を製作していますけど問題報告はないです。
因みに一人はハード・ソフトのバランスが取れてる方、もう一人はハードも
それなりでソフト開発能力については抜きん出てる方です。
・ぜんぜんそれでは分かりません。
あなたが判らなくて納得させる義務はありませんが一応説明しますか?
捨てアドを先ずは貼ってくれれば更に説明はしますよ。もちろん建設的に。
この点は既に>>191で運用方法・環境も関係すると言ってますし、あらゆる
環境で使用に耐えることは考えてはいません。また多少の修正でTXE#の
監視もできるようにはなりますけど必要性が生じた時に対応します。
・取りこぼしについて
正確には「取りこぼし」と言うよりカーネルにあるLinux用ドライバとの違いで
コードの作り方で回避できます。同じICでもドライバの違いでクセがあります。
この点も既に>>189で言及してます。windows用ドライバには作法的な制約があります。
>うまくいっているときの波形を見て、
>うまくいかないときの状況を想像してはいけないと思います。
文章なのか中身なのか判別できませんが、伝わり難い表現です。
「うまくいっているときの波形を見て、どのような条件下でも
うまくいっているときの波形と同様の波形になると予測しては行けない」
って趣旨でしょうか? 確かに、それは「独善」と言います。
>この問題が発生しているときの状態を観察するべきかと思います。
現在は問題が発生してませんので現状で考察すべきことはないです。
それで>>174の趣旨は、ドライバでLinux用とwindows用の両方の経験した方から
使い方の違いで情報を共有したかったのですけど、その前に質問が始まりました。
それで繰り返しに成りますけど製作すれば判ると考えます。
製作をしないで情報を集めたいと言うのが人情かも知れないけど説明の義務はないので。 FTDIのドライバは初期の頃(2006年ごろかな?)はちょっと怪しい挙動も
あったけど、2010年頃には安定して使えるようになってたね
過去レス読んでないけど、本当に取りこぼしとやらがあるなら
真っ先に疑った方がいいのはデバイスのファームの方だろうな >それで>>174の趣旨は、ドライバでLinux用とwindows用の両方の経験した方から
>使い方の違いで情報を共有したかったのですけど、その前に質問が始まりました。
それなら、回路図ではなく両者のコード(回避策)も含めて開示しないと議論にならないんじゃないですかね? ありゃ。おかしくなってた。
×両者のコード(回避策)も含めて開示
○両者のコードを回避策も含めて開示 前と同じ人だったんだ。
結局のところ、FT245モジュールのGNDと他のロジックICのGNDは接続されました? >>199
>それなら、回路図ではなく両者のコード(回避策)も含めて開示しないと議論にならないんじゃないですかね?
お前はコードもと思うんだろうが、
本人は回路図、波形、そして、今までの書き込みで十分,使い方の違いで情報を共有できたと思っているよ
ほんとコミュニケーションは難しいよな >>199
>両者のコード(回避策)も含めて開示しないと議論にならないんじゃないですかね?
両者のコードって一瞬、貴方のコードを提示してくれるのかと考えたけど
そうではなく windows用 とLinuxの両方を提示すれってことですか?
別にあなたのレビューは求めてませんし、更には貴方は一方的に実体験に
基ずいてない質問をしてるだけと言う印象しかないので、このままの状況なら
質問に応えても自分にとっては収穫ゼロの状況です。
>OSの負荷が高いときは、USBのバルク転送は優先度が下がることがあるはずです。
それと貴方が情無い人だとコレで認識しました。優先順位を上位に設定できますよね。
USBのバルク転送でも優先度が下がる設定で使わなければ良いだけの話しでしょう。
バルク転送で優先度が下がる環境でも取りこぼしなく、って言うのは別の話しになります。
>GND
1年前から接続してます。と言うかFT245RLに関しては外部電源5Vで使ってます。 >>202
とは言え既に、この基板を使ってソフト面で凄い機能を作った人が現れてます。
悔しいのは昔のPC用ですが、そこはともかくFT245RLの使い方は習得できます。
FT245RLに関してはLEDを輝らして終りのサイトが大半ですから全然身になりません。
と言うことで、キーワードでググれば、有名なサイトでコードは発見できます。
運悪く自分のブログを最初に発見した時でも、そこからはリンクを貼ってあります。
ただし、まだプロトタイプかも知れないのでキツいツッコミされても困惑すると思います。
不具合がある時は、ここを直して欲しいと優しく指摘して下さい。
>本人は回路図、波形、そして、今までの書き込みで十分,使い方の違いで情報を共有できたと思っているよ
有用情報を出したくないけど口出してして有用情報を収穫しようとする人達の巣窟と認識しました。
windows用とLinuxの両方のドライバを使った人がいないなら自分が長いする理由はないです。 >有用情報を出したくないけど口出してして有用情報を収穫しようとする人達の巣窟と認識しました。
有用情報を収穫以前に、
あんまりコミュ出来ないめんどくさいそうな人がなんか必死にあーだこーだ言っているななだろ。 >有用情報を出したくないけど口出してして有用情報を収穫しようとする人達の巣窟と認識しました。
・・・GNDを繋がなければうんぬんの人から得られる有用情報ってw
この人生きてくのに苦労していそう USBマイコンとかを売っているメーカーからHIDデバイスを作るサンプルコードが提供されていたりするけど
あれって基本的にUSB規格に準拠している(コンプライアンステストをパスする)と考えて大丈夫なの?
特にサスペンド等まじめに実装されてなくても実用上支障ない部分も含めて。調べていくと結構大変そうらしい
そもそもこれらをこう実装すればコンプライアンステストに合格するって資料がないみたいな話すら出てくるし コンプライアンステストは、ほとんどハード側の話しで
ファームウェアでどうこうって部分はあんまりなかった気がするけど
個人的な経験としては、
CypressFX2使ったセルフパワーデバイスで
VBUS来てないとき、D+/D-に電圧かけないように処理したくらい