Martin Cowen ⁽⁴⁶⁾

In the previous post on using a BLE peripheral example, the LED2 could only be controlled in terms of two states, On and Off. With my background of lighting controls, I wasn't satisfied that this could be called a BLE lightbulb project without at least brightness control. Since the example BLE code is already set up to send a byte as the BLE characteristic value, it should be easy to expand the example to brightness control in percentage terms using the byte in the range 0 to 100. The main addition to the previous project is the PWM software module which sets up and controls the internal PWM hardware peripheral on the nRF52832. It is better to use an existing software module which encodes all the knowledge necessary to set up the PWM peripheral rather than just accessing the registers directly…

If you are developing a BLE application with Nordic Semi's SDK, there is a need to generate a UUID for your custom services and characteristics, for example, NovelBits MIDI example. Mohammad Afaneh gives the rules for these UUIDs and suggests using a general purpose UUID generator followed by a manual check for clashes with the BT SIG reserved range. The Nordic SDK method of declaring these UUIDs requires them to be given as byte arrays in reverse order, with least significant byte first. Although this is not difficult to do manually, there is some possibility of error which would be difficult to detect without going through the full debug cycle of programming a device and reading back the UUIDs on a tool such as LightBlue or nRF Connect. I have automated the whole process in a simple Windows Form app…

I was getting a little frustrated with the Nordic examples and tutorials all being not quite ready for use. Not as badly frustrated as this guy but there always seemed to be some mismatch between what was required and what I was using, even when I chose the preferred tools. OK, I made a mistake assuming that I should start with the nRF51-DK because that is a smaller, simpler, cheaper chip. Although when you look into pricing, you find that nRF51's are not necessarily cheaper So I got myself onto the nRF52-DK so that I could use the latest SDK 16 and the Segger SES toolchain, which meets all the requirements in the Getting Starting guide. After going through that, I wanted to find a tutorial that was written from outside Nordic Semi so that it could be more objective about the tools.

Apple have just announced their latest 4.7" iPhone. Confusingly they are calling it the iPhone SE, even though they already had an iPhone SE which was a 4" screen. I'm looking at it as an upgrade to the iPhone 6s 128 GB from September 2015, so the comparison only covers that screen size. Most of the data in this chart is from Apple's comparison page. CPU and battery specs are from the relevant Wikipedia pages. The historical UK pricing at launch was obtained from the Guardian. DXO Mark and Geekbench scores are from their own sites. Bold text is used for improvements. Since the iPhone 8 did not launch with a 128 GB option, the choice would have been the 256 GB option at £849 so the iPhone SE (2nd gen) at 128GB at £469 looks like a good deal. Added confirmed…

While learning about RTOSes, I came across the idea of Timer Coalescing which improves performance by eliminating unnecessary context switches. But there is no reason that this technique cannot be applied to bare metal firmware (without RTOS). To test out how well it works, I implemented it using a STM32F4 discovery board. I wanted to see the improvement factor in a typical use case, so I decided on running 8 software timers on a 1ms timer peripheral. The software timers count down to 0 then reload themselves. From previous experience, typical periods were chosen for these timers of 1000, 200, 125, 50, 18, 27, 40 and 600ms. (If they had a common factor of say 5ms, then it would make more sense to use that as the peripheral timer rate, but it restricts the flexibility for future changes.) TIM6 was…