Приветствую всех,

Кажется, я не могу понять, почему этот код занимает 6617us на синей таблетке и занимает 2472us на UNO. Я попробовал как серийный, так и serial1 и получил одинаковые результаты.

Я использую серийную загрузку со встроенным погрузчиком. IDE 1.6.9 и ядро ​​актуально.

Код обычно работает в 7 раз быстрее, пока я не нажму »сериал.Отпечатки ".

Спасибо за отзыв!

/*###ICF### Section handled by ICF editor, don't touch! ****/ /*-Editor annotation file-*/ /* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */ /*-Specials-*/ define symbol __ICFEDIT_intvec_start__ = 0x08000000; /*-Memory Regions-*/ define symbol __ICFEDIT_region_ROM_start__ = 0x08000000; define symbol __ICFEDIT_region_ROM_end__ = 0x080FFFFF; define symbol __ICFEDIT_region_RAM_start__ = 0x20000000; define symbol __ICFEDIT_region_RAM_end__ = 0x2001FFFF; define symbol __ICFEDIT_region_CCMRAM_start__ = 0x10000000; define symbol __ICFEDIT_region_CCMRAM_end__ = 0x1000FFFF; /*-Sizes-*/ define symbol __ICFEDIT_size_cstack__ = 0x400; define symbol __ICFEDIT_size_heap__ = 0x200; /**** End of ICF editor section. ###ICF###*/ define memory mem with size = 4G; define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__]; define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__]; define region CCMRAM_region = mem:[from __ICFEDIT_region_CCMRAM_start__ to __ICFEDIT_region_CCMRAM_end__]; define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { }; define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { }; initialize by copy { readwrite }; do not initialize { section .noinit }; place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec }; place in ROM_region { readonly }; place in RAM_region { readwrite, block CSTACK, block HEAP }; place in CCMRAM_region { section CCMRAM }; /* added Aug2015 SLC */

Это результат избирательного характера передачи функции в arduino_stm32.
Поскольку ядро ​​не поддерживает прерывание по передаче, MCU должен ждать каждого байта, прежде чем отправлять другой (передача опроса).
UNO имеет передачу на основе прерываний с кольцевым буфером, сериал.Функция печати просто толкает байты в кольцевой буфер, а обработчик прерывания отправляет байты.
PS: Я надеюсь, что это изменится в ближайшем будущем...

Я модифицировал ваш код, чтобы я мог видеть, какой эффект скорость передачи передач на скорость.
uint8_t GetData() { uint8_t char_in = (digitalRead(Data0) << 0) + (digitalRead(Data1) << 1) + (digitalRead(Data2) << 2) + (digitalRead(Data3) << 3) + (digitalRead(Data4) << 4) + (digitalRead(Data5) << 5) + (digitalRead(Data6) << 6) + (digitalRead(Data7) << 7); return char_in; }

Спасибо за отзыв!

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

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

Я думал, что попробую STM. Чем быстрее я оставляю функцию данных процесса, тем раньше я смогу вернуться к опросу ISR. Повышение при обработке данных отрицается от отпечатка блокировки.

+1 для буфера.

Роджер упоминает об этом здесь http: // www.Rogerclark.net/undates-to-ar ... tm32-code/

Сламмер написал:Это результат избирательного характера передачи функции в arduino_stm32.
Поскольку ядро ​​не поддерживает прерывание по передаче, MCU должен ждать каждого байта, прежде чем отправлять другой (передача опроса).
UNO имеет передачу на основе прерываний с кольцевым буфером, сериал.Функция печати просто толкает байты в кольцевой буфер, а обработчик прерывания отправляет байты.
PS: Я надеюсь, что это изменится в ближайшем будущем...

...Как мы можем приложить эти усилия? ...Мне кажется, что это не так просто.

..Я посмотрел https: // github.com/arduino/arduino/tree ... es/arduino

..и https: // github.com/esp8266/arduino/tree ... ES/ESP8266

Спасибо!

Я думаю, что @ekawahyu смотрит на это для Core Hal Mx, но у него есть некоторые проблемы с ним (см.)

ViewTopic.PHP?f = 3&t = 1012&начало = 60#p15108

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

я.e STM32F103C имеет 3 аппаратных серийных устройств. Все это выделяет буфер.

Я знаю, что это всего лишь 192 байта, но я не уверен, что все хотят обменять это на серийные результаты.
Хотя я полагаю, мы можем провести опрос на форуме, чтобы узнать.

Rogerclark написал:<...>
Я знаю, что это всего лишь 192 байта, но я не уверен, что все хотят обменять это на серийные результаты.
Хотя я полагаю, мы можем провести опрос на форуме, чтобы узнать.

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

Это не лучшая идея для распределения фиксированного буфера 3*64BYTE, как было сказано, особенно когда вы можете использовать только 1 порт.

Я провел некоторые эксперименты и обнаружил, что если вы отправите один символ, последовательный порт не блокирует, если он уже отправит. Таким образом, должно быть возможно создать виртуальный последовательный порт с кольцевым буфером с таймером или, даже лучше, «прерывание по завершению передачи», которое питает настоящий ком. #Define для размера буфера было бы хорошим, тогда вы просто определите столько буферов, сколько вам нужен необходимый вам размер (вероятно, на пару байтов больше, чем самое большое сообщение, которое вы собираетесь отправить).

Правильным способом является «прерывание по завершению передачи», как вы сказали....
Если мы сохраним каждый класс Hardwareserialx отдельно, то можно выделить буферы только для последовательных портов, которые используются в проекте. Я думаю, что 64 байта для буфера для передачи довольно велики, особенно для быстрых скоростей, но это зависит от приложения. Мы можем установить размер буфера по умолчанию на 16 байт (например, arduino uno), и если кто -то хочет изменить это, простое определение, прежде чем включать в себя «Hardwareserialx.H "может сделать работу.... не нарушая ARDUINO API.

Я написал буфер кольца и проверил его. Моя среда разработки, VS2012 сломана с момента обновления до 1.6.9 Поэтому мне приходится работать в окружающей среде Ардуино, которая немного болезненна для меня, так как C ++ не является моим любимым языком. К тому времени, когда я привыкаю к ​​этому, мой проект закончен, и я забываю его еще 6 месяцев.

Мой совет: не могу сказать о буфере, но об использовании прерывания, я думаю, пример Freertos может поддержать:
void interrupt() { if (!(GPIOB->regs->IDR & 0x0004)) // ignore if select signal is not present { //turn on the busy signal GPIOB->regs->ODR |= 0b0001000000000000; uint8_t data = GPIOA->regs->IDR & 0x00FF; //process the new byte processData(data); delayMicroseconds(35); GPIOB->regs->ODR &= ~(0b0001000000000000); } }

Buffered_IntertruptBased_usart_tx.молния

(22.12 киб) скачано 32 раза

Спасибо! Я протестирую это...

Эдогальдо написал:Buffered_interruptbased_usart_tx.молния

Эдогальдо написал:Эдогальдо написал:Уважаемая все, я попытался применить буферные прерывания USART TX на устройствах STM32F103, те, которые я знаю (более или меньше ).
Здесь измененные файлы:
- Arduino_stm32-master \ stm32f1 \ system \ libmaple \ include \ libmaple \ usart.H: Добавлен RING_BUFFER WB в struct "usart_dev"
- Arduino_stm32-master \ stm32f1 \ system \ libmaple \ usart_private.H: Модифицированная функция обработки прерываний для обработки TX
- Arduino_stm32-master \ stm32f1 \ cores \ maple \ libmaple \ usart.C: модифицированный USART_TX () для использования wb, если TXE не готов
- Arduino_stm32-master \ stm32f1 \ cores \ maple \ libmaple \ usart_f1.C: Модифицированное определение USARTS, чтобы добавить новый буфер TX "WB"

Я приложил также соответствующие оригинальные версии, которые у меня были, так как я не знаю, были ли они модифицированы с тех пор, как я их получил (более или менее 1 месяц назад).

Надеюсь, это поможет..

PS: не удалось проверить его на реальном устройстве, но, по крайней мере, он успешно компилируется..


Лучший, e.

отличный!

Я думаю, что это определенно то, что должно быть введено в ядро.

Я протестирую его на выходных и сделаю отдельный пост / опрос, чтобы увидеть, что общины вещи.

еще раз спасибо

Роджер

Мне нравится это сообщество, это было мое удовольствие.

Большое спасибо.

Я уверен, что все будут очень благодарны, так как мы все хотим, чтобы ядро ​​работало как можно хорошо

Сламмер написал:Правильным способом является «прерывание по завершению передачи», как вы сказали....
Если мы сохраним каждый класс Hardwareserialx отдельно, то можно выделить буферы только для последовательных портов, которые используются в проекте. Я думаю, что 64 байта для буфера для передачи довольно велики, особенно для быстрых скоростей, но это зависит от приложения. Мы можем установить размер буфера по умолчанию на 16 байт (например, arduino uno), и если кто -то хочет изменить это, простое определение, прежде чем включать в себя «Hardwareserialx.H "может сделать работу.... не нарушая ARDUINO API.

Эдогальдо написал:Мне нравится это сообщество, это было мое удовольствие.

У меня такое ощущение, которое определяет в эскизе, не подбирается кодом основного кода.

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

Единственный способ контролировать это, либо добавить что -то в директивы компилятора e.глин. -DUSE_SERIAL_TX_BUFFER = 1, а затем иметь меню опции в платах.TXT, который устанавливает флаги, которые были подняты платформой.текст

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

Или пользователь может просто отредактировать один из основных заголовков E.глин. Ардуино.H и добавьте определение там, если они хотят иметь буфер TX, и в этом случае мы, вероятно, должны разрешить размер, E, E.глин.

#define serial_tx_buf_size 128

и использовать

#ifdef serial_tx_buf_size

вокруг нового кода


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

Я не смотрел тебя код, но что произойдет, если они печатают больше, чем буферы? Я предполагаю, что это блокирует, пока не останется 1 буфера, а затем продолжается ?? (Извините, еще не имел возможности просмотреть код)


Спасибо

Роджер

Официальный API Arduino имеет фиксированные значения для буферов RX/TX, и пользователь не может изменить их на уровне эскизов.
Мы говорим на самом деле для улучшения/улучшения API Arduino API...
Я думаю, что 64 байта - очень хорошее значение, для буферов TX/RX, никто не пропустит потерянные байты.... Мы в мире рук... (Даже Avr Arduino выделяет 64 байта на TX/RX для устройств Atmega168/328). Наиболее важным является выделение буферов только для серийных портов, которые используются в проекте.

Я не чувствую, что мы должны быть ограничены APR API, но в равной степени мы не должны делать ничего, что тоже ломает API

Хотя мы могли бы передать буфер в качестве дополнительного параметра в сериал.начинать

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

И мы, вероятно, должны установить его на то же значение, которое использует AVR. (Как я и предполагаю, в эту ценность вошла некоторая мысль)

Нб. Я не смотрел на значение буфера на должном или нулевом и т. Д., Чтобы увидеть, больше ли размер буфера или реализован вообще.

Если я правильно интерпретировал код, реализация SAM использует 128 байтов для каждого буфера RX и TX и выделяет их для всех доступных USARTS/UARTS, ссылка:
- вариант.CPP
- Кольцо.час

Еще несколько заметок об реализации STM32F1:
- Размер буфера используется не только в rb_init (), но особенно в определении структуры «USART_DEV», поэтому я не уверен, что мы можем выделить его динамичным способом, сохраняя тот же подход: void interruptFunc() { //turn on the busy signal GPIOB->regs->BSRR = 0b0000000000010000; uint8_t data = GPIOA->regs->IDR & 0b0000000011111111; //clean bits GPIOA->regs->BRR = 0b0000000011111111; //process the new byte processData(data); //delayMicroseconds(200); GPIOB->regs->BRR = 0b0000000000010000; }

Я не смотрел тебя код, но что произойдет, если они печатают больше, чем буферы? Я предполагаю, что это блокирует, пока не останется 1 буфера, а затем продолжается ?? (Извините, еще не имел возможности просмотреть код) Я основал свою реализацию на стандартной реализации Arduino, которая мне кажется довольно хорошо оптимизированной, код "write ()" работает так:
| defined(__STM32F1__)

Эдогальдо написал:.....
Таким образом, буфер Full - это поддерживаемый сценарий.

Лучший, e.

Эдогальдо написал: <...>
- Просить пользователей изменить файлы библиотеки (я.эн. Прося их изменить значение USART_RX_BUF_SIZE/USART_TX_BUF_SIZE), я думаю, что противоречит ардуино "MCU для чайников" Spirit
<...>

Rogerclark написал:Хотя мы могли бы передать буфер в качестве дополнительного параметра в сериал.начинать

Martinayotte написал:Rogerclark написал:Хотя мы могли бы передать буфер в качестве дополнительного параметра в сериал.начинать

Я написал свой собственный код буфера кольца, эффективно создавая виртуальный COM -порт, который, в свою очередь, питал настоящий серийный порт 1, одновременно останавливаясь, останавливая блокировку. Я не понял IRQ за то, что он кормил его, так что в качестве таймера очень грубое исправление, но тем не менее исправление, тем не менее.

Я должен признать, что думал, что сериал TX был буферизован, пока я не увидел эту ветку, но я заметил и понял проблему и способен сделать поправление кровью. Я не выполнял много проектов с STM32, но теперь я затронут, почему, по крайней мере, один не был таким отзывчивым, как я думал, что его следует сравнить с Arduino Pro Micro.

Для меня буферизация TX - это то, что должно быть доступно в STM32Duino или, необязательно, пропустив *BUF и размер виртуальной библиотеки, которая питает настоящий COM -порт. Я вижу, что некоторые проекты могут сломаться, если сериал внезапно быстрее (не блокировка), но библиотека была бы лучше для буферизации сериала. Даже в 90 -х у нас были буферизованные UARTS 16550A с использованием RS232 гораздо лучше и надежнее.

Если вы реализовали как старый сериал, так и SerialBuf, будет связан SerialBuf, если он не использовался в коде эскизов ? Если это так, пользователь может просто использовать SerialBuf или Serial. Для новых проектов.

Кстати, для всех, мы должны посмотреть, что эти буферы RX/TX уже реализованы в рамках F4.

Единственное, что USART_TX_BUF_SIZE/USART_RX_BUF_SIZE жестко закодированы до 256 символов.
Будет легко добавить новые функции settxBufsize () и setRxBufSize (), чтобы их динамически распределили динамически.

Для функции блокировки/неблокировки было бы легко сделать то же самое, что уже сделано в USB_SERIAL, где присутствуют фонации включают BlockingTX () и DisableBlockingTX ().

Итак, нет необходимости создавать новый класс...

Martinayotte написал:Для функции блокировки/неблокировки было бы легко сделать то же самое, что уже сделано в USB_SERIAL, где присутствуют фонации включают BlockingTX () и DisableBlockingTX ().

Итак, нет необходимости создавать новый класс...

Конечно, даже наличие DMA+IRQ, он не мешает блокировать/не блокировку функциональности.
Недавно я измерил пропускную способность USB_SERIAL, где источник был файлом, расположенным на SDCARD, и обнаружил, что не блокировка была не дефолта.
ViewTopic.PHP?f = 3&T = 1159#P14759
Я думаю, что этот кусок кода на F4 даже не присутствует в F1. (Я думаю, что F4 более продвинутый, чем F1 в этой области)

Martinayotte написал:Конечно, даже наличие DMA+IRQ, он не мешает блокировать/не блокировку функциональности.
Недавно я измерил пропускную способность USB_SERIAL, где источник был файлом, расположенным на SDCARD, и обнаружил, что не блокировка была не дефолта.
ViewTopic.PHP?f = 3&T = 1159#P14759
Я думаю, что этот кусок кода на F4 даже не присутствует в F1. (Я думаю, что F4 более продвинутый, чем F1 в этой области)

Эдогальдо написал: Так что я не уверен, что это очень хорошо протестированная функция...

Для Usbeserial я проверил его две недели назад (см. Выше нить), и он работает, как и ожидалось.

Звонок не "это->usbenableblockingtx () ", так что он не сама сам по себе ...
Не забывайте, что код вызывает вариант c usbenableblockingtx (), расположенный в USBF4/USB.H и, следовательно, в USBF4/USB.c, он вызывает vcp_setusbtxblocking () из USBF4/USB.в. (Я знаю, это выглядит запутанно, но это код Leaflab ... )

Да, это только в Usbeserial, я просто говорил, что он должен быть реализован также в жестком плате, чтобы мы могли получить оба варианта поведения.
И в соответствии с F1, не реализуется, даже не на USSerial, что означает, что он имеет не блокирующее поведение, предотвращая посылку больших данных без потери некоторых байтов.

Martinayotte написал:Для Usbeserial я проверил его две недели назад (см. Выше нить), и он работает, как и ожидалось.

Звонок не "это->usbenableblockingtx () ", так что он не сама сам по себе ...
Не забывайте, что код вызывает вариант c usbenableblockingtx (), расположенный в USBF4/USB.H и, следовательно, в USBF4/USB.c, он вызывает vcp_setusbtxblocking () из USBF4/USB.в. (Я знаю, это выглядит запутанно, но это код Leaflab ... )

Эдогальдо написал:Но "usbDisableBlockingTX ()" наверняка сломана: он никогда не переключит флаг "usbtxblock"

Martinayotte написал:Эдогальдо написал:Но "usbDisableBlockingTX ()" наверняка сломана: он никогда не переключит флаг "usbtxblock"

Верно ! usbenableblockingtx () используется дважды !
Я пришлю пиар в Роджер ...

РЕДАКТИРОВАТЬ: PR отправлен ...

Я поступил на этот пиар (для F4)

Спасибо @roger !
Спасибо @Edogaldo за то, что нашли эту непроверенную ошибку !

Yw.
Кстати, я только начал кое -что узнать об использовании GitHub и PRS, в следующий раз, когда попробую открыть пиар.

Лучший, e.

PR - это лучшие для меня, так как их легко управлять.

Хотя в этом случае мне нужно перенести, затем объединить пиар

Привет, Роджер, я хотел бы внести свой вклад в библиотеку arduino_stm32; Я подал заявку после улучшений в F1 USART:

• Добавлены TX на основе буферизации
• Буферы могут быть динамически распределены через твердый.начинать()
  • Мин RX Размер буфера: 16
  • Размер буфера RX по умолчанию: serial_rx_buffer_size
  • Мин TX Buffer Размер: 1
  • Размер буфера TX по умолчанию: serial_tx_buffer_size
• Добавлены твердые.enableblockingtx ()/disableblockingtx () (блокировка включена по умолчанию)
• Улучшен Ring_buffer для поддержки полного размера буфера вместо размера буфера - 1

Я хотел бы прислать вам изменения через PR, но я полный Nebie to Github, не могли бы вы объяснить мне шаги, чтобы отправить пиар для вашего проекта?


Спасибо и лучше, е.

@edogaldo,

Во -первых, вам понадобится учетная запись GitHub и войти в нее.
Во-вторых, от GitHub Roger, нажмите Link "fork" в верхнем правом углу, он создаст вилку из репо Роджера в вашу учетную запись.
На вашем компьюте <THE_FORKED_REPO_IN_YOUR_ACCOUNT>"
Изменить/объединить свои изменения там.
Сделайте их и подтолкните их в GitHub, он затем появится на веб -странице Github Github с All Commits History.
Теперь нажмите «Сравните» в вилке с учетной записью GitHub, он покажет различия против репо Роджера.
Если вы удовлетворены ими, нажмите кнопку «Создать запрос на развлечение», заполните сообщение, чтобы связать с PR и отправить.
Роджер должен будет сделать слияние ...

Большое спасибо, Мартин, я мог бы успешно создать пиар.

Лучший, e.

@edogaldo

Я посмотрел на PR, но я беспокоюсь о том, что вы внесли в сериал :: begin () и несколько других проблем.

с | defined(__STM32F1__)

Rogerclark написал: Я обеспокоен тем, как буферы динамически распределяются с использованием Malloc.

Мартин

Я уверен, что ядро ​​не использует new (), как если бы я использовал новый () в эскизе, двоичный.

Эти буферы должны будут быть статически распределяться
Sub Process_Globals Public Serial1 As Serial Private Timer1 As Timer Private pin13 As Pin End Sub Private Sub AppStart Serial1.Initialize(115200) Log("AppStart") pin13.Initialize(13, pin13.MODE_OUTPUT) Timer1.Initialize("Timer1_Tick", 1000) '1000ms = 1 second Timer1.Enabled = True End Sub Private Sub Timer1_Tick Dim currentState As Boolean = pin13.DigitalRead Log("CurrentState: ", currentState) Dim NewState As Boolean = Not(currentState) Log("NewState: ", NewState) pin13.DigitalWrite(NewState) End Sub

На педантической записке о PR

Пожалуйста, не редактируйте ничего другого, кроме изменений, которые вы делаете

Не прижимайте какой -либо другой код, включая удаление любых пробелов или новичков, так как GIT рассматривает все эти изменения как важные и раскачивает разницы, которые мне приходится, хотя при рассмотрении пиара пиар

(ПРИМЕЧАНИЕ I "М не единственный, у кого есть проблема с удалением пробела в PR PAUL (Teensy) несколько раз сообщал об этом в различных местах)

Rogerclark написал: Эти буферы должны будут быть статически распределяться

Martinayotte написал:Rogerclark написал: Эти буферы должны будут быть статически распределяться

Привет, здесь мои отзывы:

• о белых пространствах, вкладках и т. Д..: Я все равно изменил их для согласованности?
• о динамическом размере буфера: я был для статического размера буфера (как в стандартном Arduino Uno & Причитающиеся реализации), но я получил на этом форуме, это было бы плюс иметь динамические буферы, и это подразумевает динамическое распределение; Мои тесты в порядке на этом
• о методе начала:
  • Аргументы 2, 3 и 4 являются необязательными: если вы не указываете их
  • Я оставил "конфигурацию" как аргумент 4 (последний) из -за комментариев: commit 60d982ff25d966f15e8af70d4bb6f46bb1d1595a Merge: c705499 99b9aca Author: Roger Clark Date: Mon Dec 3 09:01:31 2018 +1100 Merge pull request #580 from Squonk42/titles Explicit STM32duino.com platform origin commit 99b9acaa80d2394314c7668ff83a4953104cec31 Author: Michel Stempin Date: Sun Dec 2 22:32:30 2018 +0100 Explicit STM32duino.com platform origin commit c7054992554b27ec6bdfc016347806454ab69815 Author: Roger Clark Date: Fri Nov 30 20:19:24 2018 +1100 Removed LTO options as the no longer work correctly with the newer version of gcc used in Arduino 1.8.7 commit 9a489ca25fa2794bd39d4d2d46e1d9d3ecd733e2 Author: Roger Clark Date: Sun Nov 11 20:38:47 2018 +1100 Changed USB Serial so that it will send to the host even if DTR is not set. Note this does not effect the operation of the boolean operation e.g.. while(!Serial); used to wait for the Arduino terminal to open commit 61ed869caa6bf73a4ca28e325e200670fc8ef8e5 Merge: b5cd376 188d9ce Author: Roger Clark Date: Mon Sep 24 17:35:30 2018 +1000 Merge pull request #569 from stevstrong/patch-20 F4: fix HID upload with Arduino IDE commit 188d9ce985678f72f4912cc742ee3865f92dfd7b Author: stevstrong Date: Mon Sep 24 09:31:55 2018 +0200 F4: fix HID upload with Arduino IDE commit b5cd37696b7057f8489c0a17801420756b44a4e7 Author: Roger Clark Date: Wed Sep 12 17:22:11 2018 +1000 Updated USBComposite library. Thanks to @arpruss commit 6a9c7956538892fa6fbe4a9ffc90d3c4bfab9441 Merge: b31efe8 92cdd1a Author: Roger Clark Date: Sun Aug 19 17:23:01 2018 +1000 Merge branch 'stevstrong-patch-16' commit 92cdd1ab217c50e47c87268cfbc95e128dbc2591 Merge: b31efe8 3d356aa Author: Roger Clark Date: Sun Aug 19 17:21:34 2018 +1000 Merge branch 'patch-16' of https://github.com/stevstrong/Arduino_STM32 into stevstrong-patch-16 commit b31efe83f743f234524969bab4a26e02b55b27f6 Merge: e65747d 32d2eab Author: Roger Clark Date: Sun Aug 19 17:02:18 2018 +1000 Merge branch 'smarq8-master' commit 32d2eabb608d0f2006d872a6017326c4a1037aba Merge: e65747d f781964 Author: Roger Clark Date: Sun Aug 19 16:19:57 2018 +1000 Merge branch 'master' of https://github.com/smarq8/Arduino_STM32 into smarq8-master commit e65747d8bbd8af80ff08decd2f1a564f7ae93d85 Merge: 231b9d3 e245726 Author: Roger Clark Date: Sun Aug 19 15:59:47 2018 +1000 Merge branch 'fpistm-default_build_flag' commit e245726117532897ff2394c8dff4352046b1878e Merge: 231b9d3 e160160 Author: Roger Clark Date: Sun Aug 19 15:53:21 2018 +1000 Manually merged conflict with hid upload pattern in platform.text commit 231b9d350cea8e2f6e92556c2bf02789b81c4d70 Merge: 6e2796e 7f487b3 Author: Roger Clark Date: Sun Aug 19 15:48:33 2018 +1000 Merge branch 'pamribeirox-master' commit 7f487b33c60affea8a5243d631f8734bcd7615e5 Merge: 6e2796e 129e57b Author: Roger Clark Date: Sun Aug 19 15:43:20 2018 +1000 Merge branch 'master' of https://github.com/pamribeirox/Arduino_STM32 into pamribeirox-master commit 6e2796e93893a1521fb3b9b567d4400edb500bdb Merge: f4cc34b a176fd1 Author: Roger Clark Date: Sun Aug 19 15:00:09 2018 +1000 Merge pull request #547 from fpistm/Fix_netduino2plus [STM32F4] Add missing build.vect_flags for netduino2plus commit f4cc34b82808bb5e10e90bfe3fd9dddd8d1adaab Merge: 45439cf 9be1115 Author: Roger Clark Date: Sun Aug 19 14:58:12 2018 +1000 Merge branch 'tfry-git-master' commit 9be1115f03ff71d353ba9662a9838f4d1bf5ac4b Merge: 45439cf 3cb1196 Author: Roger Clark Date: Sun Aug 19 14:57:18 2018 +1000 Merge branch 'master' of https://github.com/tfry-git/Arduino_STM32 into tfry-git-master commit 45439cf42d30350fbbf46f96a8849e42b6880e6d Merge: 26ae0cc 9870a47 Author: Roger Clark Date: Sun Aug 19 14:56:19 2018 +1000 Merge pull request #549 from stevstrong/patch-17 F4: USBD_StrDesc[] size fix commit 26ae0cc7de3296bea44c5f524ca963cc1c8f4525 Merge: 8a34f8e 3ff3b0a Author: Roger Clark Date: Sun Aug 19 14:55:56 2018 +1000 Merge pull request #550 from stevstrong/patch-18 F4: USBD_StrDesc[] size fix (continued) commit 8a34f8e2214b674d976fa8e2b9216fa91d0706d0 Merge: 9d46a1c 4ea490e Author: Roger Clark Date: Sun Aug 19 14:51:06 2018 +1000 Merge branch 'Serasidis-master' commit 4ea490e6d377980012aed198c3fbaabbf94c8d6f Author: Vassilis Serasidis Date: Sat Aug 4 17:29:51 2018 +0300 Added support to HID Bootloader 2.0 HID Bootloader 2.0 supports Bluepill and generic_f407v boards The hid-flash tool is at the moment available only on Windows Please update your HID Bootloader firmware to V2.0 (https://github.com/Serasidis/STM32_HID_Bootloader/tree/master/bootloader/bootloader_only_binaries) commit 3ff3b0aef3fa88c19755b9e873243e89c45d9bb4 Author: stevstrong Date: Sat Aug 4 10:51:21 2018 +0200 F4: USBD_StrDesc[] size fix (continued) Limit the maximum string length to 32 chars. commit 9870a471db765c08dbfbedfae69794dea7742962 Author: stevstrong Date: Fri Aug 3 18:01:02 2018 +0200 F4: USBD_StrDesc[] size fix - bug: memory overflow for size values less than 62, in function USBD_GetString(). The array in question (USBD_StrDesc) is followed in memory by 2 fill bytes for the current compile order. Arduino 1.8.6 compiles the files in different order, so that the USB will not working anymore. The longest string is 32 bytes long (plus ending zero), and 2 more bytes will be added at the beginning (https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_Device_Library/Core/src/usbd_req.c#L818-L834). The last 2 bytes are fill bytes (align 4). commit 3cb1196851088fcef5fa89d14841158a6e7f7d02 Author: Thomas Friedrichsmeier Date: Thu Aug 2 20:47:25 2018 +0200 Add pgm_read_ptr and pgm_read_ptr_far for better compatibility with libs written for AVR commit a176fd1937faba29fadc4df6907037b45bf451ab Author: Frederic.Pillon Date: Tue Jul 31 16:07:11 2018 +0200 [STM32F4] Add missing build.vect_flags for netduino2plus Broken since: 58e50e7fd9062e45ec23d575a16cd411522c37cb Fix #544 Signed-off-by: Frederic.Pillon commit 129e57b854e7d6674a6ddc28c7c8ecaa83f3ab8c Author: Pedro Ribeiro Date: Mon Jul 30 22:27:19 2018 +0100 Revert the previous proposed changes commit 53612be98f05462894acdafc8ba45eae7127b660 Author: Pedro Ribeiro Date: Mon Jul 30 22:26:46 2018 +0100 Revert the previous proposed changes commit 9b927b2f47a25ad9878f70c58f0a2f6495a3965e Author: Pedro Ribeiro Date: Mon Jul 30 22:18:56 2018 +0100 Fix I2C handling of multiple Wire.begin() at libmaple level Just skip the i2c_master_enable() code if the PE bit says it's already enabled This solves the problem of ASSERT() hang when Wire.begin() is called by multiple libraries commit 91783ae6b564c822915651c57096b99ed8b60948 Author: Pedro Ribeiro Date: Sun Jul 29 20:51:44 2018 +0100 Avoid i2c_master_enable() multiple calls Repeated calls seem to trigger some low level ASSERT() We can't avoid begin() being called by each library from the devices sharing the bus Use the attribute isbegin to keep track of begin() calls and does the i2c_master_enable() at the first one for the object instance commit 65e4bfd2a89a8dfabfee2c5b58ef0cd935c4701f Author: Pedro Ribeiro Date: Sun Jul 29 20:37:00 2018 +0100 New attribute "isbegin" This attribute is added to keep record o previous begin() calls to the instance. Repeated calls seem to trigger some low level ASSERT() We can't avoid begin() beeing called by each library from the devices sharing the bus commit e160160034004a2e7019b84d60babccd14d8661e Author: Frederic.Pillon Date: Thu Jul 26 17:46:23 2018 +0200 Define defaults optimization build.flags Signed-off-by: Frederic.Pillon commit f7819640932d921ef5cbee26976e54770d7df231 Author: smarq8 Date: Fri Jul 20 15:57:10 2018 +0200 Update HardwareSerial.cpp fix availableforwrite() commit 3d356aaf4578bfdb9af1881dece617374d05fa6a Author: stevstrong Date: Fri Jul 6 12:15:03 2018 +0200 F1: fix wrong delay timing commit d4b3cd114ba567dbd917b7373f2160d14dd29fd4 Merge: 9d46a1c 2ae1847 Author: Roger Clark Date: Mon Jul 2 19:51:54 2018 +1000 Merge pull request #534 from stevstrong/patch-16 F1: added function dma_get_count commit 2ae184754b387f67dd7647fc620ea9ccac152eff Author: stevstrong Date: Mon Jul 2 10:32:21 2018 +0200 Update dma.h small correction commit 8050dbfa580b97bf375b8f6f83894c4c2ce6478e Author: stevstrong Date: Mon Jul 2 10:30:17 2018 +0200 F1: added function dma_get_count commit 9d46a1c27d4dc9dd4df06b76a1d81684519d8acc Author: Roger Clark Date: Sat Jun 23 17:00:17 2018 +1000 Alternative fix for issue #532 commit 683b6d27969b5b423b881fb594cce1c04a116ce5 Merge: ffce10c 2f4eaa7 Author: Roger Clark Date: Sat Jun 23 16:51:55 2018 +1000 Merge pull request #533 from Serasidis/master STM32F407 BKPSRAM Boundary address fix commit ffce10ce29f0915eadaeef44a66af68bfd6e10b2 Merge: 4db3994 e8d8cdb Author: Roger Clark Date: Sat Jun 23 16:51:12 2018 +1000 Merge branch 'arpruss-master' Initial commit

@edogaldo

Я все еще думаю, что пиар - лучший подход

Я могу притянуться к новой ветви, если хотите, в настоящее время я не чувствую себя комфортно, тяну ни к мастеру, ни в разработке

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

Re: динамическое распределение.

Я думал, что люди хотят динамически распределить самих буферов и передать функцию

Re: Комментарий о конфигурации
Это действительно старый комментарий, я не могу вспомнить, если он был заменен. В любом случае, даже если он не поддерживается в настоящее время, я все равно предпочел бы добавить новые дополнительные параметры в конце подписи функции, так что когда конфигурация наконец реализована, API будет как можно ближе к Arduino.CC API e.глин. на досках AVR

Эдогальдо написал: Конечно, если вы думаете, что не стоит подхода PR, давайте отменим его.

Rogerclark написал: Re: Комментарий о конфигурации
Это действительно старый комментарий, я не могу вспомнить, если он был заменен. В любом случае, даже если он не поддерживается в настоящее время, я все равно предпочел бы добавить новые дополнительные параметры в конце подписи функции, так что когда конфигурация наконец реализована, API будет как можно ближе к Arduino.CC API e.глин. на досках AVR

Привет, Роджер, я получил ваши опасения по поводу динамического распределения и (даже если бы я на стороне Мартина, иначе я бы не использовал его), так как я думаю, что пропущенные буферные прерывания TX-это серьезный недостаток в библиотеке STM32_arduino, я хотел бы Чтобы узнать компромиссное решение, чтобы выпустить эту функциональность.
С этой целью позвольте мне перечислить мою обеспокоенность уважением к решению, которое вы имеете в виду для динамического распределения буферов (позволяя пользователям выделять пользовательские буферы и передавать их в библиотеку):

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

Все сказано, как вы думаете, мы сможем найти компромиссное решение для выпуска, по крайней мере, буферированных функций TX на основе прерываний?
Что бы вы предложили?

Спасибо и пока, e.

Мы могли бы просто пройти в статически выделенных буферах, а также размер этих буферов (но это требует 4 параметра вместо 2)

Я думаю, что это решает проблемы использования Malloc (с которыми я думаю, у многих людей будут проблемы с)

Таким образом, никаких проблем по поводу истощения барана из -за дублирования буферов?!

Поцелуй: буфер RX 128 и TX Buffer 128, оба хардкодированные..

Rogerclark написал:Мы могли бы просто пройти в статически выделенных буферах, а также размер этих буферов (но это требует 4 параметра вместо 2)

Я думаю, что это решает проблемы использования Malloc (с которыми я думаю, у многих людей будут проблемы с)

#defines - хорошее решение, но не внутри среды Arduino IDE.
IDE молча включает Arduino.H в первой строке программы (и это включает все остальные включения), поэтому невозможно определить буферы в программе.
Другое решение состоит в том, чтобы определить буферы с определением в аргументах командной строки, но это требует изменения в системе сборки Arduino IDE или для определения других вариантов с разными размерами буферов.

Сламмер написал:#defines - хорошее решение, но не внутри среды Arduino IDE.
IDE молча включает Arduino.H в первой строке программы (и это включает все остальные включения), поэтому невозможно определить буферы в программе.
Другое решение состоит в том, чтобы определить буферы с определением в аргументах командной строки, но это требует изменения в системе сборки Arduino IDE или для определения других вариантов с разными размерами буферов.

Эдогальдо написал: Да, слямм, ты прав, я пытался найти способ сделать его легким набором, но не успешно..

Mrburnette написал: В «Старые» дни можно было бы написать отдельную «конверт -утилита», чтобы точно настроить плоские файлы, используемые для фактического указания среды компиляции. Сегодня такая утилита может существовать в каталоге /инструментов. Таким образом, было бы легко установить #Defines и другие параметры конфигурации.

Луча

Для тех, кто компилирует проекты Arduino за пределами IDE (Makefiles, Eclipse, Codeblocks и т. Д.) Очень легко определить перед включением Arduino.H но для пользователей IDE невозможно.

Сламмер написал:Для тех, кто компилирует проекты Arduino за пределами IDE (Makefiles, Eclipse, Codeblocks и т. Д.) Очень легко определить перед включением Arduino.H но для пользователей IDE невозможно.

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

Но всего еще несколько вещей, чтобы бросить в микс

Если я не ошибаюсь, у нас уже есть буфер RX (кольцевой буфер) в классе UART ???? (Определенно код для этого)

Итак, что бы ни было окончательное решение. Мы не можем изменить существующее состояние по умолчанию, имея 64 -байтовый серийный буфер RX

От USART.час commit 9a489ca25fa2794bd39d4d2d46e1d9d3ecd733e2 Author: Roger Clark Date: Sun Nov 11 20:38:47 2018 +1100 Changed USB Serial so that it will send to the host even if DTR is not set. Note this does not effect the operation of the boolean operation e.g.. while(!Serial); used to wait for the Arduino terminal to open

Rogerclark написал: <...>
Другие идеи, которые стоит рассмотреть, - это добавление очень маленького буферизации TX по умолчанию E.глин. 8 или 16 байтов, и пусть пользователь редактирует #Defines ??
<...>

Выше сказано, я не против приложения GUI (или командной строки), используемого для настройки параметров ядра для STM32. Несколько радиопроизводительных кнопок и несколько контрольных списков могли бы управлять параметрами «настраиваемых», которые улучшит периферийные особенности. Если бы утилита была Java, ее можно было бы включить в Arduino/Tools и быть легко доступной. Утилита будет ориентироваться на STM32.

Луча

Хорошо, вот что -то радикальное, вы можете использовать один и тот же буфер для TX и RX. Если буфер был, скажем, длиной 64 байта, вы могли бы выдвинуть символы RXED в передней части очереди и подтолкнуть TX в конце буфера.

Это сработало бы отлично, если бы скорость TX была такой же, как RX, что, как я понимаю, это. Вам просто нужно проверить, что количество буферов RX + количество буферов TX было меньше, чем размер буфера - 1. Таким образом, у вас есть 30 символов в очереди TX и 32 символа в очереди RX, скажем, другой персонаж получен у вас есть 33 Chars в очереди RX. По мере того, как они работают с той же скоростью, очередь TX упадет на один символ до получения следующего символа RX. Таким образом, нам нужен только один 64 штук для TX и получения. Единственное, что будет блокировать, - это добавление TX ChAR в очередь, если общее количество символов в обеих очередах было 63.

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

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

Саймонф написал: <...>
Таким образом, мы не используем больше памяти, чем уже используется в текущей системе, и сталкиваемся с ней, большинство людей отправляют кучу Chars, а затем ждем ответа.<...>

Mrburnette написал: Это не означает, что новое ядро ​​не может быть разработано, радикально уходящее от чистоты Arduino, но первоначальное мышление старых членов было для «как можно-заключенного в...."

Эдогальдо написал: @Ray, основной момент этого потока является то, что Maple Library не предоставляет TX на основе прерываний для устройств USART, которые представляют собой OOTB для плат Arduino (как ООН, так и Долгое) и который делает USART TX для плат STM32F1 очень медленными (много более медленное, чем на досках ООН), поэтому это улучшение будет, IMO, только охват отсутствия в реализации Libmaple.

Лучший, e.

Mrburnette написал: Да, я понимаю, что.

Но у нас есть еще одна ответственность перед реальными кленовыми людьми, так как мы полностью унаследовали кодовую базу Leaflabs. Теперь мы несем этот факел по умолчанию... Вы все еще можете прочитать документы. Форумы останутся активными до августа 2016 года, но в этот момент они будут преобразованы в статический архив. Рассмотреть возможность проверки ресурсов и сообщества в http: // www.STM32duino.компонент вместо. Честно говоря, я не знаю, сколько наших участников владеет настоящим кленовым оборудованием и может использовать STM32Duino... Но время от времени я вижу большое количество пользователей, которые не являются ботами и не зарегистрированы. В любом случае, это о чем подумать. Черт, у меня нет проблем с изменением F2, F3 или F4. Это небольшая вещь, но ИМО, достойная какой -то серьезной активности нейронов.

Кроме того, и это личное утверждение факта, через 3 года у меня не было серийного вопроса. Может быть, мне просто повезло, или, возможно, мой код значительно не подчеркивает UC. Я уверен, что мог бы написать что -то, чтобы заставить проблему появиться, но ничто из того, что я обычно делал за 3 года, не вызвало меня беспокойство.

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


Луча

Эдогальдо написал: <...>
Да, вы несете факел, но если вы не идете с этим факелом, что вы носите его на?
Почему библиотеки F0, F2, F3 и F4 могут расти, но F1 не может?
Давай, название этого сайта «Ардуино для STM32» не «Libmaple Forever» (кстати, оригинальный Libmaple уже защищен в репозитории Libmaple, доступном для потомства).
<...>

Я не ожидаю, что кто -то берет какую -либо сторону, я просто пытаюсь внести свой вклад, чтобы улучшить библиотеку.
Я открыл выделенную ветку для своих улучшений: ViewTopic.PHP?F = 17&T = 1235
Для всех заинтересованных я бы предложил обсудить подробности.

Лучший, e.

PS: я ответил на ваши вопросы в другой ветке.
PPS: Позвольте мне также добавить, что оригинальные кленовые доски находятся в конце доски F1, чтобы они тоже выиграли для улучшений..