Elastic Sheep

Because elasticdog was already taken

Elastic Sheep header image 1

Serial Bluetooth module slave test

May 8th, 2011 · Uncategorized

I am going to test the connection of a serial Bluetooth module to my Mac laptop. Serial data will be provided to the module through a Teensy 2 used as a USB-to-Serial adapter.

Soldering the module on a breakout board

The difficulty is to correctly align all the module pins to the breakout pads. The module is so light that it can moves just because of the solder surface tension.

Two rows of header are added to fit in a prototyping breadboard.

Teensy 2 USB-to-Serial profile

I use the USBtoSerial project from LUFA 101122.

I already covered how to compile this project for the original Teensy in this previous post (Testing the LUFA USB Serial with GPS data). I apply the following modifications to the makefile:

MCU = atmega32u4
F_CPU = 16000000

Here is the binary: Teensy2-USBtoSerial.hex

To connect to the virtual serial port on a Mac:

$> sudo cu –s 9600 –l /dev/cu.usbmodemXXXX

A quick loopback test (direct wire from TX to RX) confirms that the profile is correctly working.

Useful to exit cu: ~.

Connections between the Teensy 2 and the BT module

The TX pin of the BT module is connected to the RX pin of the Teensy 2, and the RX pin on the TX pin.

My Teensy 2 board has been patched with a 3.3V regulator (see Converting the Teensy2 to 3.3V). I will use it to power the BT module.

The TX pin of the BT module is connected to the RX pin of the Teensy, and the RX pin on the TX pin.

Two leds are connected on PIO8 and PIO9 to display the status of the BT link.

The PIO11 pin is used to select the boot mode:

  • High => Command/Response mode where you can issue AT command to setup the module.
  • Low => Slave or master automatic operation.

Module configuration

I connect the PIO11 pin to the 3.3V rail. In this mode, the baud rate is 38400.

I open a cu session in the terminal and communicate with the BT module over its serial interface:

$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
Connected.
AT
OK
OK
OK
OK

The module sends the OK response repeatedly. Sending Ctrl-C can stop it. Then you can enter another commands.

AT+VERSION?
+VERSION:2.0-20100601
OK
AT+NAME?
+NAME:HC-05
OK
AT+ADDR?
+ADDR:11:3:252009
OK
AT+UART?
+UART:9600,0,0
OK

We can see that the module is currently configured for 9600 bauds operations with 1 stop bit, no parity.

I speedup the baudrate to 115200 bauds.

AT+UART=115200,0,0
OK
AT+UART?
+UART:115200,0,0
OK

I also change the role to slave-loop. In this mode, the module sends back all data it receives over the BT link. It is useful to check that the module can correctly receive and send data over the BT link before connecting it to your system.

AT+ROLE=2
OK
AT+ROLE?
+ROLE:2
OK

Now I power up the module with the PIO11 connected to GND to boot in autoconnect mode.

Pairing with a Mac

The connection of Bluetooth devices is handled by the System Preferences/Bluetooth panel.

The connection fails because the default passkey of the module is 1234. It can be changed with the AT+PSWD command.

The module is now successfully paired with the Mac but currently not connected.

It is recognized as a virtual serial port and corresponding devices are automatically created in the /dev directory:

$> ls /dev/*HC*
/dev/cu.HC-05-DevB	/dev/tty.HC-05-DevB

Slave-loop connection

I can now connect to the BT device and use it as a classic serial interface. In slave-loop mode, the characters are echoed back to the terminal.

$> sudo cu –s 115200 –l /dev/cu.HC-05-DevB
Connected.
ABCDEFGHIJKLM

The status of the bluetooth connection is reflected in the System Preferences panel.

Slave mode

I switch to the command/response mode and change back the role to slave:

AT+ROLE=0
OK
AT+ROLE?
+ROLE:0
OK

In this mode, the BT module acts as a full duplex serial interface. The data received over the BT link are forwarded to the its TX pin, while the RX pin incoming data are sent over the BT link.
So to test the connection I open two cu sessions. One is connected to the BT module, the other one to the Teensy 2 serial emulation. As the 2 devices serial pins are connected together, I am able to send characters on one session and receive them on the other sessions.

The first window displays the connection to the Teensy 2. The second window displays the connection to the BT module.

→ 16 CommentsTags:····

Bluetooth module breakout boards received

May 2nd, 2011 · Uncategorized

Go to the Shop page if you want to get one.

→ No CommentsTags:··

Serial Port Bluetooth module

April 16th, 2011 · Uncategorized

I recently ordered a couple of serial Bluetooth module on Ebay.

You can find the same board with different names and different flash memories on the net but they all are based on the same design. The main chip is a CSR BC417143 a.k.a. BlueCore4-External connected to a 8Mbit parallel Flash memory containing the firmware.

Here is the system architecture of the chip from the CSR datasheet:

The BlueCore4-Ext is a generic Bluetooth 2.0 EDR chip with a bunch of interfaces. The USB interface allows to use it in a USB BT dongle design. When integrating it in a microcontroller-based design, you could use the serial interface instead. The SPI interface allows the programming and configuration of the chip using CSR tools.
The provided firmware implements a Serial Port Profile based on a RFCOMM stack. But in theory this hardware could run other firmwares from CSR, for example a HCI stack to connect the chip as a generic BT USB dongle.

The module hardware is very small. The footprint is made to be soldered on another PCB. A serial breakout board is available with RX/TX connections and a 5V to 3.3V regulator. As I would like to tinker with the module to investigate its capabilities, I instead designed a breakout board allowing access to all the pins on a standard header.

I just ordered a batch of breakout boards from Olimex. I should receive them in a few weeks. If anyone is interested to get one, leave me a message. [Update 2011-05-06] Ordering informations are on the Shop page.

Update 2011-05-02

Here is the module datasheet provided by hongkong_electronics
BC4_Bluetooth Module Datasheet.zip

→ 4 CommentsTags:·

My blog mentioned in Open Silicium magazine

January 29th, 2011 · Uncategorized

Open Silicium is a new french magazine about open source and embedded system/hardware. It is published by the editor of Linux Magazine France. It is an interesting reading with eclectic articles that does not hesitate to dig into the hardware side.

But I think some of the articles may be difficult to grasp without a background in computer/electrical engineering. It reminds me of the magazines I was reading 15 years ago trying and often failing to make sense of articles about Turbo Pascal programming, entering program from paper to the computer. When the program worked you didn’t know why, and when it didn’t work you didn’t know why either!

What I was missing was good fundamentals on software and computer engineering. But at that time, the magazines where the only source of information I had, with local libraries very poorly filled with computer programming resources.

Now that the training knowledge is widespread and easily accessible through Internet, this kind of magazine is still useful to provide insight about different environment/tools/techniques. But if you are a beginner, you need to expect digging about the subjects you are interested in on your own.

Anyway thanks to the buzz around the Teensy2 and the PSGroove projet, I got a mention in this first issue. So thanks Open Silicium and keep up the good work!

→ No CommentsTags:

Adding alsa audio support to a Buildroot-based system

January 28th, 2011 · Uncategorized

I have tested the building of a basic Linux system with Buildroot. I would like now to add audio support to this system with mp3 decoding capabilities.

The mp3 decoding will be handled by the mpg123 application. The decoded audio playback will go through the alsa-lib userland interface that communicates with the alsa kernel subsystem.

The target hardware is the Versatile/PB platform emulated in QEMU.

System base configuration

The Builroot base configuration is the same as in my previous post:

  • Target Architecture: arm
  • Target Architecture Variant: arm926t
  • Target ABI: EABI
  • Toolchain/Kernel Headers: 2.6.36.x (I could specify a path to my kernel sources)
  • Package Selection for the Target/Busybox 1.17.x
  • Target Fileystem Options/cpio the root filesystem and Compression method: gzip

I select those options in the Buildroot configuration menu and then save the resulting config file in the configs directory.

$> cd buildroot-2010.11
$> make menuconfig
$> cp .config configs/versatilepb926_defconfig

The saved configuration can be directly applied from make if you want to return to a known state:

$> make versatilepb926_defconfig
#
# configuration written to [...]/buildroot-2010.11/.config
#

Adding the alsa and mpg123 support

To enable the alsa and mpg123 support:

  • Toolchain/Enable large file (file > 2GB) support
  • Package Selection for the target/Audio and Video libraries
    • alsa-lib
    • alsa-utils / aplay
    • mpg123

aplay is useful to check if simple WAV files can be played by the system. The Large File support is a dependency requirement from the alsa-utils package.

Adding the /dev/snd/* entries

By default, Buildroot does not add create audio device files. It uses the default device table that is located in target/generic/device_table.txt.

To add the /dev/audio and /dev/snd/* device files, I create a new device table file derived from the generic one adding the entries required by Alsa: target/generic/alsa_device_table.txt.

Then I change the selected device table in the Buildroot configuration:

  • Target Filesystem options/Path to the device table
    • target/generic/alsa_device_table.txt

Here is the updated audio section of the device table:

# Audio stuff
/dev/audio	c	666	0	29	14	4	-	-	-
#/dev/audio1	c	666	0	29	14	20	-	-	-
/dev/dsp	c	666	0	29	14	3	-	-	-
#/dev/dsp1	c	666	0	29	14	19	-	-	-
#/dev/sndstat	c	666	0	29	14	6	-	-	-
/dev/mixer	c	666	0	29	14	0	-	-	-
/dev/snd	d	755	0	29	-	-	-	-	-
/dev/snd/controlC0	c	666	0	29	116	0	-	-	-
/dev/snd/pcmC0D0c	c	666	0	29	116	24	-	-	-
/dev/snd/pcmC0D0p	c	666	0	29	116	16	-	-	-
/dev/snd/seq	c	666	0	29	116	1	-	-	-
/dev/snd/timer	c	666	0	29	116	33	-	-	-

My patched file for buildroot-2010.11: alsa_device_table.txt

Sorry I don’t remember the original source from where I copied those major/minor device numbers.

Saving the updated configuration

$> cp .config configs/versatilepb926_alsa_defconfig

Copying audio files in the root filesystem

Audio files can be directly copied in the output/target/root directory of Buildroot for test purposes.

When running make again, buildroot includes those files in the CPIO archive of the rootfs.

→ 5 CommentsTags:·····