| View previous topic :: View next topic | 
	
	
		| Author | Message | 
	
		| newguy 
 
 
 Joined: 24 Jun 2004
 Posts: 1924
 
 
 
			    
 
 | 
			
				| #use spi() and changing SPI clock speed? |  
				|  Posted: Wed Jan 17, 2018 2:05 pm |   |  
				| 
 |  
				| I need to clock a peripheral slowly until it is configured, and then I can increase the speed.  I've tried changing the SPI clock speed by having two different #use spi();  first the slow one, clock out some data, then the fast one, and clock out different data.  My SPI clock speed isn't changing.  In the past I'd use the setup_spi() function to change speeds but I was under the impression that it's no longer supposed to be used when/if using #use spi() and spi_xfer()? |  | 
	
		|  | 
	
		| PCM programmer 
 
 
 Joined: 06 Sep 2003
 Posts: 21708
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Wed Jan 17, 2018 2:13 pm |   |  
				| 
 |  
				| See the spi_speed() function in the CCS manual.  It's for use with #use spi(). |  | 
	
		|  | 
	
		| newguy 
 
 
 Joined: 24 Jun 2004
 Posts: 1924
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Wed Jan 17, 2018 2:20 pm |   |  
				| 
 |  
				| That didn't work.  I'm using the brand-spanking-new 5.076.  Interestingly the help file has a spelling error in the spi_init() entry.  It repeatedly refers to a spi_inspi_init() function that doesn't exist.  Must be a typo because spi_init() works. 
 Anyway, I answered my own question and in case anyone else finds themselves in the same boat, this works:
 
 
  	  | Code: |  	  | #use spi(MASTER, SPI1, MODE=0, BAUD=10000000, BITS=8, stream=SPI_PORT1) 
 while(TRUE) {
 delay_ms(1);
 spi_xfer(SPI_PORT1, 0x00); // this creates a "slow packet"
 spi_init(FALSE);
 spi_init(17500000);
 delay_us(1);
 spi_xfer(SPI_PORT1, 0x00); // this creates a "fast packet"
 delay_us(10);
 spi_init(FALSE);
 spi_init(10000000);
 }
 | 
 
 I'm going to alert CCS to the help file mistake and also ask why spi_speed() doesn't work.  dsPIC33EP128GP502.
 |  | 
	
		|  | 
	
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19967
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Wed Jan 17, 2018 3:53 pm |   |  
				| 
 |  
				| Er. You do realise you are trying to specify 10MHz, and 17.5MHz.... 
 It'll go as fast as possible, so I doubt if it'll change much.
 
 The chip supports up to 15Mhz (depending on your clock rate), _half duplex only_. For standard full duplex operation, 10MHz max.
 
  	  | Quote: |  	  | 3: The minimum clock period for SCK1 is 100 ns. The clock generated in Master mode must not violate this
 specification.
 
 | 
 |  | 
	
		|  | 
	
		| newguy 
 
 
 Joined: 24 Jun 2004
 Posts: 1924
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Wed Jan 17, 2018 5:00 pm |   |  
				| 
 |  
				| Yep, 10 & 17.5MHz, aye.  I'm running the chip @ 140MHz (70 MIPS) so 70 / 4 = 17.5 MHz, which is the default when you don't specify a speed/baud in the #use spi() set up. 
 Didn't see the note regarding 100ns minimum clock period.  I'll adjust accordingly.  Thanks for that.
 
 For the clock speed change test I wasn't concerned about what the clock actually was exactly;  what concerned me more was the fact that I couldn't change it using the built-in functions that should have allowed it to change.  I set up the MSSP to use the max rate first, measured it with a scope, then changed the rate in the #use spi() and repeated.  Then I decided to switch to "let's try to change this on the fly" and hit a wall.
 |  | 
	
		|  | 
	
		| Ttelmah 
 
 
 Joined: 11 Mar 2010
 Posts: 19967
 
 
 
			    
 
 | 
			
				|  |  
				|  Posted: Thu Jan 18, 2018 1:45 am |   |  
				| 
 |  
				| It's in the timing characteristics Table 30-43. 
 I ran into this, when using a 'non standard' prototype chip from MicroChip. It supported a clock rate on SPI faster than the 'off the shelf' chips. I had to use the device editor to allow it to work (or manually code), since the compiler (correctly) blocked rates above the data sheet max....
 |  | 
	
		|  | 
	
		|  |