Keil MDK-ARM v5.14 Project Generator (1) ― 2015年05月01日 21時22分04秒
MDK5 Software Packs の一部は GCC がサポートされている。
今回はそれをどうやって使うのか調べてみよう。
テストのために使うだけなのでできるだけ小さなパッケージにしたい。
Keil.STM32F2xx_DFP.2.2.0.pack が 67,991,464 と比較的小さいのでこれにしよう。
さっそく Pack Installer から Keil.STM32F2xx_DFP をインストール。
ちなみに Keil.STM32F2xx_DFP.2.0.0.pack から STMicroelectronics STM32CubeF2 Firmware Package がベースになっている。
さてインストールが終わったので New uVision Project で新規プロジェクトを作成する。
デバイスは STM32F205RBTx だ。
OK をクリックすると Run-Time Environment の画面になる。
特に ARMCC と GCC の選択項目はない。
どこで切り替えるのだろう。
CMSIS CORE と Device Startup にチェックして OK 。
startup_stm32f205xx.s と system_stm32f2xx.c がプロジェクトに入っている。
Project の Options for Target を見ると GCC になっている。デフォルトが GCC なのだろうか?
それとも何か設定を見逃したのか?
Source Group 1 にダミーの main を入れてコンパイルしてみる。
いつものエラーだ。
再度コンパイル
Project の Options CC Tab Include Paths に
C:\Keil_v5\ARM\PACK\Keil\STM32F2xx_DFP\2.2.0\Drivers\STM32F2xx_HAL_Driver\Inc を追加。
再再度コンパイル
C:\Keil_v5\ARM\Pack\Keil\STM32F2xx_DFP\2.2.0\Drivers\STM32F2xx_HAL_Driver\Inc に stm32f2xx_hal_conf_template.h があるので名前を変えてそのまま使うことにしよう。
再再再度コンパイル
Project の Options CC Tab Include Paths に
C:\Keil_v5\ARM\PACK\Keil\STM32F2xx_DFP\2.2.0\Drivers\CMSIS\Device\ST\STM32F2xx\Include を追加。
再再再再度コンパイル
Project の Options Linker Tab Linker Script File: に stm32_flash.ld を登録。
再再再再再度コンパイル
Misc controls に -Xlinker --gc-sections を指定する。
再再再再再再度コンパイル
コンパイルが通る。
プロジェクトジェネレータに GCC が復活したのはいいことだが、パスとデファインとリンカースクリプトを何とかしたいところだ。
そして、ARMCC と GCC の切り替え方法はどうなっているんだ?
参照:
MDK5 Software Packs
環境:Keil MDK-ARM V5.14
+ GCC ARM/embedded-4_9-branch revision 218278
+ Keil.STM32F2xx_DFP.2.2.0.pack
今回はそれをどうやって使うのか調べてみよう。
テストのために使うだけなのでできるだけ小さなパッケージにしたい。
Keil.STM32F2xx_DFP.2.2.0.pack が 67,991,464 と比較的小さいのでこれにしよう。
さっそく Pack Installer から Keil.STM32F2xx_DFP をインストール。
ちなみに Keil.STM32F2xx_DFP.2.0.0.pack から STMicroelectronics STM32CubeF2 Firmware Package がベースになっている。
さてインストールが終わったので New uVision Project で新規プロジェクトを作成する。
デバイスは STM32F205RBTx だ。
OK をクリックすると Run-Time Environment の画面になる。
特に ARMCC と GCC の選択項目はない。
どこで切り替えるのだろう。
CMSIS CORE と Device Startup にチェックして OK 。
startup_stm32f205xx.s と system_stm32f2xx.c がプロジェクトに入っている。
Project の Options for Target を見ると GCC になっている。デフォルトが GCC なのだろうか?
それとも何か設定を見逃したのか?
Source Group 1 にダミーの main を入れてコンパイルしてみる。
いつものエラーだ。
RTE/Device/STM32F205RBTx/system_stm32f2xx.c(1): error: target CPU does not support ARM modeProject の Options CC Tab Compile Thumb Code にチェックを入れる。
再度コンパイル
RTE/Device/STM32F205RBTx/system_stm32f2xx.c(65): error: fatal error: stm32f2xx_hal.h: No such file or directoryどうやら Path が通っていないらしい。
Project の Options CC Tab Include Paths に
C:\Keil_v5\ARM\PACK\Keil\STM32F2xx_DFP\2.2.0\Drivers\STM32F2xx_HAL_Driver\Inc を追加。
再再度コンパイル
C:/Keil_v5/ARM/PACK/Keil/STM32F2xx_DFP/2.2.0/Drivers/STM32F2xx_HAL_Driver/Inc/stm32f2xx_hal.h:48:32: fatal error: stm32f2xx_hal_conf.h: No such file or directorystm32f2xx_hal_conf.h が無い。これは自分で用意しなければならないらしい。
C:\Keil_v5\ARM\Pack\Keil\STM32F2xx_DFP\2.2.0\Drivers\STM32F2xx_HAL_Driver\Inc に stm32f2xx_hal_conf_template.h があるので名前を変えてそのまま使うことにしよう。
再再再度コンパイル
C:/Keil_v5/ARM/PACK/Keil/STM32F2xx_DFP/2.2.0/Drivers/STM32F2xx_HAL_Driver/Inc/stm32f2xx_hal_def.h:48:23: fatal error: stm32f2xx.h: No such file or directoryPath が通っていない。
Project の Options CC Tab Include Paths に
C:\Keil_v5\ARM\PACK\Keil\STM32F2xx_DFP\2.2.0\Drivers\CMSIS\Device\ST\STM32F2xx\Include を追加。
再再再再度コンパイル
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000これはリンカースクリプトが無いときのエラーだ。
Project の Options Linker Tab Linker Script File: に stm32_flash.ld を登録。
再再再再再度コンパイル
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-init.o): In function `__libc_init_array': init.c:(.text.__libc_init_array+0x20): undefined reference to `_init'Project の Options Linker Tab [Do not use Standard System Startup Files] のチェックをはずし
Misc controls に -Xlinker --gc-sections を指定する。
再再再再再再度コンパイル
コンパイルが通る。
プロジェクトジェネレータに GCC が復活したのはいいことだが、パスとデファインとリンカースクリプトを何とかしたいところだ。
そして、ARMCC と GCC の切り替え方法はどうなっているんだ?
参照:
MDK5 Software Packs
環境:Keil MDK-ARM V5.14
+ GCC ARM/embedded-4_9-branch revision 218278
+ Keil.STM32F2xx_DFP.2.2.0.pack
Raisonance Ride7 & ARM Tools (20) ― 2015年04月14日 21時09分42秒
RKit-ARM が STM32F7 をサポートしたので私の環境でも動作確認をしてみる。
RKit-ARM_1.58.15.0093 がサポートしているのは以下の MPU 。
STM32F746xE
STM32F746xG
STM32F756xE
STM32F756xG
スクリプトを書き換え HFARM.XML と registry と sim に STM32F746xE を追加する。
スタートアップは startup_stm32f7xx.s の .cpu を cortex-m7 に変更するだけにしておこう。
さっそく New Project で STM32F746xE のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
こういう場合うまく行っているように見えてけっこういろいろ問題があったりするものだ。
まず ApplicationDirectory の中を見ていこう。
リンカースクリプトは
sections_FLASH.ld
STM32F746_512K_192K_DEF.ld
STM32F746_512K_192K_FLASH.ld
STM32F74x_COMMON.ld
ができている。
中身も問題ないようだ。
次に Application0.elf.ld (ApplicationName.elf.ld)を見るとライブラリが
"smallprintf_thumb.a"
"STM32x_io_putchar_thumb.a"
になっている。ここは
"smallprintf_thumb_fpu.a"
"STM32x_io_putchar_thumb_fpu.a"
でなければならないはずだ。
まだスクリプトにおかしな所があるようだ。
GNUtools.js を調べてみると (corename=="Cortex-M4+FPU") はあるのに (corename=="Cortex-M7+FPU") が無い。
(corename=="Cortex-M7+FPU") を追加する。
ところで、ライブラリは Cortex-M4 で作ってあるが Cortex-M7 と共通と見てよいのだろうか?
そうでなければ Cortex-M7 用にライブラリの種類を増やさなければならない。
それ以前に、そもそも io_putchar と small_printf は STM32F7xx で動くのだろうか?
振り返ってみれば Raisonance は何かと抜けていることが多い。
このコアチェックの部分では corename と core をチェックしているが registry には core の項目が無いので有効なのは corename だけだ。
こういったちぐはぐな所がいたるところにある。
だいたい デバイスに関係する物が HFARM.XML 、sim file 、registry と多すぎるのも問題だ。
今回のテストでは Cortex-M7 の設定でコンパイルが通ったと言うことだけでそれ以外の部分は見直しが必要だろう。
いや、ローカルライブラリを使わない設定ならば問題ないのかもしれない。
この際ついでなので STM32L476xC も試してみよう。
同様に関係する部分のスクリプトを書き換え HFARM.XML と registry と sim に STM32L476xC を追加する。
スタートアップは startup_stm32f4xx.s をリネームして startup_stm32l4xx.s にし .cpu を cortex-m4 に変更する。(この際 startup_stm32f4xx.s も cortex-m4 に修正しておこう)
STM32L4x_COMMON.ld を作成して C:\Program Files\Raisonance\Ride\lib\ARM に入れる。
確認のため New Project で STM32L476xC のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
というわけで STM32 の場合 Raisonance が力を入れていることもあってデバイスの追加も比較的簡単だ。
RKit-ARM_1.58.15.0093 がサポートしているのは以下の MPU 。
STM32F746xE
STM32F746xG
STM32F756xE
STM32F756xG
スクリプトを書き換え HFARM.XML と registry と sim に STM32F746xE を追加する。
スタートアップは startup_stm32f7xx.s の .cpu を cortex-m7 に変更するだけにしておこう。
さっそく New Project で STM32F746xE のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
こういう場合うまく行っているように見えてけっこういろいろ問題があったりするものだ。
まず ApplicationDirectory の中を見ていこう。
リンカースクリプトは
sections_FLASH.ld
STM32F746_512K_192K_DEF.ld
STM32F746_512K_192K_FLASH.ld
STM32F74x_COMMON.ld
ができている。
中身も問題ないようだ。
次に Application0.elf.ld (ApplicationName.elf.ld)を見るとライブラリが
"smallprintf_thumb.a"
"STM32x_io_putchar_thumb.a"
になっている。ここは
"smallprintf_thumb_fpu.a"
"STM32x_io_putchar_thumb_fpu.a"
でなければならないはずだ。
まだスクリプトにおかしな所があるようだ。
GNUtools.js を調べてみると (corename=="Cortex-M4+FPU") はあるのに (corename=="Cortex-M7+FPU") が無い。
(corename=="Cortex-M7+FPU") を追加する。
ところで、ライブラリは Cortex-M4 で作ってあるが Cortex-M7 と共通と見てよいのだろうか?
そうでなければ Cortex-M7 用にライブラリの種類を増やさなければならない。
それ以前に、そもそも io_putchar と small_printf は STM32F7xx で動くのだろうか?
振り返ってみれば Raisonance は何かと抜けていることが多い。
このコアチェックの部分では corename と core をチェックしているが registry には core の項目が無いので有効なのは corename だけだ。
こういったちぐはぐな所がいたるところにある。
だいたい デバイスに関係する物が HFARM.XML 、sim file 、registry と多すぎるのも問題だ。
今回のテストでは Cortex-M7 の設定でコンパイルが通ったと言うことだけでそれ以外の部分は見直しが必要だろう。
いや、ローカルライブラリを使わない設定ならば問題ないのかもしれない。
この際ついでなので STM32L476xC も試してみよう。
同様に関係する部分のスクリプトを書き換え HFARM.XML と registry と sim に STM32L476xC を追加する。
スタートアップは startup_stm32f4xx.s をリネームして startup_stm32l4xx.s にし .cpu を cortex-m4 に変更する。(この際 startup_stm32f4xx.s も cortex-m4 に修正しておこう)
STM32L4x_COMMON.ld を作成して C:\Program Files\Raisonance\Ride\lib\ARM に入れる。
確認のため New Project で STM32L476xC のプロジェクトを作り、ダミーの main を入れコンパイルしてみる。
問題なくコンパイルが通る。
というわけで STM32 の場合 Raisonance が力を入れていることもあってデバイスの追加も比較的簡単だ。
GNU Tools for ARM Embedded Processors ― 2015年04月12日 12時22分06秒
さあ newlib-nano を使ってみよう。
使うために printf と syscall ぐらい入れておこう。
テストする環境は
さて、この後どうすればよいの?
とりあえず
Raisonance\Ride\arm-gcc\share\doc\gcc-arm-none-eabi\readme.txt を読んでみる。
どうやらリンク時に
--specs=nano.specs
を付ければよいらしい。
やってみる。
hex file で 18,092 bytes だった。
もともとが newlib で 103,846 bytes だったからかなり小さくなった。
この状態では Integer only なので %f を使うためにはコマンドオプション -u _printf_float を追加する。(scanf の場合は -u _scanf_float)
hex file で 61,038 bytes になった。
ちなみに、Optimization を Level2(Size) にすると
18,047 ( --specs=nano.specs)
60,993 ( --specs=nano.specs -u _printf_float)
103,817 ()
サイズは Optimization default とたいして変わらない。
結果:
以前テストした CooCox や LPCXpresso の printf に比べても nano はすこし大きいことが分かる。
しかし、手間を考えると便利かもしれない。
使うために printf と syscall ぐらい入れておこう。
テストする環境は
Keil MDK-ARM V4.53 ARM GCC/embedded 4.9.3 revision 218278 Startup は Atollic の startup_LPC11xx.s Linker script は RAISONANCE Ride7 を使い LPC1114FHN33 で 自動生成したもの syscall と SystemInit はダミー Optimization は default
さて、この後どうすればよいの?
とりあえず
Raisonance\Ride\arm-gcc\share\doc\gcc-arm-none-eabi\readme.txt を読んでみる。
どうやらリンク時に
--specs=nano.specs
を付ければよいらしい。
やってみる。
hex file で 18,092 bytes だった。
もともとが newlib で 103,846 bytes だったからかなり小さくなった。
この状態では Integer only なので %f を使うためにはコマンドオプション -u _printf_float を追加する。(scanf の場合は -u _scanf_float)
hex file で 61,038 bytes になった。
ちなみに、Optimization を Level2(Size) にすると
18,047 ( --specs=nano.specs)
60,993 ( --specs=nano.specs -u _printf_float)
103,817 ()
サイズは Optimization default とたいして変わらない。
結果:
以前テストした CooCox や LPCXpresso の printf に比べても nano はすこし大きいことが分かる。
しかし、手間を考えると便利かもしれない。
Raisonance Ride7 & ARM Tools (19) ― 2015年04月10日 22時46分04秒
Raisonance の tool がバージョンアップしていた。
RKit-ARM 1.58.15.0093
Ride 7.54.15.0083
release note を見てみると STM32F7 がサポートされているのと GCC が 4.9.3 になっている。
STMicroelectronics の STM32F7 サポートは Raisonance が最初かもしれない。
面白そうなのでこのバージョンもインストールしてみる。
少し中をのぞいてみよう。
今回からサポートされた STM32F7 の startup を見る。
startup_stm32f7xx.s と startup_stm32f4xx.s が同じ内容だ。
後で修正するつもりなのか?それとも同じで正しいのか?
さて、もう一度 release note を見てみる。
コンパイラは
4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
ということなのでいつからか分からないが Sourcery g++ から Launchpad に変わったようだ。
そして lib_nano が使える。
nano と言うぐらいだから 小さくなっているのだろう。
これは試してみたい。
参照:
Raisonance
RKit-ARM 1.58.15.0093
Ride 7.54.15.0083
release note を見てみると STM32F7 がサポートされているのと GCC が 4.9.3 になっている。
STMicroelectronics の STM32F7 サポートは Raisonance が最初かもしれない。
面白そうなのでこのバージョンもインストールしてみる。
少し中をのぞいてみよう。
今回からサポートされた STM32F7 の startup を見る。
startup_stm32f7xx.s と startup_stm32f4xx.s が同じ内容だ。
後で修正するつもりなのか?それとも同じで正しいのか?
さて、もう一度 release note を見てみる。
コンパイラは
4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
ということなのでいつからか分からないが Sourcery g++ から Launchpad に変わったようだ。
そして lib_nano が使える。
nano と言うぐらいだから 小さくなっているのだろう。
これは試してみたい。
参照:
Raisonance
Raisonance Ride7 & ARM Tools (18) ― 2015年03月29日 14時06分58秒
Raisonance Ride7 & RKit-ARM は free でなくなってから Activate しなければ7日しか使うことができなくなった。
ほんとにそうなんだろうかと自分で試してみようと思った。
インストールしたバージョンは忘れたが、インストール後動作確認してその後日付を一ヶ月進め Ride7 を起動した。
”Activate しなければ使えないよ”というメッセージが出て使うことができなかった。
おお!やっぱり使えない。
さて、元の日付に戻して残り7日間いろいろ試してみようと思った。
しかし、元の日付に戻したのに使えなくなっていた。
結局使えたのはインストール後1時間程度だった。
この時、要らん事しなければよかったと後悔した。
それから何年たったろう?今ではその7日間が1ヶ月になったようだ。
でも私の環境では使えない。1度期限が過ぎてしまうとその設定がどこかに残っているのだろう。
さて、問題は使用期限ではなくて新しい RKit-ARM 1.56.15.0007 の話だ。
動かないけど何かおもしろい物はないかと、時々インストールしてみる。
今回、インストールしてみて気になる物があった。
Ride\lib\ARM\ の中にある
STM32Fxx_OptionBytes.c というファイルだ。
今までなかったのに...
そして、リンカースクリプトにも
これを調べてみよう。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
ほんとにそうなんだろうかと自分で試してみようと思った。
インストールしたバージョンは忘れたが、インストール後動作確認してその後日付を一ヶ月進め Ride7 を起動した。
”Activate しなければ使えないよ”というメッセージが出て使うことができなかった。
おお!やっぱり使えない。
さて、元の日付に戻して残り7日間いろいろ試してみようと思った。
しかし、元の日付に戻したのに使えなくなっていた。
結局使えたのはインストール後1時間程度だった。
この時、要らん事しなければよかったと後悔した。
それから何年たったろう?今ではその7日間が1ヶ月になったようだ。
でも私の環境では使えない。1度期限が過ぎてしまうとその設定がどこかに残っているのだろう。
さて、問題は使用期限ではなくて新しい RKit-ARM 1.56.15.0007 の話だ。
動かないけど何かおもしろい物はないかと、時々インストールしてみる。
今回、インストールしてみて気になる物があった。
Ride\lib\ARM\ の中にある
STM32Fxx_OptionBytes.c というファイルだ。
今までなかったのに...
そして、リンカースクリプトにも
MEMORY { RAM (xrw): ORIGIN = 0x20000000, LENGTH = 0x5000 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 0x20000 STARTFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0 CRPPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0 FLASHPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0 ENDFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0 FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0x0 CONFIG (r) : ORIGIN = 0x1FFFF800, LENGTH = 0x10 CONFIG2 (r) : ORIGIN = 0x00000000, LENGTH = 0x0 EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0 EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0 }CONFIG という項目が追加になっている。
これを調べてみよう。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
Ride7 に Keil *.uvproj project を読みむ (2) ― 2015年03月24日 23時44分47秒
MDK-ARM プロジェクト内の一部の項目が変換できなかった件
*.uvproj の内部が ARM-ADS と ARM-GNU で Tag の名称が異なっていたためだった。
続いてデバイス名が変換されない件
テストしてみると stm32 系はほとんど変換できるようだ。
変換できないのは NXP の LPC 系が多いような気がする。
確認のためデバイス名を MDK-ARM と同じにしてみた。(LPC810M021) ---> 変換できる。(LPC810M021)
MDK-ARM の デバイス名を LPC81 にしてみる。(LPC81) ---> 変換できる?(LPC812)
MDK-ARM の デバイス名を LPC にしてみる。(LPC) ---> 変換できない。(LPC2478)
MDK-ARM の デバイス名を L にしてみる。(L) ---> 変換できない。(LPC2478)
MDK-ARM の デバイス名を LPC810M0210 にしてみる。(LPC810M0210) ---> 変換できない。(STR7-TEST)
見つからない場合は、全て (STR7-TEST) にしてしまう。
どうやら検索とパターンマッチングのアルゴリズムが関係しているようだ。
頻繁に使うデバイスは MDK-ARM の デバイス名と同じにしておけばよいということにしよう。
そうでなければそのつど手動で設定することにする。
この件はこのくらいでいいだろう。
今気になっているのは Project Settings の Assembler に Defines 項が無いこととか、
Startup が $(RkitLib)\ARM\crt0_*.o or startup_*.o をリンクするのがデフォルトになっていることだ。
このプロジェクト内にソースが無いというのは結構不便だ。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
*.uvproj の内部が ARM-ADS と ARM-GNU で Tag の名称が異なっていたためだった。
TargetArmAds Cads Aads LDads TargetArm Carm Aarm LDarmもう...めんどくさい。 しょうがないので ARM-GNU の Tag にも対応するように変更。
続いてデバイス名が変換されない件
テストしてみると stm32 系はほとんど変換できるようだ。
変換できないのは NXP の LPC 系が多いような気がする。
確認のためデバイス名を MDK-ARM と同じにしてみた。(LPC810M021) ---> 変換できる。(LPC810M021)
MDK-ARM の デバイス名を LPC81 にしてみる。(LPC81) ---> 変換できる?(LPC812)
MDK-ARM の デバイス名を LPC にしてみる。(LPC) ---> 変換できない。(LPC2478)
MDK-ARM の デバイス名を L にしてみる。(L) ---> 変換できない。(LPC2478)
MDK-ARM の デバイス名を LPC810M0210 にしてみる。(LPC810M0210) ---> 変換できない。(STR7-TEST)
見つからない場合は、全て (STR7-TEST) にしてしまう。
どうやら検索とパターンマッチングのアルゴリズムが関係しているようだ。
頻繁に使うデバイスは MDK-ARM の デバイス名と同じにしておけばよいということにしよう。
そうでなければそのつど手動で設定することにする。
この件はこのくらいでいいだろう。
今気になっているのは Project Settings の Assembler に Defines 項が無いこととか、
Startup が $(RkitLib)\ARM\crt0_*.o or startup_*.o をリンクするのがデフォルトになっていることだ。
このプロジェクト内にソースが無いというのは結構不便だ。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
Ride7 に Keil *.uvproj project を読みむ (1) ― 2015年03月22日 17時26分51秒
先日の Ride7 に MDK-ARM の *.uvproj project を読み込む件をやってみた。
最新のスクリプトを現在使用中のスクリプトと置き換える。(r627)
さて、stm32cubel0 v1.1.0 で試してみよう。
手順は簡単で Ride7 を立ち上げ、Open Project でプロジェクトを開く。
ただし、そのままでは Ride7 のプロジェクトしか見えないので '*' を入れて全てのファイルが見えるようにする。
拡張子 *.uvproj のファイルを読み込む。
これだけでよい。読み込むとプロジェクトで使用するファイル、デバイス情報などが表示される。
そのプロジェクトを読み込んだ状態が右上のキャプチャー画面だ。
これは、「すばらしい!!」の一言だ。
今まで MDK-ARM のプロジェクトを Ride7 の環境に持ってくる場合、ファイルやパスを一つ一つ
集めて回らなければならなかった。このスクリプトがあれば一発だ。
気をよくして次に私が作成した MDK-ARM のプロジェクトも変換してみた。
え!!
変換できない。
ちょっとがっかり。でも、スクリプトなので変更できるかもしれない。
見てみると、ARM-ADS と MSC-51 だけしか変換対象になっていない。
ARM-GNU の環境が入っていないのだ。一行追加。
確かにね。
私だって自分の想定した手順に従って操作しなければ動かないプログラムしか書けないから...
再度立ち上げてプロジェクト読み込み。
うまく読み込めた。
「うまく読み込めた」と思っていたのに...
ARM-GNU の環境はうまく読み込めていない部分があった。
defines とか path とか デバイス名などである。
そのうち何とかしよう。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
最新のスクリプトを現在使用中のスクリプトと置き換える。(r627)
さて、stm32cubel0 v1.1.0 で試してみよう。
手順は簡単で Ride7 を立ち上げ、Open Project でプロジェクトを開く。
ただし、そのままでは Ride7 のプロジェクトしか見えないので '*' を入れて全てのファイルが見えるようにする。
拡張子 *.uvproj のファイルを読み込む。
これだけでよい。読み込むとプロジェクトで使用するファイル、デバイス情報などが表示される。
そのプロジェクトを読み込んだ状態が右上のキャプチャー画面だ。
これは、「すばらしい!!」の一言だ。
今まで MDK-ARM のプロジェクトを Ride7 の環境に持ってくる場合、ファイルやパスを一つ一つ
集めて回らなければならなかった。このスクリプトがあれば一発だ。
気をよくして次に私が作成した MDK-ARM のプロジェクトも変換してみた。
え!!
変換できない。
ちょっとがっかり。でも、スクリプトなので変更できるかもしれない。
見てみると、ARM-ADS と MSC-51 だけしか変換対象になっていない。
ARM-GNU の環境が入っていないのだ。一行追加。
確かにね。
私だって自分の想定した手順に従って操作しなければ動かないプログラムしか書けないから...
再度立ち上げてプロジェクト読み込み。
うまく読み込めた。
「うまく読み込めた」と思っていたのに...
ARM-GNU の環境はうまく読み込めていない部分があった。
defines とか path とか デバイス名などである。
そのうち何とかしよう。
環境: Ride7 version 7.30.10.0169
+ RKit-ARM version 1.30.10.0356
md5 ― 2013年08月20日 22時57分46秒
最近ダウンロードがうまく行かないことが多くなってきた。
....というわけで、ダウンロードした物の md5 をとることにする。
見つけたのは
check MD5 message digest
と
md5sums-1.2
使い方もほとんど同じで、ファイル名を与えるだけ。
どちらを選択してもよいだろう。
スクリーンショットは md5sums-1.2。
bat ファイルを作って SendTo で使えるようにした。
md5.bat
md5sums.bat
....というわけで、ダウンロードした物の md5 をとることにする。
見つけたのは
check MD5 message digest
と
md5sums-1.2
使い方もほとんど同じで、ファイル名を与えるだけ。
どちらを選択してもよいだろう。
スクリーンショットは md5sums-1.2。
bat ファイルを作って SendTo で使えるようにした。
md5.bat
C:\tools\MD5\md5.exe -n -l %1 %2 %3 %4 %5 %6 %7 %8 %9 pause
md5sums.bat
C:\tools\MD5\md5sums.exe -p %1 %2 %3 %4 %5 %6 %7 %8 %9
KPIT GNU Tools (19) GNUSH v1202 Windows Tool Chain (ELF) と avast (2) ― 2012年07月22日 20時33分06秒
某bbsに「自動サンドボックスを無効にするとよい」と書いてあったので試してみる。
おお!
あの煩わしい画面が出てこない。
とは言ってもOFFにしてしまうと少々不安だ。
というわけで、「自動サンドボックスから除外されるファイル」というのを設定してみた。
コンパイルリンク・ライブラリ作成は問題ないようだ。しかし、新規プロジェクトを作った場合、一番最初に sh-elf-g++.exe と cc1plus.exe はプロジェクト中のファイルの数だけ出現する。ほかの実行ファイルとプロセスの起動方法が異なるのかもしれない。
そして、[実行を続ける]を押した回数だけ「自動サンドボックスから除外されるファイル」の数が増えていく。つまり、実行を続けるをクリックすると自動的に「自動サンドボックスから除外されるファイル」に登録されて次回から検査対象外になる仕組みなのだろう。
しかし、この機能がうまく働いてないようだ。
というわけで根本的な解決には至っていない。
追加の保護 自動サンドボックス 設定 [自動サンドボックスを有効にする]のチェックを外す
おお!
あの煩わしい画面が出てこない。
とは言ってもOFFにしてしまうと少々不安だ。
というわけで、「自動サンドボックスから除外されるファイル」というのを設定してみた。
コンパイルリンク・ライブラリ作成は問題ないようだ。しかし、新規プロジェクトを作った場合、一番最初に sh-elf-g++.exe と cc1plus.exe はプロジェクト中のファイルの数だけ出現する。ほかの実行ファイルとプロセスの起動方法が異なるのかもしれない。
そして、[実行を続ける]を押した回数だけ「自動サンドボックスから除外されるファイル」の数が増えていく。つまり、実行を続けるをクリックすると自動的に「自動サンドボックスから除外されるファイル」に登録されて次回から検査対象外になる仕組みなのだろう。
しかし、この機能がうまく働いてないようだ。
というわけで根本的な解決には至っていない。
最近のコメント