Jump to content

    

SimpleSoft

Участник
  • Content Count

    304
  • Joined

  • Last visited

Community Reputation

0 Обычный

About SimpleSoft

  • Rank
    Местный

Контакты

  • Сайт
    Array
  • ICQ
    Array

Recent Profile Visitors

4114 profile views
  1. STM32CubeIDE

    Добрый день, Используем в новом проекте STM32H750 и Ethernet PHY KSZ8091R - опять вижу в генерированном CubeMX проекте ошибки в работе с D-Cache и естественно сгенерированный проект сразу не запускается (использован STM32H7 MCU pack 1.7.0) Мы поправили - но будьте внимательны - можно легко закопать дни в поиске проблемы.
  2. Вы можете доступаться до MIPI CSI регистров из Cortex M4. Они относятся к блоку AIPS4.
  3. Добрый день. Лучше взять https://www.intrinsyc.com/snapdragon-embedded-development-kits/snapdragon-855-hdk/ Там Hexagon DSP V66x. Там в SDK, в примерах есть скрипты которые через ADB закачивают все необходимые файлы на платформу и запускают на cDSP. Дебажить у вас на целевой платформе не получится, у них там очень кривой отладчик через ADB. Мы купили Lauterbach с лицензией для Hexagon DSP и с помощью него дебажим на платформе. Но лучше вариант - это симулятор от Lauterbach.
  4. А сравнивали эти байты с пачкой при плюсовой температуре? Может всёже флешка отдаёт ошибочные данные?
  5. Только увидел сообщение :) Было такое - были проблемы с кэшем. На HDD всё ОК, на SSD - бывало проблемы. Не решили - просто перенести на HDD. Может у меня не ваш случай - гляньте ProcMon - что IAR делает в это время.
  6. Добрый день Наша компания ищет схемотехника готового работать удалённо. Задача: Необходимо разработать схему с 8-ми канальным ЦАП отвечающий следующим характеристикам: 1. Первые 4 выходных канала с возможностью управлять нагрузкой в 100 мА при +12В диапазоне (0..+12В). Точность – 1мВ (выход х Вольт ±1мВ). Допустимый уровень шума – ≤ 15 мкВ (RMS) 2. Вторые 4 выходных канала с возможностью управлять нагрузкой в 500 мА при +12В диапазоне. Точность – 25мВ. Допустимый уровень шума – ≤ 1 мВ (RMS) 3. Требуемая частота изменения значения на выходах ≥ 500 Гц. 4. Схема должна иметь возможность измерять установленный уровень каждого выхода ЦАП с точностью 1мВ (с помощью 8-канального АЦП или АЦП + мультиплексор) 5. Шина управления ЦАП и АЦП – желательно SPI (но не критично). 6. Индустриальный диапазон температур -40°C to +85°C Присылайте ваше предложение по сотрудничеству в личку.
  7. Спасибо за советы. Реализовали предложение чтению данных только если необходимо, т.е. вызываем USBD_CDC_ReceivePacket когда следующие данные реально нужны. Действительно помогло. Заметили особенность - TeraTerm Ymodem "пихает" пакеты постоянно (видимо маленький таймаут для Write, или ещё что-то, что мы упускаем из виду) - проверено с помощью Com Port monitor на стороне PC, который "слушает" всё что летит от TeraTerm в COM port.
  8. Спасибо всем за ответы. Мы хорошо разбираемся в USB, мой вопрос был про опыт решения на STM32. По поводу не читать USB RX - мы не пробовали, но возник вопрос - а не будет ли STM32 дергать постоянно прерывание о приёме данных? (в Tech Ref не копались) Может кто-то знает как OTG в STM32H7 обрабатывает RX data interrupt?
  9. Добрый день, реализуем YModem поверх USB CDC. Тестируем под Win7 с помощью TeraTerm. Как только начинается передача пакетов данных от ПК (TeraTerm) в STM32, пакеты данных (по 512) прилетают с такой скоростью, что забивают кольцевой буфер под завязку. Посмотрели более детально, TeraTerm (Ymodem TX) повторяет пакеты до тех пор, пока STM32 не пришлёт ACK (тогда шлёт следующий кусок данных). Возник вопрос - как "притормозить" приходящие пакеты? Мы рассматривали вариант отключать прерывания USB: hpcd_USB_OTG_HS.Instance->GAHBCFG &= ~USB_OTG_GAHBCFG_GINT; Но это как-то жестоко, хоть и работает. Второй вариант который мы рассматривали - это Flow Control, но отбросили - не всегда его конечный клиент использует, да и потом без него тоже система должна корректно отрабатывать. Обработчик который сейчас реализован: static int8_t CDC_Receive_HS(uint8_t* Buf, uint32_t *Len) { /* USER CODE BEGIN 11 */ USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceHS.pClassData; if (hcdc) { USBD_CDC_SetRxBuffer(&hUsbDeviceHS, Buf); USBD_CDC_ReceivePacket(&hUsbDeviceHS); if (bs_usb_rx_command(Buf, hcdc->RxLength) == 0) { return (USBD_BUSY); } } return (USBD_OK); /* USER CODE END 11 */ } Если функция bs_usb_rx_command не может записать в кольцевой буфер (он полон) данные - возвращаем USBD_BUSY (по сути теряем данные). Но следующие тут же прилетают. Поделитесь, пожалуйста, опытом, как вы решали подобную задачу. Спасибо! MCU: STM32H743XIH STM32CubeIDE Version: 1.0.2
  10. Подскажите, как вы делаете подготовку к релизу? Есть ли unit test'ы? Код ревью? Функциональное тестирование? Тесты на стабильность?
  11. Спасибо за информацию. Я так понимаю для Release лучше выключить?
  12. Да, действительно ловушка не была включена. Однако при её включении ситуация не поменялась. Попробовал configCHECK_FOR_STACK_OVERFLOW с опциями 1 и 2. FaultAnalyzer все еще ссылается на list.c файл - в тоже место. Stack вызовов выглядит так: Ветку в принципе можно закрывать. Единственное что меня смущает - так это код 1-в-1 кроме FreeRTOS portable исходников, и такое поведение. Я списываю пока это на разные компиляторы ARM IAR vs GCC ARM.
  13. Проблему решили. const osThreadAttr_t defaultTask_attributes = { .name = "defaultTask", .priority = (osPriority_t) osPriorityNormal, .stack_size = 128 }; значение .stack_size увеличили в 2 раза - поток стал работать без сбоев
  14. Спасибо за советы. Ничего сложного. Я не хочу возиться с чужим кодом и всего. Если кто-то сталкивался с подобной пробемой и может поделится решением - я буду благодарен. Иначе будем с разработчиками искать. Пс: я смотрю не особо народ в восторге от Куба ;)
  15. Я предполагал что возможно кто-то уже сталкивался. Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX. Если я генерирую в IAR ARM -> код работает нормально. Разница только в 2х файлах: Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.c и portmacro.h