◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:マイコンソフト 悩み事相談室 2 [無断転載禁止]©2ch.net YouTube動画>12本 ->画像>3枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/denki/1469905691/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
. >>1 を見て、分かり易く質問を書いてね。 前スレで出ていた値の範囲の話で便乗質問なのですが、
>>6 ＞可変できていない様
それはあなたの感想であって、他人に伝えるための情報ではない。
on/off期間それぞれが何mSecになっているのか、といった
発生している事実を伝えることを心がけるべきである。（これは一般論である）
そして質問する前にその事実とコードを見比べれば、
たぶん
＞(j = 0; j<= syuuki; i++)
が間違っているせいだろうと自分で気づけるようになる。
# もっとも、これは俺が勝手に起こっていそうな事実を
# コードから妄想しただけだが。
for(j = 0; j<= syuuki; i++){delay_us(1);}
問題起きた時くらいは、デバッガでステップ実行しながら考える習慣は
前スレの議論を全スルーしたコード出してくるとは・・・まるで成長する気が無い
parusu という変数名が良くないのかもしれん。
for(i = 0; i<= parusu; i++){delay_us(1);}
>>14 そこは次の質問用にキープしてあったんだろうにw
これ普通にtimer使って
なんでそんな面倒なことせにゃならん。
>>6 forループで回すんじゃなくて、直接delay_us関数の引数にparusuやらsyuukiやらをぶち込んだ方がいいと思う。
質問を書いた直後に間違いに気づいて
>>6 も出てきにくくなっているんじゃないかと。
リストで気づくことも大切だけど、デバッガを使う習慣も必要ですね。
それよか、この場合は
>>18 に同意です。
タイマーのないデバイスでも動くように、という条件があるなら別ですが、そういう縛りに拘る時代でもないですよね。
>>6 は arduino みたいだから、デバッガ使えないんだろうけど
逆にPWMのAPIはあるから、それ使えばいいっていうのはもっともだけど
プログラムの元の記述を尊重した上でアドバイスするとしたら
for(i = 0; i<= parusu; i++){delay_us(1);} → delay((int)parusu);
for(j = 0; j<= syuuki; i++){delay_us(1);} → delay(syuuki);
>>22 マイコンで言うところのタイマならPWM出力あるだろ。
arduinoってお手軽かもしれないけどデバッグ環境が糞だよね。
>>24 あれは細かく調整できないしゃん。
Duty1%刻みだし。
タイマー2個の方が細かい調整可能。
0%や100%ができないしね。
>>26 ネタならつまらんし、マジで言ってるなら10年ROMってろ。
>>26 8ビットタイマーでも1%刻みってことはないですよね。
>>27 どうしても0%、100%が必要なケースならやりようはあります。
なんでforループやdelay使うやり方を教えるんだろうね？
フリーランカウンター利用したwaitルーチンとかいくらでも紹介されてるけど、
タイマは便利に作ってあるし、便利に使えるんだけどなぁ。
ビジーウェイトのチューニングする労力でタイマ割り込み覚えたほうがいいとは思うけど
タイマー教える前に、for文の書き方を教えるべき。
アセンブラで書けばそんなこと知らなくても困らないよ。
コンプしてフラグが起ったらジャンプ！
傷ついた動物に群がるピラニアのようなスレだな。
なぜ、相手の歩みに合わせられないんだろう？
馬鹿ばっか？
>>6 とりあえず、
for(j = 0; j<= syuuki; i++)
が間違ってる。
これじゃj=0のままなので、ここから抜けられない。
相手が歩かないからみんなが一生懸命押してるように見えるが。
競歩のスペシャリストが、素人相手に「いいからさっさと歩けよ」って引きずり回しているように見えるが。
歩ける人が歩かない人に、「こんな感じで」って言っているようにも見える。
状態遷移でプログラムすれば、タイマー割り込みの数値だけで流れが管理出来て、改造も楽々なんだけどね。
>>29 ごめん勘違いしてた、255分の1の細かさで変えられるのか。
16bitタイマーで10ms周期のPWMやるなら、
>>44 その通り。
一個でやったほうが、間違いがない
タイマー云々言ってる人たちは、質問者とは別世界の議論してるような
>>46 ならなぜおまえは今更な書き込みしてんだよ
ダメってことはすでに前スレでレスがついてる。
それに質問者は10ms周期のPWMをご所望だ。
analogWrite()を10ms周期に変更するのはタイマーの知識は不要か？
それ以前にarduinoかどうかすら質問者から提示されていない。
>それ以前にarduinoかどうかすら質問者から提示されていない。
質問者は精度についての回答は求めていない。
>あくまでDUTYが変化しないのはどうしてか、を聞いている。
教えて下さい。
>>52 USBシリアルのデバイスを抜いて、挿しなおしたときに、Teratermがエラーになるって話ですね。
ちょっとくだけた表現で、正確な用語ではないですが次のような流れになります。
(1)USBシリアルのデバイスを挿す。
(2)OSがシリアルデバイスとして認識する。
(3)シリアルデバイスは蓋を閉ざした待ち状態。このままではプログラムからは使えません。
(4)Teratermを起動
(5)Teratermがシリアルデバイスをオープンして初期設定をする。この手続きで初めてシリアルデバイスが使えるようになります。
(6)Teratermで通信できます。
(7)USBシリアルのデバイスを抜く
(8)USBシリアルのデバイスを挿す。ここから(2)に戻ります。
(2')OSがシリアルデバイスとして認識する。
(3')シリアルデバイスは蓋を閉ざした待ち状態。このままではプログラムからは使えません。
Teratermは、(5)の段階ですでにデバイスが使える状態であると思い込んでいますから、
蓋を閉ざした状態のシリアルデバイスと使おうとしてエラーになってしまいます。
俺は、上のような状況でエラーになったら再起動せずに
ファイルメニューの「接続断」→ファイルメニューの「新しい接続」
をやっています。
>>53 なるほど、新規の接続ですね。ありがとうございます。
やはり「自動的に復旧」と言うわけには、行かないみたいですね。
「再接続」みたいなショートカットがあると、便利ですね。
ありがとうございました。
>>45 普通、タイマー ＋ アウトプットコンペアだろ？
>>55 普通はそうなんだけど、18で出ているようにタイマを覚える気がなさそうだから、普通を言っても仕方ない。
ともかく思ったようにやってみて、うまく行かなければ次の手を考えるというのもありだろう。個人的な興味でやっているならそれもよし。
>>55 それってタイマー2つ使っても変わらなくね？
どうしても2つ使いたいんならそれでもいいんだよ。
ソースコードのバージョン管理ってどうしてる
ファイル名＋日付＋連番．拡張子 だけど、ビルドしたときに、ファイルがありませんが頻発
mbed IDEの内蔵のやつ
フォルダで分けて末尾にバージョン番号だな〜
コンパイラのBuild回数をファイル名に入れてくれる、とか無いだろうか
Windows10にしてE8aが動作しなくなりました。でも添付のケーブルを短くすると動いて
ファイル名やフォルダ名て分けるとか...
mikroCでプログラム修正してコンパイルしてもHEXがなぜか更新されないバクって経験した人います？
>>67 それはよくある。
フォルダー丸ごとコピーすると、保存先のパスなど覚えていて、
オリジナルを上書きということも、多々ある
質問が2つあります。
>>69 > 1つ目
A) です。この関数は割り込みで使いますっていう指定をするでしょ。アレがそうです。
> 2つ目
push、pop とか言ってる割にはスタックのことを知らない？
もちろん割り込みの都度退避する必要があります (でないと戻って来られない)。
なので、当然レジスタだけでは足りなくなるので、メモリ (スタック) に退避します。
まともに退避していくとメモリも時間も食うので、割り込みで使用するレジスタを制限したりして
高速化を図れるコンパイラもあったりします。
>>69 ＞割込処理に飛ぶ前に、レジスタなどを待避し
この表現は（実際にはちゃんと理解してるのかもしれないけど）間違い
飛ぶ前（割り込まれる関数）は、どこで割り込まれるかは予測できないから
レジスタを退避とかできない
但し、CPUによってはNMIがかかった時などには、自動的に（ソフトに頼らず）
全レジスタを退避するようになってるのもあったような気がする
「飛んだ後の割り込み処理の中で、割り込み内で使用する（破壊する）レジスタを退避する」ですな
Cortex-Mとかは割り込みはほとんどハードウェアがやってくれるから本当にCだけで書ける
>>70 >>71 Cで割り込みは定義されてないのでインラインアセンブラで書く。
>>75 ありがとうございます。
Cでは、いつも __isr... の関数を使って書いています。
楽ちんだな、と思っていますが、
実際はどのように、どこに格納されているのか興味があり、質問しました。
どうもありがとうございました。
>>76 割り込み通知（割り込みの種類によって番号がふられている）
→CPU（割り込み許可なら）
→現在の状態や戻りアドレスをレジスタやスタックに退避
→ROMに格納されている割り込み関数への配列[該当する番号]（＝関数の実体があるアドレス）
→そのアドレスに飛び、割り込み関数実行
→復帰
>>77 割り込み関係は、ホントCPU依存なんで限定しないとウソ説明になっちゃう
8051とかPICのＣコンパイラだと、reentrant指定しない関数内の
PICのMid-Rangeじゃスタック自体が存在しないからね
>>82 素のMid rangeは連続したRAM領域が殆ど取れないからな。
PICのアーキテクチャで、Cが使えること自体がビックリなんだけど
> PICのMid-Rangeじゃスタック自体が存在しないからね
ハードウェアスタックのマイコンって、関数のネストが深くなってスタックに保存しきれなくなる場合って
>>86 エラー出すか、力業でなんとかさせるかを選べる。インライン展開するとか。
ハードウェアスタックと ソフトウェアスタックって、
たとえばFORTHではソフトウェアスタックが必要というか、使用している。
>ソース→ディステネーションが同じなのに、ソフトとハードがあるのですか?
MCUでのハードウェアスタック／ソフトウェアスタックに対する私の認識は
ぶっちゃけ、リングバッファに比べたFILO、FIFOなんてあまり使わないよな
RS232の、送受信のりんごバッファって、
リングバッファとFIFOの実装上の違いって、何なんでしょ。
FIFOは形式の書き込み読み出しの順序を示す言葉で
FIFOを作るとしたらシフタを並べるのが簡単かな
むう。俺が
>>92 を読めてないのかな。
>ぶっちゃけ、リングバッファに比べた「ら」FILO、FIFOなんてあまり使わないよな
ってな感じで「ら」を補ったんだけど。
ゴメン、「ら」を抜かしてたね
ええええ？
>92,99
>>101 >>92 (
>>93 )でそう言ったんだけど、誰も耳を傾けてくれないんだよ...
まあ日本語がおかしかったせいかorz
>>102 耳を傾けないってことはなかったんだけど、結果的にスルーになってた、すみません。
リングバッファは使うけれど、FIFOはあまり使わないって話で、
リングバッファをFIFO以外で使うことの方が少ないのではないかなって疑問に思っていたよ。
ところで、マイコンスレなのでスレチになるけれど、ハードでもFIFOをシフタで実装する例ってあるのかな。
すごく効率が悪そうな気がするのだけど。
>>104 >リングバッファは使うけれど、FIFOはあまり使わないって話で、
なんだろ、この話が伝わっていない感は。
どんな実装しようが、先入れ先出しならFIFO(First-in First-out)であって
データ取り出した後に全部のデータを１個ずつ詰める方法だろうが
リングバッファのようにポインタをずらす方法だろうが 共にFIFO。
昔、UARTの制御ICで受信バッファをいくつか持っているものがあったと思う。
>>105 えーと、
誤：FIFOよりもリングバッファ方式を使う。
正：シフト方式よりもリングバッファ方式を使う
ってこと？
>>106 >これは取り出し口が固定の、つまりトコロテン押し出し方式のFIFO。
>ソフトでもこのタイプ（ポインタが1個、取り出し口がボトム固定、データシフトする）のFIFOを
>実現出来るだろうけど処理負担が大きい。
16550みたいなUARTのことなのかな。
あれのFIFOが、シフト方式というのは何か情報があったのでしょうか。
多段になればなるほど、読みだしたときに一斉にバサあッとシフトするのってハードウェアで実装しても
消費電流の観点からも良くないような気がします。
シフト方式に何かメリットはあるのかな。
それとも、ダブルバッファ程度のUARTTのことなのでしょうか。(それならたぶんシフト方式ですね)
昔の数段ぐらいのFIFOにトランスペアレントラッチで作っているものがあって、それはそれで面白いなあと
思ったことがあります。
でも8段ぐらいのものなら、内部にリードポインタ、ライトポインタを持ってるものが多かったかと。
何度でも言うぞ
比較できないものを無理やり比較して何か意味ある結論が導けるかは疑問だ
>>109 あー。ありがとう。俺がトランスペアレントだと思ってたのはこれだ。
読み解いてみよう。等価回路下段のコントロールロジックが面白そう。
>>110 それは分かってるよ。
リングバッファ以外での実装がどれぐらい存在するのか、
リングバッファをFIFO以外でどれぐらい使うのか、
が関心事項だよ。
普通、「FIFO」という四文字の単語からはシフトレジスタを連想すると思うけど？
ハードをやってる人だけど、FIFOをシフトレジスタで
固定概念もってると苦労するよ
突き詰めるとシフトレジスタって言葉の定義しだいってことになるけど
>>117 そうですね。
ただ、それをシフトレジスタじゃない、って言ったら、
「普通、『FIFO』という四文字の単語からはシフトレジスタを連想すると思うけど？ 」、
って言ってる人に寄り添うような実例をなかなか見つけられなくて。
ハードをやってるという
>>113 がどんな実装をしたのか知りたい…
>>112 リングバッファをFIFO以外でどれぐらい使うのか
それなりにあるよ。
例えば、過去のN個のデータで移動平均処理を行う場合、
普通はリングバッファでデータを保存するけれど、
１個ずつデータを取り出す事は無いのでFIFOではない。
Ｎ個ずつ読み出すことにして、その間書き込みは禁止ってことだとしても
>>118 スレ違いな話だし、「実例」でもないからほとんど意味ない話だけど
FIFOを（どっから見ても文句のつけようない）シフトレジスタ使って
実装するとしたら、シフトレジスタを
【想定される最大の入力データレートｘ段数】以上のシフトクロックで
常に回しておいて、書き込み・読み出しは適切な所を見計らって実行する･･･
というような方法かな
まあ、リード・ライトポインタ管理しなくちゃいけないのは変わりはないから
リングバッファのメモリーをシフトレジスタで実装したってだけって話なんだけど
16450(16550)みたいなやつは、案外そういう実装されてるかも
>>120 「N個の移動平均処理」というのは、新しい１個のデータが入ってきた時に
最新データを含めた過去N個のデータの平均値を求めて出力する処理。
データ数N個のリングバッファに新しいデータを１個書き込んだ後、
バッファ全体を読み出して平均値を算出するという処理になる。
FIFOのように読み出したデータが「空になる」という扱いはしないので
FIFOと呼ぶのは適切でないと思う。
それにバッファ全体を読み出す時に、先頭から読み出しても後尾から読み出しても
結果は同じなので、順番を意識するFIFOという言葉は合わない。
>>122 >データ数N個のリングバッファに新しいデータを１個書き込んだ後、
>バッファ全体を読み出して平均値を算出するという処理になる。
もう少し効率的なアルゴリズムを考えましょう。
>>119 おー。それ。そういや俺もその用途で使ってます！
ユーザーインターフェースを伴うものだと操作履歴(古いものから破棄される)の管理にはリングバッファですね。
>>121 D-FFの純粋なN段のシフトレジスタで作って、
・書き込みは0段目だけ
・読み出しはN-1段目だけ
・N段のバッファが可能
という条件だと面倒な気がします。
単純に速くまわすだけだと、途中にムダなメモリが残ってしまうし。
>>123 言いたいことはわかるけれど、リングバッファを使っている事例には違いはなさそうですね。
それと「移動平均はFIRの特殊な形」と考えるなら、毎度、全加算を行うのは素直なやり方かも。
「連続した数バイトの高速の(割り込みでは処理できないような)データブロックを受信する、
データブロック間には数秒の空き時間がある」
というような用途だったら
>>109 の74ALS236：FIFOメモリ、
あるいは他のシフトレジスタが使えるかもしれない。
いずれにしろ、何らかの追加の回路が必要になって、
このIC1個で終わりと言うわけにはいかないだろう。
>>127 マイコン外にFIFOを置く場合は、送られてくるデータを、FIFOメモリデバイスが喰えるような形にすることが面倒ですね。
既成のFIFOメモリデバイスはたいていがパラレルイン、パラレルアウトですし。
書かれている通り、追加回路が必要になることが多くて、
そんなことをするぐらいなら、メモリブロックが使えるFPGAを使うことになることが多いように思います。
既成のシフトレジスタデバイスを使ってでFIFOを構成するのはまず無理です。
>>118 段数に依るだろ。
4段位ならシフトレジスタ使った方が回路規模小さくて済むと思う。
メモリーつかったら、アドレスカウンターとか必要になるしな。
>>129 >>118 は、
>>117 へのコメントですが、
>>117 が言っているように厳密な意味での
シフトレジスタでどうやってFIFOを実現しますかね。
少なくとも空っぽのときには、書き込みデータは、途中をすっ飛ばして出力に近い
レジスタに書くことになるわけですよね?
>>124 説明が不足だったけど、
・新しいデータを書き込まないときは、0段目には
N-1段目の出力を書き込む
という仕様加えるとイメージできるんじゃ？
（面倒かそうでないかはおいといて）
（特にFIFOとかに限らず）シフトレジスタでシーケンシャルアクセス
メモリを構成する方法は、初期の電卓なんかでは使われていたみたいで
100bitのダイナミックシフトレジスタICとかあったりする
http://eleken.y-lab.org/collection/series/msm100.shtml 誤解がないように付け加えるけど、「シフトレジスタを使うと
いずれにしても全体が同時にシフトする構造ではだめですね。
全体が同時にシフト（ローテート）してれば、Ｎ段のシフトレジスタで
>>134 シフトレジスタで直接FIFOを作るってイメージにこだわると
各段の（パラレル）ロードを独立に制御してかつ、各段の
（パラレル）ロードデータを入力端子に共通に接続する構造になるかな
結局は、TC74HC40105とほぼ同等のことをD-FFでやるだけなんだけど
シフトレジスタ式だとリードライトを完全に非同期で出来るようにするのは
>>134 今4ワードのFIFOが下のような状況だとします。
IN→□□□■→OUT
白が無効データ、黒が実際に書き込まれた有効データです。
つまり、
・FIFOに1ワード書かれて、
・そのあとOUTからアクセスできるように、なんらかの方法で出口までシフトした
状況ですね。
4段FIFOですからまだ余裕は3ワードあります。
この状態で、OUTから読み出しがないまま、INから3ワードの書き込みが発生したらどうなるのでしょうか。
3連続書き込みの1ワード目はFIFO先頭が無効データなのだからシフトしない、としても
2ワード目はさっきのワードを上書きしないためにシフトする必要があります。
そうすると、全体が同時シフトだと、OUTにあったデータはこぼれてしまうように思います。
結局のところ、最低限、各段の(前段からの)ロードを個別に制御しないと実現できないような気がします。
>>134 が言ってるのはシフトレジスタをループに接続してエンドレスにして
常にぐるぐる回しておいて、目的のデータの位置が来たときにリードライト
するということだろ。
初期の電卓はダイナミックメモリで常に回していたらしい。
>>138 意味不明。個別部品の話ではありませんよ。
※念のため。このコメントへのコメントは
>>138 または当人を明示的に名乗る人からのものだけを受け入れます。
８０８６の開発環境をお借りできないでしょうか？プログラムの改修がどうしても必要なのですが、開発を担当した会社が開発環境をもう持っていません。
>>140 なるほど。
ID:l86do+Pxさんは
>>132 で、とにかくシフトレジスタで作ったら、という話をされてますね。
規模、性能、実用性はおいておいて、という感じですね。
であれば俺は関心ないかな…。
>>129 >段数に依るだろ。
>4段位ならシフトレジスタ使った方が回路規模小さくて済むと思う。'
こちらの方は実用的な回路の話っぽい。
>>130 に戻ってしまった。規模の小さい実用的な回路ができるのかな？
ソースコードはあるのかね？
>>127 この例なら特に外付け回路は要らないのでは？
書き込み：データが来たらストローブ信号（RS232Cで言えばスタートビットに相当する）を
クロックソースとして、FIFOをシフトしながらデータを取り込む。
これを繰り返す。
またストローブ信号を割り込みでCPUに取り込む。
読み取り：CPUが割り込みを認識したら、ブロック受信時間後に、
CPUから必要な段数だけ（あるいは全段分)のクロック信号を送って
FIFOからデータを取り出す。
リングにする必要も無いしポインタも不要です。
色々と条件・制限はありそうだけど。
>>146 読み書きのタイミングがバッティングしないなら大丈夫ですね。
別にバッティングしても大丈夫でしょ
ちょっと見た感じでは、74HC40105と同じような回路かな
>>145 8086だったら普通にリアルモードでアセンブラで書けばコンパイルはできるんじゃない？デバッグはbochsとかを使うとか。
FDとかでターゲットにプログラムをコピーする必要がありそうだけど。
＞＞１４５
>>148 すみません。話が錯綜してますね。
>>127 の単独の話ならバッティングしてもOKです。
なぜなら、FIFOかシフトレジスタで実現できる、としているから、FIFOでなら実現できますし。
>>146 は、
>>127 が示した
>「連続した数バイトの高速の(割り込みでは処理できないような)データブロックを受信する、
>データブロック間には数秒の空き時間がある」
この条件の下で、シフトレジスタで実現できることを検討している文章に見えます。
俺のコメント
>>147 はそれに対するものです。
というか、FIFOと称して売られているもので、読み書きのタイミングがバッティングしちゃダメなものは
ないのではないですかね。
>>194 「74HC40105と同じような」ということですが、これってトランスペアレントモードを使ってるのかな？
(D-FFの内部がトランスペアレントだ、というのはナシで、段を外から見たときにトランスペアレントモードに
なるかどうか、という観点で)
コントロールロジックの伝搬遅延を巧みに使ってるように見えます。
空っぽの状態なら、次々にずらしたクロックを与えていくようなイメージかと。
その代わりに、遅延がハンパじゃなくて、空っぽの状態から最初の書き込みがあったあと、
読み出し可になるまでの遅延が4.5Vで208ns(typ)と大きい値になっています。
集団ストーカー・電磁波犯罪被害の加害装置はレーザー・メーザーらしいな
・レーザー兵器について知ろう！
ドキュメンタリー - 未来の戦争 レーザー兵器
ダウンロード＆関連動画＞＞ 防ぐことは、ほぼ、不可能。核兵器以上かもね
・集団ストーカー・電磁波被害の加害装置がレーザー・メーザーによるものだとしたら、レーダーを使うはず。加害者にはこのように見えているハズ。ちょっと、エロです。
64MHzの電波を使って撮像しているMRIの動画
MRI Shows What Sex Looks Like From The INSIDE | What's Trending Now
ダウンロード＆関連動画＞＞ 見えている各臓器、脳も含めて、レーザーを照射すれば、危害を加える行為が成立する
参考までにCTの動画
Radiologist discusses CT and xray small bowel obstruction Imaging
ダウンロード＆関連動画＞＞ PCB Imaging: 3D/CT X-Ray Animated Slicing (Top to Bottom)
ダウンロード＆関連動画＞＞ ・レーザー・メーザーが開発されたのが、1950年台以降、メーザー初の発振が1953年、レーザーの初の発振が1960年
https://ja.wikipedia.org/wiki/%E3%83%AC%E3%83%BC%E3%82%B6%E3%83%BC この記念すべき年以降の、人体の自然発火現象は怪しい
人体自然発火現象
https://ja.wikipedia.org/wiki/%E4%BA%BA%E4%BD%93%E8%87%AA%E7%84%B6%E7%99%BA%E7%81%AB%E7%8F%BE%E8%B1%A1 No.31 突然人間が燃え上がり、焼死に至る「人体発火現象」
http://ww5.tiki.ne.jp/ ~qyoshida/kaiki/31zintaihakka.htm
No.157 人体発火現象２
http://ww5.tiki.ne.jp/ ~qyoshida/kaiki2/157jintaihakka2.htm
人体 自然 発火現象 : 人の体が突然 灰になるまで 燃えつきる / 世界の衝撃ストーリー
dailymotionを上のタイトルで検索してみ
・モスクワシグナル事件
興味のある方は、集団ストーカー・電磁波犯罪被害の基礎知識として、知って下さい。アメリカ大使館での事件です
あなたの脳は誰のもの？（１）モスクワシグナル 前編
http://nueq.exblog.jp/17871225/ あなたの脳は誰のもの？（２）モスクワシグナル 後編
http://nueq.exblog.jp/17875689/ 映画なのですが、集団ストーカー・電磁波犯罪被害の内容にそっくりです。
暇があったら、見て下さい。
クリープゾーン : マインド・コントロール
https://goo.gl/UQ9t4m >>151 実行環境はエミュレータでネットで3.1のイメージを探せば見つかると思うよ。
開発環境はgccとかで書き直す覚悟で今のwindowsで作り直した方がいいんじゃないかな。ちゃんとライブラリ化されてれば必要な部分だけ書き直せば済むかもしれない。
修正が少ないならリスクはあるけど、バイナリパッチを作るとかもありかも。セグメントの管理とかはややこしそうだけど、チャレンジとしてはなかなか面白いと思うよ。
>>151 PC-98だろうなー i386時代の3.5インチTurboCならある気がする
あるよねー、実行Objしか残ってない古いプログラム改修せんといかん時って。
解析が好きだからそういう仕事は俺的には美味しいけどね。
今でもPC98を使っている製造ラインがあるんだけど、
>>161 エミュレータ前提なら最新のwindowsでやった方がよくない？
PC9801を模擬するWindowsソフトって、あるの？
エミュレータがあっても
>>166 GPIBのコネクタレベルまでエミュレートするというのは、ありそうな気がする。
「CONTEC GPIB基板 DLL」とか。
>>166 GPIBは需要無いからやってないが、CONTECの各種ボードはC-BUSからPCI用に置き換えて動かしてる。
>>168 >C-BUSからPCI用に置き換えて動かしてる。
それは、
>>168 が、
>>168 の技術で置き換えている、ということ?
それとも、CONTECが、PCI用の製品を発売しているので、それを
>>168 が使っている、という意味ですか?
>>169 PCI→98(C)バス変換アダプタセット
http://www3.contec.co.jp/B2B/ConIWCatProductPage_B2B.process?Merchant_Id=1& ;Catalog_Id=8&Section_Id=8&pcount=&Selected_CatalogMaster_Id=&Product_Id=889
>>169 エミュレータを書いた。
I/Oの部分はリング0で動かしてる。
１４２の件です。いろいろと情報をありがとうございます。
>>173 あーーーーー
また三号機だけ残っちまった！！
どうすんだよこの後…
無制限に回転するVRをADCに繋いで時系列で値が増えたか減ったかを検出する処理ですが
>>175 回転スピードよりも十分速いサイクルでA/D変換をして判断するしかないのでは。
例えば想定される最高回転スピードの10倍で変換すれば、もっとも大きく変化する場合でも1000/10の100。
端っこを増でまたいだときは たとえば 950→50 だったりするわけですが、もし減で950→50だとすると想定スピードより9倍も速いことになります。
減でまたいで50→950でも同じで、増で50→950であるためには(以下略
>>175 １つ前の測定値と比較して、減ってたら別処理にすれば？
そういう単純なことじゃだめなの？
あ、逆回転もありなわけか、ダメだね。
根本的な仕様検討がなってないな。
>>175 変化速度に制限つけないと回転方向は判別できないな
一度の変化量が、確実に200以下とか決まれば、大きい変化なら逆回転ってすればいい
「無制限に回転するVR」って言っても、出力が無制限に増えていくわけでもあるまい
確実にゼロあるいは開放が現れるのならそれを検出して判断すればいいと思うの。
>>182 950→ゼロ確実検出→50
これで解決するかなあ。
>>176 の要素がなかったら方向は分からないと思う。
逆に、それができていれば、ゼロ検出も要らないと思う。
てか、176の方法で対応できないケースのほうが考えにくいのでは？
皆さまありがとうございます。
>>176 一回転あたり、最低三回は検出しないとダメなのは、考えれば解るはずなのにな。
その3回の値が、
普通にロータリーエンコーダって書けば良いのに。
使ったこと無いけどPSoCのアナログブロックでレゾルバとか読めるのかな？
>ポテンショメータ型のロータリーセンサーを使う意味って何なんだろう。
入力判定でon信号がきてから±1秒でスイッチを押せているかどうかと言うのはどの様に書いていけば良いのでしょうか？
必要な精度のタイマー割り込みでonとスイッチの信号を見る。
>>192 回転角度の検出が簡単に出来る。
連続回転させて使うのではなく、ステッピングモーターとかと組み合わせて使うんだろ。
>>196 オン信号で外部入力割り込みを有効にし、一秒のタイマーをカウント開始する
タイマー割り込みで、外部入力割り込みを禁止にする
外部入力割り込みで、スイッチが押されたのを確認
>>192 アブソリュート形ロータリエンコーダだな
非接触式のプロ用は高い
>>196 ・ぴったり2秒間サンプリング可能な長さのリングバッファを用意する。
・スイッチの入力を連続サンプリングしてリングバッファに絶えず流し込む。
・on信号からぴったり1秒後にスイッチ入力のサンプリングを止めて、バッファの中にスイッチON入力があるかどうか調べる。
スイッチを常時監視しておいて、入力が来たら反応させる
新卒の僕「先輩、ここswitch-case文じゃなくてポリモーフィズム使った方がいいんじゃないですか？」
社会人の壁かな。
>>205 ハードウェアに近いことやってるところは、そんな感じが多い気がしている
ソフト屋として技術を身につけたいなら、自分で勉強するか、もっとソフト寄りのとこ行けばいい
マイコンのアプリでぽりもーなんとかっつうのもこれまた…やね
実際、OOPでカッコよく書くのとCでダサく書くのはどっちがコードサイズが小さいんだろうか
>>209 最近はコードサイズなんかより明瞭性のほうが大事なプロジェクトが多いんじゃないかな
機械制御はリアルタイム性が要求されるので
>>209 逆アセしたら分かるよ。OOPで書いたコードは元が何か分からないほど沢山のコードが生成される。コンストラクタとかグローバル変数の初期化とか、書いた人が想定してないタイミングで動くこともよくあるからね。
サイズも速度も圧倒的にCだと思うよ。可読性とコード量は逆の関係になるよ。多分。
裏で何が起こってっかわかんないのが高級言語だからしゃーない
C++使う理由はたくさんあるはずだよ。サードパーティーとかライセンスとか社内のIPとか権利とかコンパイラとか何かのバージョンとか。少し考えればいくらでもあるじゃん。それが分かってない先輩も新卒もレベルは変わらないかもね。
>>214 最近のマイコンは、昔はソフトでやってた事も周辺機能として取り込まれてるから、また、状況は変わって来てる。
>>206-215 様々な意見有難うございます。
>>206 確かに、誰もがわかるよう書くのは大事だと思うけど、
「シンプルにわかりやすく書け」という言葉を
「簡単な(俺が知ってる古い)文法手法しか使うな」
という意味で言ってるわけではないですよね？
うちの先輩は後者の方ですが
>>207 本当にリソースやタイミングがシビアなとこらなら、部分的にある程度ベタ書きは許容してもいいとおもってます。
ソフトの勉強は自分で率先してやってますよ。
ただ、仕事のなかで学べる方がスキルアップは早いのにと不満に感じています。
この不満を解決するには転職しかないんですかね？
>>208 謙虚…
確かに今の私に足りないもののひとつかも
現場を良くしたいという意識もあるので、バランスや立ち回りが難しいですね
これも上から目線だと叩かれそうですが
>>209-213 自分的には、可読性とメンテナンス性・テスト可能性を優先して書いた方がいいと思います。
コードサイズや速度を気にするのは後からで。
初めからコードサイズや速度を気にした書き方をしても、労力に見合った効果はありますか？(orありましたか？)
>>214 政治的な理由でC++を使う人が多いということですか？
言語の特性とかではなく？
後半の指摘についてはその通りだと思います。
>>215 確かに、数年前と比べて安いマイコンでも周辺回路が高機能になったのはありがたいですね。
メモリも大きいですし
>>216 例えが悪くて済まんが
最新のOOPテクニックをふんだんに使って作ったシステムをリリースした翌日に交通情報にでも遭って死んでしまったらどうする？
企業としてはメンテ出来ないシステムなんか許されないわけで先輩も言外でその事を考えてるよ。
社内ルールを漸次変えていくよう提案するか、趣味プログラミングで発散するしか無いかと。
似たような轍を通ったおっさんより。
意識が高いのはすばらしいし、行動が伴えばもっとすばらしい
可読性も含めたメンテナンスのしやすさって、結局のところ集団が持ってる知識の得手不得手に依存するのではない？
>>217 確かに、自分以外の人が管理できない属人ソースは指摘されたようにリスクを伴うとおもいます。
しかし、「OOPをする=他の人がいじれないものになる」ととれる箇所については、賛同しかねます。
他の人がメンテできなくなったとしたら、
それは書いた人が汚い設計・コードディングしかできないか、
回りの人が知識不足なのではとおもいます。
>>222 人はみな望む答だけを聞けるまで尋ね続けてしまうものだから、じゃないですかね。
心細くて自分と同じ傾向のアドバイスが欲しくなるのだと思います。
>>221 この場合、OOPで書いた人にはちゃんとした力量があるとするのなら
>それは書いた人が汚い設計・コードディングしかできないか、
↑こちらの可能性はとりあえず排除できます。
問題は、↓こちらの方ですね。
>回りの人が知識不足なのではとおもいます。
>>220 にも書いたのですが、集団として継続的なメンテナンスをする必要があるなら
「集団に所属する個人」と「集団」はレベルを合わせる必要があると思います。
誰か(Aさん)が他の人が理解できない、先進的なことをしようとしたとき、次のようなことが考えられます。
1. Aさんが諦めて集団にレベルを合わせる。
2. 集団のレベルを上げる
3. 集団で継続的メンテすることを諦めて、Aさんに尖ったことをやってもらう。
実際にはどれが一つではなく、並行してやっていくのだと思いますがさもなければ、
4. Aさんは、自分が納得できる集団に乗り換える。
という選択肢もあります。配置換えを願い出るか、転職ってことですね。
>2. 集団のレベルを上げる >>205 の意見は、正しいと思う。 >>205 のすべきことは、 >>205 に信用ができる。 >>205 がOOPで代替可能であることを示す。 >>205 はヒーローになれる。 >>205 が、いきなり4.をやっても、 新しい技術を使えばいいってもんじゃない。
>>225 一般論としてはそうだけど、今の話は周囲の勉強不足が原因だな。
なぜC++を使ってるか目的が分からない。
目的も分からないし、メリットデメリットも分かってないのにOOPを押し付けて、それを知らない人を見下してるのが気になる。
いやこれ、新人君を擁護する訳じゃないけど、
コンパイラはC++でも、組込みなら .c にするよね。
容易かどうかは分かんないけどね。普通に考えたらCとアセンブラだと思うけど、マイコンっつってもlinuxくらいのってんのかもね。
俺web屋だけど、
毛嫌いしてるわけじゃないんだけど、
組み込み屋さんのタイムスケールから考えると十分新しいし
そもそもcppなんてトロくて使えない。ｃはアセンブラの10〜100倍遅いし、cppは更に10〜100倍遅い。
>>231 効率悪いからな。仮想マシンとか中間言語インタプリタとか、電池の無駄遣いは赦されないのだよ。
なんでAndroid はあんなに流行ったんだろうな。
>ｃはアセンブラの10〜100倍遅いし、cppは更に10〜100倍遅い。
OOP＝「仮想マシンとか中間言語インタプリタとか」って感覚なのかなあ。
>>221 パソコンとちがって組み込みは、ソフトとハードが直結されてるから、OOPで隠蔽化されると、不具合起きたときに対処しづらい。
C++の話で何で「仮想マシンとか中間言語インタプリタとか」出てくるのか
ま、パソコン坊やには一生理解出来ない世界だから仕方が無いｗｗｗ
大人げないレスしてしてしまった....ｽﾏﾝ
ただね、おじさんは新しいことを頭ごなしに否定はしたくないし、
ある程度相手からの視点を理解してから反論するほうがいいと思うんだ。
ここでの議論は感覚が違いすぎる人同士でやってるからお互い理解できないんではと感じるよ。
なんでオブジェクト指向使えとか言うの？うるせぇな
って思う人は↓を読んでみると、ﾌｰﾝ便利やんってなるかも
オブジェクト指向のこころ
https://www.amazon.co.jp/dp/4621066048 で、
>>205 、またはあんま勉強せず我流でやってきた人は、
組み込みに合わせた開発手法を↓とかで勉強してみてほしい
テスト駆動開発による組み込みプログラミング
https://www.amazon.co.jp/gp/aw/d/4873116147/ モダンC言語プログラミング
https://www.amazon.co.jp/gp/aw/d/B00HWLJEKW/ >>224 で指摘してるように、すぐに変えるのは基本難しいけど、
変化の激しいこの時代、知識と視野は広いに越したことはないからね。
>>241 も
>>237 と同じで、「組み込みとはOOPが使えない規模、環境のものだ」という定義から始めているから、
結論として「組み込みではOOPが使えない」としか出てこない。退屈だと思う。
「パソコンと違って」というけれど、パソコンと組み込みは隔絶したものではなくて、辛口、甘口のカレーみたいに
境界のはっきりしない陸続きの世界だし。
8ビットの世界ならまだしも、32ビットの組込システムが主流になってきている現代でそれは無理がある主張だろう
マイコン扱うのが好きな連中はプログラミングと同じくらいハードもいじる。
>>248 中辛もまた境界がとろけてしまっている。
ちょっと横道のそれるけど、無駄に大きく複雑なモノは
>>231 組み込みでOOPそのものが毛嫌いされるのではなく、OOPではメモリの動的
割り付けするコードが生成されるから、RAM使用量と領域の厳格な管理が
できなくなる。小さなマイコンではスタックあふれの暴走とか細心の注意
を払ってコーディングする必要がある。
LinuxボードみたいなRAMを腐るほど搭載している環境ではOOPは遠慮なく
使われている。
AVRや8ビットPICなどの小さなMCUとは作法、流儀がそれなりに異なるからなぁ。
OOP＝メモリの動的割り付け、って感覚なのか。
動的にメモリを扱わない OOP にどれほどの価値があるんだろうか。
ArduinoはC++使ってるんだけど、誰も触れないのはなぜ？
使っても問題ない。ハードなリアルタイムが要求されるようなとこではC++は使わないと言っているだけ。
>>258 そういう柔軟性そのものが受け入れ難いのかも。使い道によって使い分ければいいのにって思う。
業界に入ったときには、
「研修でアセンブラか。講師の連中は何を考えているんだ。
はじめはハンドアセンブルで学ばないとマイコンのことが見えにくくなるのに」
と古参に言われたのだけど、いつでも開発に関しては保守的な人はいるね。
この人たちが強権を持たず適切なブレーキでいてくれる限りは問題はないのだけど。
ここの話の流れでは何か、C++の出すコードがCと比べて
＞・メンバー変数へのアクセスがthisポインタ経由になるから？
C++って、そんなにいいんですか? 勉強してみようかな。
>>262 C++だと、newとかでメモリの動的確保を使うことがよくあるけど、世の中のマイコンには、動的確保用のテーブル分すらRAMがもったいないみたいなのも多くてな
そんなマイコンでC++使うのもどうよ？ってのが多いんだと思う
>>262 ちゃんと勉強すればcppの駄目さ加減がわかる。
パソコン用なら使えるが、使えるってだけ。まともに設計出来ない℃素人向け言語。
規模が大きいとC++
コンパイラの最適化すら禁止されてる環境で働かされてる俺にとっては別世界の話だな…
>>269 小規模の組み込みなんて、ソフト全体がデバイスドライバー見たいな物だからな。
>>263 C++のコード逆アセしてみたことある？グローバル変数、コンストラクタ、マングリンク、ルックアップテーブル、仮想関数とか、書いてないものが挿入されるでしょ？あれが後で困るんだよ。
そもそもさ、ソフトウェアスタックと言うものがあるわけで、スタックのどのパートを書くかでアセンブラなのかCなのか、C++なのか全然違うでしょ。それを同じだって言うのは無理があるんじゃないかな？
>>261 そ、そうなんだ。それは驚きだね。肝心のコーディング規約ダウンロードできないね。見てみたかったな。
航空防衛はかなり保守的だし、認可取るの大変だから凄い変化だね。
>>271 はそのc++で自動で挿入されるもので、
どういう問題に直面したのか、教えてもらえればありがたい。
最近性能のいいマイコンが多くなってるけど、それでも問題になるの？
>>273 「教えてもらえるとありがたい」ってセリフからしてクリティカルシステムの実装者なめてる態度だよね。
>>274 いや、c++で困ったことのある人の体験談を純粋に聞きたかっただけなんだけど・・・
組み込み＝クリチカルシステム、って認識なのか。
8ﾋﾞｯﾄと32/64ﾋﾞｯﾄを同じ土俵では語れないと思うな。
>>272 新しいリンクはここよ！
www.stroustrup.com/JSF-AV-rules.pdf
Raspberry PiはModel AでもRAMを256MByte搭載しているわけで
>>281 linux が動くレベルのをマイコンとは呼ばないだろ。
>>275 問題が起きたらまずメモリダンプをとって、カーネルイメージが渡されるんだよ。これでなんとかしろと。バイナリのイメージだからね。シンボルすらないかもしれない。この時点でアセンブラがスタート地点なんだよ。
大抵は別のタスクとかドライバが別のタスクのデータを壊してるわけだ。ここからスタックを辿って、被害者と加害者を特定するわけね。
アセンブラでどの関数のどのコードを実行してたかを特定して、次にそのコードがどのデータを参照してるかを探して、そのデータがどのタスクに壊されたかを探すわけだ。
そもそもアセンブラが分かりにくいからCになって、Cじゃ不十分だからC++になったんでしょ？
で、その分かりにくいアセンブラからC++の隠蔽されたコードを避けながら目的の悪さしてるコードを見つけなきゃいけない。
CでさえめんどいのにC++なんてマジ勘弁って言いたくなるんじゃないの？
>>284 マイコン好きな人はやっぱ仕事で制御系やってる人が多いんじゃないかな？制御系はリアルタイムの要求きついから、そういう世界観になってるんでしょ。
ここで意見を交換できるのは良いことだと思うよ。どっちが正しいって話じゃないし。
仕事ならそれ以外のステークホルダによって言語やら環境は決まるからね。発端になった先輩と新人の話なんて現場じゃ関係ないよ。
>>287 言葉使いにいろいろ限定したり一般化しようというベクトルが働くのがいまいち残念。
意見交換することが有益なのは、多様性があるからだよね。自分が知ってる世界だけなら意見を交換する必要はないんだし。
そういう意図がないのかもしれないけれど、
>>286 の話も、先頭に「俺の仕事環境なら」が付いていて、
末尾が「そんなわけで、CでさえめんどいのにC++なんてマジ勘弁って言いたくなるんだ」って締めくくってあれば、
「おお、ID:wxOrnTvhさんのお仕事なら、C++になると大変っぽね」って思えるのにな。
>仕事ならそれ以外のステークホルダによって言語やら環境は決まるからね。発端になった先輩と新人の話なんて現場じゃ関係ないよ。
これも「仕事はこうやって決まるものだ」みたいな認識が読み取れてしまう。まるであなたが視野が狭い人みたいに見えちゃって残念でならない。
自分の知らない世界の人へ自分の世界の話を、交換する意見として投げるなら、
自分たち以外の決定権がある人によって言語やら環境が決まる仕事や現場であるなら、発端になった先輩と新人の話なんて現関係ないよ。
とするべきだろうなあ。自分たちの裁量で言語、環境を決める仕事だってあるわけだし。
複雑な理論を組んでみたけど、
tiny2313でもc++ですむ場合はそれですませるけどな
>>290 C++を拡張Cとして制限して使うことには賛成だが、それだとOOPではないな。
上の議論の趣旨とは外れる。
ここは悩み事相談室だろうに
ま、tiny2313をアセンブラ＋マルチタスクで組んでる俺はプログラム実行スピードとサイズでは誰にも負けない自信がある
>>297 言葉遊びがしたいのかな？
複数の処理を同時に行えば、とりあえず概念的にはマルチタスクでいいと思うんだが。
とかいうと、マルチコアじゃないと同時なんてありえないとか言い出すのかな？あーうざいうざい。
多分 296 は、スタック切り替えて複数のタスクを動かすフレームワークでも作ってるんだと思うけど。
文系ソフト錬金技術者の膨らまし商法を騙るのはこのスレでつか？
>>298 256バイトのRAMでコンテキストスイッチしてるなら無断が多くすぎると思っただけだよ。
>>300 Zレジスタとフラグレジスタを保存してのタスク2個のハード・ソフトのスイッチャーのサイズは命令12ワードで必要なRAMは7バイト
もちろん制約だらけだけど趣味ならこれで十分
32個のレジスタをどのように割り当てるかが運命の分かれ道なのでｗ
プログラム設計時にあーでもないこーでもないと時間を掛けるのが楽しい
なるほど、タスクごとにレジスタ固定してんだな。それなら分かるよ。立派なマルチタスクだね
自営業スレで仕事の話をしてるわけじゃなし、
綺麗な箱庭を作れる人がすべてそうだとは言わないけれど、
℃素人プログラマでも無い限り、マルチタスクなんて当たり前過ぎるけどな
>>306 マルチタスクと言うか、割り込み駆使したり、処理を適度に分割したりとかは、普通だしな。
マルチなのかどうなのか？
ようはプログラムした人間がマルチなのであって
>>308 それは似非だろ
レジスタの干渉も一切ない、マルチタスクの話してんだろ
複数タスク実行とマルチタスク実行の違いがよく分からないが
>>312 35年くらい前にそんな話が出てた。干支3周回遅れかな。
どっちでもええ事を長々と薀蓄ぶちまけるのは
馬鹿のレスは非論理的で意味不明だな。
うん、煽ってるつもりだろうけど、
解りやすいか？ではなく、自分の中で、相手にわかりやすいだろうか？、と推敲し、
机の上の空 大沼安史の個人新聞
電磁波拷問・スローキル（Slow Kill）攻撃を許さない！
ＮＳＡ（米国家安全保障局）の女性内部告発者が不当解雇後、集ストに遭い、それにも負けずに戦い始めたところ、こんどは「電磁波照射」による「拷問・スローキル」被害に遭う！
http://onuma.cocolog-nifty.com/blog1/2016/09/slow-kill-1dc2.html 電磁波拷問・スローキル（Slow Kill）攻撃を許さない！
２０１５年１１月になってようやく、電磁波（指向性エネルギー）照射という「人道に対する恐るべき犯罪」に、自らの体験を通して気づく！
http://onuma.cocolog-nifty.com/blog1/2016/09/slow-kill-603f.html ＤＥＷ（指向性エネルギー照射装置）による電磁波照射攻撃（スロー・キル）を許してはならない！
ＤＥＷによる報復照射を受けているＮＳＡ（米国家安全保障局）の元言語スペシャリスト、カレン・スチュアートさんがツイッターで被害報告！
http://onuma.cocolog-nifty.com/blog1/2016/09/post-fe1a.html ＤＥＷ（指向性エネルギー照射装置）による電磁波照射攻撃（スロー・キル）を許してはならない！
ＤＥＷによる報復照射を受けているＮＳＡ（米国家安全保障局）の元言語スペシャリスト、カレン・スチュアートさんがツイッターで同時進行被害報告！
http://onuma.cocolog-nifty.com/blog1/2016/10/wdew-2d3c.html 集団ストーカーによるＤＥＷ照射攻撃に、日本ではなぜ宗教カルト系組織が使われているのか？
ＮＳＡによるＤＥＷ（指向性エネルギー兵器）攻撃に曝されれている内部告発者、カレン・スチュアートさんによると、彼女の地元の「インフラガード（InfraGard）」（米連邦政府自警団）が集スト照射の実戦部隊として使われているという。
http://onuma.cocolog-nifty.com/blog1/2016/10/infragard-10a2.html 電磁波照射・拷問攻撃を許さない！
米海軍士官学校（アナポリス）の卒業生（制御システム工学で学位取得）、デイヴィッド・ヴォートさんが、「ＤＥＷ（指向性エネルギー兵器）」による電磁波拷問の脅威・現実を訴え、米国を横断ウオーク！
http://onuma.cocolog-nifty.com/blog1/2016/11/post-cc21.html 電磁波照射兵器の実験・演習・使用を、許してはならない
http://onuma.cocolog-nifty.com/blog1/2016/11/post-e223.html Ｓ・Ｒ・Ｂ・Ｓ電子倒国の皆様ごきげんよう。
やっぱりキッチーだったか。
>>245 の下2冊の本読んでみたけど、イイねこれ
趣味でしかマイコンいじらんけど
テスト駆動開発ってのはとくに組み込みで有用そうね
仕事ではこれやってる人居るのかな？
制御対象が多様なのに一つのマイコンというククリで
それ何回も言ってるけど言葉を変えて結局同じ話に戻ってきてるよね
マイクロコンピュータとミリコンピュータに分けたら？
HITAC10 のことでしょうか?
NEAC M4なら使ったことがある。
>>328 FACOM Rのメモリ増強モデル、FACOM R-Eってのを学校の授業で使ってたよ。
IPLはオート、紙テープで2パスのFORTRAN使って授業受けた。
クラスにいた秀才は、その時からアドレス直接指定してビットデータの書き換えとかできてたよ。
あの頃の俺には理解不能なまるで魔法みたいな感じだった。
今はできるけどなー
「お爺様が集って若かりし頃の思い出を楽しく懐かしく語り合うスレッド」が必要だな。
MELCOM70 360?
現在か未来について語ろうぜ
あるいは、せめて有益な思い出話を
>>205 あたりからの活気はどこにいったんだよ
こうやって若い人が離れてくんだよ
TO92パッケージの3pinマイコン知りませんか？
>>337 MELCOM 70Bから触ってた爺ですが
>>339 昔Ｄａｌｌａｓにあったな、DSなんちゃら
うまく検索できない
>>344 CICSとかADABASやDB/2起動したくなるな。
教えて下さい。
>>346 簡単にはならないが、XOR
反転させるbit を選べるメリットは有る。
ありがとうございます。
全ビット対象なら、a のビット数分だけいるんじゃないの？
C言語って、だれが考えたのか知らないけど、簡略方法のセンスがいいよね。
>>350 見易い方で良い。
今時のコンパイラは、最適化してくれる。
>>350 それは思った。さっぱりして、それでいて分かりやすい。
他の言語で使えない時、めんどくせぇ、と感じる位に。
a++は認めるが
>>352 同意です。スマートですよね。
a++; は、Verilogでは使えないので、少しだけ「イラっ」です。
a++;と単体で使うには良いとおもう
僕も最初は a++ と ++a は、戸惑ったけど、
コメントと四則演算のかけ算以外で「*」が出てくると、引いてしまいます。
>>361 Special Function Resistor
日本名は、スペシャルファンクションレジスタ
意味は、特別な機能用の置数器
>>363 特別な機能用の抵抗器じゃね？
みんな英語が苦手だもんな。
>>353 へぇ、そう言う思想もあるんだ。
a+=b
a&=b
a<<=b
とかは認めない感じ？
>>355 処理順がシビアな奴は敬遠しちゃうね。
息をするように扱えればエレガントなのかもだけど、
そこまでの力はないんで、条件式内での代入は避けてる
>>357 に同じく、アセンブリ触るといいよ。
んとに触りだけで。
メモリが見えるようになるし、配列や文字列がアドレスな理由が見えるようになる
Ｃから入った香具師
普通の人
まぁ、変数だからなぁ。
Ｃの効率がいいのは解ってる、
どういうときにポインタの嬉しさがあるかわからないです。
>>376 SFRrに反応しておいて、つまんない釣りはやめろ
Ｃや他の高級言語の話ならソフトウェア板へでも逝けば良いのかもな。
>>378 >>1 には、C言語のことが書いてあるし、
話題としてはバッチリだと思いますが。
LPC2388でMDK-ARMを使っています。
>>379 良いんじゃないの？
ところでポインタは理解出来たかな？
>>376 あなたの使うマイコンのライブラリがどういう考えで作って
あるかで決まる ポインタというものを極力使わないようにも
作れるし マイコンなんだからポインタ持ち出したほうが単純じゃん
ということでばしばしつかう流儀もあるだろうし
>>376 #defineとかで隠されているがP1はポインタだから。
実体「アメちゃんやるわ」
ポインタ使わなくていいんなら別に無理に使わなくていいし、覚えなくてもいいよ
Ｃだと動的メモリ取得と文字列操作はどうしてもポインタ見え隠れするかもね
>>380 ですが実機ではプリフェッチアボートが発生していました。
マイコン、ＰＣ周り系からＰＬＣと徐々に手を広げているが、確かにデバック環境＆ラン中書き込
>>392 マイコンとPLCはカバーしている範囲が似ているようで相容れない。
人も開発思想も仕事の仕方も。
>>393 マイコンはソフト屋で開発業、
PLCは電気屋で施工業、
みたいな空気というか思想や文化を感じる。
スタート地点間逆だしね
機械屋が自動制御化してきたようなとこの、
頑固な体育会系のやり方はどうも馴染めない
>>391 LPC2388には、キャッシュもMMUありません。
コード自体はIARで生成させたhexを書き込むと正常なので問題ないと思います。
シミュレータの例外設定は、すべてで表示、停止するようになっていますが
動作しています。シミュレータの限界なんですかね？
>>397 最適化切ったbin通してみたらどうかな
>>398 最適化のレベル0でも同じです。
ARMでもThumbでも変化ありません。
>>400 はい。だからシミュレータを使っています。
>>402 仕事じゃないです。仕事でデバッガが無いなんて考えられません。
>>388 マイコンでポインタ使わないとか、無理だろ？
>>405 隠すことはできるだろう
arduinoが典型的な例
>>405 PICでも使わないよ。
RA0 = 1;
RCSTA = 0x52; とか、書ける。
>>407 defineされてて最後はポインタになるんじゃなかったっけ
>>408 そりゃそうだろうけど、本人は使ってない（そんなことすら知らないレベルもいる）んだからポインタが分からなくてもマイコンは使えると言っていいんじゃない？
もちろん趣味レベルの話だけどね
>>390 ですが、gccで実機で動くように成りました。
IARで作成されたRTOSを使えるように成りました。
MDK-ARMでシミュレータが使えるのでデバッグが簡単になるかと思いましたが
役に立ちませんでした。コードサイズ制限もあるので、gccで使えれば私には十分です。
助言を頂け有難う御座いました。
>>408 その理屈だと、int a=0x52; でも変数aにコンパイラ・リンカが自動的に
アドレス（ポインタ）割り当ててるって話になるよね
ポインタを使わない＝*とか&を書かない
>>412 そういうことなのでしょうね。自らが*とか&を書かない、という感じで。
少し込み入ったプログラムを書こうとすると、ポインタを使った方が便利なことも出てきます。
そのときに勉強すれば良いように思います。
ポインタを分かっていなければならないとか見えないところで使っているとか
ポインタを使わなくてもプログラムを書けるとか、そういう主張を始めるとお互い頑なになってしまいますね。
どういうものか知ったうえで判断した方がいいんじゃないの？
*や&を使わなければポインタと無縁なんて間違い。
ｺﾏｹｴｺﾀｧｲｲﾝﾀﾞﾖ(AA省略
そういう話ではなかったと思うが、まぁ、細かいことはどうでもいい。
includeファイルも含めて、
考えたこともないが、そんなこと知ってどうするんだ？
>>420 意識しているかどうかは別としてprintf()の引数がすでにポインタ
なんだから嫌でも使ってるだろ
使いたくなければ使わなくてもいいんじゃない？
JavaとかC#、C++、LL言語をやったことがある人なら
>なんでポインタを嫌うんや。
>>427 わからないふりをしてネタ振りをするのをやめろ。つまらないから。
あんた何度も似たような感じで書いてるからわかるよ。
>>425 Windows 上のアプリとか作るなら、変数の実アドレスを知る必要ないけど、マイコンはアドレスが重要だからな。
>>426 時計まわり渦巻き法ってのがあるのよ
http://c-faq.com/decl/spiral.anderson.html (*(volatile struct st_ad *)0xFFFFE0)
と書かれたら，この場合は 0xFFFFE0がスタートになって
0xFFFFE0 -> (何もない) -> (volatile struct st_ad *) -> (何もない)
-> * -> (何もない) -> (一番外側のカッコを抜けた）
とコンパイラは解釈していって，結局
0xFFFFE0 -> (volatile struct st_ad *) -> *
と解釈される 0xFFFFE0 はまあ long int と解釈されるだろう
（コンパイラのintのデフォルトが32bitならintだし，16bitなら
long int だろうねと）
その次はカッコで囲まれてて基点（この場合は0xFFFFE0)の前にあるから
キャストだねと 揮発性のある(volatile) struct st_ad 型の変数
へのポインタにキャストするよと キャストのされかたは実は
コンパイラ依存なんだけど この場合は メインメモリのFFFFE0番地って
ことを指してるんでしょうね で 最後の * で そのポインタの指している
対象（struct st_ad型の変数）を指すよと
（つづき）だからこの場合は このマイコンのFFFFE0番地に struct st_adで
>アドレスは何バイトで指示すればよいのか、そのアドレスの「差し示す先の値」のbit幅は
>>427 マジレスしといちゃる。
なんとなくわかったぐらいの時にそんなややこしい例を見ればそりゃわからんよ。
たぶん SFR の参照だろうから、サンプルなんかあるだろ。で、なぜそのサンプルの方法で
アクセスできるのか考えていくといいんじゃないか。
自分もアセンブラから入ったんで、ポインタの概念自体は知ってたけど、
C 言語の記述の仕方にはだいぶ悩んだ。
>>427 低レベル（ハードに近いって意味な）C言語の通信教育かセミナー行けばよくね？
>>431 >>431 のお話は、まだ理解出来ていませんが、少しずつ読み解いて行きたいと思います。 hoge はあくまで型の名前でなきゃだめ
メモリアドレス0xFFFFE0に何があるのか知ってるのかね？
ROMの終わりにデータを埋め込んであるとか、特定のバード依存のアドレスだったりとか、可能性は色々とあるけど...
>>440-441 ありがとうございます。
>>439-3 .は、構造体なしに、1つの変数だとしたら、ということです。
>>443 AD関係の周辺回路を設定するFF(フリップフロップ)が繋がっていると思います。
>>439 です。
みなさんの説明を読んでいるううちに、どうもポインタは、メモリの番地と変数を関連づけて考えた方が
良いように思えてきました。
すみません、自信がないので、再度基礎復習させてください。
http://imgur.com/a/qsZ0r ↑ここに思っていることを書きました。
普通の変数aとポインタ変数hogeを宣言して、1〜6のように代入や読み出しを
したときの理解は、これで合っているでしょうか?
どうしても値のbit幅に自信がないので、全部chqr(8bit)の図です。
宜しくお願いします。
基本的には合ってるよ
俺が落としてきたのはH8/3048グループマニュアルってやつだけど、
15.1.4あたりに書いてある
A/DデータレジスタAH
ってやつだと思う、機種は違うかもしれんが…。
>>427 のリストは多分それにアクセスするためのファイルだと思う。
(メモリ領域にマッピングされた)内蔵A/D変換器のレジスタのアドレスで
機種固有の番号だから省略するわけには行かないんだよ。
つーか例文が悪すぎたな。
>>439 1.ここではマクロの置き換えをやっているんで カッコはとらないのが吉
たとえば
AD.ADCRS.BIT.ADF
てのを
*(volatile struct st_ad *)0xFFFFE0.ADCRS.BIT.ADF
って展開したら たぶんこれはエラーになる
2.はい
3.変数名ではなく型名ですね
4.はい
>>451 >>450 ,452 http://imgur.com/a/vuEhP 後で読みにくくなるから#defineすることをすすめる
あと、レジスタに |= を使うと問題がある場合がある
だいたいそれでいいんじゃないの？
>>453 unsigned char *hoge;
してポインタ変数を定義したとき
＞コンパイラが都合の良い番地に決られめてしまうので、
ではなくて なにもしてくれないので 最初は
意味のない値が入っている うっかりそれで
*hoge = 'c'; などとやったら
どこの番地に 'c' が書き込まれるかわからないので
大変危険 だから何らかの形で初期化が必要
マイコンの場合は仰せのとおり特定の番地に機能がアサイン
されているものが多いから 直接ポインタ変数に番地を表わす
整数を書き込んでしまう実装が多いかも
（その整数と実際の番地との対応も環境依存だけどねとかいいかけると
ややこしいので省略）
＞それも面倒なので、
＞(*(volatile struct st_ad *)0xFFFFE0)
＞のように、番地の数字をここで一気に書き込む
というよりは hogeにあたる変数を定義する必要がなくなる
からちょっとでもメモリ節約できるじゃん ぐらいのことかと
I/Oレジスタのdefineを読み解くってポインタといえばポインタだけど
>>458 LCDライブラリの自作がポインタ学習には合うと思う
話の流れからははずれるけど、I/Oレジスタのアクセスには
>>460 ポート叩くだけなのに、いちいち関数呼ぶとか非効率だよね。
変数だと思うか通信だと思うか というのはあるかも
機械語レベルでは、メモリマップI/Oと専用空間I/Oの争いがあったね
ちなみに
>>460 のOutByteは↓みたいなのだと思う
#define OutByte(port_address, value) \
(*((volatile unsigned char *)port_address) = value)
まあ、inline & template 関数にしたほうが今風なのかもしれんけど
>>465 LED |= 0x01
はマシン語１命令でも正しく動かない場合があるから気を付けて
>>467 プロとアマでは目的が全く異なるからね
趣味：ヒマつぶし・・・時間が掛かることに問題は無い
仕事：金儲け・・・可能な限り短時間で納品する
>>468 だからこそ、明確にI/Oアクセスを示す OutByte()みたいな
記述のほうがいい、って主張にもつながってくる
もっとも、最近のCPUの内蔵のI/Oレジスタに限ったら
たいていはRead/Write可能になってるかも
思い出した、AVRは入力ポートに1を書き込むと出力ポートが反転するという変態っぷりｗ
>>469 学生の頃はそう思ってたけど、働き出したら趣味の時間捻出の大変さを痛感した。
仕事はクオリティと時間のバランスが大事だけど、
趣味は時間最優先になった
#define CK0 ( 1<<3 )
>>471 動作内容から言えば変更するとしたら、たとえば「TGL PORTB,0」だけど
アセンブラ（逆アセンブラも）を変更したくなかったからかな？
メーカーからレジスタ関連のヘッダが用意されてるな一番下の層は素直にそれを使うのがいい
>>470 LED |= 0x01
がダメな例はread/write以外にも色々とあるんだけど
readとwriteの意味が異なる場合 (writeは出力のラッチの値、readはポートの電位 とか)
レジスタへの書き込み命令が制限されてる場合 (スペックシートに記載される)
|= が1命令ではなく、複数のタスクや割り込みから同じレジスタを書く場合
こういう面倒な心配をしなくて済むように、リッチなマイコンだと、
ポートセットレジスタ
ポートクリアレジスタ
ポート反転レジスタ
ポートのラッチ値取得/設定レジスタ
ポートの電位取得レジスタ
に別れてたりする
>>479 セットとリセットは、排他的だから一個でいいんじゃない？
>>479 具体的にメーカーか型番を書かないと説得力ゼロ
横からだけど、AVRmega168のポートBのビット0について書けば 初めて反転レジスタを見た時は、ちょっとびっくりした。
>>480 >>481 まあそのうち目にすることもあるかもね
そんなにマイナーなマイコンでもないから
>>479 リッチと言うか、速度重視の為だけどな。
>>486 普通に1bitだけ値を変えようとすると、リード・モディファイ・ライトとなり、メモリーアクセスが増える。
ハード的に1bit だけ変えられるようにすれば、ライトだけでよくなる。
>>487 でも書き込む値はどのように知るの?
特定bit「だけ」書き込めるならいいけど、
8bit単位で書き込むなら、他のbitを壊さないように、
・読んで
・変更して
・それを書く
となるんじゃないの?
そういうのは例えば1を書いたビットだけ操作する仕組みになってるから、読み出す必要なんてない
>>482 の各命令は1ビットだけ入出力している。
もちろんmega168にもポート(8bit)単位の入出力命令もある。
質問させてください。
沢山ぶら下げたら、むしろCSを追加しなくていいI2Cの方が楽だろ
RS485も忘れないで。
>>492 >＞I2Cが流行っています
>そのソースは？
自分です。I2CのA/D, D/A, LCD, I/O拡張IC、EEPROM, EERAM, PGAなど
トラ技の記事で、8pin ARMマイコンのときも、周辺拡張にはI2Cでしたし。
>>493 >沢山ぶら下げたら、むしろCSを追加しなくていいI2Cの方が楽だろ
確かに、それはありますね。
でもアドレスが3bitくらいしかないですよね。少ないのになると、1bitだったり。
>>496 >I2Cが何の略か調べてから再質問
Inter Integrated Circuit ではなかったでしょうか。
>>495 周辺デバイスとの接続にRS485とは豪快だなｗ
「周辺デバイス」を見落としていた、テヘペロ。
でも屋上に置いたJJY受信モジュール(aitendo GE11-670-JJY)の信号を
1階のtiny2313に入力するとき(接続ケーブル長20mほど)RS485を使った。
JJYモジュールを周辺デバイスと見なして、こんな例で豪快、どうかい、そうかいｗ
>>497 ＞自分です。I2CのA/D, D/A, LCD, I/O拡張IC、EEPROM, EERAM, PGAなど
自分だど言い切る馬鹿さ加減はあっぱれだが、すべてISP版もあるね
確認してみた？
I2C だとマルチマスターやりやすい。
>>491 クロックとデータ信号だけで繋げられる。
あとはI2Cの規格書をじっくり読んでみれば、なるほどねと思うだろう。
では、両方の長所短所を簡潔にまとめてください。
･･･っていうか、デバイス（ＩＣ）によってI2CとSPIと選べないことが
>>505 あなたが無能なことの言い訳は結構ですよ。
日記にでも殴り書きしといてください。
では、気を取り直して、大先生どぞ。
I2C
俺はI2Cが好きかな
調歩同期式の半二重なら信号線一本でやりとり出来る。
SPIでも、I2Sでもなんでもいいけどプログラムから、
I2Cはデバッグが面倒
>>514 特定番地にアクセスしたら、ハードでSPIやらI2Cで通信してくれるマイコンってことだよな
アクセス速度が違い過ぎじゃないか？
１命令に時間がかかりすぎて割り込み遅延とかすごいことになりそうだ
>>517 メモリのスピードが間に合わないって話じゃなくて、
メモリのアクセスに時間がかかるという話ですよ。
間に FPGA でもはさめばできるだろうけど、
>FPGA でもはさめば
>>513 32bit クラスのマイコンなら、大抵のは、SPI フラッシユをメモリー空間に割り当てられる。
大抵は4bit接続できるから、速度もそこそこ出る。
AD変換の結果が正しく取れず苦戦しとります。（若干低めに出る） http://akizukidenshi.com/catalog/g/gM-10172/ 変換クロックが速すぎる
>>525 キャリブレーションやってないのはありうるな
教えてください。ＩＯバスが無い小さいマイコン（ＰＩＣ，ＡＶＲ，ＡＲＭ）をＺ８０に置き換える場合、
>>525 ,526
レスありがとう。
キャリブレーションはサンプルの丸パクリだけどやってたよ。
変換速度は何も考えずに一番速くなってた。遅い側に変えたら何でか
起動できなくなったので、もうちょい見直してきます。
ありがとう！
>>527 ん？
Z80→PIC,AVR,ARM... じやなくて
Z80に置き換えたいの？
>>Z80→PIC,AVR,ARM... じやなくて
すいません。前レス読むと
>>513 氏 が似たような質問してますが、当方あくまでZ80用の 8Bitバスで 入力、出力したいんです。
従ってSPI,I2Sは無し。マイコンを 8BitバスにつないでZ80からI/Oデバイスかメモリとして扱えるかが知りたいんです。
４MHｚのZ80 から読み書き要求が来て、即座にGPIOを入力、出力に切り替えて間に合うかどうか？
>>534 消費電力、発熱ついでにコストを考えると CORTEX-M3 または M0 が対象になります。
間に合うのいっぱいあるから好きなの選んで。ていうかデータシート読みなさいよ
マイコン側からZ80にウェイトをかけて待たせれば良いのでは？
＞Ｚ８０を最近のマイコン(バス無し)に置き換え
と言っていながら
＞４MHｚのZ80 から読み書き要求が来て
とかわけ分かんないな。
質問者がもう少し頭の中を整理しないと。
>>536 が言うようにZ80の周辺としてワンチップマイコンを使うという
ことなのかな？
そうだとしたらワンチップマイコンはバス接続のI/Oには向いてない。
バスってEMIFのことか
向いてないけど出来ないとは誰も言ってないんだがな。
古い機械がZ80系で動いていて、なんらかの致命的な不具合の予兆が出ている。
説明不足ですみません。
>>538 じつは 35年以上前のアナログシンセ(Prophet600)にZ80が使われているのですが、Z80の処理速度の限界から不満があります。
これをフランス人がZ80をソケットから外してAVRに置き換えて成功させています。
どうやってバスにアクセスしてるか疑問に思って質問しました。 もちろんバスには入出力どちらもアクセスします。
http://www.d1.dion.ne.jp/ ~ohk/p600/Prophet600FirmwareUpgrade_ja_beta_1_0.pdf
これと似たような事を、ハンダ吸い取りや基板改造無しということを大前提でやろうとした場合、そのシンセは日本ではZ80はハンダ直付けになっていて外せません。
でケーブルで伸びてるバスラインでZ80と接続してコプロセッサ的な位置づけで、マイコンを取り付けたいと妄想してます。
Z80から引数出力→マイコンが計算して返す という流れ。 Z80のROMはソケット挿しなのでZ80側のソフトは書換え可能。
>>537 基板上でWAITのピンが５Vに直結されているので WAIT信号は使えません(基板には手を加えないのが前提)。
バスはバス。力業でバスを実現なんて珍しいことじゃない。組み込み屋としては、
（
>>543 の能力の問題として）Z80のソフト変更ができるって言うんだから
しらんがな、好きにしろ
だが、要はTeensyの話だろうからシンセ修理スレなら反応あるんじゃないか？
>>543 AVRでZ80バスをアクセスする方法は考えられないのに
Z80と接続してコプロセッサとして使うのができるのか疑問
「ハンダ直付けになっていて外せません」ってことだけが障害なら
「外せません」なんてこと言ってないで外してソケットつけるのが一番近道
Z80の足切ってからやれば、パターンはがす心配も少ない
あと、Z80にDMARQだったかBUSREQかければバスから切り離せるから
取り外さなくてもバスを乗っ取れる
バスラインに出てるのか分からないけど、仮に基板上で５Vに直結とか
なってても、Z80のピンを基板から切り離してGNDに直接ジャンパする
くらいでできる
再販価格のためオリジナルに手を入れずROMソケにサブボードを載せる形状にしたい、って読んだ
＞何か別なモノに切り替えたいけど知識が無い。
＞ゲタかませるように上位チップで制御、プログラム変更、と言うかたちにできないか？
＞そんなことを言ってるような気がする。
ここらへんは合ってたなｗ
Pro5に比べればやっすいんだからピンの足ビシバシ切って、
>>546 みたいにズバっとヤればいいんじゃね？
Intel487というコプロセッサの実態はCPUを内蔵していて制御をそっくり
>>549 そういう感じにするには、Z80のほうがそれに対応してなきゃ難しい
まあ、横からバスに流れるインストラクション監視してて
しかるべきときにDMAかけてバスを横取りして･･･って方法も
可能かもしれんけど、ソフトレベルのことを考えるとハードル高い
543の考えてるのは、Z80の時代にあった（名前思い出せないけど）
I/Oに接続するタイプの浮動小数点演算プロセッサ（デバイス？）みたいなのかな
>>549 ゴメン！
>>550 の上の方は間違いで、全部乗っ取るんなら
>>546 の書いてる方法でできるね
ただ、システム全部 AVRで動かすことになるんだけど、大丈夫なのかって
話になってくるけど･･･
>>546 確かに基板をいじるのは何とかできそうですが、基板のパターンカット、ジャンパ、ハンダ付け等は絶対しないのが大前提です。
>>547 >> バスが繋がってる範囲の操作ならやろうとしてること自体は実現可能だから、がんがって
Z80からIn またはOut 命令が来たと言う信号はコネクタから取り出せます。 その信号に応じて バスにつないだマイコン側のGPIOを
デフォルト「入力」にしといて、Z80からOUT命令が来たらそのまま読み込み、ＩN命令なら速攻でGPIOを「出力」に切り替えてZ80にデータを渡す。
みたいにできないかなと考えています。 これがうまくできるか心配で質問しました。
>>550 >>543 の考えてるのは、Z80の時代にあった（名前思い出せないけど）
>>I/Oに接続するタイプの浮動小数点演算プロセッサ（デバイス？）みたいなのかな
AMD社のAm9511 は私も知ってはいます。 これは扱いが複雑そうですが、私はZ80が出すOUT命令の番号に応じてデータを送る、ＩＮ命令が来たら受け取る、これだけです。
但し、IN,OUT とも 8BIT超のデータになるのでデータは連続で2BYTE以上を連続してバスに送り出す必要がありますのでうまくできるか疑問です。
>>553 メモリかI/Oの空間に空きがあるなら難しく考える必要はないんじゃない？
>>553 Z80からメモリーかI/Oとしてアクセスするにはアドレスデコーダなど
のロジックが必要。
それを標準ロジックI/Cで作るくらいならFPGAでアドレスデコーダも
追加処理する部分も作った方が簡単。
必要ならFPGAにマイコンも入れられる。
>>553 いきなりバス上のI/OデバイスとしてスレーブCPUを接続するって方向じゃなくて
バスには8255とかZ80PIOをつけて、それを通してスレーブCPUを接続するところから
考えたほうが近道では？
バスを叩いて職質受け逃走したってニュースを見てこのスレを思い出した
>>553 目的
IORQ、やRD,WR信号やアドレスバスのいくつかの信号をマイコンのDI/Oに接続して
Z80のIN、OUT命令に周辺PI/Oとして応答する。wait信号は使用不可
Z80(4MHz)の1クロックのパルス幅は250nSで、その入出力実行時間の詳細は
http://www.yamamo10.jp/yamamoto/comp/Z80/Z80_Timming/index.php の3.3
AVRはDI/Oのビット単位の処理が簡単なのでAVRを使用するとして、
(20MHz、1命令実行時間は50nS、割り込み応答時間は200nS）
たとえばIORQ↓で割り込みをかけて、アドレスバスを調べてCSかどうかを判断し、
WRがアクティブならZ80が出力したデータをAVRが取り込む。
・・・
うーん、ギリギリかなぁ、
ハードの追加（74HC138など）が許されるなら可能だと思う。
実際にCPUボードを仮り組みして実験してみたら？
みなさんレス本当に有り難うございます。
>>559 >>たとえばIORQ↓で割り込みをかけて、アドレスバスを調べてCSかどうかを判断し、
>>WRがアクティブならZ80が出力したデータをAVRが取り込む。
現状アドレスバス、RD,WD,IOREQ,MEMREQ,BUSREQ,BUSAK,WAIT,HALT,M1,RFSH,RESET信号は
Z80の基板から取り出し不可です。
マイコンに送れる信号線は データバス(8Bit)と IO要求信号 3本(IN 1本、OUT 2本)だけです。
IO要求信号とは Z80の アドレスバス、RD,WD,IOREQ を基板内のアドレスデコーダ
(正に74138)に突っ込んで生成される信号です。
IN,OUT命令が実行されると 3本のうち1本が Hi->Lo になります。
従ってその 信号線をマイコンに割り込み要因として直結すればいいはずと考えました。
マイコンは AVR ではなく、Cortex-M0 か M3 を想定しています。ARM は数値演算の
ベンチマークだとAVRより数倍高速だから余裕だろ？と考えてたのですが、
単なるＩＯアクセスとか割込処理なんかは AVR と五十歩百歩なのでしょうか？
長いので「Z80＋マイコン」に興味が無い人は読み飛ばして。 >>560 を読んだら書き込みが2ポートあることに気が付いた。 XMEGAは5Vトレラントじゃないからレベル変換だけでも面倒
>>561 有り難う。 AVRのアセンブラわかんないけど（ふいんき的に何かわかる気がする）
>>563 ARMを使う理由のひとつがトレラントの問題です。
一応入力、出力ともトレラントは大丈夫らしいけど、やってみたら思わぬ障害が出やしないか心配。
ここで延々とコミュニケーションを楽しむのが目的じゃなくて
>>565 拡張ボードの販売とかも視野いれてるんじゃないの？
>>561 ARMユーザーやPICユーザーからの解答が無いね
>>565 ICソケットに変えなくてもI/Oポートは作れるのでは？
>>567 I/Oポートは作れるけど、WAIT,BUSRQみたいな信号を入力できるようには
できないよね？
この手の質問でありがちなのは、手軽にできる方法が提案されても
それは全部否定・却下して
実現方法はオレ様の気に入る方法じゃなくちゃダメっていう流れ
まあ、566の書いてるみたいな事情なら分かるけど
>>567 追加するマイコン側の負担がやたら大きそうなのがな。
マイコンからは直接I/O類の読み書き出来ないからZ80にこのポートの値読んでとか
あのポートにこの値を書き込んでと依頼するしか無い。さらにマイコン側からは
要求出来ないから定期的にZ80が依頼無いか確認しなきゃならず、それもマイコン側の
負担になる。
スイッチ類の状態なんかはZ80から定期的送るとか、変化があったら送るとかして
マイコン側のメモリに展開しておいたほうが良さそうだけど、こっちはこっちで
やり取りが煩雑になりそう。
馬鹿だな
>>571 チューニングカー関係のところ行くとかなりあるよ。
実際旧車のチューンんで燃調いじるときにアレが無いと詰む
full ICE は、Z80外せないと無理じゃね？
Z80その他のコントロールバス、アドレスバス、メモリバスを持つCPUシステムを
>>570 Z80外してソケット化すれば
>>543 にあるTeensy++ 2.0 USB Development Board(AT90USB1286)に
載せ替えた改造例もソフトも公開されたのがあるのだから、Z80外して今更ICEで解析とか意味があるの？
そもそもZ80が行ってる作業を拡張ボード側のマイコンにやらせるのが目的なんだから、既にZ80側の
ROM(こっちはソケット挿しなので外せると)からプログラム吸い出して動作の解析は終わってるんじゃないか？
こいつの場合、絶対外さねぇみたいな事書いてあるだろ。
その時点ですべて無駄作業だろ。
CPU外さないでゲタとか頭おかしい。絶対不安定動作しますって言ってるようなもんだろう。
それに
解析されてファームが出ているのはあくまでTeensy++のにおいての話だろ？
それも、Z80を外して、載せ替えた上でのファームウェアだ。
実行コードだけで第三者が解析できるのかよ。
開発元のWebページのダウンロードにあるアーカイブもファームとHowToしかねぇ、ソースがない。
ここな
http://gligli.github.io/p600fw/ 他のもので代行させるためには、やはり一度ICEぶっこんで、現行の動きをエミュレーションして、一からやんねぇとだめだろ。
どうもこいつは
http://prophet-600.blogspot.jp/ の内容を小出しにして書き出して、
CPUに関しては
http://prophet-600.blogspot.jp/2013/07/prophet-600.html が該当するみたいなんだよ。
で、サイトの方針(?)としては、CPUを載せ替えて〜ということになっとる。
無駄、無駄、全部無駄。
やりきるには相当な時間と、そして設備、デバッグ環境が必要だ。
さらに、最初の前提から、
「〜は絶対しないのが大前提です。」
とか言い出してる自体で、上のURLの内容はほぼこのケースでは役に立たなくなる。
日本仕様のProphetの環境用に新しくオコすのなら、
実績のある海外のPropet買って上記URLのまんま行うか、prophet5の中古でも買えばいいんじゃね？
みなさんの話を聞いていたら、バラバラのICでマイコンボードが作ってみたくなりました。
ありがとうございます。
教えてください。
ピン数の問題かな？
>>584 インディアン、ウソつかない。
64bit のPCだって、charとか使うけど？
charが16bitだったり
>>586 なるほど、ありがとうございます。
そうすると、64bitのCPUでint64の変数をアクセスするときは、
その度に8回も8bitのメモリーアクセスするのでしょうか?
64bitCPUで64bitメモリにすれば、int64アクセスが1回で済むと思うんですが。
>>587 僕もそう思います。
もったいないようだけど、on/offのフラグも64bitでアクセスすることもいいと思うのです。
アクセス8回するより、bitを余らせて贅沢に使うほうが高速にできるのではないかと思うのです。
ただし、コストは篦棒(べらぼう)でしょうけど、大量生産が安くしてくれる・・・とか。
ID:p0i6/Ri0
でもかつての68K はレジスタ 32Bit だけどデータバス 16Bit だったから
>>587 68008とか68EC000もあったな。
8088は8ビットとして売ってたんだろうか。16ビット？
CPLDからマイコンに変更しようと思ってるけど、PIC以外にIOポートの電流流すことの出来るマイコンってある？
どのマイコンも
大電流ポートなら10〜20mAぐらい流せるのも少なくない
>>600 H8とか一部のポートをのぞいて数mAだったような。
それからラズパイとかも電流制限は厳しいね
自分は、デバイス保護のためにも、トランジスタぐらいはつけてるな。
>>602 まぁ、それが正しい道なんだろうけど、せっかくワンチップマイコン使ってるのに、と思っちゃうんだよね。
AVRのtiny2313の資料を見ると、出力電流±20mAでVOL＝MAX0.7V、VOH=MIN4.2Vなんだけど、
残念ながらトータルで60mAしかない。
いっそ背中にヒートシンクを貼り付ける？
>H8とか一部のポートをのぞいて数mAだったような。
>>606 1〜9mAかなぁ、想像するの。
数m、十数m、数十m、数百mの、どのレンジかな、くらいざっくりした
マイコンの機種によって、ポートに流せる電流の制限があるのはわかりますが、
>>609 出力ポートに使われているトランジスタ(MOS-FET)のON抵抗の大きさと
内部のチップとピンを接続するボンディングワイヤーなどが制約になっているかな。
後者はおもに、全ピンの合計としてGNDやVCCに流せる電流に関わってきます。
前者は、近年はどんどん改善されてきています。
ON抵抗が小さいトランジスタを作れるようになってきたのでしょうね。
昔は特にPch MOS FETは良いものが作れなかったせいか、
マイコンからの吐き出し電流が、吸い込み電流に比べて極端に少ないものが多かったものです。
LEDを灯すのにVCCに吊ったLEDのカソード側をマイコンにつなぐことが多いのはその名残だと思います。
大電流流せるってことはそれだけオーバーシュート・アンダーシュートするしノイズも出まくるしいいことないんだよ。
FET の キャパシタンスだよ
>>613 >つまり低電流仕様の物程、高速で ON-OFF 出来る
そうなんですか?
ここで論じられているのはICの出力ピンの駆動能力なのですが、
標準ロジックで、高速なものほど出力の駆動能力が低電流になっているような具体例を出せますか?
一般的には、同じ電圧であれば、入力ピンの静電容量を減らし、出力ピンの駆動能力を上げることで、
デバイス間で発生する遅延を小さくしてきましたよ。
入力の静電容量が減ったら駆動電流が増えるわけじゃない
>標準ロジックでってのがよくわからん
ON抵抗が要因と言ったから違うと言ってる
>>618 俺が
>>614 で
>入力ピンの静電容量を減らし、出力ピンの駆動能力を上げることで
と書いたのを
>だいたい入力静電容量減らせば駆動増える
と読まれたのですか?
あー標準ロジックの話じゃないのか
>>620 元の質問が
>>609 であることがわかっていれば、混乱する必要はありませんよ。
軸足は大切です。ブレてしまったときは元に戻りましょう。
元の質問は、
マイコンの出力ポートに流せる電流になぜ大小があるのでしょうか、です。
つまり、
あるマイコンは、IOが-1mAで、VCC-0.5Vになる。
あるマイコンは、IOが-5mAで、VCC-0.5Vになる。
みたいな話ですが、これが、「出力トランジスタのON抵抗が原因」とするのは違うとおっしゃるわけですね?
仮にそれがうんたらかんたらの結果であったとしても、結果的に差が出てているのは出力トランジスタのON抵抗の違いです。
>あるマイコンは、IOが-1mAで、VCC-0.5Vになる。
頭悪すぎｗ
抵抗減らす技術が足引っ張ってるのか？
>>623 何が議論対象か理解しないお前がバカなだけ
半導体屋バックエンドの範疇っぽいけど、知っときたい。
CPUのI/Oに数mAしか流せない時代に比べれば、±20mAも流せるなんて良い時代になったもんだ、
>>625 無知な癖に知ったかして「議論」ｗしたつもりになってるお前が間抜けｗｗｗ
MPLAB X IDEで.lib形式のライブラリをリンクする方法を教えてください
>>630 プロジェクトペインのライブラリを、右クリックで希望のライブラリを登録するのではダメなの？
>>632 それは試しましたがライブラリ内の関数を呼び出してもundefineが帰ってくるのでリンクされてないようです
エラーはコンパイラで出るのかリンカで出るのか識別しよう
PICのCCSCコンパイラで2文字目に「,」が入ってるか確認したいのですが、この書き方ではダメだと言われてしまいます。
>>635 そもそもC言語的にめちゃくちゃ
Cの入門書とか見た方がいいぞ
文字列の比較だから、文字列一個じゃ足りないし、コンマ2つは多すぎ
Cの基本だから
C言語なら俺に聞け 138 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1481372036/ でいいかと。初心者にも優しい
>>635 2文字目が , ってことなら
if (str[1] == ',')
ってやりたいんだろうなとは思うけど
>>637 文字列から一つだけ引き出して比べたかったのですが…。
一つ目は変数を分けるコンマで、二つ目がこれと比べなさいというコンマにしていました
CCSCの紹介でも二つ目の文字列がベタ打ちされてたので…。
>>638 了解しました、次回からはそっちで聞いてみます。
>>639 エラーが消えました…orz
今回の分で言えばstrcmp要らないんじゃぁ…
どうにかなりそうです、ありがとうございました。
>>634 この場合はそもそもリンクされてないのでコンパイラ側からしかエラーはでません
その他試してみたこととしてはプロジェクトのプロパティのxc32-ld項目からライブラリを指定する項目？があったのでそれに.libファイルのパスを指定してみたのですがそちらの場合はリンカーからcannot findが帰ってきます
>>635 1文字比較なら
>>639 のでいんじゃないかな。
strcmp使うなら、strncmp(string[1],",",1)とか？
>>642 string[1]
stringは文字列(もしくはchar*)の配列?
>>643 文字列（バイナリ文字列）だよ。
strcmpと違って\0を終端とみなさず比較する。だから長さ指定がある。
>>644 strncmpの第一、第二引数は char* だよ。
int strncmp(char *s1, char *s2, char len);
>>642 のstringが文字列(バイナリ列でも)ならば、string[1]は、その文字列の2番目のcharそのもの。
だから642の使い方は間違いです。
>>647 ああ、そか。アドレス渡さないとか、&。
とすると、第2引数はそれ用に配列用意しないとです？
>>648 ","
↑これが内部的には 0x2C,0x00 の2文字の配列になっていて、上の例では
strncmpの第二引数に、その配列の先頭番地(つまりchar*)が渡されています。
(文字コードは環境依存はありますが、細かいことは横に置いておいて…0
単に文字を比較したいだけのために、2文字ぶんのエリアが使われるのはもったいないので、
>>642 で書いておられる通り、
>>639 の方法で良いと思います。
マイコンのソフト特有じゃなくて、C言語の話だよな
>>647 標準ライブラリのstrncmpのことならプロトタイプが違う
>>651 今は、
int strncmp(const char * s1, const char * s2, size_t n);
ですね。const はC89から入ったんでしたっけ。
>>644 さん
プロトタイプに違いはあっても、
>>647 の話に変わりはありません。たぶん。
問題になるような違いがあったら、具体的にご指摘ください > みなさん。
2文字目だけの比較ら
>>639 文字列が2文字以上である保証が無いときは1文字目も調べないといけない
>>649 コンパイラやらが、メモリに領域用意して中身入れて、先頭アドレス渡してくれてるんですね。
>>645 奇数番地アクセスでアボートするCPUを思い出した。
複数番地をまたがったアクセスで、アラインメントに制限があるのはごくごく普通
>>657 せっかくだからどうやったかを書いていって
プロジェクトに加えるか、リンカの設定で指定するか
複数の機器と別々に通信がしたいけれど内蔵のシリアル通信モジュールが1チャンネルしか無いので
邪道。
シリアル通信モジュールがのる前は非同期でもタイマを頼りにIOで通信するのが一般的だったし
シリアル通常モジュールが載る前ってのはいつのこと？16550が出る前？
邪道も何も必要な機能(仕様)なら実装するだけの話。
必要な機能の乗ったマイコン持ってくりゃいいじゃない。
>>666 それは明らかにマイコン選択ミスだろ。
趣味ならいいけど。
>>666 安いATmegaにUSB1.0喋らすの流行った時期を思い出した
皆さんありがとうございます
2チャンネルUARTとAVRのレスを読んで、
昔買った秋月のAKI-RS232Cラインモニターキットを思い出した。
http://akizukidenshi.com/catalog/g/gK-00045/ いまいち使い勝手が悪いので、
2チャンネルUART＋バッファ(SRAM)の多いAVR機種(mega1284など)で作り直して欲しい。
>>663 8085AのSID/SODのことだよな。
>>672 作り直したんじゃなくて、作り直して欲しいのかい。
他力本願なやつ
シリアルIOなんて何クロックかに1回動くだけなんだから、
通信ビットレートの16倍で監視する必要があるので、
>>675 何クロックかに一回動くなんて、もの凄く早いシリアル通信だな。
>>676 >通信ビットレートの16倍で監視する必要がある
受信データの立下り（スタートビットの頭）で割り込みかけるように
してやれば、常時監視する必要はない
その後の処理は、ビット幅ないしその半分の時間ごとに
タイマ割り込みかポーリングで受信データ（ビット）を取り込めばいい
ぶっちゃけPC使うラインモニタなら、USB-シリアル2個挿してすべてPC側でやればいいだけ。
演算や履歴によるトリガ条件でサンプリングの開始・停止などをやるなら、
みえちゃんは便利だったな。
数バイト程度なら前後はあるかもしれんが、送受信の関係くらい判別できる。
>>683 >送受信の関係くらい判別できる。
判別できるのは通信内容がわかってるからだよな。
受信時刻を取得して、なんて話はやめてね。
>>687 >だろ。
別ポートなんて大前提じゃないのかな? だって、
>>679 も「USB-シリアル2個挿して」って書いてるよ。読んだ?
一つのプログラムで一つのポートしか扱えないと思ってる？
実際に出来るしやったこともある。
>さほどのずれもなく監視できる。
完全に全二重でお互いが勝手にデータを投げ合ってる状況なんざそうそうあるもんでない。
俺が最初に使ったラインモニタはデータ間の時間(mS)も表示してくれて便利だった。
後で思い出したのだが、三菱重工の機械でACK、NAK、EOTなどの制御コードを
>>698 たぶん僕もそれを使っていた。LINE-EYEでしょ?
メンブレンのスイッチシートが破れてきた。今でも使ってる。
相手と自分のデータの整合不良には「審判」になってくれて、
何度も助かってる。
>>697 \3K以下か、誰かがお商売で作るのだとすると、なかなか普通じゃ難しいな。
ちょっと違うけれど、ロジアナソフトのSIGROKが面白そう。
あんな感じで、「標準化されて割と存在するハード」＋「フリーソフト」みたいなのだったら実現できるのかな。
SIGROKってなんだろうと思ったらPulseViewのことだなw
組み込み仕事を10年ぶりぐらいにまた始めようと思うのだけどついていけると思いますか？
>>701 Arduinoやmbedで創業とかうじゃうじゃ生えてるよね
>>701 組み込みって言っても豆粒みたいなマイコンから組み込みwindowsまでいろいろだからなあ
>>701 仕様(機能と価格と納期)を満足できるならやっていけると思うよ。
世間にはブラック案件も結構あるようだから気を付けて〜
そうだね、さすがに「ラスパイ使って１週間でやれ！」みたいなのは
10年前だったら絶対無理だった機能・価格・納期でも
ロータリーエンコーダーのプログラムについて質問です。
A相の↑の時、を変化割込で検出してるなら↓でも判定が動いてるかも
A相の↑で正逆判断＆カウントするんだから
↑でカウントアップ
ありがとうございます。
モーターとエンコーダーの間のギヤが振動していたこともあります
昔、
アホなプログラマでなければ「不規則に不定期に」でソフトが原因でないことが分る。
>>717 不規則に不定期に発生するソフトのバグを知らないと
ソフトにバグがあるなら、バグのある部分を実行すると100%の確率で異常になる。
実行しなければ異常になる確率は0％。
ソフトにバグがあるけど、実行する、しないにかかわらず、
「不規則に不定期に」異常になるなら、そのCPUは壊れている。
＊異常な状態が無視できるレベルか致命的なレベルか、
回復処理が可能か、などは別問題
＊ノイズなどで誤動作するのはソフトのバグではない。
と思うけどどうでしょうか、単に定義の問題かもしれないけど？
>>719 719 じゃないけど。
タイマー割込と邪心割込がダブった時とか、
複合要因だと再現しにくいよね。
>>720 >そのCPUは壊れている。
素人丸出しだな。
z80上位互換
>>720 他の条件で書き換わるメモリ値とか、初期化を忘れていてある値のときに発動する問題とか
A.ソフトが原因で不規則に不定期に異常になるように見える、と
PIC 12F683でタイマー0とタイマー1を使って点滅灯を作っていますが
void main() {
>>733 レスありがとうございます。
試しに、タイマー0での割り込みでは何もしないで、
タイマー1の割り込みでGPIO.B0 = ~GPIO.B0;だけを書いて
オシロで見たところパルス幅200msのパルスが確認できたので
タイマー1の200msでの割り込みは出来ていると思います。
>>735 間違えた
>>736 関係ない処理の依存性をわざわざ増やさなくても
例えば、点滅の期間を205msにしてとか、キーのサンプリングを12ms間隔に変更してっていう要望が来たらどうするの？
led1, led2が1になる期間が10msしかなくて、
フリーランカウンターの使い方を根本的に勉強する。
2つのタイマー割り込みでやる発想自体は何も問題が無いと思う
つぶしが利かないけどね。
どっちかっていうとポーリングの方がつぶしが利かない気がする
PICみたいなおもちゃマイコンならフリーランのポーリングでも良いけど、
大きなシステムになればなるほど無駄なCPUの使用は嫌われる
別にどっちも自由に使えればいいんだけど
>>731 をフリーランにわざわざ変えなきゃいけない理由はない
もしかしたら
>>731 の目的が割り込み処理の練習かもしれないし
タイマーをわざわざ2個も使う必要ないってことだろ。
先読みしすぎだよｗ
目的がわからないのに、勝手に自分の設計思想を押し付けるのはどうかと思うよ
>>736 といい
>>741 といい
目的は
>>731 のデバッグなんだから、
上から目線で自分のチープな設計思想を押し付ける前に
>>731 のコードを見てあげれば？
>>731 PIC18313で同じようなコードで試したけど、ちゃんと点滅しますね
LED 1個、ボタン1個 だけですが
>>736 割り込みルーチンでだらだら仕事するんじゃねえって言ってるだろ
割り込みハンドラではフラグ処理だけしかしちゃいけないという風潮
>>750 次の割り込みまでに終えるなら構わない。
フラグだけクリアして外へ出ても、外で処理が間に合わないなら意味が無い。
つまり、どっちでもいい。
フラグなんてバグの種を増やすのはいやだな。
ステータスレジスタのフラグビットの事だと思ってたんだけど…
CPUの動作の9割は割り込み処理
>>757 10usで割り込むって、めちゃくちゃ頻繁だけど、何の木江のためにそこまで速いのですか?
とあるデバイスの電源制御です
ああ、「帰依」ですか
仕様が変わるたびにASICなんて起こせないし
実際にマイコンだと、タイマー割込は、どのくらいの割込周期で使いますか?
プリスケールの問題をクリアできれば4、5mSが多いかな。
使い道にも依りますからね。
ただの時間カウントなら1msくらいのなるべくキリが良い値
PICの8bitとかだと割り込みハンドラが共通だしマイコン自体も遅いんで、時間カウント用のタイマー割り込みは使わない
最近の人はなんで32.768kHzか知らないんだろうか
イチ
>>772 それを書き連ねることに何の意味が？
世界人類の平和でも願ってるのか？
>>774 PICでTVゲーム作ったから知ってるー。
最近じゃ32.768kHz程ポピュラーじゃなくなっちゃったけど。
>3.579545MHz
>>770 RTCが不要なら32768Hzなんか積まない
>>779 横だが参考になりもうした
あいがとさげもした
そういや、昔の真空管式のカラーテレビの回路図を見て感心したのを
>>783 水平周波数の奇数/2倍
走査線ごとに色信号が半周期ずれるようになっていて
，縦縞のようなものが見えるのを防ぐ効果も
ある．ついでに走査線数も 525なので，フレーム間でも
位相が反転して相殺されることになる
と言う事らしい
詳しい人解説してあげて
>>785 の通りですがちょっと詳しく。
NTSCカラーシステムは従来のモノクロ放送(受信機)との両立性を第一に考えられています。
これをモノクロ受信機で受けたときに色副搬送波の周波数の輝度信号に対する影響を最小限にするために水平周波数に同期して1ライン毎に位相が反転するように
色副搬送周波数=(水平走査周波数の半分)×奇数(455)
としています。
こうすると輝度信号上に現れる色副搬送波、点々に見える、が上下の2走査線毎で半周期分ずれて視覚的に平均化されて粒状感が軽減される事。
さらに垂直走査期間、フレーム毎に同一走査線の色副搬送波は反転するのでさらに影響が軽減されるのです。
上で何故に455という疑問に。
ひとつは色副搬送波を映像搬送波よりできるだけ高くして影響を少なくしたいという事。
ひとつは複合映像信号としての帯域をモノクロと同じにするためには色副搬送波は無闇に高くは出来ない事。
これらの要求の妥協点が455です。
これは453または457でも良かったのですが、回路設計の点から比較的簡単な素数の積(5×7×13)で455が選ばれたそうです。
このほか色空間の事や音声、同期、さらには残留側波帯という電波形式等々アナログテレビ放送は先達の英知そのものという気がします。
そういや昔々大学のテレビ関係の講義でクロスカラーとかドット妨害とか言ってたけど、どっちが色→映でどっちが映→色だったんだか覚えてないや。
https://goo.gl/MFkghn これ本当だったら、普通にショックじゃない？？
>>787 信号の振幅方向と位相方向とを使って、２次元的に情報乗せる技術は現役だぞ？
>>786 説明ありがとうございます。
NTSCは、まずは白黒放送があって、後にカラー放送が出てきたので、
カラーのフォーマットは、白黒との互換性という点に重きを置いて設計、
大変苦労したと聞いたことがあります。確かに英知の結集ですね。
一方で、非NTSC系のPALやSECAMなどのカラー放送も、同様に考え尽くされた方式なのでしょうか?
>>757 Windows OSも、割り込みばかりで動いていると聞いたことがあります。
アプリ1個起動中なら、1→1→1→1→.....
さらにアプリ1個起動されたら、1→2→1→2→.....
さらにアプリ1個起動されたら、1→2→3→1→2→3.....
さらにアプリ1個起動されたら、1→2→3→4→1→2→3→4.....
処理がドンドン遅くなっていく
>>791 Windowsの割り込み処理率は非常に小さい
アプリは基本的には全てスレッドで処理を行う
>>794 スレッドの切り替えはタイマー割り込みで実装されているのではなくて?
>>795 切り替え処理のトリガーは割り込みだけど、アプリの処理のほとんどはスレッド
>>757 はCPUの使用率の9割が割り込み処理
全然違う話
割り込みとOSの話を「実感」したかったら、これ
12ステップで作る組込みOS自作入門
https://www.amazon.co.jp/dp/4877832394 setjmp、longjmp のアイディアだけいただいた。
低機能の8ﾋﾞｯﾄCPUは、
>>799 機能の数だけマイコン使えば良い。
LSI にも、シーケンサーとしてマイコン入ってる物も多い。
>>800 どーだろうね。
ソフトで工夫した方が手軽なんじゃないかな。特に趣味なんかの場合は。
あとはロマン。
>>799 OSレスのほうが省メモリで高速
低機能8bitでプリエンプティブマルチスレッドとか完全な趣味の世界
わざわざ評価工数を増やす
規模が大きくなってくると逆にOSは必須になる
車輪の再開発なんかして遊んでないでさっさと仕事しろって感じ
技術革新を起こす人と、日々の業務をこなす人とでは志向が違ってきますね。
製品に入れるとか他人に強要するとかそういうことが無ければ好きにすればいい
>>799 の過去の発言がどちらかというと強要になっているので
>>807 おー。わかります。
極論を諫める反論もついつい極論に傾きがちなパラドクス。
望ましいバランスをとった反論をすることはなかなか難しいですね。
>>807 >>806 もうひとつ条件を付け加えるなら
いっとき勢い持った組織に自分の組織が潰されなければね、でしょうか。
>>809 強要は言い過ぎた
勧めるべきじゃない情況(ほとんどがそう)だろうが関係なく勧める
初心者が真に受けると危険
>>811 「初心者が真に受けると危険」って、私のプログラムは新興宗教か？（笑）、
初心者向けで無いことは認める。しかしここは初心者限定ではないでしょ？
それにたとえ初心者でもチャレンジする事は大事だし、
今理解できなくても記憶の片隅にでも残れば、将来役に立つことがあるかもしれない。
たとえばスタックを入れ替えるとどうなる？
割込み処理ルーチンの先頭に割込み禁止命令がある意味は？
など。
CPUの種類によって個々の命令は変わってくるし、リストを細かく書いてもしょうがないから、
準備部分のリスト（スタック領域のプリセットやタイマ起動など）は省略したけど分る人は分るよね？
（つうか分らない人はどんなに詳しく説明しても分らない？）
ほとんどのAVRはこれかこの応用でいける。PIC24でやったことは無いけど多分適用できると思う。
ついついマジメぶってしょうも無い事をエラそうに書いてしまった、
イラッとした皆々様、申訳ありません、これにて本日の打ち止めぇ〜、チョンチョン
割り込み処理で割り込み禁止にする意味がわかりません
>>814 多重割り込みはやってはいけない訳ではなく、本当に必要だったらそれなりの対策をして有効にする。
話題のターゲットになるデバイス指定すべきだな。
>>817 逆が多いかと
ISRコール時には割り込み禁止になっていて、禁止を解除することで多重割り込みが有効になる
そうじゃないと、ISRの先頭から割り込み禁止するまでの期間は割り込みが有効になってしまう
そういうマイコンが本当に存在する？
>>819 マルチレベルの割り込みって書いてるだろ。
明示的に割り込み禁止しなければ下位割り込み中でも上位割り込みは実行される。
いくらでも存在するわ。
RL78のユーザーズマニュアル
割り込みレベルがあるMPUなら一般的には
>>820 が正しいな。
RL78とかは単純処理向けだからなあ。OSレスが前提だろう。
「たとえば？」で出てきた一個目がいきなり違うっていう
一時的にとは言え下位割り込みが上位割り込みを必ずマスクするのはちょっと…
割り込み確定からISRの先頭までは、どんなマイコンでも他の割り込み処理が割り込めないけど
AVRもISRの先頭では割り込み禁止状態
https://www.clarestudio.org/elec/avr/mcu-interrupt.html ルネサスのドキュメントにも
「ただし一般に、割り込み要求を受け付けるとDI(Disable Interrupt)状態となるため、ネスティングを許可するにはEI(Enable Interrupt)命令を実行する必要があります。」
そうじゃない例は？
そうじゃないのが一般的だという根拠は？
MIPSもISR先頭で特定のレジスタを使うのが当たり前だから、どの実装でも割り込みが禁止になっているはず
まあ別にISRの初期状態がどうであれ、
>>814 の回答は変わらないけど
話がごちゃごちゃになってるんじゃないか。
>>814 >>799 に「ソフトウェア割込み」と書いてあるから
>>809 のタイマ割込み処理の先頭の割込み禁止命令はソフトウェア割込み用で
tiny2313のプログラマが任意のタイミングでコールしてタスクを切り替える、ということだと思う
だからタイマ割込みではCLI命令の次から実行すれば良いはずだけど
この割込み処理の作者はラベルを書いていないのでその辺が不明確
いずれにしろ割込み許可命令では無くて割込み禁止命令を実行しているので
多重割込み処理は無関係では？
（追加）
>>834 2) の話
そのままで割り込みが有効なのが一般的か、そうじゃないのが一般的か
>>814 は単独の質問だと思ったのだけと、
>>809 に対してだったのかな？
それだったらコメントの通り、ISR内で再度割り込みがかからないように(多重割り込みが発生しないように)禁止してるだけかと
久しぶりにマイコンを使用した開発をしてみようと思うのですが10年以上ブランクが空いているので浦島太郎状態でハードウェアの選定をから悩んでいます
通信＋簡単な処理ならRL78で性能的には十分
Arduinoは物足りなくなったら抽象化のゴム外して生のATMELと組んず解れつできるよ
62Nで遊んでみようってレベルならArduinoとかは選択肢に入らないような気がする
信頼性もサポートも、ATMELよりはルネサスの方が良いと思う
>>845 特に面白くもないのにいちいち下ネタに走る奴何なのって思わん？
普通に書けやって思う
下ネタ？
レスありがとうございます >>840 >>841 >>849 なんでわざわざ非純正のツールを使う必要があるんだ？
純正の開発環境でそのままでアセンブラとCの混合開発は出来るよ
>>849 だけ見るとRL78でもオーバースペックに見えちゃったりするんですが、GPIOで高速通信をしたりするんですか？
UARTx3って希望だとRL78がオーバースペックとは思えないがな。
>>850 純正評価版
野良情報が少ない。Renesasの技術サポートも得られないためトラブった時にお手上げになる可能性がある
今回の件はともかく先々(RX600とか)のことを考えると容量制限に引っかかる可能性も低くない
オープンソース系
野良情報が多い。コーディングやツールの使い方に関する情報は豊富。容量制限などは存在しない
ただし純正デバッガと連携が課題
一長一短ではあります
>>851-852 44ピンとかだとRL78でもSCIが3本あるようですね。処理能力的にはRL78で足りると思います
スイッチやボリュームの数が増えて時分割で入力装置を読み出すようになったとしてもいけるはず
>>853 既存機器への組み込みとはいえ今回は比較的余裕があるので実装面積の拡大はある程度許容できます
UARTでリモートデバッグしようとしてたり、時分割やろうとしたり、
>>854 ちょっといろいろと考え過ぎだと思うがなあ。
オープンソースでもサポートないのは同じだし、環境作るだけで力尽きてしまうぞ。
まだ純正ツール評価版のほうが、かふぇルネで回答がもらえる可能性がありそう。
容量も、リンカのジャンプテーブルの出力オプションで、ちょっと面倒だが解決できる。
評価版ユーザーは、これで頑張れといわんばかり。
でもそんなに容量いるの？
>>854 ツール自体は特にサポートが無くても問題があるような感じはしないけど
インストールも簡単だし、操作方法も普通
容量制限は、無料のを使うなら付いて回るとは思うけど...
ていうか、無料のを使う発想が無かった
コードサイズ64KBに
UART 3系統、
I2C 2系統、
リモコン受信、
キースキャン、
ブートローダー、
その他いろいろな低速の制御
を入れて量産してるけど
>>855 UARTでデバッグは年配なのか...
若い人はリアルタイム動作が必要なマイコンのデバッグはどうやるの？
e2studioとRXGCCでエエやん、無料だし制限ないし
今どきUARTでのリモートデバッグなんて、Arduino使ってるアマチュアくらいだと思ってたんですが、
まだまだ仕事でも使われてるんですかね？
正直、
>>839 さんの用途にわざわざそんな環境作り込む必要性は感じなかったので、
我流が染みついた職人級の人かと勝手に想像しただけです。
私もそれ系なんですけど、ICE安いですからリモートデバッグなんてこの10年近くやってないもので。
話の途中ですが、質問教えてください。
私の定義や解釈が他の方と異なっているかもしれませんが、私の言う「リモートデバッグ」とは、
>>861 「Arudinoのシリアルモニタそのもの」はちょっとというか
全然違うのでは？
>>862 私は同じと言って差し支えないと思います。
デバイス側でPCからの要求を受けて内部を操作したり情報を返したりする。
あるいはプログラムに従って情報を自動的に垂れ流す。
Arduinoでも普通に行われていることではないですか？
デバッガのメモリダンプやウォッチリストによる監視とシリアルコンソールの外付けによる監視はお互いに補完する関係にあり
どちらかで代替できる物ではないと思うのですが、最近はデバッガが吸い上げた情報をプログラマブルに整形して可視化できるような
ツールがあるのだろうか・・・
>>856 なるほど、リンク容量の制限はお茶を濁す方法があるのですね
RL78はともかくRXだと書くコード自体は少なくても既成のライブラリを使ったり、計算用のテーブルやフォントなどをリンクしたら容量制限の突破は
十分にあり得ると見積もっていました
>>857 自分で書いたプログラムだけだったら64KBもあればほぼ足りると思います
>>858 >e2studio
そんな物があったのか。GNUベースのツールが使えるのであればRXもRL78もgcc/as/ldで開発できますよね
RX62Nは秋月で売っている奴です。確かNICとLCDを使った物を作るつもりだったのですが開発環境の構築とネットワーク関係の実装に頭を抱えて
棚上げになっています
LEDをチカチカくらいならともかくCとの連携は全く判らないのでCで開発するなら勉強しないといけないところです
情報の後出しが多くて
UARTでデバッグってよくやったな。
今もやるでしょ？
JTAGデバッグを初めて見た時革命が起こったかと思ったよ。w
RX 用の GCC なんてあるの？と思って調べてみたら、
なんで自分で作らずに口を開けて待ってるんだかｗｗｗ
>>866 ＜CPU側にデバッグ用ハードを内蔵させておいて
クロックと双方向データ線の半2重同期式通信でデバッグ情報を外部とやり取りする＞
というのは、昔、UART＋リモートデバッガでやっていた頃と基本的に原理は同じだと思う。
(AVRのPDIの話ね）
AVRの純正デバッガもルネサスがエミュレータと呼ぶものも
デバッガの機能とデバッグ用コードは基本的には用途は別でしょ
「デバッグ」と言う用途は変わらないと私は思いますが、
同じ事にしたい理由がわからない
同じ事にするとなにか良いことがある？
デバッガは汎用的なことしか出来ない
>>873 の機能はコードを書かないと
デバッグなんて基本的には皆同じ
電子回路なんて基本的には皆同じ
人生なんて基本的には皆同じ
こんな主張がなにか役立つ？
確かにRXはオーバースペックだと思いますが、マイコンボードの値段を考えるとあまり差がなさそうですね
秋月のAE-RX210が2千円程度。RL78のボードはがじぇるねやマルツで売っているけど同程度
消費電力や基板サイズの制約はないので大は小を兼ねそうな気がしますけど何か落とし穴があったりするのかな・・・
>>865 判りにくくなってしまっていてすみません
>フォントとか計算用テーブルとか既成のライブラリとか...
同じ系列のMCUなのにプロジェクトのサイズにとって開発ツールを変更するようなことは出来れば避けたいです
>仕事なのか趣味なのか
現状は趣味です
>GPIOの本数や速度は？
ひとまず最小構成でGPIOは〜20程度、ADCは0〜2程度を考えています
>UARTの接続先、PCとデバッグ用ともう一個は何？
送信×2、受信×1。本来の目的で送信と受信の1セットが必要です。残りの送信はデバッグ用です。UARTを使わずにプログラムからデバッグ用の情報を
転送できてPC側で任意のフォーマットで表示できる方法があるならデバッグ用の1本は不要です
>アセンブラでのコーディングを気にする理由は
Cは不慣れで全く読み書き出来ないと言うほどではないにしろアセンブラと連携してゼロから開発出来るほどの知識はありません
CでコンパイルしたコードをMCU上で実行するには所定の初期化処理が必要らしいとは聴きますがそれを自分で書くことも出来ません
アセンブラによる開発の可能性を否定していないのはこのためです
めんどくさい奴だな
>>876 趣味ならオーバースペックは全く問題ないと思うのでRXでもRL78でもやりたい方で
UARTに関しては、
送信2ch, 受信1ch であれば、RL78/G13, RL78/G14, RXシリーズならどれでも可能です。
RL78なら一応こんなのもあります。
http://akizukidenshi.com/catalog/g/gM-08844/ アセンブラに関してですが、
アセンブラで開発する時代は終わり
RL78もRXもC言語だけで開発出来ます。
開発速度は圧倒的にC言語の方が速いですし、
気を使うこともアセンブラに対して非常に少ないです。
レジスタの選択も起動時の初期化処理も
割り込み処理や関数処理のprologue, epilogue処理も
コンパイラが勝手に作ってくれます。
コンパイラの能力も上がり、
アセンブラによるフルチューンコーディングとのパフォーマンスの差もずっと縮まりました。
将来マイコンが変わったとしてもC言語は使えますし、
これを機会にアセンブラを一切忘れたフルC言語によるコーディングをお勧めします。
>アセンブラによるフルチューンコーディングとのパフォーマンスの差もずっと縮まりました。
おっ久々の℃玄人登場
>>879 さすが℃玄人
全部アセンブラで書いとけよもう
CS+本体は登録しないとダウンロードできないようなので後回しにして、RX210やCS+、CC-RX関係のドキュメントを落としたので読んでみます
>>878 そのRL78が張り付いている変換基板は確認していますがDIPピッチに変換されているだけでパッケージ単品を買って自分で配線するのと
大差ないような気がします。Xtalとかは別途用意して配線する必要がありますし
>将来マイコンが変わったとしてもC言語は使えます
自分もその方向で準備するつもりですが、これを前提とするならC言語とマイコンや開発環境固有の部分を分離した方が応用が利きませんか？
>レジスタの選択も起動時の初期化処理も
>割り込み処理
この辺はマイコンや開発環境固有の部分でC言語の規格にはない部分ですよね
あとコンパイラやリンカ、アセンブラあたりの知識がないと
>>856 のリンカオプション云々を理解出来ないと思うのですが・・・現時点では
そういうことが出来るらしいという点以外は理解出来ていません
>>884 悩み事を相談したいならポイントを明確に
>>884 CS+は登録しなくてもインストール、無償版範囲で使用できる。
UART程度なら、内蔵オシレータで32MHzで動かせる。
FPハンダ付できる様なので、変換基板に、外付け部品は、RESETに10kPU、REGCに1uFで十分。
＞>アセンブラによるフルチューンコーディングとのパフォーマンスの差もずっと縮まりました
短期間で人件費抑えて開発してすぐ販売のほうがいいよね
ちょうどルネサスの話が出ているところだけどルネサスのサイトでこんなページを見つけてしまった
ENGINEER SCHOOL | ルネサス エレクトロニクス
https://www.renesas.com/ja-jp/support/technical-resources/engineer-school.html 今や半導体屋がこんなページを作らないといけないほど技術者不足なの？
マイコン活用基礎あたりまでは電子工作と無縁の人向けの内容だよね
工業高専や工学系を専攻していた大卒ならこのくらい理解していて
当然の内容じゃないのか
高卒だって趣味で電子工作をやっている人なら基本的に知っている内容だろうし
マイコンの使用経験があればこのくらい当然理解しているはずじゃあ
割り込みとかタイマとかを理解出来ていないとLチカすら出来ないぞ
>>893 今はPCソフト系からマイコン制御ボード系に来る人が多くて、
彼らはハード（回路）に詳しくないからでは？
PLC(シーケンサ）系から来る人はまだマシだと思う。
>>894 その背景はなんだろ。PCアプリ屋ってVisualStudioにどっぷり浸かっているMSのしもべだよね
リッチなライブラリ群が整備されていてマシンリソースは湯水のように使えることが前提の連中だよな
最近の組み込み関係はそういう人でも許容できるくらいに余裕が出来たのか？
連中にマイコンボードと開発環境を与えてLチカを作ってみろと言っても一ヶ月あっても出来上がるか
怪しい気がｗ
ご自分が苦労なさったからといって他人も同じと決めてかからない方がよろしいかと存じます。
>>895 チープなマイコンのプログラムしか作ったことが無い人が
業務でPCのプログラムを作るよりはマシだと思う
>>897 その心は？一般的に難易度は肥大化させるより、高密度化する方が高いでしょ
組み込み屋の方がコードの品質に対する意識は高いだろうし
>>898 もうメモリー容量を気にしてとか
そういう時代じゃない、というかそういう職人技
みたいのが求められているわけじゃない
>>898 高密後化なんて今時小型マイコンのプログラマーでもやってない
まさかアセンブラで開発してるとか思ってる？
大規模なシステムは小規模なプログラムより難易度は高い
当然だが
あと、組み込み屋の方が品質に対する意識が高いなんてことはない
もちろん医療系とか車とかそういう一部の業界はそうだが
大規模プロジェクトは、設計がしっかりしてないと必ず問題が起こる
小型マイコンの小さなプログラムは問題が起こりにくいし、起こったとしても見つかりやすい
メモリ容量はPCでも当然気にするが、それは大きなデータに対してのみ
>>899 今時のPCアプリだったらメモリやCPU、ストレージは使い放題、メモリ保護やタスクやプロセスのディスパッチ
I/OなどはOSまかせが常識だよな。組み込みも同じ感覚で書けるくらいリッチになっていると言うこと？
だとするならワンチップマイコンなんて用なしと言うことか。メモリは多くてもせいぜい100KBくらいしかないし
マルチタスキングをするにしてもノンプリエンプティブな実装がせいぜいだろうし
>>900 大規模な開発で難易度が上がるのは管理であってコーディングじゃないでしょ
この手の話題になるとみんな本当に生き生きとするのな
>>902 大規模なソフトを一度設計してみればわかるよ
>>904 大規模な業務用アプリで大変なのは設計と管理。適切なリソース配分と仕様書の作成
一般的な業務用アプリでプログラマに要求されるスキルは高くないよね
しかもそのような用途だとC/C++じゃなくてJavaなどのGCを持つプラットフォームが
多くないか。メモリ保護どころかメモリ管理すら気にする必要がないね
というかプログラマの話のはずなのに何で上流の話になっているんだ？
そもそもPCソフト屋はハード（回路）が分らないって話だったのに。
> 8ﾋﾞｯﾄCPUを自作のコンパクトな並列処理で駆動する
>>906 もともとはPCアプリ屋から来る人が多いって話だろ。何で設計の話に
なっているんだ。畑違いから来た人がいきなり設計なんて出来るかよ
これはPC→組み込みも、組み込み→PCも関係ないはずだ
で、電気のでの字も知らない人がPCアプリ屋が組み込みに来て
どのくらいで使い物になるのか？
>>908 マルチタスキングのことだろ
ROM32kバイトしかないZ80の時代でも余裕でプリエンプティブマルチタスクあったよ。
いつもの自作OSモドキを強要してる人か
OS無くともマルチタスク処理を行うことはそれなりにあるよな。この人は何を言っているんだ？
>>911 - 912
言いたいことはわからんじゃないが病院行った方がいいよ
>>913 マイコンが複数の処理を行うなんてごくごく普通
１個の処理しか行わないなんて方が珍しい
>>908 のいう「自作のコンパクトな並列処理」ってのはそんなごく普通の処理のことか？
一般的な言葉を使ってくれないと会話にならん
「8ﾋﾞｯﾄCPUを自作のコンパクトな並列処理で駆動する」
まずは
>>907 がこれの意味を説明することから
想像で話してもしょうがない
コマンドの最後に&付けるのがそんなにすごいことだったのか
>>916 やっぱりお前か
やっぱり私だよ。
先日から根拠も前提も示さずに絡んでいるだけの奴がいるよな。学問・理系板になんでそんな奴がいるんだ？
実を言うと、922 がセマフォとかイベントとかデバッガとか言うから、
ん？
勘違いしてるのか？
>>921 の処理にセマフォやイベントが必要と言ってるわけじゃないぞ
マルチでタスクが動くならそういう機能も当然必要だってことを書いただけ
そのうちにｄｓPICでもやってみたいな、と思っています。
まあ当然あるんだろうけど
>>930 君には説明してもムダ。もっと勉強してね。
悪いけどキリが無いからこれで終わりにするよ。
>>931 dsPICなら最低でも80MHzか？
>>933 君からソフトに関して教わることは何も無いと思う
あんまりしつこく書くから君のOSモドキのスペックがどんなもんかちょっと興味を持っただけ
>>933-934 お互いおちついて話せば経験が重なっていない部分で知識を交換できるのに。
相手が持ってる情報・知識を100%自分が持ってると思うのは傲慢ですよ。
え〜と・・・
>>927 「遅すぎる」「速すぎる」どっちの意味だろう？
>>935 OSごっこして遊んでるようなのから学ぶことは何もないよ
そんなのは20年前に卒業
おれが相手をするのは知識を得たいからじゃない
>>939 何を思い上がっているのか知らんが、２ちゃんなんて、昔から嘘と出鱈目の塊だ。
こんな場所の書き込みなんて信じる方がどうかしている。
>>939 ブーメランだな。学問・理系で定量的な話が出来ないあなたもアホです
ここ5年くらいで定量的な話が出ない無い奴がメッチャ増えた感があるな
単一タスクが単一デバイスを扱っている限り排他はいらんだろ。
だけど
>>921 みたいなコードで何したいのかはわからん。
原則オールアセンブラだろうし。
同期も排他制御も出来ないマルチタスク
>>946 こういう事が2、30個の追加命令で実現できるのは便利だと思いませんか？
誰もマルチタスク自体を不要とは言ってないんじゃないかな。便利だよ確かに。
実際には上位PC通信処理、操作パネルのI/O処理 (液晶表示やSW入力や
>>946 過去の書き込みを見てわかった
レジスタのバックアップすらしない、到底(ソフトウェア用語であるとこの)タスクとは呼べない代物か
C言語を使えないOS、自力でレジスタをタスクに割り振らなきゃならないOS、完全なオナニープログラムだな
>>953 それら全ての動作の関連がないなんてあり得ないわけだが
フルアセンブラではレジスタは自分で割り振るんだよ。
別のタスクのレジスタまで意識しなきゃならないマスチタスクwww
だから話のできない奴って言われるんだよ。
何度言わせる気だろう・・・・
返信要らんぞ、終わりなんだろ。
>>933 くらいで終わってもらえればベターだったんだが。
チャタリングのない世界で生きてるような人は放っておこう。
その辺はあまり本質じゃない
このAVRのアセンブラコードにイチャモン付けている人はなんで自分でコードを晒さないの？
有償のもっといいものを使っていたり、フリーならすでに公開されていたり。
>>962 仕事の依頼であればお話を伺いに参ります
過去ログを読めば、オナニー野郎がマイコンソフト初心者に対してマイナスであることがわかるから読んでみな
きっと「昔はすごかった」人なんだろうねぇ、どこの会社にもそういう人いるよ
>>965 他人の話を理解して客観的な会話をする気がないならTwitterかblogでやってくれ
たとえ2chであってもBBSでやるべきではない。そのような行為は荒らし行為である
>>949 解説ありがとう。
osというより、アセンブラで書くときのテクニックなんだね。
ラダー図っぽいことをさせるにはそれなりに便利そう。
>>944 タイミング的にArduinoから流れてきたのかも
「アセンブラが書けなきゃ素人」
>>970 あー確かに。Arduinoかどうかはともかく最近流行の高度に抽象化された
開発環境しか知らない人って感じだな。ローレベルの知識は全然無い？みたいだし
>>973 あの頃からArduino使ってIoTとか言って展示会に参加しだした怪しい企業も出てきた気がする。
さらにラズパイまで出てきてトラ技もラズパイだらけでつまらなくなった
そして最近は部品メーカーが電子部品の使い方をサポートページに載せる始末
電子部品使ったことがない変な客からの問い合わせが来るようになったのかな
>>967 ここやPIC、AVRのスレに張り付いている、少し頭のおかしな人だから相手にしない方がいい
得意技はIDをコロコロしながらの珍妙書き込みで
いよいよ追い詰められると火病の発作を起こして爆発する
人格批判はいいからマイコンソフトに関係有ることを書きなさい
>>979 徹底的に追い詰めリアルで爆発してもらって豚箱に入っていただいた方が平和になりそうな気も
>>978 中二病はっけーんｗｗｗ
（おれ平成生まれだから世紀末とか知らない設定だし~）
並列処理のサンプルが切り替え部、実行部のリストだけで中途半端だし、
アセンブラが判らない奴は三流。デバッグビルドとリリースビルドで動作の不一致が発生したらお手上げだしな
どういう解釈すると「興味ある人も居るかもしれない」になるんだろう。
このスレか。アセンブラできない馬鹿が暴れるんだって？
別にタイムスライスで動かすくらいのことは必要に迫られてやったし、
>>993 今までの書き込みのレベルから、実際に作ったとは思えない
このスレッドは１０００を超えました。
２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/ ▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/denki/1469905691/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「マイコンソフト 悩み事相談室 2 [無断転載禁止]©2ch.net YouTube動画>12本 ->画像>3枚 」 を見た人も見ています：・マイコンソフト 悩み事相談室 シスター紅の悩み事相談室 自営業 悩みごと相談室 47 自営業 悩みごと相談室 51 自営業 悩みごと相談室 46 自営業 悩みごと相談室 41 [けんじの]どすけべエロ画像3[悩み事相談所有り] 【身体】ズバリ解決！名医のお悩み相談室 気づくのが難しい『前立腺がん』 前立腺肥大症との見分け方は？[09/02] ©bbspink.com 無職・だめの為の悩み相談室 ライダーマンのお悩み相談室 吹奏楽部は「ブラック部活」 NHK「クロ現」で議論に[長文先生のお悩み相談室] Part.3 【社会】日本政府が「悩み相談」リンク表示をマイクロソフト社に要請 検索サイトの99％カバーへ…「死にたい」と打ち込むとリンク表示が ダラマンほのぼの相談室 Part33 ダラマン労働相談室 Part34 【トルク】 モーター何でも相談室 【回転数】 (●ο) 静岡・自演ヒキの夏休み 子供相談室 (ο●) 【不本意入学のスクツ】明治大学学生相談室 "進路変更を考えてる人へ"【早慶上理落ち】 NIPお悩み相談室 お悩み相談室開催中 今日子の悩み相談室 〜〜お悩み相談室〜〜 アプローチの悩み相談室 13 drunkerの「悩み相談室」 2017 ★ピクルス王子のお悩み相談室★ ４１３の悩み相談室【1人ずつ順番にな】 08070507787 ★ 真智宇 先生の悩み相談室 08070507787 ★ 真智宇 先生の悩み相談室 【復活】セックスお悩み相談室【できるか？】 【お賽銭不要】 悩み相談室by仏様 第８集会所 【dat落ち不要】 【元セクシー女優】💗松本亜璃紗ちゃんねる／ありちゃん💘【恋のお悩み相談室】 【ズバリ解決 名医のお悩み相談室】リモートワークで頻尿になってしまった…いったいなぜ？ [アルカリ性寝屋川市民★] 【LGBT】自分が女性であることがいや。もし今世、性を男にした場合、来世はどうなるのでしょうか。【ハッピーサイエンスお悩み相談室】 山口龍之介の借金相談室 Part8 【大衆演劇★なんでも相談室 3幕】 【>_<】 二郎相談室 【解決】 コロコロ シーバスなんでも相談室 荒らしはこちら No A012-2 【ジャマイカン恋愛相談室】広告対策 船乗りなんでも相談室・12 C++相談室 part142 シーバスなんでも相談室32 [ﾜｯﾁｮｲ]船乗りなんでも相談室・12 ■コンサル田中の経営相談室。■ 【構成】BTO購入相談室【見積り】■32 初心者優先デジタル一眼質問・購入相談室 122 【ｽｷｰ】中級者以上・ｱｲﾃﾑ相談室【何でも】 Part.2 不登校相談室8 船乗りなんでも相談室・13 船乗りなんでも相談室・11 小堀豊の何でも相談室 船乗りなんでも相談室・16 C++相談室 part135 C++相談室 part138 C++相談室 part144 C++相談室 part143 C++相談室 part147 C++相談室 part134 C++相談室 part137 シーバスなんでも相談室25 シーバスなんでも相談室30 シーバスなんでも相談室24 シーバスなんでも相談室30 シーバスなんでも相談室31 MFC相談室 mfc23d.dll
23:08:46 up 27 days, 12 min, 0 users, load average: 9.15, 9.65, 11.87
in 2.8607468605042 sec
@2.8607468605042@0b7 on 020913
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube![マイコンソフト 悩み事相談室 2 [無断転載禁止]©2ch.net YouTube動画>12本 ->画像>3枚](http://i.gzn.jp/img/2011/06/18/golden_curry_barikara/P1880559.jpg)
![マイコンソフト 悩み事相談室 2 [無断転載禁止]©2ch.net YouTube動画>12本 ->画像>3枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/zW02KiB.jpg)
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
