comunicação da porta serial: porta serial polling vs usando porta serial DataReceived evento

Question

Eu apenas estou revendo alguns códigos que escrevi para se comunicar com a porta serial em C # no CF2.0. Não estou usando o evento DataReceived vez que não é confiável. MSDN afirma que:

O evento DataReceived não é gauranteed a ser levantada para cada byte recebido. Use a propriedade BytesToRead para determinar a quantidade de dados é deixado para ser lido no buffer.

Eu sondar o porto com read () e ter um delegado que processa os dados quando ele é lido. Eu também li em algum lugar que "polling é ruim" (sem explicação dada).

Todas as ideias por polling pode ser ruim? além dos cuidados de threading habituais - Eu tenho um segmento separado (discussão de fundo) que as pesquisas do porto, o segmento é encerrado após os dados são lidos, todos testados e funciona bem

.

Answer 1

A maneira que eu li que, você pode obter um evento para vários bytes, em vez de um evento por byte. Gostaria ainda de esperar para obter um evento quando dados estão prontos, e não tê-lo "pular" alguns bytes por completo.

Eu sempre usei este evento, e não tive qualquer problema com ele.

Answer 2

sabedoria

convencional diz que "polling é ruim", porque muitas vezes acaba sendo um processo CPU-bound. Se o bloqueio I / O é usado em vez disso, em seguida, a CPU está disponível para outros processos até que o evento acontece.

Dito isto, normalmente é possível as coisas configurado para que uma pesquisa aguarda uma (curta) tempo de espera antes de voltar quando há caracteres estão disponíveis. Se um tempo limite adequado é escolhido, em seguida, seus usos de loop de votação simples significativamente menos tempo de CPU, e outros processos também terá de executar.

Eu não usei portas seriais de C # em tudo, mas eu vou arriscar um palpite de que o que a documentação significa

O evento DataReceived não é garantido para ser levantada para cada byte recebido. Usar a propriedade BytesToRead para determinar a quantidade de dados é deixado para ser lido no buffer.

é que você não pode esperar para receber um evento por personagem. Ele pode em algumas circunstâncias entregar o evento com mais de um caractere disponível. Simplesmente recuperar todos os caracteres disponíveis no seu manipulador de eventos, e tudo ficará bem.

Editar: Fazer uma chamada de bloqueio em um segmento leitor pode ser a melhor resposta geral. Não é polling per se uma vez que o segmento está bloqueado até personagens chegam. Talvez seja necessário ajustar os tamanhos de buffer e alguns da porta serial configurações se for necessário para processar os dados que ele chega e não em pedaços de tamanho fixo.

Answer 3

Eu tenho certeza que o código de série controlador de porta subjacente é interrupção conduzido, mesmo quando se utiliza a chamada Leia bloqueio.