adnega

Практика показывает что нужны. Тестировал на +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

Сделал принудительную инициализацию SP в начале вектора сброса - теперь все работает.

Добрый день! Столкнулся с этой же проблемой, но на GD32F405RGT6. Пока не подашь RESET - не работает. Если при подаче питания удерживать RESET - не помогает - только второй дополнительный импульс. Кста, в заводской загрузчик заходит тоже только после передергивания RESET. После дополнительного импульса RESET - все прекрасно работает. Если идти от минимального кода, то можно сделать рабочий blink. Если blink плавно усложнять, то может сложиться ситуация, когда код перестает запускаться в принципе. Это никак не связано со временем выполнения, т.к. blink может работать бесконечно. Шьется всегда без проблем. В партии обнаружили два МК с таким поведением - один у меня в наличии - могу всячески тестировать. Замена МК помогает. Если сделать рабочий blink, то при подаче питания - задержка выполнения кода - 140мс; если удерживать RESET, подать питание, отпустить RESET - те же 140мс после отпускания RESET; если передернуть RESET запитанного МК, то задержка выполнения кода нулевая. Кста, размер работающего blink порядка 32кБ, просто в начале исходника перемещаю аналог while(1) и большая часть кода не выполняется. Поискал причину: оказывается, что при старте SP не копируется из памяти. При сбросе по питанию вижу SP=0xFFFFFFFC. При нормальной работе SP=0x20020000.

Или такому нарастить длину контактов и, возможно, заменить пружину.

Контакты в сечении - квадрат. Углы быстро слижутся и условный диаметр уменьшится, а с ним и сила прижима контакта. Кста, диаметр металлизированных отверстий тоже может "плясать" от партии к партии, или от платы к плате. Когда роль играют десятые и сотые доли миллиметра - я даже не берусь. Pogo-пины всем хороши, но их нужно чем-то прижимать. Кста, если было бы что-то фиксируемое в отверстии М3, то это тоже задачу решило, т.к. вокруг отверстия М3 можно насыпать пятаков и прижиматься к ним pogo-пинами. Могу накустарить фиксатор для М3, но вот если заводское что-нить было...

- или так, если нужно отлаживать долго))

Ключевое слово "надежный". Вряд ли всякие перекосы/расклинивания и т.п. тут подойдут. Я везде использую такой разъем для программирования/отладки: Шью ответной частью с подпружиненными иголками. Если удается вывести разъем на край платы, то вообще красота: - цепляюсь самодельной прищепкой. Кста, на Али есть готовые прищепки.

На нем же написано ATM8F8040K. 1612676651183639.pdf