【Cortex-】 やっぱARMっしょ part10 【AxRxMx】©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ARMデバイス、ARMボードについて組込系ARM全般のスレ
時代は「やっぱARMっしょ」
省電力ニーズの高まりを背景に海外チップベンダーはもとより国内勢も参戦
ホビーとしてのマイコンからスマートデバイス用プロセッサまで
ARMコアを持つチップやボードのラインナップは今まさに百花繚乱
【前スレ】
【Cortex-】 やっぱARMっしょ 9 【AxRxMx】
http://wc2014.2ch.net/test/read.cgi/denki/1399381482/ >>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、デバッガの８MHｚをバイパス→PLL設定して入力してます
ちなみにこの２行をコメント化すると、デバッグコンソールに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ちょっと使ってるけど快適でとっても欲しくなるぞよ Arduinoではない
ただライブラリが比較的充実しておりWebコンパイラ上で
ライブラリのシャアができ比較的平易にプログラミングできる
という点では近いところがあるだろう
あと最近ではmbedボードでもArduino互換のピン配列の物も出てきている
ただし何度も言うがArduinoプラットフォームではない mbedいいね
USB繋いでD&Dでファーム書き込みができるのは画期的
しかもそれがデバグI/Fになり
仮想シリアルになり
しかもそれが公開されているという
(subset?だけど) >>199
ラズパイゼロみたいに$5なんて言われちゃうと、
ワンチップマイコン買ってきて・・・
なんていうのすら馬鹿らしくなってくるけどね。 こういうのは用途によって選ぶもんだから
ワンチップマイコンでやるようなことをラズパイでやろうとは俺は思わないな リッターバイクでアクセルちょっとしか開けられないのと、
小排気量でアクセルがんがんいけるのと、
どっちも良さがあるというしな。 リッターバイクで、アクセルをちょっとだけあけて使っていて
慣れてきたら少しずつあけていくっていうこともできるしね。
>>206
仮にチップ単体で入手できたとしても$5じゃ作れないしね。 起動で待たされるのもね、0.5秒で起動できるならいいけど ARMマイコンで質問があります。
PICマイコンのように、
・8 pin DIP
・18 pin DIP
・28 pin DIP
・40 pin DIP
・44 pin QFP
などを持つシリーズはありますか?
PICマイコンだと、ほとんど無改造でソース流用できますが、
それができて、形状がシリーズになったマイコン、という意味です。 そもそもARMのDIPはLPC1114FN28とLPC810M021FN8FPしかない
600mil幅にしたモジュールがよくあるのもそのせい ARMと言ってもライセンスを受けた各社の特徴が在るの一概に言えないが
例えばNPXのLPCシリーズはLPCXpressoとLPCOpen使えば移植性が高いよ ＞PICマイコンだと、ほとんど無改造でソース流用できますが、
共通なI/O類で、C言語レベルでソフトウェア互換を・・っていうなら、
CMSISを使えば、チップベンダが違っていても同じように扱えるから、
ほとんどのA製品でマイコンで共通でいけるでしょ。
PICみたいにMicrochip１社に縛られることもない。
PICと同様に内部のI/Oとかが違ってもいいなら、例えばCypressのPSoC4なら
8ピンのSOICから、16,24,28,40,44,48,56,68ピンのパッケージ品
（まぁ、全部表面実装だけどね）があって同じ開発環境（PSoC Creator）
でいけるね。（実は8ビットのPSoC3やCortex-M3のPSoC5LPも同じIDE)
ちなみに、PSoCの場合にはPICのMCCみたいなのを使うのが前提になって
いて、I/Oアクセス用のライブラリが自動生成されるから、PICみたいに
いちいちレジスタを調べたりする必要は無いし、APIレベルで互換を
とっているから、たとえばPSoC3とPSoC5LPで全く同じソースコードの
まま動いちゃったりする。 >>214
横からだけど、興味深い話を、ありがとう。
調べてみよう。
ちなみに、PoCというのは、アルデーノのような「関数のかたまり」のことですか?
アルデーノはマイコン少年にしさがないので、
I/OなどもPICのようにベタで指定したいんですが。 >>214
デジキーで見てきました。
CY8C4014という品種を見ると、
・いろいろなパッケージがありました。(DIPがないのは残念)
・型番の文字1つ1つに意味が割り当ててあって、わかりやすいです。(好き)
・I2CのI/Fはあるのに、UARTが無いのがビックリです。(理由が知りたい)
・全身32bitで、ちょっともったいない感がありますね。
・変数のbit幅は、char=8bitだと予想しますが、intは32bitなのでしょうか?
もう少し違う品種も見てみます >>215
PSoCは電子ブロックとマイコンを一つにまとめた石ですね。
ちょっとした回路をマイコン内部に突っ込めるので面白いです --ここから俺様メモ--
arm-none-enbi-gccの環境をCodesourcery4.3.3からLaunchpad5.3.1に移したんだ
そしたらmake出来なくなった
でリンカスクリプトの*(.data)を*(.data .data.*)に変えたら通る様になった訳よ
諸々のヘルパー関数含むgccライブラリも更新されてるから
新しいライブラリで使うセクションをリンカスクリプトに追加しなきゃいけないって訳で
例外処理使うなら.ARM.exidxとかも追加するとかなんとか
ソースで__attribute__((section 〜))になってるトコは追加できるけどライブラリ内で使われてるのは判然としない
まぁエラー出たらその都度追加しとけば良いか
--俺様メモ終わり-- >>214
CMSISはもう当たり前感があるけど、こんな風に対比すると凄いことなんだね。 >>191
秋月電子でSTM64シリーズ(形だけArduinoっぽいやつ)買って、
TrueSTUDIOで開発するのが簡単じゃないかな。 >>220
>TrueSTUDIOで開発するのが簡単
↓これのことですよね?
http://www.aicp.co.jp/products/atollic.shtml
>>214の言うサイプレスの物も開発とデバッガができるんでしょうか?
対応ボードにサイプレスが無いのですが。 >>215
PSoCは内部にPLD/マルチファンクションブロックみたいなものを
内蔵しているのね。
PLDなブロックはVerilogで書く事もできるけど、例えば「UART」とか
「Timer」とかいったモジュール単位で回路図レベルで描くこともできて、
ビルド時にそれらがPLD化されて（Warp・・っていうと懐かしい人もいるかも？）
それらをUARTやTimerなどとして操作する関数が自動生成されるので、
ユーザは生成されたAPIを呼べばいい。
回路が作れるので、例えばUARTの出力とタイマの出力のANDをとって
ピンに出力する（UART出力に変調かけたようになるわけね）
という具合に相互に繋ぐのも自由にできるわけ。
宣伝臭が酷くなってしまうので、あとはCypressサイトを眺めてくだされ。 >>221
Cypressは書き込み器がデバッガ兼ねてるし、PSoC Creator
（もちろん、コンパイラも含めて無償）にデバッガも
内蔵してる。 >>224 PSoCは内部にPLD/マルチファンクションブロックみたいなものを内蔵しているのね。
PLD の設計自由度は、出力マクロセルからの入力段へのフィード・バックを活用するこ
とで拡大します。例えば digital phase detector:MC4044 みたいなものも PLD で簡単
に実装できます。でもPSoC の資料には、このフィードバックの仕方が書いてありませ
ん。単に汎用バスに接続されているだけです。
たぶん汎用バスから再度 PLD 入力に戻すことをするのでしょうが、ここらをどのように
するのか、verilog でどのように記述するのかについて教えてやってください。URL の
提示だけでも助かります。お願いします。 UDBの内部構造やデータパスのチェーンの基本的な技なら
http://www.cypress.com/file/41531/download
このあたりでも見たらいいんでないの？ >>226
Verilogで書くならそのまま普通にフィードバックされるように書けば
勝手につながる。
スケマティックデザイン画面で、フィードバックかけても勝手に繋がる >>228 さん、貴重な情報有難うございます。
「Verilog または回路図で繋げば繋がる」ことは、たぶん bus switch を経由して繋が
るのだろうと推測します。
ただ、Cypress の資料に PLD の feedback についての説明が全くに近いほどないのは、
積極的には使うなという意味なんでしょう。
たぶん回路速度も期待しすぎてはいけないのでしょう。Bus switch 経由での feed-back
だとしたら、MC4044 を実装しても 100MHz 動作は無理だろうと推測します。ここらの話
になったら実際に試してみるしかなさそうですね。 そういやPSoC版のArduinoって無いな
うまく嵌ればバカ受けするだろうに ■ このスレッドは過去ログ倉庫に格納されています
