serial coms - again

[HenrikOlsson]

Hi Malcolm,
I think you need to do:

HSERIN [DEC3 NORMTEMP[0]]

/Henrik.

EDIT: Look at post #22 up above, Paul's already covered it, are you saying that IT isn't working either?

[malc-c]

Hi Henrik,

I've tried that and it does make a difference, it drops it down to 005 rather than 051, so DEC3 tends to shift things one place to the right.

I've changed Pauls suggestion so it displays the bombed out value on the LCD

Term_RX:
    HSERIN[nTest]
    SELECT CASE nTest
    CASE "S"
TempWD = 0
	HSERIN 1000,RX_Bombed,[DEC3 TempWD]
	normtemp[0] = TempWD
	    gosub send    
	RETURN
RX_Bombed:
	lcdOUT $FE,$D4,"all we got was", dec TempWD
end select 
return

And the first time I launched the application and booted the PIC I got a result on the screen. I then entered another value and the LCD reported that it bombed with a result of 0. This happens on all subsequent tries, even with the PIC and application being re-started - it seems I get a result first time the PC application is launched.... but no every time - it seems random.... would reducing the baud rate give better results ?

[HenrikOlsson]

Hi,
I just tried a somewhat modifed version here (to be able to test on my hardware).

Term_RX:
    HSERIN[nTest]
    SELECT CASE nTest
    CASE "S"
       TempWD = 0
    HSERIN 1000,RX_Bombed,[DEC3 TempWD]
    normtemp[0] = TempWD
    gosub send    
    Goto Term_Rx
RX_Bombed:
    TimeoutCount = TimeOutCount + 1
 lcdOUT $FE,1,"all we got was", dec TempWD,", ", DEC TimeOutCount 
 
    end select 
 
    Goto Term_Rx
 
Send:
    HSEROUT [DEC normtemp[0],10]
RETURN

This seems to work just fine when sending from the serial terminal. The only thing is that there will not be a value assigned to TempWd if HSERIN times out, as can be seen it screenshot.

Question is if the problem is with the PIC code or with the PC application....

/Henrik.

/Henrik.

[malc-c]

Question is if the problem is with the PIC code or with the PC application....



/Henrik.

Uhmm I'm beginning to wonder if it's my PC or possibly Vista ?

I modified the code as suggested (removing the parts that were adjusted for your hardware) and using the serial comms in MCS sent S777 and the LCD reported 0 received by the PIC.

[HenrikOlsson]

Hi,
That's weird.... As long as I send Snnn here I can't seem to make it fail. If I send Snn[CR] then it shows nn because apparently HSERIN terminates the reception when it sees the [CR], however if I just send Snn it times out properly. If I then return to properly sending Snnn it works fine again.

Try calling this:

FlushBuffer:
While PIR1.5
 HSERIN [TempWd]
WEND
TempWd=0
LCDOUT $FE,1,"Buffer flushed"
RETURN

At start up and from the timeout routine, it should flush the receive buffer.

/Henrik.

[malc-c]

Well I have no idea what's happening. I added the sub routine at the end of the code and then called it thus

Term_RX:

TempWD = 0
    HSERIN[nTest]
    SELECT CASE nTest
    CASE "S"
    TempWD = 0	
    HSERIN 1000,RX_Bombed,[DEC3 TempWD]
	normtemp[0] = TempWD   
	gosub send

    end select 
    RETURN
RX_Bombed:
gosub FlushBuffer
	LCDOUT $FE,$80
    lcdOUT $FE,$D4,"all we got was", dec TempWD
    LCDOUT $FE,$80 
return


FlushBuffer:
While PIR1.5
HSERIN [TempWd]
WEND
TempWd=0
LCDOUT $FE,1,"Buffer flushed"
RETURN

And the subroutine gets called as part of the initialization before it checks the port in the main program loop. The results when using the serial coms util in MCS were again random. I managed three changes in a row before the LCD reported 0 received. I tried the application written in LB and that too had similar results. I've also tried this application from my Son's PC and got the same result, so that would rule out my PC's port as the issue.

I've re-loaded one of the versions which included code written by DT which uses hyperterm to display data and allow variables to be changed one at a time and that functions just fine so that would suggest the coms on the EasyPIC5 board and the PIC don't have an issues.

One thing I have noticed, When I simplify the code to simply read the variable

Term_RX:
    HSERIN[nTest]
    SELECT CASE nTest
        CASE "Q" 
        gosub send
        CASE "S"
        gosub update
    End select
Return

update:

            HSERIN [DEC normtemp[0]]
            setpoints(0)=normtemp[0]
            gosub flushbuffer:

return

and send say S789 from the serial communicator the LCD changes but displays 007 as if it's picked up the 1st byte and then ignored the rest. If I change the HSERIN line by removing DEC statement the LCD displays 055 ???? - I was expecting at least 078 ???

I would welcome any further suggestions

[HenrikOlsson]

Hi,
Try running it a slower baud rate, just as a test - say 2400 baud.

One thing I have noticed, When I simplify the code to simply read the variable and send say S789 from the serial communicator the LCD changes but displays 007 as if it's picked up the 1st byte and then ignored the rest.

It is because you just say HSERIN [DEC Normtemp[0]] so PBP grabs the first character which is 7 - change that to DEC3 to grab three digits and properly convert it to 789.

If I change the HSERIN line by removing DEC statement the LCD displays 055 ???? - I was expecting at least 078 ???

And this is because you removed the DEC modifier so PBP again grabs one character and 55 is the ASCII code for "7".

You have to remember that the PC (in this case) doesn't send the "value" 789 it sends the the individual digits representing the number as text "S", "7", "8", "9" if you look at that transmision with your serial port monitor you'll see that what is sent is 83 55 56 57 which are the ASCII codes for S789.

The DEC modifier converts the text representation of the value into an actual value. If you remove it the value stored in the variable will be the value received - which is 55 when you send "7".

/Henrik.