Приветствую всех,
Я хотел бы привлечь внимание к предметному PR (https: // github.com/rogerclarkmelbourne/ ... 2/Пуль/184), который обеспечивает после улучшения USART в библиотеке F1:

• Буферированная TX на основе прерываний: Поскольку большинство из вас знают, что библиотека F1 использует подход TX опроса, который имеет очень медленную производительность (даже хуже, чем на платформе UNO), TX на основе прерываний значительно увеличивает производительность TX
• Уровень времени выполнения RX/TX Динамическое распределение буфера: Как правило, библиотеки на основе Arduino используют подход к распределению статического буфера, это подразумевает выделение буферов для всех устройств, даже если они не используются; Динамическое распределение буфера на уровне выполнения позволяет вместо этого выделять буфер для единственных используемых устройств, а также позволяет пользователям легко изменять размер буферов в качестве предпочтительного
• Введение не блокирующего TX: Эта функция, взятая из библиотеки F4 USBSerial, позволяет пользователям указать, что им не нужно блокировать TX; Разница между блокировкой TX и неблокирующей TX-это похоже на разницу между протоколами TCP и UDP: в первом случае система будет задействовать, чтобы гарантировать, что полное сообщение отправлено, во втором случае система отправит как можно больше сообщения (Это зависит от размера буфера TX) и отбросит оставшуюся часть

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

• Приглашайте пользователей активно проверить изменения и предоставить отзывы
• Оценить интерес к членам форума по поводу предложенных улучшений

Спасибо заранее и с уважением, e.

PS: Просто хочу также подчеркнуть, что этот PR не стремится удалить какую -либо из существующих функций (например, буферизацию RX), и эти усилия были потрачены на гарантирование обратной совместимости

Цитируя @mrburnette от: ViewTopic.PHP?f = 3&t = 1189&P = 15811#P15808 Насколько тщательно протестирован ваш серийный код? Любые тестовые примеры, которые терпят неудачу, в настоящее время построены F1XX, которые безупречно проходят с вашими изменениями? Вместо кода тестирования, как бы вы предложили тестировать свои изменения? Есть ли в вашем предложении какие -либо зависимости (ограничения, зарезервированные ресурсы, известные бомбы)? Я использую этот тестовый эскиз: //#define Serial Serial1 // TX A2 #include byte nodeID = 10; byte packetNum = 11; float C = 42.611; float F = 42.611; float H = 42.6; float vBatt = 3.14; int packetLoss = 10; int packetTotal = 10000; #define tx_buf_start 1 #define tx_buf_stop 300 uint16 tx_buf_size=tx_buf_start; void printData() { Serial.print(nodeID); Serial.print(","); Serial.print(packetNum); Serial.print(","); Serial.print(C); Serial.print(","); Serial.print(F); Serial.print(","); Serial.print(H); Serial.print(","); Serial.print(vBatt,3); Serial.print(","); Serial.print(packetLoss); Serial.print(","); Serial.println(packetTotal); //Serial.println(SCB_BASE->VTOR,HEX); //Serial.println("abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789"); } void setup() { //Serial.begin(57600); } void loop() { //Serial.beginNew(9600,tx_buf_size); //Serial.beginNew(57600,tx_buf_size); Serial.beginNew(115200,tx_buf_size); //Serial.disableBlockingTx(); unsigned long start = micros(); printData(); unsigned long end = micros(); Serial.print("tx_buf_size[");Serial.print(tx_buf_size);Serial.print("]: ");Serial.print(end - start);Serial.println(" us"); Serial.println(); tx_buf_size *= 2; if(tx_buf_size > tx_buf_stop){ tx_buf_size = tx_buf_start; //Serial.println("================="); Serial.println("@@@@@@@@@@@@@@@@@@@"); Serial.println(); } delay(1000); }

Если у вас есть интерес к реализации кода USART, посмотрите запрос на вытягивание и прокомментируйте GitHub.

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

Я лично предпочел бы, чтобы реализация RING_BUFFER осталась неизменной.

-рик

Рик Кимбалл написал:(...)
Я лично предпочел бы, чтобы реализация RING_BUFFER осталась неизменной.

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

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

Предполагая, что пользователи хотят определить небольшой буфер, 1 байт может иметь значение: i.эн. На общем 8 байт -буфере 1 байт составляет 12,5%.. Хорошо, это просто неуместно, ИМО, и это пограничное презрение к нашей коллективной интеллекте. Мы можем сделать математику.

Луча

Отредактировано: Это не цель этого пиара решать возможные существующие проблемы (по крайней мере, сейчас не сейчас). Я пришел из довольно строгой трудовой этики (надзор за 10 кодировщиками Java в программном капитальном инвестициях в 600 млн долларов в среду обречения сообщений), и я могу заявить, что (значительные) проблемы, обнаруженные в единичном тестировании на основе предыдущего кода, были исправлены до улучшения. Несчастные проблемы, попавшие в модульные тестирование, были включены в улучшение. Несчастный здесь предназначен для того, чтобы не подразумевать отсутствие бюджета или проскальзывания даты внедрения. Несчастные проблемы, попавшие в модульные тестирование, которые вызывали бюджет/проскальзывание даты, были приоритетными, так как применялись горячие фиксы с окном запроса на изменение от клиента BU.

Вы заставляете это звучать так, как будто хотите, чтобы ваши вещи были введены в ядро, и все остальное - чья -то проблема Эльса. Прошло несколько дискуссий с вами, я действительно не думаю, что вы имеете в виду, что вы имеете в виду.

Если мы найдем что -то в тестировании, мы будем демократически решать, как и когда это должно быть исправлено. До сих пор не было нехватки талантов для работы с работой... Хотя Роджер часто сам по себе добровольцев, ИМО.

Я бы предпочел, чтобы этот запрос на притяжение разделяется на 2 запроса на притяжение. Тот, который занимается неудачей нашей текущей реализации для использования прерываний и метода буферизации TX. Второе, чтобы рассмотреть возможность динамического изменения размера буфера RX и TX. Я могу представить, что у меня не будет возражений против первой и много проблем со вторым.

-рик

Рик Кимбалл написал:Я бы предпочел, чтобы этот запрос на разделился на 2 запроса на притяжение. Тот, который занимается неудачей нашей текущей реализации для использования прерываний и метода буферизации TX. Второе, чтобы рассмотреть возможность динамического изменения размера буфера RX и TX. Я могу представить, что у меня не будет возражений против первой и много проблем со вторым.

-рик

Рик Кимбалл написал: <...> Все краевые случаи для всех портов Serialx и проводят какую -то автоматическую проверку, возможно, используя последовательные порты, подключенные друг к другу.
<...>
-рик

Mrburnette написал: Вы заставляете это звучать так, как будто хотите, чтобы ваши вещи были введены в ядро, и все остальное - чья -то проблема Эльса. Прошло несколько дискуссий с вами, я действительно не думаю, что вы имеете в виду, что вы имеете в виду.

Если мы найдем что -то в тестировании, мы будем демократически решать, как и когда это должно быть исправлено. До сих пор не было нехватки талантов для работы с работой... Хотя Роджер часто сам по себе добровольцев, ИМО.

К вашему сведению - только: продувание кода
Эскиз - это модифицированный эскиз, переписанный для использования USB Serial для отображения всех значений Ax Mini Mini Mini.

Исходный код STM32F1: Sketch использует 14 148 байт (11%) пространства для хранения программ. Максимум составляет 122 880 байт.
Глобальные переменные используют 2560 байт динамической памяти. Накладывая содержимое Buffered_IntertruptBased_USART_TX__OK.Молния в моем существующем каталоге STM32F1 и перекомпиляции.
Новые изменения серийного прерывания STM32F1: Sketch использует 14 604 байта (11%) пространства для хранения программы. Максимум составляет 122 880 байт.
Глобальные переменные используют 2808 байт динамической памяти. Наблюдение:
Помимо кодового блока для эскиза только для USB, вывод Maple Mini над USB-сериалом работал хорошо. Нет проблем, ошибок, предупреждений.

Эскиз: /* hacked by Ray Burnette to loop through all analog values Board view: http://letsmakerobots.com/files/maplemini2.jpg Arduino 1.7.8 on Linux Mint 17.3 fully patched Sketch uses 13,948 bytes (12%) of program storage space. Maximum is 110,592 bytes. Global variables use 2,560 bytes of dynamic memory. */ int aValue ; int settlingmS = 5000; void setup() { // Configure the ADC pins for (int x =3; x < 12; x++) { pinMode(x, INPUT_ANALOG); } delay(settlingmS); } void loop() { for ( int analogInPin = 3; analogInPin < 12; analogInPin++) { // read the analog in value: aValue = analogRead(analogInPin); // print the results to the serial monitor: Serial.print("Analog pin#"); Serial.print(analogInPin); Serial.print("\t = "); Serial.println(aValue); } delay(settlingmS); }

Наложение содержимого буферизации.Загляните в мой существующий каталог STM32F1 и перекомпиляция Что ж, в этой версии используется реализация буфера статического TX (такая же, как RX Buffer), я думаю, это объясняет вздутие памяти..

[РЕДАКТИРОВАТЬ] Затем есть расширение обработчика прерываний и несколько строк кода, чтобы инициировать новый буфер и использовать его, что объясняет вздутие кода.

Эдогальдо написал:Mrburnette написал: Также о динамической буферизации, как уже говорилось в другом ветке, я начал работать над минимальным решением для буферированного TX на основе прерываний, который я разместил здесь: ViewTopic.PHP?f = 3&t = 1189&P = 15297#P15297
(Обратите внимание, что эта реализация, вероятно, все еще нуждается в некоторых изменениях)

Рик Кимбалл написал: Мне нравится идея этого как первого шага. Я дал ему вихрь, и несколько вещей, кажется, нуждаются в работе. Я создал эскиз для запуска порта UART на 2400 бод и ожидал бы меньшего времени для выполнения печати 80 символов, чем я получил. Вы провели какое -либо тестирование на эту версию? Чтобы увидеть, насколько лучше это на самом деле?

-рик

* Правильная ссылка с отсутствующей парией ')' ...

https: // github.com/edogaldo/arduino_stm ... TX-буфер)

-рик

Эта ветвь, кажется, имеет минимальные изменения. Мне это нравится. Тем не менее, эта версия также имеет проблему с Adwarwware :: end () и не промывание буфера.
https: // github.com/edogaldo/arduino_stm ... сартс.C#169

Я не тщательно протестировал этот код. Однако просто провести визуальный осмотр, кажется, что могут быть условия гонки. Например, этот код выглядит так, как будто их может быть гонка между обработчиком IRQ и настройкой флага прерывания:
https: // github.com/edogaldo/arduino_stm ... сартс.C#169

Вы думали об использовании атомных операций для защиты от этого?

-рик

Прежде всего, спасибо за исправление ссылки, я не знаю, почему, последний »)« остался вне ссылки в моем посте (я пытался включить ее, но безуспешно..) Рик Кимбалл написал:Эта ветвь, кажется, имеет минимальные изменения. Мне это нравится. Тем не менее, эта версия также имеет проблему с Adwarwware :: end () и не промывание буфера.
https: // github.com/edogaldo/arduino_stm ... сартс.C#169

@edogaldo

Спасибо за работу по этому поводу! Я первоначально опубликовал здесь: сериал Blue Pill.Печать медленно, uno быстрее? -> ViewTopic.PHP?f = 3&t = 1189

Я откладываю свои таблетки из -за этого, теперь я могу их использовать. Интересно, сколько людей, использующих серийные проекты STM Arduino, думают, что они получают максимальную отдачу от процессора, пока не попадут в Serialtx Speed ​​Bump?

Я попробовал ветвь SerialTXBuffer в https: // github.com/rogerclarkmelbourne/arduino_stm32 В моих тестах я сейчас получаю ожидаемое ~ 4.5x TX улучшение по сравнению с UNO.

Конечно, что -то подобное должно быть добавлено в ядро! ...еще раз спасибо.

ребята

Я объединю это на выходных, так как я думаю, что достаточно людей успели проверить и прокомментировать это