Go Down

Topic: Question on Dual MCU system with a memory interface (Read 300 times) previous topic - next topic

oric_dan

#15
Mar 03, 2015, 11:00 pm Last Edit: Mar 04, 2015, 03:51 am by oric_dan
Quote
To me it seems that you want to make some kind of two-headded Frankenstein-Arduino. It is not Halloween, and too early for Aprils-fool-day.
Peter, I see the project as described as having all sorts of useful applications. One processor for acquisition, another processor for processing, another processor for displays, each doing its job, and passing the data along. You could do double-buffering, all sorts of things.

Nowadays, a lot of people would jump to a much faster processor, like an ARM with a lot of RAM and which could do everything in the one cpu, but the system proposed is viable for many purposes.

The basic idea is not too different from what I'm doing with my home automation system, except I am using RF and RS232 for transfers. There are a bunch of Remote Nodes doing data collection, and sending it to a central Hub via 433 Mhz RF. The Hub then consolidates and processes the Remote Node data for transmission to the Base Station, which does displays and Ethernet to Web transfers. Actually, there are now 2 Hubs operating with different sets of Remotes on different RF frequencies. Currently the Hubs send their data to the Base via RS232, but if I had a huge amount of data to transfer, going to such an SPI buss system for transfers would be much more efficient, as the Base has plenty to do on its own time.

The Base Station is sitting there operating the LCD/joystick menuing system, posting tweets, xively updates, and emails to the internet, and also serving local webpages via the router to my Android tablet. With OP's idea, when the Base has its Flag down, the 2 Hubs can dump new data into the shared SPI RAM, and then the Base can look at it when ready, and without having to wait on the Hub transfers. The scheme has lots of possibilities.

EDIT:
This thread actually gave me some new ideas, :-). Eg, this would be a much more efficient way to transfer an "image" from a Remote Node camera via a Hub and then into a buffer in the Base Station SPI RAM, rather than sending it over RS232 from Hub to Base [assuming I can ever get the darn OV7670 camera working right].

OP gets his very first Karma, +1, :-).

westfw

Quote
The data acquisition is done with system A that receives the data at the rate of "0.1 upto 2 second".
The system B needs up to 30 second to deal with every data presented to him by system A.
So every time you lose almost 20 data because the system B is too slow.

So if I had a memory, I would place some data coming from system A there while trying to improve the capacity of system B.
I guess.  Equally, it sounds like a good excuse for using interrupts to read the data, and some sort of foreground task to do the processing.

A big problem is that the small AVRs just don't have an "external memory interface."  Reading or writing to an I2C memory is relatively slow, and may add more complexity than it's worth.

I wouldn't search around for dual-port I2C memories, though, even in a dual AVR situation.  Just attach your memory to the data-collection MCU, and use it as a "smart buffer memory" for the other controller, using SPI, I2C, or some other communications scheme between the two AVRs.


oric_dan

....
A big problem is that the small AVRs just don't have an "external memory interface."  Reading or writing to an I2C memory is relatively slow, and may add more complexity than it's worth.
This is why the main emphasis here has been on SPI RAMs. The 23LC1024 is 8-pin for easy interfacing, has 128 Kbytes of RAM, operates at both 3.3V and 5V, and runs up to 20-Mhz clock rate. Perfect for the microcontroller world. Microchip knew what they were doing when they designed this chip.

CrossRoads

I2C, SPI - either way you need a way to create a bus so multiple masters can access the part.
I2C - maybe slower, but I recall that only 20 bytes were being transferred?
So the bus can just be SCL, SDA, and one more pin that both sides monitor to see if the master is accessing the part.
SPI - fast, no doubt about that.  Both sides need something like HC125 to buffer the CS, SCK, and MOSI outputs and not drive them when not active. CS can be used to  enable the OE pins. And still need a line that both sides can monitor to see if the part is free. I was thinking monitor the other guy's CS, but if the data is being transferred in small chunks, with many chunks to complete, than a separate line would be better.
I suppose if both processors were 1284Ps, with their 16K of SRAM memory each, then the Master could send data to the Slave directly with SPI bus between the two microcontrollers, and the slave could do its processing while master gathered more data ...
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

oric_dan

#19
Mar 04, 2015, 07:58 pm Last Edit: Mar 04, 2015, 08:00 pm by oric_dan
I was figuring maybe only 20-bytes today, but tomorrow it's something else. In my case, I figure I can use the scheme for moving images from the Hub into the Base Station SPI RAM while the Base is doing something else. I hadn't thought about that before, when I was just relying on RS232 for comms between the 2 nodes.

Quote
Both sides need something like HC125 to buffer the CS, SCK, and MOSI outputs and not drive them when not active. CS can be used to  enable the OE pins. And still need a line that both sides can monitor to see if the part is free.
I don't think you really need the buffer as long as you have a good "separate" handshaking system between the 2 nodes to prevent them both from enabling their SPI busses at the same time. The AVR pins can do hi-Z without buffers. Even with the buffers, you still need the handshakes. Plus, I "always" use series-Rs in all my I/O lines, which helps keep 2 pins both set to output from bashing each other. So, the key is really good handshakes between nodes so they don't conflict.

CrossRoads

The devices don't disable their control lines, unless the code goes to extreme steps such as
SPI.end();  // if that exists
pinMode (13, INPUT_PULLUP);
pinMode (12, INPUT_PULLUP);
pinMode (11, INPUT_PULLUP);
pinMode (CS_PIN, INPUT_PULLUP);

and then undo all that before starting a transfer.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

oric_dan

#21
Mar 04, 2015, 09:58 pm Last Edit: Mar 04, 2015, 10:09 pm by oric_dan
I figured as much, although don't consider it necessarily as going to extremes, :-). BTW, this is what the mega328 d/s says this - notice after where I marked:
Quote
19.3.2 Master Mode
When the SPI is configured as a Master (MSTR in SPCR is set), the user can determine the direction of the SS
pin.
If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically,
the pin will be driving the SS pin of the SPI Slave.
If SS is configured as an input, it must be held high to ensure Master SPI operation.

>>>>>>
If the SS pin is driven low by
peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system
interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus
contention, the SPI system takes the following actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a result of the SPI becoming a Slave,
the MOSI and SCK pins become inputs.
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the I-bit in SREG is set, the interrupt
routine will be executed.
Thus, when interrupt-driven SPI transmission is used in Master mode, and there exists a possibility that SS is
driven low, the interrupt should always check that the MSTR bit is still set. If the MSTR bit has been cleared by
a slave select, it must be set by the user to re-enable SPI Master mode.
BTW and FWIW, just 5-minutes ago, I got my silly OV7670 camera working properly for the very first time - capturing real images and displaying on LCD. I may yet use the SPI RAM scheme to advantage, as mentioned earlier. Even noobees can engender really great ideas.
>>>> noobees should be encouraged, not vilified!

Go Up