Шаманъ

А реально этим пересобрать arm-none-gdb? Хочу собрать с этим https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054 патчем.

Интересно, рисование через DMA2D занимает не намного больше времени, чем копирование нарисованного участка. Например, рисование 10мс, копирование 13мс, или рисование 3мс, копирование 2.3мс. В итоге получилось, что зачастую проще (а иногда и быстрее) тупо перерисовывать все каждый раз, чем поделить на участки и сохранять промежуточные результаты в разных буферах, чтобы не рисовать одно и то же. И все же DMA2D весьма крут! Признаю, что был не прав, называя его "убогим" в начале темы :rolleyes: (хотя некоторые простые модификации/дополнения были бы ну очень полезны). Опробовал более-менее реальный вывод достаточно динамичного интерфейса - спектр/водопад на 800х330точек, поверх него полупрозрачная сетка со шкалами + остальной интерфейс рядом 800х150 (фон с анимацией+два слоя поверх) + поверх всего этого небольшие (60х480) анимированные части интерфейса с альфа каналом в независимых буферах в форматах ARGB8888 и L8. TFT работает с частотой кадров 29к/с, процессор 216МГц, память соответственно 108МГц. В начале экспериментов немного разочаровался, ибо FPS прорисовки выше 10..14 не подымался, но потом "углубился в проблему" в итоге после "борьбы за FPS" имею рисование варианта интерфейса со спектром за 19.6мс (~51fps), загрузка процессора при 29к/с 25..26%, то же с водопадом рисуется за 17мс (~58fps), загрузка процессора при 29к/с 4.5%. Я немного удивлен цифрами более 50fps :08: Получив такие цифры захотелось большего (не в плане FPS, а нарисовать больше, сохранив FPS прорисовки анимированных областей экрана выше частоты обновления ТФТ - 29к/с). Скорее всего придется рисовать в двух разноприоритетных потоках, можно конечно забить на незначительные "визуальные эффекты", но я не люблю компромиссы :). В этом вопросе мог бы помочь второй слой LTDC, но увы ему полосы памяти на больших экранах маловато. В итоге в два слоя он при частоте обовления ТФТ больше чем 22к/с (один слой RGB565 второй ARGB4444) у меня не пошел, и то даже при такой низкой скорости иногда глюк проскакивают.

Логичнее вывести сигнал напрямую без всяких прерываний через блок сравнения 2, который собственно и запускает АЦП, правда вывести можно не на любой вывод. Подозреваю, что два АЦП используются для одновременного измерения напряжения и тока, потом считается мощность :) Насколько это корректно сделано не подскажу, ибо всеми этими HALами, SPLами не пользуюсь - напрямую с регистрами проще и понятнее все выходит.

А что второй канал второго таймера от которого АЦП запускается никак конфигурировать не нужно? Или здесь не вся инициализация? АЦП то запускается не по переполнению таймера, а по событию от второго канала захвата/сравнения.

Приветствую всех! Обнаружил такую засаду (которая оказалась частично документирована в errata на этот камушек). Началось с того, что внесение в код некоторых изменений (не связаны с работой АЦП) приводило к росту шума АЦП где-то в 6 раз :1111493779: . Из-за чего устройство переставало нормально работать. При этом код этот к АЦП никакого отношения не имел :), ну а закончилось, когда изменение кода в той части, которая никогда не выполняется дало тот же результат :laughing: При этом единственное, что изменилось в работающей части кода это некоторые части кода сдвинулись на 4 байта. После этого подозрения упали на модуль флеш памяти и ART. Отключение "префетчера" полностью решило вопрос с шумом АЦП. В принципе примерно то же описано в AN4073. Собственно это вступление, которое может кому-то будет полезно :) Теперь вопрос - в более старших моделях есть специальные биты ADCDC1/ADCxDC2 которые позволяют эту проблему пофиксить и оставить префетчер включенным, в 407х их нет. В принципе мне хватает производительности и с отключенным префетчером, но все же, так сказать на будущее - кто-то боролся с этим безобразием в 407м? Если да, то какой был результат и как он был достигнут (если не секрет)?

Тогда у меня +- то же самое. У меня нет ST-Link - я его не использовал никогда. Использую OpenOCD + на FT2232 интерфейс. Скорость стоит 8МГц, но на 2МГц с такой же скоростью шьет. Кстати верификация очень бодренько идет, поле того, как я OpenOCD немного "подпилил" - около 400..500кБ/сек, а вот заливка около 15кБ/сек (используется полный JTAG). stm32f4 и stm32f1 шьются побыстрее, правда ненамного (раза в полтора-два).

Приветствую всех! Народ, а с какой скоростью у этого камня шьется флеш? А то что-то уж больно медленно прошивается (около 15кБ/с).

Рекламки раньше находились, а остальное типа по NDA. Но в реальности ходило по сети несколько документов. У меня были все (в свое время засматривался на него), если интересно могу прислать :)

Да, это единичное изделие для себя. В коммерческом девайсе, такого вопроса не возникло бы :) Так уже впаял :).

Ну Y5V у меня где-то были на 2.2мкФ. Это было первое, что я сделал :) Надеялся, что там таки "не меньше", но увы. Тоже подумал про это. С точки зрения возбуда с 10мкФ все должно быть хорошо, остаются нюансы типа тока заряда и времени заряда... P.S. Нашел у себя еще 8шт. с непонятно каким диэлектриком (скорее всего таки Y5V) поставлю их наверное, посмотрю что выйдет...

Геннадий приветствую! Я это понимаю, желания потом их выпаивать и запаивать другие нет, с другой стороны нужных нет и появиться они смогут у меня не быстро. Кстати, а какая керамика туда пойдет (я так думаю что-то типа X5R/X7R нужно)?

Собственно вопрос в заголовке - можно ли вместо двух конденсаторов 2.2мкФ поставить два по 10мкФ X5R?

Кроме уже сказанного я бы подумал на предмет временного вырезания всего, что может быть вырезано из программы, с контролем стабильности с каждым "урезанием". Смысл заключается в том, чтобы сузить зону поиска до минимума. Почти уверен, что часть прерываний можно запретить, некоторые куски кода выкинуть и т.п.

Когда экспериментировал, то с RGB565 форматом в background слое DMA2D_BGCOLR у меня не просвечивал. За информацию по AL44 спасибо :)

Поюзал я более-менее интенсивно отладку под Cortex-M7 (лаунчпадовский arm-none-eabi-gdb + OpenOCD). Выяснились некоторые косяки Netive Debug расширения, а потом вышло обновление VS Code, а с ним обновились cpptools ( https://marketplace.visualstudio.com/items?...vscode.cpptools ). После обновления мне удалось сконфигурировать cptools для работы с arm-none-eabi-gdb (без использования костыля в виде Native Debug). Собственно изменения касаются пункта 5 моей инструкции (см. выше). Native Debug теперь не нужен), launch.json выглядит так: "configurations": [ { "name": "OpenOCD & gdb", "type": "cppdbg", "request": "launch", "program": "${workspaceRoot}/Debug/Main.elf", "args": [], "stopAtEntry": false, "cwd": "${workspaceRoot}", "environment": [], "externalConsole": false, "logging": { "engineLogging":false, "moduleLoad": true, "exceptions": true }, "windows": { "MIMode": "gdb", "miDebuggerPath":"c:/arm/bin/arm-none-eabi-gdb.exe", "setupCommands": [ {"text":"-target-select remote localhost:3333"}, {"text":"-interpreter-exec console \"monitor reset halt\""} ], "launchCompleteCommand": "exec-continue" } } ] } "Под себя" нужно поменять miDebuggerPath и program, также можно изменить имя конфигурации name . Работает очень хорошо! Кроме того после обновления намного лучше работает IntelliSense (почти как в "большом" VS). Пока от VS Code у меня самые хорошие впечатления.

AT070TN92 RGB Сама она голая, но у меня есть тачскрин к ней (емкостной) и я сваял контроллер для него на stm32f103. Мне достаточно 2х касаний, в принципе можно и больше сделать. Пять для такой маленькой панели наверное уже перебор. Это в LTDC, а в DMA2D такого нет, а было бы хорошо, если бы был - я про это. В DMA2D просвечивает только при комбинировании двух слоев, один из которых сплошной фон.

Сделал, проверил. Запросы правда за это время немного "подросли" - проц. stm32f746, 8М SDRAM и 800х480хRGB565 TFT. В общем нормально DMA2D работает. Самый неприятный момент это адресация в DMA2D - не поддерживается отрицательное смещение между строками. Из-за этого скроллинг можно сделать только в одну сторону, кроме того заливки масками тоже отменяются. Еще блендер в DMA2D несколько убогий. Если бы добавили третий канал с фоном (сплошной заливкой) то некоторые вещи было бы намного удобнее делать. Да, может кому будет интересно - рисование битмапа 534х137 с преобразованием из L8 в RGB565 занимает: 1. Через DMA2D для простого рисования 1.29мс (если пересчитать на весь экран, то выходит 150fps однако) 2. Через DMA2D для наложения с прозрачностью 3. Через CPU с выключенным кэшем 12.8мс 4. Через CPU с включенным кэшем 4.2мс Это для рисования прямо в видеобуфер, параллельно вычитываемый через LTDC, частоте CPU 180МГц, памяти 90МГц, картинка во флеше. Также потестил как поменяется скорость для 1го варианта (см. выше) если картинка лежит не в флеше: 1. Для картинки в SRAM1 скорость такая же как из флеша - 1.29ms. 2. Для картинки в том же банке SDRAM - 5.03мс 3. Для картинки в другом банке SDRAM - 4.10мс Да, на последовательной записи CPU=>SDRAM получается 54Mtps, рандомные чтение/запись 5.6Mtps, в разных банках 6.6Mtps. Это без кэша данных и с работающим LTDC. Можно сказать я почти доволен :) Огорчили китайцы - панель должна была быть с бОльшим углом обзора снизу, поэтому я ее предусмотрительно перевернул, а оказалось, что у нее лучшие углы обзора сверху :laughing: ... надо будет поискать какую-нить панель с более "правильными" углами обзора.

Приветствую всех! Собственно вопрос в заголовке темы - у кого сколько получается скорость программирования флеш-памяти через OpenOCD и простой интерфейс на базе ftdi2232d (что-то типа olimex-arm-jtag)? А то как-то уж больно медленно у меня получается (около 12КБ/с)...

Ну это все очень просто делается. Для начала надо прочитать доки на ассемблер, потом: asm56300 -A -OCEX,MEX,MU,NOMD,MC -Bxxx.cld -Lxxx.lst xxx.asm cldlod xxx.cld > xxx.lod Первая команда скомпилирует Ваш xxx.asm в объектный файл xxx.cld и создаст листинг xxx.lst. Вторая из .cld файла сделает .lod, который очень просто распарсить и скормить внутреннему загрузчику по SPI, например. Я не в курсе, что там у EVM есть на борту куда можно "загрузить" и какие инструменты с ней поставлялись для этого. Могу предложить путь которым в свое время я воспользовался: 1. Делаем простую программу для DSP56k которая зажигает светодиод. 2. Пишем на ПК программу которая способна прочитать .lod и скормить его встроенному загрузчику DSP56k, например, по SPI. 3. Используем (2) чтобы загрузить (1) в ОЗУ DSP56k и убедиться, что (1) работает. Как это осилите пол дела сделано :) В принципе для поиграться хватит и этого, если же хочется большего, то после этого: 4. Пишите загрузчик который будет принимать данные с ПК и записывать их в Флеш-память на плате. 5. Модифицируете программу (2), чтобы она загружала в ОЗУ DSP56k с помощью встроенного загрузчика программу (4), а потом скармливала ей тот файл который Вам нужно записать в Флэш-память. Вот собственно и все - теперь у Вас есть все, чтобы Вы могли Вашу программу записать в Флэш-память, а из Флэш-памяти как параллельной, так и последовательной DSP5672х умеет грузится сам (DSP56307 только из параллельной). Также у Вас есть инструмент, чтобы загружать программу прямо в ОЗУ DSP56k и стартовать оттуда. Альтернативный вариант - прошиваете флеш-память отдельно (не уверен, что на EVM это возможно, но если плату делать самостоятельно, то вполне можно сделать и так), тогда никакие загрузчики не нужны. Если Вы про отладку через JTAG, то ничего не подскажу. В те времена, когда я начинал отладка стоила дурных денег, сейчас вроде есть версия (весьма древняя) OOCD, с поддержкой DSP56k, но работало/работает ли это и насколько хорошо не подскажу, т.к. не пользуюсь. Я у себя даже JTAG не разводил - мне хватает диагностического вывода/светодиодов. Серия DSP56K умерла через пару лет после выхода двухголовых DSP в серии DSP567xx :( Тогда еще это был Freescale. Если что-то конкретное нужно из древних инструментов/доков по этой части могу выложить куда-нить или отправить по мылу. P.S. Наверное нужно попросить модераторов перенести последние сообщения в DSP раздел :rolleyes: ...

Можно :) Что именно интересует?

Я когда-то давно Эклипс пробовал и он мне не понравился. С тех пор так и сижу на полноценном MSVC, с GCC я его "подружил" без особых проблем, но отлаживаться приходилось голым gdb. В принципе ничего сложного в этом нет, да и требуется серьезная отладка не так уж часто, но когда у отладчика есть ГУЙ это все же прилично комфортнее.

ОК. Тогда начнем с того, как прикрутить: 1.Собственно скачать и установить VS Code 2.В VS Code для подсветки синтаксиса, автокомплита, подсказок и т.п. нужно добавить расширение cpptools ( https://marketplace.visualstudio.com/items?...vscode.cpptools ). Это расширение может работать с gdb, но только для отладки на ПК. Поэтому отладчик в нем мы конфигурировать не будем. 3.В этом расширении есть какой-то затык - оно должно работать сразу, но без пинка не выходит. Чтобы заработало нужно в каталоге .vscode (он содается VS Code внутри главного каталога Вашего проекта) создать файл c_cpp_properties.json следующего содержания: { "configurations": [ { "name": "ARM", "includePath": [ "C:/Include", "${workspaceRoot}/Include" ], "browse" : { "limitSymbolsToIncludedHeaders" : true, "databaseFilename" : "${workspaceRoot}/.vscode/.browse.VC.db" } } ] } Пути к заголовкам указываются абсолютные. Для задания пути относительно главного каталога проекта можно использовать ${workspaceRoot} После этого расширение начинает нормально работать. 4.Чтобы работала компиляция нужно создать файл "задач" (в каталоге .vscode). У меня он выглядит так (установлены gcc/gdb/mingw), что-где должно быть понятно: { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "0.1.0", "command": "sh.exe", "isShellCommand": true, "args": ["-c"], "showOutput": "always", "suppressTaskName": false, "tasks": [ { "isBuildCommand": true, "suppressTaskName": true, "taskName": "make", "args": ["make"], "isWatching": false, "problemMatcher": { "owner": "c", "fileLocation": ["relative", "${workspaceRoot}"], "pattern": { "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$", "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5 } } }, { "isBuildCommand": false, "isTestCommand": true, "suppressTaskName": true, "taskName": "flash", "args": ["make flash"], "isWatching": false, }, { "taskName": "clean", "suppressTaskName": true, "args": ["make clean"] }, { "taskName": "rebuild", "suppressTaskName": true, "args": ["make clean all"], "isWatching": false, "problemMatcher": { "owner": "c", "fileLocation": ["relative", "${workspaceRoot}"], "pattern": { "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$", "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5 } } }, { "taskName": "oocd", "suppressTaskName": true, "args" : ["c:/openocd-0.9.0/bin-x64/openocd.exe -f interface/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg -f cfg/debug.cfg"] } ] } После этого сборка может быть запущена через Ctrl+Shift+B (сочетание можно сменить на привычное, я поставил более привычное мне Shift+F8) или через "строку команд" или как оно правильно называется у них - вызывается по Ctrl+Shift+P. Прошивка запускается через команду тестирования Ctrl+Shift+T, естественно сочетания можно сменить. 5.Прикручиваем gdb. Для этого нужно добавить расширение Native debug ( https://marketplace.visualstudio.com/items?...=webfreak.debug ). Потом нажать на кнопку Отладки на боковой панели, потом на шестеренку вверху справа и выбрать GDB в списке. Откроется файл конфигурации запуска GDB (он находится в .vscode/launch.json). У меня он выглядит так: { "version": "0.4.2", "configurations": [ { "name": "Debug gdb", "type": "gdb", "request": "attach", "executable": "${workspaceRoot}\\Debug\\Main.elf", "target": "localhost:3333", "cwd": "${workspaceRoot}", "gdbpath": "C:\\arm\\bin\\arm-kgp-eabi-gdb.exe", "remote": true, "autorun": [ "load ./Debug/Main.elf", "break main", "monitor reset" ] } ] } Назначения полей думаю понятны по их именам (кроме того при редактировании конфигов силами vs code выдаются всплывающие подсказки). Записываем файл и вот собственно и все - после этого должна работать отладка/сборка/прошивка/редактирование. Перед отладкой нужно запустить OOCD, сделать это можно сконфигурированной нами командой task->oocd, можно и вручную. 6.Для наведения красивостей можно установить пакет иконок и поправить под себя раскраску. Ну и дальше другие расширения "по вкусу". Впечатлений пока мало - времени прошло мало, да и сейчас занят немного другим. Изначально я ставил ее с другой целью - иногда пишу под DSP56300 и как-то ни один редактор, хоть с плагинами, хоть без не подсвечивает нормально синтаксис ассемблера DSP56300, и не предлагает autocomplete даже в "тупой" форме (когда для подстановки предлагаются просто все идентификаторы из текущего документа). VS Code из коробки этого тоже не предлагает, но за пол дня я разобрался как и написал к нему расширение с подсветкой синтаксиса и некоторыми фичами по вводу/форматированию кода. Плюс autocomplete работает (пусть и в "неинтеллектуальном" виде, но в ассемблере это очень удобно). Интересно, что для написания расширения ничего кроме самой VS Code не потребовалось :) Нет, тормозов нет. Да. Нормальная студия это делает лучше, хотя для использования годен и такой вариант (правда проект на чистом С, что будет на плюсах не знаю). c/c++ расширение находится в стадии "превью" и его активно допиливают, что дает надежды на "счастливый финал". Я отключил. На счет отправляет ли в таком виде не интересовался - у меня ничего особо секретного нет :) Вроде расширения могут отправлять свою "телеметрию" и ее нужно отключать отдельно. Как работает с gdb понравилось. Сам редактор несколько аскетичный на первый взгляд, но в нем все работает и в нем, в принципе, все есть (по крайней мере пока ничего такого, чего бы критически не хватало не обнаружил). При необходимости все настраивается, делается правда это не через меню и диалоги, а редактированием конфига, который в виде json файлов. Понравилось, что в отличии от полноценной студии vs code не загаживает каталог проекта кучей своих файлов - все свое она хранит в одном каталоге .vscode Да, есть подсветка синтаксиса shell, makefile и даже matlab (я уже не говорю про более популярные).

Тест памяти делали? Как по мне, то первое, что нужно сделать это прогнать хотя бы минимальный тест SDRAM, чтобы иметь хоть какую-то уверенность, что она работает нормально. И еще питание гляньте не просаживается ли. Ведь при включении дисплея потребление и памятью и МК подрастет - может его тупо не хватает, вот он и сбрасывается.

Приветствую всех! "Прикрутил" к Visual Studio Code gcc/gdb (для ARM). Все весьма недурно работает (отладка через OOCD). Довольно удобно, компактно и работает шустро. Кому-то интересно? Рассказывать как прикрутить?

Как по мне, то обычный Fractional-N синтезатор с компенсацией помех дробности. Применялась довольно широко - помню в каких-то генераторах НР, в приемнике Racal 1792 (вот структурная схема примерно то же, что и у Вас http://www.aholme.co.uk/Radio/SynthRA1792.gif, на эту тему есть куча древних патентов )