SparkFun Forums

[rschoele]

Just to be sure are you sure you've correctly configured the PIC's IO port direction so that the SPI interface is working correctly? Can you read data you've written to the chip?

I'm not sure - as far as i understand when using the 'setup_spi()' call in the 16f88 device header file the IO ports should configure automatically - I use #use standard_io, which means the compiler configures the IO based on the code. When using SPI the specific pins I define are the ones that according to the PIC data sheet are the TX,RX and SCK pins.

But I was waiting for a reply to ask a question pertaining to this. I have logic analyzer and I see the data go out the MOSI pin I set, I see the CLK as well. I'm not sure, according to the nRF24L01 data sheet how MISO works exactly - am I supposed to see a byte clocked back to the PIC simultaneously as I clock out data? or is it a separate command I have to send?

thanks
rschoele

[djulio99]

I'm not sure, according to the nRF24L01 data sheet how MISO works exactly - am I supposed to see a byte clocked back to the PIC simultaneously as I clock out data? or is it a separate command I have to send?

Yup, SPI interfaces clock a bit out for every bit you clock in. The nRF24L01 clocks out its STATUS register when you load the instruction byte (i.e. read/write command and register address).

I'm not sure what it clocks out for write 'data' bytes, my code just ignores this information.

When reading data from the chip, I just clock in garbage (whatever is in one of my PIC registers - the SpiData register). Since the chip has been configured for reading it must just ignore this data.

So you should have a total of 4 wires connected to the chip for the SPI interface. SCLK, MOSI (PIC SDO), MISO (PIC SDI) and an active low CSN signal.

Then you also need to drive the active high CE signal and receive the active low IRQ for RF operation.

It seems writing C for the PIC is quick and easy. How about creating a simple test program that writes one or more registers and then tries to read them back? Using the logic analyzer (lucky guy...) you should be able to track down any problems. I understand your frustration, getting the nRF24L01 to work for my application was a lot of little steps. But it does seem to work exactly like Nordic claims in the spec. I've now moved many many megabytes of data through it successfully.

[rschoele]

my wiring is like you state (I've looked at it a million times hoping that would be the problem). So say when I write to the CONFIG register (address 0x00) I should see the 8bit value I write to that register on the MISO pin? Or will I see the STATUS (address 0x07)?

I'll go back to some basics like you suggest, cause right now I don't see anything clocked back.

It seems writing C for the PIC is quick and easy. How about creating a simple test program that writes one or more registers and then tries to read them back?

So I guess this is some of my confusion and I'm reading that quote literally so I'll need you to clarify -- C is quick and easy and I can call the SPI like so
data = spi_read(data1);
This should simultaneoulsy pass 'data1' out the MISO and clock in the MOSI to 'data' - but is what you're saying that there won't be anything to clock in until AFTER I've written something out? In other words, should
I call an 'spi_write(data1)' then 'spi_read(data)'

Of course I'll be trying these methods in the meantime - thanks much and thanks for the code - the assembler is one of those things I tell myself I'll learn, but like you said 'C is easy' unless it doesn't work!

[rschoele]

hmmm - can't get anything back from MISO using SPI - I'm running relatively slow osc (4MHZ) I've tried all the clk/div, tried all output configurations (i.e. H_to_L, L_to_H) - I'm missing something here.
gonna try bit banging

[rschoele]

Turns out my use of the built-in SPI doesnt' work.
Bit-banging did work and I have basic comm.

thanks for the help

Ryan

[djulio99]

Well I'm glad to hear you got it working. Strange that the built-in SPI doesn't work. I did have one thought about this. Have you looked at the assembly produced by the C compiler? Perhaps there is a bug there. I don't know how the various functions you are using to initialize the SPI interface are written but perhaps there is a bug in one of them.

anyway, good luck with your project!

[rschoele]

yeh I thought about that - when comparing the SPI set up options provided in the device header file to the datasheet. It doesn't seem like I have all the options available for configuring the SPI, but then again it takes me several reads to understand this stuff.

But for now my bit-banging is working so I'm not going to sweat it.
thanks for your help.

[DarioG]

Hi, I always had troubles in "realizing" how the Modes for SPI (CPOL, PHASE ecc.) do work!
When I use bit-bang, instead, things are easier to realize. Probably you may have that kind of issue too!

[aplohbihler]

I have followed this discussion and used the SparkFun sample code to create my own test communication between a Tx and Rx. instead of the Pic F88, I use the Pic F690 which is very similar. However, when I check the output of the receiver buffer I get nothing but four bytes of zero data. I do get interrupts at the Rx and I did set up CRC, so is this implying that the CRC did work properly and that the zero data was transmitted Therefore, this seems to indicate that the data that I intended to transmit did not clock into the transmit buffer properly.

Can anyone tell me what is happening here and how to fix it? Did anyone get the nRF24L01 sample code to work as expected (i.e. actual data transmitted between two devices with F88 handling the SPI)?