STM32H7を使ってみる7 -ティアリングを何とかしたい-
←前回 次回→
なんと4年ぶりのSTM32H7の記事です！
ちなみに最新のSTM32H7R/SシリーズについてはOpenOCDが正式対応して
いないため、当面の間はSTM32H747I-Discoveryを使用した記事となります…
お前アリアハンから全然脱出できてないじゃないか！１！！
さて、ねむいさんが公開しているFatFs移植サンプル通称"いつもの"に
ついてはChaN師のFatFsのほかに簡易ファイラーやtxt(S-JISのみ)ファイル、
さらに独自フォーマットの動画ファイルも対応しております。
それでSTM32H747I-DISCOはDSIインターフェースでLTDCを動作させて
映像を出力しているのですが、素早く画面切り替えた際や動画再生時などに
画面のティアリングが発生してしまっておりました。
例としてゼERO動画を再生しているところ
赤色で線引いて強調してみましたが横方向のティアリングの上に斜め方向
にもティアリングが発生してしまっている状態です。
横方向のティアリングはLTDCのVSYNCを待つようにしたら解消しました。
具体的なコードは下記のようなコードをDMA2Dでぶん投げる前に挿入すれば
解決です。
/**************************************************************************/
/*!
Wait VSYNC signal.
*/
/**************************************************************************/
void Display_WaitVSYNC(void)
{
/* reload shadow registers on vertical blanking period */
LTDC->SRCR = LTDC_SRCR_VBR;
/* wait for next frame */
while ((LTDC->CDSR & LTDC_CDSR_VSYNCS) == 0);
}コード詳細は./lib/display/mcu_depend/src/lcdc_if_basis.cと
./lib/display/abstract/src/ts_fileloads.cを参考にしてください。
しかし、斜め方向のティアリングはこれでだけは解消しませんでした…
画面切り替えたときとかの斜め方向のティアリングがどうしても
気になってしまう…
不思議なことに斜めティアリングはDSI接続のLCDモジュールを横方向
(LANDSCAPE)で使用した時だけ発生し、縦方向(PORTRAIT)なら一切発生
しないことに気づきました…いないさんかわいい…
STのフォーラムも調べてみましたが同じ現象に悩んでる方が結構いることが
わかりました
��STM32F769-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人
��ねむいさんとおなじSTM32H747I-DISCOを使ってる人
��STM32F469I-DISCOを使ってる人その２
共通するのはDSIインターフェースのLCDモジュールを横方向で使った際に
斜めティアリングが出ちゃっているようです。
ちなみにねむいさんが所持しているSTM32F769N-Discoveryでも同じ現象が
発生しておりました。
�，里箸海蹐�ST社員の人が斜めティアリングが起こる仕組みと対策を示して
おりました。
ねむいさん所持のSTM32H747I-DISCOのTFT-LCDモジュールのコントローラは
OTM8009Aという480x800(MAX864)のWVGAの縦方向表示に特化したやつでした。
横方向にして使用すると原理通りスキャン方向の相違が起こって斜め方向に
ティアリングが発生してしまうということなのでしょうか…
で、原理は納得しましたが具体的な対策(フレームバッファを2分割せよ)
とやらを文字で示していますがソースは提示されておらずねむいさんは
肝心のソースコードを知りたかったので再び泥沼にはまってしまいました。
しかし…
最後の�い里箸海蹐�VerticalBackPorch(VBP)を増やしたら斜めティアリングを
画面の外に蹴りだせたとコメントを見つけ、ねむいさんも真似してやってみた
所確かに斜めティアリングが垂直方向に移動しました。
いろいろ試した結果、VBPの値を480追加すると丁度画面から消えるのが判明し
横方向表示の際の時だけVBPにVBP_OFSとして480を追加するようにしました。
/* Timing parameters for all Video modes
* Set Timing parameters of LTDC depending on its chosen orientation
*/
/* The following values are same for portrait and landscape orientations */
if(Orientation == LCD_ORIENTATION_PORTRAIT)
{
VSA = OTM8009A_480X800_VSYNC; /* 1 */
VBP = OTM8009A_480X800_VBP; /* 15 */
VFP = OTM8009A_480X800_VFP; /* 16 */
HSA = OTM8009A_480X800_HSYNC; /* 2 */
HBP = OTM8009A_480X800_HBP; /* 34 */
HFP = OTM8009A_480X800_HFP; /* 34 */
}
else
{
/* lcd_orientation == LCD_ORIENTATION_LANDSCAPE */
VSA = OTM8009A_800X480_VSYNC; /* 1 */
VBP = VBP_OFS + OTM8009A_800X480_VBP; /* 15(+480) */
VFP = OTM8009A_800X480_VFP; /* 16 */
HSA = OTM8009A_800X480_HSYNC; /* 2 */
HBP = OTM8009A_800X480_HBP; /* 34 */
HFP = OTM8009A_800X480_HFP; /* 34 */
} 
…コメント先ではNT35510のLCDモジュールではうまくいかなかったという
結果でしたがねむいさんがもってるOTM8009Aの奴は対策できたっぽいので
まぁワークアラウンドとしてはいいのかな…と思いまし、た！
DSI接続のLCDモジュールがあるDiscovery系ボードをお持ちで同じような
問題抱えてる方は追試していただけたら幸いです…！！
おきぱのSTM32H7,STM32F7のサンプルはワークアラウンド済です。
STM32H5を使ってみる5 -普通のSPIをDMAと交えて使う-
20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:
初めてSTM32H5を触った時も述べましたが、L5と比べてSPIやDMAの扱いが
ちょっと癖があって違います。今回はその使い方の一例を紹介します。
なお、ねむいさんのSTM32H5のプロジェクトではSPIをシリアル接続の
TFT-LCD(ST7789V2コントローラIC)で使用しております。
●コード解説(基本設定編)
以下はねむいさんのSTM32H563ZI-NUCLEO向けのプロジェクト中の
./lib/display/mcu_depend/src/display_if_basis.cを解説していきます。
./lib/display/mcu_depend/inc/display_if_basis.hも参照のこと。
Display_IoInit_If()内でハードウエアSPIからDMAの設定までやっちゃって
ますが少しずつ分解していきます。
まずはI/Oの設定です。
GPIO_InitTypeDef GPIO_InitStructure = {0};
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
/* Enable CTRL line GPIO settings */
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_RES);
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_CS);
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_DC);
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SCK);
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDO);
GPIO_InitStructure.Pin = CTRL_RES;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Pull = GPIO_NOPULL;
GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStructure.Alternate = 0;
HAL_GPIO_Init(DISPLAY_PORT_RES, &GPIO_InitStructure);
GPIO_InitStructure.Pin = CTRL_CS;
HAL_GPIO_Init(DISPLAY_PORT_CS, &GPIO_InitStructure);
GPIO_InitStructure.Pin = CTRL_DC;
HAL_GPIO_Init(DISPLAY_PORT_DC, &GPIO_InitStructure);
/* Set peripheral clock */
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_SPI1;
PeriphClkInitStruct.Spi1ClockSelection = RCC_SPI1CLKSOURCE_PLL1Q;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
{
for(;;){
__NOP();
}
}
DISPLAY_PERIF_CLK(ENABLE);
/* Connect SPI pins to aletenate function */
GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
GPIO_InitStructure.Pull = GPIO_NOPULL;
GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
/* SPI SCK pin configuration */
GPIO_InitStructure.Pin = CTRL_SCK;
GPIO_InitStructure.Alternate = SRC_SCK;
HAL_GPIO_Init(DISPLAY_PORT_SCK, &GPIO_InitStructure);
/* SPI MOSI pin configuration */
GPIO_InitStructure.Pin = CTRL_SDI;
GPIO_InitStructure.Alternate = SRC_SDI;
HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);
/* SPI MISO pin configuration */
GPIO_InitStructure.Pin = CTRL_SDO;
GPIO_InitStructure.Alternate = SRC_SDO;
HAL_GPIO_Init(DISPLAY_PORT_SDO, &GPIO_InitStructure);SCK,MOSI,MISOはAlternateFunctionとして、RESET・CS・DCはGPIOとして
設定します。
お次はSPIモジュールの設定です。
/* SPI configuration */
SpiHandle.Instance = LCD_SPI;
SpiHandle.Init.Mode = SPI_MODE_MASTER;
SpiHandle.Init.Direction = SPI_DIRECTION_2LINES;
SpiHandle.Init.DataSize = SPI_DATASIZE_8BIT;
SpiHandle.Init.CLKPolarity = SPI_POLARITY_HIGH;
SpiHandle.Init.CLKPhase = SPI_PHASE_2EDGE;
SpiHandle.Init.NSS = SPI_NSS_SOFT;
SpiHandle.Init.BaudRatePrescaler = SPI_BaudPrescale;
SpiHandle.Init.FirstBit = SPI_FIRSTBIT_MSB;
SpiHandle.Init.TIMode = SPI_TIMODE_DISABLE;
SpiHandle.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
SpiHandle.Init.CRCPolynomial = 0x7;
SpiHandle.Init.CRCLength = SPI_CRC_LENGTH_8BIT;
SpiHandle.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
SpiHandle.Init.NSSPolarity = SPI_NSS_POLARITY_LOW;
SpiHandle.Init.FifoThreshold = SPI_FIFO_THRESHOLD_01DATA;
SpiHandle.Init.MasterSSIdleness = SPI_MASTER_SS_IDLENESS_00CYCLE;
SpiHandle.Init.MasterInterDataIdleness = SPI_MASTER_INTERDATA_IDLENESS_00CYCLE;
SpiHandle.Init.MasterReceiverAutoSusp = SPI_MASTER_RX_AUTOSUSP_DISABLE;
SpiHandle.Init.MasterKeepIOState = SPI_MASTER_KEEP_IO_STATE_ENABLE; /* avoid glitch */
SpiHandle.Init.IOSwap = SPI_IO_SWAP_DISABLE;
SpiHandle.Init.ReadyMasterManagement = SPI_RDY_MASTER_MANAGEMENT_INTERNALLY;
SpiHandle.Init.ReadyPolarity = SPI_RDY_POLARITY_HIGH;
if(HAL_SPI_Init(&SpiHandle) != HAL_OK)
{
/* Capture error */
while (1);
}
/* Enable SPI module */
LCD_SPI->CR1 |= SPI_CR1_SPE;
LCD_SPI->CR1 |= SPI_CR1_CSTART;HAL_SPI_Init()が完了したらCR1レジスタのSPEとCSTARTビットを1にして
SPIモジュールをスタート状態にさせるのがミソです。
設定中で
SpiHandle.Init.BaudRatePrescaler = SPI_BaudPrescale;ですが
#define SPI_BaudPrescale SPI_BAUDRATEPRESCALER_4 /* PLL1Q CLK 100MHz/4 = 25MHz */とdefineしております。SPIのクロックは25MHzとしてます。
20240502追:
ST7789V2のSCLのクロック最大値ちゃんと調べたらなんと60MHzでした！！！
全然余裕でしたすみません！！！！！
20240502追:
そしてDMAの設定です…これが一番苦労しました。
/* DMA controller clock enable */
__HAL_RCC_GPDMA1_CLK_ENABLE();
/* DMA interrupt init */
/* SPILCD_DMA_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SPILCD_DMA_IRQn, 3, 0);
HAL_NVIC_EnableIRQ(SPILCD_DMA_IRQn);
/* Configure DMA request LcdDmaHandle */
LcdDmaHandle.Instance = SPILCD_DMA_CHANNEL;
LcdDmaHandle.Init.Request = SPILCD_DMA_REQEST;
LcdDmaHandle.Init.BlkHWRequest = DMA_BREQ_SINGLE_BURST;
LcdDmaHandle.Init.Direction = DMA_MEMORY_TO_PERIPH;
LcdDmaHandle.Init.SrcInc = DMA_SINC_INCREMENTED;
LcdDmaHandle.Init.DestInc = DMA_DINC_FIXED;
LcdDmaHandle.Init.SrcDataWidth = DMA_SRC_DATAWIDTH_BYTE;
LcdDmaHandle.Init.DestDataWidth = DMA_DEST_DATAWIDTH_BYTE;
LcdDmaHandle.Init.Priority = DMA_LOW_PRIORITY_HIGH_WEIGHT;
LcdDmaHandle.Init.SrcBurstLength = 1;
LcdDmaHandle.Init.DestBurstLength = 1;
LcdDmaHandle.Init.TransferAllocatedPort = DMA_SRC_ALLOCATED_PORT0|DMA_DEST_ALLOCATED_PORT0;
LcdDmaHandle.Init.TransferEventMode = DMA_TCEM_BLOCK_TRANSFER;
LcdDmaHandle.Init.Mode = DMA_NORMAL;
if (HAL_DMA_Init(&LcdDmaHandle) != HAL_OK)
{
for(;;){
__NOP();
}
}
__HAL_LINKDMA(&SpiHandle,hdmatx,LcdDmaHandle);
if (HAL_DMA_ConfigChannelAttributes(&LcdDmaHandle, DMA_CHANNEL_NPRIV) != HAL_OK)
{
for(;;){
__NOP();
}
}
/* SPI interrupt init */
/* SPILCD_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SPILCD_IRQn, 3, 1);
HAL_NVIC_EnableIRQ(SPILCD_IRQn);今回はTFT-LCDに向けてひたすらデータをバイト単位でぶん投げるので
LcdDmaHandle.Init.Direction = DMA_MEMORY_TO_PERIPH;
LcdDmaHandle.Init.SrcInc = DMA_SINC_INCREMENTED;
LcdDmaHandle.Init.DestInc = DMA_DINC_FIXED;
LcdDmaHandle.Init.SrcDataWidth = DMA_SRC_DATAWIDTH_BYTE;
LcdDmaHandle.Init.DestDataWidth = DMA_DEST_DATAWIDTH_BYTE;の部分が重要です。
そしてなんでかDMAのほかにSPIの割り込みも要求してくるので
DMAの設定の最後にSPIの割り込みも必ず有効にします。
●コード解説(基本データのやり取り編)
SPI接続のTFT-LCDの基本は8bitのデータをやり取りします。
で、STM32H5では8bitデータのやり取りするのに素直にTDRにデータを
放り込んでもまともに送出されないのでちょっと細工する必要があります。
まずは8bit単位でデータをやり取りするためのdefine
#define SPIx_TDR8 *(__IO uint8_t *) ((uint32_t)LCD_SPI+0x20)
#define SPIx_RDR8 *(__IO uint8_t *) ((uint32_t)LCD_SPI+0x30)☝を利用した送信関数はこちら
inline void SendSPI(uint8_t dat)
{
/* Send byte through the SPI peripheral */
SPIx_TDR8 = dat;
/* Wait to receive a byte */
while (!(LCD_SPI->SR & (SPI_FLAG_RXP)));
/* Drain Rx FIFO */
SPIx_RDR8;
}
inline void SendSPI16(uint16_t dat)
{
SendSPI((uint8_t)(dat>>8));
SendSPI((uint8_t)dat);
}STM32CubeH5のHALドライバの送信関数は異常なまでにオーバーヘッドが大きい
ですが中身を分解して簡略化すると送信はここまでシンプルになります。
さらにST7789V2向けには上記関数を利用してCMD,DATA,GRAM書き込み用に拵えます。
/**************************************************************************/
/*!
Write LCD Command.
*/
/**************************************************************************/
inline void ST7789V2_wr_cmd(uint8_t cmd)
{
ST7789V2_DC_CLR(); /* DC=L */
DISPLAY_ASSART_CS(); /* CS=L */
SendSPI(cmd);
DISPLAY_NEGATE_CS(); /* CS=H */
ST7789V2_DC_SET(); /* DC=H */
}
/**************************************************************************/
/*!
Write LCD Data and GRAM.
*/
/**************************************************************************/
inline void ST7789V2_wr_dat(uint8_t dat)
{
DISPLAY_ASSART_CS(); /* CS=L */
SendSPI(dat);
DISPLAY_NEGATE_CS(); /* CS=H */
}
/**************************************************************************/
/*!
Write LCD GRAM.
*/
/**************************************************************************/
inline void ST7789V2_wr_gram(uint16_t gram)
{
DISPLAY_ASSART_CS(); /* CS=L */
SendSPI16(gram);
DISPLAY_NEGATE_CS(); /* CS=H */
}一応Readも実装しておりますが以前も解説しておりますので今回は割愛します。
●コード解説(DMAでぶん投げる編)
これが一番難しいです…HALドライバの作例はLinkListを使用した複雑な
DMA転送しかコード例がなくてシンプルなDMAのコード例がなく作りこみに
非常に苦労しました…が、何とかなりました。
まずはHALライブラリのDMA,SPIのIRQハンドラを定義します。
/* DMA IRQ Handler */
void SPILCD_DMA_HANDLER(void)
{
HAL_DMA_IRQHandler(&LcdDmaHandle);
}
/* SPI IRQ Handler */
void SPILCD_IRQHandler(void)
{
HAL_SPI_IRQHandler(&SpiHandle);
}そんでもって今回はSend専用なのでSPIの割り込みでTx完了のコールバック
関数を定義します。
/* SPI-DMA IRQ Callback */
void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)
{
if(hspi->Instance == LCD_SPI){
wTransferState = TRANSFER_COMPLETE;
}
}STM32L5の場合はSPIの割り込みが必要なかったのですが、H5では割り込み
必須になっていやがります…！なお、STM32H7も同じくDMA転送にSPIの
割り込み設定が必須です(使ってなかったから今まで知らんかった…)。
実際のDMA転送関数はこちらになります。
/* DMA transaction */
void lcd_dma_transfer(const uint8_t *buff,unsigned int count)
{
/* Disable SPI to change register */
LCD_SPI->CR1 &= ~(SPI_CR1_SPE);
/* Start DMA */
if (HAL_SPI_Transmit_DMA(&SpiHandle, buff, count) != HAL_OK)
{
for(;;){
__NOP();
}
}
/* Wait transfer complete */
while (wTransferState == TRANSFER_WAIT) {};
/* Restore transfer state */
wTransferState = TRANSFER_WAIT;
/* Restore nomal transfer settings */
LCD_SPI->CR2 = 0; /* Restore TSIZE */
LCD_SPI->CFG2 &= ~(SPI_CFG2_COMM_Msk); /* Restore FULL duplex mode */
LCD_SPI->CR1 |= SPI_CR1_SPE; /* Re-enable SPI module */
LCD_SPI->CR1 |= SPI_CR1_CSTART; /* Re-start SPI Trasfer ready */
}転送の手順は
��SPIモジュールをDisable
��HAL_SPI_Transmit_DMAを実行
��SPIのコールバック関数が転送完了を捕まえるまで待つ
�ぜ，療樵�の準備を設定
となります。
特に�い硫宍�コードに相当する後処理は超重要です！！
/* Restore nomal transfer settings */
LCD_SPI->CR2 = 0; /* Restore TSIZE */
LCD_SPI->CFG2 &= ~(SPI_CFG2_COMM_Msk); /* Restore FULL duplex mode */
LCD_SPI->CR1 |= SPI_CR1_SPE; /* Re-enable SPI module */
LCD_SPI->CR1 |= SPI_CR1_CSTART; /* Re-start SPI Trasfer ready */これをやっておかないと通常転送ができなくなるので必ず
後処理はは忘れずに！！どれが欠けても動かなくなります。
こんなわけでかなり癖があるSTM32H5のSPIをDMAと交えて使用してみました。
今回は8bitSPI接続のTFT-LCD接続に特化したコードの紹介となりましたが、
繋がるSPIデバイスの特性よって設定はかなり変わりますのでそれぞれで
試行錯誤が必要となるでしょう…
…正直OCTO-SPIやSDMMCとかより動かすのしんどかった…。
いろいろ試す60
いろいろ試してきてついに60回を迎えてしまいましたが
ほんっと大したことやってませんね…
●ぶろぐの画像の修正すべて完了の件
2016年からはや7年も経過してしまいましたがdropboxの仕様変更のあおりを
受けて表示できなくなっていた画像ですがすべて修正が完了致しました！！
長かった…一番しんどかったのは東海自然歩道や登山関連の超大量の
画像の差し替え作業でしたがなんとかすべてこなすことができました…
もう10年以上前になるものもあって本当に年月を感じ…
あああああああああああああああああああああ！！！！１１１！！！１
現在はEDGEで見た際に表示が崩れないようにレイアウトの修正を細々と
行っております。
ゆくゆくはwordpressに移行を考えておりますが…何年後かな…？
●Windows10以降対応の64bit版FONTX2コンバータ作りました
FONTX2は現在では電子工作で大人気のフォントフォーマットです。
詳しい解説はおなじみChaN師のサイトでもされており参考になります。
ところで現在Windowsで使われているTrueTypeフォントからFONTX2ファイルを
作成したい場合はかつてはWFONTXという非常に便利なツールが存在して
いたのですがこれはWindowsNT3.1用の代物で、64bitOSが全盛の現在では
動作させることができません。
そこでねむいさんが64bitOS対応のWFONTX64を作成いたしました！
これはオリジナルからXPに対応されたすん様のWFONTX32をベースとしております。
ねむいさんが見つけた細かいバグ等も修正し使い勝手を多少上げました。
☆使い方☆
まずはプログラムを開いたところです。
ここではねむいさんの最近のお気に入りの小夏フォントを12x12pixelの
FONTX2化する例を挙げます。
注:あらかじめ小夏フォントをインストールしているのが前提です！
ドロップダウンメニューから"小夏 等幅"を選択します。
次に高さと幅をピクセル数で指定します。ここで注意ですがたとえば12x12で
表示したい場合はHeightに12,WidthにHeightの半分の6を指定します。
Widthに12をしてしまうと横長になっちゃいます。
12の半分の6を指定してください。
"FontX2 Name"の欄にはFONTX2のヘッダを指定します。FONTX2の仕様上8文字
以上は指定できません(8文字以上入力できないようにしてます)。
ここではKONATHNとします。
また、FontX2Typeは半角の"Ank"を指定します。
Save Nameの欄は生成されるファイル名を指定します。
KONATHN12.FNTとします。
ここまで入力したら"RUN"と"NO STOP"が押せるようになります。
"RUN"はダイアログに1文字ずつ表示しながら変換(遅い)、"NO STOP"は表示
せずに一気に変換します(早い)。
変換が終わるとKONATHN12.FNTが生成されます。
生成されたのはFONTX2の中のAnkフォントで半角のAscii文字だけが
格納されてます。漢字などの2バイト文字は全角用の生成操作が
必要です。
お次は2バイトの全角です。ラジオボタンをAnkからKanjiに変え、
Save NameはKONATZN12.FNTとしましょう。
これで半角・全角のFONTX2ファイルが無事生成されました！
で、こいつをねむいさんのいつものに組み込んでSTM32H5使ってTFT-LCDに
FONTX2ドライバを使って表示できました。
こんなわけで30年の時を超えて現在でもお手軽にマイコンで好きな文字が
お手軽に表示できるようになっております。
また、生成したFONTX2ファイルを含むソースコードの再配布の際は元の
フォントのライセンスに注意し、それに従ってください。
●avrdudeがv7.2になっていた
亀のような更新速度だったころから比べると日々増殖する小宇宙状態と
なっているavrdudeですがいつのまにかv7.1->v7.2に進化しております。
紹介しきれないくらい機能がアップしておりますので特に細かい不具合が
つぶさに修正されておりますので特に理由がない場合以外はv7.2に乗り
変えましょう。
ねむいさんもVerupのスピードに振り落とされないようにしがみついており、
おきぱでも常に最新のavrdudeのwindowsバイナリを公開しておりますので
よろしくお願いします！！
●CMSISもv6になっていた
10年ほどの間CMSISはver5のままメンテが行われておりましたが今年の
春くらいからver6に移行しております。
大まかな構成は変わっておりませんのでそのまま置き換えてビルドが
可能になっております。
この記事を書いてる現在では修正されましたがGCCでコンパイルした際に
"#pragma clang system_header"が引っかかってワーニングが出まくる
事態となっておりましたが10月末にようやく修正されました。
おきぱで紹介しているいつものたちはその修正されたものを適用してますので
こちらもどしどしご利用ください！
●そのGCCも13になっていた
そしてGCCも12から13にバージョンアップしておりました。
arm-none-eabi-gcc (Arm GNU Toolchain 12.3.Rel1 (Build arm-12.35)) 12.3.1 20230626->
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009ねむいさんのSTM32H7-Discovery向けプロジェクト"いつもの"のバイナリサイズを
比較してみましょう。
GCC12
Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_OTM8009A_DSI_TFT
USING_DEVBOARD = USE_STM32H747I_DISCO
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 709212 0 709212 ad25c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
707324 1888 2384060 3093272 2f3318 main.elf
main.elf :
section size addr
.text 0xac840 0x8000000
.ctors 0x0 0x80ac840
.dtors 0x0 0x80ac840
.eh_frame 0xb0 0x80ac840
.ARM.exidx 0x98 0x80ac8f0
.itcm 0x174 0x0
.data 0x760 0x24000000
.bss 0x11f2c 0x24000760
.heap 0x0 0x2401268c
.dtcm 0x20c 0x20000000
.stack 0x4 0x2000020c
.ram1_d2 0x0 0x30000000
.ram2_d2 0x0 0x30020000
.ram3_d2 0x0 0x30040000
.ram4_d3 0x0 0x38000000
.batram 0x0 0x38800000
.extram 0x233f80 0xd0000000
.qspirom 0x0 0x90000000
.comment 0x45 0x0
.debug_frame 0x1f7c 0x0
.ARM.attributes 0x30 0x0
.debug_line_str 0x1f4 0x0
Total 0x2f54fdGCC13
Built Informations:
USING_SYSTEM = BARE_METAL
USING_DISPLAY = USE_OTM8009A_DSI_TFT
USING_DEVBOARD = USE_STM32H747I_DISCO
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 709868 0 709868 ad4ec main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
707980 1888 2384060 3093928 2f35a8 main.elf
main.elf :
section size addr
.text 0xacad0 0x8000000
.ctors 0x0 0x80acad0
.dtors 0x0 0x80acad0
.eh_frame 0xb0 0x80acad0
.ARM.exidx 0x98 0x80acb80
.itcm 0x174 0x0
.data 0x760 0x24000000
.bss 0x11f2c 0x24000760
.heap 0x0 0x2401268c
.dtcm 0x20c 0x20000000
.stack 0x4 0x2000020c
.ram1_d2 0x0 0x30000000
.ram2_d2 0x0 0x30020000
.ram3_d2 0x0 0x30040000
.ram4_d3 0x0 0x38000000
.batram 0x0 0x38800000
.extram 0x233f80 0xd0000000
.qspirom 0x0 0x90000000
.comment 0x44 0x0
.debug_frame 0x1d1c 0x0
.ARM.attributes 0x30 0x0
.debug_line_str 0x1f4 0x0
Total 0x2f552cあれ…なんかバイナリサイズが600Byte近くも増えてるような…
と、とりあえず速度比較もしてみましょう
jpegファイルのデコード速度を比較します。-O2でコンパイルしました。
GCC12:(236704uSec)
GCC13:(237486uSec)
…
あ…あれ…結構遅くなってる…！？
ま、まぁ多分何かの安定性が上がったかもなのでよしとしましょう…
(脂汗)
STM8Lを使ってみる2 -いきなり終わった-
前回のあらすじ
STM32C0の登場によりSTM8Lはお役御免のNRNDとなってしまいました。
めでたしめでたし。
…
で終わったらマサカリ投げられそうなのでもう少し使ってるところを提示
して荼毘に付そうと思います…！
8pinのSTM8L050J3M3を使用します。
●ビルド環境を整える
STM8Lはかつては有償の使いづらいツールしかなかったのですが、
現在ではSDCCというGCCライクな無償のツールチェインがあります。
一方STM8LもStandardPeripheralLibrary(SPL)があるのですが、これは
SDCCに対応しておりません。しかしながら有志の方がSDCCに対応したSPL
を提供してくれております。これを利用しましょう。
また、SDCC向けのmakefileも公開しておりますのでありがたく利用させて
もらいます。基本的にSTM32でやっていたビルド環境構築と同じように
拵えていきます。
ねむいさんの作例はUARTで"unk!"を送出しながらLEDをトグルします。
基本中の基本ですね。ちなみにAVRと違ってPROGMEMとかしないでもconstが
ちゃんと機能したりしますが今となってはどうでもいいですね。
なお、読み書きデバッグで使用するSWIMピンはInput/Outputを設定する
ことができますが特にOutputに設定してしまうとBrickedしてしまうので
厳重に注意してください！！！
AN5065は穴のあくほど目を通しておきましょう。ねむいさんはSetSystem()
関数内でフェールセーフを実現しています。またBricked対策のほかに
未使用ピンは入力プルアップしておきましょう。
↓実際のSetSystem関数です。
/**************************************************************************/
/*!
@brief Configures Main system clocks & power.
@param None.
@retval None.
*/
/**************************************************************************/
void Set_System(void)
{
/* STARTUP SWIM DELAY AT FIRST(MUST NEED avoid bricking) */
for(int d = 0; d < 3000; d++) {
for(int i=0;i<100; i++){nop();}
}
/* not connected pins as output low state (the best EMC immunity)
(PA1, PB0, PB1, PB2, PB4)*/
GPIOA->DDR |= GPIO_Pin_1;
GPIOB->DDR |= GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_4;
/* configure all STM8L050 pins as input with pull up */
GPIO_Init(GPIOC, GPIO_Pin_6, GPIO_Mode_In_PU_No_IT); // pin 1
GPIO_Init(GPIOA, GPIO_Pin_3, GPIO_Mode_In_PU_No_IT); // pin 2
GPIO_Init(GPIOD, GPIO_Pin_0, GPIO_Mode_In_PU_No_IT); // pin 5
GPIO_Init(GPIOB, GPIO_Pin_6, GPIO_Mode_In_PU_No_IT); // pin 6
GPIO_Init(GPIOB, GPIO_Pin_7, GPIO_Mode_In_PU_No_IT); // pin 7
GPIO_Init(GPIOC, GPIO_Pin_5, GPIO_Mode_In_PU_No_IT); // pin 8
/* Set the frequency to 16 MHz */
CLK_SYSCLKSourceConfig(CLK_SYSCLKSource_HSI);
CLK_SYSCLKDivConfig(CLK_SYSCLKDiv_1);
/* Set delay timer */
SysTickInit();
/* Configure the LED */
LED_Configuration();
}また、UARTの送信は送信割り込みを使用しておりますがSDCCの制約でなぜか
main関数に割り込みハンドラのプロトタイプ宣言をしないと割り込みが
機能しません。
これについてはuart_support.hにプロトタイプ宣言を放り込んでincludeして
やれば解決です。
無事ビルドできました。OpenOCDはSTM8シリーズの書き込みに対応している
のでSTM32感覚で書き込みが可能です。
↓書き込みのログです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select swim" -f target/stm8l05x_swim_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00352-g1bc4182ce (2023-10-08-09:55)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
swim
Warn : Transport "swim" was already selected
Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.874897
Info : clock speed 800 kHz
Info : starting gdb server for stm8l.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, pc: 0x00006000
Info : downloaded 4253 bytes in 1.148543s (3.616 KiB/s)
Info : verified 4253 bytes in 0.172508s (24.076 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02
LEDが点滅し、一応動いてます…
●デバッグはどうするのか？
もちろんOpenOCDとGDBを組み合わせてデバッグが可能です。
必要なものは以下の3点です。
・OpenOCD
・binutils(stm8-gdb)
・CodeLite
OpenOCDはもう説明する必要もない定番でしょう〜。
binutilsは幸運にもPlatformI/OのサイトにWindows向けのビルド済み
binutilsバイナリが公開されているのでこれを利用します。
CodeLiteは統合開発環境ですが今回はGDBのGUIとして利用します。
まだ整備中ですがねむいさんのARMマイコンデバッグ手順を参考に
makefileに記述されたディレクトリと各ツールのディレクトリを
一致させておいてください。
ねむいさんの作例は基本的に下記のディレクトリ構成としております。
・OpenOCD
C:/Devz/ARM/ocd・binutils(GDB)
C:/Devz/sdcc/tool-stm8binutils/bin・CodeLite
C:/Devz/ARM/CodeLite
まず初めにmakefileの"DEBUG_MOD = 1"の設定した状態でビルド・書き込み
を行ってください。
MAKE DEBUGでCodeLiteとOpenOCDを同時に呼び出します。
GDBの設定はsettings->debuggerのタブで設定します。
まずはGDBの実行形式ファイルとGDBの基本設定を行います。
次のタブ(Startup Commands)で"set output-radix 16"を設定しておきます。
これはレジスタを16進数で参照するために必要なものです。
最後のタブはお決まりのリセット->main関数の先頭で停止コマンドを
設定しておきましょう。これで準備完了です。
メイン画面に戻ってDebugger->Start/Continue Debuggerでデバッグ開始です。
無事main関数の最初の行で止まりました。
ちゃんとレジスタも16進数で参照できてますね。
ステップ実行も自由自在です☆
ちなみにデバッグを終わらせる際はtaskkilでOpenOCDとCodeLiteを
強制終了させて終わります。強引ですがこれが一番確実です。
と、
こんな感じでフリーなツールでSTM8Lの開発ができちゃいます…
…
が、
冒頭で言ったようにSTM8シリーズはSTM32L1と同じくNRND、もう新規採用は
不適となっております。
しかしながらこれも時代の流れ、後進のSTM32C0の活躍を見守りましょう〜
というわけで今回使用したねむいさんのSTM8Lプロジェクトをここに
おいておきます。今更STM8を使ってみたいという奇特な方だけどうぞ…！
いろいろ試す59
●STM32L1とSTM8シリーズがNRNDになってしまった…
ほら言わんこっちゃない…温めすぎて腐ってしまいました…orz
STM8シリーズはもう少し進めたかったのですがSTM32C0が登場して
既存の8ビットはエコシステムから排除され駆逐される勢いとなって
しまいましたね…STM32L1のほうはSTM32L0,STM32U5とかが登場した
のでお役御免となった感じでしょうか…
今のラインナップを鑑みるにねむいさんが使ってきたSTM32F2やF4,
L4,L5とかも次のNRND候補になっちゃいそうですね…
まぁこれも時代の流れということで…とにも書くにもSTM8Lに関しては
最後っ屁で一件記事書いてクローズとさせてもらおうとおもいます…！
●STM32F4のHALじゃなくてSPLがアップデートしていたが…
2022年にHALライブラリじゃなくて古のStandardPeripheralLibraryが
アップデートしていたようです…内容は…
余計なことするな〜〜！
GPIOのレジスタ周りは致命的だったのでここだけ元に戻してアップデート
いたしました…
●ILI9341をシリアル接続で動かした際にDeviceIDを読み出す方法
10年前に一度記事を書きましたが10年の時を超えて皆忘れてしまってる
ようなので改めて詳しく解説しようと思います。
ILI9340,ILI9341,ILI9342のILITEK製のTFT-LCDコントローラはDeviceID
をそれぞれ持っておりそれらの読み出しコマンドは"0xD3"を使用します。
尤もi8080などのパラレルなデータバスの読出しはデータシートの
通りに従えば期待していたDeviceID(ILI9341なら0x9341)を読み出す
ことができます。しかし、SPI(以下シリアル)バス接続の場合は何故か
この通りにやっても絶対に読み出すことはできません。
これについては10年以上前から様々なコミュニティで話題が上がって
おりますがシリアル接続では独特の手順をもってしないと読みだす
ことができません。
ILI934x系のコントローラはシリアル接続でレジスタの値を読み出す
ためにはデータシート未記載の"undocumented"なレジスタにアクセス
する必要があります。それがRegisterReadIndex(0xD9)です！
使い方は以下の通りです。ReadID4コマンド(0xD3)を実行してシリアル
接続でDeviceIDを読み出す手順です。
/**************************************************************************/
/*!
Read ID ILI934x.
*/
/**************************************************************************/
static uint16_t ILI934x_rd_id(uint8_t cmd)
{
uint16_t val;
uint16_t temp;
ILI934x_wr_cmd(0xD9); /* SPI Register Read Command */
ILI934x_wr_dat(0x10); /* Read Mode Enable,1st Byte */
temp = ILI934x_rd_cmd(cmd); /* Dummy Read */
ILI934x_wr_cmd(0xD9); /* SPI Register Read Command */
ILI934x_wr_dat(0x11); /* Read Mode Enable,2nd Byte */
temp = ILI934x_rd_cmd(cmd); /* Dummy Read */
ILI934x_wr_cmd(0xD9); /* SPI Register Read Command */
ILI934x_wr_dat(0x12); /* Read Mode Enable,3rd Byte */
temp = ILI934x_rd_cmd(cmd); /* Upper Read */
ILI934x_wr_cmd(0xD9); /* SPI Register Read Command */
ILI934x_wr_dat(0x13); /* Read Mode Enable,4th Byte */
val = ILI934x_rd_cmd(cmd); /* Lower Read */
val &= 0x00FF;
val |= (uint16_t)temp<<8;
return val;
}このようなかんじでシリアル接続でもDeviceIDを読みだせます。
なんでデータシート未記載なんだYO！とお思いの方もいらっしゃる
でしょうが、実は近年にリニューアルされたデータシートにはちゃんと
記載されてやがったりします。これはILI9342"C"のデータシートです。
もちろんILI9342無印では記述がありませんでした。
また、同様のアクセス方法としてはILI9486Lも同機能のコマンドが存在
しております。てか"DGAMCTRL (Digital Gamma Control 2)"とかなってて
でたらめでめっちゃ適当ですね…
さらに今年判明した衝撃の事実ですが128x128サイズを主にサポートする
ILI9163系のコントローラも0xD9を実行すると不可能だと思われていた
シリアル接続のDeviceIDを読み出し可能なことを確認しました！！
ソースコードに上記のように反映しております！
という感じで定期的に持ち上がるILI934x系のネタですがシリアル接続で
この液晶を使うシーンが極めて多いので情報としてしっかり残して
おこうと思います！
最も昨今はST7789Vx一族にだいぶ押されておりますがー！
これらの成果物は主におきぱにあるSTM32F4のFatFs移植作例に収蔵
されております。プロジェクトの下記ドライバを参照してください。
./lib/display/drivers/src/ili934x.c(ILI9342を除く)
./lib/display/drivers/src/ili9342.c
./lib/display/drivers/src/ili9481.c
./lib/display/drivers/src/ili9163x.c
●新液晶モジュール続々登場！
液晶モジュールつながりでもう一件です。
超久しぶりですがこの前ST7789V2にも対応したついでに新たに買った
中華TFT液晶モジュールをいくつか紹介させていただきます。
こちらはなななんと5inchで540x960pixelでi8080データバス対応という
今までで最大サイズの液晶モジュールです！！！！！
コントローラはNT35516という品種です。
480x854が今までの最大サイズだったので大進化ですね〜
で、動かそうとすると結構癖があった…
データバスが外来ノイズに弱くてすぐ崩れるのでねむいさんのいつもの
に合わせるのに結構苦労しましたがなんとか安定動作できるように
なりました。それにしても540x960は広すぎる…
ついに(叢雲のコスプレをした)いないさんの全身が見切れせずに
表現できるように！！やった！！
とはいえ静電性タッチパネルが装着されたモデルがまだAliexpressに
登場してないのでメインで使用する段階ではないです…
やっぱしILI9806Gなこいつが一番使いやすいですね…！
お次はHX8363Bをコントローラに持つ3.97inch,480x800な現在では
定番サイズの液晶です。こちらもタッチパネルなしです。
ていうかなんなんだ真ん中のシールは。
このコントローラはちょっと癖があって8/16bitのインターフェース
を決定する設定は外部に出るピンではなくレジスタに入れる値で決定
します。これ10年以上前に使用したS1D19122に似てますね〜
動かしたところです。
まぁ可もなく不可もなくといったところですね〜
やっぱしILI9806Gなこいつが一番使いや(r
こちらはR61408が使用された3.97inch,480x800のものです。
FT5216の容量性タッチパネルコントローラがついたタッチパネル
つきになっております☆
最近に販売されている中華液晶の下駄基板はパタンでお絵描きしたりが
なくなって殺風景なのでちょっと寂しいですね…一応RGB/8bit/16bit
そしてI2Cまで使用可能です。R61408のシールは私が貼りました。
動かしたところ。
かなり発色が良いですね〜
でもやっぱしILI9806Gなこい(ry
んでもって10年くらいまえのりべんぢですがNT35510のまともな奴が
手に入りましたので動かしてみました。
サイズは定番の3.97inch,480x800です。
こちらも発色がなかなかでした…以前はまともに表示できなかったので
10年越しにりべんぢできたかんじですね…!
最後にRM68180が使用された3.97inch,480x800のモジュールです。
FPCコネクタ接続でインターフェースは8bitという速度的に苦しい
ものですがはてさて
かなり苦労しましたが何とか表示できるようになりました。
RM68120のコードとほぼ同じなのでrm68120.cと同居しました。
というわけで最近久しぶりに入手したTFT液晶モジュールを一気に
紹介しましたが現時点では使いやすさ、安定性、表示領域の面を
鑑みるとILI9806Gなこいつが鉄板と言わざるを得ませんね。
NT35516のやつがもうちょっと頑張ってくれたらよいのですが、
これから先も当分の間はILI9806G使ったやつのお世話になりそうです。
STM32L5を使ってみる2 -FatFsその他の実装-
●いつものやつを実装しよう
前回は144Pin版NUCLEO基板の下駄基板のビジュアルだけ紹介しましたが、
今回はそれを動かすためのファームウエアの要所を紹介していこうと思います。
ねむいさんの"いつもの"ことChaN師のFatFs実装を中心としております。
以下、STM32L5-NUCLEOのFatFs実装例のプロジェクトの要点を掻い摘んで
解説していきたいと思います。
●GCCビルドのためのCortex-M33向けオプション
先ずはmakefileを見ていただいたらお分かりと思いますがCortex-M33は
基本的にCortex-M4Fの進化版と思って頂けたらよいと思います。
GCCコンパイラに与えるCortex-M33コア向けオプションは以下になります。
-mcpu=cortex-m33 -mtune=cortex-m33 -mfix-cmse-cve-2021-35465-mfix-cmse-cve-2021-35465とかいうのはArmv8-Mコアの脆弱性対策です。
2023年現在の最新のGCCコンパイラはデフォルトでONになっておりいちいち
入れる必要はないかもしれませんが念のため明示してます。
●基本の"き"、タイマーとUARTの実装
STM32に代表されるCortex-M系のコアはほぼすべてにSystickタイマーが
標準装備されております。こちらを1mSecウエイト用のタイマーとして、一方
マイコン周辺機器のタイマー機能を利用してuSecオーダーのタイマーを実装します。
今回はuSec用にはTIM5を利用しました。
以下systick.cより抜粋
/* Making MicroSecond-Order Timer uses general purpose timer! */
/* Enable timer clock */
USEC_TIMx_CLKEN();
/* calculate TIMx(2 or 5) Prescaler clock(APB1) */
if(RCC->CFGR & RCC_CFGR_PPRE1){
if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV2){
cal_usec_divide = SystemCoreClock/2; /* (HCLK(=SYSCLK)*2 */
}
else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV4){
cal_usec_divide = SystemCoreClock/4; /* (HCLK(=SYSCLK)*4)*2 */
}
else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV8){
cal_usec_divide = SystemCoreClock/8; /* (HCLK(=SYSCLK)*8)*2 */
}
else if((RCC->CFGR & RCC_CFGR_PPRE1) == RCC_HCLK_DIV16){
cal_usec_divide = SystemCoreClock/16; /* (HCLK(=SYSCLK)*16)*2 */
}
}
/* usec wait timer settings */
TimHandle.Instance = USEC_TIMx;
TimHandle.Init.Period = UINT32_MAX;
TimHandle.Init.Prescaler = ((cal_usec_divide)/USEC_INTERVAL) - 1;
TimHandle.Init.ClockDivision = 0;
TimHandle.Init.CounterMode = TIM_COUNTERMODE_UP;
TimHandle.Init.RepetitionCounter = 0;
TimHandle.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;
if (HAL_TIM_Base_Init(&TimHandle) != HAL_OK)
{
/* Capture error */
while (1);
}
USEC_TIMx->CR1 &= ~(TIM_CR1_UIFREMAP); /* Disable UIF Remap(Must Need!) */
HAL_TIM_Base_Start(&TimHandle);最近のHALライブラリは"AutoReloadPreload"構造体が追加されているので
移植の際はご注意ください。また,UIFRemapビットにもご注意ください。
UARTについてはNUCLEO-L552ZE-Q基板上ではSTLinkのVCPとはLPUART
なるもので接続されております。一般のUARTとは多少違いがありますが
やることは同じです。LPUART1、GPIOG7,8をTX,RXとします。
一応LPUART以外のポートも使用できるようにしておりますので詳細は
uart.cupport.cを参照願います(丸投げ)
っとその前にLPUART1を使う際はLPUART1へのクロック供給のほかに
"HAL_PWREx_EnableVddIO2()"の実行も忘れないようにしてください。
またリングバッファによるノンブロッキング送受信なのはいつも通り
なのでスムーズにデータのやり取りができると思います。
●SDMMCドライバの実装・FatFsとの結合
STM32L5にはSDMMCがありますのでこれを実装しますが数年前STM32H7に
実装したSDMMCのドライバをスライド移植するだけのお手軽です☆
ぶっちゃけ今回の移植作業で一番楽でした。
一応使用上の注意なのですがSTM32H7と同じくSTM32L5のSDMMCはDDR
モードが使用可能ですがSDMMCに供給するクロックがバイパスされて
いないと使用不可となりますのでご注意ください。
ねむいさんの作例ではデフォルトではHSI48をSDMMCにバイパスなしで
供給しているためDDRで使用することができませんorz
もしDDR対応のeMMCをお持ちの方はコアクロックを110MHzから100MHzで
動かすとHSI48を使わずコアクロックをSDMMCのクロックにするよう
切り替えますので試してみてください。
STM32L5の最大動作クロックは110MHzなんですけどこういう制約が色々
あって100MHzで動かすほうがよっぽど有利なんですよね〜
100MHzとか昨今のマイコンでは遅い部類のクロックですがまぁ初代の
STM32F1とかのMAX72MHz動作と比べたら(消費電力も合間見ると)雲泥の
差ですがすっかり贅沢になってしまいましたね〜
STM32H7の実装でも実はひっそり最高速の480MHz対応してますが
こちらもいずれ紹介しようと思います。
●SPIとシリアル接続TFT-LCD
STM32L5のSPIモジュールも言ったって普通のSPIなので実装は容易
でした…が、DMAのほうはちょっと一癖ありました。
ねむいさんが知ってる従来のDMAではなくってDMAのチャネルがマルチ
プレクスされていて柔軟な設定ができるようになっており、逆に扱いに
苦労しましたがExampleを参考に何とかSPIでDMAを吐けるようになって
おります。以下にDMAMUXの設定を抜粋しておきます。
全体は./lib/display/mcu_depend/display_if_basis.cを参照のこと。
#ifdef USE_DISPLAY_DMA_TRANSFER
/* DMA controller clock enable */
__HAL_RCC_DMAMUX1_CLK_ENABLE();
__HAL_RCC_DMA1_CLK_ENABLE();
/* Configure DMA request LcdDmaHandle */
LcdDmaHandle.Instance = SPILCD_DMA_CHANNEL;
LcdDmaHandle.Init.Request = SPILCD_DMA_REQEST;
LcdDmaHandle.Init.Direction = DMA_MEMORY_TO_PERIPH;
LcdDmaHandle.Init.PeriphInc = DMA_PINC_DISABLE;
LcdDmaHandle.Init.MemInc = DMA_MINC_ENABLE;
LcdDmaHandle.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
LcdDmaHandle.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
LcdDmaHandle.Init.Mode = DMA_NORMAL;
LcdDmaHandle.Init.Priority = DMA_PRIORITY_MEDIUM;
if (HAL_DMA_Init(&LcdDmaHandle) != HAL_OK)
{
for(;;){
__NOP();
}
}
if (HAL_DMA_ConfigChannelAttributes(&LcdDmaHandle, DMA_CHANNEL_NPRIV) != HAL_OK)
{
for(;;){
__NOP();
}
}
__HAL_LINKDMA(&SpiHandle,hdmatx,LcdDmaHandle);
/* DMA interrupt init */
/* SPILCD_DMA_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SPILCD_DMA_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(SPILCD_DMA_IRQn);
#endifまた下駄基板ではST7789V2を使用したTFT-LCDモジュールを採用して
おりますがこちらのデータ線はSDIとSDOがマルチプレクスされたSDA
となっており、ST7789V2のデバイスIDを取得したいならばSTM32L5側で
SPIのMOSIとMISOを直結し読み出しの際にMISOの信号を正しく受け取る
MOSIをGPIOの入力にわざわざ切り替えてやる必要があります。
以下にそのコードを示します。
void Display_ChangeSDA_If(uint8_t sda_mode)
{
GPIO_InitTypeDef GPIO_InitStructure;
if(sda_mode == TFT_SDA_READ){
/* Enable CTRL Line GPIO Settings */
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);
GPIO_InitStructure.Pin = CTRL_SDI;
GPIO_InitStructure.Mode = GPIO_MODE_INPUT;
GPIO_InitStructure.Pull = GPIO_PULLUP;
GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStructure.Alternate = 0;
HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);
}
else {
/* Enable CTRL Line GPIO Settings */
#if defined(USE_SOFTWARE_SPI)
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);
GPIO_InitStructure.Pin = CTRL_SDI;
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Pull = GPIO_NOPULL;
GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStructure.Alternate = 0;
HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);
#else
/* Connect SPI pins to Alternate Function */
/* Restore SPI MOSI pin configuration */
DISPLAY_GPIOCLK_EN(DISPLAY_CLK_SDI);
DISPLAY_PERIF_CLK(ENABLE);
GPIO_InitStructure.Pin = CTRL_SDI;
GPIO_InitStructure.Mode = GPIO_MODE_AF_PP;
GPIO_InitStructure.Pull = GPIO_NOPULL;
GPIO_InitStructure.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStructure.Alternate = SRC_SDI;
HAL_GPIO_Init(DISPLAY_PORT_SDI, &GPIO_InitStructure);
#endif
}
}
ちなみにST7789V2側のドライバはデフォルトでは上記の切り替えの
必要なくIDを決め打ちで返すようにしてますのでもの好きな方だけ
SDAマルチプレクス有効にして試してみてください。
SDAマルチプレクスの際はSTM32側のMOSIとMISOをショートしてください。
ST7789V2からIDを読み出す設定でビルドしてデバッガで追っかけてみると
こんな感じにSDAからST7789V2のID(RDID2(0xDB)で0x85が返る)が
読まれてくるのがわかります。
SPI接続で動くモジュールはこんな感じでピン数節約のためにSDIとSDOが
マルチプレクスされてることもあるので覚えておいて損はないでしょう。
というわけでいつものChaN師のファイラー起動からの…
海で働いてるいないさんのpng形式のイラスツをlibpngでデコード！
(LCDのサイズ小さいので画像の一部しか表示できませんが)
libpngのほかにbmp形式はもちろんlibjpegやgiflibでjpg、gif形式
ファイルも表示できますがSTM32L5シリーズはフラッシュメモリ容量が
512kByteしかないのでフォントファイルを乗せつつ画像デコード用の
ライブラリ全部乗せは容量上非常に苦しいです。
そんなときのために容量を食うフォントファイルは外付けのSPI-ROM
にデータを配置してアクセスしたいところですが…
こういう用途に便利なOCTO-SPIという機能がありますが解説が長く
なりそうなので次回に続きます…！
大周回遅れでCortex-M33とSTM32L5はぢめました
●M33出てから何年たってるんだYO
禿ARMから小文字armに代わってもはや数年…ねむいさんもようやっと
ARMv8のCortex-M33コアに手を出しました…！
セキュリティー機能を強化したCortex-M33コアのSTM32L5です！！
ていうか2023年現在はL5をそれぞれの分野別に進化させたSTM32U5や
STM32H5も登場しておりますがまずはL5から行きます！！
実際にはSTM32L552ZET6QUを使用したNUCLEO-L552ZE-Qボードを入手
いたしました。
このNUCLEO基板は(ねむいさんの中での)通称144Pin板NUCLEOと呼ばれる
ものです。NUCLEO基板族の中では最大の大きさとなりますがピン数の
多いマイコンを使っているおかげか外部へ引き出されたポートが固定化
されており、異なるCPU間でも下駄基板を使いまわせられるという
極めて大きな利点があります。
例えばSDMMCのポートはコネクタのこの位置に必ず配置されており、
一度基板をこしらえてしさえすればSTM32H7だろうがSTM32F4だろうが
STM32U5だろうがさらに最新のSTM32H5ですら144Pin版NUCLEOなら
同位置なわけでハードとソフトの切り分けがとても容易になります。
●てわけで144PinNUCLEO基板用汎用下駄基板を作ってみた。
ねむいさんは令和5年になっても自力でプリント基板起こせない雑魚
なのでユニバーサル基板とポリウレタン銅線でせこせこ配線です…。
大動脈の+3.3VラインはLCD,SDMMC,QSPI/OCTO-SPI,I2Sデバイスと大量に
電力を消費するのでNUCLEOの+3.3V出力から取得は不可能です。
したがってVbusの+5Vから+3.3Vを個別に作ることにしました。
ここで登場するのが廉価でぱわふりゃーなLDO、MIC37100-3.3WS-TRです！
LT1963Aが高嶺の花になり、ADP3338がNRNDになってしまった今、高性能
LDO難民となったねむいさんを救うぱわふりゃーなやつです。
ドロップアウト電圧は280mV/1A,10uF以上のセラミックコンデンサで
動作可能でお値段1個240円くらいなので非常にオトクです！！！
こちらでも紹介していますのでヨロシク！
ぇっと話がそれましたがSDMMCの端子はマイクロSDコネクタを採用
しました。それと以前から言っている通り各データラインのプルアップ&
終端の処理は有言実行でしっかり施しております。ねむいさんはCMDと
D0~D3のプルアップを22kohm,CLKの直列終端は33ohmとしました。
結構ラフな実装ですが、CLKに挿入する直列終端の効果は絶大です。
無抵抗状態ではこんな暴れまわっている生意気クロックラインも…
抵抗を直列にぶちこむだけでこんなにわからせられます！これで
安定してSDカードにアクセスができてソフトに専念できますね！
表示デバイスは3年前に購入して温めすぎて腐らせたTFT-LCDモジュール、
ATM0130B3を採用しました。240x240なのに1.3インチととっても小さい
モジュールなのですがこのNUCLEO基板にはまさに最適なヤツです。
このモジュールに使用されているコントローラはST7789V2です。V2とか
お尻に名前が付いていますが2023年現在、このST7789族は電子工作の
お供として必ず名前が上がるくらい有名で、もはやILI9341よりも広く
使用されるようになり、まさに覇権を握ったといってもよいでしょう。
マルチプレックス化されたデータラインからデバイスID取得する方法等の
使用時のコツは場を改めてソフト編で紹介します。
FONTX2等の大容量データの保存先としてメモリマップドでリニアに
アクセスできるQSPIを使用します。選んだデバイスはこれまた電子
工作で定番のSPI-ROMになったWinbondのW25Q128JVSIQです。
ちなみにW25Q128JV自身はQSPIモードをサポートしていますが
(パーツナンバー末尾のIQはデフォルトでQSPIモードの意味)、STM32L5に
おいてはOCTO-SPIというQSPIがさらにパワーアップしたモジュールが
搭載されております。
注：基実装はしましたがたぶんL5版で使用せずH5版Nucleoで使うと思います。
SAIについてもフラッシュ容量の関係でH5版Nucleoで紹介します。
OCTO-SPI実装しました。
そんなわけで下駄基板の紹介だけで一杯一杯になってしまいましたので
ねむいさんのいつものに相当するFatFsの実装等のソフトウエアの紹介は
次回以降順次紹介とさせていただきます。更新頑張るぞい！
また、気づいてる方もいると思いますがすでにおきぱにFatFsの実装例の
L5向けプロジェクトを先行で公開しておりますので興味ある方はこれで
予習をお願いします。
STM32C0を使ってみる2 - OpenOCD正式対応記念 -
20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:
気づいたら私ってば今月3件も記事更新してますね…北陸侵攻は資金がすぐ
尽きるので気軽に山行けないのとGWの過密期間ずらしの相乗効果でひまが
出来てしまっておかげでしょうか…？それはさておき
さて、去る5月も末になりついにOpenOCDがSTM32C0のフラッシュ書き込みに
正式に対応と相成りました！
ねむいさんもgerritでアシストした甲斐があったものです。
おきぱにあるOpenOCDバイナリは既に対応済みで、もちろんSTM32C0用の
書き込みスクリプトの公開をしております☆
そんでもってSTM32C031-NUCLEO向けの基本プロジェクトも機能を大拡張
して公開しておりますので今のところ誰もC0使ってないようですが、
これからどんどん使ってほしいとおもいます…！
もはや実家のような景色のOpenOCDで書き込んでいるところです。
まぁ10数年やってる同じことだからもう慣れたもんですね〜
…ぇ？お前Codelite使ったデバッグ手順の公開はいつだって！？
すみませんそれだけはもうちょっとだけ待ってください・・・・！
その代わりといってはナニですが私のプロジェクトの詳細をちょっと
解説しておきましょう。色んなセンサに対応するために#defineの嵐に
なっておりますがその分細かく各機能の確認が可能です。
私の公開しているSTM32のNUCLEOボード系プロジェクトは簡単質素を
掲げており、他の方が再現しやすいようにペリフェラルも下記機能に
限定して使っております(144Pin系のNUCLEO除く)。
・汎用タイマ(を使ったuSecウエイト)
・UART(割り込み・リングバッファつき)
・I2C(センサ・表示デバイスのドライバ付き)
・1-Wire(GPIO制御による)
まずはI2Cデバイスが何もなくてもLEDとUARTが確認できるものです。
STM32C0-NUCLEO基板を買ってきてすぐに試すことができます。
UARTはSTLinkがVCPの役割もしているので別途USBシリアル変換を
用意する必要もありません☆
お次はI2Cの機能ですが、前回も言いましたがI2Cデバイス用の+3.3V
電源はAVCCからとっているため、SB25ジャンパは必ずしておいて
ください！！！買ったときはジャンパされておらずAVCCがつながって
おりません！STM32C0-NUCLEOの罠です！
NUCLEO系の基板はこんな感じに都合よくI2Cの機能を試すのに丁度よい
ピン配置で線が出ているのでやっけつハーネスを使って外部のI2C
テスト基板に接続しています。
さらにそこからSTN-LCD/OLED用の線をこんな感じで引き出します。
私はブレッドボードは意地でも使わないウーマンなのでこういった
変換基板や、ハーネス製作で汎用性を持たせプロトタイピング性を
高めております。
ちなみにI2Cのバスライン全体のプルアップ抵抗値についてですが
"つぶし"が効くように2.7~4.7kohmを保つように気を付けております。
さらにSCLのクロックはむやみやたらに上げず100kHzをベースとして動作
挿せております。最適化はまず確実に動かしてからするものです。
あとオシロスコープの波形確認用にこのようなブリッジ接続用治具を
作っておくと波形解析に極めて便利です。
秋月さんで売っているこちらのリードアダプタと組み合わせると
安定確実に波形測定が可能となります！
それとI2C程度の速度の波形確認なら今では格安で10万円以下で
USBの2chオシロが手に入るので必ず持っておきましょう。
安物でもあるのとないのとでは開発のスピードが全く違います。
遊びでも投資はケチらずしっかりと行いましょう！
話を戻して5月の更新からデフォルトのドットマトリクス表示デバイスを
I2C-STNから秋月さんで購入可能な入手しやすいI2C-OLEDに替えております。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
STNの方はねむいさんのお気に入りで今みたいにOLEDが自由に使える環境は
まだなかったので時代を感じますね…この辺長くなるのでまた次回にでも。
でもねむいさんこの2.5元I2C-STN液晶いまだ大好きなんですけどね…(一番手前の)
センサは秋月さんで購入できるAosoungのAHT21Bを使用することにします。
実際はAHT2x系ならAHT25やDHT22、AHT20も後述の設定で動作可能です。
main.cのdefineの定義はこのようにしておいてください。
ドットマトリクス表示デバイスはSSD1309を、defineはAHT2X系のテスト
ルーチンとします。
makefileの定義はSSD1309ですがスクロールなどの特殊コマンドは
使用しておらず、基本コマンドだけで動かしているのでSSD1306でも。
SH1107でも問題なく動作すると思います(動作は遅いですが)
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
それとソース読んでて気づいているかと思いますがI2Cの各センサ
モジュールとI2CのOLED/STNでSTM32の同じI2Cポートを二重に初期化
しております。
これはドットマトリクス表示ライブラリ(xMSTN)の開発はSPI接続の
ものから行っていた経緯がありI2Cインターフェースのものは後から
追加されたことに由来しております。
はたから見れば二重に初期化してて未意味な無駄コード構成になって
いるように見えますがオシロで波形を確認し、実害はないことを確認
しているので将来の拡張を考えあえてこのようにしております。
決して手抜きではない！
AHT21BをOLEDを変えつつ動かしているところです。
湿度がだいぶ高くなってますがこの記事を書いてる時点で京都も
梅雨入りしたそうです。
以前は対応しておりませんでしたがCRCチェックに対応済みです。
こちらも次回の"いろいろ試す"時に詳細をお伝えします。
DS18B20やAM230x系の1-wire系デバイスももちろん動作します。
プルアップ抵抗は4.7kohmにしておいてください。
BME280をお持ちの方はこちらもしっかり動作します。実はBME280も
シリアルナンバを取得できるのですがこれも次回に詳細をお伝え
しましょう…
そんなわけでまだユーザーがほとんどいないSTM32C0ですが、秋月さんが
STM32G0の後釜でNUCLEOや単体SO8パッケのチップとか販売してくれたら
爆発的に広まると思います！
だから秋月さん頼みますよぅ〜！
20240223追:
秋月にSTM32C0参上！！
中国自然歩道を往く -北伐！県境を越えて鳥取県に侵入せよ！-
Codeliteを使ったデバッグ環境構築はどこに行ったのか？そして北陸進出
計画はなぜ越前市に来たとたんに足踏みしているのか？ねむいさんのぶろぐの
過去画像差し替えが完了するのはいつなのか？
答えは今回の命を賭した岡山県境越えそして鳥取県侵入に隠されている…！
かも？
●2022.11.19 中国自然歩道(東粟倉〜鳥取県境〜芦津〜智頭)
いきなりのくそみたいな展開…
人身事故3連発で使いたくもない貴重な株主優待拳を消費してしまう羽目に…
しかも自由席ガラガラで指定グリーンとか無意だったの…
とにもかくにも何とか岡山県は大原にたどり着きました。
今回は東粟倉にある愛の村パークなる研修施設に泊まりました…
なんと旅行支援も使ってないのに素泊まり2500円とすさまじいコスパで
温泉まで入れちゃいます！！まぁでも車持ってる人専用のお宿ですね〜
てなわけで12時間にわたる地獄開始！！！
朝の後山地区を駆ける。
今年初めに寄った道仙寺に今回もよりました。
道仙寺護摩堂です。前回の予習はここまで。
あとは未踏の戦いの場が始まります…！
護摩堂の近くには愛の水という湧水があるのですが金とるのか…
愛がないと思ったら奥に進むとちゃんとフリー湧き水ありました…
愛とは何か。
今までの中国自然歩道はひたすらアスファルトでだらだら長い印象ですが
今から急に難易度が跳ね上がり険しい山岳地帯となります…！
ねむいさんはここさえ攻略出来たら後は楽かとこの時は思ってました…。
岡山〜鳥取県境の山野は普通にクマが出没するそうです…
真っ赤な警告看板がガチ感出してて恐ろしいですね…
ねむいさんも10年前に買ってそのまま放置していた熊鈴を今回ついに
実践投入し程度見ます…そしてここから登山道…！
東海自然歩道の犬越路をほうふつとさせる石交じりの登山路です。
途中ではクマの糞も見つけちゃったりして警戒度上げつつ上りますが…
ありゃりゃ…なんだこれめちゃくちゃきついのぼりですよぅ…
ねむいさんが山に登るとよく遭遇する斜め50度くらいの世界に…
はぁはぁ…
滑落しないように慎重に上ると勾配が緩くなってきてだんだん歩きやすく
なってきました・・難所は越えたか…やった…
…！！！！！！！
ねむいさん道を間違えて危険なバリルートを上っていたようです…
道理できついわけだわ…
そこからはほどなくして後山分岐にそしてさくっと舟木山頂上です☆
自然歩道のルートではないですがもちろん後山にも向かいます…！
岡山県最高峰、後山です…。
大馬鹿だからこんな北伐ちゃれんぢするのですよぅ！
今度は進路を西にとって自然歩道ルート上のダルガ峰を目指します…！
絶対に許さないよ
(いやらしい角度に傾きながら)
標高1000m越えの天空のトレイルを走っているとどんどん晴れてきました。
途中の鍋が谷山です。
走りやすい素晴らしいトレイル区間…最高…♥
遺跡みたいな岩がちりばめられている駒の尾山頂です。
振り返ると後山がもうあんなにはるか彼方に見えます…！
次は最後のピークダルガ峰をめざします…
だんだんススキが目立ってきました。
岡山県の区切りとなるピークダルガ峰に到着です…！
ごらんのとおり“だるがなる”とよむ不思議な山頂です。
ダルガ峰からは大量の薄に囲まれて下っていきます…。
途中のダルガ峰山小屋では私もメッセージを残してきました！
一瞬車道に出たと思ったら今度は大崩壊というか自然に帰った
山道に…おろしたてのトレランシューズがあああ！！
何とかやばい空間を躱して大茅スキー場に到着です。
雪はないですが大量のススキがお出迎えです☆
スキー場のふもとでは自販機があったのでここで後半戦を戦う装備を
整えました…！いざ！
お次は若杉原生林と岡山県境です…
600mまで降りちゃったのでまた約550mくらい登り返さないといけません☠
若杉原生林駐車場です。
ここにもくまさん警報看板が大量にありました。
若杉原生林をかいくぐる…！
ここを上り詰めるといよいよ岡山・鳥取県境がある若杉峠です。
そしてお地蔵さんがある若杉峠に到着です。
ここから先は鳥取県になります…
がいきなり熊よりやばそうな脅し文句が
…たいしたことないでしょねむいさんを誰だと思ってるのよ
鳥取県になってから突然激しくなる上り下り…
がぁぁああああぁっぁぁあ
足を踏み入れるものを遮る鳥取警告看板が再び目に入る…
しかしねむいさんのライブラリに撤退というメソッドはない！
ていうの嘘ですすみませんもう帰して…
芦津・吉川越えです…
んあこたぁわかっとるわい！です！ＹＯ！
うっかり足をつった状態で何とか上ってきた狩谷山です…
ここでアミノ酸と天日塩の補給で足の回復を行いました。
狩谷山からはさらに上って標高1200mに…がぁぁぁぁあぁっぁぁあ
でもさっきのアミノ酸と天日塩が効いて足はちゃんと動きますが
1200m超えた地点で急に下りになったちょっと先に車道が…
やっと解放された…と思ったら今度は懲役8kmのアスファルトが…
まぁ標高1100mからのえんえん下り道なので多分非常に気楽です。
ススキがきれいですね〜(必死の形相で
懲役8kmと思いきや意外と見るものがありました。
かつては林業や鉱業が盛んだったようですね。
とそれに気を取られてこの穴ぼこにやられるところだった！１！！！１１
こけそうになったけどでんぐり返りじゃなくて前回り受け身で奇跡的に
ノーダメでクリア！
そのまま駆け下りていくと本日最後のトレイル"三滝区間"にやってきました。
水洗トイレもあったので最後の補給をして挑みます…！
何気なく進むといきなり激しい落差になって気が置けません。
？？？？？
三滝ダムです。
対岸に渡りトレイルは進みます。
この区間の見せ場、三滝です。
あとは安全な道を通って今回最後のトレイル区間終了です…
暗くなる前に何とかここまで攻略できました…
あとはアスファルト道を駆け下りていくだけ！
うぉぉおおおおお！！
急速に暗がりが広がってきましたがトレイル区間は抜けたので
街灯もあったりしてライト使わなくてもへっちゃらです…☆
ていうのはうそです…どんどん暗くなってきたので熊鈴をしまって
代わりにライトを装備して進みます。
すっかり日が落ちて夜になったころに芦津バス停に到着です。
ここが次回のエントリポイントになります。
あとは走って智頭駅に向かうのみ！
ぁー星空めっちゃきれい
(写真が失敗したわけではない)
暗くてよくわかりませんでしたがここもかつての街道で史跡がたくさん
みられるようですね。
国道にぶつかって今度は国道沿い西に進路を取りひたすら走ります！！！
足もちゃんと走れてるからいまだ問題なし！！
千代川沿いに走っていると智頭駅の看板が！！！
あと少し！！！！！１！！
…ッッ着いた…！はるばる58�劼鯆兇┐童�境を越えて鳥取県の智頭駅に
ついにゴールしました…！そしてスーパーが閉まるギリギリだったので感慨に
浸る間もなくお土産と晩飯を買い込む…。
ちなみにさっきのはＪＲの智頭駅で智頭急行の智頭駅もあります。
智頭急行のほうに鎮座する駅娘のえりおさんは芋くてあんましかわいくｎ
ｶﾜｲｲ
運転手さんの計らいで休日割引料金1200円でで上郡に帰れたりちょっと
助かりました。そしてあとは新快速で京都まで夢の中…
今回も無事にタフな戦いを制しました！
そんなわけで中国自然歩道岡山の最難関をクリアして鳥取県まで進攻できました
が！今回は序の口でさらにやばい区間が待ち構えているのでしっかりリサーチを
重ねて体力をつけて挑もうと思います！！
ぁーその前に北陸地方は新幹線が敦賀に通ってしまうまでに優先的に攻略して
金沢まで到達したいのでそちらが優先になるかとおもいますという複数正面作戦
状態となりますがなんとか頑張ってみますよぅ
●2022.11.19 中国自然歩道(東粟倉〜鳥取県境〜芦津〜智頭)GNSSログ
XMEGAを使ってみる6 -どうしても外付けSRAMつけたかったので-
●XMEGAよ、やはりお前を救いたい
今から約10年前、ねむいさんはXMEGAをいじっておりましたがFatFsを実装し、
SPIのDMA化で力尽きました。ほんとは256kByteくらいのSRAMを外付けしたり
してやりたかったのですが残念ながら当時購入したATXMEGA128A1ではチップ
単体ではEBIを4PORTSRAMモードで動作させてもアドレスバスに当たる一部の
ピンが外部に出ておらず、SRAMを動作せしめることができませんでした。
(アドレスが1つだけでよいTFT-LCDとかならなんの問題もない)
その後USB機能付きのATXMEGA128A1Uが登場し、アドレスバスを別のポートに
割り当てできるようになっているとのことで入手せんと試み失敗したのが前回です。
この半導体不足で何とか手に入れられないものかと思案した結果、部品が
だめなら製品を買えばよい！
と至って久々にAliexpressでお買い物をしました。
MCUZONE製のATXMEGA128A1Uボード。
USBブートローダはちゃんと動いたので本物でした!
慎重にチップをはがして載せ替えてみました。
ちなみにATXMEGA128A1のドアップ写真を。
オリジナルATXMEGA128A1
謎の縦じまがあるぱちもん。
ATXMEGA128A1UではなくATXMEGA128A1をリマークしたもの。
本物のATXMEGA128A1U！
●外付けSRAM
今回使用する外付けのSRAMは8bitバス,2Mbit(256kByte)の
CY7C1010DV33-10ZSXIです。
10年以上前にデジキでかって塩漬けにして以来の活躍です。製造メーカの
CypressはすでにInfineonに食べられてしまっていますね。
SRAMも付けたXMEGA基板の表裏はこんな感じです…
二度とバスの配線とかやりませんよもう！
●回路とコード
すみません回路図めんどくさくて10年前から書いてませんが割り振り表はあるので
まねされる方はそれを参考にしてください。
TFT-LCD駆動用にCS0をつかってしまっているのでSRAMはCS1とします。
外付けSRAM用4Port-EBIの設定です。実行する関数はmain関数より早く実行した
ほうが良いので".init5"セクションに配置します。
EBIの設定のほかにheap領域は外部RAMで行えるようにheapの初期設定も行います。
__malloc_heap_start__malloc_heap_endにheap領域を示すアドレスを代入します。
__malloc_heap_endってなんで固定値0xFFFFなのかについては最後に解説します
また、上記のコードで書いてあった変数"__extram_end"はリンカスクリプト内で
定義します。コード内で値の設定を行うときは&を忘れずに。
以上で外付けSRAMを使う準備ができました。
●動いた！…しかし
載せ替えたXEGAにプログラムを書き込みFatfsの動作を確認です。
チップリビジョンはATXMEGAA1Uを示す'L'になってますね。
mallocで領域確保したりちゃんとできてますね★
特筆する点はFatFsの転送スピードです！
内蔵RAMは8kByteしかないので転送用のバッファも少ししか取れずDMAの
恩恵に預かれなかったのですが、外付けで32kByteとってやると断然違います！
これだけでもわざわざATXMEGA128A1Uを手に入れた甲斐がありました！
しかし…
●立ちはだかる16bitの壁
さて、上でさらっと述べましたが何も考えないで内蔵RAMのように気軽に使用
できるのはメモリのアドレスが0xFFFFまでです。つまり最大でも64kByteまで
しかだめです。今回の作例ではメモリアドレス0x005000から開始しているので
0xFFFF-0x5000=0xAFFFで、10進数に治すと45055Byte分しか楽に使えません。
そこから先の世界に踏み出そうとすると10年以上前に頭を抱えた24bitアドレス問題に
直面することとなります。私の作例では一応24bitアドレスアクセスルーチンも
テストの一部として入れております。DMAに関しては最初っから24bit分レジスタが
用意されているので心配はありません。
というわけでがんむばって256kByteのSRAMくっつけてたのがつけてから64KByte分
くらいしか得しないことを気づいてしまいましたが10年来心に抱え続けていたものに
決着をつけることができました。
世間はUPDIなAVR-DBシリーズに移行している中で盛大な寄り道をして
しまいましたが今回頭を唸らせた経験はきっと役に立つでしょう〜♨
(やばい思想にはまっている目で)。
今回の成果を反映したものをおきぱにおいておきます。
忘れたころにXMEGA触る人に少しくらい役に立つと期待しております。
在庫復活記念！！ATTINY202を限界まで使い倒す！
●ATTINY202復ｯ活ｯ！
プーチンが突然けぉって顔真っ赤にしてウクライナに侵攻してから
半導体の納期がさらに悪化する兆しを見せやがっておりますが、その中で
ATTINY202の在庫が秋月電子通商さんに復活しました！！
なんか20円値上がりしてる気がしますがたぶん気のせいでしょう…
そんなこと気にするより在庫が復活するのが超重要事項なのです！！！！
扱いが非常に簡単かつ非常に安価に使いまわせるので様々な
シーンで活躍していくことでしょう！！
●ていうわけでねむいさんも本腰入れて使ってみました
昨年になってATTINY202のポテンシャルに気付いた方々が爆買いに走り
気づいた時にはすっからかんとなっておりました。ねむいさんもちょっと
動かして満足してほっぽっていましたが他の方の使用例に刺激されて
ATTINY202のROM容量限界まで使ってみました！！！
なお,ATTINY202はメモリリソースが非常に少ないです…。
ROM:2048Byte
RAM:128Byte
ねむいさんいつもSTM32H7等の大容量メモリを扱ってたのでパワーゲームに
慣れきってしまったせいか逆に少ないリソースのマイコンは新鮮に感じます。
私のモットーとしては
１．スタックを考慮してRAMはなるべく使用しない。
２．ROMもメモリ容量圧縮しつつギッチギチに使う
で攻めてみます！
●作例1：1-Wire温湿度計
過去にSTM32G0を使用したときのAosong製AM2322Bを今回も採用して
出力をUARTから吐くようなプログラムを作ってみました！
ROM容量は2037Byte....2048バイトまで10バイト弱…これはｷﾞﾘｷﾞﾘ
-fno-split-wide-typesをコメントアウトしてみました…
2バイト削減…もはや数バイトの戦い！
関数突入時のプロローグ/エピローグルーチンをあらかじめ作ってROM容量を
削減する効果がある-mcall-prologuesをあえてコメントアウト！
使用する関数がごく少ない場合は逆にコメントアウトしたほうがROM容量が
減ってお得です☆これで2027バイト…まぁこれでよいでしょう…！
なお、XMEGAとかでこのオプションちゃんと付けてないと確実に容量が
膨れ上がって爆死します☠
動いたところはこんな感じです。
内蔵クロックが20MHzもあるので230400bpsでも余裕です☆
●作例2:2-Wireで定番LCD(IC:HD44780)を動かす
すでにI2Cでキャラクタ液晶動かすネタはほかの人がやってしまっているので
ひねくれ者のねむいさんは11年前の無理やりすぎるやつをやってみました！
SUNLIKE製の安く購入できるものに代表される2行16文字で内臓コントローラ
ICがHD44780互換なキャラクタ液晶モジュールを受動部品を追加してたったの
2線で動かしちゃう実用性皆無の超力技です！中国だもんなア…
↑のリンク先で牛という単語が散見しますが中国では牛を肯定的な意味で使用
されることがあるとのことです。この力業は文字通り強い牛を見るようだ。
ソースコードは上リンクの中国の人のATMega16のものをベースに汎用で幅広く
使えるように一般公開向けに現在整備中です！
間に合わなかったわけじゃないよ！
しかし…
そこに立ちふさがるROM容量の壁！orz
ああっつ!｢作例1：1-Wire温湿度計の計測｣結果をUART出力の代わりに
かっこよく表示して今回の記事を〆たかったのに容量ぜんぜん足らない…！
あと500Byteあれば…
･･･
15分ほど頑張りましたが挫けてしまい文字列表示ルーチンだけ走らせて
敗戦の弁を述べさせていただきます…orz
というわけでSTM32に慣れ切った私の体には負担が強すぎたのはわかりましたが
ATTINY202の(ROM容量の)イッパイ使用できて非常に満足しております…！
今回の記事で紹介した作例のソースコードはまだ公開用に整備中なので
もうしばらくお待ちいただければ幸いです。
20231201追:
ATTINY202の無理やりすぎるプロジェクトを上げました。
ついてこれる人だけついてきてください…！！！
20231201追:
ところでねむいさん今回はUPDIプログラマ使ってなくてなんかUSBシリアル
変換だけで開発してない？ですって！？
それの詳細は次回以降でみっっっちりと解説させていただきますよぅ♥
ATTIY202売り切れしたのってこれ絡みが原因だったかもれませんがこうご期待！
いろいろ試す46(+2020年反省会)
ねむいさんは悪くない全部コロナのせい全部！
反省会終了！
…
さて本題に入ります…
●OpenOCD最近の更新トピック
日々着実に機能を増強しているOpenOCD。ここ数か月の更新でめぼしい更新を
ピックアップしてみます。
１．QSPI/OCTOSPIのサポートがついに公式実装！！
何年待たせたんだYO!
ねむいさん待望のQSPI-ROMのOpenOCDからの読み書き機能がようやく公式に
マージされる運びとなりました。ねむいさんのSTM32F7やH7の作例でmakefile
みたら気付いた方もいると思います。一応以前からパッチを当てたビルドは
公開していたのですがなかなかにっちにな需要だったので表の出さずにして
おきました。
公式マージにあたり、若干の動かし方の差異が発生してましたのでこちらで
吸収しております。
makefileは516行目から、
実際に書き込みに使用するOpenOCDのcfgは私のバイナリ同梱のstm32h7disco_dap_flash.cfg
の170行目くらいを参考にしてください。
実際にQSPI-ROMに読み書きした様子はこんな感じです。
↓mass_eraseの時
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32h7disco_dap_flash.cfg -c "eraser_qspi"
Open On-Chip Debugger 0.11.0-rc1+dev-00010-gc69b4deae (2020-12-27-08:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
force hard breakpoints
Info : STLINK V3J4M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.219171
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : clock speed 1000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints
Error: stm32h747xih6.cpu0 -- clearing lockup after double fault
Polling target stm32h747xih6.cpu0 failed, trying to reexamine
Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h747xih6.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : flash1 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes
Info : flash2 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02↓FontX2ファイルなどのバイナリファイルを書き込んだ時
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32h7disco_dap_flash.cfg -c "mt_flash_qspi lib/FONTX2/inc/fonts/ILFONT/ILGZ24XF.FNT 0x90010000"
Open On-Chip Debugger 0.11.0-rc1+dev-00010-gc69b4deae (2020-12-31-18:42)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
force hard breakpoints
Info : STLINK V3J4M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.217121
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : Unable to match requested speed 1800 kHz, using 1000 kHz
Info : clock speed 1000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stm32h747xih6.cpu0: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h747xih6.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08050484 msp: 0x20020000
Info : flash1 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes
Info : flash2 'micron mt25ql512' id = 0x20ba20 size = 65536kbytes
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
Info : Device: STM32H74x/75x
Info : flash size probed value 2048
Info : STM32H7 flash has dual banks
Info : Bank (1) size is 1024 kb, base address is 0x08100000
Info : wrote 636586 bytes from file lib/FONTX2/inc/fonts/ILFONT/ILGZ24XF.FNT in 17.585402s (35.351 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:19
QSPIの読み書きに関しての注意点ですが現状は完全安定とは言えず、消去や
書き込みを行う度に電源を投入しなおさなければなりません。
いずれは解決されるでしょうがこの点だけはご留意ください。
２．ST-Linkで16bitのメモリ読み書きが実装される
何年待たせたんだYO!もう7年くらいたってるYO！
今更もう遅いよぅ！！！
FM3のフラッシュコントローラたたく以外に何の用があるのか！？
今となっては使い道が分かりません…
●arm-gcc定期更新
arm-gccも12月に更新掛かってました。
主な変更点はついにGCC10.0になったことでしょうか。
とりあえずSTM32H7のビルドサイズの比較…
↓前回の
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 768116 0 768116 bb874 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
765464 2652 2383344 3151460 301664 main.elf
main.elf :
section size addr
.text 0xbaca0 0x8000000
.ctors 0x0 0x80baca0
.dtors 0x0 0x80baca0
.ARM.exidx 0x8 0x80baca0
.itcm 0x170 0x0
.data 0xa5c 0x24000000
.bss 0x11c68 0x24000a60
.heap 0x0 0x240126c8
.dtcm 0x20c 0x20000000
.stack 0x4 0x2000020c
.ram1_d2 0x0 0x30000000
.ram2_d2 0x0 0x30020000
.ram3_d2 0x0 0x30040000
.ram4_d3 0x0 0x38000000
.batram 0x0 0x38800000
.extram 0x233f78 0xd0000000
.qspirom 0x0 0x90000000
.comment 0x76 0x0
.debug_aranges 0x4d48 0x0
.debug_info 0x186579 0x0
.debug_abbrev 0x1f290 0x0
.debug_line 0xba997 0x0
.debug_frame 0x16ca8 0x0
.debug_str 0x1c2fb 0x0
.debug_loc 0x1439d1 0x0
.ARM.attributes 0x32 0x0
.debug_ranges 0x1dc00 0x0
Total 0x6fab68
> Process Exit Code: 0
> Time Taken: 02:09
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 770912 0 770912 bc360 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
768260 2652 2383336 3154248 302148 main.elf
main.elf :
section size addr
.text 0xbb780 0x8000000
.ctors 0x0 0x80bb780
.dtors 0x0 0x80bb780
.ARM.exidx 0x8 0x80bb780
.itcm 0x17c 0x0
.data 0xa5c 0x24000000
.bss 0x11c60 0x24000a60
.heap 0x0 0x240126c0
.dtcm 0x20c 0x20000000
.stack 0x4 0x2000020c
.ram1_d2 0x0 0x30000000
.ram2_d2 0x0 0x30020000
.ram3_d2 0x0 0x30040000
.ram4_d3 0x0 0x38000000
.batram 0x0 0x38800000
.extram 0x233f78 0xd0000000
.qspirom 0x0 0x90000000
.comment 0x4d 0x0
.debug_aranges 0x4d20 0x0
.debug_info 0x118dd1 0x0
.debug_abbrev 0x18cba 0x0
.debug_line 0xb91af 0x0
.debug_frame 0x13678 0x0
.debug_str 0x1bc3c 0x0
.debug_loc 0x14a497 0x0
.ARM.attributes 0x32 0x0
.debug_ranges 0x1cd68 0x0
Total 0x687fd4
> Process Exit Code: 0
> Time Taken: 02:07う”…サイズ増えてる…
実はちょっと困ったことがあってGCC10.0に上がったせいでChaN氏のFatFsで
ワーニングが出ちゃっています。
↑2048行目でワーニングが出てしまっています。
これは配列のインデックスが0からさらにデクリメントされる
コードが実行されると推測されてときに発動されるようです。
/* itoa (hexdecimal) */
i = 7;
do {
c = (BYTE)((seq % 16) + '0');
if (c > '9') c += 7;
ns[i--] = c;
seq /= 16;
if(i==0) break; /* Nemui */
} while (seq);
ns[i] = '~';↑インデックスが0の時の判定文追加してお茶を濁してます…
ChaNさんこれ見てたら効果的なワーニング対策お願いします！１１！！！
あとこれは気にしないでいいらしいです…
それとSTM32F7discoveryにおいて最適化の問題に引っかかって正常に
LCDが表示されなくなる現象が発生してしまったのですがpragmaで最適化を
切って対処してます…もっといい方法があるかもしれませんが今はこれが
最適解…
●秋月でSTM32G0、STM32L0追加！！
なんと秋月さんよりSTM32L0と8pinのSTM32G0が追加されてます！！
実はすでに入手して動作確認も行ってますがここで話すには多すぎる
内容ですので次回以降にこうご期待！！！！
●安価なAVR128DA48評価ボードゲッツ！
AVRの正当進化系のAVR128シリーズ。
AVR128DA48の超格安の評価ボードを手に入れました！！
その名もAVR128DA48 Curiosity Nano！！！
しかも電圧変換機能を持ったmEDBGつき！！
もうAVRライタは作る時代から安価で買う時代に変遷してしまいましたね〜
ちなみにavrdudeはビルドインされたmEDBGとAVR128シリーズには対応して
なかったのですが神パッチによって自由自在にできるようになっております！！
こちらもSTM32G0と同じく来年みっっっっっっっっっちりと特集させてもらい
ますので期待してお待ちください！！
と言いたいところですが先行でAVR128DA48 Curiosity Nanoに対応した
avrdudeを公開しております！！！
興味がある方はどんどん使ってください！！！
…というわけで今年も駆け込みでばたばたしてしまいましたがたくさん
買い込んだマイコンやセンサ基板とかの評価も来年も進めていきたいと思います…
皆さまもよいお年を〜
>ねむいさん‥‥DropBoxの見えなくなった画像ﾉﾎｳﾊ…
来年から本気出す！！！！！１！！
STM32H7はぢめました・・・本当にいまさら
ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
まってたぜぇ…この瞬間(とき)をよぉ…！
出る出る詐欺で一向に出る気配がなかったSTM32HのDiscoveryがついに私の
手元に入りました…！本当に長かった…！(※正式名称はSTM32H747I-DISCO)
基板の形状はSTM32F769I-Discoveryとほぼ同一ですね
メインCPUはH7シリーズ第二世代のSTM32H747XIH6です。第2世代になって何が
変わったかというとなんとCortex-M4コアがもう一つ付いたデュアルコア構成と
なっております！！！！
そんでもってビルトインされたSTLinkも最新のV3仕様で使用CPUはSTM32F723です！
なんとオンチップでUSB-Highspeedの物理層が乗っかっているすごい奴なのです！！
SDRAMはISSI製の32Bitデータバスの32MByteの奴が乗っかっています。
液晶を外して基板表面も見てみましょう。液晶モジュールはSTM32F769I-Discoveryと
全く同じMIPI-DSI接続のWVGAなTFT-LCDです(容量性タッチパネルICも同じ)
LANの物理層はおなじみMicrochipのLAN8742Aです。
そしてこの多CHフォトカプラみたいなのなに…と思ったのですがこれがQSPI-ROM
なのです！マイクロンのMT25QL512ABB8ESF-0SITが乗っています。
そして基板の反対側にもついている。STM32H747XIでは2つのQSPI-ROMを一つの大
容量クアッドSPI-ROMのように使えるDUAL-QUAD Modeが搭載されております！
I2S-CodecはおなじみのWM8994Eです。
そしてArduinoスタイルのコネクタの他にもI/Oを外部に拡張できるコネクタが
新設されました！Xbeeとかをそのままつけられそうですね〜
…
ぜんぜんピン間隔ちがってたorz
外観はこの辺にしておいてUSBMicroケーブルぶっ刺して通電です！
STMicroがイチオシするSTemWinとTouchGFXをふんだんに使用したでもアプリが
起動します。
TouchGFXはSTM32F769I-Discoveryの時のようにCPUの負荷状態とか見られる機能や
JPEGやDMA2Dみたいな各種ハードウエアアクセラレーションの効果を見ることが
できるプログラムもあり…おや…これは…
ク ソ ゲ ー 再 び
モーやってられませんわこれ(←律儀にやる人
さて、STM32H7でもいつものベアメタルでとりあえず組んでみる予定です。
現在はLチカにはぢまってねむいさんのコンテンツでは欠かせないDMA動作を絡めた
FatFsの実装まで完了しております(画像はLED点滅しているところ)。
H7に上がって機能も制約もF7とは段違いに変わってますので実装を進めながら
次回以降にみっちりと解説していけたらと思います！
近畿自然歩道を往く(伊勢志摩めぐり終章、そして熊野古道へ)
今年も〆のトレランの季節がやってまいりました。
ここ数年の年末は近畿自然歩道の伊勢志摩ルートをひたすら掛け巡っておりましたが
今回から熊野街道伊勢路の別ルートに相当する｢熊野脇道｣と道方という場所で合流し、
さらにいくいくは熊野古道伊勢路と合流して熊野本宮を目指す流れとなって行きます。
●2017.12.28 近畿自然歩道(道方〜阿曽浦〜鵜倉半島〜(河村瑞賢公園))
舞台は伊勢志摩、ですがその南端の南伊勢町にある道方という場所まで
まずは伊勢市駅からバスで1時間くらい揺られます･･･もうすでにケツが･･･
ちなみにバスの運賃も1000円以上かかる場所なのですが今の私は違う！！！
株主優待券を駆使して交通費を圧縮して移動しますよぅ！
すでに疲れた状態で道方バス停よりスタートです･･･
当分の間、ここ道方バス停が南伊勢町エリアの前線基地となります。
ますは自然歩道のエントリポイントに向かいます。
国道に沿えばすぐですが寄り道で見所がある県道を進みます。
まずは山のてっぺんが海に落ちてできた道方の浮島です。
県道の途中で林道が延びていてそこから浮島パークなんとうの浮島展望台に
たどり着きました。ここからは今から向かう南島親子大橋が望めます。
そして県道を降りて国道と合流したところで近畿自然歩道のスタート地点と
なり、集落めぐりがはじまります。
南伊勢の集落には｢浦｣のほかにご覧のとおり後ろに｢竈｣という名がつくものが
あります。これは平家の落人伝説にちなんだもので平家の落人がここで製塩を
して暮らしたといわれることからついたそうです。
このあたりの海水は底が見えるくらい透き通っていてとても綺麗です
良い塩が作られたのでしょう。
お次は阿曽浦に向かいます。
途中で塩竈浜に行く路があるのですがかなり遠い寄り道なのと
工事中だったのでパスしました。
リアス式海岸の海沿いをなぞるように走っていきます。
阿曽浦に着きました。
冬に備えて魚の干物がたくさん作られていました。
阿曽浦を越えてついにやってきました親子大橋。
まずは阿曽浦大橋を渡ります。
橋から見下ろす海がエメラルドグリーンでものすごく綺麗でした♥
海といえば若いころは駿河湾の荒い海しか知らなかったので日本にこんな
場所がまだあったのかと感心です･･･
親子橋の中間にある中の磯展望台からの景色も
すばらしいです☆
お次は南島大橋です。
こちらも太陽と海のコントラストがすばらしいです♥
阿曽浦口バス停まで着ました。
ここで一旦自然歩道終了です。前途のとおりすでに道方から続く
熊野脇道にそってしばし進みます。
国道260号線は高台を進みますが熊野脇道は古くからの集落の中を
進んでいきます。
贄浦を通り過ぎます。このあたりで260号線が二手に別れ、
ねむいさんは海沿いの260号線を進んでいます。
虹のホール南島のあたりから次の自然歩道のステージが始まります。
鵜倉半島を進み、贄浦漁港を見返します。
鵜倉半島の展望台は近くにトイレが無いのでここで体制を立て直します。
･･･恋人の聖地？？？
工事中の看板がきになりますがゆるい坂を駆け上って展望台を目指します。
まずはあけぼの展望台です。
自然歩道は途中でかさらぎ池に降りますが寄り道してさらに駆け上がり
見江島展望台にむかいます。
見江島展望台です。
ちょうど工事中でしたがちゃんと展望台まで行けます。
そして恋人の聖地らしいこの展望台から見たかさらぎ池は･･･
言われてみると確かに･･･
････♡
さらに奥地にあるたちばな展望台です。
戻って電波塔と三角点が付近にあるかさらぎ展望台です。
展望台群から離れて自然歩道のルートに復帰しかさらぎ池におります。
冬の日の光に照らされたかさらぎ池です。
限りなく海に面していますが一応池だそうです。
池から北上していきます。
ここでルートミスをしてしまいそのまま北上することに･･･。
奈屋浦港を脇に見ながら神社によりつつ上します。
本当は東宮トンネルを抜けて八柱神社を越えて奈屋バス停に
たどり着くのですが道を一本間違えたようです･･･
･･まぁいいか･･･
そして帰りのバスが来るまで時間があまりまくっているので熊野脇道を
もう少しだけ進みました。
河村瑞賢の一族が祀られている大仙寺です。
260号線に戻り坂を上ると途中に河村瑞賢公園があります。
ここで終了としました。
ちなみに河村瑞賢公園の裏手から河村一族の墓所をとおり
大仙寺に近道で戻ることができます。
時間調整も上手くついてちょうどバスがやってきました。
もうすでに日が墜ちだしていますね。
道方バス停より三重交通バスで伊勢市に戻ります。
帰りも株主優待券を駆使してお得に帰還です☆
すっかり日も暮れたころに伊勢市駅に到着です･･･。
特急待ちで外宮の参道を少し散策しました。
い つ も の
大晦日と初詣には人でごった返すのでしょう
外宮の手前にはすでに人員整理の準備が進められています。
頃合になったので今度こそ近鉄で京都に帰還しました･･･。
交通機関の移動時間のほうが長いですがここから先さらに
過激に長くなるのは必須なのです･･･。
そして当日の戦利品はしっかり堪能させてもらいました♥
というわけで2017年のトレランも無事〆る事ができました。
来年は熊野古道の攻略に重心を置くことになりますが熊野本宮までのそれぞれの
ルートはとても広大なもので現時点でまだはるか遠いので数年越しの気の長〜い
計画になりそうです！
近畿自然歩道(道方〜阿曽浦〜鵜倉半島〜河村瑞賢公園) GPSログ
近畿自然歩道を往く(伊勢志摩めぐりその2)
昨年のダイトレ全走破に勢いをつけて今年はロングトレイルの生駒山脈縦走や六甲
全山縦走に果敢に挑んできました。
それでちょっとがんばりすぎたせいかダメージが積み重なり冷え性になってしまったので
今年の〆は昨年と同じく暖かい空気と海がある伊勢志摩に繰り出す事にしました。
私のヤマレコとか見てた方は｢すでに伊勢志摩めぐりその５くらいまで逝ってるん
じゃね？」とお思いでしょうけどもこのぶろぐ上ではまだ２つめです！ややこしいですけど。
とはいえ知らない方もいるかもしれませんので一応紹介しておきます♥
近畿自然歩道(松阪〜栃原)
「城下町松阪の文化にふれるみち」(近鉄松阪駅〜松尾小学校前バス停)
「山あいの古寺と両郡橋をたずねるみち」(松尾小学校前バス停〜丹生大師前バス停)
「丹生の歴史をめぐるみち」(丹生大師前バス停〜JR栃原駅)
近畿自然歩道(伊勢市〜松下(〜鳥羽))
「お伊勢さんを感じるみち」(近鉄伊勢市駅〜近鉄朝熊駅)
「御塩づくりにふれるみち」(近鉄朝熊駅〜JR松下駅)
近畿自然歩道(安乗〜志島〜船越浜)
「安乗灯台と文楽のみち」(安乗バス停〜志島バス停)
「大王埼灯台をたずねるみち」(島茶屋バス停〜船越浜バス停)
それではスタート！
●近畿自然歩道(船越浜バス停〜浜島港（〜浜島海浜公園〜桧山路バス停))
虹裏メイドの朝は早い。
近鉄特急で2時間以上ゆられてさらにバスで40分くらいゆられます･･･
船越浜バス停からスタートです。
今年の夏は少し進んだところのトイレのある場所で離脱したので
ホントのスタート地点はそこですけど。
ありゃりゃ･･･いきなり路に迷った･･･
確か船越大池をこっち側から見てはいけないはずだけど･･･
なんとこの布団が干してある階段の裏の壁の死角になる部分に
道標が！！！！！F**K!
でもそんな気分を一気に押し流すほど綺麗な海がお出迎えです♥
ルートを外れてちょっと寄り道して名も無き岬に向かいました。
･･･
美しい･･･♥
ルート上はこの小山を乗り越えるのですがどこにもルートが無い･･･
探しまくって日蓮宗の海難供養碑がある場所の藪の中に正式な
ルートを見っけました･･･これ夏だと絶対わかりませんてば！
！！！！！！！
確かに堕ちたら即死亡の超危険な崖でした･･･
それを乗り越えると退治岬の見に灯台があります。
冬なのに草ぼうぼうのトレイルを抜け、引っ付き虫だらけになった格好で
深谷水道を越えて車道をひた走ります。
片田稲荷神社を見送ります。
大野浜に出ました。
ずっと見ていても飽きないくらい太陽と海が綺麗ですね･･･♥
そしてルートは墓場を抜けますが･･･
そのルートには鎖から解き放たれた猛獣が･･･
そういえば地獄には番犬がいたっけ(byイレギュラーハンターSEエックス)
両者にらみ合いが続く中、飼い主が墓参りが終ったことにより戦いが
急激に終結しました。
ねむいさん霊長類猫科だから犬と仲が悪いのですよぅ〜
でも猫ちゃんも普通に逃げるよ！
orz
乙部浜です。
はるか遠くに夏に訪れた大王崎灯台が見えます。
麦崎灯台までやってきました。
絶景に次ぐ絶景です☆
この日にここに来てよかった〜♥
冬は天気が安定してるので晴れの日が多いから
穴場なのです！ホントは真夏のどピーカンな日がベストなのですけど。
灯台を抜け、片田港に進みます。
そこから先は新興住宅街で行き止まりばっかり！
しかも道標がこう言うときに限ってないのであちこち迷いました。
だがそれを乗り越えて得られた景色はプライスレス♥
たまに思い出したように近畿自然歩道の道標がありますが
あんまし役に立ちません。
志摩ふれあい公園の休憩所です。
上水道水やトイレがあります。
大きな丸い石かと思ったら
志摩半島を唄う歌の歌詞が刻まれた石碑でした･･･
ここから先、この海女さんの案内看板がたくさん目に入ってきます。
和具の港です。
ここから自然歩道的には中継地点となります。
城山休憩所です。
特に目立った特長は無いですが･･･
海の水が綺麗過ぎて水色に見える･･･(錯乱)
今回のようなアスファルト上の移動が殆どのコースではチェリオの
100円オゑイしスがとても助かります♥
熊野古道の攻略でも大活躍してると思います！！
あづり浜を横切ります。
目指すは金毘羅山！
オートキャンプ場の脇に突如現れる海女体験小屋･･･
そうこうしてるうちに金毘羅山登山口に到達です。
途中までは舗装された車道です。
近畿自然歩道は三角点が無い高いほうの金毘羅山を目指します。
トレイルに変わった道をどんどん登ると･･･
トイレがあった！？
さらにトレイルを駆け上がり･･･金毘羅山頂です！！
うわさどおり360度の展望ですね〜
さぁ後は御座浦に向かって駆け下りるだけです！
下っていくとルート上に存在する爪切り不動尊に落ち合いました
観光客が絶えずいますが荘厳な雰囲気です。
撫で石なるものもありました。
ねむいさんもなでなでしまくりです♥
国道260号を駆け下りて御座港に到着です。
今回のルートは船便があり、対岸の浜島港がゴールです。
少し早く来てしまったので結構まちましたが船は無事やってきました。
･･･っていうか搭乗口そこかい！
ドパンドパンと音を立てて船は進む･･･
十分ちょっとの船旅でしたが無事浜島港に到着です。
ここが本来のゴールですが実は次のルートの起点でもあり、
交通の便宜上ねむいさんは少し先に進みました。
やっぱり美しい浜島の海･･･
有志が作成した魚のタイルアートも見られます。
宇気比神社です･･･。
鼻かけ恵比寿さんです･･･
ここ（恵比須が丘)からみえる熊野灘は美しい･･･♥
そこから丘を降りて浜島海浜公園です。
ビン玉ロードの案内看板がある場所で
近畿自然歩道から離脱です。
浜島バス停です。
バスの来る時間がまだ先だったのととお金の関係でロードワーク追加！
桧山路というバス停でバスを待ち乗り込みました。。
鵜方駅に戻ってきました。
冬は日が堕ちるのが早いです･･･
ねむいさんがぜかましにのれるのはお金と時間に余裕が出来る時だけですね〜
と思い込んでしまいそうになりちょっとセンチになっちゃいます･･･
京都に帰るためには2段階乗換えで帰らないといけない･･･
大和八木で寝過ごすとアウチ！
そのまえに最初の鳥羽駅でお土産はしっかり買い込んでおきました！
お土産も含めてやっぱり家に帰るまでがトレランです！
というわけでこんな形で2016年の山行(？)を〆てしまいましたが･･･
来年は比良山系の縦走などのちょっと危険度の高い難しい場所に
どんどん挑戦していきたいと思います！
近畿自然歩道(船越浜バス停〜浜島港（〜浜島海浜公園〜桧山路バス停)) GPSログ
追伸：
今回から登山系のレポートで使っているSNSをYAMAPへと完全に乗り換えます。
プラットフォームがかわっても内容は変わらずしっかりと充実させていきますので
よろしくお願いします！
WVGAな解像度で容量性タッチパネルなTFT-LCDモジュールを動かすその2
どこへ行っていたンだッ！カンガルー先輩ッッ！！
俺達は君を待っていたッッッ！！
なんとめでたい･･･いつの間にかトラ技にカンガルー先輩が帰って来てくれて
ましたよぅ！また暴れまわろうＺＥ☆
めでたしめでたし♥
以下はおまけです。
前回のWVGA液晶の紹介の際にコメント欄で早々にネタバレされてしまい、おまけに
六甲全山縦走路の攻略とかなにやらでサボっていた隙に章さんに先を越されて
しまいましたが480x800をさらに越える480x854という膨大なサイズを持ちつつ容量性
タッチパネルを当たり前のように持つ5inchなTFT-LCDモジュールを4ヶ月くらい
以上前に入手して動作せしめておりますので紹介させていただきます。
前回モジュールとの大きさ比較です。4.3inchでもでかいと感じてましたが5inchの
爆☆発☆的な存在感には到底及びませんね〜♥
TFTのコントローラICはILI9806Gとなります。
ここでいきなりですが前回と同じ注意ですが大解像度の液晶モジュールでは
コントローラIC内のフレームバッファ用RAM容量の節約のために本来必要な量の
半分に削られているHalf-RAMモデルのコントローラICが存在します。
大きい解像度だとマイコンとの接続もSPIとかFSMC等のi8080スタイルのMCUバスに
よる接続よりもRGBインターフェースで繋げたほうが効率が良くなるため、少し
でもコストを下げるためにこのような品種が存在しているかとおもわれます。
ちなみにHalf-RAMモデルのコントローラは偶数アドレスしか指定できず、奇数
アドレスを指定しても無効になるので意図した座標にドットを上手く打つことが
出来ず表示がぼろぼろに崩れます(偶数アドレスだけを指定する使いかたならOk)。
ですから私にとっては私のいつものとはものすごく相性が悪く、単なる地雷に
ほかなりませんのでHalf-RAMモデルのコントローラICが乗ったTFT-LCDの購入は
極力避けております。
以下に私がうっかり購入してウボァーした品種を列挙します。
D51E5TA7601
->これは320x480のHVGAなTFT-LCDで中華通販で良く見かけるのでご注意ください。
OTM8012A
->これはWVGAなTFT-LCDコントローラではポピュラーなOTM8009AのHalf-RAM版
です。OTM8009Aとくらべてあまり遭遇しないので多分大丈夫でしょう。
ILI9806H
ｰ>これは前出のILI9806Gとものすごく間違えやすいですからご注意ください！
これも中華通販で良く出回っています。うっかり買ってしまうとｱｳﾂです！
話を戻しましょう。動かし方は初期化の呪文を唱えた後は有名なILI9341たちと同じ
ようにMIPI DisplayCommandSetに倣って0x2A,0x2Bでレクタングルを指定したら
0x2Cでデータを送信するというお決まりのパターンです。
そしてこのモジュールではIMxが外に出ていてデータビット幅とかも変更可能です。
ここまで解像度でかくなるとSTM32F4のFSMCでもきついはずなのでなるべく
デフォルトの16bit幅で使うようにしましょ。
もはや説明不要のFatFsとSDカードの動作試験も兼ねたいつもの。
480x854もの広大なサイズなのでいないさんの表示もらくらくです。
前回と比べて54ドット分ちょっと足先が長めに見えているのが分かると思います。
これだけでかい画面を十分に光らせるためバックライト用のLEDの電力消費が著しく、
モジュール全体で常に100mA以上喰うので3.3Vの電源供給は十分に行ってください。
さらに液晶自身の発色もかなり良くなっていてご覧のとおりいないさんの美しい
肌が青映りせず鮮やかに表示されています♥
有機ELとはなんだったのか…
液晶そのものの話はこの辺にしてお次はタッチパネル部分のお話です。
このモジュールは抵抗膜式タッチパネルと容量性タッチパネルの両方が選べます。
もちろんねむいさんは容量製タッチパネルのモデルを購入しましたが前回の物とは
かなり勝手が違い苦戦しました。このモジュールに使用されているCTPコントローラ
ICはFocaltech社のFT5336GQQという相互容量方式の品種です。
そう、こいつはSTM32F746G-Discoveryに乗っていた奴と同じなのです！あのときは
STマイクロ提供のBSPに頼りっぱなしでした。尤も前回でSPLでI2C接続のCTPコント
ローラを叩くためのルーチンをこさえて居たのでこれも問題ないだろうと思って
いたらなんと画面に触った時だけ変化があるINT出力の挙動がまったく違っていて
入力がまったく受け付けられていない状態となっていやがりました。
↑画面をタッチした時のINT出力波形(前回モジュール)
↑画面をタッチした時のINT出力波形(今回モジュール)
しかも今回のは内部でIOVDDが1.8Vにされているのか1.8Vしか出ていません！
(ていうか3.3Vでプルアップしてるのに1.8Vとか出力ODじゃ無いのかYO!)
一応STM32の+3.3V動作時のハイレベルのスレッショルドは切っているので電位の
問題ではなく処理の問題だと判断し、100mSec単位のポーリングで行っていたINT
の処理を割り込みに変えたりあーだこーだやっていましたが思ったように
座標データをとることがなんでか出来ませんでした。
結局100mSec単位のポーリングでSTM32の外部割込みのフラグを見てデータを取り
込むことで従来どおりの操作感覚を取り戻すことが出来ました。
EXTIだけ有効にしてNVICの設定は行わず割り込みベクタそのものに飛ばさないのが
ミソです。毎回割り込み処理に飛ばしているとタッチパネルに触ってる間ずっと
割り込みが発生することになり他の処理がまったく出来なくなっちゃいますので。
ねむいさんのいつもののtouch_if_basis.cやtouch_if.cを見ていただいたら私の
あがきの跡が分かるかと思います。
あとねむいさんが想定したY軸の座標が上下さかさまだったのでこれも前回
モジュールにあわせるようにしています。もしかして気付いてた方もいたかと
思いますが6月の終りにはすでにコードに仕込んでおりました。
ちなみにFT5336GQQのデバイスIDは0x51だそうです。
5inchは良い。心が洗われるね。
こんなわけで6月の終りくらいに購入したモジュールをいまさら紹介するハメに
なってしまいましたがSTM32のFSMCで賄うことが出来る中では実寸や解像度的に
今度こそ！
これが最強最後のTFT-LCDモジュールである！と言う事が出来ると思います！！
たぶん来年あたりも同じこと言ってるかも知れませんがー！
WVGAな解像度で容量性タッチパネルなTFT-LCDモジュールを動かすその1
数年前にこのLCDが最強最後とか言いましたが･･･
ありゃウソですよぅ
これがっ！480x800でッ！IPSの広視野角でッ！しかもCTP(容量製タッチパネル)
までついったっ！MCUバス向けの最強最後のTFT-LCDモジュールです！！！！！
そしてサイズは4inch!!
中華通販で変換基板付で購入しました。配線の手間が省けて超ラクです♥
TFT-LCDのコントローラICはRM68120という480x800サイズに対応したものです。
ここでちょっと気をつけなければならないのは、大きなサイズのLCDコントローラIC
では内部RAMが半分もしくは全部ない場合があり、そういった品種では8-bit,および
16-bitバスなどのMCUバス経由ではマトモに表示することが出来ません。中華通販で
買うときはご注意ください。
容量製タッチパネル(CTP)は抵抗膜式タッチパネルよりも処理が複雑でマイコン
単体では賄いきれないため専用ICがほぼ確実にセットになっております。
ICの頭にFT5216GM7と書いています。FocalTech社のICですね。
ネットでいろいろ調べてみたのですがFocalTech社のデータシートでよい物が
なかなか見つかりませんがこのCTPコントローラICは2.8〜5インチで相互容量
方式となっています。STM32F7-Discvery(F769版も)にはFT5336GQQという
マルチタッチサポートな相互容量方式のものが使われています。
容量性タッチパネルコントローラの自己と相互の方式の違いについては
ノリタケLCDさんちの説明がとても分かりやすいです。
さて、このFT5216はタッチポイントが一つしか搭載していません。結局抵抗膜式と
あんまし変わらない感覚ですので使い勝手を抵抗膜式の時と同じになるように、
FT5xx6シリーズはタッチポイントが5つまで、さらにジェスチャ機能もサポート
しておりますが、従来の抵抗膜式タッチパネルと同じ感覚で操作できるように
いつものにCTP向けの処理を追加していきました。
世に出回っているCTPコントローラはI2Cインターフェースと外部割込み
用端子がでているものが殆どです。当然ながらSPIよりも速度が遅いくせに
シビアなI2Cペリフェラルの操作が要求されるのでご注意ください。
また、殆どのケースでINT割り込みの処理が必須になるでしょう。
で、動かしているところです。まずCTPコントローラICのdeviceIDを読み
取って表示できるようにしました。0x79はFT5216の証です。
そんでもっていないさんの全身図を♥
480x800の世界ってｽﾊﾞﾗｼｲ♥
昨年まではWVGAサイズなTFT-LCDも容量性タッチパネルもなかなか手が伸びにく
く実験レベルで終わっていたジャンルでしたが、現在では気軽に利用できる段階に
までなったと感じております。これから先どんどん活躍していく事でしょう。
なんとこの記事、次回につづきます･･･
コスプレ大好きいないさん
どうでもいいですがねむいさん自身いなちゃんが誰のキャラのコスプレしてるのか
知らなかった･･･
近畿自然歩道を往く(伊勢志摩めぐりその1)
今年はダイトレ攻略で燃え尽きた感がありますが攻略すべきトレイルはまだまだ
たくさんあります。ねむいさんは現在交通費の割引が聞く近鉄を駆使して
伊勢志摩方面を攻略しかけています。今回もそんな攻略ルートの一つです。
朝の朝熊駅(だじゃれではない)･･･ねむいさんいきなり寝過ごして
だいぶ遅いスタートとなってしまったorz
何はともあれスタート･･･電車で我慢してたせいかいきなりもよおしてしまった･･
ううトイレトイレ(byくそみそテクニック)
であいの広場には水洗トイレがあります★
あぁすっきり♥(CV高宮なすの)
･･･すみません
このトイレのそばに登山道がありトレイル開始です･･･
朝熊が岳は信仰の山なのでお地蔵さんや丁石がたくさんあります。
ケーブルカー跡をクロスします。
ここからの景色は格別です♥
朝熊峠です。こちらの山荘跡からも良い景色が見られます★
朝熊峠からは宇治道の車道と合流します。
ここで山頂方面に進路を変えま･･ん？
んんんんんんんんん！！？
それはおいといて山頂を目指します。すぐに電波塔に出ます。
電波塔のある場所が山頂部で朝熊が岳山頂と八大竜王社があります。
もちろんここからの伊勢志摩の景色は格別なのです♥
お次は経塚群の中を下ります。
更に下ると一般参拝者と合流します。
極楽門をくぐって金剛證寺奥の院に。
そこから戻って金剛證寺本堂へ。
まんきんたん･･･実在したんだ･･･!
開山堂です。
金剛證寺の一通り見たので次の場所に行くか･･･と思ってたらその目線のさきには･･･
こっこれは･･･
ま、まさに･･･！
ﾔﾀﾞｰ//////////////////
そんな馬鹿なことやってたらルートミスしてしまいましたorz
旧参道を通るのが正解のようです。
しばらく進むと近畿自然歩道の道標があります。
しかしその道は序盤と打って変わってかなり荒れてます･･･
今は山の中、伊勢ドラブウェイが近くを走ってるはずですが･･･
やばい崩落箇所も越えます。
ようやく舗装路に･･･
ここは鳥羽レストパークと呼ばれる場所で、
春は桜で有名な場所だそうです(ルートミス中)
そのまま下って丸山庫蔵寺の分岐を見落としてたorz
丸山庫蔵寺の本堂です。
丸山庫蔵寺からの下りは滑りやすい石ばっかでヤバイです･･･！
やっとなだらかになってきたところで彦滝大明神があります。
下りきると今度は川沿いにひたすら進みます。
九鬼岩倉神社です。
加茂駅までもう少し！
のはずだったのですがこの道標で左折するとは知らずとおり過ごしてしまったorz
ファック！！！！！！！！！！！！！
加茂駅に到着です。
補給しながら第二ラウンドの準備を整えます。
次のルートは松尾駅からなので国道を加茂川に沿って移動します。
･･･この秘法館ってかつての鳥羽の･･･！？
ぜかまし
松尾駅に駅構内に近畿自然歩道の道標があります。
第二ラウンドスタート！
冬なので菖蒲園は休養中のようです。
青峯山登山口に来ました。こっから登山道です。
勾配のもゆるく、サクサク駈けあげることができました♥
ますきち岩です。
あまかぼうか岩です。
時折見える景色は素晴らしいです♥
前半の苦戦が嘘のようなサクサク具合☆
護摩岩です。
正福寺に到着です。
ここから先は舗装路です。
その前にちょっと寄り道。
車道を上がってNHKの中継局のある場所に。
ここが青峯山(天跡山)の山頂です。
あとはひたすら車道を下る！！！！！
夕日も美しい･･･
駆け下りろー！！！！
ここで県道と合流して更にみちなりに進みます。
もうすぐ日も落ちます。
い ぬ
近畿自然歩道のゴールの上の郷駅です。
もう少しだけ進みます。
伊離宮です。
磯部の御新田です。
磯部神社です。
日が落ちた直後に志摩磯部駅に到着しました。
着替えを済まして駅の外に出るとすっかり真っ暗です。
完全に暗くなった頃に特急に乗って還りました。
大和八木で乗換えなので寝堕ちができませんでしたが
無事乗り換え完了です
こんなわけで今年最後のトレランを〆ることができました。
朝から寝坊して中盤はルートミスしまくりでやばかったですが
後半は一度も落とさずほぼ予定時間に到着できたので安心しました♥
結局最後の最後までﾄﾞﾀﾊﾞﾀしてしまいましたが何とかなりましたので
皆様も良いお年を〜
近畿自然歩道(朝熊〜上之郷(〜志摩磯部)) GPSログ
STM32F7を使ってみる6 -タッチパネル入力とQSPIの追加-
もう気づいた方もいるかもしれませんがSTM32F7向けのいつものを9月1日版に
更新しております。
変更点は細かいバグ潰しと容量性タッチパネル入力、そしてQSPIの対応です。
●CTP(容量性タッチパネル入力)対応
STM32F7Discoveryには上記のタッチパネル付きのTFT-LCDモジュールが搭載
されています。型番でググっても出てこないのでおそらく特注品なのでしょう。
CTPコントローラにはFT5336GQQなる物が使用されております。
さて、以前はもっとも単純なADS7843系、ちょっとインテリジェンスな
機能をもつSTMPE811等の抵抗膜式のものを扱ってきました。
容量性の場合はメカニズムが全く違い複雑になるので専用ICに頼らざるを
得ないのですがそれの使い方を把握するのでもこれまた複雑で正攻法で
行くととても時間がかかってしまいます。
そんなわけでSTマイクロ提供のCubeF7ライブラリ群にはBSPとして
FT5336GQQ用のアクセス用関数がちゃんと用意されています。
しかもF7-Discovery用にI/Oの設定も御誂えております。
実装は拍子抜けするくらい容易でした。私の過去のタッチパネル入力の
処理と結合させてGPIOのエッジ割り込みの処理を追加するだけで済みました。
F7-Discoveryのデモではタッチした状態が変わらないと割り込み処理を
抜けられない構造になっていてデッドロックの危険性があったので、
そこだけは省いています。
他の上位のレベルの処理は一切変えていないので過去の抵抗膜式のものと同じ
ような感覚で操作できるようになっています。
本来ならばFT5336GQQのBSPがやってる処理を分解・再構築して自分独自の
タッチパネル入力処理とすべきところなのですが残念ながら私の技術力はそこまで
及ばずあえなく安易な方法、"出来合いの処理"を提示されたライセンスに従って
利用させてもらうことにしました。F7になってからは複雑化も相まってそういう
場面が多数出てきています。
私も巨人の肩の上に乗る小人のうちの一人にすぎないのです…!
前向きに考えるとソースコードを公式のものと互換性を持たせて問題を切り分け
易くするなんてことも言えますがゆくゆくはSeggerのSTemWinとかも使ってみたい
ので何でもかんでも自作にとらわれず柔軟にやってこうと思います。
もなかさんもこう言ってますしでも素のEclipseなんて絶対に使いませんよぅ！！
ｹﾞﾎｹﾞﾎ･･･ﾊｧﾊｧ失礼･･･次に進みましょう･･･
●QSPI-ROMをメモリマップドモードで使う
こちらはLPC4330の時にも紹介した奴と同じですね。SPI-ROMのメモリ領域が
特別な関数を経由せずにリニアにアクセスできるという便利な機構です。
ことSTM32F7に限ってはD-Cacheを挟むので従来のSPI-ROMではどうしようも
なかった速度的なボトルネックはある程度解消されるようです。
F7のHALライブラリにはQSPIの関数/BSPが用意されていますがメモリマップドモード
で使用する場合は一度イニシャライズしさえすれば後は普通の内蔵フラッシュ
メモリと全くおんなじです。
今回もBSPを最大限に利用させてもらっていますが、QSPIのメモリマップドモードでは
読み出し専用で使う場合は割り込み処理は全く不要なので初期化時のNVICの設定
を省いておくこともできます。
私はQSPI-ROMをFONTX2のデータ置場として利用しました。
F746DiscoveryではN25Q128Aが搭載されています。N25Q128Aは一セクタあたり
64kByteずつ分かれていますのでFONTX2ファイルを書き込むアドレスは半角を
0x90000000、全角は0x90010000に配置してみました。
あとQSPI-ROMにデータを書き込む方法ですがSTLinkUtilityのVer3.7からF7Discovery
用の外部フラッシュローダに対応しています。これを利用して書き込みます。
先ずは半角
お次は全角。
なんでか拡張子はbin,elf,hexしか駄目なのでFONTX2ファイル書き込む際は
拡張子をbinに変えて書き込んでください。
こうやってQSPI-ROMに書き込んだデータは上記のようにして参照します。
メモリマップドモードだからできる技ですね〜
無事に起動しました。S-JIS形式のtxt文書もごらんの通りです。
ビルド時に巨大なFONTX2ファイルを組み込む必要がなくなり、フラッシュ書き込み
に掛かる時間も節約できてテンポよくデバッグできるようになると思います。
デバッガからQSPIのメモリを参照するとこんな感じに見えます。
もちろん参照時はメモリマップドモードになっている必要があります。
これは半角のFONTX2です。
こちらは全角です。
現在はまだ限定的かつ実験的な使用にとどまっていますがQSPI-ROMの有効な
活用法が新たに見つかったら紹介していきたいと思います。
●おまけ
いつもののmakefileみたら何をどうすればわかるとは思いますが、デフォルトでは
以下の"ひとまず確実に動く設定"になっています。
1:内蔵フラッシュインターフェース
->AXIM
2:SDRAM
->有効
3:タッチパネル
->有効
4:FONTX2
->内蔵フラッシュから参照かつQSPIは無効
"4:"のFONTX2のドライバでQSPI-ROMを参照したい場合は当たり前ですが、
あらかじめ半角/全角それぞれのFONTX2ファイルを上で紹介した手順で
QSPI-ROMの適切なアドレスにSTLinkUtilを使用して書き込んでおく必要があります。
STM32F7を使ってみる3 -FatFsとLCDコントローラを動かす-
前回ねむいさんはUARTとFatFsをデモを参考にSDカード向けに組み替えて動作
せしめるところまで来ました。調子に乗ってDMA化しようと試みたのですが
なんでか正しく転送出来ませんでした。
ねむいさん真っ先に悪名高いHALライブラリにバグがあると思って調べまくり
ました。SPLで組んだF4のSDIOの転送するルーチンやDMAの処理の部分などを
穴の開くほど見比べたのですがこれと言って悪い箇所が見当たらず、まさか
エラッタかと思ってエラッタシートやフォーラムもしらみつぶしに見たのですが
そもそもまだF7が広まってない段階なので手がかりすら見つかりませんでした。
20150807追:
ここまで読んで｢あ、こいつキャッシュのこと理解して無い馬鹿野郎だ｣と思った
方はさっさと次のエントリに進んでくだち
20150807追:
DMA転送用のバッファメモリをDTCMやSRAM2や外部SDRAMとかにおいてもﾀﾞﾒﾀﾞﾒ
で困り果てていたのですがF7のデモがDTCMを含めた複雑な構成のSRAMを単純に
320kbyteのでかいSRAMとして扱っていたのを思い出し、ねむいさんも細かい
RAMの割り振りをやめてデモと同じようにしてみました。
するとDMAでもちゃんと転送できた。
ぇえ〜〜〜何が違うのよ！とぶちぶち言いながら何が足を引っ張っているのかの
切り分けを進めていくと最終的にFatFsの構造体をDTCMに配置していないと、
DMAがコケることが分かりました。デモではリンカスクリプトでDTCMの領域の
0x02000000から各種変数が割り当てられるため、問題だったSRAM1領域以降の
RAMまでは使用されていないことが分かりました。
データ用バッファとか話が分かるのですがなんでFatFsの構造体がDTCM領域に
無いと何故DMA転送できないのか理由が全く分かりません。F7はまだ世に出た
ばっかでエラッタも未知のものがたくさんあるでしょうから今は深追いは止め
てその先の作業に専念することにしました(しかしこのあとさらなる罠が)。
20150805追:
単にD-Cacheの取り扱いがわかってなかっただけでしたすみません。
と言う訳でFIFOポーリング版とDMA版の読み取り速度の比較を行ってみました。
ポーリング版でも効率化されてますのでDMAと遜色なくなってますね〜。ていうか早い
勿論条件は過去と同じ、スピードは双方ともSDHighSpeedModeにしております。
20150807追:
上の結果ですがPLLSAIの設定間違っていて実際はSDIO_CLK=44MHzくらいで測定
してましたすみません！！
↑ＰＬＬＳＡＩの設定を正しく行ってSDIO_CLK=48MHzで読み出したときの
真の速度です。
SDRAMを使用するとSTM32F7の最大クロック周波数は200MHzまでとなってしまい、
この時のSDMMCのクロックはSYSCLKから供給していると単純計算で48MHzよりも
若干低下してしまうのですがSAI用のPLLをSDMMCのクロック源とすることで48MHz
きっちり動作させることができます。
ひとまずFatFsはめどがついたのでお次はLCDコントローラ(LTDC)です。こちらも
以前STM32F429Discoveryで予習していたはずなのですがSPLとまっっったく構造が
代わっていたので難儀しました。
LTDCについては各種設定を行った後フレームバッファとするSRAM及びSDRAMの
ポインタを参照すれば何とかいつも通りに色を出せたのですが問題はDMA2Dでした。
ああでもないこうでもないを重ねてようやくF429で出来たのと同じように動作させる
ことができるようになりました。結局元のF4のSPLのコードを穴の開くほど読み込んで
CubeF7とどう違うのかの地道な切り分けです。
以下にDMA2D版のDisplay_wr_block_if()のF4版SPLとCubeF7の違いを示します。
両者とも色深度はRGB565の16bppです。
inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)
{
/* Set Display Pointer */
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);
/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode = DMA2D_M2M_PFC;
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_c_buf_ptr;
DMA2D_InitStruct.DMA2D_OutputOffset = (MAX_X - ((lcdc.width+1) - lcdc.x));
DMA2D_InitStruct.DMA2D_NumberOfLine = (lcdc.height+1) -lcdc.y;
DMA2D_InitStruct.DMA2D_PixelPerLine = (lcdc.width+1) -lcdc.x;
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){}
}
↑F429の
inline void Display_wr_block_if(uint8_t *p,unsigned int cnt)
{
/* Set Display Pointer */
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(lcdc.x + MAX_X*lcdc.y);
/* configure DMA2D */
Dma2dHandle.Init.Mode = DMA2D_M2M_PFC; /* memory to memory with PFC */
Dma2dHandle.Init.OutputOffset = (MAX_X - ((lcdc.width+1) - lcdc.x));
/* DMA2D Initialisation */
if(HAL_DMA2D_Init(&Dma2dHandle) != HAL_OK)
{
/* Initialization Error */
while(1);
}
/* Start DMA2D transfer */
if(HAL_DMA2D_Start_IT(&Dma2dHandle,
/* Source Buffer */
(uint32_t)p,
/* Dist Buffer */
(uint32_t)lcd_c_buf_ptr,
/* width in pixels */
((lcdc.width+1) -lcdc.x),
/* height in pixels */
((lcdc.height+1) -lcdc.y))
!= HAL_OK)
{
/* Initialization Error */
while(1);
}
}
↑F7の
DMA2Dを利用したレクタングルの塗りつぶし等の図形表現も無事再現できました。
F429で出来てたことをF7で再び出来るようになるまで1週間以上かかりやがりま
したがCubeF7が抽象化しすぎて逆にプログラムの流れが分かりづらいとかそも
そも作りこみが甘くbuggyとか公式のフォーラムでも未だに非難GOGOでF7版SPL
くだちとかいろいろ言いたいのですがまぁそれは置いといて…。
UART,FatFs,ディスプレイまで出来たら既にねむいさんのいつものができたと言っても
過言ではありません。ChaNさんの2009年作のLPC2388向けのデモをベースに足かけ
6年…もう６ねｎ…ｎ…グハッ！！！
失礼、ちょっとむせました。
画像はpngないないさん♥
libjpeg,giflib,libpng3つの画像ライブラリを用いたデコードも紆余曲折ありましたが
いつも通り出来るようになりました♥
こちらについては話が長くなるのでDMAする時のD-Cacheの取り扱いと合わせて
次回解説させていただきます。
そういうわけでSDMMCのDMA転送でだいぶ足止め喰らいましたがようやく形になって
来ましたのでここでいつものの公開をさせていただきます。残るは容量性タッチパネル
の処理の実装ですがこちらも初めての分野なのでじっっっくりと取り組んでいこうと
思います。
STM32F746G-Discoveryのいつものはこちら
STM32F7を使ってみる2 -STM32CubeF7移植への道-
STM32F7シリーズは今年から量産開始した新しいマイコンです。つまり昔から
STM32を昔から弄ってる人にとってはおなじみだったStandard Peripheral Library
(=SPL)のF7版なぞ影も形もなく、STM32CubeF7ライブラリ通称HALライブラリ
しか存在いたしません！
ChaNさんクラスの実力がある人ならリファレンスマニュアルからレジスタ構成を
引っ張ってきて自前のペリフェラルライブラリこさえるのでしょうけどねむいさんに
そんな力があるはずもなくなすすべもなくSTマイクロのエコシステムの一部に
とりこまれてしま…ぅ･･･
まだまだだぁ！！！
幸いにもCubeF7ライブラリの中にはSW4STM32(System Workbench for STM32)
なるEclipseベースのフリーのIDEがあり、コンパイラはGCCを使用していますので
これを分析することによって私のコマンドライン&makeの環境移植へのとっかかり
を見つけることが出来ました。
ところでなんでEclipse使ってるのに全身から血を吹き出して死なないのかこの
嘘吐きめと突っ込みたいでしょうが私はメーカーお仕着せの各種設定完了済の
Eclipseのカスタム版IDEでは無傷です。あくまで死ぬのは未設定の素のEclipseで
攻撃された時だけです。あといないさんがスカートをたくし上げて下着を見せてるイラストを
見せられただけでも死ぬので絶対に見せないでください
絶対にですよぅ！！！！
それはおいといてSTM32F7-Discoveryを使ってF7版のいつものの構築に移ります。
昨年の時点でNucleo系の板はSPLからHALライブラリに引っ越ししておりました。
しかしあくまでUARTやI2Cと言った基本のライブラリを動かす程度に留まって
いたのですが今回はSDRAMやFatFsなどを動かすところまで行きます。
STM32F7になってメモリ構成がF4よりもはるかに複雑になりましたが基本は
全く変わっていません。恐れずにF4と同じようにプランを練っていきました。
TCMのうちユーザーが触ることができるDTCMはF4ではできなかったDMAができる
ようになったので細かいことは気にせずスタック/Auto変数領域に割り振る
ことができます。CubeF7のExampleではDTCMの初めからメインSRAMの終わりまで
をまるまる一本の巨大SRAMとして使っていますので細かいこと気にするなと
言うことなのでしょう。実際DTCM〜SRAM2までリニアに繋がってますし。
↑実はこれが伏線だった…
そんなわけでいつものGCCのビルド環境のひな形が出来ました
先ずは基本の"き"LED点滅とUARTから。
LEDはF7-Disacovery上ではArduinoUNOライクなコネクタピンのSCKに
相当するPI1です。
なお、昨年くらいのCubeF4のアップデートで気づいたのですがGPIOのビット
単位でセット/リセットが可能なレジスタSBRR/BRRと言うのが昔はおなじみ
だったと思いますがそれが廃止され32bitのSBRRのみとなってやがります###
ビット単位でI/Oをやり取りする際にこれは超不便且つビットアクセスのための
新しくできたHALライブラリのオーバヘッドがでかすぎるので旧来のGPIOの
構造体を作って昔と同じように16bit幅のSBRR/BRRレジスタをアクセス
できるようにしました。
UARTはSTLink/V2-1のVCP入出力が繋がるUSART1ポートのPA9(TX)、そして
GPIOB7(RX)です。RXピンはおなじみのPA10じゃないのでご注意を！
と言うわけでこの2つはF4版NUCELOを参考にF7用にあてはめるだけでOKでした。
もちろんprintf関数などのnewlibの関数群との結合も余裕です★
ここでちょっと注意ですがSTLink/V2-1でVCPを使う際に特定のUSB3.0
ホストに差すとSTLink/V2-1側から送信するUARTの信号が正常に出力
されない場合があることを発見しました。
その特定のUSBホストと言うのはFL1100なのですが上記の画像のように
めちゃくちゃな信号が出力されてSTM32F7側と正常に通信ができません。
もしUSB3.0ポートで上手くいかない場合はUSB2.0ポートに差し直して
試してみてください。
お次はSDRAMです、F7-Discoveryには128MbitのSDRAMが搭載されています。
こちらもBSPの初期化コードを参考にねむいさんの環境に嵌めて行って危なげなく
動作せしめることが出来ました。このボードにおいてはSDRAMBank1に配置されて
いて0xC0000000が開始アドレスとなっています。
STM32F7でFMCを使ってSDRAMを使用する場合、F7側はデータバスが16bit分
しかないので32bitの変数のアクセスはAHBバスで16*2bitに分割転送されます。
そんなわけでこのボード上では上位16bit分のデータバスを男らしくバッサリ
捨てており容量は128MBitありますが実質64MBit分しか使えませんorz
また、Example曰く実装されたSDRAMが安定動作するシステムクロックの
上限は200MHz、その時のSDRAMCLKの上限は100MHzになるので、
(↑根拠としてSTM32F7のデータシートに下記の記述がありました。
For 3.0 V≤ VDD≤ 3.6 V, maximum FMC_SDCLK = 100 MHz at CL=20 pF (on FMC_SDCLK).)
単純計算で100MHz*16=1600MBps
が理論値となります。なんかちょっともったいない使い方ですね…。
前回の記事でたけさんと言う方からリクエスト貰いましたのでSDRAMのR/W
性能を測定してみました。4MByte分(下述)を16bit変数単位で読み書きした値です。
D/I-Cacheは有効にしていますが妙に数値が低いのは私のコーディングが悪い
せいでしょうか･･･
最後にFatFsです。CubeF7謹製のFatFsのローレベルドライバはやたら凝っていて
USB-OTGのUSB-MSCの接続も想定したつくりになっています。FatFSで必須な
関数群はFATFS_LinkDriverなる関数で結合する仕組みとなっています。
今回からはSTのスタイルに倣ってそれを積極的に使うようにしました。
といっても私のプロジェクト向けにほんの少しの変更をしただけですが。
まだTFT-LCDのドライブまでは進めてないのでUARTからのコマンドでFatFsの
動作を確認しました。F7-DiscoveryではSDIO改めSDMMCインターフェースが
出ていてSDカードからのデータを高速にやり取りできます。
いつものごとく読み出し速度を調べてみました。CubeF7のExampleではSDMMCの
クロックは潰しの効くNomalMode(25MHz以下)に抑えられているのでF4の25MHzと
さほど変わりませんね。
CubeF7のライブラリを調べているとDMAは全く使用してないFIFOポーリングで
読み書きを行っていることが分かりましたがHALライブラリにはDMAを使用する
関数も用意されていてほんの少しの改修でDMA化できるので試してみました
が…！
なん…だと…！？
つづく！
近畿自然歩道を徃く(大峯奥駈道(のごく一部だけ)を徃く)
大峯奥駈道･･･それは宗教的にも極めて重要な過酷な修験道であり、昭和時代からは
幾多のハイカー/トレラン野郎が挑み踏走破してきた極めて過酷なトレイルである―――
そんなトレイルにごく一部だけですが私も挑みました！
2014年末はルート上の大天井ヶ岳周辺の降雪量にびびって高見山+三峰山のゆるふわに
変更しましたが2015年"度"はガンガン攻めてく覚悟は決めてますので･･･
雪解けの時期かつ山桜が丁度見ごろのこの時期を完全に見切って挑みました！
●2015.04.18 吉野〜洞川
大峯奥駈道は紀伊山地の霊場の一部でありますが今回私はそのさらに一部だけを攻略
することになります。ヤマレコの過去ログを漁るとなんとスタート地点の吉野から
熊野まで何日もぶっ通してかもしか山行された方もいるのですが、私は家庭の
事情で山行はすべて日帰り必須、100歩譲って現地へ前日移動しか許されて
いないので到底無理です。
さらに奥駈道は一部区間で宗教的理由により女性は通行不能なルートがあります。
しかしながら近畿自然歩道としてのルートは近鉄吉野駅から洞川バス停までで日帰りで
十分到達できる距離なので今回のベストコンディションで挑んだわけです。まだ山開き
前なので洞川発最終バスの時刻は15:55と結構タイトでありやはり綿密なタクティクスが
求められるルートでもあります。
(※今回のルートは支線扱いでルート案内は洞川付近にしかなく道標だけが便りです)
というわけでいざ出発！
奥駈道は吉野山中腹の金峯山寺を通過しますが近畿自然歩道は如意輪寺まで下道です。
車道が終わる頃に高度を一気に上げて如意輪寺まで登り始めます。
如意輪寺です。境内には後醍醐天皇稜もあります。
如意輪寺を抜けて駐車場に出ると大きな舗装路に出ます。
このあたりをよく観察すると･･･
花矢倉へ向かうトレイルがあります！
稚児松地蔵です。
日拝地蔵です。
ここは宮滝・津風呂湖ルートからのエントリポイントでもあります。
上千本あたりまでやってきました。ここで観光客たちと再び合流します。
花矢倉です。ここは満開の時期は撮影場所の争奪戦になる場所です。ですが
もう季節的には上千本でも桜は散ってしまっていました。
しかし、上千本のさらに奥地には･･･！？
吉野水分神社です。貴重な水の補給地でもあります。
境内に咲き残る桜と本殿に今回の山行の無事を祈り、いまだ未踏の地に向かいました！
少し進むと高城山分岐があります。
そして徐々にヤマサクラも見え始め･･･
金峯神社の鳥居とヤマサクラが見えてきました！
ここは吉野では最後に満開になる"奥千本"の入り口です。
桜に出迎えられつつ修行門をくぐり神社に向かいます。
神社のちょっと左奥にある源義経の隠れ塔です。
ここではペットボトルの自販機や茶店やトイレもあります。
金峯神社です。
ここでももうすぐ始まる過酷なトレイルの無事を祈りました。
舗装路は徐々に地道に変わっていきます。
看板に書いてあるように本来の近畿自然歩道である大天井ヶ岳の巻き道は
崩落して通行不可能なので登山者も修行僧も皆大天井ヶ岳山頂を経由する
事となります。
その前にちょっと寄り道･･･
吉野奥千本です。山奥に咲き乱れるヤマサクラが見事ですね♥
吉野の千本桜は実際は千本どころか一万本以上あり、現在も桜の植林が続けられて
います。ここ奥千本も絶賛植林中で私がここを訪れる何十年か後にはさらに桜で
埋め尽くされていることでしょう。
奥千本広場の奥にある西行庵です。
奥千本から少し離れた場所にある湧き水"苔清水"です。
寄り道ルートはここで最後の水の補給ができます。
絶対に補給を忘れないようにしましょう。
対面のビューポイントから見た奥千本です。
そのビューポイントにもヤマサクラが咲いています♥
かつてはこのあたりまで寺院があったそうです。
その寺院跡を抜けると宝塔院跡という小広場に行き当たります。
観光地はここで終わりです。後は厳しいトレイルが続く修行の山となります。
･･･が実はねむいさんここに来るまでに外国人観光客たちに至る場所で道を聞かれまくり
足止めをくらいまくってました。多分合計40分くらいロスしたと思います･･･。ねむいさん
英語はぜんっぜん駄目なので"Excuse me？"と呼び止められるたびにしどろもどろでとに
かく思いつく単語ならべて難を逃れてきたのですがこの宝塔院跡でも勘違いして私の
後を付いてこようとした人たちに"ここから先は観光地じゃない"っていう意思を伝える
までに約10分くらいかかったのですがすっかり稲中の井沢さんみたく真っ白になって
しまいましたorz
私たちが棲んでる西院でも八坂神社/祇園方面に行こうとして河原町あたりからから八坂
神社と逆方向にはるばる進んでくる人たちにたまに遭遇するのですが英語ですらアレ
なのに北京語とかハングルで必死の形相で地図とかスマホの画面ﾊﾞｼﾊﾞｼたたきながら
大声でまくし立てられても路上強盗にしか見えないからマジやまてくだち(日本語で)！！！
すみません取り乱しました･･･宝塔院跡から先はトレイル区間となり林道や山道の連続
となります。ねむいさんは途中でまたまた寄り道していきました。
青根ヶ峰の山頂です。
ほんのちょっとの寄り道なのであっという間にさっきの林道と落ち合います。
その林道は奥千本から続いていたアスファルト舗装路と合流します。
合流点の駐車場には石碑ときれいなヤマサクラがあり、写真をアップで
取り巻くってしまいました。
さてその舗装路を少し歩くとまたトレイルに押し込められます。
と見せかけてまた舗装路に戻ってきますが。
黒滝村の境を越えてちょっとあとに黒滝村への分岐があります。
ここはバリケードしてある部分を越えてさらに進みます！
さらに舗装路を進んでいくとさりげなく脇のトレイルにいざなわれます。
ここからが本当に超過酷な山道の始まりなのです！
入ってすぐにオオスズメバチの巣と思われる羽音のする穴があって全速力で駆け上が
ったせいでもう息切れしてしまいましたorz
ちょっと平らになったここは心見茶屋跡だそうです。
そして情け容赦の無い異常な傾斜の登り！
ここで私は人間を捨てて大雨の寧比曽岳で使った以来の四足獣歩行姿勢ですいすい
クリアしていこうとしたのですがいいタイミングで対面から人が降りてきて超恥ずか
しい思いをするﾊﾒにorz
そんなことはどうでもいいのです！
ちなみにさっきのトレイルの始まりから"KOBO-TRAIL"なる道しるべが散見されます。
これは文字通り弘法大師の道をたどる山岳マラソン大会の道しるべだそうです。
大天井ヶ岳頂上までこの目印がどう進めばよいかをサポートしてくれます。
そんなこと考えてる間に視界が開けてきましたよぅ〜
本日第一の難関、四方岩山頂上です。
やったぜ
バスの時間が早くも気になるので長居は無用、次の目的地へ向かいます！
行者さんが使用される足摺の宿です。
ご覧の通り建物の中を通過します。
そっから先は打って変わって快適なトレイルに！♥
またまた舗装路と落ち合います。
ここは百丁口と呼ばれる広場となっています。
そこから程なくして百丁茶屋跡/ニ蔵宿です。
ちょっとここで昼食をかねて小休止しました。
さて、前途の通り本来の近畿自然歩道は崩落していて先に進めないので大天井ヶ岳の
頂上を経由することになります。これでもかってて言うくらい大天井ヶ岳へ誘導しようと
してますね〜私ももちろん大天井ヶ岳に挑戦します！
ﾊｧﾊｧ･･･四方岩山の時よりきつかった･･･
でも何とか尾根に出られましたよぅ
尾根道はなだらかです。
途中で作業用モノレールと落ち合います
大天井茶屋跡の広場で体制を整え、次に待ち受ける急登りの力を溜めます！
ぬぅぉぉぉぉあと一息だ！･･･と安全な場所に手や足を掛けて登りあがったらうっかり
頂上より東側に出てしまったのがわかり軌道修正･･･
大天井ヶ岳頂上です！東海自然歩道の姫次以来の私が登った山の最高点更新です！
やったぜ
頂上から離れ、あとは尾根に沿って五番関にむかってひたすら下っていきます。
五番関手前の広場に降りてきました。
ココには大天井ヶ岳の巻き道は通行できないという警告看板があります。
五番関です。ここから山上が岳までは"男の世界"で女子禁制なのです。
それを快しとしない者が注意看板に落書きしたり五番関の門を一部破壊したり
しています･･･！こういうことする奴はtntn付いてても付いてなくても山に登る
資格は無いですYO！！！
･･･と一通り憤ったあとは脇の近畿自然歩道の道標に沿って一気に下ります。
五番関トンネルの手前にやってきました。
こっからはまた舗装路となります。
ぬぉぉ！！
走る走る(なんかこのあたりでルートミスしてたようです)
洞川地区は和漢胃腸薬 陀羅尼助丸の看板や商店が至る場所にあります。
さらに進むと山上が岳/稲村が岳への最前線基地の母公堂にたどり着きます。
ここできれいな水が補給できます♥
そこからすこし進んだ先にまたまたきれいな水が流れるごろごろ水なる名水が
あります。しかしココは採水禁止で飲んだらお腹ｺﾞﾛｺﾞﾛ水
･･すみませんだじゃれです///
そして同時にようやくルートミスに気付き山上川沿いへ進路を変えます！
時折現れる行場を見ながら山上側の美しい渓谷を何度もクロスしていきます。
ここで面不動鍾乳洞方面に進路をとります。
森を抜けると洞川の集落のはずれに出ます･･･がすぐにまた山に向かいます。
大原山の頂上を目指すのですが･･･なにやらやばい雰囲気･･･
なんとごらんのとおり頂上へは通行不可能となっていました！！
そんなわけで大原山はなかったことにして下りに転じたトレイルを駆け下ります！
しかし･･･
やばい･･吊橋だ･･･
あぁあぁあぁぁぁっぁああああ(吊橋恐怖症)
ひェェェえええぇええい★(吊橋恐怖症)
イぇえええぇエエｪｴｴえええぃ♥(吊橋恐怖症)
吊橋を越えた先も細かく上り下りがあり私の足を苦しめます･･･。
面不動鍾乳洞の分岐までやってきました！
つい数時間前まで激闘してきた大峯奥駈道は中央奥の遠くに見えます･･･
てか五番関からここまでが結構長く感じました。
ちなみにここは入場料かかりますので時間も押してるので鍾乳洞はスルーで･･･
最後にもう一度、大峯奥駈道と洞川の町並みをとらえてから洞川の中心部へと
降りました。
洞川八幡宮まで降りてきました。
ここで近畿自然歩道のルートはゴール地点なのですがほんの少し時間ができたので
竜泉寺に寄りました。
竜泉寺です。ここでも満開の桜が歓迎してくれました♥
境内には小川や池があり、どれも鏡のように透き通ったきれいな水をしています。
悔いが無いように今年最後の桜を写真に納めてきました！
竜泉寺を離れ、今度こそゴールに向かいます。
洞川の南には洞川温泉があります。
残念ながら今回はバスの最終時刻もあいまって洞川温泉に入るまでの時間は
取れませんでした。次回ココに来たときにでもりべんぢします！
てわけで今回のゴールである洞川温泉バス停に到着です。
いろいろありましたが帰り支度する最低限の時間的余裕を残して
到着できました！
バスに揺られること一時間、近鉄下市口駅に到着です･･･
バスはココが終点ではないので転寝すらできず気を抜くことはできません･･･！
下市口からは近鉄特急で･･･
こちらも京都行きの乗換えがある橿原神宮前までは一切気が抜けません！
･･･もちろん無事乗り換えも済み、そっから先は終点の京都まで爆眠でしたZzz･･･
というわけで大きなトラブルもなく、ほぼ予定通りに近畿自然歩道の最難関といわれる
コースをクリアすることができました。気温が高くならず雪もほとんど無く人もまばらな
この時期に行くのがやはりベストです。至る場所で桜も堪能できますし☆
しかしながら今回は時間の都合で温泉には入れなかったので天川川合経由の近畿自然歩道
を攻める時には必ずや入りたいと思います！お風呂セットは忘れません！
近畿自然歩道(吉野〜洞川） GPSログ
中華Bluetoothなアレを試す
みなさまあけましておめでとうございます。
今年も当ぶろぐと私たち虹裏メイドをよろしくお願いいたします。
ぶろぐのメインコンテンツが自然歩道/低山ハイクにシフトして電子工作関連で
訪れる人もほとんどいなくなって久しくなりましたが、過去に提供した情報に
つきましては後から見に来てくれた方を困らせたりすることがない様に正確性を
保ちつつ整備を続けていく所存ですのでご安心ください。
さらに、これから発信していく情報に関しても去年末の地図の件のように
ルール違反とならないようにしっかり精査をしたうえで提供していくよう
心がけたいと思います。ルールは守ってクリーンに行きますよぅ！
●中華Bluetoothなアレ一号機
そうだね
いきなりルール無視のダーティファイトだね。
勿論日本国内の技術基準適合証明なぞ取れてないので型名すら言うことができずアレ
呼ばわりです。使用に関しては副業先にある電磁波と音波と振動が完全遮断された
連続稼働試験室(別名お仕置き部屋)で実験の形で行っていますので間違っても
野外や窓際とかで使うようなルール違反なんかしてませんよぅオホホホ♥
↑建前
このアレはBluetoothのSPPが使える、つまりUARTを手軽に無線化できる
便利な代物です。しかも値段もいずれ紹介するアレよりも安いです。
しかしピン配置くらいしか情報がわからず最初は四苦八苦しました
…が何とか使い方を見出しました。
Bluetoothで有名なのはCSRのチップですがこれはBEKENなる大陸の中華製無線チップ
のようです。さらにそのチップから私のぶろぐでおなじみ台湾製cortex-M0の
NuvotonM051シリーズが繋がっています。
UARTの信号はこちらからやり取りを行います。
裏返すとご丁寧に信号名を振ってくれています。
実際に操作できると思われる信号はKEY/LEDとTxD/RxDくらいでした。しかも他の
SPPモジュールと違いI/O電圧が厳格でRxDにVCC(MAX3.3V)を超える電圧をかけると
動作が即座に停止しやがります###
M051自身はは5V駆動可能ですが5VトレラントI/Oではないのでこうなるようです。
モジュールから脚を引き出して汎用コネクタで差し替え可能にしておきます。
ねむいさん以前から少しずつ自作のワイヤレスモジュール接続用ハブを作ってきました。
中心部にはFTDIのFT232R基板がありこれはVCCIOとして5Vを突っ込んでいます。
てわけでTxDからは抵抗を介していますが5VCMOSレベルの信号が出ているので上記
モジュールを使うことが出来ず泣く泣く5VCMOS->3.3VLVCMOSへの電圧変換を挟みました。
また、KEYをHIにして電源を投入するとATコマンドモードになるそうですがデータ
シートがどこにも見当たらなかったのでコマンド探しの旅から始めました…。
ひとまず9600N81,CRLFありで基本の"AT"に反応しました。
"AT+VER"
"AT+BAUD"
も見つけました。ボーレートさえ変えられれば何とか使い物になります。ボーレート
の設定に関してはHC-06と似たような感じですね。しかしデバイス名やペアリングキー
の設定は一切できない男らしい仕様のようです。
PCからはこんな感じに認識されました。同じ奴何個も使う時名前変えられないので
混乱必須ですね。
ペアリングキーがないものの追加されたSPP-COMポートを開こうとするとこんな
ダイアログが出てきます。もしかして隠しで設定コマンドあるのかしら･･･。
それはさておき230400bpsでも余裕で使用できます。スレーブ専用・フロー制御無し
UARTとして使うと割り切れば十分に実用可能でしょう。マイコンの工作ではTxD,RxD
さえあれば問題ないですし。
そうやって格闘していたらひょんなことから同じモジュールを使用していると
思われるピン間隔変換基板に半田付けされたモジュールのモジュールを販売してる
ところを見つけました。
そこのデータシートを見る限りではやはりATコマンドはボーレートくらい
しかいじる項目がないと言う極めて男らしいブツでしたこれ。
･･･というわけで去年夏前くらいからBluetoothのSPPデバイスをはじめBLEにも
手を出していろいろためしてきてますのでこのような形で順次紹介していきたい
と思います。中華Bluetoothモジュールは中華TFT-LCD並みに魅力的なのですが
何度も言いますが日本の技術適合証明なんてあるわけないのでクリーンな
コンテンツを目指すねむいさんのぶろぐとしましては…おや？なんだこんな時間に…
年 始 早 々 こ ん な 内 容 で す み ま せ ん ！ ！
近畿自然歩道を徃く(高見山と三峰山に樹氷を求めて)
TG-3に買い替えてからトレラン主体の記事は今年一度も書いてないからせっかく
なので書かせてもらいますよぅ
近畿自然歩道が主体の内容も今回が初めてですね〜…あれ？何嫌嬉しそうな顔
してるの？でも今回は見ごたえがあるのでだまされたと思って見てってください！
っていうか見なさい！！！！！
近畿自然歩道は東海自然歩道の時とは違って他の人の参考になるような超地味な
攻略要素はなるべく省いて単純に魅せる内容で攻めてみますからだまされt(ry
●2014.12.27 高見山+三峰山ルート
朝の榛原駅。
ここは東吉野村や高台山脈に行くための前線基地です。
交通の便は皆無といっていいほどないのでマイカーがない人は敬遠するような
場所ですがねむいさんは"虹弦流・タクシーでずるっこ移動"をかまして直接
高見山登山口に行きました！
(※樹氷が見られる時期は樹氷バスなるものが運行されています)
東吉野村の高見山バス停に到着です。
ここに来るまでは道を邪魔するものは全くなく猛スピードでかっ飛ばすタクシーの
運ちゃんのハンドリングがワイルド過ぎてすでに心臓バクバクでウォームアップは
すでに完了です…
冬山なので防風と保温を兼ねて帯電防止エアキャップを体幹に巻いておきます。
これ軽くて体積もとらずなおかつ効果抜群なので冬場のトレランの必須アイテム
です！
それじゃ今年の走り納め行ってきます！
高見山登山口は伊勢南街道としばし道を同じくします。
途中で石畳もあったりします。
木々が開けた場所では雪を冠した高台山脈が。
私もすぐにその場所に行く！
途中道が崩れている個所もありましたが巻くことができます。
でもそろそろ道が雪と氷におおわれてきてやばいです。
小峠に到着です。ここから先は急な登りと堅い雪道になるので
トレラン用アイゼンを装着して挑みます！
…なんかクマ出るみたいですねここ…
小峠からは高度を上げていくたびに白色の支配率が上がっていきます。
その白色の正体は樹氷です！
平野登山口と合流して雪の登山道を登っていきます。
樹氷バスがでるのは一月上旬ですが、樹氷はすでに見ごろのようですね〜♥
夢中になって登っていると気づいた時にはあたり一面銀世界となっていました。
山頂付近は風も強いですが樹氷も成長して見ごろです。
撮影ポイントな場所はやっぱし人が結構いてねむいさんも撮影待ち…
山頂小屋はだいぶ人が入っていました。
樹氷バスが出るころは人多すぎで入ることすらできなくなるとのこと。
ねむいさんはちんたらしてたら三峰山にすらたどり着けないので
関係ないですがー！
高見山の山頂には高角神社があります。
えびのしっぽと呼ばれる樹氷がすごい伸びてるのが分かりますね〜
高見山からは直接尾根道経由で三峰山に出られますが近畿自然歩道をたどってるので
いったん下りることになります。標高差900m以上を2回登ることになるので東海自然歩道
の北丹沢より過酷なコースです。
TG-3のマクロ撮影機能を用いて撮った雪の華です。
わたしもTG-3をだいぶ使いこなせてきましたよ！
どんどん下っていくと急に視界が開けて高台山脈の山々が広がります。
思わず"おお…！"と声をあげてしまいました。
さらに下りると高見峠に行きつきます。ここでトイレ休憩です。
ここは気温は氷点下になっていないようですね。
そこから少し下りて和歌山街道のトレイルに入ります。
ある程度下って積雪が無くなってからアイゼン解除してさらに下る
スピードを上げます！
下って行く途中でかつての街道の史跡が見られました。
なんで蘇我入鹿がこんな辺鄙なところに…？？？
道は蘇我入鹿の首塚から先ですぐに舗装路になります。
高見山に見送られて国道166号線に降ります。…ここからが長い！
ようやく国道166号線に合流です。すでに次のターゲットの三峰山は見えています！
166号線をある程度下ったら波瀬の集落の旧和歌山街道を走ります。
三度166号線と合流して松阪方面にひたすら進みます。
途中で波瀬小学校(現波瀬ゆり館)があります。
166号線をひたすら下っていくと泰運寺への道が現れます。
今度は進路を北に変えて舗装された林道を上がります。
ひたすら登っていくと泰運寺の参道が出てきます。
舗装路でも本堂に行きつきます。
泰運寺本堂です。
泰運寺本堂からちょっと戻って月出の里への分岐に進路をとります。
結構きついピークを越えて不明瞭な下りを下りると民家の庭先に出てしまいます。
一応近畿自然歩道のルートですがこれ逆から来た場合ルートが完全に
わからないんじゃ…
そんなこと考えつつ川沿いに進んでいると月出の里案内所に行きつきます。
この一帯は民宿があるそうですが泊まる人とかいるのかしら…
営業してる気配が全くないみたいですし過去の元気だったころの日本の
遺物なのでしょうか…
(自然歩道のガイド情報ってたいてい20年くらい遅れてます)
…そんなこと考えつつ次の戦いの支度をします。そう、ここは高見山コースの
終点であり三峰山コースの起点でもあります！
月出の里から三峰山へはまず中央構造線へ向かう必要があります。
超巨大ゲートを力いっぱい押しあけたり不動尊にお祈りしたりと
結構イベンツがあります。
中央構造線(正式名称は月出中央構造線露頭部)に到着です。いわゆる超巨大
断層帯です。二つの異なる岩質がぶつかり合って常に崩壊してる場所ですが
かつては上まで行けたようですが崩壊しすぎてもう駄目みたいですね〜
ここからちょっと戻ってさらに林道を登ります。
三峰山登山口までやってきました。登る体力は必要十分にあります！
ちょっと休憩したのちアイゼンをすぐにつけられる状態にして挑みました！
新道峠までは急登です。しかもちょっと荒れてます。
幾多の難路を越えてきた今では"道が見える"状態ですが油断せず進みました。
稜線に出てすぐに新道峠です。
すでに積雪が高見山よりありました。ここから三峰山までひたすら
スノートレイルになります！
高見山と違ってちょっと樹氷が雑だな〜と思っていたのですが…
そんな思いはすぐに否定され…
三峰山でも樹氷が出迎えてくれました。
ちょうど晴れてくれたのでその隙を逃さず今回のベストショットをキメました！
その後すぐに曇り始め雪も降ってきました。
樹氷も頂上に近づくにつれさらに大きくなっていきます。
御杖村への分岐を越えたころには再び一面の銀世界。
そしてそれに導かれるように頂上まで駆け上がります！
三峰山山頂に危なげなく到着です！頂上は風雪が厳しかったですが、
展望が効く曽爾方面は雪雲に阻まれずよく視界がききました♥
今回の山行を強力にバックアップしてくれたTG-3さんも気温-3℃の環境で山頂と
ツーショットです。こういうタフな環境では本当にタフネスを発揮してくれます。
これからもよろしく〜
三峰山山頂からは緩やかな下りを少し進んで八丁平に行きつきます。
こちらも眺めが素晴らしいです♥
近畿自然歩道の福本登山口への道はちょっとわかりづらいので注意してください。
厳冬期だと道が完全に消えて迷うかも。
八丁平から下りるときに撮影した一枚。日の光が高台山脈に綺麗に当たって
またもや"おお…!"と声をあげてしまいましたよ。
八丁平から先は急降下です。アイゼン外すタイミングがつかめない…
ひたすら下っていくと眼下に林道が見えてきました。
トレイルもあと少し！
福本登山口に到着です。手に持っていたアイゼンをザックにしまい
駆け下りられる体勢になります。
あとはひたすら山間部にある舗装路を下ります！！
うりゃー！
River Deep,Mountain High.
山の向こうに落ちた太陽に代わって月が輝きを増してきます。
これは…まるで…！
もうじき残照も消える。
この時期は日が落ちるのが本当に早い。
山間部ならなおさらそれを強く感じます。
国道166号線と合流する地点で近畿自然歩道の三峰山ルート起点に行きつきます。
ゴールはもう少し南です。
ゴールの富永バス停です。
到着時刻は17:14。最終バスは17:29ですがこれを逃すと和歌山街道の山の中に
一人取り残されて身動きとれなくなるという別の意味で恐ろしい難関なコース
です。おそらく近畿自然歩道一の難しいコースかと。
バスが松阪駅について特急乗る時もドタバタでしたが…、
そして電車が走り出したとたんに緊張の糸が切れて眠りこんでしまい、
危うく上本町まで行ってしまいそうになったり最後まで気が抜けません
でしたがなんとか攻略できました。
そんなわけで2014年の初走りに負けないくらい過酷なコースで今年も〆ましたが
このぶろぐ記事書いてる今ようやく筋肉痛が解けたので、綺麗な体(?)で新年を
迎えられそうです。近畿自然歩道は東海自然歩道ほど一度の距離は少ないですが
道標がない、整備がない、そのそも道がないと意外と難しい印象です。
この一年和泉山系を中心にかなり攻めたつもりですがまだ全体10分の1も攻略
していないのでほんとにライフワークになりそうです。
来年も果敢に挑んでいきたいと思います。
近畿自然歩道(高見山＋三峰山） GPSログ
今年のぶろぐこれで終わりじゃないですからもう少し耐えてください！！！
GPS/GNSSモジュールを試用する13 -OLYMPUS STYLUS TG-3 Toughを使う-
今を遡ること2か月前に購入したOLIMPUS製のSTLYLUS TG-3 Toughを
今更紹介します。
ねむいさん従来からCANON派で1年くらいのスパンでデジカメを使いつぶして
きましたが今回からとある機能に惹かれてOLYMPUSに乗り換えました。
(直前まで使用していたIXY-3は永眠いたしました…)
タフでぢかめの現時点の最高峰と言われるTG-3はこれでもかと言わんばかりに
たくさん機能が盛り込まれております。
ねむいさん的にはフィールドでバリバリ使うための防水防塵機能に加えて
マクロ撮影にものすごく強い所に惹かれました。しかも被写界深度合成まで
対応しています！この機能は面実装部品やFPCのパタンの撮影にものすごく
適していて視覚的解析の強力な武器となります(実際に副業先でもバリバリ
使っております！)。実際の使用例をしめします。
こちらはAliexpressで購入したMVA-TFT-LCDです。コントローラICがLGDP4551で
あるという情報以外は手に入りませんでした。まぁよくあることです。
しかしTFTにつながるFPCのパタンとコントローラICの足配置からマイコンとどう
つなげばよいのかの解析が可能です。肝はFPCの足の目視による解析ですがここで
TG-3のマクロ撮影機能が生きてきます。
まずは通常のマクロ撮影(顕微鏡モード)で撮影です。
お次は深度合成モードです。マクロ撮影ではぼけてしまう画面端にも
フォーカスが決まってるのがわかると思います。
画像解析でらくらくピン配置を特定し、危なげなく動作せしめることが
できました♥
こちらは2012年に購入して同じようにFPCの足を解析して動作させていた
TFT-LCDですが、同じ箇所をTG-3で取り直して比較してみましょう。
こちらはCANONのIXY-3のマクロ機能で撮影したFPCのパタンです。
寄れるのはこれが限界です。この状態で何とか解析しました。
こちらはTG-3です。もうダンチですね♥
TG-3にはレンズに拡張機能があってLED光源をマクロ撮影用に拡散できる
アダプタが取り付け可能で今回の撮影に使用しております。
せっかくなので動かしたところを(IXY-3を使った時の写真です)。
ぇ？FPCコネクタがおかしくなってるって？
ずらして挿入いいよね…よくないですけど！(IXY-3を使った時の写真です)。
…
さて、本題に入ります。このTG-3には当然のごとくGPSレシーバーが仕込まれて
います。しかも説明書にはQZSS/GLONASS対応とうたっております。これは性能
比較をせざるを得ないでしょう！
今回はTG-3のGPS機能のカタログ値が見当たらないのでカタログスペックの
比較ができないことをご了承ください。
●近畿自然歩道(孝子〜四国山〜加太)
おいそこページ閉じるな!
近畿自然歩道シリーズ第三弾は大阪と和歌山の境目を縫って海に向かうルートです！
ちなみにこの日の天気は曇りのち大雨、台風11号がまさに襲来しようとしている時に
向かいました。ねむいさんはもう雨中の山行とか慣れっこなので(でも死の危険を
感じた時はさすがに途中撤退してます)お構いなしに向かいます！！！！
OLUMPUSのでぢかめは分秒単位の書き込みができないので時刻の挿入はDatePlusを
利用させてもらっています。
冒頭の写真です。TG-3にはコンバータアダプタをつけてさらにレンズ保護を兼ねた
サーキュラーPLフィルタを装備しております。今回はSTM32Primer2+Gms-G9との
ログ精度対決となります。
ではスタート！低山だし海沿いだし楽勝だろうと思ってましたが…
このルートは近畿自然歩道の道標がゼロなので地元の有志の方たちが建てた道標と
先達の方々のレポートを頼りに進みます。公式のは役立たずです＃＃
サクサク駆け上がって犬飼谷峠です。
この辺りでは空にまだ晴れ間が広がっていました。
峠を降りて林を抜けると激藪がお出迎えですorz
去年の恐怖がよみがえる…
猛烈な藪に阻まれて本当に正しいルートがよくわからなくなってしまいそう
ですがTG-3にはもう一つの強力機能デジタルコンパスがあります。
infoボタンを数回押せば電源OFF時でも呼び出せられるので手間はかかりません。
地図と照らし合わせぐんぐん藪に果敢に突入します！
地盤が白くなってシダが目立ってきました
白砂峠です。ねむいさん序盤のこの時点ですでにクモの巣と泥だらけですorzしかも
汗びちゃびちゃ///
でもTG-3は防水防塵なのでへっちゃらなのです！
進行方向左手になんかのゴルフ場が見えました。
クモの巣があまりにもひどいので枝がたくさんある枯れ木を拾ってクモの巣ガードに
して突っ切る作戦にしました。で、そのクモの巣ガードについてたクモさんをマクロ
撮影。これ女郎蜘蛛ぽくないけど何て名前のクモさんなんでしょか…
すっかり小汚い格好になった頃にようやく車道に出ました。ここからは打って変わって
車道走りになります。
府道751号線をさらに進みます…が途中で画像奥に見える八王子社によりました。
その参道にあるきのこをマクロ撮影。
さらに深度合成モードで。本領発揮ですね★
府道を登って峠っぽい所を越えるとほどなくして甲山の登山道分岐につきます。
甲山頂上はすぐに到着します。わずかに友ヶ島がみえてきました！
しかし天気はどんどん悪くなる一方…急がねば
甲山を離れ舗装路をどんどん下っていくと佐瀬川バス停につきます。
そしてこっからがこのルートの最難関です！
はい。
道標も何もありませんがこれが正規のルートだそうです＃
あぜ道に入っていくと竹林になりますさらにそれを進むとなんかバリケードされて
ました…よく見るとすぐ先に電流柵が…この配置はハイカー狩りか…
※正規のルートです
無理やり尾根に上がると視界が開けました。
ここで進路を180度反転します。ここも方角が錯覚しやすい危険ポイントですが
TG-3のデジタルコンパス機能で迷わず進めました。
今度は不法投棄の森…
ほとんど道なき道と化した道を進んでいると謎の仏像が…
誰もこの道を通らないだろうに…
そしてその仏像の先は完全に道が消失…
どうしようもないので石柱のある所から登って車道に上がりました。
ようやく難関を越えました。
車道を下っていくと四国山への登山道分岐があり次はそこを登ります。
さっきの難関とは比べ物にならないくらい楽に四国山山頂に到着です。
しかし天気は予断を許さないので先を急ぎます。
次は高森山を目指します。
だんだん藪と蜘蛛の巣が目立ってきました。ねむいさんは序盤で装備した
蜘蛛の巣ガードで振り払いながら進みました！
藪にまみれた大川分岐です。ここを降りると由良要塞の跡がいくつか見られます。
ちなみにこの加太地区一帯が要塞だったそうです。
高森山です。
そろそろ雨降りそうな気配…
高森山から少し戻り加太への分岐を進みます。
秋の丘です。藪もようやく落ち着いてきました。
道なりに降りて行くと車道に行き当たりました。
阿振川沿いに進めば加太につくのですが…ここで油断してコンパスと地図で
方向を確認せず南進してしまったため痛恨のルートミス！
謎のｻｳﾙｽたち…なんなんだチミたちは
ようやくここでルートミスと気付くorz
畜生ッｯ有田(写真右上)め！
仕方がないのでいったん南海加太駅に向かいます。
加太駅です。今は通過しますがここに帰ってきます。
車道を走りあがり深山砲台跡に向かいます。
途中で見えた荒れ狂う海岸には命知らずのサーファーたちが…
深山バス停です。ようやく正規ルートに合流。
さらに登って休暇村加太方面に向かいます。
途中に"歩道入口"があります。この中に入ります。
一歩足を踏み込むと一気に暗くなりましたよ・・
駆けあげっていくと砲台跡につきました。
まだ日は沈んでないはずですが真っ暗だったのでナイトショットを駆使して
撮影しております。
もともとこの砲台群は紀淡海峡を通る敵船を狙うために設置された砲台だそうですが
一度も使わず解体されたそうです。この戦争遺跡は加太や友ヶ島にたくさんあります。
分厚い雲のおかげで真っ暗けですが友ヶ島です。
台風がどんどん迫ってきてます。
ポツポツと雨が出てきました。落ち着いてなおかつ急ぎます！
車道に戻ってきました。
あとは加太駅に戻るだけです！
信じられん…こんな真夏に…しかも風も強くなって立ち止まると寒いし…
海岸沿いを進みます。荒々しい波が容赦なくたたきつける！
ってのんきにサーフィンしてるー！？
さらに海岸線に沿って進みます。
当たり前ですが海水浴場は誰もいません。
加太駅に着く前にもう一つ…！淡嶋神社によります。
そしてここには
ゼERO
じゃなくて人形が祀られている神社です。
境内に所狭しと市松人形や日本人形が飾られて？います。
時間的に行けないのですがこの奥にも数多くの人形があります。
神社の横手から海に出られるのですがご覧の通り完全に荒れ狂ってます。
この辺りは完全に外海になのですさまじいことになってますね〜。
台風はもうそこまで来ているのです！
それでも人形たちは海に面したこの神社で静かに佇んでいます…
風も雨もやばくなってきたのでここで神社を後にしました。
おっ！ちょっと雨が弱まった！ラストスパートDA!
南海加太駅に到着後ほどなくして本格的な暴風雨になってしまいました。
まさにタッチの差ででした…！
今気付いたけどGP-102+のモード表記のところ…///ﾔﾀﾞﾓｳ
まぁそんなどうでもいいことは置いといて和歌山市駅に戻ります。
電車はまだ問題なく時間通りに運行していました。
疲労もたまってたせいもあって真夏に震えるくらい寒くなってきました…
特急待ちの時間に南海そばに立ち寄ってスペシャルそばで体力回復です★
帰りはサザンプレミアムですよ！
そして京都に帰…って次の日の朝に気付いたのですがこの日は昼から京都市街に
集中豪雨が降って水浸しになってたそうです…ひどい夏ですね…。
おっとすみません肝心のGPSの軌跡比較はこのようになりました。
TG-3といえども"専門職"のGPSモジュールさんにはちょっと及ばないようですね〜
おそらくTG-3にはこのモジュール相当のものが搭載されてそうですね。
ヤマレコでも書きましたがGPSのロギングをしてると電源OFF時にシャット
ダウン処理がかなりもたつきます。トレランだとそのもたつきがかなり気に
なるのでやはり専用のGPSロガーの携行は必須だと思います。
TG-3のGPS機能はもっぱら時刻合わせと現在位置把握程度にとどめておく事を
お勧めします。
ところで6月末の出た直後に即効買った癖に何で今頃レビューしてるかと
いうと即効修理送りにしてしまって修理から帰って来てからは大事に大事に
大事に使用していたからです…。最高性能なタフデジカメすら私が使うと
微妙にめんどくさいことに…でぢかめに限らずSTM32とかもねむいさんが
使うと微妙な性能に見えますがホントはもっとすごいのですよぅ！
とにもかくにもデジカメも本腰入れるとカメラ沼にはまって抜け出せなく
なるので私としては悩ましい所です。
すでにかなりアクセサリに散財してしまいましたがー！
WVGAな解像度のTFT-LCDモジュールを動かす
私が最初にTFT-LCDに手を染めてからはや4年…もう４年も経っｔグハッ
すみませんいきなり自爆しそうになりましたが時代の趨勢は大解像度化の
一途を辿っております。電子工作で使用されるTFT-LCDも例外ではなく
STM32F4等の高速・大規模なマイコンではもはや320x480(HVGA)な解像度は
当たり前となっていますね。
それ以上の解像度の物は配線や駆動が面倒なRGBインターフェースの物しか
なかったのですが2013年代後半からまた状況が変わります。
なんと480x800(WVGA)なTFT-LCDモジュールでも従来のi8080バス形式で
使用出来るものが一般にも出回り始め、私も幾つか入手したのでまとめて
動かしてみることにしました。
●TFT-LCDのバックライト用LEDの話
かつて大解像度/大型のTFT-LCDモジュールにはバックライトに冷陰極管が
用いられていました。しかし白色LEDの高性能化により冷陰極管にとって代わり、
モジュール全体の大幅な薄型化に貢献しております。また、点灯に必要な
電圧も冷陰極管と比べて極めて低いので感電の危険も無く安全に工作が
行える利点もあります。
とはいえ大きな範囲を均一に照らすためにはLEDを複数個配置しなければ
ならず、ムラなくLEDを点灯せしめるためには各LEDになるべく均一に電流を
流してやる必要が生じます。そういった点から大型/大解像度のTFT-LCD
モジュールではLEDが直列に配置されている(=全てのLEDに等しい電流を
流すことができる)物がほとんどでこの場合はLED駆動用の昇圧回路を組む
必要があります。
私が選んだ昇圧ICはオン・セミコンダクターのCAT4240という品種です。
これは4〜8個の直列LEDを点灯させるのに最適で、回路構成次第で大電流
駆動可能です。後で紹介するWVGAなTFT-LCDたちに使用されているLEDは、
6〜8個直列でLED全体のIfも20mAもあればいいので昇圧用コイルは電流容量の
低い小さいものが使えます。
ほぼデータシートに即して回路図を作成し、LED駆動用昇圧ユニットを
組んでみました。+3.3VからMAX+28Vまで昇圧可能なのでLED8連でも余裕で
対応できます♥回路中で使用されているパーツは昇圧IC以外は
同スペックの物が秋月で購入可能です。
●さぁ動かそう
先ずはこちらの5インチのTFT-LCDモジュールです。コントローラICは
NovatechのNT35510という品種です。インターフェースはi8080-16bitバス
なので私のいつものと同じように動作できるはずです。バックライトLEDは
8連直列なので上で組んだ昇圧ユニットを接続していざ電源投入！
…ぁぁ･･･
ああぁあああぁあぁぁあああぁあ！
保管の仕方が悪かったようで薄さも災いしLCDを割ってしまったようですorzorz
↑かろうじて映る部分で動作を確認しました…さぁ次です次！！！
お次は4.3インチなドライバICがOTM8009Aという品種のものです。
24bitインターフェースですがレジスタの設定は16bitかつRGB565の設定も
可能で従来どおりの16bitバスに極めて近いため特に苦労はありません。
こちらもLEDが直列の6個使いです。
※これはいないさんです。
WVGAになると表示できる範囲も大幅に増えて大きい画像表示するのに
便利ですね♥･･･あり？どしたのですかそんな顔して？
けなげに+3.3Vから+18V近くまで昇圧を続けるCAT4240さん。コイルもCAT4240も
まったく熱くなっていないのでまだ余裕がありますね。ただし昇圧に使用する
+3.3Vの供給源は1A程度ひり出せられるくらいの余裕は持たせておいてください。
最後に4.3インチでIPSなTFTです。ドライバICはHX8369-Aです。こちらは
解像度以外は従来のHX8357系とまったく変わらず。一番使いやすく感じました
(動かしてしまえばあとはどれもほとんど変わりませんが)。
Aliexpressでも購入できます。
※これはほむらちゃんではなくいないさんです。
※こ(ry
IPSなのでデジカメでとっても青っぽくならず発色がかなりよいですね〜
幾つか動かして思い知りましたがさすがにバラックでLED用昇圧回路込のボード
組むのは辛いので最初は面倒でも専用の基板起こした方がいいかもしれませんね。
言い忘れていましたが今回のWVGAなTFT-LCDモジュールの駆動に用いたのは
おなじみのSTM32F4のいつものです。
すでにソースコードに反映していますのでこれらのモジュールを手に入れて
いても攻めあぐねている方の参考になるかと思います。
今後も良い物が入手できたらラインナップにどんどん加えていくつもりです。
STM32F0版Nucleo(Nucleo F030R8)を使ってドットマトリクスI2C液晶を動かすその2
かなり間が開いてしまいましたがねむいさんが膝の治療をしてるうちに
世間はまた大きく変わり、秋月さんからついにF4版Nucleoが発売される
運びになりました。ねむいさんの狙いはF073系のボードなので手元の
ボードを消化しつつ様子見です。
さて、今回の記事は前回の続きです。以前はF0版Nucleoを使って
GPIOによるソフトウエアI2C制御にて某I2C液晶を動かし茶を濁していました。
が、今回はSTM32F0のハードウエアI2C機能を使用して同じことを行います。
しかしながら前回述べたとおりF0,F3系の物はI2Cモジュールの世代が進んでいて
以前と同じソフトウエアは利用できなくなっています。大きな違いはスタート/
ストップコンディションが自動で発行できるようになったこと、SDA,SCLに
アナログ+デジタルフィルタが追加されたことそしてSCLの周波数が直感的に
設定できなくなったことです。
SCLのクロック設定はSTのサイトから落とせるI2C_Timing_Configuration
なる物を使用して得られた謎の16進数をtimingsレジスタに書き込まないと
いけなくなりました。余計なことするなー!
とはいえ一度設定すると後から変えるような場所ではないですから…まあ
許容できる範囲だと私は思います。どうせ潰しが効く100kHzでしか
使わないですし！
20230905追:
STM32F0~H5まで使える汎用のI2C計算作りました！
20230905追:
F1/F4系のソフトとあわせるために結構苦労しましたが最終的にうまく動く
組み合わせを見つけて無事F0系でもハードウエアI2Cをしようできるように
なりました♥(写真ではハード/ソフトの見分けはつきませんが･･･)
おきぱのI2Cドットマトリクス液晶動作サンプルはすでに
差し替えてあります。実は4月頭にすでにハードウエアI2C版を作りこんでました。
もちろん液晶だけではなく前回動作させたI2C温度計もばっちり動きます♥
ちなみに私のサンプルを見て変なことやってるのに気づいた人も居ると思います。
わざとドットマトリクス液晶とI2C温度計ほかI2CデバイスのHALの部分を分けて
います。こんなことやった理由は今回使用したI2C接続の液晶以外にSPI接続の
ドットマトリクス液晶を接続せしめることを見据えているためです。TFT-LCDでは
すでに実践している手法ですがこちらも次回以降に紹介して行く予定です。
ついでの話ですがOpenOCDもついにV0.8.0が正式にリリースとなりました！
公式のページには新たに追加された主な機能の紹介があります。その中で私も
フラッシュドライバ周りでいくつか貢献しました。下の画像で黄色で
強調している箇所が私が手がけた部分になります♥
特にKinetis系のサポートは今後のFreeScale公式のツールにもとりこまれる
程の影響力でねむいさんも顔のパーツを真ん中に寄せて地獄のミサワみたいに
得意げになりたい･･･ところ で す が ！上の画像に赤で注釈書いて
あるように、以前ねむいさんが実装したNuvotonのCortex-M0向けのフラッシュ
ドライバがtfreakﾘﾝｻﾝの勘違いにより無関係のNUC910系のサポートと記されて
しまい、V0.9.0リリースに向けて早くも釈明と大変更のプランを練っている
次第でございますorz
これ以前からずっと言及してきましたがマジでどうしましょうね･･･
幸いにもOpenOCDのNuvotonドライバ自身が全世界探しても私しか使ってない
状態なのでまだ被害が一切出てないのが救いですが(呑気)
あ、すみません最後までブログ書いてて気づきましたがNucleoの話に戻りますが
同ボード上に搭載されているST-Link/V2-1用のファームウェアが
更新されています。デバッガとVCP同時使用やそのほかの安定性がかなり
改善されていますので必ず更新してください。以前のSTLink/V2系の
ファームアップも同じアップデータで可能です。
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領域にあたる)を一旦ゼロクリアしてから
表示を行うようにしてバグを潰しております。
以前は変なゴミデータが表示されていましたが…、
修正後はこんな感じにすっきりです★
いろいろ試す20…という名の今年の反省会
今年もいろいろありましたが私としてはやってることはほとんど変わらず
山走りとかに行ったりLチカを極めるべく研究したりOpenOCDのエンバグ
とかです。
特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDの
プロジェクトに対してパッチを提出する形で能動的に参加したことでしょうか。
言葉の壁はもちろんありますが何度もこなしていくうちにある程度分かって
きますので皆様もオワコンとか言わずにどんどん参加してほしいと思います。
●マイコン向けの最強最後のTFT-LCDをゲッツか
i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)・ILI9486L・超広野角・3.8inch・抵抗膜式タッチパネル
付と至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。
以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。
●GCC ARM Embedded in Launchpadがアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとリテ
ラルロードを極力movtに変えてバスの競合を避けパフォーマンスのアップを図ると
いわれるものです。ARM本家のこちらとこちらもご参照のこと。
"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはSTM32F4のいつものです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。
次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
これです！
また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのおぱn…いないさんのｲﾗｽﾂをサンプルとして計測結果をuSec単位で
こんな感じで表示しｔ
…ｹﾞﾌﾝｹﾞﾌﾌﾝ
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのBleeding-Edgeツール
チェインや役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。
↓とりあえず各条件の計測時間の羅列です
(※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
サイズが全般的に下がっております。)
libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte
LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
@@L1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496760 0 496760 79478 main.hex
***libjpeg
182341uSec
***libpng
168305uSec
@@L2222
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489144 0 489144 776b8 main.hex
***libjpeg
181903uSec
***libpng
168485uSec
@@L2222 (nano-lib)
(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 470620 0 470620 72e5c main.hex
***libjpeg
194318uSec
***libpng
234706uSec
@@L3333
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496752 0 496752 79470 main.hex
***libjpeg
182345uSec
***libpng
168311uSec
@@L4444
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489136 0 489136 776b0 main.hex
***libjpeg
181925uSec
***libpng
168588uSec
@@L5555
(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496152 0 496152 79218 main.hex
***libjpeg
186999uSec
***libpng
168740uSec
@@L6666
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 488592 0 488592 77490 main.hex
***libjpeg
187095uSec
***libpng
168490uSec
BLEEDING-EDGE
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-130810) 4.7.4 20130613 (prerelease)
@@B1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555460 0 555460 879c4 main.hex
***libjpeg
183801uSec
***libpng
170161uSec
@@B2222
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555436 0 555436 879ac main.hex
***libjpeg
183797uSec
***libpng
170156uSec
@@B3333
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 553492 0 553492 87214 main.hex
***libjpeg
187582uSec
***libpng
170098uSec
SOURCERY CODEBENCH
arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1
@@S1111
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 504568 0 504568 7b2f8 main.hex
***libjpeg
184072uSec
***libpng
203915uSec
@@L2222
(Using newlib) -Ofast -msoft-float
=== Total Binary Size ===
text data bss dec hex filename
0 504040 0 504040 879c4 main.hex
***libjpeg
186811uSec
***libpng
203920uSec
かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
おきぱにて公開してるいつものはつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに
書いてたの気づきましたすみませんorzちゃんと修正しました。
"-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。
またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的な
パフォーマンスが低下することが分かりました。libjpegもlibpngもmallocを使用
するので、そこにパフォーマンスの違いが現れていると思われます。
作成するアプリケーションの目的に応じて使い分けるのがよいでしょう。
次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。
さらにLaunchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)
ので、もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなく
なりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。
すぐにだっ！
●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。
Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:長き戦いよ、さらば！
ていうかちゃんとぐぐりなさいよー！
Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください。
USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ！
Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
何ちゃら"は何らかのシンクロニシティなのでしょうか…？？？
Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
言いたいのかよくわからないので
A:私もそう思う。
特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…
Q:OpenOCDのWindowsバイナリは配布されておらず
A:ここが見えないのですかここが！！
Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
もしくはgpl.txtを1000000000000回音読して"利用者が全責任を負う"っていうこと
を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。
Q:ルネサA:帰れや！
Q:ギンギンに勃○してるのですが
A:ﾔﾀﾞﾓｳ///
Q:ギンギンに○起してるのですが
A:ﾔﾀﾞﾓｳ///
これデザインしたの私と同性の方でしょうか…？
本来のとは逆向きに付いてますし///
Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか？
A:これは重篤なサジェスト汚染ですね〜！
当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
てぃてぃを否定する検索が多数行われているのは絶対に許さ
力を。
Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
がクラッシュしてしまいました！！！１！！ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ！１！！ねむいさんは悪くないんですけぉ！１！！１
Q:ねむいさんはさんざモロはあかんといっときながらブログでモロを進めていたのは
どういうことなの？虹裏メイドだからって何か許された特別な人間だと思ってるの？
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
画像を赤と黄色を交互に放射状にした…いわばマケドニア国旗のような非常に目立
ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
のｸﾝﾆﾘﾝｻﾝにとって二次元裏のポリシーに反する目の上のタンコブだったのです。
紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
すべてに不許を貫いておりｸﾝﾆﾘﾝｻﾝに対する反逆とも呼べる行為を続けていました。
そしてある日ついに、ついに虹裏novはｸﾝﾆの怒りによってなんと板ごと御取り潰し
に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
息絶えたわけではありません。住人達はもといたimg,may,jun,decにとしあきとして、
｢｣として溶け込みつつもマジスタンスとして2014年になろうとする今現在も続く許
されざるビューティフル・ウォーを繰り広げているのでございます。
現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為はｸﾝﾆに対する
反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除・
アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
あたかも"(モロを貼れない)お前はチキンだ！チキン野郎だ！"と言わんばかりの
挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
てくれやがります。ですがあなたたちは紳士です！そのような挑発には決して乗っ
てはいけません！奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
向けているだけです！！１！もし挑発に負けて大人の男怒らせるなよオメーラと言
わんばかりに未加工の紳士画像を張り付けてしまったらゲーム・セットです。たち
どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
スターのアチャモにも｢あちゃ〜…もろ」と吐き捨てられ、仲間であったはずのスレ
ッド住人にdelを叩き込まれてとどめにｸﾝﾆﾘﾝｻﾝになーとアク禁を喰らうでしょう！
Q:東海自然歩道の静岡バイパイコースについて質問です。
玉露の里にかかる橋のマークはなかなかイカス植物ですね？
A:し…しらない…
気のせいでしょうﾊﾊ
Q:東海自然歩道の静岡バイパイコースについて質問です。
休暇村富士の玄関で栽培されてる葉っぱはなかなかイカス植物ですね？
A:し…しらない…
き、気のせいでしょうﾊﾊ
…
ー…そろそろ大掃除しますか…
それではみなさま、よいお年を〜
STM32F4シリーズを使ってみる9 - STM32F429I-Discovery準備編 -
STM32F429I-Discovery(製品名:STM32F429I-DISCO)、ようやく一般市場でも入手
しやすくなってきましたね。twitterのタイムライン見てると既に手に入れられた方、
使用されている方々の写真もびしばし上がってます。
私の方はというと…少数の方は更新に気づいていたとは思いますが、東海自然歩道へと
向かう前日の11/29にすでに既存のSTM32F4向けFatFs実装例に対応ボードの
一つとして基本部分を組み入れたソースコードを公開しております。
尤も429I-DiscoveryからはぢめてF4シリーズに触る奇特な人もいるかもしれないので
これがどういう物で何ができるか今一度軽く解説をさせていただきます。
※注意※
こことここを見て私のプロジェクトをビルド・デバッグ出来る環境拵えてることが
前提です！"意味が分からない"という方はご縁がなかったということで…
私のFatFs実装例(通称いつもの)は、ChaNさんのFatFsを中心に各マイコンの極めて
基本的な機能を網羅しています。STM32F4においては下に述べる機能を抑えています。
STM32F429I-Discoveryでも勿論使用しております。
1.GPIO操作
->LED点滅・SW入力
2.UART
->割り込みを使用したバッファリングされた送受信・stdioのリダイレクト
3.液晶モジュール
->MCUバスインターフェース(i8080,SPI,I2C)で駆動できる表示素子の操作
STM32F429I-DiscoveryはRGBインターフェースを使わずともSPI単体でも画像
データを送ることができます(遅いですが)。
4.FatFsのローレベル部の実装
->SPIやSDIO等とMMC/SDカードとのインターフェース。STM32F429I-Discovery
ではSPI4を使用しSPI互換モードでSD/MMCを動作させております。
5.外部RAMの制御
->STM32F407系はFSMCでSRAMを、STM32F429I-DiscoveryではFMCで
SDRAMを制御します。
んでもっていつものをSTM32F429I-Discoveryで動かしているところ
DMAの転送に使用される内蔵RAMが圧倒的に増加したので多少転送効率もよくなり、
その分ヒープ領域もたくさん取れるようになったのもうれしいです♥
画像はRAM馬鹿食いのgiflibを動かしてるところ
ファイラーの操作はタッチパネルより。STM32F429I-Discvoeryではコントローラに
内蔵のフィルタがあるSTMPE811が使用されているのでキャリブレーションも簡略化
しました。同基板ではVBATがVCC直結で外部にピンが出ておらずバックアップRAMが
機能しないので苦肉の策です…
タッチパネルからのファイラーの操作は上下でファイルポインタ移動、右で選択、
左でキャンセルと手抜ｋ直感的です！
前回述べていた基礎のとっかかりに関しては対応完了です。このプロジェクトではまだ
STM32F429I-Discoveryの機能のすべてを使いこなしてはいません。以下の項目は目下
実装中のSTM32F429にしか使えない機能です。
1.LCDCを使用したRGBインターフェースによる高速な表示
->前回はやっけつで急ごしらえしましたが過去の資産をなんとか生かせるように
作り変えてます…こちらはもうすぐ完了…。
2.FatFsのファイル読み書き先をSDカードからUSBメモリに
->これ結構作業量ががが
こちらに関しては先人の作例も数多くあるので参考にさせてもらってます。
せっかくUSB-OTGがあるのにSDカードばっか使っててもったいないですから自身
の学習がてらに実装がんばります！
そういうわけでSTM32F429I-Discoveryのフル機能を駆使した作例のほうは
もう少しお待ちください。過去のSTM32F407系の作例と完全に切り離して
STM32F429I-Discovery専用のプロジェクトとして公開する予定です。
おまけ
1年以上前に購入した699元全部載せSTM32F407基板もSTM32F427IIT6に
換装してパワーアップさせました。
実はずーーーーっとF427系のチップが出るの待っていたのです！
こっちはこっちでF407系の資産生かしてなおかつ強化する方向で遊んでいきます。
PARTYHARD!(見えづらいですが左上)
もいっこおまけ
STM32F42xxx&STM32F43xxx系をJTAGから見た場合バウンダリスキャンのTAPIDが
40x系と違うものになってるのでOpenOCDで書き込もうとするとコけます。
この修正はgerritに投げてますのでOpenCOD0.9.0あたりで反映されるはずです。
東海自然歩道を徃く24(朝霧高原-富士吉田/富士吉田-平野)
東海自然歩道のルートも残すところあと5つ(と一つ)ですね…高尾山に近づくにつれ
時間的・金銭的・体力的・技術的な難易度が跳ね上がっていくのを感じます。
今期は2013年内に決着を付けるつもりでラストの関東コースを挑みます！
●2013.11.01 朝霧高原->富士吉田
夜行バスの唯一の休憩地点、土山SAにて…
今回は50km近くの長丁場、しっかり食べておかないと…
…やっと富士宮についた…こっからさらに道の駅朝霧高原に…
この日は平日で早朝のバスはないのでタクシーで移動。
道の駅朝霧高原に到着。やっと車から解放された…。
そして朝食も済ませ足回りのテーピングを完全に施し…
い ざ 出 発 ！
国道139号線を跨ぎ、前回のエントリポイントに向かいます。
今回は70%以上が平地のトレイルで文字通りのトレイルランが出来そうです！
山道に係る川をジャンプで飛び越してふと上を見ると
根原のつり橋が見えました。
A沢貯水池という事務的な名称の池に沿って走ります。
その後すぐ山道です。
端足峠への分岐をかすめて県境に向けたトレイルを走ります！！
走る！走る！
東海自然トイレを過ぎてすぐの場所に県境である割石峠につきました。
約一年かかって静岡ステージを脱出です！
割石峠からは国道139号線への離脱が可能です。
ここから先は迷いやすい問題の山梨県。まずは本栖湖に向けて走ります！
この見るからに毒々しい草、マムシグサというどくどくでした…
迷いやすいといわれる山梨ステージですがこの時点ではまだ牙を剥いてません。
それどころか写真入りで矢印が示されてる箇所も…
本栖の部落へ向かう分岐から"本栖湖"へ進路をとり、県道709号線に落ち合います。
本栖湖に到着です。
駐車場と小さな売店、そして道路を挟んでトイレもありました。
ここでほんの少しだけ休憩。
しばらくの間本栖湖湖畔を走った後県道を横切り、ついに青木ヶ原原生林に突入
します！今はもう消滅した上九一色村の道案内は当時のままです。
国道139号線をアンダークロスして樹海をひた走ります！
ノンストップで走って走って精進湖民宿村まで出てきました。googlemapが出来た
当初に"森の中に謎の集落がある！"とちょっと話題になった場所ですね。
ちょっとルートから外れ精進湖入口も見てました。
さて本ルートに戻りさらに樹海を突き進みます。標高は高い場所ですが道は平たんで
非常に走りやすい場所です。この日は平日だったので他のハイカーも全くおらず一気に
かっ飛ばします。
ぅぉぉ！！
標高が高いのですでに紅葉も色づいていました。
走って走ってだいぶたったころに風穴に到着です。ここからもう少し進むと鳴沢氷穴
があります。
このあたり溶岩がでこぼこしてて晴れててもこけやすいです。
そしてこれまた有名な"めいわく自殺防止看板"を通り過ぎると…
鳴沢氷穴に到着です。ここで紅葉台に向かうための準備を兼ねて小休憩としました。
あの…貸した金返してもらうための相談とかは…
鳴沢氷穴を離れ紅葉台へ向かいます。この案内がある場所で139号線に出られます。
また、富士急バスのバス停も存在します。
紅葉台に到着です。鳴沢氷穴との標高差は100m程なのでここまでは大した登りでは
ありません。尤も1000m以上にある場所なので既に紅葉真っ盛りでした。
しかし…肝心の富士山はちょうどその部分だけ曇ってて全く見えませんでしたF**K!
紅葉台有料展望所を超えてお次は三湖台に向かいます。
三湖台です。先ほど通過した樹海や西湖を見渡すことができます。
三湖台を離れ、足和田山(五湖台)に向かいます。このあたりから登山道は林道と常に
併走するようになります。
木々の合間から西湖が見えます。
やがて林道と離れさらに急になった登りを超えると…
五胡台こと足和田山に到着します。残念ながら樹木が多く湖はあんまし見えません。
富士山はもちろん雲に完全にkk…F**K!
長居は無用なのでとっとこ下山しました。しかもず〜〜〜っと階段攻めorz
足和田山登山口(大田和入口)に下りてきました。たしか一本木登山口という名称の
はずでしたがゲートにあった名称を期したプレートが見当たりませんでした。
こっから先はひたすら車道を進みます…が迷いやすい山梨ステージの本性がついに
現れだしました…！ここは河口湖総合運動場へ行くのが正解です！大田和へ行くと
大きく迂回してしまいます。
このあたりで道を失って行ったり来たりorz
県道704まで出てしまい、大田和バス停方面にばくちで向かった途中でようやく道を
見つけましたよクソァ！！
国道139号を横切ってダートの道を突き進みます。
ここもトラップです！！無視して直進！！
で、直進すると四つ角にでるのですが直進ではなくなぜか道標が富士山頂方面へ
向かう太い道を差しているのですがここで大きい道を道標の示すまま直進してしまうと
ルートミス！！私のたどった軌跡を参考に迷わないようにしましょう！
そしてやっと見つけた道標…クソァ！！
その後も迷いまくって河口湖総合運動場の交差点にたどり着きました。
ここでクロスしている船津口登山道を国道139号線方面に下り漸くルートに戻りました
クソァ！！
ホテルレジーナ河口湖入口です。紅葉がきれいです♥
ここから剣丸尾溶岩流のトレイルを通り国道139号に近づきます。
富士スバルラインを横切り巨大な富士ビジターセンターに到着です。
日がだいぶ傾いてきたので休憩はせず水の補給だけしてすぐに出発です。
ここから先は国道139号線を延々と通過します。
富士急ハイランドを横目に139号線をひた走ります。
たぶんいつかきっとここに家族で遊びに来れると思います…
139号線から離れて北口本宮富士浅間神社に到着です。建物の修繕の真っ最中でした。
次回のルートの無事を祈ります。ここが次回のエントリポイントとなります。
東海自然歩道のルートと離れて富士急行線の富士山駅(旧富士吉田駅)へ向かいます。
途中の下り坂で最後の最後でようやく富士山を拝めました…じわわ。
空に暗がりが広がり始めたころに富士山駅に到着です。
東京から富士山に来るばあいこちらの山梨県側から来られる方が大半のようですね。
力のかけ方が尋常じゃないです…富士宮も頑張れ！
この写真を撮った時はまだ少し明るかったのですが、QSTAのトイレで
着替えを済ませて外に出るとすっかり暗くなってました。
お土産を買った後JR御殿場駅行きのバスに乗り込み帰路につきました。
●2013.11.15 富士吉田->平野
今回は京都から富士吉田まで約10時間のバス攻め…富士急ハイランドが見えたころ
には私のキュートなお尻は崩壊していた(←と言っても漏らしたわけではない)
富士山駅内でモスバーガーが営業していたので朝飯と足回りの準備を固めました。
ストレッチも十分に行いスタート！
北口本宮富士浅間神社に向かう国道137号は富士講の宿場町として栄えていました。
通勤ラッシュも終わり車の通りがゼロなのでこんな無茶なアングルで撮影もできます。
参道までやってきました。前回の道を手繰ります。
北口本宮富士浅間神社につきました。ここが前回からのエントリポイントとなります。
今回のルートの無事を祈りお参りしました。…と、ここでタッチの差で参道から大勢
の観光客が押し寄せてきました。
他の方のレポートでは国道138号線を迂回しなければならないと記述されていましたが
2013年の現在は小川に橋が架っており、国道を経由せず境内から直接行けます。
しばしの間流れが強い用水路のわきを進みます。
そして138号線と合流します。しばし南下したのちルートは富士吉田市歴史民俗博物館
の脇道に入ります。
脇道は素晴らしい紅葉のアーチになっていました♥
しばし脇道を走ると散策路に入ります。道標が全くなく迷いやすいですが迷ったら
ひとまず138号線にでるのが吉です。またこのあたりルートが複数あるのでご注意を。
少しの間のトレイルを超えて鐘山橋に到着です。国道138号線の忍野入口交差点から
もこの場所に来られますのでご安心を。道はすぐにトレイルに戻り、忍野八海へと
向かいます。
下写真の富士学園の手前に道標がない分岐があります。ここは道なり直進で。
忍野八海分岐に出ました。本ルートは右折で山中湖ですが寄り道して忍野八海へ寄り
ました。
なんと平日にもかかわらず観光客でいっぱいです。
気が付いたら草餅買って食べてました…
忍野八海です。ここは富士山の雪解けの湧水が湧出して8つの池ができた場所です。
結構飛ばして走ってきたのですが実は私はここで初めての水分補給です。朝のモス
バーガーで燃料蓄えてたせいでしょか。固形物もさっきの草餅で賄えてます。
忍野八海を離れ、本ルートに戻ります。ぽつぽつ来ていた雨はだんだん雨脚が強く
なってきました。しかし今日は天気予報をみてあらかじめ雨対策万全にしてきたので
想定の範囲内です！
…今回目指す大平山には雲がおっかぶさっていた…。
忍野八海から少し離れた湧出池の浅海を通り過ぎます。
車道を走って今度はハリモミ純林の中の車道を突っ切ります。
ほうとう屋を過ぎた交差点で左折し別荘地の間を抜けたら石割山に続く登山道と
なります。雨は叩きつけるような土砂振りへ変わりました…。
稜線に向けて高度を上げるたびに風もだんだん強くなってきました。
しかし、私は雨中の登山は幾つか経験して来ました。身近なものを利用した電子機器
の防水対策や、濡れたところに強い風に吹かれて一気に体幹が冷やされることによって
おこる低体温症を起こさないための対策とかもこれまた身近なものをうまく使いこな
して完璧にしております！
雷とか土砂崩れ等の不可抗力を除けは注意して進めば怖くな…
ゴロゴロゴロ…ズドドン
…
…なんと稜線にでたころから風雨に加えて雷様も出てきやがったようです
オイオイオイ勘弁してくだち…
普段は風光明媚で富士山とかもきれいに見えるんでしょうけど今は自然が牙を剥いて
襲いかかってきてるような感じです。
しかし東海自然歩道進み続けてたらこんなBADDESTな日なぞよくあります…そのために
いつも特訓して装備も研究して走破できるようにしてるわけですよ…！
私は前傾姿勢になって走るスピードを上げた！
大平山に到着です。雨と風が凄まじいことになってますがイヤホン取ったら風が
バォォォォォォと語りかけます。うまいうますぎる
防風フィルムを体に巻いてなかったらとっくに低体温症になってお陀仏だったかも。
お次は平尾山に向かいます。吹きっ晒しの稜線上からは芙蓉台別荘地がちらほらと
見えました。
平尾山です。漸く雨が弱まって来ましたが風は相変わらずです。
レンズに水が付着しまくってしまいました。
本来ならこのまま平野まで下山ですが、予定より時間よりかなり早くここまできて
しまったので石割山にも行きました。
石割山頂上への最後の直登が泥でヤバかったですがロープが張ってあったおかげで
何とかたどり着けました。気温が落ちてきた所に体が温まったおかげかお尻のポッケ
に入れていたでぢかめのレンズがとうとうケツ露にorz
ｹﾞﾌﾝｹﾞﾌﾌﾝ…すみません。
石割山から平野への分岐にもどり今度こそ平野におります。
下るにつれて雨脚と風もだいぶ弱まってきました。
舗装路まで下りたらもう安心です♥
さらに下って道志道との合流地点である不動明王社に着きました。
そのすぐそばに次回の西丹沢への道標があります。
ここが次回のエントリポイントです！
さらに下って"山中湖平野"のバス停に到着しました。
ここから森の駅旭日丘までラストスパートです！
国道413号に沿ってひたすら走ります。行きかう車が容赦なく水をはねてくるので
その都度ジャンプでかわしました！(←元から濡れてるじゃんってのは無しで)
歩道はやがて紅葉の道になりました。湖畔にも降りられるようになったので
そちらへ進みました。
あんな場所を越えてきたのか…と感慨にふけってる所にもうじき今回の終点が
近づいてきました。
山中湖の巨大なレリーフがある場所で道路に戻り、今回のゴール"森の駅旭日丘"
に到着しました。距離は30kmもなく、難易度もかなり低いルートのはずですが、
中盤〜後半の超悪天候のおかげでなかなかの手ごたえでした。
着替えと土産の購入を終えて気温9度の中をバスを待っていたら"カバです！カバです!"
と妙に真面目なナレーションと共に水陸両用バスKABAが発進しておりました。
転んでひっくりかえったりしたらBAKAみたいｄ
ｹﾞﾌﾝｹﾞﾌﾌﾝ･･･やってきた富士急バスに乗り込み前回と同じく
JR御殿場駅へ向かい帰路につきましたっと
次回はいよいよ東海自然歩道の最難関、丹沢山塊の縦走です。西丹沢と北丹沢の二つ
の過酷なルートに挑みます！
朝霧高原->富士吉田 GPSログ
富士吉田->平野 GPSログ
STM32F4シリーズを使ってみる8 - STM32F429I-Discovery接触編 -
ﾃﾞﾝ！
ﾃﾞﾃﾞﾝ！
…ッツついに来ましたよ…！最強に強まったSTM32F4が…！
後ろに見えるSTM32F437IIT6も後日に…
STM32F429I-Discoveryは現時点のSTMマイコンの中で最強種のSTM32F429とそれが
サポートする64MbitのSDRAMとRGBインターフェースが利用できるTFT-LCDまで
搭載されたまさにねむいさんのために作られたようなボードです！
※正式名称は「STM32F429I-DISCO」だそうです。
STM32F429/439シリーズはRGBインターフェースのTFT-LCDドライバとSDRAMを
サポートするFMC(FSMCからSが取れた)を持ち、最高クロック180MHzで動作する
Cortex-M4Fのコアを持つマイコンです。
ついにSDRAMが…♥もうヒープサイズ気にしなくていいんじゃあんちゃん
ちなみにTFT-LCDドライバのフレームバッファ用にも使われるそうです。
とりあえず電源を入れてみるとSTLink/V2が認識してemWinと呼ばれる小洒落たGUIが
走ります。凄いもんだ…基板上に実装されたTFT-LCDの解像度は240x320です。
タッチするといろいろメニューが選択できます。本来はUSBメモリ等の記憶媒体を
挿しておくようになってるみたいですね。
今は168MHzで動いてるらしいです。
…で、
一通りデモプログラムを確認したのであとはおなじみOpenOCDで内蔵フラッシュメモリ
のバックアップをとり(2MBあるので5分くらいかかりましたよ！) 前もって予習して
いたLEDチカチカプログラムを書き込んで一発動作を確認♥
おきぱのSTM32F4向けサンプルの定義をほんの少し変えるだけで事は済みました…。
お次は目玉のTFT-LCDです。ねむいさんはこっちももちろん予習済です。
STM32F42x/43x系ではUSB用SRAMの容量拡張のほかSPIやI2C等の基本となる
ペリフェラルも数が大幅に増えていて更なる柔軟な回路構成が可能となって
います。
それではここらへんでいつものを…このTFT-LCDのコントローラICは定番の
ILI9341なのでRGBインターフェースへの応用も楽勝ですね♥
今回表示したのはねむいさんの頂き物のｲﾗｽ…ｲﾗｽﾄじゃなくて3D絵です。
あ○たご、抜錨しま〜す♪ぐふふ♥
↑ねむいさんが何のキャラのコスしてるのか最近分かったです…鈍い…
↑ねむいさんて艦これ(ブラウザゲー)やらないの？とよく本職してる時に尋ねら
れますが、6年前からずっとゴルロア続けてますし今もっともアツいブラゲに
嵌ってる(作業的な意味で)のでさすがに他のにまで手を出す余裕がないです…。
なお、びぃぶろ君に確実に怒られると思われるえろすな個所はトリミング済みなので
安心してご鑑賞ください。
20131114追：
タッチパネルコントローラはi2cのSTMPE811です。
こちらも予習済なのですんなりいけました！
というわけで今回はSTM32F429I-Discoveryのファーストタッチをご報告させて
いただきました。基本的な部分は初期のSTM32F4とほとんど一緒なので、
F4Discoveryからの移植はそこまで難しくないと感じました。
まずはFatFsとChaNさんのファイラーを完全に移植させます。12月上旬には
私のおきぱに新しいラインアップが追加されると思います。
東海自然歩道を徃く22(草薙-興津/興津-富士川)
今年の夏は暑かったですねマジで･･･屈強な高校球児すら熱中症で痙攣するレベルの
猛暑でしたが、やきう場より過酷な場所に果敢に挑んでいきました。
●2013.07.13 草薙->興津
この山行(というか今回は海行)に挑む少し前に富士山が世界文化遺産に登録されました。
同時に今回通過する予定の三保の松原も登録されたようですがはてさて･･･
今回のルートは正規ルートは三保の真崎灯台の手前で終了ですが私はそのまま
次なる戦場となる興津へ向かいます。灼熱の太陽が照りつける海岸線のルートが
勝負の鍵となるでしょう･･･いざ出発！(右端の変な仏像から目線をそらしながら)
南幹線を通過し住宅街をかいくぐると草薙神社に着きます。
こんなところにも龍勢のステマがー！？
立派なトイレがあったのでここで体制を建て直し新たに出発！
静岡バイパスコースは比較的難易度低いですね〜舗装路ばっかで楽チン
･･といいたいところですが夏場は地獄です･･･
虹裏メイドなのに第二のふたばがあるなんて知らなかったそんなの･･･
さて、ぐんぐん舗装路の坂道を越えるといったん下りの道に転じて
日本平への車道とクロスします。ここから山道がはぢまります！
し ゅ ん た
これはいい感じのトレイルですね〜♥
とおもいきやあっという間にそれは終わる。
ここを少しあがると再び舗装路に･･･
日本平ホテルです。
蝉兄貴も夏を満喫していますね…
日本平山頂公園に到着です。ここで水分補給をかねた小休止です♥
(XX高原ミルクってありがちやな･･･)
でもまんまと買ってしまう私･･･
この日は7月上旬にもかかわらずぎらぎらの猛暑でしたがツーリングの人たちも
沢山こられていました。11年前は私もよくドライブにつれてってもらｔｔ
ぶ わ っ
ずびっ･･･失礼しました･･･静岡の海岸線ルートはどうも私の青春時代を刺激
してしまって･･･ぇーっと日本平の山頂です。ここから久能山東照宮に降ります。
日本平山頂から久能山東照宮は山道は一切なく、ロープウェイで移動せざるを
得ません。しかし立派なこれも正規ルートなのでまぁ良いでしょう。
で、ロープウェイ待ちでベンチに座ってると猫ちゃんが2匹ねむいさんの元に･･･
日向をさけで私の足の下に来ましたが･･･
何故かその子の内の一匹が急にベンチを離れ、割れたコンクリの隙間に
頭を突っ込みお尻がはみ出た姿勢で固まっていました･･･そしてそれを
醒めた目でベンチ下から見つめる相方の猫･･･どうやら暑さで頭が･･･
そうこうしてる内にロープウェイがやってきました。
静岡なのでいたるところに世界遺産アピールがありますね！
ロープウェイの到着点は久能山東照宮の入り口になっています。
でも鳳来山のときと違ってお金結構掛かるのでスルー
(私の親父用にお守りだけ買ってきました)
ここからは海岸線に向けてひたすら階段を下ります。
11年前と同じ景色が眼下に広がる･･･(じわわ
上りはかなり辛そうですね〜
ぬふぅ！
ｹﾞﾌﾝ失礼、ここから先は久能街道こと国道150号線(の端っこ)を爆走します。
山道とは違った平坦な道ですが今は灼熱の太陽が容赦なく照りつける極めて
過酷なロードとなります！いざ勝負！
久能海岸は外海なので凪いでるときでも非常に荒々しいです。
JDの頃は良くここにもドライ(ry
眼から鼻水出てきました･･･ずびびびびびび
♪日射しの熱さに思わず目を閉じた 蜃気楼と過ぎてゆく夏の匂い あの日
♪荷物の重さで膝付き傾く背中に そっと触れたから 動きだした
150号線と離れ三保の松原をさらに目指します。ねむいさん作のスペシャル
ドリンクのおかげでこの過酷な天候下でも足の調子は抜群です！
実はこのルートは太平洋自転車道と道を同じくしています。
ここはホントは道に沿って左折せざるを得ないのですが、ぢつは矢印の方向に秘密の
近道があります♥なんで京都の人間が静岡の地元の人間レベルのこと知ってる
のかですって？うふふ
さて、近道の松林を抜けるともうそこは三保の松原"羽衣の松"です。
世界遺産効果か観光客もめちゃくちゃいます。私はここでも
11年前に立ち寄った茶屋で休憩を取りました･･･注文するのは
もちろんいちごみるくちゃん♥♥♥♥♥
やべ･･･一気食いしすぎて頭痛くなってきました･･･
しばしの間羽衣の松とかを見物しました･･･しかし、前日の7/12に先代の
羽衣の松が老朽化により切り倒されてしまい無残な姿に･･･
11年前は(ryこれ松の前で一緒に写した写真もまだのこしてｔぶわっつ
すみません取り乱しました･･･ちょっと眼から鼻水がまた出てきちゃったもんで･･
さて、松の先には三保の荒々しい外海が広がります！松側を振り向くと石でメッセー
ジが砂浜に刻まれてるのに気づきました。消えかかってましたがまだ･･･
オメデトウ2013世界いさん(下に富士山の絵)
メインの先代羽衣の松が切り倒されてしまいだんだん曇ってきたおかげで富士山も
見えませんorzせっかく世界遺産になったのにちょっとしょぼいです。
説明員の人がやってきた観光客相手に孤軍奮闘で解説の大立ち回りをされていました。
さて、たっぷり水分と休憩も摂ったので再出発です。
海岸線を縫うようにひた走ります。
三保灯台です。
こちらは三保飛行場です。
猫ちゃんも夏バテです。死んでるかとおもったら生きてましたよ。
自転車に轢かれないように安全な日影の場所に移して上げました。
三保海水浴場です。たしか11年前はここにシュモクザメ沸いてて遊泳禁止になってたはず･･･
でしたが･･･時代は変わった
真崎灯台です。東海自然歩道はここでいったん終了ですが私はこのまま先に進みます。
ここから先のルートは私の記憶が興津まで再び誘導してくれます(眼から鼻(ry
a>
三保の内海側です。静大ヨット部は健在ですね〜
海岸線を抜けると後は興津までひたすら車道を走り続けます。
この道も何もかも(ry
三保車庫です。ここから先はゴールの興津までひたすら車道！
さっきの三保車庫からJR清水駅はかつて国鉄三保線が走っていたそうです。
現在は自転車道になっているこのルートですが私も折戸駅跡からここに合流しました。
結構長くてきつい･･･湿度も100%あるんじゃないかという気候です。
曇ってこなかったら干上がって死んでたかも･･･
画像は清水といえば鈴与
oh...途中で国鉄三保線が私有地に吸収されてました･･
仕方ないので車道に戻ります･･･
静鉄清水駅周辺です。エスパルスドリームプラザが見えますね･･･。
右端に見てはいけない物体が･･･
杉山君総受け本
ねむいさんはさくらももこより岡田あーみんが好きでしたよぅ！！
というくだらない主張はおいといてJR清水駅に到着です。
旧三保線はこの場所で終了ですが太平洋自転車道はまだまだ続きます。
国道一号線とくっついたり離れたり。
11年前はここもねむいさんドライブで(ry
道はやがて旧東海道と再び合流します。
ここはすでに宿場町興津です。
それっぽい道標や案内板も目立ってきます。
うぉぉもうすこし！！！
ようやくJR興津駅に到着です。
久能海岸以後の舗装路延々走りはかなり効きました･･･三保の松原以降は曇ってきて
日射もかなり低減されたので超糞熱くて汗もダラダラでしたが精神的にだいぶ楽でした。
でも清水駅以降でふくらはぎがまたつりかけたのは反省ポインツです。
この程度で躓いてたら次回の過酷なルートは越えられません！
ねむいさんは次なる戦いに向け新たな決意を元に新幹線の中で爆睡するのでした･･･！
●2013.08.24 興津->富士川
今回は真夏の真っただ中に40km超の過酷なコースを巡ることになります。
ゆえに超激戦が予想されたので7月末くらいから特訓をしておりました。
仕事が終わったら西院から出発して東海自然歩道のルートでもある嵯峨の
六丁峠まで行って帰ってくる走り込みをほぼ毎日行い、特に六丁峠の登坂は
ダッシュで駆け上がり駆け下りてくるといったトレーニングでスタミナと
脚力を強化して挑みました！
出発地点のJR興津駅です。
旧東海道を少しの間手繰ります。
この興津郵便局の手前の交差点は身延道の出発点でもあります。
興津川を越えて薩た峠への旧道へと向かいます。
薩た峠への道標はいたるところにあって安心です。
そこまでやらんでええちゅうに！
この激坂を超えると休憩所とお墓がありその中をさらに通過します。
薩た峠です。
私はこの下を通る国道とかはよく来てたのですがこの峠自身を通過したのは
初めてでした。11(ry
目下には駿河湾の荒々しい海が今日もうねりを上げていました。
それにしても暑い…汗がﾎﾞﾀﾎﾞﾀたれまくってます…。雲は多少ありますが
その隙間から太陽さんはギンギラギンに直射日光を提供してくれます…
写真がちょっと暗いですが露光のせいでこんな風になってます。
薩た峠第二ビューポイントに来ました。
ここは有名な場所ですね〜。しかし肝心の富士山は雲と熱気による霞で
さえぎられてほとんど見えずorz
…おや…国道の立体交差の真ん中にあるあの建物は…？
あのうどん屋まだあった！
11年前ドライブで伊豆に連れてってもら(ry
猛烈な熱気のせいか目から大粒の汗が出てきました…貴重な水分が…
それはともかく灼熱のアスファルト道を超えて浜石岳の登山口にたどり着きました。
この日の静岡の最高気温は34.4度、持参したスペシャルドリンクとSAVASピットイン
リキッドで本日の最難関に挑みます！
浜石岳の山道は蜘蛛の巣だらけの上道が藪の上痩せてて非常に
危険です…ていうか蜘蛛の巣やめて！！１１！
ようやく走れるトレイルにでられた〜
と思ったらすぐに蜘蛛の巣ゾーン！！
藪藪藪藪藪藪
ちょっとでも止まると藪蚊が襲ってくる藪ゾーン
但沼分岐までようやくやってきました…持参した水分もあと500mlと少し…
しかし汗は滝のように出てズボンも発汗でおもらししたようになってます////
最後の急登…ここを登れば終わりだっ…！
予定時間より10分ほど遅れてようやく浜石岳頂上に到着です…
頂上に付いたころには雲が空を覆っていましたがそれを貫く勢いで
お日様光線が…とりあえずちょっと休憩…ぇどっこいしょ
…
……
…
…？
はぅあ！！
私としたことがベンチの上で仰向けで5分ほど意識失ってたようです…
このまま眼覚めなかったら熱中症でまぢで死んでたところですよぅ
長居は無用なので頂上を後にしました。
浜石岳を下りるとその先から静清庵自然歩道と何度も道を同じくします。
東海自然歩道のルートがわかりづらい箇所もありますのでご注意を
東海自然歩道は山道ではなく林道を下ります。
林道をひたすらくだってくだってくだってくだってくだって･･･
やっと民家がちらほら見えてきましたがやばいっす･･･水が切れてきました･･･
浜石岳がもうあんなに遠く･･･ボーっとしつつ間違えて入った道に
なんと共同墓地と水道水とトイレがー！ﾋﾔｯﾊｰみずだ！！１
ｺﾞｸｺﾞｸｺﾞｸｺﾞｸ･･･生き返った･･･
特訓の成果がああってか夏場で猛烈な下りの連続でも全く足が攣ってません。
ぐんぐん下ります！
銚子口の滝にも立ち寄りました。
もちろんここも蜘蛛の巣だらけ！ぬぎゃー
ようやく開けた場所まで降りてきました･･･はぁはぁ･･･。今度は県道76号線にそって
北上しますが、途中に商店と自販機があったので改めて水分を取りなおし
SAVASピットインリキッドも流し込んで２機目のエンジンをかける準備をして
再出発です。
このあたりは水が非常に綺麗で天然のわさびも道路の脇の小川にふつーに自生してます
でも私有地にあるので採っちゃ駄目ですよ！
"かぎあな"で県道とはなれ見晴観音へと向かいます。
勾配のきつい登坂でしたがようやく第２エンジンがかかったのでぐんぐん上ります！
道はやがて山道になります。しかし天候も完全に曇りになって気温も下がり始め
道も比較的歩きやすい山道なので浜石岳よりもさくさく進めます♥
見晴観音とやらにつきましたが･･･？？？観音さまは？
しかも木が邪魔で視界ゼロだし･･･さぁ次です次！
見晴観音から先は山々の縦走になりますがアップダウンもすくなく
走るテンポを上げることができました。まずは大丸山。
お次は大久保山です。
そして大平山･･･ここから野田山公園に向かって下ります！
が･･･ここで猛烈な藪藪藪･･･
下りの藪は足元が分からず非常に危険なので慎重に降ります。
無事に車道まで降りてこられました。
ここは次回行う新蒲原からのルートの合流点です。
警察屋さんがこんな山の頂上まで来てましたが･･･どうやら不法投棄監視の
パトロールされてるみたいですね。こういうとこって絶好の捨て場所ですからね･･･。
さて、エスケープルートはそのまま富士川方面にまっすぐ降りていく車道
なのですがねむいさんはもちろん東海自然歩道をさらに進みます。
ルート上の林道でついに夏富士を拝むことができました････！
さらに進んでいくと南松野の芝川コースと富士川コースの分岐点に着きます。
ここで富士川駅への進路をとります。次回のルートは結構このルートと
被りますね。
ぐんぐん車道を下っていくと新東名が見えてきました。この下をくぐります。
富士山もくっきり見えるようになってきました！
さらに下り、血流川を縫うように進むとこの東海自然トイレに突き当たります。
写真では見えてませんが手前のT字路で右折してください。
富士川の手前で身延道にそって登ります･･･だめだそろそろガス欠･･･
風の宮公園より富士宮方面と熱海方面の新東名高速を望みます。
少しのトレイルを抜け、道の駅富士川楽座をめざします。
視界が開けると富士川が一瞥できていい景色です♥
ねむいさんはもちろん川の風コースを選択！
もう暗くなってきましたし〜
道の駅富士川楽座です。
ここは富士川ICでもあります。
さらに下って富士川橋です。
11年前富士山のふもｔ･･･ぶわわっ
もはや水分は出尽くした･･･
えっと暗いですが両脇に見えるのが岩淵一里塚です。
あたりがすっかり真っ暗になった頃についにJR富士川駅に到着です･･･
足には豆ができまくりましたが懸念された足の痙攣は全行程42kmとおして全く起こらず
特訓の成果が十分に得られたと確信しております。
また午後になって曇りになり急激に気温も下がってきたのが幸いしたと思われます。
夜の帳の下りたホームは風もあって少し肌寒いくらい。
夏の終わりを感じる一日でした････。
なお、この日の夕飯は鯛めしでした♥
飲み物はもちろんゑ・び・す♥
いいんですよぅこの日超がんばったしビールは入るところ別ですし！
というわけで記録的猛暑となった過酷なこの時期に逃げ場なしの直射日光が
照り付けてさらに過酷になる海沿いの2コースをわざわざ進みました。
しかし運良くどちらも途中から曇りになり熱中症になることもなく危なげなく
ゴールに到達できました！いやもちろん適切なアイテムしっかりそろえて挑んだ
のと地元京都で特訓しまくった成果が出ちゃっただけなんですけどね〜
うふふ(地獄のミサワみたいな顔で)
次回は野田山周辺のルートをもう一度なぞりさらに芝川まで抜け、そして静岡
バイパスコースの終点であり本線とのエントリポイントでもある田貫湖をめざす
2013年度の東海自然歩道夏の陣のラストとなります。
草薙->興津 GPSログ
興津->富士川 GPSログ
いろいろ試す19
あっという間に(仕事上の)夏が終わってしまいました･･･日記上は更新
してないので夏ばてしてた様に見えるでしょうけどもじつは更なる跳躍の
ために私なりにいろいろやっていたのですよぅ！
とくに東海自然歩道関連もトレーニングを重ねて猛暑の中で難所をクリア
してきたのでこちらも近いうちにじっくりと･･･
●夏休みの工作☆LPC4088
さて、円高の頃に買い込んでいた基板やチップの中で最後の大物で
残っていたLPC4088に着手をはぢめました。
基板はLPC1788ですがLPC4088はほぼピンコンパチなのでそのまま乗っけ
られます。生基板なので仕事や家事終わったあとに大量の部品をちまちま
ちまちま付け続けお盆休み明けにようやくFatFsまで動作を確認しました。
LPC1788のときと同様に大容量のSDRAM乗っけてます。STM32系と違って
heapやstackとしてがんがん使ってもコケないのがすばらしい！
(STM32F1系のFSMCはerrataとしてFSMC上のSRAMをheapやstackに使うな
ととうとう明記されてしまいました!!!11!!F***K!!!!)
LPC4088はLPC1788には存在しないSPIFIインターフェースを持ちます。
しかし･･･
困ったことにLPC1788系と互換性を保った結果LPC4300系と違いSSPポートの
互換性がなくOpenOCDから書けないことが判明orzOpenOCDはSPIFIではなく
ポート互換のSSPで書いてたんですよね〜
･･･ドライバの対応はnuvotonドライバの時よりしんどそうだったので
早々にあきらめ外付けのコネクタを設けてFlashROMを使って書き込みする
作戦に変更しました。SPIFIは容量を喰うFONTXファイルの置き場に
使用していきます。
あと付けてないのはLCDインターフェースですがこれは私がいつも使ってる
MCUバスではなくRGBでつなげるタイプのものを必要とするのでそれに合う
液晶の調達から手を付ける予定です。
●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと
紹介します。少し前にFRDM-K20なるボードが販売されましたがこの
シリーズの一番小規模のチップであるMK20DX32VLF5とMK10DX32VLF5を
ちょっと触りました。写真はK10のほうです。
K20はUSBと内蔵3.3Vレギュレータが付いてて本当にこれひとつで完結した
基板も作れます。実際に安価に製作されている方もいるようです。
ねむいさんがこれを単品で購入した理由はOpenOCDの書き込み/デバッグ
確認のためだけに過ぎません･･･
が、このチップ特有の機能にちょっとはまってしまいました。
以前、私はKL25やKL05を触りOpenOCDへの書き込み/デバッグを可能にして
きましたが、K10/K20もコアがCortex-M4(F無し)違いでKLシリーズと同じ
ように楽勝だろうと高をくくってました。しかしPOR後のウォッチドッグ
タイマの挙動が違っていてブート直後に即効ウォッチドッグの機能を殺しに
いかないとせっかく書き込んだのにセキュリティ状態に突入してしまい、
mass-eraseして解除してからGDBからイメージをもう一回ロードしないと
デバッグできない事態になることが判明!
工場出荷時はセキュリティ状態は解除されてるらしいですがこのウォッチ
ドッグリセットのせいで実質セキュリティ状態になってる為STLink/V2などの
MDM-APを直接叩くことが不可能なデバッガハードウエアでは手詰まりに
なってしまいます･･･ぬぎゃー
(これFRDM-K20が国内販売されたらまたねむいさんのとこにプログラムが
書けなくなったって質問飛んでくるんだろうなぁ････)
●EFM32シリーズもおさわり
同じくOpenOCDの書き込み確認のために単品購入したチップです。
EnergyMicroというメーカのチップでしたが現在はSiliconLabs社に吸収されています。
Gecko(ヤモリ)のマークがチップ上に付けられたイカすデザインでCortex系の
マイコンでは超低消費電力方面に力を込めたラインナップとなっています。
ねむいさんがチラッと触った限りではCMSISライブラリがSTM32ばりに充実
していてCMSISにどっぷりつかったねむいさんの流儀に非常に組み込みやすく
最初の取っ掛かりのLチカ作成が最速の30分で完成しました(逆に一番難儀
したのはあちこちにファイルが点在してて把握しづらく挙句の果てにKeilの
サンプル中にしかCMSISヘッダファイルが無い品種もあるKinetis･･･
てか公式のサイトでリンク切れはまずいですよぅ)。
書き込みデバッグももちろんすんなり完了ですごい相性よかったので
メインのSTM32からちょっと浮気しちゃいそうです･･うそですよぅうふふふ
というわけでOpenOCDのバイナリには上記3品種の書き込みcfgファイルを
追加してます。パッチも前回から不備が見つかったものをさらに改修して
ますので私と同じ環境をお持ちの方は試してみてくださいね〜
･･･すっかりOpenOCDありきのマイコンいじりになってしまいましたが、
実務ではルネさｓ
(日記はここで途切れている)
FM3が富士通からスパンションになりましたよ記念
20161123追：
富士通のFM3を喰ったSPANSIONはCypressに喰われました。
富士通のFM3マイコンに関する記事はもう更新しないでクローズにしようと
思っていましたが、国産マイコンだったFM3シリーズが大人の事情でSPANSIONという
メモリ中心のチップベンダに移譲されたので記念に小ネタを更新します。
前回まではFM3マイコンにFatFsやTFT-LCDドライバなりを積だのを紹介して
ましたが今回はOpenOCDのFM3フラッシュ書き込みドライバの改良についてです。
いつも参考にさせてもらっているjujurouさんによると小規模のRAM物理量が少ない
品種で書き込みが出来ないとのことで、Kinetis-LシリーズやNuvotonのフラッシュ
書き込みドライバを実装して実力をつけた私も調査してみました。
上の二つの図はFM3マイコンに収納されたフラッシュ書き込みのバイトコード
(書き込みアルゴリズム)と書き込むべきデータを簡略化した物の修正前と
後の比較です。
フラッシュ書き込みはJTAG/SWDから内蔵SRAMに流し込んでおいたバイト
コードをOpenOCD側の"run_algorithm"にて実行させることにより行われて
いますが、その中でSRAM上にある"u32DummyRead"と"u32FlashResult"の値を
参照しています。この二つの変数は、アルゴリズムを確保したメモリの先頭に
置かれるため、アルゴリズム開始アドレスは、本来は基底アドレス
(BaseAddress)から+8ずれることになります。
おそらく最初にドライバを作った時のデバイスがMB9BF506Nだけだったようで
SRAMの基底となるアドレスが0x1FFF8000に固定化されていました。
しかしFM3シリーズの内蔵SRAMの構造は、0x20000000をベースとして上下に
伸びていく仕組みなので安全牌で動かすためには本来なら基底を0x20000000に
しなければなりません。現状ではSRAM量が物理的に少ない品種ではOpenOCDの
cfgファイル内でSRAM量とSRAM開始アドレスを"正しく"指定すると、
jujurouさんの指摘通りSRAMが存在しないアドレスを参照することになり、
書き込みが必ずコケる羽目になってしまいます。
というわけで私も私なりに修正してなおかつ書き込みパフォーマンスを上げる
修正を盛り込んでパッチを作成しました。先ず以前使っていたMB9BF618Tで
当然のように書き込みを確認しました。さらに今回の問題が修正されてるのを確認
するためにebayで小規模のFM3マイコンMB9AF112K(Flash:128kB/SRAM:16kB)
を仕入れて動作確認を行いました。
↓やっけつ基板
ログはこんな感じです。ばっちり書き込み出来てますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/mb9af112k_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00117-gf7fed92-dirty (2013-08-12-20:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
adapter speed: 500 kHz
cortex_m reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on May 22 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 500 kHz
Info : Found SWD-DP id:0x2BA01477
Info : mb9bfxx2.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20002000
auto erase enabled
Info : Fujitsu MB9[A/B]FXXX: Sector Erase ... (0 to 2)
Info : Fujitsu MB9[A/B]FXXX: FLASH Write ...
wrote 131072 bytes from file main.elf in 4.344639s (29.462 KiB/s)
verified 33456 bytes in 0.109398s (298.651 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05さて、上記FM3の修正のほかにkinetisドライバとNuvotonドライバのブラッシュアップ
も行い、8月11日時点のOpenOCDのコミットに適用したパッチ群も更新しました。
もちろんOpenOCDのバイナリも修正していますので奇しくも時を同じくして一般販売と
なった｢FM3-USBSTICK｣を購入された方は試してみてください(私はMB9AF112Kで試し
ましたがメモリ構造が同様のMB9AF312Kでもまったく同様に使用できます)。
･･･
本来はこの程度の小ネタはブログトップのサブタイ欄にちょっと書いて終わる
はずなのですがVersaloonのBBSにKinetis-LドライバやNuvotonドライバのパッチを
紹介したことでntfreakﾘﾝｻﾝの目に留まり、OpenOCDのgerritにFM3の修正を含めた
いくつかのパッチを叩き上げられることにめでたく相成りました。
しかし、そのFM3ドライバのパッチはまだバグが修正仕切れてなかった欠陥版
だったのがつい最近判明したので、汚名返上のために私自身もOpenOCDのコード
レビューシステムに電撃参戦する意を決めました！！
とはいえパッチを提供するまでに覚える事柄が非常に多く英語による意思の
疎通も非常に重要になります。なんにせよひとつずつ目的達成までの課題を
あせらずクリアしていくほかありませんが汚名挽回をしてしまわないように
気をつけます･･･。
いろいろ試す17
試"す"というか試"した"結果のご報告の方が多いかも…
●STM32F437シリーズの予習
2013年4月中旬現在はまだチップ単体は手に入る時期ではないのですが
去年買って放置していた超格安全部入りボードを使用して来たるSTM32F437シリーズの
予習をしていました。
ただこれに付属しているTFT-LCDモジュールのタッチパネルドライバICが定番の
ADS7843ではなく、I2C接続のSTMPE811というI/Oエキスパンダと温度計も一体化
された妙に"いんてりじぇんす"なICだったのでそれの対応に非常に苦労しました。
↑画像は春になり発情期を迎えたいないさn
とりあえずいつものが動かせられるようになったので同じ基板を購入した人たちは
無改造で追試できると思います(TFTLCDのドライバはILI932xを選択の事)。
I2Cバスエラー対策はまだ実装していませんので、フン詰まりになったら電源を
いったん落とした後再投入して対処してください。(やっけつ)
また今回はタッチパネルの処理の上位層も少し見直して無駄な記述をしていた
箇所や分かりづらい箇所を廃しております。たとえば、
キャリブレーション画面で青の■をしっかり押せたら…
黄色の■になる！…もちろんこれだけではありませんが細かいところも修正してます。
せっかくなので全体的にソースコードも見直してコメント等をできるだけ随所に
挿入して、プログラムの流れもつかみやすくなるよう努めるようにしました。
本来は書いた本人がプログラムの動作に関する詳しいドキュメントを書くべきなの
ですがこちらのかたが非常に分かりやすい解説をして下さっており、ねむいさんも
いつも参考にさせてもらっていま…あれ？
今回の修正はおきぱにあるSTM32F1,F2,L系のものを始め他社のARMマイコンのFatFs
移植例にも順次反映していきます。
●STM32F4で外部SRAMを使う
ねむいさん非常におまぬけなミスをずっと放置しておりました。
STM32F4向けのいつもののプログラム中でターゲットボードにREDBULLを指定した
場合は外部SRAMを使用できるようにFSMCの設定を行っていたのですが…
REDBULL上ではキー入力も同時に有効にしておりそこのGPIO設定がでたらめ
だったためFSMCのポートにもそれが波及し外部SRAMへの特定の
アドレスのアクセスで頻繁にHardFaultっておりましたorz
一見まともに動いているように見えたので気づくの遅れましたorzorz
今回のソースコードの見直しではぢめて気づきましたorzorzorz
というわけでそこを修正して大容量のSRAMをmalloc系関数のheap領域として
使えるようにして、(さすがに内部SRAMと比べると非常に速度が遅いうえに
マトリクス化されていないのでスタック領域までは割り当てる気がありません…
F4はCCMあるし)これでメモリサイズを気にせずに自由自在に使えるようになった！
…と思いきや、16bitのアラインメントが乱れるようなアクセスが連続で続くと
やっぱりコケます。
これはlibjpegで画像をデコードするような時に特に顕著になりこのように
途中で表示がグレーになったストール状態に、虹裏で見られる富山みたくなって
しまいます。
↑libpngとgiflibだとこの現象一切起こらないのですが…調査はいずれまた…
また、FSMCのバスにSRAM以外に入出力容量の大きいブツ(低速でしか動作できない
一昔前のTFTLCD等)がぶら下がっているとやっぱりこけます。オシロでWRの波形を
見たらオーバーシュートしまくりです。なのでTFT-LCDも影響を与えないものを
オシロの波形とにらめっこして選ぶ必要があります。もしくはFSMCに影響を与えない
SPI接続のLCDの選択も考えてください。
ねむいさんが試行した限りでは16bit区切りになるような、たとえばVRAMとして
16bitにパックされたRGB565のデータをスタティックに確保しただけの状況下の
使用では問題は一切発生なかったのでこの先も慎重に確かめてみます。
●LPC4357全部載せ基板
RMBレートが13円のころに買っておいてよかったです♥USDも99円(20130411現在)
まで回復してますが海外のパーツ・基板漁りはひとまずお休みして買いためたブツを
消化して逝きましょう先ずはNxPのCortex-M系最高峰のLPC4357のボードです！
(2013年01月中旬当初は国際送料込みでなんと13000円台で購入できていた超格安な代物でした。)
以前LPC4330というLPC4300系の基板をいじっておりましたがあっちはプログラムを
格納するフラッシュ領域が全くなく、スズメの涙ほどの内蔵SRAMか低速な
SPIFI-SPIROMから実行せざるを得ない非常に使いづらい代物でした。
しかしこいつは違います！204MHz動作でフラッシュも1MB内蔵なので使い勝手が
改善されて(ると思い)ます！…しかし…
…
4.3inchLCD基板の接合部でみてはならないものが目に入ってしまいました…
…なんだこの隙間は…これのせいでベースの基板もひん曲がってるし…
(後日このヘッダピンを半田槽で外し新しいものにまっすぐ付け直しました)
通電すると動作確認用のサンプルプログラムが起動します。またOpenOCD用の
cfgを作っていませんがLPC4300系のフラッシュ書き込みルーチンもまだ
レビュー段階なので先ずはそこから基礎を固めて試してみましょうか…！
(逆さになった何かを無視しつつ)。
●OpenOCDをさらに使いやすく
年明けくらいからでしょうか、ねむいさんが提供しているOpenOCDバイナリを
STLink/V2から使用する際にドライバをLibUSBからではなくSTMicro提供の
純正ドライバを使うように変更できないだろうか？というご要望をちらほら
いただくようになりました。
まさかとおもってSTMicro純正のドライバをよく調べてみると、Windows向け
ドライバとしてWinUSBが使用されているのがわかりました。
また去年行ったFT2232系FTDIデバイスのMPSSE対応の際にWinUSB(LibUSB-1.0)用の
ビルドができるようになっていたのですが、STLink/V2に関してはVersaloonと
同じくLibUSB0.1系を使用するようにビルドオプションを指定したままになって
いたので純正ドライバは使用できない状態でした。
今となってはWinUSB(LibUSB-1.0)を使用しない道理は存在しないのでSTLink/V2の
ドライバとしてWinUSBを使用するようにビルドオプションを変えて純正ドライバを
そのまま利用できるようになったバイナリを現在は提供しております。
ST-LinkUtilityなどの純正ツールとOpenOCDがドライバの差し替えなしに利用
できるようになったのでぐっと便利になっております。
そのかわり従来のLibUSB0.1系から使用できなくなりますのでご注意ください。
↑一応変更当時はトップにでかでかと告知してたので皆さん移行済みかと思います
追：
ドライバの扱いについてちょっとまとめます。
LibUSB-1.0：WindowsにおいてはWinUSBのラッパーとして働きます。
ですのでLibUSB-1.0のAPIを使いたい場合インストールするドライバは
WinUSBとなります。WinUSBのKMDFを使用しています。
LibUSB-0.1：WindowsにおいてはLibUSB-Win32と呼ばれ、LibUSB0.1(libusb0)の
APIはWDMを使用しています。
LibUSBK ：WinUSBのエミュレーションとして働きますが、WinUSBでサポート
してないアイソクロナス転送も使用可能です。
また、libusb0のAPIとも互換性があるのでLibUSBKをインストール
しておくと1.0系と0.1系APIを使うアプリがどちらもドライバの
入れ替え無しに使用可能となります。
さらにFT2232系デバイスの方もZadigでインストールする際にLibUSBKを選択
することによりWinUSBを使うOpenOCDやLibUSB0.1系を使うUrJTAG/FlashROM
などの便利ツールがドライバの入れ替えなしにシームレスに利用できるようになり、
低いコストと簡単な手順で強力なデバッグ環境をそろえることが可能となって
おります♥
●aitendoさんのanux
>ANUX続けるのやめまーす(←peep.usでページを保存しました)
こ ん な こ っ た ろ う と お も っ た で す よ ぅ ！ ！
そうだねチャイナリスクです…せめて全回路図くらいPDFでくだち…
東海自然歩道を徃く19(久能尾〜牛妻坂下/牛妻坂下〜大平)
静岡ステージは積雪もほとんどなく舗装路も多いので気が楽ですね〜
ただ横方向に長いので一行程ごとの距離は25km以上ありますから冬季を
選んで進んでおります。あと行きかえりの交通費(ry
そして少し前のGPSの悲惨な検証結果を受けてロガーの心臓部のGPSモジュールは
PA6Cに戻しております(せっかく1万近く出して買ったのに)
●2013.02.01 久能尾->牛妻坂下
晴れ渡った美しい朝…♥
…さっきまで乗ってきたバスを見送りスタートです。
年季の入った広告のステッカーがあるこの場所がエントリポイントです。
いきなり猛烈な登りがはぢまりやガリました…はぁはぁ
それが落ち着いて崩落個所を抜けると茶畑に出ます。
名も無き山を越えてこの橋を渡ると寺島に向かいます。
こっから先、大山山頂までひたすら林道が続きます！
結構勾配がきつい…どんどんペースが下がってます…が坂本姫とかいう
石碑が見えました。
さらにその先に目をやると有名なNTTゲートが見えます。
このゲートの先に東海自然歩道は続いています。
ひたすら林道を登…る…
登…ﾋ
走る気力が失せて久しいころにようやく大山山頂に到着です…確か富士山を
見ながら休憩できる場所が…♥
…そいえば雨降るんだっけ…先に急ごう
なだらかな登りと打って変わって山道は傾斜角45度くらいの猛烈な下り！
コケから下までまっさかさまに落ちます！でもねむいさんは去年と同じく受験せ(ｒｙ
道の傾斜が落ち着いたところで水見色峠につくはずですが…
下に土砂崩れ対策の工事と思われる重機が見えます…
水見色峠に到着です。ここから進路を北にとり谷沢を目指します。
結構大規模の土砂崩れがあったようで自然歩道が完全消滅していて
代わりに地図を頼りに林道をかけ下りました。さっき上から見ていた
重機の横を一声かけてから通過させてもらいました。
やっと落ち着いたかと思ったらその下の林道も改修中！
シューズが泥だらけに…
やっとこ谷沢に到着です。
アスファルト舗装路をかけ下りて今度は栗島に向かいます！
栗島バス停分岐の地点で進路を北にとり最後の難関油山峠へ！
大山の登りでかなり足に来てましたが何度もつっかえて倒れそうになりました
しかしねむいさんは受験生の(ry
深い林に囲まれた油山峠に到着です…
ちょっと体調も悪くなってきたのでさっさと抜けることにしました。
廃墟も越えて山道を下るとやがて渓流と並走します。
最後に橋を渡って今回の山道は終了です。
残りはゴールの牛妻坂下まで舗装路になります。
懐かしの油山温泉と油山日月龍神社そして…
学生の頃にここでジュース買った懐かしの酒屋さんは潰れていたー！！orz
バスの時間押してるのでさっさと先に進みます！
…とうとう安倍川までやってきました…この場所…何もかもが懐かしい…
次回は牛妻坂下の交差点からスタートとなります。
物陰に隠れて着替えを済ませたころにはちょうど静鉄バスが…
11年前と同じく異様に交通量が多いこの道を下って静岡駅に戻りました。
●2013.02.16 牛妻坂下->大平
(新幹線さん早いな…)
…ぁすみません、バスが8時台のが接続よいのでここ数回の行程はお金を犠牲にしまくって
新幹線で京都から移動してます。
バスを見送り、相変わらず交通量が多いこの場所からスタートです！
舗装路はグングン高度を上げて龍爪山登山口に向かいます。
もう安倍川があんな下に…
龍爪山登山口です。こっから山道です。
おしゃれな切り株。
少しのぼった後林道と交錯します。現在進行形で造成中のようです。
というわけで自然歩道も分断されまくってますが道標代わりのロープのおかげで
きつい登りも楽々です！？
桜峠分岐を超えてさらに登りにかかります！
眼下にははるかに小さくなった安倍川が…
…っついに龍爪山(文殊岳)の頂上に到着です!!
このアングルからは清水港と三保がはっきり見えますね〜…何もかもが懐か(ry
そして、そ・し・て！
大阪から駆け抜けて約2年、肉眼では4年ぶりに富士山を見ることができました!!
本当は秋葉神社あたりで見えててもよかったのですが運が悪かった…しかしこれからは
小休止をとって穂積神社に向けて下山を開始しました。
ほかの登山者の方が山頂に大勢いたのが気になりましたが皆さん全員
穂積神社側から来られたようです。
薬師岳です。影側になるのか雪が目立ってきました。
富士山に見とれてるのもつかの間、全面凍結した木階段と金属製階段が行く手を阻む！
しかしねむいさんはたまたま今回のために携行していた簡易トレラン用アイゼンを
颯爽と装着しなんなくクリアー！
雪やアイスバーンが消えた頃に穂積神社まで下りてきました。
ここでアイゼンは解除…ぁう…これ爪の中まで泥だらけだ…
穂積神社から先は下りの快適なトレイルが続きます！
この山小屋を越えると沢に合流していきます。
さらにアスファルト舗装の林道と落ち合いやませみの湯に向かいます。
やませみの湯を少し過ぎた寺尾島バス停付近にて。
今回はこのあたりでゴールですが…
先取りして平井まで向かいます。
そして時間もまだ余裕があったので寄り道していきました。
河内(こうち)の大石です。
子宝に後利益があるらしく絵馬もありました。
舗装路を駆け上がって大平バス停に到着です。
次回はここからスタートとなります！
小休止した後やませみの湯まで戻りました。
この木でできた道がﾐﾁﾐﾁ唸っててやばい…
今回の目的地であるやませみの湯に到着です！
学生のころはここは行ったことなかったので時間の許すかぎり露天風呂を
堪能してきました♥♥
しっかりと今日の収穫を購入してバス2本を乗り継いでJR興津駅に到着です。
東海道線で静岡に行きそこから新幹線で京都に帰りました…。
もうちょっと温泉につかっていたかったのですが登山以外で静岡に
帰った時にでもゆっくりすることにします。
次回からは富士山の麓を廻る富士山ステージをあと二行程進み、
今期の山行を終えることになると思います。
久能尾->牛妻坂下 GPSログ
牛妻坂下->大平 GPSログ
いろいろ試す16…という名の新年のご挨拶
あけましておめでとうございます。
去年も色々ありましたが今年も私ねむいさんといないさん(とその他虹裏メイドたち)
をよろしくお願いいたします(ぺっこりん)。
さて、早速ですが1/6に私の誕生日を控えそれの仕込みに今修羅場ってるのでお年玉
代わりのファイル更新のご連絡をさらっとだけさせていただきます！
●FatFs移植サンプルの更新
ねむいさんからのお年玉第一号です！
私のぶろぐのメインコンテンツのうちの一つですがSTM32F4をはじめとしたARM
マイコンのFatFs移植例をTFT-LCDドライバを大量追加して更新しました！
あとmakefileで無意味な記述や冗長な表現があった物を削除&外部に追い出して分かり
やすくした(つもり)です。
そしてChaN氏や海外のelec系BBSで紹介されて以来海外の方からも色々ご意見等を
戴くようになりました。国内の方の場合は私の作例見なくともFatFsの移植は簡単に
出来ちゃう人がほとんどなので、個人のノウハウが成否に大きく依存するTFT-LCDの
制御に関する情報を求めてやってこられるケースが非常に多くなっています。
尤も数年前に同じ事の繰り返しになるので概論書いて以後はもうやるまいと思って
いましたがまたTFT-LCDネタで一つ書こうかしらなんて考えています。
↑たとえばtaobaoで捨て値で買ってしまったような、ドライバーICの型番だけ
分かっててピン配置が不明の未知のTFT-LCDモジュールの解析法とかです。
こうご期待！
●OpenOCDのバイナリを更新しました。
お年玉第2号でこちらもメインコンテンツのひとつですが、年末辺りからようやく
バイナリ使ってくれる方がちらほら出てくれたようです。(私のアナウンスもまずか
ったですが…)。
もちろんオリジナルには無い機能や書き込みスクリプトも搭載してますのでとりあ
えず落として使ってみてください。
あとわざわざ告知した理由は年末にTI-ICDI(LM4F-Launchpad)が公式対応したおりに
stlink系のAPI呼び出すときの手順が少々変更されたからで、以前私が配布していた
古いcfgファイルやプロジェクトファイルを使用しているとバッティングを起こして
エラー出て停止してしまう危険性があるためです。
おもに影響を受けるのはstlink系のハードウエアで、プロプライエタリドライバの
TI-ICDIが取り込まれた際に抽象化レイヤの名称が"stlink"から"hla"という普遍的な
名称に変更されています。
現在おきぱで配布しているものはこのhlaに置き換えたものなので新しいプロジェクト
と併せてお使いください。LPC1114をSTLinkで使ってた人は知らないと嵌るかも…。
●今年の抱負など
こうやって書いとかないと絶対実行しないタイプの人間なので
1.beagleboneをいじる
->気が付いたら買ってしまったので弄らないともったいないのです！！
せめてPC連動の据え置き型mp3プレーヤーみたいなのを作ろうかと…
2.ANUXをいじる
->気が付いたら(ry
せめて虹裏見る用のブラウザ(ry
3.ドットマトリクスLCDライブラリ
->ご存知の方もいますが2.5元i2c液晶買って以来数年間育て続けたネタですが、
がた老さんに先を越されてしまいそうです(汗
いまだ水面下ですが去年の春に16諧調グレイスケールOLEDまで実装したので
TFT-LCDライブラリと同じ感覚で気軽に使用できる物を目指したいと思います！
4.英語の勉強
->私は読み書きは時間掛けると疎通は何とか可能だが会話がもう壊滅的でヤバい。
学生のうちに英語圏で不自由なく生活ができるレベルの英会話は出来るように
なっといた方がいいですよぅ…あと余裕あったら北京語も(日本に棲むような
語学力ある中国人以外は英語全く通じない奴が多いので)
5.夏期(4~10月)に近畿圏でトレランを10本以上こなす
->へばって歩いちゃったら意味ないんですけどね…
でもへとへとで山から帰ってきて風呂でさらに体液絞って絞って絞った後の
ビールがものすっっごく美味いのです…♥
それと現在使用しているGPSモジュールの精度がかなり良いので初期の精度が
悪い時の測位データの採り直しも兼ねて･･。
6."5."で体重を60�坩焚爾僕遒箸后�！！１１！！１
->油断するとすぐ60kg肥えやがる#
いろいろ試す15…という名の今年の反省会
●LPC812Xpressoを試す
Cortex-M0+コアが搭載されたLPC800シリーズ。この評価基板ではLPC812が
使用されております。またLPC1114系にはないファンクションマルチプレクス
機能などがあり、柔軟なプログラミングが可能です(と言ってもSTM32の第二世代
以降はかなり柔軟なリマップが出来るので物珍しいことでもありませんが‥)
さて、裏返すと見てはならない物が視界に入ってしまいましたが気を
取り直して即分離してSWD接続のVersaloon+OpenOCDしてみました。
…しかし…
ぐは…だめだ２番目のセクタ以降が書けてない…
OpenOCDのソースコード中にあるlpc2000.cにLPC800系のドライバ追加
しましたがフラッシュメモリの構成がLPC1000系と全く違うのでやっけつじゃ
むりですね…年明けにでも本腰入れてOepnOCDのソース掘ってみますかー！
●aitendoさんのANUXを試す
ねむいさんもご多忙にももれず買ってしまった…
え？この前のあれはどうしたって？
通電しっぱなしで放っておいたらDCDCと思われる部分が死んだので捨てました‥
さぁ通電だ！
>ANUX基板の電源スイッチ（SW1）を3秒ほど押して、１秒ほど画面が表示されます。
だそうですが早速出ましたね★
おおっ！Androidが起動しました♥
…
無事起動を確認したので他の人柱の報告待ちと行きましょうか１！１！！
さぁ次です次！！
●STM32EvoPrimterのその後
↑こうなりましたorz
リチウム電池を通電状態でうっかり放置してしまったため
放電終止電圧を大幅に下回って液漏れを起こしてしまった模様ですorz
漏れ出た電解液が基板に浸出してビアや部品の足を浸蝕していましたorz
てわけでかろうじて生きていたLCDだけ回収して荼毘に付して次です次！！１
●よくいただく質問とか
去年と同じく尺が余ったのでメールやコメントよくいただく質問に対する回答を
していきたいと思います。
Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:あのさぁ…イワナかった？
ねむいさんのOpenOCDのバイナリは上記の対策済みなのでこちらをお使いください。
また、どこぞの与太者がビルドしたものなんて使いたくない！！
なんて人は帰れよこちらの方法を試してみるのもいいと思います。
…でも面倒ですよねぇ…FPレジスタのサポートなんてまだまだ先ですし…
諦めてねむいさんがビルドしたバイナリ使いましょうよ…
ちゃんとNOD32とAVASTでウイルスチェックしてますから♥(←しつこい)
Q:いままで問題なく動いてたのに急にOpenOCDが繋がらなくなってフラッシュ
書き込みができなくなった！！１！！なんとかしろ！！！！
A:分かりましたから落ち着いてください。たぶんJTAG(若しくはDAP)へのクロックが
WFI命令等で供給を断たれてOpenOCDから繋がらなくなっただけです。
現在のARMマイコンにはほぼ必ずシステムメモリからのブートローダが内蔵されてい
ます。そちらから起動してメーカ提供のUARTブートローダ等でフラッシュを全消去
して電源をOFF->ONしたら回復します。
Q:ねむいさんのステッピングモータドライバの回路図でFETのドレイン-ソース間に
保護素子が付いていませんがほんとに設計の仕事してるんですか?
A:アバランシェ耐量でぐぐりなさい！１！！
Q:動力線の接点不良が心配なので丸端(丸型圧着端子)を圧着せずに半田つけで接続
しました(^^)これで大丈夫！
A:やめれ！
Q:なんでですか?半田つけなら確実じゃないですか！
A:熱サイクルで半田の接合部が徐々に劣化してそこの部分で発熱し出すから駄！目！
Q:先生は信頼性の高い半田つけの方が‥
A:あの…学校の授業で圧接の仕組みとかハーネス設計とかもやるべきだと思いますよー
↑つうかこれマジでヤバいのでちゃんとかしめ工具で圧着しましょうね。
Q:AWG22だと300Vで8A流せますね。てことは24Vだともっと流せますね！
A:なわけないでしょ…300Vってのは絶縁耐圧でそのAWG22とやらは300V以下の
どの電圧でも8A以下ですよぅ…てかUL番号何番の電線ですかそれ…
Q:ＸＸのシステムを設計してくださいorＸＸをしたいのですがプログラムを提示
してください。以上。
A:ねむいさんかいないさんの可愛いｲﾗｽﾂと等価交換ですね…！(ﾆｰｻﾝ風に)
えろすな奴だとサポートつきです♥
Q:twitterで参考になるサイトとして"ねむいさんのぶろぐ"をすすめたら
相手にいきなりブロックされました…
A:ねむいさんは素のEclipseが存在しない世界に生きているので素のEclipseで攻撃
されると反物質世界の住人のテレサさんのごとく爆発して死ぬ体です。Eclipseが
好きな方から見ると仏敵に見える可能性があります。気を付けてください。
とくにARMマイコン使い慣れている方ににコメントを行う際は言葉を選び注意を
払いましょう。ちなみにEclipse使うと爆発して死ぬねむいさんですが、メーカ
お仕着せなEclipseベースのIDE等はちゃんとチューンされているのでねむいさんは
爆発しません…。
Q:虹裏メイドってなんですか？
A:お笑いの集団です。
Q:某同性愛者向けAVに登場する人物がねむいさんと言うことになっていますが？
A:ララバいさんはそんなこと言わない
…はぁはぁ…だいぶ疲れてきましたので今年はこのへんで勘弁しときますよぅ‥
それでは皆様、よいお年を〜
Zzz…
STM32F4シリーズを使ってみる7 -Helix MP3 Decoderを実装してMP3ファイルの再生を行う-
マイコンを使った工作物としては入門となったMP3ファイルの再生ですが、今日日の
コアクロック100MHz越えのMPUならVS1053等の外付けのデコーダーICを使わずとも
ソフトウエアでデコードが可能です。
STM32F4にgiflibを載せて以来、次のステップとして(入院中もノートPCで)音楽再生に
挑戦していましたが私もようやく形にすることが出来ましたのでご紹介します。
すでにSTM32ではShuji009氏がHelixMP3Decorderで挑戦されており、さらに
野田さんはlibmadでMP3プレーヤーを製作されています。
ねむいさんはこちらのBBSで公開されていたHelix+STM32F4Discoveryを利用したもの
を大部分参考にさせていただきました。このプログラムはSPIポートを経由して
SDカードからデータを取得しデコードを行う形になっていてハードウエア的には私の
いつものとほぼ同じ構成だったので非常に助かりました。
ソフトウエア的な点についてはChibiOS/RTを使用していたので私の非OS環境に移植する
ためにはさすがにそのまま転用は不可能で、一つ一つ動作を理解しつつ再構成していき
ました。
ChaN氏のファイラーはデータ転送用に容量固定値の汎用のSRAMを確保するように
なっているのでそれを上手く使いSRAM容量を一切無駄にしないようにしています。
また、I2Sへのデータ転送はリングバッファ構成でDMAするのでCPUにかなり余裕が
できます。
あとSTM32F4を使い始めたころから何度も言及していますがCCM領域はDMA不可能
なのでCCM領域をスタックとして使い、自動変数にバッファを置くようなメモリの
使い方をしていると特定困難な不具合になりますのでご注意ください。
…ってわざわざこういうこと書いてるのは自分で言ったにも係らず嵌ったという
ことですorz。
ついでにいつものTFT-LCDにも各種情報を乗っけることにしました。
MP3のIDタグはv1とv2があり、v2でArtist/Titleが見つからなかった場合v1の方も
くまなく探すルーチンにしています。
もちろん日本語表示もFontX2ドライバで対応してます♥
↑MP3ファイルを再生してるところ。48kHz/230kBpsでもSTM32F4はぱわふりゃー
なのでまったくの余裕です♥(※最適化オプションは必須です)
↑Riff-WAVEファイルももちろん再生可能です。WAVEのルーチンはChaN氏の
WAVEPlayerFM3マイコン版を移植させていただきました。
MP3HelixのデコーダーはCBRとVBRをサポートしています。演奏中に全演奏時間や経過
時間をリアルタイムに表示するためにはCBRの場合はヘッダを除いたバイト数から容易
に算出可能です。しかしVBRの場合は少々厄介です。正確に算出したい場合は１フレー
ムあたりのビットレートからバイト数を計算しさらにそれを全フレームにわたって行う
必要がありますがもちろんこんなもんワンチップマイコンレベルではやってられない
のですが以下のプロセスで近似できます。
� �ID2ヘッダ領域にあるXingと呼ばれるヘッダから全フレーム数を算出
�◆．汽鵐廛襯譟璽箸�ら1フレームあたりの時間を算出
MPEG1Layer-3は1フレームあたり1152Sampleと定義付けられており、たとえば
44.1KHzなら1フレームにかかる時間は((1152*10^3)/44100(Hz))=26mSecと
近似できる。
�� �，鉢△魍櫃韻襪帆躅藾媚�間がミリ秒単位で得られる。
Xingヘッダーが無いと上記の技が使えませんので演奏時間/経過時間はめちゃくちゃに
なっちゃいます。殆どのMP3エンコーダーはXingヘッダーをちゃんと付与するのであまり
気にはなりませんが…。
今回のデモンストレーションで使用したaitendoさんのLCDはSPI接続オンリー
なのですが、STM32F4の性能のおかげでLCDへの転送をソフトSPIにしても音が一切
途切れず余裕で間に合うレベルです。
STM32F4ほんとすごいってね、また一つ確信させていただきました!
てわけで先日より先行で紹介はしておりましたがソースコードを改めて紹介します。
おまけでフリーで使用できるFontX2のフォントや隠れたメインコンテンツのTFT-LCD
ドライバも沢山(特にaitendoさんので初期化ルーチンが提示されてない品種)追加
しておりますのでこちらも併せて皆さんの参考としてください。
いろいろ試す14
●余ったAT90USBKeyをPDI接続のXMEGAライタとして使う
AT90USBKeyは(元)主人の遺品の一つでしたが引き継いだ私がSTM32をはじめとした
32bitマイコンに完全移行した今、もう必要ないかと捨てるつもりでした。
しかしLUFAの成果物の一つにAVRISPmk2の実装があったことを今更知り、
XMEGA専用のフラッシュロムライタとして再生することにしました。
XMEGAにあるPDIインターフェースはCortex-M系のマイコンにあるSWDとよく似ていて
2線式で書き込み・デバッグを行うことができます。しかもXMEGAの場合はJTAG接続よ
りも書き込みスピードが速い(ATMEL曰く)のです！！
ATUSBKey上のAVRISPmk2の実装はPD2&PD3(PDIDATA),PD5(PDICLK)として引き出
されます。AT90USBKey上では上記図の様に配線します。またポートの出力バッファの
破損を防ぐためPDIDATA・PDICLKとも各自100〜220ohmの抵抗を直列に付ける
べきです。本当は電圧トランスレータをかます必要がありますが、私は3.3V使い
しかするつもりがないのでこれで十分です。
PDIインターフェースはXmegaのReset信号を通信に使用します。外部リセット用の
メカニカルスイッチを実装している際にチャタリング防止のキャパシタを
ぶら下げてる場合は必ず外してください。
ドライバはおなじみのLibUSBを使い、書き込みはAVRDudeから行います。
メッセージはこんな感じです↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
avrdude -p atxmega128a1 -P usb -c avrisp2 -U flash:w:main.hex
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e974c
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (118286 bytes):
Writing | ################################################## | 100% 9.27s
avrdude: 118286 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 118286 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 7.77s
avrdude: verifying ...
avrdude: 118286 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:17ついでなのでXMEGAのFatFs+TFTLCDの実装サンプルも新しくしました。
しかしこのXMEGA、A1シリーズの384kByte版や4bit-EBIの完全版とかがATMEL本家
からことごとく無かったことにされ、素直にARM使った方が良い昨今は存在意義が
ほんとにわかりません…まさに
※もともと所持していた図体がでかいAVR-JTAGICEmk2は副業先に提供しました。
●ついでですがWinAVRからAVRToolchainに乗り換えるときの諸注意など
さすがにWinAVR使う人激減してますが、ねむいさんのようなコマンドラインビルド
主体の人がAVRToolchainに乗り換えるためのtipsを紹介します。
��PROGMEMの定義
これもう海外ではavr-gcc4.7系が出てすぐにFAQと化した事柄ですがたまに質問
もらいますので日本でも既に他の方々が言及してますが私もお伝えします。
prog_****系の(prog_char)等の宣言が4.7系で廃止になったのでテーブル等の定数
をフラッシュメモリ置くときは以下のように定義し直せばOKです。
旧 :const prog_char unk[] ="inachang!";
新 :const char unk PROGMEM[] = "inachang!";
私が公開してるXMEGAのサンプルはすでに修正入れています。
��utilsが無い！
AVRToolchainはAVRStudio6で使用するのが大前提なのでunixライクツールがあった
utilsフォルダが存在しません。ですがAVR-GCCのバイナリがあるフォルダに同等の
物が一緒にほぼ全部ぶち込まれてるので大抵は困りません。
(sh.exeだけは無いです)
シェル(sh.exe)に依存するmakeの書き方をしてるとエラーで止まるのでご注意
ください。…LUFAっていまだWinAVR20101110が前提なんですよね…めどい…。
因みに私が公開してるXMEGAのサンプルはもちろんこのビルド手順準拠です。
ARM-GCCの代わりにAVRToolchainをGCCコンパイラとして指定するだけです♥
●デジカメ買い換えました
2010年の8月に購入後数日で比叡山の登山道の石の上におっとこして以来だましだまし
使用していたねむいさんのIXYDIGITAL220Fちゃんが湯の山温泉のバトルで力尽き
とうとう縦向きでしか撮影できなくなりE32エラーも連発するようになったので
最新のIXY3に買い換える運びとなりました…
2年たつと全然性能が違いますね…まぢて…マクロ撮影が1cmまでできるので
TFT-LCDのCOGの解析に役立つかもしれません！
●今まで普通に使えてたSDカードが急に書き込み禁止になったんですけぉ！！１！！
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってるPCも上記の症状が
出るようになってしまいました…。SDカードは認識するがライトプロテクトが解除
出来ず書き込み禁止になるパターンはいくつかの原因が考えられます。
��SDカード本体のライトプロテクトキーがLOCKになっている
->SDカードについているLOCKキーは物理的なものでSDカード内部と
電気的なつながりはありません。もしこれがLOCKの位置になってたら
ずらすと直ります。しかし大抵は…�い紡海�
��SDカードリーダ・ライタのドライバ側がライトプロテクト設定にしてある
->ちょっとインテリジェンスなカードリーダ・ライタはたまにソフトウエアで
プロテクト設定可能な機能があります。違うカードリーダ・ライタだと普通に
読み書きができる手合いの奴ですね。マニュアルを見て解除してください。
��Windowsを使ってる場合限定でレジストリの設定でライトプロテクトにしている
->google先生に聞いてください…
��SDカードリーダ・ライトのソケットに問題があり、常にLOCK状態になっている
->使い込んだリーダライタやノートPC付属の奴ではよくありがちです。
ではなんでこんなことになるのかを説明します。
SDカードの挿入検知(INS)とライトプロテクト(WP)検知はメカニカルスイッチで
行われ、カードリーダ側でその電圧レベルを読み取って状態を判断します。
INSとWPのポートは大抵は3.3Vでプルアップされています。
カード未挿入状態ではINSは解放されているので3.3Vになり、なおかつWPも上写真
ように解放されているので3.3Vとなり、ロジックレベルではどちらもHIになります。
このときSDカードのLOCKスイッチをLOCKにしないで挿入するとINSはSD
カードリーダ側のソケットと電気的に接触し信号レベルがGNDに落ちます。
同じくWPも挿入するとSDカード側のLOCKスイッチに物理的に押されてGNDに
落ちます。この状態ではカードリーダ側は読み書き可能と判断します。
一方SDカードのLOCKスイッチをLOCKの位置にスライドして挿入した場合、同じく
WPの接点とソケットのGNDが一時的に押されるわけですが深くまで挿すと位置的に
再び解放されてロジックレベルがHIに戻ります。
この状態ではカードリーダ側は書き込みのみ可能と判断します。
まとめると3つの状態があることがわかります。
・カード未挿入
INS :HI(3.3V)
WP :HI(3.3v)
・カード挿入(LOCKの位置ではない)
INS :LOW(0V)
WP :LOW(0v)
・カード挿入(LOCKの位置)
INS :LOW(0V)
WP :HI(3.3v)
そしてWPの接点はINSよりも構造が脆弱で長期間使用で接点の弾性の劣化・酸化による
接触不良を非常に起こしやすく、ある日突然常にHIレベル(WP有効)と認識されるように
なってしまいライトプロテクト状態となってしまうわけです。
これについての対処方法ですが、つまりは接点を復活させればいいわけですが、USBの
カードリーダ使ってて起こった人は買い換えた方が手間暇も喰わず安上がりです。
しかしノートPC等で基板にソケットが備え付けられてるタイプの奴は一苦労です。大抵
修理保証期間を過ぎたころに上記の接触不良が発生するので上記の箇所の修理でも多額
のお金がかかるケースもあります。
ねむいさんの場合、購入後5年以上経過していたのとPCの裏蓋を外すとカードリーダー
のソケットが手の届く位置にあったので、WPの端子を導電性布テープで詰めて固定し
GNDに強制的に落としてLOCKスイッチの位置にかかわらず常にWP解除状態としました。
接触不良の初期段階の書き込み禁止になったりならなかったりの時は接点復活王なども
有効かもしれません。いずれにしてもソケットが手が届く位置にある場合限定です。
●STM32F4DiscoveryでMP3プレーヤーを構築する
ｸｸｸ…(by鍵最高)もうほぼ完成状態です…♥
こちらについては月末あたりに別枠でまたお知らせしますね〜
LPC4330はぢめました -まだLチカもできない-
積み基板どころか"詰み"基板になるのが分かっていながら人はなぜ、
何故、同じ過ちを繰り返してしまうのだろうか？
…しかしねむいさんはLPC1788にMCI版FatFsを移植を行ったので十分挑戦権が
あると自負しています！日本のアマチュアでは今度こそ一番乗りで(あつさんがすでに触ってました…)LPC4330が
搭載されたLPC4330-Xplorerの使用感を報告させて頂きたいと思います！！
この基板インド製だそうですがもう時代は中華大陸飛び越えてインドですよ
インド！
さて、この基板はNxP社肝入りのCortex-M4F+CortexM0のデュアルコアが搭載
された最新のマイコンLPC4330が搭載されています。
最大動作周波数はCortex-M系最高速の204MHzに上り(M4,M0コアの両方とも)、
クアッドSPI-ROMが使えるインターフェース"SPIFI"も搭載されています。
USB-HSのPHYもLPC4330内に搭載しており(USB0のみ)、外付けHS-PHYも必要
ありません！
もちろんねむいさんのいつものに必要なMCIインターフェースもあります！
んでもって基板の構成ですがSTM32F4Discovery宜しく音アプリを強く意識
した構成となっていてAudio-CodecやEthernet-PHYも実装されています。
さらに基板上にMicroSDカードコネクタやSPIFI用のシリアルROMも乗っていて
FatFsの移植も少しは楽になりそうですね♥
さぁケーブル繋いで通電だー！と思ったのですが…
…良く見るとコネクタがなんだか変…
写真分かりづらいですが無理やりねじこんだように金具の上側が微妙に
曲がってます…
そして付属ケーブルの口見たらこんなになってやがりました…
注：最初からこんなになってました。ねむいさん壊してないですよぅ！
もちろん刺さりませんorz
もうﾅﾝ持ってｲｪｪと叫びたくなるのを我慢してさらに基板をよく見ると
手半田で修正した跡がありDIPスイッチが溶けてLEDが焦げてました…
もうﾀﾞﾌﾞﾙｵﾄﾞﾛｷですよねほんと印度クオリティすごいってまたひｔ
インドのNGXから直接購入したので修理交換の手間と金が非常にかかって
しまうと感じ、結局自分でコネクタ・LED他の付け替え修理を行いました。
LPC4330-Xplorerに実装されたmicroUSB-Bコネクタとほぼ似た形状の奴を
taobaoで購入しており、スムーズに付け替えは完了しました。ちなみに
秋月さんちで売ってるタイプの奴はコネクタを挿す向きとピンの
並びが逆のため付け替えができません！ご注意ください。
LEDの交換ついでに3.3VのLDOもMLCCが使用可能なZLDO1117に換装して
おきました。
最初に付属していたUSBMicro-Bのケーブルは捨てて手持ちのを使います。
後はチュートリアルに従いVcomのドライバ入れて基本操作を確認しました。
NGXのチュートリアルにはUSB0サイドのUSBHIDデバイスは挿したらすぐに
動くように見られますがまずUSB1サイドをPCに刺し、その次にUSB0サイドを
PCに刺し、最後にSW2を押すとUSB0サイドのHIDデバイスとして認識される
ようになります。
またSW2を押した後は仮想COMポート上で上画像のように各種チェック
ルーチンが走るようになっています。
同時にEtherNetもアクセス可能です(192.1681.1.123固定なのでご注意下さい)
LEDの操作がブラウザ上から可能になっています。
最後にJTAGで繋いでみてOpenOCDからどう見えるか確かめてみました。
LPC4330-XplorerのJTAGコネクタがちいさ過ぎてTI-StellarisのICDI付属の
ケーブルしかピッチが合うのなかったので、JTAGkey2Cloneの代わりに急遽
これを使いました。
↓で繋いだ状態はこんな感じに…
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/luminary-icdi.cfg -f target/lpc4350.cfg
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-10-17:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: lpc4350.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4350.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4350.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4350.m0: hardware has 2 breakpoints, 1 watchpoints
確かにCortex-M4とCortex-M0のふたつのコアが見えてますね〜
ほんとに触っただけというかそれ以前のやっと修理したばっか状態なのでLチカ
すらも進んでませんが、豊富なサンプルをベースにいつものを作っていきます。
STM32F4シリーズを使ってみる6 -giflibを実装する-
前回はlibpngを実装してTFT-LCDに表示を行いましたが、今回は同じく現在でも
多用されているgif形式の画像がデコードできるgiflibをSTM32F4に実装し、さらに
アニメーションgifのTFT-LCD上においての再生も成功しました。
●あらまし
giflibはlibungifを前身に持ち、LZWというアルゴリズムでエンコード・デコードを
行います。ご存知の方は多いと思いますがそのパテントを持っていたUnisys社により
一時はgifフォーマットがあまり使われていなくなっていた時期がありました
(代わりのフォーマットとしてpngが出てきました)。
2012年現在はそのパテントの期限も切れて自由にLZWが利用できるに至っています。
gifフォーマットはpngと比べて256色までしか表現できませんが、アニメーションgif
として今でも現役で使用されています。ことさら私たち虹裏メイドに関しては、
ファイルのアップロードに500kByteの制限がある虹裏の板の仕様上pngと並んで
アニメーションを表現するのに非常に重要な形式であり、これをSTM32F4に代表される
大規模マイコンに移植し表示せしめることは最早宿命とも言えます！
STM32F4への実装と動作の理解の助けとして、yoya氏のwikiを参考にさせて
いただきました。ありがとうございます！
●必要なもの
giflib
今回は出来たてホヤホヤのgiflib-5.0.0を使用します。
●ファイルI/O
libjpegやlibpngと同じようにFatFsのAPIを差し替えりゃ簡単…とはまったく言えず、
PC向けにファイルI/Oが特化されたgiflibをChaNさんのFatFsの流儀に嵌めるまでは
かなり試行錯誤を強いられました。最終的にDGifOpenFileHandle()内はFatFs完全特
化する形で書き変えてしまいました。
●makefileに追加するCソースファイル
デコードするためには最低限下記ファイル群が必要です。
dgif_lib.c
gif_err.c
gif_font.c
gif_hash.c
gifalloc.c
quantize.c
dgif_lib.cに関しては一部内容の書き換えが生じます(後述)
dgif_lib_fatfs.cとリネームしておいてください。
●ARMマイコン上で動作させるための少しの変更
FatFsのAPIに当てはめるため、幾つかの変更を強いられます。
dgif_lib_fatfs.c
->"/* Nemui Changed */"の変更・削除した部分を参照してください。
gif_lib.h
->ff.hをインクルードしてください。
->178行目のプロトタイプ宣言は以下に変更してください
GifFileType *DGifOpenFileHandle(FIL* fp, int *Error);
gif_lib.h
->ff.hをインクルードしてください。
●gif(アニメーション)を表示する
多くのアニメーションgifではインターレースがどれかのフレームで使用されて
いたため、インターレースの表示ルーチンも実装しました。giflibにあったexampleを
見れば特に困ることはありません。
もちろん表示スピードは落ちますが透過表現も実装してます。
また、実際の表示に関してはRAMの少ないマイコン上の話なので一列ずつ表示
することになります。この時に消費されるRAMはベースで28672Byte(デバッガの
追跡により算出)と一列ごとのピクセル数*3です。
だいたいlibpngより少し少ない量になりますね。
しかしながら、320x240サイズのちょっと大きめでフレーム数が多いgifアニメー
ションは再生中にもメモリ要求量が増大していき、総量で70kByte近く消費しました。
libpngも大きい画像サイズの奴をデコードしようとすると65kbyte程使うように
なりますがそれより多いのです。
というわけで専ら大容量の内蔵SRAMが使用できるFM3・STM32F2&F4ですね〜。
デコードされたRGBデータは8+8+8の24ビットの形式となっているため、565の
16bitにしてTFT-LCDにデータを書き込みます。
グローバルカラーマップとローカルカラーマップの判別もこの段階で行います。
そして動かしたところです…
(gifファイルはとしあき&｢｣作の物を使わせてもらいました！)
↑写真が静止画なので分からないと思いますがgifアニメーションが動いてます。
アンドリューW.K.さん(キャラクターが)いいよね…
↑gifアニメーションの最終フレームまで来たら停止します(ループはしません)。
ちなみにgifの仕様上ディレイ時間は10mSec区切りとなるので実装時は適切な
時間のディレイを生成する必要があります。
また、私の表示プログラムでは最終フレームまで行かなくても途中で各入力を
行うことによりファイラに強制的に戻ることができます。
↑STM32F2でも動く！当たり前ですが…
…STM32F1はRAM容量的に流石にきつかったので抜きで。
↑FM3マイコンでももちろん動きます！
ということで今回の成果はおきぱのSTM32F4,F2,FM3のFatFs移植例に
すでに反映しています。前回も少し触れましたが、私が使わせてもらている各
ライブラリ・プログラム・フォントのライセンス表記についてもきちんと明記する
ようにしていくようこころがけています。
おまけ
またまた買ってしまった(写真奥)…これからは解像度320x480で小型なTFT-LCDの
時代です！手前のaitendoさんで売ってるのより一回り小さいやつで、コントローラICは
HX8357Aです。今回のいつものの更新ではこちらの液晶にももちろん対応させています。
大きさも3インチと一回り小さいので出来あいLCD基板にちょうど乗ります♥
FM3マイコンを使ってみる4 -もう、誰も...-
もう触る気力がゼロになってしまったのでいつも見に来てくださってるFujitsuの方々
には真に申し訳ないのですがここで打ち切っていつものの公開をさせていただきます。
●勝てなかったよ…
当初実装予定だった以下のコードは私の力不足もあって盛り込めませんでした。
・外部SRAMアクセス
->基板に半田付けまではしたけど配線めどい。
・松浦氏のmp3プレーヤー(libmad)の移植
->STM32F4でhelixの方を移植しリベンジ完了。
●いつもの
私のぶろぐにおいていつものとはChaN氏謹製FatFsの移植例を指します。
もちろん単に移植しただけではなくTFT-LCDと組み合わせた(同じくChaN氏の)
ファイラにより視覚的に操作が可能になっています。どのMPUにかかわらず
いつものは基本的に下記の機能を網羅するようにしており他の用途にも
簡単に応用できる仕組みとなっています。
・FatFs
・UART(TFT-LCDドライバ/FatFsテストルーチンの動作に必ず必要)
・TFT-LCDドライバ
・SPI転送(TFT-LCDドライバに使う)
・外部バス(TFT-LCDドライバ・SRAMに使う)
・タッチパネル入力(TFT-LCDドライバに使う・BlueScreenのものを汎用化して移植)
・タッチパネル入力用のデータ保持(FRK-FM3ではFRAMを使用)
・DMA転送(TFT-LCDドライバに使う)
・FONTX2ドライバ
●動かすためのハードウエアの準備
FRK-FM3にのっかっているレギュレータはデフォルトではLDO側の出力が使用
されています。これを600mA引き出せるDCDCコンバータ側に切り替えました。
基板単体で通電した時の立ちあがりとたち下がりの波形は以下の通り。
まぁ特に問題もないですね。(あったら困りますけど…)
基板から外の配線は、GNDとVCCの配線がものすごく簡単になるアイテムラボを使用しました。
さんのパワーメッシュユニバーサル基板
裏にはebayで大量に購入したmicroSDカードスロットを設けました。
安価で引き回しもやりやすいです♥
アナログ出力はローパスフィルタを通じて単電源オペアンプで構成されたボルテージ・
フォロワ経由で行います。3.5φのジャックをつけるコネクタの上に見えるヘッダピンは
ボリ松基板(LPC2388用)をつけるためのものです。
TFT-LCDモジュールはパラレル/シリアル用のポートを引き出してます。中央のICは
くっつけただけで配線で挫折した1MBのSRAM...
いつものを動かしてみたところです。もはやここまでは基本の"き"ですね〜。
8bit-i8080と8bitSPIのRGBデータのブロック転送はDMAに対応しています。
ところで外部バスを使用した場合のDMAはメモリ間転送扱いなのでまだ簡単
なのですがMFSを用いたSPIでDMAする場合の具体的な手順がいまいちわからず
難儀しました。資料を探してFM3の英文の方のサイトの別品種のサンプル例に
UARTでの転送手順があったのでこれをもとにDMA転送ルーチンを作りました。
転送に関しては以下の要素が必要です。
・MFSのDMAはハードウエアのデマンド転送とする
・MFSの送信/受信割り込みをDMA要求として使用する
・DMACBxレジスタのEBビットは立てるのを忘れずに
・送信/受信割り込み許可ビット立てて転送開始
ぇっと詳しい手順はソースを見てください(丸投げ!)
XMEGAのMSPIでDMA転送できるようになった経験が生きました。
ちなみに速度は遅いですがソフトウエアSPIも出来るようにしてます。
尤もFM3の場合は9bitSPIが可能なので出番は無いと思います。
今回は表示系もちょっとだけパワーアップしてます。ロングファイルネーム(LFN)も
表示が出来るようになってます♥
これはWAVEファイルを再生してる画面ですがLFNの日本語ファイル名にももちろん
対応です。ちなみに私もf_stat()で取得したFILEINFO構造体のデータがLFNだけ
拾ってこられない罠にはまった一人ですorzSFNからLFNを引っ張ってくる
関数を一つ設けて実現しています。
というわけでFM3にかなり寄り道してしまいましたがこの経験をSTM32F4に
反映していこうと思います。
せっかくSTM32F427超格安全部載せ基板買ってしまってもったいないですし！
FM3マイコンを使ってみる3 -FatFsとTFT液晶表示の実装-
今月(2012年7月号)のInterface誌は予想に反して私のようなホビイストには
とてもありがたい内容となっておりました。
ねむいさんは正直Windowsネイティブな環境でもGCCでビルドや
デバッグできるのになぜか面倒なcygwinを使わせた上糞の役にも立たないLED
点滅で終わらせて実用的な作例はIARとかKEILのIDEのみで行って｢んんんｎ〜〜！！！
GCCは面倒ですぞ〜！CQ出版がお勧めするIARやKEILを使ってくだされ〜！１！｣って
販促するパタンで畳み掛けると思ったのですがどうせなら開き直ってDS-5とか
推せよとかいつも思っていたのですが今回は全然そういう事は全くなく、
オープンソースなソフトウェア(OSS)をフルに活用した記事が満載でした。
もちろんOSSにもメリットデメリットがあって邑中 雅樹氏の講演のスライド13p目に
それが集約されていると思います。タダより高くつくものはないです。
しかしながら趣味でやる場合は互いに情報を出し惜しみすることなく情報を
やり取りすることによって敷居を低くできるので横のつながりを大切にして
いきましょうね。
私も"ねむいさんのページ見てもわかりづらくてOpenOCD動かせられなかったけど
他の人のページに書いてあるやり方だったら一発で出来た"と言われないような
記事作りを心がけて行きます(←まだ根に持ってる)
…さて戯言はこの辺にしといてFM3マイコンはFatFsとシリアル&i8080バス
接続タイプのTFT-LCDドライバを使ったいつものの実装を目標と
しています。FM3のデータシートや
アプリケーションノートは情報散らばりすぎでいまいち組み方がわかりづら
かったのですが、上記IF誌に収録されていた作例にわかり易いサンプル例が
多数収録されておりそれを最大限に活用させていただきました。
●UARTとFatFs
UARTは前回行ったのと同じですが、前回jujurou氏よりコメントいただいた通り
SRAMの割りあてはSTM32F4の時のように目くじら立てるほどのことではないことが
判明しふつーに128kByteの内蔵SRAMとして使うことにしました。私が試した限りでは
すべてのSRAM領域でDMA可能でなおかつコード実行も可能でした。
というわけでChaN氏の作例にならってMFSを使ったMMC用のドライバも作り、
危なげなくFatFsも動作確認しました。ちなみにChaN氏はDMAを使用せずFIFOを
使用していますがSCKを18MHzにしたリード速度は下画像のようになりました。
STM32F107(DMA転送)の時とほぼ同じですね〜。SPIモードの場合の理論上の
転送スピードは18MHzの時約2.2MByte/Secになりますから無理してDMA化する必要が
なかったようですね。尤もFM3においては内部の遅延により+3.3V駆動の際に保証
されるSCLKの最高速度は7.2MHzにしかならないそうです。
STM32F4とかはSPIでも42MHzまで叩き出せるのにs**kです。
●シリアル接続タイプのTFT-LCD
扱いも容易でaitendoさんで手軽に購入できるようになったシリアル接続タイプの
TFTLCDも、FatFsの時と同じくMFSを利用してHALを作りました。もちろんGPIOによる
ソフトウェアSPIにも対応していますが…FM3のGPIOはAPBバスにぶら下がっていて
なおかつ1HCLK分ウエイトが掛かっているようでGPIOの出力レジスタに8bitのデータ
投げるような単純にstr命令だけが連続するような操作でもMAX12MHz、ビットバンド
領域の単純なビット操作はその半分のMAX6MHzしか出ないことが判明し、あまりお勧め
できません。
↑0xFFと0x00を交互にPDORFxに全速力でﾌﾞﾝ投げた時のI/Oトグル波形…
STM32F1(18MHz)以下ですかorz
↑ビットバンドなアクセスの場合はCortexの仕様上最短2クロックサイクル
かかるのでさらにその半分orz
TFT-LCDのRES線制御等の1ビット分だけの制御の場合はリードモディファイ
ライトが行われないビットバンド領域のアクセスの方が早いです。
ちなみにFM3にはSTやNxP系ARMマイコンにあるGPIO出力ポートのビット
セット/リセットレジスタなぞありませんorz
また、上のFatFsの話の時は7.2MHzしかSPIの速度が出せないと述べていますが
リードのことは考えずただLCDにシリアル信号をﾌﾞﾝ投げるだけなら18MHzでも
全く問題ないのでどしどし使いましょう。とくにFM3では9bitシリアルもハード
ウエアで設定可能であり、9bitシリアルにしかI/Fが対応していないTFT-LCD
モジュールなどでは速度面で重宝します。
↑ということで9bitシリアルにしか対応してないHX8340B(N)なTFT-LCDモジュールを
ハードウエア9bitSPIで動かしてみました。表示が早くなって感激です！
これでNokia6070その他9bitシリアルな液晶さんたちが救われます！ちなみに…、
いないさんの大事な部分が見切れていますがこれはPNG表示ルーチンの仕様です。
●外部バスとi8080バス接続タイプのTFT-LCD
今回のFM3基板に乗っかっているチップはA24までExternalBusInterfaceとして
アドレスバスが出せられます。
とはいえLCDを駆動するだけならアドレス線は一本だけで十分ですが…
こちらに関しては7月号の付録に収録されている松浦氏のMP3プレーヤーのLCD/SRAM
アクセス初期化部をかなり参考にさせていただき、さらにSTM32/LPC2388のように
柔軟性を上げて作り込みました。
今回の松浦氏の紹介にあるMP3プレーヤーの基板の回路に互換性をもたせてあります
ので他の方も再現できると思います(タッチパネル制御はADCを使用せず、ADS7843に
任せていますので非互換です)
↑この写真ではすでにタッチパネル制御も入れてます。
●タッチパネル制御
タッチパネルによる座標情報はタッチパネルコントローラICであるADS7843を
使用して得ています。AD7843はSPI通信の信号はかなり遅めにする必要があるので
簡素なGPIOによるソフトSPIでも十分間に合います。
さて、タッチパネルはキャリブレーションが必須ですが、キャリブレーションした
後のデータはこのFM3基板上実装されたFRAM(MB85RC16)にストアしました。
こちらに関してもChaN氏がFRAM向けのI2Cドライバとして実装されていたので
こちらを活用し、ストア・リストアするルーチンを作り込みました。
使用していて気付きましたが、やはりFRAMであってもWRITEを行った後は少し
ウェイトを挿入しないと次のWRITE操作に影響が出ることが分かり、なるべく
一つのデータにまとめて一つのWRITE操作で書き込むようにしています。
…ということでChaN氏のFatFsとファイラを実装して動かすという当初の目的が
達成されたわけですが、PWM出力と外部SRAM、あと外部SRAMとのDMA転送も試して
みたいのでもう少しコードは練った上での公開とさせていただきます。
公開しています。
STM32F0とXMEGAのFatFsのDMA化とTIのStellarisと東海自然歩道のネタが次に控えて
いて書くことがたくさんあり過ぎますがもう少しだけFM3です。
おまけ：FM3マイコンの性能やデバッグ効率を上げる小ネタです。
●FM3のパフォーマンスをアップする
HCLKが72MHz以上の時、FM3はプリフェッチバッファが有効になるそうですが
(元から有効化されてるみたいですが)この時さらに先読みした命令をストアできる
トレースバッファを有効化することもできます。FUJITSU提供のテンプレートでは
有効化するルーチンは無いので自分で挿入する必要があります。
消費電流は100mAオーバー(HCLK=144MHz時)で結構発熱しますがそれを厭わない方は
ｶﾞｼｶﾞｼ使って行きましょう。
●OpenOCD経由のフラッシュ書き込み速度を増加してデバッグ効率のアップ
現在のOpenOCDのFM3のフラッシュ書き込みルーチンは、I/Dコードバスに
ぶら下がった内蔵SRAM領域にフラッシュ書き込み操作とフラッシュに書き込む
データをJTAG/SWDで転送・実行していますが、ワークメモリの容量はハード
コーディングされています。128kByteもあるMB9BF618Tではもっと大容量の
メモリを確保可能なのでこの部分をデバイスID別に可変にするようにしました
(MB9BF618Tの場合は32768Byteにしました)。
ワークエリア増やしてもあんまし変らんだろと思っていましたがなんと
驚くべき結果が！！！！！
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-26-12:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
500 kHz
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000
Rize up to Internal PLLed Clock!
15000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 9)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
verified 941740 bytes in 0.828131s (1110.534 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:21なんと
wrote 1048576 bytes from file main.elf in 18.625118s (54.980 KiB/s)
となって、前々回と比べると5倍以上高速化出来るようになりました！
なんというか新生青銅聖衣を装着して敵の本拠地にカチ込まんとする
星矢さんのような"よぉしこれで全力で戦える！！！"な気分です。
一通り検証も終わったのでOpenOCDビルド時のFM3向けパッチとして公開しています。
今回のパッチはiruka氏とjujurou氏の物を合わせたのをベースにしてます。
また、OpenOCDのFM3向けコンフィグファイルと組み合わせないと性能が
出ないので上のOpenOCDのビルド&デバッグ方法をよく読み試してください。
FM3マイコンを使ってみる2
一応ねむいさん的にはChaN氏のFatFsといつものTFT-LCDドライバの実装までを
目標としています。今回はその中継ぎとしてSTM32F4の時に行ったメモリ構成の
決定とFM3の機能であるMFSを使ったUARTを使った標準関数のリダイレクト、そして
OpenOCDを使ったデバッグ環境の強化を行いました。
FM3のシリアル通信はMFSというUART,I2C,SPIの機能を柔軟に切り替えて使用可能な
ユニットを通じて行われます。マニュアルやサンプルコードをざっと見た感じでは
非常にめどそうな設定や操作項目が多い感じでした。
●基本の"き"、UART実装
…と言いたいところでしたがIF誌の特設ページを見るとなんとChaN氏自身がFatFsと
シリアル通信関連のプログラムをFM3移植されていたのでこれを最大限に活用させて
いただき、まずUARTの環境を拵えました。ChaN氏のUARTのルーチンとは
バッファ構成が少し違っていてXMEGAを触った時に覚えたリングバッファをパク
って構成しました。
また、ChaN氏は周辺機器レジスタ定義をFujitsuが提供するCMSISのもの(mb9b610t.h)
ではなく自己生成のパブリックドメインな物を使用されていました。こちらも私の都合で
一部だけ利用させてもらい他はFujitsu製のレジスタ定義にしています。
1文字送信関数は動作したのでお次はprintf系の標準関数にリダイレクトを行いました。
●メモリ構成の決定と標準関数(newlib)のリダイレクト
もう何度も何度も言及していますが、GCC環境でARMを初めて触った人が引っかかるの
はprintf系の関数がビルドできない動作できないという点です。尤も今回のFM3マイコ
ン基板に限ってはIF誌を１章から馬鹿正直読み進めてその通りにしてしまうとLED点滅
すらできず(なんでそうなるかはよく読めばわかります)、人の話を聞かない
ねむいさんのようなタイプの人のほうがさっさと先に進めるというのは何とも
言い難いところですが、これは｢本やネットに書いてること鵜呑みにして自分の頭で
考えないからそんなくだらない所で嵌るんだよ｣というCQ出版の読者に対する
挑戦なのでしょうか?
もしそうならカンガルー先輩を本国から再召還し編集部全員にヤキ入れ直しｔ
済みません話逸れ過ぎました
20120522追:
カンガルー先輩がヤキ入れした結果
ぇっとprintfの話でしたっけ、GCCのビルド環境でたとえばSourceryCodeBenchで
newlibを使うためには未定義の関数をユーザーが定義し紐つける(=リダイレクト)
が必要となります。細かい説明はLPC2388の時と同じです。
前回はLEDの点滅ができる程度で適当に決めていましたがnewlibを使用するにあたって
内蔵SRAMの構成をひとまず下のようにしました。
20120612変更：
内蔵RAM上のどのアドレス領域でもDMAできるのがわかったので分割は止めて、
128kByte分まるまる使う構成に変更しました。
MB9BF618Tの128kByteあるSRAMのうち0x1FFF0000から始まる64kByteはI/D
コードバスに、0x20000000から始まる64kByte分はシステムバスに接続されて
いるそうです。
まだ未確認ですがDMACがシステムバス経由でしかやり取りできないっぽいので
DMA用のRAMを確保するために0x20000000から先の64kByte分はまるまるHEAP領域と
しました。この構成はFatFsを積んだときにまた変わるかもしれません。
20120530追:
実験を行いましたが、どの領域でもDMAは可能でした。
また、同じくどの領域でもコード実行が可能でした
というわけでUART経由のprintf関数も無事動作。
もちろんsprintfやscanf等も使用できます。
UARTに使用されるポートはボリ松拡張基板のUART入出力で使用されるMFS3_2
なので、(FRK-FM3ではCN3の33p&34p)ボリ板でも再現可能です。
ところでmankoiって何ですかって？ぐふふ…
●ioviewを使いOpenOCDからペリフェラルレジスタを参照する
Fujitsuが提供しているレジスタの定義は全てがビットフィールドの定義もなされて
いてフツーにプログラミングする際は便利です(mb9b610t.hのサイズが超でかくなっ
てはいますが)しかし、これをこのままioviewに適用するとunionの数が多すぎるのか
参照した瞬間にinsightやGDBが落ちてしまいました。
やはり地道に一つづつ定義していくしかないのかと思っていた矢先、ChaN氏謹製の
レジスタ定義があるのを思い出しこちらを活用させてもらいました！自動生成されて
いるので一部レジスタの定義が二重になっている箇所がありましたがすぐに気付いて
修正し、mb9bf61x_io_view.cの完成です！
ビット単位の参照が可能なのは現状PDORx系のレジスタのみです。私の動作検証が
進むにつれて主要な物はレジスタのビット参照可能なようにして行きます。
ということで長々とお話ししましたが前回のLED点滅プログラムに+αを加えた物は
すでに更新しています。以前のプログラムを使用してprintfとかしようとした人は
リンカスクリプトがまだ適当だったので多分できなかったと思いますすみません。
また、新井氏(絵描きのaraiさんと名前が被るので混乱を招かないためにこちらの
新井さんは以後漢字記名で統一させていただきます)のSystemCoreClockUpdate()
周りの修正も今回の更新にあたり反映させていただきました。
STM32F4シリーズを使ってみる5 -libpngを実装する-
誘惑に負けて買ってしまった…盈钰電子のSTM32F4ボード…
176pinなSTM32F407IGT6,1MBSRAM,NAND&NORFlash,HS-USBPHY,Ethernet,I2SCodec,camera....
そして3.2inchのTFT-LCDまでついてオトクな699RMB!
日本円単純換算でも10000円以下の超格安です(2012/5上旬現在)
本来ならばREDBULLの基板をベースにやるべきですが費用対効果が最高なので購入した
方が早いっちゅーことで…しかもSTM3240G-EVALの回路にほぼ互換なのでSTさん提供
のサンプルなんかもほとんど素で動かせられますのでこいつでいろいろ学習していき
ましょ♥
だめだ私すっかりSTM32漬けだ…
さて、前回さらっとご紹介しましたが、libpngのSTM32F2/4への移植についてお伝え
します。私たち虹メにとってpng形式の画像ファイルはコラ等で非常に身近なもので、
jpeg形式と同じく大量に扱われています。それをマイコンでデコードし表示できる
というのはとても有用性があるわけで、かねてからの悲願がかなった形でもあります。
今回は実際の移植の手順も合わせてご紹介します。
●必要なもの
libpng
これは必須ですね。少し前にlibpngのセキュリティホールが発見されているためバー
ジョンには気を付けてください。今回は"libpng 1.5.10"を使用します。
zlib
pngファイルの実画像データは可逆圧縮されていてDeflateと呼ばれる圧縮技術が使用
されています。libpngはDeflateアルゴリズムを処理するためそのライブラリである
zlibの一部コードを必要としています。今回は"zlib 1.2.6"を使用します。
MCU
libjpeg(IJG Jpeg Library)と同じくlibpngはRAMを大量に消費します。
内部SRAMが96kByte以上あるマイコンならQVGAサイズまでなら何とか表示可能です。
●ファイルI/O
こちらはlibjpeg(IJG Jpeg Library)と同じ要領でChaN氏のFatFsと連動させます。
sirius506氏、そら。氏のlibjpegの移植例を参考にしています。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数の上にあるfatfs_read_data()を読み進めてください(丸投げ！)
●makefileに追加するCソースファイル
こちらのSTM32F4サンプル中にあるlibpng.mkを見ていただければわかりますが、
pngファイルの読み取りのみに限ると以下のファイルだけが必要となります。
-libpng
png.c
pngerror.c
pngget.c
pngmem.c
pngpread.c
pngread.c
pngrio.c
pngrtran.c
pngrutil.c
pngset.c
pngtrans.c
上記のうちpngerror.cは一部内容の書き換えが生じます(後述)
-zlib
adler32.c
crc32.c
inffast.c
inflate.c
inftrees.c
zutil.c
ヘッダファイルの方については念のためオミットせずに全部ぶっこんどいてください。
また、libpngを解凍したディレクトリ中の./scripts/pnglibconf.h.prebuildをリネ
ームしpnglibconf.hとしてソースと同じディレクトリにぶっこんでください。
●ARMマイコン上で動作させるための少しの変更
x86なWindowsシステムで動作させるわけではないため、エラー表示などのコンソール
I/Oの処理のオミットは必須です。
pnglibconf.h中のPNG_CONSOLE_IO_SUPPORTEDとPNG_STDIO_SUPPORTEDの
定義はコメントアウトしておき、さらにpngerror.c中のpng_default_error
関数はfprintfからprintfに変えておきます。
(printfのリダイレクトが必要無い場合はすっからかんでもいいです)
ねむいさんの環境では書き換えたファイルはpngerror_std.cとしています。
20140731追:
↑バージョンが上がってヘッダの#defineをコメントアウトすればよくなりましたので
pngerror.cに手を加える必要がなくなりました。
また、txtとハードウエアの倍精度浮動小数点演算、インターレースのサポートも
行わないのでpnglibconf.h中の以下の定義もコメントアウトです。
PNG_READ_INTERLACING_SUPPORTED
PNG_FLOATING_ARITHMETIC_SUPPORTED
PNG_WRITE_zTXt_SUPPORTED
PNG_WRITE_iTXt_SUPPORTED
PNG_READ_zTXt_SUPPORTED
PNG_READ_iTXt_SUPPORTED
PNG_zTXt_SUPPORTED
PNG_iTXt_SUPPORTED
元からコメントアウトされていたものについてはそのままにしておいてください。
さらにpnglibconf.h中のZBUFFERの確保量(PNG_ZBUF_SIZE)をSDカードのセクタ
サイズである512バイトに合わせてください。これ以上の
値にすると512バイト以上読み込んだ際にエラーになりデコード不可能になります。
また、残念ながらlibpngにはlibjpegのような1/(2^x)にするサイズスケーリングは
ありません。
●libpngを呼び出し、画像データを表示する
大まかに分けて以下の順番で実行します。これらは必須です。
1.png_create_read_struct関数でpngファイル全般を制御するポインタ確保
2.png_create_info_struct関数でpngファイルの情報に関するデータをストアする
ポインタ確保(IHDRとIENDチャンクの分）
3.エラーハンドリングの設定
4.png_set_read_fn関数でfatfsのpngファイルポインタと連結
5.png_get_IHDR関数でIHDRチャンクの読み出し
6.画像の形式を24bitRGBに変換する。
7.画像のx,yサイズのチェック(1280pixel以上は撥ねる)
8.png_get_rowbytes関数で1行あたりのバイト数取得
9.png_malloc関数で"6."で取ったバイト数分の配列確保
10.png_read_row関数でIDATチャンクを一行ずつ読み出し、さらにRGBデータ幅を24bit->16bit
に落としてTFT-LCDに表示していく
11.表示が終わったらpng_free関数"7."で確保した配列を解放
12.png_read_end関数でIENDチャンクを読みだす。
13.png_destroy_read_struct関数で"1.""2."で確保したポインタの解放
気を付けなければならないのは各処理ごとにエラーを検知しておかしい場合は先の
処理に進ませないようにすることです。これを怠るとHardFaultに簡単に陥ってし
まいます。またIDATを読み切ってない場合にpng_read_endを実行すると即座にエラ
ーになりますのでTFT-LCDの解像度より画像サイズが大きい場合でも必ず空読みして
読み切ってください。この手順は24bitのpngを想定していますが異なる形式の場合は
24bitに変換するために"5.""6."の間に各種transformの処理が必要です。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数を読み進めてください(丸投げ！)
一回の表示で消費されるRAMはlibpng自体が必要とする量が約33kByte(デバッガの
追跡により使用量を算出),それに加えてTFT-LCDに表示する際のデコード済みの
データを置くバッファも必要とされるため結局以下の計算式で総消費量が求められます。
NEEDED_RAM_AMOUNT = ((XSIZE-1)*4)Byte+33kByte
式中のXSIZEはTFT-LCDのX軸方向最大ピクセル数ではなくpng画像データのX軸方向
最大ピクセル数です。つまり幅が広くなればなるほど使用するRAMの量が増えます
(libjpegもこの点は同じ)。また、今回のデモはアルファチャンネルを強制付与して
いるため(RGBAのならびになるため)(XSIZE-1)*3ではなく((XSIZE-1)*4)になります。
●実際の表示
今回の検証用のTFT-LCDとして320x480なTFT1P2797-Eを使用します。大規模マイコン
用のディスプレイとしてねむいさんのイチオシです♥
検証用の画像はこちら。こちらのサイトのキャラクタージェネレーターを使って作成した画像に
さらにコラージュを加えた私服のいないさんです。メイド服にコラしたかった
のですが髪型だけで力尽きましたorz…これをTFT-LCDに表示してみます。
ビット深度は24bitのトゥルーカラーです。
表示ルーチンとしてまず画面左上に画像の情報を出すようにしました。
col_depthはビット深度で8*(RGB)で上記の24bitとなります。
col_typeはpngの画像タイプで0がグレイスケール、3がインデックスカラー、
2がトゥルーカラー、6がアルファチャンネル付トゥルーカラーです。
実際の表示に関し、グレイスケールやビット深度が小さい画像も24bitに変換してい
ます。また透過pngやアルファチャンネルつきの物はいったんアルファチャンネルに
変換して、1ピクセルごとのアルファチャンネルを示すバイトは書き込み時に無視して
います。インターレースpngの表示はは私のサンプルではサポートしていません。
誰か腕に覚えのある方実装おねがします…。
てわけでPCとまったく遜色ないレベルでいなちゃんを表示することができました！
メモリが豊富な環境ではpng_read_image関数で一気に読み込みできるのですが、STM32
等のマイコンでは到底足らないので、1行ずつバッファに読みだして表示を行います。
読みだしたデータはRGBの順番で並んでいて8+8+8=24bitで1ピクセルとなります。
最終的にTFT-LCDには5+6+5=16bitにして書き込み、表示させます。
透過PNGを表示させるとこんな感じになります。前述の通りアルファチャンネルは
読み捨ててるので透過部分はRGB(0,0,0)の黒色で表現されています。また解像度の
関係で表示が隠れてしまったのですが、アルファチャンネル付トゥルーカラーに
変換された透過pngを示しています(赤で囲った部分)。
TFT-LCDのサイズよりオーバーする場合の画像では当たり前ですが画面外のデータは
表示できません。また画面からはみ出ている部分もpng_read_rowで全部読み切ってし
まわないとエラーになったりHardFaultに陥ってしまうので注意です。
ChaN氏のbmp表示ルーチンを見習って大きい画像でもUARTからのコマンドで仮想的な
表示開始位置を変えて表示できるようにするのが今後の課題ですね〜
ちなみのこのaraiさんの描いたねむいさんの絵はアダルツなのでこのブログ的にも
見えてない部分は…ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼
減色とかグレースケールにした時の比較です(注：表示の際はすべて24bitのトゥルー
カラーに変換されています。左上の数値は変換前の情報です)。
ビット深度24bitトゥルーカラーの標準的なねむいさんです。
col_depthが8になってますが実際は8bit*3で24bitとなります。
256色のインデックスカラーはこんな感じに。
24bitのグレースケールはこんな感じ。
8bitに落とすとこんな感じ。
さらに4bitに落とすとこんな感じです。
というわけで通常のPCと同じようにpngファイルの表示もSTM32F4上で可能と
なりました。しかしながらメモリはかなり食いますので内蔵SRAMが豊富にある
STM32F4専用の機能ですね〜。
libjpegと絡めると空いた時間でお茶が飲めてしまうくらいビルド時間も
倍加されてしまいますのでご注意ください。
いろいろ試す12
年度末始めになるといろいろ忙しくなります。
私がほしいもの(ハードウエア)は2011年中にあらかた買いそろえていたので
わずかな時間を見つけて目下消化中な現在です。
●NokiaのLCDたち
またまた中華掲示板から引っ張ってきたネタなのですが、もうねむいさん一部の
イカス思想の方々からs**kと思われてるかもしれませんがNokiaのGSM用のLCDは
ebayで非常に安価に購入できます。
その中でも比較的ハードル低そうなのを試してみました。
これはNokia1202用のモノクロドットマトリクスLCDです。コントローラーは
STE2007というものだそうです。ハードウエア的な接続や初期化手順は違いますが
基本としては幅広く応用例があるドットマトリクスLCDの代表格であるNokia5110と
ほとんど変わりません。
バックライトもついてますが10mAだとちょっと明るすぎですね。もう少し電流
絞れると思います。
接続はi2cではなく9bit3wireなシリアルのみです。
端子の部分を拡大。
半田付けになれてない人もこれなら何とかいけるでしょう。
ebayでは最安3$前半くらいから購入できます。
こちらはNokiaのC1-01という機種で使用されているTFT-LCDです。
128x160のQQVGAサイズです。
安価なTFT-LCDモジュールのうちホビイストにも手が届くものは数年前の型落ち
品やユーズド品しか回ってこないものですがなんと2011年製のさらぴんでした。
端子の形状は先ほどのNokia1201とほぼ同じ感覚です。またLCDのバックライト
電圧は3.2Vなので非常に扱いやすいです。
動かしてみました。
光のムラはちょっと多いですが、さすが2011年製だけあってコントラストはよい
ですね。こちらも9bit3wireのシリアル固定です。LCDのコントローラはSPDF45124Bか
もしくはHX8353-Cと思われます(両者とも初期化手順・コマンドは同一)
ちなみにebayで買うときの注意ですがこの液晶、大体相場は8$前後で売られて
いますが形がよく似ていてピン配置も同一のものが半額くらいで売られています。
これは別のNokiaの液晶でTFTではなくCSTNなのでご注意ください(SPDF45124Bの
初期化手順と全く同じものが使えます)。
●新たなARMマイコン基板
去年の秋くらいにLPC1788の載った中華基板を購入していました。現在主流になって
いるSTM32F4と比べると見劣りはしますが、それなりの性能は持っています。
外観はこんな感じです。
OpenOCDは既に対応しています。私の公開しているスクリプトファイル群はもちろん
書き込み・デバッグまでサポート済です！
さて、LPC1788はLPCXPressoの最高品種LPC1769版には存在しないMCIインター
フェースがあります。LPC2388にある奴と同じですね。
レジスタの構成もほぼ同一です。
LPCWAREのサイトにはLPC1788のMCI対応のFatFsのサンプルがあるにはあるの
ですが、残念ながら全くと言っていいほど使い物にならなかったのでChaN氏の
LPC2388用のMCIドライバを参考に移植にチャレンジしてみました。
Cortex-M3以降はアンアラインド転送が(速度低下しますが)許容されていて
ごく単純なブロック転送ルーチンで事足ります。DMAのバッファから4byte
単位でメインメモリに高速にコピーするアセンブラのルーチンをこしらえて
みました。
LPC1788のMCIクロックはPCLKが支配的かつ24MHz以下を要求されるため120MHz
だと設定上許容されるクロックは20MHz(PCLK=120MHzの時)になります。
MCUのクロックを少し下げ、CCLK=PCLK=96MHzの時だとMCIクロックも24MHzが
設定できます。
読み取りスピードはこんな感じです。LPCWAREの奴よりは安定しましたが、
残念ながら一部のカードはMCIクロックを大幅に落としても認識ができないものが
ありました。中途半端ではありますが同じくLPC1788を触られている他の方たちが
安定化してくれる事を期待して…白旗
20120905追：
安定化しました。安心してお使いください！
20230814追:
LPC4088を参考にしてください。
●公開している記事とかプログラムの見直し
私の記事は"ねむいさんの方法だと全然うまくできなかったけど(他の人が公開してる)
方法だと一発で出来た！"というご意見が圧倒的に多いですorz
ねむいさんは事態を重く見て、書きっ放しで放置せずに他の方が試して
引っかかった点を調べて即座に反映するようにしています。正直いつまでも
環境構築ネタなんかに留まってるとほんとに進歩出来なくなってしまうん
ですが、MTMとかの展示系やロボット等の競技系に参加するつもりは今後も
無いので最初のとっかかりとなる情報・ノウハウくらいはケチらずに
公開していく所存でございます。
↑英語圏漁ればこの程度の情報いくらでも転がってるだろっていう突込みは無しで!
ついでにFatFsの移植した例がどこにあるのか分からないとご指摘いただき
ましたので少し前から目立つ場所に日本語以外でもわかるようにリンクを
明記してます！
●そういうこともあって
私も一か所にとどまらずに新たな一歩を進んでみました！
おきぱではすでに対応したコードを公開していますが、STM32F2/4系にlibpngの移植
を行いました！詳細は次回に！
STM32L-Discovery(STM32LDISCOVERY)をいろいろ使う
…ッッ…や、やっとEtherPod(STM32F107VCT6)にFreeRTOSとuIP実装してその上に
DHCPクライアントとDNSレゾルバとHTTPDとそして目的のNTPから時刻合わせ機能
の実装まで完成した…！uIPやFreeRTOS付属サンプルだけだとこんなん絶対でき
ませんわこれ…。先達たちがネット上に残した知恵を探しだすスキルが鍛えられました。
とにもかくにもこれで漸くこの子を卒業してSTM32F4系EthernetとLwIPに手を…！
ところでなんで去年の9月にできたこともう一度やってるかと言うと、ソースコード入
ったUSBメモリを地下鉄の溝に落っとこして壊してしまって１から全部作り直しになっ
たからです‥‥‥‥orzｶﾂｶﾂに作りこんでてバックアップをサボってるときに限ってこ
ういう事が起こるというorzorz
ちなみに虹裏上の活動で作ったり描いたりしてきた絵やとしあき君&｢｣からの大切な頂
き物は、4重のバックアップ体制で自宅が爆発しようが京都府に巨大隕石が落ちてクレ
ーターになろうが核の炎に包まれてシェルターにどう詰めてもあと二人しか入らないと
言われた瞬間にケンシロウに｢ﾄｷ兄さん!｣と言わせる間も与えずｸﾞｺﾞｺﾞｺﾞｺﾞと扉閉めてあげ
て二週間後にや、やぁ…と余裕こいて挨拶できるくらい絶対に失わないようにしてあ
りますのでご安心くださいまし(ﾆﾔ･･)。
さてさわりはこの辺にしといて前回ほんの少しお話したSTM32L-Discoveryにごく基本
的ないつものを実装したのでご紹介します。
Discovery系で比較される対象はSTM32F100RBT6が載っているSTM32VL-Discovery
ですが、実際はこちらのSTM32L152RBT6が載ったSTM32L-Discoveryの方がはるかに
性能が高いです。
↑ねむいさんが目を付けためぼしい機能比較
STM32L系のほうが後から開発されたので当たり前と言っては当たり前なのですが、そ
のせいかバスの構成やペリフェラルのレジスタ構成などはSTM32F2/4系のMCU群と酷似
しています。私もそうでしたが、移植される方はSTM32F2/4系からのほうが楽です。
今回のいつもの(= FatFs + TFT-LCDドライバテストプログラム)について、当基板に
タッチセンス用のパタンとSTマイクロ謹製のSTM32L向けタッチセンスライブラリが用
意されているのでこちらも入力系に組み込んでいます(基本はUARTの入力のみです)。
お肌が乾燥してるとタッチセンスの入力が無反応になることがあります。S**Kです。
使用するピン/ペリフェラルの構成としてはSTM32VLDiscoveryの時となるべく似せる
ようにしてみました。今回もI/Oリソースの有効利用のためにSWD接続のみで書き込み
デバッグを行うようにしました。STM32L152RBT6は外付けの水晶を付けるとUSBも使用
できるのでこちらも試してみたいと思います。図中のLCDとあるのはLCDグラスドライ
バのことではなくいつものMCU接続タイプのTFT-LCDを指します。
あと使ってて気づきましたが、クロック周波数や多ピン品種の外部バスサポートとか
の超低消費電力とかのうたい文句見てるとXMEGA系みたいな8/16bitのアーキテクチャ
で大規模化したマイコンを潰しにかかってるなぁと感じましたね。どっちも使ってい
る私が言わせてもらうとどう見てもARMのほうが扱いはるかに楽なんですもん…
FatFSのDMA化も楽にできましたし！(←まだ根に持ってる)
動かしているところです。ChaN氏のファイラは上述のとおり定番のUARTの他に基板上
のタッチセンスパタンからも入力可能です。タッチパネルTFT-LCDモジュールの時と
微妙に勝手が違うので差の吸収するために入力方法に工夫してあります。
既におきぱにある他のマイコン向けのデモも順次更新していますが、がた老氏が私の
移植例を使って成功したのを受け、デモ内のファイラにChaN氏のTextファイルビュー
アも盛り込んでいます。(STM32F107系は先行して公開してます)
ついでですが、XMEGAのFatFsのサンプルも大幅更新してます。ChaN氏の最近の実装を
参考にファイラをVRAMを使用しない構成とし、以前は出来なかったQVGAの解像度でも
ファイラを使用できるようになってます。もちろんTextファイルビューアや動画も(遅いですが)
再生可能になりました！
またまた話が逸れますがFatFsのSTM32・LPC2388(LPC1788も近日公開予定)・XMEGAへの
移植例としてChaN氏からリンク貼ってもらってるおかげで海外からのアクセスがうな
ぎ登りになってます。その9割が共産圏(元共産国含む)なのは置いといて海外から来た
人たちのためにリンクをわかり易くしました。これでもう"HENTAI-Siteに飛ばされた"
とは言わせませんよぅ！
日本国内についてはどうかというとアクセス解析やSNS等の発言をリサーチした限りでは私
の作例を参考にされてる方はlinux系OS使いな方たちが圧倒的です。Windows系の場合、
無料で利用できる統合開発環境はかなりの選択肢が存在しています。はじめてSTM32を
触る方々にとっては私のコマンドラインビルド中心な"どういう風にプログラムを組むか"
が主体のブログは全く参考にならずむしろ"その統合開発環境をどう使いこなすか"ことこ
そが往々にして最重要課題となるので、中身のないこと長々と書きましたが私は素の
Eclipseは使いませんったら使いません！！１！メーカお仕着せのやつでも拒絶反応ｇｇ
はぁはぁ…失礼…また話が逸れてしまいました‥
ぇっと後は書き込み/デバッグについてですが、前回ご紹介した通りSTLink/v2に対応
したOpenOCDからすべてを行います。また、私の作例中のmakefileをみたらすぐにわか
るはずなのですが、各デバッガハードウエア&MCU向けのcfgを引数にとってさらに
cfgに記してあるフラッシュ書き込み用のプロシージャコールを呼び出せばtelnetを接
続してﾁﾏﾁﾏしなくてもOpenOCD単体でフラッシュに書き込みができます。
↓STLink+OpenOCDから書き込むとこうなります。
(この記事を書いた当初はLibUSBを使用しておりました)
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32lx_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
1 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Info : clock speed 1 kHz
Info : IDCODE 2ba01477
Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bf74 msp: 0x20004000
auto erase enabled
Info : flash size = 128kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
wrote 114688 bytes from file main.elf in 12.796548s (8.752 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
verified 111172 bytes in 0.515612s (210.558 KiB/s)
shutdown command invoked前回触れたAsynchronous Algorithmルーチンはすでに最新のコミットに取り入れられ
ています。
確認も終わったのでSTM32L-DiscoveryのSTLinkもVersaloon化しちゃいました！
ローダ共にSTM32F4Discoveryのものと全く同じのが流用できますが、こちらに
STM32LDiscovery用のを用意しましたので興味のある人はどうぞ。
するメリットはUSB仮想COMが使用できる点に
尽きますね♥
※大事なことなので何度でも言います
あと注意点ですが、STM32LDiscoveryは外部リセット入力回路のプルアップ抵抗が省略
されています。R37に10kohmのチップ抵抗を必ず付けてください。
↓Versaloon化+OpenOCDから書き込むとこうなります。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32lx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
Info : OpenOCD runs in SWD mode
100 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x34)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x00000008:0x00000040:0xC0000006
Info : clock speed 100 kHz
Info : stm32l.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bcb8 msp: 0x20004000
STM32L: Enabling HSI
2000 kHz
auto erase enabled
Info : flash size = 128kbytes
wrote 110592 bytes from file main.elf in 17.983915s (6.005 KiB/s)
verified 110492 bytes in 1.140595s (94.602 KiB/s)
shutdown command invokedんんｎ、現在の実装だとswdのクロックを途中で高速に変えられないので
ちょっと微妙ですね…128kByteしかないしまぁいいですか。
正直言うと素のSTLinkでもかなり使い勝手がよくなったので初めて触られる人は
無理にVersaloon化しなくても十分やっていけます。
いやはや良い時代になったものです。
OpenOCD0.6.0を使ってLPC1114に書き込み＆デバッグする為のめそっど
20160311追：
もう4年前の非常に古い記事ですがアクセスがいまだに多いので補足します。
LPC1100(u系も含む)をOpenOCDで書き込み・デバッグしたい場合は、
ねむいさん謹製のcfgファイルlpc11xxx_swd_flash.cfgをお使いください。
現在はLPC1100系は上記のファイルですべてカバーできるようになっております。
上記cfgファイルを含むねむいさんがビルドしたOpenOCDのバイナリはこちら。
SWD接続が可能なデバッガハードウェアVersaloonは、STM32使いの人たちの間では
オープンソースでSWD接続が手軽に利用できる数少ない手法の一つとして重宝されて
いますが私のぶろぐにもコメントをよくいただいている竹本氏のVersaloonに関する
記事が2012年2月号のトラ技に紹介され、さらに多くの注目が集まるようになりました。
ちなみに記事最後の参考文献の所でトラ技名物の誤植どころか段落が下の段落に
めり込んでめちゃくちゃになって肝心なURLがわからなくなってしまっているのですが
記事を書いた竹本氏は何一つ悪くないです。悪いのはチェックが毎回適当で誤植や検証
もせずにいい加減な記事のせてるCQ出版のほうなんですから！！１１！(憤怒
野獣と化したカンガルー先輩に喝入れ直してもらった方がいいと思います。
いちおう丁寧に文章がぐちゃぐちゃになってる箇所をご指摘して差し上げたのですが、
もちろんお詫びと訂正には反映されませんでしためでたしめでｔ…たくねぇ！
はぁはぁ…すみません話逸れ過ぎました…。
NxP社のLPC1114に代表されるCortex-M0系デバイスはデバッグ用ポートにJTAGは
なくSWDしか存在しません。おまけにOpenOCDのCortex-M0系コアのデバッガの
実装はSWDしか接続方法がないゆえに手が入っておらず、またまたおまけに
Cortex-M0系コアの実装がまだ不完全ゆえにフラッシュ書き込みルーチンも
不完全と３重苦となっています。
しかしながらCortex-M0系のコアはCortex-M3系コアのサブセットなのでほんの
少しの箇所の変更で何とかできるようになります。
また、当たり前のことですが多くのCortex-M0デバイスはSWDしか存在ないので
SWD接続が可能なVersaloonもしくはSTLink/v2必須です
20120712追：
公式でCorte-M0がサポートされるようになりました♥しかしワークメモリが少ない
LPC11U14はopenOCDのビルド時にフラッシュ書き込みのソースにパッチを当てる
必要があります。こちらの手順をご覧ください。
以下の話はVersaloon対応のOpenOCD(0.6.0)がビルドできる環境&ビルド時の多少の
トラブルを回避できる能力を持ってる人対象です！ここでようやく本題！
●LPC1114(Cortex-M0系)専用のOpenOCDを作る
１．先ずはノーマルで動作を確認
gitからとってきた新鮮なOpenOCDのコードにVersaloonのパッチを当ててビルド、
LPC1769やLPC1343にSWD接続で繋がりフラッシュの書き込み/デバッグが正常に
できてるかチェック。問題があれば不具合のないコミットまで巻き戻そう！(逃
2012/01/26現在は私はこれで動作確認しました。あと最近のコミットはSTM32F2/4
系で大バグが作りこまれていますが後述
２．ソースコード修正
openocd/src/target/cortex_m.c内の2025行目あたりにある下記の内容
/* Cortex-M3 has 4096 bytes autoincrement range */
armv7m->dap.tar_autoincr_block = (1 << 12);
を
/* Cortex-M0 has 1024 bytes autoincrement range */
armv7m->dap.tar_autoincr_block = (1 << 10);
に書き換えて再ビルド。
これでLPC1114(Cortex-M0)専用OpenOCDができました。めでたしめでたし。
この中にも上記修正他をまとめたcortex_m0.patchがあります。
３．といいたいところですが
OpenOCD+VersaloonでLPC1114を動かすための特別なスクリプトファイルを
意する必要がありますね。
既に私がフラッシュ書き込みルーチン付きのものを用意しているので、
こちらを使ってくださいね。
ただ注意すべき点は、私も過去に何度も述べてきたNxP系のARMマイコンに存在する
CheckSumValidationです。LPC1114もご多忙にもれず"calc_checksum"を付与
して自動計算した値をフラッシュの所定の番地に書き込んでおかないとユーザ
プログラムが実行されずISPの番地に勝手にすっ飛んでしまいます。
calc_checksum付けなくても前もって計算結果を埋めこんどいてもよいです。
これはmbed等のクラウド環境から離れ初めて地に降りた時"動くはずのプログラム
が動かない"とよく引っ掛かるポイントです。ねむいさんクラウドよりもセフィロス派
なのでmbedはとんと興味ないのですが大事なことなので何度でも言います。
４．LPC1114以外のCortex-M0のマイコンでは可能か？
LPC1227:
->できるじゃない！
同じCortex-M0系のLPC1227も書き込み&デバッグが可能です。しかしLPC1227は
リセット直後はウオッチドッグがONになっているせいかデバッグが途中からに
なってしまいます。うまく動く組み合わせを検証中です。
20120210追：
OpenOCDでattachした直後に一旦ISPのアドレス(0x1FFF0000)に飛んでから
実行するとmain関数の先頭で停まるようになりました！
このスクリプトファイルは公開しております。
LPC11U14:
->できるじゃない！
LPC11U14はフラッシュ書き込みに必要なワークメモリの最小値がどうしても確保
できず、書き込みはできませんでした。フラッシュメモリの消去のみと別な方法
でフラッシュに書き込んだ後デバッグ動作はできます。
20120530追:
LPC2000.c内のマイコン内ワークメモリアロケ―ターの下限値を下げることに
より書き込みが可能なことが分かり、パッチに反映しています！
STM32F0:
->余裕でできるじゃない！
NuvotonのNUC120はvsprogのほうは対応されたのでOpenOCDももうすぐですね♥
尺が余ってしまいましたので小ネタをいくつか
●最近のOpenOCD(0.6.0dev)でSTM32F2/F4系のマイコンにつないだ瞬間に
OpenOCDがセグメンテーションフォールトする
とあるコミットからFlashSizeRegisterなるメモリアドレスにSTM32F2/4系の固有値と
して書き込まれているらしい内蔵フラッシュメモリの実サイズ値を読みだして設定
するという実装に代わっていますが…こいつがでたらめな値を引っ張ってきて設定
しやがるため即ひでぶしやがります…。
"私の環境では問題ないです"とおっしゃられてる方もそういわずに100kByte以上の
バイナリ作って書き込んでみてください。おそらく最初に作りこんだときにLED点滅
するだけのような10kByte以下のバイナリのサイズでしかチェックしてなかったので
ひでぶを免れていただけだったのでしょう。
なんでこんな変なことしてるんだろうと思ってSTM32F4のリファレンスマニュアル
(Doc ID 018909 Rev 1)を参照すると…
先ず0x1FFF7A10に各チップごとに固有のuniqueIDがあって
次に0x1FFF7A10に16bitサイズのFlashSizeがストアされたれじすｔ…
…アドレスが被ってる!?
なんかドキュメントが変ですよこれ！？
てわけでねむいさんの虎の子のOpenOCD+InsightでSTM32F407ZGT6(RevY)に接続し
該当するメモリの付近を捜索してみましたが…
…アドレス0x1FFF7A22に0x0400(1024kByte)が見える…
これが本物のFlashSizeRegisterかしら…
念のため手持ちのSTM32F2/4系のマイコン片っ端から引っ張り出してアドレス
0x1FFF7A22の値調べてみました。私の手持ちはすべて1024kByteの品種なので、
このアドレスが真のFlashSizeRegisterならば全部0x0400(1024kByte)にならな
ければなりませんがはてさて…
STM32F207VGT6(ES) :0xFFFF
(現在のOpenOCDの実装は0xFFFFだと1024kByteを想定して書くのでセーフ)
STM32F207ZGT6(RevY) :0x0400
STM32F407VGT6(RevA) :0x0400
STM32F407ZGT6(RevA) :0x0400
…ビンゴかよ…ES品の207VGT6は仕方ないですが。
とりあえずOpenOCDとSTMicroの中の人にメッセージ投げときましたけど気づいて
くれるでしょか???だめだったらフォーラムにも。
20120214追:
STから問い合わせ結果返ってきました。やはり0x1FFF7A22が正しいです。
リファレンスマニュアルも後日差し替えしますとのことです。
また、OpenOCDのほうも対応してくれました。
●aitendoさんのTFT-LCDモジュールを使う
そうだよまただよ
こっちとこっちは至ってごく普通のモジュールなんですが、TFT2P0327-Eのほうは
Vledが3.2VtypではなくLED2個直列つなぎの6.2Vなんです…データシートが3.0~3.4
って書いてあっておもいくそ間違ってます。まぁチャイナクオリティ(ry
といいたいところですけどねむいさんが買った3つがたまたまTFT2P0327-Eにくり
そつの別のLCDモジュールだったかもしれませんし大陸系の店は何があるかわから
ないんですけど買ったの今のところ私だけみたいですからまぁいっか…
半透過式の液晶なので視野角が広く太陽光下でもそれなりに見える代物らしいです
東海自然歩道を徃く12(岐阜市内〜犬山/犬山〜定光寺)
京都から遠く離れてくると移動も時間とお金が掛り辛くなってきます。
特に岐阜県ステージは中途半端な距離にあるため、交通手段の事前調査や
現地での移動時の時間配分等のタクティクスを十分に練らないと
"往"けなくなってきます。てわけで今回の2行程はねむいさんの頭で
考えに考えて40km以上の距離を一気に走り抜けるプランをおっ立て
実行しました！
●2011.12.14 岐阜市内〜犬山
新幹線を奮発して朝早くに出発して岐阜駅に来ました。
岐阜駅バスターミナルにて。岐阜市内はバス王国です。
前回の則松バス停の接続が悪いので犬塚と言うバス停からスタートし、
まず則松バス停へ。
振り返って岐阜刑務所を。
川沿いを少し走った後住宅街を抜け才峠へ。
おれじゃない
あいつがやった
しらない
すしなう
三田洞弘法で昼食を兼ねた小休止です。
東海自然歩道を少し離れ百々ヶ峰頂上へと向かいます
百々ヶ峰頂上と眼下に流れる長良川です
白山展望所の所にある分岐は見落としやすいです。
松尾池分岐を過ぎて妙に険しい岩肌を越えると
長良川の展望が開かれます！
そこを降りると自然歩道が消滅していました…
千鳥橋です。
住宅街を抜け、名鉄下芥見駅跡(現バス停)に。
老洞峠は舗装された車道です。
天狗谷遺跡のあたりでようやく車道とお別れ。
寒洞池のこの道標の通りに進んでしまうとルートミスです。
水が抜かれた寒洞池。
通り抜け不可の所を進まないと先に進めません！
水辺の道(木組の遊歩道)は老朽化し通行厳禁の警告看板が。
そこを抜けるとマウンテンバイク用の道が倒錯する憩いの森改め"迷いの森"
に!道標が間違えやすいですがとにかく下ってください！
自然遺産の森はどう進んでいいかが全く分かりません。
とりあえず広場に出たら矢印の方向へ。奥まで行くと
東海自然歩道(と他登山道)の通路があります
ここも道標の通りに進むとルートミスです。
まっすぐ直進が正解。
車道に出ると後は下り一本道なので一安心。
日の出不動です。
大安寺付近で地図を読み誤り痛恨のルートミス…
何とかルートに復帰…
ライン大橋に。もうじき日が完全に暮れます…。
ライン大橋とライン大橋からの日没を。
完全に日が落ちた後に犬山城の入り口に到着。この辺りの地理は私は
詳しいのでもう迷いません！
犬山橋と犬山橋を渡ったに振り返って犬山城を。
50km以上の道のりを越えてJR鵜沼駅に到着です！
●2011.12.30 犬山〜定光寺
この日は前日に名古屋で泊まって早朝に出発するプランを立てました…日帰り？
犬山遊園駅を出て前回離脱した犬山橋から。
もうすぐ日が昇る木曽川。
犬山ユースホステルを越えて寂光院へ。
石段を登った先にある寂光院本堂とその周辺の建物です。
寂光院を出たら岩肌があらわな山道を越えて継鹿尾山頂上に。
その後アップダウンを越えて恵那ルートとの分岐点へ。
次回は善師野駅からこの分岐点を目指します。
名鉄善師野駅への分岐と名鉄線を見送ります。
ここから入鹿池まで舗装路と非常に走りやすいトレイルが
続きます。
…、が歩きやすすぎる道ゆえにマウンテンバイクを乗り入れる輩が多く
警告文が。
ピークを越えて下った先に鞍馬寺教会なる建物が。
入鹿大橋と入鹿池です。
八曽キャンプ場に。ここの川も水がとっても綺麗です。
丸山橋を通過した直後のこの分岐は間違えやすいので注意！
この辺りもマウンテンバイク乗り入れ禁止の警告文がちらほら
にもかかわらずマウンテンバイクの集団と何度かすれ違いました。
時間に余裕ができたので内津神社に寄り道しました。
ついでに昼休憩です。
車道を通行して内津峠で東海自然歩道に復帰しました。
振り返る土砂崩れ…
鉄製の階段を上ってさらに車道を上がって
東海自然歩道の中では人気のハイキングコースに。
いきなり脅しをかけてきます…
弥勒山、大谷山、道樹山と次々に縦走していきます！
モグラ穴？
絵峠を越えた先の木階段がヤバい…
玉野遊園地に向かう山道は苔むした石が多く滑りやすいので注意です
御嶽神社と玉野遊園地？です。
うっそうとした森を抜け春日井コースの出口に。
城嶺橋を抜け(橋の真ん中で写真撮ったけど)、JR定光寺に到着です！
JR中央線に乗り名古屋に帰還します。
この２行程でかなり距離を稼いで遠くまでやってきました。
これから先も交通手段が厳しくなってくるので今以上にうまく
やりくりしないと難しいでしょうね…。
と言うわけで今年もギリギリの更新になってしまいましたがよいお年を〜
則松〜犬山
犬山〜定光寺
東海自然歩道を徃く11(東津汲〜横蔵/横蔵〜岐阜市内)
関西圏では毎秋になると"秋の1Dayパス"というすごい便利なチケットが
販売されています。11/30まで利用可能だったのでスケジュール詰め詰めで
行けるところまで行ってみました。
それと今回の行程からみちびき(QZSS)対応のGPSモジュールPA6Cの
運用試験を開始です。2011年現在は日本の準天頂衛星システムは
みちびき一基のみで運用されており、その精密な補正機能は1日の
うち8時間しか恩恵を受けられませんがはてさて…
●2011.11.27 東津汲〜横蔵
今回で揖斐駅ともお別れです!(のはずでした…)
コミュニティバスに揺られること40分、前回のエントリポイント
東津汲のバス停に到着です。そそくさと移動の準備を進めます。
そしてこれがっ
QZSS対応のMT3339が使用されているGPSモジュール、PA6Cだぁああっ！！
ちなみにQZSSが極まってないとUP-501と補足性能は全く変わりませんが、
全体的な消費電流はさらに改善されています★
まずは小津集落を抜け、下辻峠を越えてミイラ堂がある横蔵寺に向かいます。
巨大な鉄管をくぐり…
小津トンネルわきの遊歩道を走ります…しかし…
遊歩道は一昨年の土砂崩れで埋まり跡形もありません…
基愛氏の2007年のレポートと全く違っています…
しかしまだまだスタート地点、こんな程度で踏みとどまるわけには
いきませんでした！そのまま飛び込んでいきます！
(…やっぱ走らずここはおとなしく歩こう…)
急に視界が明けたと思ったらと遊歩道のアスファルトの法面がごっそり削られて
いる場所に出くわしました。勢いよく飛び入ったらそのまま落ちて死んでましたね…。
その後も土砂崩れの後を乗り越え小津トンネル遊歩道を抜けてやっとこ小津の
集落を抜けると東海自然歩道通行止めの看板と不自然な東海自然歩道の道標が
ありました。…これは…
自然に朽ちたわけでもなく下辻峠への道標の板が故意に取り外されています。
東海自然歩道の行程でこんなのはぢめて見ました…。
湯の山温泉の時だって通行止めでも余裕で通れたから大丈夫っしょと思って
小津橋を渡りましたが…
…橋を渡った先にあるはずの道標もきれいさっぱり撤去されていたようで、道をおも
いくそ読み誤り1h30m以上ルートミスしてしまいましたorzorzorzorz
変な道に入る私を対岸で偶然見かけてわざわざ車で追っかけて権現山に間違って
登るのを阻止してくれた上に正しい道まで教えてくださった農家のおぢさん、本当
にありがとうございます…
…さて小津橋を抜けたところから再開です…
もう12:30だわ…どう頑張っても神海駅まで到達できませんorz
とにかく行けるところまで行くことにしましたが、東海自然歩道通行止めの警告が
しつこく出てきてさらに進んで山道に入ると倒木の嵐が!!
ぐわー
とうとう踏み跡も消滅しました…この時点でルートミスを取り戻すために
駆け下りてきたのが災いして足が攣りまくってます…
とにかく上に上に上がって登山道に復帰しましたが
下辻峠の直前でまたすごい崩落が！！！
落ちたら大怪我覚悟で渡り切りやっと林道が横切る峠に。
ここからは下りで一安心♥
と思ったらまた倒木！！
ルートミスしたのと倒木だらけでイライラしてきてこの人間の力で何とかなり
そうな倒木に助走付けて思い切り虹弦流・や○ざキックかましたのですが、蹴
りぬけた着地点の10m先でハンターの人たちが立ち話していてものすごく恥ず
かしい思いを///
もう熊とかそんなの気にしてる体力ありません…
その後はアスファルトの道を通過して横蔵寺に。到着時刻がすでに14時を過ぎていて
先に進む気力もなくなったのでここで離脱としましたorz
てわけで谷汲もみじ祭りの真っ最中だった横蔵寺(ミイラ堂&瑠璃殿特別拝観300円
以外はすべて拝観料無料!)のギャラリーをお楽しみください↓
さて、たっぷり写真も撮ったし着替えもしたしとっとと京都に帰るか…と
思ったのですが帰りの名阪近鉄バスが16:20と1時間以上も余っていたので…
せっかくだから車道を歩いて谷汲山華厳寺に行くことにしました！
気温は低いのですが無風だったおかげで少し汗ばむくらいです。
山間部は日が暮れるのも早い…
そして谷汲山華厳寺の参道入り口に到達した瞬間に名阪近鉄バスと落ち合いました！
参道に入ると"いのりちゃん"がおでむかえです。
ねむいさんは黒髪ぱっつんのストレートロングな髪形の娘はすべていないさんに
見えてしまうハードウエアがじっそうされｔ
横蔵と同じく谷汲もみじ祭りの真っ最中だった華厳寺(拝観料無料!←これ重要)の
ギャラリーもお楽しみください♥
すっかり日が落ちてしまいましたが華厳寺の参拝も終えて今度こそ帰路に。
(…いのりちゃんのえろす絵もネットの広大な海を潜るとあるんやろな…gff)
揖斐駅行きのバスを待つうちにすっかり真っ暗に…
揖斐駅とはもう一度お世話になるはめに…
●2011.11.30 横蔵〜岐阜市内
1Dayパスが使えるのは今日が最終日です！そして岐阜ステージの要所
となるJR&養老鉄道大垣駅ともお別れです。
養老鉄道揖斐駅とも今度こそお別れです！
横蔵のもみじ祭りが11/30が最終日でした。
人が多くなるため横蔵の一つ前のバス停が臨時の終点です。
十分にストレッチをして横蔵寺山門からスタートです！
しばし前回のおさらいからどうぞ。
ミイラ堂&瑠璃殿手前の道標が今回の目標の妙法が岳&華厳寺奥の院への
山道のスタートとなります！
横蔵寺からスタートなので体力も十分で九十九の山道もサクサク登ります。
旧横蔵の寺領につきました。仁王門跡です。
馬場跡です。
かなしいエピソードがどうたらこうたら書いてますが
先っちょの形状がちょっと卑猥な稚児が岩です。
熊谷直実という今でもいそうな名前の人のお墓です
旧横蔵寺の本堂跡です。
本堂跡を出てすぐにシャクナゲ平が。
数多くのハイカーを苦しめた妙法が岳へのアップダウンの連続が始まりました！
ねむいさんは４足獣歩行体勢で脚部の消耗をおさえつつクリア
アップダウンが収まってくるとそれっぽい石があります。
写真奥の男性の方たちに妙法が岳山頂はここですかと聞くと、"わしらも
よう分からんかったからとりあえずここで昼飯にした"とのこと
さらに進んで鉄塔を越えた先に今度こそ妙法が岳の山頂が！
山頂を越えると今度は急激な下りが始まります。
どんどん下っていくと華厳寺不動尊堂が。
そして華厳寺奥の院に到着です。
華厳寺奥の院を離れ、さらに下って今度は華厳寺への
分岐まで行きつきました。前回参拝したのでそのまま
樽見鉄道神海駅を目指します。
淀坂峠です。
夏の落し物。
トレイルがアスファルト舗装の道路に変わりました。
ここから先はすべてアスファルト舗装の道になります！
神海橋です。
神海橋を渡ってすぐの分岐点で左折が正解らしいです。
直進しても樽見鉄道沿いに北上すれば神海駅に行きつきます。
神海駅に到着です。喫茶店は無くなっていました…。
駅構内や大垣方面の線路を。
ここで行動食と水分を補給し小休止した後岐阜市内に向けて
再び走りだしました。
道標が少なく迷いやすいという前情報が散見されたので
神海駅から先は詳細なマップを紙に刷り出しておきました！
本巣にあるハリヨで有名な湯の古公園だそうです…
？？？これ？
ついに岐阜市内に！鹿穴峠も舗装路なので一気に駆け抜けます！
下雛倉にある龍峰禅寺です。
ひたすら車道を下って行く途中に見えるかどやがぬふぅ！
則松バス停までやってきました。ちょうどいい時間いいタイミングで
バスがやってきたので今回はここで終了としました。
バスを乗り継いで１時間…私もついに岐阜駅まで来るようになりましたか…！
というわけで今回の2行程の軌跡はこんな感じです。
さて、みちびき対応のPA6Cさんはルートミスしてる最中でも
しっかりと仕事をしてくれていました…
東津汲〜横蔵 ログ
横蔵〜岐阜市内 ログ
時間がへんてこりんになっていますが調査中です…
多分UTCじゃなくてJSTで記録しちゃってるかなこれ…
同時に記録しているスポーツガイドメイトGP-101(CANMORE)との分かりやすい
捕捉性能の比較をお見せします。もう"ダンチ"ですね〜♥
ぇ？肝心の山の中の捕捉はどうなんだって？
…ごめんなさい私も合ってるんだかずれてるんだかよく分かりません…
とりあえずPA6Cが普通にﾊﾞﾘﾊﾞﾘ使えるのが分かったので細かい検証は
次回以降に(丸投げ！)
STM32F4シリーズを使ってみる4 -STLink/V2をversaloon化-
20231002追:
10年以上前の記事となり現在では有効ではないリソースが多数あり、
Versaloonはお勧めいたしません。
もしそれでもどうしてもVersaloonをやってみたい方はメールをください。
20231002追:
Versaloon本家がSTM32F4対応したのを受けて今回はSTM32F4 Discoveryに
仕込まれているSTLink/V2をSWD接続方式のVersaloon化する方法を紹介します。
もう何度も行っていますが、Discovery系の基板をVersaloon化したことによる
メリットは以下の通りです。
1.書き込み・デバッグにOpenOCD(ただしVersaloon対応にビルドしたものに限る)
が利用できる。
2.VersaloonのファームウエアにUSB-CDCも仕込まれているのでUARTの
通信手段を別途用意する必要がない。
3.Versaloonはソフトもハードもファームウェアも無償で利用できるので
自分の好きなように改造できる。
と言ったところでしょうか。ねむいさん的には"2."が実際のデバッグや情報
表示等にかなり使えると実感しています。
●Versaloon化手順 on STM32F4-Discovery
概念についてはこちらとこちらで詳しく紹介しているので基本的な部分は
はしょりますが、Versaloon化するSTLink/V2(STM32F103C8T6)にいつもながらの
DFUブートローダを仕込んでおいてその後にversaloon本体(DFUファイル)を
書き込みます。
DFUブートローダのバイナリはUARTブートローダ若しくはSWD経由でフラッシュに
書き込みを行います。各々の方法も基板に下準備が必要です。
1.SWD経由でDFUブートローダを書きこむ場合
SWDで書きこむ手段として今回はvsprogを使用することにします。
用意するものはVersaloon化したSTLinkですが素のSTLinkでも書き込むまでの
下準備は同様です。
まず基板をひっくり返して写真の箇所のジャンパ抵抗をそれぞれ移転させます。
上記写真の要領でSWCLK,SWDIO,GNDをそれぞれ接続してください。
STlink/V2が仕込まれているSTM32F103C8T6にはReadProtectionのヒューズ
ビットが掛かっていて、これを解除しないとフラッシュの書き換えが
できません！
これはOpenOCDのflash unlockコマンドでも解除できません。
2013年現在ではstm32f2x.cにバグ修正が入ったのでOpenOCDからでも解除
可能です。
vsprogを立ち上げSTM32マイコンを認識したら上記画像の要領でヒューズ
設定を行ってください。エラーが出まくりますが無視してください。
この状態でWriteを押すとエラーが出まくりますが無視して書きに行って
ヒューズを消すことができます。
その後はこちらに用意したSTM32F4Discovery用のDFUブートローダ
(の中のmain.hex)をフラッシュに書き込み、ベリファイまでエラーが
出ずに行えたら書き込み成功です。
2.UARTブートローダ経由でDFUブートローダを書きこむ場合
この方法は以前細かく説明しているので、ここではSTM32F4-Discovery
基板上ではどの線を引き出せばよいかという点に絞ってお伝えします。
DFUブートローダはSTM32D4Discovery用を書き込んでください
実はSTM8S,STM32VLDiscoveryの時と比べてすっごく楽です。UARTブート
ローダ用の線が引き出されていてなおかつ線を引き出しやすいSMDの抵抗が
ライン上にあります。書き込みの手段を持ってない人はUARTブートローダしか
方法がないので比較的やりやすいと思います。"TO_+3.3V"のジャンパは
書き込みが終わったらはずすのを忘れないでくださいね。
UARTブートローダを起動するためのBOOT0につながる抵抗はR7ですが、
シルクの位置が上にずれてるので間違えないようにご注意ください。
3.Versaloon本体のDFUファイルを書きこむ
STM32VL-Discoveryの時と同じくSTM32F4-Discovery基板上のResetボタンを
押しながらPCとUSBケーブルで接続してください。DFUブートローダが正しく
書きこまれていたらPCがDFUを認識します。その後、STM32F4Discovery用VersaloonのDFUファイルを
書きこみます。書き込み方法はこちらを。
書き込み後はPCとST<32F4-Discoveryの接続を切り離し、Resetボタンを
押さずに再接続した時にVersaloonとして認識すればVersaloon化の
成功です！
Versaloon本体のLibusbドライバのインストールはZadigで
行ってください。
USB-CDC用ドライバ(COMonVersaloon)は本家のリポジトリを
手繰って取得してください。
これでおしまいっ！
…と言いたいところですが、Versaloonとして使用する前に下に述べる処理を
絶対に忘れないでください。
4.後始末
SWDでDFUブートローダを書いた場合は最初に移動したジャンパ抵抗と
ジャンパを元の位置に戻します。次にDFU・UARTブートローダ共通ですが、
R68を取っ払ってください。これはSTLink/V2側からターゲットのSTM32F4
マイコン外部クロックを供給するためのもので、Versaloonではこのピンは使用
されていません！
このジャンパ抵抗を外して8MHzクリスタルが効くようにしてやらないと
STM32F4は16MHzの内部RC発振に強制されてしまいます。一見普通に動いて
しまいUART等のタイムベースが重要なペリフェラルの動作で異常になって
しまうので注意してください！
というわけでSTM32F4-DiscoveryもVersaloonで快適デバッグ/書き込みが
できるようになりました♥
先に書いた通り私のお目当ては複合デバイスとしてVersaloonとともにに
仕込まれているUSB-CDCです。
ごてごて外付けのデバイスを接続せずに済みますのでとってもスマートです。
おまけ
今のOpenOCDでデバッグした際に浮動小数点レジスタは見えるのか！？
ねむいさんがバリバリ使っているOpenOCD(V0.6.0)+Insight(GDB7.25)で
やってみましたが浮動小数点レジスタは見えませんでした(; _ ;)
OpenOCD＋InsightがCortex-M3というか無印のARMV7M扱いでデバッグしてる
せい(Cortex-M4FのコアはCortex-M3と上位互換してるから整数演算部は
普通にデバッグ・書き込みできる)でしょか???情報待ちですね。
も一つおまけ
ぜんっぜん関係ないですがtaobaoで超掘り出し物の液晶モジュール見っけ
ました！2.6inch,240x400のWQVGAサイズでタッチパネルつきのTFT-LCDが
たったの20元でしかも新品！もちろんデータシートなんて無かったのですが
運よく推定したピン配置がドンピシャでバッチリ動いてくれました♥
しかも類似品種のピン配置を調べるとSPIも使用可能なのが分かりコスト
パフォーマンス最高だと思います。
あーしまったこの角度で撮るとせっかくのゆっこちゃんの肢体がー(棒)
STM32 Value Line Discovery(STM32VLDISCOVERY)をいろいろ使う
CQ出版より"世界の定番"との触れ込みで大々的に宣伝されたSTM32ディスカバリ本
が発売されました。これはSTM32F100RBT6が使用されたSTM32ValueLineDiscovery
基板を扱い初心者向けに解説されたものであります。
ちなみにSTM32なんちゃらディスカバリな基板はVL&L&F4と3種類あって、
"STM32ディスカバリ"と書かれてしまうとどれを指すのか非常にややこしい
のですがまぁそれは置いておいて…
以前からSTM32VLDiscovery基板については私も秋月さんからひっそりと販売されて
以来ちょこちょこと触れてきましたがこの基板に関する質問のメールをちらほらと
頂くようになったので改めて単独の記事として紹介したいと思います。
ちなみに便乗ではない！！
●FatFsとTFT-LCD表示のデモプログラム
私のブログでいうところのいつもののことですが、STM32を扱う中でごく基本的な
要素を抑えてあります。私の他の物と同じくChaN氏のLPC2388向けのFatFsの
プログラムをベースにしていますが、移植しやすいよう抽象度を上げています。
・フリーのコンパイラを使ったコマンドラインビルドに対応
・基板上のLED操作
・基板上のSW入力(外部4+1方向SWはオプションで)
・printf系標準関数がリターゲット可能なUART
(サイズ節約のためChaN氏のxprintfを割り振ってます)
・sprintf/malloc系標準関数のサポート
・systickとタイマを利用したAVR-Libcと同じ感覚で使えるDelay関数
・STM32間のポートの移植性を容易にしたFatFsのデバイス依存部
・容易に移植が可能なTFTLCD/OLED表示用ライブラリ
SPI-LCDを使った時のブロック転送はDMA化可能。
ほかのマイコンからSTM32というかARMマイコンを始めた人が真っ先に
引っかかるのはsprintf/printf系標準関数がうまく動作しない点だとおもいます。
今となってはFAQレベルの事なのでここを熟読したり私のUARTへリターゲットしてる
部分のコードを読んでうまいこと動作させられるようにしてください。
上記のプログラムについては各ペリフェラルに対しポートの割り振りは
以下のようにしています。特筆すべき点は、後述するSWD接続のVersaloonを
使いデバッグすることに限定してSWDでは使用しないJTAGポートの一部を
SDカードアクセス用に割り振り、使用可能なI/Oをさらに確保したところでしょうか。
※1：STM32VL-Discoveryデータシートより引用・加筆。
※2：単にポート振っただけでSW入力や8bitLCD等実際使用してない個所あり。
定番のSPI接続のTFT-LCD(128x160)を動かしてみたところ。
ChaN氏のTJPegDecでjpeg画像を表示している最中です。
次回紹介予定の2.5元のi2c液晶モジュールも。素晴らしい掘り出し物です！
●STM32VL Discoveryに仕込まれてるSTLinkをVersaloon化
最早これも定番でしょう。STマイクロの**ディスカバリー系な基板にSTLinkとして
仕込まれているSTM32F103C8T6は各基板ごとに微妙にポートの配置が異なっていて
同じVersaloonのバイナリは使いまわしはできませんが、すでにVersaloon本家
ではSTM32VLDiscovery向けのファームウエアがサポートされています。
さて、肝心のVersaloon化の方法ですが本家ではDFU等のブートローダを
仕込まずに直接Versaloonのバイナリを書きこむようになっていますが、
私はアップデートを容易にするためにいつも通りのDFUを仕込むように
しました。以下に私が行った手順を示します。
DFU仕込まない場合は"1."の書き込み時にいきなり本家の方のSTM32VL
Discovery用のバイナリを書きこんでください
(この場合別途ビルドする必要あり)。
1.DFUを仕込む
こちらにSTM32VLDiscovery用DFUブートローダのバイナリを用意しました。
(Versaloon_DFU_Bootloader_for_STM32VLDiscovery_.zip) 最初に
書いてください。
書きこむ方法はSTLink等のフラッシュを書きこむ手段が別に用意
されてる場合はそちらを使ってください。
Jim氏のTakenApartの記事にSTLinkをつかった手順が示されていますので
そちらの記事をもとにDFUブートローダを書きこんでください。
また、STM32はこの基板が初めてでフラッシュを書きこむ手段を他に
持ってない人は、UARTブートローダーを使う方法を、こちらの改造手順2〜8を
参照して書きこんでください。
UARTブートローダを有効にするためのジャンパの引きまわしは
STM32VLDiscovery基板上では以下の写真の通りとなります。
この基板上では足あげ等の加工も水晶の付け替えも必要なく0.5mmピッチの
足からリードを引き出すだけなのでまぁ楽勝ですね。
DFUを書き込んだ後はもちろんジャンパをはずすのを忘れないで
ください！
2.DFUを起動
さて、DFUを書きこんだらPCに接続するわけですがSTM32VLDiscovery基板
上では下画像のリセットボタンがDFUの起動キーとなります。
リセットボタンを押しながらUSBケーブルでPCと接続してください。
USBデバイスとしてDFUが認識されたら成功です。
そうだね画像使いまわしだね。言い忘れてましたがDFUseをインストールした時に
DFUドライバがインストールされますので忘れずにインストールして
おいてください。
3.Versaloonを書き込み/起動
STM32VLDsicovery用のVersaloonのDFUファイルはこちらに。書き込み方は
ここの"14."を参考にしてください。でも向こうにあるDFUファイルは別物だから
使っちゃだめです！
書き終わったら基板を一度PCと切り離し、再度接続します。この時に
Vesaloonとして認識されたら成功です。VersaloonはLibUSBが使用されて
いますが、LibUSBのドライバはZadigでインストールした方が確実です。
20120105追:
以前はSWDのジャンパはあべこべになっていましたが、現在では
差し替え無しでそのまま使用できます。
4.Versaloon化したSTM32VLDiscovery基板上でターゲットのSTM32F100RBT6を
デバッグ冒頭で述べたプログラムをビルド・書きこみを行うわけですが、
用意するものはSTM32マイコンをビルドする環境のほかにVersaloonに対応
した特別なOpenOCDが必要です。
おもな手順はこちらとこちらですでに紹介しています。
てわけで丸投げしまくりのやっけつ手順になってしまいましたが簡単に改造
可能なので(自己責任の上で)お勧めします。
しかも今のVersaloonはUSB-CDCが同時に使用できる複合デバイス構成になって
いるため、これを利用してこの基板上でUARTの通信手段を完結させることが
できます♥
STM32F4シリーズを使ってみる3 -FatFsと下部レイヤ(SDIO・MMC)ドライバたちの実装-
来たぞー！
…って来たのはもう2週間以上前ですけど…
144PinのSTM32F4も手に入ったのでSTM32F2の時と同じく中華生基板に組んで
みました。STM32F2とF4はほとんど同じです。特にコードは上位互換があるので
回路を完全に合わせるとF2のコードがそのまま使用できちゃったりします。
まあでもさっさとCortex-M4F用にしてしまった方が良いでしょう。
↑ということでいつものChan氏のプログラムを走らせて
みました。
特筆すべきはF2系では何とか動くものの安定していなかった48MHz動作の
SDIOがF4系では非常に安定してることで、SDカードとさらに大容量/高速な
データのやり取りができるようになっています。ただし高速なクロックに耐え
うるSDカードの選択は必須で、Class10のカードを必ず選んでください。
最近出回ってるUHS-1の奴は逆に駄目なものもありましたので幾つか購入して
試してみてください。あと当たり前のことですが、配線の引き回しももの
すごく重要なので注意してください。
↑でたらめ書いてました。SDカードの仕様上通常モード(NomalSpeed)は
25MHzが上限値でSTM32F2/F4ではUSBとの共用を考えると24MHzが現実的に
安定して動かせられるクロック上限となります。
お詫びして訂正しましま。
んでもって前回さらっとお見せしたSTM32F4 Discoveryの方のいつものですが、
ちゃんとした実装にあたり、周辺にぶら下がってる回路の影響でどのように
構成すべきか悩みました。なぜならば…
SDIO : SDIO_CLKがCS43L22のSDINとかぶってるから使えない
FSMC : 肝心のnRDがCS43L22のResetに、nWRがUSBの過電流検出に被ってて(ry
その他諸々のペリフェラルが被ってて(ry
SPI3 : CS43L22がI2S3として使ってて(ryついでにI2C1も
SPI2 : MP45DT02がI2S2とし(ry
SPI1 : LIS302DLがSPI1(ry
…
まぢでひっぺがしたろかと思いましたが先に書いた通りSTM32F407ZGTが
手に入ったのでSTM32+SDIO+FATFS+FSMCの構成はこっちに実装してDiscoveryの
方は既存のペリフェラルと何とか共存する道を選んでみました。
てわけで妥協したのが以下のSTM32+MMC+FATFS+SPI-LCDのプラン…。
SDカード : SPI1(LIS302DL(SPI通信)と共用)
TFT液晶 : SPI2(MP45DT02(I2S通信)と排他)
※STM32F4DiscoveryではSPITFT液晶のみ対応
その他 : CS43L22は丸々残す！
UARTはUART2(TX:PA2 RX:PA3)
SDカードとSPITFT液晶はもちろんDMA化してあります。
TFT液晶がシリアルしか使えない上にMOSIがI2Sの入力とかぶってしまうので
MP45DT02とは排他になっていますが、必要な人はGPIOによるソフトSPI
(超遅いですが)で逃げてもよいと思います。
私のLCD表示ドライバは潰しが効くようにかなり柔軟にデバイス依存の部分を
作り込んであります。またSTM32F1系ではペリフェラルはひとかたまり単位で
しかリマップできない構成でしたが、F2系以降はピン単位で柔軟なリマップが
できるようになったのでみなさんもデータシートとにらめっこして工夫して
みてください。
とりあえずSTM32F4 Discovery上でこの構成でハード改造を行わずに音楽
再生はかろうじてできるでしょうか？
音再生関係の作り込みはこれからなのでがんばってみます！
てわけでいつものコードでSDカードの読み出し速度比較を行ってみました。
使用したカードはClass10が策定される前に販売されたATP製4GBClass6の
microSDです。
STM32F4Discovery上で組んだFatFsは先に書いた通りの構成ですが、SPI1は42MHz
まで叩きだせるので読み出し速度もめっちゃ速いです！(注：SDカードは選びます)
音楽再生程度ならもう十分な早さですね♥今回の実装に際してMMCのSTM32用
ドライバも移植性をかなり高めた作りにしてみました(もちろんDMA化も)!
ちなみにDMA化に際する注意事項ですが前回も言及していますが、CCM領域を
DMAの読み書き先として利用することは一切できません！STM32F4系でCCM
領域を高速なスタック領域として使用する前提でF2系から移植を考えた場合、
既存のプログラムがauto変数をDMAの読み書き先として定義されていると
特定困難な不具合に悩まされる可能性がありますのでよく吟味してください。
お次は中華生基板(STM32F407ZGT6)で組んだSDIOの読み出しスピードです。
上にも書いていますが、F2系ではコケまくって全く安定してなかった48MHzの
クロックでも安定してアクセスができるようになり、20MByte/Sec以上の
すさまじいスピードで読み出しが可能になりました♥ちなみにこの
基板上ではFSMCもDMA化してます！
バグ出しもほとんど終わり、最低限のドキュメントもそろいましたので
STM32F4 Discoveryと中華基板対応のいつものコードを公開します。
makeファイル内の定義でSTM32F4Discoveryと中華生基板のビルドを切り替える
ことができます。その他細かい部分のノウハウは口で説明するよりソース見て
もらった方が分かると思います。
だから誰か早くSTM32F4Discoverymp3プレーヤー作ってくだち！！
20121220追:
STM32F4Discovery用でMP3再生機能追加しました！
あ、お伝え忘れてました。今回の公開に当たってSTM32F2系とSTM32F107、そして
最近この検索ワードでアクセスが急増中のSTM32VLDiscovery向けのFatFs+液晶表示
プログラムも大幅に更新しておきました。
んでもってOpenOCD用Flash書き込みCFG群もSTM32F4xx用を追加しておきましたよぅ
STM32F4シリーズを使ってみる2 -STM32F4のメモリ構成を理解し基礎を作る-
20111201追：
最近複数の方からメールでご指摘いただきましたが、私はこのwikiとは関係ありません。
私の今回の記事からいくつかの文章を丸々コピペしていますが、私が後日誤りに
気付いて修正した内容が修正されずそのままになっていますので信用しないよう
注意してください。
20111201追：
今回は前回述べたとおり192kByteに増強された内蔵SRAMをどのように使うかを
決定し、お約束の標準関数の使用やFPUを用いた浮動小数点の計算をSTM32F4
Discovery上で実践してみます。
STM32F4系は192kByteのSRAMを持っていますが、実際は112kByte,16kByte,
64kByteの3ブロックに分かれています。後で図示しますが、112kByte分は
AHBバスマトリクスに接続された汎用SRAMで,16kByte分は同じくAHBバス
マトリクスに接続されているものの、112kByte分のSRAMと同時に読み書きが
できるように(主にEtherNetMAC&USB-OTG(HS)用に特化されているようです)
なっています。
アドレスは連続しているのでEthernetやUSB-OTG(HS)を使うつもりがない人は
128kByte分まるまる汎用SRAMとして使用することが出来ます。
その他細かい制約があるので各自データシートやマニュアルを参照のこと。
☝丸投げ
もうひとつの64kByte分はCore-Coupled Memory(CCM)と呼ばれ、Cortex-M4Fの
コアに直接接続されています。このSRAM領域はAHBバスマトリクス上にはなく、
DMAの読み書き先としてこの領域を使用できません！
(20111026追：実際に試しましたがHardFaultになったりDMAが完了
しなかったりで、やはりDMA用のメモリとして使用できませんでした）
また、128kByte分の汎用SRAMもSTM32F4のコアクロックと同様の168MHzで
アクセスできるので俗に言うTCM(Tightly-Coupled Memory)としての速度的
優位差もほとんどないでしょう。
以上の点を踏まえて、STM32F4系でつぶしが利くようにねむいさんはSRAMの
構成を下図のようにしてみました。
64kByteもある広大なスタック領域を君はどうつかうのか！？
注：CCM領域はDMAできません！！大事なことだから２度言います！！
この構想をリンカスクリプトに落とすと下図のような感じです。
この下にも長−く各セクションの定義が続きますが省略。
この構成で前回のTFT-LCDの表示テストも改めてクリア・またprintf系の
標準関数もUARTにリターゲットして動作を確認しました。
次にFPUを使って浮動小数点の演算のテストに取り掛かりました。
Cortex-M4Fは単精度の浮動小数点ユニットを持っています。GCCコンパイラから
この機能を使うためには浮動小数点命令に落とし込むようにフラグを与えて
あげないといけません。
具体的にどういうフラグを与えるかについては酔漢氏が昨年に考察されていました。
氏の情報を元に私の環境では以下の箇所の変更で単精度の浮動小数点命令に
切り替わりました。
-msoft-float("-mfloat-abi=soft"と同じ意味)
↓
-mfloat-abi=softfp -mfpu=fpv4-sp-d16
-mfpu=fpv4-sp-d16は必須です。これが無いと倍精度の命令を使ってしまい、
実行したとたんにHardFaultになってしまいます。
ちなみに-mfloat-abi=※※※※ の意味はそれぞれ以下のように表されます。
-mfloat-abi=soft ：浮動小数点の演算に整数命令のみで構成された
浮動小数点演算ライブラリ(soft-float)を使う。
-mfloat-abi=softfp ：浮動小数点の演算に浮動小数点演算命令を使うが、
floatを引数にする関数の呼び出し規約はsoft-floatと
同じく汎用レジスタを使って値を渡す。
(↑この仕組みはソフトウエア・リンケージといいます)
-mfloat-abi=hard ：浮動小数点の演算に浮動小数点演算命令を使い、
floatを引数にする関数は浮動小数点レジスタを使って
値を渡す。
酔漢氏のページでは"-mfloat-abi=hard"となっていました(GCC4.5.xからこの
オプションが利用可能)が、無償で利用できるSourceryCodebenchLite版にある
標準関数等のライブラリはsoft-floatでビルドされているため、標準関数を
絡めるとリンク時に引数渡しの不整合がおきてエラーになります。
これを回避するためにはCodebenchLite版のビルド済ライブラリを使わない設定
(-nostdlibオプションを付ける)を付与し、同じ機能を持つライブラリを一から
"-mfloat-abi=hard"でビルドしなおさなければなりません。
というわけでいちいちビルドするのめどいので以後は"-mfloat-abi=softfp"で。
20131226追:
GNU Tools for ARM Embedded Processorsなら"-mfloat-abi=hard"が
使用可能です！！
これでFPUの命令を含むプログラムがビルドできるようになりましためでたし
めでたし･･･と言いたい と こ ろ だ が ！
ここも嵌ると思うので記しておきます。Cortex-M4Fの仕様によるとFPUは浮動
小数点命令が行われる前に(つまり起動時)に有効にしてやらないといけません。
STM32F4xxのサンプルではsystem_stm32f4xx.cのSystemInit()の最初で実行
されているものもありますが、テンプレートからsystem_stm32f4xx.cを生成
するとこの記述が欠けているのでほとんどの場合は自分で追加しないと
いけません。
☝のような感じでFPUの有効化を行ってください。
20120410変更：
実際にコンパイルオプションを変えて浮動小数点演算の箇所のアセンブラ
リストを比較してみました。Launchpad提供のGNUToolchainを使用しています。
●-mfloat-abi=soft
FPUを一切使用しない場合です。FPUのレジスタは一切使用されず、また
浮動小数点演算ルーチンが呼ばれています。
●-mfloat-abi=softfp -mfpu=fpv4-sp-d16
FPUを使用する場合(SoftFP)です。関数の値は汎用レジスタで渡されています。
●-mfloat-abi=hard -mfpu=fpv4-sp-d16
FPUを使用する場合(HardFP)です。関数の値もFPUレジスタで渡されています。
printf関数は暗黙の型変換によってfloat値を渡してもdouble型に強制変換
されます。単精度のFPUしかもたないSTM32F4ではdouble型に変換するための
__aeabi_f2dルーチンが必ず挿入されます。
ってわけでこれでほぼ完全にCortex-M4Fとして開発を行う下地が整いました！
現在はSDカードとSPI接続のTFT-LCDとUARTをつなげていつものをこしらえる
ところまで進みました。STM32F4 Discoveryの回路構成の都合で、SDIOとFSMCが
使用できないのでSDカードもTFTLCDもSPI接続です。
はやくこいこいSTM32F407ZGT6!
あ、そうそう、Chan氏のTJpegDecも組み込ませてもらってます。
GPSを試用する4
前回は秋月電子通商さんで販売されていて入手しやすく高性能なGT-723Fを
使用したGPSロガーの製作例と使用例をお伝えしましたが、今回はさらに性能の
高いGPSモジュールUP-501を入手しましたので紹介したいと思います。
UP-501とGT-723F(ついでにGM-316も)の性能比較は以下の通り。
UP-501の電圧上限が4.2Vとなっていますがこれはリポ電池を使用したものを
想定して設計されているようですね。現在の電子工作の電源電圧も3.3V物が
多くなっているご時世なので特に気にしなくてもよいでしょう。多分。
実際に使用してみましたが、GT-723Fと比較すると捕捉時/追跡時の消費電流が
30mA以下に抑えられ、なおかつ高感度になっていて悪天候時のコールド
スタートでは捕捉までの時間がかなり早くなっています。登山やトレランの
時は電源投入後の初回捕捉時間が結構重要で、ここで捕捉時間が長いと貴重な
時間を失って結果目的地に着いた後帰りのバスや電車に乗り遅れるという
かなりおまぬけなリスクが上がってしまいます！
(↑ねむいさんはタッチの差でよく乗り遅れるんですよぅorz)。
さらにUP-501にはVBAT端子があり、SRAM上のアルマナック&エフェメリス
データを保存できるのでAGPSと組み合わせると再補足の時間をさらに早く
することができます。登山の前日にAGPSのデータをダウンロードして
なおかつ一旦捕捉動作しておけば現地で捕捉待ちでいらいらすることなく
すぐ出発することができると思います。頻繁に電源を入り切りするような
使い方や、悪天候下のときほど効果を発揮するでしょう。
GM-316にも同様にVBAT端子が存在しますがモジュールの小ささ(=パッチ
アンテナの小ささ)ゆえに外部アンテナがないと真価を発揮できないようです。
またAGPSもないのでパッチアンテナのみだと快晴時/開けた場所でも初回捕捉
時間がかなり長くかかります。ゆうに20分以上掛かります。UP-501が手に
入る今となってはこちらのモジュールは外部アンテナをつけて据え置き型の
GPS時計の中核部とするのが良ですね。(捨てるのもったいないし!)
ちょうど台風が来て大雨が降っていたので私の塒のベランダから悪天候時の
捕捉時間の比較をいくつかの条件で行ってみました。
●GT-723Fの場合
コールドスタート(AGPS無) 約14min
コールドスタート(AGPS有) 約3min
●UP-501の場合
コールドスタート(AGPS無) 約10min
コールドスタート(AGPS有) 約3min
ウォームスタート(SRAMバックアップ有,AGPS有,
捕捉確認後電源を落とし3時間置いたあと電源投入) 約25Sec
ホットスタート(SRAMバックアップ有,AGPS有,
捕捉確認後電源を落とし即再投入) 約7Sec
GT-723FのAGPS無のコールドスタートの時間は西青山〜柘植にトレランに行った
時にGPSロガーを使用した時の初回捕捉時間とほぼ同じ(スタート地点の
西青山駅はかなり強い雨)でした。また当時同時に使用していたSRAMの
バックアップが存在するスポーツガイドメイトの場合、ウォームスタートだったため
40Sec程で捕捉できてました。
ちなみに快晴時ではGT-723FとUP-501のいずれもAGPS無のコールドスタートでも
40Sec前後で捕捉します。
↑せっかくなのでAGPS用のデータのダウンロードは某BluetoothのUART
モジュール経由でワイヤレスでできるようにしてみました。
遠隔のデバッグにも結構使えますねこれ。XBeeと違って115200でも
文字落ちほとんど出ませんし。
あと気になる入手経路ですが、今年7月ごろに一般にも流通しだしたUP-501は
現在ではSparkfunから59.95USD、国内ではswitch scienceさんより5995円で
購入できます。
GT-723Fと比べると少々値段が高いのですが、実はMARY基板の企画でマルツ
さんより販売されているGB基板にはこのモジュールが使用されており、
しかも約1000円安い4980円で購入できます！
基板をそのまま使うのもよいのですが、用途がしっかりしてるのなら
私のようにモジュールだけを外して利用させてもらうのもよいと思います。
えっとこんなふう
に…モジュールの写真撮ったのが伊勢乃宮雪子ちゃんの誕生日(8/27)だったのでついでに…
GPSモジュールと基板さんが大事な部分をしっかりガードしてるので職場や学校で見てる人も安心だ！♥
ちなみに二次裏には全部見えてるVerを
…ｹﾞﾌﾝ失礼…おまけですがスポーツガイドメイトも分解したので写真お見せします。
↑表蓋を外したところ。パッチアンテナとモノグラフィックLCD基板が
見えます。
↑パッチアンテナは基板に直結です。
↑裏蓋とリポ電池をはずしたところ。左からRF用IC、GPSの心臓部のVenus6、
そしてProlificのPL2303HX(RevD)が見えます。PL2303HXのシリアルナンバを
固定化したいところですがRev.Dのチップは書き込みに6.5Vの高電圧と特別な
ライタソフトが必要なのでこの基板上では不可能です。残念。
というわけで自作のGPSロガーに使用するモジュールはGT-723FからUP-501に
切り替えて動作検証を続けたいと思います。11月から予定の東海自然歩道本線
ルートの再開時には活躍してくれるでしょう。
GPSを試用する3
STM32Primer2を使用したGPSロガーもだいぶ安定してきましたので、
STM32 Primer2GNSS Tr@ckerのファームウェアを公開します。
動作させる際は下記ハードウエアの改造を必ず行ってください。
１．STM32Primer2の電源ICをLDOに置き換えて強化する。
２．リポ電池をこれに交換する。
JSTのコネクタははずしてリードを基板に直ハンダで。ショートに注意！
３．GPSはGT-723FもしくはUP-501を使うものとする。
ボーレートはデフォルトの9600bpsで。
４．GPSの電源はLCDバックライトの3.1V系から取るものとする。
(LDOに変えた時点で3.3Vになりますが)
５．GPSは下記のピンのみSTM32Primer2と接続する(GT-723Fの場合)
1pin(GND)
2pin(VCC)
6pin(SerialOUT,LVTTL)
６．GPSの1-2pin(GND-VCC)の近くに16V,10uF,X5R以上のグレードのMLCCを付ける。
７．STM32Primer2にmicroSD/microSDHCカード(1GB〜16GBまで動作確認済)を
挿しておく。もちろんFat12/32でフォーマットしておくこと！
ファームウェアの動作としてはSTM32Primer2の十字キーのセンター(CTキー)を押して
電源投入。投入時はSTM32は36MHzで動作しています。投入後のキー操作でGPSロガー
モードとマスストレージモードに動作が分かれます。いずれのモードもリポ電池の
電圧が3.3V以下になると自動で電源OFFの操作がされシャットダウンします。
●GPSロガーモード
電源投入直後に十字キーを何も触らなければGPSロガーモードに突入します。
シリアルのボーレートの適正な(9600bps)データが受け取られたら緑LEDが
点滅します。この点滅はGPSが衛星を補足するまで続きます。
捕捉後は緑LEDは消えて以後はmicroSDにデータが書き込まれるごとに赤LEDが
点灯します。ロギングを止めるにはセンターキーを3Sec以上押し続けた後
離してください。
LCDがOFFになっているのでよく分からないとはおもいますが代わりにGT-723Fに
あるLEDが消えるのでOFFされたことが分かります。
●マスストレージモード
電源投入直後0.5Sec以内に十字キーの右を3Sec以上押し続けるとSTM32の動作
周波数が72MHzに上がり、LCDが点灯初期化され、"Start Mass Storage"
と表示されます。
この状態でSTM32primer2にある"STM32"側のUSB-miniBコネクタとUSBケーブルで
接続するとPC上にドライブが見えるようになり、USBカードリーダーのように
通常のファイルの操作を行うことができます。
GPSのデータを取り出すためにいちいちSTM32primer2の蓋開いてmicroSDカードを
取りだして別のリーダーで読みだすと言った煩雑な操作はもう必要ありません！
上記ハード・ソフト構成で捕捉状態だと11時間以上ロギングできるので日帰りならば
十分に使用できる代物だと思います。実際には保険代わりにCanmoreのスポーツガイド
メイトGP-101持ってってますが〜(これはデジタルコンパスがあるので結構重宝する)。
中太郎生・丸八酒店手前にて。
てわけでほとんどの人は興味ないでしょうけど自作のGPSロガーで記録していった東海
自然歩道山の辺ルートの後半編を…
��長谷寺->室生口大野
長谷寺の回廊。
初瀬ダム(まほろば湖)。
室生ダムとダム穴。
��室生口大野->中太郎生(なかたろう)
大野寺の弥勒磨崖仏。
済浄坊渓谷の滝。
亀山峠から見た曽爾高原。
��中太郎生->西青山
伊賀富士・尼が岳。下山路で蜂に追っかけられる。
メナード青山リゾート。
廃墟のような近鉄西青山駅。
��西青山->柘植
青山高原の三角点の手前。強風と大雨が叩きつけるいい天気だ〜！
風力発電の風車…だがガスにおおわれて視界ゼロの恐怖！
新大仏寺の山門。
霊山についてころにはすっかり晴れ、朝に通過した
風車群もくっきりと。
東海自然歩道の本線ルートと合流し、柘植駅に再び到着。
本ルートの関ヶ原から先は11月から再開なのでこれまでは平地を走り込みつつ
ご無沙汰だったSTM32F2の続きやっていこうと思います。
F2向けのUSBライブラリもやっと出たし！
GPSを試用する2
STM32Primer2を使用したGPSロガーですが、やっと長時間安定してロギングを
行えるところまで持っていくことが出来るようになりました。
一番の強敵は衛星を捕捉していてもロギングがランダムで停止してしまう
現象に遭遇したことで、どの部分で問題を起こしているかという切り分けに
かなり時間を要しました。東海自然歩道のルートで言うと湯ノ山温泉->
西藤原のルートから始まって笠置->奈良くらいまでは特別なファームを
あれこれ試したりノイズ抑制のためにコンデンサ追加したり導電性エア
キャップにやさしくくるんだりあれこれ試しようやく不具合を特定しました。
(結局FatFsの書き込み時のエラー処理が不適切なだけだった･･･)
ついでに使っているGPSモジュールもGM316+外部アンテナから秋月さんちから
2月にラインナップに加わったCanMore製のGT-723Fに変更し、なかなかの
結果を収めています。
↑比較表作ってみました。
GT-723Fは衛星を見つける最初期のacquisition(同期捕捉)の段階では
80mA以上喰ってしまってしますがtracking(同期追跡)状態に入ると32~36mA
前後まで落ち着き、結果的に野外で使うなら電池の持ち的にもGM316+外部
アンテナで使うよりも有利なのが分かりました。元主人の持ってたGT-720Fは
常時180mA位馬鹿食いしてたのをかんがみると技術って進歩してるんだなぁ･･･
とおもうことひとしきりです。
↑現在の運用形態。STM32 Primer2からVCC,RxD(STM32 Prime2側),GNDを
引き出し、なおかつGT-723Fは別に基板を設けて固定して機械的にも
接続を強化してます。
また、このモジュールは+3.0Vからの電源入力に対応していますので、
STM32Primer2だとLCDのバックライト電源からパワー(3.1Vavg)を拝借する
形となります。
↑尤もSTM32Primer2いじり倒してる人はとある理由で当然電源周りも改造してて
原形とどめてない人も多いでしょうからもう好きにすればいいと思いますよ
(☝投げやり気味)。
↑JR笠置駅にて。
ねむいさんチキンなので実際に使う時はGPSモジュールを導電性エア
キャップにくるみ、さらにここからSTM32Primer2全体をGPSモジュールごと
くるんで物理衝撃対策してます。
この状態でもザックにぶち込んだ状態で氷点下の環境はもちろん猛暑の中
でも安定して動作したので満足です♥
タフすぎて そんはない
肝心の捕捉精度なんですけどGT-723Fはパッチアンテナのみですが深い森の
中でもしっかり衛星を握ってくれていて、逆にトンネルやトイレ等の電波が
完全に遮断される場所では案外簡単にぱっと手放してくれるようです。
GM-316の場合は電波が途切れても捕捉状態から離れずでたらめな場所を記録
してしまうことがよくあったので山中の行動の記録に使う用途としてはGT-723Fの
ほうが良いかとおもいます。
それとGT-723F買ったときに結局ついでに買ってしまったのですが市販品の
スポーツガイドメイトと比較した場合もほとんど引けをとらない結果になってます。
↑結局買ってしまった･･･Garminは高いから論外で(欲しいけど)
↑スポーツガイドメイトは電源ボタン長押しでOFFではなくワンプッシュで
OFFとなってしまう設計のため、ザックに無造作に放り込んで山野を走る
ような荒っぽい使い方は出来ないのが難点です(自転車に固定して使うことを
想定されているようです)。
PCとの接続は内蔵のUSB-シリアル変換でUSB経由でデータの読み書きをします。
↑これはJR奈良駅から近鉄長谷寺までのルートを同時に記録したものです。
ほとんどぴったり重なっちゃってるんですけど赤のラインがスポーツ
ガイドメイトで青が自作のGPSロガーです。
本末転倒になってしまっていますが、ロギング中に一方が何らかの理由で
停止しても困らないように現在は両方持って山に行ってます。
本当に本末転倒ですがもういいです(投げやり気味に)。
おまけ
私のぶろぐの中でpvが圧倒的に少ない、つまり人気が無いのが東海自然歩道
関連の記事なのですが、一部の方々にブラウザのベンチマークとして使われて
いるのを知ってまぁ少しは役にたっているかなと思ふことひとしきりですが、
それはおいといて山に興味がない方はドリフの雷様的な物と思って
あきらめてください。逃がしません…(ワグナスさんみたいな顔で)
東海自然歩道の山の辺ルートは本道ではないのでぶろぐには書かないつもり
でしたが、今回は特別にダイジェストを･････！
��石山->宇治
このルートは99%舗装路でした。
ゴール地点の平等院鳳凰堂。
宇治茶のアイス(宇治茶+桜だそうな)
��宇治->原山
やっぱり舗装路。
見所(というかこれしかないけど)の鷲峰山。
加茂駅と昔からある倉庫。
(※体力あまってたので原山から加茂駅まで走って帰りました)
��原山->笠置
童仙房山荘。
ないおん！
高山ダム。ここから先が長い。
関西本線が間近に！ｃ
ゴール地点のJR笠置駅にある良く分からない像。
��笠置->奈良
柳生家老屋敷。
一刀石。
日照が体力を削る季節になってきました･･･。
峠の茶屋。
鹿。
��奈良->長谷寺
鹿。
一番やさしいルートですが夏場だけは
逆に一番過酷なルートに！！！
石上神宮。
大神神社領からの展望。
狭井神社のハイテク御神水供給装置。
長谷寺山門
長谷寺駅からの夕暮れ。
これから夏本番です。夏場の激しい運動は熱中症や脱水症状という直ちに死ぬ危険
性の高いリスクが常に付きまといます。ねむいさん絶対に日焼けしたくないので
長袖とUVカットのゴーグみたいな眼鏡で完全ガードしてるおかげで上記のリスクが
さらに高まるので一応そっち対策もばっちりしてる(つもり)です。
欲張らずに走る距離は30km以内に抑え、朝早く出発して遅くとも15時までには走り
終えて帰るというのを心がけるようにしてます。
あとせっかく体重落ちたのに風呂上りにうっかりビール飲まないようにｓｈ…
ビールには勝てなかったよ…ﾌﾟﾊｰ♥
STM32F2シリーズを使ってみる3
4月から本当に少しずつ使い始めたSTM32F207ですが、公式の方もやっとこ
資料が出そろってきてだいぶ扱い方が理解できるようになってきました。
とりあえず一つの通過点ということでいつものchan氏のLPC2388向けのFatFs
+OLED表示プログラムの移植をしました(ほとんど原形とどめてませんが…)。
いろいろやってきた中でjpegデコーダ乗せたり(デコードが1.8倍速くなってる!)
FONTX2の使い方覚えたりで今回はM+フォント(FONTX2)を使いFilerの
日本語表示を可能にしてみました。
↑やっとここまでこれた…
なんと当のchan氏も6/11更新のLPC2368向けFatFsサンプルでFilerの
日本語化をされていたようで今度はこちらを元にしておりぢなるなFilerの
構想を練っていきたいと思います。
そうそう、気になるFatFsの読み取り速度ですが、SDIOが出せる最高速度の
48MHzまでクロックを引き上げた場合、最大21MB/Secを叩き出すことが
できました！
↑てかいつも比較に使ってるATP製のmicroSDカードもすごい…class6なのに。
しかし、48MHz動作は8bitモードしか保証していない(rm0033.pdfより)ので
sdカードで使うときは実際は24MHzで動かすことになるのですが
…それでも十分早いですね。
おきばにはすでに上記で紹介したSTM32F207ZGT6向けのプログラムを
公開しています。これはPowerAVR製の紅牛(もとはSTM32F103ZET6)という
ボードの回路互換となっています。
ねむいさんSTM32F2向けに備えてかなり前にtaobaoで部品未実装の基板
"だけ"超安価で購入していました。てわけでホントに最低限のことしか
できないのですがF2を試すに当たってはこっちの方が幾分都合がよいのです。
ここからどんどん付け足していきます
またmakeファイル内の定義の書き換えによって以前使っていたSTM32F207VGT6
向けにも対応できます。
STM32F207VGT6の方はこちらの(STM32F103VET6)ボードの
回路互換です。両者に共通するのはFSMCのピンが引き出されていて出来合いの
LCDボードが直結できるという点に尽きます
(☝TFT-LCDマニアな人には超重要なファクター)。
まぁデータシートで1xx系とのピンの処理方法の違いとかとか
詳しく解説されていますんで・・・・、
日頃ねむいさんのぶろぐ読んでる人なら簡単に乗せ換え可能でしょう。
あと開発環境のtipsとして、前回も説明しましたがCodeSourceryG++等の
ポピュラーなGCC開発環境はそのまま使用できます。Cortex-M3対応なら
何でもよいでしょう。問題は書き込み環境ですが…20110619現在はシステム
メモリ上のブートローダから使用できるフリーのツールがまだ整わず、
よってJTAG/SWDからしか書き込む方法がありません。幸いOpenOCDの0.5.x系と
VersaloonはすでにSTM32F2系のフラッシュの書き込みに対応しています。
私もフラッシュ書き込み用のOpenOCDコンフィグを公開していますのでJTAGな
いしはSWDでつなげられるアダプタ持ってる人は開発に際して問題はないです。
最後に、次回予定のLPC2388関連の記事で詳しく解説しますが、64bit版
Windows7環境下のビルドにもmakefileの設定で対応できるようにしてあります。
副業先のポジションとPC環境がガラッと変わったのでねむいさんも必要に
迫られてというのもあったりしてます。
ねむいさんとうとう従業員Bから晴れてエンジニアにじょぶちぇんぢ！
(やってること相変わらず雑用だが)
おまけ：
aitendoさんからついにあの扱いやすいSPI液晶が販売されましたね。
以前私が説明した奴です。これ使ったシールドとかも海外ではもうすでに販売されて
ますが、TFT-LCD Shieldを開発した時の生基板を利用して無理やり乗っけてみました！
次はこれで行こう。
そしてaitendoさんからはもう一つQCIFサイズのタッチパッドつきの液晶が発売されま
した。これ確かtaobaoで捨て値で売られてて私も10枚くらいまとめて買って動かして
(飽きて放置)してました。これ8/16bit選択できるのは良いのですが、ピン間隔が0.7mm
なので手配線ではきつい人がいるかもしれないですね。専用の変換ボード出るの待った
方が良いと思います。どちらかというと…、
こっちとか
こっちとか
こっち
の方がピン間広いし8bit固定で小難しいこと考えなくて良くてよいと思います。
思いますよぅ！！(重文)
↑AS021350DをXMEGAで動かしてみたところ。
実はATXMEGA128A1にもchanさんのFilerを日本語対応して移植に成功してます。
しかしXMEGAはFatFsを結局DMA化できないまま白旗降ってクローズします…。
20230701追:
DMA化してSRAMも外付けしましたよう！！！！！！！！！１！！！
STM32F2シリーズを使ってみる2
てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちに
ST公式でやっとこF-2デバイス用のペリフェラルライブラリが出たり
BeableBoardXM購入合戦に勝利したもののまったく火入れしてなかったり
ALTERAのFPGA評価ボード買ったり
ステーション型はんだごて購入したり
USB接続型PCオシロスコープPicoscope3206Aを破格値でゲッツしたり
探訪も笠置まで進んでたりそうこうしてるうちにSTM32F2シリーズも
普通に購入できるようになってたりする昨今、いかがお過ごしでしょうか？
震災を境に身の回りの状況が一変してしまいましたが、ねむいさんはいない
さんをひざに乗せてくんかくんかしつつできることから着々と取り組んでいく
所存でございます。
勘違いや無知無学が祟って時間を食ってしまいましたが、STM32F207VGT6で
SDIOとChan氏謹製のFatFsを連結させて安定動作できるまでになりました。
SDIOはもちろんDMAを使って高速に転送可能です♥
以前のSTM32F103VET6のものと同じ条件でReadの速度を比べると若干の
向上が得られました！
SDカードだとSDIOは25MHzまでしか出なかったり(MAX48MHz)カード自身の
転送速度もボトルネックになってるとは思いますが、小規模のマイコンで
もこんだけ早かったら御の字ですよね〜。
さらに前回ちょろっと紹介しましたが480x272pixelの4.3inchTFT-LCDの
ドライバも組み込んで"いつもの"をやってみました。こちらもFSMC使った
高速転送です！
ねむいさんへたれだからSSD1963っていうコントローラつきの液晶モジュール
基板使ってますが･･･。
↑タッチパネル入力にももちろん対応。
↑再びぽぽぽーん
STM32F2になってフラッシュも1MByteまで増えたことだし、フォントも扱える
ようになって機は熟したからそろそろ私もChan氏のファイラーは卒業して
おりぢなるなファイラーを作ろうかな、と。
んでもってSDIOとFSMCの高速な転送を利用して動画再生も試みました。
Chan氏のLPC2388向けの動作再生ルーチンをチューンアップしないでまんま
利用してもQVGAサイズで29.97fpsな動画も余裕で再生できたので相当
"ぱわふりゃーなので余裕"なの確認できました。
やっけつだけど一番乗りだからどっかにアップしたいな〜
とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ
先日がた老氏FreeRTOSがらみの質問をもらった機会にご無沙汰だったRTOSの
おべんきょもふたたび進めていくつもりです(BeagleBoard-xMとDE0-Nano
から目を逸らしながら)。
おまけ：
て言うかこっからが本題です！！！！
LatticeのispVMがいつの間にかFT2232デバイスに対応していた件
いままでsvfとかUrJTAGとか使って手間のかかる方法しかできなかったのが
嘘のようです！もうこれでLPTポート無くてもいいです！
↑ふつーに認識
↑そしてふつーに書き込み
JTAGkey2Cloneで使うためにはJTAGのOEを常時イネーブルにしておく
必要があります。※ispVMに対応するようにスルーモードをつけて
回路図差し替えときます。
もちろん外付けSPI-ROMにも書き込むことができます♥ispVMは多種の
SPI-ROMに対応しているわけですが･･･つまりこれはLatticeのデバイスが
JTAGで繋がってればUSB接続のSPI-ROMライタが安価にかつ確実に構築
できるというものすごいことでまさに神対応なわけなのです！！
これでマザボのBIOSいくらすっ飛ばして怖くない！
xilinxさんやalteraさんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…
いろいろ試す8
国内は大変苦しい状況が現在進行形で続いていますが、今は新しい生活が
始まる季節でもあります。ねむいさんも二度とていどひくいと
いわれないように言われないように毎年この時期に新たな決意をしながら
勉強を重ねてきたつもりですが彼ははるかにていどたかくなってしまって
やっぱ資質も必要だよねと思いつつLED点滅で足踏みして茶を濁す毎日を
送っております…そうかあの悪たれも今春から阪大か〜…#
…てわけで前回に引き続き今回も小ネタをこなしていきます。
●キャラクタLCDを2線で制御する
元ネタは中華サイトのBBSより。
2線と言ってももちろんi2c液晶ではないです。最低でもデータ4bit+制御
2bit分合計6本のI/Oの接続が必要なHD44780互換タイプのLCDモジュールを
受動部品を駆使してたった２本のI/Oで制御を行うとこのとです。
コンセプトとしてはでんし研氏の鶏卵問題を解決するAVRライタに近いですね。
↑実際にATMEGA1284Pを使用してやってみました。久しぶりにAVR使った…
20230629追:
11年後も同じ事やってる私
●LPC1114のI/Oトグルが遅い?…
> >>278
> main system clock４８Ｍで、ＩＯﾊﾟﾀﾊﾟﾀは約２Ｍだたよ。
とのことです。んなアホなと私も思いましたが、検証用のI/Oをトグルさせてる
部分のコード↓
while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}をGCC4.5.1の-O2でビルドして出てきた該当箇所のアセンブルリストが
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
390: 4a03 ldr r2, [pc, #12] ; (3a0 ) <-2cycle
392: 4b04 ldr r3, [pc, #16] ; (3a4 ) <-2cycle
394: 2100 movs r1, #0 <-1cycle
396: 50d1 str r1, [r2, r3] <-2cycle
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
398: 3101 adds r1, #1 <-1cycle
39a: 4249 negs r1, r1 <-1cycle
39c: 50d1 str r1, [r2, r3] <-2cycle
39e: e7f7 b.n 390 <-3cycle でリファレンスマニュアル首っ引きで調べると合計14サイクル、理論上でもシステム
クロックが48MHzで約3.43MHzくらいでしかトグルすることが出来ない計算になってし
まうので最適化レベルにもよりますけどやっぱしこんなものですね…
ちなみにガチでLPC1114で理論上とりうる12MHzのトグルスピードを出したいのならば
STR命令の部分だけ延々と続くようにしてやればいいので、
while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
〜(出来る限り沢山並べる)
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}ってしてやるとよいです。
この場合実際のトグル波形は↓のようになります。
Cortex-M0のSTR命令は最短2サイクルのため、GPIOがAHBバスに繋がっている
LPC1114では48MHzの場合は最高I/Oトグル速度は理論上12MHzとなります。
話は変わりますが、audin氏が指摘しているMARY基板で公開しているソースの
ライセンスが矛盾している件ですが、ねむいさん的には金銭が絡まない限り、
つまりソースコード自身はタダで利用できる状態のうちは別に大きく騒がれない
だろうと思われます(ぉぃ
などと偉そうに言ってるそういうお前はどうなんだと言われそうですが、私の
公開しているものは該当するスタートアップのコードはSTM32のアセンブラの
スタートアップコードを参考にしてarm-v6mでビルドが通すことのできる独自の
ものなので…
…ぇーとあのその…セ、セウト！
20111203追：
その後の顛末
あつ氏の見解
audin氏曰くMARYのライセンス形態が修正されたようです
i2c.h,i2c.cに関しては大本のNxPのKeil向けライブラリのライセンスに関する
文章を引用すると...
> Software that is described herein is for illustrative purposes only
> which provides customers with programming information regarding the
> products. This software is supplied "AS IS" without any warranties.
> NXP Semiconductors assumes no responsibility or liability for the
> use of the software, conveys no license or title under any patent,
> copyright, or mask work right to the product. NXP Semiconductors
> reserves the right to make changes in the software without
> notification. NXP Semiconductors also make no representation or
> warranty that such application will be suitable for the specified
> use without further testing or modification.
とのことです。
ざっと見たところ
"ここにあるソフトは製品(ここではLPC1xxx)のプログラムのしかたに
関する情報をカスタマーに提供する例示的な目的のためだけに書かれました"
ってのと
"(あなたが)このソフト使うことに(NxPは)責任も負債も持ちませんし
特許・著作権・製品のマスクワークのもとにあるライセンスや商標も譲渡しません"
という点がミソですね。再配布(redistribution)の制限に関する記載が見当た
らないのですが、再配布たことによって面倒なことになっても俺(NxP)は
責任持たないよと解釈しておけばよいでしょうか。
おまけ
MARY基板でaitendoさんの格安OLEDボード動かして見ましたねむいさんは
CheepにいくZE！これは公開しているプログラムに反映されています。
●SUG○IHUBはSUG○Iのか
http://www.system-talks.co.jp/product/sgc-4X.htm
ねむいさんはシステムトー○ス製のSUH○IHUBを副業元のノートパソコンで
愛用しています。SUG○Iハブは独自の電力増強回路によりUSBデバイスを安定
して動作させることができるという触れ込みです。確かにやっすいUSBハブでは
よく発生する「バスパワーのUSBデバイス挿しただけで突入電流で電圧ドロップ
して同じハブに刺さってるUSBデバイスも巻き添えで認識外れる」現象が一切
発生しません。しかし…
STM32のマイコン基板を一から組んででLDOの動作確認してる時に気づいた
のですが、このハブを使った時だけダウンストリーム側のVbusの波形が
えらめっちゃ汚い…
※ねむいさんが持ってるSUG○Iハブはこっちの少し古い型なので現行の
モデルでは改善されているかもしれません
恐らく独自の電力増強回路(=+5VDCDCコンバータ)のスイッチング時の
出力波形がもろに出ちゃってる感じです。デジタル回路だけならあんまし
問題無いですが、これアナログ含む回路だとこんだけ揺れてるとちょっと
都合が悪いです。
てわけでハブ側の改造でさらにSUG○くできるかしてみました。
基板はDC-DCコンバータとNEC製のUSBコントローラIC,そして2ポート分
(PORT1とPORT2)だけですがUSBパワースイッチャ(電源監視)ICまで積んで
あります。さらにダウンストリーム側には100uFのアルミケミコンが1ポート
ずつ鎮座しています。市販のハブのほとんどが最低限のパーツで寄せ集めた
チープな作りなのを鑑みると値段にしては超豪華な作りだと思います。
で、こんだけ出力に電解乗ってて波形があれってことはESR不足かな？
てことでDCDCの出力部に低いESRのキャパシタ乗っけりゃ解決かなと
判断してねむいさんのトラの子NEC-TOKIN製NEOCAP(150uF/10V品)を
ぶち込んだ！
よし！
てわけでさらにSUGO○くなれたようです。前途のとおりデジタル回路用途
のみなら未改造でも問題無いので昨今のUSB機能付きのマイコンでバリバリ
開発する人には多少のおいたにはびくともしないこのハブお勧めです！
●某付録のRX62N基板
国産マイコンは諸般の事情で全く興味ないので去年と同じく電源周りの挙動だけ…
電源立ち上がり
電源立ち下がり
去年のSH2A基板はLDOの出力が入力が断たれた後も0.数V程ず〜っとチャージを
保ったままになって次回の電源投入時に不具合が出ていました。しかし、
今回は+3.3VLDOにSBDをかまして素早くチャージを放電するようにしてあり、
しっかり対策されているようですね。
XMEGAを使ってみる4
たぬ
たぬ
たぬ！
ねむいさんもついにたぬたぬのOWNERになれた…
良いことあると良いですね〜♥法明院で見たとき以来惚れこみました♥
ちなみにこの子、前回たぬき村行った時にゲッツしたと言っていた物です！
…さて本題、Windows上でGCCにてAVR/XMEGAの開発が手軽にできる"WinAVR"は、
20100110版で開発は終了しており現在はATMEL公式から配布されているへとひきつがれています。
AVR ToolChain
そして以前から非公式で海外の掲示板で出回っていた有用なProgramMemory
アクセスの為のマクロが今回から正式にとりこまれていたりするのでここいらで
ちょっとまとめてみたいと思います。
そもそものはじまりはXMEGA触り出した去年にさかのぼります。いろいろ
文句垂れながらXMEGAを動かして来たわけですがARMではお茶の子さいさいで
できたはずの"FontX2ファイルのような大容量のデータを配列として埋め込む"
ことができないという点で躓いたことからでした。これAVRの制約というより
AVR-GCCの制約と言った方が正しいのですが、
１．引数が32767以上の配列を確保することができない
２ uint32_tの配列としてバイト数を稼ごうとしてもそもそも合計32767バイト
以上になる配列を確保することができない
３．64kb以上のメモリ領域のアドレスに通常のポインタを使って容易に
アクセスができない
と分かる範囲で上げましたが、普通はAVR使いの人はフラッシュメモリ容量64kb
以下のAVRを使いフォント等の大容量のデータはSDカードに置いてそこから
アクセスするという手段が常套となっていて今回私のように横着してCの配列
として大容量のデータをフラッシュに焼きこむようなことを安易に考えると
この問題に引っかかるというわけです。
これ何とかならないかといろいろ検索して調べていると数年前に｢ＰＩＣ
ＡＶＲ 工作室｣のnekosan氏も同じ問題に
当たられていたようでこの制約について非常に深い考察をされていました。
nekosan氏は最終的に制約に引っかからないようにいくつか分割した配列として
アクセスする方式にされたようです。また同日のコメント欄にはnekosan氏と
Chuck氏のやり取りがあり、その中で中にGET_FAR_ADDRESSという単語が
出てきています。これは後述しますが"３．"の制約を解消するための非常に
重要なキーワードとなります。
さて、制約はわかったけど実際どうすりゃいいのと言う話になりますが、
私はフォントファイルを直接オブジェクトにして焼きこんでCからは
インデックスだけ引っ張って来たらいいんじゃね？と考え、さらにググってみると
avr-freaksのフォーラムにavr-objcopyで行う方法の
議論がありました…って何年も前だけどこれあっちではFAQレベルなのか…
置き場にあるxmegaのFatFS+TFT-LCD表示のデモにはmakeファイル中に
具体的に美咲フォントをAnkと漢字ともにオブジェクト化しelfに取り込むための
記述をしてあります。
んでこれをCからアクセスするためにはavr-objcopyで吐かれたラベルを
参照すればおｋです♥
…と言いたい と こ ろ だ が！
64kByte以上プログラムメモリを持つAVRにおいて、64kByte以上の領域に
いつもの調子でアクセスしようとするとお次は"３．"の制約にあたってしまいます。
そもそもavr-gccはアドレスが16bitとして処理されていて、64kb以上の
メモリ領域にアクセスする時は非常に都合が悪いです(int型が16bitなのから
お察しできると思います)。たとえば…
prog_char inaisan[] = "daisuki!";
というプログラムメモリ上のデータを参照する際にこのデータがプログラム
メモリ上の64kByte以上のアドレスの領域にあった場合、
pgm_read_byte_far((uint_farptr_t)inaisan);
ってやっても配列inaisanの頭のデータ'd'は読み出せません。本来のアドレス
から65535さっぴかれたアドレスにある頓珍漢なデータが返ってくるでしょう。
これは本来24bitあるはずの配列のインデックスのアドレスを頭8bit分カット
した16bitで渡してしまうからです(ポインタ変数を介在させてもポインタの
サイズも16bitで、16bit分のアドレスしか表現できないから同じ結果)。
これを解消するのがGET_FAR_ADDRESSというマクロで、uint32_t型の値を返します。
このマクロを通すとpgm_read_byte_far等のELPMを使う関数へ24bitアドレ
として正常に値を渡すことができます。また、このマクロは長らく非公式でしたが
現在ATMELから配布されているAVR Toolchainではpgm_get_far_addressと
名をかえて公式にとりこまれることとなりました。めでたしめでたし。
…私の説明分かりずらいから各自pgmspace.h見た方が早いと思います…。
↑んで、見た目は去年と全く変わり映えしませんが上記のすべてを反映させて、
AVR Toolchainでビルドして動かしたXMEGAのデモさん。
やっぱARMの方が組みやすいなぁ…と思うことひとしきり
つらつらとまとまりきれないまとめを書いてみましたが、WinAVRからAVR Toolchainに
変わってから気づいたことのTipsとか
●unixライクなツール群
WinAVRにはARMマイコンのビルドにも重宝したutilsフォルダ内のmakeを含む
unixライクなツール群があったのですがATMEL公式から配布されたAVR Toolchain
には存在しません！代わりにavr-gccと同じフォルダに同等の機能のものが一切
合財ぶち込まれていますが、使いやすさを考えるとWinAVRのutilsフォルダだけ
保存しといて旧来のWinAVRよろしくビルド時にはそこからmake呼び出せられるように
すればモアベターだと思います。
私みたいなコマンドラインビルド野郎向けですがー！
20121130追：
WinAVRはもはや時代遅れです。WinAVRについていたutilsの代用は
こちらをご覧ください。
●EBIのSRAMモード
24ビットアドレスのアクセスの問題はプログラムメモリの時の問題だけではなく、
もちろんI/O領域にも波及しやがります。厳密に言うとAVR Toolchainとはあんまし
関係ないのですが、ATMEL配布のXMEGAのEBIのSRAMアクセスのデモが地味に
バージョンアップしていて、pgm_get_far_addressよろしく24bitアドレス用の
マクロが用意されています。
ねむいさんxmega使ってこれ以上やる気ナッシングになってしまいましたから
あんまし関係ないですが…
●delay.h
AVR Toolchainに変えたらmakefileで正しくクロック周波数を設定してヒューズも
間違ってないのに以前と違ってちゃんと動かねぇ！1！とお嘆きの方、utils/delay.hを
よ〜く見てください。
HAS_DELAY_CYCLESというdefineを1から0にすると幸せになれるかも…。
若しくは私みたいmakefile中でavr-gccにHAS_DELAY_CYCLES=0の定義を渡して
やるとよいです。
or
この問題、意外と根は深いようですね…
LPC1769を使う4
※トレランの記事を書く予定でしたがLPCXpressoLPC1769版が手に入ったため次回！
先日から騒がれはじめていますが、LPCXpressoのLPC1768版にLPC1769が乗っている
ものがある。という話。実際に市場に出回っているのはすでにLPC1769のものに
置き換わり初めているようです。ねむいさんもLPC1769版をゲッツしました！！
↑ご覧のように"TARGET LPC1769"と明記されているので安心です♥
↑LPC1768版で問題だったRTC用のクロックがピンコ立ちになってた件は今回の
LPC1769版ではちゃんとSMDの製品にかわりスマートな形状に戻りました。
1768版買わずにずっと我慢してた甲斐があったぜ…
さて、LPC1768とLPC1769の違いですが、単にクロック動作上限が100MHz
から120MHzに変わっただけです。
チップリビジョンも"-"の無印なのでエラッタもごっそり引き継いでいます。
細かい部分は各自エラッタシートをご参照ください。
以前に別基板で120MHzにて動作実験を行い、aitendoさんのOLEDを動かす
パフォーマンスとかもやってますが、今回もLPCXPresso1769版でおさらいを
してみました。
↑お約束で真っ二つに切断。
LPCLinkとかLPCXpressoIDEとかはもちろん一切使いません。
いつもの通りCodeSourceryG++とmakeとVersaloonとinsightを使えば
十二分に戦えます！
ところでLPC1114/LPC1343版ではフリースペースになっていた部位はLPC1769版では
I/Oピンが出ています。
このピン群の扱いは当面何も付けないでおいてあとあとどうするか考えます…。
とりあえず秋月のロープロのコネクタを両サイドに取り付けました。
↑二つに割ってしまったせいで+3.3Vの供給のことすっかり頭から飛んでましたorz
仕方ないのでVersaloonの3.3Vから拝借。他者の製品同士が合体して
なかなかシュールですね…。
↑Versaloon+VSGUIでSWDが繋がるのとOpenOCD立ち上げてLED点滅プログラムが
SWDデバッグ出来るのを先ず確認。
↑次にいつもの如く液晶表示とかやってみるのですが、今回はSPI接続
専用で128x160pixelなTFT-LCDを使ってみました！
コントローラICは皆さんもおなじみのST7735です。
↑表示周りは完全にモジュール化させてるのでデバイス依存部以外はほぼコピペです。
120MHzまできっちりまわせよ(某豆腐屋みたいな顔で)
…そういえば5か月くらい前に中華LPC1769基板をいぢっていたような…気のせいか…
前回と全く同じことをしているような気がするわけでもないかもしれなくもない…
LPC1769にはまだFatFs積んで動作確認させた実績ないので早急にベースを固めなけれ
ばなりませんね。
中華TFT液晶モジュールを動かしてみる(概論)
※今回の記事は適宜追加・修正していきます。
Arduino等のプロトタイプボードを使ってaitendoさんで売ってるようなMCUバスで動
かすタイプのTFT液晶を専用基板起こさずに無理くそうごかそうとするとどうしても
ジャンパ線山盛り配線になってしましますがこれを8bitじゃなくて16bitバスでやって
みるとどういうことになるかというと…
こういう地獄絵図になるわけでしてもう二度と横着しないと心に誓う。
さて、上の画像表示に使ったのはコントローラICにILI9327をもつDST9901A-NHと
いう3.2インチ、WQVGA(240x400)の液晶モジュールです。データシートには
コントローラICがHX8352Aとか書かれていますがブツはちゃんとILI9327です。
aitendoさんでも同じのを扱っていますが、私はtaobaoで他の商品と一緒に
まとめ買いした物です。
(ねむいさんはHX8352Aのものもちゃんと持っててこれはDST9901A-NHとくりそつなｎです
が8月位に一度ぱ…動かしてるところをお見せしてますね〜…ぬふふ)
データシートや製品紹介に記載されてる内容が現物と全く違うとか言うのは
中華液晶だけでなく中華製品にはよくある話ですが、TFT液晶モジュールを使って
何かを作るのではなくてモジュールそのものを動作させ(ただけで満足して飽き)
ることが目的と化してしまったねむいさんが得た情報をtaobao経由の購入の
事例にからめてお伝えします。
基本的にTFT液晶(とOLED)モジュールは大きく分けてRGB,MCU,シリアルの3つの
接続方法があります。MCUバスとシリアルバスで接続できるモジュールはフレーム
バッファを内蔵したコントローラICを必ず持っていて、AVR等のメモリ資産が無い
小規模のマイコンでも簡単に扱うことができます。
今回はそのMCUバスとシリアルバス接続方式のモジュールついて説明します。
●MCUバス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
↑i8080タイプのMCUバスの場合
ほとんどのモジュールはi8080タイプの8bit若しくは16bitのMCUバスとして
アクセスを行います。一部のモジュールではM68kタイプのアクセス方式を選択
できるものがありますが一般的にi8080タイプのアクセス方式の方が圧倒的
多数となっています(例外的にHD44780とかはM68kタイプですね)。
中規模のマイコンが持っている外部バスで接続したときは、マイコンからは
アドレスが2つだけあるSRAMに見えることになります。
このi8080タイプの方式はMIPI AllianceDBI(Display Bus Interface) Type B
に相当します。
また、データバス幅はコントローラICのデータバス幅選択ピン、ILI系列のICならIMx
に当たるピンをモジュールへのリセット信号入力時に信号レベルを確定しておくこと
によって選択されます。モジュールによっては外部まで出ておらず、FPC上のチップ
抵抗の配置によって決定しなければならない物や16bit幅に固定されてしまっている
ものがあります。
逆に低解像度でサイズが小さいものはFPCの面積的に8bitに固定されていたりします。
以下にaitendoさんでも購入できるモジュール達のビット幅変更箇所等を。
STM025QVT-001はソフトウエアからビット幅が変更可能な逸品なので
おきぱにあるソースコードを参照のこと…。
YHY024006A
EGO028Q02
上二つはFPC上のジャンパ抵抗(0ohm)の配置でバス幅を決定。
WBX280V009
FPC上のジャンパ抵抗(0ohm)を画像の位置に移すとIM0ピンが外部に出る。
…と以前書きましたが最近出回ってるのは少し違う模様。
なんと写真に示すとおりFPC上のパタンで16bitバス固定になっていました。
8bitバスで使ってる方や、Ardunio使いの方は別のTFT液晶モジュールを
使用しましょう。
DST9901A-NH
ビット幅選択ピンは外部に出ている。FPC上に抵抗を実装できるパタンはあるが、
前途の理由でFPC上で作業は不要。
ちなみにFPC上の該当のピンにIMxが出ていなくて実質上NC(NoConnect)になって
るモジュールもありますが、UEW等の極細の線でジャンパを飛ばしてやれば無理やり
ですが外部から選択もできます。ていうかこうしておく方がなにかと便利ですよぅ！
●シリアル(SPI)バス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
今日びの一般的なマイコンではほとんど有しているSPIインターフェースを用いて
接続することができます。基本的にMCUバス接続方式とアクセスの手順は変わらず、
パラレルのデータバスがシリアルになっただけです。
比較的小規模の解像度のTFT液晶/OLEDモジュールがシリアルバスの接続方式を
有しています。一部のモジュールでは外部ピンの設定によりMCUバスも選択できる
ものがあります。
このとき一部のコントローラICではシリアルバス接続だとREADができないものが
あります(よってMISOが不要)。
ST7735は一つのラインがMOSI/MISOを兼ねていたりして制御は少々特殊です。
READもするのならハードウエアSPIよりGPIOのソフトSPIの方が使いやすいです。
この方式はMIPI AllianceDBI(Display Bus Interface) Type Cに相当します。
QVGA以上の解像度ではコントローラICがサポートしているにもかかわらず設定用
ピンが外部に出ていないためシリアルバス接続方式が選択できないものがほとんど
でしたが2023年ではHVGA(320x480)解像度でもSPIインターフェースがありますね…。
逆に大きい解像度のRGBインターフェースをもつパネルにもSPI用のピンが出ている
ことがありますが、これはリフレッシュレートやガンマ値の設定専用という
あくまでRGB_IF(MIPI DPI(Digital Pixel Interface))の補助用です。
以下にシリアルバスで接続できるモジュールたちを。
aitendoさんのおなじみ小型OLEDモジュール。バス選択ピンの設定によりMCUバス
接続方式も可能です。このキャリーボードはSPI固定になっています。
コントローラICはSSD1332。少々癖があります。
・CSは8クロック目でD/Cの同期をとるため、下げっぱではだめ。
同じくaitendoさんでも売ってるH161T01。これを使った「TFT-LCD Shield」が
MTM06でNetSynth.orgのブースにて販売されました！そうだね宣伝だね。
お問い合わせはshield.ioはねむいさんまで!!
taobao経由で購入したシリアルの他にRGB,MCUバスも選択できてQVGAな液晶。
しかし前途のとおりコントローラICがSUCKと言う罠
同じくtaobao経由で購入した、シリアルの他にRGB,MCUバスも選択できて
QVGAな液晶。これはコントローラICが馴染みのILI9325なのでさっきのと違って
暴走とかしないで安定して動きます♥♥
…と思ったらdeviceIDを調べるとILI9325フルコンパチのILI9328であることが
分かりました…。まぁこの程度のチャイナリスクは想定済みです。
最近ebayを試用したときにego-chinaさんから購入したSPI接続専用タイプの
TFT液晶モジュールJD-T18003-T01。コントローラは皆さんおなじみのST7735です。
高速性は必要なくてちょっとした表示に使いたいなんて時に重宝します♥
そして小動物の足。
20110519追:
JD-T18003-T01には型番・外見はまったく同じですが、中のコントローラICが
異なる品種(ST7735R)があります。
ST7735RのものはST7735と初期化手順が異なるのでST7735のコードでは一切
動きません！ご注意ください！
しかもご丁寧にRDIDxで読み出すデバイスIDまで一緒なので私のいつものの
ディスプレイドライバのソースはST7735とST7735Rは分けてあります。
敢えてそうしてあります。
↑購入したばかりの状態だと保護シールのはがしタブの色の違いで
見分けがつきます…
さて、これらのマイコンから簡単に扱える液晶/OLEDモジュールは少し前までは国内
向けのリユース液晶をボｯタ価格で購入せざるを得なかったのですが、現在は大陸系の
電子部品屋であるaitendoさんがいわゆる中華TFT液晶モジュールを販売していて、
日本国内でも使いやすく安価な液晶を手に入れることができるようになりました。
通常の電子工作に使用するならば入手性・価格性・資料性・ユーザともにaitendoさん
で扱っている商品で十分なのですが、もっとマニアックなのを使いたいとかあやしい
液晶モジュールををあえて動かしたいとかいう奇特な人にはtaobaoで購入することを
お勧めします。こっからが今日の本題です！
●taobaoで売っている商品を買う
先ずtaobaoのメインサイトで欲しい商品を検索して探します。検索のときには当然
ひらがなカタカナはNGです。TFT液晶モジュールを探すなら"液晶屏"とかのキーワー
ドを絡めてみましょう。
めぼしいものを幾つか見つけたら買いたいものをいったんリストアップしましょう。
国を跨ぐので中国国内送料に加えて国際送料がかかります。小種類・少数だと効率
が悪いのでよく考えて買う物を決めましょう。
買いたいものが決まったら日本国内で購入代行をしてくれる業者さんに依頼します。
日本国内から業者挟まないで直接購入するのは日本住みでなおかつ故郷にも生きた
銀行口座を持ってる中国人くらいしか無理だと思います。
購入代行業者さんも業務形態・料金の計算方法などはさまざまですので説明をよく読
んだり質問した上で自分が購入する予定の物・値段・量・そして店舗数を考慮して
最適なところを選びましょう。料金の支払いは、落札作業前と日本に発送される前の
2回にわけて請求されることがほとんどです。
業者さんを選んだら購入依頼のやり取りを行いますが出来るだけ詳細を伝えるように
してください。こちらでは周知のことでも担当の人は基本的に部品知識は無いので
意図が伝わらないことが有ります。これこれこういう理由でこうしてくれ・こう伝え
てくれとお願いしましょう。また、購入は現地の落札担当の人が相手先店舗の人とや
りとりを行うことがほとんどです。その際に不明な点がある時は質問が返ってくると
きがあるので丁寧に分かりやすく返答しましょう。また価格が半導体部品で1元とか
異様に安い値段設定されているものもありますが、これはたいてい万個単位で購入し
た場合の価格のことで、**個なら一つ**元だがそれでもいいか？と返事がきます。
逆に他の店舗と比べて2/3くらいの微妙に安い値段で取り扱ってるのはリマーク品や
フェイク品がまぎれている可能性があるためよく吟味してください。
それと超重要な事柄ですが相手先店舗が製品紹介文に"資料は配布する"と明記され
てある時は落札時に必ずもらうようにお願いしましょう。言わないとブツだけが
来て解析に大幅に時間がかかります。もらえるものは全部もらってください！
20110404追：
taobao代行王さんで購入代行依頼した際に上記のお願いしても無視されます。
自力解析出来るor過去に動かした経験がある物じゃないとお勧めできません
しかしこれだけよく考えてやりとりしてもお国柄とんちんかんになりがちですが…
…っというわけで落札が終わりお目当ての商品が届きます…物や地域にもよりますが
2010.12現在だと購入代行依頼してから早くて3週間弱で手元につきます。
いていEMSで届けられます。
●実際に解析して動かしてみる
↑2.2寸の液晶モジュール。
落札時にデータシートを送ってくれと何度も頼みましたが対応してくれませんでしたorz
こういうことは非常によくあります。仕方なく自分で解析を行います。
解析の流れは以下の手順で進めます。
ピン配置の推定
↓
コントローラICの推定
↓
初期化手順の決定
↓
基本動作確認
TFT液晶モジュールを数種類以上触られてる人はご存知かと思いますが、FPCの
ピン配置はメーカーが違えどほぼ同様の"定番"なパタンのものがあります。
たとえばEGO028Q02とWBX280V009はピン配置が全く同じでキャリーボードが
使い回しできたりします(YHY024006Aもピッチは違いますがピン配置は同じです)。
そのことから同じピクセルサイズ&インチ数の液晶モジュールの中でデータシートが
手に入るものを調べ、記載されているピン配置から詳細不明のモジュールの
ピン配置を推定することができます。
幸いにもこのモジュールは一目しただけでわかるレベルでパタンが別れていて
容易にピン配置を推定することができました。
次に、液晶のコントローラICの推定を行います。ピン配置の推定した時と
同じように似たサイズモジュールのデータシートより候補とするコントローラICの
型番を控えます。
2.2寸のものは176x220ピクセルの品種が多いようですね。176x220ピクセル対応の
品種をあらかじめ絞り込んでおきましょう。これをもとにコントローラ内の
レジスタの値を読み出し、コントローラICの決定を行います。大抵は00h番地の
レジスタにコントローラ固有の"device code"をもっています。
ILITEK系列のものはほとんどこれでコントローラの種類を判別できます。電源電圧は
LED用電源を除いて3.3Vでほぼ事足りますが、一般的にはLCDモジュールでは標準的な
2.85Vが作れたらそれに越したことは無いです。
しかしこの液晶モジュールは読みだしても0x00が帰って来るだけでした。違う番地の
レジスタに値を放り込んで読むと放り込んだ値が正しく返ってくることから読み書き
はきちんとできていることが分かります(これができていない時はピン配置の推定まで
戻って調査しなおしです)。
私は上の結果から、176x220ピクセル対応で特定のレジスタ番地にdevice codeが無い
品種のものとして"HX8340B"がこの液晶モジュールに使用されていると推定しました。
ここまで絞りこめたら後はネットでこの型番を検索して初期化手順を調べます。
たいてい中華サイトから見つかるでしょう。なんせ中華液晶モジュールですから…。
ところでコントローラICのレジスタの値を読み出すとか言ってるけど具体的にどうすれば
いいの？という話になりますが、私の場合は動作実績があるILI9325系列のプログラム
を使用し読み出しを行っています。これはChan氏が公開しているOLEDテスト用の
プログラムをベースに各液晶モジュールにも対応できるように構造化させたものです。
またchan氏のFatFsのテストプログラムも兼ねています。
おきぱへ
上のおきぱにあるコードで実践していますが、"汎用で使える抽象的なレベル"と"
デバイス固有のレベル"なコードとを分ける、プログラムのライブラリ化/モジュール化
をしておくようにすると、未知の液晶/OLEDモジュールを調査する時やトラブル
シューティング時の問題の切り分けにも役に立つかと思いますので、コードサイズや
速度を気にしない方に強くお勧めします。
話は脱線しましたが、HX8340Bの初期化手順を作り、確認用プログラムを走らせます。
おっし！
こんな感じで上手くいけたら目的達成です。画面が真っ白でうんともすんとも言わない
場合はピン配置やコントローラICの推定まで戻って解析を進めましょう。
この液晶、大きすぎず小さすぎずで手軽に扱える掘り出し物を引き当てたみたいで、
ねむいさん的にはとても気に入ってます♥
次構想してる基板に載せちゃおうかな見たいな
20110824追：
その後の調査で宇顺电子のS95329というS95215Aを改変したモジュールである
ことが確定しました。
20111110追：
さらにその後改訂版のデータシートを手に入れ"Read HIMAX Device ID"
コマンド(0x93)でDeviceIDを読み出すことに成功しました。
データシートや資料が手に入ればここまで苦労することは無いのですが、何せ相手は
大陸なので資料が手に入ったとしてもまだ安心はできません。ふつーに全く違うデバ
イスの資料付けてきたり素で勘違いしてたりなんて日常茶飯事で私が経験してるもの
だとコントローラICがILI9320ものを指定して購入したつもりが実際に動かしてみると
"ハズレ"のLGDP4531で、資料として送ってくれた"ILI9320"の初期化ルーチンとやらも
見比べるとLGDP4531のものだったとかあってもう勘弁してくだち…
もしLGDP4531のものを引いてしまったら奇声上げながら窓から投げ捨てる以外にない
とおもいますね…(←本気でやっちゃだめよ！)
というわけでオチが無い話をつらつらと書き殴ってしまいましたが、そこまでしてチ
ャイナリスク負いたくない人は中華液晶モジュールばっかいじってる奇特な人と仲良く
なって動作が保証されてるのを譲ってもらうのがいちばんだとおもいまし た！
それといつまでも液晶デバイスばっかいじってても進歩がないので次はまぢで新しい
別の試みに手を出していこうと思います。
ちなみにおきぱで今もメンテを行っているSTM32F4向けTFT液晶モジュール表示
サンプルは以下のコントローラICに対応しています。いろんなサイト巡って集めて
きて、すべて動作確認を取っています。
当エントリは何気に当ぶろぐの一番人気のメインコンテンツの一角となってます！
20161028追:
現在、液晶ブームはひと段落したのか今度はESP-WROOM-02関連の記事が仏契です。
次点はブラウザベンチマークとか日本の自然歩道です。
20230801追:
ESP32やRaspi関連の絡みで液晶関連で参照数と問い合わせが
増えてきました…このエントリもだいぶ追い上げてます…！
↓以下、動作確認済みのTFT-LCDコントローラICです↓
*ILITEK
ILI9160
ILI9163B
ILI9163C
ILI9132
ILI9220
ILI9222
ILI9225
ILI9225B
ILI9225C
ILI9225G
ILI9320
ILI9325
ILI9325C
ILI9326
ILI9327
ILI9328
ILI9331
ILI9335
ILI9338B
ILI9340
ILI9341
ILI9341V
ILI9342
ILI9481
ILI9486L
ILI9488
ILI9806H(HALF-RAMモデルのためMCUバスには向かない)
ILI9806G
*Renesas
BD663474
HD66772
HD66773
R61514S
R61503U
R61505
R61505U
R61505V
R61505W
R61509
R61509V
R61526
R61580
R61581
R61581B0
R61408
*Himax(奇景光電)
HX8309A
HX8310A
HX8312A
HX8340A
HX8340B(T)
HX8340B(N)
HX8345A(T)
HX8346A
HX8347A
HX8347D
HX8347G
HX8352A
HX8352B
HX8352C
HX8353C
HX8353D
HX8357A
HX8357B
HX8357C
HX8357D
HX8369A
HX8369A-00
HX8369A-01
*NEC
uPD161704A
*Solomon Systech (International) Limited
SSD1332(OLED)
SSD1339(OLED)
SSD1351(OLED)
SSD1283A
SSD1286A
SSD1289
SSD1297
SSD1298
SSD2119
SSD1963(外付けタイプ)
*EPSON
S1D19122
S1D19105
*Sitronix
ST7735
ST7735R
ST7732
ST7781
ST7785(ST7787とまったく同じコードで動く/バスアクセスはかなり遅くすべし)
ST7787(バスアクセスはかなり遅くすべし)
ST7789V2
*MagnaChip
MC2PA8201(Nokia6300 & NokiaE51)
D51E5TA7601(HALF-RAMモデルのためMCUバスには向かない!)
*LG
LGDP4511
LGDP4531(←VCCｦ2.8V以下にしないと不安定になります！！！)
LGDP4535
LGDP4522
LGDP4524
LG4538(LGDP4538の誤字ではない)
LGDP4525
LGDP4551
*Samsung
S6E63D6(OLED)
S6B33B6(CSTN)
S6D0117
S6D0128
S6D0129
S6D0144
S6D0151
S6D0154
S6D0164X1
S6D1121
S6D05A1
S6D02A1
S6D04D1
*Raydium(瑞鼎科技股份有限公司)
RM68050(ILI9325と全く同じ)
RM68070(ILI9335と全く同じ)
RM68042
RM68090
RM68110
RM68120
RM68130
RM68180
*Orise Tech(旭曜科技)
SPFD5420A
SPFD54124B
SPFD54126B
SPFD5408A
SPFD5408B
OTM3225(ILI9325とまったく同じ)
OTM8009A(STM32F769I-discoveryでDSIにも対応)
OTM8012A(HALF-RAMモデルのためMCUバスには向かない!)
OTM4001A(R61509Vと全く同じ)
*統宝光電
C1L5-06
C1E2-04
*Novatek Microelectronics(聯詠科技股份有限公司)
NT3915
NT39106
NT39116B
NT35510
NT35516
NT35702
NT35582
*Tomato LSI Inc
TL1793
TL1771
*その他
SEPS525(OLED)
REL225L01
FT1505C
おまけ
駄目押しチャイナリスク
↑ﾜｰｨ USB3.0のExpressCardだ〜！
↑ｳﾎﾞｧｰ!
GPSを試用する
ライバルのNxPがLPCシリーズで攻勢をかけてきているさなか、STマイクロは4月頭に
新機種を発表したは良いがその後何の音沙汰もなくなってしまったりしてますがその
くせメインサイトはフラッシュを多用した使用に堪えないs**kなサイトへとしっかり
改悪したりしている(2010/11現在)昨今、皆さまいかがお過ごしでしょうか？
20101203追：11/30、この記事を書いたちょうどその日にに新ラインナップの
発表があったようです。
私はさる11月20＆21日に開かれたMake Tokyo Meeting 06にてGenie氏の手がける
NetSynthのブースよりTFT-LCD Shieldをついに正式リリースする運びとなったわけ
ですが、そこに至るまでに様々な人の助けをいただきました。とりわけgenie氏には
まともなパタンが引けないふがいない私に代わり、パタン設計を10割くらい手伝って
もらったりしてホントにご迷惑おかけしたのですがMTM06では無事に完売御礼とな
ったようでほっと胸をなでおろしております…。
↑なるみさん、このブログ見てたらどんまこクロックForARMの展示許可欲しいいの
でレスポンスくだち！１１！１
後ねむいさんがするべき仕事は上記シールドの初心者向けのドキュメントの整備とか
私のブログ上でも応用例を紹介する記事書くなわけですが…ぇ、あー…がんばります！
使ってるうえで分かりづらいところがあったら聞いてくだされば出来るだけ対応します。
と、いつもの前フリはこれくらいにしといて今回の本題は小型のGPSモジュールを
過酷なフィールドで使用した顛末とかを書いていきたいと思います。
事の起こりは、todotani氏の先例に倣いSTM32 Primer2でGPSレシーバー/ロガーを
作ることを思い立つことから始めたわけですが、先ずは心臓部ともいえるGPS
モジュールをaitendoさんより購入して選定を行いました。
選んだのはMMCXのGPSアンテナ端子がついたGM-316とアンテナも何にもない
すっぴんのモジュール単体であるG591という物です。
G591は変換基板も提供されているので安心のはずです。
さて、GPSモジュールで気になるポイントは受信感度と消費電流なわけですが、こちら
もモジュール単体で実測し比較してみました。ついでにめぼしいスペックも比較の為に
データシートより抽出してます。
↑どちらのモジュールも電流値が目まぐるしく変わるので平均の値をみてます。
私の使い方が問題かもしれませんけど捕捉と追跡で平均の消費電流が
変わらなかったんですよね…
カタログ上ではG591が受信感度が高くなっていますが、実際に使って静止状態で吐き
だされるNMEAのログを精査したところ、外部アンテナ付きのGM-316の方が衛星をしっ
かり補足していたので結局GM-316を選定しました。これ使ってるユーザも多いですし〜
↑これどうすっぺ…
お次はSTM32Primer2にこいつを具体的に接続する方法ですが…私は以下の回路のよう
にしています。VBATはジャンパコネクタを少し細工しリチウムイオン電池に直結です。
また、受信したデータを扱うプログラムとして今回Chan氏のGPSロガーを参考にさせ
て頂き、今後のとっかかり用として先ずはSTM32 Primer2でシンプルなGPSロガーを作
りました。実際の作り込みに関しては以前のプログラムの液晶表示部のルーチンをGPS
ロギングのルーチンに差し替えただけという手抜ｋふぁすとぷろとたいぴんぐを意識
したものですが、電源監視やSDIOのアクセス等の基本となる部分は去年よりみっちり
と作り込んでありますのでこういう芸当が出来るわけでさすがねむいさんですね。
まぁまだGPSのテスト段階ですから細かいところは追々と…。
消費電力削減に関して、MCUのコアクロック半分に落としたり要らないペリフェラルの
電源部を全部切ったりしていろいろがんばりましたが、GM316+外部アンテナを
ぶら下げた状態の総消費電流はだいぶ下がりましたが…
平均レベルじゃ頑張った方かな…。ここも真面目に勉強すべき個所ですね…。
今回の使い方だとSTM32 Primer2についているデフォの電池(400mAh)はで満タンでも
約5時間しか持たないことが分かったわけですがさらに実測で何時間もつかを試して
みると、長らくの酷使の為かたったの2時間半しかロギング出来ないほどバッテリーが
へたっていました。ということで交換を容量増強を兼ねてまたまたtodotani氏に倣い
リチウムポリマー電池を換装することにしました。
↑そうだね画像使い回しだね
これは1100mAhのもので単純計算で約14時間位持つことになります。
これなら日が暮れるまで山をうろつきまくってもばっちりです♥
(このとき、換装してちょっと動きを見ただけで満足してしまい十分なテストをしてな
かったことが後になって祟った…)
↑上手い事ケース内に収めてみました。山のなか走るので外部アンテナは必須です。
というわけで実際のフィールドでGPSモジュールを評価する準備ができました。
具体的にどこでどういう評価したかというと、東海自然歩道でトレイルランニングする
という機器が猛烈な振動を受ける過酷な環境で稼働試験を行いました。
ついでに言うと今回は私のトレイルランニングの初チャレンジでもありました。
私は全ての準備を整え(たつもり)、意気揚々と第一歩を踏み出したのでした…
し か し …
いろいろ試す5
以前購入したものの全く触れていなかったPSoC5を少し触りました。PSoC5は中の
CPUコアがMAX80MHzで動作するCortex-M3が採用されています。6月位にPSoC5の
評価キットPSoC 5 FirstTOUCHが安価で販売されたので、CypressからSRAMと
一緒に購入しました。
統合開発環境のCPUコア(Cortex-M3)プログラムのビルドはGCCです。
CodeSourceryG++を呼び出すようになっています。
P.O.V.による文字表示がデモプログラムが出荷時に書き込まれています。
電源を入れてぶんぶんふるとメッセージが順次表示されます。
今現在C言語ソースしかいじり方が分からないのでCypressのサイトの
チュートリアルでもみてツールの使用方法を覚えていきますか…。
以上前フリ終わり！
さて、ゆっこちゃんの誕生日(だいぶ前ですが)も無事終わり、少し落ち着いた
のでかねてから考案中だった複数のフォントに対応したFontX2ドライバ作りを
行いました。
ProjectC3氏のページの内容を元に以下のような動かし方にしました。
1.半角・全角ごとにFontX2ファイルのヘッダー部の構造体をSRAM上に構成する。
2.各フォントを登録するごとにSRAM構造体の分だけをｺﾞﾘｺﾞﾘ消費。
(というわけで比較的大規模のマイコン上での使用を想定してます)。
3.半角・全角ともにグローバルなFontX2の構造体ポインタを置き、文字描画する関数
群は全てこれを参照するようにする。
使いたいフォントで文字を描画する前に構造体ポインタに「1.」で登録した構造
体のアドレスを渡すようにする。こうすることで使用したいフォントを簡単に切り
換えることができる。
4.FontX2側のドライバは使用するFontX2ファイルの登録と、要求されたascii/sjis
文字コードに対してフォントデータの実体があるアドレスのオフセットを返す。
決め打ちでやるのならばSRAMなぞ消費する必要はないのですが、汎用性を上げたかっ
たのでこんな感じにまとまりました。今はまだマイコンのフラッシュメモリ上にFontX2
のデータをそのままのっけています。こちらも追々と大容量のSPI-ROMに追い出すつ
もりです。
というわけでSTM32やLPC2388のTFT液晶表示プログラムにそれを組み込みました。
タッチパネルの設定の際に使用しています。
当たり前ですがフォントそのものは同じなので以前のと見た目は変わりませんけどね。
表示に使用しているデバイスはSTM025QVT-001を使用しています。何気に使用可能な
MCUバス接続タイプのディスプレイモジュールの種類もどんどん増やしていってます。
あと、IJG JPEGライブラリを使用したjpegファイルのデコードの実験なんかも試みて
います。同ライブラリを使用したsirius506氏作成のmp3プレーヤーのフォトフレーム
部をそら氏がSH-2A向けに利用されたものをさらに参考にさせてもらいました。
いろいろ試行錯誤してようやくビルドが通ったのですがバイナリサイズが220kbyteも
膨れ上がってしまったのでフラッシュメモリ容量がMAX256kByteしかないSTM32F107
系には到底載りません。というわけでjpegデコード機能を乗っけるのはフラッシュ
容量が豊富なLPC2388やSTM32 Primer2向けのみ(将来的にはLPC1769も)
になりそうです。
QVGAサイズの場合LPC2388ではjpegデコードに必要な最低限のRAMは
1024*35=35840Byte
以上必要でした。RAMもそれなりに喰うようです。その際標準関数mallocがheap領域を
使用するのでスタートアップをいじりmakefile内で使用量を明示できるようにしました。
ｺﾂ
ﾒｶ
ﾜｳｿ
やっぱデコード->描画には多少時間かかりますね。他にもIJG JPEGライブラリは
リサイズ機能なんかもあってピクセルサイズが大きいものでも縮小してくれます。
今回使用した小動物たちの画像は大阪海遊館で撮影したコツメカワウソたちです。
まだ全く手を付けてませんが120MHzで動くLPC1769で同じことやるとどんだけ早く
デコードできるかちょっと楽しみです。
最後になりますが、少し前からTFT-LCDShield開発の折にtaobaoで液晶モジュール
などをいろいろ購入していました。その中でひときわ目立ってた3.5inch、
320x480の大解像度、それでいて扱いやすいi8080インターフェースで接続できる
液晶モジュールを紹介します。
デカイ！
で、デカイ！
72MHz駆動のSTM32F107VCT6だとSDカードから320x480,24bitの標準的なWindowsBMP
ファイルの一枚絵を読み取り表示するのに掛かる時間を測定したところ約360mSec掛
かりました。
(全画面消去->SDカード読み出し->RGBデータ24bit->16bit変換->GPIO転送)
普通これくらいの解像度になるとRGBインターフェースしかないのですがこの
モジュールはi8080のMCUバスで接続できるコントローラIC(ILI9481)が内蔵されて
いてAVR等のワンチップマイコンでも手軽に扱えます(ただし16bitバス強制)。
まだタッチパネルが搭載されたモデルは一般に出回っていないものの、簡易で
フォトフレームを作成するのなら見栄えがあるものができると思います。
おや？aitendoにも似たようなものが…？(棒読み)
追：私のはFPCの形状・ピン間隔・外観が全く違う別物です！
mbedとかLPCXPresso1768版とか超楽しそうスね(涙目)
TFT-LCD Shieldの開発に当たって、ねむいさんもついにArduinoを購入しました！
最初はEtherpodのプラットフォームだけで動かすことしか考えてませんでしたが、
HP200LX持ってないのにmorphyone作ろうとして盛大にコけたどこぞのぺ○野郎のこと
が頭よぎったので、ちゃんとArduinoを理解してライブラリも作れるようになるために
購入しました…。まぁSTM32ですでにできたことをAVRに移すだけですから驚くほど
簡･･･た…
ごめんもう白旗上げていいかな…(※xmegaの二の舞)
ところでxmegaで思い出しましたがxmegaでFatFS(のMSPI)をDMA化出来たという話を
全く聞きません。情報もってる人がいたら教えてください…
20120907追:
xmegaでFatFsのDMA化できるじゃない！
さて、前フリはこれくらいにしといて本題に入りますが、Cortex-M3の系統の
ARMマイコン、LPC1768を使用したハイエンドかつ安価な評価ボードがいくつか
出ています。
mbedやLPCXpresso(LPC1768版)等がそれに当たりますが、ねむいさんはそれの
どれにも手をつけず、taobaoで液晶買った時についでに中華LPC1768ボードを
買っていたのでした！！
↑のLPCXpresso1768版出るなんて知ってたら買ってなかったのですが…
くやしい…でも…
過ぎたことは仕方ないので私も通電してみることにしました。
↑KeilのMCB1700互換なミニボードだそうです。周辺が全くない代わりに
ほぼすべてのI/Oが外部に引き出されています。
↑即LPC1769に交換ッッ！！１!LPC1768を凌駕する120MHzで動きますッ！
恐らく私が日本国内で初めてLPC1769を動かした女になるでしょう(多分)
R&D dailyの綿谷氏がとうの昔にされていましたorz生意気言ってごめんなさいッ
マイクロマウスの開発されている方たちはなんとうか本当に格が違いますね…
さて、基本の'き'であるLED点滅から始めてみたいと思いますが、上述のとおり
MCB1700互換なので、NxPのサイトにある、
"LPC17xx CMSIS-Compliant Standard Peripheral Firmware Driver Library (GNU, Keil, IAR)"
というExample付きのCMSISライブラリがそっくりそのまま使えます。
GNU用のExampleはこれまたCodeSourceryの使用を前提にされていて、
ねむいさん的にも好都合です。手順に従い、程なくバイナリを生成出来ました。
バイナリの書き込みはもちろんJTAGKey2Clone+OpenOCDから行います。
LPC17xx系統の対応状況は現在JTAG接続のみです。NxP製のARMマイコン特有の
CheckSumValidationに注意してスクリプトファイルを作り、JTAG接続にて書き
込みました。書き込みの過程はこんな感じです。
↓
> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc1769_rclk_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.5.0-dev-00450-g450aaad (2010-07-22-09:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
none srst_pulls_trst
500 kHz
Info : device: 6 "2232H"
Info : deviceID: 67358712
Info : SerialNumber: 22222222A
Info : Description: Amontec JTAGkey-2 A
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lpc1769.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1769.cpu: hardware has 6 breakpoints, 4 watchpoints
RCLK - adaptive
Info : JTAG tap: lpc1769.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
flash 'lpc2000' found at 0x00000000
auto erase enabled
wrote 8192 bytes from file main.elf in 1.328142s (6.023 KiB/s)
verified 4968 bytes in 0.531257s (9.132 KiB/s)
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x000000e0 msp: 0x10007fe0
shutdown command invoked
現状LPC17xx系のアーキテクチャのすべてを理解はしていないのでLPC2388
みたく高速書き込み/ベリファイはまだ出来ませんが、そちらも使い込むに
つれ対応していきます。
↑LED点滅プログラムが動いてるところ。
↑JTAGkey2Clone+OpenOCD+Insightでのデバッグも自在です。
↑NxP提供のCMSISのExampleはLPC1768向けになっており、
それをそのままビルドしているので,動作周波数はまだ100MHzです。
まぁつかみはこんな感じでしょうか。私が行った最初のとっかかりのプログラムを
自分用環境に移植したものを
置いておきます。ご利用は自己責任で〜
おまけ
じっと見てたら気づいたけど何かに似てる…
いないさんのおしりに顔をうずめてくんかくんかしたい
※今日の日記は7月上旬くらいまでの内容です
(いないさんの)ぱんつだけカフェ…ぱんつだけカフェ…ぐふふ…
……おお失礼、ここ最近副業先の会社近くのカプセルホテルで寝泊まりするような
生活になってから意識が夢うつつな状況が多くなって…
(注：6月末〜7月上旬の頃の話です(重文))
最初はTFT液晶モジュール使ってなんか作るのが目的のはずでしたが今やいろんな種類
のモジュールを手にいれて動かすこと''だけ''が目的になってしまっています…。
でも8~16bitバスorSPI制御タイプのモジュールはあらかたやりつくしたのでそろそろ次
の段階に進もう か な と思っています(←同じこと言ってばっかですがー)
さて今回も、前回taobaoやaitendoで購入した液晶モジュールの火入れをやってきたい
と思います。まずは国内でも売られているのでご存知の方も多いでしょうけど3.5inch,
QVGAな少し大きめのモジュールを…。
コントローラICはSSD2119。8,16bitバス&SPI&(改造でRGB)も制御に使用できます。
いつものごとくSTM32で…powerMCU製のTFT液晶モジュール基板はコネクタに
出ている足配置が2.8,3.2,3.5"とすべて共通で、後はプログラムをこさえる
だけなので楽です。
…と思いきや3.5"のモジュールだけタッチパネルのPENIRQポート番号が
違ってました！！いやぁ慣れって怖いですねぇ…(しれっと)
てわけでタッチパネル制御も…コンパイルオプションでタテヨコ対応です。
STM32ライブラリのバージョンも上がったことだしそろそろSTM32/LPC2388用の
液晶モジュール制御プログラムも更新しましょうかね。
液晶モジュール&SSD2119のデータシートを眺めているとこのモデルは上記
CPUバス・SPIバスインターフェースの他にもSH2Aで使えるRGBインター
フェースも使用できるようです。
ただし基板には足が出ていないので自分で残りの足が出るように改造する
必要がありますね。まぁこちらは追々と…。
次に3.0inchでWQVGA(240x400)の縦長なLCDモジュールです。これはモジュールの
データシートを貰うことができませんでしたが、ネット上には同じ型種のモデルが
存在しピン配置も容易に推測できます。IM0,IM1が外部に引き出されており、
8bit,16bit,18bitCPUバスで制御可能です。コントローラはR61509Vだそうです。
得体が知れないのでタッチパネルが無い安い方を購入しましたが
案の定バリバリのユーズド品でした…。
16:9のWQVGAな画面を利用して某シングルCDのジャケットを…ドンピシャの画像…
↓
今の若い子って(まぁ私もわかいですけお)シングルCDとか知ってるのかしら…あ、
…失礼、さぁ次、次…(使ってるうちに反射板が剥がれました。なんじゃこりゃorz)
最後にaitendoさんで20%引きセールやってた頃に購入した0.94inch,96x64ピクセルの
OLEDモジュールALO-095BWNN-J9を。こちらはキャリーボードとセットも販売されて
いて、なぜかセットで購入した方がOLEDモジュール単体で買うより非常に格安でお得と
なっています(2010/07/05現在)
…？？？何で？？値段設定間違えてる？？それともセットのはなんかの不具合品？？
まぁいいや、STM32でとにかく動かしてみました。現在Lynx-EyED氏も活用されて
いますね。このモジュールは8bitCPUバスでも行けますがピクセル数が少ないのでSPIの方が
繋げる線も少なく楽でしょう。
ちっさ！めっちゃちっさ！…いつも3.2inchとか弄ってるのでやたら小さいです。
それとLynx-EyED氏も経験されてしまってるようですが、私もOLEDは焼きつくという
事実をすっかり忘れてしまっていて、冒頭のいないさんの臀部の絵を表示したまま
うっかり放置して焼きつかせてしまいました！！！みんなも気をつけよう！
…とまあ液晶モジュールはこのくらいにして次回は塩漬けにしていた各種評価ボードを
消化していこうと思います。
まずはCortex-M0なLPC1114のボード…
つずく
ペプシバオバブ
20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！
※内容的には4月下旬の頃ものです。古いです。
ぉ…結構いけるじゃん！
何時も二度と飲みたくないような味だったのにこれはイケるんじゃないでしょうか！？
コンビニにも今も置いてます♥
とりあえず生存確認の為に月一くらいは更新したかった今日この頃(駄目だったけど)。
春先にtaobao経由で安価な電子デバイスをたんまり購入しました。主な目的はaitendo
でも未だ手に入らない3.2inchの液晶モジュールだったわけですが壊したれたのと
全く同一の物が運よく見つかったおかげで復活しました。
●牙復ッ活ッ！刃●復ッ活ッ
考えて数揃えて買うと輸送量+手数料合わせても国内で少量買うより滅茶苦茶安く
つきますね…感動的だな。
ついでに目を引いた幾つかの液晶モジュール(そうだよまただよ)も買ったのですが、
これには罠が待ち受けていました…。
先ずはこれ。上で述べたものとは別の種類のさらに安価な3.2inchのTP付きな
液晶モジュールで、交渉のさいにモジュールコントローラICをILI9320と
指定して購入しました。
しかし…実際に届いたブツはILI9320用の初期化コードではどうしても動かず、
コントローラのIDを読みだしたりして(JTAGkey2+OpenOCD+insightのデバッグが
すごく役に立った)調べた結果、R61505UというILI9320と一部動作互換のICで
あることが分かり、モロに足止めを食らってしまいました…。
一瞬フェイクつかまされたかとビビってしまいましたが、初期化手順を正しく
行うとしっかり動いてくれて使えることがわかったので…まぁいい経験になりました。
20100817追：
3.0インチ以上は16bitバス制御しかできないモジュールが多いのですが、なんと
こいつにはバス幅を切り換える抵抗が存在していました！！
一気に使える液晶モジュールに！！
ちなみにaitendoの3.2inchQVGAの奴は出来ないです
いつもの。
んでもってタッチパネル(触摸屏)付きなのでBlueScreenの凡例をお手本にさせてもらっ
てタッチスクリーンセンサADS7843を使用したタッチパネル入力化にもやっとこ対応。
次にこちら。QVGAなLCDモジュールで国内でも手に入りやすく扱いやすいものは
8/16bitのCPUバスな物しか選択肢が有りません。こちらはそれに加え、なんと
SPI/RGBインターフェースによる制御も可能な一品です！
いろいろできそうだと勇んで6個くらい購入してしまいました！しかし…
実際に使用してみてわかったのですが、動作が安定しません…具体的にどういうことか
というと電源投入して約5秒以内に初期化動作に入らないとコントローラIC(LGDP4531)
がやたらと過熱しだして暴走状態になり、何やっても画面が真っ白のままと
なってしまいます。そしてその状態に一度はいるとモジュール内の残存電圧が
抜けきるまで電源落としてほっとかないと電源再投入後また即暴走の憂き目に…。
私にも落ち度があるのかと↓の項目いろいろ試してみましたが改善しませんでした…。
未使用ピンを全部GND直結->×
未使用ピンを全部VCC直結->×
スタンバイモードになってなくてもとりあえず強制解除操作->×
RESET端子にRESETICを付けてPOR出来るようにしてオープンドレインで制御->x
マイコンのVCCを3.3Vから2.8Vに落とす->×
MicroChipが配布しているグラフィックライブラリのLGDP4531用初期化コード->x(ｵｲ)
同モジュールが乗った出来合いの基板も購入したのですが結果は同じでした。つまり
モジュールそのものに問題があるっぽいです…。(初期化手順が不完全なだけか
もしれませんが、これ以上は情報が少なくて手出しができません)このモジュールを使用して
いる他の方も(Unstable)とされてますから同じ問題に直面されているようですね…。
20190726追：
9年の時を越えついに安定動作せしめる方法が判明しました！！！！！！！１１！！１
3.3V系ならばLGDP4531のLCDに供給する電圧をシリコンダイオード
とかで0.6V分おとして2.7Vくらい、2.8V以下で駆動させればOKです！！！！
こんなん分かるか！！１１１！！！！
20190726追：
まぁ一応電源投入してすぐに初期化動作を行うということを守れば言うこと聞いてくれる
ので、自分の中でだけテストするのであれば問題ないのですが…現時点ではこれ使って
売り物製作るのは無理っぽorz 以下にいくつかのモードで動かした画面をば…。
↑STM32F107VCT6でソフトウエアSPIモード
READして帰ってくるデータのバイトオーダーがデータシートの記述と違うんだが
…おいおい
↑STM32F107VCT6で16-bit,i8080cpuバスモード。出来合いボードの方。
ゆっこちゃんかわかわ
↑LPC2388で8-bit,i8080cpuバスモード,伝説のデス○リOP動画再生。
LGDP4531はさきに紹介したR61505Uと同じくILI932xと一部動作互換です。
動作不安定なトコ以外は。なんとかならないだろうか…。
つづく
ねむいさんは心がきれいだからウソなんて付けない
20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！
はぁはぁ…ま、また中華液晶モジュール買ってしまった…それはおいといて
今日はねむいさんがみなさんにいいこと教えちゃいます！！
aitendoさんのWBX280V009/EGO028Q02はコントローラがILI9235…じゃなくILI9325で
既存のコードがそのまま使える！！
それとYHY024006Aの商品ページでコントローラはILI9320ってなってるけどそれは
間違いで本当はILI9325なの！！初期化が微妙に違うからはまるよ！！
(20100720追:さり気に修正されています)
んでもってWBX280V009もJ4にあるチップ抵抗をR2に移すと8bitバス化できるけど
この改造でIM0が端子に引き出せられるようになるので外部から簡単にバス幅を切り
替えられますよぅ！！
(20100720追:
当たり前ですがこの改造を行ったら外部に出たIM0端子は使用するバス幅に
合わせてちゃんとレベルを決めてやらないとだめです)
(20101219追:
現在aitendoさんから購入出来るモデルは、FPC上で16bitバスに完全固定
されています。16bitバスでアクセスできないマイコンやプロトタイプボードを
持ってる人は、別の液晶モジュールを使用してください。
>このaitendoのWBX280V009は日を追って進化？しているようで、現時点でのロットではＦＰＣ上のパターンで16Bit固定となってしまっているらしい。
進化というかスペックがほぼ同じのとりあえず動いてるTFT-LCDモジュールをWBX280V009
という商品名で売ってるといった方が理解しやすいかと思います。
まぁ大陸系のお店やさんはえてしてこんな感じですので日本人同士だけの中で通じるような
理屈で買い物してるとえらい目にあいまくりです。
しかしながら中のコントローラがちゃんとILI9325なのは非常に良心的だと思います。
これがLGDP4531だとうごかなi(ry
それとねむいさんは某イベンツ向け用に液晶たくさん買い込んだけど中国某省
の5月にはぢまる催し物せいで上京できなくなって今現在使うあてが無くなった液晶
モジュールに囲まれて涙目なのですよｳｳｯ！
それとだれか(仕事はやめることなしに)自由に使える時間ください…
はぁはぁ…試される場合は今日の日付よく見た上で試してみてくださいね…
↓これは本当
いないさんは私の愛妹で
だーりんは私の旦那
XMEGAを使ってみる3
Versaloon関連で飛んできた人はこちらへ
年度末になると何でか糞忙しくなりますね〜…私はというと企業研修で来ている知り
合いの学生の子(去年11月下旬からSTM32初めてあっという間にマイクロマウスまで
製作ってた!!)に私のブログの内容をしてねむいさんていどひくいと罵られたり、
お客さんの現場で生暖かい目で見つめられながらハーネス打ちかえたり、私より一回
り年下の弟が私より一回り年上の彼女連れてきたりするなかで隙を見てマイコンの
勉強をやってきてます…。
LPC2388やSTM32系のMCUで動かしてきた大きめのTFT液晶、EGO028Q02や
YHY024006AをATXMEGA128A1にも導入すべく準備を進めてきました。
前回、現行のATXMEGA128A1にはPORTLが存在しないため4PORT-EBIが実質上
使用不可能と書きましたが、メモリアドレスを2つ(アドレス線は一本)しか使用しない
上記液晶たちは話が別です。FPGAボードを接続する前の肩慣らしに先ず4PORT-EBI
でTFT液晶を制御する試みを行いました。
ATxmegaのEBIに供給されるクロックはシステムクロックの2倍なので最高64MHzの
クロックスピードで動作させることができます。
高速のSRAMは恩恵を受けられるでしょうが、LCDからしてみると早すぎです。
read時だけウエイトを0->4に落とす等の細工をしています。
長々と書きましたが4PORT-EBIは無事機能して,YHY024006Aに画像やフォントを
表示することができました。
↑まだFatFs積んでないので容量の都合上このサイズの画像しか表示できないです。
ァァ残念だー(棒
あとATXEGAで試してみたい機能はADC,RTC,事象システム,FatFs(SPIをDMAにする)
搭載、それと今回試したEBIを今度は3PORT-EBIモードで大容量SRAMというか
それが乗っかったFPGAボードと接続する。そんな感じでしょうか
また、すｚ氏やいえなが氏も現在進行系でXMEGAを触られているのでお二方の
作品の完成もたのしみですね。
と、いつもならここで力尽きて日記が終わるわけですが…ていどたかい虹裏メイドを
目指すねむいさんもうちょっと頑張ってみます！！次いつ更新できるか分からないし！
私も多分にもれずSTM8S-DiscoveryというSTM32ボードを購入しましたが、以前から
目をつけていたVersaloonという汎用JTAGライタ/デバッガに改造を試みました!!
このVersaloonに使用されているマイコンはSTM32の48pin,ROM62kb,RAM20kB,
ペリフェラルとしてUSBが存在する物のようですね。そしてSTM8S-DiscoveryにSTLink
として乗っかってるSTM32F103C8T6はVersaloonになる条件をすべて満たします。
んでもっておあつらえ向きに書き換え用のJTAGの端子も出ているのでまずはUrJTAGで
様子を見てみました。
↑とりあえずJTAGKeyを繋げる…
↑ふつーのSTM32ですね〜…ちゃんとJTAGで見えます(ﾆﾔ･･
次にOpenOCDからフラッシュのバックアップを取ろうとしましたが…
↑やっぱしダメか…
というわけで一度STM32のフラッシュを書き換えてしまうともう2度とSTM8Sを
Discoverすることが出来なくなってしまうわけです。しかし！ねむいさんは
STM32のボードを購入したつもりなので容赦なく消しましたｵﾗｰ！！
次にVersaloon用の回路(後述のRelease1の回路構成)に作り替えます。必要なものは
12MHzのクリスタルです。STM8SにつながっているSWIMを構成している一部のピンは
VersaloonとDFUの動作を阻害するので必ず足上げしたりジャンパカットしてください。
注：基板の改造は必ず情報の1次ソースで提示されてる回路を参照してご自分で
判断を行ってください！！実験色が非常に強いのでここでは詳しく書きません！！
↑ねむいさんは横着なので基板からSTM32を外さずに無理やり上記の改造をしましたが
真似される奇特な人は基板から外して別に組んだ方がいいですよ?
ちょろっと出てるUEW線は用が済んで外したTDIとTDO。
↑使わなくなったSWIMのピンはDFUモードに入るためのモード
設定ピンに再利用しました。
中途半端に起立しているチップ抵抗がやっつけ感漂う…
VersaloonはDFUによりセルフアップデート出来る構成をとっています。
それに倣って最初はDFUを書き込みます…。
STM32F107系に慣れてしまった身ではとてももどかしいです。
JTAGで書くに越したことないですが、持ってない人は必要なピンだけジャンパ
引き出してシステムメモリからブートして書き込むって方法もあります…。
↑DFUが立ち上がりDFUDemonstratorが立ちあがったところ。
ここまで来たら勝ちです！
現在、Versaloonはいくつか種類があり、製作者のSimonquan氏のページから
ソース、回路図、ホスト側プログラム、OpenOCDへの対応方法などの情報は
すべて提供されています。
今回私はRelease1の回路を構成しRelease1用のファームをビルド、そして
DFU経由でVersaloon本体を書き込みしました。
↑出来上がったVersaloonを別のSTM32ボードと接続して、vsprogにて
JTAGモードとSWDモードそれぞれの方法で認識させたところ。
↑vsprog(gui)で書き込みもできます。STM32だけではなく
AVR/MSP430/PSOC/STM8Sも書き込めるようです。
↑SWDに対応するパッチを当てたOpenOCDを使用してSWDでデバッグ。
今は動作確認の為のやっけつの仮組ですが目的のSWDで使えそうなのがわかったので、
STM32を別の変換基板に移し替えて汎用のJTAGデバッガ/ライタに仕上げるつもりです。
今回の実験に使ったVersaloon用のDFUとVersaloon本体のプログラムをこちらに。非常に
実験色が強いので完全自己責任のご意見無用とさせてもらいます。
XMEGAを使ってみる2
NGワーオ：ARMその他32ビットマイコン
↑ねむいさんが余計な事を言わないため用
…さて、XMEGAを使えるものにすべく少しずつフレームワークを固めてきましたが、
今現在まだまだ手探り段階です。
↑突っ込みどころ満載な画像
私のXMEGA用の開発環境はコンパイラがWinAVR,ライタ/デバッガが
JTAGICEmk2です。主人の遺物から強奪したから譲り受けたJTAGICEmk2は
ハードウエアのリビジョンが古く、PDIモードが使用できないためJTAGモード
でしかアクセスできません!!
んでもって何でライタと書き込みアダプタをつなぐケーブルがFPCじゃないかというと
FPCコネクタがｶﾞﾊﾞｶﾞﾊﾞになってて普通の電線で無理やり繋げて修復するまで書き込み
すら満足にできなかったからですよｸｿｧ!!
…はぁはぁ…まぁコマンドラインツール使えるからあまり不便には感じませんが…。
この環境でフラッシュメモリに焼きこんだFONTX2ファイルやBMPファイルを
表示できるようになるまで出来ました。AVR使いの方はご存知かと思いますが
コンパイラやAVRのアーキテクチャそのもののいろんな制約で表示できるように
なるまで難儀しました。しかし一度峠越えて扱い方わかるともうあとは楽でした…
↑BMPファイルを表示した上にFONTX2(美咲フォント)で赤文字透過表示したところ。
一部誤字があってアレな部分が伏せ字になってしまってますが無害です(棒
バレンタインだったし！
…さて、こっから先どうするかを考えなくてはならないのですが、EBIを使って
SRAMとか繋げることも考えました。XMEGAで使用できるEBIはALE無しでもSRAMに
接続できるはずですが現行のXMEGAのモデルではEBIを構成するために必要なの
一部のバス(PORTL)が物理的に存在せず、実質上ALE使わないと大容量のSRAMを
扱うことができませんｸｿｧ！
…ｵﾎﾎ私ったら…失礼…
SDRAMはもっとひどいことになってるらしいですね…。
でもLCDを繋げるくらいならALE無しでも十分すぎるくらい賄えるので、前回の
液晶を先ずEBIで繋げてアクセスするところからはぢめます…。
それと今思いつきましたがMAI電子さんより購入した高速SRAM付きFPGAボードを
死蔵していますのでこれを利用しない手は無いですね…！
丁度fenrir氏がcblsrvをISE11.xでも使えるように更新してくれましたので…
ねむいさん今度こそ本気だす！！
↑やるやる詐欺
またTFT液晶モジュールかよ
20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！
…
え？この前買った3.2"の中華製TFT液晶どうしたって？
…どうしたもこうしたも…
"ワタシ大陸に帰るアル"って言って去っていきましたよぅ…
……さよなら5980円！！！！
…さて、つぶしｔ去っていった液晶さんの代わりにaitendoさんから
2.8"のTFT液晶モジュールEGO028Q02を購入しました…。
コントローラICは前回使用した2.4"TFT液晶モジュール
YHY024006Aと同じILI9325です。
コントローラICが同じだから前回のと同じソースコードが使えるかなと思って繋いで
試して見るとお案の定同じでふつーに表示できました！今までで一番楽だったです。
公開しているおソースは試用にあたって気づいたバグや記述ミスも順次つぶして
更新を続けていますが、試される方は自己責任でどうぞ。
↑まずはいつもの癒し系小動物を。
そしていつもはいないさんのえろす絵でお約束するのですが2/9に彼女が20歳の誕生日
を迎えたこともあって今回は真面目に行きます！おめでとう！ぐふふ…
見えてる方の画像は虹裏に投下していますのでびぃぶろぐでは無害です…無害です！
…さぁつぎいってみようか…えっと…今回はaitendoさんからは変換基板は販売され
てないので自分でユニバーサル基板使って製作しました。この基板は秋月の定番のや
つですね〜。
↑まぁお試しなので広めにとっています。広いとミスも減って組みやすいですし。
↑裏にはバックライトLEDドライバとタッチスクリーンICのADS7843を載せています。
ADS7843のおべんきょはこれからです。
また、今回の液晶を使用するにあたり、同じくEGO028Q02を試用しているそら氏より
YHY024006Aと同じく8bitバス幅でアクセスできる手法を教えてもらいました。
XMEGAみたいな8bitマイコンでも動かすことができるようにIM0端子を細工して外部
からプルアップ/ダウンでデータバス幅を切りかえられるようにしています。
↑EGO028Q02を改造したついでにYHY024006Aも同じ改造を。こちらはADS7843は無しです。
実物見た方は分かると思うんですけどね、データシート上ではIM0端子が出ているよ
うな感じがするんですが実際はNCなんですよね(中華サイトを巡るとNCと明確に記述
されてる同型異番種の物が存在する)…
以前触ったH161T01やYHY024006Aもそうですが、この辺実にチャイナクオリてi(ry
aitendoさんのTFT液晶モジュールを使う2
20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！
aitendoさんから抵抗膜式タッチスクリーン付きの2.4inchTFTモジュール、
YHY024006Aが販売されました。そろそろコントローラIC付きのおっきい液晶を
と考えていてのでねむいさんはすぐに飛びつきました！
この液晶モジュール単体は某中華製エミュレータ端末(コントローラICが同じかも）
やDSO nanoにも使用されているそうです。
データバスは8,16bitが選択できると書かれています。以前のSPI接続TFTモジュールで
中華クオリティはよく知っていたはずですが最初安易に8bitバスで挑戦して
敢え無く撃沈。
結局16bit接続でやり直しました。使用したMCUはもちろんSTM32F107VCT6です。
他のマイコン使うときは8bit分しか接続できなくてもラッチかましてあげれば16bitに
仕立て上げられるんで速度の低下に目をつぶれば何の問題もないでしょう。
変換基板にはIMOとかIM3とかバス幅切り替えられるようなシルク表記がありますが
どこにもつながっていないです！。
20100121追：vvtune氏が8bitバス接続でアクセスする方法を見つけられています。
これは…ありがたい…！
TFTの動かし方はSTM32に繋いでサンプルプログラムをSTM32用に移植(コピペ)して
そのまま"いっせーの ポン"で終了です(はしょるはしょる)。この辺は一度TFT/OLED
モジュールを制御する枠組み作ってしまえば容易なものです。
んでお約束のいつもの…
↑私は新しい液晶モジュール手に入れたら必ずこれやらないと体の調子が…
例の如くびぃぶろ君に怒られるので鮮明な画像は乗せることはできません(棒
…失礼しました…お口直しに小動物を…
↑ううむ、やっぱ画面が大きいってのは良いもんだ！？
このモジュールもとても安いので複数個購入するつもりです…
このモジュール使ってDSO nanoでっち上げられるので、107系使うためにCQ-STARM
基板から外したSTM32F103VBT6を使用して試してみる価値はありそうですね。
てわけで今回はこれにて！…と言いたいところですが実はかなり前に別経路で
中華製TFTモジュールを購入していたりする…しかも5980円も払って！！！
…悔しいので涙目になりつつもこっちも表示テストしてみます…
コントローラICは先のモジュールのものと同じメーカーのILI9320。ILI9325と
酷似したレジスタ構成でしたがデバイスの叩き方は微妙に違っていました。
コントローラICが同じでもモジュール内の結線の違いで制御方法がだいぶ
変わってきたりもするので吟味は必要です。しかし提供されているサンプル
片手に"ゲタ合わせ"しておけば後にやることは同じです。
あらよっと。
STM32 Primer2にFreeRTOSを乗せる２ -液晶表示のタスクを追加する-
あけましておめでとうございます(した)。
自分の誕生日(1/6)の準備してたりなんやかんやであっという間に10日になっちゃい
ましたね。忙しくてなかなか手が割けなくなってしまいましたが、今年もお気楽に、
たとえば"砕けた表現やアニメ調のイラストが目に障るので授業で資料として使いやす
いようにブログの記事を修正してほしい"って教育関係者とみられる方からまたクレーム
もらうくらいの感じでやっていこうと思います。これがゆとり教育の弊害かー(棒
それはさておきSTM32 Primer2にFreeRTOSを載せる試みを進めていっていますが、
今回はLCDのタスクも追加しました。さらに、ProjectC3氏のフォントドライバも使いや
すく汎用性を上げて実装しています。フォントは8~16ptまで対応で今回のデモには
フリーのM+フォント(10pt)と美咲フォント(8pt)をCヘッダファイル化した状態で使用
させていただきました(デフォルトはM+フォント)。
簡単に文字が扱えるようになると、出来ることの範囲もぐっと広がりますね〜。引き
続きFreeRTOSの動作を勉強しつつSTM32 Primer2で未使用の機能に手を出して見よう
と思います。また、STM32 Primer2とは別にもう少し大きい液晶を使用したデジタル
フォトフレームの構想なんかも練っている最中です。
↑だんだんサマになってきた!?
STM32 Primer2をBARE-METALで使ってみる(終) -フォトフレームを作る-
大きなバグ出しも終わってやっとこ使用に耐えるものが完成です。上位層の作り込みは
Chan氏のFatFsやターミナルプログラムの凡例のおかげで開発期間の大幅な短縮が
できました。そしてCircleOSに頼らないBARE-METALな試みも今回でいったん終了
です。
昨今の電子工作は回路検証はもちろんケーシングも非常に重要なファクターになって
いますが、もとからケースに入っているSTM32Primer2はとてもありがたいですなぁ。
…ってことで、
以下今回製作したフォトフレームの使用例を…
※20091226:電源監視機能を強化しました。
※20091126:USB-MSC(マスストレージクラス)機能を追加しました。
↑4+1入力キーの"真ん中"を押して電源投入。これはハード的に処理されています。
↑電源投入->タイトル表示後はSTM32Primer2に挿入されているSDカードを読み込み、
ファイラを起動します。ファイルシステムはFatFsを使用しFAT12,FAT16,FAT32の
フォーマット・およびロングファイルネームが使用可能です(画面上の表示は
8.3形式ですが）。
↑ファイラ画面の基本操作は↑↓がファイルポインタの移動、→がEnter,←がCancel
に相当します。
↑画像はbmp形式が表示可能で128x160pixelまでの物が使用できます。
それより小さいサイズは、真ん中合わせで表示されます。
画像はひねもすのたり氏画の私(ねむいさん)。
…びいぶろ君が欲情すると困るからピンボケ！
↑…すみません…お口直しに癒し系小動物を。otter-beerは結構有名らしいです。
↑動画はimg形式。img形式のファイルは同梱のChan氏謹製の付属ツールでaviから生成
できます。再生中→キーで一時停止、その後↑↓キーでコマ送り、戻しができます。
上の画像のは虹裏で活動している名無しの絵師さんの動画をお借りしました。
20091126追加
↑USBマスストレージモードに入るためにはUSBケーブルをSTM32Primer2の
"STM32"側のコネクタに挿し、ファイラのルートディレクトリでLeftキーを押します。
LCDの画面が暗転し、PCにディスクドライブがマウントされたら成功です。
20091126追加
↑MSCモードからファイラに戻るためにはLeftキーをもう一度押します。
ディスクドライブがアンマウントされ、ファイラの画面に戻ります。
↑UART2からの通信にも対応。上記結線(TTLレベル)でホストPCと接続。
↑ホストPCのターミナル(230400bps,8,N,1)上からESCキーを押すことで、ファイラは
終了し、FatFsのUART上のモニタプログラムが走ります。
↑現状では時刻設定はUART上のモニタプログラムからのみ可能です。
↑電源OFFは"真ん中"のキ―長押しで行います。この画面が出てからキーを放すと
FETスイッチが切れ"電源OFF"となります。
と、こんな感じです。ミニフォトフレームに機能を絞っているので以下に挙げる機
能は基板上には存在しますが使用していません。後は各人がソース変えてお好みで
付け足してくださいね(ひでぇ)。
*Not Used Devices
-Touch Sensor
-3D MEMS Sensor
-I2S Peripheral
-IrDA
また将来搭載予定の機能は以下に。
*Future Features
-USB-MSC 実装済
-LCD-Backlight Adjustment
-Adjustment Configuration which does not rely on host PC.
-Improve Backup Register Function.
-Improve Power Management 実装済
最優先はUSB-MSC。SDカードの抜き差しは面倒ですもんね。
USB-MSC実装しました。
IJG JPEG Library を実装しました！
んでもって修正すべき項目は以下に。
*Known Issues
-Cannot execute program if there's no Li-Ion Battery jumper. Fixed.
-Cannot execute backup function. Fixed.
現状Li-Ion電池のジャンパしてないとNo Batteryと判断されてしまいすぐに強制shutdown 修正済
されてしまいます。電源電圧の上手い監視方法見つけたらこちらはすぐに修正します。
ということでまだまだ手を加えるべき点はありますが、興味を持たれた人は試して
みてくださいね。ご利用は自己責任で〜
最新のFatFs移植例はこちらにあります。
STM32 Primer2をBARE-METALで使ってみる5 -FatFsの実装-
もともとBARE-METALで取り組むのを決めたいきさつは、Chan氏のLPC2388向けの
OLED表示プログラムを"STM32で再現できたら素敵じゃないか"って構想から
始まって少しずつ実現して来たわけですが,STM32Primer2でも再現してみたい！
という思惑からはじまってます…。
今回その要であるFatFsの実装にとり掛りました。STM32F107VCT6ではSDカードの
アクセスにSPIを使用していましたがSTM32Primer2(STM32F103VET6)ではSDIO
インターフェースが搭載されているのでこちらを使います。
またSDIOのドライバはSTマイクロさん本家からMassStorageClassのデモの形で
提供されているのでRowleyのサイトにある移植例を手本ni
"ゲタ"合わせを行いました。(ベースはSTM32F107VCT6のFatFs)
LCDの時よりかは手こずらずに移植は完了しました。が、いくつか引っかかる点が…
�ヽ笋蟾�み版のUART-Txを使うとxprintf関数を実行したときうまく表示できない
いろいろやってみましたが文字の送信がうまくいかなかったので折角割り込み版をこさ
えたのにポーリング版に戻したorz(Rxは割り込みでも問題なし)
私の経験と知識の無さはこういう形で表れてくるorz
20100317:FIFOバッファの処理が不完全なだけでしたorz
��RTCの初期化がうまくいかない
STM32Primer2は電力消費を抑えるためにVbat周辺の回路も同じく低消費電力化されて
います。以前の回路ではうまくいってたバックアップ方法は今回は動きませんでした。
具体的に言うとバックアップレジスタにマジックナンバを書いておいてその有無でバッ
クアップされているか判定していたのですが、STM32Primer2の回路だとそこが正しく
読めない…仕方ないのでマジックナンバが書かれているかの判定部分は削除しておく
と時刻情報はかろうじて保持されているのでひとまずこれで進めることに…
開発が落ち着いたらバグ出しついでに上記2点の問題おっかけます。特に大きな支障は
ないので今は対策を保留…。
20100317：RTCの初期化に問題があってバックアップレジスタへの書き込みを
禁じた状態で書こうとしてましたorz
とりあえずFatFsが動いたので読み込み転送速度の比較を行ってみました。使用した
SDカードはATP製の4GBSDHCカード。Class6のものです。比較検証用のファイルは
L氏のwebラジオ、"Lの虹裏ピアノラジオ"を録音したmp3ファイル(132MByte)を
使用しました。
↑まずSTM32F107VCT6の(SPI,18MHz,DMA使用)で…まずまずです。
↑次に今回STM32 Primer2に実装したの(SDIO,4bitmode,24MHz,DMA使用)…あれれ、思ったほど伸びませんでしたね…。
今すぐ下の方見ろ！！！１１！
↑最後にChan氏のLPC2388用MCIアクセスプログラム(MCI,4bitmode,18MHz,DMA)
ううむ…ぶっちぎりですなぁ…。
STM32のSDIOはもっと伸びるとおもうんですけどどっかでフン詰まりになって
いるようですね･･･まぁ現状でも十分すぎるのでこちらの件は以後の改善課題
としておきます。
というわけでマルチセクタ転送にちゃれんぢしてみました…
〜小一時間後〜
↑
やばい超早い♥
20111111追：
時は流れ、STM32F4では48MHzのSDIOクロックでも安定して動かせられる
ようになったので、約21Mbyte/Secの読み出し速度を常にたたき出してます！
次回は今まで検証してきた成果をすべて組み合わせ、BARE-METALなプロジェクトの
到達目標としていたPrimer2用フォトフレームの制作に挑みます。
STM32 Primer2をBARE-METALで使ってみる4 -FSMCとLCD-
もうすっかり使いこなせて当然…なはずのカラーグラフィックLCDのつもりでしたが結構
苦戦しました…。STM32Primer2ではLCDの結線はSTM32のFSMCを使用したバス接続
となっていて、CircleOSもこれを利用してLCDの操作を行っています。LCDモジュールの
コントローラICはST7732。以前のTFTモジュールやi2c液晶なんかとおなじメーカの奴です。
ST7735の時と同じ風にやったら楽勝だろうと考えていたらモジュール内部で完結して
いるICのモード設定ピンの関係に気づくまでどうしても表示がうまくいかなくて
うｎうｎ唸っていました。コントローラICが同じもしくは同等品であっても
モジュール全体でみると初期化・制御の仕方とか微妙に違うってことを
思い知りました(いまさらか)。
上記のことさえ注意しておけば後は特に気にすることなくすんなりと一枚絵の表示まで
こぎつけました。128x160フルに使って表示できます。
※性的描写があるので小さく表示
↑ごめん…またいなちゃんなんだ…もう許してもらおうとも思ってはいない
…でもやめられない♥
今回はWindowsで普通に作成できる24bitのビットマップをそのままC言語ヘッダ
ファイルに変換して直接読み込んでいます(内部で16bitに変換してます)。
FatFsが次に控えているのでそれを意識しています。
後気づいたことを一つ…
CircleOSのフォーラム見ていると拡張コネクタから出ているi2cやcanがFSMCからの干渉
でうまく動かないなどのことが議論されています。回路図見た感じではFSMCのバスは外
には手軽に出せないし現状LCD専用状態だしで、あんましFSMC使うメリットが見当たら
ないように気がしますが私の検証用のプログラムはCircleOSのを真似てFSMC使っています。
STM32Primer2をBARE-METALで使ってみる3 -ADCによる電源監視とUART2-
前回はSystickタイマを利用したスイッチ入力で電源の制御を行いました。しかし
電源を付けっぱなしにしているとどんどん電力が消費され、ついには3.5Vを切って
しまいます。（リチウムイオン電池の詳細な特性については他の専門に解説されて
いる方たちにうっちゃる(うｎ？)として、）実際3.5V以下になると急速に電圧が低
下していってしまうという特性があるので3.5Vできっちり止めなければなりません。
STM32Primer2はリチウムイオン電池の電圧低下をハードウエアで監視する機構がな
いのでSTM32に内蔵されたADCを利用してソフト的に監視し、3.5V以下になったら強
制的にシャットダウンする必要があります。今回はCircleOSのDMAを利用したADCと
過去の自分のコードを利用して電源監視ルーチンを作りました。
電源監視ルーチンはCircleOSで行っている方法とほぼ一緒で、1Secごとに移動平均
化されたVbatの値が3500(3500mV)になりさらにそれが15秒間連続した時にSHUTDOUN
信号を出してFETスイッチをOFFにするというものです。
そしてこの機構が実際に機能しているかどうかを確認するためにモニタリングする
必要がありますが、この検証には背面の拡張コネクタから出ているUART2を利用し
ました。このUART2のルーチンも自分の過去の(ry)でprintfにリダイレクトさせるよ
うにしています。
以前107系等で組んでいた時はUART-Txだけは割り込みを使用せず、ポーリングで回し
ていました。今回UART-Txも割り込み方式に変えています。それで初めて気づいた
のですがprintf等使用時に高速にバッファに転写すると早すぎて割り込み処理が
間に合わず、文字列が反転した状態で出てきてしまいましたので少し細工を行い安
定して文字列を送信できるようにしました。
↑大活躍の極小USB-Serial変換(画像右上)。
以上の条件下(72MHz駆動,LCDバックライトは未制御のため全点灯)でUART2から文字
列を排出した状態で電源電圧低下を感知して自動で切れるまでモニタリングを行い
ました
上図の結果のとおり、満充電4.1Vから徐々に電圧が落ちて行って3.5Vに差し掛かっ
たところでFETスイッチが切れています。また3.6V付近から電圧の落ち込みが急速に
早くなっているのが分かりますね。自働強制シャットダウンまで約4時間まるまる
かかりましたがCPUは最高速度,LCDのバックライトも未制御の最大輝度ですのかな
り電流喰っている状態です。この二つを制御できたらさらに持つでしょうね。
次回はFSMCを使ったLCDの制御に入ります。
FSMCは全く使用したことがないので少々手こずりそうです。
aitendoさんのTFT液晶モジュールを使う
20101228追：
MCUバス接続タイプのTFTLCDモジュールを動かしたい奴は必ず読め！！１１！
かねてから興味があったaitendoさんの液晶モジュール、ZY-FGD1442701V1が手に入っ
たので早速使ってみました。現在はそら氏がATMEGA644Pで画像の表示まで達成されて
いますね。私はいつものSTM32F107VCT6で攻めてみました。
この液晶モジュールのコントローラはST7735で、データシートみる見る限りでは
chan氏のOLEDの時とほぼ同じようなアクセスの感じに見えたので、前回STM32に
移植したOLED用のコードとサンプルコードをもとに新たにST7735用のコードを
作りました。
STM32のローレベル部分はこさえてあって表示部分はchan氏の非常に柔軟なコードが
ほぼそのまま使えたので、はんだつけ工作も含めて移植は半日も掛かりませんでした。
で、OLEDでやってたミニフォトフレーム(?)をTFT液晶モジュールでも再現。
↑やや青みがかってますがOLEDモジュールに引けを取らないほど発色がよいです。
そら氏がされているようにガンマ値いじればさらに綺麗になるでしょうね。
↑周囲を暗くして写して見ました。デジカメでうまく撮るための工夫を考えねば…。
↑ああ、残念だ。美しいいないさんの肢体が輝度が高すぎてで光学迷さ(ry
↑おやくそくはおいといてコツメちゃんを表示。うまくいった後はBEERがうまいぜHAHA！
ﾀﾌﾟﾀﾌﾟ
液晶モジュールのデータシートはロジック3.0V,LEDバックライト3.3Vまでと
謳われていますが、ロジック部のコントローラST7735は3.3V(絶対最大定格4.6V)で
運用可能です。
ねむいさんはST7735のほうのデータを信用したので(良い子は真似しちゃだめよ！)
STM32F107VCT6動かしてる3.3Vの単一電源だけで液晶モジュールを動かしています。
多分稼働寿命対策でモジュール単位では低い電圧で運用してもらううつもりで書いて
あるんでしょうけど、遊びで使うなら3.3Vでもなんら問題ないでしょう。
STM32ではうまくいったのでお次はLPC2388でもやってみます。安い上に非常に
使いやすいのが分かったのでもう5〜6個ほど買うつもりです。
色々直す…
…前回の検証でSTM32 Primer2に乗っかっているSWレギュレータIC(L6928D)を、
2つとも吹っ飛ばしてしまいましたが、これらはU9:メインMCU電源供給(2.85V)、
U17:バックライト用電源(3.1V)向けという非常にクリチカルな部分に使われており
どちらか一つでも壊すと、もはやPrimer2は使用不可能になります！！あほか！
仕方がないので代替で使用できそうなレギュレータを探し貼っ付けました
L6928Dは非常に繊細だとのことでもう使わない方向で…
まずバックライト電源生成部。元の設計上では3.1V出力ですが実際は3.2V近くです。
また、カラーLCDのバックライト電源は3.3Vまで使用可能でなおかつSTM32Primer2が
監視しているリチウム2次電池のシャットダウン電圧が3.5Vな点から、いつものLT1963A
先生に代役してもらうことに。電流は500mAも引かないので3.5Vまで落ち込んだ時の
ドロップアウト電圧も気にならないレベルです。これでもう一寸安くなってくれたら
ねむいさん的に最強のLDOなんですけお…性能が高い分お値段も高いんですよね。
次に2.85V生成部なんですが身近にすぐ手に入る2.85V出してくれるちっさいサイズの
レギュレータがLP3988しかありませんでした。残念ながら150mAしか引けないので
STM32Primer2回すだけで精いっぱいです。外部に機器を接続する時は別口でとらざるを
得ないです。耐圧はL6928Dよりも0.5V高いので過渡電圧余裕も確保…かしら？
一度は死んだSTM32primer2でしたが措置を施し電源が修復強化されて無事復ッ活！！
ちなみに10月11日は同僚のヤクいさんの誕生日なのでした！
そしてもうひとつ、不注意で壊してしまった(輝度が異様に下がってしまった)OLEDの
代わりに新しいOLEDの基板がやってきました。前々回もお見せしましたが、chan氏の
LPC2388用のOLEDアクセスプログラムをSTM32F107VCT6に移植しています。
LPC2388のFIOはI/Oクロック36MHzの高速アクセス(最高I/Oトグルスピード18MHz)が
できてOLEDも非常にスムーズに表示できたのですが、STM32もほぼ互角のI/Oアクセス
性能を持ちます。
ただし、STマイクロ提供のライブラリ関数からだと呼び出しオーバーヘッドが掛かり、
直接GPIOレジスタにアクセスする必要があります。
さらにSTM32に(というかCortex-M3)はビットバンドによるアクセスができるので、
うまく組むとLPC2388より早くアクセス可能でしょう。
今回は便宜上GPIOEのみを使用してOLEDを制御したので1命令分多くかかっています。
というわけでSTM32F107VCT6でOLED動かしたところ↓
嗚呼残念だ、せっかくのいなちゃんのえろすな絵が輝度が高すぎて光学迷彩が
掛かったみたいな写真になってしまったー(棒
…とふざけるのはここら辺にしといてカラー写真とかもOLEDでは綺麗に表示できてい
ます。モデルはコツメ氏。カワウソって良いですよね♥特に頭の形とか♥
はてさて、STM32の新(OTGを含む)USBライブラリのリリースはもう少しのはずです
が…。待ち遠しいですね〜。
LPC2388に実装したFreeRTOS上でEthernet-PHYを使う(だけ)
どうしてもWinARMを使いたいのなら20060606版を使え！
20080331版は一部の標準ライブラリが無いから使っちゃらめぇ！
↑これはねむいさんの独り言です。ねむいさんはCodeSourcery G++を使用することを
強く強くお勧めします。
…さて本題、FreeRTOS配布パッケージにあるLPC2468のデモはMCB2300デモボード
上での使用を想定してオープンソースなTCP/IPプロトコルスタックであるuIPが使用できる
ように組み込まれています。前回は外付けEthernet-PHY(DP83848)の回路を持っていな
かったのでその機能は外してRTOSの動作を見ていましたが、Digi-keyで頼んだ部品が入
ったのでEthernet-PHY周りの回路を製作し、改めて動作の確認を行いました。
Ethernet-PHY周りの回路はMCB2300の回路の丸パクリです…。回路図引く手間が省けた
50MHzの高速なクロックを扱うので、"びびり"なねむいさんはメッシュアース基板で回路
を組みました。基板組むのにかかったお値段は2944円也。QTFP変換基板やメッシュアース
基板使わなかったらもっと安く作ることができるでしょう。動作は保障できませんが。
ChanさんみたくUEW線を活用してカッコよく引き回せられたらよいんですけどね〜…私の
腕ではこれが精一杯ですorz
基板上を走る黒いリードはAWG32・UL3417の超極細耐熱電子ワイヤー。少しかさははり
ますがUEWより扱いやすく、重宝してます。また、CQ-FRK-NXP-ARM基板上の3.3Vレギュ
レータの容量が心もとないので(他のデバイスぶら下げること考えて)Ethernet-PHY基板
用に別途3.3Vレギュレータを設けました。昔秋月で販売していたL1087を使用してます。
一応50MHzのクロックのラインは最短で這わせています。オシロで見る限りでは、
ちゃんと所定の50MHzの周波数で発振しているようなのでひと安心。
ここまでやって失敗してたら死ぬわ。
↑オシロのグランドリード伸び伸びのやっけつ測定。一応50MHzは出ているが…
後はソフトの方ですが公式のFreeRTOSソースはVerUpされてすでにV5.4.0になってます。
以前動かしたLPC2388用のデモソースもV5.4.0上で問題なくコンパイル・動作確認でき
ました。んで、以前はコメントアウトでオミットしていたuIPのタスクとLCDのタスクを
再び復活させるのですが、LCDのタスクは台湾BOLIMIN製のi2c液晶モジュー
ルのルーチンに差し替え、さらに48MHzで動作させていたFreeRTOSを72MHzで動かします。
オリジナルのLPC2468のデモは48MHzで動かしてたのに今気づいたorz
そんなこんなで無事にWebServerが動作しました。i2c液晶もオリジナルのLCDと遜色なく
表示ができています。printf系の関数もHeap_3.cを使うことによりうまく機能しました。
(printf系はOSから正しい手順で動かす方法あるはずなんで調査中です。)
元のLCDのソースには80段階でバーグラフ表示させるルーチンもあったので、ST7032iの
ライブラリに移植してます。初めて知ったけどこれ使って面白いのが作れそうですね〜。
↑てわけで早速使って組み込んでみた。
今同時に進めてるCortex-M3も将来的にはSTM32F107系に乗り換えるので、RMII接続できる
Ethernet-PHY基板はこれからも重宝しそうです。
本日のソースはこちらに…。先にも書いたけどEthernet-PHYの回路はここ参照のこと。
お約束ですが真似して試される場合は自己責任でどうぞ！
LPC2388のCDC(仮想COMポート)を使う
１週間前、臨時収入が入りましたので今まで購入したいと思っていた電子部品
や評価基板をいくつか注文しちゃいました。夏物の服は「茄子」が入って
バーゲンになって値段下がってからでいいや。それまでに売れてくれるなよ…！
…そのまえに今年茄子あるかな…。
少し前にLPC2388にあるUSBホストのサンプルの追実験をしましたが、USBターゲット
を含めたサンプルコード集もNXPのサイトで提供されてます。コード集にはUSB-CDC
(仮想COMポート)の作例もあってRTCやUARTは簡単にできたので次はこいつを
ポーティングしてやろうと画策しました。
…しかし、これのUSB-CDCのは割り込みや構造体の定義がGCCとの互換性が
全くと言っていいほど無くてコードをポーティングするのが一苦労。しかもコンパイル
無理やり通してバイナリ焼き込んでも案の定動作できねぇ！！１！
XPでUSBデバイスを認識したときのあの｢♪ﾃｺﾝ」が鳴ってくれない…
結局２〜３日格闘して私のぎじゅつ力じゃこれ以上は無理と白旗上げてしまいました。
(ネットの記事漁るとちゃんと出来てる人もいるみたいです…くやしい…でも…)
なんかよい情報はないものかと海外のLPC2000のフォーラム等をいろいろあたると
GCCでソースが公開されているLPCUSBなる物があることを知り、これを叩き台にして
LPC2388向けのUSB-CDCデバイスをこしらえることに。
もともとはLPC2143用だったみたいですが、数年前にLPC2378向けにも使えるようにアップ
デートされていて、大きな変更もなくLPC2388基板で無事｢♪ﾃｺﾝ」を聞くことができました。
その後はSTM32とおんなじようにprintf使えるようにリターゲットして、以前のRTCの
サンプルのCDC版が動くとこまで確認。
懸念してたUSBの動作と他の複数の割り込みの動作の干渉も特に問題ないみたいです。
とりあえずLPC2388上で"動く"とこまで持ってけましたが、"どのようにしてUSBデバイス
として動いてるか"の理解ができないとこっから先はやってけないと感じてます。
点と線だけで繋いでいた知識のリンクを面で囲っていけるようにしたいです。
私のおべんきょはさらにつづく…。
というわけで本日のおソース。試される場合は自己責任で…。
TFT−LCD表示プログラムのUART処理部に統合しました。
ねむいさん向けにかなりいじくり倒してるので、本格的にされる方は本家の
ソース当たった方がいいと思います。
Project Examples and Misc Files
ねむいさん専用のFatFs中心のサンプルコード・プログラム置場です。
私が使いやすいようにGCC環境に勝手にポーティング&改造してあります。
文書の記述間違い・バグを見つけた場合は勝手に修正しています。
太字のリンクは更新頻度高。試される場合は自己責任でお願いします。
Dear All
Here is my ChaN's FatFs implementation examples.
Those projects are suitable to build in GNU-GCC environment.
If you have any question,see here to contact me.
●ARM
(Confirmed on 64bit Win7,8,10,11 by ARM-GCC)
ビルドの仕方はこちら
Building Method on Native Windows Environment is Here.
-Cortex-M7
STM32H7xx(STM32H747I-Discovery supported!)
(CubeH7:V1.12.0/HAL:V1.11.5)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32F7xx(STM32F769I/746G-Discovery supported!)
(CubeF7:V1.15.0/HAL:V1.2.9)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M33
STM32H5xx(STM32H563ZI-NUCLEO supported!)
(CubeH5:V1.1.0/HAL:V1.1.0)
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32L5xx(STM32L552ZE-Q-NUCLEO supported!)
(CubeL5:V1.5.0/HAL:V1.5.0)
20250501更新停止
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M4F
STM32F4(STM32F407ZGT6/PowerAVR-RedBull Compatible Circuit
& STM32F437IIT6/盈钰電子STM32F4xxIxT6开发板互換
& STM32F407VGT6/STM32F4Discovery
& STM32F429ZIT6/STM32F429I-Discovery are also supported!)
(FWLib:V1.8.0)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT/OLED Control Sample with ChaN's FatFs(SDIO&SPI-Interface)
It supports SDXC and eMMC!
STM32F401xx(STM32F401RET6/NUCLEO-F401RE Compatible Circuit)
(CubeF4:V1.24.1/HAL:V1.7.6)
*KickStart & I2C-LCD/OLED and many Devices example
STM32F334(STM32F334R8T6/NUCLEO-F334R8 Compatible Circuit)
(CubeF3:V1.11.0/HAL:V1.5.3)
*KickStart & I2C-LCD/OLED many Devices examples!
LPC4088(LPC4088/EA4088 Board Semi-Compatible Circuit)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4357(盈钰電子LPC4357开发板互換)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4330(LPC4330-Xplorer Compatible Circuit)
20150912更新停止
*Dual/SingleCore-KickStart
LM4F120H5QR(Stellaris Launchpad Compatible)
20150912更新停止
*KickStart
-Cortex-M4
K20(MK20DX32VLF5)(Bare-Metal)
*KickStart
-Cortex-M3
STM32F103(STM32F103VET6/STM32 Primer2)
(FWLib:V3.6.1 ,USBLib:V4.0.0 ,
FatFs STM32F1 SDIO-Interface Imprementation)
*Bare-Metal GPS & GNSS-Tracker using ChaN's FatFs
EFM32TG822F32(Bare-Metal for TinyGecko)
*LED-Blink & UART
LPC13xx(LPC1347/LPCXPresso Compatible Circuit)
20150912更新停止
*KickStart
STM32F2(STM32F207ZGT6/PowerAVR-RedBull Compatible Circuit)
20150912更新停止
(FWLib:V1.1.2)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SDIO-Interface)
STM32F107(STM32F107VCT6/CQ-STARM-JUNKBOARD Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1 ,USBLib:V4.0.0)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
STM32VL(STM32F100RBT6/STM32VL-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32VL SPI-Interface)
STM32L(STM32L152RBT6/STM32L-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V1.1.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32L SPI-Interface)
MB9BF618T(FRK-FM3-GARBAGEBOARD Compatible Circuit)
20150924更新停止
*(Deprecated) LED-Blink & UART
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MFS SPI-Interface)
MB9AF112K(Bare-Metal)
20150912更新停止
*(Deprecated) LED-Blink & UART
LPC177x/8x(LPC1788/EA1788 Board Semi-Compatible Circuit)
20160331更新停止
*(Deprecated) ChaN's FatFs Sample(MCI-Interface)
-Cortex-M0+
STM32U083xx
(STM32U083RCT6-NUCLEO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32C031xx/STM32C011xx
(STM32C031C6-NUCLEO/STM32C011XX-DK Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32G03xxx(STM32G0316-DISCO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
LPC824(LPC824/LPCXPresso Compatible Circuit)
*KickStart
KL25(MKL25Z128VLK4/FRDM-KL25Z Compatible Circuit)
*KickStart
KE02(MKE02Z64VQH2/FRDM-KE02Z Compatible Circuit)
*KickStart
EFM32ZG222F32(For EFM32ZG-STK3200)
*LED-Blink & UART
STM32L05xxx(STM32L053C8/STM32L0538-Discovery Compatible Circuit)
*KickStart
LPC812(LPC812/LPCXPresso Compatible Circuit)
20160331更新停止
*(Deprecated) KickStart
KL05(MKL05Z32VFM4/FRDM-KL05Z Compatible Circuit)
20170629更新停止
*KickStart
-Cortex-M0
STM32F03x(STM32F030R8T6/NUCLEO-F030R8 Compatible Circuit)
(CubeF0:V1.7.0/HAL:V1.5.0)
*KickStart & I2C-LCD/OLED and many Devices examples!
NUC120LE3(NUC120LE3AN/NuTiny-SDK-NUC120 Compatible Circuit)
*KickStart
M0516LBN(NUC120LE3AN/NuTiny-SDK-M0516 Compatible Circuit)
*KickStart
LPC11u35(LPC11U35/501 CMSIS-DAP Compatible Circuit)
*KickStart
STM32F05x(STM32F051R8T6/STM32F0-Discovery Compatible Circuit)
(CubeF0:V1.3.0)
20150922更新停止
*(Deprecated) KickStart
LPC11xx(LPC1114/LPCXPresso and MARY and DIP28-package Compatible Circuit)
20150922更新停止
*(Deprecated) KickStart
-ARM7TDMI
LPC23xx(LPC2388/CQ-FRK-NXP-ARM-JUNKBOARD Compatible Circuit)
20181222更新停止
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MCI-Interface))
●AVR
-AVR-Dx
AVR128DA48 CuriosityNANO
(and AVR128DB28,AVR64DD28 baremetal supported)
*UART & Internal Temperature Test
-XMEGA
ATxmega128A1/Atxmega128A1U
20240101更新停止
*(Deprecated)TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
●Windows Tools and Misc
- OpenOCD for Windows
ocd-0.12.0+dev-00927-g6834f022b(built on 20250413)
Windows 32bit Binary Nemuisan's Special Version
*Supported OS*
->Windows7,8,10,11(x86 or x64)
->WinXP last version is here.
*Supported Debugger Hardware*
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
->JLink On LPCXpressoV2/V3(WinUSB)
->JLink-OB(WinUSB)
->STLink,/V2,/V2-1 and /V3(STMicro's Distributed USB-Driver/WinUSB)
->Versaloon(WinUSB)
->TI-ICDI(TI's Distributed USB-Driver/WinUSB)
->CMSIS-DAP(Generic USB-HID/Mbed VCP Driver)
->Nulink(Generic USB-HID)
*OPENOCD FOR WINDOWS BINARY HERE!
SHA-1 HASH:dbd869c023d119b05d879fee52125d16530cef71
OpenOCD(0.13.0)'s Specific MCU cfg Files for Flash Programming=
*OpenOCD spesific MCU-Aimed cfg files Nemuisan Special
↑Notice:Already contained in my OpenOCD Binary.
For self build users & linux users only.
OpenOCD(0.13.0)'s Patch Set(Useful Functions & Fix Patches)
*OpenOCD Patch Set Nemuisan Special
↑For self build users & linux uses only.
- AVRDUDE for Windows
AVRDUDE for Windows v8.0 32bit Binary(built on 20250413)
Nemuisan's Special Version
Supported OS
->Windows7,8,10,11(x86 or x64)
*AVRDUDE FOR WINDOWS BINARY HERE!
-SPIROM Writer Tools
FLASHROM for Windows(SPI-ROM Writer) (built on 20250413)
1.6.0-devel (git:v1.5.0-44-g4d4688cc) 32bit Binary
For FT2232/FT232H Devices(WinUSB)
*Flashrom_v1.5.0-44-g4d4688cc.7z
-JTAG Tools
UrJTAG for Windows v2021.03 #d9a2943f(built on 20250413)
*urjtag.tar.gz
SupportedHardware
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
-JTAG Hardware
-Schematic of JTAGkey2 Compatible Circuit Rev.5
(Supports 1.4〜5.5V WideVoltage Range)
*JTAGKey2CompatibleCircuit_Rev.5
かつてこの欄でFirefox拡張｢合間合間に｣のバックアップを公開していました。
20191124更新：
waterfox向けの｢合間合間に｣のふたばの仕様変更対応版をサルベージしましたので
こちらでも公開します。
※｢赤福Firefox版」/｢合間合間に｣は有志の方がGitHubにて管理されています。
※unmhtはこちらに残っています。
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (84)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (29)
- 日本の自然歩道 (27)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ねむい (12/18) - 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ひかわ (12/15) - STM32U0はぢめました
⇒ ねむい (08/07) - STM32U0はぢめました
⇒ ひかわ (07/28) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (05/17) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - いろいろ試す61(と今年の反省会)
⇒ ねむい (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/01)
- April 2025 (1)
- March 2025 (1)
- February 2025 (1)
- January 2025 (1)
- December 2024 (2)
- November 2024 (1)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (6)
- May 2009 (14)
- January 1970 (1)
Copyright(C) B-Blog project All rights reserved.