Я использую BMP для загрузки и просмотра выхода последовательного порта этого эскиза (протестирован с помощью Generic F103T и F103R):
if(dfuActive(&USBD_Device) == 0) { loops--; }

Какая линия заканчивает вы установили?
не могли бы вы попробовать с задержкой (100)

время с 1000 мс
секунды +секунд*168 +/- 1 мсек (округление?)

Накладные расходы «ln» части Println составляет 168 мс??

Стивен

Я не установил никаких окончаний (могу ли я?).

Я, наверное, должен ясли, что я только изменил первый println для печати. Таким образом, первая строка отличается, но остальная часть теста одинакова для обоих случаев, println используется внутри цикла, и все же время отличается от времени.

С задержкой петли 100 мс я получаю:
ECHO "MAGIC" > \\.\com155:

@JCW Я не установил никаких окончаний (могу ли я?). В правом нижнем углу окна последовательного монитора находится ящик для выбора линии

Этот вывод выглядит как счет*(100+17)
Оригинальный вывод теперь выглядит как 10*count*(100 + 17)

Так что есть «делать что -то» на цикле 100 мс/часы/прерывание?

Стивен

Ах, но я не использую IDE, я использую серийную мостику BMP.
FWIW, это ничем не отличается от режима Serial Monitor - Line установлен на «Newline».
В любом случае, я не вижу, как получение / отображение конца может повлиять на это.

Загадочный...

В любом случае, я не вижу, как получение / отображение конца может повлиять на это.
и я нет
Ах, но я не использую IDE, я использую серийную мостику BMP Настоящая версия BMP или Rick Kimballs на «таблетке»?
У меня были его вывод на серийный монитор из целей PA9/PA10; Если это «серийное мостовое»?
Может, я думаю о полу-хостинге?
Так что есть «делать что -то» на цикле 100 мс/часы/прерывание? Так что есть «сделать что -то, что нужно 17 мс.» На цикле 100 мс?

Стивен

Я использую «Уродливую доску» (я думаю, имя Роджера) с Ebay, с прошивкой Rick JC66.
Мой блок работает хорошо, как SWD, так и серийные мостики (Real Uart, а не полугодий).

Я думаю, что мой первый вопрос был бы другим: почему время отличается в курсе, с такой же Код, когда единственная разница в настройке, вызов для печати VS Println?

Что происходит с первым снятым печати/println?
SRP

Ах, хороший момент! Вернуться к 0/1001/2002/3003. Добавьте Println в настройке, и дополнительные задержки возвращаются.

Ничего не происходит между setup () и loop (): https: // github.com/rogerclarkmelbourne/ ... E/Main.CPP

Может быть, это связано с USB в конце концов (прерывает?). Я использую последнюю 100% немодифицированную проверку Arduino-STM32.
Но причина, по которой я вообще попал сюда, заключалась в том, что я не могу появиться сериал USB - мой сериал привязан к USART.
У меня раньше работал сериал USB на той же доске (это Hy-TinyStm103, PA0 активен D+ подтягивание).
Я использую F103T, который был скопирован и настроен из F103C. Но обратите внимание, что то же самое происходит, если я выбрал F103R.

17% в течение 100 мс и 1000 мс - это подсказка. Должен быть какой -то прерывание питания циклов процессора.
Но почему разница в Loop () с однострочным изменением в настройке ()?

Может быть полезно, если кто -то другой сможет воспроизвести эту проблему на USART. Или USB, в этом отношении.

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

О, это количество*(1000+1)

Не могли бы вы попробовать 100 & 10000 без настройки печати/println?
Мне интересно, станет ли 10000 10017 *** РЕДАКТИРОВАТЬ 17% - 1700 DOH!

«Bell Going Ting Ting» - это как -то связано с USB Serial Serial Mlow Down и/или Buffer Size?

Что у нас есть в миксе, это BMP и его код. что он использует ST (?) & opencm3 libs и т. Д. Может быть, в настройке системных часов что -то есть, и мы недостаточно знаем о коде BMP
SRP

JCW написал:Может быть полезно, если кто -то другой сможет воспроизвести эту проблему на USART. Или USB, в этом отношении.

Мы можем исключить BMP, IMO. Он сообщает о сериале с доски на мой экран, как и Serial Monitor в IDE.
Это не может повлиять на то, что делает целевая доска, он просто передает персонажей мне, независимо от задержек времени.

100 мс, без настройки печати: 0/100/200/301/401/501/602/702/802/903/1003
10000 мс, без настройки печати: 0/10006/20014/30021/40028/50035

В некотором смысле это правдоподобно: немного накладных расходов на петлю.

Но опять же, это не. Часы Millis () излечены из прерывания Systick, я предполагаю, что.
Таким образом, даже с µC, занятым с другими прерываниями, он не должен терять время.

Не говоря уже о том, что на 17% потеря:

10000 мс, с настройкой Println: 0/11674/23348/35023/46697/58371

Спасибо, Рик.
Может быть, ваша проблема как -то связана с вашим портом платформы STM32F103T? Сначала тоже думал. Но то же самое происходит, когда я строю для F103R.

Я только что попробовал на доске Olimex-P103. То же самое 17% Миллис () Странность.
Загрузить через BMP, серийный заголовок на ext через FTDI UART.

Гремлины!

@Rick - стоит задать вопрос?
@Rick - всегда стоит задать неправильный или глупый вопрос, хотя? Иногда они делятся
где ты взял hy-tinystm103? Aliexpress ничего не дает & eBay дает моторные части

Что происходит с охраняемым первым проходом Print/Println в цикле E.глин.
void setup_vcc_sensor() { adc_reg_map *regs = ADC1->regs; regs->CR2 |= ADC_CR2_TSEREFE; // enable VREFINT and temp sensor regs->SMPR1 = ADC_SMPR1_SMP17; // sample rate for VREFINT ADC channel }

ОК, одна часть решенной головоломки - задержка () не делает то, что я ожидал, она проходит велосипедное питание вместо того, чтобы проверять истекшее время, отслеживаемое прерыванием Systick: https: // github.com/rogerclarkmelbourne/ ... Стр.#L36-L45

Что должно сделать задержка (), это зачитываем Millis (), а затем простаивает петля до тех пор, пока не пройдут миллисекунды. Тогда на это не повлияет активность прерывания на заднем плане.

Итак, теперь остается вопрос: что ест 17% µc циклов в одном случае, а почему не в другом?

РЕДАКТИРОВАТЬ: Вот исправление - https: // github.com/jcw/arduino_stm32/co ... B9D3A4649B
(Обратите внимание, что для отслеживания 17% накладных расходов вы не должны применять это изменение)

где ты взял hy-tinystm103? Хех - http: // www.HOTMCU.com/stm32f103tb-arm-c ... P-222.HTML
Что происходит с охраняемым первым проходом Print/Println в цикле E.глин. Я все еще получаю 17% дополнительных накладных расходов.

Я также переместил Begin () на настройку и изменил строку Println на int println. Нет изменений. Сумасшедший, я знаю.
Это либо что -то нелепое, смотрящее мне прямо в лицо, либо очень важная ошибка, жаждая поймать :)

Я буду придерживаться P103 с F103R, чтобы исключить H/ W или варианты.

Редактировать - У этого тоже есть замедление: // Reading Vdd and Temperature Sensor // Pito 8/2016 // Temperature sensor at ADC16, VREFINT at ADC17 // BluePill and Maple Mini void setup_vdd_tempr_sensor() { adc_reg_map *regs = ADC1->regs; regs->CR2 |= ADC_CR2_TSEREFE; // enable VREFINT and Temperature sensor // sample rate for VREFINT ADC channel and for Temperature sensor regs->SMPR1 |= (0b111 << 18); // sample rate temperature regs->SMPR1 |= (0b111 << 21); // sample rate vrefint adc_calibrate(ADC1); } void setup(){ setup_vdd_tempr_sensor(); Serial.begin(115200); delay(1); } void loop() { float tempr, vdd; // reading Vdd by utilising the internal 1.20V VREF vdd = 1.20 * 4096.0 / adc_read(ADC1, 17); // following 1.43 and 0.0043 parameters come from F103 datasheet - ch. 5.9.13 // and need to be calibrated for every chip (large fab parameters variance) tempr = (1.43 - (vdd / 4096.0 * adc_read(ADC1, 16))) / 0.0043 + 25.0; Serial.print("Vdd= "); Serial.print(vdd); Serial.println(" V"); Serial.print("Temp= "); Serial.print(tempr); Serial.println(" C"); delay(500); }

Следующая глупость, разделите задержку и между Capture Millis () на INT, захватите миллисы () до & После печати всех этих INT распечатайте эту разницу

SRP

Я не уверен, что это скажет нам. Аномалия задержки / миллиса была решена.
Есть что -то, что ест 17% циклов. Иногда. Мерфи и Гейзенберг в одном.

Я на некоторое время позволю этому жареный. Может быть.
Посмотрю, почему я не вижу серийного устройства USB в своих эскизах. Может это связано. Кто знает?

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

-рик

[Edit1] Удалило плохое предложение кода [/edit1]

Спасибо. Вот что я мог найти о порядке init: https: // github.com/rogerclarkmelbourne/ ... PP#L65-L76

Просмотр оригинального либмапла

https: // github.com/leaflabs/libmaple/bl ... h_time.CPP

Похоже, что код был там с самого начала. * Мне было интересно, было ли это изменение STM32Duino, и не похоже, что это было *

Похоже, что некоторые люди решили свернуть свои собственные:

https: // github.com/leaflabs/libmaple/bl ... Проволока.H#L54

хм ..

-рик

Похоже, что некоторые люди решили бросить свои собственные Не редкость, даже в OSS-Land :)

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

Я бы подумал только в переполнении буфера TX.

Если вы напечатаете "[Hello]" Это 7 Chars Long. Плюс еще 2 конец строки (\ n + \ r) делает 9 chars.
Если размер буфера TX составляет 8 байтов, то для самой последней строки, заканчивающей чар, SW время ожидания, чтобы освободить буферное пространство для одного чара.
Имеет ли это смысл?

Попробуйте печатать "Привет" (без скобков).

Когда нет println () в setup (), времена 0/1002/2005/3007.
Когда у Println есть даже пустая строка в качестве Arg, Times 0/1169/2339/3508.

Зарегистрированное использование данных не изменяется, только размер кода, но три println без ARG в порядке, в то время как один Println («») не является, а прежние генерируют больше кода.

Еще один данных: если я называю печать ISO Println в setup (), я могу печатать большие строки, не видя дополнительных задержек. Может быть, есть что-то особенное с обработкой новой линии?

Я не слишком обеспокоен.Т.м. Поскольку эскиз действительно работает, просто что -то начинает увеличивать 17% циклов процессора без четкой причины, что определенно является причиной для беспокойства, если мы не сможем это объяснить.

Обновлять - Обратите внимание, что с PR#131 теперь объединен в филиал Dev, таймер больше не будет показывать Эти задержки (но, я ожидаю, будет продолжаться 17% -ная велосипеда). Таким образом, чтобы исследовать это, вы не должны бежать из филиала «разработки» в GitHub.

Обновление № 2 - Похоже, это центральный код для написания персонажей в USB: https: // github.com/rogerclarkmelbourne/ ... #L107-L136 - Это нетривиально, но я не могу придумать ни одной причины, почему это приведет к быстрому увольнению или что-то в этом роде или что-то в этом роде.

Ага!

Если я прокомментирую этот код: https: // github.com/rogerclarkmelbourne/ ... #L129-L134 - Тогда все работает, как и ожидалось, больше не замедляется. Этот пустой, в то время как петля может быть намеком, хотя я не могу сказать, что я понимать Почему это изменение работает. Может отправить 2 чарса (\ r \ n), я.эн. Линия, заканчивающаяся от вызова Println, имеет значение - в этом конкретном состоянии?

Пустой, короткий, длинный... Все работает. Даже отправка тысяч персонажей все еще работает, поэтому я не уверен, что делает этот тест. Может быть, код должен сравниваться с более старыми версиями, и что -то осталось или изменилось случайно?

Мое предложение было бы: давайте прокомментируем это и сделаем это изменением в филиале разработки.

Вы могли бы попробовать посмотреть в репонгах Leadlabs/Libmaple.

Были некоторые изменения / исправления ошибок, которые они применили после того, как мы серьезно отклонились от их кода около года назад.

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

Однако я подозреваю, что это ошибка, которую никто не заметил.

Rogerclark написал:Вы могли бы попробовать посмотреть в репонгах Leadlabs/Libmaple.

Спасибо

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