Не уверен, куда это поместить.

Я нашел замечательный канал на YouTube https: // www.YouTube.com/Channel/uc-cuj6 ... K3Q/Video у которого есть действительно хорошо сделанный учебник.
Один из этих учебников показывает, как настроить бесплатные RTO и три простых потока, используя USART.

Теперь поток показывает только написание в серийном порту. Я собираюсь переехать из моего дома запеченного микро -Кернала, написанного в сборке AVR. Я мог бы перенести это в STM32, но зачем повторно изобрести колесо.

Контроллер органов трубы превратился из гибкого диска MIDI Player. (который использовал действительно убитый порт ASM от POSIX DIRMANT и требует планирования.)

В любом случае система настроена с командами заднего канала. Таким образом, основной поток ждет ввода пользователя. Есть еще одна нить высокого приоритета, которая сканирует входы клавиатуры. Третий потоки очередите выходы. Только поток сканера ключей синхронно, а на ПК-версии связана с вертикальным обновлением. На версии Micro Control это связано с MIDI -часами.

Итак, мой вопрос в том, что делаю это с RTOS. А именно в простаивании потока по умолчанию опрашивает сериал и в очереди его. У меня есть EOL CR, он обрабатывает команду и может запускать или породить другие потоки, которые могут стоять в очереди в списке действий, который очереди на таймер. Нить приоритета опрашивает клавиатуры, а затем спит до следующего таймера. Если есть действия для обработки, они тоже отложены и будут работать в списке.

В любом случае в основном пользовательском потоке, который наблюдает за последовательным обратным каналом, есть ли стандартный способ обработки последовательного ввода? Большую часть этого времени это забурена в командную строку, однако, есть коды побега (буквально), которые должны обрабатывать с более высоким приоритетом.

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

Я предполагаю, что вопрос в том, сколько за буферизации сериал обрабатывается в синтаксисе Freertos, какие функции вызываются. Я не уверен, что можно использовать мутекс для ввода так, как он используется в вышеуказанном учебнике для вывода. Команды порождают потоки, которые имеют настройку, и их собственный цикл опроса. Это потоки деконструированы, и их ресурсы выпускаются, когда завершены, вероятно, для сохранения пространства памяти, которое заполнено динамическими таблицами. Некоторые темы более постоянны, чем другие. Большинство сидят в своих бездельничальных петлях или просто состоят из инструкции по возврату.

Я на самом деле реализовал часть пользовательского интерфейса в PostScript (который основан на значении стека/ ключа.) Теперь я пытаюсь преобразовать самодокументирование PostScript в C с оригинальной сборкой 68 тыс.


Я думаю, что у меня есть ответ здесь ищу вопрос, но в каком вопросе я хочу задать просто?

Проблема в том, что я увязаю с примером кода (у меня всегда есть неверная доска/процессор) Приведенный выше учебник хорош, но он остается вырезанным и вставленным. Что, вероятно, большинство современных программ. В любом случае, если у кого -нибудь есть совет, как пройти через некоторые из них (или написать более короткие более целенаправленные вопросы), я открыт для предложения.

Джули,

Я обнаружил, что ресурсы Freertos неоценимы, отвечая на мои вопросы относительно его реализации в порту Arduino в ESP32.
https: // www.Freertos.org/documentation/rtos_book.HTML

Луча

Спасибо за ссылку.

Мои поиски продолжают возвращать меня на этот сайт, который представляет собой замечательный набор ответов в поисках вопросов.

Есть много информации для переваренного.

Основная проблема в этих учебниках, почему мне нравится https: // www.YouTube.com/Channel/uc-cuj6 ... K3Q/Video Примеры заключаются в том, что они не построены с использованием проектов Hal Cubemx. Где они используют флаги кода пользователя. Это тоже большой недостаток примеров STM. Отсутствие проекта Cubemx.

Я думаю, что я ищу довольно просто. У меня есть код рабочей сборки для конвертации в C. Это реализует RTOS. Таким образом, большая часть процесса составляет картирование функций ASM низкого уровня (где можно увидеть структуры данных.) до вызовов и обратных вызовов высокого уровня и обратных вызовов.

Базовый последовательный вход - кольцевой буфер. Существуют способы вызвать различные процедуры последовательного ввода, поэтому фактический вызов - это указатель в массиве, который называется из ISR. Как отмечалось, существует задача с высоким приоритетным сканированием, которая работает с фиксированным интервалом. Серийная задача проверяет данные в. Если в нем нет данных об изменении задачи сканирования. Сканирующее TAKS проверяет, если пришло время сканировать, если это слишком рано, он возвращается к сериалу в задаче.

Фактический серийный прием обрабатывается в ISR. Все, что это делает, это посмотрите на фиксированное местоположение (массив драйверов) для указателя на подпрограмму серийного ввода.

Я нашел несколько примеров через Freertos.орг и ссылки на репозитории GitHub, однако, в отличие от видео с Myaqoobembed, они очень быстро становятся очень сложными и имеют много ответов на вопросы, которые я не задаю.

В коде ASM вызов просто называется Swap (), который заменяет текущую задачу. Тогда код ASM выглядит, чтобы увидеть, есть ли новые данные на кольце. Это в значительной степени праздничная петля. Когда возврат найден, командный анализатор анализации строки команды. (которые могут породить другие задачи, которые функционируют окно управления и могут отвечать на символы управления клавиатурой, такие как клавиши со стрелками функциональных клавиш и клавиши пьесы.) Каждое задание хранит графический интерфейс окна (в кодах выхода из терминала ANSI), а также текущее местоположение курсора на экране.) Большинство проанализированных функций блокируются в режиме редактирования. Есть также режимы запуска, которые блокируют некоторые задачи редактирования.

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

Это всего лишь 2 цента, я попытался использовать RTO на STM32F103, я наткнулся на пару проблем
1) Заканчивается память
Это частично память сильно фрагментирована, так как каждая vtask должна зарезервировать некоторое пространство стека, и на самом деле я думаю, что его блок зарезервирован
И у нас есть только 20 тыс. Для всего на STM32F103
2) Мы часто случайно призываем к функциям «не RTO», такие как серийные.println ("Привет, мир");
Уловка - это те функции «не RTO», которые не могут быть безопасными потоком, и вряд ли будет безопасным потоком
Я полагаю, что RTOS дает каждому VTASK 1 мс времени и (контекст) SWTICH между VTASKS, это может создать ситуации улова
Где вы пишете в какую -то (общую) память и следующую Vtask, которая оживает, напишите в одну и ту же память
Особенно для функций «не RTOS»

В конце концов я разработал этот довольно сложный цикл событий !
ViewTopic.PHP?F = 18&T = 4299
Поскольку цикл событий выполняет кооперативную многозадачность (нет контекстного переключателя), каждая функция является нормальной функцией C или методом C ++.
он бежит до конца и возвращается. Если ваша функция или метод не возвращаются, все остальные задачи удерживаются,
Таким образом, вам нужно явно сохранить состояние и уход, чтобы другие задачи получали шанс запустить

Более простая форма этого цикла событий - это то, что я назвал планором Round Robin, который является не чем иным, как вызов каждой из функций в Loop ()
ViewTopic.PHP?F = 18&t = 2117

И одна из этих вещей в том, что я зацепил событие Systick, чтобы установить флаг, вы можете взглянуть на этот круглый планировщик Robin
Это так, что я называю функции только тогда, когда Systick Interrup.эн. Каждое 1 мс, так как это то, что есть в Libmaple)
Если это какое -то другое прерывания, я просто забегаю («WFI») и ждал следующего (систика) прерывания, я.эн. Сон, следовательно, сберегает силу

И в чем польза от этой «кооперативной» многозадач?
Нет контекста, вы планируете и выполняете все в правильной последовательности и правильно держите все состояния в каждом вызове функции
Это контролирует все зависимости * последовательно * - следовательно, блокировки/семафоры ненужны, и он сохраняет * много памяти, так как все хранится в одном стеке, стек (и эти локальные переменные) автоматически разворачивается каждый раз, когда функция / Метод возвращает (C, C ++ делает все это)

A * Sequential * Ploop Event работает, но жертвовать производительности? Да и нет
Просто посмотрите на Java и Swing
https: // docs.оракул.com/javase/учебное пособие ... пластырь.HTML Код обработки событий Swing работает на специальном потоке, известном как поток для отправки событий. Большинство кодов, которые вызывают методы свинга, также работает в этой теме. Это необходимо, потому что большинство методов Swing Object не являются «поток безопасны»: вызывая их из нескольких потоков рискованные помехи или ошибки согласованности памяти. Даже качающий графический интерфейс не является полностью многополосовым в тот самый день и эпоху, когда у нас есть процессоры до 128 высокопроизводительных суперкаларных ядер, возможно, способны на петафлопс
Только одна самая медленная нить запускается на крошечном потоке на этом ядре всей этой мощности обработки, удерживая всю вселенную
Я думаю, что это даже верно в отношении тех тестирования Google / Microsoft Tuging Test, нарушающего глубокое изучение AI глубокие нейронные сети, эти нейронные сети используют тысячи ядер CUDA GPU, возможно, используют Petaflops of Power для выполнения одного итерационного обновления миллиарды штатов и весов в сети.
Но стохастический градиент спуск осуществляется на * не линейном * ландшафте данных, и вам просто нужно сделать один шаг за раз в надежде найти это «дно»
Постарайтесь предпринять большие шаги или параллелизировать вещи, и вместо этого вы можете просто спуститься в хаос и никогда не сходиться

Так оно и есть, но последовательно решает проблему замков и семафоров
И это больше, чем на STM32F103 с 20K SRAM, который будет использоваться среди всех «задач»
И я на самом деле использовал свой собственный цикл событий, упомянутый

Следующим шагом является то, чтобы каждый «процесс» в цикле событий работал как Корутика.

Наиболее эффективным методом является реализация его в форме автомата конечного состояния, который выполняет код в текущем состоянии на каждом цикле, затем возвращает ЦП обратно в основной цикл. Максимальное время, которое вы разрешаете каждому данному состоянию, даст вам «мягкую задержку».

Если вы предпочитаете написать свой код в линейной резьбе, вы можете использовать протототонированные сделать синтаксический сахар на вершине.

Кроме того, не забудьте отделить четкую обработку IRQ в отдельный домен от основного цикла событий и преобразовать каждое прерывание в очередное событие (FIFO). Максимальное время, которое вы проведете последовательно в домене IRQ, даст вам «жесткую задержку».

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

Я на самом деле реализовал на AT90S8515 не меньше полной микрокерской с очередями сообщений и семафорами. Помогло то, что у меня было 128 тыс. Внешнего SRAM. Это был для гибкого диска, который использовал драйвер типа POSIX. Получил своего рода громоздкий.

В эти дни я склонен сохранять все в цикле событий. В основном для статической отладки. В C каждый вызов генерирует рамку стека, которая на MEGA328 быстро ест память. Так что да, я вижу, откуда поступают предложения.

Я конвертировал часть пользовательского интерфейса кода для запуска в PostScript (выплевывая коды терминалов ANSI на задний канал, а не рисовать на страницу рендеринга. Так что я, вероятно, мог бы просто управлять структурами потока в качестве 68 -километрового кода ASM. Это больше, так как я пишу это с нуля, я хотел использовать более современный API.

У меня также есть несколько фрагментов кода из последней версии программы для Windows. Однако они записаны в C ++ и используют шаблоны и перегрузку оператора, не говоря уже о Windows stdaFX и все накладные расходы на окна. Я действительно хочу более портативное решение C.

Одна из проблем с циклом событий заключается в том, что он заставляет обработку государств загадочным, как в основном можно думать с точки зрения переходов состояния и кодирует переключатель или блок операторов if-else для обработки переходов состояния.
Чтобы сделать жизнь проще (для себя, я надеюсь для других), я создал этот *цикл событий *
ViewTopic.PHP?F = 18&T = 4299
И одна из тех вещей, о которых я думал, - это утилита Asyncwait (), который я сделал как часть этого.
так что мигает выглядит так
https: // github.com/ag88/stm32duino-evon ... Эдтаск.CPP #define TX_BUF_SIZE 64 #define RX_BUF_SIZE 64 char rxBuf[RX_BUF_SIZE]; char txBuf[TX_BUF_SIZE];

Посмотрите на мою ссылку Protothreads выше и Как они действительно работают. Они эффективно маскируют ужас State Machine в классический поток программирования, похожий на нить. Это стоит всего 1 слово за поток.

Спасибо, я проверил протототонированные, это, возможно, лучший способ и может потреблять меньше памяти

Кстати, то же самое Устройство Даффа Используется в прототчиках может использоваться для внедрить Coroutine в C слишком.

Интересные вещи, я не возвращался, чтобы читать эти вещи Дональда Кнута годами, может быть, мне следует прочитать их снова, в последний раз я немного прочитал и заснул (это довольно густо), а затем оставил усилия
Дональд Кнут несколько критиковал многоядерных процессоров . Я мог бы также немного посвятить свое личное несчастье с текущей тенденцией к многоядерной архитектуре. Для меня это выглядит более или менее похоже на то, что у дизайнеров аппаратного обеспечения не хватает идей, и что они’Попытка передать вину за будущую кончину Мура’Закон авторам программного обеспечения, предоставляя нам машины, которые работают быстрее только на нескольких ключевых тестах! Я выиграл’Вообще удивлен, если вся идея многопоточного чтения оказалась провалом, что хуже, чем подход «Итания», который должен был быть настолько потрясающим-пока оказалось, что заслуженные компиляторы в основном невозможно написать. К сожалению, это все еще очень много современного искусства, и, что еще хуже, Multi-ядерные становятся тысячами (GPU CUDA) для миллионов ядер
Миллион ядер рук для симулятора мозга
https: // www.eetimes.com/документ.аспирант?doc_id = 1266450
https: // www.allaboutcircuits.com/news/s ... прозрачный/
https: // hothardware.com/news/spinnaker- ... Uman-Brain
Я не уверен, где это много основного и огромного количества ядерных безумия приведет нас. Казалось, суперкомпьютеры будущего - это новые алюминиевые плавицы, использующие миллионы усилителей и гигаватт, но не для того, чтобы растопить алюминий, а пытаться запустить как можно больше сердечников, я не уверен, достаточно ли жар, чтобы вызвать ядерное слияние

Да, Искусство компьютерного программирования Хорошая книга

Я считаю, что это могло уже начать. Гипер-тренер уже идет по пути Dodo: оказывается, что оно принципиально несовместимо с безопасностью процессора.

Мои книги Кнут, пошли в армию спасения, когда я переехал и пришлось сократить несколько вещей.

Лично я никогда не был большим поклонником резьбового программирования. Хотя я порезал зубы на системе таймшера HP. Однако он имеет его использование, даже если это больше иллюзия. Отладка - это немного работы, так как никогда не знает, что делает другой поток, если только кто -то не углубится в саму саму.

Микрокерна, которую я написал много лет назад на основе книги под названием C, а 8051 был круглым Роббином. Единственная превентивная вещь, которую мне когда-либо нуждались в серийном канале задней части. Что я думаю, является основой того, что я все еще ищу.

Я нашел несколько интересных учебных пособий по сериалу с чувствительностью DMA и простоя для получения асинхронных данных . Я также обнаружил, почему я не получал сериал от своего Nucleo 401. Я вытащил ремни TX и RX со стороны ST Link. Я сделал это с моим F103 Nucleo (которое я, кажется, неуместен.) использовать альтернативный последовательный порт. На Nucleo F401 есть два дополнительных ремешка для перемещения UART2 TX и RX на выводы Arduino/Morpho. Таким образом, часть проблемы была аппаратным, а не программным обеспечением.

Я склоняюсь к тому, чтобы сохранить раунд -планировщик Роббин из кода 68 км ASM, поскольку он привязан к графическому интерфейсу. В нем каждая задача имеет стек и окно. Однако означает, что мне нужно научиться вручную перемещать указатель стека, если я не сохраняю механизм потока RTOS.

Есть чему поучиться, и я благодарен за обсуждения здесь, пока они существуют.

На STM32 (F103) я обнаружил, что с помощью аппаратного обеспечения USART вам нужно явно проверить ошибки кадрирования и ошибки паритета в настройке по умолчанию
ViewTopic.PHP?F = 53&P = 53734
В противном случае байты с ошибками кадрирования или ошибки паритета передаются вместе с допустимыми данными
Это путает довольно много приложений, так как, по -видимому, приложения предполагают чистый канал данных, который передаются только допустимых данных
Тот 2 патча Liner, который я сделал, чтобы проверить ошибки кадрирования и ошибки паритета, что было видимым разницей, по крайней мере, с STM32Loader
После этого патча он работает каждый раз, ранее, до того, как у меня было много ошибок, и мне было интересно, что не так с моим эскизом, который выполняет работу с USB-сериалом

Это может помочь, если вы вмешаетесь в USART, STM32F103 является хорошей альтернативой FT232 или даже FTDI 2232H Serial Bridge, у него есть все это аппаратное обеспечение, если кто -то хочет сделать USB - USBART (x3), SPI (x2), i2c (x2 ), Can, ADC и, как правило, мосты GPIO, все, что нужно в середине, это то, что прошивка или ваш эскиз. И STM32F103 (очень) более способен, чем USB -серийный мост

[Sheepdoll - Ср 13 марта 2019 г., 16:31] - Лично я никогда не был большим поклонником резьбового программирования. (...)
Я склоняюсь к тому, чтобы сохранить раунд -планировщик Роббин из кода 68 км ASM, поскольку он привязан к графическому интерфейсу. В нем каждая задача имеет стек и окно. Однако означает, что мне нужно научиться вручную перемещать указатель стека, если я не сохраняю механизм потока RTOS.

Я имел большой успех в кооперативном планировщике. Я использую объектно -ориентированную версию, которая позволяет мне разделить все на классы и библиотеки, причем единственная конфигурация - объявление (пройти экземпляр планировщика). Это имеет плотные ограничения (наибольшее время обработки для каждой задачи = минимальное гарантированное время отклика), но накладные расходы настолько низки, что я легко использую его на Attega или Maple Mini.

[Sheepdoll - Ср 13 марта 2019 г., 16:31] - Есть чему поучиться, и я благодарен за обсуждения здесь, пока они существуют.

Искренне согласен.