View previous topic :: View next topic |
Author |
Message |
shemminger
Joined: 12 Apr 2019 Posts: 3 Location: Louisivlle
|
setup_spi throws an error |
Posted: Fri Apr 12, 2019 11:45 am |
|
|
I'm trying to build a fairly robust spi driver that I can then use in many projects but I'm running into some oddities.
Code: |
int master = SPI_MASTER;
int mode = SPI_SCK_IDLE_LOW | SPI_XMIT_L_TO_H | SPI_CLK_DIV_2;
int speed = SPI_CLK_DIV_2;
int args = master | mode | speed;
setup_spi(args)
|
doesn't work
Code: |
setup_spi(master | mode | speed);
|
doesn't work
but this
Code: |
setup_spi(SPI_MASTER | SPI_XMIT_L_TO_H | SPI_SCK_IDLE_LOW | SPI_CLK_DIV_2);
|
does.
In both of the versions that don't work I'm getting "A numeric expression must appear here ::" as the error code at compile time
Ideally I'd like to use an enum and be able to pass in arguments to a more broad spiHwInit() function.
compiler version: 4.124
target: PIC24FJ256GA108 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Apr 12, 2019 12:24 pm |
|
|
setup_spi() only works with constants. |
|
![](templates/subSilver/images/spacer.gif) |
shemminger
Joined: 12 Apr 2019 Posts: 3 Location: Louisivlle
|
|
Posted: Fri Apr 12, 2019 12:25 pm |
|
|
Well, that's a simple enough answer.
Can't say I like it though.
Thanks! |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Apr 12, 2019 5:50 pm |
|
|
You can look at using #use spi() and streams. Define a different stream
name for each setup. Invoke the stream name when you call spi_xfer(). |
|
![](templates/subSilver/images/spacer.gif) |
shemminger
Joined: 12 Apr 2019 Posts: 3 Location: Louisivlle
|
|
Posted: Fri Apr 12, 2019 6:04 pm |
|
|
Actually I think I'm going to step back and try to decide if I'm overengineering this.
Its quite likely, and probably in a way that's actually pretty bad in embedded, where how much program space I take making sure I can reuse a simple driver actually matters.
I already ran into this problem when I was playing around with using a homespun software_spi.
I managed to wind up with 7.8us clock cycles with my software spi because I spent so much time trying to make generic functions.
I cleaned it up with specific functions which means a lot less register hopping, and wound up getting it down to 800ns...
Thanks again for the input! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Fri Apr 12, 2019 6:21 pm |
|
|
The problem with 'generic' drivers is having to code for EVERY possibility. Heck there's 4 'modes' to begin with, then, hmm..speed.... then ...it gets ugly.
Usually you should KNOW exactly what devices will be on the board, so you just code for them. The driver may only use a fraction of the devices options, so the driver can be made smaller and more efficient.
Say you make a generic SPI driver and it works, 3 days later you add another device, but incorrectly point to the wrong function or some 'setup' uses negative logic(BTDT)....for the next 3 WEEKS you bash your head trying to find out what's wrong.......
I think some of the CCS bugs for new PICs might fall into this mess cause I can't figure out HOW they can get their compiler to understand every feature of every PIC...they usually get 99.99% right, but .001% wrong and the plane crashes.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
|