 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Guest
|
|
 Posted: Sun Sep 17, 2006 4:02 am |
 |
|
Dead right about the SSP function. I have posted this little set of code before, when using SPI in an interrupt:
| Code: |
/* Now the SSP handler code. Using my own, since the supplied routines test the wrong way round for my needs */
#if defined(__PCH__)
#byte SSPBUF = 0xFC9
#byte SSPSTAT = 0xFC7
#byte SSPCON1=0xFC6
#else
#byte SSPBUF = 0x13
#byte SSPSTAT = 0x94
#bit SSPEN=SSPSTAT.5
#byte SSPCON1=0x14
#endif
#bit BF=SSPSTAT.0
#bit SSPEN=SSPCON1.5
#DEFINE READ_SSP() (SSPBUF)
#DEFINE WAIT_FOR_SSP() while(!BF)
#DEFINE WRITE_SSP(x) SSPBUF=(x)
//Then rewriting the transmit code with this:
void mysend(void) {
//Make sure hardware has completed _last_byte
WAIT_FOR_SSP();
SSPEN=0;
output_low(LCDCLOCK);
output_high(LCDDATA);//send data
output_high(LCDCLOCK);
output_low(LCDCLOCK);
SSPEN=1;
WRITE_SSP(color);
}
|
With this, the transmission, will actually be taking place _while_ you are looping. The overhead of the loop is then lost.
Best Wishes |
|
 |
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Sun Sep 17, 2006 6:44 am |
|
|
Ttelmah, thanks for the DEFINEs, looks more professional than my inline assembly.
I was just wondering why did not CCS implemented spi_write() the other way, first check if SPI is busy and then send the data if not and returning control while the SPI hardware is working ? This would be more effective in more situations. |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Sep 17, 2006 7:09 am |
|
|
I'd say, it comes from 'history'. The early versions of CCS C, were based round relatively simple 'single flow' programming. Only latter were things like interrupt driving added. Hence the basic 'flow', was 'send the instruction, and wait for it to finish'. Now we have seen several functions improved in latter releases (in particular the read_adc function, where they retain the 'original' behaviour as the default, but offer use of defines to allow you to start or read the ADC as separate operations). Hopefully, one day they will offer similar versions for the SPI commands. Fortunately though, this is one of the simplest peripherals to handle 'DIY'.
Best Wishes |
|
|
Pyrofer
Joined: 13 Sep 2006
Posts: 16
|
|
| Posted: Sun Sep 17, 2006 12:10 pm |
|
|
If you take a look at my site
www.pyrofersprojects.com/3dcube.php
you will see why i need to optimise speed so much. Ive pushed the limits here of what I can do with the pic. The slowest part is the actual drawing routines, and as the sending 9 serial bits is the one part that is done most often ive concentrated on that as the best thing to optimise.
Ill try that new SPI code and see how much difference it makes. The largest overhead is on smaller drawing chunks now, larger shapes are just repeated SPI writes and are fairly well optimised, I have to work on the surrounding code too now so that smaller shapes go quicker too. |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Sun Sep 17, 2006 12:52 pm |
|
|
Wow. very interesting!  I like the Nokia phone optical BT mouse also. Would that work with my 6280 ?
Re: floating ball. once I was thinking of a similar project with many electromagnets placed in a row, and the ball moving back and forth below them, with one coil passing the ball to the other, though I planned to use a webcam for feedback (would have been too slow I think)
Pls let us know how much is the speed gain with the optimized SPI communication. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
