dlsh

Верно, для простых случаев компилятор размещает данные в flash. Для случаев чуть сложнее все уходит в RAM. Например для IAR int A_var[10]; #pragma location=0x80000b0 const __root int *pA_var[100] = { &A_var[0], &A_var[2] }; const __root int *pB_var[100] = { &A_var[1], &A_var[3] }; int main() { int B = *pA_var[0]; while(1){ B += *pB_var[B % 100]; } return 0; } Имеем размещение .......... main 0x800'02a1 0x24 Code Gb main.o [1] pA_var 0x800'00b0 0x190 Data Gb main.o [1] pB_var 0x2000'0000 0x190 Data Gb main.o [1] ............. т.е. т.к. для pA_var явно указана flash то он там и лежит, а для pB_var этого явно не указано и компилятор размещает этот объект в Data. C атрибутом __flash согласен не совсем корректно, но он очень хорошо демонстрирует то что требуется. Т.е. нужно аналогия __flash для ARM в Keil чтобы можно помечать объекты которые нужно разместить в test.zip Так указал же выхлоп компилятора ../File.c(163): error: 'B' causes a section type conflict with 'A'

const - размещает объекты в секции Data. const - не указывает где размещать, а определяет свойство неизменяемости. У keil дано решение для одного объекта, как только появляется второй с указанием размещения в той же секции то возникает конфликт размещения с ошибкой. В sct Sec_Const закоментирован.

Приветствую коллеги. Элементарная вроде задача - размещать некоторых структур/данных в rom. Для Keil не могу найти решения. В IAR для этого есть атрибут __flash. В Keil вроде как для этой цели можно было бы приспособить атрибуты __attribute__((section(".rodata"))) Однако при попытке собрать проект где идут друг за другом объявления типа const int A __attribute__((section(".rodata"))) = 1; const int B __attribute__((section(".rodata"))) = 2; Выдает ошибку ../File.c(163): error: 'B' causes a section type conflict with 'A' Введение своей секции в.sct файл картины не меняет: ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x08000000 0x00020000 { ; load region size_region ER_IROM1 0x08000000 0x00020000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) .ANY (+XO) *.o(romdata) } ;Sec_Const 0x08001FFC 0x000004 { ; Const.o(SecConst) ;} RW_IRAM1 0x20000000 0x00014000 { ; RW data .ANY (+RW +ZI) } } Как объяснить компилятору что располагать в секции данный можно последовательно? С директивой #pragma вообще ничего подходящего не нашел...

Детектор теплопроводности (ДТП) может неплохо дополнить измеритель скорости потока с этим согласен, однако это уже усложнение реализации задачи в целом. В то же время тов. П.П.Кремлевский в Расходомеры и счетчики количества.Спарвочник. в п.20.2 стр.377 явно утверждает что цель измерения от 0 м/с достижима и без ДТП. В скользь упоминает о требованиях и особенностях предъявляемых к конструкции датчика. Однако опыт показал что этих упоминаний /пожеланий не достаточно, нужны в качестве отправной точки хоть какие то расчетные данные и количественные зависимости.

Сразу с опытов и начали с готовым датчиком, только результат оказался на таких малых скоростях у водорода (да и воздуха тоже) ни какой.

Дела... век назад, ученые рассчитывали и результаты бились с практическими результатами с достаточной точностью для разработки устройств, а сейчас уже точность стала никакой. Все равно спасибо, буду дальше копать/проверять.

Если очень кратко то как максимум описать тепловое поле в трубе диаметром 10 мм с помещенным внутрь трубы нагревателем с определенными допущениями. В трубе поток воздуха/водорода от 0 до 3 см/с. Изначально задача - измерить скорость указанного потока в данной трубе. Метод предложенный Кулебакиным как отправная точка для разработки датчика. Статья Штейнгауза неплохо описывает последовательность расчета. Решил повторить расчет применительно к своей задаче, но на коэффициенте теплопередачи по Кингу дело застопорилось. Если кто в эту тему (термодинамику/МКТ) глубоко погружен, то прошу помощи.

Доброе время суток. Изучаю труды проф. МЭИ В.С.Кулебакина статья Измерение расхода пара методом нагретой проволочки 1936 года. На странице 45 дается ссылка на труды Кинга в части коэффициента теплопередачи, а именно: В указанной статье Mathematical theory of the convection of heat King не наше определение данного коэффициента, и прошу помощи сообщества в определении членов знаменателя правого части уравнения, а именно: f0p4, lv0,u. Измерение расхода пара методом нагретой проволочки at4510.pdf

Полностью поддерживаю относительно P-CAD. Ни в AD ни в KiCAD перемещать десигнаторы пинов нельзя. Однако плюшек у AD в части дизайна и приемов работы больше.

Пункта ЕСКД указывающий явно на ошибку нет, но есть ГОСТ 2.111-68 с п.4.3 а именно: далее есть ГОСТ 2.111-68 с п.6.9: а далее указываются заложенные схемы в архив с оформлением обозначения выводов справой стороны и указывается на ГОСТ 2.111-68 с п.6.9. Круг замкнулся, формально замечание корректно. Начинаешь поднимать исходники схем где есть оформление справа, в них реальные обозначения скрыты и продублированы обычным текстом. В общем решение проблемы для AD понятно, расположение компонентов так, чтобы выводы были только горизонтальны.

Доброе время суток. Есть ли возможность в AD21 pin.Designator или pin.Name переместить относительно пина так, чтобы он размещался с правой стороны? Вопрос возник при прохождении н.к. Считается что по ЕСКД обозначение должно быть с правой стороны. Потратил несколько часов времени, не получилось. Остается только совсем уж кривой путь - заменить эти номера на текстовые поля. Кто как решает эту проблему размещения обозначения пинов?

Нашел где собака порылась. В Quartus Assigments->Settings->Compiler Settings->Advanced Settings->Auto RAM Replacement установить в On. Без включения этой опции ни какие атрибуты не помогли.

Интересно... попробую/почитаю. Спасибо за направление.

В фильтре на SV есть описание RAM как module coef #(parameter DATA_WIDTH=24, parameter ADDR_WIDTH=9, parameter FILE_NAME_LPF) ( input wire [(DATA_WIDTH-1):0] data, input wire [(ADDR_WIDTH-1):0] addr, input wire we, input wire clk, output wire [(DATA_WIDTH-1):0] coef_rom ); reg [DATA_WIDTH-1:0] rom[2**ADDR_WIDTH-1:0]; reg [(DATA_WIDTH-1):0] data_out; assign coef_rom = data_out; //0..511 - blackman-harris 511 order 24-bit coeff //0..511 - blackman-harris 511 order 16-bit coeff //0..511 - squared 511 order 16-bit coeff initial $readmemh(FILE_NAME_LPF, rom); always @ (posedge clk) begin data_out <= rom[addr]; if (we) rom[addr] <= data; end endmodule При сборке проекта Q12.1 офрмляет данный модуль на регистрах без использования памяти. Что интересно - данный фильтир один в один использовался в другом проекте, правда был встроен как часть qsys. B в нем Quartus честно заменял его на ячейки M9K. Кристал в обоих проектах выбирался EP4CE55. Может кто встречался с подобным? Возможно есть какие то доп. настройки в проекте?

Если не затруднит, выложите ссылки с али на ответную часть разъемов (DATA1-DATA3 I/O с Zynq, J3, J5, J7? J8) для обсуждаемой платы.

Согласен что так лучше для конечного пользователя, но не проще в реализации. В AD нет возможности через опции Variant сгенерировать на печать несколько различных схем... Это думаю относится к навыкам читать схемы оформленные по ЕСКД.

Интересно, спасибо. Буду пробовать.

Необходимо привскрыть via от маски которые расположены не под компонентами со стороны Bottom. Не могу придумать правило для Query. Прошерстил Query Language Reference, можно получить координаты и via и компонента, но ничего рядом нету чтобы перекрываемость областей объектов. Может кто подсказать куда копать.

Интересно, спасибо попробую эти пути.

Понял, спасибо за комментарии. Тоже начал писать скриптик для синхронизации двух проектов по части пинов.

В продолжении Экспорт пинов из Altium designer в Altera Quartus II Есть ли у кого автоматизированный способ импорта/экспорта из/в Quartus информацию о выводах в связке с программами разводки печатных плат? Каким образом вы автоматизируете этот процесс? Не может же быть, что бы данный процесс не имел рабочей автоматизации.

Также интересен данный вопрос. Если кто знает прошу подсказать рабочий путь экспорта/импорта AD <-> Quartus Prime. Что удалось накопать самому. Есть подробное описания от AD каким образом они видят этот процесс. Может кто видел плагин для конвертации форматов между данными ПО. Однако либо они его не проверяли или что то не так. В чем суть проблемы. AD делает экспорт информации через Pin Mapper в *.csv файл с заголовками Pin Designator,Net Name,Display Name,IO Bank,IO Standard,Slew Rate,Drive Strength,IO Pin,Vref Pin,CLK Pin,Config Pin,Special Pin,Group,Differential Pair Pin Designator,Net Name,Display Name,IO Bank,IO Standard,Slew Rate,Drive Strength,IO Pin,Vref Pin,CLK Pin,Config Pin,Special Pin,Group,Differential Pair где Pin Designator - номера пинов вида 1,2,3... Net Name - имея подключенной цепи в AD. Quartus -> Pin Planner, на сколько я понял, умеет только экспортировать пины в *.csv файл с заголовками, а импортировать он не может. To,Direction,Location,I/O Bank,VREF Group,Fitter Location,I/O Standard,Reserved,Current Strength,Slew Rate,Differential Pair,Strict Preservation,Special Function,Live I/O Check Error где To - наименование цепи, Direction - Input/Output/Bidir Fitter Location - пины вида PIN_1, PIN_2, PIN_3 .... Очевидно что AD при попытке подсунуть ему файл из Pin Planner выдает ошибку и не понимает. В сам Quartus можно загрузить через Assignment Editor пины через *.csv файл, НО формат там свой, а именно To,Assignment Name,Value где To - наименование цепи, Assignment Name - Location Value - PIN_1, PIN_2 ... Вырисовывается запутанная картина требующая плагины переконвертации одного формата в другой с использованием, как я понимаю, некого словаря перекодирования как заголовков таблиц так и соответствие наименований цепей. В общем, если у кого есть workflow то прошу указать. А каким образом вы автоматизируете этот процесс?

По OpenOCD чего достиг: Скачал OpenOCD-20200729-0.10.0, запустил openocd.exe -f .\..\share\openocd\scripts\interface\stlink-v2.cfg -f .\..\share\openocd\scripts\target\stm32f7x.cfg -c "init;" Подключаюсь telnet telnet localhost 4444 пытаюсь включить логер tpiu config internal "D:\Documents\Project\log.txt" uart off 216000000 itm port 0 1 В ответ все тихо, никаких ошибок, но файл "D:\Documents\Project\log.txt" не создается... Хотя команда reset работает... Как бы его запустить этот логер.

Подниму тему. Необходимо вести лог с вывода SWO через J-Link(или ST-Link) в файл. J-Link SWO Viewer (Serial Wire Viewer) работают, но не понятно сколько по времени они могут вести логирование (нужно хотя бы сутки - размер текстового лога при этом оценивается как 100-200 МБайт). bragswv.exe - вылетает с ошибкой. SWOAnalyzer.exe - сохраняет какую то статистику, но самих логов нет. На хабре нашел статью вывод логов через tpiu, но запустить на windows 10 не смог. Вроде простейшая задача, но решения в легкую не находиться. Поделитесь кто находил решение по записи лога в файл с SWO. (Подключить USB-UART к SWO нет возможности, есть ST-Link/J-Link).

Тоже так думал, однако Keil считает иначе. void *malloc( size_t sizemem ) __attribute__((malloc)){ .... } ../../Source/main.c(547): warning: GCC does not allow 'malloc' attribute in this position on a function definition [-Wgcc-compat] void * malloc( size_t sizemem ) __attribute__((malloc)){ ^ 3 warnings generated. compiling main.c... linking... .\STM32F777\STM32F777.axf: Error: L6200E: Symbol malloc multiply defined (by lto-llvm-bde691.o and malloc.o). /////////////////////////////////////////////////////////////////////////////////////////////////// void *MyMalloc( size_t sizemem ) __attribute__((malloc)){ .... } ../../Source/main.c(547): warning: GCC does not allow 'malloc' attribute in this position on a function definition [-Wgcc-compat] void *MyMalloc( size_t sizemem ) __attribute__((malloc)){ ^