マイコンソフト 悩み事相談室 3 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
.
∧ ∧
( ´・ω・) ＜ コンフィグって何? 昆布なら知ってる。 ボラチルって何? ボラは魚だよ。
（ ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、
と＿_）__） (,,■) (,,■) (,,■) (,,■)
PIC AVR H8 ARM
学校でC言語を習ったことがあるので「楽勝でしょ」って、マイコンを始めたけど、
わからないことだらけ。誰か教えて!
PCとは別世界の、マイコンのソフト。難しいよね。
ツールの使い方、ツールの設定、マイコン特有のC言語の書き方、
「デバッグモードにプログラミングモード。何?」 Eclips, Emacs って何?
VBAしか知らないよぉ、という人まで、
各社マイコンに関するマイコンソフト相談室です。
質問者は、「初心者質問スレ」の>>1を見て、分かり易く質問を書いてね。
回答者は、威張らない、バカにしない、言葉使い注意で、親切に教えてあげてね。
あっ、そうそう。
ハードウェアに関する質問は、それぞれのマイコンのスレに、達人がいるから。
過去スレ
1 2014/09/11〜
2 2016/07/31〜 http://rio2016.2ch.net/test/read.cgi/denki/1469905691/l50
では、質問、ドゾ〜 I/Oやメモリを外部に作らなくて済む今のワンチップCPUは夢みたいだな。
電源さえつなげばCPUとして＜必ず＞動くんだぜ。
俺はもう若くないけど、もっと遅く生まれたかった。
出来ればあと50〜100年ほど遅く生まれたかった。
その頃にはハードウェアのAIが実用化されているかもしれん。
（チラ裏日記） アドレスバス、データバス、コントローラバスの手配線なんて悪夢だった。
電源を入れて動かない時は、ソフトが走らないので原因追及がそれなりに大変だった。 デバッガはなんて無いし、書込はワンタイムか窓付きEEPROM
メールでプログラム遅れないから、佐川の営業所に発送時刻に駆け込み >窓付きEEPROM
そんなのあるのか、すごいな。窓付きEPROMなら知ってるけど。 マイクロチップテクノロジがPICにAI機能を載せるのはいつ頃になるんだろ？
（未来話だよ〜ん）ｗ ppaのintel HDA のドライバ入れようとしてるんだけどDKMSでのコンパイルで弾かれる。
ひょっとして16.04.3Ltsに16.04.1ってドライバパッケージ入れようとしてるのが間違い？ >窓付きEEPROM
窓無しEPROMに書き込む時はそれなりに緊張した。
失敗するとそのままゴミ箱直行になるので。 >>151
書き込みは一度だけで（one time program)、消去できないので、
世間的にはそういう呼び方になりますね。
(説明するのは恥ずかしいのですが150はウケ狙いですよ、念のため） >>152
one time なんて言い方はない。
once だ。って習うよね。
不思議でならない。 >>155
そうか、申しわけ無い。
英語をちゃんと勉強しなかったのがこんな所でバレちまったｗ
OTPは「Once Tondemonai Program」でいいのかな？
そういえば「OUT ： once upon a time」なんて言い回しもあったな。
・・・
あるか！ （一人ボケ突っ込み) >>155
>one time なんて言い方はない。
>once だ。って習うよね。
中学生から勉強してないのかＷ >>157
one-time か onetime はあるな。 何十年も前から
「ワンタイムROMはおかしい。once だ。って習うよね。 」
なんて言っちゃうオバカさんは℃素人と決まってる。
ttp://www.am.ics.keio.ac.jp/digital/memory.pdf
ttp://www.cypress.com/file/228401/download
ttp://www.cqpub.co.jp/interface/sample/200703/I0703042.pdf
ttp://www.atmel.com/ja/jp/products/memories/eprom/default.aspx >>160
そこは日本語の資料だと説得力に欠けると思わないか？
One Time なんたらが有るのは知ってるけどさ。
>>158 が言うように、辞書引いたほうがいい。 PIC使いなんでMicrochipにきいてみた
https://www.microchip.com/search/searchapp/searchhome.aspx?q=one%20time
てか、onceだと他の意味もあって曖昧になるからじゃないの？
one-timeなら誤解されない。 >>161
>そこは日本語の資料だと説得力に欠けると思わないか？
思わないな。海外メーカの出してる資料だし、英文の資料でも部品名としてOnceなんて書いてあるのは見た記憶が無い。
勿論、文章中には有っても可笑しくはないが、ROMの頭にOnceなんて付けるかよ。 そもそもOTPのOがOnceって主張している人を説得する必要もない。
間違ってるよ、と言われれば、馬鹿みたいにすぐにわかるようなことなんだし
まともな人なら反論する前に自分で調べる。 賢いのは >>162 だけだった。
DVD は、Write Once だよ？ >>166
>DVD は、Write Once だよ？
それがOTPとなんの関係があるんだ？
大原節子のビキニ姿の話をしてる時に、>>166の母ちゃんデベソって言われるのと
同じくらい意味が無いと思うぞ。ほんとにデベソかも試練が。 何の関係があるのか？
と尋ねられて、ちゃんとその関係を説明するだけの誠実さがあるかな。
もうその件は置いておいて、他の事例を出してくるような気がする。
他の事例を出すこと自体が意味がないことをわからずに。 >>168 は >>166 が頓珍漢過ぎてとっさには同程度のいい例が思いつかなかっただけだろう >>168 は >>166 が頓珍漢過ぎてとっさには同程度のいい例が思いつかなかっただけだろう 一回こっきりというのを強調するためじゃないかな。
同じOTPだけどone time passwordってのも普通に使われるよ。 日本の自動車関係が、
ARMをメインで使わないのは何故なんでしょうね。 >>176
比較の問題ですが、自動車会社が求める品質保証やサポートへの対応の違いだとは聞いたことがあります。 自動車関係のCPUというときに、それに載せるアクセサリも含むのか、エンジン周りの
ヘビーデューティなものを指すのか。
電子部品で「車載対応」というと後者ですけど。 EUCとかパワートレインとか。
なんで車なのにトレインなんだよ？ トレインは、連なっている様子をイメージするコトバで、列車もその流れでつかわている。
パワートレインは、パワー伝達の一連の構造を表現しているのでは。 >>180
もちろん、後者です。
やっぱり、日本のメーカーの方が、何かと対応がいいんでしょうか？ >>183
電話口で叫べば担当が来る、叩けば無償対応するから。
日本のメーカーは昔から開発ツールやマイコンに関してはこれ。 そんな対応してくれるのは客が大手メーカーの場合だけでは？ 万単位の月産が継続する場合だな、そんなの。
片手がやっとのウチとは大違い。 万単位の生産になると製造コストが効いてくるから、そっちの問題で
安物外国産に走るしかなくなる。
大手自動車関連は障壁高いからそう簡単に変わらないだろうけど
それ以外駄目なんじゃない？＞ルネとか 国内だけの話なら「日本語障壁」っていうのもあるからね
ある程度の規模以上の会社なら、ソフト開発は派遣を集めて
やってる所がほとんどだろうけど、そういう所で
日本語ドキュメントのないデバイス使うのは至難の業じゃないかな >>188
英語赤点だった俺でも、データシート読むのは難なく出来る。 >>189
「オレ英語得意だから海外デバイスでも全然オッケーです！」
「そうか、たのもしいな！じゃ今度の開発はSTMのCortex-A7で
やってもらおうか」
･･･っていうような世界ばかりじゃないのよ
もしそういう世界にいるとしたら、それは（皮肉とかじゃなく）
幸せなことだと思うけど >>192
データシート読むのに必要な英語力なんて知れてる。
技術者としての能力が大事。
どんなに英語得意でも、文章能力無かったら英語で小説書けないのと同じ。 英語できます、って言う人でもコトの内容がわかっていないと読んでも滑る。
英語できます、って言う人が英語ができる程度に、日本ができる日本人はたくさんいるけど
日本語のデータシートを読めるかなんて別問題だものね。 英語データシートはスラスラ読めるけど小説や新聞は無理。 >>195
文章単純だし、想いを汲み取る 見たいな能力必要ないし。 >>196
いやいや、設計思想みたいなものは考えないと。 そういうのはブローシャにでも書いて貰って本体には不要 最近、中華データシートに苦しむわ。
しかも丁寧に書いてないしサンプルもない。
おまけに仕様書通りに動かないｗｗｗ 中華しか無いって半導体でか？
機械部品なら見た事あるが。 >>196
そもそも使われる単語も文体もちがうから
日常の述語力がないやつは小説は無理 家で不労所得的に稼げる方法など
参考までに、
⇒ 『武藤のムロイエウレ』 というHPで見ることができるらしいです。
グーグル検索⇒『武藤のムロイエウレ』"
QOYV9Y1F5E 質問てす
組み込みマイコンで使用されている開発言語は何が多いのでしょうか?
やはりアセンブラでやってるのでしょうか? それともC、あるいはもっと高級言語でしょうか?
例えば、
電子レンジ、冷蔵庫などの白物家電。
自動車のエンジンコンピュータ
自動販売機、コンビニのレジスター 白物家電：4〜8bit アセンブラ、C
ECU:32〜64bit C,C++
他は知らね。
白物家電専門でやってる人がいたけど
アセンブラのみ納期1週間程度だそうで。
まあ類似のものからカスタマイズだけらしいけど。
VCU(車体制御)の方は自分も10年前にやったけどC指定だったな。
フェールセーフが厳しいだけであとは結構普通だった。 コンビニレジは今や殆どwindows embedded ＭＩＳＲＡに悩まされた人ってあんまり居ないのか。
何でも書けてしまう便利なＣ、Ｃ＋＋に禁止事項、確認事項等々色々な制約を決めたもの。
まあ、可読性をあげるとかバグの可能性を極力減らすとかが目的のものだから車の動きに関係するものに必須とされるのは当然か。 そういう規約(?)の本が、FPGAにもあったよね。1万円くらいするやつ MISRA C って C を COBOL 相当に退化させるだけの代物、という気もしたりする CやC++のシステム記述言語としての万能性まで失うようなものじゃないからね。
MISRA = Motor Industry Software Reliability Association 協会のAssociationって、 ss だったんだね。いままで s だと思ってた。
ありがとう 組み込み用でフォントを探しているのですが何か情報があれば・・・
・無償で使える
・再配布に関する制約が緩い。ライセンスが他のライブラリ類と衝突しない
・一般的な日本語文書を表示できること。Unicode限定の特殊文字は含まなくても構わない
・ビットマップフォントでサイズは20dot、24dot、28dot、32dotあたり
・視認性に優れドット欠けに強い
・出力はモノクロ二値で最終的には紙へ印刷
今はIPAゴシックをレンダリングして使用していますが単純に二値化すると線が痩せたり太くなったりして
不自然に見えます。またディザを掛けると見た目が甘くなりイマイチです
10dot前後のビットマップフォントは結構あるみたいなのですが豊富なのはせいぜい16dotくらいまでで
20dotを越える物はなかなか見つかりません
もしくはアプローチを変えてTrueTypeフォントを品質の低下を抑えたまま二値化する方法とか・・・ jiskanとかパブリックドメインじゃなかったっけ 自分が調べた範囲ではjiskanは16dotと24dotしか見つからない・・・
IPAゴシック 20dot スレッショルド50% ttp://uploader.purinka.work/src/5310.png
IPAゴシック 24dot スレッショルド50% ttp://uploader.purinka.work/src/5311.png
IPAゴシック 28dot スレッショルド50% ttp://uploader.purinka.work/src/5312.png
IPAゴシック 32dot スレッショルド50% ttp://uploader.purinka.work/src/5313.png
32dotはともかく他は線が細い
IPAゴシック 20dot スレッショルド10% ttp://uploader.purinka.work/src/5314.png
IPAゴシック 24dot スレッショルド10% ttp://uploader.purinka.work/src/5315.png
IPAゴシック 28dot スレッショルド10% ttp://uploader.purinka.work/src/5316.png
IPAゴシック 32dot スレッショルド10% ttp://uploader.purinka.work/src/5317.png
上よりはマシになる
スレッショルドによらない共通する欠点として線の太さが不均一なのと潰れ方が不自然な所がある
jiskan24 ttp://uploader.purinka.work/src/5318.png
jiskan24h ttp://uploader.purinka.work/src/5319.png
無駄なく綺麗だけど明朝系故に1dotの線が多くドットの欠落に弱いのと24dotしかない
う〜む Ayuゴシックは良い感じ
Ayuゴシック 20dot ttp://uploader.purinka.work/src/5332.png
これだと1dotで細いので無理矢理倍幅にすると
Ayuゴシック 20dot なんちゃって倍幅 ttp://uploader.purinka.work/src/5333.png
潰れはあるけどIPAゴシック 20dotよりかなり良い。16dotと20dotしか無いのが難か
昔は低画素・低階調出力用の素材やアルゴリズムってあった気がするんだけど気のせいだったのかな
今探しても見あたらないや 今時のマイコンは機能てんこ盛りで、configレジスタを設定するのも大変です。
メーカーは自動生成機能でconfigの面倒臭さを軽減してくれています。
結構なことだと思います。
このことは、
メーカーがマイコン内部の機能モジュールをドンドン追加しても、
自動生成機能を使ってconfigしてくれれば、ユーザーにレジスタ詳細なんて
見せなくてももいいだろう、ということになってくるんでしょうかね? そりゃなるだろうねえ
実際USBなんかは詳細は書いてなくて
サンプルや自動生成コードを参照
って事になってたりするし
フラッシュ書き込みもライブラリで包まれていて
自力コードで書けないのもあるし そうなったらなったで違うマイコンを選ぶんでしょ君ら フルスクラッチ
フルアセンブラ
これはこれで面白いけど
そういう時代じゃないよ
標準ライブラリ
割り込みベクタ
ヒープ
ISRのプロローク、エピローグ
RAMの初期データ
毎回こんなのをゼロから作りたくない
1回くらいならそういうのも良いけど そうするとやっぱり、
「皆さーん、メインはここに書いてくださいね。タイマー割込でやりたいことは、ここに書いてくださいね。
あとは、当社の優秀なコンパイラーが全〜部やりますから、ダウンロードの準備していてください」
「あっ、但し、エラーはしっかり出しますからね。自力で解決してくださいね」
って感じですね。 >>226
「ダウンロード」はマイコンへの書込みの意味ですかね。
でも>>226で書かれているような感じが今ふうなのだと思います。
マイコンにかぎらず「プログラムが走るもの」全般に複雑化してますし、
ある程度のところまではウィザードみたいなので作っておこうってことじゃないでしょうか。 >>226
（スタートアップを含む）ライブラリを提供するだけだろ
別に組み込みに限らずWindowsのソフトでもmain( )を呼び出すコードを書く奴なんて極希にしかいないだろうし 最近プログラムもあんまり書かなくなったけど、
・データシート読んで configレジスタの説明読んで
・レジスタ値を決定して
・#include "...h" から始まって、config、グローバル変数、外部関数、main()とか
毎回全部手で打っていた。
面倒なので、使い回しするために、同じマイコン品番を使ったものですが。
自動生成ができると、殿マイコン出もプログラムできるような気がする。
今日はAVR, 明日はPIC、明後日はRX360という configはPIC用語
他じゃ通じない
RXだとオプションメモリだったかな
AVRは知らん 自動生成するドライバの仕様や機能がバラバラだから
上の変更も必要
ドライバから自作すれば上の変更はちょっとでよかったり
ラッパーでも良いけど、小規模だとあまり大げさにはしたくない >>227
前後の文脈読めば、ダウンロードが何の意味かなんて
いちいち揚げ足取らんでもいいよ、余分。
そもそも、書き込みの主旨に無関係。
>>229
あー、そこまではならないかなあ。
同じMicrochipさんでPIC32なのにMMCとHarmonyでインターフェイスが違って
私なんか混乱したりさせられてるもんね。
Arduino系に仲間入りできたチップはいいけど
マイコン単体の物は結局のところpdf見ながらごそごそ…。 >前後の文脈読めば、ダウンロードが何の意味かなんて
>>226 を読めば、クラウドでのコンパイル結果をローカルにダウンロード、とも取れるし、
マイコンへのダウンロードとも取れる。
揚げ足取りしてるわけじゃありません。
変わりゆく開発環境のイメージについて語っておられるのかなあと感心した次第ですよ。 まあまあ、それは良いですよ。
マイコンに書込のつもりで書きました。すみません。
そのうち、Eclips使って Cができれば、
FPGAもマイコンも、ARMもPICも知らないうちにできてしまう、という世の中になるのかな、って。
時代は変わるんだし。
ホイップアンテナ付き辞書のような携帯電話機が、
25年したらiphoneのようにペラペラになったんだから、
もう25年もすると、
「ヘイ、コンパイラ!
SW1が押されたら、画像1を出して、
SW2が押されたら、画像2を出して。」 と依頼すると、
「同時押しの時はどうしますか?」
「それよりも、どのデバイス使うんですか?」とか聞いてきて
「お任せでいいよ」
そんなやりとりでソースが完成。タイピングなんて、しなくなるのかも知れないですね。 >>233
＞クラウドでのコンパイル結果をローカルにダウンロード、
いちいちダウンロードの準備してって言ってくるクライアントがあるのね。
何というクラウドか教えください。 ＞FPGAもマイコンも、ARMもPICも知らないうちにできてしまう、という世の中になるのかな、って
私は趣味のプログラミングだけど、
プログラミングが共通化、単純化、ブラックボックス化していくのはイヤだな、
CPUの個性も楽しめなくなるし、作れるものも限定される。
それともいっそ開発環境の操作や高級言語処理を楽しむようにすれば良いのかｗ >>236
>>233に書いたとおりです。
俺自身は「>>226さんが『変わりゆく開発環境のイメージについて語っておられる』と考えた」わけで
実在の環境を想定していないですよ。
と思ったのですが、「イメージ」の解釈で行き違いがでて来るかもしれません。
・画像
・複製
・想像、印象、心象
後出しで申し訳けないですが、俺は、>>233では「想像、印象、心象」の意味で使いました。
ただ、「イメージ」の解釈によらず、俺は総合的には>>226での「ダウンロード」を「マイコンへの書込み」の
方かなあと考えたわけですが。 >>237
規模が大きくなってくると、だんだんそういう傾向になってきますね。
WEBで動くアプリなんて、ハードが何かなんてあまり意識しませんし。
マイコンメーカーも開発者よりエンドユーザー(とエンドユーザーに近い企画や営業)の方を向いて
作ってるはず。
趣味的な方向に行くなら、FPGAでCPUを作るとか、ですかね。 >>237
自分でCPUとかコンパイラとか作ればいいだけ ■ このスレッドは過去ログ倉庫に格納されています
