Говоря за едно отминало време, далеч преди "на себе си купи". Нямаше много за купуване по магазините, скъпо а заплатите ниски. Е, телевизор например се купуваше. Макар че имаше радиоклубове където по-запалените си правеха любителски радиостанции. Аз пък съм си правил усилвател и тонколони, такива просто нямаше по магазините.

При което често като навлезеш навътре ги правиш по-добри и от фабричните, тогава те бяха с насока ширпотреба, не особено добри параметри. Това за соц.производството, Кореком дори не съществуваше още. Всичко това караше човек да учи, МНОГО да учи. Искаш мощен усилвател с който да озвучаваш събиранията и впечатляваш съученичките, ставаш център на компанията. Ами учи радиотехника от А до Я за да го проектираш и след това направиш, по магазините ги няма. В по-късният етап що домашна ракия съм спечелил занимавайки се с радиоремонти Сам си направих и някои помощни уреди, генераторче и т.н. Всичко това е четене, четене и правене.

Сега е по-лесно да се занесе на сервиза а там пък вместо ремонт заменят направо цялата платка. Често без нужда, тя повредата е друга. Аз така си спечелих име като няколко пъти върнах към живот компютри обявени от сервиза за безнадеждни. Просто не са гледали където трябва. Може дори да не са знаели или пък решили, че тарифата не си заслужава ровенето. И естествено аз пък получавам съответното шише домашна ракия

Май че се отплеснахме. За да се върнем към темата, безспорно визуалният интерфейс е много полезен за да направи лесно използването на нещо. Особено от начинаещи. А най-добра е комбинацията която я каза Zdrav - визуален интерфейс+възможност за скриптове с команди за по-напредналите. Дали ще е възможно при тях не знам, обикновено се тръгва по обратният ред. Т.е. първо командите и после към него се добавя визуалният интерфейс. Не им знам бизнес идеята но евентуално да го направят open source, много ще ги улесни.

Ааа... няма нищо. Приказвайте си. Ние тука ще изчакаме да минат 10-20 страници, да си разкажете историите и накрая ако все още някой проявява интерес и не е забравил за какво иде реч. Ако е рекъл Господ... Живот и Здраве...

Мерси много за критиките и за съветите. Бяха повдигнати някои интересни въпроси. Ще ми трябва малко време да ги осмисля всичките, но пък нали за това е обратната връзка... за да може следващата версия да е по-добра от тази .
За момента мога да кажа че планирахме отваряне на интерфейс към други езици. По скоро отварянето на сървъра който е качен към УЕБ интерфейса така че да може да се свързва програмно с някакво API.
Относно блокчетата ... Дам в момента логиката е data flow описание... и не е практична за по сложни системи. Но се надяваме да намерим подходящ начин за описание.
Иначе системата поне на този етап мислим да се ползва свободно, като ако решим да правим платена версия по нататък .. тя да е надстройка а тази да е безплатна

Data flow е много напредничав начин за разработка и описание на системите, но трудно се прокарва - реално е близка на възхваляваното от мен функционално програмиране.
В тази връзка мога да спомена xod.io - проект отпреди около година, чиито цели са подобни на вашите - съответно могат да са ви полезни като справка и идея.

А относно графичния аспект - това което виждаме в "средата за програмиране" не е задължително да е 1:1 с формата за съхранение - споменатото xod и дори UML имат стандартизиран текстов (xml) формат за съхраняване на информацията. Графичната част е просто 'view' на този "модел" - дали ще е под формата на диаграма, flow или просто текст е въпрос на реализация и дори бих казах на способностите на програмистите. Ако определен модел/език е достатъчно изразителен (експресивен) ще може лесно да се визуализира по различни начини, и обратното - ако е много размазан и некачестен като идея няма да може да се представи лесно в други форми.
Реално лекотата която се асимилира с графичното не е илюзорна - не е лесно да се постигне описание на изолирано блокче, което да можеш да дръпнеш от палитра (да му направиш инстанция) и лесно да го свържеш със съвместими входове и изходи. Типичните "компоненти" които ние пишем не са достатъчно добри (изолирани) за да се ползват при такъв подход - което според мен значи че са по-трудно преизползваеми. Следователно ако някой е успял да опише същото в друга форма, която няма тия условности (зависимости, вътрешни данни, липса на достатъчна четимост на кода която се компенсира с голямо количество документации и изисквания), то трябва да се поучим. Имам предвид че същото може да се напише и в класическа текстова форма, но едно е да може, друго е изобщо някой да се опита - далеч е по-лесно да си сложим малко инстанционни данни, да си закачим няколко библиотеки като задължителни и да нашишем няколко тома за това как се ползва тая библиотека.
Не знам доколко авторите са си изяснили задачите и какво се изисква от една среда, за да бъде тя използваема - бегло зачекнахме управлението на "пакети", модули (блокчета), съзадването на инстанции, подкарването им (викането), предаването на входни и взимането на изходни данни. Това включва описание на типовете на входове и изходи, на събития и сигнали.
Има доста примери за успешни концепции за графично програмиране - споменатите PLC (IEC61131 и по-доброто IEC61499), labview, симулинк и подобни. И разбира се executable UML. Интересното е че всичките тези колкото и да се въртят накрая стигат до това да разделят описанието на две групи езици - структурирането го правят на графични (диаграми), но самите действия (най-ниското, крайно ниво) го описват на по-класически, да кажем императивни, езици. За UML това е ALF (или fUML) - https://www.slideshare.net/seidewitz/programming-in-uml-an-introduction-to-fuml-and-alf - нещо java-подобно. За IEC езиците е ST или аналогично.
Просто различните проблеми изискват различни форми за описание - стейт машината се чете най-лесно като statechart диаграма примерно, но финалното действие което тая стейт машина прави в определен стейт за да направи някакво въздействие върху SPI контролера примерно се описва по-лесно в императивна форма.
Затова и повечето моделиращи инструменти оставят тази работа да бъде описана директно на C/C++/java или какъвто е изходния език. Други (IBM - rhapsody) си измислят техен формат (език) за да не карат потребителите да се борят да описват loop в диаграма.
Има и друг подход - например http://mbeddr.com/ - те казват "C е добър език за описване на определени проблеми, ефективен е понеже върви навсякъде, има много инструментариум, близък е до хардуера - защо да не го разширим с езикови конструкции, които да служат да решават проблемите на организационното ниво - пакетиране, интерфейси, компоненти, верификация, ...".

Edit: да допълня че една от визиите за преизползваеми компоненти държи на абсолютното и пълно отделяне на данните от алгоритмите. Това на по-прост език идва да каже че правейки една библиотека от алгоритми сме задължени да не допускаме вътре да има какво и да е друго освен функции (алгоримти) и типове на данни. Забранени са всякакви глобални, статични и дори заделяни вътре във библиотечните фунции динамични данни. Това води до правилото че данните с които работим - входни променливи, изходни променливи, локални (инстанционни) данни трябва да бъда създадени (инстанциирани) извън нашата библиотека. Библиотечните функции дефинират в хедър тип за вход, за изход и за локални, и изисква някой извън библиотеката (в интеграцията - приложението което ползва библиотеката) да бъдат създадени данни от тези типове - дали глобални, в стека или хийпа не е интересно и на библиотечната функция не и пука - тя получава пойтъри към тия данни при повикването си.
Тези проблеми стават далеч по-явни и колегите сигурно са се сблъскали с тях когато трябва да направят пълната концепция - компоненти и инфраструктура/инструментариум за работа с тях. Ако на нас ще ни се размине да пляснем една статик променлива вътре във функцията, или статични данни в библиотеката, то при тях този номер няма да мине и на тях им се налага да намерят качествено решение, което ние сме си спестили и сме минали метър. И ако при нас е въпрос на съвест да не правим такива неща (щото нито компилатор, нито линкер ще ни "осъди"), то при тях е жизнена необходимост.

хммм... трябва поне да го видиш направено за сложна система. Иначе наистина няма как да повярваш. Нито пък да разбереш какво в момента сте направили с авера.

gicho, "графичния аспект" в това което показват момчетата не е точно view. Все пак виждаш те работят в графичната среда, а не просто я използват като изглед на композицията, която стои някъде отдолу в xml или нещо подобно.
Миро беше прав, защото когато използваш графични, визуални инструменти обикновено се разбира 2D. И това ограничава изразните средства доста, тъй като в софтуера можеш да имаш n мерно пространство.
Но от друга страна Миро не беше съвсем прав, защото ако навремето са чертаели с линийка върху хартия, то днес отдавна графичните инструменти не рисуват прости bitmap файлове. Като всяка CAD програма - имаш и графични инструменти и view-та, но имаш и инструменти с които да редактираш директно данните отдолу в какъвто и вид да са описани и съхранени. И обикновено това "отдолу" е във вид напълно смилаем машинно. Понякога е и четим за човек. И ако си достатъчно упорит (или достатъчно закъсал) може и да отвориш с текстов редактор и да "програмираш" директно. Или пък да напишеш скрипт(т.е. свой инструмент) с който да правиш по-сложни и трудоемки редактирания.

Само "графичното програмиране" никога не е достатъчно.

А какво има вътре в блокчетата? Доколкото разбирам за сега имат код. Вероятно достатъчно сложен за да се вмести в понятия като data flow и functional programing. Вероятно в блокчетата е пълно с глобални променливи и усукани, неявни стейт машини.
Предполагам там кода е на доброто старо С. И след всичките визуални гаври с него в крайна сметка на един компилатор и един линкер се подават едни С сорсове.

Добре е че има хора, които не се задоволяват само с това да си кютат на асемблера и кракнатия Алтиум. И за които "език от високо ниво" е тавана.

От това което видях оставам с впечатление че не е С, за да тръгне на таргета иска node js, т. е. предполагам те генерират някакъв жаба скрипт поне така ми се стори.

Не съм в час с модите за Ардуино явно.
Момчета ако просто сте си играли с node.js да пишете по регистрите на нещастната Мега328 рано е да се хвалите. Но пък няма лошо да работите в тази насока.

Привет.

Потребителя получава Ардуино кода под формата на Zip файл (могат да се закачат няколко Ардуинота и потребителя получава кода на всяко едно). Също получава и схема на свързването която да се чете от сървъра (NodeJS частта)... за да може да покаже модела и да знае какви елементи да очаква във всяко Ардуино.

Потребителя може да свърже системата в различни конфигурации:
- едно или няколко ардуино платки и разбери или компютър с NodeJS.
- самостоятелно ардуино (програмата си работи вътре но няма връзка със сървъра и не може да се следят параметрите вътре)
- свързване на няколко ардуино платки в мрежа (по време на генерирането се проследяват връзките и се генерират и настройки на комуникацията. Все още го разработваме)

И аз не съм в час, всъщност от ардуино изобщо не съм виждал, ама някакво расбери пусках тук да си правя тестери за работните станции и гледам има доста средства за развой различни от С, жаби, жаби на скрипт, змии и гущери разни ...

Да речем че съм Ви потребител.
Какво получавам вътре в zip файла? binary, source или някаква друга магия?!? Не съм профи с Ардуинотата за това моля да ме извините ако въпроса ми е тъп.
Схемата на свързването в какъв формат я получавам? bmp, png, sch, xml или ...?
Ако имам идея и искам да направя прототип използвайки Вашия продукт, мога ли сам да си измайсторя блокчета и да ги навържа. след това да получа изгенериран код в zip формат? Който после как наливам в Ардуиното?!?

Благодаря.

Zip файла съдържа кода на Ардуино написан на C++ и проекта за Ардуино средата (пак C++ само че разширение .INO). Може да се отвори със стандартното Ардуино IDE и да се налее в контролера по стандартния начин. За момента имаме само няколко тестови блокчета и все още се чудим как да направим така че потребител да може да си направи негово блокче ( това все още ни убягва ).

Схемата на свързване е в JSON формат. Веднъж изгенериран проекта, схемата се използва само за визуализация и описание на портовете в сървъра ( ако потребителя поиска да го използва )

Разбрах, значи визуалната среда генерира С++ код/проект за Ардуино, който после развойната среда на Ардуино ще смели до байнъри което ще може да се налее в МЦУ-то. Не звучи лошо.

Като за начало ако измислите блокчета, които да покриват повечето от задачите пак е добре. В последствие ще узреете за идеята как да дадете на потребителя възможност сам да прави блокчета.

Не знам как са го направили, но предполагам че този flow или каквото е там дето се редактира накрая се боцва в някакъв json - точно така е примерно в node-red. Така че тая графична среда си мяза на view-controller дето се очаква да е отделно от модела (json-а) им.
Не виждам принципна разлика с редакторите примерно във visual studio - отгоре имаш графичен рендър на формата или диалога който редактираш, а отдолу имаш текстовия xaml. Ако искаш да смениш примерно някакъв размер можеш или да дърпаш с мишката, или от нумпад-а да напишеш "200" - което ти е по-удобно.
Не че съм мерило, но съм се забелязал че предпочитам графичното (дърпане от палитра и слагане някъде) за добавяне на нов компонент - така явно си спестявам необходимостта да помня специфични ключови думи за дадения блок. След като го направя средата ми плясва темплейт за блокчето и тогава минавам в режим "текст" - повечето промени ги правя през xaml-а.
Затова ми се струва че и двете форми има предимства и не се изключват взаимно - въпрос на реализация е да се постигне достатъчно добра симбиоза.
Подобен е подходът на много други места - редактирането на activity в андроид студиото, където имаш даже няколко различни графични визуализация на модела - освен preview-то на формата имаш и дърво на компонентите. В еклипса много от редакторите са базирани на xml модел отдолу и подходяща визуализация. И симбиозата е постигната лесно - освен "design" view-то (графичното) имаш таб-че "text" или "xml" - така имаш достъп и до двата подхода и промените са синхронизирани за удобство.

Пак ще *напиша*, че комуникацията в текстов вид е 100 пъти по-практична. Ако някой не ми вярва може да се пробва да ме убеди като нарисува мисълта си

А ако някой търси възможно най-неудобната форма, то това е смесената. Затова съм съгласен, че трябва да си много упорит или много закъсал за да "програмираш" в бозаджийска среда