C.A.Mのブログ一覧

久しぶりにCN360のサイトを眺めてみたら





プロジェクター型出てますね。
これだとハイビームのLEDは縦並びなので、良さそう。


Amazonで探してみると

これがそうみたい。
けっこーいいお値段。

ハイビーム時にローと同時点灯みたいなんですよね。
遠くの方はどうしても暗いので、目が慣れるように手前はあんまり明るくないほうがいいと思うのですが、どうでしょう？

柔道　剣道　茶道　華道　弓道

和の心で進むには"道"の字が欠かせませんが、
僕がやってるのだと、
どーもゴロが悪い👎

てか、意味ちがう。。。。

車道（しゃどう）　ー　通常、車両および路面電車が通行する道路の部分である。

弾道（だんどう）　ー　銃弾や砲弾が発射された瞬間から弾着する瞬間までにたどる経路の事である。

Wikipediaより



んで、
道路が雪だらけで、
せっかく作ってたモーテックミクスチャ補正補助装置の実地試験ができません。

なので、おうちでできること
中断していた
"球体の空気抵抗係数を求める実験"を再開しました。

球体言っても直径6mm
いわゆるBB弾😑


https://m1234567.militaryblog.jp/




BB弾をモデル化して、弾道を推測。
玉には回転がかかっているので、結構難しいんですよ。


射撃ってのは精神集中できるので、好きなんです。

ただし、
おうちでできるのは12mくらいまで。
もっと広い(長い)ところは無いかなぁ🤔

H4バルブがプロジェクタになってる！？


こんな小さいレンズで配光が出るならアリかも。
発光体が小さければレンズは小さくてもいけるのかな？　←妄想です。

マルチリフレクタのヘッドライトならレンズは素通しだから問題なさそうだし。

まだ、これだとハイビーム側がいまいちそうなので、様子見。

考え方としては"やるなぁ"と思います。

現状のまんなか基板式LEDだとどうしても光軸中央が割れるというか暗いので、
こういう新機軸は良いですねぇ。

コールバック関数。
MCCやハーモニーで生成されるコードは
それ自体をいじらなくても済むように、
コールバックが準備されてることが多いです。　　← 妄想です。

なんて、スカして書いていますが、このコールバックするようにどういう風にコードを書くのかがさっぱりわかりませんでした。

生成されるコードには、





といった感じに　xxx_CallbackRegister（........）という関数が準備されています。
なので、このコールバックレジスターとかいう関数にうまく引数をわたせれば
割り込みが入ったときに　xxx_InterruptHandler(.......)関数から、自分の書いたコードの関数へと呼び出されるはずなんですが、なかなかうまくいかない。。。。

ネット検索して勉強しても、メンドーな言葉でかえってややこしく説明してるんではと被害モーソーに陥ってしまいます。
こういう時はテキトーにしらみつぶしにやってみる。
なので、理屈が合ってるのか全然わかりませんが、

xxx_CallbackRegisterへは、自分のコードの関数名と0を引数として渡し、




自分のコードの関数の定義では、
引数のところに（void）と書きたくなりますが、そうするとウォーニングが出るので、
空カッコ（）にします。

こうやったらエラーも出なくなって、動作もオッケになりました。　←まぐれです。


これは割り込みからの処理なので、引数が必要無いのですが、必要な時にどう書くのかはまたその時に。。。

これで、MCCやハーモニーで生成されるコードをいじることなしに割り込みとか動作させることができるようになったので、ヘッダファイルのねじれの原因も潰すことができました。

若い時は結果を急ぐあまり、まぁいっかで、どんどん先へと進んでいましたが、
年寄りになると気力体力が劣るのに時間は長くなるので、先を急がず休み休みでゆっくりになってしまうんですかね。
まぁ、とにかく、なかなかモノゴトが片付かなくて長期にわたってしまいます。

まだ20代だった頃、
C言語を勉強しようと思って買ってきた本
たしか、サルでもわかるC言語とかいうやつだったと思うんですけど、
これが、カンタンっていうんではなくて、フザケテる。

Cのプログラムはしょっぱなに
#include…
ってのが出てくるもんなんですが、
これは知らなくていいから、そのまま写せと書いてあった😑

てことはですね、これはわからないままにしておけ、ってことですよね。
"わかる"の意味からすでに外れてる😔
で、読み始めてすぐにやる気を失ってしまって、Cは封印していたのでした。。。。



最近PICをやり始めるようになって、
最初はアセンブラでやってましたが、
Cも使える統合環境がCコンパイラも含めて無料で使えるようになったので、
始めてみたわけです。

プログラムのコードの部分は、basicもFORTRANもCも　まぁ似たようなもんだから、
辞書引くような感じで、命令を置き換えていけば、なんとか書くことはできました。

調子にのってずらずら書いていくとプログラムが長くなってしまって見通しが悪くなるし、
よく使う、例えば液晶表示器のコントロールルーチンや
I2C仕様のセンサーコントロールルーチンなんかは
別のプログラムでも使えるようにしたいので、そこだけ取り出してファイル分割しますよね。

ここで、出てくる#include。。。。

いままでは、よくわかんないながらも、
なんとか動いていたのですが、
8ビット用のXC8コンパイラから32ビット用のXC32コンパイラにした途端にエラーの嵐。

どーもXC32は文法が厳しくなってる気がする。　　← 妄想です。

それで、いよいよ　いかなくなってきたので、
お正月だというのに、#includeの勉強を真面目にやらざるをえなくなった
というわけです😭


インクルードするのはヘッダファイルなんですが、
そのヘッダファイルの書き方がデタラメだったということがわかったのでした😅

定数の宣言とか、変数の定義とか、ソースファイルを書いててジャマだなと思ったものをみんなヘッダファイルに移してソースファイルの頭の部分をスッキリさせていたのが大間違いでした。

ヘッダファイルに書いていいのは宣言だけで、
定義はダメらしいです。
定義というのは、メモリに変数を割り振ったり、数値を代入したりと
プログラムメモリに何かすることイッサイという意味かな。

あとこれは、
分割した他のファイルから使うものだけを宣言しておくもので、
自分しか使わないものは、全てソースファイルの方に書いておくということらしいです。

プログラム全体で使用するグローバル変数は、
今まで、header.hに定義してしまっていましたが、
正しくは定義はその変数をメインに使うソースファイルの中で定義して、
そのソースファイルと対のヘッダファイル内でexternを付けて宣言しておく。
こうすれば、このグローバル変数を他のソースからも参照できるようになりました。

そんなんで、
今まで書いたプログラムを再確認。
2年くらい前までに書いたものは、そんなにメチャクチャにはなっていなくて、
ルールを知らなかった割には意外にオッケーでした。
一昨年あたりから、プログラム自体が巨大になってきたのもありますが、
しっちゃかめっちゃかで、ねじれにねじれていて、修正はとても大変でした。

どーもMCC使うと、たくさんのソースファイルとヘッダファイルが生成されるので、それを眺めて勘違いしてボーソーしてしまっていたようです。

MCCで生成されたファイルは　基本いじらない　ようなのですが、
割り込みとかのちょっとしたフラグ変数などを追加して
それをグローバルしたい時とかに、うまくやれずにハチャメチャにしてたみたいです。

とゆーわけで、お正月はしっかり休んで疲れをとろうケーカクは
うまくいかず、アタマがヒローしてしまいました。
けれど、"ワカッタ" ということで気晴らしにはなったかな😀