【Cortex-】 やっぱARMっしょ part10 【AxRxMx】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ARMデバイス、ARMボードについて組込系ARM全般のスレ
時代は「やっぱARMっしょ」
省電力ニーズの高まりを背景に海外チップベンダーはもとより国内勢も参戦
ホビーとしてのマイコンからスマートデバイス用プロセッサまで
ARMコアを持つチップやボードのラインナップは今まさに百花繚乱
【前スレ】
【Cortex-】 やっぱARMっしょ 9 【AxRxMx】
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/ >>82
コマンドラインとデバックで何の関係があるん?
ICEでもJTAGデバッガでもモニタでも好きな奴使えば良いやんか >>84
??
コマンドライン派って「統合環境使わない」と同義の
意味じゃないのかな。gdbのフロントエンド以外で
スタンドアロンで動くソフトあんの?
そもそもARMの世界でICEでもJTAGでもって書き方
なんか不思議デスね。ハードの話とソフトの話が
ごっちゃになってるし意味わかって書いてないのかな >>86
組込系ARM全般のスレに消防並みの基地外参上ってか
頭の悪い奴って都市伝説だと思ってたよ
お前に出会うまではな 見分けがつかないお前がNo.1だw
組込み系のデバッグとか経験する機会って無いものなのかね
まあ、日本では既に組込み系自体が絶滅危惧種 日本って1971年のi4004、μPD-707/708、あるいは1973年のTLCS-12の当時から
組み込みシステム開発を40年間やってた組み込み王国なんだよな。
10年前このスレを立てた当時、半導体製造業界のリストクチャリングが始まって
代わりにファブレスの半導体ベンチャーが雨後の筍のように増えていて
自分もそんなベンチャーの一つに居た時期にしょだのこのスレを立てた。
その後ARMはスマホの主要プロセッサになり
Strong ARMを買収したサムソンはスマホ製造の覇者となったあと、もう下り坂にさしかかっている。
10年後、20年目のこのスレはどうなっているだろうね 結局煽るばかりで実例が出ないあたりがにちゃん
らしいよな。まともに会話にならん。
俺は自動車関連にいるからそこの視点しか知らんけど
Cortex-A系のリッチな世界だとLinuxとかAndroid
みたいなものやるときはgccとかclangが出てくるので
コマンドラインも使うけど主にインテグレーションの
自動化とかで基本開発中のデバッグとかはMDK-ARMか
SoCメーカーの出してる統合環境を使う感じだね。
結局Eclipseベースになってて中でgcc/gdb呼んでる
物が多いけど。
ホビーの世界で金を出したくないとなると基本は
Eclipse+CDT+gcc/gdbじゃないのかな?
Cortex-Mとかでコードサイズ小さくてokな場合は
俺はIARのコードサイズ制限版を使うけどフルのは
個人で買おうと思う金額じゃないしねぇ。 セルフでのデバッグならEmacs + gdbもありかな。Eclipseより軽いし。 >92
周辺IOのシミュレータのないIARはARMでは使う気にならんけどなあ。
KEILがARM下に入って以後はKEILが本家本元になるし、
ホビーであってもKEILになるだろ。
IARの良いトコはARMに限らず広い範囲のアーキに対応する点だろうが、
今時はわざわざ超広域統一IDEである必要がないんよね。
どのIDEもEclipseベースで操作感おんなじ。 >10年後、20年目のこのスレ
その頃には2ちゃんがNIFTY-Serveみたいなんものになってるかな
速度が必要な処理はCPUやらGPUなんて使ってないんだろうな。 ARMマイコンの商用利用での開発環境だとIARが一番多い印象なんだが、違うのかな?
個人的には、ホビー用途しかないけど、IARは初めて触る時に全て日本語なのがありがたかった。 ☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んで
ください。私達の日本国憲法を絶対に改正しましょう。よろしくお願い致します。☆ 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でないかな
ディスコンの心配なさそうだし ■ このスレッドは過去ログ倉庫に格納されています