Открою ужасающий секрет — embedded-софт тестируют как минимум на порядок меньше и хуже, чем любой зачуханный веб-сервер. И пишут его зачастую динозавры, отладчик — это для слабаков, а «если код компилируется, значит, все работает».
Код на С. Компилируется. Значит, работает.
Я не шучу, к сожалению.
И никто этого не замечает, потому что в веб-сервер каждый день тыкают пальцами миллионы пользователей, и любые ошибки выплывают гораздо быстрее.
Еще интересно, на самом деле, что большую часть истории Земли средняя температура была выше, чем сейчас; ледяных шапок вообще не было. Хотя, конечно, сложно сказать, насколько достоверны эти данные.
Потому что С11 от С99 отличается не так существенно. А вот С89 с его объявлениями только в начале функций, отсутствием однострочных комментариев, отсутствием stdbool.h, отсутствием нормального inline, отсутствием designated-initializer'a для структур и т.д. довольно сильно раздражает.
Философский язык Джона Уилкинса был заметно раньше раньше сольресоля, примерно 1668 год.
Своеобразная идея — разбить все понятия по категориям, все слова должны были формироваться логичным образом из объединения и уточнения категорий.
Я подозреваю, что они могли вообще не задаваться этим вопросом. В то время (а может и во все времена?) наукой вообще и математикой в частности занимались, в основном те люди, которым это нравилось.
А полезно это или бесполезно — да какая разница, по большому счету.
Справедливости ради, если посмотреть бриф на ST53G, можно увидеть следующий текст:
System in package (SiP) integrating a 32-bit secure microcontroller (ST31G480, ST31G384, ST31G320 or ST31G256) and an STS3922 booster for optimized wearable applications (card emulation boosted performance)
Смотрим бриф на сам микроконтроллер и видим плашку Licensed DPA Contrmeasures. И на картинке чипы очень похожи на чипы для банковских карт, о которых вы пишите в другом комментарии.
Ну и текст пересыпан копирайтами на всякие SecurCore® SC000™.
Я сам ни разу не специалист по безопасности (и в даташит особо не вчитывался), скажите, это все вообще ничего не значит?
После третьей совершенно мистической ошибки компиляции, которая была вызвана копированием файла без исправления стража включения, я понял, что прагма рулит. И писать меньше и править не надо, если файл переименовывается. И опять-таки ошибиться почти невозможно.
Остаются, конечно, некоторые сложные случаи, когда она не работает, но они редки.
Вы как-то очень странно расставляете отступы для препроцессорных директив. Если я правильно помню стандарт, отступ перед # вообще ставить нельзя (хотя все известные мне компиляторы на это внимания не обращают). Но почему у вас написано:
#ifndef MYLIB_H
#define MYLIB_H
#if ARDUINO >= 100
#include <Arduino.h>
#else
#include <WProgram.h>
#endif
// Ваш код здесь
#endif
Почему у #define MYLIB_H есть отступ, а у всего остального нет?
К слову, раз уж взяли С++11, используйте enum class, а не просто enum. Это сильно снижает количество глупых ошибок.
Скажите пожалуйста, каков практический смысл использовать С89 в 2017 году?
Сужу по объявлению всех переменных в начале функций и по отсутствию однострочных комментариев:
int lenStr(){
int code;
int len;
char slen[256];
char *res;
/*Читаем из widget-а введенную строку в переменную tcl с именем a*/
code = Tcl_Eval(tcl_interp, "set a [.ent1 get];");
Статья действительно очень интересная, большое спасибо! Давно было интересно понять классификацию шрифтов (и почему мой друг-дизайнер заплевал меня за надпись на футболке, сделанную Calibri).
Но осмелюсь слегка придраться. Вот на этой картинке закрался косяк: .
В латинице ведь не было буквы U, но у вас она, почему-то есть — «QUE» и «POPULVS», причем как-то совершенно нелогично.
Я не большой специалист по истории, но вроде как эта надпись изначально выглядела вот так:
Гугл находит ровно 5 полных совпадений с вашим написанием, поэтому я верю, что это не опечатка, но хотелось бы узнать историю такого написания, если вас не затруднит.
И почему-то на моем мониторе очень многие подписи к шрифтам совершенно нечитаемы:
Бледно-голубой на белом фоне, да еще таким удачным шрифтом. Может дело не в мониторе, а в моих глазах, но я с большим трудом различаю самую нижнюю надпись, например.
Натурально, параллельный мир. У нас если «ты ж программист», то и закупками позанимаешься, и попроектируешь, и ТЗ напишешь, и документацию оформишь, и на совещаниях посидишь, и еще и код писать должен.
Да, мы такую же методику измерения применяли.
Но для наших применений пропадания пакетов были приемлемы, а вот накапливающаяся задержка от tcp — вообще никак.
Поскольку у нас не было камеры, которая может в h264, мы в него перекодировали, что давало возможность поиграться с параметрами энкодера. Если делать вот так: x264enc speed-preset=ultrafast tune=zerolatency threads=8 bitrate=2048, то энкодер достаточно сильно уменьшает расстояние между ключевыми кадрами, а из-за threads=8 все кадры режутся на 8 горизонтальных полосок, которые передаются отдельно.
Соответственно, при потерях выпадают не кадры целиком, а только полоски. Получилось более-менее.
Но h264 слишком нагружал процессор, поэтому в итоге мы использовали mjpeg.
Был еще волшебный способ с использованием rtpbin, в котором по одному порту шло видео по udp, а по второму синхронизация rtcp, а по третьему шла синхронизация от приемника.
Но тут проблема была в том, что приемником был не gstreamer, а приложение для Windows, оно так не умело.
Если у вас камера выдает картинку в mjpg или в raw, а вы хотите h264, то перекодировать придется.
Если же камера сама умеет выдавать h264, то это будет что-то вроде: gst-launch v4lsrc ! video/x-h264,width=640,height=480 ! rtph264pay ! udpsink host=127.0.0.1 port=5555
Писал по памяти, скорее всего нагнал, пишите в личку, если не взлетит.
Код на С. Компилируется. Значит, работает.
Я не шучу, к сожалению.
И никто этого не замечает, потому что в веб-сервер каждый день тыкают пальцами миллионы пользователей, и любые ошибки выплывают гораздо быстрее.
Своеобразная идея — разбить все понятия по категориям, все слова должны были формироваться логичным образом из объединения и уточнения категорий.
А полезно это или бесполезно — да какая разница, по большому счету.
Смотрим бриф на сам микроконтроллер и видим плашку Licensed DPA Contrmeasures. И на картинке чипы очень похожи на чипы для банковских карт, о которых вы пишите в другом комментарии.
Ну и текст пересыпан копирайтами на всякие SecurCore® SC000™.
Я сам ни разу не специалист по безопасности (и в даташит особо не вчитывался), скажите, это все вообще ничего не значит?
Остаются, конечно, некоторые сложные случаи, когда она не работает, но они редки.
Но дело ваше :)
Разумеется, не принципиально, просто странно.
Главное — не доводить до такого
(шепотом дилера) Между прочим, а вы слышали про #pragma once?
Почему у #define MYLIB_H есть отступ, а у всего остального нет?
К слову, раз уж взяли С++11, используйте enum class, а не просто enum. Это сильно снижает количество глупых ошибок.
Сужу по объявлению всех переменных в начале функций и по отсутствию однострочных комментариев:
Но осмелюсь слегка придраться. Вот на этой картинке закрался косяк:
В латинице ведь не было буквы U, но у вас она, почему-то есть — «QUE» и «POPULVS», причем как-то совершенно нелогично.
Я не большой специалист по истории, но вроде как эта надпись изначально выглядела вот так:
Гугл находит ровно 5 полных совпадений с вашим написанием, поэтому я верю, что это не опечатка, но хотелось бы узнать историю такого написания, если вас не затруднит.
И почему-то на моем мониторе очень многие подписи к шрифтам совершенно нечитаемы:
Бледно-голубой на белом фоне, да еще таким удачным шрифтом. Может дело не в мониторе, а в моих глазах, но я с большим трудом различаю самую нижнюю надпись, например.
Но для наших применений пропадания пакетов были приемлемы, а вот накапливающаяся задержка от tcp — вообще никак.
Поскольку у нас не было камеры, которая может в h264, мы в него перекодировали, что давало возможность поиграться с параметрами энкодера. Если делать вот так:
x264enc speed-preset=ultrafast tune=zerolatency threads=8 bitrate=2048, то энкодер достаточно сильно уменьшает расстояние между ключевыми кадрами, а из-за threads=8 все кадры режутся на 8 горизонтальных полосок, которые передаются отдельно.Соответственно, при потерях выпадают не кадры целиком, а только полоски. Получилось более-менее.
Но h264 слишком нагружал процессор, поэтому в итоге мы использовали mjpeg.
Был еще волшебный способ с использованием rtpbin, в котором по одному порту шло видео по udp, а по второму синхронизация rtcp, а по третьему шла синхронизация от приемника.
Но тут проблема была в том, что приемником был не gstreamer, а приложение для Windows, оно так не умело.
Если же камера сама умеет выдавать h264, то это будет что-то вроде:
gst-launch v4lsrc ! video/x-h264,width=640,height=480 ! rtph264pay ! udpsink host=127.0.0.1 port=5555Писал по памяти, скорее всего нагнал, пишите в личку, если не взлетит.