serial coms - again

[HenrikOlsson]

Hi,
Changing the FOR-NEXT loop will only change how many times it loops around checking the RCIFlag and therefor the total time it spends waitng for it - not how often it checks it or how many bytes per second that is sent or received.

For 115200 baud you must check the RCIFlag at least once every ~170us so, like I showed you earlier:

For TempWd = 0 to 10000
  If RCIF then GOSUB Term_Rx
  PauseUs 100     '<----Note PauseUs, as in Pause micro seconds...
Next
Goto Main

This will check the RCIFlag every 100us and it will do it 10000 times, so all in all it will wait one second, if no data is received it'll jump to Main.

If you by, the LCD stops updating, mean that the data written to the LCD by the main program in the PIC it's because once the PIC sees the initial RCIF caused by the the "Q" beeing received the main code stops and jumps to your receive routines. It then stays there untill you return to the main program so the LCD can't update....

RX_Bombed:
    TimeoutCount = TimeOutCount + 1 
    end select 
    Goto Term_Rx

Here, you probably don't want to jump back to Term_Tx but instead jump back to either your main program or RETURN depending on how you got to the routine in the first place. That should prevent the PIC from locking up. And you can remove the TeimOutCount thing, that was for my tests....

You need to implement some form of handshaking when the user presses Update in the application, simmilar to when the app is first started. The PC can't just dump data into the PIC since your application may be off doing something else and miss it. (Since you're not using interrupts).

Take a pen a piece of paper, think it thru.

/Henrik.

[malc-c]

Ok I see the logic behind the pause statement.

I've managed to resolve the stalling...

 CASE "Q"
        Goto Term_TX

Just placed that above the CASE "S" and now it works as it should .... strange how the logical things get overlooked !

[malc-c]

Need one final bit of assistance. We've made the changes to the PC application so that it sends the complete string back to the PIC. Q tells the PIC to send data, S tells it to expect data

QS350635250249250250250249250250250249000000000000000000000000000000001501501501500000000000000000Q

This should then populate the variables as follows

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

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

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

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

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

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

[#lightsetHR[0] DIG 1,#lightsetHR[0] DIG 0,#lightsetMN[0] DIG 1,#lightsetMN[0] DIG 0]
[#lightsetHR[1] DIG 1,#lightsetHR[1] DIG 0,#lightsetMN[1] DIG 1,#lightsetMN[1] DIG 0]

[#lightoffHR[0] DIG 1,#lightoffHR[0] DIG 0,#lightoffMN[0] DIG 1,#lightOFFMN[0] DIG 0]
[#lightoffHR[1] DIG 1,#lightoffHR[1] DIG 0,#lightoffMN[1] DIG 1,#lightOFFMN[1] DIG 0]

Now I've used the following to handle the import of things like normtemp etc and that work fine

   TempWD = 0
    HSERIN 1000,RX_Bombed,[DEC3 TempWD]
    normtemp[0] = TempWD   
    SetPoints(0)=normtemp[0]

However I'm having issues formatting the HSERIN sections for the times such as lightsON and Lights OFF and StartHour etc, especially as these are just two digits 00 - 23 for hours and 00 - 59 for mins. MCS reports

Expected ']'

but it doesn't hell me where, and adding them to most logical places (like at the end) still results in similar errors

Any ideas ?

[malc-c]

Any reason why

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

compiles, but

hserin [#StartHour[0] DIG 1,#StartHour[0] DIG 0,#StartMin[0] DIG 1,#StartMin[0] DIG 0]

Throws up an "expected ]" error. I've tried adding ] to nearly all possible permutations and still can't get it nto compile

[Jerson]

Hi Malc_c

I was curious to see this thread and got into this pretty late.

How big is the serial data packet that you send down to the PIC?
From the details you gave, I think you have problems PC->PIC (downstream)
If that is true, are you buffering your received characters on the PIC? If not, then the least you can do is make the PC space out the characters in time. Put a few mS gap between each character sent to the PIC to avoid losing characters on the PIC
How do you synch the receive to the start of the incoming stream of data? Do you have a synch character to look for?
It will be better to look over the whole code to find the problem.

Regards

[malc-c]

Hi and thanks for the advice. The PC application simply send "Q" to the PIC every 10 seconds. The PIC responds to the Q by sending the 100 odd digits for the variables as described in previous posts above. When the application is used to update or set the PIC, the application has an "update" button which sends an "S" followed by the same 100 odd digits, followed by a "Q" to read back the values just written. The application does not send variable data to the PIC at any other time.

I agree that it's difficult to diagnose what might be happening without the complete code - please drop me a PM with an e-mail address and I'll mail you the code.

[Jerson]

Hi Malcolm

PM sent. Just in case you don't get it, you can PM me

Regards

[HenrikOlsson]

Hi Malcolm,
You can get that error message when you've missed a comma somewhere in the HSERIN command, look carefully and I think you'll find it.

Anyway, I took a stab at it here and I think the following should do it:

'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 NormTemp[Counter]]
NEXT
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 AlarmLow[Counter]]
NEXT
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 AlarmHigh[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 StartHour[Counter], DEC2 StartMin[Counter]]
NEXT
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 StopHour[Counter], DEC2 StopMin[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC3 DropTemp[Counter]]
NEXT
'-------------------------------------------------------------------------------
'-------------------------------------------------------------------------------
For Counter = 0 to 3
HSERIN 1000, RX_Bombed, [DEC2 LightSetHR[Counter], DEC2 LightSetMN[Counter]]
NEXT
'-------------------------------------------------------------------------------

It seems to work, I wrote up a bit of code to re-send all the variable back to PC and it looks like in the attached screenshot. Note that I'm only sending the "S" and I'm not waiting for that final "Q" in your datastream.

/Henrik.

PS. Here's the code I used to send everything back to the terminal, might be good for further debugging:

HSEROUT ["-------------------------------",10]
For Counter = 0 to 3
    HSEROUT ["Normtemp ", #Counter, "   : ", DEC3 Normtemp[counter],10]
    HSEROUT ["AlarmHigh ",#Counter, "  : ", Dec3 AlarmHigh[Counter],10]
    HSEROUT ["AlarmLow ",#Counter, "   : ", Dec3 AlarmLow[Counter],10]
    HSEROUT ["Start ",#Counter, "      : ", Dec2 StartHour[Counter],":", DEC2 StartMin,10]
    HSEROUT ["Stop ",#Counter, "       : ", Dec2 StopHour[Counter],":", DEC2 StopMin,10]
    HSEROUT ["Droptemp ",#Counter,"   : ", DEC3 Droptemp[counter],10]
    HSEROUT ["Light set ",#Counter, "  : ", DEC2 LightSetHr, ":", Dec2 LightsetMn,10]
    HSEROUT ["-------------------------------",10]     
Next 
HSEROUT ["T H A T ' S   I T   M A L C O L M",10,10]

[HenrikOlsson]

Hello again,
I didn't see your latest message before posting my previous.

It's not a comma missing in your HSERIN statement, however I don't think DIG can be used with HSERIN, only with HSEROUT - I think.

[malc-c]

Henrik,

As always, thanks for your help - that works a treat - THANK YOU !!!!!

[malc-c]

Just thought you might like to see the final result. I just hope that others searching or working on serial communications can make use of all that has gone on in this thread

[malc-c]

Maybe I spoke too soon - seems that something corrupts the LCD after a set number of transfers.

Basically the PC applications sends a "Q" every 10 seconds which causes the PIC to respond by sending the stream of digits described above. On the 27th Q the LCD starts to display random characters, initially along the bottom line of the 4 line LCD.

Thinking it might be the application I used the serial port coms app from MCS and manually sent Q's to the PC. on the 27th the same thing happened....

Any ideas on where to start de-bugging ?