2.5元だったはずがいつの間にか5元に値上げしたかと思ったらさらに8元になり仕舞に日本で300円で売られているi2c液晶を動かす


約2年前、ねむいさんはtaobaoでピン配置以外詳細不明のi2c液晶を超破格値の
2.5元で購入しておりました。その後なぜか急に8元に値上げしやがっておりましたが
私は破格かつ超円高だったのを活用して30個くらいガメて以来殆ど動作させず
そのままで放置。

が、

2014年の春、aitendoさんもこの液晶に漸く目をつけたようで一つ当たり
300円で販売しています。さすが大陸店、阿漕っスね
このまま腐らせるのもなんなので誰かがこれを使って面白い物を作ってもらえる
ようにとの願いを込めて込めて私の当時の解析結果を公開したいと思います。




●これはなんだ

これは今となってはごく一般的なドットマトリクス形式のモノクロ液晶です。
インターフェースはI2Cのみとなっています。
プラ製の外枠はLEDをつけるくぼみのような意味深なものも見受けられますが
あまり気にしてません。

●だからこれはなんだ

なんなんでしょうねこれ…粘着テープ等でべったりつけられてるわけではないので
簡単に取り去ることができます。中華液晶は謎が多いです。


●マイコンとどうつなげればいいのか？
データシートに提示されているのはピン配置のみ…ほんっとこれだけです。
しかしその情報だけでも十分解析が可能です。


ここで閑話休題、I2Cというインターフェースについてですが…
ひとまず、I2Cの規格はNxPのサイトにPDFにて公開されていますのでしっかり確認し
ておきましょう。後述しますが最初はGPIOのエミュレーションの方が動作の把握が
しやすいかと思います。いずれの動作においてもオープンドレインで動作させるのは
変わらないため、SDA,SDLの各信号線にはプルアップ抵抗は絶対に必要です。

プルアップ抵抗算出式は　Rp(kohm)>(Vdd-0.4)/3(mA)　
なので一般的な+3.3V系では
Rp > (3.3-0.4)/3 = 0.967(kohm)となりますが、
100pFの容量で400kBps通信時の所要立ち上がり時間300nSecを考慮すると
Rp < 300(nSec)/100(pF) = 3(kohm)

計算上は0.967kohm~3kohmが適切な抵抗値なはずですが、1kohm付近では
ドライブ能力が低いF**KなI2C液晶だとACKがLowに引いてくれないことが
あるので結局実測(オシロスコープの波形)を元に安全値を求める羽目に
なります…めどい
BolyminのキャラクタI2C液晶を動かした際の実測は以下のようになりました。

(MAX400kbps通信時)
　　1kohm ×
　　1.5kohm ○
　　2.2kohm ○
　　2.7kohm ○
　　3.3kohm ○

というわけで400kBpsでI2Cデバイスを動作させる際はプルアップ抵抗は
2.7kohmが最も適しているかと思われます。

ですが速度的に潰しの効く100kbpsまで落とすなら4.7kohmで吊っとけば大抵は
問題はありません。…て言うわけで今回も4.7kohmで行きます。



先ずは液晶と意識せず一つのI2Cデバイスと思い込んでI2CのACKが返ってくる
アドレスをサーチしてやりましょう。ほとんどのデバイスは8bit変数で示される
範囲内なので捜索数も少なくそんな時間がかかりません。
で、ヒットしたアドレスは0111_101xと0111_100xでした。ヒットした
アドレスを元にいろいろググってみるとI2Cで64x96のドットマトリクスに
適合したドライバICはUC1602Sが最も近いのではないかと推測しました。
データシートを見るとデータとコマンドのレジスタが上記アドレスのとおり
二つに分かれており推測が正しかったと分かります。


ここで改めてこのI2C液晶、"GG0906186FWNNC"を動かしせしめるための
準備を行います。ドットマトリクス液晶に必須のバイアス電圧を作り出す
ための電圧ドライバもUC1602Sには入っているので後はデータシートを参考に
VLCD用のキャパシタを外付けしてやればおしまいです。
具体的には上記回路図の要領でVLCDに0.33uFぶら下げればよいです。



●動かす！



使用するマイコン/基板は今流行りのSTM32-Nucleoボードを使用します。
初めて動作させる際は低速ですがデバッグがしやすいGPIOによるI2Cバスの
エミュレーション(ソフトI2C)が良いです。上でも注意しましたが制御は
すべてODです！あと裏ワザになりますが、STM32の場合はGPIOを出力に
設定をしていてもODで制御してREADの際はポートをHI(=疑似トライステート)
にしておけばターゲットデバイスから吐かれる信号レベルがわかりますので
入出力を切り替える手間が省けてオトクです★


…ていうかハードウエアI2C制御版のほうはF1/F4系と全く違ってて動かし方を見つけ
てる最中なので今しばらくお待ちください。
20230822追:
2023年現在はハードウエアI2Cでもバリバリ安定動作してます！！！！



UC1602Sのイニシャライズのための呪文もねむいさんが既に調査済ですので
ご安心ください。ご覧の通りに無事表示が出来ました。
TFT-LCDで使用したFONTX2ドライバを使用しております。


これだけでは使いどころが分かりづらいので同じI2C接続デジタル温度計STTS751を
つなげて簡易の温度計をｻｸっと作成してみました。


特に危なげなく温度を表示することが出来ました♥
やっけつ配線ですがこういう出来合いボードは本当に便利ですね〜



今回のF0版Nucleo向けのソースコードはおきぱに置いておきます。圧縮ファイル内
のlibフォルダにxMSTNというフォルダがあり、ドットマトリクス液晶の制御のための
コードが集中しています。
今回制御したUC1602SはxMSTN/driversフォルダにuc1602.cとして抽象化して
ありますので別のマイコンやmbedに移植される方はご参考に。移植は容易に
できるはずです。

デフォルトではSTTS751の制御はIF文で切っていますのでSTTS751を
お持ちでない方もaitendoさんから購入したi2c液晶単体でも動作確認が
可能です。この液晶は動作電流がかなり小さく、低消費電力な工作にも
かなり使えるアイテムとなるでしょう。

I2Cネタは書きたいことが沢山有りすぎてまとまりがつかない状態です。
特に怪しい中華製I2Cキャラクタ液晶の電源投入時の変な動作とか回避の
ためのバスリカバリとかキリがないです。ですが今回みたいなひょんなことを
チャンスにして公開していきたいと思います。

OpenOCD小ネタ8 -STM32-Nucleo(Nucleo F030R8)で楽しむベアメタルプログラミング-


♪
…おっと、すみません。今回はSTM32-Nucleoボードのお話でしたね〜



一か月ほど前購入したSTM32-NucleoのF0バージョンですが、これには新しい
STLinkであるSTLink/V2-1という間際らしい名前のデバッガアダプタが搭載
されていることに言及しました。これはmbedサポートを謳っていてD&Dによる
フラッシュ書き込みは勿論仮想COM(VCP)や通常のデバッグも同時に可能です。
STLink/V2-1はCMSIS-DAPとしては機能しないものの現在のOpenOCDは
CMSIS-DAPは不利になるので従来のSTLinkとほとんど変わらず使える
ほうがありがたいのです。

しかしながら新たに追加されたMSDとVCPのおかげでエンドポイントの定義が
若干違うため、OpenOCDにV2-1用のパッチを当てないと使用ができませんでした。
以前も少し触れましたがこちらのサイトの情報を基にパッチをgerritに投げて
マージされることを待ったのですが、後出しじゃんけんされまくってボコボコ
STLink/V2-1のパッチが投げられる事態となってしまいました。

で、詳細は省きますが同じぱっちを投げた人同士で相談し、結局
この人のコミットをベースに私の思想を反映した形で落ち着きました。
ついでにF0,F4,L1の各シリーズのNucleoボードにも
対応したcfgも作成されました。


というわけで20140324現在では既にNucleo(STLink/V2-1)に対応したデバッグ
アダプタもOpenOCDから利用可能となっております。STLink/V2-1では仮想COM
機能もあり、F0のNucleoボードではUARTのTx,Rxが直結されているので本当に
mbed感覚で利用が可能です。
20140903追
Windows8.x系OSをお使いの方はこちらを必ずお読みください。

おきぱには既にNucleoF0版向けのGCCプロジェクトを公開しておりますがLチカに
飽き足らず勿論UARTの文字列送信も盛り込んでいますのでご参考までに。

ところでNucleoボードは拡張性を狙った各シリーズ共通のMorphoなるピン
配置が外部に出ております。
Morphoとかﾆｮｶﾞﾝ思い出して非常に縁起の悪い名称ですが。
さらに現在のプロトタイプボードでは必須となったArduinoのシールド向けの
ポートも用意されております。mbedではNucleo用のライブラリや作例などが
充実し始めております。ソフトウエアやハードウエアの技術に明るくない人
でも先人が残した成果を余すことなく利用でき、熟練度に関係なく楽しめる
仕組みになっていてなかなか考えられていると感じます。


てわけでついでなので私ももうちょっと遊んでみました。これは知る人ぞ知る
TFT-LCDシールドです！
今回はFONTXドライバとからめで文字列の表示をしてみます。

TFT-LCDシールドとNucleo上のLEDはSCLKにあたるポートがぶつかります
(PA5/D13の所)。
ですがArduino系シールドを上から挿した時点で横から覗きこまない限り
LEDは全く見えなくなるので無視して先に進みます！
(ハードウエアSPIの場合SCKは必ずぶつかる)

STM32F0/F3系のSPIはちょっと特殊で8~16bitまで自由に送受信するビット数が
変えられます。従来のF1/F2/F4系とは若干データレジスタの取り扱いが違い、
FIFOの設定を正しく行いビット数に合わせてDRレジスタのアクセス方法も
変えないとデータの送受信ができないのでご注意ください。
私はdisplay_if_basis.cの頭に8bitアクセス用のマクロを作って互換性を保ちました。


動かしてみたところです。さすがにフラッシュの容量が少ないので
ひらがなとかの表示は無理ですがこの規模ならANKで十分だと思います。

実は上記TFT-LCDシールドを動かすためのコードもおきぱにあるサンプルに
導入しております。8bit-SPIで動く奴ならピン配置さえ合わせたらほとんどの
TFT-LCDモジュールも動作せしめることができるのでTFT-LCDシールドを
お持ちでない方も少しmakefileの設定を変更するだけで手持ちの手頃で
SPIなTFT-LCDで動作可能だと思います。


忘れるところでした、今回の修正を反映したOpenOCDバイナリもすでに公開中です！

STM32F4シリーズを使ってみる11 - STM32F429I-Discovery発動編 -

ぇー…前回のSTM32の記事の最後で新しいコードスニペットと称するどことなく
卑猥な名称のふれこみで発表されたSTM32CubeMXとそのF4シリーズのサポートを
行うCubeF4という新たなファームウエアライブラリに触れましたが…
私も移植を目指して頑張ってたのですが…

私の従来のいつものに当てはめようと思うと改造個所が多岐に及び、さらにコード
サイズとオーバーヘッドも増加してしまったので移植は見送りにして新規に作る
プロジェクトからCubeF4を使用する方針に逃げ変えました。

STM32CubeF4には抽象化がさら進められ、インスタンスという概念が追加され
ています。これがかなりの曲者で従来のF4シリーズで言うDSP_StdPeriph_Driver
ライブラリに相当する"STM32F4xx_HAL_Driver"はすべてこれの
使用を前提としていてさらにサイズが大きい構造体と併用しなければならない
のが分かりました。
これSRAMやFLASHのリソースが膨大にあるF4シリーズだからよいものをF1やF0
にも当てはめるのはかなりヤバいと思います。
私も過度の抽象化は良いとは思っていません。移植性を重視しすぎてせっかくの
マイコンの性能を引き出せないのであれば本末転倒です。

あんまし考えたくないのですが無理くそ全CPUの格差を埋めるべく抽象化を
目指し、そして失敗して結局ライブラリのバージョンが多岐に分かれて
しまったLPCOpenと同じ道を歩んでいる感じがします。
おそらくCube系のライブラリに遷移していくあたって大混乱が起こると
思いますね。無理にCubeへの遷移を煽る中途半端に発言力が持ってる人が
湧くのは容易に予測されます。学生さんなんかは自分のボスの"せんせい"
にまたCubeライブラリの使い方をwikiにまとめさせられると思います。
そういうこと言ってくる人らには"こんなことしてること自体が時間の無駄。
したけりゃ自分でやれ！"とはっきりNOを突き付けるべきです。
とはいえ私のぶろぐを見られている方は私よりも技術力がはるかに上の方
ばっかなのでそもそもこんなとこ見てない私が注意しなくても各自しっかり
対処出来することができるでしょうからぐだぐだ言いましたがやっぱし
私の杞憂かな〜と思います。




さて、前置きが長くなってしまいましたが以前から触れてきた
STM32F429I-DiscoveryのTFT-LCDをSPIではなくRGBインターフェースで
動かすことに成功しました。
前回は低速なSPIインターフェースでお茶を濁していました。
しかしSTM32F429シリーズにTFT-LCDに特化したグラフィックコント
ローラ(LTDC)とグラフィックに特化したDMAである(Chrom-ART Accelerator)
が搭載されているのでこれらの機能を使っていつものの再現を目指し
ようやく完成したわけです。

●STM32F429Iにあるグラフィック機能
私が説明するよりもこちらのPDFを見たら一目瞭然です。
LTDCに関してはフレームバッファとして確保したメモリアドレスにRGBの
データを書き込むだけで色の表示が可能です。また、STM32F429系では
SDRAMがサポートされているので容量を喰う画像データでも余裕で
取り扱うことができます。

Chrom-ART Acceleratorに関しては別名DMA2Dと称されていて文字通り
2Dグラフィック特化型DMAです。しかもデータ形式を変換してメモリ間
転送したり単一データを指定して転送する(レクタングルフィルに効果を
発揮)ことができます。

STM32F429I-Discoveryでは上記二つの機能を体験可能です。同ボードに
搭載されたTFTLCDの解像度は工作物ではメジャーな240x320となっています。
STM32のLTDC単体ではレクタングルを指定して書き込み時にアドレスを
自動インクリメントしながら連続で書き込める機能はない(DMA2Dで
解説します)ためアドレス計算は必須です。

具体的にいうとたとえば座標x,yにドットを打ちたい場合は基本的には先ず
以下のように座標を指定します
(RGB=565,1ドットあたり2Byteのデータを想定)。



lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(x + (MAX_X*y));

lcd_c_buf_ptr :ドットデータを実際に書き込むメモリのアドレス
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義)


次にRGBデータcolourを書き込みます。


*(volatile uint16_t*)(lcd_c_buf_ptr) = colour;

lcd_c_buf_ptr +=2;

より具体的な実装はいつものの./lib/display/mcu_depend/src/lcdc_if_basis.cを
ご覧下さい。FONTX2等の描画ルーチンは完全にドット単位で行っていますが
MCUバスと外部LCDコントローラとの通信オーバーヘッドがなくなるので
ドット単位でも十分に早くなります。また、LTDCは2枚のレイヤーを使用可能で
さらにアルファブレンディングの透過効果も使用可能です。現状では単一の
レイヤとしてしか使用していませんがこちらも学習を重ねてモノにしていきます！


次にもう一つの目玉機能Chrom-ART Accelerator(以下DMA2D)です。
私のいつものではFillRect系のレクタングル指定塗りつぶしやレクタングル
指定の動画データ転送に使用しています。

基本的には通常のDMAと同じですがグラフィック特化なのでRGBデータを
格納するレジスタもあります。単一色描画では以下のように設定します。
※RGB565,黒色,全画面(240x320)塗りつぶしの場合


	/* configure DMA2D */

	DMA2D_DeInit();

	DMA2D_InitStruct.DMA2D_Mode				= DMA2D_R2M;

	DMA2D_InitStruct.DMA2D_CMode			= DMA2D_RGB565;

	DMA2D_InitStruct.DMA2D_OutputGreen		= (0x07E0 & COL_BLACK) >> 5;

	DMA2D_InitStruct.DMA2D_OutputBlue		=  0x001F & COL_BLACK;

	DMA2D_InitStruct.DMA2D_OutputRed		= (0xF800 & COL_BLACK) >> 11;

	DMA2D_InitStruct.DMA2D_OutputAlpha		= 0x0F;

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_f_buf_ptr;  

	DMA2D_InitStruct.DMA2D_OutputOffset		= (MAX_X - 1));   

	DMA2D_InitStruct.DMA2D_NumberOfLine		= MAX_X+1;

	DMA2D_InitStruct.DMA2D_PixelPerLine		= MAX_Y+1;

	DMA2D_Init(&DMA2D_InitStruct);

	/* Start Transfer */ 

	DMA2D_StartTransfer();

	/* Wait for CTC Flag activation */

	while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}


lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義


フォアグラウンドのレイヤーへ画像データを転送したい場合は以下のように。


	/* configure DMA2D */

	DMA2D_DeInit();

	DMA2D_InitStruct.DMA2D_Mode 			= DMA2D_M2M;

	DMA2D_InitStruct.DMA2D_CMode			= DMA2D_RGB565;

	DMA2D_InitStruct.DMA2D_OutputGreen		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputBlue		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputRed		= 0; /*　M2M系転送の場合は使わない */

	DMA2D_InitStruct.DMA2D_OutputMemoryAdd	= (uint32_t)lcd_f_buf_ptr;

	DMA2D_InitStruct.DMA2D_OutputOffset		= 1;

	DMA2D_InitStruct.DMA2D_NumberOfLine		= MAX_X+1;

	DMA2D_InitStruct.DMA2D_PixelPerLine		= MAX_Y+1;

	DMA2D_Init(&DMA2D_InitStruct);



	/* Configure default values for foreground */

	DMA2D_FG_StructInit(&DMA2D_FG_InitStruct);

	DMA2D_FG_InitStruct.DMA2D_FGMA 			= (uint32_t)p;

	DMA2D_FGConfig(&DMA2D_FG_InitStruct);



	/* Start Transfer */ 

	DMA2D_StartTransfer();

	/* Wait for CTC Flag activation */

	while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}


lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
p :転送したい画像データのポインタ

と、従来のDMAと同じ感覚で使用が可能です。もっと汎用なDMA2Dの使用法は
同じくlcdc_if_basis.cをご参照ください。DMA2DはLTDCと組み合わせると
強力なレイヤー機能が使えるようになるでしょうね。
私のサンプルでは全く使いこなせてませんがー！


という訳でそれを踏まえたいつものをビルドして書き込み、
動作させたものが上の画像です。
静止画では違いが分からないと思いますが以前の8-bitSPIのみで動かしてた
ものとは描画速度がダンチですよ♥


惜しむらくはSTM32F429I-Discoveryに使用されているTFT-LCDが発色にちょっと
劣る点です。2014年現在では超高視野角液晶はすでにホビイストでも容易に
入手可能なのでそれに慣れた私にとってはあと一歩がほしいところと感じました
(多分最新の奴搭載したら値段跳ね上がるでしょうけど)。




●いつものFatFs+TFTLCD表示サンプルの細かい整備など

LTDC+DMA2Dに対応したついでに長らく放置していた全部載せSTM32F427IIT6基板の
プログラムも見直して安定化を図りました。いまさら気付いたのですが、新しい
STM32F4に存在するFMC(フレキシブル・メモリコントローラ)ではFSMCの
設定とは微妙に違っておりました…。

なんとFSMCでは存在しなかった変数が構造体に追加されていてこれを設定して
なかったせいで動作が不安定になっておりましたorzいまさら気付きましたが
まだFMC世代の新しいSTM32F4を使用されている方が少ないのか指摘されず
助かりましたうふふふふふふふｆ

また、この全部載せ基板はI2Cのコーデックも乗っていて音質は非常に悪い
ですがmp3やwaveファイルの再生も可能です。私のいつものプログラムでは
SDIO経由でSDカードのmp3ファイルなどを読みだして再生します
…がしかしビットレートが高いmp3の再生ではSDIOのデータ読みだしにDMAの
転送を行うとI2Sの方のサーキュラモードDMA転送と干渉しまくりあっと
いう間にオーバーフローになってエラーをはいて止まります。

という訳でこれを避けるためにSTM32F4でもFIFOのポーリングでの読み書きに
本格的に対応させることにしました。STマイクロ配布のSTM32F4のデモでは
ポーリングの読み書きはRead/WriteBlockしか対応しておらず非常に低速度
なのですがマルチブロック転送でもポーリングで読み書きできるように
改良しております。ポーリングでもDMAとほぼ同等の転送速度が得られたので
速度に関しては問題なしです。


…という訳でDMAあえてを使用せずポーリングによる読み出しだけで無事ビット
レートの高いmp3ファイルの再生も可能となりましためでたしめでたし！
(helixのフォルダにあるassembly.hのマクロが前回の機能追加で間違ってて
そもそもmp3ファイルが全く再生できなくなっていたのは見逃していただきたい)


●もいっこおまけ
私のいつものでは一部のmp3ファイルを再生したときにアーティスト/曲名情報
表示の際にゴミデータが表示されてしまっておりましたが、こちらも文字列ストア用の
バッファ(私のプログラムではCCM領域にあたる)を一旦ゼロクリアしてから
表示を行うようにしてバグを潰しております。

以前は変なゴミデータが表示されていましたが…、

修正後はこんな感じにすっきりです★

STM32F4シリーズを使ってみる10 -CMSISがバージョンアップした-

STマイクロさんから超安価なArduino用拡張ボード互換且つmbedサポートな
STM32 Nucleoなるボードが発表されすでに販売されております。
ねむいさんもSTM32F030シリーズが載ったタイプのnucleoボードを
mouserから購入しました。
…のはいいのですが一緒に購入したEFM32のCortex-M4バージョンWonder Geckoの
単品が輸出規制に見事に引っかかりてんやわんやがあったため今だ手元には
届いておりませんorz入手出来たらぶろぐに書きますのでしばしお待ちを。

ちなみに元凶のWonderGeckoにはハードウエアAESが搭載されています。
これが暗号に関する技術のため他社のマイコンでも暗号化機能を持つ品種は
しばしば輸出規制に引っ掛かります。ちなみに"ZeroGecko"にもばっちり
ついていたのですがマイコン単品ではなく評価キットという形で同時に
購入したので引っ掛からず素通り。なんといい加減な…#
…まぁ海外またぐ流通では非情にとてもよくある事柄ですねorz
EFM32の件については後日OpenOCDカテゴリでもご紹介します。



さて、前置きが長くなりましたが少し前にCMSISがバージョン4
(以下CMSIS-V4)に上がっております。但し"ARM,LTD.が提唱しているCMSIS
という規格全体"がバージョン4になったという意味ですのでcore_cm0.h等の
コアに関するヘッダファイル単体はV3.20->V3.30と
いうバージョン推移となっておりますのでご注意ください。
非常にややこしいですがV4.00ではありません。

あと以前も述べました気がしますがARM社がリリースしているCMSISのコアヘッダファイル
(本来はここまでがCMSISと呼べる範疇)とSTマイクロやNxP等各ベンダがリリースして
いるCMSIS"準拠"ペリフェラルライブラリまで全部ひっくるめて"CMSIS"と混同して呼称
される方が2014年の未だになっても非常に多いです。
ARM本家に日本語で概念が記されていますのでしっかり覚えておきましょう。ちゃんと
違いを理解しておかないと展示会とかイベントやセミナーで"CMSISって無駄にコード
サイズ増えるから使いづらいですね(地獄のミサワみたいな顔で)"と言ってしまい数か月
後に自分の言った言葉の意味を漸く理解して時間差で恥かきます。
かくいう私もえらそうなこと(地獄のミサワみたいな顔で)言ってますが最初にSTM32に
触れた時は思いくそ勘違いしておりましたがー！


…すみませんまた話が脱線しました。今回のCMSIS-V4からは前回の更新で
ヘッダファイルのみが付与されていたcmsis-osが全てのソースコードが
添付されCMSIS_RTXというフォルダに同梱されております。
ライセンス的にもBSDライクなのでむしろFreeRTOSよりも自由度が高いかも
しれません。GCCのコマンドラインでビルドできるようになったら爆発的に
普及すると思います。私もどのようにして実装するか試行中です。

そういう訳で私のいつものSTM32F4のプロジェクトは上記の最新のCMSIS
コアヘッダファイルに差し替えさらにChaN氏のFatFs0.10aのかなり
クリティカルな修正も反映済にしてあります。
Makefileやリンカスクリプトの記述も将来を見据えていくつか変更を加えて
いるので、私のサンプルをベースに何かを作成されている方はご注意ください。




そしてこの記事を書く少し前にSTマイクロよりまたまた新しいSTM32向け
フレームワークが提示されていました。STM32CubeMXと呼ばれるコード
テンプレート作成のためのツールを通してプロジェクトの土台作りの簡略化を
狙うとのこと。

このSTM32CubeMXには今回のCMSIS-V4の思想を反映したCMSIS-Driverなる
ハードウエアの抽象化を狙った規格に準じた新たなSTM32F4向けのペリフェラル
ライブラリが準備されております。
以前のSTM32F4向けCMSIS準拠ペリフェラルライブラリはすでにNRND(非推奨)
となっていますのでF4以外のSTM32品種も今後はこちらをベースとした
ライブラリ群に置き換わっていくことになると思います。

サラっとみた感じでは以前と同じCMSIS準拠なのですがマクロ定義や関数が
かなり違うので右を左にやる感覚で置き換えは不可能で実質全くの別物を
移植する感じで挑みたいと思います！
まずはおなじみのF4系から攻めていきますのでこうご期待！

ちなみにNxPのLPCOpenではSTM32に先駆けて再配布の規約をようやく明確化し、
そして体系化もしたライブラリ群を提供していましたが微妙にCMSISに
準拠していないのでChaN氏にまたDisられないように早急にCMSIS-Driverに
基づいたペリフェラルライブラリ群の整備を行うべきだと感じます。
出た当初は少ない品種だったためまだまとまっていましたが周辺レジスタの
構成が全く違うのに無理矢理LPC1xxx系でひとまとめで括ろうとしたせいで
逆に冗長な記述が増えてしまい結局各シリーズごとにLPCOpenが分かれだした
始末で混乱を極めている感がします。
はっきり言って開発のしやすさ/ライブラリ整備の点ではSTM32やEFM32に
大きく引き離されています。
ChaN氏も言ってましたがこれは非常にまずいです。使いやすいライブラリを
提供するというのはチップのerrataを出さないことと同じくらい非常に
大事なことだと思います。

と、
mbedのセミナーに絶対に行けなくなるような最後っ屁を放ち今日の日記を〆ます。
かしこ

Go to top of page