HSERIN and XOUT command

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

[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

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

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