Попробуйте прокомментировать линию с серийным.flush (), так как он не будет работать, как и ожидалось.

Стивестронг написал:Попробуйте прокомментировать линию с серийным.flush (), так как он не будет работать, как и ожидалось.

Bennehboy ​​написал:Стивестронг написал:Попробуйте прокомментировать линию с серийным.flush (), так как он не будет работать, как и ожидалось.

Вполне возможно.

Я сообщил об этом, сопровождающему библиотеки, это немного за мной.

Что происходит, когда просто печатать элемент? 'Сериал << элемент<<endl; '
и добавить простой сериал<<'*************<<endl; ' строка, чтобы увидеть, умирает ли он там
SRP

ZMEMW16 написал:Что происходит, когда просто печатать элемент? 'Сериал << элемент<<endl; '

Bennehboy ​​написал:ZMEMW16 написал:Что происходит, когда просто печатать элемент? 'Сериал << элемент<<endl; '

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

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

И да, отладчик был бы хорош - уверен, что, черт возьми, бьет, перемещая сериал.println ("получил сюда"); о коде

Так что, похоже, идиот здесь, должно быть, сделал что -то глупое, код, когда он обновлен из GitHub, работает нормально на Nano, но все еще сбивает мини -.

Вы имеете в виду, что на некоторых досках AVR вылетает ?

Rogerclark написал:Вы имеете в виду, что на некоторых досках AVR вылетает ?

Эти флаги обсуждались в другой ветке

http: // www.STM32duino.com/viewtopic.PHP?t = 1241

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

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

Rogerclark написал:Эти флаги обсуждались в другой ветке

http: // www.STM32duino.com/viewtopic.PHP?t = 1241

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

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

Rogerclark написал:Эти флаги обсуждались в другой ветке

http: // www.STM32duino.com/viewtopic.PHP?t = 1241

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

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

Мой проект использует H/W SPI & i2c и много библиотек Так что есть еще одна база, покрытая с точки зрения I2C.

Виктор

Хорошо.

Я сделаю это.

Я опубликую платформу для замены.текст

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

Bennehboy ​​написал:Просто имейте в виду, что на первом компиляции CC1.Exe будет много жаловаться.

TBH Я не совсем уверен, когда IDE отображает измененные параметры сборки, восстанавливая все »и выполняет полную компиляцию, он, по -видимому, передает параметры STD = GNU ++ 11 в компиляторы C ++ и C, C One (CC1.Exe я предполагаю), затем просто отображает предупреждение, в котором говорилось, что оно было передано вариант, который имеет отношение только к C++. К счастью, это хорошо справляется с этим, просто может показать много предупреждений о том, что люди не привыкли.
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C [enabled by default]

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

Однако есть проблема, которую я обнаружил при использовании нескольких дисплеев SSD1306, потому что для всех дисплеев используется один кадр -буфер в ОЗУ, и он очищается для каждого экрана, который приводит к тому, что меню выпускает каждый раз «ClearDisplay» называется.

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

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

Bennehboy ​​написал:TBH Я не совсем уверен, когда IDE отображает измененные параметры сборки, восстанавливая все »и выполняет полную компиляцию, он, по -видимому, передает параметры STD = GNU ++ 11 в компиляторы C ++ и C, C One (CC1.Exe я предполагаю), затем просто отображает предупреждение, в котором говорилось, что оно было передано вариант, который имеет отношение только к C++. К счастью, это хорошо справляется с этим, просто может показать много предупреждений о том, что люди не привыкли.
cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C [enabled by default]

Да, я, наверное, добавил это не в том месте.

Я добавил его в флаги сборки для Maple Mini в досках.текст:
mapleMini.build.cpu_flags=-DMCU_STM32F103CB -DSERIAL_USB -std=gnu++11

Нет жалоб, если вы положите это в компиляцию.CPP.Линия флагов, а не C.компиляция.Линия флагов на платформе.текст
Q также на платформе STM32F4.TXT или просто добавьте ко всей платформе.TXT файлы?
SRP

ZMEMW16 написал:Нет жалоб, если вы положите это в компиляцию.CPP.Линия флагов, а не C.компиляция.Линия флагов на платформе.текст
Q также на платформе STM32F4.TXT или просто добавьте ко всей платформе.TXT файлы?
SRP