This posting continues to explore the performance of floating point and how microcontrollers can efficiently execute basic floating-point operations.
What makes a great runtime library different from a run-of-the-mill runtime library? This article will answer some of those questions with hard data and technical insights.
This article covers how SEGGER vastly improved its documentation process by taking control of the tools we use and, in the process, removed reliance on FrameMaker.
This continues the journey of analysing how the Akai Fire is controlled over MIDI and deals with the OLED display.
This continues the journey of reverse engineering how the Fire is controlled over MIDI and deals with illuminating the buttons and pads.
This article documents the journey I took to analyze and decipher MIDI control messages understoood by a MIDI control surface: the the most delightful Akai Fire.
This is the second in the series of postings that describe the quality processes at SEGGER. This article picks a single design principle from the many we use when developing our software products, one that is deeply rooted.
This is the first post in a series that deal with delivering SEGGER products: how they’re designed, developed, tested, documented, and released.
One of the things that irritates me a lot is manual work that should be automated by machines. Automation always trumps the error-prone human and, in my case, offered the opportunity to get to use some of SEGGER”s software I’d never used before to develop a useful tool.
One of the things that is driven from the top in SEGGER is that we can always do better. Not satisfied with standard schemes, we wanted to optimize emCompress, SEGGER’s compression library, for: Very fast decompression High compression ratio (uncompressed size divided by compressed size) Small decompressor Limited state in RAM when decompressing