2か月前、 rusEfiが完全に機能する制御ユニットになったことに決着しました。ハードウェア部分だけがパスタ工場での爆発に似ていました。 rusEfiは、stm32プラットフォーム上にハードウェアを備えたオープンソースの自動車制御ユニットであることを思い出させてください。
ぼんやりと座って問題のハードウェア側に焦点を当てたわけではありませんでした。タスクは鉄の一歩を踏み出すことでした。
名前v3はありませんでした:
フランケンシュタイン0.1になりました:
これがまだ独占的なエンジニアリングプラットフォームであり、最終製品ではないことは明らかです。しかし、主なことは進歩があることです:)
ボードは自然に機能します。
10個の「Frankenstein 0.1」ボードがすでに製造されており、さらに10個のボードが注文されています。 今、私は2つのボードを集めて、カナダに1つ、スロバキアに2つを送る必要があります-これは私たちの国際プロジェクトです。 ちなみにここのボードソース。
鉄の開発は一時停止され、ソフトウェアと実装に戻りました。 エンジン制御自体の観点から、ファームウェアは前進しませんでした-カスタマイズ可能性とデバッグの利便性の面でファームウェアが前進しました:HD44780文字画面のサポートが登場し、条件付きコンパイルの数が急激に減少しました-デバッグコンソールまたはデバッグコンソールを介して、大幅に多くの設定を変更できるようになりましたユニバーサルコンピュータセットアッププログラム。 SDスロットが登場しました。 CANバスがありました。これは、一般的にはまだ必要ありません。 人気のあるGPSモジュールのドライバーが登場しました-現時点では一般的に純粋な悪戯です:)要するに、私たちは基盤を構築しました-そして私にはそれを構築したようです。
今、あなたは最もおいしいことができます-今、これらすべてから、便利で、多用途で、シンプルな車のコントロールユニットを作ることができます。
個人的には、私は主に経験豊富なプログラマーなので、ファームウェアを徹底的に書きます。
単体テストと継続的な統合。
3日前、CからC +に切り替えました。OOPはほとんどないため、ここでは、「C +」という単語でプラス1つだけを検討します。
1週間前、Windows用のファームウェアの基本ロジックをコンパイルすることが可能になりました-これはすぐに自動機能テストにつながるはずです。
あなたが尋ねるので、ここでファームウェアに何が欠けていますか? 多くが欠けています。 ファームウェアの再起動が必要な一部のパラメーターの変更-実行中に1つのモードから別のモードに切り替えることはできません。 オンライン設定は慎重に終了する必要があります-いくつかのことはまだコードに設定されています。
したがって、ニューラルネットワークのプログラミングは少し早いですが、すべての基本的な機能をプログラミングする必要があります。 はい、タスクは比較的退屈ですが、コードは非常に明確で、ユーザーの利便性は興味をそそります。
だから、何か新しいことを学びたいと考えている完璧な完璧主義者のプログラマーがいるなら、ぜひご参加ください。
関連リンク:
http://rusefi.com/wiki/index.php?title=Main_Page/en
http://rusefi.com/forum/
PS:現在のプログラミングタスクを具体的に述べるための要求を受け取りました。
したがって、モーターはすでに実行されています-つまり 制御は、特定のモーターを参照して、プロトタイプモードで処理されます。 これらのプロセスのパラメーター化を改善する必要があります-つまり まず、シリアルポートを介して構成を完全に変更する必要があります。次に、プログラムを再起動せずに新しいパラメーターの適用を開始する必要があります。 これは現時点で最も重要です。
次の段階は、制御プロセスの複雑化です。 たとえば、入力パラメータ「負荷」は、低速のアナログセンサーではなく、高速のアナログセンサーである必要があります。これは、特定の時間ウィンドウ内でのみポーリングされ、平均化される必要があります。 アイドル状態を維持するためのアルゴリズムは、単純ではありません。何かする必要があります。 デュアルスロットルポジションセンサーの処理アルゴリズムなど。 電子スロットル制御アルゴリズムとこの制御の電子機器。 そして、ある時点で、秒/ミリ秒単位の奇妙なティックからの時間変数が必要になります。 などなど。
自動化された機能テストから始めます。外部の動作が予期せず変化しないことをチェックするときに、何かをリファクタリングする方が穏やかです。