Виж темите без отговор | Виж активните теми
Дата и час: Чет Мар 28, 2024 1:10 pm
VIsual programming for Arduino and Raspberry Pi
Автор |
Съобщение |
fred
Ранг: Форумен бог
Регистриран на: Чет Окт 05, 2017 11:55 pm Мнения: 1692
|
Re: VIsual programming for Arduino and Raspberry Pi
Да, точно това имах предвид, трагичното ниво на т.н. "функционална грамотност". Според изследванията на PISA при 40% от българските ученици тя липсва, чете но не разбира. Дали това е общ спад на интелекта или пренасочването му от текстов към визуален интерфейс още не ми е ясно.
_________________ Остап Бендер: Спасяването на давещите се е дело на самите давещи се. Стендал: Овчарят винаги се стреми да убеди овцете, че неговите и техните интереси съвпадат.
|
Вто Юни 12, 2018 4:28 pm |
|
|
gicho
Ранг: Форумен бог
Регистриран на: Пон Мар 13, 2006 12:59 pm Мнения: 3855 Местоположение: Габрово
|
Re: VIsual programming for Arduino and Raspberry Pi
Тези неща (PLC програмиране) си имат стандарти и те се казват IEC61131-3 и IEC61499. LADDER-ът е историческо наследство за да могат да се пишат програми със същите знания, с които се е правила релейна логика в старите машини (табла). А тези стандарти описват графична и текстуална форма (61131 са 6 "езика", от които 2 са текстови). Аз пък мисля че е обратното - ако ще нахвърляш нещо набързо може и да си позволиш да го "надраскаш" на C (или асемблер). За всичко останало ще трябва първо да помислиш, да събереш изискванията, да ги опишеш, да дефинираш начини за проверката ми (валидиране), да се направят тестове за тези проверки, и едва когато тоя процес мине да се хванеш да "кодираш" някакво решение. Има различни процеси за работа, един от често използваните е V-модел https://en.wikipedia.org/wiki/V-Model_(software_development)Тук си прав, и не бива да приемаш че подхода с който работиш в момента ще е ок за различни проблеми. Предимството на графичното представяне е че човешкият мозък възприема по-лесно (бързо) графичната информация - затова имаме очи а не терминален интерфейс за символи. В природата нещата са графични - представи си че задачата е да идентифицираш (посрещнеш на летището) някой човек. Какво би предпочел - да ти дам снимка на индивида, или да ти напиша 10 страници описание от типа на ръст, килограми, цвят на очи/коса? Не споря че при създаването на "информация" има място и текстовото описание - тези DSL езици. Но приемането на тази информация е по-удобно през графичния интерфейс, или поне има не малко случаи, в които е така. Т.е. има място и за двете форми. Номерът с програмирането е че то представлява конкретна имплементация на идея/алгоритъм - възможни са хиляди различни имплементации - на различни езици например, които ще покриват изискванията. Така че даването на конкретна имплементация не може да е вариант за споделяне на идеята - просто липсва достатъчно информация в тази форма (C например). Със сигурност има много по-експресивни езици, които описват много по-детайлно проблема. Това му викат да опишеш "какво" се прави, а не "как се прави". И в тая линия има подходи, който най-често се връщат към математиката, за да имат максимално точно представяне. В момента в който се постави примерно изискване за гарантирано ниво на дефектите, както е за safety продукти, се оказва че подхода "правим го и почваме якото тестване" не е ефективен. Ако нямам формални доказателства че кода ти работи ще ти се наложи да направиш 100% тестване - не 100% coverage на кода просто, в който да минеш през всички клонове (if-ове), а на минеш отвсякъде със всяка възможна стойност на всички аргументи и изобщо използвани данни. Представи си няколко 32 битови променливи,после добави и "стейта" (разни вътрешни данни от типа на локални променливи, скрити "self", "me", "this", "instance data" и заради тях разшири теста с всяка възможна последователност от подаване на аргументи. После умножи по примерно 200 функции в даденото приложение (ако е по-скромно), и после .... веригата става безкрайна и количеството тестове става непрактично, т.е. не се изпълнява. Да, ама някъде се иска да го направиш - иначе клиента не иска да говори с теб, защото няма сертификат че си спазил разните изисквания. И те са точно за да има някой по средата (Tuv Nord примерно) който да поема отговорността че ти като производител на нещото си направил минимума за да не гръмне реактора или да не откажат спирачките. Но ако ще правиш мерене на температурата в басейна може и направо на C - стига да няма нагревател или помпа, които могат да наранят децата ти.... Пак ще опитам да насоча дискусията - графичните (или подобни) представяния доказват че даденото нещо е достатъчно добре изолирано и изчистено от зависимости. На C няма достатъчно ефективни средства това да се постигне (докаже) - затова има C++ с класове, неймспейсове, има езици с пакети, ... И пак отгоре има dpkg, npm, pacman, nuget, cmake, autotools и тем подобни. Всеки един от тях си е текстов, т.е. DSL някакъв - което става, но са отделни инструменти. На C дори отделните аспекти като дифиниране на типове, алгоритми, създаване на инстанции и свързване не са "контролирани" в смисъл да има изисквания или да се налагат определен pattern. А асемблера си отива по простата причина че написания код е непортируем и трябва да се използва само от инструменти от типа на компилатори. И ако някъде ти се налага да пишеш асемблер значи че има нужда от подобряване на инструментариума - компилатор, или дори на архитектурата - арм хвалеха cortex серията с това че вече няма нужда от асемблерски стартъп файлове (векторите могат да са C функции). Не знам решението на момчетата дали е показателно - споменаха че имат проблем да предложат начин клиентите да си правят техни блокове. Това ми се струва че значи че няма достатъчно добра идея за изолирането на блокчетата.
|
Сря Юни 13, 2018 8:58 am |
|
|
kalata23
Ранг: Популярен
Регистриран на: Пон Дек 15, 2014 10:05 pm Мнения: 324
|
Re: VIsual programming for Arduino and Raspberry Pi
Виждал съм доста PLC-та, участващи в реални производствени процеси, където програмата ти е писана на LADDER или Code Blocks. Примерно в Мondi Стамболийски, цялата система (като изключим някакви стари имплементации на Siemens, Yakogawa) са имплементирани с предефинирани блокчета, които свързваш, все едно работиш с CAD програма. Говорим за управления на мотори, снимане на информация от сензори, крайни прекъсвачи, регулатори и т.н. Никой не пишеше грам код, цялата логика се имплементираше с блокчета, връзки и таблички. Контролерите бяха Metso/Valmet (двете фирми постоянно се купуват една-друга). Вентилите и приборите бяха Valmet/Metso/Emerson/Rosemount. Allen Bradley & Siemens също използват подобни подобни средстава за решение на конкретна задача. Това е пример, че дори толкова високо ниво на абстракция може да се ползва в реална среда, при това в някаква индустрия.
А проектът на пичовете и идеята ми да "напрадскаш нещо набързо" е по-скоро за хората, които искат да направят нещо сами. Защо някой трябва да отвори учебник по С, да започне да учи за променливи, функции, синтаксис, структури, компилатори, да загуби сумати време, за да направи някакво управление на лампа/диод, който да свети, когато се отваря вратата или за да управлява стъпково моторче или каквото и да е. Точно това е и смисъла от Arduino-то. Направено е за хоби, за хора, които не се занимават сериозно и които обичат да чоплят нещо. Естествено всеки може да копи-пейстне някакъв екзампъл да си купи бредборд и да нареди 5 елемента и свърже няколко кабелчета, но поднесена графично информациятта, както казваш е много по-лесна да се асимилира и хванатия от пътя да може да изпълнява елементарни задачи по даден шаблон.
|
Чет Юни 14, 2018 9:56 am |
|
|
itso.t
Ранг: Форумен бог
Регистриран на: Чет Фев 03, 2005 1:21 am Мнения: 10573 Местоположение: София
|
Re: VIsual programming for Arduino and Raspberry Pi
За да може да се запознае с разни досадности като двоичен, десетичен и шестнадесетичен формат данни, какво е това аски, и да му светне лампата защо на дисплея има "маймуни". Всъщност, къде е казано че човек трябва да може да направи нещо без да положи поне минимално усилие?
|
Чет Юни 14, 2018 10:54 am |
|
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 5:52 pm Мнения: 10356 Местоположение: Добрич
|
Re: VIsual programming for Arduino and Raspberry Pi
ъъ... не исках да насочвам дискусията на тема текст-vs-графика, затова и спрях да пиша. Това са две форми на представяне на информация. В зависимост за какво ще се ползват всяка форма може да има предимства или недостатъци. Но като цяло, когато информацията е много, представянето й в графичен вид я прави почти неизползваема (като изключим снимките). Това си е факт и не му е мястото да го обсъждаме тук. Ако някой не го разбира дадох примера със електрическите схеми. Всички чертаем схема в графичен вид, когато платката е с 5, 10 или 100 чипа. Но ако някой му се наложи примерно схема с 1000 чипа не след дълго ще разбере за какво говоря. Така че хайде да не разводняваме темата повече. Знам че сте виждали някой да ползва информация в графичен вид...
|
Чет Юни 14, 2018 11:20 am |
|
|
kalata23
Ранг: Популярен
Регистриран на: Пон Дек 15, 2014 10:05 pm Мнения: 324
|
Re: VIsual programming for Arduino and Raspberry Pi
Itso.t, много е гадно така, да ми извадиш само част от изречението. Ако става дума, всеки може да вземе едно ардуино, да свърже един резистор и един светодиод и да качи blinking led примера. После ако му стиска, може да се опита да промени дилей функцията и пак няма да е отворил грам учебник. Въпросът е, че за малки неща и когато е направено изцяло за развлечение или дори за някаква въвеждаща цел, един човек би предпочел да си нареди кутийките по някакъв шаблон, т.е информацията да е по-близка до човешката реч и човешките мисли, отколкото да ходи да да пише код и да разбере, че е изтървал semicolon символа. Не казвам, че графичното представяне е по-добро от писменото, казвам, че за конкретна група потребители с конкретни желания е по-подходящо.
Извинявам се за разводняването на темата на автора.
|
Чет Юни 14, 2018 12:33 pm |
|
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 1:01 pm Мнения: 1952 Местоположение: Варна
|
Re: VIsual programming for Arduino and Raspberry Pi
Да, така е. Аз бих казал че и визуалното програмиране също няма много общо. Но това което се опитвам да посоча, рационалното зрънце тука е че има нужда от инструменти с които да се проектира, организира и дори генерира код. На сериозните момчета не им е необходимо нищо повече от С компилатор. За наистина сериозните вече отваряме приказка за make, RTOS, библиотеки, стекове, добри практики, стил и пр. Но и това не е достатъчно. Защото с инструментите които имаме и познаваме се опитваме да решим задачи, които не са стояли на дневен ред когато са правени тези инструменти. Например, един съвсем дребен пример, почти всички проекти разчитат на файловата система за да организират информацията и съхранението и. Дори и тези които ползват и version control разчитат на имена и структура от папки. Така както Реконструктора го описва най-общо има нужда от мета ниво над С кода. Това ниво може да ползва други езици и инструменти и да има също сложна, модулна структура (не е задължително да покрива и скрива напълно С сорсовете). Дали ще са модели, функционални езици все тая. В големи проекти там където сложността е повикала неволята това се прави по един или друг начин. Графичната среда не е черешката на тортата тя е помощен инструмент. Работил съм в проекти в които има <и> графичен редактор за проектиране на структурата на сорсовете - ползвал съм го има няма 2-3 пъти за разглеждане на малки части от композицията. (:офтопик: Миро, никой не търси графичен редактор за напълно плоска структура от информация, щом става въпрос за хиляди елементи.) Да не говорим, че графично не означава само блокчета и връзки между тях. Визуалните инструменти могат да помогнат за работа по проектирането на кода, за разглеждането му. Те няма да направят сами по себе си организацията по-добра нито ще изместят останалите инструменти. Графичното не е за да е по-лесно на по-тъпичките. Понякога то е единствения начин да обхванеш и погледнеш отгоре една сложна структура. Две различни неща са човешкия поглед и машинната обработка. И двете се използват и ще се използват и за в бъдеще.
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
Пет Юни 15, 2018 9:24 am |
|
|
HSB
Ранг: Форумен бог
Регистриран на: Сря Юли 26, 2006 11:15 am Мнения: 1244 Местоположение: Phoenix AZ
|
Re: VIsual programming for Arduino and Raspberry Pi
https://flprog.ru/Что такое FLProg Программа FLProg позволяет создавать прошивки для плат Arduino с помощью графических языков FBD и LAD, которые являются стандартом в области программирования промышленных контроллеров. При создании программы я постарался максимально использовать наработки программистов Siemens, ABB, Schneider Electric в их средах программирования. А едни други руснаци са сковали и The Graphics Integrated Development Environment for AVR microcontrollers http://algrom.net/
|
Пон Юни 18, 2018 9:10 pm |
|
|
Кой е на линия |
Потребители разглеждащи този форум: 0 регистрирани и 4 госта |
|
Вие не можете да пускате нови теми Вие не можете да отговаряте на теми Вие не можете да променяте собственото си мнение Вие не можете да изтривате собствените си мнения Вие не можете да прикачвате файл
|
|