【Cortex-】 やっぱARMっしょ part10 【AxRxMx】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ARMデバイス、ARMボードについて組込系ARM全般のスレ
時代は「やっぱARMっしょ」
省電力ニーズの高まりを背景に海外チップベンダーはもとより国内勢も参戦
ホビーとしてのマイコンからスマートデバイス用プロセッサまで
ARMコアを持つチップやボードのラインナップは今まさに百花繚乱
【前スレ】
【Cortex-】 やっぱARMっしょ 9 【AxRxMx】
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/ http://ednjapan.com/edn/articles/1601/26/news018.html
こういうQを想定すること自体バカだろ。
しかも、何をわけのわからんAnswerを書いてるんだ。
どれをMPUというかMCUというかは、CPUも含めて、
"メーカーのネーミングによって決まる"だ。
んで、なんでノイマン型とハーバード型を対比してるんだ?
http://image.itmedia.co.jp/l/im/edn/articles/1601/26/l_tt160126STMCU002.jpg
ハーバードはノイマン型の一種ってことすらわかってない。 >>100
CPU、MPU、MCU・・・全部別ものだと思ってる初心者向きなんだから流せよw マイクロコントローラ って名称は主力のメインプロセッサーではなく周辺機器向けの汎用コントローラとして企画されたような
面積が小さくピン数が少なく廉価なワンチップ・マイコンでしょ。
IBM PCキーボードの内蔵コントローラとして使われたi8048/8049とか、マウスみたいのに入ってるPICとか
あとEIDE内蔵ハードディスク・ケースのSCSIインタフェースに使うH8とか >>100
バスの話だから
まぁ紛らわしいからプリンストン・ハーバードって言い方もあるけどな 興味深い情報を発見。
http://keikato.cocolog-nifty.com/blog/2016/02/ascii-c323.html
http://keikato.cocolog-nifty.com/blog/2016/02/usbaki-80basic-.html
> Z80換算でIchigoJam 1.1.1の性能は6MHz、
> ORANGE pico 0.7以降は120MHzと言えそうだ。
IchigoJam は LPC1114FN28 だから ARM Cortex-M0 の 48MHz、
ORANGE pico は PIC32MX だから MIPS32 M4K 40MHz
プロセッサの演算能力に大きな差は無いはずなので、
BASICインタプリタの完成度が激しく違うと思われる。
もっとも IchigoJam の LPC1114FN28 はRAMが4KBしかないので、
高速化したくても出来ないのかもしれないが。
そういえば、以前にも IchigoJam は遅いという話は出ていた。
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/808- >もっとも IchigoJam の LPC1114FN28 はRAMが4KBしかないので、
>高速化したくても出来ないのかもしれないが。
馬鹿ですか?? BASICマイコンでユーザープログラム領域が4KBというのは非常に狭い。
実際にはBASICインタプリタのワーク領域にも使われるので更に狭い。
だだでさえ少ない領域を高速化の為に費やして
ユーザー領域が更に狭くなってしまうと本末転倒なので
RAM消費を増やさない改良方法があるか
という事だろう。 M0は命令バスとデータバスが分離していないから元々遅い
しかも20MHz以上ではフラッシュ読み出しにウエイトが入る無策設計
RAM容量以前の問題 確か、palo alto tiny basic移植の場合
16MHzのAVRでもZ80換算40MHz相当ぐらいは出るんだがなぁ… >>105
「興味深い記事を発見」ってか、おまえがブログ主でしょ
猫うごくgifうざったいからやめてくれ。ま、もうadblockに放り込んだからどうでもいいが
ベンチ結果そのものよりも未だにaki-80使ってる奴がいたことにびっくりだよ。しかもtiny basicでww >>108
Cortex-M0に関するARM社からの発表値は 0.9 DMIPS/MHz.
PIC32MXについては 1.65 DMIPS/MHz
フラッシュ読み出しのウエイトの影響が追加されると
同一クロックで2、3倍ほどの差はあり得る。
だけど、BASICのベンチマーク結果では20倍もの差があるので、
どう考えてもインタプリタの出来が主要因なのでは? 秋月から同じ値段でSTM32 Nucleo Boardが出てきたけど
どれを買っとけば無難かな。。 ちょっとわろたw
ttps://www.google.co.jp/search?num=100&q="keikato.cocolog-nifty.com"+site%3A2ch.net >>107
むか〜し、むかし、ROM無しの4kB RAMでBasicインタプリタを走らせていた時代がありまして…
…めでたし、めでたしw >>112
DMA とSPI でビデオ出力って技が使えないからCPUは常に忙しい https://twitter.com/yo_namikaze/status/640892899018735616
> FOR 3000回ループ
> Cortex-M0 48MHz IchigoJam BASIC 1.0.1→7.6秒
> Z80 4MHz SB-5520(MZ-80B実機)→約2秒
昔の8bitマイコンより遅いってのはかなり遅いね。 RAMが足りないから毎回テキストから数値や命令に解読してんのかな basicによるけど、毎回テキストでしょ
この手のbasicはすっごく単純なフローチャートで表現できる実装だけのが多いよ
最適化とか高速化とは無関係な世界
ram消費を抑えるというよりはむしろromを抑えるのに重点置いてるんじゃないってくらい >>121
どこかのスレに書いてあったが
ビデオアウトやらペリフェラルもM0でやってるので遅くなるのでわと たしか、video処理を停止する命令があるはずだから、一度比較したいな http://www.openspc2.org/reibun/IchigoJam/code/bechmark/0003/index.html
表示やめると3倍くらい速くなるらしいけどそれでもまだ昔の8bitマイコンより
遅いくらいだね。
やっぱインタプリタの実装がクソなんだろうなあ。オープンソースではない
から誰かが改良してくれるわけもないし。 何をやりたいのかさっぱりだけど実行速度あげたいならC使えとw
純粋にハードの速度比較したいならアセンブラ(C含む)でやったら?
basic比べたいなら、アセンブラのループとbasicのループでみたら? > 実行速度あげたいならC使えとw
> 純粋にハードの速度比較したいならアセンブラ(C含む)でやったら?
> basic比べたいなら、アセンブラのループとbasicのループでみたら?
ダッセエ実装してんなあという話に対して何言ってんだかw それだったらアセンブラとbasicのループ速度比とかを見るべきでしょ
異機種間でのbasic速度だけを見てるから>>122みたいな影響を排除できてないわけで > それだったらアセンブラとbasicのループ速度比とかを見るべきでしょ
なんで?? >>127
> 異機種間でのbasic速度だけを見てるから>>122みたいな影響を排除できてないわけで
画面は消して、あとキーボードだろ? どんだけ影響がある可能性があると思ってる?
4MHz の Z80 と較べて最大 50MHz で動作する LPC1114 ってクロック速度だけでも
10倍以上、1命令辺りの実行に要するサイクル数や個々の命令の機能を考えると
処理能力的には 2桁程度は違う計算になるので、
> FOR 3000回ループ
> Cortex-M0 48MHz IchigoJam BASIC 1.0.1→7.6秒
> Z80 4MHz SB-5520(MZ-80B実機)→約2秒
画面消して 3倍速くなったとしてもどう考えても遅杉だろ。 >>130
インタプリタの実装ではなく割り込み処理の実装がクソ。 >>131
PS/2キーボードのシリアル通信なんて〜10kbpsとかそんなもんだから、
NTSCの水平同期 2回に1回のタイミングで割り込み処理を行うとか
そんなもんだろう。負荷なんて多寡が知れてる。 > PS/2キーボードのシリアル通信なんて〜10kbpsとかそんなもんだから、
Wkipedia みたら
https://en.wikipedia.org/wiki/PS/2_port
> Serial data at 10 to 16 kHz
とあったんで訂正しておく。何れにしろ負荷としては大したもんではない。 >>133
I/Fの通信速度からは割り込み処理がクソかどうかまでは判別できない。
問題の起きない範囲でベクターテーブルを潰して調べるのがいい。
同様にインタプリタがクソかどうか判別するには >>127 をした方がいい。 「割り込み処理の実装がクソ」という説にはなんら根拠がないので考察に値しない。 >>132
大抵、DMAで、RAM から画像データ転送してるから、アクセスがぶつかると、処理がまたされる。 >>136
画面消して処理が3倍くらい速くなることは既出なんだけど何言ってんの? 逆汗してみた。
インタプリタの文字判別で1文字拾う毎にスペース除外とかしてて遅いね。
中間コードに変換するくらいの事でもすればいいのに。 ARMv8-Aの32bitCPUだそうだ
ARM Cortex-A32 To Succeed Cortex-A5 And Cortex-A7 In 32-Bit Wearables, IoT Devices
http://www.tomshardware.com/news/cortex-a32-32-bit-wearables-iot,31259.html https://twitter.com/u_akihiro/status/701218592814006272
> Cortex-M0 で int8_t data = 0xff; if(data == 0xff) {呼ばれるべき処理;}
> が呼ばれない。アセンブラで見るとdataはintの0xffffffffと比較されて
> 不一致と。
↑のおかしいところを正しく指摘できればC言語初級。 > アセンブラで見るとdataはintの0xffffffffと比較されて
> 不一致と。
dataの値はintの値との比較にあたってintへ昇格され0xffffffffと評価され
intの値0xffと比較されて不一致、が正解。
アセンブラで見たというのも疑わしいな。 比較するときはマスクするのが常識だし、ベーシック()なんて使わないのが常識ってこと 元のプログラムが何したいかわからんので正解とは限らんが、
小さい符号付整数として使うために data の型に int8_t を
選んでるのだとしたら直値で 0xff なんて書かないで
if(data == -1) {呼ばれるべき処理;}
とするべきだろうし、0xff に何か特別の意味があるなら
それに名前を付けて int8_t なんて使わずに
const uint8_t Nanka = 0xff;
uint8_t data = Nanka;
if(data == Nanka) {呼ばれるべき処理;}
とかするだろうし、記憶領域をケチりたいとかの事情がなければ
typedef enum {Nanka = 0xff, Kanka} NankaType;
NankaType data = Nanka;
if(data == Nanka) {呼ばれるべき処理;}
とかやったほうがより安全。 >比較するときはマスクするのが常識だし、
こんな常識は聞いたことないし、
>ベーシック()なんて使わないのが常識ってこと
常識以前に何言いたいのかわからん。 そういう符号拡張の罠があるからunsignedばかり使うようになったとさ そのひと言ってることがふわふわだから余りさわらないほうがいいかも ハードウェアはゴミといっている人間がゴミなので笑えない そりゃ、ハードウェアは最終的には処分場行きなんだけどさ。 この人、ブッチブチといつも文句ばっかり呟いてるよね。
日本がダメだとかハードウェアはゴミだとか、資本主義が労働がどうとか。
他人の作ったIoTデバイスがダメで、他人の作ったBLEがダメなんだろ。
お前が作ったハードウェア以外はゴミなんだろ。
特に小さな会社がネットにつながるハードウェアを作るとさんざん扱き下ろす。
お前はいったい、何円の資本集めてどんだけでかいことやったんだ。
まさに事業に失敗した中年。哀れに思えてくる・・・ CooCoxの中の人が息してないっぽい
ttp://www.coocox.org/download/Tools/ nucleo F446 + eclipse で環境構築中のARM初心者の者です。
新規プロジェクトLチカサンプルプログラムのPLL設定のところ
stm32f4xx_hal_rc_ex.c ファイルの1710行と1976行でassertに引っかかっちゃうんですよ。
ちなみに基板のバージョンはC3、デバッガの8MHzをバイパス→PLL設定して入力してます
ちなみにこの2行をコメント化すると、デバッグコンソールに168MHzと表示されて動き出すけど
なんか微妙に時間が合っていない(じょじょに時計の秒針とズレてく)。
どこかで基本的なミスをしてるのでしょうね、多分。
ググッても情報が少なくて困ってます。 英語が苦手で英語のマニュアルを読みたくないから聞きに来てるんじゃねーの?
それをマニュアル嫁とかもっと空気読んだアドバイスが欲しい罠 おんなじ環境ないし、揃えてやる義理もないんで一般的な話になるけど
例えば、1710行目の
assert_param(IS_RCC_HSE(RCC_OscInitStruct->HSEState));
は、IS_RCC_HSE()マクロがfalseを返してきているのでそれを調べる。
すると、stm32f4xx_hal_rcc.hに、
#define IS_RCC_HSE(HSE) (((HSE) == RCC_HSE_OFF) || ((HSE) == RCC_HSE_ON) || \
((HSE) == RCC_HSE_BYPASS))
な記述が見つかる。
>>163の環境でRCC_OscInitStruct->HSEStateに何が入っているのか知らないが、それは
RCC_HSE_OFFでもRCC_HSE_ONでもRCC_HSE_BYPASSでもない別の何かだということがわかる。
ソース追っかけてもいいし、デバッガでアサート直前で止めて値を見てもいいし
何が入っているのか確認すればそれで何を入れればいいのかおのずとわかるはず。
ちなみに、それぞれの値は
#define RCC_HSE_OFF ((uint8_t)0x00U)
#define RCC_HSE_ON ((uint8_t)0x01U)
#define RCC_HSE_BYPASS ((uint8_t)0x05U)
と定義されているが、ここまでたどれないようなら、日本語マニュアルが充実している
ルネサスの石でも使った方がいいと思う 秋月でDIPのLPC1114FN28大幅値上げ。
SOIC使うからいいけど、こんなに上がるものなのか? >>168
秋月値段考えて、メリットあるのか?
DigiKeyの値段、見ればいいだろ >>168
高っ!
なんなの
140円くらいだったのに
600milなんて安くなければ使わんわ >>168
digikeyでは売り切れで非在庫保有
mouserはEoLフラグ
再来? LPC1114FN28はmbedでかろうじて息してるけど下火だろもう
300milだったら次世代のATMEGA328P的なポジションを確立できたかもしれないのに
NXPもバカだなあ >>173
ディスコンがなんぞのもんや(笑)、俺は採用するぜ。
(ディスコンすれば再設計の仕事が…。あぁ、ありがたや、ありがたやwww)
無論、他の部品も見直してコストを下げ、顧客にもメリットがあるようにするけどね。マジ ディスコンになっても適当な下駄を適当に作って差し替えが簡単にできるそれが600の利点だろ そもそもディスコンの恐れがある部品を使わせなくね? >>176
ディスコンが先に分かれば使わないさ。設計時の責任問題になっちまう。
デジタル系はサイクルが早いから、発表から5年経過したら避ける。
それでも予想外の部品がディスコンになるから… チラ裏
設計から2年も経過すると、ょり良い部品や回路構成が分かって、より安く作れるんだよね。 >>176
だよねー
うちもそうだが専任の部署があって認定してもらわないと使えない
認定時はディスコンの可能性やセカンドソースとかも確認するし >>179
セカンドソース?
あるにはあるけど、かなりの汎用部品でないと無くね?
あと、当たり前だけど微妙に特性が違うし。 >>180
ん?
できるだけ汎用部品に誘導する
って言うのもそう言う部署の役目だよ
セカンドソース用の部品も評価するし、極端な話ピン配置が異なるセカンドソース用のパターンをあらかじめ引いておく
なんてことも提案したりする マイクロチップ製のARMでないかな
ディスコンの心配なさそうだし 16F84がディスコンでAになって仕様vcc下がった恨みは未だに覚めない >>182
ARM(Cortex-M)はAtmelとSTが強いけど、最近Atmelがマイクロチップに買収されたから、でてるといえばでてる。 MKL82ZのLQFP64ピンが出てないと思ったらPackage Your Way いいけどここの過疎っぷりは異常
どこかフォーラムを見つけてそっちに行った方がいい 教えてください。
NXPとかから「新しいARMマイコン出たよ〜」というメールが来るのですが、
これらに使うコンパイラー(ツール?)は、何を使うのでしょうか? というか
フリーで出ているのでしょうか?
マイコンはPICで、MPLABで、XC16で・・・と、フリーで全部できるのですが、
ARMの場合はどうなのかしら、と思ったのです。
PICマイコンより、電気喰わないし、速度は速いし、ROM/RAMも多いし、周辺も充実だし
いいことづくめなので、乗り換えてもいいのかな?と思うのです。
そもそも、チップはどこで買うのか?という問題は残るんだけど。 チップはdigikeyで探せば、どれを選べば良いのか悩むくらいたくさんある。
ツール類はgcc/LLVMなどでそれこそLinuxみたいなOSまで作れる/デバッグ
できるようなツール類が完全に揃っている。
LaunchPad(https://launchpad.net/gcc-arm-embedded)
あたりも人気あるのでは?
ただ、特定のメーカさんなら、たいてい、それぞれのメーカさんのところで
フリーの開発環境が提供されているし、とっかかりはそっちの方が
楽かもしれない。 >>192
ありがとうございます。
デジキーですね。海外通販、ドキドキです。見てみます。
恥ずかしいのですが、英語が高校で暮らす最下位で止まっていますが、
やっぱり、え、え、英語ベースですよね?
(PICは、CQなどの本も日本語があり、僕の味方なんですが) IARなどであれば、マニュアルやヘルプを含めて日本語化されていますね。
その他の各メーカさんでも資料やチュートリアルなどの日本語版もある
でしょう。
もっとも、CQの本などでも全てを取り上げることは不可能ですし、
日本語マニュアルそのものもやはり英語版よりも古かったりします
(オリジナルが英語版ですし、翻訳にもお金も時間もかかるので、
仕方ないですが)ので、英文マニュアルを読むほうが良いですけどね。 最近LPC810で遊び始めた者ですが
LPCXpressoで開発してます
僕のLPC810工作ノートが結構解りやすかったですよ
LPCOPENとLPCCLOSEとの違いを理解するまで大変だったけどね
ARM始めるならLPCXpressoかmbedだと思いま LPCXpressoとKinetis Design Studio IDEは統合されるんだろうな Kinetisってなんだっけと思ったらFreescaleか でも、結局RaspberryPiでいいやってことになっていきそう >>198
調達不可チップが載ったボードに、要は無い(キリッ RaspberryPiだとlinuxだから雰囲気違うよな
デバグもセルフだし
IARとかMDKがラズπにつかえるのかしらん
MDKちょっと使ってるけど快適でとっても欲しくなるぞよ ■ このスレッドは過去ログ倉庫に格納されています