AV
на отдачу то зачем? вызвали функцию отправки байтов, она сразу вернула и все
Size: a a a
2020 November 10
AM
на отдачу то зачем? вызвали функцию отправки байтов, она сразу вернула и все
Обработка принятого и отправленного в одном таске.
Распаковать\запаковать.
Всякие CRC посчитать.
Распаковать\запаковать.
Всякие CRC посчитать.
AV
Обработка принятого и отправленного в одном таске.
Распаковать\запаковать.
Всякие CRC посчитать.
Распаковать\запаковать.
Всякие CRC посчитать.
что значит обработка отправленного? Наверное логика выше должна пакет для передачи сформировать
AV
Это будет выполняться в контексте таска логики, а не уарта
AM
что значит обработка отправленного? Наверное логика выше должна пакет для передачи сформировать
Если так. То получается у нас просто таск, который из очереди уарта кладет в очередь обработчика.
Он вообще лишний же.
Он вообще лишний же.
AV
Если так. То получается у нас просто таск, который из очереди уарта кладет в очередь обработчика.
Он вообще лишний же.
Он вообще лишний же.
Какой именно очереди? приема или передачи?
AM
Какой именно очереди? приема или передачи?
Да любой.
Тот таск который готовит данные для отправки, может вполне пихать их в очередь UART
Таск обрабатывающий данные, может их сразу забирать из UART
Тот таск который готовит данные для отправки, может вполне пихать их в очередь UART
Таск обрабатывающий данные, может их сразу забирать из UART
AV
Да любой.
Тот таск который готовит данные для отправки, может вполне пихать их в очередь UART
Таск обрабатывающий данные, может их сразу забирать из UART
Тот таск который готовит данные для отправки, может вполне пихать их в очередь UART
Таск обрабатывающий данные, может их сразу забирать из UART
Он так и делает, готовит полный пакет данных и скармливает драйверу, драйвер их копирует себе в буфер и занимается отправкой уже внутри себя, а функция отправки взвращает обратно
AV
А чтобы принять данные нужен таск. В уарте же лежат просто байты, а надо их преобразовать в пакеты данных и передать payload логике выше.
AM
Он так и делает, готовит полный пакет данных и скармливает драйверу, драйвер их копирует себе в буфер и занимается отправкой уже внутри себя, а функция отправки взвращает обратно
Да. С отправкой тут все отлично. Пришли данные из очереди на отправку, обработали, толкнули в UART. Уснули.
AM
Если бы у UART очереди был такой же хендл как и у сущностей фриртос.
Можно было бы сделать 1 таск.
Который просыпался бы по одному получению данных и ИЗ и ВНЕ.
Можно было бы сделать 1 таск.
Который просыпался бы по одному получению данных и ИЗ и ВНЕ.
AV
А чтобы принять данные нужен таск. В уарте же лежат просто байты, а надо их преобразовать в пакеты данных и передать payload логике выше.
Но, это уровень школьника. Студент, при желании, напишет кастомный вектор прерывания для конкретного модуля уарта и скормит его при конфиге драйвера. А дальше уже обработка будет происходить по прерываниям самого уарта
AM
Но, это уровень школьника. Студент, при желании, напишет кастомный вектор прерывания для конкретного модуля уарта и скормит его при конфиге драйвера. А дальше уже обработка будет происходить по прерываниям самого уарта
Разговор про то, что родное апи уарта не умеет такого, т.к. не до конца срослось с фриртосными сущностями.
AM
Я и ожидал, может кто знает и хендл очереди можно получить как то.
AV
Разговор про то, что родное апи уарта не умеет такого, т.к. не до конца срослось с фриртосными сущностями.
На самом деле, у esp одно из самых крутых апи драйверов. А при желании можно ещё и допилить что нужно и переписать компонент сдк! Куда уж лучше то?
AM
Крутое АПИ - которого не возникает желание переписывать =)
AV
Крутое АПИ - которого не возникает желание переписывать =)
Ну дак используйте регистры и переписывать ничего не нужно 😄
AM
Ага или ардуино фреймворк =)
AV
А дальше уже каждый хочет какую-то фичу для себя, но всем то не угодить
AV
вот и дали возможность менять