Development



<div style="width:70%; margin:auto;">
<h2> What are embedded systems? </h2>
Embedded systems are computer systems with a specific function within a larger system. This includes all computing systems, such as home appliances, digital watches, cameras, avionics, and medical devices, except for PCs and smartphones. When classifying embedded systems by their main computing component, two of the most common types are microcontroller (MCU) and a microprocessor (MPU/CPU) based systems. There are also DSP, FPGA and custom ASIC-based systems. 


Microcontroller-based embedded systems are typically programmed either without an operating system, known as "bare metal," or with a real-time operating system (RTOS). Microcontrollers are cost-effective, single-chip computers that include a CPU, memory, and input/output capabilities on a single integrated circuit (IC). However, their specifications are limited compared to standard PCs, with less than 1MB of RAM and less than 8MB of flash memory, and typically only one CPU core with a frequency of less than 500MHz. Many 32-bit microcontrollers today are based on ARM Cortex-M CPUs.

In contrast, microprocessor-based systems, which are based on more powerful CPUs such as ARM Cortex-A, run Linux and have specifications more similar to PCs or smartphones. These systems, known as single-board computers, feature RAM, eMMC (flash), and various peripheral chips on the board, rather than on a single IC.

![1.png](https://strapi.suprabit.eu/uploads/1_a622eb8f94.png)

While microcontroller-based systems are generally more affordable and energy-efficient than embedded Linux devices, they also have more limited computing capabilities and feature sets. This blog post will focus on the unique characteristics of microcontroller-based embedded systems. However, as part of the Internet of Things (IoT) ecosystem, modern embedded systems are expected to have a range of features such as wireless communication, internet connectivity, and advanced sensors and actuators, all while maintaining cost and power efficiency. Careful consideration of both hardware and software is crucial for the successful design and development of these devices.

<h3> Optimizing power consumption </h3>
When selecting components for a wireless embedded device, it is important to consider factors such as suitability for the intended application, software and community support, market availability and cost. The microcontroller, RF communication chip, and sensors/actuators are the main components to evaluate. Factors like deep sleep functionality, communication interfaces, security options, processing speed, and memory of the microcontroller should all be taken into account to ensure that the device's requirements are met in the most optimal way possible.

<h3>MCU</h3>
Low-power MCUs on the market can typically achieve current consumption below 1 μA in their sleep modes. Some of these include ST's STM32L0xx, Silicon Labs' C8051F98x, Microchip's SAM Lx and TI's MSP430.
In our recent project, we used STM32L051 MCU and in its Stop mode, we were able to achieve 1.3 μA with Low Power Timer and Watchdog running.



 ![Microchip.png](https://strapi.suprabit.eu/uploads/Microchip_a7739c6ed3.png)


<h3> RF communication chip </h3>
When choosing an RF communication chip, it's important to select an appropriate wireless communication protocol that takes into account factors such as power consumption, range, and throughput. Factors that will affect the power consumption of the device are protocol frequency (sub-GHz, 2.4 GHz, 5 GHz, etc.), data packet length, the number of messages being sent within a certain timeframe, and signal power. Operating frequency affects range, power consumption, and throughput. Lower frequencies (sub-GHz) have better range and lower power consumption, while higher frequencies have better throughput. It's essential to keep the number of messages sent within a certain timeframe as low as possible for battery-powered devices, usually 1-2 messages every 10+ minutes. Smaller data packet length increases the throughput and power efficiency of a protocol, as it takes less time to transmit information and keeps the RF transceiver in active mode. With greater power, the range is increased, but so is power consumption. Low-power RF chips on the market can typically achieve current consumption in the nA or few μA range in their sleep modes, making them a good choice for battery-powered devices. In our recent project, we used AX5243 sub-GHz RF chip at 868 MHz with a custom protocol. In its Powerdown mode, we were able to achieve 0.8 μA.

![2.png](https://strapi.suprabit.eu/uploads/2_d19cc36535.png)
When choosing sensors/actuators, their idle current consumption should also ideally be in nA or worst-case few μA range.

Besides hardware, software choices and optimizations can also greatly affect the power consumption of a device; choosing the appropriate sleep mode of the MCU and RF chip, minimizing time spent in running mode of the MCU and RF chip, using only the lowest-power MCU timer while the device is in idle mode, setting MCU peripherals in low-power mode, etc.



<h5>Here are some important takeaways from our recent project with STM32L051:</h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>

<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">setting all unused GPIOs as analog inputs has reduced average current consumption by a few μA</li>
<br/>
<li style="color:#ffffff">ADC needed to be powered off after each measurement, otherwise it would add ~35 μA to average current consumption in sleep mode </li>
<br/>
<li style="color:#ffffff">although Standby mode has the lowest current consumption, in this mode SRAM and register contents are lost and only certain GPIOs can wake up MCU, so we've used Stop mode</li>
<br/>
<li style="color:#ffffff">in Stop mode, LSI is the only oscillator that works (and only timers whose clock source is LSI can work</li>
<br/>
<li style="color:#ffffff">LSI is unprecise, but it can be calibrated using an internal MSI oscillator and more precise e.g. periodic interval measurements can be achieved</li>
</ul> 
</div>




Wireless embedded devices transmit data in periodic intervals and spend the rest of the time in sleep mode, which minimizes the amount of time the microcontroller and RF transceiver are running and consuming power. However, if the running time is too long, it can significantly impact the average power consumption and shorten the device's battery life. To optimize power consumption, it's important to keep the duration of running time to a minimum, whether due to a periodic interval or an interrupt.


<h5>Here are some methods that we've used to minimize the duration of running time: </h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler optimizations</li>
<br/>
<li style="color:#ffffff"> removing printfs/serial outputs  </li>
<br/>
<li style="color:#ffffff">making sure there's no polling or register flag checking that keeps device in running mode</li>
<br/>
<li style="color:#ffffff">checking whether higher MCU frequency (with higher current consumption, but shorter processing time) is better for power consumption</li>
<br/>
<li style="color:#ffffff">using constants/hard coded values instead of calculations if possible</li>
</ul> 
</div>

It's important to select an RTOS mode that is optimized for low power consumption, especially as the number of features increases, as RTOS is often required in such cases.

Finally, tools that we've used to measure current consumption are Otii Arc and a multimeter (just to double-check Otii Arc measurements). Also, it's useful to have measurement ports on PCB for measuring the current consumption of certain components separately (MCU, RF transceiver, sensors).

![pic1.png](https://strapi.suprabit.eu/uploads/pic1_6e7794a3ee.png)


With whole PCB average current consumption being under 5 μA (idle mode consumption below 2.5 μA), these devices can ideally last on one e.g. CR2032 battery (~230 mAh) for more than 5 years.

<h2> Optimizing memory usage </h2>
As projects need to be profitable, prices of the components are very important. But with lower prices, MCUs usually also come with smaller amounts of RAM and Flash memory. For example, STM32L051 has 8 kB of RAM and 64 kB of Flash memory . As the complexity of the application increases and the feature set expands, optimizing memory usage becomes necessary for these microcontrollers.

<h5>Here are some methods of optimizing memory usage that we've used in our recent project: </h5>

<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>

<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler flags</li>
<ul>

<li style="color:#ffffff; opacity: 70%;">we've used GCC's <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">-ffunction-sections, -fdata-sections, -fno-exceptions, -fno-rtti, -Os, --specs=nano.specs</span> (for using nano version of newlib)</li>
</ul>
<br/>
<li style="color:#ffffff">check out functions with the highest memory usage and try to optimize them</li>
<ul>
<li style="color:#ffffff; opacity: 70%;">for <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">arm-none-eabi-readelf -s elf_name.elf</span></li>
</ul>
<br/>
<li style="color:#ffffff"> disable unused RTOS features</li>
<br/>
<li style="color:#ffffff">remove unnecessary printfs</li>
<br/>
<li style="color:#ffffff">remove double and float arithmetic <span style="font-weight:bold">__aeabi_</span>functions if possible</li>
</ul> 
</div>



That wraps up this blog post on memory and power consumption optimization for microcontroller-based embedded systems. We hope it'll turn out to be helpful in your current and future embedded projects too!

</div>

large_IOT BLOG (2).png

medium_IOT BLOG (2).png

small_IOT BLOG (2).png

thumbnail_IOT BLOG (2).png

IOT BLOG (2).png

In this blog post, we'll explore various ways of optimizing power consumption and memory usage of wireless embedded devices with examples from one of our recent projects.

Optimizing power consumption and memory usage of wireless embedded devices

Blockchain

Internship


**First thing first: the team and the brainy stuff**

Before starting the internship, I wasn’t really feeling nervous as I felt I had a good understanding of the basics of both Solidity and blockchain. Also, my colleague shared some insider information with me regarding the atmosphere, so I wasn’t surprised by the openness of the team and their willingness to help me and the other interns.
Firstly, we slowly studied the stack and the task itself. Then we got familiar and learned to work with the new blockchain technology that enables easier management of smart contracts. We were excited to start developing our own solutions!

Since blockchain is still a quite new technology, you can learn something new about it every day, as long as you know what to search for. Us interns were involved in the whole development cycle starting from the very beginning. First, we went back and forth researching the technologies and deciding which ones would be the best for this project and the internship, before deciding on Scaffold-ETH.

**You’ve heard it several times already: tHErE aRe No STuPid qUEsTioNs!**


![mulan-mushu.gif](https://strapi.suprabit.eu/uploads/mulan_mushu_9349847d61.gif)

 

Well, I’m going to say it again, there really are no stupid questions in Suprabit. Around here, everybody is eager to help each other, be it solving a bug or replacing the coffee pod. Don’t waste your time asking yourself “What will they think of me asking many questions or the same question many times?” because nobody will turn their back or roll their eyes at you. They all know the common goal is gaining understanding and moving forward.
 
The atmosphere is chill and most enjoyable. Once you've had enough of the keyboard tapping, you can make your way to our local table tennis station situated inside the office. Ask away, someone will surely join you! (Beware of the boss, you have to let him win, otherwise...).
 
 
**Future opportunities**

The internship program was well planned and adapted to students with or without previous knowledge of blockchain technology. The people were great, and I enjoyed the entire experience. I'm grateful for the things that I’ve learned during the internship and I'm happy that I was able to stay at Suprabit as an employee after the internship had finished. I know that Suprabit will continue to support my growth and make me a better blockchain developer (and a better table tennis player)!
 
![DSC00401-min.jpg](https://strapi.suprabit.eu/uploads/DSC_00401_min_4b49f3e364.jpg)



large_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

medium_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

small_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

thumbnail_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

WhatsApp Image 2022-10-26 at 13.44.46.jpeg

This summer, I decided to spend my summer-break gaining as much knowledge on blockchain as possible. After a couple of hours of research, a few interviews and one solved solidity smart contract task, I landed my internship at Suprabit.

My Blockchain Internship at Suprabit!

React

## What and why? 👀

For starters, what exactly is Expo? Expo is a bundle of tools created around React Native to help you start an app very fast. It gives you the means to simplify the creation and testing of React Native App. With Expo, there is no need to directly use Xcode or Android Studio. That means you can finally develop for iOS even if you are not a Macbook lover.

What’s more, if you choose Expo, you will never have to touch any native Swift, Objective-C or Kotlin or Java code. This means you can rely on just your Javascript skills for developing a real-feel native app, ready to be used on both iOS and Android!
However, sometimes you still need to add some native code. We will go over the steps on how to do that as well!

## Setting up the project 💻

You can read all about getting started on [this link](https://docs.expo.dev/get-started/installation/), here we will do just a quick overview so you can get right into the important stuff.
The first step should be downloading the Expo Go app on your phone as well as installing the Expo CLI on your computer:
```bash
npm install --global expo-cli
```

Then you should enter the following command in the terminal and choose one out of four templates:
```bash
expo init-my-app
```

After installing the project, you can start the app by entering 
```bash
expo start
```

A QR code will now pop up on the screen, then you can scan the code from within the Expo Go app if you’re using Android, or directly from the phone's camera if you're using iOS.
Now you can see all the changes you’ve made within the app right as you make them.

## Adding native modules using plugins 📌

Sometimes during your development, you will need to use native modules not directly supported by React Native. Before switching to the bare workflow, you should check if there is a plugin available for the module you need. Expo uses plugins to generate and configure all the native code for a managed project. 

If there is a plugin available, you can easily add it to your project following these instructions.
First, you need to install the plugin of your choice. After installation finishes, edit the app.config.json or app.json file. Edit the expo key and put in the following code: 
```json
{
  "expo": {
    "plugins": ["@config-plugins/name-of-your-plugin"]
  }
}
```
Before being able to fully use the native module, you need to build the application in the development mode using EAS. You can read up more about building later in the article.
Now you can start your app with:
```bash
expo start –dev-client
```

## Permissions ☑️ 

Some native modules require the user to give his permission. With Expo, you don’t have to dig into the native code to handle permissions. It is again enough to just edit the app.config.json file. Here we will be adding [this Bluetooth plugin](https://github.com/dotintent/react-native-ble-plx), but the process is the same for any available plugin. 
For Android, you need to add a new permission field like this
```json
{
   "android": {
      "permissions": ['BLUETOOTH', 'BLUETOOTH_ADMIN'],
    },
}
```
For iOS, you need to do a bit more work. 
```json
{
"ios": {
      "bundleIdentifier": 'your.bundle.identifier',
      "infoPlist:" {
        "NSBluetoothAlwaysUsageDescription":
          'Our app uses bluetooth to find, connect and transfer data between different devices',
      },
    },
}
```
And that's it! Now your app will ask the user for his/hers permission on startup.

## Adding native modules with no plugins available 🖇️

Even though by using Expo we try to stay away from native coding, occasionally there is no other way to achieve some functionality. <br/> Up until recently, if you wanted to add native code, you needed to eject Expo altogether. That means that you wouldn't be able to use the Expo Go app anymore, but more importantly, you would need to remove all your plugins and add them to the native code by hand! Luckily, now there is a workaround and that is using Expo's new feature - the bare workflow!

If you want to use custom native code that isn't already in the Expo Go app, you will need to generate the native iOS and Android projects. To do that, first, you need to switch from managed to bare workflow. You do this by running
```bash
expo run:android
```
and
```
expo run:ios
```

Using the run commands will initially prebuild your project to generate all of the native code within your project directory. Keep in mind that you need to have both Xcode and Android Studio installed to do this. 
Now, you can test your native code on simulators, and continue to use the Expo Go for all other testing and development. You can’t access native code while using the Expo Go app, but you can still access and keep all of your plugins. 

After adding a plugin to the bare workflow, you need to run expo prebuild so Expo CLI adds required permissions to the Info.plist and AndroidManifest.xml. As before, anytime you add a new plugin, you need to build the app again.

## Building the app 🔨

To build the app, we will use [EAS Build](https://docs.expo.dev/build/introduction/). EAS Build allows you to build a ready-to-submit binary of your app for the Apple App Store or Google Play Store.
First, you will need an Expo Dev account. You can register [here](https://expo.dev/).

At the root of your project, you have eas.json, where you can find the four types of builds: dev-ios-simulator, development, preview, and production.
<ul>
<li>Development builds include developer tools, and they are never submitted to an app store.</li>
<li>️Dev-ios-simulator build is used to create the development build for the iOS simulator.</li>
<li>Preview builds don't include developer tools, they are intended to be installed by your team and other stakeholders, to test out the app in production-like circumstances.</li>
<li>️Production builds are submitted to the app store, they are meant for release to the general public or as part of a store-facilitated testing process such as TestFlight.</li>
</ul>


You can change the default value of the bundle identifier in the app.config.js file. By default, the build will be of production type. You can also specify the build type in your command.
```bash
eas build --profile development
```
After that, you can select the platform for which you want to build or you can skip that step by specifying the platform directly in the command.
```
eas build --profile development --platform all
```
The Android build will start immediately. If you chose iOS, log in to your Apple account.

When the build is over, go to the given link or scan the QR code and install the app.
Keep in mind that the app won't run with build types Development and Preview on iOS devices that are not registered on your Apple account.

In the development and preview build, the result for an Android build is the .apk file, while for the production build the result is the .aab file. If you want to change the type of build file, you will need to edit the eas.json file.
```json
{
  "build": {
    "preview": {
      "android": {
        "buildType": "apk"
      }
    },
    "preview2": {
      "android": {
        "gradleCommand": ":app:assembleRelease"
      }
    },
    "preview3": {
      "developmentClient": true
    },
    "production": {}
  }
}
```

You only need to make a new build if you add new native dependencies, or if you register a new Apple device in your provision profile and you want to run the build on it. 

## Conclusion 📝

With Expo's new features, you can finally use it for the whole development process. Adding plugins and native code has never been easier. Since the building process lasts only a few minutes, your clients can now get day-to-day updates on your progress! Other than that, definitely check out [the documentation](https://docs.expo.dev/) for other commonly used features.

Have fun and stay tuned for more! 📻 😊





large_expo.png

medium_expo.png

small_expo.png

thumbnail_expo.png

expo.png

See how Expo helps you in your development and takes care of native things for you.

Using Expo with React Native

Design

# We needed a change

People say that the website is the face of the company, and that is indeed true. The website is often the first thing somebody sees about your company and if they see an IT company with a bad, ugly or non-functioning website, imagine what they will think about the company itself.

Our old website was kind of out of date and since Suprabit is a company working with cutting edge technologies and following modern trends, we had to update our website to better represent us - what we do and who we are.

# Choosing what we want

Before doing a project like this, we had to agree on what we want to show on our website, how to package it and how to put emphasis on things we think are the most important. After the agreement had been made, our designer had to make a design prototype and web development team had to design application architecture and select the technologies to work with.

# Development

Our designer used **Figma**, a vector graphics editor and prototyping tool, to create the design which our development team would have to follow. For content management, we selected **Strapi**. Strapi is one of the best headless Content Management Systems, it is open source, 100% built in JavaScript and very simple to set up. **Next.js** is an open-source development framework built on top of Node.js enabling **React** based web applications functionalities such as server-side rendering and generating static websites. Since we are already experienced in developing Next.js applications, it was an easy decision to select this technology for building our website.

Following the design in Figma, the development team built React components. Next.js was important here to render as much as possible on the server side, and then serve the client with components already populated with content from Strapi. This increases user experience as the client has much fewer requests per page and pages load much faster.

# Deployment

For deployment of our web application and even through the development process, we used **Docker** containers for both Strapi API and for Next.js app. **Docker Compose** came in handy for easier management of both containers with only few command lines in the terminal. **Digital Ocean** is our selected cloud service provider and during the development phase, we had set up a dev environment and deployed our application iteratively as it was being built and as new features were being added. To do that without connecting to the server and running several commands lines every time, we created a **GitHub Action** to do all of that for us, deploying the application version on the main branch.

Once the app was ready, we needed to make it run over HTTPS protocol, instead of HTTP, and finally update DNS servers to route www.suprabit.eu to our server. 

large_Suprabit-web-1440x810.jpg

medium_Suprabit-web-1440x810.jpg

small_Suprabit-web-1440x810.jpg

thumbnail_Suprabit-web-1440x810.jpg

Suprabit-web-1440x810.jpg

Designing a new look for our website. Selecting technologies and principles to build our website on, implementing them and finally deploying the website to cloud.

Optimizing power consumption and memory usage of wireless embedded devices

My Blockchain Internship at Suprabit!

Using Expo with React Native

Building our own website