RPi and CC2520 with 6LoWPAN on Linux

It's been a long time.

Last year I have very little time for my 6Lowpan project but last week finally I managed to run CC2520 transceiver on Raspberry Pi.

First of all i decided to use official CC2520 Linux driver developed by Varka Bhadram. This component handle all basic ruins required by upper layers of IPv6 stack. Yes - I'm going to use IPv6 with 6LowPAN adaptation sublayer. And my device will be IPv6 enable node.

6LowPAN and IoT is a popular topic - more about that you can find in IETF pages ( 6LowPan and 6Lo WG ). There is also very interesting blog by Walter Colitti: www.waltercolitti.consulting.

The base for my experiment with RPi and 6LowPan was openlabs.co page where configuration of a system is described.

Configuration of my solution i very similar. The main difference is obviously that I use CC2520 whereas openlabs solution use at86rf233 transceiver.

Kernel cross-compilation and U-Boot preparation are taken from openlabs. What we have to do to deal with CC2520 is change device tree file to adopt it to Rpi platform.

Below I present how it is done for RPi platform ( in this location: arch/arm/boot/dts/bcm2835-rpi-b.dts )

...

&gpio {

...

cc2520_cape_pins: cc2520_cape_pins {

brcm,pins = <17 22 23 24 25>;

brcm,function = <1 0 0 0 0>;

};

};

…

&spi {

status = "okay";

cc2520@0 {

compatible = "ti,cc2520";

reg = <0>;

spi-max-frequency = <6000000>;

pinctrl-names = "default";

pinctrl-0 = <&cc2520_cape_pins>;

fifo-gpio = <&gpio 25 0>;

fifop-gpio = <&gpio 24 0>;

sfd-gpio = <&gpio 23 0>;

cca-gpio = <&gpio 22 0>;

reset-gpio = <&gpio 17 0>;

};

};

Also CC2520.c file was slightly changed due to the different pin configuration in my board.

I didn’t use VREG signal on my board and I just commented out the lines that handle it.

After this operation I was able to first radio transmission. I received this first wireless packets on my STM32W-RFCKIT that I bought some time ago to sniff things like this. This is very handy solution because in prepared environment received frames are piped to Wireshark.

Below a print screen from Wireshark is presented.

RPi add-on board with CC2520 and LCD interface.

I would like to describe my new project: Raspberry Pi add-on board with radio transceiver CC2520 and st7565 LCD interface.

I connected two devices to one SPI which is available on the main RPi connector.
The radio circuit based on lab11 project: https://github.com/lab11/raspberrypi-cc2520
but I have used bigger resistors and caps. I add a circuit to LCD with st7565 driver which requers only 9 caps.

I have already tested SPI communication with cc2520. There is well-designed cc2520 character driver on lab11 repository but I decided not use it because it is solution for 6lowpan and I want to use cc2520 radio itself.

Now I aim to implement my own character driver for cc2520 that could be easily plug into another program code.

Linux driver for ST7565

Hello

Today I will describe my LCD module driver for ST7565. This driver based on fbtft library solution created by Noralf Tronnes.

As I mentioned in a previous post the frame buffer is the intermediate layer between higher kernel layers and video drivers. The frame buffer provider general abstraction to handle all forms of video device.

Our device can communicate with system via different types of bus ( eg. SPI, I2C or parallel ) therefore we have to link specific bus driver with frame buffer interface.  Below we can see "par" structure where "xxx platform device" or "xxx spi device" can be plug in. 

"xxx platform device" is a device defined in platform specific files, used to parallel bus connection.
"xxx spi device" is a spi device driver. 

The Linux device model is based on bus and device concepts.  More information you can find o

Linux Device Drivers.

The frame buffer is a platform specific segment of the system.  The most popular implementation for Raspberry Pi is Fbtft created by Noralf Tronnes. More information you can find here https://github.com/notro/fbtft/wiki

I decided to use fbtft because all frame buffer interface methods are implemented and my job was only to create a new device file with a few methods to implement a specialized interface for st7565 driver.

The most important methods are:

- static int init_display(struct fbtft_par *par) - executed during initialization in fbtft_register_framebuffer implemented in fbtft library.  

- static int write_vmem(struct fbtft_par *par, size_t offset, size_t len) - executed

during screen refreshing process. This function is taking a picture image from video memory buffer and convert it to appropriate to display device format. In my case video memory buffer have a format RGB 565 (16 bpp) with screen resolution 132 x 64. Because my LCD has only two colors I convert 16 bpp video memory format to 2bpp device format black and white. Conversion RGB 565 to 2bpp pattern is simple: zero values cast to black pixels and all the other to white pixels.

Last thing to do is prepare fbtft_display structure, in this structure we define parameters which are passed to fb_var_screeninfo and fb_fix_screeninfo structures. Second thing is our device specific operation which are assigned to fbtftops structure:

static struct fbtft_display display = {

        .regwidth = 8,

        .width = WIDTH,

        .height = HEIGHT,

        .txbuflen = TXBUFLEN,

        .gamma_num = 1,

        .gamma_len = 1,

        .gamma = DEFAULT_GAMMA,

        .fbtftops = {

                .init_display = init_display,

                .set_addr_win = set_addr_win,

                .set_var = set_var,

                .write_vmem = write_vmem,

                .set_gamma = set_gamma,

        },

        .backlight = 1,

};

You can find all code on this repository : 
https://github.com/zanaster/fbtft

Ok - and this is result of my work :  

 

An introduction and the frame buffer theory

My adventure with Raspberry Pi was started by chance. Some time ago my friend Maciek showed me Raspberry Pi and say that I can lend it for some time.I wondered about Raspberry application. First thought was a radio device with some 802.15.04 transceiver connected via SPI with the board. But then I found one LCD COG display with st7565r controller that I have used for some old project. I resigned from transsiver project and I decide to make some experiments with LCD and spi driver.

I began with little knowledge about Linux driver development. I had experience only with simple character device driver. Linux drivers seemed to be complicated to me. Therefore I decided to overcome my fear of Linux driver and create own from a scratch. I was starting read about Linux and device drivers.

I have read Essential Linux DeviceDrivers by Sreekrishnan Venkateswaran – is was a great introduction to my adventure with Linux drivers, there is a very good chapter about video driver with suitable information about frame buffer.

My LCD has a graphical display with 132x64 resolution. St7565r controller can be connected by SPI or parallel port. Here is a very nice page about it.

If I had a character LCD display it would be the best option to create a simple character device driver with supported file operations eg. open(), close(), write() and maybe ioctl for device specific operations like contrast setup. 

Yeah - but I wondered about something more and I have found information about frame buffer. 

Most device drivers are not directly implemented as character devices or block devices. They are implemented under a framework , specic to a device type (frame buffer, V4L, serial, etc.). The framework allows to factorize the common parts of drivers for the same type of devices. From userspace, they are still seen as normal character devices. The framework allows to provide a coherent userspace interface (ioctl numbering and semantic, etc.) for every type of device, regardless of the driver. 

The frame buffer is intermediate layer between higher kernel layers and video drivers. To present something on display with frame buffer support we need to implement specific programing interface. I think that frame buffer can consider as a proxy design pattern. The frame buffer provider general abstraction to handle all forms of video device.

User's applications can interface with the frame buffer by file operations or in other way (using mmap for example). The frame buffer has own ioctl method to set up video devices. All of structures are defined in include/linux/fb.h, fb_ioctl is defined in drivers/video/fbmem.c.
Fb_info is the main structure with all information about frame buffer. I prepare simplified diagram of it.

 
Now we have enough information to move forward. In the next post I will describe driver implementation details.

Hello All

I am an engineer from Poland. I think that I can share my knowledge about computer science and embedded systems with the world. I am intending to post some articles about Linux drivers, Raspberry Pi , microcontrollers and wireless technologii.