あいです開発日誌

安価なオシロスコープを購入しました。

200MHz/1Gsです。

もうちょっと周波数の高いもの、チャンネル数がほしい場合はテクトロの兄貴がいるのでそれを使います。

まあ、GPIOのHi/Loとか、割り込み周期とか、SPIやI2C、UARTの通信を見るぐらいならここらでも十分かと思っています。

趣味で電子工作をやっている人には、もう少し周波数の低いものがもっと安く売られているのでそれでもいいかも。

中国製とはいえ侮れません。買ったばかりなので耐久性はこれから。

Linuxのオーディオドライバーをいじることになって参考に買った本。

結局のところ、aplay -lとかaplay -Lぐらいしか使わなかったのだが、まあまあためにはなった。

Linuxのドライバー、特に組み込み機器用は参考文献が少なく、メーカーに教えてもらうかネットで探すか。

もしくはSDKの中から似たようなものを参考にするかである。

ネット上にあるものは殆どが英語のもので、外国人はいろいろと質問したりしてるから出てくるけど日本人は少ないのかな。

Linuxマシンを使っている人は多いけど、アプリ・WEB側のことは出てくるけどホント、ドライバーは無いです。

Internal error. Please refer to https://code.google.com/p/android/issues

java.lang.VerifyError: Expecting a stack map frame
Exception Details:
Location:
com/intellij/openapi/util/text/StringUtil.pluralize(Ljava/lang/String;I)Ljava/lang/String; @7: nop
Reason:
Expected stackmap frame at this location.
Bytecode:
：
：
at com.intellij.util.io.URLUtil.splitJarUrl(URLUtil.java:144)
at com.intellij.openapi.application.PathManager.extractRoot(PathManager.java:452)
at com.intellij.openapi.application.PathManager.getResourceRoot(PathManager.java:421)
at com.intellij.openapi.application.PathManager.getHomePathFor(PathManager.java:146)
：
：
－－－－
JRE 11.0.8+10-b944.6842174 amd64 by N/A
C:\Program Files\Android\Android Studio\jre

AndroidアプリのTarget Versionを更新するためにAPK(AAB)ファイルを生成しているのだがAndroid Atudioの更新があったので4.2へアップクデートしたら立ち上がらなくなった。

別のパソコン(Android Studioがインストールされていない)で同様のインスールをしてみたが問題なく立ち上がったのでアップデータの問題ではなさそう。

多分環境だろうと思い、違いを考えた結果、日本語化していたかどうかにあたる。

ネットで検索するとpleiades-winが゜どうのこうのとか出てくるので、エラーは出たままだが4.2を日本語化することにした。(ダメ元)

見事、無事に日本語化されたAndroid Studio 4.2が起動した。

C:\Users\ユーザー名\AppData\Roaming\Google

の下にAndroidStudio4.2があり日本語化対象になるらしいのだが、それまでは古いフォルダが存在しており、ミスマッチしていて起動しなかったものと推測される。

fprintfがfputcよりも遥かに遅いということを今更ながらに知る。

普通に書くプログラムなら問題ないのだが、スピードを要求される事案だとfprintfがネックになってしまった。

バイナリをfputcで書く分には問題ないようだ。

冗長的な関数というのは時間がかかるものだと改めて実感。

組み込みではsprintfもたまに使ったりするが、こちらはもっとCPUが非力なので使用用途を考えねばならないと思った。

可読性をよくするために冗長的な書き方、言語を選択するのはいいのだが、まだまだ考えねばならんことはあるなぁ。

TCP/IP、UDPの通信をVC++で作成。

今どきは、C#とか他言語で簡単に構築できるんだろうけど、C/C++というオーダーでVCに。

なかなか参考になる資料が無くて結構難儀したけど、とりあえず通信できる状態にはなった。

プライベート・ポートを使い、マルチスレッドで動かしてと、いい勉強になりました。

マイコン屋なんでphyチップから勉強してとも思うけどプロトコルスタックが大変と聞くのでなるべく簡単に使えるものを選びたい。

BLEやUSBもモジュール使ってる人が多くて、ドライバを自分で書いてる人は少ないし。

Linux(Ubuntu)で開発することになった。

日ごろからやっている方にとっては何でもないことなのだが

普段Windows遣いなため結構面倒。

で、まずC/C++開発のためgccをインストール。

デバック用にDGBもインストール。

さて問題はエディタ。

サクラエディタみたいのがあるといいんだけど試行錯誤した結果、Visual Stusio Codeにした。

（emacsだのAtomだの、いろいろと助言はいただいたが）

いろいろ追加でgccでのコンパイル、GDBでのデバッグが可能になるし、Visual Studioは使い慣れているので楽かなと。

まずは使ってみて、また考えよう。

弊社はLabViewを使って検査装置の制御を行ったりもしています。

先日、あるお客様より緊急で対応をお願いしたいとご連絡をいただき行ってまいりました。

私共が製作したものではなく、仕様等も把握できぬまま現場へ直行。

状況を確認し、LabViewでの流れを追い、I/Fボードの交換やらいろいろと試し、何とか対応。

プログラムというのは他人が書いたものは、その意図するところがわからず困るものです。

今回は上手くいったと思うので良かったです。

昨年末より発生していた不具合。

実機で一週間以上連続運転していて１回発生する確率のもの。

でも数時間で発生する場合もある。これがやっかい。

何が起こっているのか実機ではつかみきれない。

何とかICEで捕まえられないか、やっと出た現象。

次はいつ出るかわからないのでPC、ICEは数日間電源を入れっ放しで内部がどうなっているのかを調査。

今度は何故そのようになるのかを推測、プロジェクトに関わる人たちで考えに考える。

あり得ないことが起こっている。そう、あり得ないことが起こっているから不具合なのだ！

皆でいろいろと検討しプログラムに仕掛けを入れる。

先日、やっと引っかかってバックトレース。

わかってみれば何だこんなことか！というのはいつもの事だ。

ものすごく長く感じた２か月だったが１日の時間が経つのは早かった。

プロジェクトのため、他人が書いた部分、Grepで検索しきれていなかった部分、沢山のソースコード、全ては理解できていない。

よくぞ引っかかってくれました、と。

久しぶりに凄く苦労したデバッグでした。

まだまだリリースまで開発は続く。

STM32シリーズのボードが安価に売られています。

MBedOSを使えばArduino同様に簡単にソフトウエア開発ができます。

非常に便利な世の中になりました。

ただ、標準仕様では使いにくいという場合があります。

例えば消費電流など、電池やバッテリーで動かすときは電流を抑えたいといったことがあります。

今回、標準でシステムクロック80MHzで動作するこのボードを20MHzまで落としました。

データシートを見ながら必要なレジスタに適切な値を書き込むことでクロック変更することができます。

ただし内蔵ペリフェラルにも影響が出るため、そこは数値の合わせ込みが必要になってきます。

こんなこともやってます。

弊社で設計・製作した機器が海外拠点で使用されるとのことで該非判定のパラメータ・シートを添付しました。

このようなことは以前から行っていましたが、今回ブログ記事にしました。

いろいろと勉強させてもらっています。