Нужна зделать какойнибуть скрипт на AVR, думаю запустить Java Virtual Machine но немного сложновато по ресурсам МК, может кто знаєт какой би скрипт прикрутить чтоби било просто и доступна.

И на какой же AVR Вы хотите Java машину 'присобачить'? Ну с ARM все понятно там для подобных желаний ресурсов памяти достаточно. А здесь то это зачем???

Скажем немци посадили Java на Atmega8 вроде називається NanoVM ....
Мне не нужна вся Java а только маленькая ее часть байткод интепретатор и робота с нескольками библиотеками и практически всьо. Можна и другой скрипт предложить какой би можна било би засунуть в AVR.
Скрипт должен делать какиє небуть вещи елси что случилось ...тоисть ето скрипт для автоматизации...

посмотрите на Forth, Lua

А что, Lua уже портировали на AVR?

http://www.harbaum.org/till/nanovm/

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

Впрочем среди эмбедеров С++ уже является чуть ли не пределом мечтаний, что уж говорить про то, чтобы кому-то была интересна Lua?

Или Ваш вопрос был просто подколкой?

Цытата с сайта:

The download is currently disabled due to licensing issues. The download will hopefully be available again soon. Stay tuned!

А насколько нужен такой скрипт вобше ...тоисть било у когото такая задача ...может кто писал свою Virtual Machine для своих нужд...потомушто возникла идея написать самому такой скрпит...насколько ето глупая идея...?
Может кто что посоветуєт в етом направления, или ето верний путь камикадзе.
Что он должен би иметь что б например кто из вас мог би его использивать чтоби он бил нужен вам.

вопрос скриптования он немного философичный. Смотря для чего, когда и при каких условиях. В условиях ограниченности ресурсов МК (как по объему имеющейся памяти, так и по быстродействию) любое скриптование будет подвергаться тщательнейшему анализу на предмет: а надо ли? Делать скриптование только для того шобы було нет смысла. Из готовых виртуальных машин наверное только Forth, как единственный язык зарекомендовавший себя хорошо в мире ограниченных ресурсов.

Мне например интересно использование скриптования для макетов и отладки. Но времени написать свою VM так и не хватает.

Свои идеи я излагал здесь: http://ucpy.onembedding.com

Ну ресурси можна разширить например FRAM можеть бить ОП...скрипт мне нужен для задач автоматизации...тоисть например если АЦП0==4.3В значит надо делать ето а если не так то ето ....
тоисть надо заставить мк поразному в разний момент делать разниє задачи...
Я вот подумал а может взять JavaCard ето упрощоная JAVA да вот не могу найти структури етих файлов она там попроще чем *.jar и *.class... но есть проблема там с native function ...то как не крути всюда грабли ...да вот чтоб зделать полностю свой скрипт есть тоже много проблем ведь на писать и продумивать всьо сначала и доконца а ето много времени...

Ага. Точно.
Поэтому многие здесь присутствующие для таких задач используют Си/Си++. Они немного похожи на Яву ;-)

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

А какаю нибуть силку на язик Рефлекс можеш дать

пока что только это: http://softcraft.ru/auto/etc/reflex/index.shtml
автор языка Рефлекс — Владимир Зюбин — обещает появление новых публикаций в течении следующего полугодия. Также уже готовится сайт для языка Рефлекс.

Сам я еще не имел возможности испробовать его в действии, сейчас общаюсь с автором на предмет получения демо версии для опробования.

По пунктам:
Сильно полагаю, что в Lua нет упора на минимизацию потребляемой памяти. В том плане, что хоть он и нересурсоемкий на ПК, для АВР трудно будет его адаптировать. Я исходники не изучал, читал только в доке особенности реализации. Код там оптимизировать, думаю, дальше некуда: в разы не сократишь.

Далее: мне Lua интересна, на ПК я делал как-то генератор страниц на нем из базы данных по шаблонам - задача ложится отлично, буквально несколько строк кода. Исполняемый модуль порядка 100к, описание языка - 30стр, интерфейс с ODBC - кил 30 (WIN32), вебсервер - 100к. Не надо устанавливать монстрообразные среды, изучать многотомные руководства: общие знания HTML, прочтение руководства по Lua, навыки в алгоритмизации - и вуаля! Кабы сделать типа BasicStamp - цены бы не было при приемлемых ресурсах.

Так что, не подколка это с моей стороны. Просто нравятся мне маленькие и простые средства программирования. Вот намедни поставил себе Дельфи, надо программу наваять, гляжу на эту среду и проливаю скупую слезу

Опять же, не согласен. По умолчанию в Lua используется тип double для чисел. Однако дока указывает, что можно перекомпилировать и под использование int (32бита на ПК). Думаю, что для AVR уместно будет перекомпилировать под 16-битные слова.

Потом, примерно 1/3 -- это компилятор, его тоже нужно исключать. Плюс, я думаю, если взять и удалить сборщик мусора, поддержку магических атрибутов в таблицах, через которые неявно можно реализовать объектную парадигму (фу!), то еще на 1/3 думаю ужмется. Ну и так далее -- делать TinyLua с минимальным набором того, что нужно в реальной задаче. Думаю, что если сильно попотеть, то в 50К и меньше можно уложиться. По ОЗУ кстати Lua довольно компактна, как мне показалось. В любом случае на такие объемы сразу нужно брать что-то типа Mega128.



Сравнивать с Basic не очень уместно -- сильно разные весовые категории.



Боюсь, что и тут сравнение несколько притянуто: Lua -- язык ориентированный на встраивание в первую очередь. Он изначально задуман быть не самостоятельным языком. Delphi -- это монстр для быстрой разработки типовых проектов для работы с базами данных. Так называемые коммерческие приложения. Набросайте в Дельфи "морду", скомпилируйте Lua в DLL и включайте в свой проект. Хотя проще тогда перейти на C++ Builder для облегчения интеграции с Lua. ;-)

Также я видел, что под Lua портировали библиотеку wxWidgets -- т.е. GUI уже можно пробовать писать и на Lua.

Я вот ушел от всяких дельфей/билдеров на Питон. Очень мощный и выразительный язык. Не такой как Lua -- в Питоне больше наворотов, за которые приходится "платить", но проги писать одно удовольствие.

Компилятор исключить не удастся: исполняется скомпилированный код. Так написано в доке, и так по здравому смыслу. Компактной по ОЗУ на мой взгляд не может быть среда, в которой есть RTTI: в Lua все переменные - объекты.
Сравнение с BasicStamp (а не просто Basic) в том, чтобы залить в МК исходный текст программы, без использования промежуточных компиляторов. Типа: набрал в редакторе, залил в терминале - вуаля!
По поводу Делфи: плАчу я не от того, что писАть на нем не умею, а потому, что для небольшой задачи надо большой инструмент. Мне надо работать с компортом и иметь ГУЙ. Хотел использовать PHP или Lua с веб-интерфейсом, но они не умеют (?) работать нормально с компортом, а делать эксперименты нет времени. Насчет графики в Lua: есть WxLua, LuaTK, LuaFLTK. Надо засесть и изучать, вот посвободнеет со временем...

P.S.: не в ОФФ ли мы заходим?

Да ето всьо хорошо .... но что би непредлагалось требуєт очень значительних усилий например чтоб зделать Lua для МК надо знать ее польностю чтоб вибросить то что не нужна и итоге получем свой язик ...а нет такова язика которий би изначально бил готов для использования в МК... да ето должин бить язик з байткодом , тоисть да кросс не зависемим...сечас присматриваюсь к Phyton и Forth... думаю что придумать...

Phyton на МК... не знаю. А Форт не сказать, чтоб совсем кросснезависим, но подходит, даже компилятор его запхнуть в МК можно, чтоб исходники заливать. Хотя так ресурсов больше надо. Я понял, что все (многие) коммерческие его реализации имеют кросскомпиляторы, тогда можно и библиотеки ненужные не использовать, и имнеа не хранить. А при компиляции на месте надо весь словарь хранить вместе с именем каждого слова. Хотя, если ненавороченная библиотека, то нормально. Реализаций Форта даже бесплатных хватает, в том числе и для МК.

Например, здесь.

Да но тут под АВР ведь нет....а хотелось би

Как это нет? Смотрите по ссылке Tiny Open Firmware, далее в разделе Software.
Если Вы, конечно, ко мне обращались?

Да к вам ...спосибо, сечас посмотрю

Да посмотрел ну что я не понял ето Forth потом компилирується в hex и вшиваться в АВР...но если так то он мне не нужен мне надо чтоб во Flash AVR роботала моя прога а например по COM гружу в DataFlash скрипт и AVR его испольняет ...на что ето бил байткод

компилятор можно и нужно исключать, компилировать надо на ПК, а в АВР+Луа грузить уже готовый байт код. Накладные расходы на RTTI тоже весьма умеренные: простые переменные -- оверхед 1 байт, сложные 1байт+указатель (в АВР будет 2 байта). Так что как говорится -- было бы желание ужимать. Вы почитайте доку по внутренней реализации Луа. Очень познавательно.

Я не уверен насчет BasicStamp, но то, что я видел (встроенный Basic в МК), то там предлагалась готовая ИДЕ, которая сама незаметно компилировала в байт-код и грузила в МК.

С Луа можно поступить аналогично. Набиваете прогу в текстовом редакторе, компилируете в байт-код Луа, грузите байт-код в МК. Выглядит симпатично...

По поводу дельфей: как я уже говорил -- я ушел на Питон, там все что мне нужно уже есть.


А кого это мучает? ;-) Если Вас это тревожит, можем продолжить разговор за пределами форума, если интересно



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



Если не Phyton а Python (Питон), то имеется какая-то реализация для АВР: http://ucpy.onembedding.com/review.htm#pymite

Доку я читал, правда уже давно, подзабыл.

Ну или Фрактал Бейсик, там точно исходник загружается.

Ну, в таком варианте... Надо X-Modem какой-нибудь.

Ну да, Python (Питон), то я скопировал с одного из предыдущих постов

Bialex, а про CodeSys Вы знаете? Его тоже обещают портировать под различные микроконтроллеры (CodeSys - это только воплощение стандарта MЭК на языки ПЛК). И про Рефлекс вопрос: у Вас есть спецификация языка (или какое-нибудь описание)? Статья на сайте SoftCraft слишком сжато написана. А интересно узнать насколько лучше указанного стандарта MЭК (в смысле возможных элементов языка - конструкций управления, структур данных). Я, естественно, за проект реализации языка Рефлекса, однако спросить непосредственно у автора на форуме SoftCraft пока стесняюсь (так как все мои сведения о Рефлексе ограничены статьей).

Я не могу всего знать :-)

С языком Рефлекс я сам буквально недавно начал разбираться, когда прямым текстом спросил у автора что это такое. Если погуглить, то можно найти еще пару статей Зюбина, но это тоже водичка в основном.
Недавно в журнале "Промышленные АСУ и контроллеры" (№11 2005) вышла статья Зюбина "Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы". В этой статье CodeSys не упоминается, но опять же слегка хвалится Рефлекс. Могу Вам выслать эту статью, либо если потерпите несколько недель, то позже она появится в электронном виде и в и-нете. Возможно, даже на моем сайте (согласие автора я уже имею).

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

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



PS Если не трудно, то bialix, please. Через i. Только пожалуйста: не надо извиняться ;-)

[quote name='Vic1' date='Dec 1 2005, 10:41' post='67793']
про CodeSys Вы знаете?
[quote]

Гугль как обычно рулит. Судя по этой ссылке http://www.codesys.ru/3s/OEM1.htm
CodeSys это всего лишь IDE.

Не, CodeSys серьезная штука... На днях читал статью (не могу найти) ( нашел!), так там кратко описываются средства для ПЛК. Хотя простота и заманчивость решения через заливку исходников-скриптов подкупает. Попробую попристальнее взглянуть на Луну

А что, слово IDE подразумевает нечто несерьезное?



Как я понимаю единственный плюс заливки исходников -- это то, что они никогда не потеряются, в любой момент приходишь с ноутом к дивайсу в поле, загружаешь из МК издохники и начинаешь дорабатывать... Типа как в сименовских лого -- только там используются УГО.

Не знаю, не знаю... Я не готов отдавать лишние ресурсы МК ради такой призрачной выгоды, но это всего лишь я, кому-то это может быть очень сильно интересно. Держите общественность в курсе ;-)

Серьезная штука означает "больше чем ИДЕ". ИДЕ может быть серьезной, но не может быть самодостаточной, иначе она становится монстром. Обычно кроме ИДЕ надо еще SDK или еще чего-нибудь. Я в этом смысле выразился.

Конечно, CodeSys - это IDE, как и IsaGraf, Step7, UltraLogic и еще куча пакетов, реализующих стандарт МЭК 61131-3 на языки программирования ПЛК. Однако CodeSys ориентирован не только на ПЛК, раз сразу заявляется про переносимость на разные платформы. Все эти пакеты состоят из исполнительного ядра Target, загружаемого в микроконтроллер, и среды разработки на инструментальной ПЭВМ. (Мне немного непонятен жаргон с IDE, что под этим понимается) В какой-то степени - интерпретаторы (интерпретатор внутреннего промежуточного кода). Все эти мои знания - из документации и опыта работы с IsaGaf, Step7. CodeSys-ом недавно интересовались (дорогой, зараза, и не портирован почти) для одной из задач автоматизации (разработка некоторого подобия ПЛК для требуемого множества задач). Конечно, в сравнении с Си эффективность ПО, разработанного с помощью этих пакетов никакая. Некоторые ПЛК по-другому просто не запрограммируешь. Применительно к микроконтроллерам - это может быть универсализация ПО некоторого контроллера для большого круга задач с последующим сопровождением специалистом предметной области (для АСУТП - разработка своей схемы управления мастером технологической установки с помощью языков МЭК, например релейной логики или функциональных блоковых диаграмм). Естественно, это не программирование, а только настройка условий, изменение структуры схемы, ... Внесение изменений в алгоритм функционирования системы управления - скорее всего только с программистом (иногда и для программиста нетривиальная задача, так как ограничений в каждом пакете дофига ) Еще одно достоинство - все языки, кроме SFC, взаимозаменяемы (следовало ожидать, раз внутренний код). SFC (это некоторое воплощение идеи Grafset) позволяет описывать логику параллелизма процессов и условий функционирования по событиям. Во всех остальных языках параллелизм присутствует за счет общего принципа синхронизации (каждый тик системного времени обновляются входные и выходные переменные и по очереди запускаются все сегменты программы, выполняющие какую то функцию). Если нужно будет поподробнее, то постараюсь у себя найти в электронном виде.

Стандарт МЭК - это все-таки некоторый шаг вперед в развитии языков и технологии. Рефлекс - это тоже интересный замысел, т.к. при этом еще и язык Си остается. Хотя сравнить с МЭК относительно введения новых элементов и реализации имеющихся - очень интересно.

bialix, может сама найду 11 номер "Промышленные АСУ и контроллеры", а если нет - тогда можно будет Вас попросить отсканировать? Нашла у себя статью Зюбина в "Датчики и системы", автор на эту тему уже с 96 года пишет (судя по списку публикаций).

Насчет форума на SoftCraft - может попробую обратится со своим каким-нибудь коротоким примером, который достаточно типичен и плохо реализуем в Step7 (управление задвижкой с таймаутами). Однако у меня плохо сайт SoftCraft грузится.

Мы похоже спорим о разнице между теплым и мягким. Вашу мысль я понял, ее не оспариваю, просто мои 5 копеек:

IDE == Integrated Development Environment
интегрированная среда разработки
сколько компонентов и в каком сочетании будут наинтегрированы туда -- это уже от фантазии зависит.
Главное, чтобы оно все между собой бесшовно интегрировалось.

На том и порешим. Чего там спорить из-за моей не совсем точной формулировки. Переформулирую: "Не, CodeSys не только ИДЕ"

Ребята меня интересуєт что очень простенькоє котороє работало в АВР. Да ето безусловно всьо хорошо...но времени нет изучать чтото громадноє...

Нельзя ли откадрировать NanoVM?
Буду признателен если кто нибудь сбросит его сюда - немцы ссылку убрали с сайта.

Тогда уточняйте: почему АВР? Какой АВР? Чего скриптить? Почему не годится компилятор? Какой сложности задача? В каком контексте вообще вопрос: управление моргающим светодиодом или кардиостимулятором?

Ну вопервих дествитнльно может кто имеєт NanoVM...
Сложность что по середине между светодиодами и кардостимулятором...а если серйозна то надо для нужд автоматизации...кортит свой написать но очень много надо писать...так вот незнаю что и делать

попробуйте написать прямиком автору, может удасться у него выпросить

>>Hallo,
>>
>>Die NanoVM ist wieder online!
>>The NanoVM is online again!
>>
>>Gruss/Regards,
>> Till
>>
>>--
>>Dr.Ing. Till Harbaum, till@harbaum.org

тута NanoVM

Да теперь будем разбирать NanoVM подойдет ли оно нам

Если "незнаю что и делать", то лучше использовать готовое что-то, а не изобретать велосипед. На http://www.avrfreaks.net поиск по слову "basic" дает несколько ссылок на компилеры. Есть с демками. У Фрактала есть модули (на 51 правда) со встроенным бейсиком. Может, сначала стоит выбрать плату готовую или хотя бы платформу?

ставлю 3 проти 2 що не підійде

Клянусь своим Тектрониксом, два дня тому назад ссылка в нокауте была.)
На вид очень простой . Из классов тока :
# Native classes include:
* java/lang/Object (object handling)
* java/lang/System (IO handling)
* java/io/PrintStream (console output)
* java/lang/StringBuffer (string processing)
* asuro (asuro control)

Если какие то классы не нравятся или функции - то можешь начинать кастрацию кода отсюдова с nanovm\vm\src\vm.c, плюс там еше надо будет классы отфильтровать какие в eeprom будут записываться. Для трансляции NanoVMTool используется. Кстати в директории nanovm\tool\config если не ошибаюсь есть декларация трансляции имен классов и их членов в нумерованные значения , воспринимаемые в виртуальной машине.

Описание самого робота для которого есть пример кода (asuro robot) здесь:
http://www.robotstore.com/support.asp
http://www.robotstore.com/download/402114_manual.pdf

Но кроме того есть и простой пример со светодиодом .
Интересная штучка , будет время как нибудь попробую.

Дык Till как только мне письмо прислал, так я его в инете и опубликовал. Удивительно, что помнит обо мне.

А код действительно забавный!

Поддерживаю.

так кто запустил NanoVM ...кому уже подошла

FVM factory, http://sourceforge.net/projects/c-fvm

Открытый проект с "мягкой" BSD лицензией. Цель проекта - упростить и ускорить процесс создания виртуальных Форт-машин и программ (скриптов) для них. Заточено для embedded применений, под любой процессор. Результирующая FVM пишется на С.

В составе проекта две РС-шные программы под Win32 (в исходниках):

-- Компилятор токенов
Hаписан на Дельфи. Hа входе - желаемый список команд виртуальной машины (токенов), на выходе - С-шные заготовки виртуальной машины. C-шный код в заготовки затем добавляется вручную или берется из "репозитория". В составе проекта есть действующая FVM в качестве примера, а также небольшой "репозиторий", откуда при компиляции берутся "стандартные" С-шные тела токенов. Токены можно добавлять постепенно, по одному, чтобы проще было их отлаживать.

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

Создаваемые FVM 16-битные. Байткоды 1-, 2- и 3-байтные. В отличие от Форта, словари не содержат никакой дополнительной информации, только исполняемые байт-коды. Результирующая FVM займет примерно 1...2К программной памяти.

Найденная ссылка к использованию JAVA для программирования роботов
( дополнительные ссылки есть внутри описания проекта). Корни растут от
программирования Lego Mindstorms.

http://is.ifmo.ru/projects/lego/
http://www.legoproject.narod.ru/ ( доп ссылка )
Bye.

P.S. Использованию форт виртуальных машин можно поискать на http://forth.org.ru
в разделе Wiki сайта.
IDE c сайта tinyboot.com использовал для написания прог для процессора PDP-11
( система команд близка к MSP430 ). Страничка проекта http://forth.org.ru/~kp
Часть оригинальной документации перевел.

Давно интересует данная тема, к сожалению ничего толквого не попадалось.
Вот недавно нашел забавку,

http://www.circuitcellar.com/renesas2005m1...inners/1685.htm

правда руки не доходят разобраться внимательно.
У кого дойдут дайте знать.
Имхо Луа это единственное, что стоит портировать на мелкие кристаллы.

Наиболее впечатляющая Жаба для встроенных применений из всех, которые мне встречались: http://www.rtjcom.com/main.php?p=home

In contrast to other embedded implementations of the virtual machine the simpleRTJ requires on average about 18-24KB of code memory to run.

The simpleRTJ has been primarily designed to run on the small 8/16 bit systems with a small amount of memory. However, the simpleRTJ can also be used on the more powerful devices based on the 32 bit microcontrollers as it supports linear memory addressing of up to 16MB. Porting the simpleRTJ is quite straightforward and in some cases the compilation for the target device may not require any changes at all to the generic VM sources.

The simpleRTJ has been ported to a number of target processors including MC68302, MC68376/332, 68HC11, 68HC16, 8051XA, various ARM7/9 derivatives, H8S/2241, STi5512, embedded x86, ZSP200/400/neo, and many others.

The simpleRTJ includes all of the core features expected from any virtual machine like multi threading, exception handling, interfaces and the garbage collection. On top of this the simpleRTJ doesn't require any support from the underlying RTOS. In fact, it can be considered as a mini Java OS that can run on it's own as it has built in support for the memory allocation, heap management, multi-threading, software timers, etc.

The simpleRTJ is provided free of charge under the RTJ Computing non-commercial source code license agreement to everyone for evaluation, educational and private use.