hardwario / twr-sdk

HARDWARIO TOWER Firmware SDK (Software Development Kit)

HARDWARIO Firmware SDK

This repository contains firmware SDK for:

• HARDWARIO Core Module
• HARDWARIO Radio Dongle
• HARDWARIO Cloony

Introduction

Firmware SDK for Core Module is implemented in C (ISO C99) language. It is the core foundation of all the firmware repositories and device projects.

In short it is a set of libraries and APIs which simplify embedded firmware development workflow.

All the drivers provide high-level abstraction of the underlying hardware and follow event-driven approach.

The whole library is documented using Doxygen and automatically generated at sdk.hardwario.com with every commit/merge to master branch using Travis CI.

Firmware SDK also comes with Makefile recipe to build the firmware projects.

This repository is best integrated within each firmware project as a Git submodule so it is easy to update it to the most recent version and at the same time keep the know-to-work version of the firmware locked to the specific commit of the SDK.

License

This project is licensed under the MIT License - see the LICENSE file for details.

---

Made with ❤  by HARDWARIO s.r.o. in the heart of Europe.

twr-sdk's Issues

BC_LED_MODE_BLINK_* actual speed?

What is the actual delay between state changes defined by

• BC_LED_MODE_BLINK_SLOW
• BC_LED_MODE_BLINK_FAST
• BC_LED_MODE_BLINK
• BC_LED_MODE_FLASH

I don't see it described in documentation. Thanks.

POWER

Add ability to define parameters for RX2 window (module bc_cmwx1zzabz)

It will be useful to be able to define parameters of LoRaWAN second receive window. In case of OTAA this parameter is set according to join reply of network server but in case of ABP you need to set this parameter manually. Problem is that RX2 configuration is network dependent and e.g. The Things Network use different configuration (see LoRaWAN Frequencies Overview) than default one of modem.

According to my observation default is 869.525 MHz and DR0. But TTN use DR3 (SF9BW125). There is AT command AT+RX2 for that but this AT command is not supported in current SDK.

bc_module_battery_get_voltage() always returns 0

Since commit bcb25bd the bc_module_battery_get_voltage() function always returns 0V.

Works correctly in https://github.com/bigclownlabs/bcf-generic-node/releases/tag/v1.5.0 and does not works in https://github.com/bigclownlabs/bcf-generic-node/releases/tag/v1.5.5

The reason seams to be there: https://github.com/bigclownlabs/bcf-sdk-core-module/blob/master/bcl/src/bc_adc.c#L222

The BC_ADC_FORMAT_FLOAT part is commented out. When I uncomment it, the bc_module_battery_get_voltage() function works again. Only returns little bit bigger value (6.32V in generic-node v1.5.0 vs. 6.75V in latest).

Is there any reason, why was this part commented out?

Incorrect color handling in twr_gfx_draw_fill_rectangle_dithering()

Hi,
when computing pixel color in twr_gfx_draw_fill_rectangle_dithering() function, following code is used:

uint32_t d_color = color & (1 << (dx + 4*dy));

This produces either zero or some positive number in range [1…32768]. This will work fine with monochromatic implementations considering any positive value to be black, but it will break any implementation expecting real color value (for multicolor displays). There is another drawback, which will not allow to choose dithering color.

My suggestion is to fix this function to consistently produce color value of "0" or "1", for example:

uint32_t d_color = (color & (1 << (dx + 4*dy))) >> (dx + 4*dy);

And to introduce another function to allow for multicolor dithering:

void twr_gfx_draw_fill_rectangle_dithering_color(twr_gfx_t *self, int x0, int y0, int x1, int y1, uint16_t pattern, uint32_t color_fg, uint32_t color_bg)
{
    int y;
    for (; x0 <= x1; x0++)
    {
        for (y = y0; y <= y1; y++)
        {
            uint8_t dx = x0 % 4;
            uint8_t dy = y % 4;
            uint32_t d_color = pattern & (1 << (dx + 4*dy)) ? color_fg : color_bg;
            twr_gfx_draw_pixel(self, x0, y, d_color);
        }
    }
}

void bc_usb_cdc_start(void);

void bc_usb_cdc_start(void); is not used anywhere in the SDK?

https://github.com/bigclownlabs/bcf-sdk/blob/2b167dce4cce0c460cbb8521e8222c298c1e5dae/bcl/inc/bc_usb_cdc.h#L7

return codes

On any error return false; is returned. On no error, return true; is returned.

I propose to change it such that on no error 0 is returned. On error a positive number is returned.

As it is now, it is impossible to know where exactly the function fails...

Add ability to send confirmed LoRaWAN message and check ACK (module bc_cmwx1zzabz)

I will be useful be able to send confirmed message and check if message was confirmed or not (by event).

Current SDK use AT+UTX (unconfirmed transmission). There is also AT+CTX (confirm transmission).

Wrong screen dimension handling for 90/270 degree display rotation in twr_gfx.c

Hi,
while implementing twr_gfx support for waveshare 2.9" e-ink display (128×296 pixels), I noticed wrong behavior for 90 and 270 degree display rotation. It works OK with LCD module as it have square 128×128 display, but it doesn't work for non-square displays.

In particular, problem is in following code snippets from twr_gfx_draw_pixel():

        case TWR_GFX_ROTATION_90:
        {
            tmp = x;
            x = self->_caps.height - 1 - y;
            y = tmp;
            break;
        }

        case TWR_GFX_ROTATION_270:
        {
            tmp = y;
            y = self->_caps.width - 1 - x;
            x = tmp;
            break;
        }

this should be:

        case TWR_GFX_ROTATION_90:
        {
            tmp = x;
            x = self->_caps.width - 1 - y;
            y = tmp;
            break;
        }

        case TWR_GFX_ROTATION_270:
        {
            tmp = y;
            y = self->_caps.height - 1 - x;
            x = tmp;
            break;
        }

Logic behind this is, that screen size is relevant to left side of assignment as it represents hardware coordinates. As an example, for my 128×296 display and 270° rotation, writing pixel to 0,0 coordinates should translate to bottom left which is 0,295:

original code: y = self->_caps.width - 1 - x = 128 - 1 - 0 = 127
fixed code: y = self->_caps.height - 1 - x = 296 - 1 - 0 = 295

Fix format

https://github.com/bigclownlabs/bcf-sdk/blob/0e65393394b067283352fcc6f75615e65427b9a6/bcl/src/bc_pyq1648.c#L25

Wrong pointer calculation in bc_radio_uint16_to_buffer

It should be uint16_t:

https://github.com/hardwario/bcf-sdk/blob/bf549c739518c7f3de233c7e448f6b623821d8c4/bcl/src/bc_radio.c#L1170

You owe me a beer, this was hell to debug as I didn't expect any mistake in SDK ;-).

Remove hard-coded channel from kit's firmwares

I found it strange that I have to define pub channels in kit's firmware like this: https://github.com/bigclownlabs/bcf-kit-wireless-climate-monitor/blob/master/app/application.c#L71

When you write you firmware from the scratch you have to dive into SDK and found/derive the "channel" for yourself. It would be better if channel is provided in the event somehow, similar to what's done here: https://github.com/bigclownlabs/bcf-kit-wireless-motion-detector/blob/master/app/application.c#L58

What do you think about it?

Scheduler timing is way off

When using scheduler to execute task at specific interval (e.g. 2s), task gets executed late after only few executions. Debug time stamps are exactly at desired interval - 2s, but in reality it is not 2s.

sigfox get device pac bug

I think that the following code is wrong. As a response I get ED700B1981C3FC7F or as dec 069d 068d 055d 048d 048d 066d 049d 057d 056d 049d 067d 051d 070d 067d 055d 070d so there is no \r and the length is 16 characters and not 17.

https://github.com/bigclownlabs/bcf-sdk/blob/216c8e8060f8cf7349faa2e1458313c226242870/bcl/src/bc_wssfm10r1at.c#L140

    if (strlen(self->_response) != 17 || self->_response[16] != '\r')
    {
        return false;
    }

EDIT: I think the same will go for bc_wssfm10r1at_get_device_id

Add support for publishing battery charge level

Because you offer two various battery modules I think it would be more useful to sent battery charge level instead of voltage. The reason is that if you save data from sensors into e.g. InfluxDB and you want to graph the charge level you have to know the "maximum" voltage for each sensor which is not easy to do.

Here's what I've implemented for myself for now: https://github.com/synaptiko/bigclown-nodes-firmware/blob/master/apps/climate-monitor/application.c#L34-L44

Add ability to define uplink port for LoRaWAN message (module bc_cmwx1zzabz)

It will be useful to be able to define port for uplink message. Modem has AT command AT+PORT for that but this AT command is not supported in current SDK.