Jump to content
Sign in to follow this  
TimC

Multi Spi Design Problem

Recommended Posts

I have 3 SPI devices on an X1 micro Engineering board, DS1620 Temp, DS1302 clock and a 25LS640 EEProm. Being used for a Temperature recording project. My problem is how to reuse a software SPI.h and SPI.c files which contain all the shift in and shift out calls.

 

Currently the calls are designed so the header file points to one device at a time.

------------------------------------------------

//#define CS_TRIS TRISA // ds1302, spi eeprom

//#define CS_PORT PORTA // ds1302, spi eeprom

#define CS_TRIS TRISC // ds1620

#define CS_PORT PORTC // ds1620

//#define CS_PIN 2 //ds1302

//#define CS_PIN 5 //spi eeprom

#define CS_PIN 0 //ds1620

------------------------------------------------

 

I have looked at using templates and I do not see how to create multiple definitions like 2 LCD’s or 2 serial ports. It all looks like define once and use that one instance.

 

To me what would make the most sense would be creating a SPI class that defines an instance/device. But all I have seen so far is comments stating you can not efficiently pass port names.

 

What would look so nice and be maintainable would be:

//create new SPI instance for DS1302 using CLK @ PORTA.1, I/O @ PORTB.2 and Select @ PORTB,3

SPI *DS1302 = new SPI(PORTA,1,PORTB,2,PORTB,3);

 

And just for reference this is what the simple Basic interpreter can do.

------------------------------------------------

ReadRtcBurst:

'read all time keeping in one burst

HIGH Rtccs

SHIFTOUT Dta, Clk, LSBFIRST,[%1\1,BrstReg\5,%10\2]

SHIFTIN Dta, Clk, LSBPRE,[seconds,Minutes,Hours,Date,Month,Day,Year]

'debug cr,"Burst read ",hex2 Month,"/",hex2 Day,"/",hex2 Year," ",hex2 Hours,":",hex2 Minutes," ",hex2 Seconds

LOW Rtccs

RETURN

------------------------------------------------

 

Ok basic has a ton of problems like no call stack but they can pass the port names

Maybe shiftout and shiftin should each be a template and SPI.c and SPI.h is on top of that?

Oh and code portability I don’t think I am asking for too much am I?

 

Thank You

TimC

Share this post


Link to post
Share on other sites

We started working on SPI driver that has almost identical interface and code structure as UART driver publisher earlier on this forum. Because both drivers are template based they let as many UART/SPI connections as needed to be used in the code and still produce very efficient code. This SPI driver code is still untested but it is a good place to start with.

 

Regards,

Pavel

spi_driver.h

Share this post


Link to post
Share on other sites

Thank You It's a start. I am looking for a software based SPI, but I could back step a little more and try this on hardware SPI platform then modify to software bit bang.

One question I have yet to figure out. How do I use the templates to define more than one? For example what does code look like for using 2 LCD's (lcd_driver.h) or 2 Serial ports (rs232_driver.h) or two I2C devices (i2c_driver.h)

 

TimC

Edited by TimC

Share this post


Link to post
Share on other sites
Thank You It's a start. I am looking for a software based SPI, but I could back step a little more and try this on hardware SPI platform then modify to software bit bang.

One question I have yet to figure out. How do I use the templates to define more than one? For example what does code look like for using 2 LCD's (lcd_driver.h) or 2 Serial ports (rs232_driver.h) or two I2C devices (i2c_driver.h)

 

TimC

Tim, If u need to connect more than one LCD to ur mico connect them in parallel & multiplex them using some thing like using chip-select pin.

Only one driver file can be used. May be u need to write ur own driver to support parallel devices working on different i/o pins.

Most spi device will have chip-select pin. connect all devices in parallel(in, out & clk)& use different i/o pins for multiplexing the chip-select pin.

Regards

Raghunathan.P

Share this post


Link to post
Share on other sites

I did the same thing on devices with only one hardware SPI peripheral.

 

As a matter of fact, I used a two-wire serial-in, parallel-out (SIPO) circuit to derive as many slave select

lines as needed. It is relatively fast to carry out via a simple bit-banging routine.

 

(2 or 3 wire would work)

 

That was for a a multiplexed SPI network of identical slaves with "only 16 possible" addresses, with only one SPI peripheral, in order extend the address range I could use (like banking sort of).

 

I always prefer to use the hardware SPI instead of bit-banging as I can free up the CPU and rely on the "done" flag to trigger an ISR for the next SPI byte.

Share this post


Link to post
Share on other sites
One question I have yet to figure out. How do I use the templates to define more than one? For example what does code look like for using 2 LCD's (lcd_driver.h) or 2 Serial ports (rs232_driver.h) or two I2C devices (i2c_driver.h)

 

Here is link to some code that shows how to use 2 UARTs with template based UART driver. The SPI driver code uses almost identical API and should be user in similar fashion.

 

The idea is that you use same template calls but with different arguments. For example spiInit for SPI1 will use registers related to SPI1 and same spiInit used for SPI2 will use SPI2 related registers for its template arguments.

 

#define spi1Init spiInit<PIE1,SSP1IE,SSP1CON1,SSPEN>

#define spi2Init spiInit<PIE3,SSP2IE,SSP2CON1,SSPEN>

 

Now one can use code like spi1Init(); to initialise SPI1 and spi2Init() to initialize SPI2.

 

The beauty of template based approach is that it can handle any number of SPI/UART/LCD/etc. connections without any code bloat. If there was a PIC that had 10 SPI ports or 100 UARTs these drivers could handle all of them. The scalability is just phenomenal.

 

Look at templates as a kind of code generation tool. You have to supply some arguments (things inside the angle braces) and compiler will generate some code out of it. For every set of arguments different code will get generated. This will be done behind the scenes so you won't see the actual generated code but it will be there.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Thank you Pavel for answering my question. This really is a huge advancement for small memory devices!

Lots of examples will help your users understand how to use this feature and give you a competitive advantage.

 

I have already rewritten the LCD template so that the control pins can all be on different ports but I have much more to learn.

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×