serial coms - again

[HenrikOlsson]

Hi,
If you HSEROUT DEC3 Temperatures(0) it will write three digits, ie. 000 if the value is 0.

/Henrik.

[malc-c]

Thankyou - works a treat

[gadelhas]

Hi malc-c;

Hi use a function in VB, that does do the job, that you want, but you must send to VB more things;

You are sending 4 temperatures, i supose from 4 diferent sensors, 1 temperatura measure for each sensor.
So if you put something before sendig the temperatures to identify de sensor, like this for exemple;
You are Sending;
002610
002660
002680
002680

Ff you send;
S1002610
S2002660
S3002680
S4002680

The 2 first chars, are the ID of the sensor, and the 6 next chars are the temperature.

Now it's easy to separate them in VB, with the function "Mid",
On the event Data Received, you must do something like this;

 Private Sub DataReceived(ByVal sender As Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
        Dim buffer As String

        buffer = SerialPort1.ReadExisting

      If Mid(buffer, 1, 2) = "S1" Then
            Label1.Text = Mid(buffer, 3, 6) ' label to show the temperature of 1º sensor
       End If

      If Mid(buffer, 1, 2) = "S2" Then
            Label2.Text = Mid(buffer, 3, 6) ' label to show the temperature of 2º sensor
       End If

      If Mid(buffer, 1, 2) = "S3" Then
            Label3.Text = Mid(buffer, 3, 6) ' label to show the temperature of 3º sensor
       End If

      If Mid(buffer, 1, 2) = "S4" Then
            Label4.Text = Mid(buffer, 3, 6) ' label to show the temperature of 4º sensor
       End If
End Sub

You can use it too in a Select case, and you should put a try....cath too.

If you don't understanding something, please tell me.

[malc-c]

That sounds promising.

At the moment I've used Henriks suggestion to send three digits per record which helps with the formatting when the data is received by the application written by a chap from another forum who offered to help (he used liberty basic). However I'm trying to learn VB so your suggestion will help (I'm running two versions of PBP code side by side so I can develop either one )

At the moment the PIC sends data as

Hserout [DEC3 Temperatures(0)]
Hserout [DEC3 Temperatures(1)]
Hserout [DEC3 Temperatures(2)]
Hserout [DEC3 Temperatures(3)]

HSEROUT [dec3 normtemp[0]]
HSEROUT [dec3 normtemp[1]]
HSEROUT [dec3 normtemp[2]]
HSEROUT [dec3 normtemp[3]]

Hserout [dec3 alarmlow[0]]
Hserout [dec3 alarmlow[1]]
Hserout [dec alarmlow[2]]
Hserout [dec alarmlow[3]]

Hserout [dec3 alarmhigh[0]]
Hserout [dec3 alarmhigh[1]]
Hserout [dec3 alarmhigh[2]]
Hserout [dec3 alarmhigh[3]]

hserout [#StartHour[0] DIG 1,#StartHour[0] DIG 0,#StartMin[0] DIG 1,#StartMin[0] DIG 0]
hserout [#StartHour[1] DIG 1,#StartHour[1] DIG 0,#StartMin[1] DIG 1,#StartMin[1] DIG 0]
hserout [#StartHour[2] DIG 1,#StartHour[2] DIG 0,#StartMin[2] DIG 1,#StartMin[2] DIG 0]
hserout [#StartHour[3] DIG 1,#StartHour[3] DIG 0,#StartMin[3] DIG 1,#StartMin[3] DIG 0]

hserout [#StopHour[0] DIG 1,#StopHour[0] DIG 0,#StopMin[0] DIG 1,#StopMin[0] DIG 0]
hserout [#StopHour[1] DIG 1,#StopHour[1] DIG 0,#StopMin[1] DIG 1,#StopMin[1] DIG 0]
hserout [#StopHour[2] DIG 1,#StopHour[2] DIG 0,#StopMin[2] DIG 1,#StopMin[2] DIG 0]
hserout [#StopHour[3] DIG 1,#StopHour[3] DIG 0,#StopMin[3] DIG 1,#StopMin[3] DIG 0]

Hserout [dec3 Droptemp[0]]
Hserout [dec3 Droptemp[1]]
Hserout [dec3 Droptemp[2]]
Hserout [dec3 Droptemp[3]]

hserout [#lightsetHR[0] DIG 1,#lightsetHR[0] DIG 0,#lightsetMN[0] DIG 1,#lightsetMN[0] DIG 0]
hserout [#lightsetHR[1] DIG 1,#lightsetHR[1] DIG 0,#lightsetMN[1] DIG 1,#lightsetMN[1] DIG 0]
hserout [#lightsetHR[2] DIG 1,#lightsetHR[2] DIG 0,#lightsetMN[2] DIG 1,#lightsetMN[2] DIG 0]
hserout [#lightsetHR[3] DIG 1,#lightsetHR[3] DIG 0,#lightsetMN[3] DIG 1,#lightsetMN[3] DIG 0]

hserout [#lightoffHR[0] DIG 1,#lightoffHR[0] DIG 0,#lightoffMN[0] DIG 1,#lightOFFMN[0] DIG 0]
hserout [#lightoffHR[1] DIG 1,#lightoffHR[1] DIG 0,#lightoffMN[1] DIG 1,#lightOFFMN[1] DIG 0]
hserout [#lightoffHR[2] DIG 1,#lightoffHR[2] DIG 0,#lightoffMN[2] DIG 1,#lightOFFMN[2] DIG 0]
hserout [#lightoffHR[3] DIG 1,#lightoffHR[3] DIG 0,#lightoffMN[3] DIG 1,#lightOFFMN[3] DIG 0]

I assume if I need to prefix each section to apply the same code to make each set of three digits get placed in the right text box ?

Also how would I modify the PBP code to send S1, S2 etc as part of the data, would it be "hserout [S1,dec3 temperatures[0]]

[malc-c]

Guys and Gals, need your help.

Through an other forum I've had the offer of some assistance from one of it's members. He has written an application (I believe it's in Liberty Basic) and so far we've got it to read the data stream from the PIC and display it in boxes



We're now trying to get the application to send new values back to the PIC and this is where I need some guidance.

This is how he is sending data from the application

This version will send only the target temperatures.
It should send "S" followed by carriage return
Then it should send 12 digits (4 sensors * 3 digits) followed by carriage return
It should then wait 3 seconds to give you time to process stuff, then it will query everything and expect all 108 characters back.
It will then wait 4 seconds, and display what it received.

The PBP code contains the following sections

;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -     
    FOR TempWD = 0 TO 1000
        IF RCIF THEN GOSUB Term_RX                
        PAUSE 1
    NEXT TempWD
;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I've removed the original code that DT had written which displayed PID info via hyperterminal and replaced it with

Term_RX:
 HSERIN [Char]
    SELECT CASE Char
        CASE "S","s"  
Hserin [DEC3 normtemp(0)]
Hserin [DEC3 normtemp(1)]
Hserin [DEC3 normtemp(2)]
Hserin [DEC3 normtemp(3)]
    END SELECT
return

But when the update button is clicked on the PC app the PIC appears to lock up.

I would welcome suggestions on what I'm doing wrong, or what's needed to work with the protocol my friend has evolved.

For reference here is the section that Darrel coded which used to set just one thermostat channel (ie would send just one value ) at a time

Term_RX:
    HSERIN [Char]
    SELECT CASE Char
        CASE "S","s"                            ' Enter Setpoint
            X=1 : Y=22 : GOSUB MoveCursor
            HSEROUT ["Enter SetPoint ... (340=34.0",$F8,"): "]
            HSERIN [DEC SetPoints(EditChannel)]
            GOSUB  TerminalMenu
            SELECT CASE EditChannel
              CASE 0 : Bvar = EE_SetPoint1
              CASE 1 : Bvar = EE_SetPoint2
              CASE 2 : Bvar = EE_SetPoint3
              CASE 3 : Bvar = EE_SetPoint4
            END SELECT

            WRITE Bvar, WORD SetPoints(EditChannel)

I've got a routine within the code that contains SetPoints(0)=normtemp(0) etc so please don't get confused over the actual variables.

[prstein]

This version will send only the target temperatures.
It should send "S" followed by carriage return
Then it should send 12 digits (4 sensors * 3 digits) followed by carriage return
It should then wait 3 seconds to give you time to process stuff, then it will query everything and expect all 108 characters back.
It will then wait 4 seconds, and display what it received

Instead, try:

It should send "S"(single character, no carriage return)
It should wait for the PIC to reply with "K" (or your favorite acknowledge character)
Then it should send 12 digits (4 sensors * 3 digits) followed by carriage return
It should then wait 3 seconds to give you time to process stuff, then it will query everything and expect all 108 characters back.
It will then wait 4 seconds, and display what it received

Then in your main loop add something like:
nTest var byte

If PIR1.5 = 1 Then 'check to see if there is data in the serial buffer
	HSERIN[nTest]
	if nTest = "S" then
		HSEROUT["K"]  'Let the PC know to start sending data
		HSERIN[....all the rest of your stuff...]
	endif
endif

I suspect the PIC appears to lock because it misses a byte. The above slows everything just a little and uses a positive acknowledgement to make sure everything is set.

Hope this helps somehow...

Best Regards,
Paul

[malc-c]

Paul,

Many thanks for the prompt reply.

One further question, in the original code there was the command to WRITE the result

WRITE Bvar, WORD SetPoints(EditChannel)

Would I need to use a similar line to update the normtemp variable with the data received from the PC, or will

Hserin [DEC3 normtemp(0)]
Hserin [DEC3 normtemp(1)]
Hserin [DEC3 normtemp(2)]
Hserin [DEC3 normtemp(3)]

suffice.

Also I'll add Bruce's time out as suggested, but should I also have the PIC send something at the end to tell the PC to signify data recived ?

[prstein]

Hello Malcom,

I confess the line "WRITE Bvar, WORD SetPoints(EditChannel)" doesn't make a lot of sense to me. I guess use it or not, depending on if you want non-volatile storage of the data. Just wait until *after* all the serial data is received as writing to the EEPROM takes (precious) time.

Regarding sending a final acknowledgement to the PC, I probably wouldn't bother if it was working well. Primarily because it can get complicated quickly between the PC program and PIC code, and it becomes extra frustrating if you are only writing one side and someone else is on the other.

Uncle Paul's general advice for serial ports:
0. Use the hardware USART/EUSART whenever possible. The software serial routines work well enough but are far trickier because there is no buffer.

1. Never try to read serial data until PIR1.5 = 1. Otherwise there is no data to be read and the firmware will hang. You can make this an interrupt source but I generally put it as an item in the main program loop.

2. Have the PC application send initially only 1 or 2 bytes of data to get the PIC's attention (because the PIC's serial buffer is 2 bytes so you are GUARANTEED to get that much successfully). Then the PC must patiently wait for the PIC to respond.

3. When the PIC is ready to receive the clump of data ("clump" means greater than two bytes), have it send a character or two back to the PC to signify "I'm ready."

4. After the PC receives the "I'm ready" message it should immediately send the data clump.

I don't work at all with VB or other forms of BASIC for the PC so I can't say anything specific about that. I generally use Delphi or C++, make use of the PC's multi-threading and serial buffer capabilities.

Hope I'm not missing the point here...8^)

Best Regards,
Paul