RE: Ble application with spi manager library

Youngjun — Sun, 26 Apr 2020 23:47:56 GMT

Thanks for replying.

I tested using 500K.

And, it doesn't work.

I changed code to use flag in main loop.

But, it also doesn't work.

When i delete ads1292ReadData(), drdy worked.
Is there any problem in SDK when using scheduleSPI()?

	for (;;)
	{
		if (NRF_LOG_PROCESS() == false)
		{
			idle_state_handle();
		}
		
		if(ads1292_drdy_flag){
			ads1292_drdy_flag = false;
			ads1292ReadData();
		}
		/*
		if(ads1292_dat_read_flag){
			ads1292_dat_read_flag = false;
			sendData();
		}
		*/
			
	}

RE: Ble application with spi manager library

hmolesworth — Fri, 24 Apr 2020 16:42:26 GMT

Two suggestions, first care is required above 500kHz:

spi_config.frequency = NRF_DRV_SPI_FREQ_500K;  // Ensure less than 4 clk cycles for ADS1292

// Sending Multi-Byte Commands
// The ADS1291, ADS1292, and ADS1292R serial interface decodes commands in bytes and requires 4 tCLK cycles
// to decode and execute. Therefore, when sending multi-byte commands, a 4 tCLK period must separate the end of
// one byte (or opcode) and the next.
// Assume CLK is 512 kHz, then tSDECODE (4 tCLK) is 7.8125 us. When SCLK is 16 MHz, one byte can be
// transferred in 500 ns. This byte-transfer time does not meet the tSDECODE specification; therefore, a delay must be
// inserted so the end of the second byte arrives 7.3125 us later. If SCLK is 1 MHz, one byte is transferred in 8 ï¿½s.
// Because this transfer time exceeds the tSDECODE specification, the processor can send subsequent bytes without
// delay. In this later scenario, the serial port can be programmed to move from single-byte transfer per cycle to
// multiple bytes.

// Chip Select (CS)
// CS selects the ADS1291, ADS1292, and ADS1292R for SPI communication. CS must remain low for the entire
// duration of the serial communication. After the serial communication is finished, always wait four or more tCLK
// cycles before taking CS high.

Second interrupt functions triggering other interrupt functions can be avoided by using flags or signals, so I would suggest only set a flag in both DRDY and SPI interrupts and monitoring those flags on each wakeup (given the interrupt generates a wakeup) and then invoking the functions (eg spi from DRDY). This leads to more robust code and may fix the issues.