いろいろ試す62
●Picoscope7のソフトがバージョンアップ！今度こそ安定…か？
すぐフリーズしたり落ちたりでなかなか安定しないPicoscope7のソフトですが
Stable版が7.1.29にバージョンアップしておりました。
今度こそ本当にStableなんでしょうね…！？(どきどき
※会社で現役でバリバリ使用中のPicoscope3206Aで試してます
☝2画面で動かして放置すると固まったorz
…
ファ〇ッッック！！！！！
基本的な操作はだいぶ安定してきましたがちょっと複雑な操作はまだ
安定していないようですね…
というわけで安定して使用できるまでPicoscope6使っていきましょ…。
●arm-gccが久々の更新
Arm GNU-GCCが久々の更新です。
といってもGCC14ではなくまだGCC13のままです…。
13.2->13.3のマイナーチェンジですね。
また、今回はセキュリティ対策のアップデートしております。
同じプログラムをビルドしてバイナリサイズの比較です。
13.2Rel1(前のやつ)
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 479156 0 479156 74fb4 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
477416 1740 39668 518824 7eaa8 main.elf
main.elf :
section size addr
.text 0x747fc 0x8000000
.ctors 0x0 0x80747fc
.dtors 0x0 0x80747fc
.eh_frame 0x54 0x80747fc
.ARM.exidx 0x98 0x8074850
.data 0x6cc 0x20000000
.bss 0x18a8 0x200006d0
.heap 0x0 0x20001f78
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x44 0x0
.debug_frame 0x1e88 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x80b9e13.3Rel1(新しいほう)
arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478396 0 478396 74cbc main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476624 1772 39668 518064 7e7b0 main.elf
main.elf :
section size addr
.text 0x744e4 0x8000000
.ctors 0x0 0x80744e4
.dtors 0x0 0x80744e4
.eh_frame 0x54 0x80744e4
.ARM.exidx 0x98 0x8074538
.data 0x6ec 0x20000000
.bss 0x18a8 0x200006f0
.heap 0x0 0x20001f98
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x45 0x0
.debug_frame 0x1d98 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x807b7Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。
mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。
一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1
13.3Rel1
あ…ありり…
ちょっとかなり遅くなってる…(脂汗
…
GCC14に期待しましょう〜！！
13.3Rel1のGDBはCortex-M33コアでbreakpointが効かなくてデバッグが
できないことが判明しました…(多分バグです)
ひとつ前の13.2Rel1のやつ使いましょう…
20240828追:
13.3Rel1のGDB(GDB14)はちょっと規模が大きいプロクラムになると
breakpointが効かなくなってデバッグが全くできなくなることが
判明しました…orzおそらくGDBのバグっぽい挙動ですがまだ情報が
出そろっていないので今は13.2Rel1のarm-gccを使ったほうが無難です…
どうしてこんなことにorzorz
●組み込み向けのLTO考察
リンク時最適化(LinkTimeOptimization)。ねむいさんは10年位前に使った際に
バグが多くて封印してそれっきりでした。ここ最近はどうなっているのか色々
調べてみましたが、あのころと比べてかなり様変わりしてるのがわかりました。
まずは公式のLTOの解説をしっかりと読みとおすこと。
そのうえでLTOのビルドを成功させるためには幾つかの障壁がありました。
*FONTX2のファイルを直接取り込むincbinと相性が悪い
LTOなしだとビルドできるのにLTOつけるとアセンブラでエラー吐いてこける。
LTOの場合はmakefileがあるところからのフルパスを指定しないといけない。
makefileが存在するディレクトリからの相対パスを指定しなおすことで
苦しみ紛れに屁をこいたような対策ですが何とか対処できました。
*引数も重要
ビルド時に与える引数も"-flto"だけじゃダメになっていて、試行錯誤した結果
以下のオプションを全部追加することでLTOビルドを達成できました。
-flto
-ffat-lto-objects
-fuse-linker-plugin
-flto-partition=noneSTM32H5のビルドサイズ比較をしてみましょう
LTOなし
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478260 0 478260 74c34 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476488 1772 39668 517928 7e728 main.elfLTOあり
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 473372 0 473372 7391c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
471608 1764 39672 513044 7d414 main.elf5kByte弱削減できました。SRAM消費量も微量ながら減ってますね。
もちろんLTOありでもちゃんとプログラムは機能します。
大規模プロジェクトなので効果は感じづらいですがSTM32C0とかの
小規模なプログラムなら削減効果をかなり実感できると思います。
あとリンク段階で変なワーニング出るんですけど対象方法知ってる人いたら
教えてくだち。
●mbedサ終
ついに来てしまいましたね…
ねむいさんもほとんど使用しないままここまで来てしまいましたが
時代の仇花として人々の記憶に残るでしょう…(2026年完全終了)。
ねむいさん的にはオンラインコンパイラは圧倒的に相性悪くてやっぱり
PCで普通にコンパイルするのが身の丈に合っていると感じました。
●STLinkV3はST製以外のマイコンを排斥する！実質STM32専用ｯ！
まぢですか…、OpenOCDからも使えないとは…！
秋月で売ってるやつ買わないでよかった…！
実質STM32以外の他社製のCortex-Mのマイコンのフラッシュ書き込みは
おろかコアにconnectすらできないようです…。
一方で手持ちのSTLink/V2系は大丈夫なのかどうか実際に確認してみました。
使用したのはおそロシアの力でSWIMに無理やり対応させたSTM32F0Discovery
付属のSTLink/V2です…相手は今は亡きLPC810です！
まずはHLAとして接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : clock speed 1000 kHz
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.905861
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.093837s (2.743 KiB/s)
Info : verified 3072 bytes in 0.055933s (53.636 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01お次はDAPDirectで接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.882555
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0bc11477
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.219387s (2.460 KiB/s)
Info : verified 3072 bytes in 0.063133s (47.519 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
ファームのVerは20240821最新のV2J45S7を使用しておりますが、
STLink/V2のハードウエアなら他社製Cortex-Mマイコンでも大丈夫なようですね…
●そしてぱちもんSTLinkV2にもパチモン対策が
まぁこんなこったろうと思っていましたが、粗製乱造で広まっている中華製偽物
STLink/V2を検知したらシリアル番号を"C"にしてしまうファームウエアが発動
しているようです。
STM32CubeProgrammerではこのシリアルをもつぱちもんSTLink/V2が
使用できなくなります。
OpenOCDからはまだ大丈夫っぽいですがこちらも穴がふさがれそうですね。
ちなみにねむいさんがSTM8マイコンの読み書きするためにおそロシアの力を
使って改造したSTLink/V2はシリアル番号は"C"ではなかったのでセーフでした。
恐らく正規のSTM32マイコンを使用しているか否かで判別しているようですね。
STM32H5を使ってみる4 -STM32L5の時みたいにOCTO-SPIを使ってみる-
20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:
つい最近、STM32H7シリーズにSTM32H7R/Sというかなり尖った品種が
追加されましたが思い出したようにSTM32H5を触っていこうと思います。
20240321追:
STM32U0シリーズなんてのも出現してました…！！
20240321追:
今回もSTM32H563ZI-NUCLEOを使用したFatFsの移植デモのソースコードを
使用して解説していきます。
●STM32L5から進化したSTM32H5のOCTO-SPI
STM32H5のOCTO-SPIはポピュラーなQUADSPI-ROMだけではなく、最大
16bitなクロックドシリアルROM/PSRAMなんかも接続可能で、もちろん
メモリマップドなアクセスが可能となっております。
シリアルなのに16bitもパラレルってなんなんだよと常に感じてますが
時代は常に進化していっているなと同じく感じております(混乱)。
sirius506さんはそんなOCTO-SPIを完全に使いこなしDOOMというゲームを
移植されており、ほんとに感心してしまいました…
ねむいさんは組み込み系界隈の中では雑魚キャラに過ぎないのでそんな
高度なことはできず、基本中の基本のQSPI-ROMを接続してメモリ
マップドモードで読み出し専用で動かすことからやってきます。
OCTO-SPIについてはST公式のAN5050もしっかり熟読してください。
●STM32H5のOCTO-SPIをメモリマップドモードで動かすコード
移植に当たってはSTM32L5のやつをそのままスライド移植…というわけには
簡単にいかず、L5のOCTO-SPIのコードから少し改変が必要でした。
その前に、STM32H563ZI-NUCLEOでOCTO-SPIを使う際はSB70をジャンパして
PE2(COTO-SPI IO2)を外部に引き出せられるようにするのを忘れないで
くださいね。
それではSTM32H5のOCTO-SPIのメモリマップドモードで使うためのコードを
紹介します。まずはI/O
/**************************************************************************/
/*!
@brief OCTO-SPI GPIO Configuration.
@param None.
@retval None.
*/
/**************************************************************************/
void OSPI_IoInit_If(void)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
/* Initializes the peripherals clock */
PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_OSPI;
PeriphClkInit.OspiClockSelection = RCC_OSPICLKSOURCE_HCLK;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
{
for(;;);
}
/* Peripheral clock enable */
__HAL_RCC_OSPI1_CLK_ENABLE();
/* Alternate GPIO enable */
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();
__HAL_RCC_GPIOE_CLK_ENABLE();
__HAL_RCC_GPIOG_CLK_ENABLE();
/* PD11 as OSPI_IO0 */
GPIO_InitStruct.Pin = GPIO_PIN_11;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF9_OCTOSPI1;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
/* PD12 as OSPI_IO1 */
GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Alternate = GPIO_AF9_OCTOSPI1;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
/* PE2 as OSPI_IO2(Need SB70 SolderBridge) */
GPIO_InitStruct.Pin = GPIO_PIN_2;
GPIO_InitStruct.Alternate = GPIO_AF9_OCTOSPI1;
HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
/* PD13 as OSPI_IO3 */
GPIO_InitStruct.Pin = GPIO_PIN_13;
GPIO_InitStruct.Alternate = GPIO_AF9_OCTOSPI1;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);
/* PB2 as OSPI_CLK */
GPIO_InitStruct.Pin = GPIO_PIN_2;
GPIO_InitStruct.Alternate = GPIO_AF9_OCTOSPI1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
/* PG6 as OSPI_NCS */
GPIO_InitStruct.Pin = GPIO_PIN_6;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);
}お次はOCTO-SPIのメモリマップドモードの初期化です。
/**************************************************************************/
/*!
@brief Configure OCTO-SPI as Memory Mapped Mode.
Winbond W25Q128JVSIQ specific setting.
* Address size is 24bit(16MBytes).
* Initially sets QUAD-MODE(not need quadmode command).
* MAX 133MHz CLK.
* Support "XIP",thus suitable for MemoryMappedMode.
@param None.
@retval None.
*/
/**************************************************************************/
void Set_OSPI_MemoryMappedMode(void)
{
XSPI_RegularCmdTypeDef sCommand = {0};
XSPI_MemoryMappedTypeDef sMemMappedCfg = {0};
uint8_t reg_data =0;
/* Initialize OCTO-SPI I/O */
OSPI_IoInit_If();
/* Initialize OCTO-SPI */
hxspi.Instance = OCTOSPI1;
hxspi.Init.FifoThresholdByte = 1;
hxspi.Init.MemoryMode = HAL_XSPI_SINGLE_MEM;
hxspi.Init.MemoryType = HAL_XSPI_MEMTYPE_MICRON;
hxspi.Init.MemorySize = 23; /* 128Mbit=16MByte=2^(23+1) W25Q128JVSIQ */
hxspi.Init.ChipSelectHighTimeCycle = 4; /* 4ClockCycle(16nSec@250MHzMAX) Need for W25Q128JVSIQ >10nSec@read */
hxspi.Init.FreeRunningClock = HAL_XSPI_FREERUNCLK_DISABLE;
hxspi.Init.ClockMode = HAL_XSPI_CLOCK_MODE_0;
hxspi.Init.WrapSize = HAL_XSPI_WRAP_NOT_SUPPORTED;
hxspi.Init.ClockPrescaler = 1; /* 250MHzMAX/(1+1) = 125MHz (Allowed SDR Clock is 150MHz@3.3V) */
hxspi.Init.SampleShifting = HAL_XSPI_SAMPLE_SHIFT_HALFCYCLE;
hxspi.Init.DelayHoldQuarterCycle = HAL_XSPI_DHQC_DISABLE;
hxspi.Init.ChipSelectBoundary = 0;
hxspi.Init.DelayBlockBypass = HAL_XSPI_DELAY_BLOCK_BYPASS;
hxspi.Init.Refresh = 0;
if (HAL_XSPI_Init(&hxspi) != HAL_OK)
{
for(;;);
}
/* Enable Reset --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_XSPI_OPTYPE_COMMON_CFG;
sCommand.IOSelect = HAL_XSPI_SELECT_IO_3_0;
sCommand.InstructionDTRMode = HAL_XSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDTRMode = HAL_XSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDTRMode = HAL_XSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_XSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytes = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesWidth = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesDTRMode = HAL_XSPI_ALT_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.InstructionWidth = HAL_XSPI_INSTRUCTION_8_BITS;
sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x66; /* Reset Enable W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_XSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_XSPI_DATA_NONE;
sCommand.DataLength = 0;
sCommand.DummyCycles = 0;
if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Reset Device --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_XSPI_OPTYPE_COMMON_CFG;
sCommand.IOSelect = HAL_XSPI_SELECT_IO_3_0;
sCommand.InstructionDTRMode = HAL_XSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDTRMode = HAL_XSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDTRMode = HAL_XSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_XSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytes = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesWidth = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesDTRMode = HAL_XSPI_ALT_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.InstructionWidth = HAL_XSPI_INSTRUCTION_8_BITS;
sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x99; /* Reset W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_XSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_XSPI_DATA_NONE;
sCommand.DataLength = 0;
sCommand.DummyCycles = 0;
if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Enter Quad-SPI Mode --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_XSPI_OPTYPE_COMMON_CFG;
sCommand.IOSelect = HAL_XSPI_SELECT_IO_3_0;
sCommand.InstructionDTRMode = HAL_XSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDTRMode = HAL_XSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDTRMode = HAL_XSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_XSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytes = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesWidth = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesDTRMode = HAL_XSPI_ALT_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.InstructionWidth = HAL_XSPI_INSTRUCTION_8_BITS;
sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x31; /* Set Status2 W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_XSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.DataLength = 1;
sCommand.DummyCycles = 0;
reg_data = 0x02; /* Enable QuadI/O Mode */
if (HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
if (HAL_XSPI_Transmit(&hxspi, ®_data, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Enter MemoryMappedMode --------------------------- */
/* Read Commands */
sCommand.OperationType = HAL_XSPI_OPTYPE_READ_CFG;
sCommand.IOSelect = HAL_XSPI_SELECT_IO_3_0;
sCommand.InstructionDTRMode = HAL_XSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDTRMode = HAL_XSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDTRMode = HAL_XSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_XSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_XSPI_ALT_BYTES_4_LINES;
sCommand.AlternateBytes = 0xFF; /* Need for Fast Read QUAD W25Q128JVSIQ */
sCommand.AlternateBytesWidth = HAL_XSPI_ALT_BYTES_8_BITS;
sCommand.AlternateBytesDTRMode = HAL_XSPI_ALT_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.InstructionWidth = HAL_XSPI_INSTRUCTION_8_BITS;
sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0xEB; /* Fast Read QUAD W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_XSPI_ADDRESS_4_LINES;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_XSPI_DATA_4_LINES;
sCommand.DataLength = 0;
sCommand.DummyCycles = 4; /* DUMMY 4Cycle for Fast Read QUAD W25Q128JVSIQ */
if(HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Write Commands */
sCommand.OperationType = HAL_XSPI_OPTYPE_WRITE_CFG;
sCommand.IOSelect = HAL_XSPI_SELECT_IO_3_0;
sCommand.InstructionDTRMode = HAL_XSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDTRMode = HAL_XSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDTRMode = HAL_XSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_XSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_XSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytes = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesWidth = HAL_XSPI_ALT_BYTES_NONE;
sCommand.AlternateBytesDTRMode = HAL_XSPI_ALT_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_XSPI_INSTRUCTION_1_LINE;
sCommand.InstructionWidth = HAL_XSPI_INSTRUCTION_8_BITS;
sCommand.AddressWidth = HAL_XSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x32; /* Page Write QUAD W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_XSPI_ADDRESS_1_LINE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_XSPI_DATA_4_LINES;
sCommand.DataLength = 0;
sCommand.DummyCycles = 0;
if(HAL_XSPI_Command(&hxspi, &sCommand, HAL_XSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Set OCTO-SPI as MemoryMappedMode */
sMemMappedCfg.TimeOutActivation = HAL_XSPI_TIMEOUT_COUNTER_DISABLE;
sMemMappedCfg.TimeoutPeriodClock = 0;
if(HAL_XSPI_MemoryMapped(&hxspi, &sMemMappedCfg) != HAL_OK)
{
for(;;);
}
}STM32H5のOCTO-SPIのHALはL5と微妙に違っており"HAL_OSPI"だったのが
"HAL_XSPI"に変わってたりして移植の際めっちゃ鬱陶しかったのですが
基本的な設定の流れはL5の時とそこまで変わっておりません。
特筆すべきはSTM32H5は250MHzで動作するのでW25Q128JVSIQ(最大133MHz)
に対して125MHzという過激なスピードのクロックが供給可能で非常に高速な
動作が可能です！しかもデータキャッシュもついてます！
ちなみにSTM32H5のOCTO-SPIの最大供給クロックは150MHz(3.3V時)まで
可能となっております。
●実際に動かしてみる
ていうかポリウレタン被覆銅線でQSPI-ROMへ配線引き伸ばしてほんとに
125MHzで動いてンのかと自分でも訝しんでいましたので実際にクロックの
波形を測定してみました。
使用したオシロはPicoscope5444D MSOです。そうだね宣伝だね。
Picoscope5444D MSOのアナログ帯域200MHzなのに125MHzの高速信号測るの
どうなのとお思いでしょうが測定限界を大幅に超えていますがETSモードで
測定した限りではきっちり125MHzのクロックが出ていることがわかります。
ねむいさんはQSPI-ROMをFONTX2を格納するのに使っていますがこんな感じで
文字崩れも起こさずきれいに表示できております！
手配線の限界に挑んだ感じですがまぁSCLKは一応33ohmで直列終端は
しているのでそれが効いて安定して動作しているのでしょう〜。
●おまけ・STM32L5とのパフォーマンス比較
せっかく下駄基板作ってハード的に同じ条件が揃えてるのでSTM32L5と
STM32H5のパフォーマンス比較とかやってみました。
同一のpngファイルでlibpngを使ったデコード時間を比較してみました。
☝STM32L5の場合(動作クロック:110MHz)
☝STM32H5の場合(動作クロック:250MHz)
う〜むやはり圧倒的に違いますね〜というかねむいさんがSTM32H5の
パワーを持て余しててまだまだ機能の一握りも使えてないので頑張って
使いこなしていこうと思います！これからも頑張るぞい！
いろいろ試す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)
…
あ…あれ…結構遅くなってる…！？
ま、まぁ多分何かの安定性が上がったかもなのでよしとしましょう…
(脂汗)
STM32L5を使ってみる3 -OCTO-SPIでQUAD-SPIROMを使おう-
●QUAD-SPI接続NORFLASH-ROMを使いこなせ!
FONTX2ファイルなどの大容量のデータはSTM32等の大規模マイコンと
いえどもフラッシュ容量を非常にひっ迫します。
以前からはそういったデータは外付けのQSPI-ROMに格納し、そこから
アクセスするといった手法が定番となっております。
STM32L5では信号線を最大8本持つクロックドシリアルインターフェース
いわゆる"OCTO-SPI"をもちさらに利便性が高まっております！
このOCTO-SPIを使ってQSPI-ROMと接続し内蔵フラッシュメモリのように
使えるMemoryMappedModeで読み出していこうと思います！
●もはや定番☆WinbondのW25Q128JVSIQ
前々回からの紹介の通り、ねむいさんは入手も容易で十分な容量(16MB)、
高速なクロック(133MHz)でデフォルトでQUAD-SPIモードになっていて
コマンドが省略出来て扱いやすいW25Q128JVSIQを使用しました。
W25Qのシリーズにはいろいろありますが末尾"IQ"のものは上でも
書いた通り最初っからQUAD-SPIモードになっており今から紹介する
メモリマップドモードで投げるコマンドがいくつか省略出来て楽です。
digikeyやmouserで購入の際はうっかり違うやつを買わないように
型番には注意してください。
●OCTO-SPIをMemoryMappedModeで使用するためのコード手順
STM32L5に搭載されているOCTO-SPIはSTM32F7などにあったQUAD-SPI
インターフェースからされに拡張され、読み出しのほかに書き込みも
サポートされています。基本的な設定の流れはQUAD-SPIの頃とほぼ
同じですがOCTO-SPIならではの設定もあるので注意しましょう。
↓まずはI/O設定です。
/**************************************************************************/
/*!
@brief OCTO-SPI GPIO Configuration.
@param None.
@retval None.
*/
/**************************************************************************/
void OSPI_IoInit_If(void)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
/* Initializes the peripherals clock */
PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_OSPI;
PeriphClkInit.OspiClockSelection = RCC_OSPICLKSOURCE_SYSCLK;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
{
for(;;);
}
/* Peripheral clock enable */
__HAL_RCC_OSPI1_CLK_ENABLE();
/* Alternate GPIO enable */
__HAL_RCC_GPIOE_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
/* PE12 as OSPI_IO0 */
GPIO_InitStruct.Pin = GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
/* PB0 as OSPI_IO1 */
GPIO_InitStruct.Pin = GPIO_PIN_0;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
/* PE14 as OSPI_IO2 */
GPIO_InitStruct.Pin = GPIO_PIN_14;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
/* PE15 as OSPI_IO3 */
GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOE, &GPIO_InitStruct);
/* PB10 as OSPI_CLK */
GPIO_InitStruct.Pin = GPIO_PIN_10;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
/* PA2 as OSPI_NCS */
GPIO_InitStruct.Pin = GPIO_PIN_2;
GPIO_InitStruct.Alternate = GPIO_AF10_OCTOSPI1;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
}これはNUCLEO-L552ZE-Qから出たQUAD-SPIの足に対応したものです。
OCTO-SPIなのに8本全部使わぬぇのかと思いでしょうがこれはNUCLEO
が引き出してる足がそうなってるからそれに従ったわけなのでー
↓お次はOCTO-SPIの設定です。
/**************************************************************************/
/*!
@brief Configure OCTO-SPI as Memory Mapped Mode.
Winbond W25Q128JVSIQ specific setting.
* Address size is 24bit(16MBytes).
* Initially sets QUAD-MODE(not need quadmode command).
* MAX 133MHz CLK.
* Support "XIP",thus suitable for MemoryMappedMode.
@param None.
@retval None.
*/
/**************************************************************************/
void Set_OSPI_MemoryMappedMode(void)
{
OSPI_RegularCmdTypeDef sCommand = {0};
OSPI_MemoryMappedTypeDef sMemMappedCfg = {0};
uint8_t reg_data =0;
/* Initialize OCTO-SPI I/O */
OSPI_IoInit_If();
/* Initialize OCTO-SPI */
hospi.Instance = OCTOSPI1;
hospi.Init.FifoThreshold = 1;
hospi.Init.DualQuad = HAL_OSPI_DUALQUAD_DISABLE;
hospi.Init.MemoryType = HAL_OSPI_MEMTYPE_MICRON;
hospi.Init.DeviceSize = 24; /* 128Mbit=16MByte=2^24 W25Q128JVSIQ */
hospi.Init.ChipSelectHighTime = 2; /* 2ClockCycle(18nSec@110MHz) Need for W25Q128JVSIQ >10nSec@read */
hospi.Init.FreeRunningClock = HAL_OSPI_FREERUNCLK_DISABLE;
hospi.Init.ClockMode = HAL_OSPI_CLOCK_MODE_0;
hospi.Init.WrapSize = HAL_OSPI_WRAP_NOT_SUPPORTED;
hospi.Init.ClockPrescaler = 2; /* 110MHzMAX/2 = 55MHz(MAX OSPI-CLK:90MHz) */
hospi.Init.SampleShifting = HAL_OSPI_SAMPLE_SHIFTING_HALFCYCLE;
hospi.Init.DelayHoldQuarterCycle = HAL_OSPI_DHQC_DISABLE;
hospi.Init.ChipSelectBoundary = 0;
hospi.Init.DelayBlockBypass = HAL_OSPI_DELAY_BLOCK_BYPASSED;
hospi.Init.Refresh = 0;
if (HAL_OSPI_Init(&hospi) != HAL_OK)
{
for(;;);
}
/* Enable Reset --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_OSPI_OPTYPE_COMMON_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytes = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesSize = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x66; /* Reset Enable W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_OSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_OSPI_DATA_NONE;
sCommand.DummyCycles = 0;
sCommand.NbData = 0;
if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Reset Device --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_OSPI_OPTYPE_COMMON_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytes = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesSize = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x99; /* Reset W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_OSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_OSPI_DATA_NONE;
sCommand.DummyCycles = 0;
sCommand.NbData = 0;
if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Enter Quad-SPI Mode --------------------------- */
/* Common Commands */
sCommand.OperationType = HAL_OSPI_OPTYPE_COMMON_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytes = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesSize = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x31; /* Set Status2 W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_OSPI_ADDRESS_NONE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.DummyCycles = 0;
sCommand.NbData = 1;
reg_data = 0x02; /* Enable QuadI/O Mode */
if (HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
if (HAL_OSPI_Transmit(&hospi, ®_data, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Enter MemoryMappedMode --------------------------- */
/* Read Commands */
sCommand.OperationType = HAL_OSPI_OPTYPE_READ_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_4_LINES;
sCommand.AlternateBytes = 0xFF; /* Need for Fast Read QUAD W25Q128JVSIQ */
sCommand.AlternateBytesSize = HAL_OSPI_ALTERNATE_BYTES_8_BITS;
sCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0xEB; /* Fast Read QUAD W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_OSPI_ADDRESS_4_LINES;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_OSPI_DATA_4_LINES;
sCommand.DummyCycles = 4; /* DUMMY 4Cycle for Fast Read QUAD W25Q128JVSIQ */
sCommand.NbData = 0;
if(HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Write Commands */
sCommand.OperationType = HAL_OSPI_OPTYPE_WRITE_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytes = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesSize = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.AlternateBytesDtrMode = HAL_OSPI_ALTERNATE_BYTES_DTR_DISABLE;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_1_LINE;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
/* Instruction */
sCommand.Instruction = 0x32; /* Page Write QUAD W25Q128JVSIQ */
/* Address */
sCommand.AddressMode = HAL_OSPI_ADDRESS_1_LINE;
sCommand.Address = 0;
/* Data */
sCommand.DataMode = HAL_OSPI_DATA_4_LINES;
sCommand.DummyCycles = 0;
sCommand.NbData = 0;
if(HAL_OSPI_Command(&hospi, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
{
for(;;);
}
/* Set OCTO-SPI as MemoryMappedMode */
sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_DISABLE;
sMemMappedCfg.TimeOutPeriod = 0;
if(HAL_OSPI_MemoryMapped(&hospi, &sMemMappedCfg) != HAL_OK)
{
for(;;);
}
}流れとしてはリセット有効->リセット->クアッドI/Oモード有効->
クアッド高速読み出しコマンド->クアッドセクタ書き込みコマンド
->HALのMemoryMappedMode移行関数呼び出し
となっております。
"クアッドI/Oモード有効"はW25Q128JVSIQ使うなら本来不要ですが
"念のため"突っ込んどきました…一応なくても動作します。
注意点ですがOCTO-SPIは書き込みもMemoryMappedModeが使用可能の為、
クアッド読み出しコマンドの次にセクタ書き込みコマンドの設定が
必須になります！！
なぜそうなっているかというとHALの関数内で書き込みコマンドの
設定まで要求してきやがるからです(別に今回書き込み要らんのに☠)
これも設定しないと先に進めません！
●動作してるところ
MemoryMappedModeで設定したアドレスはSTM32F7のでやった時と同じく
0x90000000からとなりますので過去のリソースが利用できます。
ねむいさんの使い方ではFONTX2ファイルのAnkの方を0x90000000、
Sjis-Kanjiフォントの方は0x90010000から参照しております。
Ankのファイルサイズはどんなにでかくとも65536byte以上にならない
だろうという打算でこのオフセット値を設定してます。
こんな感じでFONTX2(全角&半角)ファイルを仕込んだW25Q128JVSIQから
内蔵フラッシュと変わらない感覚でデータを読み出し表示ができました。
使用したフォントは小夏フォントを12ptのFONTX2に変換したものです。
STM32L5のOCTO-SPIは命令キャッシュだけでデータキャッシュは無い
ですが文字表示や操作感に特にもたついた感じはしてませんね。
デバッガで0x90000000番地を表示してみました。
MemoyMappedMode有効後は内蔵フラッシュと同じようにデバッガで
内部のデータを参照できてますね。
●ところでどうやってQSPI-ROMにデータ書くの？
…今回の記事はこれが最大の難関です…！
OpenOCDではDiscovery系のボードではI/Fの足もQSPI-ROMの品種も
決め打ちのためにQSPI-ROMの読み書きがサポートされていますが
NUCLEO系のやつは足は出ているもののその先に何がつながるかは
わからないのでサポートしているものは何にもありません。
したがってOpenOCDのmmwのコマンドでそれぞれのROMデバイス向けに
上で書いたコードを16進数並べてがむばって定義していくしかないの
ですがねむいさんはそんなことやる気力がないので…
Jtagkey2とSPI-ROM書き込みプログラム"Flashom"にてFONTX2データを
書き込むことにしました。
使用するフォントは12x12pxの小夏フォントです。
AnkはKONATHN12.FNTを、S-JisのKanjiはKONATZN12.FNTを使用します。
上記ファイルについて、私のL5プロジェクトの下記ディレクトリを
参照してください。
./lib/FONTX2/inc/fonts/KONATSU
※小夏フォントについてはTTFファイルで提供されております。
今回はあらかじめFONTX2コンバータでTTF->FONTX2形式に変換
して全角/半角とも使用しております。
まずはSPI-ROMの認識と読み出し。ちゃんと認識されているのを確認。
ついでに読み出したデータは後で使用するのでbin形式で保存します。
JtagKey2(で使用されているFT2232H)のSCKは最大30MHzのスピートなので
配線長はなるべく短くしましょう。5cm以下だとまず問題ないです。
残念ながらげたゲタ基板とNUCLEO基板を合体した状態ではまともに認識
出来なかったのでNUCLEOから5Vだけ拝借してW25Q128JVSIQと一対一で配線
する形になります。なお、CSはプルアップ必須なのですがねむいさんは
念のためCLK除くすべてのI/Oを22kohmでプルアップしてます。
一方CLKはSDMMCと同じく直列終端抵抗を忘れずに！！
ねむいさんはSDMMCと同じ33ohmを直列終端として使用してます。
お次は書き込み用バイナリの作成。
ねむいさんの知る限りではFlashromはアドレスをオフセット指定して
一部の領域だけを書き込むことができず、全領域一気に書き込みしないと
いけないので先に読み出したbinファイルを利用してそこにFONTX2ファイル
を上書きする形で配置しFONTX2を仕込んだROMファイルを作成します。
バイナリ編集プログラム"Stirling"を駆使して0x0000000にANKフォントを
0x00010000にKanjiフォントをそれぞれ上書きモードでコピペ配置します。
オフセットは1バイトでもずれないように注意してください。
Ankは配置されるとこんな感じ
Kanjiはこんなかんじになります。
Stirlingのビットマップ表示だとバイナリイメージはこんな感じです。
まだまだ一杯データ詰め込めますね。
そして書き込み。JtagKey2とFlashromを使用した際は通常のSPIで
書き込むことになりますがW25Q128JVSIQはセクタ書き込み対応なので
16MByteもある容量でも2分もかからず終わっちゃいます。
ねむいさんの公開しているプログラムでは一応作成済みのQSPI-ROM
イメージ(128QVFONT.bin)を添付して簡単な使用手順も書いてますので
酔狂な方はご参考に…。
まぁ私のぶろぐ普段から見られてる方は楽勝だと思います。
そんなわけでSTM32H5からやる予定だったOCTO-SPIでしたがL5でもうまく
使いこなすことができました！
L5でやりたいことは一通り全部やり切ったのでいい感じでSTM32H5へと
繋げて行きたいとおもいます！！
大周回遅れで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向けプロジェクトを先行で公開しておりますので興味ある方はこれで
予習をお願いします。
AVR128DAとかDBをもうちょっと使ってみる
●XMEGAの後継！機能満載でエラッタも満載
品種的にはXMEGAの後継となるAVR-Dxシリーズ。数々の新機能がありますが
それは同時に数々のエラッタを仕込むこととなりエラッタシートとチップリビジョンに
注意しておかないとドハマリして目の下にクマつけてダブルピースして
しまいます。
現在、AVR128DAに代表されるAVR-DAシリーズとAVR-DBシリーズが
流通しております。
DAとDBの違いはアナログ入出力がさらに強化されているのと異なる電圧の
I/OそしてDAに存在したエラッタが修正されていることです。
マイクロチップは過去のシリーズで出たエラッタは新しい奴で修正するよという
スタンスなのでしょうか…???これから買う人はDBシリーズ以降にしておけば変な
地雷踏まずに済むと思います。ただし使用前にエラッターシートは必ず目を
通しておいてください。
20240229追:
秋月さんよりAVR128DB28が販売されました！！！！！！
20240229追:
●製造開始直後のAVR32DAに存在した致命的エラッタ
さてAVRはアトメル時代からまず大きめの容量のチップ作ってそのあとシュリンク
していく量産体制の流れになっていますがAVR128DAが世に出て少し経った頃に
製造されたAVR32DAというチップに致命的エなエラッタが存在していました！！！
エラッタの内容は本来は4バイト必要な割り込みベクタが2バイト刻みになっている
というものです。AVR32DAのフラッシュ領域すべてにアクセスするためには割り込み
ベクタで4バイトのjmp命令を使う必要があります。が、ハード的に発生する割り込み
要因は2バイトずつで詰め詰めになってるのでjmp命令ではとんだ先がめちゃくちゃ
になってrjmp命令を使用しなければならず、8kB分しかアクセスできません。
↓以下AVRのジャンプ命令の参考資料
RJMPは16bitオペコードなので2バイト
(フラッシュ8kB以下のデバイスはこちら)
JMPは32bitオぺコードなので4バイト
(フラッシュ8kB以上のでデバイスはこちら)
avr-gccに関しては4バイト区切りの割り込みベクタアドレスを前提に
スタートアップコードがビルドインされておりうんこつきのAVR32DAでは
どう頑張ってもまともに割り込みが使えません！
↑データシートよりAVR32DAの割り込みベクタの解説。
アドレスは2ワード(=4バイト)区切りなのがわかります。
AVRって最初に出た当初は"すっきり16bitオペコード"を売りにしてて伝統的に
ワード(16bit)でプログラムアドレスを表現してきたからシュリンク設計した人が
バイトアドレスと間違っちゃったんじゃないかな…
というわけでこの製造初期に出てしまったAVR32DAは回収され、現在流通している
物については正しい割り込みアドレス間隔になっているそうです。わたしは怖くて
使う気もないですけど！
ちなみに致命的すぎるエラッタゆえにエラッターシートには記載されておらず、
AvrFreaksで指摘があって初めて広く知られるようになったそうです。
●AVR128DAにもやっぱりあかんエラッタ
そして私が持っているAVR128DAもフラシュメモリがらみのエラッタがありますが、
それは下記の条件がすべて重なった時に起こります。
�．侫薀奪轡緡琉茲鬟如璽仁琉茲�0x8000から32kB分をマッピングして読み書きする
��FUSE領域のBOOTCODEに0以外の数値が入っている(=APPCODE領域を有効にする)
��NVMCTRL.CTRLBのBOOTRPをたててブート領域のプロテクションを行う
上記すべてが重なると32kB区切りのどの領域をマッピングしても最初のBOOTCODEの
領域が頭のほうにかぶさってきやがります！！
↑超わかりづらい公式のエラッタシートの解説DA!。
ブート領域を設定しなかったりLPMでフラッシュ領域のデータの読み取りするなら
全く気にする必要はありませんがせっかくデータ領域にフラッシュ領域のデータを
マッピングできるのですからせめて活用はしたいですよね…！
●AVR-Dxを救いたい
というわけでせめて32kB分だけでもPROGMEMしないでSTM32とかと同じように
constな値を置いてみたかったので上記エラッタを踏まないように配慮したうえで
リンカスクリプトをいじりフラッシュ領域のマッピング機能を最大限に活用する
作戦を取りました！
１．通常版の場合
マッピングを使用せず素直にPROGMEMした場合のプランです。
128kByte自由に使えますが64kB以上のPROGMEMの読み出しはfarポインタを
使用する必要があります。
なお、私は使おうとするAVRのフラッシュ容量を見てfar使うか使わないかを使い分け
られるようにしてます。しかしなんでもかんでもfarにするとべらぼうにリソースを
食ってしまいますのでChaN師に倣いfarはなるべく使用しない方が吉です。
２．マッピングあり&フラッシュ容量32kBのマイコンとして使う
妥協案その1。AVR128DAを32kB分しか使わず残り96kBは見なかったことにしたら
32kByte全域にPROGMEMしないでもconstだけでアクセスできるわ♥ﾔｯﾀｰ!
ってあほか！
３．マッピングあり&rodataだけ最終セクタに押し込む。
妥協案その2.リンカスクリプトをいじくり倒してrodataだけ96kB以降に押し込んで
この領域をマッピングする！
これが一番妥協できて無難ではないでしょうか？FONTX2みたいな馬鹿でかい
ファイルおかない限りはリード専用領域32kBは十分すぎると思いますよぅ。
リンカスクリプトのいじる際のミソは__RODATA_PM_OFFSET__にデータ領域へ
マッピングされたアドレス0x8000を指定することとtextの次にrodataが
来るようにすること(重要)
順番間違えたらビルドが通らないです。
こんなわけでAVR−Dxシリーズの売りの一つだったフラッシュ領域のデータ領域への
マッピングも一応使いものになってきましたので少しは救いになったかと思います！
今回のソースコードは↓になります。回路はAVR128DA48-CuriosityNANOに準拠した
つくりとなっておりますが設定を変えてビルドしたらDBシリーズでも使用可能です。
AVR-DAとかDBとか買ったはいいものの持て余してる方はお試しください。
AVR128DA48 CuriosityNANO TestProgram.
●AVR-XMEGA、お前は救えない
上でちょっと触れたfar使う使わないの判定ですがXMEGAにも横展開しました。
対象はChaN氏のAVR版xprintfと私のavr版fontx2ドライバです。
FONTX2ドライバとかサイズでかいからさいっしょっからfar必須でしょ
とお思いかもしれませんがankコードだけなら10kbyteもないものが
あるので少しでもリソース減らすために追加してみました。
なんというか4年ぶりのxmegaの更新をしましたがここまでプログラムの規模が
でかくなるとやはりSTM32とかの32bitマイコンのほうが使いやすいなと感じます。
一方AVR使うならフラッシュ容量32kB以下のものを使っていくのが適材適所かなと
感じてます。進化の袋小路に入りこんだXMEGA。そこから生まれたAVR-Dxは
どこまで正当な進化を続けられるのか？
これからの活躍を見届けたいと思います！
おまけ
超久しぶりにXMEGA触ったからAとAUの違いって何だろうと調べたらUSB機能追加の
ほかにPORTLが存在しなくて不可能だった4Port-EBIが完全に使用できるのが判明！
今さら遅いんだYO!
STM32G0を使ってみる2 -I2Cを使ってみるていうかそれぐらいしか思いつかない-
本年度も後半に入ってしまいましたが今年最初に紹介したSTM32G0を
もうちょっと使って見ようと思います。
さて…本来はこのような構成でI2Cデバイスを使う予定でしたが…
残念ながらリマップの関係上かなり難しいことが判明…オプションバイトを弄らず
自由に使えるのはたったの3ポートのみ！
しかもSTM32G031-Discovery互換ではI2CのSDAで使うPA12(6Pin)が
LEDに取られてしまっているのでお辛い…
そんなわけで折半でこのような回路構成にしてみました。LEDとI2CのSDAを
干渉させないようにわざわざ高速バッファを挟む本末転倒…だがそれがいい
SWCLK,SWDIO,nResetはいつでも使えるようしておきました。先人の方々も
I2C専用で動かすことを前提でこれ使ってる感じですね。
それとあまったPC14(1Pin)は1wireでもぶら下げるとしますか…
ピンの選定については今回は下記の方の記事を参考にしました。
ありがとうございます。
Crescent様
http://meerstern.seesaa.net/article/477348927.html
システム関連ピンのGPIO化に際する注意を詳しく解説されています。
caa45040様
https://qiita.com/caa45040/items/a6ca28ae4b1dfa5c489c
オプションバイトをいじりリスクを負ってたくさん製作されておられます
ねむいさんもS-5851A持っているのでせっかくだからまねさせてもらいます
液晶はもちろんドットマトリクスな中華I2C液晶です！
ROMが32Kbyteあるのでfontx2でankフォントくらいは表示できますね！
液晶については過去記事のこちらをご参照ください。
一時期aitendoで売ってたので持ってる方はまだいるかも！？
特にリマップとかは行わず、パワーオンリセット後のGPIOポートをそのまま
使用するので5PinがI2C2のSCL,6PinがI2C2のSDAとします。
また、S-5851AのアドレスはAD1=1,AD0=0として
0x94(7ビットアドレスだと0x4A)に。
あとはSTM32F03のプロジェクトからI2Cライブラリをサクっと移植し動作完了☆
すごいやっけつ感ですがあっけなくできてしまいました。さすが私
STM32G0のI2C周りはSTM32F3やF0系とほぼ同じレジスタ構成なのでややこしい
タイミングレジスタの設定値もタイミング値計算機で算出可能です。
STM32のHSIは16MHz,そこからSysClockの64MHzにします。
この設定で100kHzのI2Cクロックを生成する数値を代入します。
オシロスコープで実際の波形をキャプチャしたところです。きっかり100kHzは
出ませんがまぁだいたい近いですね。画像はSTTS751との通信(I2Cアドレス0x72、
7ビットアドレスでは0x39)です。
こんな感じでI2Cの解析にPicoscope大活躍ですわ。
そうだね宣伝だね。
そんなわけで重い腰を上げでSTM32G0の続きやってみましたがあとから来た人に
どんどん先を越されてしまいましたがいつもの感じでやっていこうと思います。
そして…小さな巨人STM32G0で次動かすデバイスは…
こいつだ！
つづく！
おっとーその前に久々の新規プロジェクトになりますがこちらにアップロードして
おりますので自己責任でどうぞ。
いろいろ試す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を使ってみる4 -キャッシュ・ワンダリング(中篇)-
←前回 次回→
自宅のPC環境を完全にWin10に切り替えました。
ハードウエアも11年ぶりに新調してメモリも16GBも乗っけてます！！！！
システムディスクも最新のM.2SSDに換装してこれで向こう20年は戦うことが
できるでしょう！！！！！
さて、今回は前回説明した各種キャッシュ設定がパフォーマンスにどう影響
してくるのかを実動作を交えて説明していこうとおもいます。
比較ということでlibpng(倍精度浮動小数点演算あり)のデコード/表示時間を計測して
いきます。ﾃｽﾂ用png画像は自作の虹裏的美少女ｲﾗｽﾂを使用してまいります！
突っ込みは受け付けません！！いないさんかわいい！!1！！！1！
また、png画像を読み出すストレージは以前紹介した産業用MicroSDの64GB品を使用
します。安くて信頼性があって使い勝手が良いので重宝します♥
●キャッシュ無し
まずはデータキャッシュそのものを無効にします。
本当はAXI-SRAMだけ無効にしたかったのですがなぜかpngのデコード時にHardFaultに
なってしまったので仕方なくぜんぶキャッシュOFFにしてます。
キャッシュ効いてないせいで遅いのですがAXIバスのクロックが200MHzと高速なので
それでも十分"早い"ですね…
●ライトバック&ライトアロケートなし
こちらはいつもので公開しているキャッシュ設定となります。
ライトスルーのエラッタが認知されてしまった今これに頼らざるを得ません。
●ライトバック&ライトアロケートあり
ライトアロケートなしとほとんど変わらず誤差程度です。
これならライトアロケートありでいいじゃんとお思いでしょうが…
残念ながらLTDCと相性が非常に悪くLTDCが管轄するフレームバッファ領域にこの
設定を行っているとご覧の通り表示が崩れてしまいます…
一応対策できないこともないですがキャッシュコントロール関数をあちこちに放り
こまないといけないため全く現実的ではないです。
それならSDRAMにはその設定しないでAXI-SRAMだけにすればとお思いででしょうが
ねむいさんもそうしようと思ったのですがなんとSAIとも相性が悪く高ビットレートの
音声再生時にﾌﾞﾁﾌﾞﾁノイズが入りやがりますorzこちらもあちこちでキャッシュコント
ロールしまくったら問題ないのですがそんなんするくらいならライトバック＋ライト
アロケートなしのほうでいいやとなり今に至った次第です。
●ライトスルー
今となってはエラッタで禁じ手になったライトスルーモードです。
ライトバックより遅いですがキャッシュ無しより断然早い理由は実メモリに書き込みに
いったときにライトバッファが効いて速度が上がっているからです。
いちいちcleanしないで済むから楽だったんですけどねライトスルー…
●おまけ・ｶﾘｶﾘﾁｭｰﾝのF7
STM32F769I-Discoでも同じMicroSDを使ってやってみました。
フレームバッファを除くDMAの送受信バッファ・各変数・ヒープ領域をキャッシュ
しなくても超高速に動作できるDTCMに設定して同じようにやってみたのがこちら。
H7と比べるとコアクロックが1/2の200MHz動作なのですが意外と健闘してます。
F7シリーズではDTCM領域でもDMAできるのでこのような芸当ができるのですが
H7は直接できなってしまいましたのでライトスルーが使えなくなったのもあって
DMAするだけでもいろんな工夫が必要です。
次回はSTM32H7でキャッシュを効かせた状態でDMAをどのように安定して動かして
いけば良いのかを解説していこうと思います。
20191104追:
jujurouさんがF7ではSDRAMのライトバック+ライトアロケートなしでもDMA2Dで
表示おかしくなると報告されているのでねむいさんも追って知らべてみました…
が…(STM32F746G-Discoveryで試した)
ううむねむいさんのいつものじゃどういう状況でもデータ化けしてぬぇ…
※9月度版の時点でライトバック版に変更済みです。
キャッシュを効かせたRAM領域にフレームバッファを確保してLTDCを動作させている
時点でDMAしてる時と同じようになりDMA2DせずともキャッシュとLTDCコントローラ
との干渉が発生してしまいます。これはライトアロケートあるなしに関係は
ないのでライトバックではデータ転送前に必ずキャッシュのCleanが必要です。
ねむいさんのいつものでこれに引っかかった例がChaNさんのjpegライブラリを使い
jpegファイルを表示させようとした時で、disp_blt関数内で転送直前にクリーンを
行うことにより対策しております。
そして前回も簡単に説明しましたがキャッシュコントロールをしているにもかかわらず
ライトアロケート時に表示が崩れてしまう原因は書き込みキャッシュミス時に実メモリ
からデータを読み出しキャッシュラインに展開している動作そのものにあります。
実メモリ(SDRAM)からのread動作によってキャッシュラインが逆汚染され、結果として
寄生Evictionが起こりまくり表示が崩れてしまうことになります。
データキャッシュサイズ上限以下の容量でチマチマ書き換える…たとえばFONTX2の
表示とかの時に一番崩れやすくなります。
↑こんな感じに崩れます。
これはLTDCに限らずSAIとかの基本書き込みっぱなしのぶっ放しのペリフェラルでも
起こりますが長くなりそうなので次回にでも解説します。
いろいろ試す28
おいおいついにGW来たと思ったらもう一ヶ月経っちまいましたよどういうことだYO!
●STM32L0シリーズを使う
数年前に買ったのですけど暖めすぎて腐っちゃいましたてへ♥
STM32L0シリーズはCortex-M0+をコアに持つ低消費電力特化型の
ARMマイコンとなっております。
この評価ボードSTM32L0538-Discoveryも低消費電力に特化した作りとなっています。
主役のSTM32L0は基板裏面にあります。
目玉はこの電子ペーパーです。電源を切っても表示内容が保存されるという優れもの
ですが通常のドットマトリクス液晶のように簡単には扱えずかつ画面書き換えも長い
時間掛かるのでもっぱら静止画表示に留めておくのがまともな使い方といえます。
L0シリーズ初期のSTM32L053C8が使用されております。
この電子ペーパーのドライバにはSTM32L152が使用されてたりします。
こちらが表示して２ヶ月経過した後の画面です。電源を落としても表示内容が保た
れるのですが時間の経過と共にやはり薄れていきます。おもなターゲットとされて
いる店舗の価格表示板での使用を考えたら十分すぎる保持時間ともいえます。
でも白黒なのはウケるのでしょうか？？？？あとはテキストリーダー用途とか？？
フリーの開発環境から使う場合はおなじみOpenOCDで内蔵フラッシュに書き込みます。
※L0シリーズはかなりクロック落とさないとコケまくります。気を付けてください。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32l0discovery_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00143-gf6449a7-dirty (2017-05-20-14:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.240553
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08002148 msp: 0x20002000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
adapter speed: 1800 kHz
adapter speed: 1200 kHz
auto erase enabled
Info : Device: STM32L0xx (Cat. 3)
Info : STM32L flash size is 64kb, base address is 0x8000000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20002000
wrote 16384 bytes from file main.elf in 3.218750s (4.971 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
verified 16096 bytes in 0.140625s (111.778 KiB/s)
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
adapter speed: 1200 kHz
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:04書き込み時のログはこんな感じです。
ねむいさん謹製STM32L0デバイス向けフラッシュ書き込み用cfgは
ねむいさんのOpenOCDバイナリにもちろん収録済みです！
L0シリーズのフラッシュ書き込みは数年前からOpenOCDに対応していたのですが
1Wordごとのﾁﾏﾁﾏ書きしか対応しておらずねむいさんも｢使えねぇ！｣と判断して
肥やしにしておりましたが今年になってようやくマイコン側ローダーのソースが
見直され、まともに使用できるようになりました。
ちなみ何故そうなってしまったかというとCortex-M3シリーズのSTM32L1
シリーズとフラッシュ書き込み用コードと同じ扱いにしてしまったせいで
M0+で使用不可能なM3の命令がローダのバイトコードとして使用されて
しまっていたからなのでした。
ねむいさん当時はNuvotonやKinetisのサポートに躍起になっていたので
STM32に関しては簡単なコードの追加程度しかコミットできなかったのですが
細かい事考えたら先にすすめませんのでとりあえずどんどん活用していこうと
思います。いずれはNuvotonもローダのコード見直したいですね〜。
というわけでおきぱのラインナップに追加しましたのでよろしくお願いします！
おなじみのUARTにリターゲットしたprintfの実行とメモリ液晶にFONTX2ドライバを
用いて文字表示する内容となっております。
もちろんHALライブラリ対応となっております☆
●過去の記事の正当性について考
3月下旬から続いておりますがぶろぐ上でDropBoxの画像が表示されなくなった問題を
ぽちぽちと地道に修正しております。
201705末現在はアクセス数が多かったESP32・ESP8266・ダイトレ・六甲・
STM32F4のの記事はすべて修正が完了し、STM32F7の修正もほぼ終えたところです。
残りは2016年度以前の小ネタ関連の記事全部と東海自然歩道の記事となりました。
それに伴って自分が書いた過去の記事の内容の見直しも適宜行っています。
特にリンク切れが目立ちますが治せるものは何とか治しています。さすがに
3年以上前の記事になるとどうしても今では誤った概念であると判明したり
その時は通じた手法が現在では通じなかったりといったことが沢山出てきます。
ですが対応にもやはり限界はあります。
こちらの方は私の5年前のぶろぐ記事を参照して知りたい情報が消滅し到達できなかった
ことに言及されておられますが2012年のねむいさんは既に｢CMSISv3以降を使え｣と
アドバイスしているのでそれに従わず自己流でされて勝手に困られて私のせいにされ
てもそれはちょっとちがいますよと、特に免責事項はぶろぐのプロフにも明記して
ありますので私に何年も前の内容を補償する義務はないです。と。
これだけははっきりと真実を伝えたかった。
とはいえこのまま放置するのは私としても心苦しいので2017年の内容に即したものに
情報を修正させていただきました。
一方こちらの方が指摘されたENとBOOT間違えてた件はESP-WROOM-32から
放射された電磁波の影響からか私の頭がぼけてて完全に私のミスです。
なんにせよどっかの壺にまた｢こいつが書いてることはデタラメ｣とか書かれないよう
世間に公開する前に一息おいて精読して間違いを修正する癖を習慣づけてこれからは
なお一層のこと気を付けて行こうと思いまし、た！
●FatFsが0.13に更新
ChaN氏のFatFsも5月中旬に更新しておりました！
主な更新内容は"syscalls.c"やoptionフォルダ内のコードページ変換テーブル
が廃止されてffsystem.cとffunicode.cに変更されたこと、あと幾つかの定義も
接頭語に"FF_"が付与されて他のソースコードとの定義のバッティングが低減され
てたことです。
exFAT関するルーチンは初登場以降日進月歩で進化しまくっているので皆さん自身
でforumや更新情報を常に確認した方が良いでしょう。
ねむいさん的にはdefineの接頭語に"FF_"が付与されたのが効きました。自分で書
いた部分にも多数のFatFsのdefineで切ってあったので見逃さないように修正して
廻ったので大変です。ですが何とか全部治すことが出来ておきぱに置いてる
サポート中の4種のFatFs移植例も無事0.13対応となっております☆
・STM32F7(HALドライバ使用)
・STM32F4(SPL使用)
・STM32F1(SPL使用)
・LPC4088
おっと、最も重要な事柄が変更されていたのを忘れておりました。
今回の更新からChaNさんのFatFsに関するページは全て英語のみになり日本語に
訳された解説が完全に消滅しました。
昨今のembedded事情を鑑みると有益な情報は凡て英語圏のコミュニティに
集約されて行くのが必然でありこの流れは避けられない事柄ですがねむいさんの
知能レベルですら英語で意志の疎通が問題なくできておりますので皆さんに
とっても問題ないはずです…よね!?(威圧)
●SDカードの規格がV6.00にバージョンアップ
昨年秋にSDv5に更新と報じましたが早いものでA1クラスの定義が追加されたV6.00へと
早々に規格がバージョンアップしております。もう巷ではそのA1クラスのロゴが乗った
SDカードが出回っているようです。
A1クラスの利点は小さいサイズのちまちま読み書きのスピードが一定値以上保証されて
いるという点ですが随所で上がっているベンチマークを見る限りではA1策定以前から
存在する高価格帯の高性能カードと比べると大きな有意差はなさそうです。
ねむいさんは次買うカードはS.M.A.R.T.が採れるDelkinのMLCのやつに決めてますので
しかも今はフラッシュメモリも3D-NANDへの過渡期でSDカードそのものの値段がどん
どん高くなっているのでA1ロゴ付きのカード見かけても手を出さないと思います。
ていうか民生用SDカードの値段が高くなり相対的にDelkinのやつがお求めやすい
値段になっちまいましたので運よく特別収入が発生したら即買いしたいと思います！！
いきなり10億円(税引き後)とか手に入らないかしら…
STM32F7を使ってみる7 -秋月さんよりF7Discovery販売記念-
※とある大切な方の訃報を受けて霊場めぐりをしていたため更新が一週間以上遅れて
ます。すみません。
先々週末、秋月さんよりSTM32F7-Discoveryが販売されました。
入手しやすくなった事によって皆さんもF7に触れるチャンスができたと思います。
ねむいさんもF7ネタで一つ記事を書きたかったのですがいまいち"ぱんち"が弱く
更新に躊躇していたので今回の販売開始は渡りに舟でした。しかももう一つ嬉しい
ニュースも同時にでてきました。
●OpenOCDがSTM32F7の内蔵フラッシュ書き込みに正式対応
7月上旬、私が最初にいじりだしたころからF2/F4系と別系統のSTM32F7のテスト用
ドライバは存在していたのですが秋月さんの販売と時を同じくしてOpenOCDにF7系の
フラッシュ書き込みサポートがF2/F4ドライバに正式にようやく追加されました。
Corex-M7はL1キャッシュを持つのでフラッシュ書き込みルーチンを呼び出すとき
にメモリバリア命令を張って意図した手順で書き込みのための命令を実行させる
ようにしないといけませんでした。
最初にコミットされた時はそんな理由でF7専用のフラッシュになっていましたが
同じMPUを持つF2/F4系でも問題が無かったため結局stm32f2x.cに統合されています。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32f7discovery_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0-dev-00104-gf3be0f6-dirty (2015-11-13-09:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.219974
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0803276c msp: 0x20010000
auto erase enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000046 msp: 0x20010000
wrote 786432 bytes from file main.elf in 18.501879s (41.509 KiB/s)
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
stm32f7x.cpu: target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20010000
verified 600552 bytes in 2.451303s (239.251 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:21
書き込みはこんな感じです。以前と全く変わってませんね〜。
私が提供しているバイナリはもちろんSTM32F7-Discoveryに対応しています★
また、以前も伝えましたがSTLink/V2-1のファームは2.24.11以降にアップデートして
おいてください。古い番だとmbedのMSCの方のインターフェースと干渉して書き
込みが必ず失敗してしまいます。秋月さんで購入できる奴はさすがに最新版に
なってるはずですのでたぶん問題ないでしょうけど。
●MPUとSDRAMのキャッシュ設定
過去にも少し触れたMPUの事ですが、F2/F4系ではほとんど出番がなかった代物ですが
L1キャッシュが実装されたF7系では極めて重要な意味を持ちます。しっかり考えて設定
しないとパフォーマンスに大きな影響が出てしまいます。
書くいう私もキャッシュの概念をよく理解してなくてDMAで無駄に苦戦したり
してましたが新たにFMCを使ったSDRAMで手落ちを見つけてしまいましたorz
↑AN4667より引用
通常はFMCはD-Cacheを通じてアクセス速度の向上が行われているのですが、それが
有効なアドレス領域はCortex-M7のコア上で制限があります。
SDARAMが割り当てられるアドレス(0xC0000000~)ではご覧のとおりキャッシュ
メモリの恩恵にあやかることができません。
↑AN4667より引用
FMCのSDRAMのアドレスをリマップしてキャッシュが効くアドレス領域に変える
方法もありますがMPUでキャッシュ可の領域に設定してしまう方が簡単です。
MPUの設定はこんな感じです。キャッシュ有効の時に"MPU_ACCESS_NOT_BUFFERABLE"
とするとライトスルーとなります。
ライトバックは"MPU_ACCESS_BUFFERABLE"です。
なお、FMCやSDRAMを有効にしてなくてもMPUはそれらと完全に分離しているので、
設定した瞬間にいきなりHardFaultとかになることはありません。
また、QSPIの領域については前途のとおり元からキャッシュ可になっていますので
特にMPUを設定する必要はないです。
てわけで早速いつものjpegファイルのデコード時間で比較してみましょう。
その１．フラッシュインターフェースはAXIM
↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
予想通りキャッシュ無効のデフォルト状態の方が断然はやi...
…
？？？
？？？どういうことなんだ？？？(←C.V.櫻井のイケボで)
キャッシュ無効が一番早いじゃないですかー！？たぶんAXIMバス経由でプログラムを
実行してるからバスのトランザクションとかキャッシュラインが干渉しまくって
逆にパフォーマンスが低下してしまったのでしょうね。
･･･すみません適当な考察で…てわけでAXIマトリクスの影響を受けないITCMから
プログラムを実行してみますか。
その２．フラッシュインターフェースはITCM
↑MPUは何も設定してないSDRAMのD-Cache無効状態です。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
↑MPUを使ってSDRAMのD-Cache有効、ライトスルーです。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
↑MPUを使ってSDRAMのD-Cache有効、ライトバックです。
最適化スイッチは-Ofast、FONTX2ドライバは内蔵フラッシュからです。
ITCM経由だとバスの競合が減りますので確かにキャッシュが効いているのが
分かりますね★
所で本来ならライトスルーよりライトバックの方が早くなるはずなのですが、
ライトスルーの方がほんの少し早い結果になりました。キャッシュを効かせて
いるとキャッシュヒットとミスの時のブレ幅がかなり大きく出てくるので
そっちの方が気になるくらいですけど。
おきぱのF7のサンプルではAXIM/ITCMの両方でSDRAM領域のMPU有効・ライト
スルーキャッシュ設定にして更新しております。
以前はQSPI-ROMにFONTX2ドライバを置いていた場合文字の表示で崩れる
ことがあったのですがSDRAM領域もMPU・キャッシュ有効にするとそれが
一切発生しなくなったという副次的効果が見られましたのでAXIMだと
若干パフォーマンスが落ちますが敢えてMPUを効かせています。
もちろんキャッシュを経由するとDMAの問題がまた持ち上がってきますが
私のサンプルではDMA2Dをそうなる使い方はしてないのが分かったので
DMA対策は特に行わず様子見としております。
さらについでですがCubeF7もV1.2.0になってHALライブラリもV1.0.2に
アップデートしておりますので差し替えてあります。
でもSDMMCのuint64_tで処理しなきゃならない処理がuint32_tのままで
まだ治ってないので私自らHALライブラリに修正を加えておきましたｸｿｧ！
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はぢめました
昨年秋にプレスリリースで発表されたSTM32F7ですが私がESP-ROOM-02弄りに
夢中になってる間にひっそりと市場に流通しておりました。
ﾋを見てたら国内外問わず既に入手してOpenOCDでバリバリ使い倒してる人たちもいて
STM32好きの私としてはすっかり流れに取り残された感じですがDigiKeyで大量に在庫
していたので私も一つ購入してみました。
目の前に現れたSTM32F7-Discoveryは私の知ってるDiscovery系のキットの想像を
超えた液晶もSDカードスロットも外部SDRAMもQSPI-ROMもついた夢の全部載せでした！
ちなみに液晶のタッチパネルは抵抗膜式ではなくなんと静電容量式です！
なんてゴージャスな…
Cortex-M7コアを持つSTM32F746NGH6が搭載されています。スペックについては昨年
秋も触れましたが量産開始後に最大動作周波数が200->216MHzにパワーアップして
ます。デバッガはSTLinkV2-1が搭載されています。
当然のごとくSDRAMが搭載されています。Micronの128MBitのSDRAMです。
同じくSTM32F7シリーズの目玉の一つQ(uad)SPI-ROMです。LPC4000シリーズの
SPIFIと同じくリニアなアクセスができるのが特徴です。FontX2ファイル等の
大規模データは一切合財ここにぶち込みましょう！
また、Ethernet用のPHYも搭載です。接続するピン数が少ないRMII方式で
STM32F7と接続されています。
さらにUSB-HighSpeed用のPHYまでついています！！こちらはULPIで接続されます。
後で触れますがUSBメモリを接続するのにちょうど良いですね。
さらにさらにI2S-Codecも搭載されています！！！STM32F4でも搭載されていましたが
同じように"いつもの"が出来そうです。SAIインターフェースで接続されています。
そしてこれだけそろってお値段はなななんと$50ですよ奥さん！！(DigiKeyより)
こんな時代になったのですね…2009年のころは全く考えられなかったのですが…
しみじみ
しみじみするのはその辺にして早速いじってみました。
STLink側のUSB-miniBケーブルをPCと接続するとドライバを読み込んだ後STM32F7
側にも電源が供給されてプログラムが走り出します。
すぐにナウいロゴが出てきます。
すぐにメニュー画面になり、タップでいくつかのアプリケーションが選べるように
なっています。しかもCPUの負荷率もリアルタイムで表示されます。
200MHzで動いているので結構発熱します。F4シリーズと違ってΔTは10度以上あると
思ってください。それでも他の品種の同周波数のものと比べると低いほうですが。
静電容量式タッチパネル(CTP)なので物理で押してもだめです。指で操作しましょ。
先ずは"audioplayer"です。USBメモリに仕込んだwaveファイルを読み込んで再生し
ます。デモはHS側のUSB-OTGだけしか反応しませんのでご注意ください。USB-FSや
SDカードは未実装のようです。
再生してる所です。音量調節が狭くて音量を上げようとすると指がメニューに
あたってしまって最初の画面に戻ってしまいがちです。どうでもいいですが。
infoメニューでは現在の動作周波数やファームウエアのバージョンが表示されます、
ファームウェアとやらは勿論STM32CubeF7の事です…。
どうでもいいことですがたまに異様にCPU負荷が100%になって動作が異様にもっさり
したり固まったりするのですが私の操作が早すぎるせいなのでしょうか？？？
さて、デモプログラムを触るのはこの辺にしてねむいさんのいつものの準備を、
GCCのコマンドラインビルドできる環境を固めて行こうと思います。OpenOCDはまだ
レビュー段階ですがSTM32F7フラッシュ書き込み用パッチが公開されています。
糞ややこしいのですがパッチはCortex-M7用とSTM32F7用の2種類か必要でした
http://openocd.zylin.com/#/c/2786/
http://openocd.zylin.com/#/c/2784/
http://openocd.zylin.com/#/c/2753/4
http://openocd.zylin.com/#/c/2753/5
2753は要注意です。#5のパッチだけあててもF7対応になりません！
まぁやり方さえわかればビルドはいつもどおりなのでらくちんです★
バイナリは既にSTM32F7対応に更新してあります♥
cfgファイル群も更新しましたのでどうぞ。
STLink/V2-1もファームがM11に更新されていますので事前にアップデートして
おきましょう。STLink-Utilityも3.6に更新しておいてください。
20150714追:
M11に更新しないとOpenOCDで書き込むことができませんのでご注意！！！！
まだF7向けのGCCプロジェクトはこさえていないので記事を書く2日前に1.0.1に
アップデートしたばっかリのCubeF7のF7Discovery向けのデモプログラムの
ビルド済みhexファイルをOpenOCDから焼いてみます。その前にSTLink-Utilityで
接続し、デモプログラムのhexを読み込ませてみました
このhexファイル、19MByteも有るのですがフォントと画像データがあるQSPIの領域も
含まれているようです(0x90000000以降の領域)。まだ外付けのQSPIの読み書きには
対応していないので内蔵フラッシュしか書き込むことができませんがQSPIに仕込んで
あるデータはシカトして内蔵フラッシュのだけ無理やり更新できます。
STLink-UtilityのExternalFlashLoaderにF7Discovery向けのQSPIドライバ無いんです
けぉ･･･###それはおいといてOpenOCDに話を移します！！！！
案の定QSPIの領域ではエラーが出ますが何とかフラッシュは書き込みできてます。
無事ファームウエアをV1.0.1に変更することができました。
そんなわけでSTM32F7をほんとに触りだけでしたが触れてみました。
これからいつものビルド環境に合わせたプロジェクト作りを進めて行きたいと思います。
F4の時にCubeF4向けにペリフェラルドライバの移植を試みましたが結局UARTまでしか
実装できなかったので今度こそ本気出します！！
(2年ぶり4度目)
STM32F7が発表になってCMSISヘッダファイルもようやくV4.00になった
20150717追
STM32F7はぢめました
20150717追
少し前にCortex-M4をさらに進化させたCortex-M7が発表され、ねむいさんを含む
一部の方の間で騒然としておりました。同時にSTMicroさんからも同コアが搭載された
STM32F7シリーズが発表され、既にBGA品がサンプルとして
出荷されているそうです。
既にSTM32F7用のサイトもあってデータシートも
公開されております(RMはまだです）。
Cortex-M7コアではAXI+AHBのマトリクスになり、密結合メモリ(TCM)も
インストラクションとデータ専用に用意されさらに外部メモリ用にI/Dとも
4kByteずつL1キャッシュも搭載されております。
ねむいさんがSTM32F7で着目したのはLPC4300シリーズではおなじみのクアッド
SPI-ROMの対応です。
これによりリニアなアドレスに配置されて内蔵フラッシュと同じ感覚で
使用できることになるためFONTX2のような大容量のデータを扱うプログラムも
組み易くなりますね♥
内蔵フラッシュが1MBに抑えられているのもデータの塊はSPI-ROMに押し込めよ
という意図があると思います。
あとCortex-M7では浮動小数点演算ユニット(FPv5)が倍精度まで対応して
います…が、STM32F7ではSTM32F4と同じ単精度のみの対応となるそうでF**K!
発表された当初はデータシートよく読み込んでおらず、ついに倍精度に
対応かー！と思い込んでたのでぬか喜びでしたorz
アーキテクチャとしてはCortex-M4Fと同じARMv7E-Mとなるのでバイナリは
互換出来るそうです。STM32F4ではTCMではなくCCMがありましたがそれが
配置されていたアドレスはTCMとは全く異なりますので凝った使い方されて
いる方は結局リンカスクリプトから組み直しになりますのでご注意ください。
しかしながらCCMではできなかったDMA転送がDTCMでは可能になっていますので
かなり素直にプログラムを組むことができるようになるでしょう。
さて、発表されたばっかで商用はともかくGCCコンパイラもこれから対応開始となる
ようですのでSTM32F7を実際に入手して遊べるようになるのは半年くらい先に
なるかなと思います。
STM32F2の時見たES品が中華から流れてきてくれたらもっと早いかも。
20141001追：
LauchpadのARM-GCCがアップデートされましたがなんとCortex-M7の対応が
ギリギリで突っ込まれたようです！
STM32F7対応にする場合はSTM32F4からは以下のようにオプションを変えることに
より可能です。
STM32F4:
-mthumb -mcpu=cortex-m4 -march=armv7e-m -mtune=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16STM32F7:
-mthumb -mcpu=cortex-m7 -march=armv7e-m -mtune=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16そしてCMSISのサポートの方ですがこちらの方は発表と同時にCMSISもアップデート
してヘッダライブラリもやっとこ3.30->4.00に更新されています。
もちろんCortex-M7コアのヘッダも追加されております。ようやくメジャーナンバの
更新になりましたが私が試したところでは全く影響はなかったのでそのまま差し替えて
使用が可能かと思います。
おきぱのプログラムも10月度の更新から順次V4.00版CMSISヘッダファイルに
差し替えて更新していきますのでよろしくおねがいします。
おまけ
STM32F411RE-Nucleoが夏前に手に入りました。STM32F411シリーズはF401の
機能拡張版の位置づけのようです。PCM1723氏が非常に詳しく考察されています。
PCM1723氏もCubeMXのバグに言及されてますね…
なお、おきぱのF401-Nucleo向けのバイナリはそのままSTM32F411版でも
使用可能です♥
OpenOCDはSTM32F411シリーズは未対応だったので対応させております。
本来はOpenOCD小ネタ行きの案件ですが小ネタ過ぎて載せられなかったので
こちらで告知させていただきます。
次回は大物の更新が控えていますのでご期待下さい♥
おきぱにあるWindows用バイナリもすでに対応済ですのでご利用ください。
おまけのおまけ
ああああああああああああ！！
RTC用のチップコンデンサは位置的に物が当たり易い位置にあってすぐ欠けるorz
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キャラクタ液晶の電源投入時の変な動作とか回避の
ためのバスリカバリとかキリがないです。ですが今回みたいなひょんなことを
チャンスにして公開していきたいと思います。
STM32F4シリーズを使ってみる11 - STM32F429I-Discovery発動編 -
ぇー…前回のSTM32の記事の最後で新しいコードスニペットと称するどことなく
卑猥な名称のふれこみで発表されたSTM32CubeMXとそのF4シリーズのサポートを
行うCubeF4という新たなファームウエアライブラリに触れましたが…
私も移植を目指して頑張ってたのですが…
私の従来のいつものに当てはめようと思うと改造個所が多岐に及び、さらにコード
サイズとオーバーヘッドも増加してしまったので移植は見送りにして新規に作る
プロジェクトからCubeF4を使用する方針に逃げ変えました。
STM32CubeF4には抽象化がさら進められ、インスタンスという概念が追加され
ています。これがかなりの曲者で従来のF4シリーズで言うDSP_StdPeriph_Driver
ライブラリに相当する"STM32F4xx_HAL_Driver"はすべてこれの
使用を前提としていてさらにサイズが大きい構造体と併用しなければならない
のが分かりました。
これSRAMやFLASHのリソースが膨大にあるF4シリーズだからよいものをF1やF0
にも当てはめるのはかなりヤバいと思います。
私も過度の抽象化は良いとは思っていません。移植性を重視しすぎてせっかくの
マイコンの性能を引き出せないのであれば本末転倒です。
あんまし考えたくないのですが無理くそ全CPUの格差を埋めるべく抽象化を
目指し、そして失敗して結局ライブラリのバージョンが多岐に分かれて
しまったLPCOpenと同じ道を歩んでいる感じがします。
おそらくCube系のライブラリに遷移していくあたって大混乱が起こると
思いますね。無理にCubeへの遷移を煽る中途半端に発言力が持ってる人が
湧くのは容易に予測されます。学生さんなんかは自分のボスの"せんせい"
にまたCubeライブラリの使い方をwikiにまとめさせられると思います。
そういうこと言ってくる人らには"こんなことしてること自体が時間の無駄。
したけりゃ自分でやれ！"とはっきりNOを突き付けるべきです。
とはいえ私のぶろぐを見られている方は私よりも技術力がはるかに上の方
ばっかなのでそもそもこんなとこ見てない私が注意しなくても各自しっかり
対処出来することができるでしょうからぐだぐだ言いましたがやっぱし
私の杞憂かな〜と思います。
さて、前置きが長くなってしまいましたが以前から触れてきた
STM32F429I-DiscoveryのTFT-LCDをSPIではなくRGBインターフェースで
動かすことに成功しました。
前回は低速なSPIインターフェースでお茶を濁していました。
しかしSTM32F429シリーズにTFT-LCDに特化したグラフィックコント
ローラ(LTDC)とグラフィックに特化したDMAである(Chrom-ART Accelerator)
が搭載されているのでこれらの機能を使っていつものの再現を目指し
ようやく完成したわけです。
●STM32F429Iにあるグラフィック機能
私が説明するよりもこちらのPDFを見たら一目瞭然です。
LTDCに関してはフレームバッファとして確保したメモリアドレスにRGBの
データを書き込むだけで色の表示が可能です。また、STM32F429系では
SDRAMがサポートされているので容量を喰う画像データでも余裕で
取り扱うことができます。
Chrom-ART Acceleratorに関しては別名DMA2Dと称されていて文字通り
2Dグラフィック特化型DMAです。しかもデータ形式を変換してメモリ間
転送したり単一データを指定して転送する(レクタングルフィルに効果を
発揮)ことができます。
STM32F429I-Discoveryでは上記二つの機能を体験可能です。同ボードに
搭載されたTFTLCDの解像度は工作物ではメジャーな240x320となっています。
STM32のLTDC単体ではレクタングルを指定して書き込み時にアドレスを
自動インクリメントしながら連続で書き込める機能はない(DMA2Dで
解説します)ためアドレス計算は必須です。
具体的にいうとたとえば座標x,yにドットを打ちたい場合は基本的には先ず
以下のように座標を指定します
(RGB=565,1ドットあたり2Byteのデータを想定)。
lcd_c_buf_ptr = lcd_f_buf_ptr + 2*(x + (MAX_X*y));
lcd_c_buf_ptr :ドットデータを実際に書き込むメモリのアドレス
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義)
次にRGBデータcolourを書き込みます。
*(volatile uint16_t*)(lcd_c_buf_ptr) = colour;
lcd_c_buf_ptr +=2;
より具体的な実装はいつものの./lib/display/mcu_depend/src/lcdc_if_basis.cを
ご覧下さい。FONTX2等の描画ルーチンは完全にドット単位で行っていますが
MCUバスと外部LCDコントローラとの通信オーバーヘッドがなくなるので
ドット単位でも十分に早くなります。また、LTDCは2枚のレイヤーを使用可能で
さらにアルファブレンディングの透過効果も使用可能です。現状では単一の
レイヤとしてしか使用していませんがこちらも学習を重ねてモノにしていきます！
次にもう一つの目玉機能Chrom-ART Accelerator(以下DMA2D)です。
私のいつものではFillRect系のレクタングル指定塗りつぶしやレクタングル
指定の動画データ転送に使用しています。
基本的には通常のDMAと同じですがグラフィック特化なのでRGBデータを
格納するレジスタもあります。単一色描画では以下のように設定します。
※RGB565,黒色,全画面(240x320)塗りつぶしの場合
/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode = DMA2D_R2M;
DMA2D_InitStruct.DMA2D_CMode = DMA2D_RGB565;
DMA2D_InitStruct.DMA2D_OutputGreen = (0x07E0 & COL_BLACK) >> 5;
DMA2D_InitStruct.DMA2D_OutputBlue = 0x001F & COL_BLACK;
DMA2D_InitStruct.DMA2D_OutputRed = (0xF800 & COL_BLACK) >> 11;
DMA2D_InitStruct.DMA2D_OutputAlpha = 0x0F;
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_f_buf_ptr;
DMA2D_InitStruct.DMA2D_OutputOffset = (MAX_X - 1));
DMA2D_InitStruct.DMA2D_NumberOfLine = MAX_X+1;
DMA2D_InitStruct.DMA2D_PixelPerLine = MAX_Y+1;
DMA2D_Init(&DMA2D_InitStruct);
/* Start Transfer */
DMA2D_StartTransfer();
/* Wait for CTC Flag activation */
while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
フォアグラウンドのレイヤーへ画像データを転送したい場合は以下のように。
/* configure DMA2D */
DMA2D_DeInit();
DMA2D_InitStruct.DMA2D_Mode = DMA2D_M2M;
DMA2D_InitStruct.DMA2D_CMode = DMA2D_RGB565;
DMA2D_InitStruct.DMA2D_OutputGreen = 0; /* M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputBlue = 0; /* M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputRed = 0; /* M2M系転送の場合は使わない */
DMA2D_InitStruct.DMA2D_OutputMemoryAdd = (uint32_t)lcd_f_buf_ptr;
DMA2D_InitStruct.DMA2D_OutputOffset = 1;
DMA2D_InitStruct.DMA2D_NumberOfLine = MAX_X+1;
DMA2D_InitStruct.DMA2D_PixelPerLine = MAX_Y+1;
DMA2D_Init(&DMA2D_InitStruct);
/* Configure default values for foreground */
DMA2D_FG_StructInit(&DMA2D_FG_InitStruct);
DMA2D_FG_InitStruct.DMA2D_FGMA = (uint32_t)p;
DMA2D_FGConfig(&DMA2D_FG_InitStruct);
/* Start Transfer */
DMA2D_StartTransfer();
/* Wait for CTC Flag activation */
while(DMA2D_GetFlagStatus(DMA2D_FLAG_TC) == RESET){}
lcd_f_buf_ptr :フレームバッファとして確保したメモリ領域のベースアドレス
MAX_X :TFT-LCDのX軸の最大ドット数(F429I-Discoveryでは240と定義
MAX_Y :TFT-LCDのY軸の最大ドット数(F429I-Discoveryでは320と定義
p :転送したい画像データのポインタ
と、従来のDMAと同じ感覚で使用が可能です。もっと汎用なDMA2Dの使用法は
同じくlcdc_if_basis.cをご参照ください。DMA2DはLTDCと組み合わせると
強力なレイヤー機能が使えるようになるでしょうね。
私のサンプルでは全く使いこなせてませんがー！
という訳でそれを踏まえたいつものをビルドして書き込み、
動作させたものが上の画像です。
静止画では違いが分からないと思いますが以前の8-bitSPIのみで動かしてた
ものとは描画速度がダンチですよ♥
惜しむらくはSTM32F429I-Discoveryに使用されているTFT-LCDが発色にちょっと
劣る点です。2014年現在では超高視野角液晶はすでにホビイストでも容易に
入手可能なのでそれに慣れた私にとってはあと一歩がほしいところと感じました
(多分最新の奴搭載したら値段跳ね上がるでしょうけど)。
●いつものFatFs+TFTLCD表示サンプルの細かい整備など
LTDC+DMA2Dに対応したついでに長らく放置していた全部載せSTM32F427IIT6基板の
プログラムも見直して安定化を図りました。いまさら気付いたのですが、新しい
STM32F4に存在するFMC(フレキシブル・メモリコントローラ)ではFSMCの
設定とは微妙に違っておりました…。
なんとFSMCでは存在しなかった変数が構造体に追加されていてこれを設定して
なかったせいで動作が不安定になっておりましたorzいまさら気付きましたが
まだFMC世代の新しいSTM32F4を使用されている方が少ないのか指摘されず
助かりましたうふふふふふふふｆ
また、この全部載せ基板はI2Cのコーデックも乗っていて音質は非常に悪い
ですがmp3やwaveファイルの再生も可能です。私のいつものプログラムでは
SDIO経由でSDカードのmp3ファイルなどを読みだして再生します
…がしかしビットレートが高いmp3の再生ではSDIOのデータ読みだしにDMAの
転送を行うとI2Sの方のサーキュラモードDMA転送と干渉しまくりあっと
いう間にオーバーフローになってエラーをはいて止まります。
という訳でこれを避けるためにSTM32F4でもFIFOのポーリングでの読み書きに
本格的に対応させることにしました。STマイクロ配布のSTM32F4のデモでは
ポーリングの読み書きはRead/WriteBlockしか対応しておらず非常に低速度
なのですがマルチブロック転送でもポーリングで読み書きできるように
改良しております。ポーリングでもDMAとほぼ同等の転送速度が得られたので
速度に関しては問題なしです。
…という訳でDMAあえてを使用せずポーリングによる読み出しだけで無事ビット
レートの高いmp3ファイルの再生も可能となりましためでたしめでたし！
(helixのフォルダにあるassembly.hのマクロが前回の機能追加で間違ってて
そもそもmp3ファイルが全く再生できなくなっていたのは見逃していただきたい)
●もいっこおまけ
私のいつものでは一部のmp3ファイルを再生したときにアーティスト/曲名情報
表示の際にゴミデータが表示されてしまっておりましたが、こちらも文字列ストア用の
バッファ(私のプログラムではCCM領域にあたる)を一旦ゼロクリアしてから
表示を行うようにしてバグを潰しております。
以前は変なゴミデータが表示されていましたが…、
修正後はこんな感じにすっきりです★
STM32F4シリーズを使ってみる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さんので初期化ルーチンが提示されてない品種)追加
しておりますのでこちらも併せて皆さんの参考としてください。
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超格安全部載せ基板買ってしまってもったいないですし！
Windows10対応軽量シンプルなARMマイコンのGCCビルド環境を構築する(2020年度版)
OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
解説はこのバイナリを基にすすめますので4649!
当記事はWindows環境下におけるARMマイコンの開発環境構築を目指してはおりますが
私が公開しているプロジェクトをビルド/デバッグするために必要な最小限の手順の
指南という位置づけです。
はっきり言いますが初学者向きの解説ではありません。専門的な語句の意味や
GNUMakeを駆使したコマンドラインビルドの方法を熟知している前提で話を進めます。
2019年現在は無料のEclipseベースの開発環境GNUARMECLIPSE、
STM32限定でフル機能が使えるAtollic TrueStudioとMDK-ARMの2品種、
そしてオンラインコンパイラ+ライブラリ等の強力なサポートがあるmbedとかが
充実しており、一般的な事柄を学びたい初学者の方にはそちらを強くお勧めいたします。
ちなみにねむいさんはメーカサポートが無い素のEclipseを使うと｢あわびゅ！｣と
叫びながら全身から血を吹き出して死ぬ奇病に罹っていて、且つCygwinを使うと
バストサイズが強制的に20cm減のマイナス補正を喰らい(=フラットなB(Breasts)特性
を持ついないさんと同レベルに堕ちてしまい）虹裏メイドねむいさんとしての
あいでんてぃてぃを完全に失ってしまうため、当ぶろぐでは絶対に扱いません。
※要注意※
ツール群の盛衰や時勢により時々刻々と本記事の内容は変化していきます!
●必要なもの
１．ARM用GCCコンパイラ
とにもかくにもまずはこれです。
現在はLaunchpad.netが提供し、ARM本家から配布されている
GNU Tools for ARM Embedded Processors
を強くお勧めします。表向きCortex-Mx向けとなっておりますが、LPC2388等の
ARM7TDMIもしっかりサポートしており古い品種でも問題なくビルドが可能です。
今回の手順ではダウンロードした上記コンパイラをC:/Devz/ARM/launchpad
直下に解凍するものとします。解凍後launchpadフォルダには
arm-none-eabi,bin,share,libの4つのフォルダがあるのが正解です。
Windows環境下で動くARM用GCCコンパイラとして、Bleeding Edge Toolchain
なんかもあります。いずれもABIはEABIで2015年以降流通している
最新のGCCコンパイラはもはやすべてEABIとなっています。
２．サポートツール群
ねむいさんが公開しているプログラムはコマンドラインビルドを想定しています。
IDE全盛の昨今は古臭いものとなってしまいましたがmakeコマンドでビルドする
というベタベタなクラシックな手法を敢えてとっています。
makeの他にunixコマンドのechoやrmなどを用いているので、これらのunix
ライクなコマンドをネイティブなWindows環境下で動かすことができる
Coreutilsを使用します。
a.Coreutils本体
有志の方々が作成されたCoreutilsの"Binaries"のリンク先をダウンロードし、
2バイト文字やスペースを含まない任意のフォルダに解凍してください。
b.GNUMake3.81
次にGNUMakeを同様にダウンロードしたあと解凍しCoreutilsを解凍した
場所と同じフォルダに置いてください。
c.サポートDLL群
最後にmakeをダウンロードしたページの下にある"dependencies zip file
(中身はlibintl3とlibiconv2)"をダウンロードしGNUMakeと同様の処置を
してください。
今回の手順では上記3点がすべてC:/Devz/Coreutils/bin内にあるものとします。
このbinフォルダ内にmake,echo,rm等のunixライクコマンドとdepedenciesの
libintl3.dll,libiconv2.dllが存在していることを必ず確認して進めてください。
ここで間違ってると下述のPN2からmakeを呼び出す段階でコケて失敗します。
よくやる間違いが、最初のCoreutilsを解凍して出てくるbinフォルダの中に
さらにmakeやdepedenciesの入ったbinフォルダを置いてしまうことです。
C:/Devz↑ねむいさんは上記のディレクトリ構造にしています。
├ARM
|└launchpad
| └bin (←GCCコンパイラのバイナリがある場所)
|└ocd(←openocd.exeのある場所)
└Coreutils
└bin (←make他unixライクコマンド群のある場所)
以下この構成で話を進めます。
ちなみにAVRToolChainでもARMと同じような感じのディレクトリ構成にすると、
同じ感じでコマンドラインビルドが出来ますのでおすすめです。
※以前はWinAVRのutils配下にあった同様のファイル群の使用を推奨していましたが、
WinAVRは開発が停止し数年経ち、フリーで利用できるAVRToolchainに主流が移行
したのでもう一切使用しませんし使ってはいけません。
２.５．sh.exeが見つかりません対策(必ずしも必要ではない)
ネット上で手に入るARMマイコンのGCCプロジェクトの中ではWinAVRのmakefileを
ベースにしたものがいくつか存在し、そこにはshell関数などのbashに依存した記述が
数か所あります。この記述が含まれているとまともにビルドができません。
当ぶろぐで公開してるプロジェクトはmakefileからbash(/bin/sh)に依存して
いる記述はすべて排しておりますが、他の方のプロジェクトをビルドする際の
回避措置として紹介します。
こちらからwin-bash.zipをダウンロードし、解凍して出てきたwin-bash.exeを
Coreutilsのbinフォルダに突っ込んでください。次にmakefile ファイル中に
記載されているはずのSHELLの設定を以下のように書き換えてください。
SHELL = sh
↓
SHELL = win-bash.exe
bash.exeは自身のファイル名によって特殊な動きをするので横着してwin-bash.exeの
方をsh.exeとリネームしてしまうと逆にビルドが通らなくなります。ご注意ください。
３．エディタ
メモ帳でｾｺｾｺ編集してコマンドプロンプトからmakeを実行してもいいですけど
makeを引数つきで呼び出せられるエディタを使えばIDEのように使えます！
ねむいさんのお勧めはProgrammers Notepad2(PN2)です。素のEclipseは(ry
ビルド時の解説はこのPN2を使用して解説します。
注：必ずStable2.3以降を使用してください。
また、日本語入力に対応するために下記の要領で多バイト文字の設定を
”Shift-JIS”に変更しておいてください。
それとPN2のインストール先は無用なトラブルを避けるためスペースや2バイト
文字が混ざるディレクトリは避けてください。
４．デバッガソフトウエア&ハードウエア
ARM用のデバッガはホビーユーザーご用達のGDBサーバであるOpenOCDを
使用します。次回の記事で使用法を紹介します。
また、MCUとJTAG/SWDで通信するハードウエアはFTDIのFT2232系JTAG-I/Fを
使用するのが私の中でスタンダードになっています。
これらに関しても次回詳しく紹介します。
●下準備とビルド
※以後はエディタとしてPN2をインストールして使うことを想定して解説します。
１．ソースコードの展開
今回の凡例として、STM32F4向けの液晶表示プログラムをダウンロードして
ローカルに落としたzipファイルをローカルフォルダに展開します。
このときディレクトリパス(アドレス)にスペースや２バイト文字が絶対に
入らないようにしてください。
２．makeファイルの編集
PN2がインストールされている場合、拡張子pnprojのアイコンをダブルクリック
すると下のような画面になると思います。"makefile"をクリックしてmakefileの
編集画面を出しましょう。
OpenOCDとarm-none-eabiのファイル名は特殊なことをやらない限りは
もう変えないようにしてください。
下画像の要領でそれぞれの環境に合わせてARM用GCCコンパイラ、サポートツール
群、デバッガのディレクトリパスを設定していきます。パスの区切りは"¥"
ではなく"/"を使用してください。
ディレクトリパスはスペースや２バイト文字が絶対に入らないように
してください。大事なことなので二度言います!!
makefileの書き方の作法は此処では解説しないので
各自詳細は調べて下さい。
３．PN2の設定
PN2をインストールしたての人は、makeコマンドをPN2の"TOOL"から
呼び出すことが出来るように以下の要領でmakeコマンドを引数"all"
つきで登録してください。
その後、"build","clean"の引数についても同様に登録してください。
重要：Windows環境変数のPATHは設定する必要はありません！
下手に設定しているとビルドが通らなくなることがあるのでご注意ください。
４．ビルド開始
デフォルトでは評価ボードの設定はSTM32F4Discovery向けになっています。
また、各評価ボード設定時の各ピン配置を知りたい場合は同梱のdoc/Boards.txtを
参照してください。
設定が終わったら"Tool"から"make all"を呼び出しビルド開始です。
ビルドが完了したらメモリ使用量などの情報がコンソール上に現れます。
もしコンパイルエラーなどが発生しビルドが止まったら赤色で強調表示されるので
エラー箇所の特定も簡単です。
上記の液晶表示プログラムはデフォで下記のライブラリ/ドライバを
有効にしてます。
-libjpeg
-libpng
-giflib
-FONTX2ドライバ
-抵抗膜式/容量性タッチパネルドライバ(特定のボード限定)
-HelixMP3デコーダ(特定のボード限定)
-HelixHE-AACデコーダ(特定のボード限定)
数分ほど時間がかかります。Warningが出ますがビルド時の設定喚起の
ためにソースコード中に"#warning"プリプロセッサを敢えて入れてる箇所が
いくつかありますので気にしないでください。
エラーが出てビルドが止まった場合は各種設定を見直しましょう。殆どの場合、
makefile中でPATHの設定を誤っています。
ちなみに"make all"はコンパイルしたオブジェクトを全部消してまっさらに
してからビルド、"make build"はすでにオブジェクト吐かれたソースはスルー
してビルド(ソースコードを一部書き換えてカット&トライしたいときに最適)です。
"make clean"はその名のとおり生成されたelfやhexファイル含めてアセンブラ
リストファイルやオブジェクトをまるっと消去してしまいます。
お次はターゲットCPUへの書き込み&デバッグですが…次回に続きます。
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も外付けしましたよう！！！！！！！！！１！！！
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
この問題、意外と根は深いようですね…
いろいろ試す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の形状・ピン間隔・外観が全く違う別物です！
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でも使えるように更新してくれましたので…
ねむいさん今度こそ本気だす！！
↑やるやる詐欺
免責・連絡先は↑のリンクを
↓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.