Xenia

Вижу, что на отечественное "импортозамещение" надежды нет - аналоги импортных МК по ценам неконкуретноспособны. А что скажите про китайскую серию GD32, которая старалась быть похожей на STM32? Правда ли, что они по цоколевке и по программированию взаимозаменяемы? Кто-то пытался ими заменить STM32? https://www.eltech.spb.ru/mikrokontrollery-gigadevice-instrukciya-po-osvoeniyu

А что там с оборудованием от AMD для производства чипов с нормами 130-90 нм, купленного аж 13 лет назад (в 2008 -году)? То, что Ангстрем-Т банкрот, не суть важно, но ведь оборудование не сгноили же? Кому-то ведь оно должно было достаться. Неужели за эти 13 лет дело с мертвой точки так и не сдвинулось? https://habr.com/ru/post/413377/

Перенесла в /pub/BOOKS/DSP/Meyer-Baese U., Digital Signal Processing with Field Programmable Gate Arrays(2014)CD.zip Однако, удивительное дело, - там уже был CD-диск к этой книге, то только 2007-го года издания, причем на порядок большего размера - 414 МБ в zip-архиве, тогда как сейчас в архиве только 36 МБ. Не могли бы вы выяснить, что там пропало за 7 лет?

TM4C123 и TM4C129 плохи тем, что сделали и забыли. Тогда как линия должна развиваться, сохраняя какую-то преемственность. Позитивные примеры - AVR и STM32. Т.е. если даже первый блин комом, по последующие версии становятся всё лучше и лучше.

Бог с ней, с российской электроникой :). Ее недостатки уже и без того достаточно обсосаны в других темах. Тогда как в этой теме осталось совершенно неясным, что могло помешать компании ST производить свои STM32 на фабриках более низкого ранга (там где техпроцесс всё еще крупный). Ведь если STM32 не требуют для своего производства слишком уж передового техпроцесса (STM32 мельче 40 нм не бывает), то очевидно, что и нет необходимости обращаться с этим к TMSC, которая сейчас перегружена заказами. И если спрос на персональные компьютеры в пандемию мог и в самом деле возрасти, то совершенно неясно, с чего бы ему возрасти на микроконтроллеры.

Вроде бы для производства STM32 техпроцесс 65 нм не так уж необходим. В интернете нашла такую информацию: STM32 F3/F4 - 180 нм STM32 F7/G4 - 90 нм STM32 H7 - 40 нм Т.е. аналоги наиболее популярных STM32F0, STM32F1 и STM32F4 отечественная промышленность вполне могла бы выпускать сама. Причем не в урезанном варианте, как это сделал НИИЭТ в своих AVR-клонах (1887ВЕ), а так, как делают китайцы - стараются усовершенствовать то, что копируют. Ну, хотя бы ерраты исправить :). Тогда как у STM32 можно найти многое из того, что исправить было бы не грешно. Например, размножить периферийные регистры на старшие порты. А то на портах PA-PB густо, а на PF-PH пусто.

Это было бы так, если бы они сами микросхемы делали, а не заказывали их на Тайване. А раз делают не сами, то на них общая анафема распространяется - тайваньская фабрика завалена заказами и будет тормозить производство псевдо-отечественных микросхем еще пуще, чем остальных (ибо там более солидные клиенты).

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

Полагаю, что ошибка в том, что в ассемблере этого контроллера нет команды "memcpy".

При дефиците полупроводников практически все микроконтроллеры становятся дефицитными. А те, что производятся по совсем грубым технологическим нормам (их дефицит слабее затронул), обычно примитевнее, чем STM32, и потому переход на них с STM32 был бы шагом не вперед, а назад. Прошу ознакомиться с данными коммерческого вестника EBV, специализирующегося на мониторинге рынка микроконтроллеров. Свежий выпуск (июль-август 2021) вышел буквально на днях: http://tk-gm.com/Newsletter/EBV/2021_Commercial/07/Commercial_Newsletter_Jul_2021.pdf там на странице 8 есть данные для "MCU & DSP" по отдельным производителям. Обращает на себя внимание, что 32-битные микроконтроллеры от компании Microchip, продукцию которой в этой теме предлагали на замену STM32, являются в настоящее время чемпионами по задержке с поставками - они достигли 64-72 недель. Т.е. почти полтора года! Лучше всех дело обстоит у Infineon'а, но, полагаю, только из-за того, что они имеют ограниченный спрос. Не вижу в списке компанию Texas Instruments (TI), а то бы рекомендовала присмотреться к Sitara - AM335X (и выше, если денег не жалко). Оно есть ранее знакомый вам по STM32 Cortex, только не Cortex-M, а Cortex-A. Кстати, и компилятор IAR его тоже поддерживает. Конечно, в этом варианте есть тот минус, что американцы могут перекрыть России кислород, объявив эмбарго на электронную продукцию. Однако эти микроконтроллеры несложно купить у третьих лиц, в том числе и Китае. К тому же китайцы продают уже готовые модули с памятью на этом микроконтроллере по приемлемым ценам, поскольку этот модуль выпускается большими тиражами для кассовых аппаратов: https://aliexpress.ru/item/4001085729647.html

Фьюзы вы задали верно, а потому свой совет я отзываю. Тем более что вы изначально не указали, что проблема в зависании в процессе записи, а не в отказе avrdude прошивать ваш контроллер. А это может несколько менять дело, перекладывая отвестственность за сбой с avrdude на программатор. Вы можете отдельно прошить фьюзы с помощью avrdude, а следом использовать openOCD или какую-то другую программу для прошивки кода. Обычно фьюзы они не трогают, если их об этом не просить. Я вот тоже прошиваю фьюзы всего однажды, а потом только меняю прошивки (при отлаживании кода это приходится делать многократно), более не трогая фьюзы. Ибо боюсь, что от частого перебивания фьюз контроллер испортится :). У меня была похожая ситуация с ATmega2560 (похожа на вашу ATmega2561) на плате управления 3D-принтером. И я уж было взялась исследовать, как следует прошивать ее верхнюю память (это нетривиально, т.к. стандартное адресное пространство в AVR-архитектуре 128К байт или 64K слов), но скоро бросила это дело, обнаружив, что моя прошивка короче 128K. Т.е. верхнюю память я попросту не прошивала.

Было бы полезно, если бы вы привели командную строку для avrdude, которой вы пытались зашить ATmega2561. А поскольку вы этого злонамеренно :) не сделали, то и мой ответ вам будет того же сорта: ваша ошибка в том, что вы не использовали ключ hfuse, который используется для прошивки флеша за пределами младших 128К. А ваш самодельный программатор на основе FT2232H в этом совершенно не виноват. Примеры использования этого ключа можно найти здесь: https://ph0en1x.net/77-avrdude-full-howto-samples-options-gui-linux.html

Можно и на интринсиках, однако к их именам приходится привыкать, тогда как AVX-инструкций много (велико разнообразие). Так стоит ли овчинка выделки? - Стоит ли привыкать к этим именам, когда у инструкций есть свои "родные" имена (далеко не всегда совпадающие с интринсиками). Тем более что тогда пришлось бы писать на интринсиках всё подряд, включая оформление циклов. А здесь есть свои тонкости - например, инструкция LOOP, типично используемая для "циклизации" в 64-разрядном коде, работает заметно медленнее, чем декремент с сравнением.

Я пишу на ASM'е времякритичные процедуры, а не программы целиком. А потому эволюция здесь направлена только в сторону увеличения разрядности: писать под DOS = писать 16-разрядный код, писать под WinXP = писать 32-разрядный код, писать под современные ОС = писать 64-разрядный код. Писать 64-разрядный код начала сравнительно недавно (2 года назад), а раньше писала только 32-разрядный. Причем, основное поле моих ассемблерных занятий - это возня с SSE/AVX-инструкциями в пакетном режиме (это когда операция параллельно выполняются сразу над несколькими аргументами). Тогда как обычные компиляторы добровольно пакетный режим никогда не используют. Мечтаю в будущем заполучить процессор типа Intel Rocket Lake, умеющий выполнять инструкции AVX-512. Тогда бы в длинные регистры поместилось бы 512/64=8 чисел типа double, что позволило бы еще больше ускорить флоат-арифметику за счет параллелизма. Тогда как надежд на то, что тактовая частота процессоров значительно превзойдет 5 ГГц, уже не осталось. ,

Я наверное отстала от жизни :), т.к. до сих пор считаю, что MASM, FASM и NASM - компиляторы для процессоров архитектуры x86/x64, а вовсе не для МК. Уже давно пописываю на ассемблере для ПК, еще со времен TASM (Turbo Assembler из ранних поделок компании Borland, к которому позднее писали дополнения). А что касается компиляторов ассемблера для МК, то здесь, на мой взгляд, принцип выбора тот же, что и для ПК - следует выбирать тот, который входит в комплект языка более высокого уровня, которым вы владеете. Например, использовать MASM (ныне он называется ml.exe), если пишете на MS Visual Studio. Это дает возможность писать на смеси языков, используя ассемблер там, где требуется ускорить выполнение каких-то процедур. С этой стороны имеет смысл обратить внимание на компиляторы языка C/C++ от компании IAR, в комплект которых входит и компилятор с ассемблера. Это обстоятельство позволяет писать на смеси языков, используя один и тот же линкер. А для тех, кто изучает ассемблер в качестве второго языка, такая возможность - сущий подарок, поскольку позволяет сперва посмотреть на код функции , которую генерит компилятор C/C++, чтобы потом его отредактировать и использовать уже в ассемблерной версии.

Имя массива, как и имя переменной, не могут начинаться с цифры.

Потому, что сама структура GPIO_InitTypeDef, пример инициализации которой приведен в топовом сообщении, определена в пакете CubeMX, здесь: \Drivers\STM32F4xx_HAL_Driver\Inc\ А если бы она была определена в CMSIS, то вопрос о том, что использует топикстартер, оставался бы открытым.

Основное отличие программирования F4 от F1 через CubeMX cостоит в том, что в структуре GPIO_InitTypeDef появилось новое поле "Alternate", через которое теперь в явном виде задаются функции пинов порта, отличные от ногодрыга. Например: GPIO_InitStruct.Alternate = GPIO_AF2_TIM4; При переходе от F1 на F4 необходимо эти поля проинициализировать для каждого конкретного случая и занулить, если переопределение стандартной функции не используется. Однако проще всего создать для F4 новый проект, задав в нем системные клоки и описав в нем функции портов. А в уже сгенерированный код добавить всё то. что было у вас прежде написано под F1.

Хорошая тема получилась - всяк может похвастаться своим мультиметром :). Вот и у меня тоже есть более крутой мультиметр APPA-103N, но парадокс в том, что пользуюсь в основном тем самым примитивным тестером, который был заявлен в топовом сообщении. Причина видимо в том, что он небольшого размера и легкий, а какая-то высокая точность измерения бывает мне нужна редко.

А зачем этому прибору генератор меандра, если сам он частоту измерять не может? Было бы гораздо логичнее, если бы прибор совмещал в себе и функцию частотомера, поскольку измерение частоты - это тоже измерительная функция. Тогда как у меня в этом положении рукоятки на дисплее появляется цифра "1.1" непонятно чего. P.S. На моем приборе надпись "DT-832" отсутствует, а то бы я еще раньше в интернете информацию про него нашла.

Очень познавательно :). Любопытно, что начиная с 13:30 минуты мультиметр подменили - у него появился еще один сектор со значком меандра. Что бы это значило? Измеряет ли мультиметр в этом положении частоту или, наоборот, генерит ее? P.S. У меня как раз такой есть - на рынке за 200 руб когда-то купила, без описания.

На МК нет dll-лек.

Переименовываешь расширение имени файла с *.c на *.cpp - вот и весь переход :).

Если 77-пин у вас носит имя PA15, то он у вас не работает исключительно потому, что занят под JTAG (это его default функция). Отключите полный JTАG (оставьте только двухпроводный SWD+SWCLK) после чего он у вас заработает. Лично у меня он импульсы считает :). В CubeMX это делается так: Pinout & Configuration -> System Core -> SYS -> Debug -> Serial Wire.

Если делать ставку на STM32, то я бы посоветовала вместо голубой таблетки черную :). https://aliexpress.ru/item/4001157813131.html 250 руб (доставка бесплатная) топикстартера не разорят, а плюс в таком решении тот, что на этой плате стоит младшая модель Cortex-M4 - STM32F401, у которых фабрично прошит USB-загрузчик. А стало быть програматор можно не покупать. К тому же Cortex-M4 - это уже "взрослый" контроллер, который вполне годится на вырост. Тем не менее, хотя готовые платы STM32 удовлетворяют требованию максимальной эффективности за рубль затрат, STM32 не удовлетворяет требованию обойтись без IDE и библиотек. Я вот тоже не рискнула бы программировать STM32 "в сухомятку" :). Но если впереди ставить требование простоты написания программы с нуля, то в этом случае имело бы смысл купить Ардуину (на ATmega) с USB-коннектором - что-нибудь вроде этого: https://aliexpress.ru/item/32810655273.html А дальше программировать ее без использования Arduino Studio, как обычный контроллер. Тем паче, что фабричный ардуиновый загрузчик позволяет заливать в нее прошивку без программатора с помощью программы avrdude.exe.