マイコンソフト 悩み事相談室 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
では、質問、ドゾ〜 >>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とかコンパイラとか作ればいいだけ 222が書いてるような事がまだ起こる気配すらないのに先回りして心配してるとか暇な人たちですね。 >>241
コードの自動生成は、ルネサスの開発環境でもガンガン行われているけど、
「気配もない」んですか? >>238
何の前触れもなくいきなり冒頭で
＞>>226
＞「ダウンロード」はマイコンへの書込みの意味ですかね。
とレスしておきながら、
＞「想像、印象、心象」の意味で使いました。
と言い訳して済まされるなら、何書いてもOKってことになる。
それがあなたのよく言う、IDを連続させる意義、ですかね？ 嫁を全力で叩こうとする信者たちｗｗ
みっとも無いな >>242
気配を感じることが出来ない人は「気配がない」んだろうね。 >>244
そもそもレスを読めていない。部分引用して曲解する悪意はないと信じてる。出直してきて。
ただし、ここは国語のスレじゃないから、俺がその部分に付き合うかどうかは俺が決めます。
付き合わない。 >>248
ま、自分がそれで気が済むならいいんじゃないかな。
見ている他人が、あなたのIDに何か語りかけようとは思わないだろうってだけ。
とても嫌な感じだから。
気づいてるだろうけど、各所のあなたのレス、現に全く他人から引用されてないよね。
内容が陳腐なせいもあるかもしれないけど。 >>76
昔の書き方だと { の前に引数の変数宣言入れる。 マイコンってCでしかメモリ容量的に無理だとおもってたんだが、もっぱらC++使って
る人いる？
メモリーの問題だと思うが、どの程度メモリー積んでればC++使った方がいいんだろ。
C++で書けたら楽だものな。 >>251
「動的にオブジェクトのnew/deleteをしないとC++じゃない」という前提でもなくて、
静的にクラスを使うだけでも記述する上で便利だ、ということなら、ArduinoだってC++使ってますし。 そういうことなんだね。例えば関数内でNewする場合（動的）にはやはり普通の変数と同じで
スタックに積むのだろうね。そうするとコツとしてはスタックエリアをかなり確保しておくべきなんだろうね。
８ｋｂのラムの場合はスタチック変数１ｋｂ＋スタック８ｋｂとかにするんだろうか？
mbed
M0 ３２Kb,８Kb
M3 ５１２ｋB,３２ｋB
M0はC++できる？（無理っぽい気がする。）
M3でもRamが少ないよな。こんなしょぼいのでC++つかえるのか？ >>254
>例えば関数内でNewする場合（動的）にはやはり普通の変数と同じでスタックに積むのだろうね。
ClassAクラスのコンストラクタで中で、動的メモリの確保はしていないという条件で。
(1)はオブジェクトの実体がスタックに置かれる。
(2)のようにnewしたら、スタックにはオブジェクトのポインタだけが置かれる
オブジェクトの実体はヒープに置かれる。この場合は(3)のようにdeleteしないとメモリリークする。
じゃなかったっけ。今はスマートポインタを使うのかな。
void foo(void)
{
ClassA a; //(1)
ClassA* pa = new ClassA; //(2)
:
:
delete pa; //(3)
}
メモリ管理の実装で違ってくるのかな？ >>255の続き
(1)のように、クラスの実体をスタックに置く(置いているのかな)とか、
(2)(3)の場合でもnew-deleteがそのときどきできっちり対になってるとか、
プログラムの最初の方に、EEPROMから得た設定データをもとに、
どかんとクラスの配列をnewしてあとはそのまま使うような場合なら
C言語で構造体を扱うのと、さほど変わらんのではないかと思います。
でも、C++の匠は、いろいろなサイズのクラスをnewしたりdeleteしたり、またnewしたりと
ガンガンやりますよね。虫食いだらけになって辛いかな。
そういえば、昔の携帯のJavaのプログラミングで、同僚から、
「オブジェクトは最初に確保してそのあとはずっとそれを使う。メモリ貧弱だし」
って聞いたことがあります。似ているかも。 >>251
コンパイルはパソコンでやるから、問題ない。
ただし、小規模のソフトをC++化しても、めんどくさいだけな気がする。 >>251
コンストラクタ、デストラクタ、テンプレート、デフォルト引数
これだけでも使う価値がある
new / delete はアドレス変換の無い小規模マイコンでは基本使わない
使うとしたら起動時にnewだけ 組み込みだと、グローバルなクラスのコンストラクタが呼ばれるように自分でしなきゃならないことがあるので注意
Cからも呼ばれる事がある関数のヘッダをC/C++両対応にするのがちょっと面倒
Cが絶滅出来れば良いけど、なかなかそうも行かない 教えてください。
#define LED_ON 1
#define LED_OFF 0
上記は、
#define で、1つの単語
LED_ON で1つの単語
1 で1つの単語だと思います。
本の雑誌などのサンプルプログラムで、
#define AAA BBB CCC というのを見ました。
この場合、「AAA」 を「BBB CCC」に置き換える
ということでしょうか?
つまり、
置き換えられる1つ目は「必ず1ワード」だけですが、
置き換える文字は「2つ目以降改行までスペースを含めて全部」
という理解で正しいでしょうか? >>261
処理系によって違うかもしれない
試して見りゃいいじゃんか目の前に箱あるんだろ?
1.AAAがBBB CCCに変換される
2.プリプロセッサがエラー吐く
3.CCCが無視される(warningが出る)
さあ、どれだった? そもそも複数行に展開されるマクロとかも定義できるから
> 置き換える文字は「2つ目以降改行までスペースを含めて全部」
と言う理解は正しくない >>264
基本は行末まで。
￥で連結すれば、複数行にまたがって記述可能だが。 >>266
連結するということは、一行扱いにすると言うこと。 >>267
￥があっても行末は行末
それをどう解釈するかはプロセッサの仕様の話 > 置き換える文字は「2つ目以降改行までスペースを含めて全部」
の中の「改行」は末尾の「\」による「テキストファイル上の改行」を「ソースの解釈の上での改行」に含まない表現ではないの？
その解釈で>>267の発言だと思う。
「\」を含めた話をするときは、行末、改行は混乱を招きやすい。相手がどっちの意味で話をしているかはわかると思う。 >>269
> の中の「改行」は末尾の「\」による「テキストファイル上の改行」を「ソースの解釈の上での改行」に含まない表現
とか言うオレオレ解釈を力説されてもな w >>268
#define 自体がプリプロセッサの機能だし。
それを言い出したら、
やってみなければわからん
としか言えない。 >>271
特定の環境の話でないなら規格準拠が前提だと思うが？ >>271はプリプロセッサは規格にのっとった動作するのだから、と>>268に批判的に見える。
>>272は>>268は規格準拠を前提にした話であるような言いかた。
「それをどう解釈するかはプロセッサの仕様の話」
とだけ聞けば、客観的には「プロセッサの動作にはいろいろあって解釈もまちまち」が前提になるだろね。
>>268が規格準拠を前提にした発言だとしたら、意図が読めない。
「それをどう感じるかは人次第」なんて話で、「誰もが同じ解釈をすることが前提」とは普通は考えないよね。 >>273
> 「それをどう解釈するかはプロセッサの仕様の話」
「ソースの行」の話と「行を連結して一行に解釈」話を分けて考えろ
って話
> 「それをどう感じるかは人次第」なんて話で、「誰もが同じ解釈をすることが前提」とは普通は考えないよね。
そりゃ
> 「それをどう解釈するかはプロセッサの仕様の話」
って書いてあって「それをどう解釈するかはプロセッサ次第」って書いてないからな
これが同じ文だと思うならちょっと注意力が無さすぎ >>274
>「ソースの行」の話と「行を連結して一行に解釈」話を分けて考えろ
その表現でいいと思います。 今のは知らないですが、「プログラミング言語C 第2版」(古い)では、
\での連結のことを「行の併合」って表現してますね。 >>275
なるほど、壊滅的に話の流れを読む能力がないのな w >>277
無用に相手を挑発せずに、すりあわせて意見の一致を探す方が有益ですよね？ やって見りゃすぐ済む話を延々と・・・
不毛な非生産的な話が続くなぁ
最初の質問者は試しにやってみたのかよ
使った処理系と、結果書けよ まあでも自分には、丸々行末までと置き換えるっていう知識はなかったから
参考にはなったかな コメントは除去される
（空白1個が残るかのごとく、コメントの前後は連結はされない。
大昔は連結され…るような処理系もあった） >>283
言えてる。
#defineなんて、ON 1 とか true 1 とかしか知らなかったよね。 ABS(x) ((x)>=0?(x):(-(x))) くらいは知ってるやろ 安易にSWAP(x,y)を作ってはまるのは、定番の教科書ネタですね。 y = ABS(x++)
とかやってはまるのも追加で #define hoge(X) X
と
#define hoge(X)
とを切り替えて、デバッグ用の文を入れ外しするよ。
例えば、
hoge(printf("DEBUG\n"));
とかやれば、#ifdefで書くよりも行数少なくエレガント define いいけど、行末の ; を付けてしまうとエラーにならない? ■ このスレッドは過去ログ倉庫に格納されています
