I want to have 2 ATmega2560 connected to the same SDcard.
I wanted them both to read and write to the card.
Whenever one is reading or writing to the card the other is configured as SPI slave, so there will only be one master in line at a time.
Besides the 3,3V caution (SDcard power and coms), do you think i need any type of care when shunting the MISO, MOSI and SCK of the MCUs?
do you think i need any type of care when shunting the MISO, MOSI and SCK of the MCUs?
I sure do, this would be an easy way to get a corrupted SD card.
You will have to sync the two masters and tristate the MOSI and SCK lines of the one not using the bus.
While you could do this by dicking with the DDR regs I would use two TXB0104 chips. These will do the voltage conversion and that have an enable pin as well so they deal with two problems.
One master should be the master master It disables it's TXB chip, enables the other one and tells the other master it can proceed. When done the other master tells the master master it's finished. This requires a couple of handshaking signals but there will be no race conditions with two trying to access at the same time.
If you want true asynchronous multi-master you'll have to organize some hardware to ensure that only one gets access at a time.
Do you have to have both MCUs talk to the card as master? I'm working on a project where a master talks to an SD card through a slave MCU. Essentially RPC via SPI, using a modified SdFat library. If you can stand the loss in throughput I feel like it's a relatively elegant solution unless both of your micros work entirely independent from each other.
My code is only in an alpha state, and very application dependent, but you're welcome to dig through it for ideas if you like.
I wasn´t completely truthfull the first time just to avoid very complicated texts...
I´m going to describe better what i want:
Basically i have the following components (MCU#1 (ATmega2560), MCU#2 (ATmega2560) and SDCard)
I want to:
1 - Whenever power starts or signal is received in MCU#2, MCU#2 pulls down reset of MCU#1
2 - MCU#2 reads from SDcard an .Hex file
3 - MCU#2 writes the .Hex file to the flash of MCU#1
4 - MCU#2 puts itself in SPI slave mode
5 - MCU#2 pulls MCU#1 Reset signal high
6 - MCU#1 operates normally and uses SDcard to do staff
So normally the operation and usage of the SPI bus is well defined.
MCU#2 only uses it for writting the .Hex file during reset time...
This is the only function of MCU#2
That is exactly what I'm doing, except I'm using 328s instead XD
I had spent just a little bit of time trying to think of good ways to share the bus. The big problem is that the Atmega doesn't use a CS pin while being programmed. I even thought about playing tricks with the CLK line and issuing streaming reads with MOSI routed to the SD card and MISO from the card going straight to the micro to be programmed to avoid the (minimum) 50% throughput penalty of sharing the bus. In the end I never did anything other than mental exercises with those ideas though.
I wouldn't worry about messing with the DDR regs, the startup sequence is really pretty safe since the bootstrapper has full control over both it's own pins and the reset of the other chip. But you're going to need the level shifters anyway, and since the enable pin solves your lack of CS on the micro to be programmed it sounds like you might as well go for that.
In the end I decided to go with the slave-passthru setup because I'm not expecting to need the dedicated sustained bandwith from a directly connected card, and I'm hoping to be able to use some of the extra SRAM in my slave MCU as a write buffer to avoid some of the long write delays from the SD card. So I'm trading throughput for super low latency.
My main worry was the clock, that would be shared between MCU#1 and SDCard while MCU#2 will be reading from one and writting on the other....
You have to put CLK thru the level shifter as well anyway, so when you pull the disable on the shifter on MCU1 to talk to the card for the HEX file it will kill the clock. When you program MCU1 you enable the level shifter and disable CS on the SD card. It still sees the clock signal, but since CS is high it ignores it.
Have you been to rogue robotics uMMC project.
They have more or less your idea for sale.
I have talked with Brett (the guy in charge of the project), the problem is that their code is proprietary so i drop that idea....
Tell me, how are you programming your MCU#1? Serially PDI, PDO, SCK? Do you already have code for that or have successfully programmed it?
One of the advantages of my approach is that the amount of code is much smaller, right?
1 - Whenever power starts or signal is received in MCU#2, MCU#2 pulls down reset of MCU#1
2 - MCU#2 reads from SDcard an .Hex file
3 - MCU#2 writes the .Hex file to the flash of MCU#1
4 - MCU#2 puts itself in SPI slave mode
5 - MCU#2 pulls MCU#1 Reset signal high
6 - MCU#1 operates normally and uses SDcard to do stuff
That sounds like the sort of thing I was suggesting on another thread.
MCU#2 only uses it for writting the .Hex file during reset time...
#2 probably can't use its own SPI to program #1 because it's already using it to read the SD, it might be easier to implement an ISP programmer using some spare pins.
In my point of view i think MCU#2 can use the same bus because you use the TXB0104.
In serial memory programming you right page by page and as there is no time limit to holding the MCU#1 reset low,
i think it is possible to read part of the file (using 2 TXB0104 to share the bus), then write one page of the memory and then repeat this process untill you program the all memory.
Yes, it's very similar to the uMMC module, except I insisted on SPI for my design (for higher speeds, and to free the serial port for other devices), and my slave is also driving 2x 4bit LCD screens, to free up pins for IO on my main chip and again to reduce the impact of latency of slow commands like LCD.Home() The primary goal I had though was what you're attempting, being able to do in-field updates, so that logic is quite a bit different from just a card interface. Once I get my own project sorted out I'll probably try and make a shield of it and get all my designs online, it seems like something that enough people are looking to try to do.
The best code reference you have for ICSP is WestfW's OptiLoader
I haven't actually implemented my own ICSP code yet (I've been working on my SD RPC) but I do have a bodged together program that I did as a proof of concept, pulling from optiloader. It CRC checks the entire HEX file before programming it to the target MCU.
This is in no way, shape, or form production worthy code It is in fact the worst kind of mess filled with debugging, unused, convoluted, and otherwise horrible code (but it works)
This is meant for an Arduino Mega with a Sparkfun SD shield (running soft spi), with the target MCU hooked up to the Megas hardware SPI pins. It's hard coded with my own targetIDs and fuse settings. But if you're willing to wade through it all there it is.
The ATmega has some support for multi-master setup - specifically if you set pin 10 (SS) to INPUT mode and given a pullup resistor, the 328 acts as master until pin 10 is pulled low - master mode is then abandoned.
So you could use this mechanism for two Arduinos to control each other (say pin 9 of each Arduino drives pin 10 of the other, and the AND of the two is used as SS for the SD card. Either Arduino pulling its pin 9 low will become sole master as well as selecting the SD card. However this doesn't address the question of SD card corruption. By adding explicit code to check pin 10 you could implement a locking mechanism (semaphore) between the Arduinos
That is the very definition of ICSP. I'm pretty sure OptiLoader doesn't support Megas, but all you need to do is check the datasheets to see what's different about their implementation.
This does sound like an unsafe - and could cause conflicts on the SPI , besides corrupting the SDCard.
I would suggest an additional flag line signal pin - to safely grab Control.