cho45ソフトウェア開発って、他人が過去に作ったものに対する発見を重ねるみたいなところがあって、人工的に作られた過去の遺物を発見してうまく解釈するという、なんかよくSFモノにある、失なわれた技術を発掘していくみたいな、そういう感じ。ソフトウェアは書いた通りにしか動かない。ソフトウェアのどこかの部品が壊れて(バグって)いたら必ず、なにかしら観測可能な状態に落としこめるような環境が整っている。cho45ハードウェア部分は、人間が工夫して設計しているとはいえ、基本は物理現象(電子の動き)を利用していて、それが自分には不思議で面白い。ソフトウェアレイヤーをいじっている限りでは物理現象を利用しているという感覚は一切なく「他人がどういう意図で設計したか?」という、物理というよりは精神なことを考えていることが多い。ハードウェア、回路レベルの設計は全体的にパズル的で、動いているのが不思議な感じがする。ソフトウェアでこういうパズル的なことをやろうとしたらテストを書かないと殺されると思うけど、頑張ってだいたいうまく動いてる感じで感心すると同時に、こんなので大丈夫なのかと心配になる。実際には精度良くハードウェアは動くように設計されていて、そういう頑張ってる感じのパズル的に動くロジックの大量の組合せでCPUが構成されて、その上で機械語が実行されていて、機械語を生成するための言語があって、Cから機械語を生成するためのツールチェインがあって、それらを利用してさらに抽象化されたレイヤーで書けるLLがあって、なんだか考えていると、LLでコードを書くのはジェンガの上のほうでコードを書いている感じに思えてくる。行うのが一番簡単っぽい。以下のような感じでかなり簡単に書ける。この程度だとライブラリを使う必要はない。指定時間ごとに論理が反転する。コンポジットビデオ出力できるから、これで十分すぎる感じがする。|そこそこ使いやすい感じなのを学習しながら書いてみた。cho45そこそこ使いやすい感じなのを学習しながら書いてみた。割込みを利用はしてますが、APIとしてはブロックする同期なものしか用意してません。できる、という感じの設計になっています。10);割込みでいつのまにかデータが変化する感じなので、マルチバイトデータの読み書きではデータが化ける可能性があります。してからが必要だと思います。通信中のデータはコピーして別で持っておけばいいんですが、もったいないし、そんなに問題にならなそうだしお手軽なのでこんな感じです。仕様書の日本語訳で公開されている。(今のところ必要性を感じてない)。「特定のアドレスのデータを読みだしたい」みたいな場合は、その上にプロトコルを乗せる必要がある。同じだけど...)データをnバイト受信するというもののようだ。ステートフルなので、読み出される側は読まれようとしているアドレスを記憶しておく必要があり、1バイト読まれるごとにインクリメントする必要がある。送信と受信は別々にアドレスを指定する必要があるので、この場合2度アドレス送信が行われる。書くということらしい。基本がわかればあとはそんなに難しくなく、試行錯誤したらできる感じだった。割込みの中で余計なことをすると、うまく次の割込みが入らなくなるということがあったりするので、動作を観測するのが難しい。チカらせてデバッグするしかないことがある。いうのはPCの電源管理とかで使われるプロトコルで、基礎プロトコルとしてI2Cを利用している。いうレイヤーがあるイメージ。自体が起動していようがしていまいが、電源ケーブルさえ接続されていれば供給されています。本体が起動していないとき、もっというとそれらを扱うデーモンが起動していないときに電源供給されてもエコじゃないので、なんとかしました。論理によってオン・オフします。ピンのハイ・ローを切り替えるだけです。ローにするようにしてるだけです。以外の他の電源を回路に接続するとよくないかもしれないです。わからないんですが、こういう回路はハイサイドにしたほうが安全なのかな。オブジェクトとしてラッピングできる。(async)});とかできる。かっこいいけど、既存APIで使おうとすると、些細なフォーマットの違いで案の定使えなかったりする。方法である程度なら対応させることができる。配列のJSONが返ってくることを前提にしているそして付属するデータをうまく返す方法がないいろいろやってみると以下のようになった。"FooBar";entry.$update();みたいになる。アホっぽいし、この部分のコードがカオスになるけど、一応使えるようにはなる。