Main Site Documentation

Low level access to I/O pin EMX


Hi All

I have a little issue.
Have designed and have my first rev of our board up and running with the EMX module.
Connected to the module we have two CC1101 from Texas Instruments sharing the same SPI bus.
The power on reset sequence of the CC1101 have CHIP READY signal on the SO pin of the SPI. So to check if the chip have started and are ready we need to toggle the CS signal and then monitor the SO Signal.
if i write:

OutputPort ChipSelectRadio0 = new OutputPort((Cpu.Pin)GHI.Hardware.EMX.Pin.IO15, true); 
OutputPort misoRadio0 = new OutputPort((Cpu.Pin)GHI.Hardware.EMX.Pin.IO24, true); 

bool misoState = misoRadio0.Read();
misoState = misoRadio0.Read();
misoState = misoRadio0.Read();

My SO signal is always true, if I use my logic analyzer and remove all of the misoRadio0 code I can see that the chip is ready and the SO signal «follow» my CS signal.

My Question, is there a way to read the pin level directly, bypassing all between Micro framework codes? If yes how?
I am used to working at a lower level so all this is a bit new :slight_smile:


Normally SO is High-Z unless you assert a 0 on CS pin. So you are probably going too fast. I suggest a Sleep() of few ms between the two subsequent CS pin write. If you have just setup SPI comm, I think you can’t read MISO pin as a GPIO with OutputPort(). If not yet SPI enabled eventually try InputPort().


I figuerd some of it out :slight_smile:

     public void PORRadio0()
            OutputPort ChipSelectRadio0 = new OutputPort((Cpu.Pin)GHI.Hardware.EMX.Pin.IO15, true);
            InputPort misoInput = new InputPort((Cpu.Pin)GHI.Hardware.EMX.Pin.IO25, false, Port.ResistorMode.PullUp );

            bool soValue = misoInput.Read();
            soValue = misoInput.Read();
            soValue = misoInput.Read();
            misoInput.Dispose ();

This is just debug code, need to add som checks to check that line is actualy low, but this works now.
The issue is that the inputPort will not work when the SO is linked to my SPI object. Is it a way to still check the value of SO pin? or do I need to dispose of my SPI object first?


I don’t think this is a “common” use of the SPI lines, and the framework doesn’t let you do this - hence the locking of the pin when you use it in a SPI scenario first. So my suggestion would be to not work against this but work with it - hardwire the pins you need to use from the SPI port to additional IO pins, and use it in your InputPort and OutputPort commands. One problem I can see with this though is that because you have two of the same devices sharing the bus, you will use the MISO line for both checks, and you’ll need the two CS lines - so that means you need to retain three pins to do the toggles at setup time.


@ Brett - Been away so slow response. That will tie up to many pins. I now dispose of the SPI objects when I have to check the status of the chip. This is not a big problem on my base station side because it runs from mains and the radio chip is always on. On a battery powered device that need to sleep this would be an issue but then again I would not use Micro Framework there…
Thanks for the answers though.


Great to hear you’re comfortable disposing and re-creating. That is totally workable… the option I offered was really a way to influence the behaviour specifically so that you didn’t need to do that, but if you’re ok doing that then there’s no problem!