-
-
Notifications
You must be signed in to change notification settings - Fork 19.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SD card SPI conflicts #1226
Comments
related to #1227 |
one way to solve this one is to use the chip select pin.... if master do not use SPI it will not pull the chip select lines high... one line is needed for each device... when master wants a temp reading it will pull high the chip select line a and talk to the thermocouple... when done it puts the line low... http://en.wikipedia.org/wiki/Serial_Peripheral_Interface-bus |
Yes, this can be done, however, it will need careful implementation to not screw up in progress communication. |
http://elm-chan.org/docs/mmc/mmc_e.html |
would this explain the times I've been seeing the sd card as showing files but when I try going into a sub directory it shows the files briefly and then they disappear ? Using a thermocouple hooked up with one of these http://reprap.org/wiki/ExtThermoCouple_1.0 boards |
its a problem in general... SPI needs one line for each device that the master can use when it needs to talk to say the thermocouple... lets say it can talk to the LCD in general but then the thermocouple sends out data at the same time... why does this happen? because the CS (chipselect) line is not driven right |
If this is related to code in the SDFat library, we should have a look at the SDFat Beta repo and see if the latest library is doing the right thing, then incorporate those changes. (Assuming there is a "right thing" it can even do!) |
I just got home, and doing a quick catch up, before I head out again in 20 minutes. It's the whole SD card implementation, it's just a mess. I just had a look at that repo, briefly, and looking through the code, it is doing some right thing I expect in SdSpiCard.cpp I have been racking my head for a couple of weeks now, of some way, this/similar function could be adapted to read all the SPI devices automagically. I only know some very basic elements in code, not in any way would I consider myself adept at coding. |
The readme on SDFat beta seems optimistic with its mention of "Allow[ing] simultaneous use of hardware and software SPI with multiple cards. See the ThreeCard example." But I suppose it would be good to query the author @greiman and see what he thinks is possible. |
You need this patch to fix the MAX6675 code with SD cards: As this changes the MAX6675 read from interrupt to main loop. And as the SD is also called from the main loop the conflict is suddenly gone. |
I will roll a patch from that soon. |
Changes to temperature.cpp from Ultimaker fork, intended to address MarlinFirmware#1226 and MarlinFirmware#1227
Changes to temperature.cpp from Ultimaker fork, intended to address MarlinFirmware#1226 and MarlinFirmware#1227
Still haven't got around to checking this merge out. |
Just a comment question. ISP devices assume that they can share a bus but there is a chip select (or Slave Select signal in the spec) that determines which device has been granted access to the bus. In general, the master controller arbitrates and uses the SS to use the different peripherals. The SPI bus is not like the I2C where you can address devices in the bus, they require their unique CS signal. |
The Max6675 does not support being connected on a multi-slave shared CS configuration. As soon as the CS is asserted low and it sees a clock signal in the its SCK pin, it will start clocking data out. This will short anything on the MISO line. Please indicate how the MAX6675 is connected and if it shares the CS with the SD card-reader. |
yes i have said the same a few times.... i will try and find the schematics for the 2... |
In the patch shared by daid it is using a different pin for the chip select. |
oh... yes... so this just needs testing then |
@Grogyan had time to test if the included patch worked? but basicly the issue here is that every SPI device must have an individual CS pin |
@fmalpartida |
So we can close this one if someone can try it out. I don't have the needed setup. |
@fmalpartida excatly... someone with the setup needs to test... so if we dont see any activity in say 7 days i will close it issues can always be reopened if the issue is still there |
When I last checked, this problem was resolved.
|
will close this one since it has been resolved... we can always open a new issue if the the problem comes back |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The SPI for the SD card assumes no other devices are connected to the same bus and so data conflicts occur because the code doesn't do a sanity check to ensure that the SPI bus to free to communicate over.
Noticeable with;
RAMPS 1.4
RepRap discount full graphic display
Max6675 thermocouple
The text was updated successfully, but these errors were encountered: