Медленный CrossWorks for ARM?

На моей текущей работе мы используем CrossWorks for ARM IDE со встроенным GCC в качестве среды разработки приложений для встраиваемых систем. До недавнего времени никто не замечал проблем с этим, пока мы не начали работать над проектом у которого требования к выходу системы из спящего режима оказались «выше обычного».
Упомянутая система работала под управлением процессора STM32L4 (ядро ARM Cortex-M4) и имела в качестве одного из источников пробуждения пьезо-кнопку. Кнопка подключена к линии MCU и пользовательское нажатие на неё генерирует прерывание, от которого происходит пробуждение. Необходимость в ускорении времени пробуждения системы возникла по нескольким причинам:
- наша пьезо-кнопка притягивает сенсорную линию к уровню нуля на 100-200 мс в случае, когда пользователь делает естественное касание и не пытается её продавить. Если бы использовалась обычная механическая кнопка, то наверняка проблема, о которой я хочу рассказать, осталась бы незамеченной, так как те экземпляры, с которыми я работал, прижимали сенсорную линию на 500+ мс.
- схема включения пьезо-кнопки не предусматривала какую-либо аппаратную защиту от дребезга (причина сейчас уже не важна и к теме статьи не относится, поэтому эти детали опустим) и, как следствие, это привело к тому, что случались ложные пробуждения, которые нужно было отлавливать
О том, как мы обнаружили проблему и как с помощью небольших правок в реализации CRT (C Run-time) стандартной библиотеки CrossWorks for ARM добились ощутимого ускорения дальше.
Эта статья может быть особенна интересна тем, кто пользуется следующими средами разработки:
- CrossWorks for ARM (очень вероятно, что все проекты для ARM Cortex-M ядер будут подвержены задержкам при старте)
- Segger Embedded Studio (SES)

Сейчас о концепции IoT («интернета вещей») говорят везде. Появляется «умная» бытовая техника, которая может подключиться к сети (Bluetooth/Wi-Fi) по беспроводному интерфейсу и начать рассылать уведомления о том, что задача по стирке/готовке еды/кипячению воды завершена и неплохо бы что-то с этим сделать. Большинство таких «умных» устройств получает питание непосредственно из электросети. Но как быть, если хочется получать информацию от беспроводного термометра и при этом не менять батарейку каждую неделю? Или иметь беспроводной выключатель с небольшим аккумулятором для которого не понадобится штробить стены? И хорошо бы объединить такие устройства в единую распределенную сеть, которой можно управлять удаленно и которая сама, основываясь на показаниях датчиков/извещателей/счетчиков, могла бы принимать какие-то решения.