PC serial port funny

[nicjo]

Hi all,

I guess this is a question more about the MSCOMM object within VB6 than PICs however, it may turn out the other way.

I'm sending serial data to the PC and displaying the data in several text boxes. The connection between the PC and PICF628 begins when the VB6 form opens and the user initiates a request from the PIC. The PIC then sends 5 differnent variables plus a couple of characters at the front so that I could rip out the two command char which indicate which text box to display the data. I'm using the DEBUG @ 300 BPS for communication.

The funny thing is that when any other data is sent after the initialization the PC comm port seems to have shifted (right) to places. I've attached both the PC code and a snippet from a large PIC file.

I must mention that some of the VB code I obtained was off Rentron.com, I just added a few things.

Oh, and one more thing, the days of frustration over the PICF88, was due to a decoupling cap, thanks for everyones advice especially Steve.

Private Sub cmdinit_Click()
Dim out As String
out = "k"
MSComm1.Output = out            'command to PIC to begin sending data.
End Sub
----------------------------------------
Private Sub Form_Load()
Dim i As Integer
Dim send_data As String
Dim InStr As String
    
MSComm1.CommPort = 2
' Fire Rx Event Every Two Bytes
MSComm1.RThreshold = 6

'If MSComm1.InBufferCount = 6 Then
    ' When Inputting Data, Input 6 Bytes at a time
    MSComm1.InputLen = 6
'End If

' 300 Baud, No Parity, 8 Data Bits, 1 Stop Bit
MSComm1.Settings = "300,N,8,1"
' Disable DTR
MSComm1.DTREnable = False

' Open the port
MSComm1.PortOpen = True

End Sub
----------------------------------------------------------------
Public Sub MSComm1_OnComm()
Dim sData As String

If MSComm1.CommEvent = comEvReceive Then
    sData = sData & MSComm1.Input
    sData = MSComm1.Input ' Get data (2 bytes)
End If

Call display(sData)
End Sub
--------------------------------------------------------------------
Public Sub display(instring As String)
Dim cmdword As String         'hold the command word
Dim word As String        'holds the data
Dim outstring As String

If Len(instring >= Limit) Then
    outstring = instring
    instring = Right$(instring, Len(instring) - Limit)      'clears the buf
Call handleinput(outstring)

End If
End Sub
------------------------------------------------------------------------
Sub handleinput(displaystr As String)
Dim newstring As String


cmdword = Left(displaystr, 2)     ' rip out the command 
word = Mid$(displaystr, 3, 4)      'rip out the data to be displayed

Select Case cmdword
    Case "OK"
        
    Case "aa"       'lower bound
        lower.Text = word
        
    Case "bb"       'upper bound
        upper.Text = word
        
    Case "cn"       'step count
        stepcnt.Text = word
        
    Case "ab"
        focus1.Text = word
        
End Select
    
End Sub

----------------------------------------------------

PIC code

init:                           '
sendlower:
debug "aa", #lower
PAUSE 100

debug "bb", #upper
PAUSE 100 
   
sendstepcnt:       
debug "cn", #stepcnt
PAUSE 100

sendf1:
ADDR_L=1
ADDR_H=2
GOSUB readset
DataA.byte0 = RDDATA_L
DataA.byte1 = RDDATA_H
debug "ab", #DataA

I'm thinking that maybe I need to encapsulate the data in control characters then strip them out at the other end. But after looking at the output of the pic using (MCS Communicator) when the initialistion command is given, I can't see any errors. ?????

[HenrikOlsson]

Hi,
I think yoyr problem is in your DEBUG statements in the PIC code. If you use the #modifier the PIC sends the the value of the variable as "text". So if the varaible lower is a word and set to 1234 the pic will send four bytes ie. "1","2","3","4" instead of the two bytes that the wordvariable consists of. That way the number of bytes the PIC sends depends on the actuall value of the variables so the OnComm() event will fire at different places in your "stream" since it's set to fire after every 6 bytes.

I think that you need to do:

sendlower:
debug "aa", lower
PAUSE 100

And then on the VB-side you look for "aa" and then extract the high and low byte from the stream and put them together with Result = highbyte*256+lowbyte or something like that.

Did it make any sence?

/Henrik Olsson.

[nicjo]

Thanks Henrik,

Yes I have tried what you've suggested, but only on the transmission of one variable containing 2 bytes. It worked fine. I will change the code and see if that does the trick. Ithink it might be a little tricky though.


John.

[nicjo]

Hi all,

I've been able to get error free comms by sending the variables as high and low bytes (debug "aa", stepcnt.byte1, stepcnt.byte0). The same is not true when I send the variable as

DEBUG "aa", stepcnt

My steps taken to covert for display;

cmdword = Left(displaystr, 2) ' rip out the command 'aa'
newstring = asc(mid$, 3, 2)) ' put the rest of the word into var
Lbyte = newstring AND &H255
Hbyte = (newstring - Lbyte) / &H100
word = (Hbyte * &H100) OR Lbyte
Text.text=word

This seems to work on paper. I've also swapped high and low around as I think the PIC sends the low order byte first?

Even though I've got the project working well, could someone explain the correct way to strip data using VB.

Most appreciated

John

[mister_e]

Could you post your whole codes here (all VB(Vbp,form...) and PBP.Bas)? just pack both in a zip. Save me to re-invent the wheel and work exactly with what you have

My single brain cell simply can't work with scratch and partial code snip... sorry i'm getting old

[nicjo]

Steve, I've attached the VB program and the PBP prog. Its pretty uglgy but for the best part it works. Its works well with the vb prog when variables are sent as byte1, byte2. Strange this occur when the variable is sent eg HSEROUT ["aa", stepcnt].
I also changed to the USART as I found using the serial commands I could not catch external inputs.

Thanks for your time Steve,

John

[mister_e]

O.K. i'll look at that. So you're using a 16F628 right? for serial comm, i would suggest you to use a crystal. To make sure to don't miss incoming stuff, i always suggest to use a USART interrupt.

this

["aa", stepcnt]

can't work because it will send a WORD ascii character... wich is impossible. So instead, you should work around and use

["aa", #stepcnt]

but use VAL on the VB side.

I'll do a little something here, totally different, so you could use some part of it in your actual code.

[nicjo]

Thanks, I,m using a Xtal, found that out the hard way, could'nt work out why there were so many errors, after puting xtal in cct, errors disappeared. And yes, I'm using a 628.

I kind of figured that "aa" stepcnt was a word representation of stepcnt and that on the other end it would need to be split in two to find the original values. I started off with #stepcnt but on the vb side after sending a whole bunch of words, errors started appearing. Never thought of the VAL function though. I just placed the value from the PIC straight into a txt box. Anyway, I hope my code is not to painfull.

Thanks again

John

[mister_e]

OK then, so i'll stop it here and skip the USART interrupt. In meantime, maybe you could use/read some part of what i've include.

What i did is to use a fixed string format using DEC5 modifier on the PIC side

hserout ["aa",DEC5 WordA]

So it always send 7 bytes to the PC

and on the PC side, i split the incoming string in 2 parts

        sWichOne = Mid(IncommingData, 1, 2)     ' get the header (two first character)
        wValue = Val(Right(IncommingData, 5))   ' get the value (5 last character)

Where IncommingData = MSComm1.Input, sWichOne hold the "aa", "bb" or else 2 character header, wValue hold the decimal value after the header.

no big deal.

[mister_e]

Bah, why not after all. This one use the USART interrupt. Thanks to Darrel instant interrupts... reduce indeed RTFM sessions to a minimum

[nicjo]

Thanks Steve,

I've just opened up the files the files you sent and begin to incorporate into my project. I'll let you know how I went, hopefully all good.


Cheers

John

[nicjo]

Thanks Steve. Eventually got back to my project. (To much time spent on this thing, so the missus says). Anyway, it works a treat. Iv'e added a couple more things to it as now the comms side of it works fine. I am considering using the picf88 for its ADC to measure battery voltgae.

Thansk again Steve,

John

[SteveB]

...To much time spent on this thing, so the missus says...

Listen to her! Mister_e (and Darrel Taylor) can attest to the "life ruining power " of the humble PIC if not dealt with in moderation.

LOL,
SteveB

"Problems lead to Learning...Learning leads to Feature Creeep... Feature Creep leads to Obsession...
Obsession leads to the Dark Side of the the PIC"

[Squibcakes]

DEFINE HSER_CLROERR 1 ' Clear overflow automatically

I wish that I had learnt this trick in the beggining!! LOL

Squib