Xenia

Там не срок действия ссылки истек, а IP изменился: http://136.243.71.244/CSpySDK/ В этом директории к zip-архиву еще что-то прибавилось.

Ходила по ссылкам, но мне показалось, что они не работают (Error Forbidden). Но проблема оказалась в том, что я сейчас в Крыму, а потому для меня многие ссылки закрыты. Когда поняла в чем дело, добыла файл через VPN. Тем не менее, эти исходники меня разочаровали - слишком много непонятного кода, в котором фиг разберешься :). Тогда как мне хотелось бы чего-то попроще для полутоновых изображений (градации серого), когда в сжатии потребности нет.

А на этот libpng есть исходники? Где бы их мне добыть? А то Linux не признает формат bmp .

На FTP в директории /pub/MCs/ARM/STM32/STM32CubeMX/Packages/ оно есть. Не все, но stm32cube_fw_f1_v184.zip там есть точно.

Если у вас сохранился ioc-файл, а он у вас сохранился - "AD ADC.ioc", то ставьте последнюю (самую свежую) версию CubeMX, а уж она, согласно ioc-файлу, создаст нужное окружение - компилятор и Drivers (это так у нее исходники фирменных библиотек называются). И так, инсталлируем последнюю версию CubeMX (ныне это версия 6.11.0), запускаем AD ADC.ioc и видим это: Это означает, ваш проект был когда-то создан на версии CubeMX 6.6.1. Дальше надо нажать на кнопку Continue, чтобы проект был скомпилирован, как встарь. После чего начнется закачка из интернета сперва образа старой версии CubeMX, а затем библиотеки "stm32cube_fw_h7_v1100.zip" (по нынешним временам она уже устарела), поскольку именно так в вашем файле "AD ADC.ioc" прописано: ProjectManager.FirmwarePackage=STM32Cube FW_H7 V1.10.0 А дальше действуете по обстоятельствам - где попросит, соглашаетесь, но только не на миграцию! dimka76 прав, ранее скопилированный проект в вашем архиве уже есть - "AD ADC.elf".

Виновата - килогерцы с мегагерцами спутала.

Возможно, что я отстала от жизни :), но по моим представлениям 1000 SPS (а тем более 4000 SPS) не совместимо с требованием иметь разрешение в 20-24 разряда. Высокоразрядные АЦП, как правило, относятся к типу "сигма-дельта", чья высокая разрядность базирутся на принципе интегрирования входного сигнала на всем протяжении периода измерения. Именно благодаря такому усреднению удается уменьшить уровень шума и тем самым повысить число значащих бит в результате. Но по мере того, как мы увеличиваем частоту оцифровки данных, период измерения сокращается и эффект от усреднения всё меньше дает пользы. Оттого и разрешение с ростом частоты сэмплирования неизбежно уменьшается. Поэтому, на мой взгляд, при частоте сэмплирования свыше 1 МГц стоило бы использовать обычный SAR и смириться с разрядностью 16 бит.

Через Transmit и Receive у меня тоже не получалось читать датчики, но для этой цели хорошо подошла функция: HAL_I2C_Mem_Read( &hi2c1, devAddress << 1, regAddress, 1, pData, 2, I2C_TIMEOUT10); куда сразу закладываем номер регистра данных - regAddress и адрес буфера на 2 байта, куда надо прочесть данные - pData. Т.е. всё делает одна эта функция. В вашем случае это будет выглядеть так: HAL_I2C_Mem_Read( &hi2c1, I2C_ACL_ADRESS << 1, rgMgnAdress, 1, &rgMgnData, 2, I2C_TIMEOUT10); Внимание! в качестве rgMgnAdress следует класть число (в вашем случае 0x4F), а не адрес памяти, где оно лежит! Вероятно в этом ваша ошибка. HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);

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

Золотые слова :). Судя по картинке, двигатели там относительно маломощные (на вид Nema17), а для таких есть дешевые драйверы на ток до 2А. У меня, например, стоят A4988 на каждый двигатель (у меня их 4 штуки). Лот из 5-ти штук на Aliexpress за $1 когда-то покупала. Ныне, когда 3D-принтеры широко распространены, драйверы для них достать очень легко.

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

Вместо пинга я пользуюсь программой NMAP (https://nmap.org), которой сканирую всю сетку. К сожалению, при подключении моей платы к роутеру новый IP-узел не появляется.

Все равно не работает... А может быть DHCP не надо отключать? Пусть роутер присвоит свой IP - тогда уж сеть у компьютера и платы с гарантией будет одинаковой, раз уж они в один и тот же роутер воткнуты. Или это плохая идея? P.S. И вообще для меня было бы большим облегчением увидеть своими глазами исходники рабочего проекта, написанного на HAL (CubeMХ) в конфигурации "DP83848+RMII". Без RTOS. В репозитории (\Repository\STM32Cube_FW_F4_V1.28.0\Projects\) уже искала, но там только под MII есть примеры, тогда как у меня на плате DP83848 кормит отдельный генератор на 50 МГц (именно генератор, а не резонатор). А раз так то я вынуждена режим RMII использовать. Это было бы для меня наиболее эффективной помощью, т.к. у меня не хватает наглости просить участников нашей конференции, чтобы они искали ошибки в моем программном коде.

Из ваших объяснений не поняла, в каком месте надо выставить IP и какой. Но больше всего я боюсь, что, перенастроив ПК на связь с платой, я лишусь интернета. На эту мысль меня наводит тот факт, что на ПК DHCP у меня включен, а на плате выключен. Именно такой совет мне был дан: А пока DHCP на вкладке CubeMX не выключишь, статический IP адрес он ввести не дает. Вот оно как у меня: Тогда как в настройках ПК ситуация выглядит так:

Однако не заработало оно у меня... Однако я задам вопрос не о возможных причинах этого (тем более, что их может быть очень много), а о том, как этот пинг проверять. Пока что я просто соединила пач-кордом Ethernet-гнездо на плате с Ethernet-гнездом на материнской плате компьютера. Результат таков: компьютер крутит колесико (у меня Win7) в поисках интернет-сети, но так ее и не находит. Оно и понятно, т.к. моя плата предоставить выход в интернет не может. А поскольку сети компьютер не находит, то я и не могу поглядеть , какие TCP/IP-адреса в ней есть. Сперва я подумала, что в программе у меня ошибка и поэтому вместо самодельно-запрограммированной платы поставила другую плату (иной конструкции), где какая-то заводская прошивка для Ethernet уже была. Но результат получила точно такой же. От этого и закралась у меня мысль, что может быть я платный Ethernet неправильно проверяю? Вдруг компьютер надо как-то иначе настраивать, чтобы он такую плату в своем окружении увидел?