Rst7

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

Особенно, когда связь разорвется на середине передачи прошивки, прям замечательно будет. Хоть с подписями, хоть без.

Это если Ваше устройство - клиент. А если сервер? Да конкретно Вас никто не заставляет пользоваться ftp. Более того, я, например, вообще обновляю через tftp у себя, полностью отдельным буткором, там что-то килобайта полтора кода вообще на все, если отладочный printf выбросить. Потому что у меня устройство может в интернет и не попасть, а вот с софтом верхнего уровня коммуницировать всегда будет (у него работа такая), вот софт верхнего уровня через tftp при необходимости в девайс прошивку и зальет.

Тут, кстати, ТС нас бы просветил, у него вообще клиент или сервер. А то из стартового поста не очень понятно, мне привиделось, что сервер. И мне пофиг на всякие стены и прочее. А Вам, походу, что клиент. И Вас теперь это беспокоит

Еще раз и сначала. Мы тут беседуем о буткоре. Вы передаете прошивку в свои приборы нешифрованную и неподписанную? Оставляете все на совесть протоколов передачи данных?

А в http он есть? Напомню, что ftp, что http работают по TCP, и именно он гарантирует целостность данных. Более того, tftp, работая через UDP тоже вполне гарантирует правильность данных в пределах пакета, а повторы потерянных пакетов там заложены в протокол. Ну и речь вообще идет о заливке прошивки. Очень было бы нифигово вообще хэши/эцп прошивки проверять перед тем, как ее применять. Независимо от того, каким способом она прилетела.

Да там же закат солнце вручную в угоду размеру и скорости. Любителям готовых решений и bsd socket style не подойдет, т.к. там все на callback сделано. А зачем Вам тогда http-загрузчик? Сделайте tftp, минимально же получается.

Я вот не помню, честно говоря, давали в школе или нет, познакомился я с этой формулой явно самостоятельно. Справедливости ради, я в ФМШ учился, так что может и в школе давали, но не помню. В любом случае мне кажется, что для 6-8 класса реально крутовато будет.

Ну конкретно вывод Ф.Э. - это не школьная алгебра. Разложите e^ix в ряд Тейлора (точнее, в ряд Маклорена, ибо надо брать окрестность точки 0), и увидите, что это сумма двух рядов, синус и косинус.

Ну как бы *p++=v явно быстрее, чем fwrite(&v,sizeof(v),1,f) Я, понятное дело, про накладные расходы и прочее, если одно и другое вызвать 32768 раза (чтобы получить 128К данных)

Для узкополосной - улучшится.

Ну так просто расширение полосы сигнала приводит к увеличению и шума тоже, полоса-то шире в n раз, шум больше в sqrt(n). И меняете шило на мыло.

Смотрите, у Вас есть две полосы. Пусть f - это ширина полосы полезного сигнала до расширения спектра, F - после. F много больше f. Если Вы к сигналу с полосой F примешиваете шум (тоже с полосой F, лишнее надо отфильтровать до перемножения с ПСП), то после перемножения с ПСП в приемнике ширина спектра полезного сигнала становится f, а шума остается все равно F (грубо говоря). Теперь надо отфильтровать полезный сигнал с полосой f, и тогда уровень сигнала помехи упадет на выходе в sqrt(F/f) раз. А уровень полезного сигнала после перемножения возрастет в F/f раз. С узкополосной помехой будет то же самое - энергия размажется по спектру, и лишнее отфильтруется. Может Вы там в своих моделях забыли фильтры поставить?

В борьбе с многолучевым распространением в основном.

Куча есть КВ-радиоприемников с ключевыми смесителями на входе. И вполне адекватно работают.