roboforum.ru

Так надо правильно организовывать программу, если грамотно по функциям раскидывать и делать правильные библиотеки, то как раз в основном теле надо будет писать blow_all_up() вместо 50 строк типа int i; index++; if(index<=0) {index=10;}

Да. Я про это и говорю - надо продумать набор удобных
для мелких школьничков библиотек, которые они осознать смогут интуитивно...

Вот, кстати, иллюстрация:
Виден ход программы как явная последовательность действий,
две параллельных ветки и передача параметра из одной в другую.
Это мне нравится.

А вот куча красных кубиков, которые по сути означают (++i>10)
мне кажется перегруженной. Кроме того, я бы в явном виде нарисовал
стрелочкой откуда и куда передается параметр (из нижнего процесса в верхний).

Michael_K писал(а):

Параллельность - а оно реально настолько нужно?

С моей точки зрения это просто более естественно.

Параллельность нужна. В принципе можно написать псевдопараллельность самим, но тогда код, понятный пятикласснику, превращается в код, понятный в лучшем случае девятикласснику.
Вот пример сторожевого таймера для робота, который ездит по комнате и, увидев препятствие, разворачивается. А если не увидит и застрянет на чем-нибудь, то через 10 с сработает сторожевой таймер в параллельной задаче и робот попытается выбраться. Это основа для целого класса задач с защитой от помех.

Кроме того, мы осуществляем управление положением регуляторов из параллельных задач.

Это всё красиво - а под какие МК можно компилировать код получаемый на выходе с таких схемок?

а под какие МК можно компилировать код получаемый на выходе с таких схемок

Деад, сейчас речь не об этом. Я пытаюсь для себя сформулировать требования к такого рода языку.
Если угодно, давайте добавим к требованиям:
"чтобы на выходе схемки был си (или байт-код, или hex для AVR, или XML какое-нибудь)"

А вообще из Лабвью в некоторых пакетах можно получить и код для ARM, и Си, и даже прошивку для плиса

Так а что тут формулировать, ИМХО - простые конструкции в графическом языке понятней, сложные - наоборот

Michael_K писал(а):но все-таки, хотелось бы чтобы нарисовались требования-пожелания
к базовому минимальному набору "для пятиклассников"...
Имхо в порядке важности - так.
- "фичи" среды программирования

1. Графическое представление команд с явным заданием последовательности выполнения.
2. Масштабирование графического окна (почему не сделали этого в NXT-G? - в Ma-Vin есть).
3. Явное указание параметров (модификаторов) выполнения команд. Глядя на программу, ребенок должен точно сказать, что в ней происходит. (В NXT-G какие-то едва различимые пиктограммы на блоке, а вся информация в отдельной панели, как в Object Inspector - ненаглядно). Можно ввести опцию скрывать параметры.
4. Очень желательна визуализация. Т.е. инициализирует пятиклассник моторы и ему предлагается указать их на роботе в маленьком окошке. Ряд стандартных задач тоже можно визуализировать: движение по линии и прочее. Это просто, а эффект даст потрясающий!
5. Ветвления не только по показаниям датчиков или значениям переменных, но и по логическим выражениям.
6. Циклы тоже. И с предусловием, и с постусловием. Выделенный параметр (счетчик) цикла.
7. Набор стандартных функций, включая тригонометрию и логарифмы. Скобки в выражениях!!!
8. Вставка кусков текстового кода вместо отдельных блоков. Если язык будет расширяем таким образом, он может стать невероятно популярен.
9. Именуемые переменные разных типов, включая строковый.
10. Массивы хотя бы до 256 элементов. Лучше - больше.
11. Целый тип четырехбайтовый.
12. Управление выводом на экран.
13. Управление задержками.
14. Таймеры с точностью до 1 мс, штуки четыре.
15. Команды типа "Сделай" и команды типа "Жди события", а также их композиции: "Крути моторы 720 градусов".
16. Веселый дебаггер, который, например, может вербализовать содержимое блоков.
17. Измерение показаний датчиков в процентах, мощность моторов тоже: от -100 до 100. Или от -512 до 511.
18. Функционал для сетевого соединения и обмена данными: проводной и беспроводной.
19. Подпрограммы, вызываемые по имени.
20. Возможность преобразования графического кода в C или Паскаль и продолжения программирования на нем.
21. Многозадачность. Глобальные переменные.

Придумался путь по которому можно дойти до графического языка - надо взять готовый open-source редактор диаграмм, сохраняющий свои проекты в понятном формате и создать под него оболочку и набор компонент + написать компилятор диаграмм в Си-код.

Добавлено спустя 57 секунд:
Вот на вскидку некий обзор редакторов диаграмм Open-Source'ных:
http://www.techmixer.com/free-diagram-s ... g-purpose/

простые конструкции в графическом языке понятней, сложные - наоборот

Это очень общие слова...

Так а что тут формулировать

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

Ну циклы и условные переходы - очевидно да.
Многопоточность? - ну, пусть, тоже да.
Объекты? - Может быть.
Переменные? - Допустим.
Пользовательские функции - Черт его знает.
Типы, массивы, структуры, рекурсия.? Уже не уверен.
А ссылки, области видимости переменных? Еще более не уверен.
А наследование, перегрузка?
И т.д. и т.п.

А вы говорите: "простые конструкции - понятней, сложные - непонятней"
Еще неизвестно, какие конструкции сложные с точки зрения ребенка...

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

Добавлено спустя 2 минуты 15 секунд:

надо взять готовый open-source редактор диаграмм

...в игле сделать библиотеку и ULP-скрипт, который переведет нетлист в сишник (шучу, конечно)

=DeaD= писал(а):Это всё красиво - а под какие МК можно компилировать код получаемый на выходе с таких схемок?

Это для NXT. Там внутри ARM и AVR. Среда Robolab 2.9. Спецификация на NXT во вложении. Куда еще можно применить, не знаю.

5 копеек: про многозадачность немного рано, сейчас только-только стали появляться различные фреймворки, библиотеки, расширения языков,... от разных контор (интел, майкрософт,...). самимбы сейчас с этим всем разобраться и научится применять, потом может что-то и удасться из этого применить по данной теме. а за событийность всеми руками и ногами, и уже сейчас, и у же прям сразу

Sergey Filippov писал(а):Там внутри ARM и AVR.

Внутри-то там конечно и АРМ и АВР, только вот эти языки (в том числе и роботЦ),
кажется, компиляются в байт код, который исполняется фирмварным интерпретатором.
Таким образом к конкретному процу он НЕ привязан. Спецификация открыта.

многозадачность немного рано

Совершенно не согласен.
Во-первых, для начала можно обойтись всего двумя функциями - StartTask(* task), TerminateTask();
Обмен данными в простейшем организовать через глобальные volatile-переменные.

за событийность всеми руками и ногами

Нужно придумать, как бы это изобразить естественно, и не перегружая деталями процесса.
Имхо, реализация в виндах (например) сложна, так как одно и то же событие частенько
выполняет на разных стадиях исполнения проги разные действия - приходится вводить
глобальные переменные состояний, и делать кривые ветвления...

Кроме того это сразу тянет за собой всякие очереди событий и т.д.
Хотя в применении к роботам и детям может быть и проще все должно быть:
так же как и с многозадачностью - урезать функциональность на минимально приемлемом уровне.

да дело не в том, что многозадачность это плохо или "рано им". дело в том, что во первых на меге (да, я пока с оглядкой на http://roboforum.ru/viewtopic.php?f=35&t=7313 рассуждаю, проектов на арме по данной теме пока вроде не планируется) идея с многозадачностью маловероятна по куче причин. во вторых на реализицию многозадачности скорей всего понадобится очень и очень много сил и времени. в третьих... в четвёртых...
надеюсь ошибаюсь в своих выводах. но в общем пока не вижу простого и лёгкого решения и т.к. это не критичный пока вопрос, думаю лучше с ним повременить.

Тоже думаю что до ARM-ов дорасти надо, если с OR-duino выгорит - следующим можно будет делать такую же платку на ARM с интегрированным USB и может быть даже BT/WiFi интерфейсами. Благо контроллеры соответствующие уже запланированы к производству и в этом году начнут вроде их клепать, а к началу следующего - глядишь и до РФ дойдут

Добавлено спустя 20 минут 42 секунды:
Хм, байт-код это хорошо, надо будет почитать его спецификацию... может оно и на AVR потянет

Angel71 писал(а):...на меге ... идея с многозадачностью маловероятна по куче причин....

Гхм... Не понимаю, чего это вы испугались.
Готовых многозадачных осей для даже маленьких АВРов - как грязи,
в том числе и бесплатных и с открытым кодом...
Да, в общем-то и пишутся они с полпинка без проблем...

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

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