PDA

View Full Version : PC serial port funny



nicjo
- 9th January 2007, 10:17
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
- 9th January 2007, 12:14
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
- 9th January 2007, 12:47
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
- 10th January 2007, 09:12
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
- 10th January 2007, 19:02
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 :D

nicjo
- 12th January 2007, 10:32
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
- 12th January 2007, 22:29
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
- 12th January 2007, 23:40
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
- 13th January 2007, 00:32
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
- 13th January 2007, 01:27
Bah, why not after all. This one use the USART interrupt. Thanks to Darrel instant interrupts... reduce indeed RTFM sessions to a minimum ;)

nicjo
- 15th January 2007, 02:19
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
- 19th January 2007, 11:45
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
- 19th January 2007, 14:19
...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. :D

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
- 6th February 2007, 06:34
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

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

Squib