Solved :Sharing External eeprom

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible more than one microcontroller share one external eeprom?

I'm not satisfied with what Google said

This topic has a solution.

Salman

Last Edited: Wed. Mar 29, 2017 - 08:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What did Google say?
In general, having more than one master of a shared object - especially hardware makes things a bit trickier. Obviously, only one master can access it at a time, so you need to provide a mechanism to ensure this happens.
Personally, i'd suggest you rethink your strategy.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes it is possible.

 

A simple solution is to use a dual port eeprom: http://www.onsemi.com/PowerSolutions/product.do?id=CAT24C208

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that one eeprom with one port can be shared by using multiplexers
Can I use like this?

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why did u ask to rethink?
Is it difficult or any drawback

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

salmanma6 wrote:
by using multiplexers
It doesn't really need anything that complex as long as the two potential masters have some agreed protocol by which each can warn the other that it is in control.

 

One (very simplistic) way would be for the two to have an output line as an input to the other. A master that is "using" the EEPROM perhaps pulls his output low (or high - your choice) to say "I'm using it at the moment". The other reads his input first before going near the EEPROM if he finds the line active he backs off until it is set inactive by the other master.

 

There is the question of "contention" for any data/signal lines going from the AVR to the device of course. The non-active master should always tristate its lines to the device when it is not taking control. I suppose you COULD employ a multiplexer for this purpose.

 

Life is LOT (lot, lot, lot!) simpler if you only employ one CPU in the design !!! Is there some reason you are contemplating two?

 

If there has to be two CPUs then why does the EEPROM need to be attached to both anyway? Why can't you have the EEPROM attached to only one CPU and then, over some comms link (that you probably have between the CPUs anyway) the EEPROM controlling CPU offers a read/write "service" that the other CPU can call upon. So it can say "write data X to location Y for me" or "tell me what is contained in location Z".

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Define CPU here

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm really not sure .whether following is correct or not
Here is the schematic using multiplexers

Attachment(s): 

Salman

Last Edited: Tue. Mar 28, 2017 - 04:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The answer depends on whether the EEPROM is parallel or serial, and if serial, whether it is SPI or I2C. Give us a part number and you will get more help!

 

By the way, the issues are the same, whether it is RAM or ROM or EEPROM. Nothing unique, there. And, please tell us a bit more about why you wish to do this. There may be other solutions that are a LOT simpler.

 

Don't see any schematic in your previous post!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Mar 28, 2017 - 04:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I2c

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That will work in the very simplest case. However, you have one more mux than is needed - with I2C, only SCL and SDA need to be multiplexed.

 

How does the multiplexer control device know when to change the multiplexers? Suppose that one device is accessing the EEPROM and the control device decides to give a different device access in the middle of a transfer (read) by the first device? That data will be corrupted. There is no (easy) way for the control device to know when a transfer is happening by looking at the state of the I2C bus because the logic is static and it can be arbitrarily slow. So, whether or not it will really work depends on what the control device is and how it knows the status of the bus.

 

That is really a "sub-optimal" system. And I am being charitable, here. You have not told us why you think this is needed.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Mar 28, 2017 - 04:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

salmanma6 wrote:
Define CPU here
CPU = Central Processing Unit. Some people just call them "computers".

 

A mega328 is a CPU. A tiny85 is a CPU etc.

 

A CPU consists of an ALU (Arithmetic Logic Unit) and some registers to work with it. There's also usually some kind of finite state logic that is responsible for the fetch and execution of opcodes that drive the ALU+registers.

 

You may also call them MCU (Micro Controller Unit). That is generally a CPU that also has some peripherals attached to it in the same chip. Perhaps also some RAM and ROM/flash also attached.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Since no one else has mentioned it) Do Not Multiplex the GNDs!

GND should be common throughout the system.

 

As has been mentioned, you will need to have some form of arbitration to determine who is allowed to access the EEPROM, and I believe that having each uC (micro controller) float its control signals when not active should be sufficient.

 

Remember, I2C is a bi-directional bus, so unless those are bi-directional multiplexers none of the uCs will be able to read the EEPROM...

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need to multiplex anything.   The I2C bus can have multiple Masters and multiple Slaves.

 

Handling multi-Master is a bit tricky.   If you know that another Master is not active,  you can just assume that you are the single Master.

 

I2C is normally a single pcb with one Master and one or more Slaves.    Do you really have two CPUs on the same pcb?

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:

 bi-directional multiplexers 

multiplexers are generally bidirectional on the fact that they can be used as demultiplexers.

https://en.wikipedia.org/wiki/Mu...

third paragraph last line

 

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

salmanma6 wrote:
multiplexers are generally bidirectional

Not unless you are talking about CBT or other multiplexer/demultiplexer devices.

 

When someone says "multiplexer", I think of the standard TTL multiplexers (74150, 74151, 74153, 74157, etc.) which are unidirectional.

Just look at the 4-to-1 multiplexer schematic further down in that article.

 

When someone says "mux/demux", then that would be a different type device like the CBTs.

 

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I still want to hear why this EEPROM has to be accessible to two processors? It just sounds the like the maddest, most ill thought out design idea in the first place to me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using multiplexers really is pointless - as Cliff said early on, all you need is for the 2 potential masters to agree which one takes the actual Master role at any one time.

 

Note that the I2C specification has provision for multiple masters...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I still want to hear why this EEPROM has to be accessible to two processors? It just sounds the like the maddest, most ill thought out design idea in the first place to me.

Agreed!!

 

http://www.catb.org/~esr/faqs/sm...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Salmanma- by all means go ahead and implement your idea. It can be done. We've told you what the basic challenge is. By actually doing it you will learn many things - things that you probably didn't expect. Then you can come back here and tell us of your adventures.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If the two CPUs communicate, it may be easier to just have one act as an access proxy for the other. And, keep the hardware simple.

Mike Adams
ADI Development, Inc.
http://www.adidev.com

... When it has to actually work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An I2C serial EEPROM can be accessed by two microprocessors by using what the I2C people call multi-mastering.

 

I've read over it and it's complicated, but it works.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
An I2C serial EEPROM can be accessed by two microprocessors by using what the I2C people call multi-mastering.

Yes - see https://www.avrfreaks.net/comment...

 

it's complicated, but it works.

But, on a "closed" system, you don't have to do it that way - you can come up with your own simple "arbitration" scheme to ensure that only 1 master is actually active at any one time.

 

Or, as also suggested earlier, just have one MCU dedicated as Master, and it passes whatever is required on to the other (possibly via I2C) ...

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I still want to hear why this EEPROM has to be accessible to two processors? It just sounds the like the maddest, most ill thought out design idea in the first place to me.

one mcu for speaker

one mcu for headphone

eeprom contains file

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not:

one mcu for digital to analog conversion of file

one amplifier for headphone

one amplifier for speaker

 

or

 

one mcu for digital to analog conversion of file

one amplifier for headphone and speaker

 

If you insist to have two mcu's, then a dual ported eeprom will save you all the trouble of synchronizing mcu acces to eeprom.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

salmanma6 wrote:
one mcu for speaker

one mcu for headphone

Why on earth would you have separate MCUs for headphone & speaker?!?!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have a paradigm violator in our midst. Disrupt or be disrupted! That would've been good advice at school!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot the loop holes and simple modifications
I also forgot about working of eeprom.
Well Im sorry for being vague and for this thread
End of thread

Salman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, Salman -

 

Program-wise, speaker and headphone are the SAME signal. Thus, you only need ONE digital-analog conversion. You simply have two amplifiers driven by the single DAC, one that will drive the low impedance and higher power requirement of a loudspeaker and one that will drive the relatively simple headphone. Since this is for audio that is to be heard by a human, I suggest that you use a "real" DAC rather than PWM (its hard to get PWM to run at a high enough frequency for the resolution needed for good audio). Assuming that this is a continuation of your "prayer caller", you probably want more than 8 bits; 10 or 12 should do.

 

Now, you may want separate volume and tone controls for the two. Simply implement those using digital potentiometers, interfaced by I2C (TWI) or SPI. You can have as many as you need. The microcontroller that is doing the file read and analog conversion can "remember" the settings in its own internal EEPROM so that the user does not have to "fiddle" with them. 

 

Hope this helps,

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You guys are assuming that the same audio signal will be presented to both the speaker and headphones.  It's possible the OP has something different in mind.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, the OP would have pointed that out by now if it were the case ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...