Easyelectronics.ru

micropascal у него.

Сейчас пока в основном MikroPascal Pro 1.4. Есть также скачанные до версии 3.2, но особой разницы почти нет, 3.20 проинсталировал, просмотрел, но исходники лень перетаскивать, так пока 1.40и пользую. Есть все, что надо, вплоть до Ethernet, многие библиотеки продублированы и для софтовой, и для аппаратной реализации интерфейсов. Единственно, чего нехватает - почему-то нет поддержки I2C Slave, только для Master. В принципе, несложно добавить несколько аналогичных процедур на ассемблере, и использовать также, как библиотечные для Мастера, но лучше бы были. В остальном замечаний нет, все прекрасно сделано и работает. Я уже несколько раз писал про компиляторы от МикроЭлектроники по другим темам.

Мне тоже другие компиляторы не нравились, приходилось писать на ассемблере, пока не попробовал от МикроЭлектроники. Лучше не видел, а самому писать - только время терять, и вряд ли лучше получится.
Я в 80х годах на работе от нужды, чтобы работать с однокристаллками РВЕ35 (КР1816ВЕ35), позже с 48, сделал микропроцессорный отладочный комплекс на КР580ВМ80А, для которого написал полную кросс - систему, - редактор, компилятор, дизассемблер, отладчик, программатор. Программы хранил на магнитофоне Илеть 203... Потратил полгода, зато сэкономил потом кучу времени на разработках контроллеров. Из заводских компов у нас в то время были только ДВК-2, и то гораздо позже, когда у меня уже все работало... В 89г купили 3шт "Корвет" (сам с Москвы их поездом вез), там в комплекте уже было 10 языков и 2 операционки - CP/M-80 и МикроДОС.
Сейчас намахать компилятор для микроконтроллера, например, на DELPHI, не проблема, только зачем, когда готовых полно...

DI HALT
Спасибо, я так и думал

--
To All
Что с виртуальной машиной? Не хочется что бы обсуждение умерло. Предлагайте свои идеи что ли :)
Начать, я думаю, лучше с синтаксиса и основных механизмов входного языка. Свой вариант я уже предложил. Так же нужно подумать о вычислительной модели и разрядности ВМ. Предлагаю для простоты ВМ сделать 8-разрядной регистровой с одним аккумулятором. Я думаю, что это упростит вычисления на микроконтроллере и сильно уменьшит размер занимаемой памяти по сравнению со стековой ВМ.

Так же хотелось бы услышать соображения по поводу распараллеливания процессов

SWG
Спасибо за ответ. На делфи и намахивал :)
А работать я стал именно над паскалем, так как он не очень популярен в среде микроконтроллеров. Вот разве что от микроэлектроники компилятор более-менее, но то что они сделали с механизмом библиотек для меня не понятно.. И к тому же оптимизатор там не очень - код сжирает кучу памяти. Были у них и другие недостатки, уже не вспомню. Сделать лучше чем они вполне реально. Даже одному, имхо, главное что бы желание было. Долго, правда.. :)

Я MikroPascal for PIC начинал 2 года назад с версии 8.0.0.1, сравнивал с компиляторами, в основном С, других фирм и был приятно поражен размерами кода. В позапрошлом году я приводил результаты. Просто вы наверное пробовали совсем старые версии...

Да, версия была довольно старая.. но это что касается оптимизации. В более поздних версиях у них все равно остался сишный подход к библиотекам. Правда, как обстоят дела сейчас я не знаю.

В каком смысле? И что именно не нравится?

А что я уже скелетик набросал. Сегодня наверное первый прототип выложу на обсуждение.

Архитектуру я закладываю такую:
8ми разрядная, с жесткой привязкой по функционалу к железу. Т.е. это не универсальная ВМ которую можно куда угодно воткнуть, а скорей концепция и ВМ придется писать под каждую железку заново, с учетом ее функционала.

Коды команд 8разрядов+операнды (любое число). Есть несколько десятков (максимум 255) РОН с которыми можно обращаться по усмотрению. Сами команды очень похожи на ассемблерные. Т.е. по сути я делаю надассемблер, управляющий уже не процессорным ядром, а устройством.

Ну вот. Тягайте проект:
http://easyelectronics.ru/files/Robot/WM-GCC-RTOS.ZIP

Пока самый мизер. Потому как обкатал просто технологию. Еще все сыро и в зачатках, но идея будет уже ясна.

в файле VM_PROG.h находится собственно код программы для VM

вот такого вида:


Сам язык это просто обвязаные макросами номера по таблице смещений на функции ВМ.



Параметры идут после номера команды. Например, функция DELAY свою 16ти разрядную задержку загребает так:



VM_PC это виртуальный Programm counter. Массивом -- потому что планируется многозадачность и думаю будут еще паралельные ветви, но пока не допетрил как бы это красивей реализовать. (надо чтобы в диспетчер ВМ передавался номер треда, но где его хранить я ума не приложу пока. Думаю, что сделать надстройку над диспетчером ядра - добавить параметры, но может удастся сделать и красивей)

Это основной код виртуальной машины. Функция VM первоначально дергается диспетчером. Дальше ее вызывают функции VM, обеспечивая тем самым его непрерывное вращение, но пошагово. Кроме функции VM_OFF она просто обнуляет состояние VM и все, VM выключается осовобождая конвейер.

Я пока это дело на Pinboard гонял, там отладочных средств больше. Сейчас буду ставить на колеса.

SWG
> В каком смысле? И что именно не нравится?

То, что они не имеют своего пространства имен. Яркий пример - создать новый проект и попробовать объявить W: Byte где-нибудь. Были там и еще какие-то недостатки. Например, лично я привык, когда каждый модуль собирается в свой obj-файл.

DI HALT
Интересно получилось, молодец :) Жаль только что оно слишком жестко привязано к конечному устройству. Какие ты планируешь ввести команды ? Будет арифметика и пр ? Т.е. что бы код не просто заставлял машинку ехать вперед-назад, но еще и работал с ее устройствами, обрабатывая данные и на их основе принимал решения

Приведу свой вариант для этой же задачи, я пока придерживаюсь первоначального плана

Значит, задача:
FORWARD
1000 ms
STOP
1000 ms
BACK
2000 ms
STOP
OFF

Синтаксис решения подобной задачи (пока что отказался от списков []):



символьный байт-код:


компилированный байт-код:


Использование памяти RAM: 0 Байт
Использование памяти ROM: 72 Байт

Так.. пока только начал рассматривать систему команд. Эта пока что не очень оптимальная, но работать должна:)

Надо бы закончить проектирование своего "pinboard" и тоже приступить к экспериментам :))

Жетская привязка к устройству это обязательное условие. А иначе нахрена тогда вообще ВМ? Для того чтобы получить еще один (ненужный) абстрактный язык? Нет, у меня устройство цельное и ВМ это лишь для резкой компактизации управляющего алгоритма. Воможности его изменения на лету и прочие радости.

Ну.. дело твое :)
Лично я всегда стараюсь создать как можно более универсальный инструмент. Да и интереснее так

Тут ценой универсальности станет тяжеловесность и избыточность. В условиях жесткой экономии ресурсов МК это критично.

Я поэтому в программе того же ходового контроллера отделил дешифрацию команд от исполнения их. Дешифратор только ставит флажки в слове состояния, и заносит параметры в соответствующие переменные, а далее уже модули управления периферией просматривают свои флаги и реализуют соответствующие действия. Например, модуль управления ШИМ отслеживает свои флаги и переменные и меняет коэффициенты ШИМ левого и правого двигателя, модуль двигателей включает, выключает и реверсирует правый и левый двигатели и отслеживает заданное время их работы (когда поставлю наконец датчики одометров - будет отслеживать путь), модуль управления АЦП замеряет напряжение батареи по запросу или по таймеру, ставит на выдачу в канал, и блокирует работу двигателей при разряде батарей. Модуль передачи следит, нет ли сообщений для передачи, при их наличии - ждет завершения приема очередной команды (если он происходит), и начинает передавать, заблокировав на время передачи приемник. Модуль приема при отсутствии своей передачи следит за приемом с канала, ожидая признака передачи команды, и принимает ее, блокируя соостветствующим флажком начало своей передачи. Закончив прием очередной команды, выставляет соответствующий флаг, сообщая об этом дешифратору команд. Модуль одометров в это время следит за пройденным каждым колесом путем, а модуль обмена с контроллером бамперов следит за появлением препятствий и сообщает о них. Модуль управления пищалки, получив свой флажок, включает звук, отсчитывает заданное время, и выключает его. Ну и так далее.
Все работает практически параллельно (время прогона главного цикла 250-260мкс).
При желании легко добавить новые команды. Например, сначала у меня повороты налево и направо реализовались вращением обоих колес в разные стороны. Ось вращения проходила посередине между колес. Позже я добавил еше по паре команд поворота в каждую сторону, реализуемые вращением только одного колеса при заторможенном другом. При этом поворот, например, налево можно реализовать вращением левого колеса назад или правого вперед. Ось вращения в этом случае проходит через неподвижное колесо, а центр робота перемещается по дуге назад или вперед одновременно с поворотом. Это дает большую подвижность при огибании препятствий. В дешифраторе добавилось 4 команды с обработчиками по 6 строк каждая, исполнительный же уровень остался без изменений.

Ну у меня тоже идет наброс на конвеер, т.е. вначале дешифрация и обработка, а выполнение в порядке очереди.

У тебя же, как понимаю, как таковой программы из команд в памяти нет (пока нет?), а сами команды будут поступать извне, от стационарного компа?

Это у меня оставлено для центрального контроллера. Там будет и очередь команд, и раскладка заданий от компа на команды нижнего уровня, и трансляция команд нижнего уровня контроллерам напрямую. За неимением центрального, мне приходится использовать пока вместо него ходовой, подавая ему команды нижнего уровня непосредственно с виртуального пульта в компе, который создавался в основном как раз для отладочных целей. Естественно, мне пока нет смысла перегружать ходовой контроллер ненужными в дальнейшем ему функциями, а нужные ему команды он получает пока через USART с радиоканала, потом будет по I2C, SPI, или RS485 получать их же от центрального, практически без переделки. Просто модуль связи в программе изменится. Правда, может, на первое время к нему башню подцеплю, по SPI, пока центральный не появится. Другой вариант - отлаживать контроллер поворотной платформы (башни) автономно, через свой собственный RS232, через шнурок или по тому же радиоканалу (команды разных контроллеров перекрываться не будут, 255 команд на все хватит).
Когда же будет готов центральный контроллер, там будет несколько вариантов:

1. Прямая трансляция команд нижнего уровня подчиненным контроллерам.

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

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

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

Вот примерно такой расклад. Пока топчусь на нижнем уровне. Думаю над башней, попутно вылизываю то, что есть. Например, сегодня переписал обмен ходового контроллера с бамперами с самопального последовательного протокола на стандартный Паскалевский SPI. Завтра распаяю шнурок для SPI и проверю, если не лень будет. Будет все нормально - возможно, весь межконтроллерный обмен переведу на SPI. Проводов будет больше, зато скорость выше, чем I2C, а устройств у меня не так много будет. Что - то не нравятся мне на I2C заморочки с ведомым. Вроде все аппаратно поддержано, а все равно надо контролировать каждый шаг. Ну его. Проще по SPI отдельной линией выбрать нужное устройство, сбросить ему в буфер что нужно, или считать из него, ведомый же будет отвлекаться только по прерыванию после каждого байта. Это мне больше нравится, да и скорость выше. Думаю между ведущим и ведомым устройствами кинуть по 2 линии (кроме стандартных SDO, SDI, SCK): 1 - аналог /SS, другая - готовность ведомого, она же - запрос от него на обслуживание, если надо. Всего получится по 5 проводов у каждого ведомого, из них 3 - (SDO, SDI, SCK) - общие для всех. Скорость 1 Мбит (максимум 4 при 16мгц, но, думаю, 1 за глаза). Для пересылки 2 байт со всеми дополнительными наворотами, задержками и проверками, думаю микросекунд 30-40 за глаза. Обкатаю завтра такой вариант на бамперах, а там видно будет.

А зачем вы тут писали интерпретаторы под систему команд, если есть такие штуки, как CPLD? Или даже проще - можно на ББ компилировать программу на асме AVR, и заливать ее в контроллер on-the-fly?

Это не совсем то. Речь идет о скрипт-коде определяющем поведение системы целиком, а не работы ее МК.

Я, конечно, извиняюсь, но чем forth не устраивает?

1. Философией FORTH. (все через задницу, что непривычно).
2. Необходимостью иметь большой стек (для PIC отпадает сразу!).
3. Когда-то пробовал, не понравился.
4. Есть более удобные языки.
Кроме того, смотри ответ постом выше. Речь не о языке программирования, а о наборе команд управления роботом.