nRF24LE1 SDK

Questions for programming 8051 microcontrollers in C or assembly using SDCC

nRF24LE1 SDK

Postby fintor » Tue Jul 31, 2012 2:33 pm

Hi,

Was not quite sure of whether to ask this question here or in the wireless board.

Anyway, does the current version of the SDK for the nRF24LE1 enable SPI slave?

with regards,
fintor
fintor
 
Posts: 21
Joined: Thu Mar 01, 2012 9:08 am

Re: nRF24LE1 SDK

Postby brennen » Tue Jul 31, 2012 4:44 pm

There isn't any support for slave SPI in my SDK at this time. I'm not sure if there's anything in the Nordic SDK that you could port or not, though.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24LE1 SDK

Postby fintor » Wed Aug 29, 2012 8:52 am

Hi Brennen,

Thanks for the reply. I have looked at the Nordic SDK and think I have ported things correctly.

I was wondering about how to setup the pins for the SSPI to work properly. SMISO is of course an output while SMOSI is an input.
But what about SSCK and SCSN? Should they be inputs or outputs?

What about interrupts? What interrupts should be enabled in the SPISSTAT register?

with regards,
fintor
fintor
 
Posts: 21
Joined: Thu Mar 01, 2012 9:08 am

Re: nRF24LE1 SDK

Postby brennen » Wed Aug 29, 2012 12:23 pm

If you enable SSPI, then you don't actually have to do any GPIO setup yourself, as the microcontroller handles that for you (one exception is the UART, for which you *DO* have to set up the GPIO manually). But for your question, SMISO is an output and SMOSI, SSCK, and SCSN are all inputs in a general slave SPI setup.

As far as interrupts, I would start out just reading SPISSTAT.spiSlaveDone (bit 0) in a polling loop to see if a transaction had been started by a master. You may also want to look at the SCSN status bits (SPISSTAT.csnHigh (bit 5) and SPISSTAT.csnLow (bit 4)) if your protocol requires you to know the exact moment a transaction has begun (CSN goes low) or ended (CSN goes high). It appears that all three of those bits will get cleared when you read the SPISSTAT register, so to read its value, you'll want to declare a temporary byte and read out SPISSTAT into that variable. Then do your if() checks on the variable, so that you can test for all three bits. Something like this:

Code: Select all
{
   unsigned char tempSPISSTAT = SPISSTAT;

   if(tempSPISSTAT & (1 << 5))
   {
      //Do what needs to be done when CSN high bit is set
   }

   if(tempSPISSTAT & (1 << 4))
   {
      //Do what needs to be done when CSN low bit is set
   }

   if(tempSPISSTAT & (1 << 0))
   {
      //Do what needs to be done when SPI slave done bit is set
   }
}


After that, you can move to interrupts. Basically, when you find out which of the sections in the above code snippet you're actually using (CSN high, CSN low, or SPI slave done), then you would enable that interrupt in SPISCON0 (bit 6, 5, and 4, respectively), and create an interrupt handler. You would literally just move the code that is inside the above if() statements into their respective interrupt handler and you should be done.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24LE1 SDK

Postby fintor » Thu Aug 30, 2012 4:07 pm

Hi Brennen,

Thanks for the reply.

However, I have a strange issue. The master SPI device, does not seem to be able to pull the CSN pin on the nrF24LE1 low. Do you have any idea what might be causing the problem?

The setup is like this:

SPI Master: STM32F101T8
SPI Slaves: ADXL34 Accelerometer, nRF24LE1

The Connection is something like this:

Code: Select all
STM.MMOSI --- 1kOhm --------------------------------> nRF.SMOSI
                            |-----------------------> ADXL.SMOSI

STM.MMISO --- 1kOhm --------------------------------> nRF.SMISO
                            |-----------------------> ADXL.SMISO

STM.MSCK --- 1kOhm --------------------------------> nRF.SSCK
                            |-----------------------> ADXL.SSCK

STM.PB4 --- 1kOhm --------------------------------> nRF.CSN
STM.PB1 ----------------------------------------------> ADXL.CSN



I have the communication between the accelerometer and STM up and running, but not between the nRF24LE1 and STM. Like I said, there is at least the issue of putting the CSN pin on the nRF low. I have also shorted the resistor between the CSN pins, but it does not work either. I have changed the pin to an unused pin on the STM to see whether the toggling function works, and it does, so that is not the issue here.
When I put the STM to standby, the pin goes low, and the nRF senses that, and it goes back high when I pull it from standby again and the nRF senses that as well.

Do you know what might be the issue?

PS. Programming the nRF24LE1 with the SPI programmer I made with your breakout board works perfectly, so I know that the SPI communication there at least works.

EDIT:
Nevermind that. I have figured it out. It turns out the PB4 on the STM was a JNTRST pin by default, and I had to remap the function so it became a GPIO pin. Now with the code you provided, there is functionality, i.e. it reads the SPISTAT register correctly and all. But I want to have it interrupt driven. Is it enogh to use the interrupt_control_spi_2wire_enable() and the interrupt_isr_spi_2wire() for that, and of course enable them in the SPISCON0 register?

Hope you understand what I am trying to say here :)

with regards, fintor

Anyway. Now my question is. There are 3 interrupt sources for the SSPI port. csnHigh, csnLow and spiSlaveDone. I
fintor
 
Posts: 21
Joined: Thu Mar 01, 2012 9:08 am

Re: nRF24LE1 SDK

Postby brennen » Thu Aug 30, 2012 10:23 pm

For the interrupt, I think code like this should work (this is not tested, though):

Code: Select all
interrupt_isr_spi_2wire(); //This has to have a prototype or SDCC typically won't insert the function as an interrupt vector

void main()
{
   //Select which interrupts you'd like to enable in SPISCON0 here...the default value enables all of them
   interrupt_control_spi_2wire_enable();
   interrupt_control_global_enable();

   //Main routine stuff
}

interrupt_isr_spi_2wire()
{
   //Interrupt processing code
}
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24LE1 SDK

Postby fintor » Sat Sep 01, 2012 2:32 pm

Hi Brennen,

Thanks for all the help. It is working very well right now. If you are interested, I can send you the slave SPI implementation to add to the SDK.

I was also wondering. Is the SDK in any way compatible also with the nRF24LU+ that Nordic also offer?
fintor
 
Posts: 21
Joined: Thu Mar 01, 2012 9:08 am

Re: nRF24LE1 SDK

Postby brennen » Sat Sep 01, 2012 4:27 pm

I'm glad you got it working! As of now, I'm probably not going to add slave SPI to the SDK, but I'll definitely hit you up if I change my mind. You may be able to share some of the code with the nRF24LU1+. However, as I recall, the SPI module was a bit different between the two of them, at least as far as the registers and interrupts were set up.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Re: nRF24LE1 SDK

Postby fintor » Wed Sep 19, 2012 3:23 pm

Hello Brennen,

If I enter Deep Sleep mode. Isn't it enough to pull the \RESET pin low for a while to start the nRF24LE1 up again? Or do I need to set bits 5:4 to 10 in the CLKCTRL register? Or is there something else needed?

with regards,

fintor
fintor
 
Posts: 21
Joined: Thu Mar 01, 2012 9:08 am

Re: nRF24LE1 SDK

Postby brennen » Wed Sep 19, 2012 6:01 pm

If you're in deep sleep, the *only* thing that can wake you up is from a GPIO pin with that feature. Otherwise, you have to do a manual reset of the chip. See p. 106 of v1.6 of the nRF24LE1 datasheet, as well as p. 114-115.

To wakeup from a pin, you have to configure the pin(s) first as an input, then set up the proper bit(s) WUOPC0/WUOPC1 (depending on the GPIO[s] you want to enable waking the LE1 with), then lock the retention latch in register OPMCON (bit 1). The latch keeps your GPIO settings intact when you go into sleep mode. After this, do your processing in code, then you can enter deep sleep. Once asleep, you can now wake from the pin(s) you set up in the previous steps. When you wake up, you will go through a full reset sequence.
brennen
Site Admin
 
Posts: 395
Joined: Sun Aug 17, 2008 2:15 pm

Next

Return to 8051 Programming

Who is online

Users browsing this forum: No registered users and 1 guest

cron