余っているAndroidスマホをオシロにしよう！
右のキャプ画面のように電圧軸はなんとか実装しました．
時間軸はTriggerを未実装なのでまだあまり進んでません．
オシロの設定パラメータはいろいろありまして、波形表示だけでもざっとこんなのが必要です．
V/div、Trigger ch、Trigger電圧、Offset電圧、Sec/div、ADCサンプリング周波数、ADC bit数、表示エリアXY寸法、ch色
さらにこれらがch共通とch別に分類されます．
表示パラメータですから大域変数的に運用したいのだけれど、Java/Kotlinなので大域変数は使えないし#defineすら無いんじゃね？ その結果Objectがあっちゃこっちゃに分散しちまって初期設定すらグダグダになってます．
追記：android.app.Application でグローバル変数みたく扱う手段が用意されているらしいです
おおまかな構造は、
・ボタンやseekbarを記述するMain activity
・波形表示するCanvas
・波形データをscaling等するobject
これらObjectが隔離されているのでややこしくなってる．
土台からRefactoringが必要でぇす．作り直しが必要でぇす．
UI的にはseekbar周りの苦労が多いです．ボタンでサイクリックにch切り替えしたり、10秒無操作で表示を消す、ボタンclickで表示復旧 とかしてるのでcodeの行数が増えて見づらい上にbugりやすい．
あと、生のADC波形データは8bit配列で、それをスマホ画面サイズにFloatでscalingするのですが、波形データをfor文で何度も上から下までなめると処理が遅くなって動きがカクカクします．for文１発でやった方が動きが滑らかになりんす．パソコン並みの処理速度があるだろうとか思ってるとそうでもないですね．
そうだ、なぜか点線を描けてない．
かしこ
>余っているAndroidスマホをオシロにしよう！
返信削除なんかやっぱり、
「Androidは、スマホ以外には使うんじゃねーよ！」
という、
「Googleの呪い」
が、掛かってんじゃないでしょうか？という気がする。
・そういう意味では「スマホゲーム」とかも、開発初期は同じようなところで
「ハマりまくってた」んだろうな・・・なので、最初なかなか
「ＰＣゲームからスマホゲームへの移行」が、うまくいかなかったんだろうな。
（最近は、開発環境が確立してきたのか、いろんなゲームが出てくるようになったみたいですが）
※そういう意味では、「Java/Kotlin」で、「シコシコ」書くんじゃなくて、最初から
「Unity」みたいな環境で書いたほうが良かったかもしれません。
（確か、「Android用オブジェクトの出力」も、あったはず。うまくいくかは知りませんが。）
スマホゲームの開発はプラットホーム的な枠組みを初期メンバーが確立するのに苦心したんじゃないでしょうか。
削除確かunityってiphoneとandroidアプリを吐かせる開発ツールでしたっけ？
わたしがGUI programmingに手出ししたのって1993年頃の68040のMACの頃でしたからその当時よりは格段に簡単になってるみたいではあります。
>スマホゲームの開発はプラットホーム的な枠組みを初期メンバーが確立するのに苦心した
削除多分、今ここでやってるのと同じことです。
（「ＰＣ等でうまくいくやり方が、Androidだと通じない」ので、その手法を確立するのに時間が掛かった。）
そういう意味で、
>確かunityってiphoneとandroidアプリを吐かせる開発ツール
のほうが、少なくとも「最初から対応してる」という意味では、近道かな？と、思った次第です。
※「Unityが作れるのは、ゲームだけじゃない」って、どこかにあったような。
Unityのライセンスは、、、
削除Personal Unity の無料版で制作を開始 無料
利用資格：収入ならびに資金調達(自己資金を含む)の過去12ヶ月の合計が年間 10 万ドルを超えない場合、 Personal を使用できます。
ぼくちん余裕で無料ランセンシー
>1993年頃の68040のMACの頃
削除多分その頃は
「イベントロジック」
を、直書きしてた頃だと思うので、そういう意味では、
「全くの別物」（レイヤー／概念自体が違うレベル）だと思います。
（まぁ、「イベントドリブン」という基本概念は同じですが、それをもっと
「簡単に操作できる」便利な上位レイヤーがいろいろと用意されている、
みたいな感じでしょうか。）
いや、そういう意味では、「Java/Kotlin」なんて、
削除「ＧＵＩのアセンブラレベル」
ですからね。自前で「ライブラリ（クラス）」をもってなきゃ、
「なーんもできない」（その代わり、必要最小限なので「軽い」）
・「Unityのライブラリ」とか、超重そうな感じがします。使ってないから知らんけど。
個人的には、「Unity」も、「Verilog（みたいなＨＤＬ）」と同じで、
削除・今年こそは、習得するぞ！（時代についていけなくなるから）
と、思いながら「幾星霜」なんですけどね・・・
※そろそろヤバいので、まじめに始めよう・・・
＞多分その頃は「イベントロジック」を、直書き
削除そんなもんだと思います．main loopがあるんです．こまめにそいつに制御を返さなくちゃいけないとかいう．現在から見るとまるでSTM32の雛形source codeみたいな代物でした．素朴っつうかなんつうか．
＞ＧＵＩのアセンブラレベル
削除そんなもんだから逆に判り易いのかもしれません．便利とは思わんけど．
なるべく自分でcode書きたくないです．パクリで済ませたいです．
Unity無料ライセンスなら味見してみてもいいかもですね．
「便利だよこれ」とか言ってたりして．えへへ
グラフィック使うならunityもありですが、unityで3d以外のことをすると、えっ?これできないの？ということがままあります。LINE引くのも結構調べまくらないとできなかったり。
返信削除android studioに比べて便利になることもあれば不便になることもあるという感じかもです。
周りの若い人達の開発の仕方を見ていると、まずは非常に簡単に実現できるフレームワークかないか探します。そしてそのフレームワークでできないことは仕様から削除するよう要求します。
削除フレームワークが無ければ他の実装できる人を探します。どちらも無いなら上司に実装不可能と報告して終了。という感じです。ある意味スマートで正解なのですが。無ければ作るんじゃ無いのと思うのですが、それは彼らからするとプロの態度では無いようです。
エンジニアという言葉が意味するところが変わっていることを感じて居心地の悪さも感じてしまいます。
技術を深く掘って根っ子の仕組みから全て把握しないとどうにも落ち着かない本能が強い自分のようなタイプは蛮族ポジションみたいです。
Linuxの部品を集めて構築するのはエンジニア．
削除Linuxディストリをインストして使うのはユーザー．
マクドナルドのマニュアルを作るのはホワイトカラー．
マクドナルドのマニュアル通りに働くのはブルーカラー．
車の整備について
返信削除メーカのチェンジニアは診断装置を接続して、結果を見て、部品を交換して直します。
街のエンジニアは不具合症状を聞き取り、エンジン音や、ベルト音、振動など五感を振る活用して、車の挙動を創造して、必要な部品を交換したり、調整したりします。
リユース部品を使ったりして、お財布にもやさしい。
チェンジニアは一発で直る場合もありますが、たまに頓珍漢な場所の部品を交換したりしますが、そのままお客さんに請求します。
車自体も人が調整する部分はどんどん減っています。
調子が悪ければ部品交換で対応するのが当たり前になってきています。
ゼントラディーの軍艦は壊れても修理しません。
全自動の生産工場から生産された新品に乗り換えます。
おっと、兵士も人工子宮で製造されるという設定だったはずなので、船が壊れたら兵士ごと廃棄なのかもしれません。
ECUのログを解析ソフトに読ませると不具合箇所が表示される．便利すぎて考えるのをやめてしまいそうです．
削除中東やインドやパキスタンの鬼の様な修理動画を見て唖然とするのがいいかも．