Serrxd qualifier issue on 18M2

[Jeremy Leach]

Hello everyone.
I've got a puzzle with an 18M2 (firmware PICAXE-18M2+ vD.A, PICAXE running atdefault 4MHz) where I'm sending "RTSHi" from my laptop as a test (over an AXE027 cable) and :
SERRXD [5000,CommsTimeout],b6,b7,b8,b9,b10 works fine and loads up R,T,S,H,i
However SERRXD [5000,CommsTimeout],("RTS"),b6,b7 always times out.

If I reduce the qualifier to just "*" then it doesn't block but the loaded data is corrupted.
It looks as if adding the qualifier causes an internal processing delay somehow on the PICAXE, which causes a timing problem. However I'm just guessing.
Does anyone have any ideas? It might well be me missing something obvious though ! It's not essential for me to use a qualifier but it would be nice to understand the issue. Thanks.

Just in case it has any relevance, my VB.NET sending code is :
Dim WithEvents ComPort As New IO.Ports.SerialPort
With ComPort
If .IsOpen Then .Close()
.PortName = My.Settings.com_port
.BaudRate = 4800 ' 4800 'Speed for18M2 at 4MHz
.Parity = IO.Ports.Parity.None
.DataBits = 8
.StopBits = IO.Ports.StopBits.One
.ReadTimeout = 5000
.Open()
.DiscardOutBuffer()
End With
Dim WritePacket() As Byte
WritePacket = Encoding.ASCII.GetBytes("RTSHi")
ComPort.Write(WritePacket, 0, 5)

 

[hippy]

It could be that data is being received quicker than the SERRXD can handle it so it leading to corruption and not matching qualifiers. You can increase the operating speed of the PICAXE or slow down the transmission of data, sending each byte with a delay between them. Simply using two stop bits may be enough to solve the problem.

 

[Jeremy Leach]

Thanks Hippy that sounds a good possibility then. I'll do some experiments over the weekend. It's been a while since I've used PICAXEs but am enjoying coming back to them immensely .

 

[Jeremy Leach]

Well, I tried using calibfreq and +4 to -4 didn't help. Although I could have carried on with higher values I feel it's the wrong approach because the code should work with any physical 18M2 chip.

I also tried changing stop bits to Two (.StopBits = IO.Ports.StopBits.Two)

What has worked is slowing the VB.NET down a bit. Instead of using the inbuilt .NET write command for sending a packet (byte array):
ComPort.Write(WritePacket, 0, ByteCount)

I instead used this crude byte-by-byte routine to send the bytes one at a time:

    Private Sub ComPortWrite(ByteCount As Integer)
         Dim OneByteArray(0 To 0) As Byte
         For i As Integer = 0 To ByteCount - 1
             OneByteArray(0) = WritePacket(I)
             ComPort.Write(OneByteArray, 0, 1)
         Next
     End Sub

I was originally going to add a delay in the loop between sending each byte but have found it works as-is. It's surprising because I'd have thought .NET ran so quickly that this routine without any delay is effectively the same as its inbuilt 'write' statement. Maybe there's a subtle difference between how it actually sends from the buffer (because as I understand it the .NET 'write' command simply sends to the PCs serial buffer and then some other magic actually sends the contents of the buffer to the port and off to the PICAXE).

Anyway, so far so good. So I'll use this and see how I get on.

EDIT: For anyone that has the same issues and stumbles on this: I've found that adding a 1ms delay using Threading.Thread.Sleep(1) in the loop above seems to work well. It doesn't have to be 1ms. In fact at 4800 baud the width of a stop bit is 'roughly' a quarter of a millisecond so a delay of 1ms is effectively like adding 4 stop bits, which might be unnecessarily long.

 

[Jeremy Leach]

Oh and just for completeness, I think there is a bit of subtlety here that I think I understand:
Attached is the simple serial diagram from Wiki. I've highlighted the bit about the stop 'period'. So my VB.NET code (at Hippy's suggestion) is spacing out the byte transmissions by pausing between sending each byte. This effectively increases the stop bit width. The PICAXE presumably does some internal processing between received bytes (especially for qualifiers) during this stop bit period. So I'm giving the PICAXE more time to do this.



I might be wrong, but I think increasing the PICAXE clock frequency(using setfreq M8 etc) might not solve anything because the Serrxd baud rate would be increased too (9600 at PICAXE clock freq of M8). So this spacing of bytes seems abetter approach to me.

 

[hippy]

I might be wrong, but I think increasing the PICAXE clock frequency(using setfreq M8 etc) might not solve anything because the Serrxd baud rate would be increased too (9600 at PICAXE clock freq of M8).

I was suggesting increasing the clock speed but keeping the baud rate the same. But you are right in noting that cannot work with SERRXD, the two are implicitly tied together. I overlooked that.

You can however use SERIN on the Download Serial In pin to achieve that, though the baud rates available do depend on the speed chosen, and you need to explicitly add a DISCONNECT.

 

[Jeremy Leach]

Thanks Hippy. I didn't realise you could do a serin on the download pin. That's something else to play with.