Forums

SPI with multiple microcontrollers

Started by Alexander Becher July 8, 2005
Hello everyone,

I am facing the following situation: I have a microcontroller (e.g.
Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip
(e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a
second microcontroller to access the flash memory.

The central question in this regard is: Can I add this second
microcontroller to the bus without changing the software on the first
microcontroller or the wiring to it? Or do I need some support for this
configuration in the first uC?

Obviously, I used Google with the wrong search terms, so I'm trying my
luck here. I'd appreciate any replies.

Regards
Alexander Becher

"Alexander Becher" <abecher@i4.informatik.rwth-aachen.de> wrote in message 
news:3j7ggvFng6c5U1@news.dfncis.de...
> Hello everyone, > > I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for this > configuration in the first uC? > > Obviously, I used Google with the wrong search terms, so I'm trying my > luck here. I'd appreciate any replies. > > Regards > Alexander Becher >
You are only allowed a single master on SPI, so you will need to change the original. Depending on the chips used you may cause problems for the original master if you bang on the clock line with another device. You may need to let the master get the data that you want. If you have a spare line you could set an I/O bit to tell the master you need something. Scott
Seems to me that you would have to high z the SPI interface on the original 
micro. You could do this in hardware with a tri-state buffer but this means 
changing the wiring, which is what you asked to avoid. However there are 
huge advantages to not changing the original software, based one how your 
company handles software control and documentation.

Thomas

"Alexander Becher" <abecher@i4.informatik.rwth-aachen.de> wrote in message 
news:3j7ggvFng6c5U1@news.dfncis.de...
> Hello everyone, > > I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for this > configuration in the first uC? > > Obviously, I used Google with the wrong search terms, so I'm trying my > luck here. I'd appreciate any replies. > > Regards > Alexander Becher >
Thomas Magma <somewhere@overtherainbow.com> wrote:
> Seems to me that you would have to high z the SPI interface on the original > micro. You could do this in hardware with a tri-state buffer but this means > changing the wiring, which is what you asked to avoid. However there are > huge advantages to not changing the original software, based one how your > company handles software control and documentation.
Two comments: 1) If getting a software change filed into the configuration management system is noticably harder than getting a hardware change filed, then I would tend to claim you have a seriously broken CMS on your hands (or you're using it very badly). 2) A hardware change alone almost certainly wouldn't help, anyway: only the software will be in a position to know when to high-z those pins. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Thomas Magma <somewhere@overtherainbow.com> wrote:
>> Seems to me that you would have to high z the SPI interface on >> the original micro. You could do this in hardware with a >> tri-state buffer but this means changing the wiring, which is >> what you asked to avoid. However there are huge advantages to >> not changing the original software, based one how your >> company handles software control and documentation. > > Two comments: > > 1) If getting a software change filed into the configuration > management system is noticably harder than getting a hardware > change filed, then I would tend to claim you have a seriously > broken CMS on your hands (or you're using it very badly).
Perhaps he's trying to avoid forking the firmware that runs in the old processor.
> 2) A hardware change alone almost certainly wouldn't help, > anyway: only the software will be in a position to know when > to high-z those pins.
Unless you gave the new processor control over the old processor's buffers. The new processor could then "disconnect" the old one. If the old processor tries to use the SPI bus while it's disconnected let's hope the error handling in the old SW is up to snuff. -- Grant Edwards grante Yow! Just imagine you're at entering a state-of-the-art visi.com CAR WASH!!
Alexander Becher <abecher@i4.informatik.rwth-aachen.de> wrote:

> I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory.
Plugging multi-master capability into an existing bus system that isn't designed to support them is quite certainly impossible without change to existing masters. Think about it: how would your existing master know that it may not touch the bus while the second one is using it, if its designer never had reason to believe that such a thing might happen? The thing's called the "master" because it owns the bus, and may do with it whatever it wants, any time it wants. There's no way you're going to break it out of that attitude without breaking its package. Therefore I suspect your best bet would be to seriously re-think the goal: why do you want to do this, and what completely different ways might exist to do it? Second-best, implement a protocol on top of SPI to let the masters hand over ownership of the bus from one to the other. Token-passing or regular "do you need the bus?" queries from the current master to the dormant one would be among the obvious choices. For this to work, the masters also have to be able to act as SPI slaves. Otherwise, you'll need physical intervention, i.e. the "ueber-master" could have direct control over parts of the hardware of the secondary master, so it can disable its transmitters or even disconnect it from the lines completely. Or just forget about SPI and use a protocol that's actually designed for multi-master applications. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message 
news:3j7malFokhtlU3@news.dfncis.de...
> Thomas Magma <somewhere@overtherainbow.com> wrote: >> Seems to me that you would have to high z the SPI interface on the >> original >> micro. You could do this in hardware with a tri-state buffer but this >> means >> changing the wiring, which is what you asked to avoid. However there are >> huge advantages to not changing the original software, based one how your >> company handles software control and documentation. > > Two comments: > > 1) If getting a software change filed into the configuration > management system is noticably harder than getting a hardware change > filed, then I would tend to claim you have a seriously broken CMS on > your hands (or you're using it very badly). > > 2) A hardware change alone almost certainly wouldn't help, anyway: > only the software will be in a position to know when to high-z those > pins. > > -- > Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) > Even if all the snow were burnt, ashes would remain.
Two comments. 1) DO-178A or equivalent. 2) The second micro would control the tri-state of the first and take control of the SPI. It depends on his specific application whether this would be a viable solution. I was just providing possible solutions to help in the thought process. Without knowing his specific application or hardware or the engineering quality procedures of his company, it's impossible to suggest the most effective method of implementation. Thomas
Grant Edwards <grante@visi.com> wrote:
> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Perhaps he's trying to avoid forking the firmware that runs in > the old processor.
If forking the hardware is always easier than forking the software, then either the CMS is braindead, or somebody thought it wasn't necessary to apply it to hardware, too, which I count as "using it very badly".
> If the old processor tries to use the SPI bus while it's > disconnected let's hope the error handling in the old SW is up to > snuff.
Given that the error symptoms this would cause to the disabled master are stricly in the "this cannot ever, possibly happen" category, odds are it's not. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Grant Edwards <grante@visi.com> wrote: >> On 2005-07-08, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote: > >> Perhaps he's trying to avoid forking the firmware that runs in >> the old processor. > > If forking the hardware is always easier than forking the > software,
But nobody said that. My reading of the OP was that forking the hardware is a given: the new product has to have a new board. Now the choice is does the new product require forking the old firmware or not. Assuming the old product must remain supported, it would be nice if the old firmware worked in both products.
>> If the old processor tries to use the SPI bus while it's >> disconnected let's hope the error handling in the old SW is up >> to snuff. > > Given that the error symptoms this would cause to the disabled > master are stricly in the "this cannot ever, possibly happen" > category, odds are it's not.
I expect you're right. The chances of the firmware for the old processor being able to tolerate being arbitrarily disconnected from the SPI bus at any point are pretty close to zero. At a minimum he'll have to connect the old/new processors together with a couple pins so that they can negotiate over bus ownership. -- Grant Edwards grante Yow! You should all JUMP at UP AND DOWN for TWO HOURS visi.com while I decide on a NEW CAREER!!
Alexander Becher wrote:
> Hello everyone, > > I am facing the following situation: I have a microcontroller (e.g. > Atmel ATmega 128 or TI MSP430) connected via SPI to a flash memory chip > (e.g. Atmel AT45DB014B or ST M25P80). I'd very much like to enable a > second microcontroller to access the flash memory. > > The central question in this regard is: Can I add this second > microcontroller to the bus without changing the software on the first > microcontroller or the wiring to it? Or do I need some support for this > configuration in the first uC? > > Obviously, I used Google with the wrong search terms, so I'm trying my > luck here. I'd appreciate any replies.
When you say access, do you mean Read and Write ? It will be much easier if you can add support in the first uC - SPI is not multi-master, so to simply OR-WIRE the bus, requires handshake between the controllers. Your-turn/My-turn stuff, and that should include write-time allowances. One side effect of this sharing, is that it is still just possible a write/read will fail, so the firmware should include verify/retry. If you had a system where the original was in ROM, then it is still possible: One way is to create a virtual Flash device, that to the original looks like the genuine article, but is actually your other uC, and now it handles in SW the hand-over to the physical device. This will restrict your second uC choice, as most small uC's have rather poor SPI Slave operation on multi-byte streams - or, you could use a CPLD to assist. -jg