HSERIN and XOUT command

[aratti]

I am facing a singolar behaviour using a pic 16F628 working @ 3.3 Volts.

I am receiving a string of 9 characters via Xbee, the string is serially collected in an array using HSERIN command. The string is than decoded and an X10 command is generated via XOUT. Everything work fine only for two strings sent, with the third string the HSERIN doesn't work anymore, I need to reset the pic to get HSERIN to work again (but still for two strings only)

Using SERIN2 the problem disappear and the system works fine, but since I want to use the chip USART capability, I did try to understand the reason for such a behaviour, but with no luck.

Here the USART setting

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 25 ' 9600 Baud @ 4MHz, 0,16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically


Here the X10 command code


High TxEnable ' enable pwr line transmission
pause 5
Xout X10Tx,Zcrox,[House\Unit,House\Unit2]
low TxEnable


Does anybody know if there is any incompatibility between the two commands "HSERIN and XOUT"?

Al.

[aratti]

Adding to the code : INCLUDE "Modedefs.bas", HSERIN and XOUT now work!

Fantastic, but the question remains, why.

Al.

[Archangel]

Adding to the code : INCLUDE "Modedefs.bas", HSERIN and XOUT now work!

Fantastic, but the question remains, why.

Al.
Hi Al, if you open MODEDEFS.BAS you find the following code

' Xout Commands
Symbol UnitOn = %10010
Symbol UnitOff = %11010
Symbol UnitsOff = %11100
Symbol LightsOn = %10100
Symbol LightsOff = %10000
Symbol Dim = %11110
Symbol Bright = %10110

[aratti]

Hi Joe, thank you for your reply.
My perplexity still remain, I don't think anything in MODEDEFS.BAS can interfere with HSERIN command.

The XOUT command was working without MODEDEFS.BAS file (because I am using my own X10 coding), the only problem was that I had to use SERIN2 instead of HSERIN .

Al.

[Archangel]

Hi Al,
It was HSERIN that didn't work . . . Thought it was the x10 code . . . I should have read it through . . . might have something to do with the RX ports idle state, perhaps the code in modedefs.bas affected it that way. I DO know hserin likes to idle high.

[mister_e]

Are you using the TX pin for XOUT? If so, yes It may give you some weird problem, because XOUT may try to modify the TRIS setting, and/could disable the USART.
Try
RCSTA=0 before XOUT
RCSTA=$90 after Xout
and see how good, worst it is.

From what I know, there's no good reason why MODEDEFS should solve the problem. If it wasn't there, you would probably have some compilation error but not much.

[aratti]

Thank you Joe and Steve,
Pins RB1(Rx) and RB2(Tx) are used to service the serial connection with the Xbee module. Xout uses pin RB6; Xin uses pin RB4 and zerocrossing is on pin RB6. Here the code:



INCLUDE "Modedefs.bas"
INCLUDE "DT_INTS-14_2.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP.bas" ; Include if using PBP interrupts

CMCON = 7

TrisA = %00000000
TrisB = %00110010
PortA = 0

DEFINE OSC 10

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 64 ' 9600 Baud @ 10MHz, 0,16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

XbDtr var PortB.0
XbRts var PortB.3
XbSlp var PortA.3

Pwr var PortA.0
Led var PortA.1
Buz var PortA.2

X10Rx var PortB.4
ZCrox var PortB.5
X10Tx var PortB.6
TxEnable var PortB.7

high Pwr
high XbSlp
low TxEnable
low XbRts
Low XbDtr

A0 var Byte
House var byte
Unit var Byte
Job var Byte
Decode var byte
Pass var byte

Rdata var Byte[10]

HouseKey var word

'--------------------------- Rx DT interrupt definition -------------------
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RX_INT, _Getbytes, PBP, no
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

@ INT_ENABLE RX_INT ; enable RX_INT interrupts

'-------------------------------------------------------------------------

gosub Buzzer


Main:
pause 1
If Rdata[0]=250 then loop
goto main

Getbytes:
Hserin 100,ErrorFlag,[str Rdata\9]
High led

If Rdata[0]=36 then
House = ((Rdata[4]-48)*10) + (Rdata[5]-49)
Unit = ((Rdata[6]-48)*10) + (Rdata[7]-49)
Decode = Rdata[8]-48
If decode = 1 then Job = 18 : Pass = 1
If decode = 2 then Job = 26 : Pass = 1
If decode = 50 then Job = 20: Pass = 1
If decode = 51 then Job = 28: Pass = 1
gosub TxCommand
endif
Pass=0
Low led
@ INT_RETURN

ErrorFlag:
RCSTA.4 = 0
RCSTA.4 = 1
Pass=0
low led
@ INT_RETURN

TxCommand:
If Pass=0 then return
High TxEnable
pause 1
Xout X10Tx,Zcrox,[House\Unit,House\Job]
low TxEnable


Buzzer:
high buz
pause 20
low buz
return

Loop:
xin X10Rx,ZCrox,[Housekey]
hSerout ["H: ",#Housekey.byte1,13,10]
hserout ["K: ",#Housekey.byte0,13,10]
goto loop


Now the code works with the exception of HSEROUT that I was anable to get it to work in the "Main" loop. I had to make the trick to jump in a secondary loop "LOOP" to have it working, but if I re-enter the "LOOP" the second time then HSEROUT doesn't work anymore. There must be something effecting the USART setting using Xin and Xout command.

I should mention once again that pic16F628 is working @ 3.3 Volts. No compilation errors without Modedefs.bas file.

Any tip will be welcome!

Al.

[Darrel Taylor]

Hi Aratti,

This could be a problem.

In the Main loop, actually Loop:, there is an XIN statement that runs on every loop. Then if you receive data in the interrupt handler, the TxCommand is called which does an XOUT. The XOUT could potentially be triggered in the middle of the XIN. Possibly leaving XIN waiting for something it will never receive.

That could keep the HSEROUT's from being executed.

If you set a "flag" in the interrupt handler when it receives data, then do the XOUT in the main loop when it sees the flag, it won't try to do both XIN and XOUT at the same time.

Added: You may also need to have the RX interrupt receive bytes 1 at a time instead of a full string, to keep it from interfereing with the XIN to begin with.

hth,

[aratti]

Hi Darell, thank you for your answer. I did try your suggestion without any luck.
In doing these changes I came to the conclusion that Xin command is the problem, infact simply removing Xin from the code and Txing numbers with a For/Next loop everything work fine. As soon as I enable Xin the problem is back again.

At this time it seems I have got only one bullet left "use two pics" one for Xin and one for Xout.

Al.

[Darrel Taylor]

I did try your suggestion without any luck.
Did you also change the RX handler to receive only 1 byte at a time? Waiting for a whole string takes a LONG time.

And, have you tried the XIN without the interrupts? Is XIN working at all?
You can add a Timeout to XIN, in case it's not receiving anything.

Is the XIN supposed to be running continuously in a loop, or as a response to the 250 command?
If it was in response to the command, it's more likely that incoming data will not occur again in the middle of the XIN.
<br>

[aratti]

Did you also change the RX handler to receive only 1 byte at a time?

Yes I did But it doesn't work very well. A command must be sent twice or three times to be executed, while with the whole string method commands are all decoded and executed correctly at the first time. Very likely my code is not so efficient as the whole string.

Here the code used: (Where : RxBuffer VAR PIR1.5)

Getbytes:
A0=0
While RxBuffer=1
Hserin 100,ErrorFlag,[Rdata[A0]]
A0=A0+1
Wend
@ INT_RETURN




And, have you tried the XIN without the interrupts? Is XIN working at all?

Yes with "SERIN2/SEROUT2" did work, not with "HSERIN/HSEROUT". But as you can understand, I need to jump out from Xin loop when an X10 command is received via Xbee in order to service it with the Xout command.



Is the XIN supposed to be running continuously in a loop, or as a response to the 250 command?

Xin is supposed to continuouly scan the main for X10 commands coming in from the different sources capable to issue such a command. The incoming data will be used to update a memory area containing the status of various lamps and appliances (On/Off).

Al.

[mister_e]

how about get rid of the timeout label and the IF-THEN?

[dhouston]

As written, Xin is blocking. You need a timeout and jump_to_label.

[aratti]

how about get rid of the timeout label and the IF-THEN?

Steve, are you refering to the code in my post#11?



As written, Xin is blocking. You need a timeout and jump_to_label.

dhoston, Xin is blocking the USART with and without the timeout

Al.

[mister_e]

yes I do (and so Darrel @ post #8). Anyway, if you jump to that ISR... your buffer already hold something.. so there's no real advantage to the Timeout, then no advantage to whatch PIR1 either. You get the character, you get out of there as fast as possible, if there's a second character, you'll be redirected over there shortly.

That Is easy to do that in asm. So it will be faster again, and give you less latency in XOUT... so probably solve most part of the problem.

You could still get rid of HSERIN and read RCREG directly.

[dhouston]

dhoston, Xin is blocking the USART with and without the timeout
Loop:
xin X10Rx,ZCrox,[Housekey]
hSerout ["H: ",#Housekey.byte1,13,10]
hserout ["K: ",#Housekey.byte0,13,10]
goto loopYour XIN will wait forever for an input. You can add a timeout and label to XIN but it does not solve the problem.

PBP is not a good choice for doing X10 because of this. You either need a dedicated loop that does nothing but wait for X10 input or risk missing the X10 input. Unless you can write a interrupt routine to check for input 500µS after each ZC you should look for another solution.

As it happens, I am currently working with the creater of ZBasic to refine its X10 functions. It does X10 input and output in the background automatically, including collision avoidance. The refined version should be available in a couple of weeks.

The smallest ZBasic chip costs $10 but may not have enough program memory for you. I haven't really analyzed your code.

ZBasic uses Atmel AVR chips. It has a serial bootloader and a free IDE/compiler. It has a hardware UART and up to 4 full-duplex, interrupt driven, software UARTs that operate in the background. It also has many other features but the smallest chip is 28-pins. http://www.zbasic.net/

[dhouston]

ZBasic does collision avoidance in the application I am working on. It cannot do collision avoidance with the TW523 (and clones) as the TW523 X10 outputs are delayed 22 ZC cycles and any detected collisions have already occured - only Dr. Who could avoid them. But we can detect them with the TW523.

[aratti]

You get the character, you get out of there as fast as possible, if there's a second character, you'll be redirected over there shortly.


Steve, in this case I must change sligthly the Tx string, adding a terminator character.

The code as it is, using "Hserin 100,ErrorFlag,[str Rdata\9]" works perfectly and Xout do the job.
I have got away from the trouble when I did remove the "XIN" command.

I am sure that XIN and Hserin/Hserout are not compatible for unknown (so far) reasons.

Since I need also the XIN, I am putting togheter a second prototype with two pics on board, so I will separate XIN/SEROUT2 commands, from Hserin/XOUT (Hardware solution to the problem)

Al.

[mister_e]

Maybe not


YourArray[YourCounter] = RCREG
If YourCounter !=9 then
YourCounter=YourCounter+1
ELSE
NewDataIsReady = 1
ENDIF
a bit of work around the above could work. IF so, then yes maybe there's a conflict between XIN and HSERIN... I don't see where, appart if a Timeout is used on both... or some Systems vars are shared... and if so, they're saved/restore by DT INTS... maybe there's one missing in DT list... but I have some reasonable doubt about it.

[aratti]

Steve, this code doesn't work


Getbytes:
Rdata[A0] = RCREG
If A0 !=8 then
A0=A0+1
ELSE
DTReady = 1
ENDIF
@ INT_RETURN

This one works. But cannot appreciate any difference in speed, perhaps what is gained here is lost in the two variables check:
"IF Rdata[0] = 36 and DTReady = 1 then"


Getbytes:
Hserin [Rdata[A0]]
If A0 !=8 then
A0=A0+1
ELSE
DTReady = 1
ENDIF
@ INT_RETURN

Al.

[mister_e]

If you don't have any HSERIN/HSEROUT in your code, you must write to the register RCSTA/TXSTA/SPBRG instead of using DEFINEs, probably this why It doesn't work.

Not sure of the overhead though... Would be great to have some X-10 device here... never messed with that before. Sure enough, I can't afford to buy any for now :mad: