ARV 0 16 февраля, 2019 Опубликовано 16 февраля, 2019 · Жалоба 26 минут назад, jcxz сказал: в какой-то момент времени все 10 задач могут затребовать одновременно память, то ПО должно быть рассчитано на это. И должно предоставить эту память. Или обеспечить блокировку задач (ожидание на семафоре) до момента освобождения памяти. Да, именно этот вариант я и считаю приемлемым. "Какой-то момент" явление редкое, и потому затормозить несколько задач на время завершения работы других - вполне допустимо. Именно из-за редкости такой ситуации. Делать же нормальным явлением ожидание семафора всякий раз, когда кому-то послал сообщение - это, с моей т.з. значительно хуже, это перечеркивает всю парадигму многозадачности. 26 минут назад, jcxz сказал: нет проверки того, что mem_alloc() может вернуть NULL Это да, не всегда проверяю, хотя и стремлюсь к этому. Косяк, признаю. 26 минут назад, jcxz сказал: Так что статическое распределение ВСЕГДА эффективнее по использованию памяти Еще раз: нет, нет и нет! Не стану утверждать, что всегда, но что НЕ всегда - однозначно! Само существование динамического распределения памяти, как явления, опровергает ваше утверждение. Даже в системах с ОЗУ в десятки гигабайт, даже в системах с виртуальной, теоретически ничем не ограниченной, памяти. К тому же статическое выделение одного буфера и последующая "передача" его то одному, то другому процессу, по сути своей ничем от динамического распределения не отличается. Семафоры и т.п. как раз и будут выполнять функции менеджера кучи. Только геморрою программисту больше. И "нормальность" ожидания другой задачи на каждом шаге работы с памятью де-факто превращает любую RTOS в кооперативку. 26 минут назад, jcxz сказал: при динамическом распределении может требоваться существенно больше памяти в системе Вот это самое "может" и является камнем преткновения: мы оба используем это слово, т.е. ориентируемся на некое допущение. Может быть != обязательно будет. Памяти должно хватать, но может и не хватить. И тогда наступает момент компромисса, о котором говорю я, а вы маскируете его мьютексами и семафорами: надо рассчитывать на наиболее характерную для конкретного девайса потребность в памяти, а не на предельно возможную (случай, когда ОЗУ в избытке, я опускаю по естественным причинам). В этом случае в наиболее типичном режиме будет использован [минимальный] оптимум памяти, а в наиболее "плохом" возникнет ожидание доступности нужного количества. 26 минут назад, jcxz сказал: У вас там может происходить разрушение памяти. Может, я это признал. Но не будет, поскольку конкретные условия таковы. Конечно, мне не помешает провести ревизию кода еще раз, чтобы гарантировать отсутствие реального разыменования NULL, а не возможного (т.е. всегда проверять результат mem_alloc). 26 минут назад, jcxz сказал: Если какие-то аргументы могут принимать недопустимые значения - обязательно проверяю это и обхожу. И никогда не рассчитываю на авось или какие-то вероятности. Преклоняюсь перед вашей тщательностью. Но, например, при управлении инкубатором, я никогда не проверяю на ноль значение температуры. Надеюсь, почему так, не стоит объяснять? (но объсню: потому что если температура в инкубаторе достигла нуля, абсолютно без разницы, зависнет ли терморегулятор или пересбросится). 26 минут назад, jcxz сказал: Так и появляется быдлокод Ну, имхо, это слишком резко сказано даже для профессионала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 16 февраля, 2019 Опубликовано 16 февраля, 2019 · Жалоба 43 минуты назад, ARV сказал: Еще раз: нет, нет и нет! Не стану утверждать, что всегда, но что НЕ всегда - однозначно! Само существование динамического распределения памяти, как явления, опровергает ваше утверждение. Даже в системах с ОЗУ в десятки гигабайт, даже в системах с виртуальной, теоретически ничем не ограниченной, памяти. Вот именно - в больших системах, таких где могут запускаться разные произвольные задачи с заранее неизвестными требованиями памяти и в заранее неизвестное время - там она оправдана. А в микроконтроллере, где ПО только одно, всё время работающее и заранее известны все его требования - здесь дин.память не нужна. Потому что, под это ПО можно распределить имеющуюся память оптимально вручную в соответствии с алгоритмом работы. Цитата В этом случае в наиболее типичном режиме будет использован [минимальный] оптимум памяти, а в наиболее "плохом" возникнет ожидание доступности нужного количества. В вашем коде никакого ожидания не возникнет. Возникнет разрушение памяти и зависон. Если переделаете менеджер дин.памяти так, чтобы при нехватке памяти он ставил задачу на ожидание, а не возвращал NULL - тогда будет нормально. Но эффективнее куча от этого не станет - фрагментация всё равно останется как и расходы на служебные поля. Да и время на выделение/освобождение - оно тоже не нулевое - опять лишние тормоза. Цитата Преклоняюсь перед вашей тщательностью. Но, например, при управлении инкубатором, я никогда не проверяю на ноль значение температуры. Надеюсь, почему так, не стоит объяснять? (но объсню: потому что если температура в инкубаторе достигла нуля, абсолютно без разницы, зависнет ли терморегулятор или пересбросится). А если просто из-за помехи по питанию/линии связи был считан 0? Или мыши отгрызли провод датчика? Фермер прийдёт - провод починит. Но теперь ему нужно ещё и лезть вскрывать контроллер чтобы его пересбросить, а то и восстановить похеренный конфиг. Для домашних поделок наверное сойдёт, но когда фермер побегает так с сотней таких контроллеров, поматерится, то в следующий раз, когда он начнёт строить новый курятник, то он предпочтёт выбрать контроллер другого производителя, который не виснет от любого нештатного чиха. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 16 февраля, 2019 Опубликовано 16 февраля, 2019 · Жалоба 28 минут назад, jcxz сказал: А если просто из-за помехи по питанию/линии связи был считан 0? А если метеорит упал в курятник? А если землетрясение? А если ядерная война? Всяких "если" можно придумать миллион. Расскажите мне про ваш идеальный проект, и я придумаю "если", которое вы не учли. Даже когда спутники делают, предусматривают тройное резервирвоание - казалось бы, все предусмотрено, что еще может быть? А все равно наступает такое "ещё", что как раз четвертого комплекта и не хватает. И что из этого следует? Никто никогда не делает тройной резерв на каждый из трех комплектов оборудования. То есть я хочу сказать, никто никогда не пытается предусмотреть все вероятные случайности, всегда ограничиваются наиболее вероятными. И граница приемлемости этой вероятности может быть разной: иной раз и 0,5 много, иной раз и 0,98 мало... Но требовать 1,0 - бессмысленно. 28 минут назад, jcxz сказал: В вашем коде никакого ожидания не возникнет. Недостатки моего кода очевидны, и критика ваша практически всегда справедлива. Изначально я задавал вопрос совсем не об этом, но раз так завертелось, теперь вынужден заниматься пересмотром кода и переписыванием его. И советы мне вполне пригодятся, как ваши, так и другие, как минимум, в качестве стартовой точки для размышлений. И по мере обдумывания у меня возникают новые и новые вопросы, на которые наверняка последуют новые и новые советы и так далее... Что же делать, когда остановиться? Если допустить исключение динамического распределения памяти, это означает переделку 100% кода. Если отказаться от выбранного принципа приема сообщений от модуля, это означает переделку, пожалуй, 80% кода. Если отказаться от парадигмы RTOS - снова 100%.... просто вычистить косяки? Может, возьмете "шефство" надо мной, неучем? И в отдельно заведенной теме (а то я уже чувствую, как буфер терпения модератора переполняется и вот вот hard fault будет теме) продолжите меня воспитывать? ;) Я-то самоучка от еще ассемблера MCS51 и tasm - кроме нескольких книг, меня никто ничему не учил целенаправленно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 20 февраля, 2019 Опубликовано 20 февраля, 2019 · Жалоба Вопрос об алгоритме работы SIM800L То ли это не отражено в документации, то ли я прозевал, где это описано, но есть однин вопросик. Как известно, в ответ на запрос чтения СМС модуль возвращает ответ в виде +CMGR: <преамбула><CR><LF><текст СМС><CR><LF><OK><CR><LF> Так вот, если в процессе вывода этого ответа поступит входящий звонок или новое СМС, сможет ли модуль выдать уведомление RING или иное в середине ответа CMGR? например, как-то так: +CMGR: <преамбула><CR><LF><RING><CR><LF><текст СМС><CR><LF><OK><CR><LF> ? Или он сначала завершит ответ, а потом сформирует поступившее уведомление? Это я к тому, надо ли в процессе анализа ответа на запрос СМС проверять поток на наличие "неожиданных" уведомлений? Очень не хочется разбираться с этим методом экспериментов, ведь искусственно создать такую ситуацию довольно сложно... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 20 февраля, 2019 Опубликовано 20 февраля, 2019 · Жалоба 1 час назад, ARV сказал: Так вот, если в процессе вывода этого ответа поступит входящий звонок или новое СМС, сможет ли модуль выдать уведомление RING или иное в середине ответа CMGR? например, как-то так: +CMGR: <преамбула><CR><LF><RING><CR><LF><текст СМС><CR><LF><OK><CR><LF> ? Или он сначала завершит ответ, а потом сформирует поступившее уведомление? Только если прошивка модуля кривая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 20 февраля, 2019 Опубликовано 20 февраля, 2019 · Жалоба Спасибо, это значительно облегчает мои муки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 5 22 февраля, 2019 Опубликовано 22 февраля, 2019 · Жалоба On 2/20/2019 at 9:56 AM, jcxz said: Только если прошивка модуля кривая. Это не вопрос "делают ли так нормальные люди". Очевидно, что делать так не надо. Вопрос "делает ли так Simcom?". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 22 февраля, 2019 Опубликовано 22 февраля, 2019 · Жалоба 3 часа назад, esaulenka сказал: Это не вопрос "делают ли так нормальные люди". Очевидно, что делать так не надо. Вопрос "делает ли так Simcom?". Я вобщем-то об этом и сказал. Simcom делает кривые прошивки (сам сталкивался в SIM808). Но такого бага не видел. Да и конкретно с SIM800L я не работал - там скорей всего всё по-своему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 5 22 февраля, 2019 Опубликовано 22 февраля, 2019 · Жалоба 1 minute ago, jcxz said: Я вобщем-то об этом и сказал. Т.е. на вопрос Вы не ответили. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 22 февраля, 2019 Опубликовано 22 февраля, 2019 · Жалоба Только что, esaulenka сказал: Т.е. на вопрос Вы не ответили. Спасибо. Т.е. - Вы вопроса не поняли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 22 февраля, 2019 Опубликовано 22 февраля, 2019 · Жалоба On 2/20/2019 at 8:56 AM, jcxz said: Только если прошивка модуля кривая. Системное сообщение что в "локальной" системе произошел crash или что-то подобное. Влезет ли такой "синий экран" в текущее сообщение, или станет в очередь за ним - надо курить док. ps Где-то встречал что есть режим работы с СМС в "цифре". Думаю в этом режиме хлопот было бы меньше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 24 февраля, 2019 Опубликовано 24 февраля, 2019 · Жалоба Кстати, если кого-то вдруг интересует мой вопрос о том, надо ли ждать "промпта" при вводе СМС... Так вот, в документации на команду AT+CMGS модуля SIM800L написано: Цитата Write Command 1) If text mode (+CMGF=1):+CMGS=<da>[,<toda>]<CR>text is entered<ctrl-Z/ESC> ESC quits without sending То есть текст сообщения следует сразу за <CR> без какого-либо упоминания промпта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 24 февраля, 2019 Опубликовано 24 февраля, 2019 · Жалоба В 22.02.2019 в 18:28, k155la3 сказал: Влезет ли такой "синий экран" в текущее сообщение, или станет в очередь за ним - надо курить док. Если "влезет" - это значит есть баг. Не должно "влезать" в нормально написанной прошивке. Это противоречит протоколу обмена. И странно было бы если бы баг в доке описывался, вместо того чтобы устраняться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
