Результаты поиска

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

Я не "знающий", но исходя из самого названия ram_image_end следует, что эта строчка контролирует чтобы область ram_image заканчивалась на адресе 0x100020c0. Значит это почему-то необходимо программе. И очевидно, что "после стягивания" в скомпилированной Вами прошивке ram_image заканчивается по...

Очевидно, что у меня канал используется не на 100%. Я же написал: ...и может ещё 50кБ/с свободной полосы осталось. Не на чем проверить. К тому же - после подключения к р/ст, сначала, до начала декодирования аудио, идёт пребуферизация на полной скорости канала и (визуально) буфер заполняется...

Уже год работает нормально в интернет-радиоприёмнике. Потоки нормально работают все до 320 кб/с. TCP. Более быстрых источников не нашёл, поэтому не могу проверить. Но одновременно с входящим потоком, работает и исходящий поток на небольшой скорости. И иногда UDP-кадры проскакивают (SNTP-клиент)...

Просто и дешёво вытащить поток из чипа можно через параллельную шину (если конечно ног хватит). Прицепить эту шину можно к GPIF CY7C68013A, а с неё на комп. Интерфейс у неё удобнее чем у FTDI-ных USB-FIFO, так как он - user-definable. И готовых коробочек с CY7C68013A продаётся много задёшево под...

Её не надо восстанавливать. Надо: 1. Искать баги в своём коде. 2. Учиться писать оптимально (без такого отстоя: Subj.replace(" ", "%20"); Subj.replace("\"", "");). 3. Научиться обходиться без динамической памяти. ...и память перестанет утекать.

Выделяет разработчик протокола обмена. И сделать можно как угодно. PS: Дальнейшее участие в этой теме прекращаю - не вижу никакой пользы.

Вобщем - с вами всё ясно. Никакого обсуждения "технических деталей" вам не надо было - пустой трёп. Критику Вы воспринимать нормально не умеете всё сводите к "распальцовке". Смысл изначального поста вообще не ясна: похвастаться? чем? этим? никаких оригинальных решений, оптимальности - одни...

CC1352R я привёл как идеальный вариант. Не обязательно его. Основная мысль моего поста была: сделать на любом обычном МК (например с Cortex-M ядром) с достаточным количеством ресурсов (ног). И всё по максимуму в этот МК и засунуть. В смысле? Разве ваш RTC-чип не слэйв, а ESP для него - не...

Сами только что защищали абдурину и тут вдруг оказывается, что приходится ставить дополнительный чип только из-за того что в некоей библиотеке зачем-то запрещаются прерывания. Как бы противоречий не замечаете? При нормальном программировании (а не таскании чужих кусков из инета) таких проблем...

Во-первых: ещё раз процитирую Ваше же сообщение: технических, о времени вроде разговора не было. Ну и если уж пошёл разговор за время: я без понятия сколько надо вашего времени, но как по мне, так реализовать такое на обычном знакомом Cortex-M МК будет быстрее чем разбираться в каких-то...

При чём тут цена отладочного комплекта, если автор видимо будет делать свою плату (и покупать отдельные чипы)? А разработка ПО там не сложнее чем для любого другого Cortex-M.

Ожидаемая цена на CC1352R == 4.73$ (при 1000шт. конечно). Думаете весь тот зоопарк из 5 чипов у автора стоит около 0.47$ в сумме? Что-то сильно сомневаюсь...

А Вы сейчас обходитесь без батарейки? :D Наличие RTC в современных МК - это вообще то давно уже норма. В чём именно "плохая сочетаемость"? :eek: Естественно если речь идёт о быдлокоде из инета - так у него плохая сочетаемость с чем угодно. Так я вообще-то и говорю о выборе МК с адекватным...

Избыточно получилось у Вас. Избыточно и плохо расширяемо. Колхоз из DS3231 + DS2482-100 + 74HC595 легко заменяется на любой МК общего назначения (1 чип вместо 3-х). Например STM32 какой-нить. К которому цепляется ESP. Ещё лучше вместо STM32: какой-нить МК со встроенным радио-модулем (их полно...

Это бесполезно. Товарищ не понимает очевидных вещей. И откровенно несёт чушь. Шедулинг в РТОС - это не при чём конечно и его считать не надо при учёте затрат времени (хоть он и будет составлять львиную часть затрат времени в случае с ОС). Так можно любые факты подтасовать, ничего Вы ему не...

И опять пустой трёп. На конкретные замечания ничего не ответили (поняли ли вообще?) Опять переливание из пустого в порожнее... Вобщем: писать Вам что-то серьёзное рано ещё. Даже простые вещи понять не можете. Одно пустое надувание щёк и надёрганные откуда-то куски кода... Больше говорить с вами...

А Вы не думайте, а откройте проект с обычным ISR, нажмите "скомпилить" и откройте листинг. А если обойтись без вызова функций в ISR, не думали? И если Вы не можете даже простейший ISR написать без "библиотек", ну что-ж - мне Вас жаль. Ну да ну да. Вы форумом не ошиблись? Здесь вроде не форум...

Я думаю, что nikolz хотел сказать, что для ISR компилятор может определить какие регистры используются внутри функции ISR и сохранить только те, что ISR портит. В то время как переключатель контекста ОС не может определить какие регистры использованы в текущей задаче (с некоторыми оговорками) и...

Могут использоваться != всегда используются. Для каких-то случаев взаимодействия драйвер<->пользовательский уровень могут использоваться очереди. Но в целом: это не обязательно. Это то же самое что утверждать, что автомобиль для перевозки груза использует прицеп. Да, прицеп может использоваться...