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

Это перестало работать. Несмотря на то, что не проходит только при выполнении некоторых последовательных компаний (при 10400 бод) с другим STM32, выступая в качестве притворного ЭБУ.

Итак, я сделал GIT Refloog, чтобы увидеть, каким был предыдущий хэш -притяжение, и нашел его: 4DB3994 Head@{1}

Итак, после выполнения: git reset -hard Head@{1}

Я восстановил, и проблема решена.

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

PS, это проявляется как тяжелый повес.

Я редко делаю git utling...

Скорее, я предпочитаю быть Джо-пользователем и просто скачать Zip и Unzip в каталог Temp. Затем я использую утилиту Linux Muld для выполнения каталога, файловой дифференциации. Мне нравятся красивые цвета, и презентация колонки/колонки, кажется, соответствует моему конкретному мышлению.


Луча

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

Просто нужно выяснить, где/почему/что мне нужно изменить...
#include #define BOARD_SPI1_NSS_PIN PA4 //Port2Pin('A', 4) int sensor_data[3] = { 0, 0, 0 }; SPIClass spi(1); void setup() { spi.begin(); spi.setBitOrder(MSBFIRST); spi.setDataMode(SPI_MODE0); spi.setClockDivider(SPI_CLOCK_DIV128); pinMode(BOARD_SPI1_NSS_PIN, OUTPUT); } void loop() { digitalWrite(BOARD_SPI1_NSS_PIN, LOW); sensor_data[0] = spi.transfer(0); sensor_data[1] = spi.transfer(1); sensor_data[2] = spi.transfer(2); digitalWrite(BOARD_SPI1_NSS_PIN, HIGH); delay (100); }

Хорошо, теперь это немного странно....

Мой эскиз выводит информацию отладки в Serial (USBERIAL) и отправка/получение запросов OBDII через Serial3.

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

Есть пара коммитов, которые могут быть по причине (на мой взгляд): BOOT1/PB2 (TIM2_CH2/SPI1_SCK)/SPI3_CLK/TRACESWO/I2S3_CK/JTDIO/PB3

Может это то, что вы ищете spi.beginTransaction(SPISettings(1000000)); // 1 MHz //spi.begin(); //spi.setBitOrder(MSBFIRST); //spi.setDataMode(SPI_MODE0); //spi.setClockDivider(SPI_CLOCK_DIV128);

Я признаю, что сериал USB висит, пока данные не принимаются хостом.
Существует обсуждение GitHub в отношении этой проблемы: https: // github.com/rogerclarkmelbourne/ ... D3ECD733E2

Это был непреднамеренный побочный эффект изменения, чтобы решить другую проблему.

В идеале USB -сериал должен быть в состоянии отправлять данные на проведение программного обеспечения, которое не устанавливает DTR, и кажется, что Arduino IDE находится в меньшинстве программ, которые по умолчанию устанавливают DTR

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

[Rogerclark - Пт 18 января 2019 г. 20:46] - ...
В идеале USB -сериал должен быть в состоянии отправлять данные на проведение программного обеспечения, которое не устанавливает DTR, и кажется, что Arduino IDE находится в меньшинстве программ, которые по умолчанию устанавливают DTR
...

Я читаю сообщения GitHub; Как историк форума, я просто хочу напомнить всем, что версия Arduino IDE Leaflabs была их собственным распространением V0022... Итак, они могли сделать то, что, черт возьми, они хотели.

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

Луча

я думаю, что Стив прав в одном
https: // github.com/rogerclarkmelbourne/ ... T-31985859 Стевстранг написал: Самые доски Arduino будут работать без DTR, потому что у них есть сериал USART.

Когда я исправил серийную проблему USB для F4, я проанализировал полный серийный протокол USB и должен был прийти к выводу, что, Afaik, в случае USB -сериала, DTR - единственный флаг, доступный для приложения хоста, чтобы сообщить клиенту, что он может получить данные. Так что я не думаю, что это была ошибка от Leaflabs, чтобы использовать его.

Выдержка из Википедии:
«Готово терминала данных (DTR)-это контрольный сигнал в последовательных коммуникациях RS-232, передаваемом из оборудования терминала данных (DTE), например, компьютера, на оборудование передачи данных (DCE), например, модем, чтобы указать, что терминал готов к коммуникациям, и модем может инициировать канал связи."

Это правда, у нас здесь есть сериал USB вместо RS232, но область такого же.

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

Таким образом, поскольку выпуск стабильного выпуска, кажется, является приоритетом каждого, лучшее, что я могу сделать, это простое обмен IFDEF на ifndef (или наоборот), чтобы это изменение было отключено по умолчанию.

Тогда я, вероятно, изменю ветвь «разработки», чтобы добавить это изменение снова, и постараюсь исправить его последствия.

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

[Rogerclark - Сб 19 января 2019 г. 23:39] - ...
Интересно, как то, что я думал, было бы простым изменением, вызвало проблему, которая не влияет на большинство людей.
Следовательно, даже автоматизированное тестирование e.глин. Чтобы проверить компиляции кода, и даже тестирование времени выполнения, вероятно, не обнаружило бы эту ошибку.

Начав одну группу QA (программное обеспечение) и управляя группой из 10 программистов Java для того, что казалось навсегда, я видел вашу историю много раз повторялась. Одной из самых больших проблем в QA является создание тестовых наборов и репрезентативных данных (Inc. метаданные) люксы. Это наполовину искусство и половина магии.

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


Луча

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

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

Но это не блокирует, если вы запускаете из внешнего источника питания или USB -зарядного устройства и т. Д.

Проблема возникает только в том случае, если вы подключены к компьютеру (E.глин. ПК), который перечисляет USB -шину, но у вас нет последовательного терминала, работающего для принятия входящих данных.


В любом случае.

Глядя на опрос около года назад...

https: // www.STM32duino.com/viewtopic.PHP?t = 2477

Большинство людей хотели выбора о том, должен ли USB -сериал блокировать, а второй в опросе, когда USB -сериал не должен блокировать.


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


Я знаю, что это изменение в ядре, и он не порадует всех, поскольку он может нарушить некоторый существующий код, но исправление вещей, в которых ядро ​​Libmaple не придерживается API Arduino (или ведут себя как большинство досок ARDUINO AVR), IMHO Хорошая идея, даже если она нарушает 1% существующих приложений.

<защита от пламени на шлем>

К вашему сведению

Мой новый код, который, кажется, работает (в usb_serial.CPP)
/* Using the first SPI port (SPI_1) SS <--> PA4 <--> BOARD_SPI1_NSS_PIN SCK <--> PA5 <--> BOARD_SPI1_SCK_PIN MISO <--> PA6 <--> BOARD_SPI1_MISO_PIN */ #include #define BOARD_SPI1_NSS_PIN PA4 //Port2Pin('A', 4) int sensor_data[3] = { 0, 0, 0 }; SPIClass spi(1); void setup() { spi.beginTransaction(SPISettings(1000000)); // 1 MHz pinMode(BOARD_SPI1_NSS_PIN, OUTPUT); } void loop() { digitalWrite(BOARD_SPI1_NSS_PIN, LOW); sensor_data[0] = spi.transfer(0); sensor_data[1] = spi.transfer(1); sensor_data[2] = spi.transfer(2); digitalWrite(BOARD_SPI1_NSS_PIN, HIGH); delay (100); }

Роджер, если честно, если он не блокирует, пока USB отключен, это достаточно для меня хорошо.

Я только заметил это во время развития против моего проекта, и доски всегда работают с USB в то время, следовательно, DTR будет иметь значение.