Unlit 塗りしてるあいだはいいんだよな
kb10uy(@kb10uy@mstdn.maud.io)の投稿
あ、じゃあ「読みが だ で始まる漢字で始まるトゥート」をしようとして Shift じゃなくて Ctrl を押してしまったというやつかもしれない
多分何かトゥートしようとしたときに間違って Ctrl+B を押してしまってブクマの名前を入力する状態になったしまったんだろうな
ちなみにみなさんのナツキ・イラストはほぼ全部ブクマに保存していて特に数が多い人についてはフォルダ分けしていたんですが、いつだかのブクマ同期の拍子にそれらが全部「他のブックマーク」に flatten されて 
になったという思い出があります
元の Crypko の画像、後ろ髪の長さをいかようにも解釈できるの想像の余地を適切に残していて僕は好きですね
それとも USB ハブみたいにインテリジェントなコントローラーが載ってる場合は電圧/電流が適切に制御されるので大丈夫というやつなんだろうか
@kb10uy トポロジー的にはなりますけれど、変換アダプタと違ってハブはそれ自体がデバイスなのでハブ自身で適切に処理する必要があります。（USB-C R2.0でいうと4.7と4.8あたり）
それとも USB ハブみたいにインテリジェントなコントローラーが載ってる場合は電圧/電流が適切に制御されるので大丈夫というやつなんだろうか
@omasanori Cメス - Aオス の変換と同等になってしまうのではないかという懸念というか疑問があります
それはそれとして x1ポート に追加で周辺ボードを差してもすぐに グラボが x16 じゃなくなるわけじゃないのか
@omasanori それはそうで、よくある A オスが upstream の USB ハブに C を追加できたらいいのにねという話が発端だった
これなんですが、USB-C R2.0 2.6 Hubsに “USB hubs implemented with USB Type-C receptacles are required to clearly identify the upstream facing port. This requirement is needed because a user can no longer know which port on a hub is the upstream facing port and which ports are the downstream facing ports by the type of receptacles that are exposed, i.e., USB Type-B is the upstream facing port and
USB Type-A is a downstream facing port.” とあるので、Type-Cレセプタクルがついているハブは規格に反しません。
/cc @pikepikeid @kb10uy
PCIe から まず USB 3.1 喋る Key-A 20pin を生やさないといけないのではになてり
50%の確率で表が出るコインを2回投げたら必ず表が1回は出る理論ほんとすき
https://mstdn.jp/@POGO/104465920095362417
このアカウントは、notestockで公開設定になっていません。
今更なんだけどつなげたままで直角に面が折れてるところを 4〜8 分割でベベルしたほうがよかったかもしれない
Overlay で頂点の法線を表示して変な方向向いてなければ大丈夫(たとえばその場所なら真上)
このアカウントは、notestockで公開設定になっていません。
ちなみに Windows は最近 Windows API ガン無視して NT kernel のシステムコールを叩くアプリケーションが増えてるみたいで，Linux に特定のメモリ領域のシステムコールだけフックする機構の追加などが提案されている >> Emulating Windows system calls in Linux [LWN.net] https://lwn.net/SubscriberLink/824380/25ad0afe31766ee1/
素直さよりも拡張とモジュール性により多くの人が利用しやすいオープンプラットフォームとしての側面が強い気がする
実用的な例として、Cコードを出力するタイプのコンパイラは末尾呼び出し最適化を実装するときにallocaを駆使してスタックを対象にGCすることがあって、それが壊れる
レジスタウィンドウ、盛ると関数コールが速くなって削るとコンテキストスイッチが速くなるのバランス間隔が必要そう
ちゃんと while みたいな等価なコードに変換されるものだと思ってたけど確かにスタックフレームを積まずに上書きしてもできはするな……
SPARCはプログラミング言語処理系開発者にとって重要な意味があって、あの命令セットアーキテクチャではサブルーチン呼び出しにレジスタウィンドウという機構を使うので、スタックに積んでいくのを前提にした素朴な末尾呼び出し最適化（tail-call optimization; TCO）の実装が正しく動かない
このアカウントは、notestockで公開設定になっていません。
ということは 完全に入れ替わってるわけじゃなくてクリップボードにコピーする瞬間だけ入れ替わってるのか
avahi が入ってるならホスト名固定しちゃえば hostname.local でアクセスできたりしない？
とはいえ最近の USB 通信とコンピューターは十分に高速なので、本当に GPIO と電源しか生えてないようなボードをホスト PC で鬼のように bit-bang してもそこそこ使い物になりそうだな
やっぱり電子工作のおたく的にはダイレクトな I/O とかも少しぐらいは残っててほしいところだね
あとはやっぱり映像出力とかか。 NTSC 信号とか作るのはまあできても肝心の受像装置が順調に消えていってるし、VGA もいつまで生きてるかわかったもんじゃない
まあ最近は動作電圧で書き込みもできるマイコンばっかりなので電圧レベル変換がいらないのが助かりますね
もはや歴史資料みたいな感じだけどこういうのがあって、純正の数千円するライタを買わなくてもなんとかなったのでけっこう人気があったっぽい
http://startelc.com/PIC/Pic_RCD.html
このアカウントは、notestockで公開設定になっていません。
まだパソンココに パラレルポートが付いていたころ、パラレルポートの直接制御とそのやや高めの電圧を利用して直接 PIC に書き込んじまえという電子工作が流行っていた
いまどきのオタクは VCC TX RX GND しか使わんしなんなら格安 USB シリアルモジュールはその 4ピンぐらいしか出てないからな
だいたいそういうやつです(FT232 の例でいえばフル機能のシリアルポートとしてではなく 数ピンの GPIO として H/L を直接操作できるという感じの)
このアカウントは、notestockで公開設定になっていません。
有名な例を挙げると、ARM マイコンの書き込みツールとして名高い(?) FlashMagic は FT232 をシリアルポートとしてではなく FT232 として扱うことで、今日日誰も使わないシリアルポートの制御ピンをリセットピンや ISP モードピンとして bit-bang して楽に書き込みができる
問題というか謎なのはなぜ 1ch で同じように動作すると思われる FT232 などに擬態しないのかというところですね。 FT232 だって一部の他のポートを bit-bang することはできるのに……
つまりシリアルポートとしてではなく GPIO として bit-bang することで書き込み時の K210 のモードを制御してる
CH552T も 2ch なんですよ。じゃあ 2ch 目は何に使ってるんだという話ですが、 RST と BOOT に繋がってる
2ポート出るのは正しくて、それはさっき言ったとおり FT2232 として認識されてるからなんですが
このアカウントは、notestockで公開設定になっていません。
本物の FT2232 はこれ
http://akizukidenshi.com/catalog/g/gM-02990/
実際に 2ch 目が動作するかどうかは別として(多分しない)、 FT2232 は 2ch USB-Serial 変換 IC なので FT2232 だと思ったら無条件に 2 本生やすのかもしれない
かなりどうでもいいんですけどさっきのスクショの色配置は適当じゃなくてちゃんとスクランブルしてるので解けます(?)
僕はこの OLL は「由」の甲種と覚えているんだけど英語圏だと headlights と言うらしい(?)
(R U R' U')x3 で揃えるやつ右向きだけじゃなくて左向きでもできると持ち替えが少なくなってよさそうだな
ひっかかり以外にも回す手順は確定してるのに迷ってしまうところがたまにあるのでそれをなくしていきたい
