roboforum.ru

Так надо правильно организовывать программу, если грамотно по функциям раскидывать и делать правильные библиотеки, то как раз в основном теле надо будет писать blow_all_up() вместо 50 строк типа int i; index++; if(index<=0) {index=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. Многозадачность. Глобальные переменные.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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