adnega
-
Постов
3 603 -
Зарегистрирован
-
Посещение
-
Победитель дней
3
Сообщения, опубликованные adnega
-
-
Можно до 8 байт уменьшить. И перед передачей порции данных передавать NAK-ов на несколько миллисекунд.
-
В 19.10.2023 в 12:37, mnovikov2000 сказал:
Скорее до минут. Не отвечать пробовал, все плохо и по-разному. Тут скорее что-то вроде сигнала ожидания при чтении-записи напрашивается, но в командах scsi не нашел такого, там из всего несколько. Чтение-запись медленная, и пока начитает-напишет 512 байт времени много уходит, до минут.
Есть не отвечать совсем, а есть отвечать "NAK" для конечной точки. Вы как делали?
Какой у вас размер для BULK-IN конечной точки?
-
В 12.10.2023 в 10:30, CADiLO сказал:
Трясите поставщиков, так как релизнотес на B03 DS уже как бы имеется.
Саму прошивку я еще не видел, но список изменений уже читал.
Буду иметь ввиду. Поставщик рекомендует DS как основную для данного модуля рассматривать. Попробую запросить.
-
В 12.10.2023 в 07:46, CADiLO сказал:
Ну если начали делать второй билд, то В01 есть релизный. 🙂
У меня только такой есть A011B01V04A7672M7_F_DS_A7672E-FASE-DS_V101220124.
Спасибо! Буду пробовать B09 и B02V05_DS.
-
В 11.10.2023 в 14:03, CADiLO сказал:
Можете рискнуть если хотите, но я бы без необходимости не ставил такое.
Хорошо. Попробую обе.
А существует релизная DS?
-
В 11.10.2023 в 07:31, CADiLO сказал:
Я бы для начала обновился до A011B09A7672M7 - было много исправлений.
Поставщик порекомендовал: A011B02V05A7672M7_F_DS_A7672E-FASE_V101210811
как самую актуальную и функциональную. Сойдет?
-
В 11.10.2023 в 07:31, CADiLO сказал:
Я бы для начала обновился до A011B09A7672M7 - было много исправлений.
Спасибо! Попробую.
-
В 10.10.2023 в 19:23, jcxz сказал:
Знать мы не можем, но можем взять МК, занимающийся задачей примерно такого же класса. И сравнить.
Вы все сравнили - молодец - а толку?
В 10.10.2023 в 19:23, jcxz сказал:Я всего лишь говорю что, те симптомы, которые вы привели на осциллограммах - ОЧЕНЬ странные. Я бы даже сказал - неправдоподобно странные. Ибо такого - не должно быть.
А если "быть не должно, но есть", то нужно искать причину - "почему?" А не складывать лапки, что "так и должно быть". Именно в этом и была моя мысль. О чём я несколько раз писал.
Архив с логом и декодер для A76xx прицепил.
В 10.10.2023 в 19:23, jcxz сказал:Кроме причин, о которых говорил выше, ещё причина может быть в контрафактности модуля. Может он у вас контрафактный? И там левая прошивка?
Отладка от mt-system. Повторю, при хороших условиях связи она работает отлично - без единого дерганья на FC.
Но у меня изделие будет далеко не в тепличных условиях. Я не готов терять каждый 17 байт, поэтому и акцентирую внимание. Кста, мне ничего не мешает повторить эксперимент на SIM868 с FC. Нужно?
В 10.10.2023 в 19:23, jcxz сказал:У нас была такая же ситуация перед тем, как мы применили SIM868 - сначала мы взяли SIM808. И начали работать с ним. Вот там как раз была куча подобных глюков - и пропуски байт и многие другие "чудеса".
Прошу дать оценку работоспособности такого комплекта:
Прошивка версии +GMR:A011B05A7672M7_F
-
В 10.10.2023 в 17:34, jcxz сказал:
А "архитектуру" эту кто разрабатывает? Не программист-ли? Или какой-то дядя?
Я не думаю, что с выходом нового модуля программисту начинают придумывать архитектуру ПО с нуля.
Конечно, есть наработки - их используют. Но разговор не об этом.
Я вас понял, вы можете реализовать обмен по UART, не используя FC, я тоже могу и мне ни разу не приходилось тормозить поток.
А SIMCOM то ли не могут, то ли не хотят, раз у них такой функционал есть и он живой. Может, там историческая подоплека.
В 10.10.2023 в 17:34, jcxz сказал:Ну или дело не в программе, а условиях работы вашего SIMCOM-модуля. Может вы ему питание нормальное не обеспечили? И, из-за просадок, у него какой-нить внутренний монитор переводит его в sleep. Это только предположение. Или ещё чего. Но такое поведение (останов FC посреди вводимой команды) - это явно ненормально.
Повторю: я использую оригинальную отладочную плату. В разных условиях связи она работает по-разному.
В 10.10.2023 в 17:34, jcxz сказал:Да хоть 10 клавиатур.
Я не знаю чем в модуле проц занят. Но это похоже не на то, что он не умеет в UART, а скорее на отказ в обслуживании, мол, данные ты, конечно, можешь заслать, но их модуль все равно в сеть не отправит.
В 10.10.2023 в 17:34, jcxz сказал:Чукча не читатель, чукча - писатель?
Я не защищаю ни SIMCOM, ни пытаюсь вас оспорить в части правильного ПО - я лишь привел примеры с чем лично сталкивался, где без FC в некоторых случаях будет грустно.
Ваше право распорядится этой информацией как посчитаете нужным.
В 10.10.2023 в 17:34, jcxz сказал:Если по вашему - принять несколько байт в буфер по UART - непосильная задача "невиданная доселе", то на этом можно поставить точку.
Где я такое заявлял? Я из тех программистов, кто давным давно занимался экономией каждого такта и каждого байта, поэтому про посильность что-то смыслю.
Кроме UART модуль может заниматься и другими делами. Поскольку там стоит МК профиля R, осмелюсь предположить, что и задачами реального времени.
А это когда в какой-то определенный момент времени нужно делать определенное дела, а все остальное подождет.
Чем именно занимается проц и сколько это длится по времени - я знать не могу.
В 10.10.2023 в 17:34, jcxz сказал:С вами всё ясно.
Я-то тут причем? Обсуждаем не меня, а факты. Хотите - можете повторить поведение модулей. Ваши советы строятся на вашем же понимании качественного ПО.
Вы, не сомневаюсь, можете запустить любой модуль и любой проц, чтоб не глючило, и даете советы. Кому? Профессионалам - дык, они сами с усами.
Новичкам? Увы, они не смогут все и сразу сделать правильно, столкнутся с неидеальностью модулей - тут-то их FC и выручит.
Я на A7672E вообще основным каналом постараюсь сделать USB, поэтому FC - не актуально. Использую SIM868 без FC - и тоже не грущу.
Чтоб закрыть тему про меня, доложу: АТ-команды, в моем понимании, устаревшая технология.
На ESP пишу софт непосредственно под ESP, на SIMCOM использую EAT где возможно.
Постараюсь на новых модулях уйти от UART в сторону USB, где есть интерфейсы сетевой карты и CDC (debug+GSM+GNSS).
Если конкретно у вас нет FC-опыта, то это не значит, что FC не существует))
В 10.10.2023 в 16:27, CADiLO сказал:А вот с АТ и под Linux это уже CAT4 - A7602E-H --- разные модули с разными чипсетами.
Вы правы, я этого не знал, и какое-то время пытался работать с ним через АТ-команды. Что-то работало, но соединение так установить и не получилось))
-
В 10.10.2023 в 13:39, jcxz сказал:
Можно, да.... криворукий программист может что угодно завалить.
Нельзя все валить на программиста. Есть еще такое понятие как "архитектура ПО". Любое спроектированное ПО будет иметь свои ограничения.
В 10.10.2023 в 13:39, jcxz сказал:Тогда для SIMCOM это ещё более лёгкий режим должен быть.
В моих примерах SIMCOM и ESP - это две абсолютно несвязанные вещи. Общее у них - есть примеры ситуаций, где FC пригождается.
В 10.10.2023 в 13:39, jcxz сказал:если у него не хватает сил даже просто принять несколько байт команды???
Просто, он может обрабатывать другие более приоритетные задачи. Обратите внимание на "фаршированность" модуля - там много чему нужно работать помимо AT.
В 10.10.2023 в 13:39, jcxz сказал:Принять пару десятков байт по UART - это что - непосильная задача по вашему?
В очереди стоят две SIM-карты, SDIO-карточка, дисплей, клавиатура и т.п. - и каждый так же про себя думает.
А в это время проц пытается правдами и неправдами вытащить полезную инфу из сетевого трафика.
В 10.10.2023 в 13:39, jcxz сказал:И написатель кода имеет голову на плечах не только чтобы в неё есть.
)) Если вы имеете дело только с миганием светодиодом, то вам неизвестна вся боль, возникающая при организации связи с интеллектуальной второй стороной.
Под "миганием", я понимаю, ваш полный контроль за выполнением команд. Как только появляется нечто, что может не ответить, или может задуматься, то появляются совершенно новые
невиданные доселе проблемы. Вы как программист можете все валить на вторую сторону, но юзер, который использует ваше устройство будет считать именно вас бракоделом.
В 10.10.2023 в 13:39, jcxz сказал:Ну если конечно может в этом A7672 SIMCOM-овцы сэкономили на отдельном DSP для радио, и всё взвалили на один CPU. Тогда может он реально занят чем-то связанным с эфиром.
)) я вас понял - 51-е ядро туда - для обработки АТ хватит с горкой. А SIMCOMовцы туда аж Cortex-R5 засунули, причем, R - это жжж не спроста.
Я так понял, вы конкретно с A7672E не работали. Их, кста, как минимум две версии есть, и вторая вообще не про АТ-команды))
-
В 10.10.2023 в 10:51, jcxz сказал:
Там же серьёзный процессор стоит. И как такое может быть, на незагруженном даже (каким-то мощным потоком) процессоре???
Процессор любой мощности можно напрячь по-полной.
Я точно не знаю - лишь впечатления. Были плохие условия связи, видимо, проц был полностью вовлечен в дела радиочасти, а AT-задачи стали менее приоритетными.
Видно, что uart потреблял данные блоками по 16 байт, а затем тормозил прием - видимо насыщался какой-то FIFO буфер.
В 10.10.2023 в 10:51, jcxz сказал:Складывается ощущение, что вы что-то нарушаете в условиях подключения или использования SIMCOM (питание, уровни сигналов, etc.).
Пользуюсь оригинальной отладочной платой - там должно все быть ок.
Если есть желание, могу скинуть дамп логического анализатора всего обмена - там тоже все ок))
Кста, приделал антенну получше и заменил оператора связи - все взлетело.
Да, на столе можно заставить работать хорошо, создав тепличные условия, но мне нужно, чтоб и в поле работало.
В 10.10.2023 в 10:51, jcxz сказал:Какая версия прошивки? В старых версиях были баги, очень криво работали.
AT version:1.6.0.0(Feb 3 2018 12:00:06) SDK version:2.2.1(f42c330) compile time:Feb 12 2018 16:31:26 Bin version(Wroom 02):1.6.1
Может, и старая - дело было в марте 2018 - на тот момент прошивка свежайшая.
В 10.10.2023 в 10:51, jcxz сказал:У меня есть давно работающий проект на ESP8266+STM32F429.
У меня ESP использовалась в режиме сквозного канала - по сути UART-TCP.
AT+CWJAP_DEF="ssid","password"// настройка сети AT+SAVETRANSLINK=1,"192.168.0.200",12345,"TCP"// настройка сервера
В 10.10.2023 в 10:51, jcxz сказал:На бОльших входящих потоках тоже не могу проверить
Мне от ESP в том эксперименте была важна не пропускная способность, а как можно большее число пакетов в секунду, т.к. целевой протокол был "запрос-ответ".
Тестирование скорости - это побочная часть эксперимента.
По итогу поправили протокол, ввели в него команды более высокого уровня, чтоб "запрос-ответов" снизить, и чтоб рутинную часть обмена убрать.
В 10.10.2023 в 10:51, jcxz сказал:80 МГц - это частота вашего МК?
Да у STM, чтоб скорости совпадали. У меня МК в эксперименте прохлаждался - молотили UART+DMA, он только статистику вел без какой-либо полезной работы.
В 10.10.2023 в 10:51, jcxz сказал:Это очень странно. В момент передачи команды к SIMCOM, он вроде как даже ничем не занят. А там очень мощный процессор стоит.
Ага, там стоит мощный проц только для обработки АТ-команд ))
В 10.10.2023 в 10:51, jcxz сказал:Имхо: Или нарушения условий использования модуля с Вашей стороны;
По железу - исключено, по софту - могу дамп анализатора скинуть со всем обменом))
В 10.10.2023 в 10:51, jcxz сказал:или баги в прошивке SIMCOM.
Удобно называть все, что требует FC - забагованным))
-
В 10.10.2023 в 08:31, Arlleex сказал:
Может, скорости самого UART чуть-чуть, но различаются? Из-за этого и потери.
Нет. Явно видно, что модуль "задумывается". Да, и с FC проблема принципиально исчезает - если бы проблема была в различии скоростей, то она бы осталась.
-
В 10.10.2023 в 03:34, jcxz сказал:
Ну вот, хоть что-то....
Т.е. - хотите сказать, что параметры современных A7672E стали даже хуже, чем у SIM868E (которым вроде они рекомендуются на замену)?
На SIM868E делал проект, в котором была интенсивная передача файлов (не какие-то отдельные команды, а объёмные файлы). Да - изначально заложили в схему CTS/RTS. Но при разработке прошивки выяснилось, что прекрасно работает и без flow control. Правда я работал на 460800 бод. Не помню - пробовал ли выше, возможно не пробовал. Но я тестировал передачами файлов большого объёма и ничего не терялось.
Я несколько дней гонял A7672E. У одного Оператора связи - все прекрасно. У другого - такой лес на FC. Есть огромное желание подключить модуль по USB, т.к. требуется максимальная скорость.
А SIM868 использую в промышленных масштабах без FC - вроде, норм, но допускаю, что софт хорошо разруливает возможные последствия потери байтов.
Кста, я на ESP8266 в AT-прошивке тоже получал потери байтов (при передаче в ESP8266) без использования FC.
Там есть прозрачный режим, который сносно работает, если трафик умеренный.
При работе на скорости 80МГц/24=3.3Мбод на непрерывном потоке получал порядка 8% потерь:
Цитатаrx_count = 97278080, tx_count = 106877488,
tx_time = 320s,
tx_speed = 326kB/s, rx_speed = 296kB/s,
delta = 9599408B, delta% = 8При интенсивности 2048 байт каждые 10 мс потери меньше 1%, но есть:
Цитатаrx_count = 64677888, tx_count = 65239040,
tx_time = 318s,
tx_speed = 200kB/s, rx_speed = 198kB/s,
delta = 561152B, delta% = 0(указаны число принятых байт, переданных байт, общее время работы, средняя скорость, число потерянных байт и процент потерь)
При работе с FC - потерь нет вообще.
-
В 10.10.2023 в 02:43, jcxz сказал:
Серьёзно?
Гладиолус!
A7672E, P/N:S2-109ZS-Z31DH, 921600 бод.
-
В 30.08.2023 в 11:03, jcxz сказал:
о скорей всего (90% вероятность) окажется что RTS/CTS совсем не нужны.
Практика показывает что нужны.
Тестировал на +GMR:A011B05A7672M7_F
-
В 27.09.2023 в 12:04, EdgeAligned сказал:
Этот вопрос был в теме темы: "Если маркировка стерлась ацетоном, то выкинуть микросхему в мусорку или хотя-бы проверить, работает ли она?"
В серию нужно ставить компоненты от проверенного поставщика. Все остальное - не целесообразно, т.к. время профессионала, потраченное на "опыты", будет значительно дороже.
Но "для дома, для семьи" балуюсь китайщиной, и это все на уровне поделок, мигалок, игрушек для развлечения детей.
-
В 27.09.2023 в 00:37, paskal сказал:
Приобрел на Алиэкспрессе несколько МК атмега88 для опытов.
Если для опытов - то смело можно паять. Ни разу не попадались (с Али) микросхемы с дефектами, хотя не исключаю.
В продукцию - ставить компоненты только от проверенных поставщиков.
-
В 07.09.2023 в 12:56, jcxz сказал:
Этот код Unicode кодирует китайский иероглиф, выражающий пожелания здоровья и благополучия Председателю Мао.
Брехня!
E339 - это фосфат натрия.
ЦитатаФосфаты натрия ранее широко применялись в различных стиральных порошках и моющих средствах. Однако, начиная с 1960 года использование фосфата натрия в стиральных порошках начало постепенно запрещаться во многих странах для уменьшения эвтрофикации водоемов.
Его добавляют, чтоб flash лучше стиралась.
-
В 31.08.2023 в 14:47, EdgeAligned сказал:
Посоветуем либо ПЛИС
Можно на чем-то типа STM32H745xI/G удержаться за счет High-Resolution Timer (HRTIM). Обещают:
Цитата1× high-resolution timer (2.1 ns max resolution)
или на STM32G474 с его
ЦитатаHRTIM (Hi-Resolution and complex waveform builder): 6 x16-bit counters, 184 ps resolution, 12 PWM
(эквивалентная частота 5.44 ГГц)
-
И самое забавное, что если быстро в конце обработчика скинуть запрос прерывания от периферии, то при выходе из прерывания NVIC может не успеть на это среагировать и будет повторное вхождение. Поэтому в обработчике я всегда проверяю установку флага от периферии, сбрасываю флаг от периферии подальше от конца обработчика, ну, еще и барьер можно влепить после сброса флага от периферии.
-
В 28.08.2023 в 08:50, Arlleex сказал:
Не совсем понял. Почему прерывание может возникнуть еще раз?
Типа, мы уже в обработчике прерывания, но приходит еще один запрос для того же прерывания - и получаем вложенное прерывание (само в себя). Насколько мне известно на Cortex-M такое невозможно.
-
Попробуйте EXTI дать высший приоритет, а UART/DMA понизить приоритет. UART/DMA не должны пострадать, т.к. за время выполнения EXTI не прилетят два символа по UART (при разумной скорости обмена).
-
Пока выполняются обработчики UART и/или DMA все повторные (и более) импульсы будут потеряны. Каждый импульс защелкивается до его обработки обработчиком EXTI, поэтому на низких частотах потерь нет, даже если импульс пришел в момент выполнения обработчиков UART/DMA.
-
Может, работает еще какое-нить высокоприоритетное прерывание, которое выполняется порядка 50 мкс?
притормозить USB MS
в RS232/LPT/USB/PCMCIA/FireWire
Опубликовано · Пожаловаться
100 кБ - это 12800 пакетов по 8 байт. Если "начить" по 5 мс для каждого пакета, то это превратится в 64 секунды. Думаю, до 50 мс можно безопасно выдавать NAKи, а это порядка 10 минут для 100 кБ.