Xenia

http://89.175.255.52/8051/EW8051-EV-720H.exe.rar

Найдется. Как только интернет мне починят, так сразу выложу. (Текстовые сообщения кое-как проходят с 10-го раза, но файл в 48 МБ мне не закачать).

А надо ли программатор заменять, когда китайцы их за дешево продают? (порядок цены 100 руб) Например здесь: https://aliexpress.ru/item/32879822219.html Из описания следует, что ваша Tiny13 и AVRDude им тоже поддерживаются: Поддержка AVRDude Начиная с версии 5.2 Поддерживаемые микроконтроллеры включают: ATtiny12 ATtiny13 ATtiny15 ATtiny25 ATtiny26 ATtiny45 ATtiny85 ATtiny2313 Суть проблемы, как я полагаю, не в электронике, а в мозгах микроконтроллера, который должен быть способен выдать себя за один из стандартных программаторов, поддерживаемых AVRDude. Короче говоря, AVRDude сама не определяет, как надо дрыгать линиями MOSI, MISO и CLK, а отправляет в программатор файл прошивки в текстовом виде (extended intel hex), который интерпретируется на месте микроконтроллером программатора.

Скриншот натуральный, я его лишь обрезала с боков. Я вас уже предупреждала, что надо скроллером покрутить, чтобы подняться по списку до этих строк. Тогда как в противном случае в окне видна лишь концовка списка, где текст не таков, как на картинке. Вы же, по-видимому, этого не сделали, а потому и удивляетесь, что видите в окне другой текст, а не тот, что на скришоте. Лично у меня концовка messages-текста такова: IAR ELF Linker V8.50.4.261/W32 for ARM Copyright 2007-2020 IAR Systems AB. 51'507 bytes of readonly code memory 1'279 bytes of readonly data memory 12'601 bytes of readwrite data memory Errors: none Warnings: none Link time: 0.25 (CPU) 0.29 (elapsed) ZJoy.out Converting ielftool.exe --ihex --verbose P:\Z19-test\EWARM\ZJoy\Exe\ZJoy.out P:\Z19-test\EWARM\ZJoy\Exe\ZJoy.hex IAR ELF Tool V10.6.8.1259 [BUILT locally] Copyright 2007-2020 IAR Systems AB. Loading P:\Z19-test\EWARM\ZJoy\Exe\ZJoy.out Saving ihex file to P:\Z19-test\EWARM\ZJoy\Exe\ZJoy.hex Total number of errors: 0 Total number of warnings: 2 Где строки про загрузку памяти находятся чуть выше верхней кромки окна, если оно узкое по высоте. Поэтому и пришлось прибегнуть с скроллированию, чтобы сдвинуть текст вниз, чтобы показать вам эти строки.

Однако заметьте, что эти строки не последние в списке окна Messages. Я чуть подкрутила скроллер, чтобы вам эти строки показать.

Вы сделали совсем не то, что я сказала. В "IDE Option" ходить не надо и на эту вкладку зырить тоже. Надо вот что сделать:

Тогда только это могу посоветовать: вызовите контекстное меню в окне Messages (для этого правой кнопкой мыши по нему кликнуть надо) и там переставьте галочку с Messages на All. Получите много мусора :), среди которого будут и вожделенные вами строки.

Во всех версиях IAR это устроен одинаково. Главное меню: Project -> Options -> Linker -> List -> ставите галочку возле "Generate linker map file". Это для того, чтобы линкер *.map файл в директорий List писал. И в этом файле после компиляции найдете интересующую вас информацию - она в самом его конце. Например, у меня так: 51'531 bytes of readonly code memory 1'291 bytes of readonly data memory 12'689 bytes of readwrite data memory Errors: none Warnings: none А такого, чтобы вам эту информацию в каком-то окне само показывало, - этого нет, map-файл надо читать.

На код функций чтения и записи это не вляиет, но может влиять на протокол обмена. Экономия одного лишь бита дает выигрыш в скорости передачи на 4% :) (шутка).

Размер может иметь значение: У вас вероятно hqspi.Init.FlashSize = 26; а у меня hqspi.Init.FlashSize = 25; т.е. на 1 бит адреса меньше. Впрочем, я не уверена, что у вас это так. Это так в коде, который dr.v опубликовал: "Стандартным коннектом" я назвала тот, который CubeMХ выбирает по умолчанию, когда активируешь QSPI.

А у меня W25Q64JVSIQ, т.е. вдвое менее ёмкая, чем ваша. Коннект к QSPI стандартный.

MementoMori, вы ранее уже приводили код инициализации QSPI, а можно ли вас попросить привести еще и код записи/чтения? Это не потому, что я ваши ошибки там искать намерена :)) а просто хочу испытать свои платы на STM32H473, которые получила на прошлой неделе. Тогда как опыта работы с QSPI у меня нет, т.к. у тех МК, с которыми я прежде имела дело, контроллера QSPI не было. Заодно бы посмотрела, работает ли эта память на 35 МГц.

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

Я заказал у нашего поставщика сам контроллер, не более. Тогда я поделюсь с вами информацией по поводу китайских плат, которые сама совсем недавно купила. Первая: Вторая: Вторая мне нравится больше (из-за кварца). Однако из двух одинаковых микросхем flash-памяти режим QSPI доступен только для нижней, тогда как для верхней он не доступен, т.к. у нее линии IO2 и IO3 припаяны к 3V3. Тогда как голая микросхема STM32H743VIT6 в "Чипе и Дипе" стоит 1 350 руб. Ну как мне после этого не любить китайцев? :)

У китайцев? Если это продаваемая готовая плата, то не поделитесь ли ее источником?

Может быть стоит уменьшить делитель DIVM, чтобы множитель DIVN стал меньше? Скажем вместо 8 MHz /8 * 420 / 2 = 210 MHz написать 8 MHz /2 * 210 / 2 = 210 MHz а то от множителя 420 мне как-то не по себе - не видела таких больших.

Я не вступала с вами в дискуссию, а лишь задала вопрос про STM32H7: На что получила вот такой ваш ответ: Ясно, что после такого ответа мне пришлось задать этот же вопрос другому человеку (_4afc_), который был в курсе технических характеристик Sega Genesis. Да тоже. Тем более что ныне существуют двухядерные STM32H747/STM32H757, где второе ядро ну никак не слабее Z80. По двум причинам. Во-первых, STM32 - это контроллер (MCU), ему и карты в руки управлять периферией, включая дисплей. А во-вторых, я просто ближе с ним знакома, и платы на нем у меня есть, тогда как с Allwinner'ом я никогда прежде не встречалась. Полагаю, что C/C++ для этих целей вполне достаточно, тем паче, что у ARM'ов ассемблер гадкий :).

Тогда отчего __inline__ мне ответил, что реализовать игры от "Sega Genesis" на STM32H7 нереально? Ведь у STM32H7 тактовая частота 480 МГц! И пусть там интерлив и всё такое, но по сравнению с 7.61 МГц это очень много, и даже эмуляция нативного кода не должна понижать производительность на порядок.

Вопрос, чтобы работать в режиме HS, вообще не ставился! Вполне очевидно, что STM32F429 в одиночку с ним не справится. Странная ситуация сложилась только оттого, что режим FS был реализован через порт OTG_HS, а не через OTG_FS, как следовало бы ожидать. Причем, ножки контроллера, относящиеся к OTG_HS и OTG_FS разные! Тогда как DMA может быть использован в обоих режимах. На картинке диалог из CubeMX, где OTG_HS заставляют работать в FS-режиме.

В том-то и дело, что порт OTG_HS способен работать еще и в режиме FS, и тогда во внешнем драйвере он не нуждается. Вот и на плате STM32F429I-DISCO порт OTG_HS был припаян к разъему, но в демо-программе был запрограммирован на режим FS. Но я-то о том сперва не знала, а потому и не додумалась сначала, что надо OTG_HS выбирать, хотя мне FS-режим был нужен.

Действительно, я уже разобралась с ситуацией. Ближе всего к истине оказался пост GenaSPB : в котором он обратил мое внимание на то, что порт OTG_HS может работать в FS-режиме. Тогда как производители плат (преимущественно китайские, которые я люблю за их дешевизну :)) разводят на USB-разъем обычно порт OTG_FS. С ними я прежде ни раз работала и решила, что так оно и должно быть. Непредвиденная ситуация возникла у меня, когда столкнулась с платой STM32F429I-DISCO (на этот раз уже не китайской), где на USB-разъем был выведен на порт OTG_HS. Это явилось для меня неожиданностью, т.к. я точно знала, что эта плата работает в режиме FS, а для режима HS ей нужна внешняя поддержка. Ситуация усугубилась тем, что в CubeMX аббревиатуры FS и HS обозначали не скорость, а имена портов. Потому я настойчиво заказывала FS-конфигурацию, тогда как наружу был выведен порт OTG_HS. Оттого-то CDC на плате STM32F429I-DISCO у меня не работал, хотя отлично работал на китайских платах. Кроме того, негативную роль сыграло и мое знакомство с пресловутым STM32F103 :), у которого порта OTG_HS нет совсем. Отсюда сложилось впечатление, что HS-режим мне никогда не понадобится, из-за чего его особенности я не изучала, оставив без внимания.

Надо не в лупе их крутить, а ДМА раскорчегарить :). По сути вопрос сводится к тому, насколько высоко позволит конкретная SD-карта поднять частоту клока SPI, а не от искусства программиста.

Я тоже попыталась добавить в проект копию cstartup.s52 (это ассемблер), закомметарить в нем строку PUBLIC ??handler_10 и метку ??handler_10: А собственную функцию обработки 16-го прерывания назвать handler_10 Однако от этого появились другие ошибки в другом модуле. Скажите, а на кой вам сдалось прерывание IVEC_RESET_TRANSPONDER ? Ведь со всеми другими векторами такой ошибки нет. От какого-то хоть события это прерывание?

week-заглушки не должны препятствовать переопределению вектора, а вот если служебное слово "week" там пропущено, но возникнет конфликт. И вообще, что это за вектор? vector=0x10 Может быть его вообще переопределять нельзя? Есть еще и такая гипотеза, что нельзя задавать вектор цифрой (0x10). Ныне на компиляторе ARM так делать можно, однако у топикстартера старая версия IAR Embedded Workbench for MRK-II V1.32 где символы следовало брать из "I/O header file". Так оно и в тамошнем руководстве описано:

Из сообщения об ошибке следует не вина библиотеки CLIB, а вина стартап-кода. Например, здесь: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.4\arm\src\lib\arm\cstartup.s Посмотрите что у вас написано в cstartup.s, возможно, что там интеррапт этого вектора там уже задействован. И вообще стартап-код можно писать свой, редактируя фабричный.