background + regular serial

[BeanieBots]

I recall a recent thread that suggested that there were some commands which could impair background serial.
Is it possible to continue receiving serial data in the background whilst also waiting for 'regular' serial on another input?

 

[srnet]

I recall a recent thread that suggested that there were some commands which could impair background serial.

Which thread was that ?

You would assume that 'background' serial would keep on working in the 'background'.

I have noticed that the data recieved from a GPS in bacground recieve mode is on ocaision corrupted, but I have yet to identify why.

 

[BeanieBots]

I don't recall the exact thread but do recall some chat about it.
There is mention that commands such as ReadTemp can effect background tasks. (frequency change during command and interrupt inhibit)
I'm also aware that there is a slight difference between the function in M2 and X2 parts. My interest is in X2.

 

[Technical]

Background serial is carried out by a separate internal silicon module, completely separate from the main processor/firmware, so yes it is not affected by regular serial.

However the silicon buffer is only two bytes deep, so the firmware needs to react to the received byte and clear this buffer as soon as possible, in X2 parts this is carried out by the firmware moving the data into the scratchpad. So the issue is not so much detecting and receiving the background data itself, it is the firmware being able to keep the background 2 level buffer empty in time for the next background byte to be received.

So how many bytes do you need to receive and what else is going on?

 

[BeanieBots]

Thanks for the clarification.
My plan is to have a string of 28X2 each reading a set of sensors (including DS18B20s and maybe I2C involved as well)
There will be some basic decisions and actions based on sensor values.
Meanwhile, each 28X2 will need to receive 'commands' in the background, passing the command on (and maybe modifying it) to the next 28X2 in line.
Some sensors output serial (typically 8-10 bytes) which will be received by 'regular' serin with timeout to avoid locking up if no sensor input.
The idea is that the sensors (and processing the data) takes priority while commands accumulate in scratchpad and get processed when time is available.

 

[inglewoodpete]

I have some (painful) experience in this area. I was having some trouble with incoming data to the hSerial port, so tried to log it via the SerialOut pin to see what was being received. The SerTxds caused corruption to the incoming hSerial data. Big mistake but Technical set me straight at the time.

The difficulty with combinations of background serial reception and foreground serial (in or out) is that firmware interrupts must be disabled so that the strict timing of the foreground task can be controlled. If these interrupts are needed to clear the hardware receive buffer, then there is a risk that the incoming serial buffer could be overwritten as further data is received.

As Technical mentioned, it depends a lot on how many characters are being received on either serial port (or sent on the bit-banged port). Also, the speed of the data can have an effect. You may be able to break up your 'commands' into smaller data packets or swap the ports, depending on the priority of the data streams.

One for the wish-list: Could the firmware of the 28X2 be enhanced to utilise both hardware serial ports on the PIC18F25K22? I guess it would complicate the use of the scratchpad.

 

[BeanieBots]

Thanks for the heads up ip.
Your issue is what I was sort of expecting. Fortunately, the incoming data is under my control so I can put delays between each character which hopefully will remove the problem.
Alternatively, I'll put in some flow control so only one stream comes at any one time.