Доброго времени суток!

Возникла идея написания интерпретатора Basic для МК AVR. Не буду говорить о мотивах, подтолкнувших меня на это дело. Возникло несколько вопросов перед решением данной задачи:



1. Нужно ли это кому нибудь.

2. А не изобретаю ли я велосипед.



Ну и еще несколько, которые появятся, если я реально за это возьмусь.

Не то что велосипед, баян
Например AttoBasic в гугле

Может одумаетесь!? Помоемому такого добра уже имеется, кто-то как-то спрашивал и ссылки давали:
http://www.fastavr.com
Так же попробуйте сделать тематический поиск по форуму еще есть информация...

Я написал, что собираюсь написать ИНТЕРПРЕТАТОР а не КОМПИЛЯТОР, вы различаете буквы!?







Понятно :-) А Вы его пользовали сами, или аналогичные интерпретаторы. Как по скорости, и по глючности? И, вообще, какие впечатления?

http://instruct1.cit.cornell.edu/courses/e...dbh8/index.html

Различаю, различаю, очень различаю! Тем более никакой интерпретатор не идет в сравнение с компилятором - для 'встроенных систем'. Одна из прелестей AVR, то что это довольно скоростные 8-ми битные микроконтроллеры, а Вы их своим интерпретатором - придавить хотите...
Ну да дело, как говориться 'на вкус на цвет'...

Не всегда нужно ограничиваться скоростью при выборе МК. Тем паче у AVR еще, кроме скорости, масса преимуществ перед другими МК. Иногда системе нужна не скорость, а нечто другое. Я уважаю Ваше мнение, и часто читаю Ваши ответы в топиках, и, честно говоря, не думал что Вы так узко мыслите по поводу AVR...Извините, если я Вас обидел, конечно.



Одно из качеств, которое мне нравилось в контроллерах и микропроцессорах, отличных от AVR, так это то, что к ним в память программ можно было "на лету" подгрузить код. А AVR этого не позволяют (я не имею ввиду программирование памяти программ), хотя у них есть много того, чего нет в том же MCS-51 и т.п. Есть не мало задач, требующих выполнения каких либо скриптов в реал-тайме...

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

Может и вам надо что-то свое, а не бейсик?

Кстати, как вариант - жаба...

:-) Жаба - это с уклоном в сторону мобильников, что ли? BASIC он и в Африке ВАСИК. Просто и быстро. Кстати, поиск по сети, кроме AttoBasic и ECE476:Basic Interpreter ничего не дал, хотя я может быть плохо искал... Последний проблемноориентированный, т.е. требует LCD клавы и т.д.



Я идею свою до конца еще не сформировал. Но скорее из железа будет требоваться только RS-232 адаптер. Со стороны РС софт (консоль или DOS) для загрузки кода и приема данных от функции PRINT. Скорее всего интерпретатор я не буду писать с нуля (я не Билли Гейтс :-)). Возьму какой нибудь каракас для основы, понятно. У меня есть исходники для MCS-51 и x86... Ладно буду пробовать.



Спасибо всем за ответы-советы.

Насчет бейсика - точно не нужно, а вот интерпретатор урезанного паскаля был бы очень кстати.
Интерпретаторов какого-либо языка на AVR не встречал.

PS: Интерпретатору нужно много RAM'а.. память внешнюю будете ставить?

Все таки поэксперементирую пока с BASICом. Все проще начинать. По поводу памятив голове много идей вертится. Можно, например, прикрутить внешний SPI ФЛЭШ, и грузить скрипты(программу) через него, а можно задействовать один из портов для связи с внешней SRAM. Пока еще все витает в невесомости, так же как и сама идея написание интерпретатора.



А интерператоры для AVR имеются. Где то совсем недавно была ветка по встраиванию Явы. Поищите, там есть что почитать и масса ссылок

Идея крайне интересная, однако ничего достойного пока не попадалось.
Бэйсик имхо не лучший выбор, смотрел Ruby и Lua, тяжеловато будет.
Вероятно надо рыть на sourceforge, там полно проектов по скриптовым языкам, выбрать что-н полегковеснее и портировать.

Все же я не пойму, чем Васик то не устраивает? По моему, его проще всего запихать в МК, и если надо подзаточить под ядро

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

Есть типы, определяются суффиксом переменной: A% - целое, A$ - строка, и т.п. Во встраиваемом варианте для простоты можно оставить только int и, возможно, строки.
В целом, задача в смысле ресурсов не тяжёлая, младшие меги вполне потянут.
БГ, помнится, свой первый интерпретатор в 4К уместил

Даешь Python для AVR! А что, это было бы круто! Только очень медленно.

Насколько я понимаю, задача построения интерпретатора в общем разделяется на две части - операторы и работа с данными. Операторы большой сложности не представляют. Главная проблема в данных.
Во всех скриптовых языках данные тяготеют именно к типу Variant
Насколько я пытался анализировать, в Python, tcl, Lua данные храняться в текстовом виде в таблицах. Это соответсвенно требует памяти, о чем уже говорилось. Васик здесь будет не лучше и не хуже.Почему я не считаю Васик лучшим выбором - вышеприведенные языки во-первых более вольны в синтаксисе, во-вторых растут из более профессионального UNIX-мира, в третьих изначально создавались как embedded, для встраивания сценариев в большой софт. С таким же успехом могут быть встроены и в железо.

И последнее, может быть просто здесь, в ветке, сформировать требования к языку и попробовать найти реализацию соответствующую требованиям? Или урезать что-н известное для соответсвия ним?

Всегда тянуло на какой-нибудь аналогичный подвиг. :-) Но так и не довелось. Самое большое ASM и DISASM для 51.
Интерпретатор по определению много памяти жрёт. Ну очень много. Хотя есть и варианты. Я некогда встречал типа компилятор-интерпретатор с языка Паскаль. На так называемом Пи-коде. Так реализация очень маленькая. По-моему 4к. И работала прилично. Кстати к интерпретатору ещё и редактор нужен.

А в общем - дерзай. Зачем обосновывать необходимость? Я тебя марально поддерживаю! По крайней мере удовольствие получишь.

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

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

Насчет удовольствия полностью поддерживаю!

И имхо надо делать автономное устройство - с ЖКИ, клавиатурой, энергонезависимой памятью. И ОЗУ вешать не на какой-нибудь порт, а на специально отведенную для этого шину Со временем добавлять различные "быстрые" функции.
Подобный девайс есть, например, у касио - т.н. графический калькулятор. Очень и очень приятная вещь.
Причем мне кажется, что интерпретатор на AVR-ке обгонит спектрумовский асм.

posmotrite Circuitcellar M16C contest , tam jest project PLC Basic i project Lua. Renesas M16C nemnogo moshneje AVR noo ne osobo.
http://www.circuitcellar.com/renesas2005m16c/
http://www.circuitcellar.com/renesas2005m1...inners/1685.htm
http://www.circuitcellar.com/renesas2005m1...ers/DE/1678.htm

Да что Вы, какие тут могут быть обиды. Здесь форум, а не столовая или баня.
Если кому-то это действительно нужно, как уже выяснилось, со своей стороны могу пожелать удачи в этом деле. Руссуждения мои по поводу Basic относительно того, кто пишет на 'C/C++', здесь преимущества очевидны... т.е. глубокая проработка проекта относительно использования языка программирования, что не всегда можно сделать на Basic. Аргумент по скоростным качествам AVR, приводился, как один из немногих. Конечно же выбор контроллера проводиться по комплексу характеристик максимального соответствия поставленной задачи.

С уважением,
BVU

Ссылка на динамический паскаль
http://www.southern-storm.com.au/portable_net.html

Для Windы собирал через cygwin

Еще можно посоветовать обратить взоры на язык Форт (Forth) не путать с фортраном
(Один из лучших, по моему, языков программирования)

Поймите, я не собираюсь писать OS BASIC а ля Спектрум. Я хочу написать что то типа скрипта, с возможностью запуска кода пользователя. У меня нет цели написать объектно-ориентированную среду программирования, этим занимается исполняемый код в контроллере. А интерпретатор (может быть это даже громко сказанно) - это прослойка между хостом и исполняемым кодом, хотя исполняемого кода может и не быть совсем :-). Я тут накидал примерный список команд и разделение типов (больше относится к адресам)

Не совсем обязательно. Предлагаю другой подход!
Пишется и применяется одно ядро. А после ядра подряд располагаются вектора! Типа:
getc
putc
getc_prg
putc_prg
printc

Ядро обращается только к векторам.
Таким образом при смене стандартной переферии необходимо лишь написать BIOS. И подключай чего хошь! Хошь RS232, а хошь встроенный LCD. И для программы можно использовать разные устройства хранения. Хошь внутр. или внешний флэш а хошь SD.

Короче в этом случае нет необходимости жёсткой привязки к оборудованию. И не требуется введение нестандартных команд и опций!

Примерно так все и делается для AVR в IDE http://www.tinyboot.com/ ( в разделе Firmware)
IDE написана на Форте. Данную IDE использовал при программировании CPU PDP-11
( адаптация заняла примерно пару недель ).

Сейчас продумываю возможности улучшения. (Часть документации перевел)
для PDP также писал симулятор проца и цеплял к IDE.

2SasaVitebsk

Это уже больше похоже на ОС.Речь же идет об интерпретаторе.

2BVU

Вот у меня сейчас работают усторойства - опрос разных датчиков и выдача сигнала о сбоях с системе.
Уже сейчас, в эксплуатации выясняеться, что на разных конечных точках заветная комбинация будет разная, сигналы аварии тоже. В результате поддерживаю 5 версий одной прошивки. Перестановка коробки сопровожддаеться прошивкой софта. Вижу простейшее решение - опрос датчиков, клавиатуры, 485-го на С, интерпретацией полученных результатов - заветные комбинации совпадений и выдача сигнала на буззер, светодиоды и 485-й занимаеться именно скрипт, который при необходимости может нашкрябать и сам потребитель.

2Kopa вижу не первый ваш пост посвященный Форту. О языки слыхал много и возможно это действительно решение. Где можно почитать толковый Getting Started?

<PEEK - get value at adress/port
POKE - set value to adress/port>
Я бы разделил. Все-таки POKE-PEEK и OUT-IN - разные вещи, если адресное простанство памяти и ввода-вывода физически разделено:-)

Читайте внимательней, что я привел. Во входном параметре для функций POKE-PEEK есть префикс - #, %, @ - означающий соответственно ФЛЭШ, ЕЕПРОМ и ИО. Если префикса нет, то SRAM.

Кстати адресное пространство ввода-вывода как раз не разделено, а есть одно и то же простарнство статической памяти (SRAM). Просто через команды IN, OUT идет обращение со смещением и адрес в инструкции имеет длину помоему 6 бит. К портам и к РОН можно обращаться так же как к ячейкам памяти SRAM непосредственно или через указатель

Кстати совсем без улыбок. Вспомни множество одноплатных эвм. Бэйсик там и выполняет по сути функцию ОС. Да и по-моему вполне обоснованное решение. Это же интерпретатор. Т.е любая команда может быть сразу же исполнена. Ну например на приглашение написал 2+2 и получил свои 4.

Зато такой продукт можно поставлять как законченный. В откомпилированном виде. И типовые решения для векторов. Например для rs232.

Короче если бы это делал я, то делал бы так как я описал. В любом случае это практически не даёт проигрыша в производительности (+3 такта на вызов).

По поводу Форта.
Пробовал когда-то ещё в институте. Может это и мощная штука, ну уж очень координальная.
Я тут старую книжку по C взял и во вступлении напоролся на фразу типа Си это отмерающий язык, а вот Форт сейчас стремительно завоёвывает популярность. Тому уже больше 20 лет. Нифига что-то стремительности не видно. Хочется задать вопрос - почему?

аналогичный мысль и у меня в голове,только на мс12ne64 , автономныи Basic контроллер для дома,программируемый через web и способный посылать email или sms если что-то екстренное. пока только нашел примитивныи basic, написанный в C, но мне кажется , проблемы будут с real-time. скорее всего, надо делать так что интерпретатор запускался с определенном интерваллом, например раз в сек. тогда процессору останется время для web применении

Есть у меня давняя потаенная мечта - сделать контроллер, у которого
* все RT задачи были бы на писаны на С/ASM под мультитаскером
* управляющая логика общалась бы через очереди с RT частью (обычно эта часть не сильно сложная и не сильно RT)

Вижу, что я не одинок.

Но смущает меня изначальная ориентация на AVR. Это чудный кристалл, но не для этой задачи.

Щас в меня полетят кирпичи и палки... Я предлагаю:
* LPC229x c 256K FLASH
* 2 микрухи SRAM 4Mbit (256kx 16) на ОЗУ
* портировать на это упомянутый выше замечательный пример на LUAВот отличие от игрушек с BASIC и AVR, это получился бы вполне ценный коммерческий продукт, над которым негрешно дого и плодотворно работать. Так сказать, и кайф поймаете, и денежные перспективы не такие уж и стремные. IMHO, есть масса задач, который надо решать скриптовыми языками. IO порт опрашивать из скрипта - маразм, а от из FIFO читать да анализировать - полный кайф!

Дык, а разве не так все нормальные программы пишутся?..
Что-то Вы пропустили imho.. Интерпретатор то здесь с какого боку?

Знакомство с возможностями Форт языка можно начать с http://forth.org.ru ( в разделе литература
,если поискать, находятся ссылки на учебники и стандарт форта 94г. переведенный на русский язык)
Обсуждения околофортовских вопросов находится в раздел wiki этого сайта.

По поводу популярности языка можно высказать следующее мнение:

1. Язык разрабатывался и применяется для разработки встроенного ПО в ограниченых ресурсах.
Изначально применялась техника шитого кода для уменьшения объема исполняемого кода.
Сейчас, зачастую, язык компилируется в код процессора.
2. Парадигма программирования близка к функциональному программированию.
И предполагает обработку данных потоковым способом. Данные при этом неявным способом
могут передаваться между процедурами ( в терминалогии Форт системм гланым понятием выступает - слово ). В процедуре же они , из возможностей стандарта 94г., могут иметь локальные имена (формальные параметры).
На переходе 90х годов для разработки крупных проектов приняли, более жесткую и прозрачную парадигму привязки программ обработки данных к самим данным.
3. Для начального изучения основ алгоритмов не так хорош, в силу своей изоморфности.
4. Разработка форто подобного языка проводилась до недавнего времени в МГУ назывался он
ДССП ( диалоговая система структурного программирования ). Одна из поставленных целей
это сокращение разрыва между языком и процессором.
5. Язык не поддержан крупными производителями, по разным причинам.
6. Изданная литература по языку в России начала 90х годов не отражает текущее состояния
возможностей языка.
7. В силу своей изоморфности, расширяемости и внутреннего построения данный язык может быстро трансформироваться в любой другой язык. Доступ к внутренней форт машине всегда открыт!!!!
Математическая модель Форт машины близка к Java, Net и многим другим виртуалкам.
Поддержку синтаксисиса своего языка необреминительное занятие. Более менее расширенных несовместимых реализаций Форт языка много.
8. Минимальный контроль над действиями программиста не всегда способствует дисциплине
программирования.
...

В активе русского форта SPF написаны пара серьезных программ eserv ( мультисервер) и
nncron ( продвинутый планировщик)

Извиняюсь за офтопик. На данном форуме, наверное только, =AK= использует его для работы
( поправьте меня если еще кто находит реальные применения данному языку)

С юзеровского.

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

А вот сваять скрипт на LUA (из которого при правильном подоходе _физически_ ничего нельзя "вынести" в других частях ПО) может любой чуть-чуть продвинутый кустомер.

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

А тут вместо мегабайтного конфигурационного файла - скриптовая прога. Что хочешь, что и пиши (в пределах ресурса контроллера).

Интересно, почему? Вот глядя в доку - все очень классно. А чего же не юзают в реальном мире?

Или все дело в стереотипе мышления?

1. По поводу поддержки крупным( считай потребители его "миллионы") производителем, то
по этому поводу можно предположить, что зависимость потребителя от производителя ПО
станет минимальной-> доходы производителя резко упадут.
2. Привитые стереотипы играют доминирующую роль в восприятии предметной области и
способов работы с ней.
3. В реальном мире очень даже юзают, но т.к. этот язык достаточно уникален, то знают
о нем немногие. Да и на работе требуется мобильность проектов( в вузе его не преподают).
Печатных книг с хорошим учебным материалам не издается.

Просто заговор мирового "империалИзьма" против "рабочих-программистов". Интересно, сколько занимает эта самая фиртуальная forth машина скажем, для ARM, AVR или 68000?

На сайте http://forth.org.ru/ я то-то перевода стандарта 94 г. не нашел. Не ткнете носом?

Все зависит от разработчика, его способностей и необходимой функциональности.
Примерные цифры 8кБ

Стандарт можно найти кликнув в разделе литература по первой ссылке, в открывшемся окне
кликнуть по ссылки УчебникиФорта ( тоже вверху страничке ). Бардак какой-то
Стандарт языка без знания общей идеалогии языка читать, может быть, трудно.

Да, да, да!!!
Потребность в такой игрушке ощущаю уже года 2. И мелкие АРМы просто созданы для этой задачи.
ReVaLuaTe скачал довольно давно, только вот руки не доходят покопаться основательно.
И последнее 0.5М памяти зачем? Не слишком ли?
Я бы например предложил связку из последовательных флэш и рам,
у Атмела помоему есть оба в одном флаконе. Можно спокойно масштабировать в зависимости от размера скриптов.

Примерно 2 кило на сях, см. http://sourceforge.net/projects/c-fvm
Но это не полный Форт, а именно виртуальная Форт-машина, где компилятор кроссовый.

Это совсем не игрушка!!!Даже не 0.5, а 1М памяти.

Есть такая замечательная ОС - eCos. Я о ней тут довольно много писал, сам сейчас ее активно изучаю.

А для eCos есть порт LUA.

1М SRAM - этого хватит для комфортной отладки eCos с пликухой. Потребности памяти реального проекта будут определены позднее.

Гробить производительност на последовательной памяти - может, где-то это и допустимо, но не на этапе разработки и отладки.


Нда, все это живо напомнило мне калькулятор МК-61. Помнится, "отформатировав могзи", я очень быстро на нем считал и писал программы. И когда мне в руки попадался обычный калькулятор "со скобками" - я удивлялся - нафига люди пользуются этим уродцем?

Было это в 1986 году... Но сейчас я уже забыл все это в силу неактуальности.

Ну да с eCos это уже не игрушка.
Я думал взять чего-н. попроще.Но в принципе можно поиграться и на максимуме, а потом урезать.
Впрочем разговор уже уходит за пределы AVR.
М.б. продолжим в ARM или OS?

Именно! Обрезать куда легче, чем пришивать. А для отладочной борды разница в цене не существенна - сама плата и время стоят куда дороже!

Кстати, есть свежая книжка по форту - непонятно, почему на сайте супер-пупер фортистов нет на нее ссылки (есть только перевод первого издания 10 летней давности)?
http://thinking-forth.sourceforge.net/Да! В ОСях тема недавно была хорошая - "Когда не нужна ОС РВ?"
http://electronix.ru/forum/index.php?showtopic=13407
Там всякие МЭКовские языки обсуждали пр - довольно близко к тому, что мы начали тут обсуждать.

Имеет смысл перенести обсуждение в ОСи.

В ссылках на литературу именно эта ссылка и находится

Да, есть такое!

Все выше сказанное, конечно, очень интересно. Но, я, с вашего позволения, продолжу тему BASIC INTERPRETER FOR AVR :-)

Пока я делал наброски кода, параллельно обдумывал интерфейс связи с хостом. Хотелось бы сделать данную софтину как можно менее ресурсо прожорливую. В качестве внешнего интерфейса в AVR пока для меня видится USART. Вот только вопрос, надо ли задействовать аппаратный, или же применить программный... Хотя в этом случае придется задействовать один из счетчиков. Наверное, проще будет сделать оба варианта...Сам на свой вопрос и ответил... :-)

"Чернила для 6-го класса?" Разве что пустой причуды ради хотите написать его на ассемблере. Ресурсы по Бэйсику, http://www.nicholson.com/rhn/basic/

Сам интерпретатор может быть достаточно произвольным. Например, Атари Бэйсик компилировал бэйсик исходник в байт-код, который затем исполнялся виртуальной Форт-машиной. Все было написано на ассемблере 6502, но это когда ж было...

У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?

OFF:Ну конечно, куда мне до вас, акул электроники, мечтающих, забабахать что нибудь эдакое и новомодное. Да, из 6-го класса я вылез не так давно, и ВУЗ окончил совсем таки недавно. То что мне попадалось в сети и то, на что давались ссылки в этом топике я смотрел и анализировал, что то понравилось, от чего то отказался. Но мне это нужно, и я это напишу. Сдесь же я пытался получить какие то конструктивные советы, а не мечтания о новой ОСи



RE: У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?



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