HSERIN and XOUT command

Printable View

- 9th May 2009, 00:16
aratti

HSERIN and XOUT command

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

Code:

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

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.
- 9th May 2009, 08:23
aratti

Solution

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

Fantastic, but the question remains, why.

Al.
- 9th May 2009, 08:30
Archangel

Quote:

Originally Posted by aratti

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

Code:

' Xout Commands Symbol UnitOn = %10010 Symbol UnitOff = %11010 Symbol UnitsOff = %11100 Symbol LightsOn = %10100 Symbol LightsOff = %10000 Symbol Dim = %11110 Symbol Bright = %10110
- 9th May 2009, 18:25
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.
- 9th May 2009, 19:14
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.
- 9th May 2009, 20:14
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.
- 9th May 2009, 23:44
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:

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.
- 10th May 2009, 00:40
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,
- 10th May 2009, 17:31
aratti

No luck

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.
- 10th May 2009, 20:22
Darrel Taylor

Quote:

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>
- 10th May 2009, 23:43
aratti

Quote:

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)

Code:

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

Quote:

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.

Quote:

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.
- 11th May 2009, 17:54
mister_e

how about get rid of the timeout label and the IF-THEN?
- 11th May 2009, 18:35
dhouston

As written, Xin is blocking. You need a timeout and jump_to_label.
- 11th May 2009, 19:46
aratti

Quote:

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

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

Quote:

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.
- 11th May 2009, 20:03
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.
- 11th May 2009, 20:47
dhouston

Quote:

Originally Posted by aratti

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

Code:

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

Your 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/
- 11th May 2009, 20:59
dhouston

Ooops!

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.
- 11th May 2009, 21:11
aratti

Quote:

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.
- 11th May 2009, 21:21
mister_e

Maybe not

Code:

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.
- 12th May 2009, 01:39
aratti

Steve, this code doesn't work

Code:

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"

Code:

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

Al.
- 12th May 2009, 11:58
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: