Форт (Forth) и MSP430 для изучения, Программирование и исследование на Форт Опции

[Kopa]

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

Код

4E4th on the LaunchPad - 8/16K
Recently we had a meeting in the Lower Rhine region dreaming about a small nice affordable board with a modern MCU and a compact Forth inside.

There it is!

The TI LaunchPad with 4E4th on it. 16K FLASH - 8K Forth and 8K for our own apps. The 4E4th is covered in a 20Pin DIL MSP430G2553.
Now our goal is to supply a TI LaunchPad ready with the MSP430G2553 and Forth inside - all for 4€ - plug in the USB, open the terminal, and there we go! CamelForth430 is the kernel of 4E4th.

I think these are exciting developments.

Michael

P.S. Возможно окажется полезным инструментарием проект немецкого Форт сообщества.
В репозитарии есть ещё некоторые Форт системы для MSP430.
Хотчется услышать мнение участников местного форума.

C MSP430 близко не работал, но "ностальгия" по системе команд PDP-11 осталась
И если приобрести launch pad ($4,6) то можно многое сделать используя Форт идеалогию.
Есть и другие Форт системы для MSP430, но наверное без "продвижителя" данного направления тема "заглохнет":)

Сообщение отредактировал Kopa - Sep 20 2012, 17:15

[zhevak]

Ага. Спасибо. Уже читаю.

Н-н... да. Забавно. Очередное Дурдуино для домохозяек.

Читаю, и иногда подвисаю на приятных воспоминаниях по временам РК-86...
Ну мы тогда Форт тоже изредка юзали. Так, не серьезно. Скорее от безысходности -- ведь Си-компайлера для РК-ашек тогда не было. Зато были широко распространены только ассемблер и Бейсик, которые закрывали почти весь спектр тогдашних задач. Ходил по рукам, правда, еще какой-то не работающий Лэйди-Паскаль. Ну и этот там был -- Форт. Был больше для "коллекции программ", чем для работы.

Я, вот, только не понимаю -- где его (Форт внутри msp430) можно сейчас реально применить с пользой? Сейчас всяких кросс-компиляторов -- мать моя! -- каких только нет! Профи в основном пишут либо на С, либо на асме. Всякие Форты, Паскали, Бэсики, PL... -- это экзотика, а не инструмент для зарабатывания денег. А не профи -- "непрофи" юзают Ардуины.

Может быть я чего-то не догоняю. Но мне кажется, что что-то все-таки ускользает от моего понимания. Что-то я не представляю, что же _такое_толковое_ можно написать на Форте, причем _это_толковое_ ну никак невозможно было бы так же красиво реализовать на С/С++? В чем фишка?

-- Чувствую, что меня кидают. А где -- понять не могу. (с) из анекдота

[MrYuran]

Я, вот, только не понимаю -- где его (Форт внутри msp430) можно сейчас реально применить с пользой?

1. мета-язык (в т.ч. красивая обертка для ассемблера)
2. встраиваемый интерактивный скриптовой движок, который без труда ложится в любой контроллер, от младших пиков и авр до арм.
3. возможна очень плотная упаковка программы засчет использования байт-кода
4. распределенная система хост-таргет с возможностью перераспределения в ходе отладки
5. много ещё чего

Теперь о грустном: к сожалению, систем типа "сел и поехал" практически нет, а если есть (SwiftForth), то стоит вполне конкретно.

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

Вряд ли его сейчас станут применять массово

Посмотрите спецификацию CIL (основа дотнета)
Ничего не напоминает ?

[zhevak]

1. мета-язык (в т.ч. красивая обертка для ассемблера)
2. встраиваемый интерактивный скриптовой движок, который без труда ложится в любой контроллер, от младших пиков и авр до арм.
3. возможна очень плотная упаковка программы засчет использования байт-кода
4. распределенная система хост-таргет с возможностью перераспределения в ходе отладки
5. много ещё чего

1. Ичё? Продолжайте свою мысль, а то она как-то внезапно оборвалась. Клиенту, для кого создается гаджет не то что бы "красивая обертка" не нужна -- ему вообще пофигу на каком языке пишется встроенное в его гаджет ПО. Красота для программиста? ... Сомнительно. Прогеры пишут свои программы не для красоты, а чтобы устройство работало. Программисту-разработчику от этой красоты ни холодно-ни жарко. Удобство использования нужно -- это да. А красота ... это уже к гуманитариям -- художникам, поэтам, музыкантам... К "любителям программирования", которые пишут красивый код не для работы, а для личного самоудовлетворения. (Еще один из множества разновидностей онанизма?)

2. Скрипт -- это хорошо. Скрипт -- это компактно и мощно. Скрипт -- это сверхвысокоуровнево. (Вчера прочитал: "Python -- это язык сверхвысокого уровня". Вот это я понимаю!) Ляжет-то он, конечно, ляжет... но опять же -- какие задачи он нацелен? Что им решать? Приведите какие-нибудь конкретные примеры, что ли. А я (или кто-нибудь) попробуем обсудить -- возможно ли эту задачу решить с помощью каких-то иных средств так же быстро и правильно, как на Форте. Но пока, я в упор не вижу -- где можно использовать "скриптовый" язык в МК-устройствах.

Вот, смотрите -- с одной стороны мы согласны отдать 8 кило флэша под сам Форт. Хорошо. Но, что мы при этом получаем взамен?

А если мы отдаем столько же памяти под какую-нибудь RTOS -- что мы в этом случае теряем, и что получаем?

Вы ведь не хотите отдать область создания ПО для МК домохозяйкам?

И да! Скрипты! Это область, когда нужно оперативно накидать прожку, чтобы быстро разрулить большой объем работы. Скрипты хороши тогда, когда нужно время от времени подправлять их (скриптов) работу. Но мы знаем, что в 99.9% МК-устройствах программа заливается один раз. И пашет там пожизненно. Заметьте, поменять уставки (установки, параметры, конфиги) -- это не то, что поменять скриптовую прогу.

3. Очень плотная упаковка кода? Хм... Это как? Разве есть какие-то проблемы с МК, у которых не хватает памяти? Люди уже давно не пишут на асме большие проги (большие, скажем, 2-4 килоайт) ради того, чтобы сэкономить еще "один байт". Смысл ужиматься? Не хватает памяти -- возьмите другой МК.

Давно уже канули времена, когда разница в МК с разным объемом памяти была ощутима. По инерции приводят гипотетические примеры, дескать -- для производства, которое выдает на гора стони-тысячи изделий в месяц, это проблема стоит очень остро. -- Фигня! Бред! У меня такое же производство, и я по первости тоже искал себе "проблему одного байта". Сейчас понял -- надуманно это все! Стоимость МК в изделии составляет от силы несколько процентов. Какая разница, во сколько будет выливаться себестоимость изделия -- в 2345 рублей или 2389? Важно не это, а динамика развития производства. Если каждый месяц количество заказов увеличивается на 10-30%, то экономить на 1-2% за счет "узкого" проца -- только себе засерать развитие. Производите разработку -- Отлично! Закладывайте сразу проц в двукратным количеством памяти. По деньгам не чувствительно, зато будет пространства для маневра.

4. "Переведи!" (с) из советского к/ф. Это как? Ничего не понял.

5. Ни о чем! Всё будет надуманно и высосано из пальца. (Паручики, молчать!!!)


Теперь о грустном. К сожалению, я так и не понял -- зачем Форт? Или что он должен собой вытеснить (заменить)?

Да! И еще пара вопросов.

1. О манагерах. Я их тоже недолюбливаю. Но в данном вопросе с ними солидарен.

Вот, допустим, был у меня один такой уникум -- разработчик МК-системы, писал на Форте. Уволился (не важно по какой причине!) Дальше что? Разработки встали колом? Все начинать с начала и на международном языке программирования (С/С++) или учить самому/учить людей Форту. Ну и зачем мне залазить в такой "производственный капкан"?

2. Как у Форта обстоят дела с многозадачностью? Можно-ли на нем написать event-driven ПО? (Уточняю -- событийно-управляемое ПО.) Грубо -- это такое ПО, которое всё время спит, то есть не кушает батарею, не греется. Но как только в системе возникает какое-либо событие (прерывание), система пробуждается и начинает его обрабатывать. В такой системе возможны порождения вторичных событий. События в систему могут поступать по нескольким каналам.

Например:
- тикает системный таймер,
- пришел ответ по SPI, достать его из регистра и засунуть в буфер
- UART отправил байт, и нужно в него загрузить следующий
- юзвер нажал на кнопочку,
- сработал концевик, датчик перегрузки и т.п.
и т.д.

А то получится как во времена DOS:

Код

do (!конец_работы())
{
  if (ответ_от_HDD_получен() == 1)
    обработать_файл();
  else if (клавиатура_нажата() == 1)
    определить_нажатую_клавишу();
  else if (событие_от_мышки() == 1)
    определить_какое_событие_случилось_у_мышки();
  else if (тайм-аут_истек() == 1)
    погасить_экран();
}

Ни в спячку систему не отправить, ни быстро отреагировать на событие.

[SyncLair]

1.Но пока, я в упор не вижу -- где можно использовать "скриптовый" язык в МК-устройствах.
Скрипты хороши тогда, когда нужно время от времени подправлять их (скриптов) работу.

2. Очень плотная упаковка кода? Хм... Это как? Разве есть какие-то проблемы с МК, у которых не хватает памяти? Люди уже давно не пишут на асме большие проги (большие, скажем, 2-4 килоайт) ради того, чтобы сэкономить еще "один байт". Смысл ужиматься? Не хватает памяти -- возьмите другой МК.


3. Как у Форта обстоят дела с многозадачностью? Можно-ли на нем написать event-driven ПО? (Уточняю -- событийно-управляемое ПО.)

1. Менее грамотные специалисты-программисты просто пишут скриптовый файл -- система их выполняет. Актуально на мой взгляд, сложно ли будет написать форт интерпретатор который кушает что-то типа DOSовских *.BAT файлов?

2. Вот действительно как оценить упаковку кода? Наверное имелось в виду то, что программа на Форте меньше занимает строк, слов, выражений Я правильно понимаю?

3.Вот этот вопрос меня действительно интересует! Есть в Форте механизмы параллельного исполнения?
Или единственный вариант -- упаковывать все события в системе в одну большую очередь и обрабатывать их единственным интерпретатором.


И напоследок ещё один вопрос! Есть ли где примеры того что на форте написан рельно работающий интерпретатор для embedded устройств. Интересует хотя бы такие вещи:
1.Чтение конфигурационных файлов для загрузчика -- на подобие синтаксиса GRUB или UBOOT
2.Интерпретация FTP команд embedded FTP сервером ?