Main Site Documentation

What is the most efficient way to stop NetMF 4.3 from reserving the SPI1 receive pin on the G120?


#1

What is the most efficient way to stop NetMF 4.3 from reserving the SPI1 receive pin on the G120? NetMF 4.3 reserves SPI pins on the G120 that NetMF 4.2 did not reserve. I need to move to NetMF 4.3 to remain supported, to match the firmware being used on other devices, and to use Visual Studio 2013. My application only transmits- it does not receive. The receive pin for SPI1 is already used for another purpose on my board, which is already in place and working. I realize this is a special case. I am OK with modifying NetMF 4.3 if that is what is needed. However, prior to doing that, I wanted to ask if there was a more efficient way to do this.


#2

so you want to stop the framework from using MISO pin? That’s going to be hard. And you won’t be able to modify the source for a G120 as that’s GHI’s code. But the good news is SPI is real simple to bitbang, especially if you’re just sending.


#3

I only need to stop the pin reservation.

If this is GHI, not NetMF, I understand I am not going to be able to change it. I only saw the change and made an assumption that it was NetMF.

This leaves the software SPI as the best option.

Can you suggest a good reference, example, or sample for doing my own SPI implementation?

I’m assuming that would be an RLP.


#4

Remember, in netmf there’s no “layers”, there’s only an individual firmware implementation for your hardware, and for a G120 that implementation is GHI’s.

SPI is super easy to bitbang. No need to revert to RLP, unless you need precise timing. Since SPI uses a CLK, there’s a good chance most SPI slave device implementations are not going to be timing sensitive.

The reason I make a point about the framework - SPI is pretty well defined, it’s a two-way serial stream on MOSI and MISO pins, with a CLK; what you’re doing is not really SPI, and I’d honestly suggest when you get a chance (ie PCB revisions etc) moving away from using MISO as anything other than a part of the SPI peripheral, as a different processor may implement this in such a way that you have no control over that, if you enable SPI peripheral you lock that pin to the SPI port, and no matter what the firmware does you don’t get the choice.


#5

I understand- the ability to build NetMF for an NXT LPC ARM chip is not the same as the ability to build NetMF for a G120.

So, one option will be a simple hardware change to use a different pin than the one which is reserved by SPI1.

The other option will be a transmit-only software SPI, using NetMF and not worrying about speed because it is a synchronous transmission. And, the transmit-only SPI will be reusable, since lots of devices only need to receive a command over their SPI interface to operate.

I haven’t seen this already written for NetMF so I will use the data sheet for the part I’m driving for reference.


#6

Of course you might find there’s a really simple hardware solution as well - just jumper MISO over to an unused pin, no need to redo the PCB, and use it there.

Typically this bitbanging is quite simple as precise timing doesn’t matter, so it’s a case of setting the output pin (MOSI) at the desired bit state, setting the CLK pin, pausing, reversing the CLK, and then repeating for all the bits you need.