[bialix 0]

По пунктам:

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

 

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

 

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

 

Далее: мне Lua интересна, на ПК я делал как-то генератор страниц на нем из базы данных по шаблонам - задача ложится отлично, буквально несколько строк кода... Кабы сделать типа BasicStamp - цены бы не было при приемлемых ресурсах.

 

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

 

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

 

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

 

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

 

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

[Andy Great 0]

Потом, примерно 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.: не в ОФФ ли мы заходим?

Изменено 30 ноября, 2005 пользователем Andy Great

[volod_ua 0]

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

[Andy Great 0]

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

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

[IgorKossak 0]

... Реализаций Форта даже бесплатных хватает, в том числе и для МК.

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

[volod_ua 0]

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

[IgorKossak 0]

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

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

Если Вы, конечно, ко мне обращались? ;)

[volod_ua 0]

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

 

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

[bialix 0]

Потом, примерно 1/3 -- это компилятор, его тоже нужно исключать.

Компилятор исключить не удастся: исполняется скомпилированный код. Так написано в доке, и так по здравому смыслу. Компактной по ОЗУ на мой взгляд не может быть среда, в которой есть RTTI: в Lua все переменные - объекты.

Сравнение с BasicStamp (а не просто Basic) в том, чтобы залить в МК исходный текст программы, без использования промежуточных компиляторов. Типа: набрал в редакторе, залил в терминале - вуаля!

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

Phyton на МК... не знаю.

 

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

[Andy Great 0]

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

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

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

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

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

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

Phyton на МК... не знаю.

 

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

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

[Виктория 0]

...

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

 

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

[bialix 0]

...

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

 

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

 

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

 

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

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

 

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

 

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

 

 

 

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

 

про CodeSys Вы знаете?

 

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

CodeSys это всего лишь IDE.

[Andy Great 0]

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

CodeSys это всего лишь IDE.

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

[bialix 0]

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

CodeSys это всего лишь IDE.

Не, CodeSys серьезная штука...

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

 

Хотя простота и заманчивость решения через заливку исходников-скриптов подкупает. Попробую попристальнее взглянуть на Луну :smile3046:

 

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

 

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

Изменено 2 декабря, 2005 пользователем bialix

[Andy Great 0]

Не, CodeSys серьезная штука...

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

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