What is the best way to talk to a very busy chip?

I have a 28X2 which keeps busy with four continuous tasks, and I want to occasionally change the contents of word variables in that chip from a second Picaxe chip which could be an M2 or X2 chip, or whatever is optimal for the job.

I'm kind of overwhelmed by the various means of doing this and by their various advantages and disadvantages because this is an entirely new area (chip-to-chip comm) for me. The information transfer will happen across wires between two co-located circuit cards.

Is there a single obviously best way to move data into the 28X2 chip which cannot pause very long from its other duties? Advice very much appreciated.

i believe background receive on the X2's may be what you are looking for, i have not used any X2 chips yet but if you type that in the search box it should give you plenty of threads and reading for some time lol

tony

What tony_g says.
Lookup hsersetup in the manual and come back if anything is not clear.
In breif, you can send up to 1023 characters which the receiver can then process when it's suitable to do so.
There are flags which can be configured to "process right now" (interrupt.. see setintflags) or just state "data is available"

If the boards are collocated, the best solution would probably be i2c, with the 28X2 that you refer to configured as the i2c slave.

i2c makes the job so easy: the master chip just reads-from or writes-to selected locations in the 28X2's scratchpad and the firmware does the hard work. The 28X2 just has to read the designated locations its scratchpad to get new data. It can also post data into its scratchpad for the master to read.

tony_g said:

i believe background receive on the X2's may be what you are looking for, i have not used any X2 chips yet but if you type that in the search box it should give you plenty of threads and reading for some time lol

tony

Click to expand...

I tried this... but it's not a true hardware background receive...
So, some commands may prevent main Picaxe from receiving background data. Not very reliable for me.
Never tried slave I2C, but I suspect same problem.
I now use a "Clear to Send Line" and I am happy with that.
For more details, google rs232 protocol... That exist till 1962. They where not so stupid at this date... and computers where extremely slows

BESQUEUT said:

I tried this... but it's not a true hardware background receive...
So, some commands may prevent main Picaxe from receiving background data.

Click to expand...

Can you explain more fully the problems you encountered? I have found background receive on the X2s to be quite reliable (but of course have not tested it in combination with all possible commands). I've also found it reliable for 2-character commands on the M2s.

BESQUEUT said:

Never tried slave I2C, but I suspect same problem.

Click to expand...

No problem with master - slave I2C on scratchpad!
I think it's the best way....

It looks like I2C is what I'll try first and if it's not successful, then a serial solution maybe. Thank you all for your comments -- a little focused discussion goes a long way when reading reams of nonspecific discussion doesn't work well.

There are some foreground commands that hog the CPU. SerOut and SerTxd are two of them. Because they are bit-banged commands, strict foreground timing is required. This can mean that background tasks like clearing the hi2c receive buffer get delayed and bytes lost. Generally, I have not found it to be a problem.

inglewoodpete said:

There are some foreground commands that hog the CPU. SerOut and SerTxd are two of them. Because they are bit-banged commands, strict foreground timing is required. This can mean that background tasks like clearing the hi2c receive buffer get delayed and bytes lost. Generally, I have not found it to be a problem.

Click to expand...

PieM said:

No problem with master - slave I2C on scratchpad!
I think it's the best way....

Click to expand...

That is why, for me, it's not very reliable, but do as you want...
I was trying to receive data at 4800 bauds and retransmit at 19200.
Finally I use an XMega for that (it have a true 2 octets hardware buffer for each channel). Work well with 4 input channels and one out.
With Picaxes, hardware handshaking is very reliable.