Background serial + blocking serial

[BeanieBots]

A quick question to save me having to try it.

I have two 28X2's that need to talk to each other.
The first one receives and sends data to/from a PC via Bluetooth using hserin/hserout. This works fine.
Some of that data needs to be passed on to a second 28X2 and a reply is also required.
I had been using I2C for this but I now need to put more physical distance between them and I2C would not work.
I'm now thinking of using RS232 serial but I have a concern that using 'regular' serial (blocking) will interfere with the background serial.

So, simple question.
Can 'regular' serial and background serial work together nicely?
If yes, are there any caveats?
eg.1. if 28X2 is waiting for data using blocking serial (not on hserin), will the background serial continue to receive OK?
2. If 28X2 is sending serial data (on pin other than hserout), will background serial receive continue OK

I could implement an Xon/Xoff system for the background serial but would prefer not to as I'm getting low on code space and it would also require changes to the PC side of things.

If anyone has any experience of trying this, any hints/tips much appreciated.

 

[hippy]

If 28X2 is sending serial data (on pin other than hserout), will background serial receive continue OK

Any SERIN, SEROUT or other command requiring dedicated timing will potentially block handling of background serial. A couple of bytes may be received and buffered in internal hardware registers, but any more than that and data will be lost if the command has not completed execution before they arrive.

Using SEROUT to send single bytes, at higher baud rate, with background receiving at a lower baud rate, will increase the chance of getting all data.

 

[BeanieBots]

Ok, thanks for quick reply.
So, am I correct that the bigger issue is when sending data?
I can get around that by only sending one char at a time with a pause between each one.
The hardware should be able to buffer TWO characters on background receive, so if I make the pause between chars long enough, it should all end up in scratchpad. Is this assumption correct?

Will background receive work OK whilst also receiving on another line?
To be more precise, will data find it's way to scratchpad while the PICAXE is waiting for serial to arrive on another line?
(I can arrange for both data inputs to have long pauses between characters)

 

[hippy]

I believe it should work as envisioned, and you shouldn't need pauses between bytes sent; the firmware will put bytes into its buffer then moves those buffers to scratchpad between commands, it's during execution of timed commands that move to scratchpad part gets suspended.

That's also why SERIN on another line can get tricky if no serial is coming in on that line because it can block the move into scratchpad.

 

[BeanieBots]

Ok, thanks.
I fully get the not moving bytes to scratchpad during the actual character send because it's timing critical.
The bit I was not sure about was while it was waiting for serial data on another line.
I think I will need to implement Xon/Xoff after all.

Both PICAXEs are running servo loops and continually reading sensors.
The PC can send (at any time) a state change for the servos or a request to send sensor data.

The sequence I have concerns about is as follows:-

1. PC sends "get data request" to PICAXE_1 (background serial)
2. PICAXE_1 determines that the requested data needs to come from PICAXE_2
3. PICAXE_1 sends "get data request" to PICAXE_2 (PICAXE_2 receives this as background serial)
4. PICAXE_1 then executes serin command (with timeout to avoid locking up) and waits for PICAXE_2 to send requested data.
5. As soon as it has time (could be up to 800mS delay), PICAXE_2 sends the data to PICAXE_1
6. PICAXE_1 then passes the data back to the PC.

Unfortunately, the PC could issue a new command to PICAXE_1 during step 4.
I think I need to send Xoff to the PC between 3 & 4 and then Xon between 5 & 6 or if there has been a timeout.
(or maybe just an Xoff with the PC sorting out a timeout to avoid problems if Xon is never received)
I suppose I could put another 28X2 as a serial buffer between the PC input and PICAXE_2 with hardware handshaking between PICAXEs but that seems a bit overkill.
Open to other suggestions. Both PICAXEs are very busy and commands from the PC are only to be processed when time permits.

The issue is how to have PICAXE_1 still capable of receiving commands from the PC while it waits for data to come back from PICAXE_2.

 

[hippy]

Yes, I think you will need X-On/X-Off or some sort of handshake protocol to tell the PC "not now, or I'll miss it", or have the PC not send anything until it has had the previous request fulfilled.

One trick could be to have a multi-drop RX to the PC so #2 talks directly to PC once instructed to respond. That allows the PC to keep communicating with #1 when there are no replies required.

You could add some kind of arbitration so both #1 and #2 can reply but won't corrupt each other.

 

[BeanieBots]

I think there are several ways to skin this cat but the important thing is that I now know which issues are waiting to bite!
It might even be as simple as not allowing the PC to send any new commands within X mS of the previous one.
The proof will be in the testing. Off to build the hardware........
Thanks very much for your help.

 

[techElder]

Don't forget. There are also I2C extenders.

 

[BeanieBots]

Don't forget. There are also I2C extenders.

I had toyed with that idea but decided against it. Might revisit though if 232 does not want to play nicely.

 

[jsmanson]

I have had good success with a 5 volt I2C extender (P82B715) using about 150 feet of Cat5 with 2 40x2's talkng to each other. (one talking, the other one setting an interrupt line to ask the other one to 'please talk'. Using i2c slow though, haven't tried i2c fast. If this helps.

 

[BeanieBots]

Thanks but I've ruled out I2C because I'm already using a fair amount of it on the main board already and don't want it compromised.
The final solution was to use a MAX232 giving Rx & Tx pass-through with diode OR'd multidrop on each node board.
The PC gets given an Xoff whenever one of the nodes wants to talk and then self times out so no need to send Xon.
Things are so much easier and nicer when you have control of both ends of the comms!