Home/Support/Support Forum/Digi Connect ME 9210 - SPI
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Digi Connect ME 9210 - SPI

0 votes
A have DC ME 9210 on way. Does anybody now how to setup SPI interface?

The SPI functions in NET+OS 7.3 is only NS9360 Rev A, NS9750 Rev A, ConnectCore 9C compatible.

Is somewhere same updates for this digi module?

Thanks Jirka
asked Jul 28, 2008 in NET+OS by kubiajir Community Contributor (61 points)
retagged Dec 18, 2013 by tuxembb

Please log in or register to answer this question.

20 Answers

0 votes
Did you ever hear back? I am working with a 9210 and would like to set up a SPI interface, but there is no documentation on the ME 9210 in the NetOS7.4 docs.

-Erik
answered Aug 2, 2009 by egawtry Veteran of the Digi Community (349 points)
0 votes
HI,

I am not certain about the 9210, but I have the 9P module with the 9215 on it and I have SPI working OK. I started with the sample application and it worked with no problem on the 9P. You may have to change some definitions to get the right signal lines hooked up to get it to work on the 9210
answered Aug 3, 2009 by rdeabill Community Contributor (142 points)
0 votes
Yeah, I was trying to avoid reverse engineering.

I did that for NetOS5/6 on the ME and practically had to rewrite the bsp to get it to work properly. The three months it took to do that almost bankrupted the company.

I was hoping that there were some ME9210 docs that came out late or something that Digi posted somewhere I can't find.

-Erik
answered Aug 3, 2009 by egawtry Veteran of the Digi Community (349 points)
0 votes
Getting SPI to work on the ME 9210 (or CC9P 9215) is pretty trivial because both have dedicated SPI interfaces. All you have to do is:

- Setup the GPIO:

#define APP_SPI_MASTER_GPIO_CS 0
#define APP_SPI_MASTER_GPIO_CLK 5
#define APP_SPI_MASTER_GPIO_RXD 3
#define APP_SPI_MASTER_GPIO_TXD 7

if(NAconfigureGPIOpin(APP_SPI_MASTER_GPIO_CS, NA_GPIO_FUNC4_STATE, 0))
return -1;

if(NAconfigureGPIOpin(APP_SPI_MASTER_GPIO_CLK, NA_GPIO_FUNC4_STATE, 0))
return -1;

if(NAconfigureGPIOpin(APP_SPI_MASTER_GPIO_RXD, NA_GPIO_FUNC4_STATE, 0))
return -1;

if(NAconfigureGPIOpin(APP_SPI_MASTER_GPIO_TXD, NA_GPIO_FUNC4_STATE, 0))
return -1;

- Call NASpiRegisterDevice to setup the SPI Port (mode, bitrate, etc)

- Use NASpiReadWrite (to read/write your data)

Note - There are a few references and things you should be aware of:

There is an SPI Master and Slave example (File -> New -> Sample Project)

The ME 9210 HRM has good information on pin multiplexing (Programming Considerations section) and the NS9210 HRM has all the information about the GPIO lines: http://www.digi.com/support/productdetl.jsp?pid=3510&osvid=0&s=375&tp=3

Mode information can be found here: http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus

Your read buffer has to be 32 byte aligned, so I use something like this to get around that issue:

char readBuf[BUFFER_SIZE + 32];
char *readptr;

readptr = readbuf + (32 - ((int)readbuf % 32));
answered Aug 3, 2009 by charliek Veteran of the Digi Community (408 points)
0 votes
.
answered Aug 3, 2009 by miker New to the Community (38 points)
0 votes
Hi,

THere are a couple of things to note with the SPI master.

If you are going to be sending very short messages you will find that there is a bit of a problem. The standard code uses NAuWait(1) to effectively poll for the transaction complete Flag. NAuWait uses a timer to provide very short and should delay for the number of microsecs defined by the parameter, but due to the way it is implemented it is unable to operate with very short delays.

Overall if you are doing a lot of transactions one after the other, there is an excessive delay between each transaction. I sorthed this out by changing code in "spi_master.c" as follows.

OLD CODE:
/* wait for spi done */
while (timeout && (!gTxFlag || !gRxFlag))
{
/* Should this be a tx_thread_sleep(1) or something in order to
* allow lower priority threads to run as well?
*/
if (bufferLength < 8000)
NAuWait(1);
else
tx_thread_sleep(NS_MILLISECONDS_TO_TICKS(1));
timeout--;
}

NEW CODE:
/* wait for spi done */
while (timeout && (!gTxFlag || !gRxFlag))
{
/* Should this be a tx_thread_sleep(1) or something in order to
* allow lower priority threads to run as well?
*/
if (bufferLength < 8000) {
if (bufferLength > 1000)
NAuWait(1);
}
else
tx_thread_sleep(NS_MILLISECONDS_TO_TICKS(1));
timeout--;
}


Hope this helps

Regards
Roy
answered Aug 4, 2009 by rdeabill Community Contributor (142 points)
0 votes
In other words, reverse engineer it.

Taking a look at it, seems simple enough.

Thanks guys.
answered Aug 4, 2009 by egawtry Veteran of the Digi Community (349 points)
0 votes
That's far from reverse engineering... That's modifying the code to behave differently... It's also why Digi provides the source...
answered Aug 8, 2009 by charliek Veteran of the Digi Community (408 points)
0 votes
It is reverse engineering the source...

Right now I am trying to figure out what the *$%#! they mean by "ring buffer". I am getting quite confused with the SPI slave extern source...

I only have 1 buffer, that should be all I need. Right?

Digi really, really needs to learn what KISS means. I have been fighting this type of stuff for over five years now.
answered Aug 18, 2009 by egawtry Veteran of the Digi Community (349 points)
0 votes
http://en.wikipedia.org/wiki/Ring_buffer

By the way, while this is a public forum, a less aggressive style would still be appreciated. New here, but already noticed a couple of these posts from you.
answered Aug 18, 2009 by pretep New to the Community (1 point)
...