マイコンソフト 悩み事相談室
レス数が1000を超えています。これ以上書き込みはできません。
.
∧ ∧
( ´・ω・) ＜ コンフィグって何? 昆布なら知ってる。 ボラチルって何? ボラは魚だよ。
（ ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、
と＿_）__） (,,■) (,,■) (,,■) (,,■)
PIC AVR H8 ARM
学校でC言語を習ったことがあるので「楽勝でしょ」って、マイコンを始めたけど、
わからないことだらけ。誰か教えて!
PCとは、別世界のマイコンのソフト。難しいよね。
ツールの使い方、ツールの設定、マイコン特有のC言語の書き方、
「デバッグモードにプログラミングモード。何?」 Eclips, Emacs って何?
VBAしか知らないよぉ、という人まで、
各社マイコンに関するマイコンソフト相談室です。
質問者は、「初心者質問スレ」の>>1を見て、分かり易く質問を書いてね。
回答者は、威張らない、バカにしない、言葉使い注意で、親切に教えてあげてね。
あっ、そうそう。
ハードウェアに関する質問は、それぞれのマイコンのスレに、達人がいるから。
では、質問、ドゾ～ High Speed ホストになれるのでは、AtmelのSAM3Xが早くから出てたね
評価ボードとしてはArduino Dueの中華互換機が使えて安いけど
JTAGデバッガを別に用意しないといけないのが弱点
まあ、今だとLPC-Link2とか使えるかな STMの評価ボードの値段は、もう自分で基板作ってIC載せるとか
趣味の基板製作以外では引き合わないって思わせるな
TIなんかのは、キャンペーンで一時的に安く供給してても
いつのまにか供給自体なくなっちゃたりするけど、STMのは
結構長く供給してるし PICのプログラムで値の変換をしようとして上手く動かず困っています。
使用環境はMikroCです。
0から10000までの測定値を2000から300までの範囲に対応させたくて、
測定値/10000*(700-2600)+2600という式を使いました。
int sokutei;
int keisankekka;
keisankekka = sokutei/10000*(300-2000)+2000;
としたところsokuteiが変化してもkeisankekkaの中身が2000になってしまいます。
整数型だといけないのかと思いsokuteiをdoubleで定義しても変わらずでした。
この場合どうすれば計算結果を得れるでしょうか？
よろしくお願いします。 keisankekka も double にしないと切り捨てられますよ。
sokutei はキャストすればいいと思います。
int sokutei;
double keisankekka;
keisankekka = (double)sokutei/10000*(300-2000)+2000; >>902
long sokutei;
long keisannkekka;
keisankekka = ( ( 10000 - sokutei ) * 1700 + 3000000 ) / 10000; >>903
ありがとうございます。
思うように計算結果が出るようになりました。 >>904
ありがとうございます。
式を変形させて計算する方法ですか。
思い付きませんでした。 ラジコン用のサーボをPICで動かそうとして悩んでいます。
条件は周期10msでパルス幅0.7から2.6msをRB5の端子からの出力です。
パルス幅の指定はint PW;に700から2600と入ります。
以下のように書いたのですがパルス幅の可変が出来ませんでした。
int PW;
int SYUUKI;
while(1){
PW=SOKUTEI();
SYUUKI=10000-PW;
PORTB.B5=1;
for(i=0,i<PW;i++){chien();}
PORTB.B5=0;
for(i=0,i<SYUUKI;i++){chien();}
}
void chien(){
Delay_us(1);
}
SOKUTEI()関数での測定により若干周期がずれますがサーボはパルス幅が重要で周期は若干ずれても影響ないので無視しています。
パルス幅を可変するにあたって何か致命的なミスをしているでしょうか？
よろしくお願いします。 教えても理解できると思えない。
マジでLチカからタイマーの勉強しなおせ。 >>907
30年前はこんなレベルでも雑誌執筆者になれた >>908
>>909
すみません、稚拙なプログラムはなのは自分でも解っているのですが、タイマーを使わず作りたいと思いました。
何がいけないのが教えて頂けないでしょうか？ >>907
PIC PWM サーボ ソースでくぐれ
取りあえず動いたら、タイマー割り込みに挑戦してほしい
動かなかったらクラウドワークスあたりに発注したらいいよね >>907
SOKUTEI()関数が何をやっている関数なのか分からんので、答えようがない。 >>912
ADCで読んだ値を元に変換しているだけです。
LCD繋いだプログラムではキッチリ700から2600に変換されていました。 >>907
＞パルス幅の可変が出来ませんでした。
可変は出来てるでしょ
幅が狙い通りじゃないだけで
実際にパルスを測定してみた？ ①タイマーを使いたくない
②タイマーを使うスキルがない
どっちよ？ フォント最大にしてよく眺めろ。
for(i=0,i<PW;i++){chien();} >>920
見落としてた。気づかなかった。真面目に読んでなかった。てか、そこでタイプミスするのか。取りあえず、本当にすまない。 >>920
関心する
コンパイラがエラー吐いてくれるような内容は
気にも留めないし目に入らないから 時折見せる2ch民の異常なまでの同調性ってキモいよなって思う >>926
forってオーバーフローして勝手にぬけるか？ 本来コンパイルエラーになるべき構文だから動作を考えるだけムダ
鼻から悪魔が出なかった幸運に感謝するしかない >>908
コードを見る限り、考え方は間違ってないと思うが、
どこを見てそう思ったのか。 >>934
今回Delay_us走らせることで、この手の関数だかマクロの精度や制限を知ることも大事なのではないか。
現実は２ちゃんねるより厳しいから、元スレの人にはがんばってほしい。 だから「Lチカからタイマーの勉強しなおせ」なんじゃないの？
>>935が言うような超基本的なことなんにも経験してなさそう >>931
判定式がi++になるから初期値i=0でFALSEになるからループせず即抜けだな 何でビルドできる前提？
ま、どんなコンパイラか知らんけどさ。 「急いては事を仕損じる」とか「急がば回れ」とか「慌てる乞食は貰いが少ない」とか？ 早起きは三文の得
…違うか。
でも、おつ。本当に必要になったときに、忘れてて再スレ建てをしないかどうかだけが気がかり。 >>902
測定値や計算結果の定義域が固定なら(＝0～10000や2000～300の値が
プログラム実行時に変化しないのなら)
sokutei/10000*(300-2000)+2000
→2000-sokutei*17/100 == (200000-sokutei*17)/100
一方、
(200000-sokutei*17)/100+0.5 == (200050-sokutei*17)/100
なので、
>>903
int sokutei;
double keisankekka;
keisankekka = 2000 - sokutei * 0.17;
>>904
int sokutei;
long keisannkekka; // intでもいいのかも
keisankekka = (200000L-sokutei*17L)/100; // 小数点以下切捨て
keisankekka = (200050L-sokutei*17L)/100; // 小数点以下四捨五入 速度上の理由とかで、long同士の除算を避けたい場合は、
(2000 - sokutei * 0.17) * 2^21 ≒ 4194304000 - sokutei * 356516
(2000 - sokutei * 0.17 + 0.5)* 2^21 ≒ 4195352576 - sokutei * 356516
なので、
int sokutei;
long keisannkekka; // intでもいいのかも
keisankekka = (4194304000UL - sokutei * 356516UL)>>21; // 切捨て
keisankekka = (4195352576UL - sokutei * 356516UL)>>21; // 四捨五入 ちょっと修正
>>947
356516 == 2^2*19*4691 == 2^2 * 89129
なのに注意すると、
4194304000 - sokutei * 356516 == (1048576000 - sokutei * 89129) * 2^2
4195352576 - sokutei * 356516 == (1048838144 - sokutei * 89129) * 2^2
ビットシフトを2ビット分節約しても精度を損なわないので、
int sokutei;
long keisannkekka; // intでもいいのかも
keisankekka = (1048576000L - sokutei * 89129L)>>19; // 切捨て
keisankekka = (1048838144L - sokutei * 89129L)>>19; // 四捨五入 PICだとか、ARMだとか、AVRだとか、マイコンの種類に関係なく、
いろいろなソフトウェアの話がでるといいと思う。
>>946のような話は、とても参考になります 理解を助けるために、あえてまとめない場合も多いけどね。
最適化はコンパイラにまかせておく方が主流な気もする。 >>949
この方向を極めるにはこれがおすすめ
ttps://www.amazon.co.jp/dp/443420159X
>>850
うん。
CPU速度やメモリとかがリッチなターゲットなら、
keisankekka = 2000 - sokutei * 0.17;
って書くのが理解し易いですし、変換式が変更になる場合等の保守性も
良好でしょうね。 今気が付いたけど、
keisankekka = 2000 - sokutei * 0.17;
を四捨五入して整数化したものと、
keisankekka = (200050L-sokutei*17L)/100;
とでは結果が異なる場合があるのは内緒なｗ
sokuteiが5750の場合とかね。
0.17が二進の浮動小数で正確に表現出来ない事に起因するので諦めるしか！ 一方で、sokutei∈[0, 10000](整数)の範囲で、
keisankekka = (200050L-sokutei*17L)/100;
に、
keisankekka = (1048838144L - sokutei * 89129L)>>19;
を一致させようとすると、1048838144Lに398足して、
keisankekka = (1048838542L - sokutei * 89129L)>>19;
って微調整すればいいのだけど、こんな事やってられないよなぁｗ >>955-956
ターゲットに依るんでしょうね。
実行速度が問題になる場合は、実機でベンチマーク取って
どの方法にするかを決めるしか！ プログラムROMってね何%まで使えますか?
気持ち悪いので、いつも50%くらいで使っているんですが。
70%を超えると、ドキドキしてしまいます。 なににドキドキするのかわかりませんが、基本 100% 使えるでしょう。
それよりあなたの書き込みの方がキモいです。 >>957
やっぱ実機で検証して満足行くかですね。
しかし、普段Cでしか書かないので同じ計算量でもintだと出来たHEXの容量が少ないlongやdoubleだと容量が大きい、程度の認識しか無いのですが命令数も多い少ない有るのでしょうか？
自分もMikroCのフリーなので2kワードの制限で使ってるので興味深いです。 コンパイラにアセンブラコード吐かせてどんな処理になってるかみたりしますね。
まあ普通に思いつくコード書いてれば、たいていそれがほぼ最適なコードになるんですがね。
無理してポインタとか駆使しても、見にくいだけで大して効果はないという。 さて、
0.17≒2^13/48188==2^11/12047
なので、
2000 + sokutei * 0.17 + 0.5
≒ (2000 + sokutei * 2^11/12047 + 0.5)*12047/12047
≒ (24100024 + sokutei * 2^11)/12047
これから、
int sokutei;
long keisannkekka; // intでもいいのかも
keisankekka = (24100024L + (long)sokutei<<11)/12047; // 四捨五入
>>948と比較して、定数がひとつだけ16ビット値に収まる様になった。
除算は乗算よりも演算速度が不利な場合があるけど、それよりも、
メモリを削るのを優先させたい場合もあると思う。 メモリーが足りないときは、何でもやりますよね。
未使用の周辺機能の設定レジスタをRAM代わりにするとか。 >>962について、>>953みたいな事を試みると、
24100024Lに99足してやると良くて、
keisankekka = (24100123L + (long)sokutei<<11)/12047; // 四捨五入
これも手作業ではやってらんないｗ ん～～、自分で決められる立場にない人ばっかりなんだろうとは思うけど
今は最低でも Cortex-M0 使うことに何の障害もないはず
発注元がバカだったとしても、「今はこういうマイコンが出てます」って
提案して「それはダメだ」とか拒絶されることって、少なくとも自分の
経験ではないんだけどな >>965
8051は永遠に不滅でぇーす！ｗ
…触った事ないけどｗｗ
USBつきとか頭おかしい←絶賛
ttp://www.atmel.com/ja/jp/products/microcontrollers/8051architecture/usb_mcus.aspx >>952みたいな事態に何でなるのかと云うと、計算過程で、
0.17 * sokutei ≡ 0.5(mod 1)
になる様なsokuteiが存在して(50, 150, 250, ...)、かつ
0.17 * sokuteiを含む式の値を正確に計算出来ないからなので、
0.17ではない他の値の場合には当て嵌まらないのに注意してね。
つか偶数丸めなんか知らんぞｗ
みんな真面目に偶数丸めになる様に組んでる？ まだやってたのか・・
コンパイラは最適化最強にするとこんな感じのコード吐くんだよ↓
int sokutei;
int keisankekka;
keisankekka = 2000 - (int)((11142L * sokutei) >> 16);
この程度に四捨五入なんていらんだろ。
どうしても四捨五入したいならこうだが時間とメモリの無駄。
keisankekka = 2000 - ((int)((22284L * sokutei) >> 16 + 1) >> 1); みなさんに質問です。
世の中に、バグのないソフトウェアって、あると思いますか?
JRの切符と改札のソフトは、バグを潰しに潰したのか、異常は出ないですよね。
銀行もスゴイ。自動車は・・・ ソフトウェアにバグが存在しないことは証明できない、と誰かが証明していた。 LEDチカチカくらいならバグなしに出来そうだけど。 確かに、巷では、バグの８０パーセントは１０年たっても
発見されていない場合が多いともいわれるし
２０年後にバグが発見されることもある・・・・ >LEDチカチカくらいならバグなしに出来そうだけど。
でも、電源on時に起動しないとか・・・ これはハードウェアのバグか。
ちなみに、プログラム動作用にLED1個を贅沢に付けているのは、この私です。 ＞プログラム動作用にLED1個を
動作確認用に、なら俺も付けてる。
LEDと抵抗、合わせてたった２円だしな。 四捨五入ですらバグが入り込む事があるんだぜｗ
ttp://d.hatena.ne.jp/hnw/20160702 LED 1つでも、点滅してくれていると「おっ、タイマ割り込み、ちゃんと動いてるね」と
わかって、いい。
タイマー割り込みじゃなくて、メインループでon/offするのが筋だろうけどね。 10年くらい前になるけど、ボードにJTAGデバッグ用のコネクタ付けようとしたら
派遣先の責任者に、「実運用時には、シリアルポートからプログラム及び
FPGAのコンフィグデータをダウンロードしてフラッシュメモリに書き込むから
（コストダウンのために）必要ない」って言われた。
自分は、ハードだけの担当で、派遣期間も終わりに近かったから
言われた通りに（回路図だけ書いて）おさらばしたら、半年後に
他の仕事してるときに、「頼むから週２日とかでいいから来てくれ」って
言われて、１か月ほど週２日で行った。
すでに修羅場は過ぎてたみたいだけど、聞いたところによると、その前の
２か月ほどは（派遣先の正社員が毎日午前３時に退社とか）地獄だったらしい。
フラッシュメモリへの書き込みプログラムが出来損ないで、30分とか
掛かってたこともあるんだけど、ホント、自分で開発やったことない連中は
デバッグ（官僚用語では「評価」とか言うらしいけどｗ）環境軽視してるんだなって
痛感した、今ではいい思い出 へー、スゴイね。
連日午前3時までやって、翌日はちゃんし8時半とか9時に来るの?
デバッグと同じくらい、チェック(検査)も舐めちゃ行けない。
「あの電圧を測定するくらいなら、1分もかからずにできるな」と思ったら
測定のための線だしの段取りだけで1時間とかザラ。測定は5秒ね。
アートワークの時に出してもらっとけじ良かったな、と後悔しても遅いね。
とにかく端子やチェックランドは付けて置いて損は無いよね。
実務で徹夜を何度もやったことのある人なら、わかってくれる システム設計がテキトーだと後が大変って教訓ならわかる 例外処理にバグがあったとして、
その例外処理が発生する確率が極めて少ない確率だった場合、
バグは発生しないように見える状態が継続します。
そんなもん。 while(1)｛バグ対策がバグの嵐を呼ぶ。結局、作り直す。} 1カ所変更したら、全機能をチェックし直す。これが基本ですよね。
やってられません。 >>982
＞10年くらい前になるけど
まで読んだ。 >>989
自動化出来るとこは自動化しておくとかって思ったけど、
このスレが対象にしてるやつって、PC内だけでチェックが完結する訳では
ないんでしょうねぇ…。 pc内では完結しなくても、pc繋いだら完結するのが出来たら良いかな。 一箇所変更したら全機能チェックしないと逆にバグで
やられてしまいます。
俗に言うパッチあててそのまま納入したらバグの嵐になったことがある。 // コメント1行だけの追加でも、やっぱり全チェックでしょうか? >>994
行番号とかのデバッグ用の情報無しでコンパイルしたバイナリが、
コメント追加の有無で(バイナリに埋め込まれたタイムスタンプを除いて)
変化しないのなら、気にしないのも手ではないかと。
一致しないのならコンパイラが腐ってるので捨て！
…る訳にはいかないのだろうな。メーカー純正ツールの場合は。 コメント行追加とかデバッグON-OFFでオブジェクトが違うとか
今時ないと思うんだけど、甘いかな？ そうだと思う。
けど、もしかしたら・・・と思うと。
チェックに使ったデバッグルーチンも「込み」で完成品にすることがほとんど。 レス数が1000を超えています。これ以上書き込みはできません。
