【Cortex-】 やっぱARMっしょ 11 【AxRxMx】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
>>466
DigiKeyでいいなら、旧ATMEL(現Microchip)のATSAMD10D13A-MNTが1個70円
ATSAMD09C13A-SSUTが115円
ZilogのZ32F06423AKEが124円
Silicon LabsのEFM32ZG108F4-QFN24Tが128円。
とかとか >>472
> DigiKey 〜 ATSAMD10D13A-MNTが1個70円
在庫無しなんですけどぉ〜 ATSAMD10D13A-MNTが70円で、在庫数4352個
ただし、非在庫保有商品なんでお早めに。 おっと・・・DigiKey型番は
1611-ATSAMD10D13A-MNTCT-ND
これな。 MNT,MUT合わせて一万個以上あるな@digikey
動作温度広い方が一円安いw
しかし24QFNじゃ素人は手出しができない アマチュア的には・・・だけど、
このQFNの場合、パッドがパッケージ側面まで出ているから、QFPと同じ感覚で
手半田できる。
QFPみたいに足が基板のパッドに引っかかったり、足の間にハンダが吸い上げられたり
しないから、QFPより楽だよ。 >>484
さすがにUEW空中配線とかいう職人芸は…… bga系のハンダで悩むなら
素直に基板プリヒーティング機能付きな
中華製BGA rework starion買えば良いじゃない〜 以前8pinQFNをジャンパでむりくり使ったけど
すげー面倒だった
それ以上は基板起こさないと無理だは
(根性無)
ジャンパ線は多芯銅線をばらして使った この手の側面までパッドの出てるQFNを変換基板に乗せて使ったけど、楽だったよ。 SWDのハーフピッチ9ピンヘッダが欲しいがどこかで売ってないかな
10ピンを切るしかないのか? 9ピンなんてあんの?
奇数
ふつーきーぴんはひっこぬくけどな LPC810について尋ねた人に専用スレがあるよとSTM32スレを薦めるのは、
実はよくわかっていないからなのか、単なるいやがらせなのか。
>>495
LPC810はディスコン。それほど売れなかったということだろね。 ×単なるなかやせののか。
○単なる嫌がらせなのか。 ワロタ
AVRスレでも今度それやってみるわ>他の石誘導 ATmegaの質問をした人に専用スレがあるよとPICスレを勧めるのは、強ち誤りではない >>503
世間知らずのバカのふりですか。ベタですね。 >>504
いや、会社でも客との会話でも、最近マジAVRなぞ出て来ないなぁ このスレもおっさんスレらしく雑談でないと盛り上がらないんだな >>506
方針も終わりでないの?
悪いね。ここARMスレだからマジ眼中にないんだわ
マイナビより
著者が、以前、Microchip米国本社を取材した際には、「当社は、8ビットマイコンではルネサスに製造コストでも売上高でも圧勝しており、世界一のサプライヤだ。
次は16ビットで勝負したい」とルネサスに対して闘志をむき出しにしていた。新たなMicrochip 2.0戦略では、さらに32ビットMCU/MPUに注力することにしている。 Microsemiを買収した3月のニュースで語られている将来の話を
現状の認識が誤っている話とすり替えようとしているね。見苦しいな。
そもそも眼中にない(知ろうともしていないこと)なら、世間を知らないのだな、と言われたときに
認めれば済む話なのに。 >>509
>見苦しいな
5chにくるおっさんはそういうもんだ
スレに関係なく雑談必死するのが5chのおっさんだし >>509
はいはい、AVRに反応して悪かったよ。
あんたのAVR愛には負けたよ。 LPC810に代わる8pin DIPは何がありますか? DIPのARMがLPC810とLPC1114ぐらいしか無いし 812あたりをピンコンパチのDIPに変換する代物を誰かが作ってたな だったらもっと足がある奴でってなって
STM32でとなり
最終的にラズパイでヨクネ…に >>513
すでにディスコンの製品を例にとって、「ぐらいしか無いし」は違和感…
SOP, (T)SSOP のものはあるから、変換基板で対処するしかないような。
>>514
これですかね。
https://www.switch-science.com/catalog/3879/ >>516
うわぁ…なんかもったいねー…うわぁ
812→810にしても増えてるROMサイズは勿論使えるとはいえ >>517
すでに、8ピンDIPで教材を作った学校なんかがあったなら需要はあるかもだけどね。もったいない。
DIPのマイコンへのニーズというか愛が一定量あって、それがPIC人気の一つだとは思うけど、
手軽な工作用ということなら、BluePillサイズやArduino miniサイズのモジュールが妥当な解って気がする。 今時CPU周りの回路は最早モジュールでもいいよね
DIPで無ければいけない理由は無いよ ボードでも中華だと安いからなぁ
ワンコインだもんなぁ
品質から言って趣味にしか使えんだろうけど 趣味だと、今は基板も安く作れるしね。
DIP変換+αな基板作って100均で手に入るレジンで固めればオリジナルICの完成だ。
中にヲタな絵なんか入れて名前付けたりするんじゃねぇぞ 【後藤弘茂のWeekly海外ニュース】96コアの高性能サーバーCPUも目論むArmの新ブランド「Neoverse」 - PC Watch
https://pc.watch.impress.co.jp/docs/column/kaigai/1148482.html >>522
そういえば、スパコン"京"の次は順調に開発が進んでいるんだろうか? 孫さんとサウジの関係がもやもやしているが、欧米企業からみたときに、行動規範として望ましくないと映ることはないのかな。 DesignStartにCortex-A5を追加
Linux対応Armプロセッサ、利用がより簡単に
http://eetimes.jp/ee/articles/1810/24/news040.html ARM命令セットにプリフェッチ命令ってあるんだっけ?
演算用のテーブルがキャッシュに乗らないほどでかい場合何も考えずに書くとストールが頻発 プリフェッチのための命令って意味不
じゃあそのプリフェッチ命令のためのプリフェッチはどうするの 自分でも何言ってっかわかんないからスルーでお願いします SSEにはプリフェッチ用の命令があるし同じようなのがARMにもないのかなと
ストールさせずにキャッシュへロードしてくれるなら専用の命令でなくてもかまわないけど プリフェッチって言うとどうしても命令プリフェッチが思い起こされるのでプリロードとかにしてくれれば良かったのに... 車の電装系に転職したのを契機にマイコンの勉強をしようと考えております。
来週東京出張があるので秋葉原で色々と買ってこようかと思っております。
秋月と千石ぐらいしか行ったこと無いのですが、他に品揃えの良い店とか
ありますでしょうか?
これは必要だから買っておけ、といったようなアドバイスも頂けたら幸いです。
何卒宜しくお願い致します。 >>537
今から勉強しますって奴を採るはずないだろ
夢見てないで頑張って明日もハローワーク行こうね >>537
もうほとんどないもんなぁ〜秋葉原w
あとは、あいてんどー位かな?
http://www.aitendo.com
てか何買うのよ?それ次第だわ 手段が目的化している典型例じゃないかw
まずはマイコンを使って何をしたいのか?が重要ではないのかな
それがわからなければ方向性も定まらないだろう
釣りでないならもう一度よく考えてみよう >>537
Amazonで色々買えるけど、秋葉がいいの?
車の電装系でARMなら、最近NXPがルネを逆転したらしいから、NXPのが役立つんじゃないかな?
>>538
「転職した」んだってさ。 年はいくつか知らんけど
車の電装系ってそんな未経験でも採用してくれるような緩いもんなの?
それとも4月入社かな?
まさかLED屋のことを電装系って呼んでないよな?
538は辛辣すぎるが多分こういうことを言いたいんじゃないかと 電装系の開発部隊に属するのであれば
普通はその会社が採用しているマイコンで研修を受けるわけだから
わざわざ開発環境も異なる別の石を使ってまで何かしても
初学者にとっては遠回り以外の何物でもないと思うが…
なにか物を作って、制御工学一般の意識を養ったり
そもそものC言語を習得したりってとこぐらいにしかならないかと そうなんだよね。仕事の勉強か趣味なのかでもだいぶ変わってくる 仕事の勉強っていったって、直接マイコンを触るグループでもなければ、
教養としての取り組みでもいいし、そうでもなくて、これを機会に
マイコンも触ってみたいなあ、っていう興味の問題かもしれないよな。
いいんじゃないのか、気の赴くままにエンジョイしたら。
一般的にはモノ作りにおいては、
目的…その作ったモノで何を実現するのか
手段…そのモノを作るためにどんなことをするのか
だと思う。でも
「面白そうなデバイスが出てきたら、手段のために目的はえらばない。なくてもいい」
と俺の先輩が言ってた。 会社が使ってるマイコン以外のものに触っておくとかも技術者のたしなみ まぁ、どれをお使いになられても似たようなものですが どれを使っても似たようなものだと、みんなが思ってるなら、好き嫌いの論争なんてないだろね。 実際に似たようなものかは置いといて
意外と似たようなもの同士でも好き嫌い論争にはなるw 争いは近いものほど、似たものほど苛烈になることがあるよな。 でも、あまりNXP派とSTM32派がケンカしてるのは見ないな。
俺が知らんだけですごい争いやってたりして。 どうせARMなんだからコストとペリフェラルの充実度、あとは開発環境くらいなもんだろ >>548
じゃあ、それください
…これなんですか? >>451
通りすがりのメイドですがねむいさんがlpc81x_swd_flash.cfg内で
参照しているlpc8xx.cfg、さらにlpc8xx.cfgが参照しているopenocd公式の
lpc1xxx.cfgに問題があるのがわかりました。
ここで本来LPC8xx系では0x0bc11477でなくてはならない_CPUTAPIDに
0x0bb11477を設定してしまっておりさらにSTLink系のデバッガだけは
律儀にそれを確認しに行くので不一致でエラーを出してしまいつながらなく
なっています。
今はほとんどの人はLPC系はCMSIS-DAPで開発しているので見落とされて
しまったのでしょうけどじきに修正が入ると思われます。 ねむいさんいつもご苦労さまです
ここも巡回されてたのか >>491
Mouserで売ってたよ。安くないけど D&Dでファーム書き込み、
デバッガ、
仮想シリアル
これがUSB一本線でできるんだから
画期的ですねぇ
しかもソースがopenときた どこがやねん
ブラウザ上のエディタとか害悪
せめてvi互換にしろや 100%俺を満足させんと使わんてか?
手に合わない環境エディタなんか使うほうがあほ
気に入ったいいとこだけ使えばいいんよ >>568
は?Emacsのほうがいいだろゴミクズ emacs使いはとりあえず叩かれる風潮どうにかしてほしい ARMでパラレルなカメラインターフェイスついてるのってSTM32位?
できればYUV422に対応している奴が欲しいんだけど。 >>576
STM32でなんの不満が?
開発環境もフリーになったし問題ないぞ じゃなくてTrueStudioっつうのがいいのか? >>577
いやハードで競合とか無いかなと思って。
自分でも調べたけど、独自に積んでるみたいだし、一応ARM側でもカメラIF積みたいと言われてたけど実現したのかなって。 ねむいさんが転職活動時にお前のブログはマイナスにしかならんから書くなって言われてたん笑う
技術力ある職人気質の人ということと同時にどうしようもない変態ということが伝わるからね 電子系のエンジニアってアニメ好きドール好き率高いよな soramimiとかいう人、色々ためになるネタ上げてるけどお人形さん遊びをサイトに載せるのやめてほしい モルフィーの悲劇知る人も減って
そろそろ同じ悲劇が繰り返される悪寒 そのくせクレカとか運転免許とか持ってなかったりするんだよな 日本の技能職って薄給&長時間のオワタ式で社会的地位も低いだろ 日本の技術者がアニメ・ドール好きに見えるのはネット界隈の趣味の人間だけ見てる
からだろう。人口のごく一部にすぎない。
今は世界的に低年齢化しているし日本の悪いアニメ・コスプレ文化を学んでいるから
その影響だろうが、日本人だけではないし、大人世代ではそんなことしていないから。
先日秋葉原で白人の若者が日本刀をリュックに差し込んでコスプレ喫茶に入店しようと
していたり、ドイツ人らしき若者が日本のサラリーマンみたいに公園で昼飯食べて会話
していたり、中国人の地方から出てきた清楚なお姉さんが日本で働き始めて次第に化粧
厚くなって派手な服装になってゆく時系列を目撃すると、Youは一体どうなってんだ?
と思うぞ。 >>587
キックスターターとかマクアケとかで誰かMorphyOne IIとか立ててほしいわ
今なら爆釣れだろ >モルフィーの悲劇知る人も減って
>そろそろ同じ悲劇が繰り返される悪寒
そろそろも何もクラウドファンディング関係で既にあると思うが >>595
200lx後継機のプロジェクトの話だけどあったの?
貼ってくれよ >200lx後継機のプロジェクトの話だけど
どこにもそんな話は書かれてないが? >>597
自分で引用してるじゃん
モルフィーの悲劇、って
それこそただの目標不達とか無関係のネタでの発案者失踪の話なんてこっちも話題にすらしてないんだが 気違いに触っちゃったみたいだなw
俺は「モルフィーワンの悲劇の話(>>587)」にはレスはしたが「モルフィーワンの後継機の話」に
レス何てしてないぞ インテリジェントデバイスの高画質化を実現??イメージシグナルプロセッサー「Arm Mali-C52」、「Arm Mali-C32」 | fabcross
https://fabcross.jp/news/2019/20190110_armisp_malic52_c32.html ATSAMD10(CortexM0)の話題もここでいいんでしょうか? どうぞどうぞ
ペリフェラルはユーザーいないとわからんが >>603 です。
atmel-ice は、持ってます。
atsamd10 も買いました。
avrstudio7もセットアップしてます。
atmel-ice の接続ケーブル別途入手しなければならないけど、純正のケーブルセット
digikey でも6000位するんですね。
それは、おいておいて、
簡単なLチカコードを書いて、レジスタの動きをや、実行タイミングを見たいのですけど、
どうも、avrstudio7 ではatsamd10用のシミュレータが無いようなんですが、
atmel-ice使って、debuggerで見る?しかないのですか? シミュレーターないなら実機+デバッガしかないんじゃないかなー ARM系の既成品なら大抵ハーフピッチ10pinコネクタだから4枚目の写真の下のケーブルの真ん中のコネクタで繋げられるんじゃないかな
自作基板とかはしらん とりあえず適切にピン接続できれば付属ケーブルでいけるよ 接続について詳しく質問したいならターゲットの情報が必要
それにしてもMicrochipの箱にatmel製品が入ってるのは未だに慣れない STM32+AD9283でオシロを作った人がいましたらアドバイスをお願いします。
STM32F407のシステムクロックは168MHzなので、1/4の42MHzをMCOからAD9283に入力してパラレル出力(42Msps)をGPIOで取得するつもりです。
GPIOの取得に使う「value[0]=GPIOA->IDR」は1クロックで実行できるようなので以下のようにしてSTM32とAD9283のタイミングを合わせています。
value[1]=GPIOA->IDR;asm("NOP");asm("NOP");asm("NOP");
value[2]=GPIOA->IDR;asm("NOP");asm("NOP");asm("NOP");
value[3]=GPIOA->IDR;asm("NOP");asm("NOP");asm("NOP");
〜中略〜
value[1023]=GPIOA->IDR;asm("NOP");asm("NOP");asm("NOP");
現状としては一応数値は取れているのですが、値がデタラメになってしまいます。
どなたか上手く動かす方法を教えていただけないでしょうか? >>612
本当に1クロックで動いてんの?
コンパイラで最適化されてたりしないの?
プログラムはSRAM?Flash?どっちで動いてんの?
CPUキャッシュとか絡んでないの?(あるんだっけ?)
オシロで1クロックで動いてるか調べた?
しらんけど >>613
すみません。
もう一度クロックを計算しなおしたら3クロックでした。
コードの前後でパルスを出力したので今度こそ間違いないと思います。
asm("NOP");を一つにしたところ、多少はまともな値になりました。
でもまだ数値が±20%くらい揺れるので、オシロとしては使い物にならない状態です。
この原因がパラレル出力の有効時間外にサンプリングしていることだとしたら位相シフト回路が必要になるんでしょうけど、また別のドツボに嵌りそうで心配です。 >>615
DMAは検討したのですが、STM32のDMAは8クロックもかかるようなのでやめました。 >>617
FPGAも勉強してはいるんですけど単価が高いのとマイコン以上に難解なんで二の足を踏んでます。 NXPのLPC1800のSTimerとDMAで出来ないかな >>621
どのステートの時にどの条件値到達でどのステートに遷移するか。
いろいろ出来る事はあるけど基本はそれだけだよ
なんならステートは1つしか使わなくてもいいし >この原因がパラレル出力の有効時間外にサンプリングしていることだとしたら位相シフト回路が必要になるんでしょうけど、また別のドツボに嵌りそうで心配です。
現状で、AD9283 のクロックとの位相はどうやって保証してるの? >>623
やってません(キリッ
一応以下のようなコードを入れて測定開始前のAD9283のクロックが1になるようにしています。(疑似コードです)
2行目のwhileを抜けられるのは図中でいう1,2,5,6の時のため、ある程度測定開始時の位相をそろえられると考えています。
後はズレのであればasm("NOP");を入れて調整しようかと。
実際にAD9283のクロックをサンプルと同時計測すると毎度0にすることが出来たのでクロック単位での位相はそろうようです。
(AD9283の測定結果が有効になるのはクロックが0の時です。)
とは言え、私のオシロの帯域幅は60MHzなので実際に意図通りに動いているのか確認することはできません。
while(AD9283clock == 1); //実際の「AD9283clock」はGPIOAの9番目
while(AD9283clock == 0);
value[1]=GPIOA->IDR; //よってここで「AD9283clock」も記録される
以下略
システムクロック
1 ┏━┓ ┏━┓ ┏━┓ ┏━┓ ┏━┓ ┏━┓ ┏━┓ ┏━
0━┛ ┗━┛ ┗━┛ ┗━┛ ┗━┛ ┗━┛ ┗━┛ ┗━┛
1 2 3 4 5 6 7 8
AD9283のクロック
1 ┏━━━━━━━┓ ┏━━━━━━━┓
0━┛ ┗━━━━━━━┛ ┗━━━━━━━┛ 図がすごくずれてしまった…
システムクロック
1─┏━┓─┏━┓─┏━┓─┏━┓─┏━┓─┏━┓─┏━┓─┏━
0━┛─┗━┛─┗━┛─┗━┛─┗━┛─┗━┛─┗━┛─┗━┛─
───1───2────3───4───5────6───7───8
AD9283のクロック
1 ┏━━━━━━━┓───────┏━━━━━━━┓────────
0━┛───────┗━━━━━━━┛───────┗━━━━━━━┛ トラ技のLPC810の特集、今更やってみてる。
質問です。
USB-シリアル変換モジュールを使用してプログラムの書き込みをしています。
LPC810との物理的な接続はTXD/RXD/GNDです。
LPC810を複数、USB-シリアル変換モジュールにぶら下げて同じプログラムを同時に
書き込む事は可能でしょうか?
LPC810への送信で¥を垂れ流しならいけるかなと思いますが、同期をとっていれば、不整合が
起きるのかな?と思っていますので、アドバイス頂ければと思います。 >>626
むり
TXDとRXD両方を繋いでいる時点で察するべし >>628
PC−>LPCのTxDを並列に配って、RxDはどれか一つからだけ戻せば、もしかしたら・・・。
ただべりファイはできんけど。 >>625
逆に超ウルトラ低速動作での動作確認はやってあるの?
A/Dにボリュームでもつないで、DCレベルでの変換がちゃんと拾えるか。
これが確認できれば、ノイズ拾ってる、とか結線間違えてた、とかがクリアになって、
いよいよ高速データ受け渡しだけの確認作業になる。
あとそこまでタイミングがタイトな構造にするのなら、プログラムのデータ取得部分はすべて
アセンブラで書くべきかと。拾ったデータをメモリに落とす value[n] のメモリ代入側も
ホントに 1clock になってる?
少なくともelfをobjdumpで逆アセンブルしてコードは確認すべし。 Arm、スマホで“ノートPC並の性能”を実現するCPU「Cortex-A77」 〜性能1.4倍の「Mali-G76」GPUや機械学習コアも - PC Watch
https://pc.watch.impress.co.jp/docs/news/1186724.html 【後藤弘茂のWeekly海外ニュース】シングルスレッド処理向上で最上級の性能を得たArm「Cortex-A77」のマイクロアーキテクチャ - PC Watch
https://pc.watch.impress.co.jp/docs/column/kaigai/1188094.html NVIDIA,「CUDA-X AI」を含むAI開発向けソフトウェア開発キットのArm対応を表明 - 4Gamer.net
https://www.4gamer.net/games/076/G007660/20190617085/ 【後藤弘茂のWeekly海外ニュース】Armが次々世代CPUコア「Matterhorn」の技術を発表 - PC Watch
https://pc.watch.impress.co.jp/docs/column/kaigai/1211845.html RXの新規開発中止、既存もNRNDくらいやってくれないと本気には見えない。 >>644
泥船ひのまる半導体選定して設計するアホが悪い 選定が完全でないことでアホだとされるのだとしたら、
俺を開発設計担当にしてくれているお客様がアホってことになる。まったくもって申し訳けない。
>>645自身はパーフェクトな仕事人なんだろうか。
もしかして>>645もたくさんのアホ様のおかげでメシを食えている、ということはないのだろうか。 かと言っていつ会社が傾くかわからんのを使う理由にはならんわな
顧客の既存案件のしがらみだったとしても
そこを説得して今の内にマイグレしとくべきな場合もある >>647
煽り抜きで聞くんだけどさ
ディスコンにも成ってない現状で追加開発費出してまで
あんたはRXから何にマイグレを検討すべきだと思うの?
まさかARMとかいう情けない事言わないよな?ちゃんとどこのベンダかまで根拠付きで頼む ARMもいつまで天下とってるかわからないからな
RISC-Vも勢いづいてきてるし >>650
イニシアチブを取る企業があるかどうかだろうな。
例えばAndroid、Googleがオープン化して後押ししたからそこそこシェアを取った。
例えばLinux、カーネルはAndroidでメジャーだが、OSとしてはWindowsのシェアを奪えてない。
例えばIEEE1394、最初は家電に歓迎されたが、intelの強烈なUSB押しのライセンスフリーに性能アップでIEEE1394を蹴散らした。今や蹴散らされたAppleがUSB-C押し。
例えば国産OS TRON、B-TRONは米国に負けた。ITRON組込みでNo.1だったけど今では……。
多数連合で勝ったのはHDMI位じゃない?
今のところ烏合の衆(に見える)というか、バークレー校がガンガンとRISC-Vを推進して爆進……するかなぁ? モバイル向けOSのトップはAndroid
デスクトップ向けOSはいまだにWindowsが強いが市場そのものが右肩下がり
USBはライバル不在になったらVID代爆上げ&ジャイアン化
国内勢が衰退したのは戦略戦に負けたから。物が悪い訳じゃない RISC-Vはちゃんと最適化してくれるコンパイラ群がフリーで使えるのがでかい
ただしCortex-M0+クラスは現状でもフリーで使えるからね
M3以上になると乗り換えるメリットがでてくる
シナ製以外がでてきたら本番だな。エッジコンピューティングの覇権はどこが握るのか
LPWAもAmazonが参戦してきたし、もたもたしてるとデファクトスタンダード取られるな
ESP32の後継機も気になるところ(S2は省エネマイナーチェンジだけど) とにかく学生やメイカーズ党がフリーで開発できないプラットフォームは衰退あるのみ
チップ売りたいのにソフト面でも金がかかるってのはナンセンスだわ
クラウドコンパイラが使えるってのはあんまり意味ないね
mbedはプロトタイピングには便利だけど
本格的にデバッグするのにオフラインには勝てないから(ARMもその点は優秀) Cortex-M7レンジのRISC-V ASICはよ来い 昔のTRON CPUもISAだけ定義された設計とも云えない代物だった >>656
んなもん要るかよww
普通にCortex-m7 使えばいい
Risc-Vみたいなもんはメーカごとにローカル拡張が勝手に行われて規格としての破綻が目に見えてる ARM「カスタム命令拡張対応のCortex-M33を用意したよ!」 ARM一社がやってる分に何が困るんだwww
事実M3の拡張がM4だしなwww
フリーというかざっくりした規格なら、いろんなところが勝手なことをやりかねないことを言ってる。
iTronのようなxx準拠ってやつだ ttps://open-isa.org/
>VEGAborad
これ欲しい Arm、機械学習向けのNPUなど最新プロセッサーIP4種「Ethos-N57」「Ethos-N37」「Mali-G57」「Mali-D37」を発表 | fabcross
https://fabcross.jp/news/2019/20191025_arm.html >>655
確かに、ちょっとしたプログラム作っても
かなりの容量になっているのは確かだ
ROMはたっぷり使えるからいいというやつもいるけど
サイズがでかいということは遅いということになりかねない??? >>655
gccよりllvmの方が最適化は良いかもしれないね ARMで高性能なカメラを取り込める通信IF付きのシリーズってない?
STM32ならF446が8ビットバス持ってるからどうにかなるかなと思うんだけど、40ビットバスぐらいの高解像度持ちって居る? >>667
何でしょぼいF4なのよ?
いまならSTM32H7シリーズじゃね?
もしくはSTM32MP1シリーズ >>668
H7とMP1ね。
しょぼいのは基板があって、変換ICを8ビットピクセルバスで考えてたから。
MIPIじゃないと使えるんだけど、その辺はSTMに聞いてみる。
ありがとう。 レスが抜けたね、ごめん。
>>669
TIだっけ、そっちも調べてみるね。 >>654 エクリプスがあるじゃん。keilは突っ込んたカスタマイズをするにはめんどくさい。 NordicなどのBLEモジュール(Bluetoothクラシックも含む)を扱うスレってありますか?
ハードウェア板にBluetoothスレはあったんですがそっちはPCでBluetoothを利用するためのスレだったので違うっぽかったです。
Nordicに限ればARMだからこのスレでしょうか? >>675
このスレでBLEが話題になった記憶が無いw
居るとしたらこっち↓だけど、本職が使うnordicは、ちまたでは無名かも。
【電波】無線モノ自作スレ【ゆんゆん】
https://rio2016.5ch.net/test/read.cgi/denki/1342008222/ >>675
無線モノスレの10/25に、nordicのニュース転載した人が居るね。 >>676
ここでは一度も話題はありませんか
無線モノスレ見てきました
かなりの過疎スレでした…
Nordicと思われる書き込みは2013年に一回と10/25のみで他はBLEはありませんでした。
けれど、そのスレが適切っぽい感じですね
どうもありがとうございました 別にここでやってもいいじゃん 全く無関係という訳でもないし >>679
いいじゃんと言っても……。
開発環境はマイナーなSegger社 Embedded Studio。ARMを使っててもライブラリ使うから普段は意識すらしない。後はBLE系用語と無線系用語が飛び交うのみ。
無線モノスレのほうが、続く人にもいいと思うが? >>679
いっその事、専用スレを建てたほうがいいかもな。
なに、この板の下はゴミスレばかり(だから俺は常にageる)
専用スレでも構わないだろう 2chでnordic全然人気ないな
softdeviceの出来はいいしBLEやるなら一択なんだけど
nrf91も期待できるし需要あるならNordic専用スレ欲しいな >>682
本職が使うチップだからね。
作り込み易さは頭一つ抜けてるね 日本ではmicro:bit自体人気無いからしゃーないな nRF9160 SiPはかなりいけてるチップ
STMも悪くないんだけどLPWAの開発ボードとしては
でかいし肝心のGPSがオンボじゃないから何がしたいのか謎 そういえばmicro:bitのスレすら無いんだな
5ちゃんとmicro:bitのユーザ層が違うのか Arduinoでポチポチやってるレベルの人間でも行っていいのかな? スレ立てやってみようかと思うんだが、Nordic専門にするかBLE、Bluetooth全般がいいのか、開発環境もSegger専用かArduinoもいいのかその辺意見頼む。
個人的にはSeggerだけだと過疎りそうだし、ArduinoやMicroPythonもいいと思う。
間口の広そうな無線モノスレですら過疎ってるからね >>690
専用スレでいいと思うな。
一般向けなら無線モノスレがあるから、重複スレになっちまう。 こんなんでいい?
【Bluetooth Low Energy】BLEの鉄板Nordicのスレ【ANT+】
技適対応モジュール... Raytac、太陽誘電などから
開発環境... Segger Embedded Studio、Arduino、CircuitPythonなど
業務の人も趣味の人も仲良くしてね >>692
個人的にはNordicのしばりはない方が 過疎らなくていいかとは思う どうせ過疎る時は過疎る
BLEなんて後はESP32くらいでしょ >>694
このスレも過疎スレだが、恐らく
このスレよりもずっと過疎スレになるだろうな 度々すみません
スレタイどっちが良いですか?
ESP32スレが900超えたので、向こうの新スレ立ったらBLEスレを立てようかと思います。
https://i.imgur.com/eNe5qM9.jpg >>697
こだわるねぇ、テキトーでいいやん
強いて言えばNordicが先でBLEが後。BLEのスレかと誤解を与えるから。 メモ保存してなくて遅くなったけど建ててきたよ
【Nordic NRFxx】BLEについて語るスレ【Bluetooth Low Energy】
http://rio2016.5ch.net/test/read.cgi/denki/1575216922/ もうARMは終わり
スマホ市場自体が終わって、ARMどころかINTELもNVIDIAも終わりまで行った
結果やつらはアーキテクチャ更新するって、けどARMは何もしないって
なにもしないままARM需要、市場、スマホ市場は収縮する
で次の世代でARMが変化ないまま、全個体バッテリとかでスマホのCPUに使える電力やバッテリが強化されたら.......
INTELやAMDがスマホ市場に殴り込んできて淘汰だな
GPUパワーPRも操作性はスイッチ、パワーはINTEL、AMD、NVIDIAに惨敗だよ
しかもAMD7nmEUVなんかは省エネ性改善するから
ARM市場殴り込んでくるかもしれない。行き場なくなったINTELも攻めそうな勢い
ARMはテクノロジでもコストでも劣るから、INTELその他が本気出したら終わりなんだよ INTELのLAKEFILEDとかは貧弱でノートパソコンじゃ勝負できないけどARM相手なら最適だよ
・メモリは4GBしかないが、6-10GBスマホとかいらん、あれは情弱商法
・あらゆる面でARMを圧倒できる
ARMはシステム構造的にだめなくせにゼロベースでリセットできない
ならINTELが逆襲するチャンスはいくらでもある >>708
マイコンで機械学習ってか。
出来るとは思って無かったからぶっ飛んでんな〜 >>707
Intelというよりx86プロセッサはこれまで負けたことなんか無いんだがww
歴史を知らないおばかちゃん 互換CPUなんてクソ!Intel最強!的な態度を突き通してきていたIntelが
互換CPUメーカーの開発したISAをメインラインに実装したというのは歴史的大事件だった >>718
プレスコットだっけ?
その頃にクロック至上主義のインテルが挫折したのは。
その後低迷したAMDも復活したな >>713
いや、それはそもそも誤解だろ
そもそも携帯電話の時代からx86を選択肢に考えたことなんかないんだが。
いったいどこのメーカがx86で携帯電話製品化したのか言ってみな。 ピピンアットマークはPPCでマルチメディアだったな
バンダイは20年先を進んでた
ファミコンも電話に繋いで株や競馬出来たらしいな >>724
でも Celeron J とか Pentium N とか残るんだろ。 「モバイル向け」と書いてあるのが読めんのかな?
インテルx86の敗北はまだある。
インテル、IoT向け小型コンピュータ3種類を静かに生産終了へ。出荷も年内完了予定 ...
https://japanese.engadget.com/2017/06/21/iot-3/ >>723
はぁ?
x86が、分岐予測をさんざんはしょったARMに消費電流で優位にたてるわきゃねぇだろが。
常識ないのかお前が >>724
お前メクラか
当社は今後、クラウドやIoT(モノのインターネット)、メモリ/プログラマブルソリューション、5G(第5世代移動通信)、
ムーアの法則などの分野に注力し、真正面から取り組んでいく考えだ
おまえ5G や IoTがモバイルじゃないとでも思ってんのかwww 大体スマホやらタブレットはともかくx86のバイナリが動くノート市場がなくなるとでも思ってんのか
ノートPCはモバイルじゃないんかいww ARMはCPU以外で強みを持ってるメーカーが強いからね
5GはQualcommやファーウェイが強いだろうし >>728
それのどこがx86なんだい?
話を逸らせるなよw > x86が、分岐予測をさんざんはしょったARMに消費電流で
分岐予測とか、何処からそんな誤認識を引っ張って来たんだい?
そもそもx86が不利なのはその前段の命令デコード。
命令デコードで電力食ってしまうからArmに勝てない。
【後藤弘茂のWeekly海外ニュース】フロムスクラッチでCPUを設計するAMDと ...
2017/01/05 · そのため、x86/x64命令のCPUは、命令デコードのロジックが複雑になり、 デコード段での電力消費が大きくなり、デコードの ... x86は拡張につぐ拡張でプレフィックスだらけだし
アドレッシングモードまで判明しないと命令の長さすらわからないから
デコードは大変そうだね x86 というのなら、8086 でいいのではないか? >>734
ルネサスのM16CやR8Cが8086に似たような感じだね >>733
確かIA-32でもSSE命令系は命令長が分かるんだよね?
でも元々の命令は分からないしね。
AMDはよく無駄な16命令を見つけて、上手に拡張したなと思うよ。
https://www.saluteweb.net/~oss_amd64isa.html
残念ながらIA-32にはプリフィックスの「空き」はない。
しかたなく何かの命令とトレードオフし、そこを拡張用のプリフィックスとして割り当てることになる。
:
つまり上位4bitをエスケープのためのプリフィックス、下位4bitを拡張用のビットとするわけだ。
そうすれば命令長がIA-32より1バイト長くなるだけで済む。
しかしその代わり4bit分、つまり16個もの命令とトレードオフにしなくてはならない。
そんなにたくさんの命令を削除しなくてはならないのだが、何を犠牲にしたものか。
IA-32には8086からの名残で、レジスタのincとdec命令が1バイトのものと2バイトのものがあり、2つずつダブって存在している。 >>732
簡単では無いだろうが、インテルはモバイル向けに命令デコードが簡単で、x86と互換性の無い新しいISAを定義すべきだったと思う。無論、x86命令はx86モードとして残してさ。
もしその新ISAがArm互換だったら、世界は変わってたかもしれないw
ただ「モバイルにもx86命令を!」という至上命題があったから、この選択肢はありえなかった訳だったけど。 極端なローパワーを求められない用途ではまだまだAMD64が強い 最近のChromebookにはArmモデルもあるのか。知らんかった。
Chromebookか、どうなんだろう。 ARMマイコンについてなんですが
PICやAVRマイコンはワンチップに極力機能を納める方向で進化してて
CortexのようなARM系マイコン、RISC系マイコンはワンチップに納めようとせず周辺パーツと連携するためにバスをはやす方向で進化してるってイメージはあっているでしょうか? >>742
はぁ?なぜそんな認識?
今はSoC化でなんでもワンチップにする方向。Armもね。 そこそこの速度で周辺を拡張ってなら
SPIやQuadSPI十分だろ?的な… >>741
Androidベースなら普通にARMになるだろ。 >>745
最近ときどきChromebookのテレビCM見るけどARMベースだったんだ!
Intelマシンと比べてパフォーマンスはどうなんだろうね?
やっぱりグラフィック速度とかはIntel系が強いかな? >>745
スレチだが、Chromebook OSとAndroid OSとは別物。
最近のChromebook OSは、LinuxアプリとAndroidアプリを実行出来るんだってさ。 >>747
LinuxもAndroidも両方実行できるChromebookって、何気に凄そうに思えてきたんだけど。。 >>748
俺も1台あってもいいかなとは思うが、何に使うかで逡巡してる。 普通に居間でネットサーフィンするのに使ってる。
キーボードあるとメールも検索も早いし。
ソファで動画見るにはタブレットのほうがいいけど。 cerelonNとかatomなネットブック系win機でyoutubeを見るとビミョーだけど
chrome bookなら >>751
欲しくなるだろ!!
投資で大損したから当分は我慢だなorz ちょっと古いpcにcloudready入れるといい感じ
androidアプリは対応してないけど >>752
このスレにも、コロナの影響で株で損した奴がいるんだ?
>>750
Chromebookでoffice関連アプリ使ってる?
スマホ用だからAndroidのofficeアプリはイマイチだよね?
Linuxで良いofficeってある? Chromebook で office なんて使わないよ。
ってか、職場で仕方なくは使うけど。
基本、アプリは入れない。ブラウザのみ。 >>754
基本的にthin clientだからな。
繋ぐ先でアプリは変わる。
ローカルには接続するソフトしか入れてないよ。
殆どブラウザで、都度javascriptのアプリ落としてきてるのが多いけど、サーバー側で動いてるのも有る。
オフィス系はgoogleappは使えるけど、そういうの使いたい時はwindowsの画面引っ張ってくることの方が多いな。 >>754
iPad、iPhone、Androidで使うExcelは、軽く触った限りはExcelだったよ。
そこそこ使えるんじゃね >>747
AndroidはLinuxベースだろ?
(Ubuntuだっけ?) >>758
カーネルはLinuxだが、ユーザーランドはオリジナル。
無論、Ubuntuではない ユーザーランドもパクりまくってたからOracleに訴えられて負けたんだろ。 >>761
ググれってw 二次ソースじゃなく一次ソース嫁や >>762
訴えられたのはJavaAPI、ユーザーランドをパクった訳ではない ARM版Windows 10搭載の2in1 PC「Yoga C630」が税込79,800円でセール
https://akiba-pc.watch.impress.co.jp/docs/wakiba/find/1244803.html
Lenovo Yoga C630 製品仕様書 81JL000DJP | レノボジャパン
https://www.lenovo.com/jp/ja/static/catalog/nb-2019-yoga_C630_web_0416
Snapdragon 850
Adreno™ 630
SIMフリー
Active Pen、Microsoft Office Home&Business 2019付属 Cortex-A53が載っているのでこのスレに
ソシオネクスト 電力効率が汎用GPUの10倍以上、量子化DNNエンジン搭載のAIチップを開発
https://monoist.atmarkit.co.jp/mn/spv/2004/08/news095.html
何に使えるかな?記事には自動運転、監視カメラ、FAとか書いてあるけどさ。
NVIDIA® Jetson Xavier™ NXと比べてどうだろう。NVIDIAは長期供給がアレなんで、エッジのキラーデバイスになったりして。
ワクテカ(死語w)だわ 5nmプロセス向け。性能が2割向上したArm「Cortex-A78」 〜新フラグシップGPU「Mali-G78」なども - PC Watch
https://pc.watch.impress.co.jp/docs/news/1254999.html >>763
一般常識としてJavaの発明はSun/OracleにあるのだしJavaを使っているのだから
何らかの費用経費の支払いが生ずるのは当然だと思うよ。
Androidで無償使用するにしてもSun/Oracleからの何らかの書面が必要になると思う。
それすらないわけだから。
なぜGoogle側が負けることが不満なのか理解できない。
もしこれが正しく履行されないならソフトウエアのビジネス自体成り立たないよ。 >>770
2ヶ月も前の話題に何を言いたいのやら。
元ネタは「ユーザーランドもパクりまくった」の間違いであって、誰も不満とは言ってない訳だが? 東芝のマイコンて聞いたことないんだが?
総合電機のなかで東芝マイコンをそもそも検討したことがない。
今マイコン出すならシリコン以上の開発デバッグ環境とサポートツール、
RTOS用意しないととても勝負にならん T芝独自マイコンならTLCS90とか900シリーズがあるだろ!! AKI80のZ80が東芝製だったな。それ以外は思い出せんw その時代のワンチップはまだマスクROMベースが主流で
個人で使うなんて無いし…
ましてやまだ開発環境が有償だった時代じゃ
メーカー独自CPUなんて、それこそ特殊な事情がなけりゃとても… >>777
大口専任で小口にはそっぽを向き、それでマインドシェアが低いとか? >>780
NECには「使った事は無いが、名前は聞いた事がある」って石が多いよ。78なんとかとか、V860なんとかとかね。
説明しろと言われたらさっぱり答えられんがw TMPZ84Cだね バスが出ててROM外付けだからROMライタで焼いてソケットに
挿して使っていた 今やRL78も普通に買えるが前身の78K0とか何処に売っているんだよ状態だった
IDEもICEも良いお値段していたし趣味で使うとかあり得なかった
78K0のIDEに付いているシミュレータは一部のペリフェラルもサポートしていて結構優秀だったな 此処はArmスレ
Z80も78KもRL78もスレチ スレチスレチ言う人に限ってスレにふさわしい話題を投稿しない法則 ほんじゃま、スレに相応しい話題w
RISCの生い立ちからRISC-Vまでの遠い道のり:
ARMの誕生 〜Sinclair、BBCからNewton、Symbianへ〜
https://www.itmedia.co.jp/news/spv/2006/08/news058.html この記事でこんなこと言ってるけどこれどうなの?とかあるならまだしも単にリンク貼るだけなんて嵐と変わらないw >>788
我が儘な奴だw
ARM躍進はスマホ(正しくは携帯)だった!の認識通りて特にコメントは無い >>787
良くしらんかったけど ARM7 と ARM7TDMI って世代の違う別物だったのね 【国際】イギリスの半導体設計大手アームが中国合弁会社のCEO解任発表 合弁会社側は否定 説明食い違い、内部対立か [さかい★]
http://asahi.5ch.net/test/read.cgi/newsplus/1591829366/ x86オワコン、これからはARMの時代と言われて大分経つが
未だにARMはタブレット止まり。数は多いから儲かってはいるだろうが
PCでもクリエイティブやエンジニアリング分野、サーバー等は
高性能競争で火花を散らすIntel vs AMDに割って入れそうな雰囲気は全くない スパコンってFUJITSU A64FXのことを言っているのかな。あれって1コア当たりの性能は大したことなくね?
多コアでも高効率を維持出来る処理じゃないと高スループットを出せないように見える
ベクトル系の処理だとNEC SX-Aurora TSUBASAに勝てる気がしない Macが2025までにARMへ完全移行するって正式発表を今月中にするって噂がある >>794
割って入る雰囲気がない?本当かそれ?
Amazon設計のARMプロセッサ「Graviton 2」の性能はIntel製CPUにどれほど迫っているのか?
https://gigazine.net/news/20200616-intel-vs-graviton2/ 命令セットの素養とか
浮動小数点演算系命令の新しさとか利用頻度なんかだと
どうしたってarm64が一番新しいからね!
古いコードが未だに利用されかねないx64よりは…ね! >>798
それ、汎用用途ではAMD64に勝てませんと言っているようなものでは
クラウドだとコア数勝負になるしプロセスルールで後れをとっているIntelが振るわないのは当然
てかその程度だと64コア/128スレッドの3rd EPYCに対するアドバンテージは少なそう >>800
> プロセスルールで後れをとっているIntelが振るわないのは当然
なぜそこでインテル擁護?
つうか、グラフの見方を分かってないだろ? 汎用用途はいくら性能が勝っててもなかなか採用できないよ
ソフトないんだからw >>799
内部をRISC化すれば、性能に命令セット関係ねぇ!の流れで進化して来たから、その素養説はちょっと解釈が違うと思うな。
コア数に比例して性能が増加するのは、逆にx86は消費電力的に頭打ちなるから。つまり温度上昇を許容出来なくなるから。
その原因は、x86命令のデコードに余計な電力を食われるから。
素養説も大きくは間違ってないけど、結局x86命令セットは電力効率の悪さがこの結果を招いた。 x86系のデコードは高コストと昔から言われている割にはIPCや周波数でx86を越えられるプロセッサってなくね?
ARMだってコア増やしてスループットを上げる方向だしシングルスレッドで競ったら勝負にならない すでにApple A11以降はSkylakeの倍以上のIPCがあってA14はシングル性能も完全に追い抜いているが >>804
あははは(笑)
IPCについては今まで、Arm社は本気を出して無かったからなぁ。
これからどうなるか?ってとこ
シングルスレッド処理向上で最上級の性能を得たArm「Cortex-A77」のマイクロアーキテクチャ
https://pc.watch.impress.co.jp/docs/column/kaigai/1188094.html Skylake/IceLakeのデコーダは5命令/cycle
Zen2のデコーダは4命令/cycle
Cortex-A77のデコーダは6命令/cycle
A11のIPCがSkylakeの倍以上?10命令デコードしてそれを全部計算できる?
x86の場合実際には2〜3命令/cycle程度だったと思うけどその倍でも4〜6命令もある
いくらARMのデコードが軽くたってロードストアや計算、分岐予測等のコストが軽くなる訳じゃない
トランジスタの数が合わなくね?それ何処情報だよ>>>805 >>807
> Skylake/IceLakeのデコーダは5命令/cycle
残念ながら違う
理論上の最高値が4.2で実際はもっと落ちる
Pentium Pro以降のIntel CPUはすべての命令をデコードできるComplex Decoder1基と
簡単な命令しかデコードできないSimple Decoder複数から構成されていて、Simple
Decoderは1サイクルでデコードできるけどComplex Decoderはデコードに4サイクルかかる
それにSimple Decoderでデコードできない命令が2つ以上あった場合4サイクル経って
Complex Decoderが開放されるまでデコードが止まる
SkylakeはComplex Decoder1でSimple Decoder4で実行ポートは8ポート
だからSkylakeはせいぜい3命令/サイクルぐらいでしかデコードできない
A11以降は7命令/サイクルで実行ポートが13なのでA11はSkylakeの倍以上のIPCがある >>808
一読すると正論に読めるけど、なんか違和感ある。なんだろ? >>808
これか?
https://pc.watch.impress.co.jp/docs/column/kaigai/1208397.html
AppleはCPUコアのシングルスレッド性能の向上にこだわってきた。A12の性能CPUコア「Vortex」は命令デコード幅が7-wideとされており、Arm命令セットアーキテクチャのモバイルCPUコアのなかでは飛び抜けて広い。Arm自身のCPUコアIPでは、現状はCortex-A77の4-wideが最大だ。これは、アウトオブオーダーマシンとしてAppleの性能CPUコアは、すでに効率的な性能向上の限界に近づいてきていることを示している。 >>809
何年か前のcoreでは、複数μOPに変換されるのがComplex Decoderでデコードされて、
1μOPに変換される命令だけ対応してるのがSimple Decoder
Complex Decoderのスループットも1命令/サイクルだったから、違和感ありまくり
それにネハ以降はデコード済みキャッシュを搭載していて、実行時間の多くを占めるループでは
デコーダを使わずに実行できるようにしていて、デコーダへの依存を少なくして消費電力軽減も行ってる 命令の消費クロック数をメモしながらアセンブラで書いてた身としては今のCPUでそんな単純比較できるのかって疑問しかないw
しようがないんだろうけどさ Skylakeのデコーダの数とかはIntelのスライド等で既知の情報だが
>A11以降は7命令/サイクルで実行ポートが13なのでA11はSkylakeの倍以上のIPCがある
のソースが示されていないからな。実アプリでの性能も示されていないし
Skylake
Decoder 5
ALU 4
Load/Store 3
Zen2
Decoder 4
ALU 4
Load/Store 3
A11
Decoder 7
ALU ?
Load/Store ?
ソースは後藤氏の記事 >>814
それにはデコーダの帯域しか書いていないしIPCがSkylakeの倍とも書いていない >>811
Neharemの頃の資料だけど
ttps://news.mynavi.jp/article/20081225-s_nehalem02/menu
の
ttps://news.mynavi.jp/article/20081225-s_nehalem02/2
ttps://news.mynavi.jp/article/20081225-s_nehalem02/3
NeharemのComplex Decoderは単純な命令でも1命令4サイクルで複雑な命令は
もっとサイクルが長くなる
そもそもx86の複雑な命令を1サイクルでデコードできるわけないだろうに
ちなみにApple A11以降にはマイクロ命令のL0キャッシュはなく直接デコードのみ >>816
嘘くさ こんな記事書いてたのかよ
Complex Decoderってのは、最大の命令長に対応するように、先頭に位置してんだよ
それが必ずレイテンシ4以上だったらボトルネックになんだろうが
マイクロコードROM参照しなければレイテンシ1ってのが伝統的な実装だったはずだが >A11以降は7命令/サイクルで実行ポートが13なのでA11はSkylakeの倍以上のIPCがある
のソースを提示できないって事はID:HvJ+uMZLの妄想なのかな >>818
CoreのデコーダのSimple、Complexの区分は変換されるμOPの数のはずだしな
なんか思い込みが強そう 1つのComplex decoder+複数のSimple decoderの構成は大分昔からだし、AMDだって似たような物だし処理系だって百も承知だろう
当然命令がそのように並ばないようにバイナリが生成されるはずでComplex decoderの負荷がどうのと言う指摘は的外れの可能性が高い
そしてコンパイラがSimple decoderを積極的に使うのであればプロセッサもそのように進化するわけで実際にそうなっている
野良で集計された物のようだがこんなまとめ資料がある
ttps://www.agner.org/optimize/instruction_tables.pdf >>820
最適化マニュアルにはマイクロコードROMを参照する命令は避けろって書いてあったはずだし、
マイクロフュージョン登場後はSimple Decoderでも”かなり複雑な命令”を扱えるようになったんだよね
それにデコード済みキャッシュ登場後はIPCはデコード済みキャッシュからの供給数が主体になってて、
これだとIPC6にはなってたと思う そもそも1命令あたりの仕事量は一般的にCISC>RISCでありIPCが高かったとしても実際の仕事を多くこなせるとは限らない ARM64でAMD64相当のパフォーマンスを得られるなら同様の手法を用いることでRISC-Vでも得られそう
で、Apple AはIntelに勝っているの人は何処行ったんだ? 超チープ?かどうかはともかく
大昔考えられた余計なアドレッシングモードがほぼ無いとか
浮動小数点演算命令は新し目のSIMD系命令が標準とか
そこら辺は超有利だよね! 余計なアドレッシングモード?
CISCのメリットとして上げようと思ったくらい便利だぞ
普通の整数計算でもアドレッシング計算命令を頻繁に使うほど x86はSIMDも非常にリッチ
これに比べるとARMのSIMDはうんこ >>827
アセンブラで書くのが便利?
メモリアクセスはペナルティが大きいから過去の話っしょ >>829
今時の高性能プロセッサはアウトオブオーダー実行が標準装備だしロード待ちの命令があっても依存関係のない他の命令から実行していくでしょ
むしろそうなるようにコードを並べるのがプログラマやオプティマイザの仕事 >>829
アセンブラでもコンパイラでも便利
メモリアクセス?
突然どうした? >>830
> 依存関係のない他の命令から実行していくでしょ
> アドレッシング計算命令を頻繁に使うほど
いくら依存関係が無くても詰まるっしょ >>827はコンパイラがそういうコードをはくってこと
アセンブラで手動でやらなくても SIMD系命令に至っては、コンパイラは、もう諦めたと言うか
intrin.hやarm_neon.hで自分で埋め込めや!状態だしな…orz SIMDをコンパイラに丸投げはまだ時代が早すぎる
速度が重要な小さなループは
アセンブラやintrinsicを使った方が良い
x86だと非常にリッチなSIMD命令が使える
AMDはSIMDもチープ 何を使おうがコードの書き方で速度は大幅に変わる
コンパイラは値が変わらない範囲でしか最適化をしてくれない
浮動小数点は計算順番で値が微妙に変わるから最適化しづらい
C言語だろうがアセンブラだろうが
パフォーマンスが必要なら
依存関係を減らしたり最適なデータ構造を考えるのは
プログラマーの仕事 スパコンにはベクトル化&並列化してくれるコンパイラがあるらしい
もちろんどんなコードでも速くなるわけではないようだが >>838
日常にはもちろんしない
パフォーマンスが必要な時はする 【笠原一輝のユビキタス情報局】IntelからArmへのシームレスな移行を実現する「macOS Big Sur」 - PC Watch
https://pc.watch.impress.co.jp/docs/column/ubiq/1260735.html
新Mac CPUは独自の「Apple Silicon」に。既存アプリもiPhoneアプリも動作 - PC Watch
https://pc.watch.impress.co.jp/docs/news/1260709.html 【後藤弘茂のWeekly海外ニュース】AppleがArmベースのSoCをMacに採用する背景 - PC Watch
ttps://pc.watch.impress.co.jp/docs/column/kaigai/1261696.html
同クロックならAMD64に匹敵しそうだけど、絶対性能で勝れる理由はないって感じか >>844
どうだろう?
x86は命令デコードのエリアが大きく、同じダイサイズならより実行ユニットに振り向けられるArm優位ではないかな。
だとしたら、もしかすると超えているかもしれない。証拠は無いけど コスパワッパのARMじゃx86にシングル性能で同等になるのは不可能
マルチ性能はいい線いくかもしれない >>844
> ttps://pc.watch.impress.co.jp/docs/column/kaigai/1261696.html
> たとえば、Zen 2は4命令デコードだが、実行パイプは11パイプだ。雑に言えば、Arm系の6-7命令デコードCPUは、
> 実行パイプで比較するならx86/x64系CPUの4-5命令デコードクラスだと言えそうだ。
ここが意味不明なんだけど
Zen2
ttps://en.wikichip.org/w/images/thumb/f/f2/zen_2_core_diagram.svg/1800px-zen_2_core_diagram.svg.png
Cortex A77
ttps://en.wikichip.org/w/images/thumb/8/81/cortex-a77_block_diagram.svg/1238px-cortex-a77_block_diagram.svg.png
Skylake
ttps://en.wikichip.org/w/images/7/7e/skylake_block_diagram.svg
Execution EngineやMemory Subsystemのついて、Cortex A77の実行ポート12なのに対してZen2は11でSkylakeは8
Reorder BufferがZen2やSkylakeが224entryだけどCortex A77は160entryなのと、Zen2の浮動小数点処理が4パイプ
あること以外、CortexA77の方が上だよね?
なんでARMの方が下みたいにいっているんだろう? Samsung Exynos M4だとZen2に対する浮動小数点処理以外全部上か
ttps://en.wikichip.org/w/images/4/47/mongoose_4_block_diagram.svg
少なくともSkylakeは追い抜いているよね? ARMとx86の命令を比べれば
ARMのチープさがよくわかるよ
IPCが高くても性能は糞 >>851-852
Execute Engineでの比較なんだけど?
命令セットアーキテクチャが関係してくるのはデコーダのレイヤーでしょ
命令を解釈したあとアウトオブオーダー処理して実際にExecute Unitに入れて実行する部分が、
・Skylake
6マイクロ命令ディスパッチ、8マイクロ命令実行、4整数ALU、2浮動小数点ALU(整数ALUとポート共有)、3アドレス生成ユニット(+StoreData)
・Zen2
6マイクロ命令ディスパッチ、11マイクロ命令実行、4整数ALU、4浮動小数点ALU、3アドレス生成ユニット
・Exynos M4
6マイクロ命令ディスパッチ、12マイクロ命令実行、4整数ALU、3浮動小数点ALU、3アドレス生成ユニット(+StoreData)、1分岐処理
Execute EngineレベルではSkylakeよりExynos M4が上だから、IPCも実際の処理性能も上でしょ? >>853
1命令あたりの処理量が違う
Execute Unitの >>854
整数演算ALUの性能は同じだよ
浮動小数点ユニットはあいまいだけど
要するにSkylakeは整数演算と浮動小数点演算の処理能力は1サイクルで両方合わせて
最大同時4実行だけど、Zen2は最大整数演算4+浮動小数点演算4=同時8実行で、
Exynos M4は最大整数演算4+浮動小数点演算3=同時7実行になるわけ
命令セットが何であれ1サイクルの処理能力はSkylakeよりExynos M4のほうが上でしょ?
あとSkylakeは6マイクロ命令ディスパッチ、8マイクロ命令実行、4整数ALU、2浮動小数点ALU
(整数ALUとポート共有)、3アドレス生成ユニット(+StoreData)に加えて2分岐処理があるね >>855
同じじゃないよ
命令知ってていってんの? >>856
命令は関係ない
ALUだよ?算術演算ユニット
ハードウェア回路レベルの話 >>857
intelでいうところのuOP命令
これの処理量が違うの ただのレジスタ同士のスカラ整数加算みたいな単純なのでも
レイテンシやスループットが違ったりする
1命令で出来ることも違う てかなんでIntelだけ古いSkylakeなんだ?Exynos M4は2018年からだしZen2は2019年からだ
比較するならIce Lakeあたりじゃないの。AGUとStoreDataが+1されて10ポートになっているし x86は
32bit小数の積和が16個出来たり
整数の積和が16個出来たり
ビット数カウントが出来たり
任意の3オペランド論理演算が出来たり >>852
> IPCが高くても性能は糞
とは言えないみたいよ、マジで
AMD Ryzen 7 3700X vs Apple A13 Bionic
https://gadgetversus.com/processor/amd-ryzen-7-3700x-vs-apple-a13-bionic/
Zen2 A13
Base frequency 3.6 GHz 1.8 GHz
Turbo frequency 4.4 GHz 2.7 GHz
Geekbench 5
single core 1.251 1.331
multi-core 7.897 3.364
これだと比較出来ないからGHz辺りで見ると、
Geekbench 5 / Base frequency
single core 0.348 0.739
multi-core 2.194 1.869
シングル性能は倍。
マルチスレディング(16vs6)の力技でZen2でやっと上回ってるw >>858>>861
ALUの話をしているんだけどCPUの構造全くわかっていないのかな?
FPGAとかでCPUを実際に作ったことある?
まあ自分も担当したのはCPUシミュレータとラベル付きアセンブラと整数演算で浮動小数点
演算するルーチンの実装だけど、ALUぐらいなら自分でもVHDLで実装できるぞ
それと命令セットについても何か勘違いしているね
実際の命令セット見てみたら
ttps://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html
ttps://developer.arm.com/docs/ddi0487/latest >>862
その数字は実態を反映しているのか?マルチコアの値をコア数で割るとA13はボロボロじゃないか >>863
同じ処理なら
アーキテクチャによらずに同じ内部命令になって
それらの内部命令はスループットもレイテンシも全て同じだって?
バカ? >>864
A13は高性能コア2と高効率コア4だから高効率コア4の性能がそれほどでもないだけかと
>>865
もう一度言うけどALUって何かわかる?レジスタファイルってわかる?
組み合わせ回路と順序回路の違いわかる?
回路レベルの話をしているの
何もわかっていない的はずれなツッコミやめて >>860
同じレベルのブロック図があれば使ったんだけどここには載っていない
ttps://en.wikichip.org/wiki/intel/microarchitectures/ice_lake_(client)
どこかにある? 加減論理演算1bitシフトしか出来ないALUから
乗除算バレルシフタビットカウントが出来るALUまで 積和やなど複数の演算を1回で出来るのが普通なのに
全部同じ? >>866
> A13は高性能コア2と高効率コア4だから
そういやそうだな。
えっ、2個でここまで肉迫?とんでもない性能だな 過疎スレが突然盛り上がって何事かと思ったら…
appleは宗教だから、中身にハムスターが車輪回して動かしてたって買うさ >>849
> > Zen 2は4命令デコードだが、実行パイプは11パイプだ。雑に言えば、Arm系の6-7命令デコードCPUは、
> > 実行パイプで比較するならx86/x64系CPUの4-5命令デコードクラスだと言えそうだ。
> ここが意味不明なんだけど
ARMが下と言っている訳ではなく、「大雑把に言えば同じ」と言っているかと。
その直前に「x86/x64系のハイエンドCPUは、4から5命令デコード/サイクル」とx86が下だと誤解を招きかねない事を書いているので、その補足説明ですね。 デコード/サイクル
を比べてもそれだけじゃなんの意味もない
命令あたりの処理量も違うし
uOPキャッシュもある 広く使われているプロセッサを設計しているメーカーが
デコーダの能力と実行パイプの本数を大きく誤るとは思えない
>>862は何かボトルネックが存在しそう >>876
実際の使い方考えたら、単純な演算速度よりも、外部バスの速度が効いてくる。 先日知人と話してて過去にLPC1114を使ってた話から
今どうなってんのかと秋月見たらDIPはもうディスコンなのな
TSSOPならまだあるみたいだけど もともとが気まぐれなんだろうね
絶対に数出ないもん >>888
XC32の対応デバイスリストには、既に有ったと思う。 >>892
PIC32Cとかって名前になってた気がする 【経済】 アームを3兆4000億円超で買収検討か 米半導体エヌビディア、ソフトバンクグループから [影のたけし軍団★]
http://asahi.5ch.net/test/read.cgi/newsplus/1596249352/ ハゲは結局ARM買収して何したかったんだか?
もうこの期に及んでは将来ビジョンなど語る余裕もなく資金繰りのために
売却するしかないだろな
今のビデオカードにCPUコア埋め込むとかなんかメリットある? >>866
>もう一度言うけどALUって何かわかる?レジスタファイルってわかる?
>組み合わせ回路と順序回路の違いわかる?
さすがに
ここ電電板だしww
pc板見てたのかと確認したわ
pc板のCPU関連スレも見てるんで。 誰も見てないからココに愚痴を書いておく
この前、旧atmelのSAM3S等用の基板にSAM4SD16載ってけてみたんだ
でUSBでSAM-BA動くかな?と思って繋げたら
ウンともスンとも言わない
と言うか不明なデバイスと出る
調べたら、SAM4SはUSBでSAM-BAダメとか言うエラッタがある
仕方ないからシリアルで繋げても「こんなチップ知らん」
結局、SAM4SD系はSAM4SD32だけしか標準でSAM-BA対応しないらしい… Arm、プロセッサ内でOSを動作可能にした「Cortex-R82」
〜64bit化されたArmv8-Rのストレージコントローラ
https://pc.watch.impress.co.jp/docs/news/1274842.html
> Cortex-R82は、Cortex-R8の後継となるリアルタイムプロセッサで、Armv8-Rアーキテクチャを採用。
> Cortex-Rファミリとしては初の64bitをサポートする。
> 最大8コアで設計でき、Cortex-R8と比較して性能は最大2倍に向上した。
> また、最大1TBのDRAMにアクセスできるようになっている。
>
> また、SIMD(Single Instruction, Multiple Data)演算のための命令「Neon」もオプションで利用でき、
> 処理をさらに高速化することも可能。
> データ保護を行なうArm TrustZone技術も用意されている。 >>905
ニュース見たけど、リアルタイム処理するのに64bitとかMMUって必要なんか?
演算時間に32bitと64bitは差が無いし、浮動小数点演算に関係無いし、固定小数点演算にそこまで精度必要無いし。
誰か解説してくんない? >>906
主にストレージデバイス用だよ
Windowsでも32bit Windowsより64bit Windowsの方がディスクアクセス速いし
HDDやSSDのコントローラならHDD、SSDの容量的に64bit演算を多用するからね
>Armは4日、組み込み向けプロセッサ「Cortex-R82」を発表した。
>おもに同社が約85%のシェアを持つとするHDDやSSDといったストレージデバイスのコントローラなどとして利用される。 >>907
えっ? 今さら? もう遅くね?
WD、2019年からNAND/HDDのコントローラを順次RISC-Vベースに移行
https://pc.watch.impress.co.jp/docs/news/1128863.html >リアルタイム処理するのに64bitとかMMUって必要なんか?
リアルタイム云々ではなくてOS乗せる前提というなら必要で間違ってはいない
メモリ保護管理機能がないと1つのプロセスが暴走してOS全体が壊れる
OSが動くとDDR4などRAM上で動くので小規模組み込みのフラッシュのみという訳には
いかないからな …一応、MMU載ってない奴でも、メモリ保護の為のMPUは載ってるから… >>910
なに言ってんだか。
一つでもプロセスが暴走したら、組込みシステムとしては致命的。
OS保護しても意味がない 日本がARMなど買収しても意味は無く、もてあますだけだから早く売却してしまった
ほうがよいだろうとは思うね。買収額も高すぎ。
NVIDIAはソフトバンクよりもテクノロジー企業なのでNVIDIAであればARMをさらに
成長させることが可能だろう。 ARMは薄利多売で普及させた企業だからNvidiaとは真逆の経営方針と言える。 ソフトバンクは投資会社のような存在だし通信会社は基地局や端末ハードは外注で
アンドロイドのOS開発も一切関わってない。
ARMの命令セットや内部設計に助言できるほど今の通信会社はノウハウ持ってない。
テクノロジー企業のARMは同じテクノロジー企業のNVIDIAと近い。
投資会社とテクノロジー企業ほど乖離してないからNVIDIAはうまくやると思うぞ。 >>919
IntelのAltera買収はうまくいきましたか?Xilinx一色になっているように見えるが Cortex M系で、メモリが16MB程度載っている製品ってありますか?Spresenseよりリッチなことをしたいのですがなかなか探せてなくて。 >>921
DigiKeyで条件検索すればすぐ判るのでは? >>921
16MBものSRAMを内蔵しているcortex-mはないだろ
外付けSDRAMすれば良いんじゃないか >>926
ありがとう。あるんだね。このぐらいの消費電力ならA系でもありなので助かります! >>927
そもそも、そんな大量のRAM何に使うん? >>929
なんちゅうか、もっと具体的になにやりたいん?って事 >>930
遅くてもいいのですが、1024x1024とか2048x2048の画像の簡単な処理(座標変換など)をしてフレームバッファに書きたいのですよね。今はグレースケール2bppぐらいに抑えてなんとかしてますが、もうちょっとbpp欲しいです。 >>930
5chにはコミュ力がない奴が普通だからな
探している物はcortex-Mで16MB,でも(消費電力あえば?)AでもOKなんです。
実はARMでもなくてもOKだったり。
エスパー、高脳でないとほんとに探しているものは分からないと >>931
そう言うのだったらARMとは全然ちがうけど、
Jetson NANOとかでフルパワーで動かすと楽勝で処理出来そう >>931
>>926は情報少なそうだね
Raspberry Pi ZeroやRaspberry Pi Zero Wはどうなの?
消費電力はこんなものみたいだよ
https://www.usagi1975.com/052520180823/ >>932
ワンチップで16MBのSRAM持ってるマイコンはないだろうね
外付けなら16MBも512MBも大して消費電力変わらないのでは? >>936
それなら QSPI SRAMがより良くね? >>939
あれは今のところ一回こっきり。性能向上版はいつになるやら >>941
リナウス トパーズ?氏も欲しいと言ってるみたいやね、Linuxが動くならw 勘違いしている人を少なからず見かけるが
A64FXはSVEが速いのであってARMv8は特段速くないだろ
出回っているARMv8コードで○TFLOPS出るわけではない >>943
A64FXはArmの皮を被ったSPARCだと聞いた事があるなぁ。
シングルスレッドの処理能力が全体に効くとも聞くし、そこそこ強化されてんじゃね?知らんけど >>944
そりゃ新しいぶん先代よりは強化されているだろうが
ARM CPUとして使った場合、競合CPUと比べて
ぶっちぎりで速いわけじゃなくね
どうせベクトル化できるコードを用意して専用コンパイラで
コンパイルしなきゃいけないんだしARMである必然性もない そうは言っても
今まで、arm命令セットでさ
デスクトップ以上の発熱とか許容するCPUにしたてた会社が少なすぎてw
比較出来る対象が(ry AMD64なりPOWERなりと比べればよくね
HPCなんて計算速度が速ければ命令セットなんて何でも良い世界なんだし >>945
そもそもスバコン用のプロセッサを普通のプロセッサと比べて意味あるのかな?
I/Oやメモリアクセスはメチャ強力だから、もし整数演算が悪くても見えないんじゃね?知らんけど
ちなみにx86と単体で比較すると1.2倍位。極端に差は無いね。
https://news.mynavi.jp/photo/article/20191206-933874/images/014l.jpg >>948
比べる意味はほとんどないと思うよ
でも富岳をもってARMスゲー言う人をしばしば見かけるような
もっといえばA64FXはTSMC 7nmであり日本製ではない
あれで「日の丸半導体の復活」などと謳うのは恥ずかしい・・・
NECのVEもTSMC 14nmだったはずで日本に最先端のプロセッサを
製造できる能力はない
そのグラフだけどx86はIntelにしろAMDにしろメモリはDDR系だろう
A64FXはHBM2搭載で1.x倍だとコスパは相当良くないとも言える
やはりSVEをブン回して初めて意味のあるチップかと >>949
実際Armは凄いんでないかい。
AppleのM1チップはx86を凌駕してるっぽいし >>950
M1のアドバンテージはTSMC 5nmとメモリ混載と専用OSだからじゃね?
それにM1が5GHzで回ればすごいかもしれないがそう都合良くはいくまい
ワークステーション等のハイパフォーマンスレンジでも同等のアドバンテージを
保つのは難しいと思う >>952
今、ワークステーションなんかあったっけ?絶滅したんでない? >>949
工場がどこにあるかそんなに重要か?誰が設計したかだろ?
DDRだから?そりゃそうさ、片や汎用品。片やスパコン用に作られた専用品。 >>953
HP、Dell、Lenovo、FUJITSU・・・etc
ワークステーションと称するモデルを売っているようだが
>>954
国防戦略的に見たらかなり重要。核物理演算に強いスパコンは核兵器開発技術の一環と見なされる
それが内製できれば核抑止力としての効果を持つ
かつてトップを独走していた地球シミュレータ(プロセッサが内製)はこの理由でアメリカに大分警戒されていた
スパコンだけじゃなく核物質の生成・濃縮技術や全段個体ロケット技術なんかも同様
日本のこの辺の技術は昔より落ちているし、隣国になめられることが増えたのは当然の流れ
逆に中国は半導体やスパコンも力を付けつつありアメリカが警戒するのも当然と言える 「句読点」とバカにされると思い無理してさらにバカにされてるw なんで高性能になったmicro:bit V2は日本で人気出ないの >>955
頭おかしいのかな。スパコンがあっただけでは核抑止力にはならない。
スパコンの存在は兵器ではないので核抑止力はない。
シミュレーションだけやって脳内だけで核抑止力なんてのは一番マヌケ。
コンピュータの計算能力は日本では安全保障分野には何も関わりはないから。
PEZYの詐欺師のように勘違いした奴がいるから日本のスパコン計画がおかしくなるんだよ。 素人はCPU直叩きなんてしないから
要はコスパと入手性と使い方情報
冬休み用にmicrobitでも買うかな
でもesp32もまだいじり倒して
ないんだなこれが >冬休み用にmicrobitでも買うかな
とりあえずTinkerCADで遊んでみるとか Intelが今年後半にARMチップ開発を発表か?2022年〜23年に供給開始の可能性
https://iphone-mania.jp/news-337261/ RISC-VはピンキリだがSweRVとかならCortex-M7やRXv2とも遜色ない性能 Raspberry picoのPIOとかいう謎ペリフェラル、LPCのSCTを思い出すなあ 最近の安価なATSAMは、いつの間にか50円切る勢いなんだな。
一方、STマイクロは低価格競争を諦めた感じ。
50円切るとロジックIC替わりに載せる事が出来そう、低速だけど。 >>972
STM32は、今のひっ迫状況で値上がりしているだけでは?
値段どころか、発注できない。発注してもいつになるかわからない、みたいな感じ。
そりゃ流通にあるの部品は値上がりするね。
価格競争以前に、Microchipの供給能力がすごいな、って見直してる。 売れてなかったから在庫余ってるんだろ
とは言わない、優しさを感じる… >>973
STマイクロはどうなんだろうね。
MicrochipのSMSC部門が一時タイトだったけど、Atmel部門はそうでも無いのかな。
しかしここで旧Atmelが出てくるのは予想外。てっきり旧FreescaleがSTマイクロに挑むと思ってた microchipでも、電源系ICの一部とか品薄だったりしなくもない M1がCore i9を越えたとニュースになっているが…
ArmにはArm命令(32ビット)とThumb命令(16ビット)の2つの命令体系があるが、x86が同じ事をしないのは何故なんだろう?
x86は拡張に拡張を加えた面もあるが、デコードしないと命令長が不明の面もある。
ならば頻度が高い従来命令と1対1で対応する新しい命令体系を作っても良さそうなもの、Thumb命令みたく。
したくとも出来ない理由があるんだろうか? Apple Siliconの優位性はプロセスの優位性
AMD比で1世代、Intel比で2世代進んでいるからその分有利なだけ
アーキテクチャ上圧倒的に有利なわけではない Apple SiliconがIntelより二世代もプロセス進んでるとか初耳。 へーすげーなと思ってググったら大嘘だった。セミコミメーカーですらなかった。 Intel も TSMC に委託するから同じになるだろ。 M1(TSMC 5nm)比でトランジスタ数はCezanne(TSMC 7nm)とTiger Lake(Intel 10nm)が70%程度
Rocket Lake(Intel 14nm)だと半分以下
トランジスタ数の差が性能差だが現状モバイル限定。デスクトップ以上のプロセッサに対する
性能的な優位性はない
>>983
委託するにしても一部だけだろ。先端半導体を捨てるようなことはするまい 並列性能上げたいならトランジスタ数を増えればコア数とかいろいろ増やせるけど、
clock上げたいならまだIntelの14nmが最強なんでしょ? 速度はIntel 14nmが最強だが消費電力も最強だぞ
本気出すとと300Wとかだしな。液冷必須だ >>951
ARMは64bitに対応した時に64bitの命令セットは一新してるから >>978
32bitのARMのA32と、Thumb-2のT32とそれに加えて64bitのARM命令セットのA64がある
ARMでは64bitのA64オンリーのCPUも設計可能
64bitのA64はA32とは全く違う命令体系 あんまりバイナリ互換に拘ってない
x86みたいには
まあ土俵が違うんだろうけど 最近のマイコン内蔵のタイマにはパルス幅を計る機能が付いているけど
DMAを使って両エッジで連続的に計る場合に取りこぼさない最小幅を知りたい
もしくは取りこぼさないバスやDMAのクロック等の各種設定でも可
RX
→マニュアルのタイミングチャートからおおむね算出可
STM32
→マトリックスタイプのバスを経由する上にラウンドロビン固定なので難しい
マニュアルにもバス動作に関する詳しい情報は見あたらない
マトリックスの切り替えが発生しないような状況を想定しない限り安定動作は難しそう
LPC
→バス調停の優先順位は付けられるみたいだけど遅延量の算出方法はよく判らない
LPCのバス回りの動作に詳しい人がいたら教えてもらえると嬉しく・・・
あと行けそうなら100pin級でM4F/M7搭載の安価な評価ボードを紹介してもらえると嬉しいです
NXPスレで聞こうと思ったらそんなものはなかった・・・ >>991
というかどうやって調べるんだ?
ペリフェラルも少なくバスもシンプルなマイコンならともかく
今時の32bitマイコンはバスが何本も走りペリフェラルはてんこ盛り
バスの動作状況なんて観察できないし
関係するであろう不明なパラメータもてんこ盛りだし
国内系のARMマイコンでもこの辺の記載は少ないんだよね
TXZとかはそれっぽいこと書いていないっぽいし、RAですら
I/Oレジスタの書き込みサイクル数のページがない(RXにはある)
RAはDMAのタイミングチャートが載っているからまだマシだけど アホだな
厳密にタイミングが必要ならそもそも予測不能なデバイス使っちゃいかんよ
CPLDとか単純なロジックで測るべし
それだってスレッショルドとか気をつけないといけない用途もある
GPSのPPS監視とかね DMA、FIFOなどざっくり調べてから
実測で詰める
GPSのPPS監視?
これより簡単な監視
なかなか思い浮かばない 具体的に、何Hzぐらいのパルス列をどれぐらいのカウント値でどれぐらいの時間連続測定したいの? >>996
これ中国でよくある商慣習のバリエーションで、日系企業も苦労している。
購買の担当者が納入業者からリベートを受け取ったら日本なら背任罪だが
中国では通常の商慣習として法的にも認められている。 >>999
「中華人民共和国反不正当競争法」「2017年修正不当競争法」「関与禁止商業賄賂行為的暫行規定」とかあるけど、
「法的に認められている」の根拠は何?
適当なこと書くなよ。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 1696日 21時間 58分 58秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。