C++でシリアル通信するにあたって最適なプロジェクトを選びたい

解決


HTS  2007-04-17 05:07:26  No: 64927

シリアル通信を行い、データベースに値を書き込むプログラムを

Visual studio 2005 の Visual C++ 

で作成することを検討しているのですが、

.NET Frame Work2.0 SerialPortコンポーネントが使用できるCLR windowsフォームアプリケーションプロジェクト 

を元に開発を行うべきか、
createFileなどのwindowsAPIを使用するWin32  プロジェクト

で開発を行うべきか、また、MFCなどの選択肢もあって迷っています。

短時間で大量のトランザクションが発生する仕様なので処理が早いプロジェクトでの作成が好ましいのですが、プロジェクト間にさほど差がないのでしたら  CLR windowsフォームアプリケーションプロジェクト   を検討しています。

参考資料等探しては見たのですが、
言語間の適正については理解できたのですが、
プロジェクト間の適正(特に処理速度)について分からなかったので
お知恵をお貸し頂きたく、質問させていただきました。

宜しくお願い致します。


オショウ  2007-04-17 08:07:38  No: 64928

一番遅いのが、シリアル通信処理ですが・・・
ただ、何と比較してどうするのかと言う部分では、全く情報不足です。

シルアル通信の設定は?
どのようなデータが一定時間内にどの程度受信され、それらをDBに
保存するのでしょうか?
また、DBは何ですか?

以上。


HTS  2007-04-17 19:03:34  No: 64929

アドバイスありがとうございます。
説明不足で申し訳ございません。
シリアル通信の設定は

通信速度  115200
偶数パリティ有

通信内容としましては、

スタートビット・データ数・コード・実データ・ストップビット・CRCチェック

バイト数にすると一通信でおよそ42バイト程度

こちら側がマスターで1〜15機の子と通信を行う処理が

最短20ms程度で発生します。

組み込み機器向けDBのUltraLightを検討しております。

自分が何と比較してどうしたいのかをまとめますと、
他言語の処理速度の比較は良く見かけるのですが、同一言語のプロジェクトの違いによる処理速度の比較が分からなかったので、今回の仕様に最も適したプロジェクトの採択の為の参考となる意見を頂きたく投稿させて頂きました。宜しくお願い致します。


オショウ  2007-04-18 07:35:01  No: 64930

42バイトを受信する時間は、論理値で3.65msec
恐らく、5msec程度で受信してしまうと考えます。
そうしますと、C++でしょうネ〜
ただし、最短20msecで次データの送信が始まるので、DB保存する時間
がどの程度発生するのか、確認しておく必要があります。

もしパフォーマンスが落ちてくれば、受信ルーチンから直接DBに保存
しないで、メモリ上のデータバッファを設け、受信機能とDB保存機能
をマルチスレッドさせ、バッファを介して処理するようなことになろう
かと・・・

実際にどんなCPUを持ってきても、RS-232C通信はCPUに負荷をかけ
ますので、CPU負荷を下げたいなら、イーサ・RS-232C変換とかを用い
てRS-232C通信を行えば、CPU負荷は格段に少なくなりますので、DB
処理や他の機能にCPUタイムが回り、性能向上するでしょう。

因みに、一般アプリで製作するより、システムサービスや仮想ドライバ
として動作させれば、もっと処理能力が得られることでしょう。

以上。参考まで


Ban  2007-04-18 08:10:14  No: 64931

> 同一言語のプロジェクトの違いによる処理速度の比較が分からなかったので、

2005から.NET2.0を使うとなると「C++/CLI」かなと思いますが、
「C++/CLI」はあくまで「C++/CLIという言語」であって「C++言語」とは別物です。
# そして.NET1.1時代のManaged C++もMicrosoft独自拡張言語で、ほぼ別物。

C言語(ISO/IEC9899)とC++言語(ISO/IEC14882)という別言語を扱える
C++コンパイラは多いですが、VC2005はC,C++に加えてC++/CLI(ECMA-372)という
「似て非なる別の言語」にも対応しています。

・ISO/IEC9899 C
・ISO/IEC14882 C++
・ECMA-372 C++/CLI (ISO/IECにはなれなかった)

まぁ、性能面という意味では「.NETか、否か」の問題であって
# 言語の問題ではないという気はしますが。


HTS  2007-04-20 18:28:42  No: 64932

データベースにアクセスするNETコンポーネント等が用意されているのと、納期等や、今後の移植の問題を踏まえた上でCLIで作成する方向にすることにしました。

言語性能に固執し過ぎて、一処理のロジックの効率向上に関して少し調査不足でした。

大変貴重なアドバイスありがとうございました。


※返信する前に利用規約をご確認ください。

※Google reCAPTCHA認証からCloudflare Turnstile認証へ変更しました。






  このエントリーをはてなブックマークに追加