adnega

Вы все сравнили - молодец - а толку? Архив с логом и декодер для A76xx прицепил. Отладка от mt-system. Повторю, при хороших условиях связи она работает отлично - без единого дерганья на FC. Но у меня изделие будет далеко не в тепличных условиях. Я не готов терять каждый 17 байт, поэтому и акцентирую внимание. Кста, мне ничего не мешает повторить эксперимент на SIM868 с FC. Нужно? Прошу дать оценку работоспособности такого комплекта: Прошивка версии +GMR:A011B05A7672M7_F A76xx.zip

Я не думаю, что с выходом нового модуля программисту начинают придумывать архитектуру ПО с нуля. Конечно, есть наработки - их используют. Но разговор не об этом. Я вас понял, вы можете реализовать обмен по UART, не используя FC, я тоже могу и мне ни разу не приходилось тормозить поток. А SIMCOM то ли не могут, то ли не хотят, раз у них такой функционал есть и он живой. Может, там историческая подоплека. Повторю: я использую оригинальную отладочную плату. В разных условиях связи она работает по-разному. Я не знаю чем в модуле проц занят. Но это похоже не на то, что он не умеет в UART, а скорее на отказ в обслуживании, мол, данные ты, конечно, можешь заслать, но их модуль все равно в сеть не отправит. Я не защищаю ни SIMCOM, ни пытаюсь вас оспорить в части правильного ПО - я лишь привел примеры с чем лично сталкивался, где без FC в некоторых случаях будет грустно. Ваше право распорядится этой информацией как посчитаете нужным. Где я такое заявлял? Я из тех программистов, кто давным давно занимался экономией каждого такта и каждого байта, поэтому про посильность что-то смыслю. Кроме UART модуль может заниматься и другими делами. Поскольку там стоит МК профиля R, осмелюсь предположить, что и задачами реального времени. А это когда в какой-то определенный момент времени нужно делать определенное дела, а все остальное подождет. Чем именно занимается проц и сколько это длится по времени - я знать не могу. Я-то тут причем? Обсуждаем не меня, а факты. Хотите - можете повторить поведение модулей. Ваши советы строятся на вашем же понимании качественного ПО. Вы, не сомневаюсь, можете запустить любой модуль и любой проц, чтоб не глючило, и даете советы. Кому? Профессионалам - дык, они сами с усами. Новичкам? Увы, они не смогут все и сразу сделать правильно, столкнутся с неидеальностью модулей - тут-то их FC и выручит. Я на A7672E вообще основным каналом постараюсь сделать USB, поэтому FC - не актуально. Использую SIM868 без FC - и тоже не грущу. Чтоб закрыть тему про меня, доложу: АТ-команды, в моем понимании, устаревшая технология. На ESP пишу софт непосредственно под ESP, на SIMCOM использую EAT где возможно. Постараюсь на новых модулях уйти от UART в сторону USB, где есть интерфейсы сетевой карты и CDC (debug+GSM+GNSS). Если конкретно у вас нет FC-опыта, то это не значит, что FC не существует)) Вы правы, я этого не знал, и какое-то время пытался работать с ним через АТ-команды. Что-то работало, но соединение так установить и не получилось))

Нельзя все валить на программиста. Есть еще такое понятие как "архитектура ПО". Любое спроектированное ПО будет иметь свои ограничения. В моих примерах SIMCOM и ESP - это две абсолютно несвязанные вещи. Общее у них - есть примеры ситуаций, где FC пригождается. Просто, он может обрабатывать другие более приоритетные задачи. Обратите внимание на "фаршированность" модуля - там много чему нужно работать помимо AT. В очереди стоят две SIM-карты, SDIO-карточка, дисплей, клавиатура и т.п. - и каждый так же про себя думает. А в это время проц пытается правдами и неправдами вытащить полезную инфу из сетевого трафика. )) Если вы имеете дело только с миганием светодиодом, то вам неизвестна вся боль, возникающая при организации связи с интеллектуальной второй стороной. Под "миганием", я понимаю, ваш полный контроль за выполнением команд. Как только появляется нечто, что может не ответить, или может задуматься, то появляются совершенно новые невиданные доселе проблемы. Вы как программист можете все валить на вторую сторону, но юзер, который использует ваше устройство будет считать именно вас бракоделом. )) я вас понял - 51-е ядро туда - для обработки АТ хватит с горкой. А SIMCOMовцы туда аж Cortex-R5 засунули, причем, R - это жжж не спроста. Я так понял, вы конкретно с A7672E не работали. Их, кста, как минимум две версии есть, и вторая вообще не про АТ-команды))

Процессор любой мощности можно напрячь по-полной. Я точно не знаю - лишь впечатления. Были плохие условия связи, видимо, проц был полностью вовлечен в дела радиочасти, а AT-задачи стали менее приоритетными. Видно, что uart потреблял данные блоками по 16 байт, а затем тормозил прием - видимо насыщался какой-то FIFO буфер. Пользуюсь оригинальной отладочной платой - там должно все быть ок. Если есть желание, могу скинуть дамп логического анализатора всего обмена - там тоже все ок)) Кста, приделал антенну получше и заменил оператора связи - все взлетело. Да, на столе можно заставить работать хорошо, создав тепличные условия, но мне нужно, чтоб и в поле работало. 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 - на тот момент прошивка свежайшая. У меня ESP использовалась в режиме сквозного канала - по сути UART-TCP. AT+CWJAP_DEF="ssid","password"// настройка сети AT+SAVETRANSLINK=1,"192.168.0.200",12345,"TCP"// настройка сервера Мне от ESP в том эксперименте была важна не пропускная способность, а как можно большее число пакетов в секунду, т.к. целевой протокол был "запрос-ответ". Тестирование скорости - это побочная часть эксперимента. По итогу поправили протокол, ввели в него команды более высокого уровня, чтоб "запрос-ответов" снизить, и чтоб рутинную часть обмена убрать. Да у STM, чтоб скорости совпадали. У меня МК в эксперименте прохлаждался - молотили UART+DMA, он только статистику вел без какой-либо полезной работы. Ага, там стоит мощный проц только для обработки АТ-команд )) По железу - исключено, по софту - могу дамп анализатора скинуть со всем обменом)) Удобно называть все, что требует FC - забагованным))

Нет. Явно видно, что модуль "задумывается". Да, и с FC проблема принципиально исчезает - если бы проблема была в различии скоростей, то она бы осталась.

Я несколько дней гонял A7672E. У одного Оператора связи - все прекрасно. У другого - такой лес на FC. Есть огромное желание подключить модуль по USB, т.к. требуется максимальная скорость. А SIM868 использую в промышленных масштабах без FC - вроде, норм, но допускаю, что софт хорошо разруливает возможные последствия потери байтов. Кста, я на ESP8266 в AT-прошивке тоже получал потери байтов (при передаче в ESP8266) без использования FC. Там есть прозрачный режим, который сносно работает, если трафик умеренный. При работе на скорости 80МГц/24=3.3Мбод на непрерывном потоке получал порядка 8% потерь: При интенсивности 2048 байт каждые 10 мс потери меньше 1%, но есть: (указаны число принятых байт, переданных байт, общее время работы, средняя скорость, число потерянных байт и процент потерь) При работе с FC - потерь нет вообще.

A7672E, P/N:S2-109ZS-Z31DH, 921600 бод.

Практика показывает что нужны. Тестировал на +GMR:A011B05A7672M7_F

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

Если для опытов - то смело можно паять. Ни разу не попадались (с Али) микросхемы с дефектами, хотя не исключаю. В продукцию - ставить компоненты только от проверенных поставщиков.

Брехня! E339 - это фосфат натрия. Его добавляют, чтоб flash лучше стиралась.

Можно на чем-то типа STM32H745xI/G удержаться за счет High-Resolution Timer (HRTIM). Обещают: или на STM32G474 с его (эквивалентная частота 5.44 ГГц)

И самое забавное, что если быстро в конце обработчика скинуть запрос прерывания от периферии, то при выходе из прерывания NVIC может не успеть на это среагировать и будет повторное вхождение. Поэтому в обработчике я всегда проверяю установку флага от периферии, сбрасываю флаг от периферии подальше от конца обработчика, ну, еще и барьер можно влепить после сброса флага от периферии.

Типа, мы уже в обработчике прерывания, но приходит еще один запрос для того же прерывания - и получаем вложенное прерывание (само в себя). Насколько мне известно на Cortex-M такое невозможно.

Попробуйте EXTI дать высший приоритет, а UART/DMA понизить приоритет. UART/DMA не должны пострадать, т.к. за время выполнения EXTI не прилетят два символа по UART (при разумной скорости обмена).

Пока выполняются обработчики UART и/или DMA все повторные (и более) импульсы будут потеряны. Каждый импульс защелкивается до его обработки обработчиком EXTI, поэтому на низких частотах потерь нет, даже если импульс пришел в момент выполнения обработчиков UART/DMA.

Может, работает еще какое-нить высокоприоритетное прерывание, которое выполняется порядка 50 мкс?

Ммм.. ; 20.4ns = 6t ; LDR R5, =0x40020418 800530a: 4d04 ldr r5, [pc, #16] ; (800531c <cc+0x3c>) ; LDR R6, =0x40020418 800530c: 4e03 ldr r6, [pc, #12] ; (800531c <cc+0x3c>) 800531c: 40020418 .word 0x40020418 Да 8 байт. Но какой толк от второй команды, когда есть MOV ? Пока делаю вывод, что у МК с WS0 для кода самая быстрая загрузка imm32 будет с использованием MOV/MOVT, но более расточительна по памяти.

"=imm32" я понимаю как "[PC, label]". Команда "LDRD R5, R6, [PC, label]" компилируется, и листинг я приводил (данные лежат по метке "cc"): 80052bc: e9df 5604 ldrd r5, r6, [pc, #16] ; 80052d0 <cc> .. 080052d0 <cc>: 80052d0: 40020418 .word 0x40020418 80052d4: 40020418 .word 0x40020418

LDRD - это загрузка двух 32-битных слов (данные занимают 2 * 4 байта = 8 байт). Плюс сама команда 4 байта. 8 + 4 = 12 байт.

80052bc: e9df 5604 ldrd r5, r6, [pc, #16] ; 80052d0 <cc> .. 080052d0 <cc>: 80052d0: 40020418 .word 0x40020418 80052d4: 40020418 .word 0x40020418 те же 20.4 нс (6 тактов, 12 байт). Но 80052bc: f44f 6583 mov.w r5, #0x0418 80052c0: f2c4 0502 movt r5, #0x4002 80052c4: f44f 6683 mov.w r6, #0x0418 80052c8: f2c4 0602 movt r6, #0x4002 всего 13.4 нс (4 такта, 16 байт) Кста, на тему теневого копирования, WS=0 и т.п. недавно сделал пост, но он оказался не замеченным, хотя там беда масштабнее.

Вот несколько измерений, которые добавлял в середину цепочки из STR R4, [R5, #imm] // 13.4 ns MOV R5, #0x0418 MOVT R5, #0x4002 LDR R6, [R5] // 20.4 ns LDR R5, =0x40020418 LDR R6, [R5] // 20.4 ns LDR R5, =0x40020418 NOP LDR R6, [R5] // 24.0 ns LDR R5, =0x40020418 LDR R6, [R5] LDR R6, [R5] // 3.5 ns LDR R6, [R5] // 16.6 ns LDR R5, =0x40020418 // 20.4 ns LDR R5, =0x40020418 LDR R5, =0x40020418 // 20.4 ns LDR R5, =0x40020418 LDR R6, =0x40020418 Интересный документ.

Вы правы. Если сравнить реализацию в AT32F437 с реализацией в STM32F43x то видно, что I и D шины у ST разделены, поэтому ситуация может быть принципиально лучше. Но если ответить на часть вопроса, то в AT32F437 выборка инструкций идет на частоте PLL (288 МГц макс), с нулевыми циклами ожидания. В случаях, когда команда дергает I и D шины - МК AT32F437 может существенно проигрывать ST. Получается, что для загрузки 32-битных значений в регистр по памяти проигрываем (8 против 6), но по тактам можем выиграть сильно (если таких ситуаций много). Может, есть какой ключик компилятора на этот случай?

Кста, вместо "LDR R5, =0x40020418" можно использовать MOV/MOVT MOV R5, #0x0418 MOVT R5, #0x4002 - это чуть-чуть быстрее (раза в два)

Я запустил такой код на частоте 288МГц. 1 такт ~3.47нс. MOVS R4, #0x0001 LDR R5, =0x40020418 STR R4, [R5, #0] STR R4, [R5, #16] STR R4, [R5, #0] STR R4, [R5, #16] LDR R5, =0x40020418 LDR R6, [R5] LDR R5, =0x40020418 LDR R6, [R5] STR R4, [R5, #0] STR R4, [R5, #16] STR R4, [R5, #0] STR R4, [R5, #16] STR R4, [R5, #0] STR R4, [R5, #16] В середине есть блок из пар загрузки из Flash с последующим чтением из периферии. Каждая такая пара выполняется за порядка 20нс (~6 тактов). Если убрать либо чтение Flash, либо чтение из периферии, то число тактов резко падает (к 1 такту). Я подозреваю какую-то очередь в районе шины AHB. Видимо, не нужно создавать очередей, чтоб код стал эффективно выполняться. Например, между этими двумя командами можно поставить NOP, и это никак не повлияет на время выполнения - оно не увеличится. Вместо NOP можно поместить более полезную команду, которая не конфликтует за доступ к AHB. AT32F437 то пропадают, то появляются по несколько тысяч штук. -ZG и -ZM не принципиально отличаются по цене, и за такой функционал - считаю, даром. В идеале хотелось бы, чтоб все устаканилось, и появилась ревизия В, т.к. в А много силиконовых глюков. Тоже долго мучились, но решили делать серийное изделие на AT32F437Z