I am working on a very curious problem involving SD card and touch screen. In the sample bellow I could not put both to work togheter. If SD works touch screen does not and vice-versa, depending on gpio-set-mode applyied to SPI pins. I suspect the libraries I am using URTouch and SdFat are uncompatible. Does someone had experienced something like that ? Thanks for any advice. Antonio
#include <URTouch.h>
#include <SdFat.h>
SdFat sd;
SdFile file;
const uint8_t SD_CS = PC10;
#define TS_PIN_CLK PB3
#define TS_PIN_CS PC11
#define TS_PIN_IN PB5
#define TS_PIN_OUT PB4
#define TS_PIN_IRQ PC9
URTouch ts(TS_PIN_CLK, TS_PIN_CS, TS_PIN_IN, TS_PIN_OUT, TS_PIN_IRQ);
void setup() {
Serial1.begin(115200);
afio_cfg_debug_ports(AFIO_DEBUG_SW_ONLY);
afio_remap(AFIO_REMAP_SPI1);
//without the bellow gpiob-set-mode, touch screen works, SD not
//with them, SD works, touch screen not
gpio_set_mode (GPIOB, 3, GPIO_AF_OUTPUT_PP);
gpio_set_mode (GPIOB, 4, GPIO_INPUT_FLOATING);
gpio_set_mode (GPIOB, 5, GPIO_AF_OUTPUT_PP);
ts.InitTouch(LANDSCAPE);
ts.setPrecision(PREC_LOW);
if (sd.begin(SD_CS, SD_SCK_MHZ(18)))
{
Serial1.println("SD is working...");
}
}
void loop() {
if (!ts.dataAvailable()){}
Serial1.println("Touch is working...");
while(1){}
}
CS means "chip select". The behaviour you mention is normal, nothing can work if both devices try to share data lines. The whole reason of CS is to "select"! So in your sketch, you might have to manually set the CS lines to the correct state for the device you are using at the moment, e.g. SD on and TS off or vice versa. Likely, one of the libraries is incorrectly setting it permanently instead of toggling it for an access. You could also investigate that and modify (fix) the library.
This is a good cue. I will investigate and monitoring the both CS lines during operation. I hope you are right ! I will put a feed back here soon. Thanks a lot
aarg, bad news... The CS lines are ok. They are active only one by time. I think the problem is located at pins set mode. It seams that each library are both programming the mode for ISP pins in different ways... If it is true probably my problem has no solution 
The STM32F103 has 3 hardware SPI ports, so there is a solution. 
I am already using all that other SPI pins for other functions... So the SPI1 remaped to PB5,PB4,PB3 is all I have !!!
Can't you change the GPIO modes dynamically, according to which device you want to use?
aarg:
The STM32F103 has 3 hardware SPI ports, so there is a solution.
I am already using all that other SPI pins for other functions... So the SPI1 remaped to PB5,PB4,PB3 is all I have !!! Besides that, I am using a SD unit builtin in backside of one TFT 4" display. It means that SD and touchscreen data flows by only one SPI port with two separated CS lines...
I have also tryed your suggestion to programm GPIO pins dinamically according with each device is in use but it fails. After the commands gpio_set_mode (GPIOB, 3, GPIO_AF_OUTPUT_PP); gpio_set_mode (GPIOB, 4, GPIO_INPUT_FLOATING); and gpio_set_mode (GPIOB, 5, GPIO_AF_OUTPUT_PP); that are required by SdFat library, the URTouch does not work anymore even after it's specific setmode pins are applied... The STM32F103 should be powered off and on and the correct setmode applied to get it working back.
Many strange things happening at this kindom !!!
Another thing you might be able to try, is work up a quick test program in Cube instead of Arduino. Then back port it.
aarg, no way. I think the problem is located at one or both libraries and I do not know how to fix it. Thanks anyway for suggestions and helps