Версия для печати темы

Автор: Димон Безпарольный Feb 16 2018, 03:26

Не хочется создавать большой кольцевой буфер для PRINTF. Поступил по - другому. С задержкой.

Посчитав что PRINTF работает через int fputc(int ch, FILE *f), в ней и написал:

Т.е. когда буфер заполняется, происходит задержка для ожидания завершения передачи буфера в порт. Передача осуществляется через прерывание:





Само прерывание:






Самой задержки (30мс) по идее должно хватать. Т.е. при скорости 115200 за 1 секунду улетает 10килобайт. Примерно. Значит за милисекунду - 10 байт. Итого - 300байт при буфере в 256.

Такой подход по идее должен разрешать иметь любой малый (в разумных пределах) буфер для передачи. На практике же это не работает - часть выводимой информации теряется. И только когда я делаю #define PC_TxBufSize 8192, передача осуществляется без потерь.

Где же я не прав, может кто подскажет?

Автор: mcheb Feb 16 2018, 04:24

Я бился с такой проблемой, не решил. Сделал так. Отказался от передачи ТХ в прерывании, то есть перешёл на поллинг. В терминальной программе поставил задержку после передачи новой строки на 1 миллисекунду. Увеличение буфера до 8кБ помогает, но не всегда. Причём это в Виндоуз и в Линуксе. А файл 1кБ отлично передавался и с буфером 256 байт.

Автор: adnega Feb 16 2018, 05:39

А вы уверены, что теряет не приемная сторона?

Автор: mcheb Feb 16 2018, 05:51

Я делал USB-UART на STM32F103 и на CC2511. RX замкнут на TX. На CC2511 нормально работало до 1 МГц, на STM32F103 после 9600 были сбои на длинных файлах. Так и не разобрался.

Автор: Димон Безпарольный Feb 16 2018, 06:10

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





Но поллинг накладывает временные ограничения на выполнение. Я пишу код MBED TLS и в этом случае не проходит даже handshake. Либо в моем софте еще один глюк...

Видимо без буфера не обойтись.


У меня были сбои на 460800 пока я не перешел на кварц. Хотя на 9600 смещение частоты вряд ли скажется...


Уверен что приемная сторона нипричем. Сделал поллинг - вывод сработал исправно.

Автор: adnega Feb 16 2018, 06:16

Я при помощи STM32F103C8 гнал поток 2.25 Мбод (RX замкнут с TX). Ни один байт не потерялся за значительное время.

Автор: x893 Feb 16 2018, 06:55

Конечно не будет теряться, если код написан правильно.
Я на 926000 тоже нормально гонял на другое устройство.

Автор: adnega Feb 16 2018, 07:05

Я писал так

push и pop помещают и извлекают байты из кольцевых буферов tx и rx.

Автор: jcxz Feb 16 2018, 07:36

Задержки - типичный ардуино-подход, дилетантский.
Для вывода в поток с помощью printf() никаких задержек вообще не нужно. И размер буфера может быть абсолютно любым, хоть 1 байт. Буфер только даёт возможность более эффективно использовать быстродействие CPU - в среднем уменьшает загрузку CPU.
Если у Вас что-то не работает из-за изменения размеров буфера или требует каких-то задержек - правьте консерваторию.

Автор: x893 Feb 16 2018, 08:18

Я делал совсем по простому
2 буфера линейных
ПДП
таймер
всё пузЫрилось на ура.

Автор: Эдди Feb 16 2018, 08:23

Проверяйте в функции отправки сообщения статус возврата! Если ошибка — либо пропускайте (сообщение некритичное), либо ждите подтверждения отправки.
Соответственно, функция, заполняющая буфер просто будет возвращать OK если место есть и ошибку, если буфер полностью заполнен и надо подождать, пока "уедет".

Если используете линейный буфер (тогда удобней делать двойную буферизацию), отправка реализуется при помощи DMA, а буферы меняются местами по флагу, выставленному в прерывании по окончании DMA.
Если буфер кольцевой, придется в обработчике прерывания TXE выполнять основную работу.

Но в любом случае ни в коем случае не надо лепить паузы! Это же не абдурина!!! Если буфер заполняется слишком быстро, либо повышайте скорость передачи, либо увеличивайте буфер.

Автор: mcheb Feb 16 2018, 09:27

Очень может быть, что сбои (потери) байтов из-за плохой трассировки печатной платы. Изменение буферов, скоростей, поллинга-прерываний изменяют наводки от фронтов Rx-Tx и уменьшение скорости тогда единственный выход.

Автор: Димон Безпарольный Feb 16 2018, 09:44

Интересная точка зрения. Ну допустим буфер 128 байт. Кольцевой. За пару милисекунд проц настрочил 5кб текста и выплюнул все это в кольцевой буфер. А с одним байтом будет еще прикольнее. Наверно только первый байт от 5кб и попадет в терминал. Мож и не первый...

Автор: Эдди Feb 16 2018, 10:18

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

Автор: Димон Безпарольный Feb 16 2018, 10:50

printf использует библиотека MBEDTLS, нужен форматирванный вывод.

Суть во всем это одна -



Я так и делал, но другим способом - наблюдая за головой и хвостом.

В данном случае это ПОКА неприемлимо. Сервер выкидывает HandShake, следом сертификаты. Так вот. С выводом debug информации не получается успевать декодировать первое сообщение - его затирает втрое.

Автор: Эдди Feb 16 2018, 11:27

Если вы не можете обойтись без дырявой библиотеки, правьте ее код и высылайте пулл-риквесты автору.

Автор: x893 Feb 16 2018, 11:35

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

Автор: jcxz Feb 16 2018, 12:41

Проц сам ничего не "строчит". Если Вы так пишете своё ПО, что у Вас байты попадают или не попадают куда-то по воле случая, то пенять надо только на себя.
Если немного включить голову и понять, что при заполнении буфера, задачу в которой выполняется printf(), можно заблокировать до момента освобождения места в этом буфере, то всё получится с любым размером буфера. ISR или DMA передаст часть данных из буфера в UART и сообщит об этом ждущей задаче (с printf-ом), разбудит её, чтобы она могла дописать ещё байты в буфер.
И всё. Всё элементарно. Но ардуинщики продолжают городить задержки, и удивляются что у них кто-то куда-то "строчит" и уже не хватает даже килобайтов памяти на ерундовую задачу...
PS: У меня printf вполне себе нормально формирует HTTP-ответы (в HTTP-сервере) большими потоками и нескольким клиентам параллельно. И обходится минимальными буферами.

Автор: Димон Безпарольный Feb 16 2018, 13:42

Можно и дальше гнуть свое, не читая что я пишу, но толку от этого не будет. Много букв и все впустую.

Заблокировать до момента... как раз нельзя. Нельзя прервать выполнение программы до определенного момента. Я об этом выше писал. И этот код, должный быть выполнен за минимальное время формирует большой поток DEBUG информации. Складывать его кроме как в буфер некуда. Задержка - не лучший выход, полинг - не выход. Остается только буфер.

P.S.
Я даже не ардуинщик - я тупой и еще тупее. Пнумпень вообщем. Это чтоб Вам было спокойней.

Автор: HardEgor Feb 16 2018, 13:42

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

Автор: Димон Безпарольный Feb 16 2018, 13:49

Даже не представляю как на стадии Hanshake это сделать. Стандарт этого не предусматривает. Более того, после HandShake в меня через миллисекунды вываливаются сертификаты. Если не успеть обработать Hanshake, то его в буфере забивают сертификаты. А мне бы хотелось еще и DEBUG почитать. Но Вы правы. Кроме огромного 8кБ буфера кажется решений не существует.

Автор: Эдди Feb 16 2018, 14:14

Почему же? Есть еще одно решение: отдельно выделенный микроконтроллер, который только и будет что "общаться".
Но лучше уж, если так надо много данных хранить, взять МК пожирней.

Автор: adnega Feb 16 2018, 14:51

А по какому каналу связь с сервером? Какой протокол?

Автор: Димон Безпарольный Feb 16 2018, 17:02

Протокол MQTT уже отлажен. Теперь надо все закрыть TLS.

Дошел до parse certificate. Застрял с проблемой вывода отладочной информации. Сервер internetofthings.ibmcloud.com

Автор: kolobok0 Feb 16 2018, 17:33

чисто по коду в первом посте...
1) задержку надо делать не после а ДО вывода. Тогда возможно шансов упереться в ожидание - снижается, хотя фокусов не бывает. поток вывода из мк, должен обеспечивать скорострельность софта генерящего эти мессаги.
2) если у вас буффер(или предполагаете его юзать) - то ждать надо не абстрактное число мкс а именно свободное место в буффере вывода. Но буффер для дебажного вывода - не есть гуд. когда мозги подвисают - всё самое интересное именно не успеет уйти...

по поводу вообще логики логгирования и метрии..
- рекомендую глянуть готовую либу libp7-baical. Она под мк так-же...


удачи вам
(круглый)

Автор: adnega Feb 16 2018, 19:41

Вы можете стандартными средствами TCP притормозить выдачу данных удаленной стороной, чтобы она вам буфер не перезаписывала.

Автор: HardEgor Feb 16 2018, 23:50

Что за дурацкий протокол без подтверждения приема?
Стоп, а каким образом на незавершенный hanshake начинают слать сертификаты? Вы же еще не договорились с удаленной стороной?
А если вы не успели обработать сертификаты, сервер начинает слать данные, которые забивают сертификаты??? 8-)
Либо в протоколе всё это есть и вы не разобрались с самой сложной частью протокола, либо протокол тупо рассчитан на большие компьютеры и естественно плохо ложится на микроконтроллеры.

Автор: Димон Безпарольный Feb 17 2018, 01:54

Не нашел такой возможности у модулей Quectel M95. Наверно аппаратно можно RTS - CTS. Но они не заведены.


Второе от части верно. Может я неправильно выразился. Первая часть hanshake - это когда сервер сообщает о выбранном шифронаборе из предложенных абонентом. После этого вываливает сертификаты. Но контроллер то не слабый - Cortex M3. L151 STM.

Проблему частично решил пока вставив в некритичные во времени места библиотеки TLS функцию:



Это позволило уменьшить буфер с 8 до 2Кб. Информация выводится без потерь.

Автор: jcxz Feb 17 2018, 10:23

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


Видимо этот косяк надо исправить.
Хотя аппаратный flowcontrol по UART может быть управлением потоком только именно по UART, между модулем и МК. И никак не влиять на TCP-сокет. Управлять потоком надо именно в TCP-сокете, т.е. - там где расположен стек.

PS: Изначально автор писал о переполнении вывода по UART, постепенно нарисовался ещё TCP (где-то) и, видимо, этот TCP находится в некоем модуле, подключенном по UART (другому или этому же самому?). А переполнение видимо идёт в другом UART (?), через который выводится отладочный лог. Или не так?
Автор в шапке треда написал чрезмерно много буков, но не удосужился даже мельком описать свою архитектуру.
Вобщем - для форумчан предлагается очередной конкурс-угадайка для экстрасенсов. Видимо автору не нужна реальная помощь, а просто хочется потрепаться...
Если для проблемного вывода отладки используется именно отдельный интерфейс, то тут только или тормозить отлаживаемый процесс (управлением потоком), или увеличить скорость отладочного интерфейса. Не вижу проблем поднять скорость UART до 921600 даже на таком дохлом МК как у автора (RC-генератор - не есть препятствие для этого, препятствие есть - не использование DMA на таком МК). Ещё больше поднять скорость можно заменив вывод в UART, каким-то другим интерфейсом, например: вывод в параллельный порт, USB, Ethernet, ...

Автор: Димон Безпарольный Feb 17 2018, 12:15

Да, наверно надо было рассказать об архитектуре. К процессору по уартам подключены модули ESP-05 WiFi и M95 GSM.
По отдельному порту работает DEBUG. C ним и проблемы.

Задача - собрать информацию и отправить ее на MQTT сервер. Это отлажено и работает уже в железках. Теперь начальство возгордилось своим детищем и решило закрыть все это TLSом. Подводная лодка же. Вот тут и начались проблемы описанные выше. Скорость Debug сейчас 460800.

Да, обнаружилась таки еще проблема уже с железом не связанная. При больших потоках байты таки теряются уже в интерфейсе USB. Приходится таки выдавать с задержками. Тогда работает.

Автор: HardEgor Feb 17 2018, 12:18

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

Автор: Димон Безпарольный Feb 17 2018, 12:20

И кому из нас здесь хочется потрепаться? Столько букф - ради чего?

Автор: jcxz Feb 17 2018, 12:53

О! Ещё и USB всплыл... Угадайка продолжается?
Где в Вашей архитектуре он фигурирует и в каком качестве?
И опять магические костылизадержки на которых всё только и держится

Автор: Димон Безпарольный Feb 17 2018, 12:56

FT232. Странное дело. Вроде компов - то с комом не осталось... Слушай, хочешь потрепаться - иди в другую тему. Толку от тебя все равно нет. А на задержках - да, держится. Через сутки я разберусь в чем проблема и сотру этот код вместе с задержками.

Автор: jcxz Feb 17 2018, 13:15

Действительно странное. На домашнем компе - 2x COM на MB, на работе - COM на MB + мультипортовка-PCI, на старой работе - мультипортовка-PCI.
Видимо это глюки это у меня. Видимо их всё-таки нет
Если у Вас чего-то нет, то не нужно думать, что все такие бедные.


Слушайте - не нужно меня посылать. И мы с вами на брудершафт не пили.


ну-ну. ...и слепите новые костыли.

PS: Не нужны советы - нафига тогда вообще сюда писать? Не умеете прочитать и понять советы - это ваша проблема, а не тех кто советует.

Автор: Димон Безпарольный Feb 17 2018, 13:34

Зачем столько букв писать? Я получил информацию от людей, за что им большое спасибо. А ты загаживаешь мою тему хламом, расходуя на это самое дорогое что у человека есть - время. Еще раз, для непонятливых - мне не нужны ТВОИ советы. Они не содержат информации.

Автор: adnega Feb 17 2018, 14:54

Еще в посте #9 уважаемый jcxz посоветовал проверить консерваторию. Я полностью поддерживаю его совет, а от себя посоветовал бы не переходить на необоснованное хамство в отношении людей. Подход, который вы используете не годится для решения коммерческих задач, а поскольку у вас есть руководство, то осмелюсь предположить, что ваша задачка не поделка выходного для. Если вы для себя или для начальства хотите получить подтверждение "эта задача не может быть решена", то вы ошибаетесь - задача элементарная, но вы решаете ее не с того края, отсюда и сложности. Попробуйте успокоиться и понять, что вам советуют. Я сам в том месяце работал с ESP8266 и МК уровня STM32F0. От сервера приходят UDP-пакеты и я на каждый должен ответить. Но пока я отвечаю на предыдущий, ко мне может прилетесь еще несколько новых. Памяти на всех нет в принципе. Поэтому, получив и обработав пакет, я помечаю, что нужно отправить ответ (один флаг). Получив другие пакеты - обрабатываю их и устанавливаю соответствующие флаги. Когда есть возможность отправить ответ, смотрю первый попавшийся флаг и отправляю соответствующий ответ сбросив флаг. Расход памяти минимальный, все пакеты обрабатываются, никто не теряется, никаких задержек нет. Предыдущий код требовал, чтобы сервер не отправлял UDP-пакет, не получив ответ на предыдущий, т.к. буфера перетерались.
Все решает грамотная архитектура, а необходимость задержек, зависимость от размера буферов и т.п. являются свидетельством неграмотной архитектуры или ее отсутствия. Кто-то называет это консерваторией. Подход "через сутки разберусь, а дальше меня не волнует" тоже не признак профессионализма. Завтра начальство захочет новую фичу, и вы с большой вероятностью не сможете ее добавить, т.к. ваш подход обладает плохой масштабируемостью. Пару раз по банальным фичам ответите начальству отказом - на вашем месте будет работать другой программист. Оно вам надо?

Автор: Димон Безпарольный Feb 18 2018, 02:38

Мне этот подход знаком - самое главное не замечать что хамство и переход на личность начался с 29 поста и обвинять в этом только меня. Терпел до последнего, но господин принял вежливость за слабость и не унялся.

Здесь вполне уважаемые люди, но без гнильцы не обходится ни один форум. У товарища гонору как у Циолковского, а желания разбираться нет. Видимо и знаний тоже нет.

Здесь только один человек придрался к задержкам не пожелав разобраться в сути. Даже когда я написал, что проблема УЖЕ не в контроллере, пакеты теряются за ним - он не унялся. Число байт ушедших в DR больше чем выплюнул терминал на 1-3байта на 8Кб информации. Поскольку данные не искажаются, я склонен полагать что частоты не смещены. И только ЗАДЕРЖКА в некритичных во времени местах решила эту проблему, я думаю что Вы уже догадались почему.

У Вас желания тоже не нашлось. У меня другая ситуация чем то, что Вы написали. Замечательно что Вы обошлись без памяти и у Вас просто все это работает. Рад за Вас. Вы просто герой.

Я НЕ могу ничего отложить. В меня последовательно выплевывают тремя пакетами - таков алгоритм HANDSHAKE. Я должен их обработать в реальном времени. Задержка между пакетами - милисекунды. Поэтому если я занимаюсь выводом DEBUG информации с ОЖИДАНИЕМ появления в буфере свободного места - я ПРОСТО ТЕРЯЮ ПАКЕТЫ.

ЗДЕРЖКА в некритичных во времени местах помогает снизить размер кольцевого буфера PC порта с 8 до 2кБ. Предложите другой способ - обсудим.

Ну как до "светочей" разума и всяких свидомитов донести эту простую мысль? Третий раз пишу. А мне намекают на консерваторию. Зачем тартить жизнь на написание глупостей особенно если считаешь себя Циолковским?

Автор: adnega Feb 18 2018, 07:11

Дык, вы же их обрабатываете без проблем. Просто вы хотите параллельно зачем-то сгенерить гораздо большую по объему отладочную информацию и успеть ее выплюнуть. Старайтесь в отладку выкидывать только ошибки и результат обработчика HardFault. Что вам мешает подключиться к uart от модема и записывать весь обмен, а затем его обрабатывать (в том числе и с помощью спецутилит)?


Дык, попытайтесь писать суть, а не "много букв". Не всегда, чем длиннее текст, тем там больше информации.
Как называется ваша тема? И при чем тут printf, когда причина у вас в совершенно другом месте?
Боюсь, если вы не поменяете манеру общения, то заработаете на этом форуме себе такую репутацию, что большинство профи откажутся вам помогать.
У меня позиция, что отвечая на форуме - помогаешь не ТС, а всем, т.к. кто-то может столкнуться с аналогичной проблемой в будущем.

Автор: Сергей Борщ Feb 18 2018, 08:42

Неа. Тут уже правильно писали: проблема в консерватории. Прислушайтесь к этому совету:

Автор: Димон Безпарольный Feb 18 2018, 09:09

Если такие "профи" перестанут тут "помогать", я скажу им спасибо. Пролистайте страницу выше. Первый пост. Зачем этот кирпич тут? Если Вы отвечаете для других, должны понимать что тему с этим говном будет сложно читать. Сюда заходят разные люди за советом. И профи и новички. Я себя поофи никогда не считал. Но здесь за ошибки некоторые считают себя обязанным наказать человека изрядно ему нахамив. И очень обижаются на ответное хамство. Зачем нужно не разобравшись в сути писать кирпичи про консерваторию?

Тема о правильной организации вывода debug информации. Она выводится через printf. Эта информация генерится библиотекой mbedtls. Вывод раскидан в три файла по 5-7 тысяч строк каждый. В общей сложности 150 точек вывода примерно. Ей Богу, править и раскидывать по уровням debuglevel - не лучший выход.

Не я что - то там выкидываю отладочное в порт, а автор библиотеки. Ну и я потом печатаю принятый дамп уже в некритичном по времени месте.

Сейчас это работает и очень помогает мне разобраться в сути.

Автор: adnega Feb 18 2018, 11:14

Что ж остается лишь пожелать вам удачи.

Автор: jcxz Feb 18 2018, 11:30

Не утруждайте себя, коллега. Товарищ уже показал тут во всей красе кем он является - тут уже ничего не исправимо.
У него все вокруг виноваты: и не правильно советуют, и автор некоей "библиотеки" неправильно что-то там делает.
И сплошной поток хамства в ответ на попытки помочь ему...
Товарищ уже в игнор-листе.

Автор: Димон Безпарольный Feb 18 2018, 13:26

Попытки "помочь" как раз и начались у этого "помошника" с хамства в 29-м посту. Остальное - чистая ложь. Ное ему не привыкать.

Автор: adnega Feb 18 2018, 13:34

Перечитал пост #29. Кроме

все остальное по делу и справедливо. Хотя, и процитированное предположение имеет право на жизнь.

Автор: Димон Безпарольный Feb 18 2018, 14:54

Хоть тут мне и приписали что я обвиняю в чем - то авторов MBED TLS (вероятно тоже "по делу"), хочу отдать должное - ребята грамотные, постарались на славу. Благодаря debug информации, проверкам конфигурации такая сложная библиотека не так уж трудно отлаживается. Респект.

Что касается самого DBUG, то сколько тут местные "помощники" ни надрывались, ничего нового не придумали - не можешь ждать, делай буфер шире. Как промежуточное решение - задержка перед критическим во времени местом выполнения, чтобы войти в этот кусок кода с чистым буфером. Тогда буфер можно сделать меньше. Это вкратце.

Автор: adnega Feb 18 2018, 15:23

Ровно так же никто из профи не сможет ничего придумать, чтобы по вашему желанию "2х2=5".
Грамотное решение - попросить вторую сторону не присылать данные, к обработке которых вы не готовы.
TCP позволяет это делать, причем очень гибко и грамотно. Если вы не хотите разобраться как это сделать, то да - увеличивайте буфер,
но не надо в код вставлять задержки, даже если сейчас это работает. И точно не нужно хамить людям, которые считают такой подход
дурным тоном программирования.

Автор: Эдди Feb 18 2018, 15:32

Да ладно!
То-то чрез одно место оно работает…
Хотя, надо еще уточнить, по чьей вине: то ли вы, товарищ, неправильно документацию читаете, то ли авторы этой библиотеки...

Автор: Димон Безпарольный Feb 18 2018, 15:59

Никто и не собирался изначально хамить. Хамство и переход на личности начался с 29 поста. Я лишь вежливо просил не гадить в этой теме. Но "помошник" так и не понял о чем его просят.

Что касается 2х2 =5, люди предлагают иногда нестандартные решения. На это и надеялся. Но нарвался на хама . знал бы - не начинал бы сюда писать.

На стадии handshake сервер ждать не будет. Так обьяснили инженеры IBM. Связано с загрузкой серверов. Да и я не представляю сейчас как это сделать через M95 в котором TCP реализован внутри.




Ну Вам конечно виднее. Вы же код писали - не я. Работает нормально. Третий час - без сбоев.

Автор: Эдди Feb 18 2018, 16:07

Это оно без сбоев работает, пока не понадобилось еще что-то добавить. А там опять та же песня пойдет?

Автор: HardEgor Feb 18 2018, 16:10

Завтра у них немного изменится размер hadshake, сертификатов, или задержка в одном месте появится, а в другом исчезнет и у вас внезапно всё перестанет работать. Или вдруг сервер сменится....

Автор: Димон Безпарольный Feb 18 2018, 16:43

Вы наверно стандарт не читали. Весь мир работает с серверами MQTT IBM. В России кучу железа понаделали. Откуда столько страхов?

Автор: adnega Feb 18 2018, 16:59

Почитать Инструкцию

Автор: Димон Безпарольный Feb 18 2018, 17:04

Я уже писал, что аппаратная реализация не предусматривает пару RTS - CTS. К тому же в модулях ESP - 05 эти сигналы наружу не выведены. В изделии два радиомодуля.

Автор: adnega Feb 18 2018, 17:32

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

Автор: HardEgor Feb 18 2018, 17:32

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

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

Автор: Димон Безпарольный Feb 19 2018, 01:51

Стандарт как раз такое допскает. Задержка нужна была на стадии отладки как временное решение. Ее уже нет, как и вывода массива DBUG информации. Стандарт на TLS допускает такую работу сервера. Дилетант как раз и говорит:

и не разобравшись в сути делает вывод:


Ничего подбирать не требовалось. Читайте выше. Не делайте глупых выводов раз Вы кого - то там учите.


Так уже. DEBUG отключен. Библиотека TLS работает AS - IS, без изменения кода библиотеки.

Автор: Димон Безпарольный Feb 26 2018, 16:34

Может кому пригодится - когда начал дорабатывать вывод в порт заметил что контроллер виснет на строке

если переменные объявлять без volatile. Получается так:

http://electronix.ru/redirect.php?https://postimages.org/

Если объявлять:



То получается совсем другая картина:


http://electronix.ru/redirect.php?https://postimages.org/


Оптимизация Level 3.

Автор: x893 Feb 26 2018, 22:20

Это уже всем ёжикам известно.
Но за заботу огромное спасибо.

Автор: Димон Безпарольный Feb 27 2018, 05:33

Какие же все таки люди злые.