Pro IoT SoftWare | Platforms And Technologies

Assumption is that you know what LoRa technology. Howevever, if you are not familiar with it basics are:

Topology used by LoRaWan network is laid out in star-of-stars topology. End-devices communicate with gateways that relay messages to network servers. Gateways use sophisticated digital baseband chip (SX1301) that use DSP to simultaneously decode up to 8 frequencies at any data rate. There is a lot more to it than just SX1301 (two more chips are required SX1257 and quite some more circuitry to tune front end RF circuits to 433MHz, 868MHz, 915 MHz or any other frequency band). Best place to get more info is LoRa Aliance.

Some low cost embedded devices support only 16 bit timers and sometimes in our applications we actually need 32 bit timers for whatever purpose it might be (E.g. measuring some events micro seconds, providing delays in micro seconds, etc).

Not long ago we had to scale down application to low power, lower cost Arm Cortex MCU but downside was that smaller, more energy efficient part did not have 32 bit timer required by the application. We were scaling from STM32F401RE down to STM32L100RCT device.

There is plethora of material on the net on how to do it in theory but very few actual examples on how to do it so if you are in need of quick solution to the same problem here is short guide on how to do it on real life example.

Processors

We have extensive experience across most contemporary and legacy processors to name the few:

Arm Processors 32/64 bit architectures
Low Power Processors Ti MSP430 families, Nordic nRF series, Freescale, STM32 Series, Atmel
Intel Desktop and Embedded Processors
AMD processors
Legacy 8/16/32 bit processors (Motorola, PowerPC, Intel, Z80)

Embedded Hardware Platforms

Beaglebone, Raspberry PI, Arduino, Freescale Tower System
Custom Developed Platforms (Compulab, Olimex and others)

Peripherals

Serial Communications (RS232, RS485, USB Serial)
Ethernet
WiFi
3G, 4G, NextG
Low Powered Radios (LoRa, UHF 433) and licenss free
RFID technologies
BlueTooth and BLE
LCD Displays, Touch Screens
Mass storage peripherals (SD Cards, Flash, SSD, HD)

Software

We cover most programing language, each one on expert level:

C/C++
Java/Java FX
C#
Python, Perl
NODE.js
JS, Angular

Operating Systems

We provide in-depth knowledge in configuration, deployment, device driver and application development on most operation systems (we also provide services of porting operating systems to proprietrary platforms):

Linux on all platforms (desktop and embedded)
Windows (desktop and embedded)
Android and iOS
FreeRTOS and similar

Software Development Frameworks

C/C++ - stdlb, Qt, boost
Java - Spring, Apache,
.NET
FreeRTOS and similar

Software Architecture, Design Principles And Development

We always provide top of the class architectural solutions that always focus on development cost, re-usability and platform indepenence. To name the few:

Inversion of Control
MVC
Platform independent development
Test Driven Development - TDD
Continuous Integration - CI (Automated build, test and deployment)

Using STM32 Discovery Board (ST-Link v1) With VisualGDB

Details: Published: Thursday, 09 June 2016 12:36; Written by Dub Bartolec

These days it happens to be that everything that has USB interface and it is connected to PC pretty much works out of the box.

Mainly it is like that, but from time to time it happens to be that certain combination of USB devices and certain software packages just don't work together when we need them most. When internet search for the solution to the similar problem doesn't give any result we often face hours of desperation trying to get something going burning valuable time. We've had similar situation recently.

In the past, I've used number of boards (MSP430, STM32, K6 and others) boards to make quick proof of concept solutions that can be demonstrated to clients during decision making phase of the projects to be deployed in IoT, M2M. They all worked fine until I've stumbled upon a batch of cards that just refused to be programmed from VisualGDB (IDE extension for Visual Studio).

Those particular boards were STM32VLDISCOVERY. Initially their USB interfaces were recognized by the VisualGDB as ST-Link v1 but on an attempt to test the connection they just did not work and it appeared that driver was not compatible with ST-Link. Those boards could easily be programmed by the STM32 STLink Utility.