[dxp 53]

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

[beer_warrior 0]

Насколько я понимаю, задача построения интерпретатора в общем разделяется на две части - операторы и работа с данными. Операторы большой сложности не представляют. Главная проблема в данных.

Во всех скриптовых языках данные тяготеют именно к типу Variant

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

 

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

[SapegoAL 0]

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

 

Всегда тянуло на какой-нибудь аналогичный подвиг. :-) Но так и не довелось. Самое большое ASM и DISASM для 51. :)

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

 

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

[ZiB 0]

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

[beer_warrior 0]

если бы программа выполнялась из внешней памяти

Естессно, например обычно девайс управляеться командами с ком-порта.

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

[SpyBot 0]

[...]

Кстати к интерпретатору ещё и редактор нужен. :)

 

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

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

 

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

Подобный девайс есть, например, у касио - т.н. графический калькулятор. Очень и очень приятная вещь.

Причем мне кажется, что интерпретатор на AVR-ке обгонит спектрумовский асм.

Изменено 5 апреля, 2006 пользователем SpyBot

[proba 0]

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

[BVU 0]

...

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

...

Да что Вы, какие тут могут быть обиды. Здесь форум, а не столовая или баня. :)

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

 

С уважением,

BVU

[Kopa 0]

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

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

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

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

Интерпретаторов какого-либо языка на AVR не встречал.

 

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

Ссылка на динамический паскаль

http://www.southern-storm.com.au/portable_net.html

 

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

 

Еще можно посоветовать обратить взоры на язык Форт (Forth) не путать с фортраном

(Один из лучших, по моему, языков программирования)

[prottoss 0]

...

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

...

Да что Вы, какие тут могут быть обиды. Здесь форум, а не столовая или баня. :)

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

 

С уважением,

BVU

 

 

 

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

 

 

-DATA TYPES-

INTEGER  - 16-bit signed value  ex: 127; $33; 'A' (-32767...32767)
SRAM adress - 16-bit unsigned value ex: 0, $6A, 65500 (0...65535) 
FLASH adress - 16 bit unsigned value ex: #0, #$7FF, #65500 (0...65535) 
EEPROM adress - 16-bit unsigned value ex: %0, %$7DE, %65500 (0...65535) 
PORT adress - 16-bit unsigned value ex: @0, @15, @$1F (0...65535) 


-CONTROL-

RUN  - start BASIC code
CODE  - start user code at adress with programm memory
PRINT  - send value for USART thread
DUMP  - send dump for USART thread
FOR-TO-NEXT - looping structure
GOSUB-RETURN - call subroutine
GOTO  - programm jump
REM  - comment


-LOGICAL, ARITHMETIC-

=  - set equal to
==  - used for evaluation for IF-THEN structure
<>  - not equivalent
>  - is greater than
<  - is less then
>=  - is greater or equivalent than
<=  - is less or equivalent then
-  - subtraction
+  - addition
*  - multiplication
/  - division
AND  - logical AND
OR  - logical OR
XOR  - logical XOR
LSL  - logical shift left
LSR  - logical shift right
RAND  - randomize value
ABS  - get absolute value


-IO-

PEEK  - get value at adress/port
POKE  - set value to adress/port
SET  - set bit at value
CLR  - clear bit at value
BIT  - invert bit at value

[SapegoAL 0]

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

Подобный девайс есть, например, у касио - т.н. графический калькулятор. Очень и очень приятная вещь.

Причем мне кажется, что интерпретатор на AVR-ке обгонит спектрумовский асм.

 

Не совсем обязательно. Предлагаю другой подход!

Пишется и применяется одно ядро. А после ядра подряд располагаются вектора! Типа:

getc

putc

getc_prg

putc_prg

printc

 

Ядро обращается только к векторам.

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

 

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

[Kopa 0]

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

...

 

Примерно так все и делается для AVR в IDE http://www.tinyboot.com/ ( в разделе Firmware)

IDE написана на Форте. Данную IDE использовал при программировании CPU PDP-11

( адаптация заняла примерно пару недель ).

 

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

для PDP также писал симулятор проца и цеплял к IDE.

Изменено 5 апреля, 2006 пользователем Kopa

[beer_warrior 0]

2SasaVitebsk

Пишется и применяется одно ядро. А после ядра подряд располагаются вектора! Типа:

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

 

2BVU

Руссуждения мои по поводу Basic относительно того, кто пишет на 'C/C++', здесь преимущества очевидны...

Вот у меня сейчас работают усторойства - опрос разных датчиков и выдача сигнала о сбоях с системе.

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

 

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

[Harbinger 10]

<PEEK - get value at adress/port

POKE - set value to adress/port>

Я бы разделил. Все-таки POKE-PEEK и OUT-IN - разные вещи, если адресное простанство памяти и ввода-вывода физически разделено:-)

[prottoss 0]

<PEEK - get value at adress/port

POKE - set value to adress/port>

Я бы разделил. Все-таки POKE-PEEK и OUT-IN - разные вещи, если адресное простанство памяти и ввода-вывода физически разделено:-)

 

 

 

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

 

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