【Coretex-M3】 やっぱARMっしょ３ 【最安$1.47】

教えてください。
ARMマイコンの基板付きの本が、CQ出版でいろいろ出ています。
でもARMの何が嬉しいのか、わからずにいます。
H8とかSHとかPICが使えれば、全然満足ですし、
いろいろ考えてみたのですか、ARMに行く理由が見つからないんです。
・低価格→マイクロチップがやってくれそう
・高速→SHがある

すみません、宜しくお願いします。

>>293
無理に使う必要はないのではないでしょうか。

同じ内容でＰＩＣスレを荒らしていた奴
ARMを使う必要が無いなら使わなくて宜しい・・・とＰＩＣスレで結論

>>293
仕事じゃないなら、何使ってもいいだろ。
そんなことも人に聞かないと分からないの？
何所の大学？

仕事の場合、ARMじゃないとダメな理由は色々ある。
特に、カスタムSoCを作る場合はARMかMIPS以外に選択肢はほとんど無い。

SHやRXはIPコアとして流通していないから、
ルネサスに大金を払って作ってもらうことになる。

SoCを作っている半導体メーカーならARMコアのライセンスは
必ず取得しているので、東芝でも富士通でも海外メーカーでもOK。

あとは、開発ツールが充実してるってのは大きいよね。
もっと高性能なプロセッサは作れるけど、コンパイラなり
デバッガなりを揃えなきゃなんないし。
ハードウェアIPもARMのバスに合わせてあることが多い。

みなさん、ありがとうございます。
>>294
今のところ使う予定は無いのですが、
・CQ出版で、ARMだARMだ、と何冊も本が出てるし、
・トラ技も特集組んでるし、
・XilinxもFPGAの中にARM入れようとしてるし、
なんでかな?と思ったのです。

>>296
>そんなことも人に聞かないと分からないの？何所の大学？
それは言えませんが、あちこち調べて見ても「コレだっ!!」という理由を言っている人もいないみたいなので、
このスレで聞いてみました。ごめんなさい。

>>297
ありがとうございます。
>カスタムSoCを作る場合はARMかMIPS以外に選択肢はほとんど無い。
理由はこれですね、たぶん。良くわかりました。
少量他品種の製品を売り出すのに、ASSPでは時間と費用の面で不利になるけど、
SoC+IPを使うことで、安く早くできる。さらに、同一チップ上に周辺回路、特に
メモリなどを置ければ、アクセスも高速で、かつ小型にできる、でしょうか。
FPGAにマイコンコアを乗せれば似たようなことはできるが、メモリは小さいし、ADも載らないし、
IPはXilinxから高いお金を出して買う必要がある。ということですね。

僕のように小規模使用では、FPGAにマイコンを入れる程度で良いみたいです。
長年の疑問が解けて、スッキリしました。
みなさん、どうもありがとうございました。

>>293
島国のマイコンなんぞ使ってたら世界で量産できん
性能差があまりないのであれば外国産を使おう

>島国のマイコン
ああ、グレートブリテン島の ARM のことね。

確かルネサスは、Super-Hって会社を作ってSHコアの外販をもくろんでいた
けど、まったく売れずに会社も既に解散したのではなかったかと。

ttp://webcache.googleusercontent.com/search?q=cache:533BUhtDil0J:techon.nikkeibp.co.jp/members/01db/200104/1012960/+SH%E3%82%B3%E3%82%A2+%E5%A4%96%E8%B2%A9&cd=5&hl=ja&ct=clnk&gl=jp&source=www.google.co.jp

迷走は今も昔も変わらず
ttp://japan.renesas.com/company_info/news_and_events/press_releases/press_release20060223.jsp

東芝、富士通だったらどっちがいいかな

>>301
わろた

>>293
> ・低価格→マイクロチップがやってくれそう
スレタイに書いたけど、PICとそんなに値段は変わらないよ。

> ・高速→SHがある
SHは、遅い割りには高い。
SH7785/7786は600MHz。でも、その値段でARMならGHzを超えてる。

もう三つ目の違いはペリフェラル。
ARM系ならよりどりみどりだけど、SH-2AではEthernetを選べば他の機能が劣るとかね。

>>305
SHはもはや時代遅れでしょう。

汎用I/Oの機能で比べても、きょうびピン入力のレベル変化を任意のエッジで
検出して割り込みかけるとか、プルアップ、プルダウン設定の選択くらいは
ごく普通だけど、単純なI/O方向の選択くらいしかない。

あと、UARTやタイマなど内蔵I/Oも機能によって使用するピンが固定だし。

ARMのマイコンだと、
好きなピンに好きな機能を、割り当てることができるのでしょうか?
だったらいいですね。H8は、AD入力ピンはデジタルI/Oだと入力にしか使えない。
出力を多用する使い方だと、あの入力ピンの余り方が恨めしい。

LPC1114で楽しんでいます。
IARでデバッグモードでBlinkyの動作を無事確認（簡単でした）。
そこで、Releaseにして、Blinky.hexを出力。
これをFlashMagicでUART経由で書込み ・・・ 動作しない。

どなたか、原因が分かる人いますか？

マイコンのアーキテクチャとは関係ないが、PICやAVRでさえ、もA/D入力に
割り当てられるピンをデジタルI/Oで使う場合、入力にも出力にも設定できる。

またこれもARMに限った話ではないが、最近のマイコンは、UARTやタイマ等の
機能で使うピンも、全ピンに割り当て可能ではないが、ある程度入れ替えが可能
なので、回路設計の自由度があがる。

ルネサスのマイコンはもはや時代遅れ。

日本の仕事はひも付きビジネスが多いのでARMの出番は少ないな
海外の仕事が多くなってほとんどARM開発になっているけど　ｗ

ひも付きって？

本音と建前の違いとか
裏でなにかやってるとか

IARの無償ｺﾝﾊﾟｲﾗって登録時、会社名とかﾌﾟﾛｼﾞｪｸﾄなんたら・・・で個人ではアレだな

審査しているわけではないから、何でもいいから埋めとけばよい。

学生時代、大学名借りて登録して、その後もずっと個人で使ってる。
つーかルネサス使わなく成って、ARMかMIPSばかりなのだが、勝手に
お知らせメールが届いてる。

>>309-310
>ルネサスのマイコンはもはや時代遅れ。
>日本の仕事はひも付きビジネスが多いのでARMの出番は少ないな
>海外の仕事が多くなってほとんどARM開発になっているけど　ｗ
これに尽きるな。紐付きでがんじがらめの縛りのキツい開発環境ばかり。
HEWのver.upのお知らせメールが届く度にウゼェって軽く精神的トラウマ。
普通にGCCとmakeでサクサク開発できるARMやMIPSの開発仕事が
多く成って来るのは必然だな。

GCCってデバッグできるの？

デバッグできなきゃどうやってバグ取るんだよ！

もしかして、GCCのバグを取るの？

デバッグできるんだ。
GCCよりGUI対応の統合環境の方がメジャーなので、GCCではデバッグ
できないか、とても大変、と思っていた。

>>315
HEWのバージョンアップはしないようにと開発チームで取り決められてたｗ

>>315
ルネサスの肩を持つわけではないが、別にH8だろうがSHがろうが、GCCと
makeでの開発は可能な点は変わらんと思うが？ハッキリ言って、マイコン
のアーキテクチャや機能となんら関係ない。

HEWは単なる統合開発環境の1つに過ぎず、GUIベースのIDEがよければ、
KPIT-GCCだってEclipseと組み合わせる選択もある。(というか、KPITも
HEWへの対応は既に打ち止め)

windowsに特化したからねえ、HEW
もとはunix系？だったのに

>>316 >>317
話がかみ合っていないような気が・・・

「デバッグできる？」と聞くよりも、「デバッガはあるの？」と聞けば
誤解される余地は無くなると思うぞ。

>>320
純正があれば純正使えって言われるだろ。
それともそのへん自由ですか、いいですね。

つまり、H8, SH + HEWがある人は、無理にARMを使う必要は全く無くて、
またARMには、H8, SHから移行させるほどの魅力は無い、
ということで良いでしょうか?

HEW以外使えないだけなんだろうな

H8,SHなマイコンからARMに移行すると、モノによってはハマるかも
わかってる人は平気かもしれないけど

>>324
長所短所なんて人それぞれだし
現状で困ってないなら移行する必要はないでしょ。

>>327
同意。H8, SHで済むなら、その方が良い。
他のマイコンに比べて、ARMマイコンだけが特に優れているワケでもないし。
世の中には、多くの人と違うこと(違うもの)を使うことが、
「格好いい」と勘違いしている人が多い。

資産とか慣れとかしがらみあるわな
アーキやなんかでarmは世辞にも綺麗とは
言えんし
この辺はintelと同じでイナーシャついてるから
armで決まりだわな

困った時には既に手遅れ。
新しいことは余裕のあるときにこそやらないと。

NXPのARMは、Sampleの出来が非常に悪く、動作しないことが多い。
ARMは難しい、というトラウマが出来つつ、悩んでいます。

>>331
NXPは雑誌付録で飛びついたら結構ハマった。
ドキュメントが酷い、まぁ電子マニュアルだから検索でなんとかなったけど。
チップ自体の出来はいいと思った。

セキュアで８７６５４３２１０って書き込みするやり方が凄く悩んだｗ

> 世の中には、多くの人と違うこと(違うもの)を使うことが、
> 「格好いい」と勘違いしている人が多い。

CQとか、オライリーとか、本を売りたい思惑と、それに繋がってる連中が
「トレンド(w」を自作自演している気がする。正直、高級言語でARMを使う
だけなら、新らしいコトと言えるほどのものはない。

ARMに関しては、TI(旧Luminary Micro)の方がサンプルが充実しているし、
チップ自体も高機能と思い、評価ボードも手に入れ、無料セミナーにも出た
が、なにせDigikeyでも在庫がなくて石が手に入らない。

仕方ないので、NXPを使っている。NXPは汎用I/Oで使いたい場合、連続した
ビットが確保できるポートが少なく、切り替えて使う周辺I/Oのピンもほぼ
固定なのでハード設計の自由度が低い。

H8とかSHから移行するなら、単にI/O操作とシリアル程度でよければ、東芝の
Cortex M3がええんでないのかな？国産だし。(w周辺が簡素(しょぼいとも言う)
ので、その分動かすまでに設定が必要なレジスタ数は少ない。

>>332
例えば、I2Cのサンプル。
書込みは成功するけど、読込みは失敗。
データが1バイトずれたり、ハングアップしたり・・・
割り込み方式からポーリング方式に変更しようかと、思案中。

>>334
案外、エラッタ(ハードのバグ情報)とか出てないの？

読み込みが失敗するということは、相手デバイスの上限を超える動作クロ
ックを与えて読み出そうとしているとか、プルアップ抵抗が大きすぎて、
Hレベルの回復が遅れているとか、別に原因があるんでない？

プルアップ抵抗が小さすぎて、読み出しデータを送出(SDAを駆動)する相手
デバイスでLレベルまで電流を十分に引き切れないとか。

>>334
IICマスタに限るならBitbangで十分だと思う。

>>335
プルアップは2.2kΩで10kHzまでクロックを落としてもNGでした。

>>336
Bitbangって？

>>337
>Bitbangって？
ソフトウェアでビットを上げ下げすること。
ttp://en.wikipedia.org/wiki/Bit-banging

だけどIICをbitbangって、CPUが勿体ないような気がする。

>>338
ソフト制御I2Cは持っているので、手間はかからないのですが、
さすがにI2Cモジュールがあるのに・・・

NXPのサンプルは、入力割り込みサンプルも、ハンドラールーチンの
名前が違っていて、ハングアップするなど、ずさんなので、ユーザーズ
マニュアルを見れば解決できそうな気はします。
しかし、こんなに手間がかかるとは、という状態です。

やっぱり組み込み分野は日本が優秀だったのだな、という事を思い出すな。
IARのIDEもなんかHEWよりも貧弱だし。VC++以下だから。
そもそもARMのビジネスモデルに問題があって、開発環境なんて単体で利益上がらないだろう。
MSのVC++だってOS売り上げから投資に回しているだろうし。
ARMは設計、チップ、開発環境が別個だから、デメリットにもなってる。
台湾で苦労して政府がARMのソフトウエアに投資してるのも、これが原因だろう。
商売が下手というか、これはどうにもならんね。アーキテクチャは優秀なのだが。

ARM以外にもColdFireとか、Powerとかあるのだから検討してみるといいよ。

マイコンも高性能になっていくとC#とかで開発って方法もあるっちゃあるし
性能を最大限に引き出すとかしないなら「アーキテクチャなんてどうでも良い」
って流れも今後はありかもねん。

>>399
ところで、1つ気になったのだが、書き込みが成功と判断した理由は？
実は書き込みの時点で失敗していて、その後に読み込んだ値がおかしい
可能性は？

>>342
もはや、命令アーキテクチャより、内蔵周辺機能やライブラリの充実度に
移っている気がする。ソフトはハードのオマケと扱ってきた日本メーカー
凋落の原因もそこにある気がする。サポート部隊なんて、登録派遣や嘱託
に丸投げだし。

ちなみに、C#はフレームワークがメモリを食うし、ガベコレがあるので、
リアルタイム応答が要求される組込製品には使えんでしょう。さしあた
ってC#を使うメリットが見当たらない。

>>343
NETMFをTOPPERSの上で動かして、リアルタイムを要求する部分は
TOPPERSで動かすとかそういうながれはありますよ。
グラフィック周りとかフルに入れるとさすがに数MBのメモリは必要ですけどね。
意味があるかどうかはわからないけど最小構成なら内蔵フラッシュとメモリで動く

C#かぁ、素人にUIを実装させる部分くらいか
割り当てるメモリが広大でなければガベコレも瞬時に終わるかな

ガベコレの速度は、メモリ領域の大きさではなく、分断された数に依存では
ないか？それに組み込みは、デスクトップとは比べ物にならんくらいCPUも
メモリも遅いし、バス幅も狭い。

DotNET Framework のMicro版だっけ？あれを載せても、それだけではGUI廻り
はサポートされんのでは？

Qtとかでもいいが、バス直結でチマチマ描画するような小型TFT液晶じゃあ
GUIアクセラレータなんて載ってないからナァ。

CORTEX-M3で、ROMプログラムを動かしたまま 内蔵FlashROMにデータを書ける奴ってご存知ないですか？

>>347
STM32Fシリーズ

とりあえずMSフリーは目指すべき
はおいといて、
RVDS高いしKEILもアレだし
arm社がgccをサポートして欲しいな

RVDS?
いまどきは DS-5ですよ

>348
Thanks
ちなみに、TIのはRAMでprogram動かしてFlashROM writeしろって書いてあった。

>>351
というか、内蔵フラッシュ物は普通はそうだ
コントローラで相当うまい事やらないと読みながらは書けない

Digikeyでbeagleboardxmとpandaboardを頼んでるんですけど、
普通は1ヶ月程度じゃ届かないもんなんですか。

結構時間かかるよ
俺ん時は半月ぐらい
向こうの在庫事情によるみたい

>>354
レスありがとう。
ワクテカしながら待っときます。

仕入れ先にあればすぐに入る事もあるかもしれないよ
ARMとは関係ないけど、納期5wのFPGA28ヶ注文したら、
3日後に出荷された事もあるでよ

同じFPGAで、納期15w!!でｹﾞｪってなってたら翌週200ヶ在庫ありとかもある

マルツWebShopでNXPマイコン・チップ取り扱い開始。
http://www.marutsu.co.jp/user/ichiran.php?KEYWORD=110414-00

LPC1114は激安！\291

>>357
M0でしょ？STBee-mini買ったほうが良いな

mbed で　汎用　東京電力電力供給状況表示装置　
http://ameblo.jp/tenten2008/entry-10862421551.html

mbed高いよｗ

無駄に電気使うなw

ＳＴＭ３２マイコン評価ボードＳＴＭ３２ＶＬＤＩＳＣＯＶＥＲＹ　秋月　￥1,100（税込）
ttp://akizukidenshi.com/catalog/g/gM-04276/

STM32マイコンボード 『STBee Mini』(72MHz, 128K+20K) 　1,974円
ttp://strawberry-linux.com/catalog/items?code=32105


しかし32bitを使うなら、マイコンとしての機能のみならず、PCとしての機能や
たくさんのデバイスハブ、ネットワークも使いたくなる。そこで
STM32マイコンボード『STBee』(72MHz, 512K+64KB)　3,150円
ttp://strawberry-linux.com/catalog/items?code=32103

ＭＡＲＹは手軽だけどARM cortex-M0なので論外。ARMならM3以上が楽しい
ttp://www.marutsu.co.jp/user/tr_kikaku1101.php

個人的には能力的にはM0で、clockも低くてもOKなのだが、メモリが沢山
欲しい。特にRAM。せめて4MBぐらい載ってくれんかな。
あるいはいっそノートPC用のSO-DIMMが繋がるとか。

>>363
> 特にRAM。せめて4MBぐらい載ってくれんかな。
ローカルバスのピンがあれば、疑似SRAMを繋ぐのが手軽だよね。

擬似SRAMって最近使ってなかったけど、
リフレッシュ動作隠蔽してくれるようになった？

リフレッシュを外部が念力で検出してWAITサイクル入れるとか、擬似SRAM
(DRAM側)からWAIT信号を出すとか、仕様上のアクセスタイムを2倍にして
アクセスと同時にリフレッシュするなりせんとSRAMと同じ外部仕様じゃムリ
だろ。JK。

そもそも、まだ容量4MBクラスの擬似SRAMって出荷されてんの？

NXP限定(内蔵フラッシュROMのアクセスが遅い)の話かも知れんけど、50MHz
動作といってもCortex M0は20MHzのAVRと比べてもかなり遅いみたいだから、
4MBも積むのはどうかと。

>366 Cortex M0は20MHzのAVRと比べてもかなり遅い

バカの声がデカいだけだ、それは。

ちなみに、遅くみえるのはコンパイルで -O2 が渡ってないからだから。

>>366
> SRAMと同じ外部仕様じゃムリだろ。JK。
一体、何年前の常識を語ってるんだ?

ttp://www.issi.com/pdf/66WVE2M16BLL.pdf
The hidden refresh requires no additional support
from the system memory controller and has no significant impact on device read/write
performance.

1ページ分のSRAM持ってれば普通にリフレッシュ隠せるよなぁ
いまどき当然の機能のような

>>368
日本語でおｋ

で、
＞バカの声がデカいだけだ、それは。
このイミフ文に納得ｗ

しかし内蔵フラッシュが遅くて
性能出ないのはもったいないよな
わずかでもキャッシュがあればいいんだが

SRAMウンヌンの話は、結局の所、安いSDRAM付きCPUボードがあれば済む話だしな…。
BeagleBoard程の重装備はいらないにしても
ARM926EJとかCortex-Aで安いボードが出てくれば一番だな。

WM8505+SDRAMなカード(AndroidタブレットのCPUボード)とか、\800で買えたりするので
利用できれば安上がりかもね。

>>373
> SRAMウンヌンの話は、結局の所、安いSDRAM付きCPUボードがあれば済む話だしな…。
ホビーならその通り。でも、ビジネスならそうはいかない。
大口で価格を叩けるならともかく、SDRAMより疑似SRAMの方が安い。
SDRAMコントローラ入りのARMより、コントローラ無しのARMの方が安い。

同じ機能を実現するのに、どう安く作るかもエンジニアの腕の見せ所なんだな。

腕を使って使用するRAM容量を減らす選択肢はないのかね？(w

>>375
速度が犠牲になるしソフトの工期やメンテ性能も落ちるからRAMの貧乏性は個人でやってくれって感じだろ

そこで、Rubyチップとか出てくるんですな。(w　PHPで組込開発なんて話も
あったなぁ。

小ロット生産者ならともかく、量産で安く上げるなら、ワンチップで(I/O
ピン潰して)RAM外付けとか論外では？部品点数減れば、製品の原価、実装
コストは下がり、信頼性はあがる。

> 速度が犠牲になるしソフトの工期やメンテ性能も落ちるから

変数が少ない方が、メンテ性は向上すると思うが？ところで、外付けの
擬似SRAMって50MHzノーウェイトで動くの？

木を見て森を見ないタイプ？

>>377
> 擬似SRAMって50MHzノーウェイトで動くの？

アクセスタイム20nsは絶対に無理
DRAMメモリセルのアクセスタイムはいまだに100ns弱のままだ

製造方法的に、機能の有無で価格が違うのは、面積が違うからか？
それ以外の違いなんて、すし屋の時価と同じで言い値だろうな。

突き詰めると、同じものだけを大量に製造していった方が効率的。
なんで細かい機能の組みあわせでレパートリー増やして、自らの首絞めるのかわからんｗ

>>375
コード・データを馬鹿食いするソフト屋に言ってくれｗ
ハード屋はそこまで面倒みれんｗ

>>379
> なんで細かい機能の組みあわせでレパートリー増やして、自らの首絞めるのかわからんｗ
見た目の歩留りを上げられるからだろう。
ダイの何処かに欠陥があるなら、その回路だけ切り離せばよし。
結果、シリーズ中の品種が増えるｗ

>>380
ヒープ使用禁止にすれば要求RAM容量激減するぞ。
開発期間が激増するけどなｗ

仕事次第で使うRAMとか大きく変わるだろ
8kとかに収めれるのは相当しょぼいモノだけ

>>382
うわぁ、それは余りにも可哀相ｗ
それで思い出したのがこのネタ。

>>113
> まだ半分も残ってるやん。Z80や8085の時代には、外付けはROMのみでRAMは
> なく、変数はすべて内部汎用レジスタのみに割り当てて処理しているプロ
> グラムとか、わりと普通にあったけど？
これは究極だと思うｗ

実際どうしているかと言えば、要求分析時に必要RAM量をソフト屋に尋ねても答えが返って来た試しが無い orz
だから使用目的と過去の事例から、「これだけあれば十分だろ? 量産時には調整して減らすけど」で決めて載せてる。

が、そうするとそれが最後。あればある分だけ使ってくれちゃって、量産時に減らせられた試しが無いｗ

Z80/8085は外付けRAMないとスタック使えないから
割込から復帰すらできなくてさすがに厳しい

>384
きっと、
「うわ、やべえ。RAM足りねえ。どこを削る？」なんて会話が何十回となく繰り返された結果が、
＞が、そうするとそれが最後。あればある分だけ使ってくれちゃって、量産時に減らせられた試しが無いｗ
という結果になるんじゃないの。
もしもっとRAMがあれば開発機関を短縮できるかもしれないよ。
短縮できないかもしれないが。

開発期間だって製造コストのうち。
部品代を削ることでソフト部分の開発費が上がるなら、実質上の製造コストの上昇にもつながると思う。
よほど大量に作るなら別だが...

と、無関係な素人考えで悪いが、ちと疑問に思ったので。

>>386
幸い、そういうのは無いかな。
検討段階での予想使用量に対し、その倍載せているからｗ
画像系でGBクラス載せたら、画像のワークとしては十分だけど、I/Oの処理能力がボトルネックになった事はあるけど orz

良くあるのは、ソフト屋さんがメモリマップをあるだけ使って決めて、変更不能になること。
勿論、余っているところを削るのは可能だけど、完成したソフトを修正して全テストをもう一回ってのが時間的・費用的に無理。
なのでそのまま量産っと orz

RAMの使用量を見積るいいやり方があれば、ハード屋のオレに教えてほしい。

＞良くあるのは、ソフト屋さんがメモリマップをあるだけ使って決めて、変更不能になること。
ソフト屋さんともっと密に協力出来て、逐次要らないところを削って行けるような
体制にするしかないんじゃね？

OSの絡みもあるし、ソフトを何人で作ってるかにもよる。
マトモなアーキテクチャが仕切るなら上手く行くだろうけど、
営業マン的な資源奪い合いの足引っ張りあいするなら全部使い切るのは当然。

結局、純粋に技術的な考えを持つ奴が仕切る事が大切って事。

外部RAMってノイズに弱くなんね？

RAMの見積もりもせんでやってるのかよ？

連投ｽﾏｿ。
>>388
Linuxとか、メモリ管理があるOSなら自在なんだろうけどね。
メモリ管理が甘いOSだと…ね。
>>390
だから必要RAM量をソフト屋に尋ねても(ry

>>389
その可能性は否定出来ないけど、パスコンとバスのクロストークに注意すればおｋ
良く見受けるのが、SDRAMリフレッシュ時のピーク電流を無視したパスコン設計かな。
案外知らないハード屋が多い。

まぁソフト屋もわからないとしか言えないだろう。
ロクに決めずに始めさせて、途中で後から後から仕様を肥大させていくのがこの国の開発のやり方だ。

>>389
> 案外知らないハード屋が多い。
もう一つ思い出した。
DDR2のVTT REFは電圧が1/2でありその精度が±2%であること。
かつリップルが10mV以下であること。
知らない野郎が雑な設計して、とんでもね〜回路で基板作っている事がある(怒

加えてシミュレーションもせずに基板を作り、「DDR2は難しい」とかなんとかのたまう。
ええ加減にしろよなって思う(怒

ソフトやってる人が壊れてる感じが...

>>393
ソフト屋もそのハード屋と同じような感じだろ

RAM増やすのに基板作らないとダメなことが多いから
余分に載せといて削るでいんじゃないのw
途中で足らなくなってソフト開発が滞ったら困るしね
ハードの機能や設計がマズイのを
カバーしたりも良くある話やし
お互い様ってことやね

>>396
製品単価計算してるならその手は有効だが、
単価を上げてでもメモリーを増やすなんて、開発費増やす以上に無理だｗ

8投目、ｳｻﾞくてｽﾏｿ
>>396
> 余分に載せといて削るでいんじゃないのw
DDRで余分に載せるのは、結構大変なのよ。
アホなパターン引けばスタブになるし、シミュレーションも二通り検討しなければいけないし。
SDRAMならメモリ容量が小さくなる分、削るとバス幅が半分とかｗ

お互い様は仰る通り。
でも、ハード屋は一発勝負ってことを理解してくれないソフト屋さんも多いよ。
(ソフトで言えば、コーディング・コンパイル・ビルドが一回だけ! と言うと判ってくれるｗ)

>>397
そうそう。決まった製品単価を変えるなんて…。

Stellaris はここではマイナーかな…。
Stellaris Robotic Evaluation Board 買って地道に遊んでいる。w

>>385
2000年以降のマイコンでも品種によって内蔵RAM無しのマイコンあったけどねｗ
スタックはハードウェアスタック3段とか
今はそういうの無いと思うけど

>>399
俺興味ある
どんくらい遊べるの？
モータとかセンサーの精度とかどう？

ヒープ無しなんて考えられん　PCアプリ並みにインターフェース処理が複雑になってきているのに
Cでクラス化設計せんと対応できなくなりつつあるで．．．

atollic TrueStudio(r)/STM32 Lite version使ってる人いますか？
新しいバージョン(2.1.0)が出て highly recommends されたけど、インストーラが途中で
異常終了してしまいます。
回避策があったら、教えてください。

暫く留守してる間に、何か間違った方向に議論が進んでしまってるが、そんな
8bit時代みたいなメモリ貧乏自慢は要らない。
Z80だって、bootstrapはRAM無しで書く(ってか書いた)。書かざるを得ない。
何しろ最初は何kB載ってるか? 下手すると載ってないかも知れないからな。
搭載メモリ容量を認識してから、それに合わせた各種初期化が始まる。最近は
統合開発環境やお仕着せのcrt0.oが全部やってくれちゃったりするので忘れて
る人も多いだろうけど。

せっかく32bitマイコン使うんだから、デジカメを作りたい。VGA動画なら8bit
でも済むが、逆に低速(つーかスチル)デジカメを作りたい。小ロットで。
スチル用のCCDは何世代も型落ちのローエンドでも2百万画素有る。これを
ゆっくりで構わないので16bit-A/D変換して、たった1フレームのフレームバッファ
に蓄えようとすると、それだけで4MBのRAMが必要に成ってしまう。

変数のやりくりを多少節約したところでkB単位で済む計算には成らない。海外
のベンチャー企業の製品を見ると、i8051+EZ-USBでやってて、数kB単位で
CCDを転送&読出してはA/D変換して、USBでPCに転送しては、また次の
数kB分の画素を読出しに行く…という処理で、凄まじく遅い。転送に数分掛かる
上、その間USBバスを握りっぱなしでフリーズしたように成ってしまう始末。
遅いとはいえ、ある程度リアルタイム性が求められる計測なので、分割読み出しに
よるUSBのフリーズは致命的に困る。
RAMさえ1フレーム分有れば、分割読出し&転送せずに、一気に処理できるはず
…と思ってARMに目を付けたんだけど。

>>404
メモリコントローラ内蔵の品種で
外部にメモリ接続するので良いのでは?

200万画素のWebカメラなら、ヤマダで2000円で売ってたぞ

それ16bit階調有るの? どーせ8bitで、しかもノイズだらけでしょ?

そもそもUSBを握りっぱなしってのがイマイチピンとこない

>>404
> 何か間違った方向に議論が進んでしまってるが、そんな
> 8bit時代みたいなメモリ貧乏自慢は要らない。
8/16bitマイコンを代替えする$1のCoretex-M0/3の組込みARMから、
まもなくWindows8が動いてしまうCoretex-A8/9のシステムARMまで、
一つのスレに同居しているからご勘弁をｗ

> RAMさえ1フレーム分有れば、分割読出し&転送せずに、一気に処理できるはず
> …と思ってARMに目を付けたんだけど。
4MBでも足りなくないかい?
モノクロなら確かに4MBだけど、カラーならその3倍は要る。
それに、(詳しくないけど)CCDってホワイトノイズ除去にγ補正とか、要るんじゃなかったっけ?
USBで転送するなら、ある種の圧縮処理も必要だろうし。

1フレーム分を全部処理しながら蓄えるなら判るけど、素直に設計したら少なくとも32MBは要りそう。
でも、8051で出来る話しなら、そんな処理は要らないのかな?

んな大容量にはDRAM使えよ。
４Gbitとか普通にあるぞｗ

DRAMはコントローラー内蔵のチップでも何を設定していいのか面倒臭いけどな
パラメータ間違っててもある程度動いちゃうのも怖い
後でオシロで測って条件満たしてるか確認も面倒だしｗ

>>404
一般にはデータシート出回ってないタイプのCCD使えるのかｗ
現像はPCでやればいいんじゃね？

そんなに面倒だっけ?
最近はコアのクロックの初期設定とかも必要だし
たいした手間じゃない気がする。

パート毎にハードで固定できればいいんだけどね、
RSやら調整入るとクロック全体見直しするからいちいち面倒よ

今や　M3規模でも多数のクラスオブジェクトがCreate->Destroyのダイナミック生成で動作してるで．．．
ワンチップ組込みの世界も日進月歩．．．　内蔵RAMは大きいほうがいい．．．

そりゃ大きい方が良いけどね。
けど小さくても消費電流少ない方が良いって場合もあるから
適材適所だね。

マイコンはどうしても必要な箇所でのみ使えばいい
RAWデータなんか扱ったらUSBじゃ追いつかないし
車輪の再発明するよりも得られたデータで何をするかでも考えたら

>404
SH系で搭載メモリの多いモデルがあった気がするが
（昨年のInterface付属基板のアレの、もっとメモリが多い上位モデル）
それでも2MBだったっけ?

それよりいっそ、CCDのデータを縦横半分に減らしながら読み込んで（2x2サイズで平均を取るとか?）
画素数を減らすわけにはいかんのかな。

>409
＞モノクロなら確かに4MBだけど、カラーならその3倍は要る。
YC分離映像の形に圧縮したら3倍じゃなく2倍で足りない?

YUVは外にデコーダー付いてるならいいけど無駄じゃないか

>>415
Create->Destroyのダイナミック生成で動作してるで

どこの国の言語かしらんが、new/deleteじゃなくて？単にHogeObject::
Create, HogeObject::Destroyといったメンバ関数を呼んでるだけじゃあ
静的オブジェクトの場合だってありうる。

RAMが増えると、ゆとり頭のWeb屋(スクリプト書き)が流入してコードの
質を下げるので、M3クラスはRAM容量は今くらいで十分。

>>418
1Vp-pでも16bit分解能だと1bitの重みは、約15uVになる計算な訳だが、
そもそも、映像系CCDに16bit分解能でサンプリングするほどの潜在的
性能(感度リアリティや、信号ダイナミックレンジ)があるとは思えん
のだが？

ましてや、出力先がそこいらの液晶モニタなら尚更。

M3クラスの内蔵メモリなら
staticまみれしか考えられんわ

>>420
ん？　CでのOOPの書き方知らんの？
この世界はWeb屋ではどうにもならんな　ｗ

>>422
CでOOPって、マンドクサｗ

組み込みでOOPプログラミング活用というと、
継承の形を取った修正がやりやすいよねｗ

何重にも継承されて、少しずつ修正が入るという開発手法にもってこいだよｗｗｗ

なんで、わざわざC++使わずに、背伸びしてCでOOPモドキとかやりたがる
んだろ。C++でもソースコードの書き方次第で肥大化はいくらでも防げる。

よもや、単にmalloc/freeで構造体を動的にしてるとか、mbedライブラリ
みたいなのがOOPとか思ってないよな？

>>409
>モノクロなら確かに4MBだけど、カラーならその3倍は要る。
後で別の人が書いてる通り、カラー化とか現像処理は、転送した先のPCでやれば良い。

>>410
まぁそうなんだけどね。外部D-RAM I/F載った安いCortex-Mって有るの?

>418
>CCDのデータを縦横半分に減らしながら読み込んで
「ビニング」はもちろん可能だが、プレビューはともかく本番はビニング無しで撮影
しなきゃ無意味なわけで。分割読込み&転送なら、i8051でやってる通り。

>1Vp-pでも16bit分解能だと1bitの重みは、約15uVになる計算な訳だが、
>そもそも、映像系CCDに16bit分解能でサンプリングするほどの潜在的
>性能(感度リアリティや、信号ダイナミックレンジ)があるとは思えんのだが？
それが有る(必要とされる)分野が有る。
8bit A/D-Cなら>>406で書かれてる通り、ビデオレートで変換できる。だが16bit
A/D変換は(それに見合う精度を出そうとすると)そこそこ時間が掛かる。10μV
単位で電源が安定する時間を空けながら1画素づつ読込むから。そしてCCDも
1画素がそこそこ大きいので、たった200万画素でも結構大きかったりする。
極端な奴はたった25万画素(512x512)で35mm判フルサイズ並とか。
米国ベンチャーの奴は$1万で、俺が買った時のレートで130万円した。
国産だと唯一、浜フォトが作ってるが裏面照射やら液窒冷却やらもあって、オプション
の補器類によるが、一番安い25万画素のやつで7〜8百万円してる。
Spring-8には瞬間を測定するために高速A/D搭載版も有るが、4千万円するとか。

Create/Destroyもnew/deleteもmalloc/freeも本質は同じで、
動的メモリ確保とGCの悩みだ。今日もOOPの世界的ネ申fujieda氏が
つぶやいてたが、汎用のものでマトモなものは1つも無い。K&R malloc
を超えるモノを作るだけでどんだけ大変か。
問題が予め決まってる組込制御なら、これらは一切使わず、専用メモリ管理
ルーチン・俺様libmallocを作る所から始めるべき、という結論に。

>>426
LM3S9B96だと90個で単価千数百円くらいだっけか?

>>427
家庭用ゲームとか、組み込みに似てメモリ管理大変らしいね。

ザッと読んだら、ソフト屋とハード屋が入り乱れて凄いなぁ〜
>>418
> それでも2MBだったっけ?
それ、FlashROMじゃない?
> YC分離映像の形に圧縮したら3倍じゃなく2倍で足りない?
それは知ってるけど、転送するなら焼け石に水かなって。

>>420
> そもそも、映像系CCDに16bit分解能でサンプリングするほどの潜在的
そう思う。8bitでRGBの24bppで十分じゃないかな。

>>424
> 何重にも継承されて、少しずつ修正が入るという開発手法にもってこいだよｗｗｗ
それやっている奴居るのかなぁ。
なんにせよ、ソフトのバグでハード屋を巻き込むのは止めてくれ orz

>そう思う。8bitでRGBの24bppで十分じゃないかな。
そう思うのは、素人の浅はかさ。
そもそもそれだったら8bitマイコンで済む話で、スタレのARMの出番は無い。
まぁ浜フォトが手本見せろよとは思うけど、昔見た計測器の中身はZ80だった。
この辺に成ると16bitどころか20bitなんて製品も有るみたいだけど。FORTRAN
だけど、32bit float *3 =96bitカラーなんて処理も、50年近く前既に存在するな。

まずそもそもソフト屋とハード屋が分かれてるのが凄くマズい。そんなブラック会社
多いけどさ。哲学の初歩の初歩だが「まず初めに目的有りき」。目的を達成する
機能ごとに、仕事を割振るべきで、それは決してソフト/ハードと分かれてはならない。

>>427
> 問題が予め決まってる組込制御なら、これらは一切使わず、専用メモリ管理
> ルーチン・俺様libmallocを作る所から始めるべき、という結論に。

今頃そんな結論に？　同じような指摘は10年以上も前にfjに書いた
記憶がある。　わざわざオブジェクト生成単位でmalloc/freeする
必然性はない。　C++なら、オブジェクト毎にnew/delete演算子を
定義すればいい。

OOPの神とか知らんナァ。(w　自称研究者同士の相互格付けオナnew？
「新しい肩書きが動的生成されました」とか。

なんか変な方向に話が流れとるな

＞まずそもそもソフト屋とハード屋が分かれてるのが凄くマズい。そんなブラック会社多いけどさ。

？？？
業務の細分化はどこの大企業でも当たり前なんだけど？
人手が無くて両方やってるのは中小企業だけだろう

>>426
SH7268シリーズあたりかな?＞2MB

>>431
> そう思う。8bitでRGBの24bppで十分じゃないかな。
> そう思うのは、素人の浅はかさ。
元ネタの人?
何用に作りたいのか判らないから、話しがGIGO(garbage in garbage out)になるんだけどぉ。
2000円のデジカメじゃなかったの? GC(garbage collection)しちゃうゾｗ

さて、素人って言われたから一応補足するけど、
今のハイビジョン(古!)の放送機器で使われている、1.5Gbpsのシリアル伝送する規格はHD-SDI (Serial Digital Interface)。
こいつは放送現場で使われるデジタル映像を、無圧縮で伝送する(業界で)一般的なもの。

HD-SDIに使われている映像規格はSMPTE 292Mであり、YCbCrで20bit。
RGBに変換すると24bppになると。

> そもそもそれだったら8bitマイコンで済む話で、スタレのARMの出番は無い。
悪いんだけど、無圧縮で1.5Gbpsのデータ転送に、Z80なぞ出る幕は無い。

>430
いや、VRAM代わりに使えるように大容量メモリを積んでるモデルらしい
フラッシュは外付けだったかもしれん。シリアルROMからコード読んで実行、とか

>435
426じゃないが、たしか、それ。

>436
そういや、ビットレートすごいな。
テレビ放送の解像度（D1相当?）でも、640ｘ480で30フレーム相当。211Mbpsか
（実際のCCDからの取り込み信号はモノクロ画像相当だから70Mbpsかな？）
200万画素CCDなら、取り込みデータ自体でも1フレームで2MB、
これを30フレーム毎秒で取り込んだら60MB/秒（480Mbps）
RGB化処理したらデータ3倍で1.5Gbpsになるんだ。（1画素、8bitｘ3色の場合）
こりゃ、それなりの高速なマイコンじゃないと追いつかんわ。

>>434
>>431に言わせると
日本はブラック電子産業企業がほとんどと言うことだろう

ブラックはキチガイ思考しか出来ない
そんな思考だから大手でもチョン企業にすら勝てないだよだろうな
そして、ブラック企業が増えて日本の電子産業が駄目になったってことだろな

粗製乱造しちゃったからね、人もモノも

>>431
俺ハード、俺はソフトって縄張り作るのを止めて、
製品の機能ブロック毎に縄張り作ろうぜ、って事で良いんだよね？

結局、面倒事を人に回そう、知らない振りをして、後で問題でたら対処しようｗ
って姿勢である限り無理だよねｗｗｗ

その為のハード屋、ソフト屋という区分は便利。
やらないイイワケになるワケｗ

プロジェクト制にすると今度は個々のスキルが落ちるんだよ
競う相手が不明瞭になってね

>>436
そんな素人丸出しの既成のコンシューマ製品はもういいの。スタレのARMも
何も要らなくて、完成品買ってくれば済むじゃん。
RGBに変換すると96bitで、しかもfloatのやつ。
http://schickworld.com/astronomy/text/Battle_of_CCDs.htm
国産だと浜フォトのやつとか。こんなのでGFP蛋白を計測する。

>>440
最初の段落は合ってる。他は間違ってるな。君のような無能なくせに責任逃れ
だけは必死な、ぶら下がり社員には便利なんだろうけど。
哲学の無い物作りに未来は無いな。

思わず笑ってしまったw
>>442
> そんな素人丸出しの既成のコンシューマ製品はもういいの。スタレのARMも
> 何も要らなくて、完成品買ってくれば済むじゃん。
俺、作る側だしw
その俺が買ってきてどうするww

> RGBに変換すると96bitで、しかもfloatのやつ。
よ〜わからんけど、
　ttp://www.goto-kyoei.co.jp/netshop/c_ccd_camera/sbig/st2000xm.htm
　ttp://www.goto-kyoei.co.jp/netshop/c_ccd_camera/sbig/stl11000m.htm
これらの16bit ADCじゃダメで、32bit ADCな奴が欲しいの?

32bit ADCは世間にあるから、頑張って作ればいいじゃん。
値段は$218.75なのだから、RAM容量ケチっても無駄な気がするけど。

>>433
このスレがハードと組込みソフトが一緒になってるからじゃね？
ハードの進歩に伴なってソフトウェイトも高まってるし　内蔵ＲＡＭ増大で組込みアーキテクチュアも10年前とは段違い
組込みOOPなんてデザパタやらPCアプリで経験した奴しか組込みでは生きれない
ついてこれない者との差が広がってるよ．．．

面白い世界は　先に歩まないと現れないもんさ．．．　往々にして面白い世界は金にならんが　ｗ

てか　もうSHだARMだとかのハード選択の時代ではねぇんだけどな．．．　小規模か大規模かの選択はあるけれど．．．
開発アーキテクチュアの時代だよ　アメはもうそうなってる．．．．

>>444-445
> 小規模か大規模かの選択はあるけれど．．．
もう、そんな時代なのかぁ。
でも、相変わらず下回り(ドライバー)で困っているみたいだけど。

(･∀･≡･∀･) ﾀﾞﾚﾓｲﾅｲ

　　　　　　　　　_,,..,,,,_
　　　　　　　　./ ,' 3　 `ヽｰっ
　　　　　　　　l　　 ⊃　⌒_つ
　 　　　　　　 `'ｰ---‐'''''"

(･∀･≡･∀･) ﾀﾞﾚﾓｲﾅｲ ｲﾏﾉｳﾁ ﾁﾗｼﾉｳﾗ

Steralisキット数量間違えて発注したのに気づいて
24H以内に慌ててキャンセルメール送ったがアウトだった。
キビシイ。w　でもう日本かよ。w

DigikeyにSAM7SEのRev.Bが…
あのエラータが取り除かれるのか?
でも、ぶっちゃけSAM7Sに対するSAM3Sの様に
ピンコンパチのSAM3SEとか作ってくれた方が良かったヨウナ…

ARM + linux + USB2.0でUSB AUDIO CLASS relese 2.0 かつ
Asynchronous(非同期)モード対応のマイコンボード出したら、
オーディオファンがこぞって買うはずだから、誰か開発して。

>>451
あんたが個人的に欲しいだけと違うん？
本当やったらオーディオファンとやらを100人集めてから
出直して来んしゃい。

>>451が1万個単位でまとめて発注してくれるんじゃないの?

オーディオファン（）

>>451
オーディオマニアは、アートワークや電磁気的な問題で、性能が高いマイコン+D級以外のD/Aやアンプを非常に嫌うから、たぶん需要ないｗ
1000円程度のサウンドボードの性能を、勉強で出すと言う意味でも、音を極める意味でも、組み込みを極める意味でも、
USB端子付きのDSPの評価基板のほうが、そっちの需要はあると
到達できないレベルであれば、arduinoのシールドで、我慢しなｗ

>D級以外
�刄ｰの間違いじゃないか？　D級は電磁波の嵐でしょ

原理主義的オーヲタはデジタルを嫌いそうな印象。

>>451 ARM + linux + USB2.0
この範囲ならbeagleboardやpandaboardで実現しているはず。

それらのボード用に USB AUDIO として動作するソフトをキミが書けば
目的は達成できるんじゃないかな？

いろいろレスありがとうございます。

beagleboardはUSBコントローラが兼用になるので
pandaboard + Ubuntu あたりから調べてみます。

>>451の条件があれば、最新のUSB-DDCデバイスが
ドライバレスで接続できるはずなので、
ノイズ対策はそっちの方である程度やってるものもありますから
それなりに良い結果が出るのでは？と思っています。

これ、日本でも流通するかな？
ttp://jp.techcrunch.com/archives/20110505raspberry-pi-a-25-bare-bones-pc-that-fits-on-your-keychain/

DigiKeyで取り扱ってくれんかね

専用ケースってあるの?
なければ誰か専用ケース作って販売するんだ

ケースが$50とか。(w

オモチャにするのに面白いな
実用目指すならRAMが少なすぎるが…

今更arm11じゃオモチャにしかならないよ
USBはlinuxだと苦労する
本当に暇な人向け

linuxでUSBのDACというかオーディオクラスの実装をするって話なの?なんでlinux…
簡単なデジタル・トランスポートだったらlinuxなんかなくとも実装できる…が、
簡単でも良いからリアルタイムモニタがあった方が楽だよね。
#バッファへのロード中に操作受け付けないとかなるからな…orz

ヲーヲタな俺だが、正直、マイコンに付いてるI2S機能は微妙かも知れないので
CS8406とか繋げるつもりなら結局はCPLD+FIFOとかで実装した方が楽かもな。
ATMELのSSCが微妙なだけかも…orz

オーオタは、水晶のジッタが聞いてわかるらしいので、セシウム原発振で
ポ・ポ・ポ・ポーンじゃないとダメなんでわ？(w

アンプやD/Aで音が変わるのはともかく、メモリのメーカで音が違うとかもうね・・・
ARM は高音の伸びがよいが、低音の響きが弱くロックやジャズには向かないとか言い出しそう。

まあ純銅のケーブルにバカのように金使う奴らだからな

>>467
本当の水晶のジッタは多分分かんないと思う、
設計が甘い基板だと電圧変動で水晶発振もドリフトするのでそれが分かる程度かと。

オーオタ向けに、Burr-Brownのロゴ付けたARMとか、バックロードホーン型
ヒートシンクとか、バスレフ型表面実装パッケージとか出せば、高く売れ
そう。　純度99.999%、無酸素銅リードフレーム採用とか。

>>470
設計が甘い基板って、メタボ体型の糖尿オサーンが設計した基板のことで桶？
シロップ漬けとかか？

これから暑くなってくると、水晶の温度ドリフトのせいで、「今日は暑い
から、チャイコフスキーのヴァイオリンの音が1万分の3オクターブ高いな」
とか、気になるンですね。

５点

>>471
鉛が含まれてて甘いんじゃないか？
鉛フリー半田の味は知らないが・・・

>>471
> オーオタ向けに、Burr-Brownのロゴ付けたARMとか、
BBはTIが買収して、今やTIのブランド名。
TIがその気になれば、捺印を変えるだけだったりするｗ

>>474
A/D、D/A回路はBurr-Brownが設計しました！
と言うマイコンを作ればいいんだｗ

防振パッケージと称して、チップに鉛とブチルゴムくっ付けて、
表面は人造大理石で覆う。

端子は金メッキ仕様、
ソケットもオーディオグレードｗのごついソケットが別売りになってるとか。

バーブラウンって、最近聞かないと思ったら、買収されてたのか・・・

>>475
パッケージはあれだがBBの名前で
出ていますな石は過去に有ったような
汎用マイコンじゃなくASSPだが

w

BBって、なんでオーデオマニアに受けるの?
社名がカッコイイのかな

結構早い段階で良い製品を出したからブランドイメージが良い

>>479
既に寡占化が進んでしまっていて
現実的にオーディオ帯域の高性能DACを供給してる所が少ない。

今日、ビッグサイトの組込みシステム開発技術展いってきた。
ARM結構出てた。Cortex-M3結構見かけた。

>>474
石の捺印最近は縛りがゆるいらしく、前カスタムチップ作った時
営業が「どんなロゴでも入れますよ」とのりのりだった。
最近は型いらずでレーザーだったりするの？

もう何年も前からYAGレーザーマーカーが多いですよ
テスト機もあるのでぜひ

ESEC今回は行きそびれたな
大阪からだと結構金かかるし

ARMにすると、どのようなメリットがあるのですか?

>>486に対応するメリットが知りたい。

既出　>>293-294

上司から「次の製品はこの石を使え」なんて名指しされたら他の選択肢がない、とか、
製品の仕様によっては、たまたまARM採用の特定の石が最もコストパフォーマンスが高い、とか、
個別のメリットないし事情が有る場合に採用するものではないの?

もっとも、用途によってはARM以外の選択肢がない場合もあるみたいだが。

一定以上の性能が要求される場合、ARMかx86しか製品がなく、
少しでも消費電力とか価格で有利なARMしか選択肢がないって例がある。

選択肢が充分にあるなら、使いたい石でいい。のではないか?

>>489
>選択肢が充分にあるなら、使いたい石でいい。のではないか

↑の為（使いたい＆馴染みの）に少し前までCQ出版が各メーカーとタイアップして
付録基板を出してたんだが。

>>486
ARMのメリット？　世界に飛び出してみればわかるよ
別にARMだけじゃないけどね　ｗ

日本のメジャーな通販で手に入りやすいのもARMの良い所か。

>>486
フルICEを開発しないで済む
開発環境の無償提供も断り易い

>>476
> バーブラウンって、最近聞かないと思ったら、買収されてたのか・・・
うん、BB製品が欲しければTIのADC・DACを漁ると出てくるｗ

そういや、TIは先月NSも買収したね。
メモリを除けば、TI製品だけでほとんど揃ってしまう。

なんかTIってプロセッサ周辺のチップメーカをどんどん取り込んでいるね。

>>486
> ARMにすると、どのようなメリットがあるのですか?
俺が思うに…、

vs 8/16bit MPU
・アドレス空間が素直
・32bitなので、PCでプロトタイプを作りARMに持って行きやすい。
・32bitなので、gccが使える。
・32bitなので、固定小数点演算でもそこそこ精度を確保出来る。
・でも、Thumb命令セットで16bit MCU並にコード効率がいい。
・OSも利用可。

vs SH
・SHはルネサス一社だが、ARMは様々なベンダーからリリースされ競争が激しい。(=進化が早い)
・したがてコストパフォーマンスが高い。
・SHのJTAG ICEベンダーは限られ高めだが、ARM用は安く揃えることも可。

vs x86
・避けようとしても、チップセットが必要。が、ARMならSoC。
・BIOSを移植しないと、OSが生きない。
・でもBIOS移植だけで結構費用が必要。

なので8bit MCUからx86に迫る1GHzまで、広いレンジをカバーできる。
でも、コアは統一されてもメモリマップ・ペリフェラルはバラバラ、ここら辺は困ったちゃん。

ペリフェラルがアフォなマッピングだったり使いにくい統一性が無い
ってのは日本勢も一緒ですよ

>>496
>コアは統一されてもメモリマップ・ペリフェラルはバラバラ、ここら辺は困ったちゃん。
それに対しての解決としてCMSISなんじゃないかな。

ARMは英語が使える人は海外で質問して問題をクリアできるし　リソースが多い　この一点が全てだな．．．

>>496
今まで、一番明快で分かり易い対比ですね。素晴らしいと思います。
特に
>・SHはルネサス一社だが、ARMは様々なベンダーからリリースされ競争が激しい。(=進化が早い)
>・したがてコストパフォーマンスが高い。
の2行は、初めてARMのメリットに納得した文章です。

そこで、横からですがさらに教えてください。

例えば、
「今までA社のARMマイコンを使っていた。でも今回の○○の影響で
　A社のARMマイコンが入荷しない、困ったな」というとき、
同じARMマイコンなら、B社のARMマイコンがコンパチで行ける、とか、ありますか?

1) Yes、74HCxxのように、各メーカーは完全コンパチなものを作ってるから安心。
2) いや、良く似たものはあるけど、完全コンパチは無いから、少しの手直しが発生。
3) いや、まったく1からやり直し。ARM→SHに移行するのと、手間は同じ。
上記のどれになるでしょうか。

コアは同じでもペリフェラルがバラバラだったりするし、ピン配置やパッケージも違うから2)じゃない？

>>501
ありがとうございます。
やっぱり、そうですよね。
もし各社同じだったら嬉しいと思いました。
でも、今度のXilinxのFPGAの中には、ARMが載るという噂があるので、
マイコンもFPGAもARMにしておけば、いろいろと悩まなくてもいいな、
と思っています。

安いのは魅力ですね。H8系は、秋月が安いのでそこで買いますが、
ARMも、どのくらい安いのか、調べてみます。

秋月のH8が安いと言えるなら、激安では？　ルネサスでも旧世代のH8は
価格性能比で考えてもかなり高い。

あと、ARMといってもコアの世代が違えば互換性ないから。下位は下位なり。

バッタ屋の値段と比べても意味ねーからｗ

釣りかよｗ

最近のマイコンってRTC内蔵してるけど電源OFFの間もカウントさせるには
やっぱOFF時にもマイコンに電池とか接続しておく必要あるんだよね？
そうすると消費電力的に別個にRTC用意した方がよさそうだけど、どうなんでしょう？

消費電流は測ったことないけど内臓RTC用の電源ピンって分かれてないですか?

電源オフって、マイコンの電源入力を完全にシャットダウンするんじゃなくて、
普通は「省電力モード」に入るだけなんじゃないか?

電源を物理的に切るなら、その制御回路の電源は要らないか?

また、別チップをつければ、回路の肥大で消費電力増えるだろ?


たいていの場合、省電力モードの設定をきちんと行えば、電力消費は小さいはずなんだが。


マイコン種別によっては、あまり省電力性がない機種もあって侮れない。

>>507
内臓RTCって、腹時計みたいなもんですか？
なんかグロい（ｗ

>>509
typoったｗ

STマイクロ、NXPあたりのARMは、VDD/VDDAの他に、VBAT端子というバックアップ
電源(ボタン電池やスーパーキャパシタ)をつなぐ専用の端子がある。故に、
電源切る外付け回路は不要。(スーパーキャパシタや二次電池を充電する
なら別途回路は必要)

VBAT端子は内部でショットキーかP-ch MOSFETで、通常電源と合流させてRTC
ブロックに電源が供給されるようになってる。メインクロックが発振して
いる省電力モードではあまり消費電流は減らない。RTC部単独の消費電流は、
10uA程度。

LPC23xxはCR2032で一年しか持たなかったが、LPC17xxではRTCの消費電力が
劇的に改善されたようだ。
たぶんバッテリーRAMが無くなったのが効いているのだろう。

kinetisってどうなんすか？

ちょっと教えてください。
お仕事で使っている開発環境と価格を教えてください。
KEIL RealView?
IAR Embeedded Workbench?
Code Red Red Suite, Atollic TrueSTUDIOなどGCC系?
それともGNUARM？

うちの会社は貧乏で、H8の開発環境がYellowIDEだったりするので、、

最近、LPC1769を使い始めて気付いたのだが、
もしかして、NXPのCMSISって糞?

そんな話をどこかで見た肝駿河、CMSISの仕様自体が...。

将来的にもまともになるかどうか知らんけど、今んとこCMSISの実装はどのメーカのもゴミ。

仕様書だけみて中身は自分で書くがよろし。

>516
仕様の方針そのものはそんなに間違っちゃいないと思うよ。
引数を巨大なstructで渡してるけど、コンパイラが頑張って
ほとんど一命令にまで落ちるような仕掛けにはなってる。

>>513
発表からそろそろ一年、もう食べてもいいんじゃない?ｗ

>>514
自分は趣味人なので無料ツールしか使っていないが
IARの価格表が載っている資料を見つけたので
とりあえず紹介

ttp://www.freescale.co.jp/event/mcutokyo2011/images/S3_IAR_0303.pdf

>>520
ありがとうございます。30万かぁ。私が調べたところ、
Red Suite 3が999ドル
TrueSTUDIO (for STM32)が995ユーロ
Sourcery CodeBench Standard Editionが1599ドル
でした。

テキサスのARM限定だけど
統合開発環境Code Composer Studio(Eclipseベース)と
XDS100つーしょぼいJTAGエミュレータの組み合わせで$79

Keilは年間ライセンスて20マン超えてた
買うと50万位だっけ

>>522
ありがとうございます。
79ドルですか、、安いのは助かるんですが、これ、仕事で使う人はいるんでしょうか？
なんとなく、大丈夫かなあと心配になってしまいます。

79ドルはエミュレータの値段で、開発ツールはタダだよ。
無償版の制限は、
・使用可能なJTAGエミュレータはXDS100と、TI純正の評価ボードに搭載されたオンボードエミュレータのみ。
・CPUシミュレータが使えない
・メーカーサポートが無い
といったところかな。
エミュレータが廉価版に限定されるので、ダウンロードが遅かったり、トレースデバッグ機能が無い
といった制限もある。

それでも、コードサイズの制限はないし、最適化レベルの制限もないから
自己責任で仕事に使うのもアリじゃないかな？

>>525
「Code Composer Studio」って、TIが出してる統合開発環境のことだよね？
これって、TIのDSPや、ARM9ベースのSitaraやIntegra用なんでは？

同じTI製品でも、元々はLuminary Microの製品であるStellaris(Cortex-M3)
には対応していないんじゃないの？

ttp://focus.tij.co.jp/jp/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=44&toolTypeId=12&go=Go

まぁ、対応していないと言っても「Code Composer Studio」自体は、Eclipse
ベースの単なる統合環境に過ぎないんで、コンパイラやデバッガを別立てで
用意して、場合によっては自分でプラグインを書けば、デバッガ機能も使え
なくはないだろうけど。

単にARM開発環境ならどれでもいいのかね？

CCS自体はStellarisサポートしてなかったっけ?
ttp://processors.wiki.ti.com/index.php/Stellaris_support_in_CCS

>>527
ここは初めて見た。確かに、

> Stellaris development in Code Composer Studio is first supported by the 4.1.0.
> ...
> The 4.6.1 compiler included in CCSv4.1

ってなってるね。TIのWebサイトは情報が入り乱れててようわからん。

>TIのWebサイトは情報が入り乱れててようわからん。
激しく同意
品種の多いメーカのサイトってどうも情報がどこにあるかわからない

TIって、ダウンロードするWebページが違うと、中身が同じ(File Compare
してないけど、Rev表記が同じ)、データシート(PDF)があるよね。

もちろん、日本語と英語とかってオチはなく、どっちも英語版。

TIのサイトはアクセスしてるとそのうち出てくるアンケートページで
具体的に注文付ければ直してくれるよ。

STにも機会あるたびに言ってるけどこっちは全然ダメなんだよな。

少し話を戻すよ

無償版CCSで使用可能なSterallis用エミュレータは、
以前は評価ボード内蔵エミュレータだけだったけれど、
CCS 4.2.3以降はXDS100v2も対応したようだ

なんか連休明けたらninjaとかで規制されて書き込めんかったけど、
>>443
>　ttp://www.goto-kyoei.co.jp/netshop/c_ccd_camera/sbig/st2000xm.htm
>　ttp://www.goto-kyoei.co.jp/netshop/c_ccd_camera/sbig/stl11000m.htm
だからそれ、中身はi8051(つーかEZ-USB)なので、チマチマ分割読出ししてるから
メチャクチャ遅いんだってば。しかも転送中はA/D止まってるシングルタスクだし。
1100万画素も有って8bitマイコン(の中でも非力なi8051)で制御とかアンバランス。
世間が秒間何連射とか言ってる時代に、1コマ読出すだけに何分掛かってるのかと。
このスレ的には「やっぱARMっしょ」と思うワケ。

>俺、作る側だしw
作ってから言えよ。買ってやるから。goto-kyoeiなら職場の近くだし。

>>520, 522
単に安いだけでなく、開発環境に「縛り」が無いのが嬉しいね。

pandaboard, beagleboard の話題はスレチですか？

STM32には、無償で使えるファームウェアがありますよね。
http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&ClassID=1734
TCP/IPとUSBはSTM32F2を対象にしてないみたいですが、、

(ARMじゃないですが)PIC32には、マイクロチップ社無償ソフトウェア ライブラリがありました。
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2637&redirects=pic32libraries
こちらは、一通り揃ってます。

有償だと、100万前後すると思いますが、無料のものは実際のところ使い心地とかどうなんでしょう？
単にサポートがないだけでしょうか？

>>533
>>443
> 32bit ADCは世間にあるから、頑張って作ればいいじゃん。
> 値段は$218.75なのだから、RAM容量ケチっても無駄な気がするけど。

SH2、SH2Aが入手難のため、代わりのCPUを探し中。
CORTEX-M3を検討しているが、
　STM、TI、NXP、TOSHIBA、FUJITSU
辺りがメジャーメーカーだよね？

FreescaleもCortex-M4で本格参入。

一応ARMやってるマイナーな所だと、Rohm(元:沖電気半導体事業部)とか、
Nuvoton Technology (元:WinBondのロジックIC事業)とか。

小松左京もビックリの電子立国ニッポン沈没。

本当に、ガラパゴスマイコンが津波に沈んでしまったな…

>>537
東芝TMPZ84C015が生産中止になっても、セカンドソースのZilogは作り続けてるのを見てから、
私は日本の大メーカーのものは選ばないようにしてます。
ARMだと、マイコン専業に近いメーカはどこでしょう？

>>537
Cortex-M3ならSTM、TIじゃない?
NXPはARM7が良いかんじ。
TOSHIBA、FUJITSUって作っているの? メジャーとは思えない。

SH2,SH2Aからの移行でCortex-M3なら大抵困らないだろうけど、外部バスが必要だとSTM。
SDRAMも必要だと、Cortex-M3は選択肢から外れると思う。

>>538
> 小松左京もビックリの電子立国ニッポン沈没。
だねぇ。
最近のAtmelはどうよ?

>>541
SDRAMで良いならTIのやつはコントローラ内蔵してなかったっけ?
DDRとかは対応してないけど

教えてください。

今はH8マイコンを、HEWでソフトを作っています。
今回ARMも始めてみたいのですが、Cコンパイラが今ひとつピンと来ません。
H8の場合は、日立が全部お膳立てしてくれているので、インストールして
マイコンの型番を設定するくらいで、ソフト開発ができます。

一方、ARMの場合はどうなのでしょう。
マイコンの品種の他に、メーカーもバラバラなので、
どのようなコンパイラーを使えば良いのでしょうか。
あるいは、コンパイラーのマイコン型番設定リストに、各メーカーの各品番が
リストアップされていて、そこで正しく品種を設定すれば良いのでしょうか?

また、メーカーが違うと、レジスタの呼び名も違うと思うのですが、どうでしょうか。
あるメーカーでは、P1DDRと言っていたのに、別のメーカーにしたら、DDR1Pと言ってみたり。

すみません

文系コピペ猿は、R&Dに向いてない、むしろ足手まといなので退場願います。
日立と心中してれば良いじゃん。

「普通に」GCCとか自分の好きなコンパイラや処理系で開発してれば良いじゃん。
いっそGoogle Goをmakeから呼ぶとかw
諸君、私はJavaが嫌いだ、のスレでも見てみたら?

>>544
感じ悪いですね。

>>544
オマエ　その悪い性格が災いして会社クビになり自宅警備ｗの毎日なんだろ。
カスはひっこんでろ

>>543
ツールによってはメーカと型番指定するだけのもあるよ。
一度営業に相談してみると良いかも

日立、必死だな。

心中お断り。

情報、ありがとう。

DigiKeyにSTM32F2が見当たらないのは流通したてだから？か...

ARMなら、あるメーカーが生産中止になっても他が作ってるから云々〜
って昨日言われたんだけど、
メーカー変わったら周辺変わる、ピン配置変わる→基板作り直し、だよね？

まあ、作り直せるだけマシ、という感じなのかな？

長期生産を望むならCM3系より
車載用途のCR4系の方がいいかもね
小口で販売してくれるのか不明だが
あと、さほど速度が要らないなら
CM0,1をサポートしてるFPGAって
手も有るが

みなさん、開発環境は何を使っているのでしょうか？
統合環境名を教えてください

コマンドプロンプト

ルネサスの在庫切れで仕方なく乗り換えするのかなｗ
まー頑張ってください

そういうユーザー多いかも・・・

bash

>>542
本当だ、TIのM3はSDRAM対応品まであるのか。
Coretex-M3最強か?

>>550
> メーカー変わったら周辺変わる、ピン配置変わる→基板作り直し、だよね？
だね。機能互換品があれば救いだけど、上位機種だとどうかな?
それまでには、もっといいのがあるか。

でも、作り直しだとあれもやりたい、これもやりたいで結局新規設計じゃまいか?

>まあ、作り直せるだけマシ、という感じなのかな？

・開発ツールを買い直さなくて良いからマシ
・開発ツールの使い方を覚え直さなくて良いからマシ
・同じOSが使えるからマシ
・商用OSの場合、ライセンスを買い直さなくて良いからマシ

>>551
一応、TIの製品はDigikeyで買えるようだが、値段も高いし、そもそも
車載用じゃあEthernetも、USBも内蔵していないんだが？

ttp://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556109&k=Cortex%20R4F

> あと、さほど速度が要らないなら
> CM0,1をサポートしてるFPGAって
> 手も有るが

速度が要求されない場合、大抵は低消費電力と、低コストを要求される。
FPGAでは逆立ちしてもムリぽ。(w

>>557
外部バス付きのCortex-M3は、STマイクロ、TI(Luminary Micro)以外にAtmel
にもある。ただしSDRAMには非対応。

>>557
あとNXPのLPC18xxもSDRAM対応のハズ
まだ出荷はされていませんけど・・・

それとM4になっちゃうけどFreeScaleのやつはDDRも対応してたハズ

ハズばかりで申し訳ない＞＜

>>550
基板とか、モノの作り直しなんかたかが知れてる。最近の製品サイクルだと、どうせ
モデルチェンジの方が早いんだし。それより、
>>558
>・開発ツールの使い方を覚え直さなくて良いからマシ
マイコンアーキを勉強し直さなくても良いからマシ
…などといった「ヒト」の教育コスト・時間の方が遥かに重要。

かくして、>>548 みたく「ガラパゴスマイコンと心中したくない」と成る。

>>552
GCC, make, CVS(Hg)

>>556
ごめん、tcshで有害なscript書いてるw

>>558
VAX(BSD), SUNの頃からかれこれこの道30年やってるからな。
そもそも開発環境とか、OS環境とか、本質と直接関係無いことを覚え直さなくて
済むのが良い。Z80(64180)や68HC03のような8bitの時代から、HEWのような
囲い込み商法丸出しのIDE環境は(沢山)有ったが、皆、ベンダと心中して消えて
逝ったからな。コの業界で長生きしたければ、>>556 さんみたくベンダ依存を
徹底的に排除して、心中させられないようにしとけ。

うちはARMはAtmel一択　そろそろ他も使うかな　引き合いも多くなってきたし．．．　周辺のライブは作り直しだな

マイコンというより、もはや日本全体が丸ごとガラパゴスというか、世界の
お荷物になっている気がする。

当然、日本人は絶滅危惧種ですよ。(w

いずれ、在来個体数が100を切るくらいになると、白セラミックパッケージ
入りのuPD8080AFみたくオークションに出品されたり、鑑賞目的に売買とか、
トキやパンダみたく種付け繁殖実験とか。(w

>564
生物資源として利用できるかもしれない貴重な固有種が多いって意味でもある。

（ちなみに、ガラパゴス諸島よりも日本列島の方が固有種が多く生息してる。
生物的な意味では少なくとも、日本の方がずっと「ガラパゴス的」とさえ言える。）

他の地域で見られない特殊進化の中から成長株を探すという努力が足りないだけだな。
売り込みが足らないから袋小路入りしてるだけ。

巨乳JDとなら繁殖実験に協力するぞ

巨乳の情報系男子学生なら、客員講師先に掃いて捨てる程居るがw

んむ．．．　ガラパゴスか．．．　もう忘れろ！　つまらん時間帯だったんだよ！
何かくだらん機能を付ければ給料が上がったからな．．．

さて　今日はPSoC　Createrがアップデートされたな．．．　世界はがんばっている．．．　日本？　国会を見ての通り！

PCのアプリ的な手法じゃ、限界があるってことでしょ

ビジネスとしての価値と技術的な価値は違うんだろ。
そういう人材をたくさん作るようになってる
日本の教育体制とか、価値観とか、そういう物がある限りどうにもならんでしょ。

馬鹿がふんぞり返っていられる社会を維持するためには、科学・技術は邪魔なのです。

STM32のバリューラインって、DigiKeyなら安いし在庫あるのに、
国内の代理店に聞くと国内では流通してないと言われる。
どして？

代理店と言っても、実際は登録型派遣業の部品屋みたいなモンだからなぁ。

さすがに正規の一次代理店ではないと思うけど、Digikeyに注文丸投げして、
マージン上乗せして、Digikeyのラベルが付いたまま納品してくる業者だって
ある時代だし。(w

>>573
良心的じゃん。

次からDigikeyで買えって事だ。

投下

NyLPC
http://code.google.com/p/nylpc-freertos/

>>561
製品サイクル、短ければいいんだけど、10年以上経ってもモデルチェンジしてないよ、、
でも、今さらZ80はなあ

IARとHEWのIDEだったらどっちがよいですか？
できれば理由も知りたいです。

>>561
> マイコンアーキを勉強し直さなくても良いからマシ
> …などといった「ヒト」の教育コスト・時間の方が遥かに重要。
ったく、ソフト屋の常識は甘ったるくてかなわん。

偉そうに言うならマトモな大学で情報系の修士号取ってから出直しな。
ポインタ、再帰、λ関数、NP完全も理解できないハード専業屋の
単純過ぎる一階述語論理なんか、クソの役にも立たないから。

キモい流れ

一階述語論理って初めて聞いてググッた…
ぶっちゃけ、学問の為の学問だと思った。

>>579
博士号・修士号持ちなのにその日暮らしVol.6
がDAT落ちして居場所がなくなったか？

同じく、初めて聞いてググッた。
Prologで処理できるのが１階述語論理ですか？

>>579
そういう偉そうな事は、Verilog-HDL, VHDLでタイムドメインな記述をマスターしてからほざいてもらおうか?
そもそも、なんで電気/電子板にソフト屋が紛れ込んでいるんだ?

スクリプト書きは、30代でお払い箱だから、転職応募先で、付け焼刃で
『ハードもできます』って騙るためでは？w

でも、HDL書きもハード屋と言うよりソフト屋の希ガス。www

>>584
ソフト屋がソフト屋を自己否定してどうすんねん!?
せめてVHDLコンパイラの中身の自動配置やオートルータの「実装」ぐらいやって
からハードを語ってくれ。出来ればアナログ挙動の解析も。

なんかよくわかんないけど、ハード屋やっててごめんなさいごめんなさい

大前提

　　HDL書き = ソフト屋

>>586
>せめてVHDLコンパイラの中身の自動配置やオートルータの「実装」ぐらいやってから

それってアルゴリズムとの実装なので、やっぱりソフトの範疇じゃないの？
電気的・物理的な特性と関係してない。

>>579
> ポインタ、再帰、λ関数、NP完全も理解できないハード専業屋
組込み屋には、クソの役にも立たないことを並べ立てている様な…。
組込み屋なら、ｚ変換・伝達関数・インパルス応答辺りじゃないの?

>>582
ﾜﾛﾀｗ

>>584
> そういう偉そうな事は、Verilog-HDL, VHDLで
>>585
> でも、HDL書きもハード屋と言うよりソフト屋の希ガス。www
まぁまぁｗ

そうだね、ハード屋とソフト屋の最大の違いは、
「一日に何回、デバッグサイクルを回せるか?」と悩むのがソフト屋。サイクルを出来るだけ多く回すのを良しとする人種。
一方ハード屋は、デバッグサイクル三回で並、二回でプロ、一回で神。ワンショットの一発勝負で仕上げるのがハード屋。
この違いは大きいかな?

>>589
そっとしておこうよ。
がっこうで学んだことが、そのまま実社会でも通用すると思っている甘ちゃんなんだから。

デバッグサイクルってのはなんのことかいな？
HDLはハードよりの思考じゃないとできないような

半田付けの1つも出来ないで、ハード屋というなかれ。
オシロの操作でボタンを指が覚えていて、チャチャっと操作できるのがハード屋。
「えーと、ch1の、垂直の、感度の・・・・」　
「とりあえず採って、止めて。よーし、ポジションツマミでドンドン送って・・・」というのがソフト屋。
回路図を見て、電線の太さが見えるのがハード屋。
回路図を見て、2個入りOP AMP ICのピン番を見て、ピン入れ替えまでわかってしまうのがハード屋。

そう言えば(自称)ハード屋が、2個入りOP Ampの電源ラインを回路図通りに
接続してなくて「動かないぃぃ!!」って騒いでたな。
NECだっけ? CPUのキャッシュメモリの電源ラインを繋ぎ忘れたまま出荷したのは?

>>593
「回路図を見て」はそう思うけど、オシロは微妙だなぁ。
設計→一発完動→評価は下っ端で、本人はオシロの操作を忘れかけている。
普段はソフト屋がジタバタしてるのを眺めてるけど、問題が起きたらハードかソフトか、スッパリと切り分ける。それがハード屋。

あれ、ここってなんのスレ?w

さてARMの話題に戻ろうか^^

>>586
修士持ってて現場かいな落ちぶれてるなぁ・・・

中卒・専門学校卒もがんばろうな！

> あれ、ここってなんのスレ?w

ARMが提供するCortex-M0コアをFPGAに載せるHDL屋が、自分はハード屋と
言い張るスレでは？

新聞配達員が、マスコミ関係者を名乗るみたいなものか？

>597
今は大学院卒が過剰だから仕方ないんじゃないか?

よっぽど学歴コンプレックスな奴が多いんだな。
修士どころか、東工大博士持ちでH8の現場逝きな奴も多数居るのに。
JSPとかToppersとか開発して、東大の助教やら特任講師に迎えられてたが。

学歴なんぞどうでもいい。
スレチ

JSPとか、Toppersとか、未踏とか、実社会では使えない院卒に金をばらまく
方便でしょ。助教やら特任講師のポストを与えるのを含めて。

あと、TRONといえば、パーソナルなんとか。

東工大と言えば、居直りの菅直人と負け(MAKE)ですな。

>>596
何かネタを頼む．．．　今は　ARMとかチップで盛り上がる時代じゃ無くなったのかもね．．．
つい釣られて　ｗ　ソフト屋か．．．う〜む
確かにファームウェアを含めPCアプリ一体のビジネスモデルを提案できるソフト屋は大事だが．．．　土方はいらん！
それに　機能追加やメンテを考えればファームウェアも早くOOP化せんと．．．
ハード屋が心配する事じゃないとは思うが．．．

ネタってほどじゃないけどLPC1114/302の低消費がちょっと微妙だったので
STM32Lに期待中

>>604
そんな提案するペテン師なら、掃いて捨てるほどいるのでは？そして、
実装する土方は誰もいなくなった。

書換可能なフラッシュとはいえ、アップデートはブート領域以外全書換が
前提の組み込みでOOP化なんて、ムダにコードが肥大化するだけでメリット
あるか？仮想関数テーブルだけどっか別のセグメントでも置くとオブジェ
クト単位で機能追加版と差し替えできるとか。まぁ、新たにバグが出るだけ
の予感。

>>605
Nuvoton(で綴り合ってたっけ？、元WinBond)の、USB内蔵Cortex-M0がDigikey
で安くていいかなと思ったが、データシート見たら消費電流50mAとかズバ抜け
て大食らい。

>JSPとか、Toppersとか、未踏とか、実社会では使えない院卒に金をばらまく
>方便でしょ。助教やら特任講師のポストを与えるのを含めて。
なるほど
院卒レベルの設計、実装ってあの程度なのか？

>>606
LPC1114/302って起動直後（12MHzだから）3mAくらい食うんですよね。
STM32Lは起動直後のクロックが遅そうなんでちょっと期待しているんですよ。

>>608
そもそも、LPC1114/302って終息で、カンマ以降のサフィックスが違う
後継品への移行推奨ではなかったかと。

あと、低消費電力のL付きシリーズってのがあった記憶が。

>>609
LPC1114FBD48/302みたいに/xx2になっているのが所謂L付ですよ。

>>606
> データシート見たら消費電流50mAとかズバ抜けて大食らい。
へえ〜、覚えておこう。

>>599
> HDL屋が、自分はハード屋と言い張るスレでは？
それで思い出したけど、その気になれば回路図もHDLで書けたハズ。
要はネットリストを吐き出すことが出来て、部品情報がDBとリンクしていればなんでもいいんだよな…。

>>611
ここのスレ連中なら、HDLで簡単なハードぐらい設計できるだろうからな

問題切り分けにハード屋だけで出来たの
見たことねえ
逆は多いがな
結局個人のレベルに依存するだけの話

CADの流行りはじめの頃、ネットリストって何、状態の人がいたなあ

ハード屋＝クライアントって図式が多いから
そういう観点からはハード側がソフト側に
問題投げてくる場合が多い気がする。

それに、大抵の問題は複雑なロジック扱うソフト屋が抱えてるし、
そうでなくても修正はソフト側からやる方が簡単だし。

でも、規模が小さければハード屋ソフト屋って言ってる間に
問題片付けろと思うｗ

>>614
初耳。具体的にいつ頃？

みんなコンパイラはなに使ってる？

論理和CADの頃の話だよ

CR3000 とかじゃね？
いや、流行ってないけど・・・

DS-5Pro

突然だけど　Logitech　のC910というウエブカメラにDaVinciのDM368が載っているようだよ。

Linux（FreeBSD)で動くUVCドライバがあるそうだ。
開発は上海某社

ARM純正コンパイラってgccと比べてどれくらい性能いいの?
NEONのコードって効くの?

533だけど、とりあえずポチった。どーせ8bitだろうけど。
200万画素、FullHDで充分なので16bit A/Dの静止画カメラ出ないかな。

アンカー忘れたけど、>>621 のLogitech C910ね。
DaVinciなら資料も入手できるだろうし。

センサはＯｍｎｉｖｉｓｉｏｎのＯＶ９２１５らしい。

８、１０、１２ｂｉｔ狩野だがレジスタが１２びｔでファーム書き換えればできるが
線さ作ったのがどこかわからないから。

なおＭｉｃｒｏｓｏｆｔの同等品もＤａＶｉｎｃｉだが開発は自社（別会社）らしい。

おいらは上海から激安１０８０Ｐ　ＩＰかめらか出るのを待つ。



Ｌ者もＭ者も両方買ったけどしらっ茶けた絵だ。ＷＤＲにし手君ないかな。

＞＞16bit A/Dの静止画カメラ

Ｃ−もｓは　巻く自体が薄すぎて無理
とらんぢすた派遅すぎて無理
言ってることはたぶんＷＤＲ（高速煮中露光）
ＤａＶｉｎｃｉならＤＭ３６８で狩野だということ。

ＯＰＭＩまでいらない。高すぎ。

ID:YCrUPa9t
スレチなことに気がついてないらしい

>>628

店員

本当だ。Ｍと書いてあった。

しかもＭ３．

何だトラ儀の付録クラブでした。

では際なら

さいならと書く ... 実は居座って出て行かない。

ミニ菅直人と予想。

(アルファベットを全角で書く奴って、エンジニアだとは思えないんだよな)

（未だにそんな呆けたこと言ってるのが、いるんだな）

(>>633 個人の主観だからｽﾙｰﾖﾛ)

その間にPICスレに
> １６Ｆ８８クラスに組み込んだ経験があればオーディオ用途で最高
> 何ｋＨｚくらいまでのＬＰＦ作れる、とか言えると思ったんだけど。
というレスがあったから、「15kHz位か?」とレスった。
http://kamome.2ch.net/test/read.cgi/denki/1305436859/455-482

レスった後、ARMの方が簡単でもっと性能出るじゃんと思ったw

ID:fohdWwapはなかなか面白いヤツだな
ｽﾙｰﾖﾛなら予めそう断っておいて書くか書くこと自体やめとけばいいんじゃね？
反応された後でｽﾙｰﾖﾛじゃ意味ねえし。

Mではビデオどころか音も通らないのでさらばです。

>>622
CortexだとGCCに追い上げられて大差無い
FPU,NEON,Thumb code等のハンドリングを
含めるならARMコンパイラが便利
ってARMのおじさんが言ってた

世界レベルで評価するならARMには優秀な人は山ほどいるからなあ。
中国だって、アメリカ西海岸の卒業でキャリア積んで国に帰ってきて事業してるなんてざらに見るし、
ARMの世界だとそういうのが山ほどいるからね。優秀さと言う意味では日本の評価のそれとは違うな。
逆に日本の教育に汚染されていないと言う意味で、今までを反省し底辺がキャリアを積むならば世界に通用するよ。
過去の人は驕りを反省し、日本らしい良さや特徴を理解し、自らの強みに出来ないと難しい世の中だろうね。

ここはペテン師がつぶやくスレ？

ARMだから特別ってことは、何一つないと思う。

そうそう、日立はいいよね。

>>638
ん？　>>639が言う様に　ARMだからという事じゃないんじゃね　このGCCの時代に．．．
日本のコミュニティー形成が民族の性格かしらんが　極端に悪いのが原因じゃね？
会社の仲間だけで回るコミュニティーとか　ｗ　その結果　ガラパゴス．．．

回帰(回亀)政策ってヤツだよね。
何だかんだ言って、一流大学で揉まれてきた高学歴を重用する。

日本はガラパゴス。井の中の蛙。ずっと居座ってるだけの馬鹿ボンボンがのさばる。
ジャイアンの俺様リサイタル(HEW)に付き合う馬鹿が優遇される。

つーかarmの下回り汚い

質問です。
IARを使って、LPC1114のプログラム開発をしているのですが、
電源を一度切って、リセットスタートさせると動作しません。
サンプルのblinkyはそんなことはないのですが。

？？状態です。

「僕がなにか間違っているのですか?」という質問なら答えはYesかもしれないね。

644です。
IRCの発振周波数が、
デバッグ時 10MHz、リセットスタート時 12MHzというのが原因とは
分かったのですが、なぜそうなるのか分かりません。
どなたかわかりますか？

初期化ルーチンがバグってるだろう、としか予想できない。

設定忘れがあるんじゃないか?

ソース晒さないと
適当な答えしか出てこんだろうに

すみません、PLLを使っていないので、関係するとしたらSystemInitだけと思います。
void SystemInit (void)
{
uint32_t i;

#ifdef __DEBUG_RAM
LPC_SYSCON->SYSMEMREMAP = 0x1; /* remap to internal RAM */
#else
#ifdef __DEBUG_FLASH
LPC_SYSCON->SYSMEMREMAP = 0x2; /* remap to internal flash */
#endif
#endif

#if (CLOCK_SETUP) /* Clock Setup */
/* bit 0 default is crystal bypass,
bit1 0=0~20Mhz crystal input, 1=15~50Mhz crystal input. */
LPC_SYSCON->SYSOSCCTRL = 0x00;

/* main system OSC run is cleared, bit 5 in PDRUNCFG register */
LPC_SYSCON->PDRUNCFG &= ~(0x1<<5);
/* Wait 200us for OSC to be stablized, no status
indication, dummy wait. */
for ( i = 0; i < 0x100; i++ );

#if (MAIN_PLL_SETUP)
Main_PLL_Setup();
#endif

#if (USB_CLK_SETUP)
USB_PLL_Setup();
#else
/* Enable USB clock. USB clock bit 8 and 10 in PDRUNCFG. */
LPC_SYSCON->PDRUNCFG &= ~((0x1<<8)|(0x1<<10));
#endif

#endif /* endif CLOCK_SETUP */

/* System clock to the IOCON needs to be enabled or
most of the I/O related peripherals won't work. */
LPC_SYSCON->SYSAHBCLKCTRL |= (1<<16);
return;
}

remap to internal flash
が妖しそうだけど、SystemInitってどこに配置されてるのかな？
__DEBUG_FLASHって使ってる？

IDEはIARで、サンプルをベースに使用しています。
SystemInitはmainの一番最初です。
DEBUG_FLASHでデバッグしています。

SystemInitのコードがflash上にあるのなら
flashをremapすると次に実行するコードが行方不明みたい事になってるんじゃないかと

サンプルといわれても、define使いまくりだと作るとこから追っかけないとわからないような（見たわけじゃないから）

remapってのは割り込みベクタの切り替えかいな？（マニュアル読んでみた）
boot部分で動かす分にはおかしくならない感じだけど

ベクタ領域のsumチェックに引っ掛かってるだけかと

644です。
IARのバグでした。最新版にアップデートしたら直りました。
お騒がせしまして、すみませんでした。

ARM7とかCortex-M3でUSB 480Mbpsをサポートしているのがあるけど、使った奴居る?
EZ-USBをチューニングするより楽かな?

別スレ向け返信
> 18 名前：774ワット発電中さん[] 投稿日：2011/07/01(金) 22:42:38.15 ID:tUEiPens
> ARMに20pinとかのDIPタイプの石があれば使ってみたいよw
知る限り、ARMにDIPは無いな。
ただ、電子工作向きならこれかな。
　TI:LM3S101
　　ttp://focus.tij.co.jp/jp/docs/prod/folders/print/lm3s101.html
1.27mmピッチの28SOICパッケージがあるから、変換基板への半田付けは楽勝。

CORTEX-M3 BUS付きで、数百ロットで買えるものがない。
Digikeyは数買うときに納期が心配だし。
メジャーメーカーは結局大量ロットを買わないと使えないのか...

だって、たかが数百個でいくらの利益になるんよ？
手間（＝人件費）ばっかりかかってしまって儲からないじゃん

だからIBM-PCみたいな「規格」が必要なんだけどな、本当は。
CortexでPCIまたはPCIeバスslotの生えたm-ATX基板みたいなのが出れば良いのに。

>>660
PCIならPC104があるけどさ…。

組込の場合、規格化しにくくない?
計測用途アナログ重視、メカ制御パワー重視、制御用途通信IFの数重視。使われ方が違う。

VME、CAMAC

VMEは68Kバスだっけ? CAMACは知らないや。
ARM一つとってもやたらと品種が多いのは、それだけ用途が多いんだろうな。

つか、ARM以外の選択肢が日本産以外思い浮かばないんだが…

余程のヘタレ以外は日本産なんて使うメリットないじゃん

ARM以外は、乾電池動作の低消費電力か、処理速度が思いっ切り必要かでない限り、選択肢にならないなぁ。
ARMはカバーするレンジが広いし。

>>661
PC104はISAバス

ISAなんてとっくにオワコン。組込み向けならPCI-compactなんてのも有るな。
VMEは汎用バス。MC68kだけでなく、88kも、PPC, VAX, MIPS, SPARC,
色々有るよ。

制御系は使われ方が色々有るからこそ、規格化する意味が有るんだろ。

ARMも1.5GHzまで達したから、もうすぐそういう時代がくるかもしんないね。
でも、その手の上位制御ボードは当分x86じゃないか?

ただ、これまで386/486辺りでVxWorksを動かしていた下位制御ボードの後継として、
ARM-Linuxを選ぶ事例が増えているらしい。
ニュースソースは俺w

いや実はウチも…。産総研のロボット見学しに行ったら、アチラさんも
ART-Linuxでかなり高度なRT処理やってた。
消費電力敵に、RT-Linux/ARMって構成はこれから広がるんじゃ?

intelは電気食い過ぎ、発熱酷過ぎ。atomはいきなり能力低過ぎ。
せっかくatomが省エネでも、抱き合わせのchipsetがバカ食いするので
意味無い。

IntelのCPUはMMXみたいなハード持ってるからロボット用途には不要かもね

>>671
産業用ロボットだとMMXみたいなのあると凄く楽なんだけどね。
趣味の模型的な要素じゃつかわないよなー

MMXでいいなら、Cortex-A8のNEONでいいやん

Intel謹製のwirelessMMXと呼ばれる命令群もありました…

BeagleBoardみたく、ARM+DSPで良いよ、もう。

まぁintelのMMXやSSE命令もダイ面積の0.1%も取ってなくて、実は今はもう
ほとんど使われない昔の複雑過ぎるi386 CISC命令が大半を占めてるらしい
けど。盲腸が体の9割を占有してるようなもんだな。
そのうち一部、投機実行とか実行時Out-of-Orderとかを削って省エネにしたのが
atom.元から最小限の命令だけで設計されてるRISCとは比較に成らんけど。

>>675
> ほとんど使われない昔の複雑過ぎるi386 CISC命令が大半を占めてるらしい
古典だけど、j20695h.pdf(AMD-K6R プロセッサ データシート)が面白いよ。
x86の命令デコードとかの詳細が書かれてて、読み物として面白い。

> BeagleBoardみたく、ARM+DSPで良いよ、もう。
DSPでx86命令をデコードしてARMで実行したら、メチャ速いQEMUになるんじゃないかと、ずっと思ってるw

>>676
読んだ。この時点でもすでに過去の遺産を背負って複雑なことになっとるのな
コンパイラ作る人って偉いなぁ

>675
ちょっと疑問なんだけどi386DXが27万5000個のトランジスタで実現できた機能を
例えばAtomの4700万トランジスタの大半を使うってのはおかしくない？

>>678
1クロックあたりの処理量が同じならね

同じコードが矛盾なく動く ≠ 同じ機能

デュアルコアによる並列処理は別にしても、一部の特殊な命令を除いて、圧倒
的に出現頻度が多い、整数演算やロード/ストア命令の処理クロック数は286
/386の時代からほとんど変わっていないのでは？

瑣末的な違いは抜きにして、性能向上はクロック向上と、同一ダイに搭載した
一次/二次キャッシュの大容量化による、見かけ上のバスパフォーマンス向上
による部分が大きいかと。

キャッシュより処理パイプラインの複雑化(多段化)が効いてそう

>>680
> 整数演算やロード/ストア命令の処理クロック数は286
> /386の時代からほとんど変わっていないのでは？
Pentium/K5以前と、PentiumPro/K6以降とで、アーキテクチャの大変更があったんだ。
PentiumPro/K6以降は、CISCの皮を被せたRISCプロセッサになってる。

4700万Trの大半はキャッシュで、コア部分はそんなに増えてないがな。
クロックは劇的に上がってるが、そのクロックはパイプラインの最も複雑な部分の
FF to FFの配線長で制限されてることに変わりはない。
intelは微細加工技術で誤魔化してるが、過去の互換性を捨てて盲腸みたいな
CISC命令を捨てて、
>圧倒的に出現頻度が多い、整数演算やロード/ストア命令
だけに絞れば、劇的にクロック上げられるハズ。

Windows動かなく成るからやらないだろうけど、どうせ我々組込み屋は
>>680 さんが言うような単純命令しか使わないし。現状でもARMやPIC
の命令でこと足りてるわけだし。

以前80x87があったように、「昔の命令プロセッサ」を独立させればいい!?

具体的にどういうのが「昔の命令」って思っているんだ？

パイプライン化で面倒くさいのは、特定命令のOPコードのデコードよりも、レジ
スタ修飾付きのメモリアドレスに対してイミディエイト値を書いたり、演算
したりするような、めったに使われないアドレッシングモードの方では？

mini 2440買ってしまった

スレチな気もするけど、さすがARMスレだな。レベルが高いわ。

>>684
>以前80x87があったように、「昔の命令プロセッサ」を独立させればいい!?
間違えてたらゴメン。
あれは確かx86もデコードしてて、x87命令を見つけたら動作停止。
次にスヌーブしていたx87が処理して終わったら割り込みをx86に発行していた希ガス
とっても非効率。

>>685
> パイプライン化で面倒くさいのは、
> めったに使われないアドレッシングモードの方では？
>>676を読めばわかるけど、面倒なアドレッシングもOPコードに分解されてスケジューリングされてからバイブラインに投入するから、どうってことないみたいよ。

x86の古い命令で厄介なのって、
それっらよりも、ストリング命令とかリピート命令とかじゃないの?

あと、セグメントレジスタをいじってしまうプログラムも問題児か。

セグメントレジスタいじらないとまともなアプリ組めないだろｗ

だからそれら全部まとめて、FF to FFのパスが延びるんだってば。
使うひとにとってはどうってことないんだけど、そう見せ掛けるためには
凄く大変な実装しなきゃいけない。
凄く面倒なアドレッシングや、便利過ぎるストリング・リピート命令なんか削って
ロード・ストアに限定すれば、パイポラインもFF to FFも凄くスッキリする。

>>688
> x86の古い命令で厄介なのって、
x86の古い命令は16bit CISC CPUとしての命令だから、厄介でもあるし、厄介では無いとも言える。
少なくともリピート命令は予測可能な命令。
それよりも厄介なのは、可変長命令。

元々8086では新規に命令セットが定義された。ただし、8080の上位互換を保つ様に定義されている。
そのため、8080のアセンブラは8086に機械的にコンバート出来た。
ただ、この長さが判らない可変長命令であったことが尾を引く。

可変長命令の長さが判らなければ、実際に読んでみないと次の命令が見つからない。
もし長さが判れば、デコードにもパイプラインで並列解析が出来るだろうが、x86命令ではそれが出来ない。
これがデコーダーにおける厄介な命令。

ちなみに、SSE命令になると長さが判る様に改良されており、こちらならデコードは簡単。

>>690
命令を実行するパイプラインなんて対した問題じゃないんだ。
問題はデコーダでありスケジューラ。

凄く面倒なアドレッシングや、便利過ぎるストリング・リピート命令を削ってもパイプラインが簡素化する訳じゃない。
そんなのは前段のデコーダとスケジューラで処理済みなんだから。

Coretex-M3ならば、5μsくらいのストローブ
を割り込みとして入力して、ソフトでデータラッチ
動作、十分にできるよね。

ストリング命令とかリピートとか、一部の高度なアドレシングモードとか、
あとセグメントレジスタをいじるとかは、

デコード時に命令をマクロ展開して多数の命令に変換するだろ?
一定数以上のμOPsに変換する命令って、デコードできる強力なデコーダは一つだけじゃなかったっけ?
それ以外のデコーダは単純命令用の簡易デコーダで。

まあ、デコーダでx86命令の展開さえ終わってしまえば、あとの処理は単純なものが大半だが、
実行ステージよりデコードステージの方が長い（ステージ数が多い）ほどなんだから、
デコード部分こそネックなんだよな、たしかに。

可変長命令も、長さが数種類程度なら問題はなかったんだろうな。
x86の可変長の範囲は1〜12バイトぐらいだっけ? あまりにも多種多様すぎるのが問題なのか。

>>694
うん、暑いらしいよ
ttp://pc.watch.impress.co.jp/docs/2008/0523/kaigai441.htm

「(CISCであるx86命令セットの)可変長命令のデコーダは、固定長命令のRISCのデコーダより電力を消費する。IntelやAMDのプロセッサのサーマルマップ(温度分布図)を見れば、 チップ上の最も熱いエリアがデコーダ部分であることがわかる。

>>693
100〜500命令位実行できるかな。
GPIOなら十分出来る。でもADCならADCの特性もあるからなんとも。
他に出来ないのはなんだろう…

CISCであるx86のトリックに気づいて...

もうx86アーキ捨てて、windowsも
ドライバーとか全て実行時コンパイルして逐次ARMコードにしていこう

そういえばARMで動くwindowsってどんな仕組みなの？

>>699
Windows CE系の話だとすれば、ARMや他のMIPS,SH等それぞれのターゲット
CPU向けに同じソースからバイナリを生成する。

ゲイツ自身の意向かどうかは知らないが、Microsoftの方針は、ゆくゆくは
Intelアーキテクチャ(x86バイナリ)に依存しているWin32APIを捨てて、
Windows自体が、.NETフレームワークという一種の仮想環境(仮想CPU)で動く
ようにすることで、アプリ層は中間コードで実行され、特定CPUアーキテク
チャへの依存性をなくすことらしい。

一部の年寄りなら知ってる、UCSD p-Systemみたいなもんだ。

つまり、Javaなどに近い方向。全体のパフォーマンスは大きく下がるが、Intel
などにとってはより高性能なCPUへの潜在需要が生まれるのでむしろ好都合。

最大の理由は、膨大な過去のしがらみと、サポートに要するコスト。MS-DOSから
Windowsへの移行は大成功したが、次の移行に失敗したら、Microsoftは沈んで
消えるかもしれんな。

>>700
ありがと。windows8が気になっててさ。
.netはいいとして、従来のx86バイナリをどうやってARMで実行するのか。
すっぱり切り捨てるのか、いまどきのARMならエミュで実用になるのか。

>>701
切り捨てるんじゃなかったっけ？
WP7の存在意義は…？

>>701
騙されてはいかんぜよ。
「Intelアーキテクチャ(x86バイナリ)に依存しているWin32API」なんて嘘もいいところ。
ttp://en.wikipedia.org/wiki/Windows_NT
Windows NT 4.0 was the last major release to support Alpha, MIPS, or PowerPC, though development of Windows 2000 for Alpha continued until August 1999,

今でもXBoxで、WindowsがPowerPCで動いているんだから。

うまく、パクッたらしい、ほんとかどうか知らんけど

>>703
そういや初期のNTは色々なアーキテクチャで動作してたっけ。

ホラ？話でもしたいのかな

>>705
うん、元々WindowsNTはintel i960かi860向けに開発が始まったもの。
ポータビリティは最初っから考慮されてて、HALでハードの違いを吸収する構成。

Win32APIにしてもWindowsサブシステム用のAPIに過ぎなくて、他にもPOSIXサブシステムがある。
無くなったOS/2サブシステムもあったから、OS/2 v3 = WindowsNTってのは嘘ではない。
最新は知らないけど、Windows Services for UNIXと呼ばれる完全にUNIX化するパッケージも提供されている。

Win32APIを使っていれば、アプリはリコンパイルするだけでいけるだろうね。
実際、NT系とCE系の親和性はWin32APIで確保されているし。

ネットブックならぬARMを搭載したのはスマートブックと言うらしいけど、Windows8で復活するかも。楽しみ。

NT 4.0というか、NT 3.5だか3.51から複数のアーキテクチャに対応していた
けど、それは単に「Windows」という商標を使っていただけで、同じバイナリ
(.exe)が動いたわけではない。OSも違えば、それぞれのCPU向けのバイナリを
生成する必要からコンパイラも違っていた。

そういや、その頃だっけMSDNに加入したのは。品川プリンスかどっかでNTの
開発者イベントへ行ったっけか。

結局、AlphaもMIPSもPowerPCも事実上死んでマイクロソフトの努力は無駄に
なったが、従来方式のマルチCPU展開ではコストが掛かり過ぎるので、最低
でもユーザーモードで走るアプリケーションについては、特定のCPUアーキ
テクチャに依存しない中間コードで走るようにしたいんだと思う。

>>708
余談だけど、DEC Alpha上のWindowsNTには、x86からのバイナリトランスレータも搭載されてた。
作ったのはDECだっけ?
そんな訳でx86用をインスコすると、初回は遅いけどバイナリがAlpha用に置換されて速く実行出来た。

.NETもいいけど、一度実行したら置換してくれれば尚いいのに。

過去を懐かしんで宣伝かい？

温故知新というじゃないか、歴史は繰り返すものなんだよ。
未来は常に新しいものだなんて思ってるのか?
過去の焼き直しってのがいっぱいあるぞw

>>711
そうだね、本当にそうだ。
今のところARM上のメジャーなOSと言えばLinux,Android,WinCEだけど、もしかすると来年にはWindows8が加わっているんだから。

>>709
FX!32のことだね、懐かしい。
あと、Itanium系だと拡張カード中の拡張BIOS（x86コード）を実行するためのトランスレータがBIOS中にある。機能は限定的だけど。
他にはトランスメタとかのCMS（Code Morphing Software）とかもあったネ

今は、GPUもあることだし、NVIDIAとかがWindows8用のx86トランスレータを作ってくれんかな？
まあレーテンシが大きいんで組み込み用には使えんが。

OMAP5の動物ボードはまだでつか？

>>696
mbedでやってみました。
最初、適当なポートでやったら、約5usくらいで応答。
結局、P0.0のp9が最速のようで、約2usでした。
使うポートによってレイテンシが異なるってのは
Coretex-M3では常識ですか？

そりゃたしかARMは割り込みエントリー１つで、割り込み要因判定して分岐だからじゃね？

>>716
GPIO割り込みはEINT3のHandlerの中で、
ポーリングされてるってことですね。
mbedって、このあたりのソースは無いんでしたっけ。
ありがとうございました。

非アライメントアクセスとかエンディアン依存とかしてる
Win32アプリはリコンパイルでちゃんと動くのだろうか?

やっぱり行儀の良いプログラムじゃないとダメなんだろうな。

ARMってビッグエンディアンだっけ、
マッパーとかで両対応できるよね

え、リトルじゃあ、基本

そうだよね、エンディアンの話が出てきたからx86と逆なのかと勘違いした

以前までPICやってたのですがそろそろ新しいマイコンを使おうと思い
最近よく聞くARMを学習しようと思いました。

ARMの学習でおすすめのサイトなどはあるでしょうか？
それとも学習本を買った方がよいのでしょうか？

>>722
STM32 Primer2　でも買って、
添付のプロジェクトでも眺めてみては？

Cortex M3でいろいろ遊びたいのですが、入手性、開発環境、情報の入手性からいくとデバイスメーカーは、

NXPが無難でしょうか。

NXPが無難でしょうね。

横から失礼、
NXPで外部BUS付きを出す予定とか、情報知りませんか？

>>726
Cortex-M0/3には無いけど、ARM7にはあった気が…
(Cortex-M3って、ARM7の機能縮小版の認識)

>>727
でも、STMの石だと外部SRAM用のポート（NAND兼用）があるんだよな。FSMCだっけ？

CortexMって小型システム用だから、
外部バスを必要とするような使い方は想定外じゃなかったっけ。

外部SRAMなどメモリを取り付けることができるものもあるが、
バス幅が16bitなど狭くなってて、システム用に使うのは無理だろう。

外部バスを使うような大きめのシステムなら、同じCortexでもRかAを使うべきなんじゃないか?

>>728
あるある。だからCoretex-M3にSRAMだのLCDを繋ぎたかったら、STを選んでる。
>>729
> バス幅が16bitなど狭くなってて、システム用に使うのは無理だろう。
俺は16bitでいいかな。
最近の16bitはベースクロックが上がってて、速いSRAMでもそこそこ行けるし。
でも非同期32bitは配線がメンドーだし、32bitならPCIを選ぶなぁ。

>>730
あー言われてみればたしかにそうだわ。
メモリ"バス"として使うんならビット数は少ないほうが配線しやすい。

STマイクロのやつって、CQの付録基板が出た頃に、外部バスのウェイト端子が
使えないエラッタがあると聞いた気がするけど、今は直ってるの？

Cortex-M3で外部バス付きは、ST以外だとTIにもあるね。

NXPはメーカー提供のサンプルコード(CMSISライブラリ含む)が糞というか
バグありで動作確認にも使えん。(逆にハマる)

富士通のも外部バスあるね。

>>727
LPC1788は(32bit)外部バスあるよ。
SDR-SDRAMならメモリコントローラも内蔵してたと思った。
ttp://www.nxp-lpc.com/

今度M3を使う案件があるんだが、 みんな開発環境はどうしてる？
Keil とIARってどっちがやりやすい？
ケチって、GCCとかでも大丈夫かな。

え？　基本GCCじゃねーのか？

>>734
知らなかった。しかもかなり豪勢な仕様。面白いなぁ。

>>735
GCCって仕事でも使う物なのか？

仕事の半分はgccでできている

ARMコンバイラもDS-5じゃPROにしか
付いてこなくなったしな

>735
ARM用のgccは結構良くできてて、油断するとgccのほうがkeilより良いコード出てたりするからな。
でもkeilだろ常考。デバッグ窓の見やすさは異常。

IARはアーキテクチャいろいろ跨いで使うときはサポートが早くてプロジェクトの素早い立ち上げによさそうだが、
アーキテクチャの細かい部分のサポートがないから初期対応が早いといういい方も出来そうなほど
周辺デバイスのサポートが駄目。

ARM開発用に限っても、CodeRedとか、Code Sourceryとか、gccベースの
の有償(商用)コンパイラってあるよね。

結局のところ、タダで手に入るものにわざわざサービス対価としての金を
払わない一方で、高額なコストを払っておけば何か問題が発生した時の
言い訳として通用すると思う、日本人のケチさ加減と、無責任体質を反映
した消費行動の顕れか？

江崎先生がTECH-Iをまるまる執筆かさすがだ

鯖系だとLinuxなんかはgcc使ってない仕事の方が珍しいけど
組み込みだと中小ほどgccを避けるイメージだな

俺は実際コンパイラに何かあったら
なんとかする時間なんてないから商用ライセンスに頼ってる

商用でもなんかあったら一緒なんだけど上に問題をエスカレートして
自分の問題じゃなく出来るのは大きい

>>737
あとLPC17xxって23xx/24xxからの置き換えを狙っているっぽいね
ttp://www.nxp-lpc.com/lineup.html

>>741
結構前に少し触っただけだが、IARの方がデバッグ窓とか見やすい印象あるんだが、今はKeilの方がいいのかな？

>>744
海外だと有償コンパイラの方がメジャーって話も聞いたことあるけど、どうなんだろな。大手も予算あるから当然有償コンパイラ使ってると思ってたわ。

gcc触る時間あればいいんだが、今回の案件は時間なさそうだからなあ。

よっぽど金が余ってるならともかく
まずgcc試して、それからだろう

ん？　GCCに何か問題あるの？　KEILやIARから今ではGCCなんだが・・・

>>744
ARM9の頃はgcc腐ってたから
昔からやってる所はRVDS使ってるな
Linuxだと遅いけどgccてのも有ったが

>>746
keilはARMの子会社だから安心出来るイメージ
DS-5も実質keil開発じゃ無かったっけ?
IARも来月価格改正だったような

東電社員は、みな鬼畜。

gccにしとけば、Cortex-Mや-Aもやる際にgccしか選択肢がなさそうだし、移植が楽かなと思ってる。

gccが問題なのはサポートではなくコード効率だと思う。
市販コンパイラは最適化が徹底しているという事でしょ。

あと統合環境の使いやすさとか。デバッガとの連携のあたりも。

ライブラリのサイズも市販品はサイズが小さかったりしますね。

gcc　or　純正云々とかより　目先にに突きつけられた難題を打破できない能力の無さが問題なのでは？
今や　無料のgccで　ビジネスに対応できるよ　ｗ
むしろ　純正という屍で食ってる事がオワコンの時代という事に気づけ！　日本型防御システムは終わったんだよ　南無

能力もあるがコストの問題でしょ。
開発環境ごときに時間を避けるようなとこはいいんだろうが。

実際、海外だと有償コンパイラとか使ってるところも多いよ

上司を説得したり、見積もりとったり、注文したり、納品されてインストールするまで
の手間や時間で gcc の開発環境ができちゃいました o...rz

>実際、海外だと有償コンパイラとか使ってるところも多いよ
>実際、海外だと有償コンパイラとか使ってるところも多いよ
>実際、海外だと有償コンパイラとか使ってるところも多いよ

海外チップメーカーはコンパイラなんてわざわざ作らないからね。

>>753
いやARM社は純正とgccに昔のような差は無いと認めてる
だからDS-5は最上位のPROにしかコンバイラ付い無いんじねえかな
まぁVFPやNEONのサポートは上だとも言ってたが

Android-OSのビルドは普通にgccなんだけど、
どうしてARM純正じゃないんだろうね。

googleが必要と思うならARM純正コンパイラを買うのに躊躇しないはず。

gnuの感染とか気にしない人たちなのかな？
趣味や公開コードのコンパイルならともかく、業務の新規開発でgccは使いたくないなぁ

>>762
newlibを使わなければ、gnu感染しないのでは？

業務で違法コピー使ってる企業はあいかわらず多いよね。通常のライセンスで
外注企業にソフトウェアを使わせる行為は、ライセンス貸与に該当する。

たとえ正規に購入したライセンスであっても、偽装請負や客先常駐で、被雇用
関係にない外部の人間にソフトウェアを使わせる行為は、違法。

だけど、IPAも、BSAも、大企業の違法行為は華麗にスルー。

コードが小さいってまさか Thumb コードの事じゃじゃないよね？

>>764 アンカー打て!

すいません、

LPC XPRESSO LPC11U14 (USBデバイス機能つき)　はどこで買えるでしょうか。

見つかりませーん。

>>766
つ ttp://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=EA-XPR-007-ND

2,683 JPY 在庫:5個

>>767
おお、ありがとう。
ほしい人いたら、一緒に注文しますよー。

>>768
なんでここで共同購入しないとならんのだよｗ
おまいが詐欺師じゃない保証もないのに

twitterで知り合いに呼びかけた方が確実かと

共同購入と言えば聞こえはいいが、単に自分の送料を浮かせたいだけでは？

ネット偽善者を装うなら、リスクを負って余分に買って、オクで転売する
なりすればいいのにね。まぁ漏れは買わんけど。(w

自分はこれ注文してみた
ttp://www.embeddedartists.com/products/boards/lpc1343_qsb.php
送料が4.5 EURだったので1個からでもまあ良いかなと

秋月にこんなの増えてた
ttp://akizukidenshi.com/catalog/g/gM-05028/
USBデバイス機能内蔵でCortex-M0らしい

>>773
一瞬、PCの色設定BUGったかと思ったわｗ

>773
これって2つに折れそうな構造になっているのは右側がデバッグボード
左がターゲットボードで最終的には分割出来るって事かな？
そのうちもっと安くターゲットボードだけ発売されたりするのだろうか?

>>775
分割できるっぽいね。
ターゲット部分だけ販売するかはしらない。

中央から切り離せそうだね。

チップ自体にもISPローダ機能があるんだね。

その手のボード、切り離せそうに見えるけど、のこぎりで切るしかないｗ
ミシン目なんてねえからｗ

件のボードはミシン目っぽいのあるように見えるよ

>>780
それは単なるシルクだｗ

>781
この画像だとミシン目っぽく削ってあるように見えるけど
ttp://akizukidenshi.com/img/goods/C/M-05028.JPG

>>782
まあ、買ってみｗ

wをイチイチ付ける奴は、ほんとクズしかいないな

>>775
> これって2つに折れそうな構造に
折れそうでも、折らないほうがいいよ。
折ると部品が破損したり、内部パターンが切れたりするから。
ノコで切ったほうがいいよ。

ＲＪ−４５コネクタってついてないんじゃない？

ルネサスはこのままいけばいつか潰れると思うが、そうすると組み込みはARMの一人勝ちになるのかな？

ARMアーキ優秀だし他は滅びても問題ない

CPU名が冠になるようなパソコンか何か売らないとだめだよ。
RX680000とか。「今、黄金のマスクが甦る。再び」
そのままRXなんて名前じゃせいぜいくるまにしか入れてもらえないだろう？

ルネか．．．　南無
ARMの利点は評価基板が世界中から手に入れられる事だな！
マイコンチップやIC収集家は別にして普通は基板をいたぶってハードやプログラムを完成させるのが目的だろうから．．．
その点ルネに秋月は貢献したが　もはやディスコンチップの基板ばかりの現状ではどうにもならん．．．

ルネ偏重の風潮からARM中心の採用になるように社内を説得したいんだが、稟議でなにかいたら良いか悩む。

みんな感じてるARMのメリットってなに？

「みんな使ってます」でいいんじゃね?

「長いものには巻かれろ」
「ハズレくじを引かずに済む」
って辺りじゃないか？
ARMというアーキテクチャが優れている訳じゃない。
多数派だというのが、最大のメリット。

>>791
脊髄反射で書いてしまうな　ｗ　グローバルスタンダード．．．
大事なのは　世界で通用する仕様ですよ。
日本は業界を守る安直な理由で世界の規格をオリジナル化する癖をつけてしまった！

OLIMEXのSTM32-LCDでお遊び中．．．
しかし　CMSISとか中途半端な使い勝手の悪い仕様は止めて欲しいな
あと　stm32F10x_lib.hとかで一括インクルード定義するやり方

ほとんどビルトイン的なものは自前で作ってるし、クラス設計で一括インクルードはプライベート性が損なわれる
当然　オリジナルフレームワークを作り直すハメになる
OOPでなければメーカー供給のライブで良いのだろうけど．．．
GUI　Widgeオブジェクトを作るにはライブ環境の再構築が必須だな

なんかWindowsOSそのものを作っている感じで面白い　ｗ
とりあえず　CLabelクラスとCImageクラスの試作完了！

>>793
ARMはフラグの変化しないオペレーションが可能なので最適化コンパイラを作りやすい。

>>796
意味がわからん。

演算命令単位にフラグを変化させるかどうか指定できるなら、それを指定
できるフィールドが追加されることで命令長が長くなる。

常に演算命令の結果でフラグが変化しないなら、多くのプロセッサなら不要
なゼロとの比較など、演算後の結果判定が必要な場合に、わざわざ演算命令
を追加する必要があり、コード効率が低下。

そもそも、演算命令の結果でフラグが変化しないなら、桁あふれ(キャリー
付き)演算は？

>>796
ｋｗｓｋ

ありゃ　STM32-LCDのタッチスクリーンy値がとんでも値だ．．．　画面アイコンが飛ぶ〜
なんでだろ？　キャリブレーションもやってるのに？　こりゃ　サンプルソースの検討だな

ワラタ　下8ビットがxで上がy値だったのね．．．　ホホホ！

>>797
> できるフィールドが追加されることで命令長が長くなる。
それを承知でフラグ変化無しの命令を組み込んだのはなぜか？

> そもそも、演算命令の結果でフラグが変化しないなら、桁あふれ(キャリー
> 付き)演算は？
もちろんフラグの変化する通常の命令もある。

>>798
分岐条件はフラグ状態で来まる。
分岐条件が成立したあと、実際に分岐するまでにフラグ変化なしの命令を実行できる。

来まる　->　決まる
最適化コンパイラが作りやすいというのは私の推測であって、未確認です。
失礼しました。

フラグを参照して実行するかどうかを決める「条件付き実行」も、
最適化に際して有利だよな。

条件実行の条件指定のために何ビットもとられてるけど。
32bit固定命令長にする必要上、余ったbitが出たってトコじゃないか?

16bit長のthumb命令の場合はフラグ変化の指定も条件付き実行もできなくなってるはず。

>797
＞そもそも、演算命令の結果でフラグが変化しないなら、桁あふれ(キャリー
付き)演算は？

同一の命令でもフラグ変化する場合としない場合があるって読み落としてるだろ?

オレ的には概ね796,802に同意だ。
ただ、「最適化コンパイラを作りやすい」のではなくて、「最適化しやすい」だと思う。

ようやく　Palmライクな画面になった．．．　STM32F103は結構使えるね　STM32-LCD　安い買物だったかな？
STM32F207なんて性能が上で安いときてるから．．．　凄い時代だね．．．

さて、次はChanさんのFatFsインプリとファイルエクスプローラーの作成だな．．．　Fontを小さくせにゃ

開発環境がRowleyの最下位グレードなんで　Paulに文句も言えんが　インテリセンスが欲しい
Segger-Jlinkの組み合せは抜群なんだが．．．　
CでのOOP開発ではインテリセンスが無いとつらいなぁ．．．　AVR　Studio5は楽だ　ｗ

エクスプローラーなんてデザパタ　コンポジットなんで．．．　大変　ｗ

クスン！　RowleyはSTM32F207はまだ未サポートだったのね．．．　orz
Altiumで回路を書き始めて　気付いた　ｗ
PCBアートワーク終わるまでサポートして欲しいな　って　数日だが．．．　無理か　orz

>>802
> 実際に分岐するまでにフラグ変化なしの命令を実行できる。
お〜、なるほど。

>>807
なんか読みにくい文体だと思えば…。
句読点って、小学校で習わなかった?

>>808
しかも、フラグ変化なしの命令も、804さんの指摘してくれた条件付き実行もほとんどダイサイズを消費しない。
なぜなら前者はフラグ保存をスキップするだけ、後者はジャンプ命令に存在するフラグ条件判定と通常の命令の組み合わせで実現できるから。
まあ、これも推定ですけど。

ま、条件付き実行はパイプライン実装の障害になるけどなww

条件分岐よりはペナルティーが小さいだろ

>>810
細かい話しをすれば…、
パイプラインってぶちゃけ途中でFFで叩くだけのもの。
「条件付き実行はパイプライン実装の障害」にはならないよ。

ちょい広い話しをすれば、それってとりあえず全部実行して、パイプラインを出たところで条件に従って取捨選択すればいい。
そう、アウトオブオーダと同じ考えで実装出来そうよ。

でもさ、条件が判っているならパイプラインに投げる前に判断したほうが効率的な訳で…???

>>802
> 分岐条件が成立したあと、実際に分岐するまでにフラグ変化なしの命令を実行できる。
ハード的なメリットはこっちは判りやすいな。
命令デコーダは実行ユニット(各パイプライン)より先行するから、分岐命令を見つける前に実行ユニットから分岐条件の結果が得られるとする。
すると命令デコーダは演算結果を待つ必要が無く、即座に分岐先をフェッチ出来る様になる。
素晴らしい、考えた人は頭いいな。

すると、条件付き実行ってアウトオブオーダの一種なの? >>804

あくまで条件付き実行は1つの命令をスキップするかどうかで、直前の演算
命令によって逐次フラグは変化するので、複数命令をスキップするのに条件
付き実行を並べて使えないし、実際に使える場面は限られる。

局所的に見れば有効だが、結局は遅延分岐とあまり変わらん気がするな。

>>812
> ちょい広い話しをすれば、それってとりあえず全部実行して、パイプラインを出たところで条件に従って取捨選択すればいい。
> そう、アウトオブオーダと同じ考えで実装出来そうよ。

2倍のシリコンを占有して実行ユニットを並べた費用対効果比は？

それと命令デコーダより前段のパイプラインにプリフェッチキューがあって、
両者は別物。

・フラグ変化の許可/禁止指定と条件付き実行とは両立できないの?
条件付き実行の時は必ずフラグ変化するの? >813


>812
＞すると、条件付き実行ってアウトオブオーダの一種なの?
複雑なハードウェアを用いて実行するアウトオブオーダと同等の
（もしくは、それに近い）効果を、小規模なハードウェアだけで実行できるという簡易版じゃないかな?

実際のところ、アウトオブオーダとか分岐予測とかは、
コンパイル時にちょっと工夫すれば近似的な機能を実現できるはずなので、
（某プロセッサみたく、分岐時にLikely指定を付けるヤツとか）、
大昔にコンパイルされたソースの失われたソフト、なんてものでない限り、
プロセッサの複雑化よりもコンパイルしなおす方が効果が高いだろう。

>>813
だからフラグが変化しない命令もある
ARMのアセンブラやマシン語の知識ないの？

ここに簡単に解説してあるぞ
http://www.mztn.org/slasm/arm03.html

さすがに　STM32-LCDでは描画が遅い　ｗ　ICON表示する程度なら問題無いがファイラーはちっょと酷いな
タッチスクリーンClassからファイラーClassにSendMessageするメッセージドリブン式の理由もあるが　遅い
制御機器の操作盤向けには使えるかもな？

FSMCとSDIOがもっと早くなれば解決するかな？　さて、STM32F207基板をFusionPCBに発注するか．．．

しっかし　ファイラーなんかをFreeRTOSなんかで階層設計する事を考えたら　ｗ　バグの度に下に行ったり上に行ったり　大変だろうな
ICONリソースの再利用もたいへんだろうし．．．　数日でプロト完成という事もないな　OOP様　あんがとん！
ただ　難点はCのOOPは超難解という事だな　第三者メンテできんだろ　これ！　C++ができたのが良くわかる　ｗ

ファイラーを作れる人間が、なぜ句読点を打てないんだ

天才プログラマーにはよくある事

変な端末使ってて。とか、が機種依存文字だったりしてｗ

>>820
!?が打てるのに?
>>819
Cでセミコロンが打てるのに?

>>816
> STM32-LCDでは描画が遅い　ｗ
> FSMCとSDIOがもっと早くなれば解決するかな？
フォントを毎回SDから読んでないか?
SRAMも付けてキャッシュすれば?

きっと暑さで頭をやられたんだろうて
そっとしとき

ようやく仕事から解放！　かな入力なんだけど　ｗ
>>821
サンクス！　フォントマネージャーClassに一々メッセージを送ってやりとりするのが不味かったみたい
美咲あたりをフラッシュに入れられれば良いのだが　lwIPとかいろいろ入れるのでなぁ．．．
改良しても　やはり　STM32F2xxあたりに移行した方が無難な感じはする
STM32-LCDのTFTの品質は悪くない　苺さんはARMの推進力だな　ｗ

さて　基板アートワークをおわすとするか．．．

やはり今現場でがんばっている奴はすごいな
俺は大昔、出始めのH8でちょこちょことしたのを作っていたが
いまはスマートフォンとか、組み込み系は大変だね。

>>824
現場は大変ですね　独自性を出せと下命されているので課長クラスが　で　ガラパゴスへと　ｗ

スタンダードの立案が少ないですね
例えば　照明に限れば　DMX、RDM、ACN、DALI、ArtNetやら世界中がしのぎを削っているのに　日本は無し
建築ファシリティーに関すれば　BACNetやらXXXグリットやら．．．．
その上、海外侵略を食い止める為と称して海外の規格を捻じ曲げるという手腕も発揮するものだから
とてもとても規格原文で読んでオブジェクトモデルを設計する身としては　赤面ものです　ｗ

ファイラーか。懐かしいな。
STM32_LCDにFDでも移植してみようかな。

>>826
FD．．．ですか．．．　File Maintainとか．．．　MIFES時代のモジュール設計産物ですね．．．
STM32-LCDでの構築は携帯電話とは違い　OS無しですから　Widgetを全て自分で作る事になります
もうモジュール設計の時代でもないのでOOPでメッセージ、イベントドリブンでオブジェクトカップリングを実現する必要があります
メッセージのルーターはちょっとしたOSになります．．．　なれればそうでもないのですが　なかなか大変な作業です

STM32-LCDでFD画面は無理がありますので　タブ付きノートWidgetとかアイディアが必要と思われます
いずれにしろ　STM32-LCDは　GUI　OOPトレーニングには最適な教材ではないでしょうか

>>772だけど届いた。意外に早かった。
サンプルコード眺め中

mbed と Xpresso の違い（目的）がいまいちわからないです。
だれか教えて。

カブ50にタコメーター、温度計二つ、（関数電卓、）バッテリー電圧計、時計の高機能な
マイコンをつけたいと考えているサンデーマイコン野郎超初心者です。
当初はAVRで考えていたんですが、ARMの方がPCと接続する労力も抑えられそうだし、
将来性もありそうだし、個人レベルでの環境を整えられるなら5年後、10年後には幸せに
なれるのかなと想像しています。
8bitマイコンで実装するのが素直なら多少かじろうかなと思っています。

5年間で部品代、ソフト代トータル10万円のお金を落とすとしてかなり楽しめますかね？
画像動画処理、オーディオ処理には興味なし。普段の生活にマイコンを組み込むことで軽く制御したい。市販品の電子機器と
ほぼ性能が等価で金銭コストがほぼ等価ならそれを作ってみたいなと思っています。
20万円の方がもっとコストパフォーマンスが良いでしょうか？　
あとカブの件はAVRで実装する方が素直ですかね？

>>830
関数電卓はともかく、他の機能はAVRで十分かと。
というより、バイク（でいいですよね？）につけること考えるとノイズとか熱の影響が大きいからしょぼいマイコンの方がいいかも。

電源周りの素人配線を考えるとPICやAVRでの実装が無難っぽいな、
出来合えの基板を埋め込めるスペースがあるならARMでもいいけど。

>>823
> ようやく仕事から解放！　かな入力なんだけど　ｗ
かな入力でも句読点は打てるだろ? 会社でも同じなの?

> 改良しても　やはり　STM32F2xxあたりに移行した方が無難な感じはする
STM32F2でググッたらねむいさんのプログが出てきて、その先ではSTM32F2で動画再生したとか…。
VideoCDが出たのが486の時代だから、120MHzで出来て当たり前なんだけど、そんな時代になったんだな。

>>833
ピンクパイナップルのVideoCDとかまだ持ってるわ…w

おっ　盛り上がってるな
>>833
句読点そんなに気になるか？　2chではこれで通している
見たら　ねむいさんアグレッシブだね　脱帽！　ファームウェアはちょっと苦手そうだけど　闘志がすごい
ねむいさんは　もうF2に行ってるんだ　orz

>>830
832が言うようにAVR　8bitで充分じゃね？
いずれチップSRAMも640KBとか肥大化すると仮定して大きなファームウェアの構築法を勉強するのであれば
投資は良いだろうが　投資しても　教えてくれる師が居ないと．．．

あちきはサブビジネスが農業なんで　いろいろ小物を作って役立ってるよ
発芽促進用LEDモジュールとCO2センサーを組み合わせたりして．．．　光合成細菌にはまっているんで　それの関連制御機器を作りたいな！

>>835
> 句読点そんなに気になるか？　2chではこれで通している
携帯から自分のレスを見てみな。何言っているのか、読みづらい、読みづらい。
なんでワザワザ、頭の中で句読点付けながら読まないといけない?
アンタのルールは知ったこっちゃないが、コテ付けるか句読点付けるか、どっちかにしてくれ。
アボーンするから。

そんなにピリピリしなさんなや。
技術屋は半導体とのコミュニケーションには手を抜かないけど、
人とのコミュニケーションは大雑把なんやから。

大雑把か、やけに神経質かの両極端だな
普段の力を入れてる方向に因るんだろう

なんで文句言ってのかわからんかったが。携帯か。
それおまえの問題じゃね？

携帯　厨に対する嫌が　らせの仕方を覚えたｗ　
文節できれ　いに切らない書き　方だと更にいら　いら感がすごいこ　とになったりする　んじゃね？ｗ

おまえら、消えてくれていいよw

まっ　どうでもいい　なが〜い2chネラーなんで　句読点で爆発してるのはおもろいな　としてしか見ていないよ　ｗ

アホ　ここはそんなスレじゃね！　テクニカルスレだ！　ｗ

消えてくれていいよw

qJrg/ymyが日常も同じ書き方をしているから変えられないんだろうな。

仕事でそんな書類回ってきたらさすがに文句言うわー

かたくなに日本語の文章でも,と.使う奴もいるな。

普通にしていればいいのに、つまらない拘りをするから叩かれる。

"俺は他の奴らとは違うんだ"って中二病をこじらせるとこうなる

>>845
それ、大昔の日本語入力の癖かなんかで、
それで論文みたいなのを統一したことがあったと記憶しているのだが、
まだ生き残りがいるのか！！！

>>849
>>845 → >>846 です。
でも、全角だったよな。

LPC1114 で FATfsは動作実績はあるでしょうか？

FatFSなら既に本家で実装されてる。
ttp://elm-chan.org/junk/32bit/report.html

>>849
”横書きの場合は「、」を用いず、「，」を用いる。”らしい。
ttp://www2.chokai.ne.jp/~assoonas/UC408.HTML
スレ違いなので以降は言語学板のこちらで。
【初心者歓迎】スレ立てるまでもない質問スレ
http://kamome.2ch.net/test/read.cgi/gengo/1311108144/

chanさんが記事連載してくれたらトラ儀とかも買うんだがなあ

chanさんって誰？

>>855
お前は素人だな

>>856
俺も知らないな。そもそも開発するのに本とか買わないなぁ。
メーカーが提供する資料で十分だろ？

俺も知らんね

FatFSの作者様ですお

それは知ってる（汗

訂正
FatFSは知ってる（汗

どうでもいい個人を知らないと潜りとか素人とかないわー
Wikiすらねーじゃん

もう知ってしまったから素人ではなくなったね
よかったね

wiki(笑)

AVRから背伸びしてARM使ってみたいんだけど、まず何を買えば良いのかわからない……
詳しく纏められてるwebページとかありませんか？

>>865
MARY本とかmbed本とかは

>>865
AVRをどう習得したかによるな〜

elm/chan氏のISPケーブルと英文データシートだけでやってたってなら…

ATMELのSAM3S/SAM7Sをどっかから買ってきて
評価ボードの回路図を元に基板自力で用意して、ATMELに置いてあるSAMBAとサンプルコード、
あとCodeSorceryのgccで十分使える様になると思う。
gccのインラインアセンブラとかTOPPERSとかは良く判らないけどな…orz

やりたいことなければ買ってもジャンク箱行き

んん？

いっこずつか

俺のおもちゃ箱には５千円や８千円で買ったCPU基盤がびっちりあるぜｗ
まあ、サンプルソフトでチカチカやったら飽きてポイなんだけどなｗ

ARM使いやすいッスか？
SH2ごときでひーこら言っている俺ですが、ARMにも興味あり

SH2もARMも大差ないんじゃないかな。

そうですか。価格も安いみたいだし秋月から買って試してみようかな

むしろSHだから無駄に苦労するんじゃ内科医?

SHは購入に苦労するからなぁ…。
ところで、CQの最強のSHボードに対抗できそうなボードってARMでお手軽に変えるランクである？
CQのボードを見ていると面白そうなんだけどSHはちょっと勉強してもなぁと思う。

>>876さんのお手軽の価格帯がよくわからない・・・

安ければ安いほど良いよ、当然だよ！！
といいたいけれど、変換基板込みで5千円くらいで…
出来れば増設メモリ込みで5千円ぐらいでorz

リナックスの載せられて、タッチパネル液晶も付けられて
USB2.0もおｋな上で書き込みが楽な石がいいなぁ。
その辺の増設は自前でやりたいので別価格でお願いします。

USBはたしかFSだけど「Atmel AT91SAM9G20) / 400 MHz, RAM 32MB / Flash ROM 8MB」で
9000円だね。と思ったらこいつLCDインタフェース持ってないやつだった。

SHはHEWが付いてるし書き込みも楽だもんね……

NXPとかATMELのチップはブートローダ内蔵でUSB経由で書けるっしょ

ARMにLAMEを埋め込んでハードウェアエンコーダにしてみたら面白そうだけど、
LAMEのソースをどう埋めるかは知らない。どうしたものか

>879
デジキーデ見たら思いのほか安くてびっくりした、しかしBGAしかなかったorz
こういうBGAをそこそこ生かせるような基板設計が出来るようになりたい。
ワークは外注して1万ぐらいでへんてこな基板出したりとか…。
「組み込み - マイクロコントローラ、MCU」で調べると結構出てくるんだな。
…まだまだマイコンすら使いこなせてないのに積んでおく余裕もないんだけど、物欲と学習欲にじわじわとヒットするぜ。

>>883
9000円ってメモリ込みのEddy CPUってボードのお値段

aitendoだと、ARM用の部品未実装基板が\150〜\300ぐらいで売ってるけど
部品集めからだと価格が高くつくかな。
LCD付きとかじゃないし。

>>883
9G20には無いけど同系下位品種(クロック180MHz)のSAM9260とSAM9XEにはPQFP208pinがある。
SAM7SEとかSDRAM品でクロック低めなら両面基板で
SDRAM含めてそれなりに動いて楽しい。

BGAでも1.27mmピッチ、0.8mmでも3周とかならまだ基板発注する業者が色々選べるけど
ATMELだと0.8mmで4周以上が多いから設計ルールの関係で業者が減るし…

> BGAでも1.27mmピッチ、0.8mmでも3周とかならまだ基板発注する業者が色々選べるけど
> ATMELだと0.8mmで4周以上が多いから設計ルールの関係で業者が減るし…

ビルドアップ基板(非貫通ビア)や6層以上を使うかどうかや、Pad on via
で穴埋めとかやるなら判るけど、0.8mmで3周のBGAと0.8mmで4周のBGAとで
設計ルールって変わる？

最外周のボールを部品面から引き出すのは同じで、内周は45°斜めにパターン
を引き出して、ボール間の貫通ビアで内層やハンダ面へ逃がして引き出す条件は
どちらも変わらないのでは？

あと設計はいいとして、BGAの実装はどうするの？温調付きトースター？

＞BGAの実装はどうするの

ホットプレートとヒートガンで実装してる動画を見た

BGA→PGA変換ソケット
http://www.meganics.co.jp/product.php?series_id=2436

>>886
>引き出す条件はどちらも変わらないのでは？

0.8mmピッチで1本通せるってルールで4周の場合は、内周側の角で手詰まりになる場合が…orz
2本通せるルールなら大丈夫だけど。

>BGAの実装はどうするの？

リボールキットを用意して何回も練習できる条件を整える事ができれば〜

>>889
> 0.8mmピッチで1本通せるってルールで4周の場合は、内周側の角で手詰まりになる場合が…orz
> 2本通せるルールなら大丈夫だけど。

それって、層数を増やせば(6層や8層)解決できそうにも思うけど、ダメ？

ちなみに、ボール間0.8mmで2本通せるルールて、設計上の線幅/ギャップ/パッド径
はどんな寸法配分に？

線幅0.1mm（100ミクロン）以下じゃないとムリだよね？

> リボールキットを用意して何回も練習できる条件を整える事ができれば〜

BGAは、付けるのも難しいが、綺麗に剥がすのも難しい気がする。

おまけに、ドアを閉めた冷蔵庫の中のランプが消えたか判らないのと同様、
ちゃんと付いたかどうか、確認できない。

X線ツールで透視してやらないといけないんで難しいよね

X線で見るのはライン立ち上げて最初だけって聞いたことあるよ
マウントが安定すると見なくてもいいらしい

ライン落ち修理では全数検査なのです

LPC1114に温度センサ、湿度センサ、気圧センサ、ＲＴＣ、ＳＤカード、ＸＢＥＥを接続可能な基板を
設計します。だれかソフトを書いてもらえませんか？

カメラは付かないの?
USBカメラに魚眼レンズ付けて全天カメラにしようとしてるんだけど。

894
それくらいの機能なら、メリー基板+αで十分じゃね?

書けないのに作るとは何事ぞ

mbed NXP LPC1768購入して、いざ使ってみたら、簡単便利。
コンパイラをオンラインで動かすのね。
便利な関数もいろいろあって、シングルタスクやるには困らない。
オレンジボードとかいうのを仕入れるといろんな周辺機器を操作できるようだ。

やっとプロバイダが規制が解けました。
>>831
> 関数電卓はともかく、他の機能はAVRで十分かと。
> というより、バイク（でいいですよね？）につけること考えるとノイズとか熱の影響が大きいからしょぼいマイコンの方がいいかも。
ノイズについては無知なんですが、耐熱に関してはAVRもARMも85度って書いてあるから、ほとんど変わらないような。
夏の熱対策にLCDは脱却できるようにしないとダメっぽそうですね。カブのハンドルに100均腕時計をつけていたんですが、去年の夏は壊れずに乗り切ったけど、今年の夏は乗り切れずに死んでしまった。
>>832
> 電源周りの素人配線を考えるとPICやAVRでの実装が無難っぽいな、
うん？
>>839
> なんで文句言ってのかわからんかったが。携帯か。
> それおまえの問題じゃね？
2006年ぐらいの報告のひろゆきの報告でPC4割、ケータイ6割のアクセスじゃなかったか。

>>899
データシート上は同じ耐熱温度で表示されるが、集積度の低い半導体って丈夫だからな。
一回PIC(16F84A)に9V突っ込んで動作させたことがあったが、クソ熱くなっても普通に動いた。流石にずっとそうした訳じゃなくてせいぜい数秒の話だったけど。
たぶん、ARMとか高性能なやつだと逝かれると思う。

ノイズに関して言えば、これも集積度が低くて比較的高い電圧で動くマイコンのほうが有利だと思う。
試しに適当な評価ボードを動かしてみるといいと思う。MARYなら本付きで4000円しないし。

>>899
>ノイズについては無知なんですが

自分でノイズ関係無知と言っておきながら、俺のレスに　ん？　ってのは何だ？
電源電圧が低いってだけでもノイズの誘導電位に弱かったりするんだがな。

cortex M3コアはさすがに高速だな
LPC1768

ちょっと気が早いかもしれないけど、次スレのスレタイどうする?
3スレ目がCortex-M3の組込み系だったから、

【Cortex-A8】 やっぱARMっしょ-4 【Android】

とでもする?

gccつかってます。
ARM11がターゲットで、最適化で省略されないnopを
インラインアセンブラで入れたいんだけど、
どうしたらよい？

試さずに
asm volatile("mov r0,r0");
と書いてみる

>904,905
voltileで省略はされなくなるが、近所のvoltileでない文との順番は入れ換えられてしまう。
904的にはそれも困ると思うので、
-fno-tree-ter をコンパイルオプションに入れておいたほうがいい。

>>906
voltileだと文法エラーだと思う voltileだと
大事なことだから2回書きました

よくあるコンマイクオリティだから、大目にみておけよｗ

>>904です。

みなさん、レスありがとうございました。
>>905さんの記述で問題なくできました。

>>906さんが仰ってるのは、Using the GCCに書かれている
-ftree-terを適用しない、ということだと思うのですが、
英文の説明を読んでもさっぱりでして。。。。
追加するかどうか判断しかねてます。少なくとも、
いま注目している範囲に限れば、アセンブラを見る限り
-fno-tree-terを追加しても、しなくても命令順が変わることは
ない様でして、もう少し考えてみたいと思います。

>909
tree-terは

asm volatile ("mov r10,r10");
A = B + C;
asm volatile ("mov r11,r11");

を

asm volatile ("mov r10,r10");
asm volatile ("mov r11,r11");
A = B + C;

と変形する奴。
ただGCCの版とアーキによってtree-terの実装は入ってたり
(まだ?)なかったりするのでARM11でどうかは知らね。

>>909です。

>>910さん、レスありがとうございました。

今のところARM11でやってますが、
将来はCortex-A9、-A15あたりに移行するっぽいので、
そのとき改めて振り返りたいと思います。

mbedでARMに入門。
mbed はサンプル走らせるにも、自作のプログラムを走らせるにせよ、非常に早くできますね。

mbed便利だけど、ちとお高いのが

最初はmbed、要領つかめたら、LPCXpressoってかんじ。

stm32fも使いたいな。

>>915
stm32f207お勧め。　基板はFusionPCBで格安。　PCBCAD?　Eagleもあればなんでも有りの時代。適当に．．．
プログラム環境は、ちまた溢れているので．．．　デバッガーだけは高速ロードできるものを選択するがよろし。
プログラム構造は．．．　こっこれは、C++でのOOPが良いんじゃね？　能力があればだが．．．
メッセンージドリブンでメッセージポンプの手法と割り込みからのメッセージ送信をどうするかが課題だが
なんとかなんじゃね？　セマフォ専用スレッドを作るも良し、また〜りとフラグでポーリングでメッセージを発行するも良し．．．

mbed買ったけど結局gccとcmsis頼りに遊んでる。
デバッガのことを考えればLPCxpressoでよかったかも。
STM32も手を出したいけどLPCのcmsis付属のドライバ・ライブラリみたいなのが豊富なの？

>>916
にわか組込屋か

mbedもweb上だけでなくローカルでコンパイルできるファームウェアだしてくれればいいのにな。
必要なときだけwebにライブラリを取りにいくような感じで。

>>1
１から、やっと読み終わった・・・Orz

最近ARMをやろうと思っている。
理由は「中国液晶を使いたいｗｗ」
と言う不純な動機です。右も左も分からない。

とりあえず、知識が無いので
家に外付けHDD化しているクロバコとインターフェースの付録で遊んでみる
新参者ですが、ヨロ

>>920
無理。

>>921
え〜そんなー　ｏｒｚ
できればｋｗｓｋ

>>922
その気持ち悪い態度で教えてもらえるとでも思ったか
死ね

>>923
と言うより、本当は９２３が作り方を知らないとか？ｗｗ

まずmbedで試してみればいいじゃん。Cortex M3コア乗っかっているし、価格もenrouteで買うと5700円くらいで買える。
それに基板本舗のボードオレンジ付ければかなり遊べる。

>>925
有り難うございます。

俺的には、この辺で攻めたいと思っています
カラーLCD付 STM32マイコンボード STM32-LCD
http://strawberry-linux.com/catalog/items?code=15057

>>923
こいつ本当に何も知らないんじゃねえの？ｗｗｗ

>>926
お前は何為に来たんだよ。

>>926
STM32-LCDも面白そうだね。でかいLCDがついているのが魅力。

mbedとか買ってきた方がいいよね

>>927
雑談

>>928
今本屋行って来たけど、ＡＲＭ関係の本が増えている。
ＬＣＤ関係の記述も沢山あった。
結構面白そうｗ

>>926
STM32-LCD．．．　使い応えあるよ。　GUIでWidgetをあれこれ作成中だが、作り応えがあるな。
Button、Label、Image、ListBox等基本コンポは完成したが、アプリ作成でかなりバグが出てくる　ｗ

Rowley　+　C++　+　OOPの環境だが、組込みロジックの開発の一次検証がこの基板で完了できる。
あれこれ企画のクラスを全てぶちこんで必要なクラスをTDDデバック検証できるので、PCアプリ開発感覚でやってる。

このボードはお勧めです。

>>926
ついでですが、ご参考まで。
STM32-LCDがホコリを被らないようにするにはGUIが命です。
参考としてMicrochipのC30GUIライブラリを参考にC++で書き直す方法があります。
原本はCですが、C++での記述はもっと楽になります。
イベントドリブンの書き方が解れば、WidgetのPaint()、MessageProcedure()までのメッセージ伝達は理解できると思います。
ミニOSの規模になりますが、がんばってチャレンジしてくみてください。
割り込みからのメセージ発行は宿題になります　ｗ

>>931-932
有り難う御座います。
ボードを買わないうちから、助言が貰えるとは思いませんでした。

＞このボードはお勧めです。
他の皆さんも勧めていますね？このスレの方々も興味が有る人・既に持っている人
も多いと思います。

さてＬＣＤなんですが、何か難しそうですね？
いずれチャレンジしたいと思います。ｗ

句読点…w

ｗ

こんな過疎スレで一人劇場か(w

>PCアプリ開発感覚でやってる。
そういうの(GUI)は、PC側でやれよ。何故、組込み側で無理して、小さくて画素数
少な過ぎて使い物にならない液晶載せて、ミニOS規模の開発しなきゃ成らないの?

組込み側は、Simple is the Best! で、液晶もGUIも不要だってば。
(PCと)繋がることに、意義・価値が有る。

マイコンの制御なんてPCからリモートでやった方がいいけど、
LCDと電源スイッチとタッチパネルだけでスタンドアロン化できるなら
それもいいんじゃないかな。

>>937
> 組込み側は、〜 (PCと)繋がることに、意義・価値が有る。
それは「組込み」ではなく、単なるPCの周辺機器だな。

いや、それ「こそ」が組込みだろ。

>>940
ここで「組込み」の言葉の定義を議論してもつまらないが…。

HDDレコーダーを、PCから操作するのか?
(フィリプスの)インテリジェントリモコンを、PCから操作するのか?
携帯からプリンタへ、デジカメ印刷する時に、PCから操作するのか?
ドアホンや風呂に警報装置が合体したホーム端末を、PCから操作するのか?
デジカメで写真撮るのにPCを持ち運ぶのか?

もっとも、フリーなGUIライブラリがあるのに、「ミ二OSです」とドヤ顔されるのもどうかとは思うが。

そもそもマイコンのROMは書き込み寿命があるわけで、たくさん書き換える用途には向いてない。
なんとかリモコンとやらも一回きりだからな。
マイコンそのもので遊ぶつもりなら、入出力と一寸したインタプリタ組めばそれで十分なんじゃないの

>>942
それ、ちょっと前まで100回とかのルネサスだろ?
ARM系はもっと多い。

それでも心配なら、SPI FlashからブートするARMを選べば無問題。

ルネサス時代って100回とかそんな少ないやつあったっけ
なんにしろ内臓ROMはブートくらいにしか使わないからよほどの事が無いと書き換えないよなぁ

>>941
そもそもPCが有ったら、HDDレコーダだのリモコンだの不要だろ、JK
>携帯からプリンタへ、デジカメ印刷する時に、PCから操作するのか?
>ドアホンや風呂に警報装置が合体したホーム端末を、PCから操作するのか?
>デジカメで写真撮るのにPCを持ち運ぶのか?
全部、Yes!
既にそういうシステムで暮らしてるが、世の中にはワザワザPC使わずに、デジカメ
からプリンタへ印刷しようと苦労してる馬鹿が居るからウンザリする。

>フリーなGUIライブラリがあるのに、「ミ二OSです」とドヤ顔されるのもどうかとは思うが。
ここは同感だけど、「フリーなGUIライブラリ」って、中身を確認しようとすると、iTRON
より巨大だったりして目を通すだけでウンザリすることうけあい。
しかもコレをクロス開発とか気が遠く成る。だったらGUI部分はPCでやれよ…と思う。

>>945
その場合ってPC込の組み込みってイメージ
組み込み向けのPCってあるけどね。

>>945
おまえか組込屋で無いとこまで読んだw

業務で、数百ロット以下の製品でSTM32使った人いる？
入手不定で採用できん。

タッチ選択しか使わないような簡単な物までPCセットにすると高上がりしね？
市販GUI？　RTOS無しで使い物になるものある？

>>948
1ロットが何個か知らないけど、その規模なら年間でアロケーション取らないとダメでしょ。ＪＫ

>>948
50〜500ロットって、意外と入手難しいんだよね。
国内ガラパゴスマイコンだと、最低5000個ロットからw、って言われることが多いし。
ARMとか海外勢もES品はホイホイくれても、正規は千個ロットからのことが多い。
だったらESサンプルを50個発注しちゃえ!…とか。

>>950
多分、>948さんの場合も最終的な製品単価は高いんだと思うが、会社に体力無いと
月間で資金繰りを要求される自転車操業だったりするんじゃないかと邪推。
年単位で下手に在庫抱えると、税金が馬鹿に成らないし。

>>947
日本語でプリーズ。

数千台売れる見込みのある電子機器っていうと何だろう。

>>948
>>951
>>50〜500ロット
>>最低5000個ロット

細かいことだが、「個」が入るかどうかで、
大量で入社難なのか、少量で入手難なのか意味が変わってくる。

1,000個/lot…なの?
おっかしいな、ロットサイズはウェハーからの取れ数に依存する筈なんだけど。
ベンダーによって違うのかな…。
いやいや、ロットを混ぜこぜにして納品されたら品質管理的に問題…。
(以上、チラ裏)

>>953
言葉で「最低5000個ロット」と言えば、それは「5,000Q'ty/lot(min)」のことだよ。
そうでなければ、営業マンと話が通じなくなる。
>>951
実際には一括発注・分割納入・分割検収で、在庫が膨れ上がることも無いだろう。需給予測を見誤らなければ。
見誤ると買い取り責任があるから、期末に在庫を抱える事になるけどさ。

言文一致にもほどがある

野田総理、在日献金問題を否定できず。まもなく辞任か？
http://hatsukari.2ch.net/test/read.cgi/news/1315033127/

>需給予測を見誤らなければ。
>需給予測を見誤らなければ。
無理ゲー過ぎる…

>>957
それは俺らの責任ではない、営業の責任だw

元組込屋、現素人の俺はmbedで適当なプログラムつくって遊んでいる。
プロでやるもんじゃないな。MCUの選択からして自由を奪われている。

>>948
932ですが、毎月50個程度、STM32F103は各パッケージ購入してます。
本業が農業なんで、サイドジョブですが。
ARM開発の人手不足は深刻なようですね。　ARMというより、エンベッディド全体だと思いますが。　

ただ今、CircleOSをC++で書き換えてます。　そろそろ稲穂が黄金色になってきましたので、IDLE状態になります。

人手不足が深刻ってよりも、
外注丸投げで二束三文の受託開発費だから誰も寄って来ないだけでしょ。

>>961
そうなんですか。
フラッシュも1M、SRAMが128Kのチップ時代になって、いよいよ、エンベッディットでもOOPが活用できるというのに．．．
まず、何か製品を作る。　その後にその製品を商品にするという基本の流れが確立できないもんだろうか？
全ては人材に有りか．．．

OOPとかC++とか冗談でしょ

大阪の専業職です。 本業が農業って方、初めて伺いました。 新鮮です。

SRAM 128KBなら、まずはRTOS系+FAT系を動かして延々使いまわすベースにする、と発想しました。
エンドユーザーがデータを入れ替えれるように、と。

>>962
常に製造原価を問われるから流暢なシステム設計なんて来ないでしょ。
そんなアプリ開発が許されるのはiPhoneとかandroidだけだと思う、
もしゆるゆるの案件があるのなら紹介して欲しいです。

>>965
UMLもOOPも、一応生産性を上げるためにある訳で(ry

ｒｙ）あるが、そんな案件は無いってかｗ

>>960
人手不足なんて全然無い。
組込みの人材なんて、リーマンショックで余りまくって、
樹海の入り口で大勢行列してるから、いくらでも見つかる。
androidのJava経験者の方が不足気味だね。

優秀な人材は常に不足してるが
海外圧力と有象無象の進出で
人の質と価格は下落だよな

>>965
iPhone案件なめんな
１人月かかる開発を5万で買い叩かれた奴を知ってる

>>969
優秀な人材が不足なんて、もう昔話。
組込みは日本語があまりネックにならないから、元々海外に行きやすい。
ガラケーが最後の砦だったのに、もはや崩壊寸前。
そういえば、大昔は、PC98って非関税障壁が国内ソフト産業を守ってたね。

今じゃ平気でプロマネまで非正規にやらせるからな
しかも中抜き後の料金で

>>970
ひでぇなそりゃ

正規雇用してる社員自体がもうゴミだらけだからな

>>970
マジっすかｗｗｗ
スーパーでレジ売ってるおばさんよりも低賃金っすか
色々とおわてるなぁ・・・

なんだかんだでその仕事受けちゃうからそうなるんじゃないかな。

手塚治虫のせいだ

>>970
まぁ、組込みアプリは本当に組込みか？って議論もあるけどな。

iOSアプリは、だろ？組み込みの要素は無いよ
ガチガチにiOSが固めてる&変なコードは審査が通らない

組み込み系のお客さんとの付き合いで案件が回って来る事があるだけ

>>970
１人月かかる見積もりの仕事だったが、実は１日で終わら
せていたっていう落ちがあったりはしないんだろうね。

「今回の分は次の案件で…」ってパターンだったらしい
次の案件があったかは知らん

>>979
他にもガラケーのJAVAとか、WinCEアプリとかもあるなぁ。

>>972-975
それ何て三菱電機MDIS?

まぁiPhoneアプリなんて、大半のものが5〜10万円しか売上げ無いからな。
その程度のソフトを更に外注に出すという発想そのものが間違ってて、必要なら
自前で作れ、と。

iPhoneアプリって組込みなの？
その辺になると制御と言うよりアプリじゃね？

PCのアプリそのまま持って来ようとして動かないと
組み込み屋に回ってくるパターンかな

実際は、よく知らないのだけど

給料・年収
ＶＢアプリ＞＞組込み

難しさ・知識度
組込み＞＞ＶＢアプリ

なんか理不尽じゃない

組み込みはハードの開発費が必要じゃないか、部品だってネジ一個まで値段が出るんだよ
形の無いソフトの値段なんて予算つけらんねーよ

という。

>>986
日本のIT業界そのものが、難易度・仕事量と、時給・年収が反比例してるからな。

高校の同級生で腐女子だったのが結婚してパート主婦でWebデザイナ(HTMLプログラマw)
してるのが、一番稼ぎが良くて萎える…。

世界一の組み込み大国になれてたろうにな
結局美味しいところは欧米
下働きはアジアその他に取られてしまってる
車とかも酷いもんだ

組み込みに転向しようとしたら仕事がないって言われた
ソフトはおいしいけど病気になる
仕事がないよりは病気になった方がいい
多分、原発で働く気が狂った人も同じ気持ちだろう

>>990
原発で働いている人に失礼だぞ。
日本のために働いてくれているんだぞ。
東京でのほほんとしてるなら、原発の仕事手伝ったら?

マイコンプログラミングをしてみたく、
数千円で買えて、入出力が最初からいろいろ実装されてて
（各種スイッチとかLEDとかLCDとか各種センサとかできるだけたくさん欲しい）
っていう評価ボードみたいなのを探したいんだけど
>>1のTI , EKI-LM3S6965, \6,618-がなんか良さそうに思ったんだけど
何かほかにお勧めってありますでしょうか？

|電柱|･ω･`)ゞ　誰か次スレお願いね？

>>992
Arduino

>>993
>>1だけど、>>903をスルーされたから心が折れた orz

>>992
STMicroかな。
雑誌の付録になったから、基板がもっと安く別売されてた気がする。
雑誌のバックナンバーが手に入れば、取っつきやすい。
ただ、
> （各種スイッチとかLEDとかLCDとか各種センサとかできるだけたくさん欲しい）
これには該当しないけど。

>>990
AVRを知らないんだが、8bitなんだろ?
32bitのほうが取っつきやすいと思う。

>>992
シミュレータで遊んでみたら？

>>995
安心しろ！
俺が来たのは９２０からだぁ〜ｗｗ

ねじには、手作りならではの個性は、いらないのです。
ねじ穴の太さや長さは規格からはずれていれば、
使いものにならないからです。
均一に正しく作る、他のねじとまったく同じく作る、
手作りであることの痕跡を消す、そのことが重要なのです。

すまん誤爆した

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。