Can two Microcontrollers exchange Data through shared memory ?

[JayDee]

Bare with me on this..   
Two microcontrollers in a single application but able to exchange variables.

The main system is run by one microcontroller (A). This all works correctly so you dont want the support engineer to go chopping its control code around.

The second is effectively blank microcontroller with boot loader (B), the support engineer can load onto this anything they wish, thus being able to perform certain calculations and functions that may be required but are guaranteed not to screw the first micro.

If Microcontroller A writes all of its Input and Output variables to a shared memory, Microcontroller B could read only these variables, perform some function and write its results back to its own separate section of the shared memory.  Microcontroller A would then be able to read back these resultant variables.
You would obviously need to ensure that each device could only write to certain addresses so they dont overwrite each others variable data.

Is it common to exchange data between devices using a shared memory?  Do you need a specific type of data bus or memory to enable this sort of behaviour?

I appreciate this is all very vague but its only in concept stage and I want to pitch it to the dev engineers a bit more formed that just a scribble diagram. 
Thanks for any ideas!
Jay.

[Kjelt]

Yeah could be done if you take care of the same stuff you always have to do with shared resources like synchronisation, semaphores, prevent deadlock etcetera.
But if micro A also depends on the results of micro B you have made your system less reliable, now two components can fail.
I would first suggest to do research if a faster (bigger) microcontroller is not a better solution for the given problem?

[gmb42]

I've worked on systems in the past that had dual ported ram that allows access by two different devices, usually for such things as video buffers, but they are very expensive.

See here.

[grumpydoc]

Well,  if you think about it every modern computer does this in some way because that's how the interface to the GPU works.

Dual port ram is moderately expensive as far as things go but not totally bank-breaking eg - http://uk.farnell.com/integrated-device-technology/idt7006l15jg/sram-dual-port-16k-x-8-smd-plcc68/dp/1260371

[amyk]

You don't need dual-port memory, if you don't need simultaneous access. If the two MCUs have a protocol to request/relinquish the bus, then they can share the memory.

[codeboy2k]

There's some other creative ways to do this too.

(1) If the size of the shared space is large and you need fast and immediate access, then dual-ported memory is the (expensive) way to go
(2) if the size is large, but you don't need full speed simultaneous access, then you can use a small CPLD between both CPU's and the single ported memory, as an arbiter.  The CPLD logic will make one CPU wait if the other CPU is writing. The amount of granularity is up to you. For example, you can segment 64K of memory into 4 x 16k blocks and arbitrate at that level (so two CPU's can be writing to different blocks at the same time through the CPLD). You can make every read or write access to a block completely exclusive, or you can have multiple read access and single writes.. again to the whole memory array or on block boundaries.  The complexity is dependent on your needs..
(3) if your shared memory needs are even smaller still, say just 8k or 16k of shared data, and you have a region of unused memory in the address spaces of both CPUs, then you can simply use the CPLD and its internal RAM as the shared memory, and it can be mapped into the two available address spaces of both CPUs.
(4) if you don't need high speed access, you can even use a shared SPI serial flash, or a shared I2C EEPROM, and use external priority logic for /REQ and /GRANT between the two CPUs to gain access to the shared I2C or SPI device.

* and to extend my #3 with what amyk says, you can just use a RAM chip and /REQ, /GRANT the bus to it

[nctnico]

I'd make microcontroller A act as an I2C device which microcontroller B can access. If both microcontrollers are fairly decent then you can run the I2C at 1MHz (or more) and use DMA/interrupts to manage the transfers so the software overhead is extremely low.

[JayDee]

Hmm...thank you guys, lots to think about there.
This all came from a review of our existing product capability, we would love to release a version of our product that allows the more competent end users and support engineers to add there own routines. (From a support point, also dangerous I know!!  ) Writing a complete user definable control section into the existing system and still providing enough depth to be truly useful..could turn into a real pain and adds quite a bit to the firmware/software re-design.
This is why I was thinking out of the box, and simply having a second microcontroller on-board.  I was thinking; The main microcontroller might be writing up to 256 16bit values at around 100Hz,  the second microcontroller would be able to use these and write back results to 64 separate 16bit memory locations, also at 100hz. 
Its bit of a clunky way of giving the end users/engineers there own area to play but means we could also use it to bolt on specific requests from customers, without disturbing the core device.

[Kjelt]

Indeed dangerous unless you continually check all values for their boundaries. Also are you sure you have all the possibilities covered with 64 times 16 bit values?
I am wondering if it would be a good idea to make an API or write some kind of scripting language, let the microcontroller itself compile it (check for errors) and run or schedule it as an extra task, something like that.

[nctnico]

Another option is to implement a PLC or embedded Lua.

Years ago I maintained the firmware of a control unit for spot welding. That unit had digital input/outputs and an embedded PLC. The embedded PLC had a standard program but if the end user wanted they could change the programming.

[JayDee]

Hi nctnico, Kjelt,
Yep both of those solution are in the mix...    The device is essentially an application specific PLC, it is intended that basic user definable control be built into the devices software. However it could become a vast project in itself to provide an indepth user definable control script/language.   We are look it eLua exactly if we went this route.
Currently we do use external 8 bit microcontrollers to perform specific computations, receiving and returning values over CAN, the method I proposed was really just bringing this capability onto the main board but with a 16bit microcontroller and not passing everything over CAN.
lots to consider... hmm. 

[abyrvalg]

There is a C-like pretty compact embedded scripting language also: http://www.compuphase.com/pawn/pawn.htm

[Kjelt]

From my own experience the real problem is finding the balance between "user freedom of control" and "product safety". The users would like to change as many parameters as possible,  but on the other hand you do not want the user to change settings such that the product can be damaged or cause damage.
One of the reasons that a similar project in my company was cancelled after two years.

[JayDee]

A very valid point...I also know of a case where they made a embedded controller product almost completely definable... the designers there are still debugging the system years (and year) later as almost everyday someone finds a new combination that has the system over. Not sure they would go this route again!
However many of our systems are quite constrained and a reasonable level of user defined control strategies would go a long way in solving many of the requests from the power users.  We have to way of that balance of feature set Vs supportable and stable product.