0

コンピューター（VB.NET）からシリアル接続されたAT89s52にファイルをバイト単位で送信する必要があります。
送信されたすべてのバイトには、マイクロコントローラーで実行する必要のある作業があります。
これが私のCコードのバイトの受信に関連する部分です：

SCON = 0x50;
TMOD = 0x20; // timer 1, mode 2, 8-bit reload
TH1  = 0xFD; // reload value for 9600 baud
TR1  = 1;
TI   = 1;

again:

        while(RI!=0)
        {
            P1=SBUF;          // show data on led's
            RI=0;
            receivedBytes++;
        }

        if (key1==0)
        {
            goto exitreceive; // break receiving
        }

        show_lcd_received_bytes(receivedBytes); 
        // here is one more loop 
        // with different duration for every byte
        goto again;

そして、バイトを送信するためのVB.NETコードは次のとおりです。

    For a As Integer = 1 To 10
        For t As Integer = 0 To 255
            SerialPort1.Write(Chr(t))
        Next t
    Next a

問題は、mCには受信したすべてのバイトの後に実行する作業があり、VB.NETはそれを認識せず、バイトの送信が速すぎるため、mCではすべてのバイトの一部（約10％）が終了することです。「Sleep（20）」をVBループに組み込むことができます。そうすれば動作しますが、バイトごとに処理に異なる時間が必要であり、通信が遅くなることは許容できないため、多くの無駄な時間があります。

さて、私の質問は、8051がUARTにビジー状態を設定できるかどうかです。これは、送信前にVBが読み取って、バイトを送信するかどうかを決定することができます。または、他の方法で説明されているような通信を設定するにはどうすればよいですか？また、mC側でシリアル割り込みのあるバイトを受信しようとすると、同じ結果になります。

（予想通り）コンピュータにデータをうまく送ることができるので、ハードウェアは確かに大丈夫です。

4

4 に答える 4

1

過去からの爆発、私はこの種のものをデバッグするシリアルライントレーサーにブレイクアウトボックスを使用したことを覚えています。

シリアル通信では、すべてのピン/ワイヤを使用している場合、RTS（送信準備完了）およびDTR（データ端末準備完了）を介したフロー制御があり、さらにデータを送信してもよい場合に信号を送信します。Cを介してコーディングしているデバイスでそれを制御できますか？VB.NETには、これらの信号を受信するために使用されるイベントがあります。または、SerialPortオブジェクトのプロパティを使用してクエリを実行できます。

于 2012-08-10T12:05:57.263 に答える
1

あなたの問題は建築です。バイトRxを処理する割り込みで受信データを処理しようとしないでください。バイトRx割り込みに、受信したバイトを別のRxデータバッファーにのみコピーさせ、Rx割り込みハンドラーをブロックせずに着信データの実際の処理を実行するバックグラウンドタスクを設定します。全体的なスループットの問題が原因で追いつけない場合は、RTS/CTSフロー制御が適切なメカニズムです。たとえば、Rxバッファが90％いっぱいになったら、フロー制御信号をディアサートして送信側を一時停止します。

于 2012-08-10T17:07:02.960 に答える
1

@TJDが言及しているように、ハードウェアフロー制御を使用して、マイクロコンピューターが受信したバイトを処理している間、PCが文字を送信するのを停止できます。これまで、使用可能なポートラインを出力として使用してハードウェアフローを実装しました。出力は、TTLからRS-232へのドライバーに接続する必要があります（現在RS-232を使用している場合は、追加のドライバーを使用できます）。USB仮想シリアルポートまたはRS-422/485を使用している場合は、ソフトウェアフロー制御を実装する必要があります。通常、control-Sは、PCに送信を停止するように指示し、control-Qは続行するように送信します。フロー制御を最大限に活用するには、文字を送受信するために完全に割り込み駆動のFIFOも実装する必要があります。

ハードウェアフロー制御に関する追加情報が必要な場合は、http：//electronics.stackexchange.comを確認してください。

于 2012-08-11T03:09:02.727 に答える
0

これらの回答の多くはハードウェアフロー制御を示唆していますが、ソフトウェアフロー制御を使用して送信をより堅牢にするオプションもあります。現在、通信は強力ですが、ボーレートを高くしたり、距離を長くしたり、接続がノイズの多い場合でも、誤った文字を受信したり、文字をドロップしたりする可能性があります。

実行するように設定されているアクションの完了時に、単純な2バイトのACKシーケンスを追加できます。次のようになります。

ホストはコマンドバイトを送信します：<0x00>デバイスはコマンドバイトをエコーし​​ます：<0x00>デバイスは必要なアクションを実行しますデバイスはACK / NAKバイトを送信します（結果に基づく）：

これにより、通信が途絶えているかどうかをホスト側で確認できます。エコーされた文字は、送信されたものと一致しない可能性があり、問題を警告します。さらに、あるタイムアウト内にホストが文字を受信しなかった場合、ホストは再送信を試みることができます。最後に、ACK / NAKにはステータスを返すオプションがありますが、最も重要なのは、操作が完了したことと、別のコマンドを送信できることをホストに通知することです。

これを拡張してチェックサムを含め、受信したコマンドが有効であることをデバイスに確認する方法を提供できます（コマンドバイトと一緒に送信される単純な論理逆数で十分です）。

このソリューションの利点は、ハードウェアフロー制御のために両端に追加のラインやUARTサポートを必要としないことです。

于 2012-08-22T18:22:01.433 に答える