serial coms - again

[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.

[malc-c]

Full Code:

ASM 
  __CONFIG    _CONFIG1H, _OSC_HSPLL_1H
  __CONFIG    _CONFIG2L, _PWRT_ON_2L  
  __CONFIG    _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
  __CONFIG    _CONFIG3H, _PBADEN_OFF_3H
  __CONFIG    _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
ENDASM


DEFINE OSC 48                     ; uses 12Mhz xtal

ADCON1 = $0F
clear

DEFINE LCD_DREG  PORTB           ' LCD Data port
DEFINE LCD_DBIT  0               ' starting Data bit (0 or 4)
DEFINE LCD_EREG  PORTB           ' LCD Enable port
DEFINE LCD_EBIT  5               '     Enable bit  (on EasyPIC 5 LCD)
DEFINE LCD_RSREG PORTB           ' LCD Register Select port
DEFINE LCD_RSBIT 4               '     Register Select bit   (on EasyPIC 5 LCD)
DEFINE LCD_BITS  4               ' LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 4               ' number of lines on LCD
DEFINE LCD_COMMANDUS 2000        ' Command delay time in us 
DEFINE LCD_DATAUS 50             ' Data delay time in us 


;----[Port settings]----------------------------------------------------

TRISA = %11001111
TRISB = %00000000
TRISD = %00001111
CMCON = 7                                       ' disable Comparators

;----[USART defines]--------------------------------------------------------


DEFINE HSER_RCSTA 90h                           ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h                           ' Enable transmit, BRGH = 0
DEFINE HSER_CLROERR 1                           ' Clear overflow automatically
DEFINE HSER_SPBRG 25                            ' 115200 Baud @ 48MHz, 0.16%
SPBRGH = 0
BAUDCON.3 = 1                                   ' Enable 16 bit baudrate generator
ColumnWidth CON 10


TempWD            VAR WORD
RCIF              VAR PIR1.5                    ' USART receive flag
GIE               VAR INTCON.7

tr var byte


  
normtemp          VAR WORD[4]                   ' used to store the desired temperature setting
  normtemp1       VAR normtemp[0]
  normtemp2       VAR normtemp[1]
  normtemp3       VAR normtemp[2]
  normtemp4       VAR normtemp[3]  

nTest var byte
temphold var byte
temp var byte

TimeoutCount var byte
;---------------------------------------------------------------------
 
;set test values

  
normtemp[0]=240
normtemp[1]=250
normtemp[2]=260
normtemp[3]=270



  ;______________________________________________________________


gosub FlushBuffer

main:

FOR TempWD = 0 TO 1000
        IF RCIF=1 THEN GOsub Term_RX
        PAUSE 1
NEXT TempWD

pause 200
goto main



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]
    setpoints(0)=normtemp[0]
    LCDOut $FE,$D4,#setpoints(0)dig 2,#setpoints(0)dig 1,#setpoints(0)dig 0
RETURN


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

I tried this at 2400 baud (having use PIC multicalc to get the Uart setting) and it gave one error and then echoed all the subsequent entry's correctly. I then changed it back to 115200 and it works a treat - even with my friends application.

Henrick thanks for taking the time out to assist me with this, and for explaining the serial function in laymens terms, I have learnt a lot from your posts.

Now just got to amend the code so that it does the same for all the other variables

I think Charles was going to have his application send one long string of all the variables, maybe I should ask him if he can make it user selected so it updates just the one ?

[malc-c]

Uhmmm strange things.. I spoke too soon.

If I follow your example code

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

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

when the program 1st runs and detects somthing in the buffer it gosubs to Term_RX, but with the goto hi-lighted above the program then never returns to the main program... If I change this to go to main I'm back where I started from...

I guess I should ask Charles to design his application so that it opens a second window to do the updates, and when it opens that window it sends a Q or P or something which makes the PIC jump to the Term_RX section, and then sends another character when the updating window is closed (sort of click APPLY )