[PIC] Pic to Pic communication via external RAM

I would like to transmit data from a pic18f to another pic18f via an external ram . The ram needs to accomadate data from pic1 and transmit it to pic2 when called for ; if possible simultaneously too . The ram size shall be 1-2 Mb .

I have gone through immense application notes on pic to pic communication and pic to external ram communication but failed to get detailed documentation on pic to pic communication via a memory element .

My intention of using RAM is ofcourse for extended space , faster speed , adding option for parallel and serial communication and for independently communicating to pic1 and pic2 .

Hi,

Try to explain more precisely what you want to do. Why and how.

****
Using one SRAM for two microcontrollers is made from time to time.

A single, simple one port SRAM is the problematic, because you need an arbitration for the SRAM access and to switch datalines, address lines and control lines.

A dual port ram is morre easy. But 1-2Mb is very expensive. And here also you need some ( very simple) arbitration, especiall when there is the chance that both controllers use the same address at the same time.

A bidirectional FIFO may be a simple solution, but it depends on your application, if it is useful.

I can think of a solution with two (or more) single port SRAMS combined with an FPGA. You can either switch a complete chip to the one or the other microcontroller, or use some kind of FIFO or DMA access to the "foreign" RAM areas.

****

With AVR, PLD and external SRAM I once managed a continous
* DAC write from SRAM
* read ADC values to SRAM (block)
* block switching (after one block is full), causing an interrupt
* FFT processing the other SRAM block my the microcontroller
Resulting in a continous datastream SRAM to DAC -> analog signal -> back to ADC to SRAM. Without interrruption.

I managed to place the DAC and ADC to SRAM access "inbetween" two AVR SRAM access. So I never run into an access conflict.
****

Klaus

mY intension is taking continuous inputs form the sensors integrated with uC1 ( pic18f) and storing it in the ram , while the uC2( another pic18f) can extrapolate these datas and store it in its internal memory as per its available space and transmit it to PC via ethernet .

It would be helpful if you mention intended data throughput.

i am transmitting 8bit data from uC1 at 1ms to the RAM and the uC2 extrapolates the data from RAM at every sec ; and the data from uC2 is transfered to PC at every minute .

Oscillator with pic is 40MHz . Hence Fosc = 10Mhz approx .

Hi,

It seems this is small throughput (1000 bytes/second). So a UART style data exchange maybe is the eaysiest way.

The SRAM solution is relatively difficult and maybe not be worth the effort.
Even the costs are realtively high, so maybe think of a one microcontroller solution with more processing power (16 bit or 32 bit controller, ARM?)

Klaus

Pls suggest me a cost effective method where by i can carry out communication between uC1 to uC2 via a memory element . I cannot carry out all the requirements in a single controller as the uC2 is involved in lot of things like data processing and communication .

i have to to keep data aquisition to uC1 , and i am bound to use low cost uCs .

which one will be fair and cheap , a parallel RAM , serial RAM or something else whereby both the uCs could access the memory .

i would also prefer a SPI interface in serial if available at low cost .

What's the intended RAM size, 1- 2 Mbit or Mbyte?

The very low data rate allows to multiplex the access from both processors to a single port RAM, either with parallel or SPI interface. SPI interfaced SRAM is presently available up to 4 Mbit capacity.

could you use a USB memory stick and switch it between processors using a switch such as the ISL54200 USB 2.0 High/Full Speed Multiplexer
https://www.intersil.com/en/product...b-high-full-speed-switches-muxs/ISL54200.html

Why the fixation with shared RAM?
As has been pointed out, for the transfer speeds you are wanting, this is a technically difficult approach and therefore will be more expensive in both time and money, not to mention the possibility of being error prone.
There are simpler, cheaper, more reliable methods around (UART transfer has already been mentioned - it is 'tried and true') which from a manufacturing, design and commercial point of view are much better,
Or is this an assignment to have been set?
Susan

Can i write using one uC(1) and read using other uC(2)from the USB simultaneously ?????

uart is slower compared to parallel communication .(even though for my basic requirement it is more than enough )
<and yes its more kind of an assignment .

Hi,

uart is slower compared to parallel communication

Click to expand...

True, but you transmit 1 byte per ms, that is 1000bytes/s so 19200 baud is enough.
even a baud rate of 115200 should be no problem (this is ten times what you need)

A 16k x 8 dual port sram is about 20€ (single piece, farnell), .. but you want MBytes.
128k x 8 serial sram is about the price of a PIC. You need 8 pieces for 1Mbyte.

even with two SPI SRAMs you can´t write and read the same device at the same time. You need some arbitration, wich PIC may have access to the SRAM.
Depending how often you need to do the arbitration, it may need more than the 1kBytes/s of data transfer for the arbitration only.
And then if you switch two devices, you maybe need an additional fixed SRAM at the receiving PIC to copy data..

More expensive, more parts and PCB area, more assembling costs, more programming overhead... i wonder where the benefit is.
1kByte/s can´t be the problem.

Klaus

You mention parallel transfers being faster that serial (UART) - do you have enough pins on both devices to allow for a parallel exchange? If you do (i.e. say 9 lines - 8 for data and 1 for clocking) then you can exchange the values that way, BUT you still need to do a lot of the work in software (as far as I can tell the PIC18F families do not have a PMP like some of the PIC24/dsPIC33 families).
As has been pointed out, a UART (which needs 1 line) running at 115200 baud will transfer the volume of data you are talking about easily (you could transfer 10,000 bytes a second at that rate). If you are worried about the processing involved, the UART is a hardware peripheral so it will do nearly all of the work for you except for writing the value in the first place and using an ISR to receive the value and put it into a memory location on the receiving MCU's RAM.
I suggest that you concentrate on ways to satisfy your your requirements rather that pushing a specific solution.
Susan

KlausST said:

Hi,
A 16k x 8 dual port sram is about 20€ (single piece, farnell), .. but you want MBytes.
128k x 8 serial sram is about the price of a PIC. You need 8 pieces for 1Mbyte.
Klaus

Click to expand...

Yes, dual-port RAMs are extremely expensive.

KlausST said:

Hi,
even with two SPI SRAMs you can´t write and read the same device at the same time. You need some arbitration, wich PIC may have access to the SRAM.
Klaus

Click to expand...

One SPI SRAM would do the job. Both uC can be connected to the SPI lines of the SRAM, but only one can talk to the SRAM at a time. The speed of SPI can go up to MHz, so sharing timeslots should not be a problem. A simple arbitration, e.g. a 2-input AND gate can be used. The inputs of the AND gate go to one pin of each uC, output will go to both uC. The uC that wants to talk to the SRAM will set the input of the AND gate HIGH and check the output whether it stays LOW. This means the bus is free to use for that uC. If the other input of the AND gate is already HIGH (that means the other uC is using the bus) then the output of the AND gate will be HIGH and the uC needs to wait till the other uC releases the bus and sets the input of the AND gate LOW, thus the output of the AND gate will go LOW too.

Hi,

I wonder if your arbitration could work.

You know: writing one byte via uart needs one instruction. (with one byte per ms you don´t even need to check if buffer is full)
Writing to the SPI RAM needs to handle a buffer (in case the SPI is used by the other PIC), some instructions for arbitration, some instructions to enable SRAM, all the SPI transfer for setting address and transferring data.
The waiting for each byte to be transmitted, disable SRAM...
It surely needs way more processing power.

Klaus

KlausST said:

Hi,

I wonder if your arbitration could work.

You know: writing one byte via uart needs one instruction. (with one byte per ms you don´t even need to check if buffer is full)
Writing to the SPI RAM needs to handle a buffer (in case the SPI is used by the other PIC), some instructions for arbitration, some instructions to enable SRAM, all the SPI transfer for setting address and transferring data.
The waiting for each byte to be transmitted, disable SRAM...
It surely needs way more processing power.

Klaus

Click to expand...

I think the same pertains to the UART communication. I don't suppose it will be enough only to write bytes into the UART data register. There will also be need to wrap the data into some kind of protocol with checksum and header which contains some information about the data. Furthermore the receiving buffer in the UART is 1 byte long only, so before the next byte arrives the uC must read and process the received byte in order to prevent data loss.
This requires to implement some kind of acknowledge in the protocol. Using UART in reliable communication isn't so easy.

Hi,

since you talk about two PICs communicating with one SPI SRAM, i think this all is on one PCB. No long distance communication.

Why do you need a protocol? Why checksum, why header?
For one byte per ms you surely don´t need a "receive buffer". Where do you see the difference between a "receive buffer" and the usual SRAM of the receiving PIC? This takes less than 1us. You can do this many hundreds times in one ms.
One simple interrupt driven data receive routine in the PIC and you don´t need any acknowledge.
If you feel unsafe with transmitting data per UART from one PIC to the other, how can you be sure to receive the correct data from the sensor?

UART does need one line of CMOS/TTL level to transmit data form one IC to the other.
For single access SPI you need CLK, MOSI, MISO, SCK. Four wires means for times the chance of an erroneous bit. (UART receiver usually has built in filtering, SPI devices not).
And with SPI you are transferring more bits per data byte (address...), so here also the chance for an error is bigger.

****

If you want to do your "switched SPI SRAM" communication you should draw a schematic. Especially on your arbitration logic and all the SPI signals.

Klaus

If for example 16-bit ADC data is sent over UART, then it is necessary to know which byte is MSB and LSB. When the communication runs error free we don't need any protocol. But what if there happend an short ESD event that caused one byte to get lost. The the order of the data will be switched. Protocol should prevent this.



This is an idea how a communication with the SPI SRAM could work (don't look at uC type and the lines, its only to demonstrate the idea).
I presented the idea with the SPI SRAM because mr_sophisticated did ask for a solution with a SRAM. Personally I would also choose communication over UART or SPI in master-slave mode. but with a protocol to make it more error robust.
1. In idle state both pins PTA1 are set to low, so the output of the AND gate is low. PTA0 is an input.
2. uC A wants to get access to the memory, so it sets to high PTA1.
3. uC A checks pin PTA0 whether it is still low, if yes it gets access to the spi bus and starts to use it.
4. uC B wants to get access to the memory, so it sets to high its PTA1.
5. uC B checks pin PTA0 whether it is still low, but the output of the AND gate is now high (high AND high = high), bus is busy.
6. uC B waits till PTA0 becomes low.
7. uC A has finished communication with the memory, it switches its spi bus lines to high-Z, then set to low PTA1.
8. The output of the AND gate is now low (low AND high = low), uC B takes over the spi bus.
9. uC B finishes communication with the memory, it switches its spi bus lines to high-Z, then set to low PTA1.

Hi,

from OP´s post#5

i am transmitting 8bit data from uC1 at 1ms to the RAM

Click to expand...

All my posts referred to this.
For sure 16 bit transfer is different. But we can only answer to that informations the OP gives us.

****
So we let the OP decide, what he wants to do.

Klaus