setup_spi throws an error

[shemminger]

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.

[PCM programmer]

setup_spi() only works with constants.

[shemminger]

Well, that's a simple enough answer.

Can't say I like it though.

Thanks!

[PCM programmer]

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().

[shemminger]

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!

[temtronic]

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