Вряд ли это так просто сделать, чтобы нормально смотрелось в маленьком разрешении 400x240 монохромных точек. Тут надо и дизеринг делать, и дорисовывать каждый кадр. К примеру, рисунок экрана я достаточно долго дорисовывал по пикселям, чтобы все элементы смотрелись красивее. Даже цветочки на труселях волка:) А то чисто после уменьшения оригинальной картинки там было очень ужасный вид.
Очень крутой проект! Я относительно недавно тоже делал свою версию этой легендарной игры на STM32, но я не стал уходить в эмуляцию, а просто написал свой вариант алгоритма игры и даже добавил 24-часовой вариант часов и подсчёт до 9999 очков. Причём я использовал монохромный экран 400х240 пикселей, поэтому изображение выглядит очень похоже на старый ЖКИ:)
У меня теперь многие просят добавить туда мультик после набора 1000 очков:) А я рисовать анимации не умею, так бы добавил бы ради прикола:)
Ещё пока я искал инфу, нашёл такой комментарий на одном из форумов: "Режим отладки был, когда не учитывались штрафные очки. Чтобы включить его, нужно замкнуть вывод 20 процессора на минус питания. И делать это после подачи питания, иначе игра не включится." Если вы делали точный эмулятор, то, возможно, у вас этот режим отладки тоже существует:)
Потом я придумал новый вариант игры на современную тему "Илон Маск ловит Старшипы", это был вариант для моего английского канала https://youtu.be/e2QhG2kzE6A
Как я понял, если не включать режим flow control при открытии порта, то RTS/CTS никак не задействованы аппаратным модулем приёма-передачи, поэтому ими можно управлять программно как захочется. Если же flow control активировать при инициализации порта, тогда эти пины автоматически работают на аппаратном уровне или через драйвер системы.
А что дают два свитых провода? Ёмкость и индуктивность, которые снижают частоту? Что-то мне кажется, что такой подход сильно увеличит температурную нестабильность генератора.
Если вы про DateTime.Now.Ticks, то с этими тиками не всё так просто оказалось. В прошлой статье я использовал их для измерения времени выполнения функции, но в комментариях мне объяснили, что эти тики не обновляются в реальном времени. Я проверил экспериментально, на самом деле, они обновляются через миллисекунды.
Насчёт миллисекунд: конечно, в винде они есть, но вот в RTC микроконтроллера их нет, там просто какой-то регистр, выдающий от 0 до 255 в течение секунды. То есть, напрямую записывать их некуда, а заниматься пересчётом не особо охота было. Да и смысл был только в том, чтобы проверить правильность формулы пересчёта, а не добиться идеальной синхронизации.
Спасибо, любопытно. Правда я мало что понял из этого описания, достаточно запутанная схема:) Впрочем, наверняка схема подстройки в STM32 тоже непростая.
На главной картинке экран от Nokia 1203, а на последней - монохромный экран на 128х64 точки с драйвером ST7567 - их много вариантов бывает. Вообще разрешение 128х64 достаточно популярное, поэтому один и тот же интерфейс можно будет сделать с разными дисплеями. Для настольных часов отличный вариант. В своём видео я рассказывал про один из таких дисплеев https://youtu.be/YvdRZc50BPs
Я делаю всякие поделки на микроконтроллерах и решил сделать часы на STM32. А раз там есть такая фишка, то почему бы её не задействовать? Нет, это не какая-то большая необходимость, а скорее просто интерес и желание немного разобраться с темой, поэкспериментировать. Хотя я до сих пор пользуюсь обычными недорогими настольными часами, которые достаточно сильно бегут вперёд. Возможно, получится их заменить более точными часами своей разработки. В этом плане есть какая-то необходимость, но не прям большая.
Попробовал YandexGPT 4 Pro RC в бесплатном режиме. С числами не особо хорошо работает (правильный ответ: 4 раза). Также код на питоне, который он мне выдал, не запустился.
Да, спасибо, вроде я всё это уже изучил и понял проблему. Свойство Stopwatch.Frequency возвращает true, значит, у меня таймер высокого разрешения. И вышеприведённый код я уже проверил на измерении времени выполнения расчётов в цикле - он показывает микросекунды. Например, код
Stopwatch stopWatch = new Stopwatch(); double f = 0; stopWatch.Start(); for (int i = 0; i < 10000; i++) { f += (double)i / 3; } stopWatch.Stop(); label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString(); label2.Text = f.ToString();
всегда выдаёт примерно 5E-05 . То есть, это 50 мкс. Если менять количество циклов, то время тоже меняется через микросекунды, а не миллисекунды, как с функциями COM-порта. То есть, это реально более точный способ, но именно для задачи в статье ничего особо не изменилось.
Скорее всего намного быстрее, но это же будет не универсальное решение. То есть, такой режим используется только в API драйвера, который у каждой фирмы свой. Тогда программу надо затачивать на конкретную микросхему. В этом плане лучше будет использовать специализированные версии типа CP2104 и CH341, у которых есть дополнительные GPIO. Статья же про стандартный COM порт и его выводы:)
Да, мне тоже CP2102 не подходят именно из-за корпуса. Одну кое-как припаял, но дальше перешёл на CH340 :) Хотя для устройств такой миниатюрный корпус это скорее преимущество, но не для самодельщиков:)
Всегда показывает ноль:) Но если добавить какой-то большой цикл с делением между считываниями, то, действительно, время почти всегда кратно 1 мс, хоть и не ровно.
Вроде бы это должно показывать время в секундах. Как результат - примерно то же самое: в среднем функция выполняется 2 мс для CP2102. То есть, вы правы насчёт точности DateTime.Now.Ticks , но в итоге результаты те же и со Stopwatch(); Попробовал и другие функции - тоже результат совпадает и так же значения постоянно прыгают с шагом примерно в мс.
То есть, функции реально медленные и привязаны к мс, поэтому особенно ничего не изменилось при переходе на более точный метод. Или я что-то не так сделал и тут:)
Вряд ли это так просто сделать, чтобы нормально смотрелось в маленьком разрешении 400x240 монохромных точек. Тут надо и дизеринг делать, и дорисовывать каждый кадр. К примеру, рисунок экрана я достаточно долго дорисовывал по пикселям, чтобы все элементы смотрелись красивее. Даже цветочки на труселях волка:) А то чисто после уменьшения оригинальной картинки там было очень ужасный вид.
Очень крутой проект! Я относительно недавно тоже делал свою версию этой легендарной игры на STM32, но я не стал уходить в эмуляцию, а просто написал свой вариант алгоритма игры и даже добавил 24-часовой вариант часов и подсчёт до 9999 очков. Причём я использовал монохромный экран 400х240 пикселей, поэтому изображение выглядит очень похоже на старый ЖКИ:)
Свой вариант я показал в видео на Ютуб https://youtu.be/e2UXSahfM6E и вконтакте https://vkvideo.ru/video-146803702_456239124
У меня теперь многие просят добавить туда мультик после набора 1000 очков:) А я рисовать анимации не умею, так бы добавил бы ради прикола:)
Ещё пока я искал инфу, нашёл такой комментарий на одном из форумов: "Режим отладки был, когда не учитывались штрафные очки. Чтобы включить его, нужно замкнуть вывод 20 процессора на минус питания. И делать это после подачи питания, иначе игра не включится." Если вы делали точный эмулятор, то, возможно, у вас этот режим отладки тоже существует:)
Потом я придумал новый вариант игры на современную тему "Илон Маск ловит Старшипы", это был вариант для моего английского канала https://youtu.be/e2QhG2kzE6A
Я отправил заявку 15 января, но её до сих пор так и не рассмотрели. Как-то медленно работают:)
Как я понял, если не включать режим flow control при открытии порта, то RTS/CTS никак не задействованы аппаратным модулем приёма-передачи, поэтому ими можно управлять программно как захочется. Если же flow control активировать при инициализации порта, тогда эти пины автоматически работают на аппаратном уровне или через драйвер системы.
А что дают два свитых провода? Ёмкость и индуктивность, которые снижают частоту? Что-то мне кажется, что такой подход сильно увеличит температурную нестабильность генератора.
Если вы про DateTime.Now.Ticks, то с этими тиками не всё так просто оказалось. В прошлой статье я использовал их для измерения времени выполнения функции, но в комментариях мне объяснили, что эти тики не обновляются в реальном времени. Я проверил экспериментально, на самом деле, они обновляются через миллисекунды.
Ну 38768 это опечатка, подправил.
Насчёт миллисекунд: конечно, в винде они есть, но вот в RTC микроконтроллера их нет, там просто какой-то регистр, выдающий от 0 до 255 в течение секунды. То есть, напрямую записывать их некуда, а заниматься пересчётом не особо охота было. Да и смысл был только в том, чтобы проверить правильность формулы пересчёта, а не добиться идеальной синхронизации.
Спасибо, любопытно. Правда я мало что понял из этого описания, достаточно запутанная схема:) Впрочем, наверняка схема подстройки в STM32 тоже непростая.
Может и с этой микросхемой что-то сделаю, есть она у меня. Но она крупнее микроконтроллера:)
На главной картинке экран от Nokia 1203, а на последней - монохромный экран на 128х64 точки с драйвером ST7567 - их много вариантов бывает. Вообще разрешение 128х64 достаточно популярное, поэтому один и тот же интерфейс можно будет сделать с разными дисплеями. Для настольных часов отличный вариант. В своём видео я рассказывал про один из таких дисплеев https://youtu.be/YvdRZc50BPs
Я делаю всякие поделки на микроконтроллерах и решил сделать часы на STM32. А раз там есть такая фишка, то почему бы её не задействовать? Нет, это не какая-то большая необходимость, а скорее просто интерес и желание немного разобраться с темой, поэкспериментировать. Хотя я до сих пор пользуюсь обычными недорогими настольными часами, которые достаточно сильно бегут вперёд. Возможно, получится их заменить более точными часами своей разработки. В этом плане есть какая-то необходимость, но не прям большая.
Но на странные вопросы отвечает неплохо:)
Попробовал YandexGPT 4 Pro RC в бесплатном режиме. С числами не особо хорошо работает (правильный ответ: 4 раза). Также код на питоне, который он мне выдал, не запустился.
И там есть показательное видео о том, как кошка выбирает отверстие для прохода https://www.reddit.com/r/catsareliquid/comments/1g68yzk/cat_really_can_just_fit_through_anything_huh/
Да, спасибо, вроде я всё это уже изучил и понял проблему. Свойство Stopwatch.Frequency возвращает true, значит, у меня таймер высокого разрешения. И вышеприведённый код я уже проверил на измерении времени выполнения расчётов в цикле - он показывает микросекунды. Например, код
Stopwatch stopWatch = new Stopwatch();
double f = 0;
stopWatch.Start();
for (int i = 0; i < 10000; i++)
{
f += (double)i / 3;
}
stopWatch.Stop();
label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString();
label2.Text = f.ToString();
всегда выдаёт примерно 5E-05 . То есть, это 50 мкс. Если менять количество циклов, то время тоже меняется через микросекунды, а не миллисекунды, как с функциями COM-порта. То есть, это реально более точный способ, но именно для задачи в статье ничего особо не изменилось.
Скорее всего намного быстрее, но это же будет не универсальное решение. То есть, такой режим используется только в API драйвера, который у каждой фирмы свой. Тогда программу надо затачивать на конкретную микросхему. В этом плане лучше будет использовать специализированные версии типа CP2104 и CH341, у которых есть дополнительные GPIO. Статья же про стандартный COM порт и его выводы:)
А, вот зачем нужно это свойство порта:)
Да, мне тоже CP2102 не подходят именно из-за корпуса. Одну кое-как припаял, но дальше перешёл на CH340 :) Хотя для устройств такой миниатюрный корпус это скорее преимущество, но не для самодельщиков:)
Да, похоже, вы правы, хотя у меня код:
Int64 start_time1 = DateTime.Now.Ticks;Int64 start_time2 = DateTime.Now.Ticks;label1.Text = (start_time2 - start_time1).ToString();Всегда показывает ноль:) Но если добавить какой-то большой цикл с делением между считываниями, то, действительно, время почти всегда кратно 1 мс, хоть и не ровно.
Попробовал такой вариант:
Stopwatch stopWatch = new Stopwatch();stopWatch.Start();bool b = MyPort.CtsHolding;stopWatch.Stop();label1.Text = ((double)stopWatch.ElapsedTicks / (double)Stopwatch.Frequency).ToString();label2.Text = b.ToString();Вроде бы это должно показывать время в секундах. Как результат - примерно то же самое: в среднем функция выполняется 2 мс для CP2102. То есть, вы правы насчёт точности
DateTime.Now.Ticks, но в итоге результаты те же и соStopwatch();Попробовал и другие функции - тоже результат совпадает и так же значения постоянно прыгают с шагом примерно в мс.То есть, функции реально медленные и привязаны к мс, поэтому особенно ничего не изменилось при переходе на более точный метод. Или я что-то не так сделал и тут:)
Идея, конечно, гениальная:) Правда светодиоды CapsLock и NumLock вполне полезны. И ещё они включаются, когда нажимаешь на соответствующие кнопки.
Но можно добавить переключатель, который активирует эту скрытую функцию лампочек на клавиатуре:)