I started ESP8266 project, the first step was to support SDMMC over SPI. I have implemented SDMMC SPI interface years ago. The main challenge was to adapt it to new MCU core. After many attempts, it was up and running. Below are lessons learned.
Recently, I've complete my 'geshtalt' - migrate and release Windows FMX app, Ecolight-AP under MacOSX platform. And, by God, it was painful and hard, mainly due to EMB toolchain tried to fracture my butt on almost each final step.
The dehydrated knowledge here is crystallized two weeks of pain and swearing, and sweatting.
Problem starts reveling itself after all Debug stuff was successfully brushed on MAC, under PAServer session, and Release for App Store was created with Developer ID * certificates, which allow to install from signed local pkg.
Recently I've implemented lightweight header library to encapsulate interfacing with FTDI EVE chip, namely, FT800, in templated OO manner. It should compile in modern embedded x86/ARM toolchains, like ones Keil or C++ Builder have.
The idea is as follows - while your core framework provides standard IO bus interface, like mine esfwxe, via EseChannel templated abstract facade, the rest is done in modular manner by EVE library classes.
For the recent mobile FMX application development, I had a challenge, do not use any service from my full-featured cross-platform framework, to minimize application bloat, besides, FMX framework itself is rather big piece of cake.
One of the cornerstones is a I18N support which in my framework is based upon custom implementation of gettext. In current case, I decided to wrap I18N manager coode around FMX's TLang. As far as TLang may use, besides its binary stoarage, the plain text files as well, formatted as key=value pair.
Recently, I got to, as many many years ago, dive in Windows API, to implement a rather simple task. I needed to restrict an FMX-based application, namely its Windows-flavour target, to be single-instance, so any attempt to launch yet anther copy of its process would (try to) bring up the first running one.
Article explains how to use standard style elements to customize LookAndFeel of own GUI elements.
ExacTsoft C++ framework is kind of creature, that was born back in 2000s, when I realized, that products, I developed back there, need common functional codebase.
What would old tethered programmer want from its main working tool? Obviously, it must, no, MUST work as expected, and provide an expected, I emphasize, EXPECTED result(s). Recently, we tried to compile our middle-sized application project group for MAC OS. All components were separately ported beforehand, to be at least compileable under toolchains other than Win32|Win64. Needless to say, that after a few tries to compile entire project group, and getting a load of ‘unresolved externals’, I started to suspect that something is wrong there :) Test project for the article.