Jump to content

    

manul78

Участник
  • Content Count

    416
  • Joined

  • Last visited

Community Reputation

0 Обычный

About manul78

  • Rank
    Местный
  • Birthday 03/22/1978

Информация

  • Город
    Array

Recent Profile Visitors

2914 profile views
  1. Безумно жалко потраченного времени... Говно полное. Ничего не работает... IDE Keil 5 uVision... Плата Discovery-F429i Никаких Middleware TouchGFX у меня в Кубе нет, всё подключается через вкладку Additional Software. Путем проб и ошибок настроил. Никакой кнопки Execute тоже в этом кубе нет. Пришлось вручную открывать редактор и делать. Ещё раз прошу: Конкретно. Для платы DISCOVERY - F429i пришлите бинарник. Простейший. Одну кнопочку. Бинарник или HEX. Уверен, что это гуано TouchGFX на данной борде не работает от слова ВООБЩЕ !!! Нигде не видел в сети и на форумах хотя-бы ОДИН рабочий пример. У всех одна теория... всё работает, всё ОК, всё просто... На деле - одно словоблудие и пи$джь, бесконечный флуд пи$доболов собеседников из страны советов... ДАЙТЕ ПРОСТОЙ РАБОЧИЙ БИНАРНИК ИЛИ HEX ФАЙЛ, чтобы я его тупо загрузил и посмотрел результат. Я не видел НИ ОДНОГО РАБОЧЕГО ПРИМЕРА TouchGFX ДЛЯ ПЛАТЫ DISCOVERY - F429i в сети ИНТЕРНЕТ от СЛОВА ВООБЩЕ !!! Ни на российских сайтах/форумах ни на буржуйских сайтах/форумах.
  2. Любой. Мне даже честно говоря уже даже исходники не нужны, дайте бинарник рабочий чтобы загрузить и посмотреть. Иначе у меня складывается впечатление что TouchGFX это большой и толстый развод от STM, абсолютно мёртвый и имеющий статус "синей птицы", о которой все слышали но никто не видел...
  3. День добрый ! Таки кому нибудь удалось завести любой (!) проект для TouchGFX на Discovery-F429i ? Я вот третий день бьюсь. Пример который идет с упаковкой для CubeMX F4 не рабочий. Он компилится и линкуется, и даже прошивается - но не работает. Мусор на экране. Примеры которые идут с самой TouchGFX также мертвые, отсутствуют шрифты, криво настроена FreeRTOS, короче там "полна зоппа огурцов"... Сгенерировал практически пустой проект с одной кнопкой. Опять кривое подключение FreeRTOS и не подключенные файлы с графикой. Подключил. Скомпилировалось... Белый Экран и Hard Fault... :) Полазил по форумам - смотрю что-то никто подцепить не может к Discovery - F429i... Только умничают и советы дают. Страна советов блин... Прошу дайте бинарник просто глянуть, если вам исходники жалко - исчезают как дым... Здесь кто-нибудь хотя-бы синий экран получил через TouchGFX на плате Discovery-F429i ?
  4. Странно... У меня всё ОК. И с смартфона специально посмотрел.
  5. Здравствуйте ! Мы портировали ПЛК Mitsubishi Melsec FX2N на дешевую плату "синяя таблетка" на базе STM32F103C8T6. Фирменое програмное обеспечение IDE Mitsubishi Developer FX 8, которое поддерживает AWL - листинг инструкций. STL. - пошаговая схема. LD Ladder Diagram (язык графической релейной логики) Обучающая программа от Misubishi FX Trainer Всё на русском языке. Документация на русском. Нужны ваши отзывы и тесты. Сайт с информацией и пошаговой инструкцией для быстрого старта на русском языке Bp-plc.ru Программное обеспечение и прошивка для "таблетки" там-же... Подробная инструкция как всё настроить там-же... Проект НЕ коммерческий, предназначен для студентов и начинающих в мире автоматизации. Вопросы, Пожелания, комментарии - можно писать здесь, либо в разделе "В Помощь Начинающему" Заранее благодарны за отзывы, Команда BP-PLC. (Blue Pill PLC)
  6. Добрый день ! Спасибо всем за ответы, шутки, стёб, серьёзные советы. Но тему честно говоря я поднимал ради совсем других вещей. И пример с устройством приведён просто как пример, а не тема для обсуждения. А вопрос-то изначально был простой, но со сложными ответами. Попытка собрать в один список алгоритм действий для разработчика, у которого нет дикого бюджета, из аппаратуры только пара хороших компов, ноутбук, ST-Link, J-Link, цифровой осциллограф и простой недорогой логический анализатор. Устройство которое он делает не серийное, их может быть от силы пару штук, и оно заточено под конкретные цели - штучный товар. Дельные ответы изо всей "воды" здесь вылитой я всё-же получил: 1. Делать как минимум два экземпляра, дабы исключить глюки с железом из-за некачественной пайки, компонентов и пр. Также это пригодиться в процессе отладки, когда один экземпляр работает "в поле" а с другим можно заниматься в лаборатории на столе. 2. Сразу-же вести записи и документацию. Эдакий "бортовой журнал". Всё записывать и документировать. 3. В процессе разработки сразу предусмотреть как минимум один порт и интерфейс (UART,SPI,I2C) для отладки. Если нет места и ног - брать более функциональный чип из серии МК. 4. В процессе написания программы предусмотреть контрольные точки и индикацию происходящих в МК процессов, чтобы поиск неисправности не превратился в заглядывание под капот мчащегося на скорости 200 км/ч автомобиля - "всё шумит, всё крутится, ничего не понятно..." 5. ...... Далее прошу продолжить участникам данной темы, если не лень конечно...
  7. Я уже отвечал выше. "Это не моя война..." (с) Меня интересуют методы. Данный девайс и его глюки приведены как пример. Моя цель собрать воедино все советы и написать для себя и других базовый алгоритм действий при поиске неисправностей в железе и софте, дабы не метаться из угла в угол тратя время на "авось заработает" а действовать в четком направлении. Извините, но очень смешно... :) По питанию проблем нет и быть не может. Автомобильный аккумулятор и два линейных регулятора на 5 и 3.3 Вольта. Никаких импульсников и пр. Вот здесь уже теплее... Человек, который давно уже бьётся с данным устройством связывает сбои именно с этим. Дело в том, что пакеты отправляемые "мастеру" фиксированной величины. Этим спокойно занимается DMA. А вот пакеты поступающие от "мастера" разной величины, поэтому разработчик сделал прием на прерываниях. Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу. Арбитраж видимо был не предусмотрен... :) Немножко об отладочной системе CoreSight... Кто-то тут писал про Segger-овский ULINK 2, так вот, у STM32 урезаная версия CoreSight, которая не поддерживает ETM :( Так что с трассировкой прерываний через крутой ULINK 2 пролёт... :(
  8. "Знали-бы где упасть - соломку подстелили-бы..." (с) :( Тут я полностью согласен. Быдлокодерство не подразумевает ни ведение грамотной документации, ни специальных программных вставок-решений для отладки. Слепили из "говна и палок" - заработало кое-как и ладно... А там хоть не рассветай... Второе грамотное предложение. Действительно, надо было сделать хотя-бы пару идентичных устройств, дабы в процессе тестирования и работы отсечь аппаратные неисправности, как-то битый МК, обвязка, комплектующие и пр. То есть чётко отделить железо от софта Время - есть. Денег - нет....
  9. Если честно - "Это не моя война..." (с) Софт писали какие-то студенты на Cube-HAL-е... Потом они уволились, допиливали другие... и т.д. Я привёл данный случай как пример. Но если софт писали дилетанты - это не значит, что не глючит софт написанный профессионалами, по всем канонам и со всеми ритуалами. Я запустил эту тему для себя, чтобы попробовать выжать экстракт из общего опыта поиска неисправностей. Универсального решения разумеется нет, но поределённые базовые шаги и грабли думаю будут интересны всем. Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно... :) Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство. Я понимаю Вас. Меня интересуют "методы", пусть даже нестандартные. Возможно даже кто-то здесь имеет в своём распоряжении самопальные компактные супервазеры для STM32, я-же не прошу схему, код и готовые решения на халяву. Я ищу ВЕКТОР направления в котором двигаться.
  10. Я уже писал в начале. С крутым отладчиком, в тёплой лаборатории и при достаточном бюджете... Девайс работает на отшибе на территории завода. К нему лишний раз не набегаешься, и лабораторию измерительную не соорудить вокруг. Глюки спонтанны, но как заметили связаны с увеличением траффика передаваемых данных.
  11. Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 8-ми битный порт отдают на real-time bug catcher. его подключают к прозрачному регистру-защёлке типа 74HC573 а выходы на 7 светодиодов. 7-бит "красный", 6-й "зелёный", остальные "жёлтые" Суть такая: Присваиваются номера. Процедурам на вход и на выход и нее, и прерываниям на вход и на выход. Например: Процедура A (0x01 -IN, 0x02 - OUT) , Процедура B (0x03-IN, 0x04 - OUT)..... и т.д. Прерывание A (0x41 -IN, 0x42 - OUT) , Пррерывание B (0x43-IN, 0x44 - OUT)..... и т.д. При прирывании по WWDT перед сбросом в информационном байте устанавливается 7-й бит в 1, это чтобы после сброса при начальных установках не скинуло содержимое регимтра-защёлки подключенной к bug-catcher порту. Процедуры и прерывания пишут свои номера при входе и выходе в порт. Регистр-защёлка их запоминает. В случае ступора или сброса, на светодиодах видно - где споткнулся МК. 50/50... :) Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные. они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру". Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем. А вообще - то, мне тема интересная. Я большой любитель ловли "багов", и пофлудить не прочь. В любом случае это - ОПЫТ.
  12. Как поймать "Баг" на скорости 72 МГц ? (тема для обсуждения и поиска решения) Задача: Есть условное устройство на базе STM32F103C8 (Cortex-3M) которое работает на максимально разрешенной частоте в режиме максимальной нагрузки, то есть активно работает ядро АРМ, периферия, порты ввода-вывода, DMA, таймеры. В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д. Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса. Вопрос: Как поймать сбой происходящий в периоде довольно длительного отрезка времени? У простого разработчика разумеется нет тех аппаратных возможностей которыми оперируют крупные лаборатории и производители серийных устройств, нет возможности обвешать "девайс" супервайзерами, логическими анализаторами и неделями круглосуточно гонять устройство, писать Log-и, а потом отрядом в 50 человек анализировать их. Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight. Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный. Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК. Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров. Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго ! Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко... :) А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва. Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер. Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться. Так что Давайте высказываться, Уважаемые участники сообщества. У кого какие есть на это мысли и решения?
  13. STM32 и USB

    Попробовал - не помогло. Полазив по буржуйским форумам нашел кучу решений, но все из них зависят от конкретной "борды" и МК. Причём в одних случаях через транзистор и резистор в 1.5К одни сажают D+ на "землю" - другие на шину питания :cranky: Сочленил вот такую схему: Теперь заработало. Видимо не хватало "мощщи" дабы посадить канал D+ на землю как следует. Но это зависит от Хоста или от конкретной входной схемы платы МК. Ваше решение вполне может работать на конкретно вашей плате. Покопавшись еще в сети нашел еще один "метод", в котором даже лишний пин использовать не надо и вообще никакой обвязки... И его попробовал. Всё работает. Программно переключаем пин порта PA12 на ВЫХОД с Открытым стоком и сажаем USB D+ тупо на землю на 500 мс. Но я данный метод считаю варварским ибо тупо сажать канал на землю, по типу КЗ не есть гуд. Тем не менее он имеет место и им пользуются... :) Всем спасибо за помощь ! Если кому-то знакомы более цивилизованные методы (как пишут выше, используя свой USB стек) прошу поделиться. Заранее благодарен. P.S. Сижу ржу... В первом случае зачем-то повесил резистор на 1.5К, если в случае конфигурации порта как выход с открытым стоком - в случае А) Выход в Hi-Z состоянии, а в случае Б) линия USB D+ (PA12) тупо стекает накоротко на землю. :) Резистор нужен тут как собаке пятая нога... :) От него только лишняя помеха на линии... :) P.P.S. Уменьшил резистор до 500 Ом - заработало...
  14. STM32 и USB

    День добрый всем ! Работать с STM32 я начал недавно, поэтому сильно не пинайте. Суть такая: Есть МК stm32f103c8t6. В процессе настройки программы я использовал UART и переходник-мост USB-COM. Но ведь на борту имеется USB модуль. Взял шаблон из библиотеки и организовал в контроллере CDC устройство, то бишь Виртуальный COM порт. Всё работает, всё нормально. Единственная загвоздка, что каждый раз после сброса МК он перегружается, а вот хост на компе нет. Поэтому приходиться тупо выключать и обратно включать тем самым проводить повторную энумерацию и т.д. Физически. Мне это надоело, постоянно вынимать и опять вставлять штекер разъёма. На Мегах АВР с USB всё было много проще. Функции Attach() и Detach(). С библиотеками для STM32 всё сложнее. Никак не могу организовать программно со стороны МК подключение к компу заново. Нашёл в библиотеках STM32 функции @brief Connect the USB device * @param hpcd: PCD handle * @retval HAL status */ HAL_StatusTypeDef HAL_PCD_DevConnect(PCD_HandleTypeDef *hpcd) { __HAL_LOCK(hpcd); HAL_PCDEx_SetConnectionState (hpcd, 1); USB_DevConnect(hpcd->Instance); __HAL_UNLOCK(hpcd); return HAL_OK; } /** * @brief Disconnect the USB device * @param hpcd: PCD handle * @retval HAL status */ HAL_StatusTypeDef HAL_PCD_DevDisconnect(PCD_HandleTypeDef *hpcd) Вроде как аналоги Attach() и Detach(). В мануале сказано, что HAL_PCD_DevDisconnect() даёт команду хосту на отключение, затем надо сделать паузу не менне 5 мс, далее вызываем HAL_PCD_DevConnect() и хотст проводит новую процедуру энумерации, как было-бы если я тупо вынул и вставил по новой штекер USB устройства в Хост. Но что-то никак не получается... :( "Люди добрые ! Поможите чем можете ! (с) Может я чего не понимаю, или криво делаю. Если есть примеры кода - напишите пожалуйста. Без разницы, хоть в прямом доступе к регистрам, хоть SPL, HAL или LL... Мне главное суть присходящего понять, и вообще возможно-лт это ? Заранее благодарен за ответы.
  15. UPD: Разобрался, но не совсем... :( При помощи "говна и палок" запустил таки. Пришлось использовать для инициализации портов столь ненавистный мне HAL... Его драйвер рабочий. static void MX_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct; /* GPIO Ports Clock Enable */ __HAL_RCC_GPIOD_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); /*Configure GPIO pin Output Level */ HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9, GPIO_PIN_RESET); /*Configure GPIO pin : PA11 */ GPIO_InitStruct.Pin = GPIO_PIN_9; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); } Ну а потом закомментировать в инициализации USART1 настройки порта при помощи LL драйвера. /* USART1 init function */ static void MX_USART1_UART_Init(void) { LL_USART_InitTypeDef USART_InitStruct; //LL_GPIO_InitTypeDef GPIO_InitStruct; /* Peripheral clock enable */ LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_USART1); /**USART1 GPIO Configuration PA9 ------> USART1_TX PA10 ------> USART1_RX */ //GPIO_InitStruct.Pin = LL_GPIO_PIN_9; //GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE; //GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH; //GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL; //LL_GPIO_Init(GPIOA, &GPIO_InitStruct); //GPIO_InitStruct.Pin = LL_GPIO_PIN_10; //GPIO_InitStruct.Mode = LL_GPIO_MODE_FLOATING; //LL_GPIO_Init(GPIOA, &GPIO_InitStruct); USART_InitStruct.BaudRate = 115200; USART_InitStruct.DataWidth = LL_USART_DATAWIDTH_8B; USART_InitStruct.StopBits = LL_USART_STOPBITS_1; USART_InitStruct.Parity = LL_USART_PARITY_NONE; USART_InitStruct.TransferDirection = LL_USART_DIRECTION_TX_RX; USART_InitStruct.HardwareFlowControl = LL_USART_HWCONTROL_NONE; LL_USART_Init(USART1, &USART_InitStruct); LL_USART_ConfigAsyncMode(USART1); LL_USART_Enable(USART1); } Вот ТАКОЙ гибрид получился. Унылый. Но работает. Виноват кривой LL драйвер портов GPIO. Где конкретно грабли в stm32f1xx_ll_gpio.c или в stm32f1xx_ll_gpio.h пока не знаю. Знаю только что библиотека кривая. Пол года уже. author MCD Application Team version V1.1.1 date 12-May-2017 GPIO LL module driver. Привет компании STM и MCD Application Team... :) Тему не закрываю. Постараюсь найти где именно ошибка. Если кто-то уже налетал на эти грабли - пишите, чтобы другие не наступали. P.S. Кто-то разумеется спросит: "Зачем мне это нужно ? ". Отвечаю. Почти год писал для STM32F030F4 исключительно используя библиотеку LL, привык, код компактный, всё понятно. Никаких нареканий не было. Честно, говоря она мне даже нравится. :)