• HUGE status update: Linux kernel driver, nRF24LU1P and HELP WANTED!

    Necromant • 09/15/2015 at 19:14 • 0 comments

    Another of those rare status updates. Finally found a few evenings to work in detail on nRF24LU1p. Turns out they are more complicated to work with than expected. I will be making a detailed "getting started with nRF24LU1p development" post some time soon in my blog. This notes will just cover a few details, so it you don't understand a thing - skip it and make you read the HELP WANTED part. ;).

    Now, if you remember - to flash your boards remotely we need a USB dongle. Up until now I used atmega8-based usb dongles with nRF24L01. Those were good, but alas slow and vusb was the bottleneck. nRF24LU1p is more expensive, but provides the speed with hardware USB and is SMALL. So the idea was to make a firmware for nRF24LU1p to make those a drop-in replacement for my AVR dongles. e.g. librf24pp should not even care, whether the thing you plugged in is an AVR-based dongle or a nRF24LU1p dongle.

    At first I started by adapting nrfprog for my uISP. This is basically the tool I use to flash nrf24lu1p over SPI. You can grab the sources here. Not really documented (yet!) https://github.com/nekromant/nrfprog

    Anyways, I was first playing with Nordic's bootloader for those chips and *SURPRISE* ended up rewriting it from scratch. The Nordic-provided usb bootloader can only be started from within the application and can't run the application when host pings it. So I decided to rewrite it from scratch. I made use of HID profile, since HID doesn't need any drivers under windows.

    Since my old uisp-bootloader (a lousy fork of BootloadHID with added blows and whistles) that I used on AVR was never meant to work on anything but AVR, I quickly ended up in rewriting a bunch of other older code and it now even works!

    As a result My HID bootloader for nRF24LU1p eats up 3K of flash (I'll see if I can optimize it to 2KiB, some stuff can be moved to infopage), supports reading of both flash data and infopage data, writing flash data and (the most needed feature) can start the application when the host tells it to!

    Since the usb bootloader will have the same usb API for both AVR dongles and nRF24LU1p I will now ship precompiled fimwares with librf24pp and make the library take care that you are always running a compatible firmware on the dongle.

    As of another effort - I gave my nrf24l01 library from antares a spin running inside linux kernel. The kernel driver itself is still VERY buggy proof-of-concept and is in early development, but already provides proper interrupt handling and packet buffering within the kernel. It should be way faster and efficient than those spidev implementations. This is something I'm going to work on when I'm done with nRF24LU1p, so it's not a priority for now.

    That's all the news for now, I'll post a new status update when there will be something worth writing about.

    HELP WANTED

    Despite this project has started as a bootloader and nothing more, I ended up targeting WAY more than just a bootloader for AVRs and others. In other words, I now ended up with:

    • A somewhat usable userspace C++ library (librf24pp) to work with these radios.
    • A set of tools based on this library
    • AVR and nRF24LU1p dongle firmware and hardware design
    • A HID bootloader for avr and nRF24LU1p
    • Possibly upcoming linux kernel driver for nRF24L01 connected to spidev (e.g. I've shoved my nrf24l01 in linux kernel once in a hacky way, it works, but submitting it to LKML will need some effort)

    And I really want to make it an awesome OpenSource nRF24L01 software stack. However I don't have much time for this project, and only commit stuff when I have time. In other words - HELP WANTED. If you think you can help with anything mentioned above, from documentation to hacking - drop me a note. I'll try to help you get started and of-course add your name to AUTHORS. It would be even greater if you are a windows guy who knows WinAPI, DDK and can help out with windows porting. Despite the fact that I really try hard to keep things more or less portable, I'm not really a windows-guy, so any help...

    Read more »

  • A 'cost-optimized' nrf24l01 design: details

    Necromant • 03/14/2015 at 11:07 • 0 comments

    For those wondering about internal details of those 'cost-optimized' nrf24l01 modules - I've made a full writeup in my blog here

  • A 'cost-optimized' nrf24l01 design from china

    Necromant • 03/13/2015 at 13:01 • 10 comments

    Just got 10 new nrf24l01 modules from china. Now accepting bets whether these will work at all.

    From a quick view (according to nordic's reference schematics, p. 69) - they are missing L1, L2, C3, C4, C6, R1, R2 and one of C8 or C9.

  • rf24boot: A huge update

    Necromant • 03/07/2015 at 16:25 • 0 comments

    There hasn't been much going with rf24boot for a while, till I was playing with esp8266 and accidentally writing frankenstein firmware for it. Despite being cool and cheap, esp8266 still consumes way more than nrf24l01, so I'm back to rf24boot. This time I've taken time to completely refactor all the linux userspace, improve and optimize dongle code, so librf24 is now actually a LibRF24PP (written in C++) and is a good deal faster and simpler.

    The rf24boot itself also lost a few hundred bytes in size due to random optimizations here and there and got a little bit faster. Here's a sample log of rf24boot bootloading a board (Host pc side).

    necromant @ sylwer ~/Dev/software/wisp$ rf24-boot --channel=13 --part="flash" --write --file=images/antares.bin  --run
nRF24L01 over-the-air programmer
(c) Necromant 2013-2015 <andrew@ncrmnt.org> 
This is free software licensed under the terms of GPLv2 or above
Adaptor: libusb/etheria
Local Address:  b0:0b:c0:de:ed
Remote Address: b0:0b:10:ad:ed
Waiting for target...GOTCHA!
Target:     red-wisp
Endianness: little
Partitions: 2
0.       eeprom  size     1024 iosize 16 pad 1
1.        flash  size    28672 iosize 16 pad 128
Writing partition flash: 15794/28672 bytes 
15794/15794 bytes | 3.35 s | 100.00 % done [################################################################################################################################################################################################]
Verifying partition flash against file images/antares.bin, 15794 bytes to verify
15794/15794 bytes | 2.01 s | 100.00 % done [################################################################################################################################################################################################]
Starting app in partition 1 (flash)...
All done, have a nice day!

    Apart from the actual bootloader, there are a set if linux userspace utilities upcoming, so that you can send and receive packets from commandline for fun, profit and testing. The first one you've seen above actually loads code onto the microcontroller. It's already ready for everyday use and API shouldn't change any time soon.

    One of the newly added utilities is called rf24-sweep. It uses your rf24 dongle and gnuplot to create you a nice chart showing what 2.4Ghz frequences are currently being used. Here's an obligatory screenshot. Upcoming are: rf24-send, rf24-listen and rf24-term (serial-like) terminal.

  • nrf24lu1: Up & running

    Necromant • 09/14/2014 at 09:53 • 0 comments

    nrf24lu1 usb sticks just arrived yesterday! So far I already threw up an SPI programming app of my own called nrfdude (uses uISP, the same firmware uISP-flashrog does:

    https://github.com/nekromant/nrfprog

    As you might guess, it's loosely based on nrfprog by JoseJX@github, although I had to rewrite 90% of the code from scratch (It used buspirate only - and not in the most portable fasion). The reason number one - I put my buspirate somewhere far and couldn't find it. Anyways, nrfdude is designed with multiple SPI adaptors supported, so you can easily hack in your favourite one.

    Achievement number 2 - nrf24lu1 is now a supported target by antares (experimental branch) and nrfdude is a valid deployment target. No big problems there - I just borrowed the C header from crazyradio and I could blink the led happily. 

    However, bigger problems are along the way - USB. If I hadn't seen fiberchannel and a handful of other stuff with even more weird specs, I'd say USB is worst. 

    It does look like the time has come for antares to have a proper USB device framework.

  • More boards, nrf24lu1 and etc.

    Necromant • 08/20/2014 at 22:31 • 0 comments

    Apart from getting a few more nice nrf24l01-aware boards ready for my own home automation you see on the pics below, I ordered a few nrf24lu1 usb dongles. I plan to give them a spin and see if I can hook them into rf24tool. 

    So far the librf24 refactor is going really slow, since I'm kind of buried under the amount of routine work, but the concept is mostly ready. I hope I have a more or less stable API in september. 

  • 8051 - here we come

    Necromant • 06/29/2014 at 13:31 • 0 comments

    Just got a chance to compile rf24boot for 8051 STC. 

    Well, the good news it now compiles (Though, it needs the experimental branch of antares) 

    The bad news - it occupies ~10KiB of flash with debugging disabled and 16K with debugging enabled. Looks like it's high time to make a stripped down version of rf24boot to further optimise size. 

  • Autoreset possible!

    Necromant • 06/28/2014 at 09:45 • 0 comments

    A few people asked if autoreset is possible with nrf24l01. With a little hack - it is! If you remember, rf24boot doesn't use IRQ line of nRF24L01. And since the IRQ line is active-low:

    * Connect IRQ line to the RESET via a jumper

    * Mask all nRF24L01 IRQs while the bootloader works. 

    * Unmask TX_DR (data received) IRQ just before jumping to app code

    * Any packet received by nRF24L01 will result in avr rebooting to bootloader as if reset has been pressed. 

    This won't work if you initialize nRF24L01 in your app code and use it for anything. So you'll still have to implement some kind of software-reset in your firmware or just get up and hit reset button yourself. 

    The trickery mentioned above will hit git master as soon as I get the boards for my next project where the required jumper is builtin.

  • Hate me

    Necromant • 06/24/2014 at 05:51 • 0 comments

    I have accidentally ditched the rf24boot project from hackaday.io when navigating from a cellphone with a broken touchscreen (it went mad and made its revenge on the guy who broke it!). I will try to fill in all the missing details ASAP.