SDL Опции

[Fujitser]

Имею вопрос. Здесь пролетало сообщение об использовании SDL для программирования контроллеров. Можно поподробнее? Где взять хотя бы описание SDL?
Вообще, кто-либо видел инструментальные средства для программирования МК с помощью языков типа UML и т. п.?
Вообще, интересует все, что связано с формальным описанием конечных автоматов и получением на базе данного описания исполняемого кода.
Кому интересно - давайте пообщаемся.

[TMX]

Имею вопрос. Здесь пролетало сообщение об использовании SDL для программирования контроллеров. Можно поподробнее? Где взять хотя бы описание SDL?
Вообще, кто-либо видел инструментальные средства для программирования МК с помощью языков типа UML и т. п.?
Вообще, интересует все, что связано с формальным описанием конечных автоматов и получением на базе данного описания исполняемого кода.
Кому интересно - давайте пообщаемся.

Я использую ДРАКОН, мне нравится больше чем SDL или UML.
Особенно удобно для конечных автоматов (протоколов например), в сущности, это совмещение диаграммы состояний и диаграммы действий.
Однако средств генерации кода для него не видел.
Да, собственно, и не особенно искал - прорисовка и обдумывание алгоритма занимают основное время, написание кода гораздо меньше (выйгрыш от экономии времени при тестировании)

[Fujitser]

Абсолютно согласен с тем, что прорисовка и обдумывание алгоритма занимают основное время, но и на ручное кодирование время тоже уходит немало.
После того, как я пять раз перешивал свое устройство (один раз для этого пришлось ехать за тыщу км, так как оно было уже установлено на объекте заказчика моего заказчика), я придумал изощренное издевательство над заказчиком - рисую UML-диаграммы полностью, заказчик их проверяет (благо, они просты для понимания), потом кодирую формальным образом - что на диаграмме, то и в коде. Заказчик сначала пытался возмущаться, потом понял, что экономится и его, и мое время. Преимущество огромное.
Но хотелось бы автокодер. Причина - даже если кодирование занимает 2-3 дня (вместо 2-3-х недель, как раньше), даже этих двух дней просто нет (я веду одновременно 3-4 проекта).
IAR VisualState скачивал, но во-первых, демку (кстати, никто не знает, где взять лечилку для полной версии), во вторых, мне она показалась очень сырой, в третьих, я использую 16-битные Fujitsu (MB90FXXX), а данный продукт их не поддерживает (поправьте меня, если я ошибаюсь). Отсюда идея - создание транслятора UML - C, с возможностью подключения различных модулей трансляции для разных МК. Время займет много, но IMHO, оно того стоит. Недостаток один - "раздутый" код, но, опять же, по моему мнению, не так уж это и страшно, если программа вместо 1-2 Кб будет весить 10-15Кб, так как в "моих" контроллерах флэш-памяти меньше 32Кб не бывает в принципе, а обычное значение - от 64 до 256Кб (бывает и больше). Конечно, если у вас миллионное производство и нужно экономить каждую копейку, то поневоле придется писать все на асме и тщательно оптимизировать, чтобы вошло в самый дешевый ПИК или Атмел, но как показывают наблюдения, 99 процентов разрабатываемых у нас МК устройств - одиночные экземпляры или мелкосерийка (услышал на одном семинаре замечательную фразу - в России пять штук - уже серия), а в этих условиях основные затраты приходятся на проектирование. А основные затраты на проектирование МК-устройств приходятся на разработку ПО.
Кто что скажет по данному поводу?

[bialix]

IAR VisualState скачивал, но во-первых, демку (кстати, никто не знает, где взять лечилку для полной версии),

Я знаю ;-)

во вторых, мне она показалась очень сырой,

Я бы не стал называть сырым продукт, версия которого дошла до 5.1 ;-)

в третьих, я использую 16-битные Fujitsu (MB90FXXX), а данный продукт их не поддерживает (поправьте меня, если я ошибаюсь).

Не путайте мягкое с теплым.
ИАР не имеет Си-компилятора под фуджики, такое впечатление что кроме софтюны ничего под фуджи не существует.
Сам же VisualState генерит переносимый Си-код, который уж затем нужно компилировать вашим любимым компилятором. И не обязательно, чтобы это был ТОЛЬКО иаровский компилер. Такого в доке нигде не написано. Никакой жесткой привязки к конкретной архитектуре при генерации кода не наблюдается. Вполне приличный переносимый код. Не лишенный определенных недостатков, с которыми тем не менее можно мириться.

Отсюда идея - создание транслятора UML - C, с возможностью подключения различных модулей трансляции для разных МК. Время займет много, но IMHO, оно того стоит.

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

Редактор очень удобный. Есть функция проверки и симуляции работы логики конечного автомата. Есть генератор кода. Что еще нужно для счастья? Почитать доку и разобраться как использовать сгенерированный код в своем проекте. Вот в сущности и все.

Так что начинать проект подобного масштаба в то время, когда есть готовый продукт -- ИМХО глупо, это нелогичная трата времени.

Попробуйте все-таки поразбираться с докой на VisualState (для начала хорошо бы почитать вводный документ Quick Start Tutorial). Если Вы уже знакомы с конечными автоматами и диаграммами UML -- у Вас уйдет на это полдня максимум. Демка позволяет строить диаграммы на 20 состояний и генерить полноценный код.

Если и после этого Вам все равно будет хотеться сделать все самому и с нуля, то имеет смысл пойти на sourceforge.net и покопаться в залежах проектов на тему Code Generation. Я там видел несколько проектов, ориентированных на finite state machine.

За лекарством -- обращайтесь.
Кстати, как положить лекарство на местный ftp?
Может кто из админов сделает это? Я вышлю мылом - там небольшой архив