Я новичок в STM32DUINO и компилируюсь на MAC, USB ведет себя немного странно при сравнении перечисления питания USB и USB -перечисления после фазы программирования с использованием загрузчика STM32Duino.

Я использую синюю таблетку (BP) с generic_boot20_pc13.корзина загружена.
При включении и использовании «LSUSB» BP перечисляется как «Устройство шины 020 014: ID 1EAF: 0004 1EAF Maple»
и можно последовательно подключиться к устройству "/dev/cu.usbmodem1411 ".

После программирования простой эскиз "lsusb" показывает следующее устройство: «Устройство шины 020 024: ID 1EAF: 0003 1EAF Maple 003 Сериал: LLM 003»
На этом этапе невозможно последовательно подключить или перепрограммировать без жесткого сброса BP. В конце диалога загрузки есть подсказка: «Сбросить USB для переключения обратно в режим времени выполнения».
Deducing device DFU version from functional descriptor length Opening DFU capable USB device... ID 1eaf:0003 Run-time device DFU version 0110 Claiming USB DFU Interface... Setting Alternate Setting #2 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0110 Device returned transfer size 1024 Copying data from PC to DFU device Download [ ] 0% 0 bytes Download [= ] 6% 1024 bytes Download [=== ] 13% 2048 bytes Download [==== ] 19% 3072 bytes Download [====== ] 26% 4096 bytes Download [======== ] 33% 5120 bytes Download [========= ] 39% 6144 bytes Download [=========== ] 46% 7168 bytes Download [============= ] 53% 8192 bytes Download [============== ] 59% 9216 bytes Download [================ ] 66% 10240 bytes Download [================== ] 72% 11264 bytes Download [=================== ] 79% 12288 bytes Download [===================== ] 86% 13312 bytes Download [======================= ] 92% 14336 bytes Download [======================== ] 99% 14420 bytes Download [=========================] 100% 14420 bytes Download done. state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode

Нажмите сброс, он вернулся бы в эти быстрые/медленные мигание на некоторое время (режим DFU), а затем прыгнул к своему наброску

Реализация USB Mac OS и Libusb (библиотека, которая используется хост -инструментами) имеют проблему.
Есть связанная тема с этой проблемой. Я модифицировал загрузчик для синей пары, чтобы решить проблему.

Не удалось повторно подключить последовательный монитор после загрузки на macOS
http: // www.STM32duino.com/viewtopic.PHP?f = 21&T = 2050

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

Спасибо за ваш ответ @hanyazou, ваш измененный загрузчик включил вещи в том, что теперь я могу загрузить эскиз несколько раз без какого -либо необходимости сброса BP. Эскиз, который я протестировал, выводит поток символов перед входом в жесткую петлю в ожидании сброса. Если, после программирования, я использую последовательный монитор Arduino, текст отображается правильно. Тем не менее, периодически после использования серийного монитора он больше невозможно программировать АД до тех пор, пока аппаратное обеспечение сбросит:
/Users/johare/Documents/Arduino/hardware/Arduino_STM32/tools/macosx/maple_upload cu.usbmodem1411 2 1EAF:0003 /var/folders/6c/gxr4fz9s0_1cfcfnq7b8fmr40000gp/T/arduino_build_661694/rik.ino.bin dfu-util 0.8 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2014 Tormod Volden and Stefan Schmidt dfu-util: Invalid DFU suffix signature This program is Free Software and has ABSOLUTELY NO WARRANTY dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Deducing device DFU version from functional descriptor length dfu-util: No DFU capable USB device available An error occurred while uploading the sketch

Заглядывая на это немного дальше, эскиз все еще активен, и серийный монитор способен воссоединиться с ним. Тем не менее, периодически невозможно перепрограммировать эскиз. /Users/johare/Documents/Arduino/hardware/Arduino_STM32/tools/macosx/maple_upload cu.usbmodem1411 2 1EAF:0003 /var/folders/6c/gxr4fz9s0_1cfcfnq7b8fmr40000gp/T/arduino_build_661694/rik.ino.bin dfu-util 0.8 dfu-util: Invalid DFU suffix signature Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Copyright 2010-2014 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Deducing device DFU version from functional descriptor length Opening DFU capable USB device... ID 1eaf:0003 Run-time device DFU version 0110 Claiming USB DFU Interface... Setting Alternate Setting #2 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0110 Device returned transfer size 1024 Copying data from PC to DFU device Download [ ] 0% 0 bytes Download [= ] 6% 1024 bytes Download [=== ] 13% 2048 bytes Download [==== ] 19% 3072 bytes Download [====== ] 26% 4096 bytes Download [======== ] 33% 5120 bytes Download [========= ] 39% 6144 bytes Download [=========== ] 46% 7168 bytes Download [============= ] 52% 8192 bytes Download [============== ] 59% 9216 bytes Download [================ ] 66% 10240 bytes Download [================== ] 72% 11264 bytes Download [=================== ] 79% 12288 bytes Download [===================== ] 86% 13312 bytesprocessing.app.SerialException: Error opening serial port '/dev/cu.usbmodem1411'. at processing.app.Serial.(Serial.java:125) at processing.app.Serial.(Serial.java:66) at processing.app.SerialMonitor$3.(SerialMonitor.java:93) at processing.app.SerialMonitor.open(SerialMonitor.java:93) at processing.app.AbstractMonitor.resume(AbstractMonitor.java:110) at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2226) at processing.app.Editor.access$2400(Editor.java:77) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2204) at java.lang.Thread.run(Thread.java:745) Caused by: jssc.SerialPortException: Port name - /dev/cu.usbmodem1411; Method name - openPort(); Exception type - Port not found. at jssc.SerialPort.openPort(SerialPort.java:167) at processing.app.Serial.(Serial.java:114) ... 8 more Error opening serial port '/dev/cu.usbmodem1411'. Download [======================= ] 92% 14336 bytes Download [======================== ] 99% 14444 bytes Download [=========================] 100% 14444 bytes Download done. state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode

Здесь много всего происходит, что выходит за пределы моего рук. Добавление задержки в качестве первой строки setup () предотвращает дальнейшее программирование: void setup() { delay(1000); //Initialize USBSerial and wait for port to open: Serial.begin(); . .

Джоно написал:Заглядывая на это немного дальше, эскиз все еще активен, и серийный монитор способен воссоединиться с ним. Тем не менее, периодически невозможно перепрограммировать эскиз. ... Download [================== ] 72% 11264 bytes Download [=================== ] 79% 12288 bytes Download [===================== ] 86% 13312 bytesprocessing.app.SerialException: Error opening serial port '/dev/cu.usbmodem1411'. at processing.app.Serial.(Serial.java:125) at processing.app.Serial.(Serial.java:66) at processing.app.SerialMonitor$3.(SerialMonitor.java:93) at processing.app.SerialMonitor.open(SerialMonitor.java:93) at processing.app.AbstractMonitor.resume(AbstractMonitor.java:110) at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2226) at processing.app.Editor.access$2400(Editor.java:77) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2204) at java.lang.Thread.run(Thread.java:745) Caused by: jssc.SerialPortException: Port name - /dev/cu.usbmodem1411; Method name - openPort(); Exception type - Port not found. at jssc.SerialPort.openPort(SerialPort.java:167) at processing.app.Serial.(Serial.java:114) ... 8 more Error opening serial port '/dev/cu.usbmodem1411'. Download [======================= ] 92% 14336 bytes Download [======================== ] 99% 14444 bytes Download [=========================] 100% 14444 bytes Download done. ...

Ханьязу написал: Когда вы получите эту ошибку «DFU-UTIL: недоступно USB-устройства DFU», вы должны проверить красный светодиод на BP, чтобы увидеть, успешно ли утилита MAPLE_UPLOAD-RESET с помощью ARDUINO_STM32/Tools/MacOSX/загрузка.

Это то же самое происходит со мной, если я оставлю серийный монитор открытым, а затем нажму кнопку загрузки.
Ответ на эту проблему состоит в том, чтобы закрыть окно серийного монитора, прежде чем попытаться загрузить новый код. Это правда, если вы используете Old Arduino IDE. Последняя IDE автоматически закроет последовательный порт, когда вы нажимаете кнопку загрузки и снова откроете последовательный порт после загрузки.
FWIW: У моего чертежа есть синий пользовательский светодиод (PC13) и красная мощность светодиода. У одного из моих светодиодов синего и красного пользователя светодиод. И у другого из моих светодиодов с красным мощностью и зеленым пользователем светодиода.

Ханьязу написал: Это правда, если вы используете Old Arduino IDE. Последняя IDE автоматически закроет последовательный порт, когда вы нажимаете кнопку загрузки и снова откроете последовательный порт после загрузки.

Ханьязу написал:[ diff --git a/tools/macosx/maple_upload b/tools/macosx/maple_upload index 8d15eff..ef581c8 100755 --- a/tools/macosx/maple_upload +++ b/tools/macosx/maple_upload @@ -50,4 +50,13 @@ if [ ! -x ${DFU_UTIL} ]; then exit 2 fi +echo ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R + +# take a breath waiting for restarting the target device +/bin/echo -n wait for ${dummy_port_fullpath}... +while [ ! -c ${dummy_port_fullpath} ]; do + sleep 0.1 +done +sleep 0.3 +echo done.

Рик Кимбалл написал:Ханьязу написал: Это правда, если вы используете Old Arduino IDE. Последняя IDE автоматически закроет последовательный порт, когда вы нажимаете кнопку загрузки и снова откроете последовательный порт после загрузки.

Джоно написал: Я все еще вижу проблему, в которой используется задержка сразу после настройки (): void setup() { delay(1000); //Initialize USBSerial and wait for port to open: Serial.begin(); while (!Serial) { ; } while (!Serial.isConnected() ) { ; }

Это на самом деле работает и в Windows, ожидая 3 секунды в конце win/maple_upload.летучая мышь (`ping -n 3 127.0.0.1 > nul`), и мне не нужно закрывать/вновь открывать серийный монитор. (Maplemini, Bootloader, Arduino 1.8.2)

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

--РЕДАКТИРОВАТЬ: Почему загрузчик влияет подробности в эскизе?

У меня есть, код серийного монитора только ожидает сериала.начинать(). Если он не видит сериала.Begin () экран серийного монитора остается пустым. Я не знаю, что на самом деле делает эскиз.

--РЕДАКТИРОВАТЬ: не объясняет, что программирование не работает. Загрузчик тратит ли загрузчик на 265 мс, пытаясь настроить серийный путь перед выполнением программирования? void setup() { //Initialize USBSerial and wait for port to open: Serial.begin(); delay(1000);

Джоно написал:У меня есть, код серийного монитора только ожидает сериала.начинать(). Если он не видит сериала.Begin () экран серийного монитора остается пустым. Я не знаю, что на самом деле делает эскиз.

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

Отличный @danieleff!

--РЕДАКТИРОВАТЬ: Это объясняет программирование? Задержка больше 0.265 с эскиза заставляют программирование провалиться? Я до сих пор не вижу этого.

@Johno
Есть ли какие-либо ошибки от Maple_upload, а также загрузки? Вы не можете программировать, если он не сможет сбросить доску.

Если у вас все еще есть эти две строки ниже в настройке (), они могут заблокировать эскиз, а загрузка может не работать. Поскольку загрузка-резит сделайте открытие/закрытие в 1200BPS, чтобы уведомить сброс в пользовательском приложении (Sketch), работающем на плате, и эскиз должен обрабатывать открытые/закрытые в 1200BPS правильно.
while (!Serial) { ; } while (!Serial.isConnected() ) { ; }

Рик Кимбалл написал: Основываясь на выводе отладки Johno, выясняется, IDE пытается возобновить серийный порт до завершения загрузки.

Спасибо @hanyazou, эскиз работает нормально с двумя строками кода или без них.

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

Я прав, чтобы понять, что сериал.Begin должен быть в любом эскизе для загрузчика/загрузчика, чтобы функционировать независимо от того, что эскиз не имеет никакой другой потребности в серийном? Нет, извините. Мое понимание не было правильным.
Я могу загрузить свой простой набросок, который не включает сериал.начинать () неоднократно.

Итак, были решены все ваши проблемы? Чем дольше ожидание загрузчика?

Ваши изменения улучшили мой опыт работы STM32Duino.

Тем не менее, я хотел бы понять, почему задержка (1000) в качестве первой строки после Setup () приводит к сбои последующей загрузки программы. То есть, если активный код, загруженный во флэш -память, содержит задержку (1000) в качестве первой строки в setup (), то следующая загрузка потерпит неудачу с:
/Users/johare/Documents/Arduino/hardware/Arduino_STM32/tools/macosx/dfu-util/dfu-util -d 1EAF:0003 -a 2 -D /var/folders/6c/gxr4fz9s0_1cfcfnq7b8fmr40000gp/T/arduino_build_996/rik.ino.bin -R -R dfu-util 0.8 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2014 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ dfu-util: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Deducing device DFU version from functional descriptor length dfu-util: No DFU capable USB device available An error occurred while uploading the sketch

Обычно я пробовал другой подход, я жду ключи от серийного монитора while(!Serial.available()) delay(10);

Вы смогли проверить мой опыт в этом?
Все остальное место на.
* Чувствует *, что задержка предотвращает взаимодействие загрузчика с DFU-UTIL. Нет... Я могу многократно загружать этот эскиз.
void setup() { delay(1000); // 2000, 3000... Serial.begin(9600); while (!Serial); Serial.println("Hello!"); // initialize digital pin LED_BUILTIN as an output. pinMode(LED_BUILTIN, OUTPUT); } // the loop function runs over and over again forever void loop() { Serial.println("running..."); digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) delay(1000); // wait for a second digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW delay(1000); // wait for a second }

Первоначально, чтобы диагностировать проблемы, я склонен использовать DFU -UTIL -L и DFU -uTil -a 2 -r -d эскиз.бин
Чтобы установить мои наброски E.глин.Использование сценария оболочки #!/bin/bash dfu-util -l dfu-util -a 2 -R -D $*

AG123 написал: Для Maple Mini Boards существует кнопка (пользователь) (на самом деле Boot0 * повторно используется * для этой цели), которую вы можете нажать, чтобы сообщить загрузчику, чтобы перейти в «Режим вечной загрузки»
Эта опция невозможна на Bluepill, потому что это просто перемычка, если вы установите перемычку для подъема Boot0 и нажмите сброс, он попадет в режим загрузчика UART -загрузчика/установки (это натуральный загрузчик ST), а не загрузчик STM32Duino загрузчик. Чтобы попасть в режим «вечной загрузки», означало бы, что вы должны сохранять низкий уровень Boot0, когда вы нажимаете сброс, и быстро устанавливаете Boot0 High * во время * Fast Blinks, это очень сложно, если сделать Boot0 или переключатель в этом отношении

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

Я думал, что обычно серийный монитор начинается вручную из меню, разве это не так?

Обратите внимание, что установка эскиза не требуется, если она просто для запуска эскиза, сброс на синей таблетке/Maple Mini перезагрузил эскиз.
Чтобы все было более предсказуемым, e.глин. Я ожидаю отпечатки на последовательном терминале, я часто исправляю несколько кодов, чтобы дождаться нажатия клавиш на последовательной консоли, прежде чем остальные заезды эскизов, другие уловки, которые я часто делаю с проблемными набросками, - это включить светодиод доски, это будет укажите, если после всего эскиза разбился E.глин.//board led pin 33 PB1 on maple mini #define BOARD_LED_PIN 33 void setup() { Serial.begin(115200); pinMode(BOARD_LED_PIN,OUTPUT); digitalWrite(BOARD_LED_PIN,HIGH); Serial.println("press any key to start"); while(!Serial.available()) delay(10); digitalWrite(BOARD_LED_PIN,LOW); //led off after keypress is received }

AG123 написал:Я думаю, что если проблемы с последовательным монитором сохраняются, мы сможем отзывы об этом исполнителям Arduino IDE, чтобы предоставить некоторые «настройки/предпочтения» для серийного монитора, чтобы, возможно, настраиваемая задержка для запуска последовательного монитора после эскиза установить. Возможно, это решило бы некоторые проблемы серийного монитора

Я думал, что обычно серийный монитор начинается вручную из меню, разве это не так?

Ханьязу написал: Вы смогли проверить мой опыт в этом?
Все остальное место на.
* Чувствует *, что задержка предотвращает взаимодействие загрузчика с DFU-UTIL. Нет... Я могу многократно загружать этот эскиз.
void setup() { delay(1000); // 2000, 3000... Serial.begin(9600); while (!Serial); Serial.println("Hello!"); // initialize digital pin LED_BUILTIN as an output. pinMode(LED_BUILTIN, OUTPUT); } // the loop function runs over and over again forever void loop() { Serial.println("running..."); digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level) delay(1000); // wait for a second digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW delay(1000); // wait for a second }

Спасибо, Даниэфф, Ханьязу

Я попробовал патчи Hanyazou, это в основном редактирует сценарий оболочки, который является частью ядра Arduino_stm32. Я использую Linux OpenSuse 13.1
ViewTopic.PHP?F = 28&T = 2107#P28441

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

Скрипт оболочки является частью Arduino/Adware/arduino_stm32/tools/{macosx, linux, linux64, win}/maple_upload
Следовательно, нам не нужно было бы ждать, пока исполнители Arduino IDE предоставит какие -либо исправления

Я могу скомпилировать/загрузить эскиз и подключиться к нему в серийном терминале в Arduino IDE после патча.
(USB) Сериал также работает так же, как и ожидалось

@Johno,
Вы можете попробовать загрузчик Boot1 в качестве загрузчика «Постоянная загрузка» из репозитория Роджера
http: // www.STM32duino.com/viewtopic.PHP ... = 20#p28466
Это может помочь заставить BP ждать установки, вместо того, чтобы вручную мчаться между нажатием сброса и нажатия на установку Sketch на Arduino IDE

Привет, Джонно,

Я попробовал ваш код с некоторыми дополнениями, чтобы дождаться нажатия клавиши
Видимо задержка перед сериалом.begin () оказывает влияние.
Если я установил задержку (450); перед сериалом.begin () эскиз все еще работает нормально
Однако, если я установил задержку (500); перед сериалом.Begin () Sketch Swalls, светодиод остается включенным и не реагирует на Keypress (я.эн. светодиод не выключился) на основе моего клавиши

Однако, если вы разместите эту задержку (1000) после сериала.начинать () все работает. Я думаю, что это может иметь какое-то отношение к инициализации USB-серии на хосте. Возможно, слишком длинная задержка приводит к тайм -ауту на хозяине, и хост больше не рассматривает это как сериал USB (я.эн. Устройство CDC ACM).
Следовательно, мы не должны откладывать задержку перед сериалом.начинать(). Сериал.begin () должен начинаться сразу же настройки (), чтобы инициализация USB-сериала и инициализация могла начаться как можно скорее как можно скорее.
#include "Streaming.h" //http://arduiniana.org/libraries/streaming/ //board led pin 33 PB1 on maple mini #define BOARD_LED_PIN 33 static const bool USE_STREAMING = true; void setup() { //delay(1000); //Initialize USBSerial and wait for port to open: Serial.begin(); delay(1000); pinMode(BOARD_LED_PIN,OUTPUT); digitalWrite(BOARD_LED_PIN,HIGH); Serial.println("press any key to start"); while(!Serial.available()) delay(10); digitalWrite(BOARD_LED_PIN,LOW); //led off after keypress is received if ( USE_STREAMING ) { Serial << "ASCII Table ~ Character Map" << endl; } else { // prints title with ending line break Serial.println("ASCII Table ~ Character Map"); } } // first visible ASCIIcharacter '!' is number 33: int thisByte = 33; void loop() { if ( USE_STREAMING ) { Serial << (char)thisByte << ", dec: " << _DEC(thisByte) << ", hex: " << _HEX(thisByte) << ", oct: " << _OCT(thisByte) << ", bin: " << _BIN(thisByte) << endl; } else { Serial.write((char)thisByte); Serial.print(", dec: "); Serial.print(thisByte, DEC); Serial.print(", hex: "); Serial.print(thisByte, HEX); Serial.print(", oct: "); Serial.print(thisByte, OCT); Serial.print(", bin: "); Serial.println(thisByte, BIN); } if (thisByte == 126) { // you could also use if (thisByte == '~') { // This loop loops forever and does nothing // while (true) { // delay(2000); thisByte = 33; // } } // go on to the next character thisByte++; }

Я рад, что мы видим те же симптомы. Не поймите меня неправильно, я очень доволен тем, где мы должны.

Моя голова изо всех сил пытается принять эту задержку (1000) перед сериалом.начинать должно иметь эти последствия, и мне нужно понять, почему это происходит, прежде чем принять участие в обходном пути. На некоторые наброски не влияют задержка, в то время как другие облажаются программированием, у нас есть проблема здесь. Если задержка имеет эти последствия, могут быть и другие, и отладка их в * следующем * проекте может быть еще более сложным, чем раскрыть его сейчас.
Ответ будет в загрузке, так как загрузчик выпускает код уровня пользователя, прежде чем он завершит обработку запуска.

Не беспокойтесь, я на самом деле отказался от Arduino Ide за его серийные неприятности, пока не попытался исправить Hanyazou сегодня
Я устанавливал эскиз вручную с помощью DFU-UTIL и использую внешний серийный терминал

Я думаю, что исправления Hanyazou в сценарии оболочки DFU-Install должны быть отправлены в репозиторий Roger Arduino_stm32, по крайней мере, для Linux и Mac, я не уверен насчет Windows, хотя

Если сериал.begin () не называется по умолчанию в инициации эскиза перед настройкой () (это в кодах основных кодов Libmaple), это можно прочитать как «хорошая вещь». я.эн. Если вам нужен сериал, вам нужно позвонить в сериал.начинать () как можно раньше в Setup ();. Таким образом, если вы хотите использовать USB для любых других целей, вы можете назвать USB_SOME_OTHER_DEVICE_CLASS.Begin (), это позволило бы использовать синюю таблетку/клен Mini в качестве «универсального» USB -устройства, E.глин. Другой эскиз заставляет BP/мм работать в качестве разных USB -устройств

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

Я не слишком уверен в сценариях сборки, я сделал патчи, как предложено в патче Hanyazou: arduino_stm32/tools/{macosx, linux64}/maple_upload.
Остальные являются «запасами» от arduino_stm32

Я также наблюдал, как однажды проблема с последовательным перечислением при использовании задержки (1000) прямо в начале setup (), перед сериалом.begin (), используя Win 10.
Так что я могу подтвердить, у нас может быть проблема здесь.

Я думаю, что задержка (n) никогда не должна вызывать до сериала.begin (), задержка вызова (n) перед сериалом.begin () может привести к тому, что хост * будет выходить на Time Out и больше не распознавать USB -устройство

В вашем файле сценария показано несколько устройств: Johns-MacBook-Pro:~ john$ ./dfu-install.sh /var/folders/6c/gxr4fz9s0_1cfcfnq7b8fmr40000gp/T/arduino_build_696853/rik.ino.bin dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Deducing device DFU version from functional descriptor length Found Runtime: [05ac:821d] ver=0154, devnum=8, cfg=1, intf=3, path="29-3", alt=0, name="UNKNOWN", serial="UNKNOWN" Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="20-2", alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000", serial="LLM 003" Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="20-2", alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000", serial="LLM 003" Found DFU: [1eaf:0003] ver=0201, devnum=7, cfg=1, intf=0, path="20-2", alt=0, name="STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.", serial="LLM 003" dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ dfu-util: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Deducing device DFU version from functional descriptor length dfu-util: More than one DFU capable USB device found! Try `--list' and specify the serial number or disconnect all but one device

@Johno,
У вас есть еще одно устройство, которое способно DFU, следовательно, добавьте опцию -D 1EAF: 0003 в последнюю строку, которая устанавливает сам эскиз #!/bin/bash dfu-util -l dfu-util -d 1eaf:0003 -a 2 -R -D $*

У Windows 7 иногда есть эта проблема

Дело в этом...

Сериал.begin () уже называется в boards_setup.CPP в board_setup_usb (), который называется из досок.CPP в init ();

Так что, если у меня есть

void setup() { // put your setup code here, to run once: Serial.end(); delay(1000); Serial.begin(); } int c=0; void loop() { // put your main code here, to run repeatedly: Serial.println(c++); delay(500); }

@Роджер
Я бы подумал, что «проще» оставить USBERIAL.begin () в кодах инициализации ядра Libmaple.
Причина в том, что многие эскизы Arduino ожидают, что сериал будет «там», и мы, вероятно, получим больше «жалоб» на нефункциональный сериал.

Использование этого «флага» звучит как интересное решение. Но я наполовину задаюсь вопросом, если в этом случае второй сериал.Begin () Это началось с эскиза в этом конкретном случае фактически инициализируйте интерфейс USB-сериал! я.эн. Первая инициализация не удалась. Кажется, могут быть некоторые другие возможности, e.глин. между USBSerial.Begin () до 2 -го сериала.Begin (), время из какого -то извращения произошло, если задержка вставлена ​​перед вторым сериалом.начинай (), но я не уверен, хотя

Я могу потратить немного времени, играя с USB.конец(); usb_reset () /* i.эн. Потягивание D+/D- низко в течение 10 мс */; usb_something_else.начинать()
Я думаю, что это возможный способ реализации многофункционального USB-устройства.
USB Serial должен оставаться там, так как очень полезно иметь серийный USB с самого начала, эскиз всегда может «дерироваться» в другое USB -устройство в своем коде e.глин. Эскиз может «слушать на USB-сериале», а затем закончить USB-сериал, сделать USB-сброс и инициализировать как USB что-то еще. Это проложит путь для «многофункционального» USB-устройства, я.эн. USB-Serial-это всегда режим по умолчанию, чтобы слушать «команды»
всего 2 цента

AG123 написал:@Johno,
У вас есть еще одно устройство, которое способно DFU, следовательно, добавьте опцию -D 1EAF: 0003 в последнюю строку, которая устанавливает сам эскиз #!/bin/bash dfu-util -l dfu-util -d 1eaf:0003 -a 2 -R -D $*

Джоно написал: @hanyazou делает у вашего загрузчика все еще есть опция Boot0, чтобы тянуть высоко во время Fast Flashes, чтобы войти в Perpetual Bootloader?
У моего BP есть мягкий пульс на Boot0, и я, кажется, не могу вытащить его высоко, чтобы запустить режим вечного загрузчика.

«Длинная» задержка @hanyazou Bootloader, похоже, не требуется.

Усовершенствованный загрузчик @hanyazou вместе с поправками к сценарию, по -видимому, делает все это, кроме сериала.Начните проблему, как объяснено @Roger.

Если вам нужен вечный загрузчик для загрузки для работы над вашей системой, существует способ, которым магическое число помещается в регистр BKP (NV RAM) непосредственно перед эскизом при перезагрузке для загрузки через сериал.

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

Таким образом, вы можете попробовать изменить ядро, чтобы установить рег.

Редактировать.

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

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

Ханьязу написал:Почему это вызывает проблему, когда вы называете сериал.Начните () дважды с некоторой задержкой () ?

Я мог бы воспроизвести ошибку с помощью этой модификации.
void setup() { delay(500); - Serial.begin(9600); + Serial.begin(); while (!Serial); Serial.println("Hello!");

Ханьязу написал:Я мог бы воспроизвести ошибку с помощью этой модификации.
void setup() { delay(500); - Serial.begin(9600); + Serial.begin(); while (!Serial); Serial.println("Hello!");

Я думаю, что это может быть правдой, что это воспроизводимо, мои мысли в том, что для диагностики это было бы необходимо познакомиться со спецификациями класса USB и USB CDC CRSC. Я не слишком уверен, если при определенных условиях хост (я.эн. PC / O / S и т. Д.) Может оказаться в * Time Out * из -за чрезмерной задержки.
Государства USB и государственные переходы довольно сложны, среди государств - «киоск» состояние. Как только USB -хост попадет в состояние «киоска», я думаю, что он может прекратить отправлять ответы на устройство.

Я склонен к воспроизведению этого, если вставлю задержку свыше 450 мс перед сериалом.Begin () вызывается. Я не слишком уверен, почему после сериала.begin () называется, он может переносить задержку на 1000 мс, я еще не попробовал дальнейшие задержки после (второго) сериала.начинать()
http: // www.STM32duino.com/viewtopic.PHP ... = 30#p28483

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

Другой тест, который мне еще предстоит сделать, и подтвердить, можно ли просто пропустить этот сериал.Begin () в эскизе, как он был называться во всех, на стадии инициализации еще до того, как он достигнет Main (). Я не слишком уверен, что в силу несчастного случая, 2 -й сериал.begin () фактически инициализируйте USB. Тем не менее это кажется маловероятным. Я думаю, что второй сериал.begin () просто повторно инициализировать USB.

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

Я думаю, если мы можем как -то использовать, скажем, STM32F407 в качестве анализатора протокола, поскольку он имеет 2 USB и имеет как OTG, так и режим устройства. Но все же, тем не менее, это не будет легко, так как, по крайней мере, нужно написать «эскиз» / s / w, чтобы сделать это.

всего 2 цента

всем привет,

Пожалуйста, обратите внимание, что я отправил пиар для исправлений Hanyazou и Danieleff's для введения короткой задержки сразу после вспышки эскиза
http: // www.STM32duino.com/viewtopic.PHP ... 107#P28441
http: // www.STM32duino.com/viewtopic.PHP ... = 10#p28452

Пожалуйста, прокомментируйте непосредственно на GitHub в запросе на привлечение с обратной связью
>>> https: // github.com/rogerclarkmelbourne/ ... 2/pull/292

Rogerclark написал:Ханьязу написал:Я мог бы воспроизвести ошибку с помощью этой модификации.
void setup() { delay(500); - Serial.begin(9600); + Serial.begin(); while (!Serial); Serial.println("Hello!");

Флаг действительно должен быть логином, а не инт

(Компилятор может превратиться в INT, но все еще лучше, если он кодируется как логический. )

Я обновлю репо

Извини! Мой патч выглядит не правильно. Начальное значение и логика нечетны, хотя я проверил свой патч, и это сработало.

Этот патч работает хорошо. (Но начальное значение неверно.) USBSerial::USBSerial(void) : running(1) { #if !BOARD_HAVE_SERIALUSB ASSERT(0); #endif } void USBSerial::begin(void) { if (running) return; running = 1; #if BOARD_HAVE_SERIALUSB usb_cdcacm_enable(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT); usb_cdcacm_set_hooks(USB_CDCACM_HOOK_RX, rxHook); usb_cdcacm_set_hooks(USB_CDCACM_HOOK_IFACE_SETUP, ifaceSetupHook); #endif }

@hanyazou

Да.

Я заметил, что происходит что -то странное

Я вставляю какой -то код, чтобы установить переменную _hasbegun = true; в Usbeserial :: begin ()
void USBSerial::begin(void) { #if BOARD_HAVE_SERIALUSB if (_hasBegun==true) { return; } usb_cdcacm_enable(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT); usb_cdcacm_set_hooks(USB_CDCACM_HOOK_RX, rxHook); usb_cdcacm_set_hooks(USB_CDCACM_HOOK_IFACE_SETUP, ifaceSetupHook); _hasBegun=true; #endif }

Я отправил пиар для загрузчика.
https: // github.com/rogerclarkmelbourne/ ... ER/pull/22

Rogerclark написал:@hanyazou
Я знаю, что код запускается очень рано в начале, но я не уверен, как переменная может быть очищена, или, возможно, она не будет установлена.
Возможно, сделать его статичным, может помочь, так как на F1 есть только одно USB -устройство

Вызовы кодов непосредственно в main (), который не конкретен на плате, не является хорошей идеей, так как вы, вероятно, столкнетесь с другой платой, которая, возможно, работает по -разному названному классу, который инициализирует serialusb e.глин. В ядре F4 он будет назван serialusb, а не серийным
эн.глин. В филиале F4 (Black/Generic), который в настоящее время находится в репозитории Стива, вот как написано init (), serialusb.begin () запускается непосредственно перед выходом из init ()
https: // github.com/stevstrong/arduino_s ... доски.CPP

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

------- STM32F1DUINO Bootstrap -----------
Есть вещи, которые запускаются до выполнения main (), так и работает
в папке варианта e.глин. Stm32f1/variants/maple_mini/wirish есть начало.S и start_c.c, график вызова начинается как
начинать.с -> start_c () -> __libc_init_array ();
__libc_init_array () является частью Newlib, которая выглядит так
https: // github.com/eblot/newlib/blob/ma ... ISC/Init.в /* Iterate over all the init routines. */ void __libc_init_array (void) { size_t count; size_t i; count = __preinit_array_end - __preinit_array_start; for (i = 0; i < count; i++) __preinit_array_start[i] (); //********* _init (); count = __init_array_end - __init_array_start; for (i = 0; i < count; i++) __init_array_start[i] (); }

Есть некоторые дискуссии о некоторых переменных, которые должны быть объявлены «летучими» или иным образом компилятор может «оптимизировать» некоторые коды, я предполагаю, что нам может потребоваться углубляться в USB -коды, если мы действительно подозреваем, что это связано с этими ». нестабильные объявления.

Я думаю, что это недавнее исправление Эдогальдо для Ringbuffer посвящено недавним обновлениям Master Branch
http: // www.STM32duino.com/viewtopic.PHP?f = 3&t = 2091
Если USB Serial использует Ringbuffer, возможно, это могло решить, смягчил проблемы?

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

Возможно, изменение кода USB на летучие.

F1 имеет только 1 USB -интерфейс, поэтому переменная может быть объявлена ​​статичной, но это решение не будет работать для F4, поскольку у нее 2 сообщения USB

Я где -то читал, что «нестабильный» должен сообщить компилятору/процессору, чтобы прочитать это значение из памяти/gpio, а не взять значение из кэша
я.эн. Переменная считается «нестабильной», если значение может измениться, даже если сам процессор «ничего не сделал». Это было бы верно для регистров GPIO
Но я еще не выкопал глубже в USB -кодах

Я мог бы представить, что, возможно, есть 2 заявления
a = gpio_register;
b = gpio_register;
Компилятор может прочитать gpio_register и просто использовать регистры процессора для обновления A и B. Объявление gpio_register volatile я предполагаю

AG123 написал: ------- STM32F1DUINO Bootstrap -----------
Есть вещи, которые запускаются до выполнения main (), так и работает
в папке варианта e.глин. Stm32f1/variants/maple_mini/wirish есть начало.S и start_c.c, график вызова начинается как
начинать.с -> start_c () -> __libc_init_array ();

Когда я не вошел и не изучал USB -коды, я не мог бы сказать, действительно ли это причиной. Но на основе анализа загрузки последовательности
init () на самом деле не отличается от Main (), они являются простыми C -функциями

Я играл с идеей, что мы называем init (), setup () и loop () в main () main() { init(); setup(); while(1) loop(); }

Я думаю, что и init (), и ctors вызываются из __libc_init_array (). Так что «нестабильный» не имеет значения.
Вы не можете назвать сериал.begin () in init (), потому что init () следует называться Brefore ctors.

AG123 написал:Когда я не вошел и не изучал USB -коды, я не мог бы сказать, действительно ли это причиной. Но на основе анализа загрузки последовательности
init () на самом деле не отличается от Main (), они являются простыми C -функциями
[/код]

Я думаю, что это чище и легче читать

Я не думаю, что это важно так, как будто вы прослеживаете коды E.глин. Использование отладки, это в основном обычные функции C, я.эн. оба init () и main ();
Но USB -коды и сам USB довольно сложны, и, вероятно, потребуется некоторое время, чтобы проанализировать и определить основную причину проблем

Обратите внимание, что оператор * Specai * 'Constructor' не является обычным конструктором C ++, они являются C -функциями, так что __LIBC_INIT_ARRAY () может их вызвать.
С точки зрения статического распределения, некоторые глобальные настройки памяти E.глин. Для глобальных переменных и статических переменных выполняются в самом start_c ()
Может быть случай, когда конструкторы C ++ используют один и тот же механизм __LIBC_INIT_ARRAY (), но я еще не изучил его подробно, даже тогда они вызывают различные функции, возможно, непересекающиеся

В качестве альтернативы на самом деле есть другой крючок void _init () {}

AG123 написал: Что касается инициализации USB, конструктор статического объекта. Я думаю, что один из способов «исправить» - это то, что строительство класса USB не должна иметь дело с оборудованием, а просто инициализировать свой собственный экземпляр и глобальные переменные. Не касаясь аппаратного обеспечения, оно не будет поймано в ситуации E.глин. что адрес вектора прерывания изменен.

В этом случае это кажется двойной инициализацией USBSerial.начинать () это вызывает неприятности. Поможет ли это, если мы используем синглтонский рисунок? эн.глин. class UsbSerial { public: static UsbSerial* getInstance() { static UsbSerial static_usbserial; return &static_usbserial; } }

Я добавил код, чтобы назвать USB Serial.Begin (), не осознавая, что могут возникнуть потенциальные проблемы из -за всего процесса init, но странно, что он работает, и USB Seeial инициализируется ОК.

Метод Синглтона опирается на статическое свойство в классе, но, как все, что нам нужно для записи, это то, называется ли USB -серийный начало, не можем ли мы просто сделать статичное свойство _hasbegun?

Казалось, это на самом деле не о сам init () на этот раз, а *конструктор *для Usbeserial называется *дважды *и создает глупые сценарии.
Что казалось необходимым, так это каких -то кодов «синглтона», так что есть только 1 экземпляр, и что мы не будем называть конструктор USBERIAL дважды

Или, возможно, если этот 2 -й init после всех инициализированных вещей для работы в порядке. Мы бы оставили это в конце концов. Возможно, «несчастный случай» заключается в том, что есть только один кусок аппаратного обеспечения USB, поэтому, если вы инициализируете его снова, это все же

всего 2 цента

Rogerclark написал: Разве мы не можем просто сделать свойство _hasbegun статическим?

Не была первоначальной причиной автоматического сериала.Begin () звоните из -за запроса от @jcw ? Кажется, что он отказался от использования местного USB, http: // jeelabs.org/article/1708a/ и использует чипы FTDI на доске, которую он продает. Он согласился со мной во время первоначальных дискуссий, что Native USB утомительно в использовании.

Мне не очень нравится, что нативный USB создается без просьба (пользователь). Мне не нравится 3 -секундная задержка, когда вы настраиваете свою плату для использования загрузчика STM32Duino. Я бы предпочел решить, если и когда я использую родной сериал. Есть что -то в том, чтобы кое -что навязывало мне, что меня беспокоит.

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

Тем не менее, я не вижу точки автоматического вызова сериала.begin () Если ваш метод загрузки установлен на последовательность, Stlink или BMP. По моему мнению, это не должно быть вызвано, если пользователь это не назовет. Называя его автоматически съесть процессор для обработки USB Heartbeat IRQ, который я мог бы использовать для других вещей. Это задерживает мой код с немедленного начала при сбросе. Это разжевывает пространство кода флэш -кода, которое никогда не будет вызвано, если я не использую его.

FWIW: Я хотел бы увидеть дополнительную нативную USB, у которого нет Hokey In-Stream Sainsing для Magic Reset String. Это было бы намного чище и, вероятно, меньше, так как все, что будет делать, это действовать как устройство CDC ACM.

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

Рик,

Я не думаю, что USB -сериал включен вообще, если вы загружаете через сериал.

Это все еще включено для Stlink, так как у внедорожных внедорожников нет встроенного сериала, который содержит версию «Доски Nucleo.

Я не могу вспомнить, что такое текущая конфигурация для BMP, но USB Serial может быть отключен на BMP, поскольку у него также есть собственный сериал.

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

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

Так что я думаю, что статический VAR, вероятно, является лучшей работой, чтобы замаскировать этот сериал.begin () уже был вызван в Init (для некоторых конфигураций)

Единственная потенциальная проблема со статическим VAR была бы для нескольких случаев серийного класса USB, но мы можем обойти это, используя битовые поля в статическом VAR, чтобы указать номер серийного экземпляра USB.
И на F1 есть только один экземпляр в любом случае.

Ханьязу написал: Обратите внимание, что конструктор серийного объекта не касается USB Serial HW.
В настоящее время, по моему предположению, это так, как ниже:

0. start_c () вызывается из начала.С
1. __libc_init_array () называется
2. init () называется
3. board_setup_usb () называется
4. Сериал.begin () называется
_hadbegun = true, и серийный HW будет инициализирован.
5. Конструктор, «usbeserial :: usbeserial (void): _hasbegun (false)», вызванный из __libc_init_array ()
_hasbegun = false
6. main () называется
7. setup () называется
8. 2 -й сериал.begin () называется
Это перезаписывает USB HW регистры, потому что _hadbegun == false.

Проблема в том, что мы называем сериал.begin () до того, как конструктор серийного объекта будет вызван.

Привет, Даниэль,
__libc_init_array () фактически явно называется в кодах запуска start_c ();
Это запускает специальные коды Premain () __attribute__(( constructor (101))) void premain() { init(); }

Вау, это странный дизайн, чтобы иметь функцию init, называемую, как это было конструктор.

(Да, мастер? Джинн выходит из бутылки...)

Насколько я помню, проблема, которую я пытался решить тогда, заключается в том, как заставить USB -загрузочный загрузчик работать вместе с эскизом. Поскольку загрузчик нуждается в инициализации и перечислении аппаратного обеспечения USB, я думаю, что проблема заключалась в том, чтобы попытаться избежать повторной инициализации USB во второй раз в эскизе, так как это вызвало бы повторную деятельность (я.эн. Разрыв и восстановление серийного соединения) в «setup ()».

Я не продолжил этот путь, но для тех, кто интересуется этим кодом - последняя версия должна быть доступна на GitHub, см https: // github.com/jeelabs/emello/ree ... S/USBSerup

Даниэфф написал: Вы прошли с отладчиком?
__libc_init_array () называется оба в 1. и 5. шаги?

@hanyazou

Вы правы в отношении своих оценок о статических инициализациях класса
http: // www.STM32duino.com/viewtopic.PHP ... 132#P28861

Казалось бы, инициализации оборудования должны быть выполнены в 2 частях тех частей, от которых должны зависеть статические конструкторы, которые должны быть вызваны до конструкторов статических объектов

Тогда существуют аппаратные инициализации, которые зависят от статических объектов E.глин. USBERIAL Class/Object. Это должно быть названо * после * Статические конструкторы инициализации завершены.

Это может быть, например, быть в main () перед настройкой ().

Тем не менее, инициализации аппаратного обеспечения, как правило, представляют собой e Board и MCU.глин. USB -контроллер на F1 и F4 разные, это будет означать вызов различных функций вниз по стеку вызовов. Следовательно, в этом случае было бы лучше, если бы создан второй init (), но этот 2 -й инициатор живет в конкретных файлах совета директоров. Возможно, в файлах доски/вариантов могут быть #includes, так что общие инициализации для той же семьи E.глин. STM32F1 может быть вызван в этом общем файле.

Я хотел бы отправить PR исправить эту проблему с инициализацией USB.

Я добавил init_2nd () и board_setup_usb_2nd (), как ниже,
diff --git a/STM32F1/cores/maple/boards_private.h b/STM32F1/cores/maple/boards_private.h index 49867ca..690577a 100644 --- a/STM32F1/cores/maple/boards_private.h +++ b/STM32F1/cores/maple/boards_private.h @@ -63,6 +63,7 @@ namespace wirish { void board_setup_clock_prescalers(void); void board_setup_gpio(void); void board_setup_usb(void); + void board_setup_usb_2nd(void); void series_init(void); } diff --git a/STM32F1/cores/maple/main.cpp b/STM32F1/cores/maple/main.cpp index 3d78443..73f6f14 100644 --- a/STM32F1/cores/maple/main.cpp +++ b/STM32F1/cores/maple/main.cpp @@ -27,6 +27,7 @@ extern void setup(void); extern void loop(void); extern void init(void); +extern void init_2nd(void); // Force init to be called *first*, i.e. before static object allocation. // Otherwise, statically allocated objects that need libmaple may fail. @@ -35,6 +36,7 @@ extern void init(void); } int main(void) { + init_2nd(); // board initialization using statically allocated objects setup(); while (1) { diff --git a/STM32F1/cores/maple/usb_serial.cpp b/STM32F1/cores/maple/usb_serial.cpp index 5eaf70e..dc86da7 100644 --- a/STM32F1/cores/maple/usb_serial.cpp +++ b/STM32F1/cores/maple/usb_serial.cpp @@ -55,13 +55,16 @@ static void ifaceSetupHook(unsigned, void*); #define USB_TIMEOUT 50 -USBSerial::USBSerial(void) { +USBSerial::USBSerial(void) : _hasBegun(false) { #if !BOARD_HAVE_SERIALUSB ASSERT(0); #endif } void USBSerial::begin(void) { + if (_hasBegun) + return; + _hasBegun = true; #if BOARD_HAVE_SERIALUSB usb_cdcacm_enable(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT); usb_cdcacm_set_hooks(USB_CDCACM_HOOK_RX, rxHook); @@ -90,6 +93,7 @@ void USBSerial::end(void) { usb_cdcacm_disable(BOARD_USB_DISC_DEV, BOARD_USB_DISC_BIT); usb_cdcacm_remove_hooks(USB_CDCACM_HOOK_RX | USB_CDCACM_HOOK_IFACE_SETUP); #endif + _hasBegun = false; } size_t USBSerial::write(uint8 ch) { diff --git a/STM32F1/cores/maple/usb_serial.h b/STM32F1/cores/maple/usb_serial.h index 96bbefc..cf66347 100644 --- a/STM32F1/cores/maple/usb_serial.h +++ b/STM32F1/cores/maple/usb_serial.h @@ -71,6 +71,9 @@ public: uint8 getDTR(); uint8 isConnected(); uint8 pending(); + +protected: + bool _hasBegun; }; #ifdef SERIAL_USB diff --git a/STM32F1/variants/generic_stm32f103c/wirish/boards.cpp b/STM32F1/variants/generic_stm32f103c/wirish/boards.cpp index 36fcb3e..a6acbb5 100644 --- a/STM32F1/variants/generic_stm32f103c/wirish/boards.cpp +++ b/STM32F1/variants/generic_stm32f103c/wirish/boards.cpp @@ -75,6 +75,10 @@ void init(void) { boardInit();^M }^M ^M +void init_2nd(void) {^M + wirish::priv::board_setup_usb_2nd();^M +}^M +^M /* Provide a default no-op boardInit(). */^M __weak void boardInit(void) {^M }^M diff --git a/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp b/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp index 5516282..b1e2c34 100644 --- a/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp +++ b/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp @@ -94,10 +94,16 @@ namespace wirish { for(volatile unsigned int i=0;i<512;i++);// Only small delay seems to be needed, and USB pins will get configured in Serial.begin^M gpio_set_mode(PIN_MAP[PA12].gpio_device, PIN_MAP[PA12].gpio_bit, GPIO_INPUT_FLOATING);^M #endif ^M - Serial.begin();// Roger Clark. Changed SerialUSB to Serial for Arduino sketch compatibility^M #endif^M }^M ^M + __weak void board_setup_usb_2nd(void) {^M +#ifdef SERIAL_USB^M + // Roger Clark. Changed SerialUSB to Serial for Arduino sketch compatibility^M + Serial.begin();^M +#endif^M + }^M +^M __weak void series_init(void) {^M // Initialize AFIO here, too, so peripheral remaps and external^M // interrupts work out of the box.^M

Пожалуйста, сделайте это как PR, даже если только для BluePill (Generic STM32F103C), тогда другие люди могут проверить его для себя

Вы имеете в виду, вы думаете, что последний простой патч лучше? Я должен изменить все варианты stm32f1/*/wirish/если я изменяю main () в STM32F1/Cores/Maple/Main.в.

Я не знаю, какой шанс вы измените.

Но если вы отправите пиар для одного совета E.глин. Bluepill, он позволит сообществу проверить его, и если есть подавляющее большинство в пользу изменения, оно может стать частью ядра.

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

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

Rogerclark написал:Я не знаю, какой шанс вы измените.

Но если вы отправите пиар для одного совета E.глин. Bluepill, он позволит сообществу проверить его, и если есть подавляющее большинство в пользу изменения, оно может стать частью ядра.

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

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

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

Я думаю, что исправление хорошее
Это «обнаружение» о глобальных или статических объектах C ++ - это «Просвещение». Мне никогда не бывает, что статическая инициализация класса связана с одной функцией C __libc_init_array (), i.эн. C ++ предназначен для «Все, что происходит в main ()» не раньше, чем он. C ++ предназначен для «системного программирования», но я предполагаю, что дизайнерам не удалось решить проблему, если есть только яйцо (написание O/S) без курицы (сама O/S)

Я вытащил пиар, чтобы исправить это, и он работает нормально.

Однако я заметил еще одну существующую ошибку.

Я добавил 2 фиктивные функции для начала
//Roger Clark. Two new begin functions has been added so that normal Arduino Sketches that use Serial.begin(xxx) will compile. void USBSerial::begin(unsigned long ignoreBaud) { volatile unsigned long removeCompilerWarningsIgnoreBaud=ignoreBaud; ignoreBaud=removeCompilerWarningsIgnoreBaud; } void USBSerial::begin(unsigned long ignoreBaud, uint8_t ignore) { volatile unsigned long removeCompilerWarningsIgnoreBaud=ignoreBaud; volatile uint8_t removeCompilerWarningsIgnore=ignore; ignoreBaud=removeCompilerWarningsIgnoreBaud; ignore=removeCompilerWarningsIgnore; }

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

Но я нашел другую проблему, которая, по -видимому, влияет на Maple Mini, а также повлияет на Bluepill

Если я назову сериал.конец(); а затем сериал.начинать () USB больше не работает.

Похоже, что это потому, что код в USB_CDCACM_ENABL
void usb_cdcacm_enable(gpio_dev *disc_dev, uint8 disc_bit) { /* Present ourselves to the host. Writing 0 to "disc" pin must * pull USB_DP pin up while leaving USB_DM pulled down by the * transceiver. See USB 2.0 spec, section 7.1.7.3. */ gpio_set_mode(disc_dev, disc_bit, GPIO_OUTPUT_PP); gpio_write_bit(disc_dev, disc_bit, 0); /* Initialize the USB peripheral. */ usb_init_usblib(USBLIB, ep_int_in, ep_int_out); }

Я только что заметил, что в USBSerial :: END это называет USB_CDCACM_DISABLE, который

действительно устанавливает бит диска USB

gpio_write_bit(disc_dev, disc_bit, 1);