このテーマに関するリソースを知っている人はいますか?
2x16 LCD ディスプレイ用の組み込みアプリケーションを開発しています。理想的には、1 つまたは複数のセグメント LED、1x16、2x16 LCD など、事実上任意のディスプレイで使用できる一般的な (ディスプレイに依存しない) フレームワークが必要です。ユーザー インターフェイス。
編集: 高レベルの機能、ユーザー インターフェイス (メニュー、オプション、ユーザー入力) を整理する方法に興味があります。ここでは、LCD コントローラーの問題については説明しません。
I would design it for a single-line interface, using more lines would give you more space.
I would go for at least 4 buttons:
線の幅 (16 など) を指定すると、これは 16x2、16x1、および 16 の 7 セグメント ディスプレイで機能し、メニューのテキストを設計するときにそれを考慮します。
ボタンを追加すると、UI がより便利になります。優先度順に並べて考えますが、これらは必須ではありません。
ネストされたサブメニューまたはアクション アイテムに移動するメイン メニューがあります。
例を挙げましょう。16x1 または 16x2 で動作するデジタル時計を使用しているとします。
メニューキーを押すと、メイン画面は 08:15P SUN101908 のようになります。メニュー (時刻の設定、日付の設定、アラームの設定、表示の設定) が表示され、UP&DOWN で項目を移動し、OK で項目を選択します。 .
「時間の設定」を選択すると、上矢印と下矢印で時間が変わり、OK を押すと分選択に移動します。
テンキーがあれば、もっと使いやすいでしょう。
ディスプレイのサイズは、ユーザー インターフェイスに大きな影響を与えます。
1 行は 1 つのレベルのメニューに十分な大きさにすぎませんが、それでさえそれを押し進めていると思います。ボタンとしてすべての機能を持ち、データを表示するためだけに表示します。
マルチレベル メニューには 2 行で十分です。メニュー モードでは、一番上の行はメニュー ツリーのどこにあるかを示すために使用され、2 番目の行はメニューの選択に使用できます。メニューに多くのレベルを追加することはお勧めしません。そうしないと、ユーザーが現在の場所を忘れてしまい、メニュー ツリーのどこにあるのかを思い出すのに苦労します。機能モードでは、一番上の行は選択された機能を示し、2 番目の行はデータを示すために使用できます。ボタンの上下メニューで問題を解決できますが、機能専用のボタンを引き続き配置することを検討します。
メニューは4行がいいです。上記のレイアウトと同様で、追加の行は、ユーザーがメニュー ツリーのどこにいるかを覚えるのに役立ちます。空間的に視覚化するのに役立ちます。この場合、アップダウン メニューの [OK] ボタンを使用し、特定のファンクション キーは使用しないことをお勧めします。特定のファンクション キーは、メニュー パラダイムに関してユーザーを混乱させることがあります。
私は 1 行または 2 行のディスプレイ用の数字キーパッドに煩わされることはなく、QWERTY キーボードをまったく使用しません。これだけ多くのボタンを前面に配置するためのスペースを確保できる場合は、ユーザーに大きなディスプレイを用意する義務があります。1 x 16 ディスプレイの QWERTY を想像してみてください。ばかげている。UI の複雑さは、デバイスの複雑さを反映する必要があります。
オサマのシングル ライン クロックの例を考えてみましょう。これは、2 つのボタンとメニューなしで実現できます。ボタンは「設定」および「調整」と呼ぶことができます。
操作は次のとおりです。
数字キーパッドは過剰であり、エンジニアリングの観点から見ると、ハードウェアとコストが増加します。これが、目覚まし時計にテンキーがない理由です。
1x16 と 2x16 の LCD の違いは非常に大きいため、両方を処理できる GUI ライブラリを作成しようと努力すべきではないと思います - バックエンドとして CURSES と Cocoa の両方を処理できる GUI ライブラリを作成しようとしないのと同じです (まあ、誰かがそうしましたが、それは... 間違っています）。
表示が非常に少ないため、GUI は非常にドメイン指向である必要があります...つまり、ドメインが何であるかを知らずに、何が良い概念かはわかりません。
2行×16文字のディスプレイについて言及している場合、それらは通常ピクセルベースであり、制御がはるかに複雑であるため、統合コントローラーを備えています。私が過去に使用した 2x16 および 4x16 LCD デバイスは、実際にはニブル幅のインターフェイスを備えており<command>[<address>][<data>]、有効なコマンドに必要なニブル数はコマンド自体によって決定され、コマンドはスタイリッシュにデバイスに送信されます。メーカーごとの標準が実際にはないように思われるため、ターゲットデバイスにリンクすると役立ちます。
セグメント化された LED と LCD に関しては、ピクシー管から始まった、いわゆる 7 セグメント デバイスの標準的なレイアウトがあります。このセグメンテーションを示す図は次のとおりです。
a
---
f| g |b
---
e| |c
---
d
もう 1 つの問題は、ディスプレイを直接駆動するのか、それともコントローラー IC を使用するのかということです。7 セグメント LED を駆動するのは非常に簡単です。一般に共通のカソードまたはアノードがあり、十分な電流をシンクまたはソースできる必要があるだけです。デバイスへの損傷を避けるために、ピクセルまたはセグメントに適用される極性を常に反転させる必要があるため、LCD を直接駆動するのはもう少し複雑です。この機能を実行する統合クロックを備えたコントローラーを見つける方がはるかに簡単です。
任天堂のようなコントローラーは簡単に作成でき、ほとんどすべてのアプリケーションに使用できます。必要なのは 8 つのキーだけです。方向パッド用に 4 つ、中央に 2 つ、A および B ボタン用に 2 つ。この種のコントローラーの作成は非常に簡単で、ユーザーにとっては非常に直感的です。また、ユーザーが手に持つことができるため、マウントされたコントロールよりもはるかにユーザーフレンドリーになります.
SONY のジョグダイヤルも良い選択です: Up/Down/press(enter)/press & hold(escape)。ジョグダイヤルモジュールが利用できない場合。では、マウスホイールを分解してみてください。
この明示的な目的のために構築された「プロジェクト」またはライブラリは知りません。
画面とフィールドの概念に基づいて動作する「ディスプレイ レイヤー」コードを使用するアプローチを取ることをお勧めします。画面は、画面上のすべてのフィールドを「所有」する責任があり、フィールドは、表示されるもの、フィールドが影響する変数、およびフィールド値に影響を与える入力メソッドを指定する責任があります。フィールドには、フィールドの前後のセットアップ/検証関数への関数ポインタも格納されます。
これを行うと、かなり一貫した UI を維持するのに役立ちます。コードも 1 か所に集中するため、デバッグが容易になる可能性があります。