Recently, I bought a 7" touch screen from 4D Systems (4DCAPE-70T) for my Beaglebone Black to use it in a new project. I really like this one, because it is designed as a cape, you just mount the Beaglebone beneath it and that's it. It is automatically recognized by the OS (I prepared the BBB with Debian 9.3) and also the touchscreen is working out of the box. At least, this is what I have thougt. It turned out that the touchscreen calibration is not as easy as expected, not because the "process itself" is complicated, rather the required information is potentially hard to find. This is also the reason why I am writing this down here, it is intended to be a reminder for myself rather than something spectacular.
Mbedtls provides functions to access symmetric and asymmetric cryptography algorithms, it is licensed under GPLv2 and Apache 2 License and is maintained by ARM mbed. The library does not have any external dependencies, the compiled binary has a size of 60 KB and requires only 64 KB RAM when executed. This makes it an ideal solution to run on a bare-metal embedded system, such as the Arduino Primo (nRF52832).
Mbedtls needs to be configured for the target, this can be done by deactivating platform unsupported build options. The following configuration options were disabled, because the corresponding (hardware) modules are not present on the traget platform (ARM-based Arduinos): MBEDTLS_NET_C, MBEDTLS_TIMING_C, MBEDTLS_ENTROPY_PLATFORM, MBEDTLS_FS_IO, MBEDTLS_HAVE_TIME_DATE, MBEDTLS_HAVE_TIME
MBEDTLS_NET_C requires the BSD sockets API, which is obviously not present on a bare-metal system. MBEDTLS_TIMING_C, MBEDTLS_HAVE_TIME\_DATE, MBEDTLS_HAVE_TIME need to be deactivated because no RTC is present. MBEDTLS_FS_IO is also not available because a POSIX like filesystem is not present on the Arduinos. MBEDTLS_ENTROPY_PLATFORM is important for random number generation but must be deactivated because it implements a POSIX API and uses /dev/urandom as a seed, which is not present on the Arduino (and on other bare-metal embedded systems). When a RNG (random number generator) is important for the project it must be implemented differently. A lot of ARM based microcontrollers provide embedded hardware RNGs. See my other blogpost to make use of the Arduino Primo RNG.
The Arduino Primo is a quite new board which was introduced by arduino.org and delivers a wide range for sensor networks, IoT applications and prototyping.
It features three microcontrollers:
The nRF52832 is used as the main CPU for program execution, it includes BLE and NFC hardware for communication. WiFi is managed by the ESP8266 CPU, which can be used with the provided libraries. The STM32f103 is used as a service microcontroller and is therefore responsible for flashing the executable onto the previous named CPUs and allows extended debugging. Additionally it features a connected infrared receiver and transmitter. Beside the obvious possibilities of peripheral interconnections the nRF52832 offers more benefit for wireless sensor networks and security related applications. It has an integrated hardware Random Number Generator (RNG) whose output is suitable for cryptographic tasks. A hardware implementation of the Advanced Encryption Standard in Electronic Code Book working mode (AES-ECB) and AES-CCM is also available. Real-time applications will benefit from the integrated Real-Time-Counter.
Lithium Polymer batteries have a lot of advantages compared to the standard rechargeable NiMh or NiCd batteries.
It is mainly the weight per cell and per Wh. A LiPo battery can also be much more smaller by having the same capacity and voltage (compared to a NiMh or NiCd rechargeable battery).
This makes the LiPo very useful for small embedded systems, computers (notebook or tablet PCs), phones (smart phones) , etc., (or everywhere else a low weight is needed e.g. RC Hobby…).
Using a LiPo is not as easy as using NiMh batteries. Charging and discharging a NiMh battery (or battery pack) is easy. Discharge until the application stops working, change the battery and meanwhile charge the other one. A charged NiMh cell has a voltage about 1.2 V a discharged one about 0 V (or everything between 0 and 1.2 V).
A LiPo cell has a voltage about 3.7 V when it is discharged and a voltage about 4.2 V when it is fully charged. Here comes the first problem: Discharging a LiPo cell should not go under 3.5 V (this value is controversially discussed) but it is easy to damage a LiPo cell by discharging it below 3 V.
This is the reason why every application which is using a LiPo battery (or battery pack) needs a monitor. The monitor takes care for the battery. The easiest way to monitor such a battery is to check the cell voltage.
IF CELL_VOLTAGE < 3.5 V THEN CUT_POWER
This protects the battery from depth discharge but this technique is not able to provide the batterie's state of charge.
There are many reasons why you may need an RS485 bus. Imagine you have a cluster of microcontrollers and/or embedded computers far away from each other. Then an RS232 or TTL serial connection is not useable, because the cables are to long, the signal is damped and data cannot be transmitted. With a RS485 bus it is possible to use a cable length up to 1200 m (with a data transmission speed of 100 kbit/s). The RS485 bus normally uses two wires, + and -, this configuration allows to use it half-duplex (members can talk to each other but sending and receiving at the same time is not possible).
Page 1 of 2