From 536c92257755487710088df6ac4932ea25005e3e Mon Sep 17 00:00:00 2001 From: Jared Boone Date: Fri, 15 Jun 2012 17:20:50 -0700 Subject: Modified SSP driver to wait for data to be sent before returning. This is critical when controlling device CS# pins via GPIO. Long-term, it might be better to have a different API that permits this level of control. --- lib/lpc43xx/ssp.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/lib/lpc43xx/ssp.c b/lib/lpc43xx/ssp.c index 592b5d8..e9cf5b0 100644 --- a/lib/lpc43xx/ssp.c +++ b/lib/lpc43xx/ssp.c @@ -113,6 +113,21 @@ u16 ssp_read(ssp_num_t ssp_num) return SSP_DR(ssp_port); } +void ssp_wait_until_not_busy(ssp_num_t ssp_num) +{ + u32 ssp_port; + + if(ssp_num == SSP0_NUM) + { + ssp_port = SSP0; + }else + { + ssp_port = SSP1; + } + + while( (SSP_SR(ssp_port) & SSP_SR_BSY) ); +} + /* This Function Wait Data TX Ready, and Write Data to SSP */ void ssp_write(ssp_num_t ssp_num, u16 data) { @@ -130,5 +145,16 @@ void ssp_write(ssp_num_t ssp_num, u16 data) while( (SSP_SR(ssp_port) & SSP_SR_TNF) == 0); SSP_DR(ssp_port) = data; + + /* Wait for not busy, since we're controlling CS# of + * devices manually and need to wait for the data to + * be sent. It may also be important to wait here + * in case we're configuring devices via SPI and also + * with GPIO control -- we need to know when SPI + * commands are effective before altering a device's + * state with GPIO. I'm thinking the MAX2837, for + * example... + */ + ssp_wait_until_not_busy(ssp_num); } -- cgit v1.2.3