Сделал программу, которая запускает прошивку от AVR микроконтроллера, написанную в среде Arduino, WinAVR, AVR Studio (и других) с использованием специальных библиотек на Си. В итоге получается простая программа для Windows. Скачать программу наноням, а также описание и примеры можно на странице http://www.nanoslavic.ru/nanonyam.html
Здесь хотелось бы почитать отзывы и предложения, если кто-то решится попробовать что-то сделать в наноням
Вот простая программа, которая выводит "Hello, World!" на экран и скриншот полученной программы.

Какую задачу ваша программа решает, для чего ее можно использовать?
Для какой-никакой кроссплатформы? Да вроде нет: там гвоздями прибита консоль, причем кривая виндовая. Да и в поддержке контроллерной периферии что-то сомнения.
Чтобы писать виндовые (и только виндовые консольные?! уже бредово звучит...) программы в привычной среде? Так в этом смысла нет: текстовые редакторы везде одинаковы. Хоть в программерском нотпаде писать можно, подсветка там вроде была.

Можно использовать, например, для проработки графического меню для какого-нибудь дисплея без необходимости в реальном железе. После проработки программа легко перенесётся в реальный микроконтроллер.
Конечно, можно использовать Proteus, но он ведь сильно платный и требовательный к ресурсам и не для всех дисплеев есть компоненты.
Это не консольная программа, а скорее окно, в котором можно рисовать и которое может считывать клавиатуру и мышку. Вполне неплохо для моделирования менюшек. И тут нет периферии! Вместо неё тут Windows API. Скачайте и почитайте описание PDF.
Второй пример: для создания своего специфического терминала для COM-порта. Можно хоть графики рисовать на основе данных, поступающих из порта.
Третий пример: для создания управляющей Windows-программы для прибора. Например, делаем на ардуине датчик, который отправляет через USB-COM-порт данные о температуре. Также в ардуине, но для Nanonyam пишем программу, которая красиво отображает температуру в окне программы, при необходимости пишет в файл. И всё на одном языке Си, без необходимости изучать другие системы.
Пример четвёртый: делаем платку, которая отправляет в COM-порт команды по каким-нибудь событиям (например, нажата кнопка). Пишем программу для Nanonyam, которая по умолчанию спрятана (отключено окно), но появляется с сообщением, когда пришла команда от платы. Или можно запускать другие программы или имитировать нажатие комбинаций клавиш в системе (например, чтобы убавить громкость в плеере или перейти к другому треку).
Программа Nanonyam для людей, которые изучили ардуино (или что-то другое) для AVR и не хотят изучать другое. То есть это только для любителей. Для профи этот инструмент нафиг не нужен. И это всего лишь пробная beta, пока я не уверен, что собираюсь это пилить дальше.

Графическое меню для AVR при помощи winapi-подобных функций? Пожалейте контроллер!
Графики на основе данных с COM-порта проще рисовать стандартными средствами . (с флагами, кажется, накосячил, ну да суть понятна) По крайней мере, я примерно таким способом имитировал осциллограф на контроллере. Потом, конечно, написал более-менее нормальную оболочку на GLUT. Но возможность посмотреть график только стандартными утилитами, без написания кода, пусть и в простейшем виде, штука полезная.
И такое делал, но тоже более по-человечески. На работе была задача сделать адаптер для научного АЦП с COM-портовым интерфейсом чтобы подключать в USB. Со стороны железа это вылилось в ATmega8 + max232 + vusb (HID). А со стороны компа - "драйвер" в юзерспейсе, без графической оболочки, естественно, читающий данные с адаптера и пишущий их в файл. А уж читать файл и отображать информацию на экране - задача тривиальная.
То есть сама постановка задачи: обработка отдельно, отображение отдельно, особенно это важно с измерительными устройствами. Вдруг кому-то нужно будет их обрабатывать - не лезть же в код драйвера, правда?
Сильно сомневаюсь, что ваша программа наберет популярность. Все же вы пытаетесь смешать уж больно далекие среды. Если человек хочет писать графический интерфейс, пусть учит нормальные библиотеки, которыми весь мир пользуется - Qt, gtk, wxWidgets и т.п. Да хоть Delphi / CBuilder / Lazarus если задача "нашлепать компонентов на форму". Вот эти знания потом пригодятся.
Кстати о менюшках и тому подобном. Возможно, стоит посмотреть в обратную сторону - портировать стандартные графические библиотеки под AVR. Возможно, где-то упростить и урезать (скажем, реализацию многопоточности из Qt тащить явно не нужно).

Для создания интерфейсных приложений под ПК/android и ардуинки имеется вот такая IDE
https://processing.org
и ее "референс"
https://processing.org/reference/
далее...
симулятор ардуино-уно (для не слишком навороченных программок):
https://www.sites.google.com/site/unoardusim/
Зачем еще чего-то изобретать?
Освоить бы то, что имеется на данный момент!

Пы.СЫ.
Для самой адуринки - как этап развития попробуйте многофайловые проекты сделать (самодельные библиотеки это как обязательный навык).

Вы, конечно же, не почитали описание Nanonyam на моём сайте? Причём здесь контроллер?
Там и рисуется всё стандартными средствами.

Добавлено after 7 minutes 50 seconds:


Я в курсе и про processing и про симуляторы AVR. В processing немного другой язык (java-подобный) и сходу вы туда не перейдёте, а симуляторы направлены на симуляцию схем, а не управление windows. А в nanonyam вы просто меняете библиотеки и у вас куча новых функций. Это как взять новую навороченную плату ардуино, только не реальную, а виртуальную. Будто все выводы микроконтроллера направлены не во внешние схемы, а внутрь компьютера и им можно управлять.
Конечно, не известно зачем это нужно и будет ли популярно - какой толк от новорождённого?
Основная мысль этого всего: люди ленивы, особенно те, кто в ардуино только ради простоты и любопытства (а таких немало). Я сделал ещё одну лентяйку. Не надо учить новые языки и программы - всё тоже самое, а на выходе продукт другой.

Однако разделение - "платформа ПК" и платформа внешней ардуиноподобной платы должно соблюдаться.
Посему уж если придерживаться концепции ардуино IDE достаточно создать "платформу консоли виндовс ХР" и "платформу консоли "виндовс10" (а вероятно и "платформу консоли линукс").
А далее результатом обработки/компиляции скотча для ПК должен быть исполняемый файл прикладной программы.
В принципе ничего особо сверхестественного - делается очередное дополнение списка платформ.
Если данное дополнение будет корректно выполнено и устанавливаться в рамках правил для списка ссылок окна "настройки" IDE да оснащена оффлайн референсом, аналогичным минимум референсу самой ардуиноIDE
(а максимум вот таким как здесь к примеру:
https://z-uno.z-wave.me/reference/ )
То вполне можно рассчитывать на успех...

Заглянул, отчего же. Но вы предлагаете писать в парадигме winapi, а потом портировать на контроллер. Не знаю, что за дисплей вы там обкатываете, но AVR для дисплеев слабоват. А уж заставлять его ворочать winapi-подобными обертками это какое-то издевательство.
Впрочем, мне писать графические интерфейсы для контроллеров не доводилось (вывод трехмерной графики в реальном времени не в счет, она не про взаимодействие). Может, не так уж страшно... Хотя все равно winapi далеко не образец удобного программирования.
Идея-то хороша, но без симуляции ограничений контроллера слишком примитивная. Если winapi может себе позволить хранить все пиксели окна плюс все координаты контролов, то контроллер - нет. Он даже не может себе позволить слишком часто перерисовывать экран.
Бессмысленно. Лучше написать кроссплатформенную обертку вокруг общих функций. Благо почти под все эта обертка и так есть, разве что захотите чего-то уж совсем странного - но это будет звонком вылезать из пеленок ардуины.
А, понял. Разные платформы нужны для правильного выбора avr-gcc / gcc / i686-w64-mingw-gcc / етц.
Но все равно, если уж хочется "без напряга" писать гуйню для компа - возьмите любую "формошлепку" вроде Delphi / CBuilder / Lazarus. Графика плохо ложится на линейную программу и даже на процедурный подход. Даже gtk, написанный на Си, использует ООП.

Вы всё недопоняли:) Дисплей тут - ваш монитор. Вместо платы - ваш компьютер.
Там нет никакого портирования на контроллер. Функции WinAPI реализованы внутри Nanonyam, там же выделяется вся память под изображения (системная память Windows). Можно делать десятки графических страниц разрешением на весь монитор, а потом их перелистывать и показывать мультики. Конечно, функции WinAPI я упростил немного, чтобы не париться с кучей ненужных параметров, это неизбежно для простоты.
Я сделал 12 примеров, которые можно скачать по ссылке на сайте вместе с самой программой (весит меньше мегабайта): http://www.nanoslavic.ru/nanonyam.html
Там есть скетч, в нём написано что делать, чтобы запустить примеры. Никаких реальных контроллеров для этого не нужно.
Сложно для понимания, видать я замутил, но если взять и попробовать, должно легко прийти понимание.
Я собираюсь снять ролик на ютуб про свою программу, расскажу что и как, может будет понятней.

Имелось ввиду именно адаптация ардуино IDE для работы с ПК в том стиле, который применен в отношении разнообразных "ардуиноподобных" платформ в самой ардуино IDE.
Допустим те же "синии пилюльки" на АРМ/STM32 , платформы для ESP8266, для той же интел intel i686 boards for intel....
Вот именно такой вариант адаптации.
Называем допустим "платформа консоли ПК"...
Собственно в состав включается все необходимое для создания консольного приложения (включая необходимые компиляторы и их настройки для соответствия правилам стандартного референса arduino IDE).
Добавляется только дополнительное специфичное описание референса библиотек именно для работы с нашей консолью.
Это не привязка к проектам на АВРках, а привязка к концепту функций референса IDE, где нас особо не интересует начинка МК, применяемого в конкретной платформе и настройки компилятора, а используется общая абстракция описания работы с ее (платформы) внешними выводами.
На выходе нашей "платформы консоли ПК" мы получаем готовую консольную прожку, которую можно непосредственно запускать на персональном компьютере.
"выводами" той "консоли" можно считать дисплей, клавиатру, СОМ порт и работу с дисководами.
Возможно также подключение к локальной сети...

А как образец создания платформы под свой процессор и расширенные специфичные задачи в рамках ардуино IDE я и приводил ранее сайт Z-UNO (ZigBee для "умного дома").
Ежли бы подобный вариант был сделан авторами тех же "синих пилюлек" и WEMOS - с оными было бы гораздо удобнее работать.


У Вас же, nanoslavic, получается "двуступенчатый" подход - приложение ардуино IDE создает файл для запуска в отдельной программе. Т.е.
"платформой" является не операционная система ПК, а Ваша виртуальная машина.

Для начала... возможно и подойдет, но... Сначала должен быть определен перечень и функционал "выводов" той виртуальной машины...
Далее правила обращения к ее элементам в рамках стандартного функционала IDE и уж затем специфика дополнительных функций.
Причем библиотеки дополнительных функций должны быть подключены "по умолчанию" - аналогично таковым библиотекам адуриньи, а не добавляться вручную.

Я знаю, что если придерживаться концепций, то надо так. Но ведь это же надо будет качать эту платформу, а в ней целый компилятор на сотни мегабайт (хорошо если - для винды компиляторы большие), да ещё и библиотеки всякие здоровенные. А с наноням всё проще: достаточно базовой платформы ATMEGA2560 (она вроде по умолчанию в ардуино), немного библиотек с функциями наноням (типа задать размеры окна, выбрать шрифт, написать в окне, нарисовать что-нибудь и тп), а еще маленький Nanonyam.exe, который запускает файл получившейся после компиляции прошивки для этой ATMEGA2560 - и вот и всё что нужно для получения простого приложения. Исполняемый файл можно копировать с каждым скетчем, а можно положить в одно место, и открывать прошивку по клику, если связать расширение с программой. Вот такая тут концепция.

Добавлено after 3 minutes:

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

Я скорректировал основные тезисы.
Касательно объёмов - не забывайте, что сама IDE создает дополнительный скрытый каталог для приложений (те же компиляторы в соответствии с платформами) для ESP и ARMов и прочих "не АВРок".
Объём того каталога у меня более 4 гигабайт.
Так что ежли рисковать - то по полной.
В принципе действительно вариант виртуальной машины может представлять собой нашу "платформу-консоль", а IDE только генерирует файл для данной "платформы"...
Так проще обеспечить миграцию по операционным системам разных версий (типов).
Это одна сторона.
А вторая - это функционал, взаимодействующий с программой, сгенерированной в IDE средствами ее пользовательских функций.
Как-то так...
Однако ... требуется "список функций платформы" - что имеется в наличии - для начала жесткий и абсолютно работоспособный "спартанский минимум" под ХР х32 - как наиболее "демократичный". Что-то типа "описания внешних выводов" и их наименований /карты выводов для обычной платформы...
Дальше - по обстановке.
Если с "железными платформами" в принципе проще разбираться, то с софтовой, не вникая в дебри ПК достаточно муторно.
Собственно загрузка целевого файла... С учетом того, что две программы уж никак не могут делить один и тот же СОМ порт связь с результатом компиляции в IDE придется как-то модифицировать.
Как вариант окно "загрузить скотч" в виртуальной машине, а в IDE только генерация соответствующего файла...
Надоть подумать чего там еще...


А воть и первый ОБЛОМ - "...не является приложением WIN32..."
Так что... придется оставить без внимания...

Без портирования смысла вообще нет.
Если хотите писать для ПК на С++ и вам не хватает готовых графических библиотек - так напишите библиотеки, Ардуина-то тут при чем? Чем g++ в составе среды лучше любого другого g++? Наличием примитивной IDE? Так программерский блокнот или kwrite все равно удобнее. Ну или нормальные компьютерные IDE если кому места не жалко.
А вот это уже чуть более полезно. Нарисовать библиотеку для какого-нибудь ili9341, которая на контроллерах использует SPI, а на компе - окно через gtk/Qt (ну не через winapi же!). Хорошо бы еще ограничения памяти и скорости эмулировать, но не очень понятно чьи, контроллеров-то поддерживается много.
То же самое с UART'ом: для контроллера будет аппаратный, а для ПК либо реальный, либо эмулируемый.
Даже эмулятор клавиатуры можно прикрутить, для МК - матричный, PS/2 или USB (на что фантазии хватит), для ПК стандартный ввод или окошко с виртуальной.
Конечно, даже так много без камня не отладить, но хотя бы назначение понятным будет - отладка GUI или CLI.

Вот ...
отдельная прожка в виде консольки с собственным экранчиком и клавиатурой, тыцькаемой с мышки да выходом на СОМ порт.
Эта консолька есть наша "платформа консоли персоналки"
Действует на компе та консолька как самостоятельная сущность, с IDE у нее отношения только для перезагрузки целевой программы, которую в данный момент консолька отображает.
А с подключенными к ПК адуриньями связь минимум через СОМ портец (максимум те же локалка через сетевую карту и вай-фай).
У самой консольки добавлен функционал работы с дисками (и опционно с USB приблудами).
Собственно для ввода с клавиатуры (экранное поле кнопок - стандартная клавиатура ПК как расширенный опцион) и отображения на экранчике не эмуляция имеющихся СБИС, а собственный набор команд/функций - основная то задача платформы не эмулятор чего-то из имеющегося набора шилдов, а создание собственного устройства на ПК для удобства работы с внешними адуринками.
Блоки работы с дисками и сетью могут идти как "спецшилды" для данного консольного приложения(т.е. добавляться по мере разжирения).
Консолька не для имитации/симуляции уже существующих изделий, а именно для реализации контрольно - управляющих приложений при работе с внешними изделиями на основе ардуиноподобных.
Это экран данных и отсылка команд.
Те же функции, но в урезанном виде терминалка делает.
Однако мы не можем изменить саму терминалку под собственную задачу - сменить вид и функционал экрана, создать собственный набор функциональных кнопок, прописать дополнительные функции, обработки данных/экранных эфектов.
Посему создадим собственное приложение-платформу "консоль ПК"...
И функционал данной консоли будем определять "скотчем" созданным в рамках ардуиноIDE.
Это по минимуму стандартный информационный экранчик (сегментный, матричный) и набор функциональных экранных кнопок.
Клавиатура ПК как расширенный опцион.
Весь текущий вид и функционал нашей платформы-терминалки определяются скотчем, который мы создаем в ардуиноIDE для нашей компьютерной платформы-консольки.

МНДЯ...
Писатель из меня .....

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


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

ДЫК...
Я при всем интересе запустить на своих "рабочих лошадках" Вашу прожку не смогу - моя база это ХР х32.
Ардуино IDE 1.8.9 у меня НА ЛЮБОМ из компов работает.
А вот уже симулятор требует чего получше, чем Pentium-III...
Ну и так далее... (Ардуино IDE 1.8.10 и 1.8.12 работают только под 7-10кой х64).
Так что и такой вариант учитывать надо.
А те, у кого ПК да ОС понавороченнее простыми средствами ессно ... "носом воротить" будут.

Да и мое видение места самих адуринкоподобных как отдельного компонента элементной базы...
Вот тут выложено:
https://radiokot.ru/forum/viewtopic.php?f=62&t=156720
определяется как среднее между апологетами "истинного ардуино" и сторонниками "чистокровных МК"( и соответствующих средств разработки).

Ну поддержку XP я могу сделать, просто смысл использовать эту систему, если с неё даже в интернет опасно выходить. И windows 10 не такая уж требовательная, раз работает на нетбуках с жёстким 32ГБ и 2 Гб ОЗУ.
Пусть водят носом, я просто сделал бесплатный инструмент и предлагаю. И мне вобще пофигу будут его использовать или нет. Не будет интереса, просто оставлю этот проект и займусь другими.

А моё видение определяется доступностью, удобством, функциональностью, надёжностью и практичностью инструмента. Если работаю в одной проге, но появляется другая - проверяю её и перехожу, если она лучше. На самом деле в ардуино никогда и не работал, поэтому впервые вижу понятия "истинного ардуино" и "чистокровных МК". Похоже на секту какую-то

А так оно и есть - "секта" ...
"свидетелей святого STM", "истинного АСМодея" или "высшего Си" к примеру...
или уж слишком примитивно-массового подхода к ардуино (от оного порой одни ТОШНОТИКИ)...
Или битвы "яйца и курицы" прошлых лет между сторонниками PICовых и AVR.
Крайности всегда череваты...
Сам через подобное прошел.

Переход на новое определяется не только положительным эфектом от той новинки, но и К СОЖАЛЕНИЮ...
материальным уровнем потребителя в возможности реализации задуманного.
Одни условия для любителя с домашним бюджетом,
другие для любителя с практической отдачей от проектов (работа под заказ)
и третьи у профессионала-разработчика на предприятии.
Собствено из того и исходить приходится.

Довольно часто именно вышеуказанная разница и является основой разнообразных "спорных ситуаций".

А я вот скрестил сразу несколько всего разного. Кстати, есть желание добавить в nanonyam также поддежрку какого-нибудь 32-битного ядра. Процессорные инструкции будут разные, так что можно автоматически отличать прошивки и запускать симуляцию соответствующего ядра. А виртуальные функции одинаковые.
На самом деле глобальная идея этого наноням - портировать на 32-битный процессор с небольшим дисплеем, клавиатурой и SD-картой. И использовать в качестве виртуальной машины для запуска программ с карты памяти - эдакий маленький микрокомпьютер. Конечно, виртуальные функции поменяются, но принцип будет тот же. А также добавятся физические порты. Можно будет подключать этот микрокомпьютер к разным внешним схемам и запускать соответствующую программу с карты. А может, ограничусь только игрушками типа ардубой. Но это далеко в будущем.

Это немного разные платформы:
1. по факту симулятор МК
2. терминал-консоль поддержки внешних самоделок (в том числе и ардуиноподобных) для ПК
Ежли первое как-то весьма ограничено (ибо аналогично имеющемуся "железному" варианту), то второе весьма актуально.
Ибо писать собственную программу-терминалку с произвольным оформлением под ПК для того, кто занят самоделками на основе МК таки весьма напряжно... В большинстве случаев уровень "продвинутого пользователя"...
В то же время изучать еще дополнительно компиляторы (в добавку к имеющимся знаниям) ради разового проекта таки нерационально.
А вот платформа консольки-терминала с задаваемыми с помощью единого подхода, в рамках правил ардуино-IDE, пользовательскими параметрами тут заметно более востребована будет.
Пусть не с такими возможностями, как у процессингIDE, зато практично и быстро... Без дополнительного переобучения...