Project - nRF24L01+ Module installer (4.1, 4.2, and 4.3)

Archive
1

I just posted nRF24L01+ Module installer (4.1, 4.2, and 4.3) on Codeshare. Feel free to discuss and make suggestions here.

3 Likes
2

just installed this, and thought there’s a couple of things I’d mention.

The image you use shows the module in red, but I think you should make it a black or blue module - anything except red which implies a power module.

The image is, well, a little large :slight_smile: You could shrink it a bit/lot, and when you do you could rotate and tweak the socket location.

2 Likes
3

Next challenge. Looks like the pre-compiled installer didn’t work - the references list shows that the GTM.WBSimms.nRF24L01Plus reference is added, but the error list shows that "the type or namespace name “nRF24L01Plus does not exist in the namespace”. Any thoughts ? I tried on a new 4.2 and a new 4.3 project, neither made a difference.

4

@ Brett - in Program.generated.cs, change…



to...


```cs]        private Gadgeteer.Modules.WBSimms.NRF24L01Plus nRF24L01Plus;[/code


and you should be in business.  I'll send WBSimms a pull request with a fix on the driver side.


@ wbsimms - I have one suggestion for your repo.  It's somewhat controversial about whether binaries (your .msi installer) should be included in the source code area of a repo.  My opinion is that the "Installers" folder you have should not exist.  GitHub provides a better place to put those.  You can attach them to your "Release" instead.
5

Thanks @ Ian

It’s not quite all though. InitializeModules() is missing the auto-generated constructor as it thinks the module is not connected; perhaps that’s related to the above correction? But to me it looks like the constructor needs to be expanded to leverage the socket that’s ordinarily passed in. Possibly that’s more work than just wrapping Gralin’s original code (but I did kind of expect that)

6

Hi,

I merged the pull request and improved the image size.

@ ianlee74, I though the “Release” is based on applied tags. You can see that I’m tagging the code. “Release_1_1” is latest. This automatically creates a zipped file with those files included. If there’s another way to do it, please point me to documentation or an example. I’m always up for learning something new.

7

@ Brett - I just did enough to make it compile. I don’t actually have the module and didn’t try to run anything. It sounds like there are other issues.

@ wbsimms - If you go to your release and hit “Edit Release” you will see the box where you can drop binaries. See…

1 Like
8

@ brett

Did you see the example project?

https://www.ghielectronics.com/community/codeshare/entry/993

This does require a bit more setup than I’d like.

9

HI @ WBSimms,

yep, I did see the example, but it’s not using the Gadgeteer module - the module is not dragged into the designer and connected to the right socket - but I agree, that example does work (well AFAIK, to the best of my testing ability - I can apparently talk to the module but can’t yet send/receive, I need to dig into the wiring I have on my g-plugs).

If this was really going to be a Gadgeteer module then I’d have it rely on an S socket (which it does) and have it manage the SPI channel and the pins - basically the Initialize() step - all within the Gadgeteer construct and not leave it to the user.

10

and can I triple check what your wiring is ? I’ve tried to replicate what I think your module diagram does and what I think the pins/roles will be but I am not getting anywhere. I will connect up a scope to make sure I am getting what I expect, but making sure I’m connecting what you are might speed things up for me :slight_smile:

1 Like
11

Sure. With the impending storm in the Northeast, I should have lots of time.

If you’re using the Raptor, you should able to see which pins I’m using in the example:


var socket1 = GT.Socket.GetSocket(1, true, null, null);
var socket2 = GT.Socket.GetSocket(3, true, null, null);

nSender.Initialize(socket1.SPIModule,G400.PB5,G400.PB0,G400.PA7);
...

nReceiver.Initialize(socket2.SPIModule,G400.PB3,G400.PB1,G400.PC23);
...

To make this a “true” Gadgeteer module, I only need to wire the pins to sockets. I’m working on that. A socket fairy is visiting soon. :slight_smile:

12

ok, I meant I wanted to double check where you’d connected them to on the nRF24 :slight_smile:

I did find one g-plug solder joint not correct, and I see data that looks correct on each pin individually, so looks like I’m going to dig into the actual driver to see what is failing. I can’t get my Raptor example to work using your code - maybe my modules are cheap-and-not-working-nasty.

13

Are you using the same ones from Addicore? If so, they’re pretty good.

Try wiring w/o using the gplug. We can get on Skype over the weekend if you want to go over it together?

Just as a test, have you tried my example and is it working correctly? I just retried and it still works for me.

14

no, cheap-and-nasty-from-random-ebay-seller modules

I have not tried the raptor since finding the potentially dodgy solder joint. I really should :slight_smile:

I’ll document my wiring to try to confirm it against yours. I am not near my kit at the moment.

And hunker down, I saw the news and yes the storms might be a good reason to spend time tinkering. Unlike here, where we had two days in the early 30’s C (~90F) over our weekend

15

nRF pin --> Gadgeteer Pin (S socket)

1 GND --> 10
2 3v3 --> 1
3 CE --> 4 (arbitrary; could have been 5)
4 CSN/CS --> 6
5 SCK --> 9
6 MOSI --> 7
7 MISO --> 8
8 IRQ --> 3 (only guaranteed interrupt capable pin)

The only real difference is in the Initialize() call, where you pass in the supplemental pins for CS, CE, and IRQ pins (pin6, pin4, pin3 in my case).

I might only just have enough wires to ditch g-plugs, and I don’t think I have any breakout modules soldered up ready to go so I’ll fire up the soldering iron tomorrow, as well as pull out the raptor then, must sleep or I’ll be a zombie in the morning :wall:

16

So, in my testing I’ve established that the pin mapping you’ve used may not work on an S socket. Looking at your Initialize() calls above, you have the interrupt pin that is on the IRQ line on the nRF24 connected to PA7 and PC23. You should make sure you use PB1 and PB1 (socket 1 and socket 3 respectively) as those are the only pins guaranteed to be interrupt capable - on a raptor however, the ones you use just happen to be interrupt capable so don’t cause you a problem.

I now have it all working. Wasn’t anything wrong with my G-plugs or connections, I just went back to basics and made sure I checked the constructor and the physical wiring matched, and it seems to be working reasonably well (I do still get some failed to send errors, but not quite sure why yet; not a problem)

1 Like
17

This is good news. Sorry I’ve been MIA. We’ve been under quite a bit of snow and I’m still catching up on work and other side projects.

I’m looking forward to seeing pull requests if you suggest any improvements.

Thanks!

1 Like