Search the Community

Всем добрый день! На работе поручили заняться разработкой нового прибора на микроконтроллере STM32 (исходя из технической задачи мой выбор пал на STM32F407VE) с обязательным условием - использование ОСРВ FreeRTOS. С микроконтроллерами знаком, разрабатывал на их основе пару приборов, но с данной ОСР не работал никогда, и поэтому хочу попросить здесь совета. Работаю в STM32CubeIDE. Одна из возможностей моего девайся - это ручное управление коллекторным двигателем. В проекте я настроил две ножки на внешние прерывания GPIO_EXTI_3 и GPIO_EXTI_4. Включена подтяжка по питанию и срабатывание прерывания по любому изменению фронта сигнала (прибор должен реагировать на нажатие/отпускание кнопок. Пока одна из кнопок нажата - крутим вверх или вниз, а если отпустили, то остановка). Схемотехнически нажатие кнопки коммутирует вход МК с землёй. Программно я себе это представлял так: Срабатывание прерывания на одном из входов -> В перывании определяем, какой именно фронт пришёл -> Если фронт низкий, то крутим двигатель || Если фронт высокий, то останавливаемся. Вставлять в прерывание функцию вращения двигателем я, разумеется не стал. Вместо этого я решил в зависимости от статуса кнопки пересылать в функцию управления двигателем семафор. Условно говоря, код выглядит так: void EXTI3_IRQHandler(void) //Кнопка вращения двигателя вверх { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_3); if(HAL_GPIO_ReadPin(GPIOD,GPIO_PIN_3) == GPIO_PIN_SET) //Если на входе высокий уровень, то пока ничего не делаем { asm("nop"); } else //Если уровень изменился, то { xSemaphoreGiveFromISR(sem_curr_upHandle,NULL); //Даём семафор из прерывания } } // void EXTI4_IRQHandler(void) //Кнопка вращения двигателя вниз { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_4); if(HAL_GPIO_ReadPin(GPIOD,GPIO_PIN_4) == GPIO_PIN_SET) //Если высокий уровень, то ничего не делаем { asm("nop"); } else //В противном случае выдаём семафор { xSemaphoreGiveFromISR(sem_curr_downHandle,NULL); } } Задача, в которой я собираюсь вращать двигателем, выглядит так: void poll_button(void const * argument) { for(;;) { if(xSemaphoreTake(sem_curr_upHandle,portMAX_DELAY) == pdPASS) //Если семафор на вращение вверх принят функцией и равен одному (время ожидания семафора максимальное) { HAL_GPIO_WritePin(GPIOA,GPIO_PIN_9,GPIO_PIN_SET); } else if(xSemaphoreTake(sem_curr_downHandle,portMAX_DELAY) == pdPASS) //Если семафор на вращение вниз принят функцией и равен одному (время ожидания семафора максимальное) { HAL_GPIO_WritePin(GPIOA,GPIO_PIN_10,GPIO_PIN_SET); } } } В качестве отлаживающего механизма использую светодиоды (их и пытаюсь зажечь на отладочной плате в зависимости от полученного семафора), но после прошивки платы ничего не происходит. Я понимаю, что код ещё не дописан, так как после отжатия кнопки мне надо вернуть семафор обратно (правильно ли - "вернуть"?), но по идее данная конструкция уже должна его "выдать", а задача - "принять", и в соответствии с этим что-то сделать. Поэтому мои вопросы заключаются в следующем: 1. Правильна ли моя идея с использованием семафоров в принципе для данной ситуации? В любом случае, эту ОСРВ мне надо изучать по работе; 2. После отдачи семафора по нажатию кнопки - как его вернуть обратно после её отжатия? 3. Задача poll_button не реагирует на полученный семафор. Если в одном из условий изменить "== pdPass" на "!= pdPass", то светодиод будет гореть, но если так сделать в двух условиях, то всё равно будет гореть только один светодиод, будто бы задача по какой-то причине зависает. Что это может быть? Заранее всех благодарю за ответы.

Доброго времени суток! Пытаюсь запустить FreeRTOS на NUC980 на отладочной плате NuMaker-Server-NUC980 (https://www.nuvoton.com/products/iot-solution/iot-platform/numaker-server-nuc980/). В репозитории NUC980_NonOS_BSP есть пример проекта (https://github.com/OpenNuvoton/NUC980_NonOS_BSP/tree/master/SampleCode/FreeRTOS). Проект собранный в Keil запускается и работает без проблем. Стартует и в отладке и при записи на SPI NAND Flash. Проблемы возникли c запуском прошивки собранной с помощью GCC. Если загрузить образ используя NuWriter в ОЗУ, то он стартует и работает нормально, а вот если его записать во Flash, то он стартует и работает до первого отключения питания платы. Если после подачи питания на плату выполнить соединение с NuWriter, при этом ни чего не загружать в контроллер, а просто перевести его в режим загрузки с SPI NAND переключателем на плате и нажать кнопочку reset, то образ, ранее записанный во Flash начинает запускаться нормально (до следующего сброса питания). Так же образ GCC если перед этим запустить любым из доступных способов образ собранный в Keil. Т.е. отличия, скорее всего, заключаются в начальной инициализации. Стартапы Keil и GCC отличаются тем, что для GCC инициализация векторов прерываний и очистка секции bss выполняется в в самом стартапе, а для keil это делается процедурой __main. GCC startup.S: Keil startup.s: При отладке вижу следующее: Запускается Scheduler FreeRTOS и передает управление первой задаче vCheckTask. В этой задаче вызывается vTaskDelayUntil(). Отработав,vTaskDelayUntil() вызывает portYIELD_WITHIN_API() (task.c строка 1275), т.е. `asm volatile ("SWI 0\n"`. Но вместо прерывания по вектору SWI_Handler (vPortYieldProcessor) вызывается прерывание по вектору Undef_Handler. Подскажите, пожалуйста куда копать.

Привет всем страждущим комфорта в программировании. Всем известно, что FreeRTOS отлично компилируется под отечественные 1986ВЕ1Т и 1986ВЕ3Т. Но немецкая пунктуальность товарищей из ARM не позволяет простым юзерам из России так вольготно конфигурировать свои проекты, да и с нашей отечкой они скорее всего слабо знакомы. Поэтому если вы используете в своих проектах вышеуказанные процы, то для них вы не сможете выбрать FreeRTOS напрямую в Manage Run-Time Environment. Он вам просто не даст это сделать поскольку... ну это же Cortex-M1. А FreeRTOS нативно понимает только или Cortex-M0 или M3, ну и там остальные по списку к делу не относящиеся. Хмм... Конечно подключение FreeRTOS к проекту вручную не требует особо много телодвижений. Достаточно скопировать пару папок и настроить инклуды. Но, как известно, программисты - самые ленивые существа. Иногда хочется просто поставить галочку для FreeRTOS как это описано тут для 1986ВЕ9x. Вот с этой целью я для себя подкорректировал конфигурационный файл пакета Keil. И теперь он стал узнавать наши 1986ВЕ1Т и 1986ВЕ3Т и даёт конфигурировать FreeRTOS как обычно. Это очень удобно особенно если вам приходится создавать много мелких пробных проектов с FreeRTOS. Файл прилагаю во вложении. Может кому и пригодится. Для того чтобы им воспользоваться нужно в папке установки библиотек, по умолчанию это C:\Users\$USER\AppData\Local\Arm\Packs\ARM\CMSIS-FreeRTOS\10.3.1, сделать снять режим "Только для чтения" с файла ARM.CMSIS-FreeRTOS.pdsc. Потом переименовать его в ARM.CMSIS-FreeRTOS.pdsc.bak. Так мы сделали резервную копию. (Всегда делайте резервную копию всего что изменяете ) Затем копируете приложенный файл в указанную папку. И перезапускаете Keil. Теперь у вас есть FreeRTOS для 1986ВЕ1Т и 1986ВЕ3Т. PS: Работает для последней на данный момент версии FreeRTOS 10.3.1 в Keil 5.31. Файл даётся на правах "AS IS". Ответственность на использующем. ARM.CMSIS-FreeRTOS.pdsc

Здравствуйте, Для ускорения работы, нужен программист микроконтроллеров. Делаем прибор, который состоит из контроллера и шины Modbus (RTU), на которой висит несколько устройств (датчики, реле, 4-20 и т.п.). Контроллер на STM32, с дисплеем 800х480. GUI реализован на STemWin. Все это работает под FreeRTOS. Язык разработки Си. Для вспомогательных целей используем Python (в основном утилиты командной строки, максимум - MatPlotlib или PyGame, графики вывести). Для контроля версий пользуемся GitHub. Если не хватает одного-двух навыков из перечисленного - не беда, подскажу/помогу. Сам прибор реализован, основной функционал выполняет. Теперь на его базе нужно реализовать родственный прибор, с похожими функциями. Работа по договору подряда. Возможны и другие формы взаимодействия, от ИП до мордобоя трудоустройства, а если у исполнителя статус "самозанятый", руководство и бухгалтерия будут в восторге. Находимся на юге Москвы, пара км за МКАД. Связь через почту, здесь бываю редко. offer.6303@gmail.com

Доброго времени суток, уважаемые коллеги! Встала задача принимать пакеты из UART и передавать их в сеть. Запустил задачу-сервер на Socket API из примера ST, проверил, send - receive работает. Но когда дело дошло до реальной реализации, выяснилось, что функции accept и receive намертво блокируют задачу. Блокировку функцией accept решил вот такой нехитрой конструкцией: if (accept_state==0){ newconn = accept(sock, (struct sockaddr *)&remotehost, (socklen_t *)&size);//принимаем входящее подключение accept_state=1; } То есть, сервер принимает только одно входящее подключение. Общий вид главного цикла задачи-сервера: while (1) { if (accept_state==0){ newconn = accept(sock, (struct sockaddr *)&remotehost, (socklen_t *)&size);//принимаем входящее подключение accept_state=1; } event=osMessageGet(UART_RX_QHandle,10);//получаем указатель на структуру, которую нужно передать в сокет if (event.status==osEventMessage){ printf ("Queue received at %lu\r\n", osKernelSysTick()); pDataToSend=(UART_RX_Data*)event.value.v; HAL_GPIO_TogglePin(LD2_GPIO_Port,LD2_Pin); send(newconn, pDataToSend->payload, pDataToSend->size, 0);//отправляем данные в сокет HAL_UART_Receive_IT(&huart3,uartRXBuffer,UART3RX_BUF_SIZE);//включаем приём в UART printf ("Switch context at %lu\r\n", osKernelSysTick()); osThreadYield(); } } в общем, циклично, по приходу пакета в UART, в задачу-сервер через очередь передается указатель на данные, которые нужно отправить в сокет. Вот теперь возникли два вопроса. Первый - как корректно завершить соединение по запросу от клиента? Попробовал сделать так: nbytes=recv(newconn, rxBuf, BUFLEN, MSG_PEEK); if (nbytes<=0){ close(newconn); } Сразу перестала работать очередь, потому что функция recv наглухо блокирует задачу. Что подскажете? И второй вопрос. Как отслеживать физический дисконнект? Может, кто уже решал эту задачу?

В небольшой коллектив ищем программиста с уверенным владением C/C++ на удаленную работу . Для проекта встраиваемого устройства необходимо дорабатывать и поддерживать текущий аппаратно-независимый код (написан на C и C++). Текущие задачи включают в себя работу с графической библиотекой TouchGFX, работу с AT библиотекой ESP8266, а также работу с сетевой частью и сервером (C#). Также есть и другие задачи, связанные с IoT (Bluetooth Mesh). Для тех, кто из Санкт-Петербурга есть возможность посещать или работать у нас в офисе. Требования: Уверенное владение C/C++. Базовые навыки работы с C# кодом. Базовая работа с git. Базовые знания цифровой схемотехники. По времени 40+ ч. Совещания дважды в неделю по скайпу. Желательно уметь разговаривать, хотя-бы, на ломанном английском. Писать сюда. Либо на почту andrew.verzhakovskyi@komfortiq.com

Здравствуйте, система на MAX10 с использованием Nios, на Nios рабтает FreeRTOS. Использую TCP/IP стек FreeRTOS. Nios на 50 MHz входной частоты давал скорость пеердачи по TCP 10 Мбит, с оптимизациями O2 (без них ~5-6). Увеличил частоту Nios до 100 MHz, скорость выросла до 12 Мбит(с оптимизациями). TSE и SGDMA работают на частоте Nios. Памяти много, 16MB sdram, 100MHz. Видел пример альтеры по ускорению Ethernet, система у них работает на 100 MHz, и без оптимизаций выдает скорость ~22 Мбита, а с оптимизациями от 50 до 80 МБит. Не могу понять где узкое место и почему увеличивая тактовую частоту в 2 раза такой маленький прирост. Может кто-то сталкивался или посоветует куда копать?