Армянское Радио

Я бы вообще руки отрывал за использование С++ с его жутким оверхедом на микроконтроллерах!
В данном случае даже glibc нафиг не нужна: реализуем strcmp() вручную, аналогично поступаем для memmove и прочих полезных функций. В итоге код будет небольшим + шустрым.
Если нужно сравнить содержимое полученной строки с эталоном, то просто пишем

int strcmp(char *a, char *b){
  int ret = 0;
  do{ ret = (int)(*a++) - (int)(*b++); }while(!ret && *a && *b);
  return ret;
}
char *in = get_serial_buf(); // функция, возвращающая указатель на первый байт в кольцевом приемном буфере USART
char *ref = "строка";
if(!strcmp(in, ref)){ // действия, выполняемые при равенстве строк
}

Если нужно найти подстроку, то аналогичным образом реализуем функцию strstr:

int strstr(char *haystack, char *needle){
  char *ret = NULL, *n = needle+1, n0 = needle[0];
  do{
    int cmp;
    if(*haystack != n0) continue;
    ret = haystack++;
    do{ cmp = (int)(*haystack++) - (int)(*n++); }while(!cmp && *haystack && *n);
    if(!cmp && !*n) break; // found
    ret = NULL; n = needle + 1;
    if(!haystack) break; // haystack ended while not found
  }while(*(++haystack));
  return ret;
}

Есть развернутый ответ для С++ кода, но его можно обобщить и на другие языки и платформы:

Если приложение уже написано, то для начала следует с помощи профилировщика найти в программе узкие места (участки кода, на выполнение которых тратится наибольшее количество времени). Когда такие участки найдены, то можно приступать к их оптимизации. Важно помнить, что, как правило, любая оптимизация ухудшает читаемость кода, потому не следует заниматься оптимизацией там, где это непосредственно не требуется. В процессе оптимизации легко можно совершить ошибки, потому очень желательно перед оптимизацией обложить оптимизируемый функционал юнит-тестами.

1) Важно понимать, что алгоритмическая оптимизация практически всегда может дать лучший эффект, чем программная. Так, если алгоритм имеет сложность O(n^2), то на больших исходных данных он при любой оптимизации будет медленнее, чем неоптимизированный алгоритм сложности O(n). Впрочем, при выборе алгоритма, опираться только на его сложность не стоит: если объем исходных данных не велик, то вполне может оказаться, что алгоритм со сложностью O(n^2) будет работать быстрее, чем с O(n).
2) Очень важно повторное использование (кеширование) промежуточных данных, вычисленных в программе – ибо быстрее всего выполняется работа, которую не надо делать. Тем не менее, не надо чрезмерно кешированием увлекаться – если объем кэшируемых данных слишком велик, то это может отрицательно сказаться на общей производительности программы (некоторые данные быстрее вычислять на лету, чем считывать из памяти).
3) Следует избегать излишнего копирования данных (например, передавать сложные типы данных по ссылке, а не по значению).
4) По возможности следует избегать условных операторов во вложенных циклах. Так как условные переходы, вызываемые такими операторами, плохо обрабатываются современными процессорами с конвейерной архитектурой.
5) Данные в памяти, которые используются алгоритмами, должны по возможности лежать упорядочено, и использоваться последовательно. Это позволит процессору их эффективно кешировать. Важно помнить, что доступ к кэшу процессора значительнее быстрее, чем к оперативной памяти.
6) Если алгоритмы это позволяют, то возможно стоит реализовать их параллельное исполнение (в отдельных потоках или процессах). Это позволит эффективно задействовать современные многоядерные процессы.
7) В некоторых случаях (например обработка изображений) большого эффекта можно достичь применением специализированных расширений процессора (SSE, SSE2, AXX, AVX2 и другие). Стоит отметить, что большинство современных компиляторов (GCC, MSVS, ICC) поддерживают непосредственное использование данных расширений непосредственно из С++ кода при помощи специальных встроенных функций (intrinsics). Минусами такого подхода является потеря переносимости (впрочем, эта проблема решается наличием разных веток программы под разные процессоры) и значительное усложнение программы.
8) Также большого эффекта можно достичь применением специализированных ускорителей, например GPU (технологии CUDA, OpenCL). Минусами таких решений являются потеря универсальности и значительное усложнение программы, а также то, что на специализированных ускорителях, как правило, хорошо работает далеко не каждый алгоритм.

Разбираетесь как работает память, проц, диск - узнаете про архитектуру, про виды памяти, про кеши и синхронизацию.
Разбираетесь как работает язык на котором пишете - узнаете про его слабые стороны, про практики проектирования на нем, про компиляторы, виды автоматической оптимизации и анализаторы кода.
Разбираетесь как работает программа которую оптимизируете - профилируете, исправляете уже с учетом полученных знаний из первых двух пунктов.

По другому никак. Без знаний оптимизацией не занимаются.

Главное правило оптимизации - не заниматься преждевременной оптимизацией.

Вообще все просто - пишите код, пишите нагрузочные тесты, профилируете, оптимизируете узкие места. С опытом ляпов будет меньше изначально. Ну и книжки стоит читать всякие, желательно обобщенные (типа там паттерны проектирования и т.д.) что бы можно было вместо оптимизации просто быстро систему масштабировать (это дешевле). Ну и еще теория алгоритмов помогает, если у вас есть именно обработка больших объемов данных (массивы на миллионы айтемов, на тысячах пофигу обычно)

Например если взять обычное радио - там FM, полезные данные получаются за счет изменения частоты, а если например скомбинировать его с AM/PWM (к примеру) которые будут выстраивать идентификационную информацию об отправителе и будут подчиняться определенному алгоритму, так что только второе сетевое устройство сможет их распознать?
Тогда устройство точно может быть уверен что пакет не подменен.
Да и ещё засунуть в алгоритм какой-нибудь рандом чтобы только два сетевых устройства знали как он будет меняться с каждым 5 или 10 битом?

Это называется security through obscurity и считается плохой практикой.

Жарить яичницу на контуре охлаждения ядерного реактора? Здорово придумано!