Reading the RS232 Hardware Port

[Bertrand BAROTH]

I wanna put the hardware RS232 port on Mega8515 (or 162) in NON BLOCKING mode, with default character read 255. So, if I wait with :

Do
HSerReceive (UserByte)
Loop Until (UserByte <> 255)

the value "Received", different from 255, is stored in UserByte. Does this reset the value read by HSerReceive, i.e. if I perform again a HSerReceive, will I get the same former value or again the default value 255 until next byte is transmitted by the external device ?

[Anobium]

The design intent is that the constant 'DEFAULTUSARTRETURNVALUE' should be returned in non-blocking if no data was recieved. As a constant 'DEFAULTUSARTRETURNVALUE' will not change upon subsequent reads.

However, the AVR portion of the library assume that the follow Bit() are valid...

'AVR Usart has data flags setup
    If Bit(RXC0) Then
      USARTHasData = "RXC0 = On"
    End If
    If NoBit(RXC0) Then
      USARTHasData = "RXC = On"
    End If
    If Bit(RXC1) Then
      USART2HasData = "RXC1 = On"
    End If
    If Bit(RXC2) Then
      USART3HasData = "RXC2 = On"
    End If
    If Bit(RXC3) Then
      USART4HasData = "RXC3 = On"
    End If
    ~~~



-----

Your chip uses the code below, so, it should all be ok.

If NoBit(RXC0) Then
USARTHasData = "RXC = On"
End If
~~~

[Bertrand BAROTH]

My device (Elechouse VR3 for voice recognition) will send 9 bytes (including a 0xFF which is not significant), beginning with 0xAA and finishing wit 0x0A. Maybe it would be better if I use the blocking mode and receive the 9 bytes via an interrupt routine (UsartRX1Ready) ; but there is another question (rather related with the interrupt structure of the processor) : if I call this routine and read the following bytes inside of the routine (still in blocking mode), is the interrupt AUTOMATICALLY disabled, or must I disable it via IntOff, to avoid recursive call when the following bytes are received ?

[Anobium]

Use the ring buffer - then, you know what is happening.

Re IntOff. No. Once the ISR has started it will complete, if another byte arrives it will generate the next interrupt. The ring buffer is meant for this purpose - it is small and fast. I have had no lost data but you easily add a buffer overrun check to see if any overrun errors are happening.

[Bertrand BAROTH]

Post cancelled, Admin my erase it if possible ...

[mmotte]

Ring buffer seems like the long way around recording a 9 byte message. You would still need to parse for the message out of the ring, find the beginning , the message and the end. I understand you don't want to sit there waiting for a message but I think "polling" to see if a message started and then using "blocking" for the next chars would work.

Here are two methods. The first one is really simple linear coding. You will define USART_BLOCKING and then only start receiving when there is message started and the first char is 0xAA. Then there must be the rest of the correct number of chars.

'My device (Elechouse VR3 for voice recognition) will send 9 bytes
' (including a 0xFF which is not significant), beginning with 0xAA
'and finishing wit 0x0A. Maybe it would be better if I use the
'blocking mode and receive the 9 bytes

' Use blocking because msg comes all at once
' return the string of the data gathered

' #define USART_BLOCKING

sub get_VR3_Msg(Out VR3_Msg As String)   'gets 9 values
  if USARTHasData then
    HSerReceive temp
    If temp = 0xAA    Then  'Look for 0xAA for  start of message
      VR3_Msg(1) = temp
      HSerReceive  VR3_Msg(2)
      HSerReceive  VR3_Msg(3)
      HSerReceive  VR3_Msg(4)
      HSerReceive  VR3_Msg(5)
      HSerReceive  VR3_Msg(6)
      HSerReceive  VR3_Msg(7)
      HSerReceive  VR3_Msg(8)
      HSerReceive  VR3_Msg(9)


    end if
  end if
end Sub

The second one is really simple loop. You will define USART_BLOCKING and then only start receiving when there is message started and the first char is 0xAA. Then the rest of the message of variable length would end with the requested termination char 0x0A.

'My device (Elechouse VR3 for voice recognition) will send 9 bytes
' (including a 0xFF which is not significant), beginning with 0xAA
'and finishing wit 0x0A. Maybe it would be better if I use the
'blocking mode and receive the 9 bytes

' Use blocking because msg comes all at once
' return the string of the data gathered

'#define USART_BLOCKING

sub get_VR3_Msg(Out VR3_Msg As String)   'gets  values until 0x0A
  if USARTHasData then
    VR3Index = 1

    HSerReceive temp
    If temp = 0xAA    Then  'Look for 0xAA for  start of message
        VR3_Msg(VR3Index) = temp
        Do
          HSerReceive ( temp )
          'LineFeed?
          If temp = 0x0A Then
             Exit Sub
          End If

          VR3Index++
          VR3_Msg(HSerIndex) = temp
          VR3_Msg(0) = HSerIndex

        Loop
    end if
  end if
end Sub

I am sorry these are untested but are adapted from working code. I may have missed something.

Mike

[Bertrand BAROTH]

PS : for my application VR3 is obsolete, it is TOO sensitive and seems to trigger at minimal loudness, so it is useless for me ...

[Bertrand BAROTH]

New informations about Elechouse VR3 : Now I succeeded in using it ... "roughly" ! In fact it is not too sensitive to background noise. My problem was that I read (and printed) only the non-Arduino section of the manual (I use it with the STK200 for testing), and I will have to make some additional tests with a terminal program, to see EXACTLY the data sent back by the device (I am waiting for delivery of an USB to TTL-serial interface, I don't wanna use a MAX232 on the computer's COM port) : especially after receiving a "training" command, the device sends an acknowledgment, but I could not find any data sent for "training the word is complete", only blinking codes of Leds on the module (maybe I could "tinker" a non-standard interface and feed these informations back to the processor ? Testing the voltage at the Leds with analog comparators ? All the way I must route the Led's connections to the front of the cabinet). I use presently a delay after sending the command : I don't perform training in an interactive mode, word after word, but in a loop ...

[Bertrand BAROTH]

VR3 rejects sometimes a word and one has to repeat it several times before it gets accepted ... The device seems to be rather sensitive to variations in pronunciation.
:(
Often I wonder if we don't have still the same issues as described already in 1973 by Theodore Sturgeon in the short story : "Agnes, Accent and Access" !
:)