（このネタをXに振るのはまだ時期尚早なのでこっち）ジェネリック医薬品の生物学的同等性試験にある、AUC/Cmaxのパラメータだけ抜き出してまとめたデータベースがあったらいいな、ということでちょっと作業を始めてみました。実はどこかで既に出来上がっていたりして。

ジェネリックレビューでやっている、効果量による評価 http://generic-rev.com/article/kiso.php で使うのが主たる目的なんですが…

どうもパラメータを見てると、同じ薬品を何社かで（ラベルを変えて）出しているニオイもしますね…こういうのは何処かがコケるとつられて他のメーカーもコケるというパターンになりそうな気がするのですが。 https://github.com/jg1uaa/ge-aucdb/blob/dev/ge-aucdb.csv#L7445

このアカウントは、notestockで公開設定になっていません。

東京都に対し情報工作を行い、弱体化をしなければという周囲４件の思惑にもかかわらず、東京都は今もまだその力を誇示し続けている…どの県から送り込んだ諜報員も、帰ってきた者がいないのだ。 #何かを受信

町田市を巡る神奈川県兵 vs 東京都兵の戦いは日々激化しており、都県境の封鎖は当然として横浜線・京王線の運行にも支障が出ているなど云々 #何かを受信

このアカウントは、notestockで公開設定になっていません。

STM32F103のGPIO PA11/12とUSB D+/D-ピン、GPIOのpin configurationのAlternateFunctionで切り替えるのかと思っていたんだけどどうも自動的に切り替わる…ってこれ本当なんすか？

> once you enable the USB module, PA11 and PA12 automatically are "hijacked" by the USB module. input/output mode or AF doesn't matter.

http://www.chibios.com/forum/viewtopic.php?t=4586#p32541

//Pin PA11,PA12=LOW, USB Resetの項目は活かして、LONG_USB_RESETの有無は今後評価するとして、その後のところは削除で良いんだと思う。

config/ZUMspot_USB.hからSEND_RSSI_DATA, SERIAL_REPEATER(_BAUD), LONG_USB_RESET, ENABLE_DEBUGを除いて、上の改造を施している。他のconfigだとどうなるかも調査が必要かも。

とりあえず一歩進んだか。

https://github.com/juribeparada/MMDVM_HS/blob/master/IOSTM.cpp#L327 Mode_IN_FLOATINGの設定を行わせないようコメントアウトすると動くようになる。

逆に、LONG_USB_RESETの前にあるMode_Out_PPの設定を行わせないようコメントアウトすると（Bit_RESETの有無は関係ない）動かない。

bootloaderの、GPIO_Pin_11/12のこの辺の設定がどうなっているかを一度確認してみる必要があるかも。

メモ：USB Full-speedはD+を、Low-SpeedはD-を1.5kΩでpull-up（本当はUSB仕様書を見れば良いけど面倒なのでこっちにリンク）

https://www.macnica.co.jp/business/semiconductor/support/faqs/silicon_labs/109673/

STM32F103内部にあるGPIO pull-up/downは30k～50kΩくらい。代用にはならないはず。

https://www.st.com/resource/en/datasheet/stm32f103c8.pdf

おはよーございます。

ちょっとまだ試していないんですが、多分この辺が怪しい気がします。

https://github.com/juribeparada/MMDVM_HS/blob/master/IOSTM.cpp#L311

GPIO11/12のMode_Out_PPを設定したら、USB-CDCの初期化をすべて完了した後にMode_IN__FLOATINGにしないとマズいんじゃないかなあと考えています。

この想定が正しかったとすると、とりあえずの修正は可能そうですがSTM32Libと連携した修正を考えると厄介です…

bootloaderはちゃんと接続/解除を制御している感じなので、「何か」はあるんだと思う。

という訳で寝ます。Twitterと違って長々と書けるから考えをまとめるのが楽だ。

generic_boot20_pc13_long_rst.bin
ZUMSPOT_ADF7021
LONG_USB_RESETは指定せず

この組み合わせでも、GPIO_WriteBit(GPIOx, GPIO_Pin, Bit_RESET)の有無に影響しない。

USBモジュールの初期化がきちんと行われてからPC側にデバイスの存在を通知すりゃいいんじゃね？と思っているのだけど…

https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/config.h を見るに、TARGET_GENERIC_F103_PC13ではUSB_DISC_BANK/PINが未定義になっているのでGPIOでの制御はしていないと考えるべきか？（USBモジュール側の操作で完結というかなんというか）

今テストした組み合わせ（動いてない）

generic_boot20_pc13_long_rst.bin
LIBRE_KIT_ADF7021
LONG_USB_RESETは指定せず

JumboSPOTってZUMSPOTの完全なコピーなのかなあ。それとも一部だけな（改変してる箇所がある）のかなあ。回路図があれば良いんだけど…

STM32F10X_Lib/usb/usb_cdcacm.c、usb_cdcarm_enable()のGPIO_WriteBit(GPIOx, GPIO_Pin, Bit_RESET)をコメントアウトしても何も起きない。…となると、一体どこでUSBデバイスとして接続されたことをPC側に通知する(D+/D-のpull-upだかdownだかの制御をしている)んだろ？

もう一つ分かっているのは、ST-Link経由で給電している場合はUSBポート側で抜き差ししてもPC側ではMMDVMの存在をちゃんと検出できるのに対し、USBポートのみ使う場合はbootloaderのみ検出できる。なーんかヘンなバグが居る。

で、購入時のファームウェアは問題ないんだけど何故か今は配布されていない、とか。

LONG_USB_RESETの有無は（今のところ）関係なさそう。USBアナライザで見たところでは、bootloader→MMDVM_HSに切り替わった直後のUSBリクエストにだんまりを決めていることは分かっている。

bootloaderはgeneric_boot20_pc13.binではなくgeneric_boot20_pc13_long_rst.binを使った方が良さそう。Maple純正でも試してみたいけど、FlashROMの空きが無いのでできない。