[新]なんでも日記
ジャンル不定の日記です。

SC1602BS

先日SPIフラッシュの実験をして、I2Cも使ってみたいが実験できるようなデバイス無いかなと思ったが、
昔買ったけど使わなかったキャラクタLCDがあるので確認してみたが、I2Cではなく8ピンでデータを送るデバイスだった。

I2Cデバイスは持ってないので、Aliexpressでなにかデバイス探してみたが、
手持ちの使ってないキャラクタLCDに似たものにI2Cのボードを付属したような商品が売ってた。
そういうことなら、同じく買ったけど使わなかったマイコンを使って手持ちのキャラクタLCDをマイコンで制御してI2Cでマイコンを制御すればよくね？
と思った。

なので、ちょっと手持ちのLCDを調べてみたが、
SC1602BSのバックライト付きってやつで、昔秋月で買ったやつ。


↑表画像


↑裏画像
右側の14電源と制御用の端子で、左側にも端子がある。
左側の端子は2ピンずつつながってて間に間隔があるが真ん中のオープンのとこにも穴が開いてるんで5ピンのヘッダーが挿さる感じ。
右側は7x2列の14ピン。

左側の方はバックライトみたいで、
近くにJ3があるんでハンダでショートさせて、R9に抵抗を設置。
Aの方に5V、Kの方にGNDを繋げばいいみたい。
バックライトはVF4.2で、R9は付属説明書で10-100Ωと記載されてる。
10Ωで80mAになるが、80mAでも暗いくらいでもっと小さい抵抗のほうがいいとか・・・
と思ったが、J3とR9を使用すると電源が共用されて、使わずにAとKを使うと別電源化できるぽい。
両側使ったほうが基板を支えられるが、電源共用化なら右の14品だけでいいから外部基板をちっちゃくできるね。

付属品と思われるもので、手元に7x2の14ピンソケットと100Ω抵抗x3があった。
だが、100Ωだと大きすぎ説があるのと、R9は穴無しのランドなんで本来はチップ抵抗載せるもんと思う。
R9のランドは0.5mmから4.0mmくらいな感じ。ランドの大きさは1.5mm角くらいかな？

14ピンの端子は付属品はソケットなんでブレッドボードで使うことを考えるとヘッダー品のほうが良いよね。
とおもったが、2列だと結局ブレッドボードにささらんわｗ
だが、このLCDを直接自作デバイスにつけるよりも、マイコン1個つけてSPIかI2Cで制御できる感じのデバイス化したいかな思うんで、やっぱソケットよりヘッダーのほうが良さそう。

左のバックライト端子と右の端子の外側の方の間隔は81.0mmぽい。
2.54mm単位で考えると81.24mmが近いがちょっとずれるが挿さる？
基板サイズは85x30mmで、端子の位置は端から2mm。
縦方向はセンターから対称ぽい。
LCD自体のサイズは71.2x25.2mm。
固定用の穴は81x24mm。
厚みは8.8mm。（説明書にLED=12.7って書いてあるが、実測8.8だな。もしかして手持ちのバックライトなし？）
LCD上面から基板上面までが4.8mmで基板厚みが1.6mm、
らしい。

物理的な構造以外は互換品がいっぱい出回っているようで、ソフト的なもんは情報に困らなそう。

spidevでSPIフラッシュの読み書きした

昨日はspidevの実験でデバイスのIDだけ取得してみたが、読み書きも試してみた。

ソースコード
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/spi/spidev.h>

void CmdRdid(int fd);
char CmdRdsr(int fd);
char CmdRdscur(int fd);
void CmdWren(int fd);
void CmdRead(int fd);
void CmdPp(int fd);

int main(int argc,char** argv){
    char* dev=argv[1];
    int fd=open(dev,O_RDWR);
    if(fd<0){
        perror("open");
        exit(1);
    }
    CmdRdid(fd);
//    CmdRdsr(fd);
//    CmdWren(fd);
    CmdRead(fd);
    CmdPp(fd);
    CmdRead(fd);
    exit(0);
}
char SendMessage(int fd,char* tx_buf,int tx_len,int rx_len){
    int tr_len=rx_len?2:1;
    struct spi_ioc_transfer tr[2];
    char rx_buf[rx_len];
    memset(tr,0,sizeof tr);
    memset(rx_buf,0,sizeof rx_buf);
    tr[0].tx_buf=(unsigned long)tx_buf;
    tr[0].len=tx_len;
    tr[1].rx_buf=(unsigned long)rx_buf;
    tr[1].len=rx_len;
    if (ioctl(fd,SPI_IOC_MESSAGE(tr_len),tr)<0){
        perror("SPI_IOC_MESSAGE");
        exit(-1);
    }
    printf("%02x:",tx_buf[0]);
    for (int i=0;i<rx_len;i++){
        printf("%02x ",rx_buf[i]);
    }
    printf("\n");
    return(rx_buf[0]);
}
void CmdRdid(int fd){
    SendMessage(fd,"\x9f",1,3);
}
char CmdRdsr(int fd){
    return(SendMessage(fd,"\x05",1,1));
}
char CmdRdscur(int fd){
    return(SendMessage(fd,"\x2b",1,1));
}
void CmdWren(int fd){
    SendMessage(fd,"\x06",1,0);
}
void CmdRead(int fd){
    if(CmdRdsr(fd)&1){
        printf("WIP=1\n");
        exit(0);
    }
    SendMessage(fd,"\x03\x00\x00\x00",4,10);
}
void CmdPp(int fd){
    CmdWren(fd);
    if(!CmdRdsr(fd)&(1<<1)){
        printf("WEL=0\n");
        exit(0);
    }
    char tx_buf[260];
    tx_buf[0]=0x02;
    tx_buf[1]=0;
    tx_buf[2]=0;
    tx_buf[3]=0;
    for(int i=255;i>=0;i--){
        tx_buf[3+(256-i)]=i;
    }
    SendMessage(fd,tx_buf,260,0);
    while(CmdRdsr(fd)&1){
        printf("WIP=1\n");
    }
    if(CmdRdscur(fd)&(1<<5)){
        printf("P_FAIL=1\n");
        exit(0);
    }
}
昨日使ったサンプルはincludeがもっと多かったが、上記だけでコンパイルできた。

複数のコマンドを実装したんで、実際のデバイスアクセス部分はSendMessageに分割した。
ステータスの確認が必要なコマンドもあるんで先頭1byteだけ返す。
応答のないコマンドはSPI_IOC_MESSAGE(1)にすれば構造体が2要素になってても2番目は無視される模様。
tx_bufで送信文字列渡してるから長さはここで取得できるかと思ったが、NULLが含まれててうまく行かなかったんでtx_lenで長さも別途渡すことにした。

READ (0x03)→ PP (0x02) → READ(0x03)
の順でコマンドを送る。

RDSR(0x05)で最下位bit(WIP)が1の場合は書き込み中でREAD不能ぽいんで先にRDSRをする必要がある。
READは0x03に続けて3byteのアドレスを送信すると、そこからCSが上がるまで何バイトでも読み続ける。
指定しなければ、CSはioctlの開始時に下がって終了時に上がってくれるみたいなのでrx_lenで指定したbyte数だけ読み込まれる。

書き込みの際はWREN(0x06)を実行するとRDSR(0x05)で下から2bit目(WEL)が1になる。WEL=1じゃないと書き込み不可なので先に確認。
PPは0x03に続けて3byteのアドレスを送信だが、アドレスの3byte目(最下位)は0x00にする必要がある。
先頭4byteに続けて256byteのデータを続けるんで260byteをデバイスに送信する。
送信されたデータは一旦バッファに保存されて、データ送信完了後にCSが上がると書き込みが開始される。
書き込み中はWIPが1になるんでRDSRで確認する必要がある。
書き込みが成功するとRDSCURで取得できる1byteの下から5byte目(P_FAIL)が0になるが失敗すると1になるらしい。
WELは書き込みが完了すると0になるんで書き込み系の命令を使うときは毎回WRENが必要。


実行結果
# ./spi /dev/spidev1.0
9f:c2 20 18  
05:02  
03:ff ff ff ff ff ff ff ff ff ff  
06:
05:02  
02:
05:03  
WIP=1
05:03  
WIP=1
05:03  
WIP=1
05:03  
WIP=1
05:03  
WIP=1
05:03  
WIP=1
05:03  
WIP=1
05:00  
2b:00  
05:00  
03:ff fe fd fc fb fa f9 f8 f7 f6
こんな感じになった。
255から0のASCIIコードを書き込んだ。（最後がNULLのがいいと思ったんでデクリメントにした）
PPは256byte単位だがREADは10byteだけにした。
想定通りの結果と思う。

データの初期値は1なのかな？実験中に書き換わっちゃった可能性も否定できないが・・・
なお、書き込み中のWIPの確認で6回ループしてるが、2回目に実行するとPPして次のRDSRでWIP=0になった。
同じデータだと書き込まれない？PCの処理速度の問題か？

spidevを使ってみた

先日Orange Pi Zeroでspidevが出てくるようにしたが、
前にZeroの2MBフラッシュと交換しようとして買ったSPIフラッシュ（macronix MX25L12835F）が手元にあって、今日SOP8のDIP変換ボードが届いたんで試してみることにした。

https://www.emcraft.com/stm32f769i-discovery-board/accessing-spi-devices-in-linux
↑にSPIフラッシュのIDを確認するコマンドを送るサンプルがあったんでそのまま使ってみた。

# ./spi /dev/spidev1.0
response(7): c2 20 18 c2 20 18
データシートの9-5のとこに0x9Fの出力がc2 20 18って書いてあるんでデバイスは機能してるぽい。
が、応答3byteだと思うんだがなんで6byteなんだろ。サンプルのソースコードでも6byteになってるが・・・

# ./spi /dev/spidev1.0
response(6): 18 c2 20 00 00 00
サンプルのソースコードからxfer[1].lenを3にしたら一応3byteになった。

あとググって調べたところxfer(変数名がxferではなくtrの例が多かったが)の配列要素が1で同じとこにtx_bufとrx_bufを設定してる例が多かった。
これは要素数が1だとSPI_IOC_MESSAGE(2)のとこもSPI_IOC_MESSAGE(1)になるぽいんだが、
試しに要素数1でやってみたら、
# ./spi /dev/spidev1.0
response(6): 00 c2 20 18 c2 20
こんな感じで返ってきた。
TXの送信中もrx_bufに入る感じと思う。
だから配列の要素数を増やして分離すれば応答だけを取れる？

データシート見るとコマンドの送信がコマンド番号1byteに続いてダミー2byteとアドレス1byteを送信しているようにも見えるんだが、
xfer[0].len = 1;を3に（ダミーが1byteと勘違いした）んだが、応答ずれちゃいそうな気がするが結果が変わらなかった。
配列の要素が切り替わるときにCSが切り替わってたりするのか？
調べてもよくわからんかった。

改造の際にmemset(xfer, 0, sizeof xfer);を消してみたら、
# ./spi /dev/spidev1.0
SPI_IOC_MESSAGE: Invalid argument
で機能しなかった。
設定しない構造体の要素は0に初期化しないとダメな感じ？

12Vを駆動するNOT回路

Orange Pi ZeroのGPIOが足りないからNOT回路で1本の信号で2回路制御するのを考えたが、


こんな感じでMOSFET3つ使わないとできない？
回路の上流側にスイッチをつけるのがハイサイドで下流側につけるのがローサイドというみたいだが、
ステッピングモーターの駆動でHブリッジにするんでハイサイドにスイッチをつける必要がある。
電圧は12VでGPIOは3.3Vなんで、NMOSは12Vを制御するのに12Vよりも大きい電圧が必要。PMOSなら12Vで制御できるが3.3Vではできない。

右上がPMOSだが、ゲートに電源電圧をつなげちゃえばオフにできる。
なので、右のPMOS部分だけ見るとゲートに12Vがかかっているので回路はOFF。

真ん中のMOSFETはNMOSでゲートに直接3.3VがかかっててソースがGNDなので、
ここだけ見るとNMOSはONで、右のPMOSのゲートからGNDに短絡するんで右のPMOSのゲートは0Vになって回路に通電してる。
ここの電圧は3.3Vである必要はないかな。

左もNMOSでGPIOとゲートをつなぐ。
これがONになると真ん中のNMOSのゲートがGNDになるんで真ん中のNMOSがOFFになる。
真ん中のNMOSがOFFだと右のPMOSのゲートが12Vになるんで回路が遮断される。


ような気がする・・・

モータードライバ買った

Orange Pi Zeroと MOSFET でのモーター制御ができたが、
次の段階として今回は5V駆動したんで12V駆動のために2.54mm化のDCジャックを注文して、
N-MOSFETだけだとモーター1つにGPIO4ピン使うが半分P-MOSFETならGPIOx2で制御できるはず。
というわけでP-MOSFETを買おうと思ったんだが、
デュアルMOSFETなるものを知った。

デュアルMOSFETはそのまんまMOSFETが2つのIC？なんだが、N+Pのものがある。
NのデュアルとPのデュアルに部品を分けた方が1個で電流を1本流せるが、
今回SOT-23のMOSFET使ってわかったが、肉眼で印字が見えないからNとPの2種類あったらどっちかわからん。
N+PのデュアルMOSFET使えば部品が1種で済むから見分ける必要がない。
というわけで、AO4606ってSOIC-8（SOP-8とは幅が違うぽい）のデュアルMOSFETを買おうかと思った。
SOT-23のシングルMOSFET50個分の値段で10個入りくらいの価格。
L9110SってフルブリッジのモータードライバICと似たような価格。
L9110は12V0.8Aしか流せないんでギリギリな感じだがAO4606は30V6Aまででかなり大電流が流せる。

が、よく考えるとフルブリッジのモータードライバはMOSFET4個分なんだよね。
ということに気づいたんでL9110買ってみることにした。
SOP-8だとAO4606と大差ない価格だったが、
変換基板につけるのもめんどいし勿体無いから、テスト用にL9110HってDIPパッケージのやつを5個にした。
本番ではSOP-8のL9110Sを別途買うつもり。

MOSFETでモーターを動かす前にLEDで実験

昨日タクトスイッチとMOSFETを使ってLEDを1個光らせる実験をしたが、
Orange Pi ZeroでMOSFET8個を制御する実験やった。

#include <unistd.h>
#include <fcntl.h>

int main(void){
    char phase[4][4]={
        {'1','0','0','1'},
        {'1','0','1','0'},
        {'0','1','1','0'},
        {'0','1','0','1'}
    };
    int gpio[4];
    gpio[0]=open("/sys/class/gpio/gpio12/value",O_WRONLY);
    gpio[1]=open("/sys/class/gpio/gpio11/value",O_WRONLY);
    gpio[2]=open("/sys/class/gpio/gpio6/value",O_WRONLY);
    gpio[3]=open("/sys/class/gpio/gpio1/value",O_WRONLY);
    int i,j,p;
    for(i=0;i<100;i++){
        p=i%4;
        for(j=0;j<4;j++){
            write(gpio[j],&phase[p][j],1);
        }
        sleep(1);
    }
    char b='0';
    for(j=0;j<4;j++){
        write(gpio[j],&b,1);
    }
    close(gpio[0]);
    close(gpio[1]);
    close(gpio[2]);
    close(gpio[3]);
    return(0);
}
↑ソースコードはこんな感じ。


1秒毎に2個ずつ光るLEDが変わる。
ミニブレッドボード4個は全部同じでハーフブリッジ回路？にした。
MOSFETは8個だが2個は同時にON/OFFするんでGPIOは4本。
12,11,6,1のGPIO使った。6と1の間にはGNDがあるんで1ピン飛ぶ。
MOSFETは全部Nチャネルだが、半分Pチャネルにすれば2本で制御できると思ってる。

MOSFETでLED光らせてみた

昨日MOSFET届いてたんでLED光らせる実験してみた。

注文したMOSFETはAO3406ってやつなんだが、届いたの顕微鏡で見たらA69Tって書いてあった。
最初A59Tに見えて調べたらPチャネルのようで違うの送られたのかと思ったが、（まあAO3406じゃない時点で違うがｗ）
A69TというのがNチャネルのようで、よく見たら印字はA69だった。
A69Tのデータシートは見つからなかったがAO3406と同等品と信じる・・・
AO3406は30V,3.6Aまで流せてチャージ速度が速そうなものを選んだ。


↑LED光らせてる実験。指の下にタクトスイッチがある。

SOT23変換ボードは先日届いてたのでMOSFETは変換ボードに載せたが、ハンダが思いっきし曲がったｗ
まあ電気的には問題なさそうだったんで曲がったまま。
テープで固定してからハンダすべき？
端子はAO3406のデータシートのとおりにやったが、1本だけの側がDで左下（Dが上として）がGで右下がS。

以前買った中華フラックスが未使用で、国産無洗浄フラックスももったいないし中華フラックス使ってみたがいい感じだった。
MOSFETのハンダは失敗して曲がっちゃったが、ヘッダーピンのハンダはランドに吸い込まれる感じできれいにハンダできた。
無洗浄じゃないフラックスと思うんで、一応ウェットティッシュで軽く拭いといた。

後から書いたが、

回路図こんな感じ。
LEDのVFわからんので適当に300Ωで事前に光ること確認してからやった。
最初MOSFETのゲートのところに抵抗つけなかったんだが、電源つないだらスイッチ押して無いのに光った。
ゲートをGNDに繋がないと電圧不定で誤動作しちゃうわけね。
100kΩつけたら期待通りの動作になった。

Mini-ITXケースのVESAマウント金具作った

先日届いた中華Mini−ITXのVESAマウントをどうしようか考えてたが、
近所のホームセンター3軒目で使えそうな素材発見したんで作った。

1x200x300のアルミ板使った。900円ちょい。
アルミなら2mmくらい厚み必要かと思ってたが、ホームセンターで触った感触だと思ったより硬くて、1mmどころか0.5mmくらいでもなんとかなりそうな気はした。
ステンとかブリキなんかも売ってたが、1mmアルミでいけるなら加工しやすいと思ったんでアルミに。

1枚板じゃなくて20mm以上のフラットバーを2本でもいけると思ってそっち方向で考えてたが、フラットバーは近所には売ってなかった。
コメリの通販で取り寄せようとしたが、10個からだったんで無理だった。


こんな感じに。

筐体幅が225mmで、ケース側のネジのピッチが先日の記事にも書いたが120mmと思ったが、今日測ったら119mmぽかった。
最初そのとおりに図面作り始めたが、VESA穴は中央から測るんで奇数だと0.5mm単位になる。
1mm単位のが簡単と思って、誤差1mmならなんとかなると思い、226mmと120mmに変更して図面書き終えた。
それが失敗だった。
VESAの100mmピッチはちょいきついがなんとか締まったのだが、ケース側のネジが入らんかった。
最初4mmドリルで穴開けたが4.8mmまで広げてそれでも入らず、ヤスリで気持ち内側に広げたがまだ入らず、ちょっと板を歪ませる感じでなんとか固定できた。
ネジは全部M4ワッシャーをつけた。ケース側のネジはインチネジ。

  1. 図面をセロテープで固定。
  2. 金属定規をセロテープで固定してカッターナイフで削る。
  3. 前後に何度も折り曲げる。
で板は切れた。
最初ノコギリで切ろうとしたらすごく大変で、カッターで切れないか思ってググったら2mmまでならいけるとの情報を得てカッターでやってみた。
参考にしたサイトでは裏側からもカッターで削ってたが、裏側には図面がないので表だけ削って折ったら切れた。

使った道具は、
道具
用途
プリンター図面書く
セロテープ図面貼る、定規固定
金属定規カッターガイドに
カッターマット
なくてもいいと思うが
カッターナイフ切る。というか削る
センターポンチ穴位置叩く
電動ドリル穴開ける
クランプx2すのこと端材で板を挟んで折り曲げた
すのこ作業台

作業台持ってなかったんだが、今日行ったホームセンターでちっちゃいすのこが300円ちょいだったんで使えると思って買った。
センターポンチは前にOrange Pi R1のVESAマウンタ作ろうと思って買ったが、素材をクリアファイルにしたんで使わなかったので初使用。AliExpressで買ったオートのやつ。

STM32F042K6T6の基本回路図書いてみた

前回のLチカの際は中華ST-Linkの3.3VをSTM32F042K6T6に直結したが、データシート見るとパスコンがついてる。
実際に使う際はコンデンサつけたほうがいいだろうし、電源周りとか基本の回路図を書いてみた。



VDDは2本あるのかと思ったが、17番ピンはVDDIO2でちょい違うみたいだった。
VDDIO2はPA8からPA15に供給される電源らしい。必須なのか不明だが、17番ピンは他の用途には使えないのでつけとけばいいと思う。
VDDとVDDIO2は共通電源で4.7uFは1個で100nFを別々につければいいものと思ってる。
VDD-VSSは-0.3から4.0の範囲が絶対定格で、2から3.6Vの範囲で起動。
VDDIO2は1.65から3.6V。絶対定格はVDDと同じ。

VDDAはアナログ用の電源で、デジタルと共通でいいと思うがデータシートのコンデンサは10nF+1uFになってる。
VDD-VDDA=0.4が最大絶対定格なんでVDDAは必須だと思う。
最初に失敗した際にはVDDA繋がなかったんで壊したのかもしれん・・・
VDD以上で3.6Vまでを供給するらしい。

NRSTはリセット用のピンで他の用途には使えないが、必須ではないのでリセット不要なら何もつけなくていい。
SWDIOとSWCLKを別用途に使う場合にNRST対応のST-Linkを使えば書き換えが可能と思われるが、中華ST-LinkのNRST端子は機能しないとか・・・

中華ST-LinkはNRSTが利用できないらしいので、23番ピンと24番ピンはSWDIOとSWCLK以外の機能を割り当てないほうがいいと思われる。
23番ピンはSWDIO以外に、PA13、IR_OUT、USB_NOEが利用できる。
24番ピンはSWCLK以外に、PA14、USART2_TXが利用できる。
IRは赤外線？USARTは2個あるみたいだから要らんね。
USB_NOEってのはなんだろ？USB使うのに要るの？


こんな感じですね。
適量のコンデンサあったら次回からつけることにする。

STM32F042K6T6のリセットと電源周り

STM32F042K6T6にNRSTピンがあるけどこれリセットだよね？
昨日のLチカの際は何も接続しなかったけど問題ないのか？
思って調べたが、
やはりNRSTでリセットができるようで、LにしてからHになったタイミングでリセットがかかるぽい？
データシートの 6.3.15 NRST pin characteristics に回路図が記載されてたが、
スイッチと0.1uFのコンデンサを並列にGNDと繋げばリセットが使えるぽい。

ついでにもうちょっとデータシート見てたが、6.1.6 Power supply scheme に電源周りの回路が記載されてる。
VDDとVSSはST-Linkの端子に直結したが、
2x VDD,VSSのところに、2x100nF+1x4.7uFのコンデンサがついてる。
電源の近くに4.7uFをつけて、2個あるVDDピンの近くに100nFをつけたほうが良さそう？
VDDAは10nF+1uFになってる。
VBATは1.65-3.6Vの電池直結になってるが、電池不要ならVDDと同じ電源に直結でいいのかな？

あと、6.2 Absolute maximum ratings のところにVDD-VDDAがMax 0.4と記載されてる。
更に、
All main power (VDD, VDDA) and ground (VSS, VSSA) pins must always be connected to the external power supply, in the permitted range.
常にVDD,VSS,VDDA,VSSAは常に接続しなきゃダメとか。
最初うまく行かなかった際はVDDAとVSSAは何も接続しなかったが、そうするとVDD-VDDAが3.3で許容範囲超えちゃうから壊した？