[SOLVED] My first steps - can't make LCD work

today I received my first set of modules - battery, core, encoder, lcd and some tags. I’m on Gentoo linux, cross compiling set via crossdev.

$ gcc-config -l
 [1] arm-none-eabi-5.4.0 *
 [2] arm-none-eabi-6.4.0

 [3] x86_64-pc-linux-gnu-6.4.0 *

I started with basic functionality in bcf-skeleton-core-module repo. But it does not works :frowning: LED did not switch on after reset. After many tries I switched to gcc-5.4.0 and it starts working. Is gcc-6.4 supported?

Then I replaced the app content with sdk/_examples/lcd-text content. Compiled, flashed and nothing. Does not works :frowning: LCD is blank. Even if I comment all rows except bc_module_lcd_init, it does not work, LED is not switched on:

#include <application.h>

#define BLACK true

// LED instance
bc_led_t led;

void application_init(void)
    // Initialize LCD
    // The parameter is internal buffer in SDK, no need to define it

   // Don't forget to update

   // Initialize LED
   bc_led_init(&led, BC_GPIO_LED, false, false);
   bc_led_set_mode(&led, BC_LED_MODE_ON);


I’m using latest SDK. I had to update the sdk submodule as it does not compile. After it, compilation finishes without errors. But does not work.

When I remove lcd related row, LED switch on after reset.

What I’m doing wrong? Did I miss something?

Hello, I tried to compile your example and it works on my board. We have few ways to figure out what could be wrong.

First, let’s try the precompiled binaries from Github, so we can be sure, that your hardware is ok. Please install bcf Python flashing utility by pip3 install bcf. Then run sudo bcf update and sudo bcf list. We will try to upload the remote firmware which displays connected sensors’ values on the LCD module. Do not forget to set the Core Module to DFU mode before flashing.

bcf flash --dfu bigclownlabs/bcf-generic-node:firmware-battery-mini.bin:v1.4.0

Then I tried to display some text:
I cloned the bcf-skeleton-core-module, I don’t even updated the submodule, then I run compilation on my windows machine with make. Here is info about my gcc version.

gcc version 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437] (GNU Tools for ARM Embedded 
Processors 6-2017-q2-update)

I’ve used this code to display text:

void application_init(void)
    // Initialize LCD
    // The parameter is internal buffer in SDK, no need to define it
    bc_module_lcd_draw_string(5, 5, "Hi from LCD", true);

   // Don't forget to update

   // Initialize LED
   bc_led_init(&led, BC_GPIO_LED, false, false);
   bc_led_set_mode(&led, BC_LED_MODE_ON);

The text appears on the LCD and the red LED is also lit.

Please let us know your results.

I’ll test it evening. My gcc (as prepared by crossdev - default options):

$ arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /var/tmp/portage/cross-arm-none-eabi/gcc-5.4.0-r3/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/arm-none-eabi/5.4.0/include --datadir=/usr/share/gcc-data/arm-none-eabi/5.4.0 --mandir=/usr/share/gcc-data/arm-none-eabi/5.4.0/man --infodir=/usr/share/gcc-data/arm-none-eabi/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/arm-none-eabi/5.4.0/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0-r3 p1.4, pie-0.6.5' --enable-poison-system-directories --disable-shared --disable-libatomic --disable-threads --without-headers --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer
Thread model: single
gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.4, pie-0.6.5)

Probably I need change some options for compiller

the downloaded fireware works.

In next step I download a linux tarbal from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads , unpacked and set PATH so this is used during compilation.

export PATH="/opt/gcc-arm-none-eabi-6-2017-q2-update/bin/:$PATH"

And it works. So issue is probably with some missing option of Gentoo crossdev compiled arm gcc. I’ll will investigate it and let you know if I found a working setup. If not, I can use the downloaded toolchain.

Hi, actually the toolchain you downloaded from arm.com is a preferred way, since this is ARM validated tarball and we always use this one for all our firmware development and deployment. It is actually a former distribution tarball from Launchpad: https://launchpad.net/gcc-arm-embedded

The tutorial in our development setup references PPA repositories on Ubuntu and Homebrew on macOS, but they all use the same origin…

Ok. So I’ll continue with this one. I also will try update the official doc to reflect other linux distributions.

Awesome, such contribution would be great - we are writing a new documentation in bc-website repo on our GH. It would be best to commit it there already. I was planning to commit firmware development setup tomorrow.

Well I’ll probably play a little with my new toy now, as it finally works :smiley: :handshake:

Cool - have fun and let us know if you have any more issues. Cheers!

Is it possible to pair sensor with two base stations? My planned setup is outside sensor(s), core module with LCD as simple meteo station and USB dongle in Turris to store data and visualize them. So I need to sent values from the sensor to both modules - Meteo module with LCD and Turris. And I also need to sent Meteo module data to Turris.

Is it possible? Or I need make Meteo station module or Turrs as a Master and re-publish all data from remote sensors to subMaster?

The problem with any Master is that, in case of outage of the Master, LCD will not show remote values (Turris is Master) or data are not stored on Turris (meteo is Master)

The current implementation is a start radio topology, so the simple answer is “no, it is not possible right now”. However, if you do a few tweaks to bc_radio.c in address filtering part, it is not that difficult to simply broadcast the measured data and enroll the broadcaster’s address to as many receivers as possible. Otherwise, you can do as you suggest - to relay the data forth and back. We also do it with other projects…

Thanks. I’ll think about it. I’m still investigating possibilities and planning what I want (or will be able) implement.

Initial request is replacement of current, sometimes freezing, weather station with something similar and connect it to Turris, so in the last step I’ll be able to see actual and historic values on my desktop. E.g. via nice KDE Plasmoid :smiley:

Oh that sounds cool - could you please share a screenshot when you have that working? I am really interested to see how it looks like. Thx!

Sure. But will take some time. Also I’ll need buy modules for remote sensor and usb dongle soon. Currently I have only one core with LCD, Encoder and battery module. And some tags :wink:

No problem, Take your time. BTW USB Dongle is available on email pre-order now :slight_smile:

And what is final price (in CZK)? Or can I see / buy it on LinuxDays? :wink:

This year we are not going to Linux Days, but I will be at DevFest. The price is 890 CZK,

It looks like this:

1 Like

Could be like this? https://github.com/mkyral/bc-website/blob/c5212e6556f2cc53dedd9d8693138e4495fe8f71/content/doc/firmware/toolchain-setup.en.md

Hi, I quickly went through it and it looks pretty good to me. Will you send pull request so I can merge it? Thanks! P.

I will sent a pull request - needs to check typos first.