SDCC went from worst STM8 compiler to best in a very short time

I never used STM8 but I’m impressed with this achievement of SDCC compiler.

The ST marketing materials put STM8 Dhrystone performance at 0.29 DMIPS / Mhz.

Commercial compilers as Raisonance achieves 0.289 DMIPS / Mhz, Cosmic achieves 0.296 DMIPS / Mhz and IAR achieves 0.347 DMIPS / Mhz. See benchmark comparison here: http://colecovision.eu/stm8/compilers.shtml

SDCC 3.5.0 achieves 0.151 DMIPS / Mhz and SDCC 3.6.0 achieve 0.167 DMIPS / Mhz.

Now the SDCC in the repository (Revision #9652) outperforms them all at 0.355 DMIPS / Mhz.

If you want to use STM8 on Linux, these links could be useful:
http://embedonix.com/articles/linux/setting-up-development-and-programming-for-stm8-on-linux/
http://www.cnx-software.com/2015/04/13/how-to-program-stm8s-1-board-in-linux/

Source: Philipp Klaus Krause email in the SDCC mailing list “STM8 Dhrystone performance – new record at 0.355 DMIPS / Mhz using SDCC”.

How to copy a schematic block in the KiCAD

KiCAD is a very nice EDA software, but it try to avoid copying blocks from a schematic to another (from different projects in this case).

Don’t worry! There is a way to you do that:

1) Select the block you want to copy;
2) Using the right mouse button select: "Save Block";
3) Insert a Hierarchical Sheet: menu Place -> Hierarchical Sheet;
4) Choose a "File name" for new sheet and click OK;
5) Press ESC and double click over the Hierarchical Sheet block;
6) Past (Ctrl+V) the saved block in this new sheet, save and close;
7) Open the other schematic where you want to include this block and import it:
   File -> Import Schematic Sheet Content

It might be easier, but KiCAD folks want to avoid users to mess.

Compiling KiCAD from source code on Debian Sid

These are the steps I did to compile KiCAD on Debian 8 Sid:

Download the source code:

$ git clone https://github.com/KiCad/kicad-source-mirror

Create a build directory:

$ cd kicad-source-mirror/
$ mkdir -p build/release
$ cd build/release

Install the dependences:

$ sudo apt-get install libwxbase3.0-dev libwxgtk3.0-dev libgl1-mesa-dev libglew-dev libglm-dev libcurl4-openssl-dev libboost-dev libboost-thread-dev libboost-system-dev libboost-context-dev libssl-dev wx-common libpython-dev python-wxgtk3.0-dev swig3.0

//create a symbolic link to pretend be swig2.0 for cmake:
$ sudo ln -s /usr/bin/swig3.0 /usr/bin/swig2.0

Execute the cmake configuration:

$ cmake -DCMAKE_BUILD_TYPE=Release  -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON ../../
$ make
$ sudo checkinstall

Done! Now we have a cutting-edge KiCAD version installed on our system!

Web Bluetooth on Chromium Debian SID – The Saga

If you are following my posts probably you saw my latest post about how to run Web Bluetooth on Chrome/Chromium:
https://acassis.wordpress.com/2016/06/28/how-to-get-chrome-web-bluetooth-working-on-linux/

Although in that post I got the Web Bluetooth working on Chrome/Chromium browser, I noted that after closing the browser and opening again the “get characteristic” sample was not able to list the BLE Device’s Characteristics again:
https://googlechrome.github.io/samples/web-bluetooth/discover-services-and-characteristics.html

Also I observed that after removing the bluez cache (entering in bluetoothctl and executing a “remove XX:YY:ZZ:KK:WW:AA”) the get characteristics sample was enable to list it again.

Then I worked with François Beaufort (a Google Chromium’s Developer) to figure-out what was going on. François was not facing this issue, because he uses a Chromebook powered by ChromeOS. At that moment we didn’t realize that even closing the sample page’s tab the Chromium keep running because it is the heart of ChromeOS. Later François discovered that if he “Sign out” and “Sign in” this issue also will affect him.

Initially we thought it could be some bug in the BlueZ 5.40, maybe bluez was not sending the data when it was cached. But we also discovered that after closing the browser if I issue a connection to device in bluetoothctl (“connect XX:YY:ZZ:KK:WW:AA”) and open the browser, then the get characteristics sample will work again. So it was not a fail of bluez to send cached data.

We decided to contact Luiz von Dentz (Bluez developer at Intel) at #bluez-users IRC channel and he figured out the issue:

vudentz: if (!IsGattServicesDiscoveryComplete()) {
vudentz:     VLOG(2) << "Gatt services have not been fully
resolved for device " << object_path_.value();
vudentz:     return;
vudentz:   }

vudentz: This is probably false if the device is disconnected since
ServicesResolved: no in that case
vudentz: This would explain why it is not enumerating the service on
InitializeGattServiceMap

vudentz:   // Notify on the discovery complete for each service
which is found in the
vudentz:   // first discovery.
vudentz:   DCHECK(adapter());
vudentz:   for (const auto& iter : gatt_services_)
vudentz:     adapter()->NotifyGattDiscoveryComplete(iter.second);
vudentz: This was also not in the original patch, why would we notify
on the InitializeGattServiceMap, there should be any client waiting for it

François was very kind and helpful instructing me to create many debug log to help him, his team and Luiz to debug the issue. Without his patience and dedication we couldn’t find a solution so fast. Thank you François!

The issue was fixed in the BlueZ 5.41 and latest chromium build.
Patch that was applied is https://codereview.chromium.org/2105423003

More info:
https://bugs.chromium.org/p/chromium/issues/detail?id=624400

How to get Chrome Web Bluetooth working on Linux

In my previous post I demonstrated how to test and scan for Bluetooth Low Energy:
https://acassis.wordpress.com/2016/06/27/getting-started-with-bluetooth-low-energy-on-linux/

Now I will explain what I did to get Bluetooth Low Energy working on Linux Debian.

First I installed the Chrome Dev version 53 from here:
https://www.google.com/chrome/browser/desktop/index.html?platform=linux&extra=devchannel

But the Bluetooth Scan Page example was not working:
https://googlechrome.github.io/samples/web-bluetooth/device-info.html

Then searching in the forums I discovered these four requirements to get it working:
1) A recente Chrome version 45+ (I’m using version 53);
2) A recente Linux kernel 3.19+ (my kernel was too old: 3.16);
3) BlueZ 5.40+ (my bluez version was 5.36);
4) Bluetooth daemon (bluetoothd) running with experimental interface (/usr/bin/bluetoothd -E).

Then I updated my Linux kernel:

$ sudo apt-get install linux-image-4.6.0-1-amd64

Compiled Bluez 5.40:

// Install the dependecies:
$ sudo apt-get -y install automake autotools-dev bison check clang flex lcov libcap-ng-dev libdbus-glib-1-dev libdw-dev libglib2.0-dev libical-dev libreadline-dev libtool libudev-dev

//Download bluez-5.40:
$ wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.40.tar.xz

//Extract it:
$ tar xvf bluez-5.40.tar.xz

// Configure and compile it:
$ cd bluez-5.40
$ ./configure --prefix=/usr           \
            --mandir=/usr/share/man \
            --sysconfdir=/etc       \
            --localstatedir=/var    \
            --enable-library        \
            --disable-systemd       \
            --disable-android       \
            --enable-experimental
$ make

// Create a debian package with checkinstall:
$ sudo checkinstall

Here checkinstall didn’t create the /usb/bin/bluetoothd link, let us to create it:

# ln -s /usr/libexec/bluetooth/bluetoothd /usr/bin/bluetoothd

We need to stop bluetoothd daemon and call it with -E:

# /etc/init.d/bluetooth stop
# /usr/libexec/bluetooth/bluetoothd -E &

Now let see if Chromium could communicate with the BLE device:

$ ./chrome --enable-web-bluetooth

Then open the sample page to test Discover Services and Characteristics:
https://googlechrome.github.io/samples/web-bluetooth/discover-services-and-characteristics.html

I will test the Nordic Serial Service, then I enter:

6e400001-b5a3-f393-e0a9-e50e24dcca9e

After updating bluez to version 5.40 the Bluetooth Chooser pop-up window stopped to list the nearby Bluetooth LE devices.

This issue was caused because I used “ControllerMode = le” in the /etc/bluetooth/main.conf. This BUG didn’t exist in the bluez 5.36.

Changing “ControllerMode = dual” in the /etc/bluetooth/main.conf fixed the issue (thanks François Beaufort for the help).

And after restarting bluetoothd and clicking on “Discover services and characteristics” and choosing the Nordic_UART device, it returns:

Requesting any Bluetooth Device...
> Name:             Nordic_UART
> Allowed Services: 6e400001-b5a3-f393-e0a9-e50e24dcca9e
Connecting to GATT Server...
Getting Services...
Getting Characteristics...
> Service: 6e400001-b5a3-f393-e0a9-e50e24dcca9e
>> Characteristic: 6e400003-b5a3-f393-e0a9-e50e24dcca9e [NOTIFY]
>> Characteristic: 6e400002-b5a3-f393-e0a9-e50e24dcca9e [WRITEWITHOUTRESPONSE, WRITE]

References:
https://github.com/beaufortfrancois/sandbox/blob/gh-pages/web-bluetooth/Bluez.md
http://www.linuxfromscratch.org/blfs/view/svn/general/bluez.html

Getting started with Bluetooth Low Energy on Linux

I’m working with BLE on Linux and decided to share here my finding.

First you will need a Bluetooth Low Energy (BLE) compatible host, then if your laptop’s bluetooth is not BLE compatible you will need a bluetooth dongle.

Searching in the Internet I discovered that this low cost CSR V4.0 is compatible.

When plugin it on my laptop I got this info:

#dmesg
...
[ 8972.648662] usb 3-3: new full-speed USB device number 16 using xhci_hcd
[ 8972.870695] usb 3-3: New USB device found, idVendor=0a12, idProduct=0001
[ 8972.870699] usb 3-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 8972.870702] usb 3-3: Product: CSR8510 A10

Let see the lsusb listing (idVendor=0a12, idProduct=0001):

# lsusb 
...
Bus 003 Device 016: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Ok, but for some strange reason my Debian 8.0 delayed some time (~30s) to get it working, strange but at least:

# hciconfig -a hci0
hci0: Type: BR/EDR Bus: USB
BD Address: 00:1A:7D:DA:XX:XX ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:10241 acl:0 sco:0 events:348 errors:0
TX bytes:1738 acl:0 sco:0 commands:47 errors:0
Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'inspire'
Class: 0x00010c
Service Classes: Unspecified
Device Class: Computer, Laptop
HCI Version: 4.0 (0x6) Revision: 0x22bb
LMP Version: 4.0 (0x6) Subversion: 0x22bb
Manufacturer: Cambridge Silicon Radio (10)

Now let search for a Bluetooth LE device:

# hcitool lescan
LE Scan ...
BC:6A:29:AB:3F:46 (unknown)
BC:6A:29:AB:3F:46 SensorTag
BC:6A:29:AB:3F:46 (unknown)
BC:6A:29:AB:3F:46 SensorTag
BC:6A:29:AB:3F:46 (unknown)

You can connect to this device using the gattool

# gatttool -I
[                 ][LE]> help
help                                           Show this help
exit                                           Exit interactive mode
quit                                           Exit interactive mode
connect         [address [address type]]       Connect to a remote device
disconnect                                     Disconnect from a remote device
primary         [UUID]                         Primary Service Discovery
included        [start hnd [end hnd]]          Find Included Services
characteristics [start hnd [end hnd [UUID]]]   Characteristics Discovery
char-desc       [start hnd] [end hnd]          Characteristics Descriptor Discovery
char-read-hnd                          Characteristics Value/Descriptor Read by handle
char-read-uuid   [start hnd] [end hnd]   Characteristics Value/Descriptor Read by UUID
char-write-req              Characteristic Value Write (Write Request)
char-write-cmd              Characteristic Value Write (No response)
sec-level       [low | medium | high]          Set security level. Default: low
mtu                                     Exchange MTU for GATT/ATT
[                 ][LE]> connect BC:6A:29:AB:3F:46
Attempting to connect to BC:6A:29:AB:3F:46
Connection successful

// Let to list primary Services:
[BC:6A:29:AB:3F:46][LE]> primary
attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0010, end grp handle: 0x0022 uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x0023, end grp handle: 0x002a uuid: f000aa00-0451-4000-b000-000000000000
attr handle: 0x002b, end grp handle: 0x0035 uuid: f000aa10-0451-4000-b000-000000000000
attr handle: 0x0036, end grp handle: 0x003d uuid: f000aa20-0451-4000-b000-000000000000
attr handle: 0x003e, end grp handle: 0x0048 uuid: f000aa30-0451-4000-b000-000000000000
attr handle: 0x0049, end grp handle: 0x0054 uuid: f000aa40-0451-4000-b000-000000000000
attr handle: 0x0055, end grp handle: 0x005c uuid: f000aa50-0451-4000-b000-000000000000
attr handle: 0x005d, end grp handle: 0x0061 uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
attr handle: 0x0062, end grp handle: 0x0068 uuid: f000aa60-0451-4000-b000-000000000000
attr handle: 0x0069, end grp handle: 0xffff uuid: f000ffc0-0451-4000-b000-000000000000

//Let see the visible characteristics:
[BC:6A:29:AB:3F:46][LE]> char-desc 0x0018 0x002A
handle: 0x0018, uuid: 00002a26-0000-1000-8000-00805f9b34fb
handle: 0x0019, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001a, uuid: 00002a27-0000-1000-8000-00805f9b34fb
handle: 0x001b, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001c, uuid: 00002a28-0000-1000-8000-00805f9b34fb
handle: 0x001d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x001e, uuid: 00002a29-0000-1000-8000-00805f9b34fb
handle: 0x001f, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0020, uuid: 00002a2a-0000-1000-8000-00805f9b34fb
handle: 0x0021, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0022, uuid: 00002a50-0000-1000-8000-00805f9b34fb
handle: 0x0023, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0024, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0025, uuid: f000aa01-0451-4000-b000-000000000000
handle: 0x0026, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0027, uuid: 00002901-0000-1000-8000-00805f9b34fb
handle: 0x0028, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0029, uuid: f000aa02-0451-4000-b000-000000000000
handle: 0x002a, uuid: 00002901-0000-1000-8000-00805f9b34fb
[BC:6A:29:AB:3F:46][LE]> 

Nice! Everthing is working!

The “gatttool” is deprecated and will be removed soon, then we need to use bluetoothctl instead! This way:

# bluetoothctl
//scan for BLE devices:
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:1A:7D:DA:71:10 Discovering: yes
[CHG] Device EC:F2:E5:CE:30:5B RSSI: -44
[CHG] Device EC:F2:E5:CE:30:5B RSSI: -52
[CHG] Device EC:F2:E5:CE:30:5B RSSI: -44

//connect to it:
[bluetooth]# connect EC:F2:E5:CE:30:5B
Attempting to connect to EC:F2:E5:CE:30:5B
[CHG] Device EC:F2:E5:CE:30:5B Connected: yes
Connection successful

//get information from device
[Nordic_UART]# info
Device EC:F2:E5:CE:30:5B
	Name: Nordic_UART
	Alias: Nordic_UART
	Paired: no
	Trusted: yes
	Blocked: no
	Connected: yes
	LegacyPairing: no
	UUID:                           (1800)
	UUID:                           (1801)
	UUID: Vendor specific           (6e400001-b5a3-f393-e0a9-e50e24dcca9e)
	RSSI: -44

//list the attributes
[Nordic_UART]# list-attributes
Service /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009 Vendor specific (Primary)
Characteristic /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009/char000d Vendor specific
Characteristic /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009/char000a Vendor specific
Descriptor /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009/char000a/desc000c Client Characteristic Configuration

//get information from an attribute:
[Nordic_UART]# attribute-info /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009
Service - Vendor specific
	UUID: 6e400001-b5a3-f393-e0a9-e50e24dcca9e
	Primary: yes
	Characteristics: /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009/char000a
	Characteristics: /org/bluez/hci0/dev_EC_F2_E5_CE_30_5B/service0009/char000d

The listing of primary services you can find here:
https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

The listing of characteristics you can find here:
https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicsHome.aspx

Case you don’t have a BLE compatible device to search for, you can transform your smartphone in a BLE device using the peripheral mode application:
https://github.com/WebBluetoothCG/ble-test-peripheral-android

References: https://learn.adafruit.com/reverse-engineering-a-bluetooth-low-energy-light-bulb/control-with-bluez

How I got fooled by Nordic’s app_uart_init

The Nordic nRF51822 SDK supports two serial communication modes: raw and fifo.

There are two macros used to initialize each mode:

APP_UART_INIT(P_COMM_PARAMS, EVT_HANDLER, IRQ_PRIO, ERR_CODE)

APP_UART_FIFO_INIT(P_COMM_PARAMS, RX_BUF_SIZE, TX_BUF_SIZE, EVT_HANDLER, IRQ_PRIO, ERR_CODE)

Once initialized you can use “app_uart_put()” to send a character and “app_uart_get()” to get a character.

If you initialize with APP_UART_FIFO_INIT() macro, but link your application to app_uart.c instead of app_uart_fifo.c everything will compile fine.
You could send some text using app_uart_put in your main() function, but when you get some BLE data received event and try to use it… you will get troubles!

Only the first character will be sent to UART, nothing else…

I spent much time trying to figure-out why it was not working, finally I found someone with same problem and he give a hint:

https://devzone.nordicsemi.com/question/20383/sending-via-uart/

Just linking to app_uart_fifo.c instead of app_uart.c fixed the issue!