Xenia

Инсталлятор под Win так называться не может: l_cembd_iqd_p_1.0.4.036.exe а может только так: w_cembd_iqd_p_1.0.4.036.exe

А известно ли вам точное название файла, который вы ищите? Если бы вы могли его называть, что я бы возможно вытащила его с сайта Intel, если он там еще сохранился. Пока же мне сложно угадать его название, т.к. в интернете встречаются упоминания по меньшей мере о 3-х версиях: ISSM_d1000_2015.3.022 ISSM_d1000_2015.3.024 ISSM_d1000_2015.4.036 Скорее всего, и название нужного вам файла на эти имена похоже. Однако поиск на "ISSM_d1000_2015.4.036.exe" результата не дал.

В том и прелесть :) проекта ad9834_drv.zip, что для обращения к AD9834 по SPI используется всего одна функцию - SPI_WriteDDS(), перед употреблением которой требуется один разок вызвать функцию инициализации SPI-периферии - SPI_Init(). Реализация этих обеих функций вынесена в другой модуль spi.c. При этом оказывается, что только код spi.c является архитектурно зависимым, а код ad9834.c всегда один и тот же. Это позволяет написать "самодельную" функцию SPI_Init() которая бы устанавливала частоту SPI-клока в 1 МГц и передачу по переднему фронту. А вторая функция SPI_WriteDDS() - просто ожидание готовности (окончание предыдущей передачи) и запуск на передачу содержимого буфера. Очевидно, что эти две функции можно написать для любой архитектуры - не только для AVR (нативный код там именно такой), но и для дешевого STM32, где функции такого рода давным-давно написаны.

Для того, чтобы что-то искать, нужно понимать предмет поиска. Тогда как в данной теме вопрос стоит не о том, чтобы собрать как можно больше проектов, в названии которых есть слово "AD9834", а найти среди них тот, что по-проще, который не только можно было бы бездумно скомпилировать, но и хотя бы в общих чертах понять новичку, который до этого вообще никаких микроконтроллеров еще не программировал. Поэтому мой совет (использовать проект ad9834_drv.zip с этого форума) был обдуманным советом: я сама его когда-то выбрала из нескольких десятков именно благодаря его простоте (всего два файла = ad9834.c + ad9834.h), а потому и советую. Тогда как вы, по-видимому, вовнутрь проекта, который рекомендовали, даже не заглядывали. А между тем в нем 218 файлов, среди которых есть и поддержка графического дисплея с тачскрином, и файловая система на SD-карте, и ЦАП AD5310, и счетчик реального времени, и много чего еще (оттого и в проекте так много файлов). Изолировать из этого проекта часть, относящуюся к AD9834, не так-то просто, а без вникания в логику этого проекта, так и совсем невозможно, а тем более новичку. Если я вас спрошу "для какого микроконтроллера написан рекомендуемый вами проект?", так вы и не ответите, т.к. даже этим вы, скорее всего, не поинтересовались, а лишь продемонстрировали свою способность прочесть 1-ую страницу, которую вам выдал Google. На сайте CQHAM.ru искать коды без толку - радиолюбители обычно используют DDS для синтеза несущей частоты в своих радиоконструкциях, но схематику и программный код, как правило, заимствуют в других местах, мало что в том коде понимая. Я уже имела опыт переговоров с ними и была крайне разочарована их результатами. Хотя признаю, что там есть и выдающиеся проекты вроде того, что сейчас разрабатывается на основе STM32H7 (проект "Малахит-DSP"), где уровень автора проекта очень высок. А на AD9834 когда-то был основан проект "Маламут" (я с его автором даже в переписку вступала), но потом он заменил в своем проекте AD9834 на AD9852. P.S. Тем не менее, топикстартер этой темы скрывает тип своего контроллера и даже умалчивает о том, выбрал ли он его окончательно или находится в раздумьях. Честно говоря, не хочется помогать таким людям, которые просят помочь им "запрограммировать МК", при этом не понимая, что прежде должны называть тип этого МК. Т.е. сложилось впечатление, что это просто студент, которому надо лишь побыстрее спихнуть лабораторную работу, как можно меньше утруждая свои мозги.

Зря вы этот проект новичку советуете - он сложный.

На нашем форуме уже есть тема "ad9834" здесь: Я сама, когда код для AD9834 писала, использовала оттуда ссылку ad9834_drv.zip Там код написан под ATMega8515 и мне прошлось его переделывать только по части интерфейса SPI, т.к. у меня был контроллер ATxmega128A1, который хоть и AVR, но очень сильно отличается от ATMega8515 по части управления периферией. А микросхему AD9834 покупала сразу в виде готового модуля у китайцев вот такого типа: https://aliexpress.ru/item/32790171360.html на нем уже генератор тактовой частоты на 75 МГц установлен и прочая обвязка, включая ВЧ-коннекторы. Точно так же можно купить отдельно плату с контроллером, хотя бы Arduino (таких очень много продается), а потом "сломать" :) ее, переписав ей прошивку на свою. Если проект учебный, то лучше выбрать плату с USB-портом, чтобы напрямую с компьютером можно было бы стыковать. Иначе управление превратится в отдельный проект. Правда у китайцев можно приобрести плату с AD9834, где уж стоит контроллер (STM32F103) c USB-коннектором: https://aliexpress.ru/item/4000687606434.html только тогда вам никто не поверит, что код сами писали :).

Спасибо за совет! Хотелось мне спросить, чем можно заменить 1117-ый, чтобы меньше напряжения на нем падало, но постеснялась :). Однако TLV703 китайцы не продают :), а мне бы хотелось дешевого решения. А задача у меня простая и очень часто встречающаяся - девайс, питаемый за счет USB-порта компьютера, которому нужны стабильные 3.3V. Именно в этом случае традиционно ставят AMS1117-3.3V. К сожалению, на некоторых компьютерах (не всех) напряжение на USB-разъеме, сразу же при подключении к нему девайса, садится с 4.8-5.0V до 4.4-4.5V, что приводит к тому, что на выходе AMS1117 вместо 3.28-3.30V имею 3.26V. Казалось бы потеря не велика (всего 0.3V), но появляются большие пульсации, которых при 5-вольтовом питании не было. Т.е. несмотря на то, что напряжение он все-таки понижает, с функцией фильтрации он очевидно не справляется. Полагаю, что разница 37 мВ для моих целей было бы слишком жирной :), а было бы достаточно даже 500 mV. Нет ли у вас таких LDO на примете, но так, чтобы корпус был как у AMS1117?

А есть такие LDO, которые способны фильтровать при разнице между входным и выходным напряжением всего в 0.3V? Обычно даже 1V такой разницы бывает недостаточно.

Если это Ардуино, то очень просто - ищите для нее Google'ом код для интерфейса того же типа. Например, I2C. А чтобы скомпилировать ее и прошить нужно проинсталлировать Студию, это здесь дают: https://www.microchip.com/en-us/development-tools-tools-and-software/microchip-studio-for-avr-and-sam-devices Правда говорят, что у последней версии компилятор сменился, а потому я ее сама пока не пробовала. Как использовать Студию и как заливать прошивку в микроконтролер, в интернете информации много, и она более подробная чем та, что вы можете раздобыть на форуме. Однако начать хорошо было бы с конца - вывода результатов в том виде, в котором вам было бы возможно их обозревать. А то прочтет ваш контроллер на плате Ардуино данные с магнитометра и что дальше будет с ними делать? Последний вопрос хорошо бы решить заранее, еще до сопряжения с датчиком, т.к. вслепую справится с это работой будет трудно. Да и лучше бы с ним определиться раньше - до покупки Ардуино-платы. Т.е. с компьютером вы ее сопрягать станете (тогда у вас получится установка привязанная к компьютеру) или необходимо сделать мобильное устройство, которое должно совмещать в себе средства индикации результата.

На FTP, куда вы уже имеете доступ, есть все версии IAR. А "релиз-справки" по ним, как и прочие описания, можно добыть без инсталляции - для этого достаточно переименовать инсталятор из EXE в ZIP и выбрать из этого архива то, что вам нужно.

Тогда это может быть сама борная кислота, эта плавится ниже. Раньше в любой аптеке можно было купить по дешевке, а хотя нынче уже реже продают.

По вашему описанию - бурой паяли, т.е. использовали в качестве флюса тетраборат натрия. Его присутствие тоже можно определить по той же "лакмусовой бумажке" (pH-индикатору), только на этот раз реакция будет щелочной - pH около девятки.

Влажной лакмусовой бумажкой - все эти "чудо-флюсы" кислые, т.к. именно кислота - их действующее начало (именно она растворяет окислы). По этой остаточной кислотности как раз и можно определить факт их использования. Тот же совет относится и к фосфорной кислоте, которую тоже очень часто используют в качестве флюса, когда спаиваемые поверхности наотрез отказываются лудиться :). В электронике использование кислых флюсов категорически запрещено, т.е. остаточной кислотности вполне достаточно, чтобы создать паразитную проводимость за счет сорбирования влаги из воздуха в купе с остатками кислого реагента.

Вы твердо уверены, что у STM32H7-го Stream0 1-ого DMA обслуживает ADC1? А то я на этот момент уже спотыкалась на STM32F4, когда выяснила, что для обслуживания ADC1 нужен не DMA1, а DMA2. Для STM32H7 такой таблицы не нашла, но для STM32F4 она такая:

Например, здесь: https://narodstream.ru/avr-urok-16-interfejs-twi-i2c-chast-6/ Но если у вас в этом деле нет опыта, то почему бы вам не взять ... Arduino :), благо что они почти все поголовно собираются на базе контроллеров AVR? А в той среде уже есть готовые модули для большинства операций, в том числе и для обмена информацией по интерфейсу I2C: https://all-arduino.ru/arduino-dlya-nachinayushhih-urok-11-interfejs-i2c/

А вы не боитесь, что такого рода датчик годится не для всех металлов, а только для железа? Ведь большинство прочих металлов от магнитного поля земли не намагничиваются, а стало быть, магнитное поле вблизи них не увеличивается.

Ищите ответ на ваш вопрос в даташите на датчик. Там должна быть информация о том, как он подключается к микроконтроллеру. Тогда как тип самого микроконтроллера обычно значения не имеет, поскольку большинство интерфейсов связи с датчиками стандартизовано.

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

Но мы же здесь не в точности цитирования Википедии соревнуемся :). Эйлер сперва предложил свою аппроксимацию степенной функции ex бесконечным рядом, а после подставил в него комплексное число и предложил считать величину, к которой такой ряд сходится, за комплексную экспоненту. Это предложение всем понравилось :), поскольку допускало формальную подстановку комплексных чисел вместо действительных. Но так бывает не всегда - есть ряды, которые после замены действительной величины на мнимую перестают сходится. Фактически в то время многие функции попросту не были определены для комплексного аргумента, вот их и стали в спешном порядке доопределять. Кажется Эйлер тем же подходом еще и логарифм от комплексного числа определил, а может быть и еще что-то. Для этого личного авторитета ему хватало :).

Полагаю, что Эйлер не вывел эту формулу, а просто определил правило, как следует возводить числа в мнимую степень, исходя из геометрического представления, что действительная и мнимая оси образуют комплексную плоскость. Причем, определил так, чтобы результат возведения в степень всегда принадлежал этой же плоскости. И сделал это с тем умыслом, чтобы комплексные числа образовали (алгебраическое) поле.

Залила в закрома. Вот сюда: /pub/BOOKS/OS/_FreeRTOS_/Amos B., Hands-On RTOS with Microcontrollers. Building real-time embedded systems using FreeRTOS, STM32 MCUs, and SEGGER debug tools(2020).pdf P.S. И в дальнейшем - если кто-то из вас располагает прямой ссылкой на литературу или на что-то еще более крутое :), то пишите мне в личку. Я, как лицо заинтересованное и наделенное кое-какими дополнительными возможностями, сделаю это быстро и качественно :).

Значит, не все скопировали. У меня тоже так бывает, когда-то что-то недокопировала. Но так и должно быть. В свежих версиях STM32Cube_FW_F4_V1.25.1 и STM32Cube_FW_H7_V1.8.0 в файле usbd_core.h функции USBD_LL_Transmit и USBD_LL_PrepareReceive определены именно так - с параметром uint32_t, и это правильно. А если у вас не так, то значит где-то тащите за собой хвост из старых версий, когда тот параметр был uint16_t. Мне странно, что это место в своем же проекте вы никак не можете найти. А пока я могу лишь только посоветовать вам обновить заодно и версию CubeMX - ныне ее последняя версия 6.10. Возможно, что это она виновата.

Земли еще надо соединять. А из картинки неясно, соединены они или нет.

Подобные случаи бывают, когда что-то из Middlewares спускают в проект в виде копии, а затем репозитарий обновляется, и в результате h-файл перестает соответствовать c-файлу. Например, в случае, когда c-файл спустили в проект для модификации, а комплиментарный ему h-файл остался в папке Middlewares. Я сама раза два на это натыкалась, когда переходила на новую версию репозитария. Кстати, STM32Cube_FW_H7_V1.7.0 на сегодняшний день не последний - появился STM32Cube_FW_H7_V1.8.0. А поскольку вам все равно решать свою проблему хирургическим путем :), то имеет смысл перейти на более свежую версию, тем более что H7 - довольно новое семейство и в коде для него всё еще происходят подвижки, тогда как для F4 код уже устаканился. Но пока я опишу, что предлагаю вам сделать на вашей версии STM32Cube_FW_H7_V1.7.0. 1. Вы не пишите, какой компилятор используете, но полагаю, что вы умеете определять, откуда ваш проект берет файлы. Проверьте их источник. Это может быть глобальный источник: C:\Users\...\STM32Cube\Repository\ или локальный: ваш проект\Drivers\ ваш проект\Middlewares\ На худой случай можно посмотреть в файл .mxproject, но лучше все-таки проверить проект компилятора, а не Куба. Будет лучше, если проект у вас окажется локальным - тогда несмотря на больший его объем, он будет независим от версии репозитария, проинсталлированного на данный компьютер. 2. Если проект у вас локальный, то проверьте совпадение (по размеру и дате) файлов из локального репозитария с файлами из глобального: C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Drivers\STM32H7xx_HAL_Driver\ C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Drivers\CMSIS\ C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Middlewares\ST\ и обновите файлы локального репозитория, взяв их из глобального. Все подряд копировать не надо (там много лишнего), а только содержимое тех папок, имена которых в локальном репозитории уже были. 3. При желании перейти сразу на новую версию STM32Cube_FW_H7_V1.8.0 делаете всё то же самое, только сверх того в файле *.ioc замените строку ProjectManager.FirmwarePackage=STM32Cube FW_H7 V1.7.0 на ProjectManager.FirmwarePackage=STM32Cube FW_H7 V1.8.0 Тогда при запуске Куба он сам предложит залить новый репозиторий, если дать на то согласие.

Эти функции определены здесь: \Middlewares\ST\STM32_USB_Device_Library\Core\Inc\usbd_core.h а используются тут: \Middlewares\ST\STM32_USB_Device_Library\Core\Src\usbd_ioreq.c а ваши расхождения можно объяснить только тем, что Inc и Src были выбрали из разных источников. Определитесь с источником и возьмите usbd_core.h и usbd_ioreq.c из одного места.