Здравствуйте. Возможно ли сформировать QueueSet из IDF-шного API юарта?

Ну или какой нибудь другой способ встать в ожидание ИЛИ данных из UART ИЛИ мутекса\очереди одновременно

Что хочу: 1 таск и на отправку данных UART и на получение. Иначе приходится 2 делать, т.к. один встает в ожидание данных из UART, а другой данных из очереди на отправку.

Что хочу: 1 таск и на отправку данных UART и на получение. Иначе приходится 2 делать, т.к. один встает в ожидание данных из UART, а другой данных из очереди на отправку.

Так в прерывании по приёму кладите в очередь

Так в прерывании по приёму кладите в очередь

Я не осилил пока кастомный драйвер UART =)

А на отправку надо неблокирующее получение делать

Я не осилил пока кастомный драйвер UART =)

Они же там в исходниках все

Просто допилить существующий, как вам надо

Вообще пока борцую с самой FreeRTOS и C++, чем именно с ESP железом и самой IDF.

Это же не writing from scratch )

Просто допилить существующий, как вам надо

Ну вот я ожидал из коробки как нибудь. =)

Я через 2 очереди делал на stm32. Так-то карты у всех процов практически одинаковые и набор флагов, их оьслуживающие

Мне вообще странным кажется, что китайцы IDF апи до конца с фриртосом не сростили =\

Какое то не рыба не мясо помоему.

Мне вообще странным кажется, что китайцы IDF апи до конца с фриртосом не сростили =\

Весь драйвер уарта адаптирован для фриртоса. Драйвер уже имеет тх буфер, нужно при конфиге драйвера указать размер буфера передачи. Таким образом Вам нужен 1 так на прием и все

Весь драйвер уарта адаптирован для фриртоса. Драйвер уже имеет тх буфер, нужно при конфиге драйвера указать размер буфера передачи. Таким образом Вам нужен 1 так на прием и все

Так было бы круто 1 и на прием и на отдачу. Там делов то =\ Но юарт хендл своей очереди не дает и не возможно его в QueueSet добавить.

на отдачу то зачем? вызвали функцию отправки байтов, она сразу вернула и все

на отдачу то зачем? вызвали функцию отправки байтов, она сразу вернула и все

Обработка принятого и отправленного в одном таске. Распаковать\запаковать. Всякие CRC посчитать.

Обработка принятого и отправленного в одном таске. Распаковать\запаковать. Всякие CRC посчитать.

что значит обработка отправленного? Наверное логика выше должна пакет для передачи сформировать

Это будет выполняться в контексте таска логики, а не уарта

что значит обработка отправленного? Наверное логика выше должна пакет для передачи сформировать

Если так. То получается у нас просто таск, который из очереди уарта кладет в очередь обработчика. Он вообще лишний же.

Если так. То получается у нас просто таск, который из очереди уарта кладет в очередь обработчика. Он вообще лишний же.

Какой именно очереди? приема или передачи?

Какой именно очереди? приема или передачи?

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

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

Он так и делает, готовит полный пакет данных и скармливает драйверу, драйвер их копирует себе в буфер и занимается отправкой уже внутри себя, а функция отправки взвращает обратно

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

Он так и делает, готовит полный пакет данных и скармливает драйверу, драйвер их копирует себе в буфер и занимается отправкой уже внутри себя, а функция отправки взвращает обратно

Да. С отправкой тут все отлично. Пришли данные из очереди на отправку, обработали, толкнули в UART. Уснули.

Если бы у UART очереди был такой же хендл как и у сущностей фриртос. Можно было бы сделать 1 таск. Который просыпался бы по одному получению данных и ИЗ и ВНЕ.

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

Но, это уровень школьника. Студент, при желании, напишет кастомный вектор прерывания для конкретного модуля уарта и скормит его при конфиге драйвера. А дальше уже обработка будет происходить по прерываниям самого уарта

Но, это уровень школьника. Студент, при желании, напишет кастомный вектор прерывания для конкретного модуля уарта и скормит его при конфиге драйвера. А дальше уже обработка будет происходить по прерываниям самого уарта

Разговор про то, что родное апи уарта не умеет такого, т.к. не до конца срослось с фриртосными сущностями.

Я и ожидал, может кто знает и хендл очереди можно получить как то.

Разговор про то, что родное апи уарта не умеет такого, т.к. не до конца срослось с фриртосными сущностями.

На самом деле, у esp одно из самых крутых апи драйверов. А при желании можно ещё и допилить что нужно и переписать компонент сдк! Куда уж лучше то?

Крутое АПИ - которого не возникает желание переписывать =)

Крутое АПИ - которого не возникает желание переписывать =)

Ну дак используйте регистры и переписывать ничего не нужно 😄

Ага или ардуино фреймворк =)

А дальше уже каждый хочет какую-то фичу для себя, но всем то не угодить

вот и дали возможность менять

Я и ожидал, может кто знает и хендл очереди можно получить как то.

Ну а тут чисто кастомный вектор прерывания и будет такое

Но, это уровень школьника. Студент, при желании, напишет кастомный вектор прерывания для конкретного модуля уарта и скормит его при конфиге драйвера. А дальше уже обработка будет происходить по прерываниям самого уарта

Почему-то ppp демон использует стандартные вызовы драйвера последовательного порт, а не пытается щемиться к 16550 самостоятельно

Почему-то ppp демон использует стандартные вызовы драйвера последовательного порт, а не пытается щемиться к 16550 самостоятельно

Ну он же не использует промежуточный таск только чтобы читать данные, а обрабатывать их в другом месте

Унификация - вот ключ к переносимости. Сделайте вызовы для open, write, read, close, ionotify.

Ну он же не использует промежуточный таск только чтобы читать данные, а обрабатывать их в другом месте

Эти вызовы в ядре происходят, если мы про линуксовое ядро говорим, и по аналогии с ним.

Т.е. - да, отдельный таск

Я конкретно говорю про драйвер уарта на есп, ничего кроме :)

Я тоже. Похожий подход

Унификация - вот ключ к переносимости. Сделайте вызовы для open, write, read, close, ionotify.

это конечно правильно, но если вдруг встанет задача MDB какой-нибудь поднять на esp, тут уже нужно переписывать вектор прерывания

Сделайте системный таск, а в нём все драйвера крутятся

В qnx ядро отдельно, драйвера - отдельные таски (программы), пользовательское приложение - вообще третий таск

Ну дак ежей и ужей в кучу собирать не стоит, FreeRTOS то весьма простая система, смысла городить отдельных демонов для драйверов не вижу совсем. Проще привязать драйвер к логике которая с ним работает и вся работа по обмену байтами уже через эту логику

подскажите, можно вот эти платы поменять на что-то более актуальное? Есть под esp32 похожие шилды?

или может лучше в сторону stm смотреть?

Обычно выбор комплектации начинают с задачи, с целей которые нужно решать. Мы же не знаем какие у вас задачи и цели

Вряд-ли ваша задача по картинкам заменить одну плату на другую

Обычно выбор комплектации начинают с задачи, с целей которые нужно решать. Мы же не знаем какие у вас задачи и цели

цель - сделать робота валли, не сильно отходя от проекта https://www.thingiverse.com/thing:3703555 но это забугорное творчество, и они там могут себе позволить оригинальные ардуины. Мне же жалко даже 800р отдавать за плату контроллера под уно. потому как считаю, что можно сделать то же самое гораздо удобнее на чем-то вроде esp32. С Самими есп-шками знаком, а вот с модулями под движки/сервы еще не сталкивался, вот интересуюсь, возможно есть что-то из бест практис...

На картинке шилды для ардуино, то есть это то что добавляют к ардуино чтобы получить задуманный функционал. Думаю, к этим платам можно добавить есп и задуманный функционал сохранится

да, наверно, но шилды под ардуино распинованы под ардуино. А вот нет ли чего похожего под wemos ? Круто было б кконечно, если б ttgo сделали что-то похожее, но их магаз я просмотрел, не нашёл.

или может лучше в сторону stm смотреть?

В стм32 Шима больше и он более продвинутый, но wifi/bt в нём нет

В стм32 Шима больше и он более продвинутый, но wifi/bt в нём нет

но там наверно есть что-то из радиочастотного, дронов много на них клепают....

Stm32w серия

И ещё там какая-то Можно всегда прицепить трансивер внешний

Ышо есть nrf52 серия

Там и выводов побольше и вафля с блютусом

Касательно радиоуправления - обычно из задачи исходят, какая дальность и устойчивость нужна. И это основное. А потом уже, чипы, диапазоны...

И да, в дронах на стм32 приёмник внешний

На openinverter.org частотник с вебмордой. Частотник (то, что делает быстрый ШИМ по хитрому закону) - на stm32f103, вебморда - на esp8266

Можно и так. Т.е. строго на одном чипе прям - не обязательно.

есть кто пробовал использовать usb-c для питания. Если просто 5В то вроде просто. А если полное питание есть какие-то контроллеры так чтоб без микроконтроллера сами умели переключать ?

у Raspberry Pi 4 питание через usb-c ведь заведено, но там похоже просто 5В

есть кто пробовал использовать usb-c для питания. Если просто 5В то вроде просто. А если полное питание есть какие-то контроллеры так чтоб без микроконтроллера сами умели переключать ?

Скорее есть, чем нет. Стоит в сторону Power Delivery and Quick Charge 3.0/4.0 погуглить. Именно на предмет микросхем для них

На хабре недавно статья была, там QC 3.0 управляли с помощью стм32, чисто софт реализация, без специальной переферии

На хабре недавно статья была, там QC 3.0 управляли с помощью стм32, чисто софт реализация, без специальной переферии

я как раз наоборот интересуюсь, есть ли контроллеры быстрого заряда на полную мощность usb-c для которых не нужен микроконтроллер с драверами

На Али есть такие модули (причем как источник и как приёмник), соответственно и контроллеры есть :)

скорее всего нет, так как там целая процедура инициализации PD с выходом на 20В питания

На Али есть такие модули (причем как источник и как приёмник), соответственно и контроллеры есть :)

можно примеры кинуть?

скорее всего нет, так как там целая процедура инициализации PD с выходом на 20В питания

Именно этим контроллеры такие и занимаются

Именно этим контроллеры такие и занимаются

хорошо, верю, покажите

можно примеры кинуть?

В поиске али "type-c module"

На распбери пи4 просто 5В ,

дак а зачем ей больше? 5 в сейчас бывает до 3а. А если бы было 12 или 20 надо было бы dc-dc ставить и тд

дак а зачем ей больше? 5 в сейчас бывает до 3а. А если бы было 12 или 20 надо было бы dc-dc ставить и тд

так вы же говорите вот модули есть ?

В поиске али "type-c module"

находит просто платы с usb-c разъемом,