マイコンソフト 悩み事相談室 4
.
∧ ∧
( ´・ω・) ＜ コンフィグって何? 昆布なら知ってる。 ボラチルって何? ボラは魚だよ。
（ ∪ ∪ ,.-、 ,.-、 ,.-、 ,.-、
と＿_）__） (,,■) (,,■) (,,■) (,,■)
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
3 2017/06/19〜 https://rio2016.5ch.net/test/read.cgi/denki/1497806664/
では、質問、ドゾ〜 PIC18Fは16bitじゃないな、俺が悪かった。 現状、PICで使えるのはdsPIC33だけってこと。
だからSAM使ったほうがいいって書いた。 >>65
>5V対応不用でホビーならRaspberry Pi picoがお手軽じゃないかな
550円で安いですね。I/Oも周辺機能もあるしいいですね。
>MicroPythonはPythonと言っても仮想マシンだし、
これはどういう意味でしょうか。直接PythonでI/Oピンの H/Lができないのでしょうか?
>速くないし メモリの使用効率は良くないし、
133MHzで動いているのに、遅いんですか?
>コンパイル用にPCがいる
PCなしでできるんでしょうか?
C言語の代わりにPythonで書いて、ICSPで書き込めば自立で動く、
普通のPICマイコンとして使いたいのですが難しいでしょうか。 人のことを知ったで知識が古いとか言うのにこういう間違いは指摘しないような連中しかいないからここでは何も得られないよ。 ありがとうございます。
でも、いろいろな話聞いて、私には情報になると思っています。 普通のPICマイコンとして使いたいなら
素直にC言語で組めば >>72
MicroPythonやmruby/cなどはPCでソースコードをバイトコードにコンパイルして
マイコンにバイトコードとバイトコードを実行する仮想マシン(実質インタプリタ)を書き込んで動作させるからね
Pythonコードが直接マイコン上で走るわけではないし、JITなわけでもないし、仮想マシンが使用する分のメモリが必要
効率はArduinoより悪いかも
以前にちょっと検討したことあるけどメリットを見いだせなかった。この辺を載せるくらいなら、もうちょっとがんばって
Luaインタプリタを載せた方が使えそう。セルフ開発可能になるし >>73
何が間違いとも指摘できないお前のレスが一番無駄 >>72
> これはどういう意味でしょうか。直接PythonでI/Oピンの H/Lができないのでしょうか?
サポートされてればPythonコードだけでできる
https://micropython-docs-ja.readthedocs.io/ja/latest/library/machine.Pin.html
> 133MHzで動いているのに、遅いんですか?
C言語とかのネイティブな奴に比べたら当然遅い
Lチカぐらいなら問題ないけどそれなり処理をしようとしたら問題になるかも
あとガベージコレクションするからタイミングがシビアなものは色々知識が必要になる
> PCなしでできるんでしょうか?
基本無理
> C言語の代わりにPythonで書いて、ICSPで書き込めば自立で動く、
> 普通のPICマイコンとして使いたいのですが難しいでしょうか。
最低限そのボードにC言語のプログラムを書き込んで自立して動かせるスキルは必要 >>76
ありがとうございます。
>(実質インタプリタ)を書き込んで動作させるからね
マイコンにROM BASICを載せて、
1行1行読み込んで実行するようなものですか?
>>78
ありがとうございます。
>>直接PythonでI/Oピンの H/Lができないのでしょうか?
>サポートされてればPythonコードだけでできる
>> 133MHzで動いているのに、遅いんですか?
>C言語とかのネイティブな奴に比べたら当然遅い
>Lチカぐらいなら問題ないけどそれなり処理をしようとしたら問題になるかも
>最低限そのボードにC言語のプログラムを書き込んで自立して動かせるスキルは必要
それは何度もやって来たので大丈夫だと思います。
皆さんの話からすると、マイコンにはちょっと・・・という感じですね。
学校の授業でもPaython、本屋さんにはPaythonの本がたくさん。
Paythonの何が嬉しいのでしょうか。
初心者に分かりやすいからでしょうか。
アルデーノみたいに、他人の作ったモジュールを組み合わせると
簡単にできてしまうとか、そういうことですかね。 >>76
USBやシリアルでつないでREPLが動くでしょ。
PC側でコンパイルなんてしないよ。 >>80
> マイコンにROM BASICを載せて、
> 1行1行読み込んで実行するようなものですか?
そこまで原始的じゃないよw
コンパイルはするけどネイティブコードじゃなくて仮想マシン用のコードを生成するって話
古くはUCSD PascalからJavaやC#などでも使われてるやり方
ネイティブコードを吐くとか定数を定義するとかで高速化の方法はいくつかあるよ、詳しくは↓
https://micropython-docs-ja.readthedocs.io/ja/latest/reference/speed_python.html
ただ、Pythonは言語仕様的に速度を重要視しておらずC言語とかに比べたらオーバーヘッドはかなり大きいのでホントに速度が重要なら素直にCで書いた方が楽だと思う
>> 最低限そのボードにC言語のプログラムを書き込んで自立して動かせるスキルは必要
> それは何度もやって来たので大丈夫だと思います。
ならやってみてもいいと思うよ
> Paythonの何が嬉しいのでしょうか。
オブジェクト指向とかコードがわかりやすいとか>>81が言うインタラクティブに使ってハードのテストするとか色々あるけどあるけどぶっちゃけ流行りかなw
>>81
MicroPythonでもREPL使えるんだな
これは知らなかったわ >>81
てことはFlashAirみたいに生のソースコードを自力で解析して実行できるの？ >>83
PythonのコードをFLASHに置いて実行するのが本来の使い方。
テストする時はREPLが便利。
>>82 は何で VM にこだわってんの？
.mpy を実行するのが VM だって言うならPCのPythonもVMだよ。
Micropyhon は単なるインタープリタ。
結構重いからマイコン側の能力が必要。だから下記が推奨される。
256KB以上のフラッシュ
16KB以上のRAM
80MHz以上のCPUクロック
まあ、8bitマイコンでもメモリあれば実装は出来るかもな。
>>77 がいるからもう書かない。こいつはMicropython使ったことないだろ。
自分で実機いじったほうがいいよ。
ESP32オススメ。 >>84
> >>82 は何で VM にこだわってんの？
どう理解したらこだわってるように思えるんだろう…
> Micropyhon は単なるインタープリタ。
仮想マシンとインタープリターの違いは？
てか、むしろインタープリターにこだわり過ぎかと
> >>77 がいるからもう書かない。
何が間違いかも書けないならそれが正解
とっととROMっててねw C言語の基本で、教えてください。
typedef と初めて接するのですが、分からないことがあります。
以下は、ネットにあったソースです。(作者さん、勝手に引用と改変すみません)
#include <stdio.h>
#include <stdlib.h>
typedef enum{
RUNNING = '1',
STOPPED = '2',
FAILED = '3',
HIBERNATING = '4'
} MACHINE_STATE; // (a)
int main(void) {
int input1;
MACHINE_STATE state; // (b)
// char state; // (c)
printf("type [1-4]: ");
input1 = getchar();
state = input1; // (d)
switch (state) {
case RUNNING: printf("running\n"); break;
case STOPPED: printf("stopped\n"); break;
case FAILED: printf("fail\n"); break;
case HIBERNATING: printf("hibernated\n"); break;
default: break;
}
while(1){}
}
typedef unsigned char UCHAR と書くと、以降のところで
UCHAR c; と書けば、unsigned char c; と同じ作用になると本などに書かれていました。まさにtypedefだと思います。
ところが上記のソースだと、typedef〜(a)までの間に、unsigned int とかの文字が書かれていません。
そして(b)で、MACHINE_STATE型でstsusという変数を取る、ということをしています。
ここまでの行でMACHINE_STATEが unsigned char なのか、intなのか、型のことに触れていません。
1. この場合、MACHINE_STATE は、何型になるのでしょうか。
2. このようなtypedefの使用は、(c)のように普通に取るのと比べて、どういうメリットがあるのでしょうか。
3. また、(d)の点で、input1を あえてstatusに入れ直していますが、これは、なぜなのでしょうか。
宜しくお願いします。 >>87
enum は 整数値。
char や int で宣言しないのは、変数の意図をわかりやすくするためじゃないですかね。
コンパイラや設定によってはワーニングを出してくれるのかな?
ここに書かれている範囲だったら、いきなりstateにgetchar()値を入れても問題はなさそう。
でも、あとあとwhile(1){}の中に書き込んでいく意図があるとしたら、
その中でプログラムのステートを管理するstateはgetchar()でいきなりいじるのはしたくないはず。
getchar()は習慣的にいったんinput1みたいな変数に入れているのでは。 >>88
ありがとうございます。
>char や int で宣言しないのは、変数の意図をわかりやすくするためじゃないですかね。
確かに本にもそのようなことが書いてありました。
ただ、メンバーの名前では、unsigned char なのか unsigned int なのかがわからないと思うのです。
というか、unsigned int 一択で、unsigned charは無いということでしょうか? でしたら、納得しました。
いつも型ばかり気にしているので、型が分からない宣言は、とても心配でした。
なんだか unsigned int 一択が正解な気がしてきました。
>その中でプログラムのステートを管理するstateはgetchar()でいきなりいじるのはしたくないはず。
>getchar()は習慣的にいったんinput1みたいな変数に入れているのでは。
たしかに、直接は嫌ですね。入力値の評価をしてOKを確認してから採用ですね。
どうもありがとうございました。 enum の型は基本intと同じ扱い
ただし、
intの範囲を越えたらより大きな型になる
コンパイラやコンパイラの設定によっては
charから拡張していく物もある
また、型を指定出来る物もある
詳細はコンパイラの仕様書を見て
enumはenumとして別の値に直接キャストしない
特定の値、特定のサイズを仮定しない
のが本来だけど
効率を考えるとそんな正論ばかりは言ってられない
単なる値の#defineの代わりにenumを使うこともある >>90
ありがとうございます。
>単なる値の#defineの代わりにenumを使うこともある
そうですよね。僕は逆でしたが、enumで並べるの代わりに、
#defineで数字を定義して使っていました。
数字の大小に意味は無いと思うのです。
>intの範囲を越えたらより大きな型になる
そうなんですか。65535の次は42億....とか。
それででしょうか、状態遷移などのとき、enum で、
idle, wait, start, stop などと列挙して、if()で比較するときに、
if( さきほどの例のstatus == enumのメンバ ){
という比較をしている例がありました。
型の大きさが同じもの同士の比較なら、問題も起きないですよね。
どうもありがとうございました。 >>91
enum をtypedefするのは、その型の変数にはenumで定義した値しか入らないってことを明確にする意味がある
だから、typedefした型の変数にintの数値を代入したり、intと比較するところがあったらおかしいってわかるようになる >>93
コンパイラによるけど、出る方が多いんじゃないかな >typedefした型の変数にintの数値を代入
STM32CubeIDEのgcc(.cファイル)だと設定を厳しくしてもワーニングが出ないっぽい。
適当に書いたから最適化で無視されたかもしれないけど。
gpp(.cppファイル)はキャストがないとワーニングが出る。 >>92
enumは、もともとint なんだから、
intを入れても問題ない。
何言ってんだか。 >>96
C++のようにワーニングが出るなら、
enumで定義されていない値を、おかまいなしに int値で入れるようなことをしたらわかるしね。 まとめ
MicroPythonは、基盤となるマイクロコントローラハードウェアに依存せずに
リアルタイム組み込みアプリケーションを実装したいと考える開発者にとって、
魅力的なプラットフォームです。
開発者は、MicroPythonで提供された標準ライブラリを使用して
高水準のPythonスクリプトを作成し、サポートされる任意のマイクロコントローラで実行できます。
これには、次を含む数多くのメリットがあります。
アプリケーションの再利用性が高くなる
市場投入までの時間を短縮できる
アプリケーションとハードウェアを分離できる
MicroPythonはあらゆるアプリケーションに最適というわけではありませんが、
産業用および宇宙システムのアプリケーションやプロトタイピング、概念実証では、
これまでに高い効果を発揮しています。
試してみたいけど、Windowsでできるのか・・・ ポケモンをきっかけにマイコンに興味持ったんだけどhexファイルをなんとかしてATmega32U4系で使う方法ってない？
逆は出てくるんだが ダメと君が判断した理由が逆に分からん。
HEXは入れ物に過ぎん。 何のhexファイルなんだろう。
なんかdocxファイルを手に入れたんだけど、卒論に使えるかな?
みたいな。
HEXファイルは、世の中のさまざまなマイコンのプログラムや、ROMに書き込む
データのフォーマットで、マイコンの機種が違ったり、同じマイコンでも、
マイコンの周辺の回路が違えば使えないと思った方がいいよ。 >>102
マイコンの動作を考えて→プログラムにして→コンパイルをすると→機械語が生成されます。
その機械語ファイルの形式を、hexファイルと呼びます。
プログラム→コンパイル→機械語ファイル生成(hexファイル)という流れは逆行できません。
もちろん、あのマイコンで作ったhexファイルを、機種の違うマイコンで使うこともできません。 >>105
ファミコンのROMがPCで使えるのは何故なんだぜ？ 機械的にか人手かしらんがリソースかければ逆行できるよ。 逆コンパイルしてコンパイルしても動かないだろ
同じマイコンじゃなきゃ >>106
それはもしかしてエミュレータ?
だとしたら、パソコンの中にソフトウェア的にファミコンを作っているからできること。 マイコンも別のマイコンのエミュレータを走らせればいい。 質問させてください。
ほとんどのマイコンで、複数のタイマーモジュールがあると思います。
この複数のタイマーは、どのような使用を想定して装備してあるのでしょうか?
例えば、main()処理中にtimer1割り込みが発生しました。その処理をします。main()に戻ります。
これは普通に使いますし便利な機能だと思いますが、timer1, timer2のつを動作させた場合、
timer1の割り込み処理中に、たまたまtimer2の割り込みが発生します。
優先順位が高ければtimer1の処理をそっちのけで、timer2を処理しに行きます。
timer2から戻ってtimer1が再開して、その後main()に戻ります。
通常はtimer1とtimer2の周期は違いますから、
多重割り込みが発生するときもあれば、しないときもあります。
そうすると、せっかくのtimer1の定時性が崩れてしまうと思うのです。
ではtimer1のpriorityを上げれば今度はtimer2の定時性が維持できないと思います。
timer1の処理中で、if( n++ > T2 ){ T=0; timer2の処理 } とやれば、timer1 1本なので、
どちらの定時性も確保できて良いと思うのですが、この考え方は間違っているでしょうか?
現実にtimerが5本も6本もあるところを見ると、私の考えは正しくないことは想像できるのですが、
学生時代からずっと疑問に思っているのでお尋ねしました。 ・タイマーはいろんな用途がある
波形の幅測定、波形出力、ソフト処理用タイマー、フリーラン、...
・完全な一定間隔でのソフト処理は難しい
実行中の命令、割り込み禁止区間、多重割り込み、キャッシュ
などにより命令サイクルレベルの一定間隔での処理は(ほぼ)不可能
>>113の方法も、処理1の処理時間がifや可変数ループなどで一定でなければ処理2は一定間隔でなはなくなってしまう
その程度のばらつきが許容される用途にしかソフト処理は使えない
・タイマーの共有
単純に使用リソースを減らす意味でタイマーを共有するのは一般的
規模が大きなソフトなら一定間隔で行いたい処理は100個以上にもなる
・割り込みの優先順位
どの程度処理が遅延していいか、どの程度処理に時間がかかるか、その処理のクリティカル性
などによって割り込み優先度を決める
許容遅延10usオーダーのタイムクリティカルな処理はタイマーA、1ms程度ならタイマーB、10ms以上ならメインループ
のような階層にする >>113
そもそも多重割込で定時性が許容できないような処理を割り込みルーチンでやるなよって話 >>116
重たい処理はスレッドに通知してやらせるとかが普通かと 定時性ってどれぐらいを定時って考えるかによる。±1m秒ぐらいでOKなら、とか、±100nsでないといけないとか。
ひとつのタイマー割り込みでソフトウェアで分岐するやりかたもありだし、タイマーが少ないマイコンだったらそうしてた。
それでも、ソフトの処理の分岐や、タイマー割り込みルーチンに入るまでの時間ばらつきで、応答のばらつきはあるし
定時性のばらつきをどこまでを許容するのかを想定しないと。
たくさんのタイマーは、必ずしもそれぞれで別個の割り込み処理につかうわけでもない。
別のペリフェラルの直接に起動に使ったり、I/Oピンからタイマーの状態をソフトを介さずに使うこともあるわけだし。
定時性のばらつきは、クロックのジッター程度しか許さない。ってことだったら、そういう処理は外部デバイスに任せる
しかないのでは。 6800 6809 のアセンブリをやってみたいのですが、
フリーのアセンブラーってありますか?
6502 や 68000 もさわってみたい。チップがあるかわかんないけど。
CPU, PIO, TIMER, SCI ぐらいあれば、デバッグもできそうだし。 >>119
6502は秋月でも売ってる。
アセンブラもC コンパイラなんかもある。
ただ、ROMに書き込むのはどうするかとか、そもそも最初はCPUがROMやRAMを読めるのか？ってあたりからテストしていかないといけないから、それなりのスキルと道具は必要かな？
トラ技でも以前6502マイコンボードを製作していて、スイッチパチパチしてRAMにプートローダを書き込んで、PC上で作成したプログラムをシリアルでダウンロードして動かすなんてやってたな。 >>119
6800、6809、6502、68000のアセンブラで思い出したけど、
昔、汎用の（複数のCPUに対応している）メタ・アセンブラなるものがあった。
検索してみたらCross-32は今でもあるみたいだが、残念ながらタダではない。
https://www.cdadapter.com/cross32.htm asm6809とかググれば一発目に出てくるが
コレ
6309にも対応とか遊べそう いまさらROMライタとか胸アツだわ
もうやり方すらわからねえよ イレーサーの蓋開けたときの
オゾン臭がなつかしいにほひ O-Zoneってマイヤヒーの？
苦しいな
フラッシュ式で消すやつと紫外線で消すやつが有るのよね
でROMライタでブランクチェックするのがルーティン 昔は遊技機から外されたものと思しき窓付きの27256とかが出回っていたけど、
今ならどうするんだろう。FLASHとかEEPROMで代替かな。
実験だったらOTPは使いにくいし。 主計機は書き換えられんようマスクだったと思う。
演出用は何でもあり。 医療用のX線だったか粒子加速器だったかで消去を試みたが
デバイス自体がお亡くなりになったという話を聞いたことがある。 あれは特定波長の紫外線が必要
ブラックライトじゃ消えないよ
消毒用じゃないとだめ うちは自作したのがあるな。
といっても、紫外線ランプと安定期、グローランプをつないだだけだけど。
今ならレジン用のが手芸用品店で手に入るかな？ なんか料理してるみたいな感じだった
あれはあれで味があったな
面倒だけど 普通にROMイレーサーの製品を使ってたわ
測定器と同じ括りになるから自作じゃ無くて銘板が貼ってある製品 ストロボ式で、すぐ消えるっていうのもあったけど、一回では上手く行かなかったり、色々あったな。 トラ技のコラムか何かで
新製品発表会で製品を動作させてるとき、撮影でフラッシュをたかれたら誤動作してしまい
UV-EPROMに遮光シールを貼ってなかったから、みたいな話があったな 光で発電するからね
LEDも光当てると発電する
意外とこれ知られてないんですけど ストロボの方が合ってるの？フラッシュ（メモリじゃ無い）の方が合ってるの？
言葉はどうでも良いのだけど、発光させて（たしか10回くらいだった）消すやつが有ったけど消えたり消えなかったりでブランクチェックする手間考えたらUVのイレーサー使ってた
あっちの方が確実だった 開発時はローテさせてやってたな
ROMエミュは便利だった 底辺職やってたとき開発じゃ無くてマスターROMを空のROMへコピーする簡単なお仕事してました フラッシュっていうのは、本来は使い捨てのフラッシュバルブ（閃光電球）
を使った奴のことなんだろう。
アセンブルし直すとすごい時間がかかるのと、開発装置自体が取り合いに
なるので、今みたいにソースを修正して再アセンブルなんてできなくて、
ROMライター使って、パッチあてるなんていうこともやってたな。
命令コード記憶していたしね（笑） そう、ストロボタイプの商品もあった。
でも、実際に使うとEPROMの不良が多発して使うのをやめたっけな。
「やっぱり、じっくりこんがり焼かないと駄目なんだね」なんて言いながら・・ >>146
開けたらズラーっとUV-EPROM?
ちょっと怖いかも笑 昔、IA80というコンパイラーって無かった? たしかフロッピーベースで動くという。
それで6801のソフトをやっていた。 コンパイラはないだろ
PROASM（IA80 アセンブラ、IR80 リンカ）じゃないの？ 昔はたいていフロッピーで動作してたよ。 BDS CとかLSI-C 80とかあったよな。
パソコン用でもMS-C、Lattice C、Turbo C/C++、LSI-C 86 をフロッピーで使ってた。 >CP/Mとかはそれ以前の問題だったね
それ以前の問題、ってどういう意味? >>154
その当時から、構造体とか共用体、ポインターもあったんですか？ >>160
あった。
というか、Cって高水準アセンブラみたいなものだからね。
ポインタがあってこそのCって感じで。 CP/M の BDS-C だったか α-C だったかの本まだあるかな
探してみよう >>165
すまん。たしかα-Cは、BDS-Cと違って、何かのファイルが付いてなくてROM化ができなかった。 始める前は なんでROMライターは10個も一度に消去できるんだろう？ って思ったけど、
自分でやり出したら、すぐに理由がわかった。
その後FLASH ROMになったときは、考えた人スゲエと思った。
オンボード書き込みになった時は、考えた人 天才だと思った。
進歩していないのは、俺だけ。 
