Прикручиваем скриптовый движок к STM32

С STM32 я начал разбираться совсем недавно и они меня сразу же «зацепили» — эдакая «любовь с первого взгляда» получилась. На данный момент, по долгу службы я разрабатываю на STM32F103 устройство, попутно изучая семейство и прикручивая разные штуки. Совмещаю приятное, так сказать, с полезным :)
И вот, встала задача прикрутить скриптовый движок. Если по fatfs, RTOS, USB и эзернету информации полным-полно, то со скриптами я встрял — найти ничегошеньки толком не удалось :( Поэтому, волевым решением я начал кабанчиком протаривать эту стезю.

Немного отвлекусь, ведь многие спросят: «Зачем тебе вообще понадобился скриптовый движок?». Я расскажу зачем.
Представьте себе контроллер, допустим, пропусконй системы. Он а) читает карточки/ключи/пальцы/мысли/прочее, б) тем или иным образом узнает можно ли пропускать, в) открывает двери/ворота/турникеты/шлагбаумы/шлюзы/силовые поля/и т.д. и г) фиксирует событие.
Это в общем и целом. Теперь проблема: если пункты б) и г) реализуются в той или иной железке как удобно разработчику системы (всего остального софта) и тут каждый выбирает свой воздушный коридор творческого полета, то в пунктах а) и особенно в) есть загвоздка. Мы же хотим сделать универсальный контроллер, а всех этих ключей и дверей великое множество и все работают совершенно по разному. Вот и приходится современным установщикам подбирать и шлюзы под контроллер, контроллер под турникет и под все это находить совместимые считыватели. А то и вообще строить немыслимые «системы сопряжения» на всяких рэле (и такое я видел!).
Можно, конечно, взять и закодировать логику работы входов и выходов под разные варианты, но трудно охватить их все. Да и не нужно: на помощь придут скрипты!
Фактически, все, что делает система — отдает команду, скажем, «выполнить функцию ПропуститьНаВход()» скриптовому движку и получает результат: прошел или таймаут. А все входы и выходы дергает уже сам скрипт, в котором можно реализовать практически неограниченный функционал и любую конфигурацию этих самых ключей и дверей. Хоть тройной шлюз с биообработкой и четыремя степенями защиты. Вот тут уж рай для установщика! А если свое не нужно, то можно всегда выбрать что-то готовое из комплекта поставки :)

Итак, мне необходим был движок простой, занимающий мало памятей и шустро работающий, при этом не обделенный функционалом и, желательно, синтаксически совместимый с сями. Все, что я нарыл в сети — пара совсем простых бейсик-подобных интерпретаторов, eLua и PyMite. Бейсики отпали сразу из-за своей ограниченности, а Луа и Питон, как выяснилось после их изучения, достаточно крупные и представляют собой скорее среду выполнения, расчитаную на то, что вся программа будет работать на них. Но мне был нужен прикладной движок, а не целая жырная среда. Тут то я и пригорюнился, начал подумывать о адаптировании PyMite, как самого нежырного. Но волей случая набрел на еще одно решение под названием Pawn, которое отвечало всем моим требованиям и сразу же мне приглянулось. О нем то и пойдет речь.

Pawn обладает следующим рядом основных фишек:
  • простой язык, синтаксически совместимый с сями
  • компилятор на стороне хоста, который делает всю «грязную» работу и абстрактная машина (виртуалка), которая выполняет готовый байткод уже в камне
  • абстрактная машина регистровая, быстрая и компактная; написана на асме
  • поддерживается механизм оверлэев, который подгружает в заранее выделенный небольшой объем оперативки только нужный на данный момент кусок всего скрипта и выполняет его, что позволяет крутить здоровенные как язь скрипты, используя очень мало оперативки
  • на уровне языка поддерживает реализацию конечных автоматов, что очень удобно, особенно если нужно управлять какой-то механикой
  • очень широко настраивается при сборке всякими дефайнами; при должном изучении документации позволяет вырезать все ненужное, получив на выходе неприлично малые значения откушанных памятей


Это основное. В остальном, есть еще куча разных плюшек, от макрокоманд, которые позволяют увеличить скорость выполнения скриптов чуть ли не до трети скорости выполнения нативного кода до дебаг-хуков, используя которые можно устроить отладку скрипта прямо в таргете. Все это очень хорошо описано в двух основных мануалах, которые легко написаны и хорошо усваиваются: Language Guide и Implementer's Guide.

Основная задача, которую мне пришлось решить, чтобы запустить свой первый скрипт — портировать все это дело под STM32 и IAR, собрать рабочую конфигурацию, убрав все лишнее и поправить несколько багов, с которыми все это нормально не работало. А осложнялось это все тем, что ничего готового я в сети на эту тему не нашел: вот нате код и мануалы, в которых вопрос низкоуровневого портирования не затронут, и делай что хочешь.

Расскажу обо все по порядку.

Сначала я почитал внимательно доки и сделал выводы о том, какие же конкретно исходники мне будут нужны. Из всего многообразия, что было в дистрибутиве, получилось всего 2, так как от использования комплектных библиотек я отказался:
  • amx.c / amx.h (собственно, сам движок)
  • amxexec.s (ядро виртуальной машины на асме)
  • osdefs.h (дополнительные дефайны)


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

После этого, повникав в документацию и примеры, придумал для себя структуру своей сборки в целом и допилил еще несколько исходников:
  • pawn.c / pawn.h (то, что будет подключаться к основной программе; тут реализован функционал по загрузке и выполнению скриптов, вызывая функции из amx.c)
  • amxfuncs.c / amxfuncs.h (тут будут размещаться библиотечные функции, которыми будет пользоваться скрипт; пока забит тестовым мусором)
  • amxconf.h (вся конфигурация движка для удобства собрана здесь)


Затем я взялся за компилятор. Из коробки он почему-то отказывался компилировать скрипты с поддержкой оверлэев. После изучения исходников оказалось, что есть баг: перепутаны строковые названия оверлэйных опкодов. Баг был поправлен + я понаменял еще много всего по мелочи, «причесав» немного компилятор (поправил генерацию .asm и .lst, обдефайнил и отключил ненужный функционал типа генератора документации, keeloq и т.д.).
После этого все встало на свои места и стало работать нормально.

Ну и, конечно же, хотелось уже проверить работу всего этого. Я написал, если это можно так назвать, самый простой скрипт: он просто возвращает определенное значение, отличное от нуля:

// Test script

main() {
  return 12;
}


Далее, в свой main.c добавил вот такой код (предполагается, что запилен fatfs от мистера Чана и скрипты хранятся на каком-то носителе):

#include "pawn.h"

int main() {

  FATFS Fatfs;
  
  ... // here you need to do a platform initialization

  //Mount filesystem
  f_mount(0, &Fatfs);
  
  // Execute test script
  PawnExec("TEST.AMX");
  
  // Endless loop
  while(1) {

  }

}


И все замечательно заработало. Скрипт выполнился без ошибок и дебаггером я посмотрел, что он действительно вернул число «12».

Теперь движок готов к употреблению и допиливанию под реальные нужды! Возможностей у него действительно куча, так что читайте вышеобозначенную документацию (тем более, что она очень хорошо написана).

Во вложении прикрепил свою сборку движка и компилятора. Пользуйтесь наздоровье!

З.Ы. Это моя первая статья здесь, так что не ругайте сильно, если получилось что-то не так, как надо :)
Файлы в топике: Pawn_stm32.zip, Pawn_compiler.zip

Комментарии (184)

RSS свернуть / развернуть
Блин. Файлы не прикрепились. И прикрепить их теперь нельзя :(
В общем, вот:
Pawn_stm32.zip
Pawn_compiler.zip
0
Что значит нельзя? архивы, к тому же мелкие — можно же.

P.S.: свои статьи можно редактировать, комменты — нет.
0
Пробовал редактировать. Говорит, что к уже существующим статьям нельзя прикреплять файлы.
0
Понял. Надо было просто перезалить, а не прикреплять. Поправил, теперь буду знать, спасибо.
0
Вы как думаете если вместо свитча на 125 с лишним case'ов.
сделать массив с указателями на функции я посмотрел что кеил в листинг асма вывел. один большой кейс.
Думаю займусь как до оптимизации дойдет. Странно почем разработчики это не сделали.
0
Ассемблерую машину, не?
0
сразу что-то не пошло. толи синтаксис асма другой много ошибок показал. а там тоже вроде кейсы одни.
0
Синтаксис другой, кейсов там никаких нет.
0
как подопрет буд править.
0
синтаксис как раз Армовский только компиляция неверно проходит. если в иаровком можно подключить сишный инклуд с всеми дефайнами то в армовском асемблере походу это не прокатывает покарйней мере я этого не нашел как сделать. И поначалу с успешкной компиляции улетал в хардфаулт. пока не посмотрел на чем он вылетает выполнение.\
будет задача оптимизировать займусь этим.
0
т.е. надо добавит дефайны в асм для условной компиляции.
0
«Армовский» — это какой? Если gcc, то для обработки сишных девайнов надо указать файлу расширение .S, а не .s.
0
MDK-ARM
0
Не поймы чем Lua так неподошла. Да «довольно крупная» для описанной задачи дергания релюшки, но позволяет и себя встроить и сама вызывает обычный код. Это так, как поклонник Lua возмущаюсь.
Более непонятно чем не устроили «бейсик-подобные языки»? На мой взгляд это куда лучшее решение. Простота синтаксиса куда больший плюс, и «ограниченность языка» в таких проектах куда важнее. Зачем нужен скриптовый язык то? Применение «излишне сложного» синтаксиса Си не оправдано на мой взгляд. Да, он понятен программистам, но он вовершенно чужд пользователям/настройщикам. Куда правильнее применить синтаксис паскаля или бейсик-интерпретатор.

P.S.: За ссылки спасибо, почитаем. Только сразу замечу один недостаток: там вс ё по англички, и далеко не все сообщество умеет читать. Так что було бы не лишним написать русскоязычный обзор возможностей языка, что бы народ имел представление, стоит ли им тратить свое время на изучение кучи неясной документации. Без такого обзора найболее популярным будет ответ «нет».
-1
Луа не подошла тем, что она не просто «довольно крупная», а скорее «здоровенная как йааааааазь». Т.е. запилил Луу — забыл про все остальное. Я тоже ей поклоняюсь, в какой-то степени, но, как гогорится, «Кесарю — кесарево...».

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

О пользователях речи не идет. Что касательно установщиков, тут уж извините. Во всех более-менее нормальных конторах, с которыми мне приходилось общаться, есть свой программист, что снимает проблему. Ну а у кого нет — всегда можно заказать реализацию той или иной схемы у разработчика :) И это будет дешевле и проще, чем подбирать оборудование, ужиматься и крестить ежа с ужом.

По поводу англицкого это да. Просто уже он как второй родной, от того и не задумался об этом вообще. Обзор имеет смысл сделать, есть такой момент, но это надо собраться и отдельную статью запилить. Там много очень.
0
Ну да, для мк она тяжеловата, но для компа самое то :)
По бейсику недавно стала довольно популярная тема бейсик на авр. с гоуто и строками. только вроде все интерпретацией занимаются.
По поводу штатного программиста это правильно, но бывает и так где перестановка мебели является обязанностью программиста :)
я английский немного понимаю, в частности обзорно прочитать возможности могу, пусть и не все пойму. Только русский язык гораздо приятние :)
0
плюс, намного проще пробежать обзорную статью по очередному языку на русском просто чтобы понять нужно/интересно оно или нет, чем напрягаться чтением на инглише. он ведь второй «родной»…

вот я например, не загорелся даже просто гуглением про этот самый павн. не говоря уже про чтение англоязычных док…

так что, присоединяюсь просьбе обзорки про этот самый павн.
0
Насчет обзорки согласен.
Но тут еще такой момент. Если нужен прикладной язык с огромными возможностями, компактный до памяти и с очень быстрой регистровой виртуалкой, то альтернатив нет. Тут уж хочешь-не хочешь, а загуглить и почитать придется :)
0
Но тут еще такой момент. Пока не нужен. Но если будет хорошее описание возможностей, то бум знать, что есть такое. А если сильно понравится, то или подгоним задачу под использование, или вообще придумаем такую задачу. А там, мб, может случиться и так, что некоторое время спустя зададимся вопросом: «И как я раньше без такого счастья жил??!»

Так что, ждем обзор и описание. ;)
0
Присоединяюсь :)
0
Я добавил в закладки для чтения на досуге. Это будет явно не сейчас, но в будущем чем изобретать свой велосипед, подумаю о его применение, если конечно станет такой вопрос.
0
ох уж эти закладки на «потом почитаю»…
(наблюдая только в ИЕ 1418 линков в фаворитес… %) )
0
ну дык :) Хорошо что там папочки можно создавать, хоть немного структурированно: разное, different, хлам, junk, сохранено, отсортировать, save, save it, save different,... Красота! не то что раньше, всё в кучу.
За частую занесение в закладки означает, что посмотрю я его минимум через пару недель, когда вообще делать нефиг будет. Конечно бывают исключения. Нужное обычно в гугле быстрее найти. Но бывают случаи когда гугл всякие нетрадиционной ориентации личности засирают рекламой и пр. Тогда закладки спасают.
0
читать программу на паскале гораздо сложней не говоря на уже про бейсик. что легче искать сливающиеся с переменными begin then и пр, нежели { }. если конечно программа не 2 листа. приходилось писать на разных языках. и для себя сделал вывод что конструкции из си перекочевали в почти все современные языки(С++ ява шарп..) из-за того что код визуально удобно читаем по блокам.
+2
что легче искать сливающиеся с переменными begin then и пр, нежели { }
С подсветкой — begin/end, без — без разницы. Чтобы код хорошо читался по блокам, он должен быть аккуратно отформатирован — что в С, что в Паскале.
конструкции из си перекочевали в почти все современные языки(С++ ява шарп..) из-за того что код визуально удобно читаем по блокам
Не из-за этого, а из-за того, что они нацелены на вытеснение С и потому имеют С-подобный синтаксис. Жаба с шарпом вообще паскаль, замаскированный под си.
К тому же, в паскале затруднительно объявить тип вида «char *(*(**foo[][8])())[];», в котором нужно полчаса скобочки разбирать, что на читаемость паскаля влияет весьма положительно.
0
char *(*(**foo[][8])())[];
Посмотреть бы в глаза тому программисту, который захочет такое объявлять.
0
Поищи в Питере _YS_ 'а :)
0
Торжественно объявляю вас char *(*(**foo[][8])())[]; и char *(*(**bar[][8])())[];
А теперь скомпилируетесь!
0
Посмотреть в глаза легко: на собеседованиях почему-то любят тыкать носом в такое дерьмо.
0
С собоседования и есть. e_mc2 таким отфильтровывает любителей писать в стиле IOCCC.
0
Расшифруй IOCCC.
0
Ах да, www.ioccc.org
А зачем их отфильтровывать, они видны невооружённым глазом.
Ну а если таких людей нужно принять на работу, тогда да, необходим тест на понимание своего же кода или написанного собратом по разуму.
0
В свое время, когда хохмы ради решил походить по собеседованиям, посмотреть что-как, пару раз нарывался на такое. Удавалось провести следующего рода экзерсис: с покерфейсом объявлял, что раз тут у вас «вот так», то мы с вами не сработаемся видимо, после чего вставал, брал портфэль, сухо прощался и уходил, чем вызывал феерическое недоумение и зависон у собеседовавшего, который явно не ожидал вот такого поворота :)
+1
с покерфейсом объявлял, что раз тут у вас «вот так», то мы с вами не сработаемся
И правильно.
Раньше я пыхтел над подобными задачками на собеседованиях, а теперь я бы именно ушёл.
Только вот не хожу я теперь на собеседования. :-)
0
e_mc2 таким отфильтровывает любителей писать в стиле IOCCC.
Вы путаете, я таких вопросов на собеседовании не задаю. И считаю, что задавать такие вопросы – это очень плохая идея. Более того, я бы сам не ответил на вопрос об этом типе данных.
0
Да, действительно. Это я вот этот комментарий неправильно вспомнил)
0
Что касается eLua, то для него нужно довольно много флеша: голое ядро интерпретатора для lm3s занимает 121кб (и это версия без поддержки float в lua). Со всеми плюшками типа консоли по ethernet и romfs получается уже 243кб
0
В том и дело. И PyMite, хоть и покомпактнее, но на прикладной скриптовый движок совсем не тянет… По этому и получается, что альтернатив Pawn как-то и нету. По размеру кода по MAP файлу на вскидку получается где-то 4.5-5 кб со всеми возможностями языка, естественно. Но без библиотек функций, у меня все равно будут свои.
0
Мне в нем не особо нравится применение ассемблера. Уж сильно большая привязка получается и к камню и к среде разработки. «мечтой» бы было портируемая полностью Си версия, и возможность замены на оптимизированне асм функции.
0
Так он и является «мечтой» же. Он изначально, включая виртуальную машину, написан на Си и полностью портируем. Нужен только amx.c / amx.h и все.
А ассемблерное ядро — опция, уменьшающая размер и повышающая производительность. Но эту опцию можно и не использовать.
0
Ах вон оно чё. Прошу прощения, не понял сразу по прочтении статьи. Решил что асм файл обязательная составляющая.
Тогда да, можно присмотреться.
0
Ничего страшного. Я же об этом в статье не написал (руководствуясь тем, что затачивал все конкретно под CM4). А так да, хоть на АВР, хоть на ПИК. Только надо учесть, что сишная реализация эмулятора — один бааааальшой case, который не очень оптимально по скорости будет работать. Хотя, если использовать GCC, то там юзается какое-то расширение языка, которое позволяет увеличить скорость разбора этого кейса до вполне приемлемой.
0
Некоторые компиляторы способны кейс перевернуть в массив переходов, но не все. Да и много у них требований к таким свичам :(
0
Кстати, именно из-за асма он и отправлен «в долгий ящик»
0
Зря :)
0
Очень интересно, вами проделана большая работа!
Т.е. вы хотите сделать аналог ПЛК (например, что-то вроде такого www.owen.ru/catalog/81771770)? Только вместо программирования в среде CoDeSys, пользователь пишет на PAWN и заливает в контроллер?
Вот и приходится современным установщикам подбирать и шлюзы под контроллер, контроллер под турникет и под все это находить совместимые считыватели. А то и вообще строить немыслимые «системы сопряжения» на всяких рэле (и такое я видел!).
На каком уровне эти составные части не совместимы — на уровне интерфейсов (например у одного выход сухой контакт, а у другого вход 4-20 мА) или протоколов?
0
Не совсем аналог ПЛК, это именно контроллер СКУД. Но касательно управления исполнительными механизмами, возможно, определенная аналогия есть. Т.е., скажем так, «кусочек ПЛК» там будет :)
Обычно не совместимы и на уровне интерфейсов (банально разное количество управляющих сигналов, но, обычно, везде сухой контакт или ОК) и протоколов (т.е. где-то просто надо подать логический уровень, а где-то — импульс определенной длительности, например).
0
А как у него со скорость дела?
0
и насколько проблематично его прикрутить к кокосу без знания асма?
0
К кокосу, который, как я понимаю, использует GCC ассемблер, прикрутить можно. Надо только брать не мой файл amxexec_thumb2_iar.s, а из комплекта. Там уже есть amxexec_thumb2_gas.s, который будет собираться гну ассемблером.
0
С асмовым ядром скорость выполнения байткода может достигать 2-4 асмовые инструкции за одну байткодовую. Быстро.
0
А что такое сухой контакт?
0
беспотенциальный — контакт реле например
0
можно посмотреть в сторону Форта, будет более полноценное решение — компилятор + интерпретатор в одном флаконе, отладку/добавление своих функций можно делать через RS232/USB консоль
0
С одной стороны интерпретатор/компилятор в мк это хорошо, но с другой это лишние действия которые будут выполняться всегда/один раз и съедать достаточную долю ресурсов. если компилятор на стороне компа легкий (да плюс если ещё портируемый), то лучше всё де компилировать на компе а в устройство заливать. Ведь какая разница заливать в устройство новый скрипт по телнету текстом или бинарником с программы?
Понятно что текстом да прикольно, можно в блокноте поправить что надо на месте и залить обратно. Но! Это не решение — это костыль. Нормальная контора должна выезжать на объект подготовленными сотрудниками и оборудованием, а не «я тут с пляжа мимо шел, дай думаю к вам загляну».
Так что если есть легкий портируемый компилятор на машине — лучше он. И собирёт быстрее, и синтаксис можно задействовать более понятный пользователю а не машине, и с устройства снимается огромная куча требований по ресурсам.
0
тогда чем это отличается от обычного С/С++, тем более с таким синтаксисом? зачем лишняя прослойка? компилируйте на компе, прошивайте бутлоадером, что еще нужно?
-1
Да ничего не мешает так делать. Только вопрос зачем тогда вообще скрипты?
Чем скрипты хороши, так это именно ненужностью монструозных компиляторов. Что бы вместо зажигания зелёного светодиодика передать на комп строку — не надо ставить 500метровую студию, а достаточно запустить более легкую среду формирования скриптов.
Идет движение в сторону целеориентированного средства настройки. Пусть это и не нормальная программа настройки с дружественным пользовательским интерфейсом, но и не монструозное чудовище 95% функционала которого не используется. Мы получаем уже некий компромис между простота/гибкость.
0
при теперешних размерах дисков говорить о «монструозности» как то смешно. фильмы/игры на гигабайты качают чуть ли не каждый день и не кашляют.
размер голого avr-gcc и какого-нибудь компактного редактора типа np++/gedit/scite не больше 50..100М (пример — тот же Arduino)
0
К сведению, не у каждого есть широкий, безлимитный инет. Если он есть конкретно у вас, то не значит что есть и у остальных тоже. И это не глубинки, это и в столице тоже.
То что «они качают гигабайты фильмов» не оправдание вашему безделию и криворукости. Фильмы качают для себя, что бы получить удовольствие/отдохнуть. А такие «у всех резиновые диски» заставляют людей качать совершенно ненужные им сотни метров программ, ради того что бы устройство заработало хоть как-то.
0
А главное, подобные девайсы часто стоят в таких местах, что за GPRS-инетом придется лезть на ближайшую сосну.
0
О да. Командировки это отдельный разговор. Я то всё так, про случаи из своей жизни расказывал, а есть же ещё работа :)
0
А теперь представим переход от всё ещё гибкого к удобному пользователю:
Пишем пользовательскую программу с набором флажков и кнопочек. Пользователь тыкает что ему нужно, программа комбинирует зарание подготовленные куски скрипта, компилирует их и льет на устройство.
Да можно комбинировать и куски Си-кода, и вызывать обычный компилятор, но как вы собираетесь решить проблему лицензирования? Будите сами покупать кейл для каждого клиента, или заставите их покупать студию самостоятельно?
Хорошо, пускай это не кеил а гцц. Но скажите, на кой хрен пользователь куча хедеров, библиотек, какая-то документация ещё и прочая куча файлов? Да, обычный пользователь туда не полезет и не увидет всего этого говна. Но диск то оно засирает. Ладно гадьте у себя, не возражаю, но зачем вы гадите у других людей?
0
как пример посмотрите на Arduino.
при желании даже библиотеку на С/С++ можно допилить до простоты «кубиков», когда можно писать не сложнее чем для логики пром.контроллера
0
Можно и ардуину, я что ли против? Ардуина это хорошо.
Только вопрос, у вас есть ардуина на стм8? я бы с удовольствием скачал бы себе в качестве бесплатного компилятора Си. Так уж, извините, вышло, что на стм8 нет халявных С компиляторов, или хотя бы за разумную цену, что бы их (компиляторы) поставлять клиентам в составе своего продукта.
Да, «Не удачно выбрана платформа — архитектор дурак», кто ж с вами спорит.
0
Космик вроде бы халявный. Или у него тоже ограничения?
0
Он все равно закрытый, все они с ограничениями и требуют лицуху. IAR пожалуй самый сговорчивый из них)
Хотет GCC-STM8.
+1
Хотет GCC-STM8.
Что то здесь наклевывается: groups.google.com/group/llvm-dev/browse_thread/thread/284485491b53c95e?pli=1
(конечно если речь идет только о халявном компиляторе для stm8)
0
у космика лимит 32к персонал юз. всё остальное платное. райд 8 или 16к не помню, тоже персонал. Из халявного только ст-асм.
0
В прошлом году у резонанса было 32КБ, сейчас — 16.
0
а у космика была временная анлимка на 16кБ, а теперь только годовая 32кБ.
И не факт что оно так долго будет, может прикроют и эту халяву и будет только 30дней тестовая версия.
Вообщем надо гцц или другой халявный компилятор.
0
В случае скриптов компилятор может быть прямо в МК (и это на самом деле весьма желательно). Также скрипт может храниться на том же МК в виде исходного кода. Т.е. не потребуется ни компилятор, ни исходники для правки — только блокнот и нечто для связи с железкой (терминал обычно). После чего код сливается прямо с железки, правится и льется обратно.
0
то есть по любому для связи нужен компьютер с терминалом. ;) рекурсия аднака!
0
Только комп без терминала ты фиг найдешь. Даже в DOS можно написать type COM1 > c:\source.c.
0
в семёрке телнет урезали из коробки, надо доставлять :(
0
Дык не телнет нужен вроде, а гипертерминал.
Ну и командную строку с ее COM1-COM31 AFAIK никто не отменял даже в семерке.
0
Да не, я про то что телнет уже убрали, а там гляди и кмд запрячут и терминал.
0
Да не запрячут поди, они вон не так давно PowerShell запилили.
0
дак ему командная строка вроде и не нужна. с ярлыков запускаются.
0
Ну вообще-то PS — это и есть командная строка, только продвинутая.
0
значит я его с каким-то ява скриптом перепутал :)
0
Но заметьте как резко упали требования к каналу связи и ресурсам компьютера. Оказывается то что 300 метров нам качать не обязательно, устанавливать всё это дело 10 минут тоже, и главное не надо изучать 15метровые пдф-ки что бы узнать как открыть проект, как его собрать, и как при этом не угробить девайс.
Достаточно прочитать специализированную доку на пускай на 10 листов, и ты уже готов горы воротить. И при этом даже если что не так собрал, загрузчик то вот он, в железе и живой.
0
Я всё же не думаю что компилятор внутри мк правильно. Стационарник сможет провести оптимизации получше, если надо будет вдруг. Да и соберёт быстрее, ввиду своих широких ресурсов. А ждать 5 минут пока девайс скомпилирует исходники — как то не очень это. Запятую потерял и опять иди курить.
0
В скриптовых движках с оптимизацией обычно туго. Да и компилятся они быстро, это только семейство С слоупоки-рекордсмены (ну еще бы, в каждый файлик в 10-1000 строк они включают сотни килострок инклюдов и заново их компилируют, приходится костылять всякие PCH).
Так что с компиляцией он скорее всего справится в реалтайме, по мере схавывания сорца по уарту.
0
Вот и я говорю, что паслаль подобный синтаксис для скриптов будет лучше. и человеку и машине :)
0
Компилятор в МК — зло. Начнем хотя бы с того, что движок со всем функционалом у меня занимает 5к флеша, а компилятор этот же, если я его соберу под МК будет занимать 500к. Урезать его? А зачем, если он и так представляет собой одну исполняшку (и два с половиной файла к ней) весом мегабайт, которую можно собрать и поставлять хоть под дос. А еще у павна же есть легковесная (2 метра) визуальная среда Quincy, которую тоже можно допилить под нужное тебе решение (а можно и забить — и так работает) и хоть отлаживать через нее скрипт прямо на девайсе через уарт.
Вот и все. О каком компилировании внутри МК может вообще идти речь?
А такой вариант. Допустим, в каком-то приложении совершенно не нужно, что бы было видно исходник или даже как работает тот или иной скрипт. Его делает разработчик за деньги и все. И правит разработчик за деньги. Ну и накой тут компилирование в МК, если разраб может симметрично зашифровать байткод, а МК его симметрично будет расшифровывать. Что думаете, шифровать исходник, потом расшифровывать его и компилировать? Да бред же полный!
И еще варианты, и еще… Все в результате сводится к абсолютной ненужности и неудобности компилятора внутри МК, если есть портируемый легковесный и простой компилятор на хосте. А еще не забываем про эмулятор. Иногда очень удобно погонять что-то на модели, перед тем как запиливать в рабочую систему.
0
Все в результате сводится к абсолютной ненужности и неудобности компилятора внутри МК, если есть портируемый легковесный и простой компилятор на хосте.
Во первых, я уже озвучил варианты, где это полезно. Во вторых, практически все применения скриптов на больших системах ключевой характеристикой имеют отсутствие компилятора и компиляции (скрипт — принципиально интерпретируемый язык, даже если реально он компилируется в байткод для ускорения исполнения). И в третьих, не так давно здесь было обсуждение платформы умного дома, чей главный идеолог основой платформы видел именно возможность получения пригодного для работы с ним программного кода прямо из устройства.
Начнем хотя бы с того, что движок со всем функционалом у меня занимает 5к флеша, а компилятор этот же, если я его соберу под МК будет занимать 500к.
Этот — да. Другой может и влезть — существуют интерпретаторы С и васика, которые умещаются в AVR, а не то что в STM32.
Что думаете, шифровать исходник, потом расшифровывать его и компилировать? Да бред же полный!
И правда, это никому не нужно и вообще так не бывает.
0
Идея компилятора/интерпретатора в устройстве — правильная и очень нужная. Решил даже прикрутить экранчик и разъем ps/2 для клавы к платке с STM32F4 и отлаживать программы на самом устройстве. Но столкнулся с тем, что готовой среды для STM32 просто не нашел. Решил уже писать свою микро-IDE для микроконтроллера :)
Компилятор писать не возьмусь, но ассемблер, думаю, сделаю.
Зачем мне работа с МК без персоналки? Удобно. Ведь эмуляторы не всегда годятся. Бывает, нужно отточить алгоритм, и несколько ассемблерных строк десятки раз меняешь: правим код… компилим… заливаем… проверяем — надоедает. Хочу сделать так: исправил — нажал F9 — результат на экране.
0
исправил — нажал F9 — результат на экране

Так можно спокойно сделать и без компиляции внутри МК.
А если отлаживать? Отладчик тоже для МК собирать?
0
Ну не знаю. Я не вижу в этом смысла, пускай останется это моим большим «ИМХО».
Наверное не бывает ненужных решений — все только зависит от их применения. Но как по мне — компилятор и отладчик внутри МК это дюже излишне. Когда, блин, среда в МК занимает больше ресурсов чем сам скрипт, который будет там крутиться… Речь то у нас изначально идет о прикладном движке, а не о целой среде внутри МК, в конце концов.
Что же касается интерпретирующих движков — это очень медленно. К стати, хотелось бы увидеть ссылочку на интерпретируемый С с нормальными возможностями, который поместится в АВР, если не сложно. Долго искал в свое время и не нашел.
Да и если нужен компилятор и интерпретатор в одном флаконе, то, как тут уже кто-то высказывал мысль, может быть имеет смысл присмотреться к форту?
+1
Наверное не бывает ненужных решений — все только зависит от их применения.
Вот это — правильно.
Когда, блин, среда в МК занимает больше ресурсов чем сам скрипт, который будет там крутиться…
Все зависит от задачи. Если есть задача просто и с минимумом инструментария (в том числе программного) подкрутить систему под задачи на месте — это вполне оправданно, т.к. среда скрипта выполняет требуемую ТЗ задачу.
К стати, хотелось бы увидеть ссылочку на интерпретируемый С с нормальными возможностями, который поместится в АВР, если не сложно.
Не знаю насчет нормальности возможностей, но тут упоминался PicoC. ЕМНИП достаточные по Тьюрингу возможности он имеет.
Да и если нужен компилятор и интерпретатор в одном флаконе, то, как тут уже кто-то высказывал мысль, может быть имеет смысл присмотреться к форту?
Можно и к форту. А в некоторых случаях вполне годится и язык, который нечитаем человеком (т.е. не текстовый, а бинарный и требует специального редактора для себя) и выполняется прямо по исходнику — например, графические языки вроде FBD.
0
Спасибо, гляну.
0
Нормальные компиляторы в большинстве случаев разворачивать нужно и настраивать. Со скриптами проще, нужен только блокнот, опционально маленький и не требующий разворачивания компилятор.
+1
ну ардуино например не нужно «разворачивать» — достаточно просто распаковать архив.
0
Да, в удобстве разворачивания его плюс. Но получаемая среда по примитивности соревнуется с комплектом блокнот+компилер, а последние весят меньше и не требуют даже разархивации.
0
Vga, давай пойдем и ебанемся с крыши. Нахуй так жить.
-1
Мне очень нравится идея. Была бы еще возможность на ходу интерпретировать скрипт. Добавить к этому поддержку многозадачность, диспетчер задач, мьютексов и прочего счастья POSIX, реализовать API для доступа к перефирии и все, вот оно — счастье!
Конечно для разработок, где нет жестких требований к скорости.
Вот так и вижу — написал скрипт, закинул на microSD, вставил в платку, к UART подключился — дал команду на запуск скрипта, или добавил в автозапуск. Да и вообще по UART скрипты заливать.
Хотя можно и откомпилированные для виртуальной машины.
0
Чувствую, назревает тема Forth'a: потирая руки: :)
Где б выкроить неделю на эксперименты и пару дней на оформление…
0
Forth конешно хорошая идея. Но у него проблема — для многих он сложен для понимания. А все конверторы с разных языков генерируют рабочий код но в несколько раз больше чем бы придумал человек. Да и иногда невозможно понять как он работает :) Для этого надо писать специальный компилятор, например flash player и есть стековая машина как и JAVA.
0
Но у него проблема — для многих он сложен для понимания
проблема только в обратном порядке операндов, что решается несложным препроцессором, который будет разворачивать прямой в фортовский порядок
0
Ну не совсем так. Там не только порядок операндов. Там и логика работы безадресная. Для многих это тоже делает проблемы.
0
Я лично занимался forth машиной на AVR и сейчас играюсь с FPGA версией…
0
Добрый день! Тоже давно испытывал потребность в скриптовом движке со сверхмалыми требованиями ресурсов. Даже свой реализовал тоже с виртуальной машиной, разбирающей байткод.

Хотел разобраться с Pawn-ом. Скачал архив «pawn-4.0.4548.tgz». Сразу встретил некоторые трудности, которые преодолеть самостоятельно не смог. Помогите, пожалуйста, разобраться! Заранее, большое спасибо!

1) CMakeLists.txt файла в папке source нет, есть два отдельных в папках compiler и amx. А у вас так же?

2) По-умолчанию компилироваться в Release режиме не хочет, потому как в файле sc6.c структура «OPCODE» имеет «условный» вид:

typedef struct {
  cell opcode;
  char *name;
  int segment;          /* sIN_CSEG=parse in cseg, sIN_DSEG=parse in dseg */
  OPCODE_PROC func;
  #if !defined NDEBUG
    int opt_level;      /* optimization level for this instruction set */
  #endif
} OPCODE;


А там, где инициализируется массив, дело выглядит так:

static OPCODE opcodelist[] = {
  /* node for "invalid instruction" */
  {  0, NULL,          0,        noop,     0 },
  /* opcodes in alphapetically sorted order */
  { 44, "add",         sIN_CSEG, parm0,    1 },
  {100, "add.c",       sIN_CSEG, parm1,    2 },


Т. е. в принципе работать не может, так как, по-умолчанию NDEBUG в Release-ном варианте компиляции не определена. Соответственно, число полей структуры на одно меньше, чем в коде инициализации.

2) При попытке скомпилировать пример, например, «fib.p», у меня компилятор pawncc бесконечно долго крутится в цикле

while (!matchtoken('}')){     /* repeat until compound statement is closed */
    if (!freading){
      error(30,block_start);    /* compound block not closed at end of file */
      break;
    } else {
      if (count_stmt>0 && (lastst==tRETURN || lastst==tBREAK || lastst==tCONTINUE || lastst==tENDLESS))
        error(225);             /* unreachable code */
      statement(&indent,TRUE);  /* do a statement */
      count_stmt++;
    } /* if */
  } /* while */

Это место в файле sc1.c строки 5704 — 5714.

А у Вас как это всё работает? Может я дистрибутив не тот скачал?
0
по первому из двух вторых пунктов :)
Соответственно, число полей структуры на одно меньше, чем в коде инициализации.
Неинициализированные поля по дефолту пробьются нулями. Всё собирётся нормально.
0
Возможно, в GCC соберётся, в MSVC выдаётся «C2078: too many initializers». В GCC вечером проверю.
0
Ой. Прошу прощения. Я не посчитал количество параметров и полей и думал что там нехватает инициализаторов.
0
Сейчас попробовал отлаживать другие файлы, выдаёт: «Run-Time Check Failure #3 — The variable 'usage' is being used without being initialized», 0 в строке 4430 файла sc1.c.
0
Если переменную 'usage' при объявлении сделать равной 0, то компиляция файла 'ones.p' проходит, но с кучей ошибок. А 'fib.p' так навсегда и повисает в бесконечном цикле, который я упоминал выше.

Может какие-нибудь define-ы нужно поставить?
0
А скачать и построить компилятор из моей сборки, где я все поправил, слабо? :) Насчет повисания в бесконечном цикле — не знаю. Попробую дома собрать, как приеду.
0
Специально щяс залез домой, не поленился, радмином. У меня все нормально собирает. И уанс.п, и фиб.п… Качайте мой правленый вариант. Если не заработает — значит руки, увы :(
0
Ни на секунду не усомнился в непревзойдённости Ваших, darksimpson, правок! У меня вопрос, если в двух словах его выразить, сводится к

1) Неужели полнейший говнокод в дистрибутивах на оф.сайте лежит?

2) Версия 4.0.4538 собирается ли и работает ли у кого-нибудь без правок?

3) Если нет, то какая собирается?

В принципе, морально готов к варианту <да, нет, х.з.>. Давно пользуюсь Qt. Так там практически аналогичная ситуация наблюдается с дистрибутивами. Из git-а почти невозможно собрать — только из архива с сайта. И версия из архива никогда не совпадает с аналогичным тэгом в репозитории.

Версия продукта аж 4.0.4548, а вовсе не 0.0.1-alpha. Я Всегда верил в разумность человечества и думал, что для такого матёрого номера версии работать должно изначально. А любые кустарные правки призваны отрезать лишнее под конкретный проект. В данном случае оказалось, что правки таки нужны.

Собственно, убрал #define в определении OPCODE и ещё в одном месте — теперь работает. Но, блин, так ведь не должно быть с версией аж 4.0.4548!!! Этим вопросы и вызваны.
0
offtopic: чёта как-то послушал Вас и резко расхотел связываться с qt.
0
1) не полнейший, но косяки есть
2) х.з.
3) с правками собирается моя, насчет остального не в курсе, как-то чисто из спортивного интереса мне пофиг )

кроме дефайна там есть еще что поправить, иначе с оверлеями не будет работать, как минимум.
0
Я попробовал предыдущую версию 3.3.4097 и следующую 4.0.4641. Они работают вполне нормально, в том числе и в режиме с Overlay-ами «из коробки». Т.е. ничего править не нужно.

Однако, во всех версиях обнаружил странную вещь.

    b[0] = a[4]*a[8]-a[5]*a[7];
    new d = (a[4]*a[8]-a[5]*a[7] / 65536) * a[0];
    //new d = (b[0] / 65536) * a[0];
    d += (b[1] / 65536) * a[3];
    d += (b[2] / 65536) * a[6];
    d = d / 65536;
    return d;

В этом коде третья строка закомментирована. Если раскомментировать её, убрав вторую, то amx_Exec возвращает код ошибки AMX_ERR_BOUNDS. Исходя из первой строки видно, что это то же самое. Я так понимаю, глючит при обращении к нулевому элементу массива. Ещё эта ошибка появляется только в этой строчке. Во всех других местах кода с нулевым элементом работа всегда проходит нормально. Этот глюк проявляется во всех дистрибутивах, которые я попробовал.

Ещё обнаружил, что для тупо нахождения обратной матрицы 3х3 Pawn-у с максимальной оптимизацией требуется довольно много (примерно 3500 байт) кода и 184 байта памяти. Разделив код на отдельные функции удалось решить эту задачу в Overlay-ях, используя под Overlay-и 1024 байта, а на код 128 байт. Но это же элементарная задача, операций явно меньше, чем если 3500 поделить на размер ячейки. Или мне кажется?

Для STM32, видимо, это не проблема, на в AVR, скорее всего, не влезет. То есть, есть мнение, что сложные алгоритмы реализовать или очень трудно, или вообще не получится.
0
Исходя из первой строки видно, что это то же самое.
Ошибка.
Учитывайте порядок операций. С начала выполняется деление, затем вычитание. Расставляем скобки правильно. Вторая строка:
new d = ( ( a[4] * a[8] ) — ( ( a[5] * a[7] ) / 65536 ) ) * a[0];
В то время как третья получается:
new d = ( ( ( a[4] * a[8]) — ( a[5] * a[7] ) ) / 65536) * a[0];
0
4.0.4641? А где ее взять? Вот тут www.compuphase.com/pawn/pawnhistory.htm нет такой версии. Или лыжи не едут, или я идиот.
4.0.4548, которая там последняя, у меня с оверлеями отказывалась компилировать, вылетала во ассерту, пока я конкретно в определенных местах не поправил исходники компилятора.

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

Мне для нахождения обратной матрицы 3х3 тоже, скорее всего, нужно пару листов бумаги :) И еще вспомнить какой-нибудь из способов как это делать :) Но тут, на самом деле, по существу ничего подсказать не смогу — не занимался такими вещами.
0
Ещё, скриптовые языки, в основном, не предназначены для численных вычислений. «Вы бы ещё преобразование Фурье на них написали бы» :)
Если есть возможность, то соответствующие вычисления лучше проводить в нативном коде, отдавая в скрипт готовую функцию.
0
Это верно. Просто тут у человека видимо академический интерес.
0
Ошибка.
Учитывайте порядок операций. С начала выполняется деление, затем вычитание. Расставляем скобки правильно.

Ох, ну не придирайтесь к мелочам, не сумел правильно скопировать/вставить :) Смысл в том, что виртуальная машина считает (по крайней мере я там себе перевожу с английского фразу «index out of bounds»), что у массива нет индекса 0. При этом ассемблерные файлы для разных версий получаются существенно разные. Но в конкретно этом месте они все солидарны :)

4.0.4641? А где ее взять? Вот тут www.compuphase.com/pawn/pawnhistory.htm нет такой версии. Или лыжи не едут, или я идиот.
4.0.4548, которая там последняя, у меня с оверлеями отказывалась компилировать, вылетала во ассерту, пока я конкретно в определенных местах не поправил исходники компилятора.

Ну я ж Вам тут ср@л кирпичами (см. выше, где много истеричного текста), что нифига не работает версия 4.0.4548. И стал искать, какая работает. Следующая 4.0.4641: code.google.com/p/pawnscript/downloads/list и первая предыдущая (3.3.4097) работают. Другие не проверял. Но репозиторий на googlecode подозрительно маленький. Я его на всякий случай клонировал, но там далеко не всё…

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


Изучаю, но пока недоизучал. Думал уже, чтобы сэкономить время, другой скрипт взять. 100 лет как Lua использую. Думал, что мне, возможно, eLua подойдёт. Единственное, пока не нашёл, сколько ему flash-а надо и сколько RAM-а. Про PyMite чОтко написано, 40кБ-64кБ Flash и 4кБ RAM, что многовато.

Ещё, скриптовые языки, в основном, не предназначены для численных вычислений.

А вот это я не понЕл :) Почему не предназначены? Алгоритмический язык — он и есть алгоритмический язык.

Это верно. Просто тут у человека видимо академический интерес.
Интерес ни при чём :) Мне нужно оси магнетометра и акселерометра, абы как помещённых в девайс откалибровать и сделать сонаправленными с осями девайса. Для этого и обратная матрица. Хотел делать 3 замера и обратить матрицу показаний, чтобы получать результаты в системе координат, связанной с девайсом, а не датчиком. Оно без проблем работает, но сильно удивил размер кода.

Простите за много букв…
0
Кстати, darksimpson, вот Вы разбирались со скриптовыми движками для микроконтроллеров. PyMite или eLua могут исполнять код не из RAM/FLASH, а с внешнего устройства? Это бы тоже позволило большие по размеру скрипты выполнять.
0
Нашёл требования для eLua:

As a general rule, for a 32-bit CPU, we recommend at least 256k of Flash and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definitely fit in 128k of Flash and depending on your type of application, 32k of RAM might prove just fine. We have built eLua for targets with less than 10K RAM but you can't do much than blinking an LED with them. It really largely depends on your needs.

жЫрный, аки свинья! До неприличия просто!
0
Дадададад.
0
Не, XIP нет нигде, ой-вэй.
Единственное, в документации по павну встречал упоминания о возможности выполнения скрипта из ромконстанты. Там его только надо было специально собирать, чтоб не приходилось патчить при загрузке адреса. точно не помню, но вроде можно это провернуть.
0
Следующая 4.0.4641: code.google.com/p/pawnscript/downloads/list
Миль пардон.
Поизучаю на досуге. Интересны изменения относительно той, что на сайте.

Ещё, скриптовые языки, в основном, не предназначены для численных вычислений.
Скорее «не ориентированны». Но суть та же. Просто вашу калибровку гораздо правильнее было бы вынести в нативную функцию. Вряд ли в ее алгоритме придется что-то менять. А весь цимес скриптового языка, как прикладного — что-то быстро поменять в логике работы приложения, не пересобирая его. Да и это было бы всяко компактнее и быстрее, числа перемалывать.
+1
А весь цимес скриптового языка, как прикладного — что-то быстро поменять в логике работы приложения, не пересобирая его. Да и это было бы всяко компактнее и быстрее, числа перемалывать.

Да это само собой. Я ж для примера обращение матрицы написал. Ясен перец, шо для «боевого» варианта все вычисления на аппаратном уровне лучше делать. Я ведь всё это к тому, что

1) хотел предостеречь о том, что в реализации есть косяки.

2) Косяки эти переходят из версии в версию в неизменном виде.

3) Косяки касаются таких базовых понятий, как сложение/вычитание/умножение/обращение к элементам массива.

Я ещё у вас, darksimpson хотел уточнить, при загрузке header-а из файла, когда работа с overlay-ами, у этого header-а размер вычисляется как AMX_HEADER::cod.


  if ((hdr.flags & AMX_FLAG_OVERLAY) != 0) {
      // read the entire header
      fread(datablock, 1, hdr.cod, fp);
      // read the data section, put it behind the header in the block
      fseek(fp, hdr.dat, SEEK_SET);
      fread(datablock + hdr.cod, 1, hdr.hea - hdr.dat, fp);
      // initialize the overlay pool
      amx_poolinit(datablock + (hdr.stp - hdr.dat) + hdr.cod, OVLPOOLSIZE);


Нашёл ещё две неясности.

1) Вот этот самый hdr.cod для разных скриптов разный. Т.е. Это AMX_HEADER + ещё что-то. Размеры overlay pool и stack/heap задаются ключами компилятора -V и -S. А размер header-а, угадать заранее низя что ли? Резервировать с запасом?

2) Начальный указатель стека всегда чуть больше, чем размер -S, указанный при компиляции. Т.е. amx.stp больше, чем значение -S=… Поэтому приходится резервировать под stack/heap больше места, чем указывалось ключом -S. А у Вас тоже такие же проблемы? Или точно всегда соответствует?
0
2) Косяки эти переходят из версии в версию в неизменном виде.
А вы багрепорт написали? Думаю это поспособствует прекращению перехода косяков.
0
А вы багрепорт написали? Думаю это поспособствует прекращению перехода косяков.

Да, написал. Но не про конкретно эту ошибку. Когда разбирался с версией, выложенной на оф.сайте, написал отчётик на оф.форуме: www.compuphase.com/fluxbb/index.php.

После этого (я, конечно, не верю, что мой репорт был причиной) форум больше не открывается :) Уже несколько недель при попытке зайти пишет: «Error: Unable to fetch user information».

Так что про этот глюк написать уже никак.

Остаётся молиться, креститься, слушать радио «Радонеж» и в надежде на лучшее разбираться с внутренним ассемблером.
0
Да, начальный указатель стека всегда чуть больше, если мне не изменяет память.

А касательно размера хедера как угадать — там же запилены всякие таблицы нативных функций и еще всяческой фигни, которой так вот заранее для любого скрипта неизвестно сколько. Так что, с запасом резервировать.
0
Ох, ну не придирайтесь к мелочам, не сумел правильно скопировать/вставить :)
Придераться и не собирался. Интерпретировал ошибку AMX_ERR_BOUNDS как просто «вне границ». Про индекс в сокращении ни вижу ни символа, а у чисел тоже есть границы (INT_MIN, INT_MAX, ...). ситуация a-b < INT_MIN в то время как a-b/n > INT_MIN вполне считаю допустимой. Исходя из этого и написано замечание.
0
Интерпретировал ошибку AMX_ERR_BOUNDS как просто «вне границ»

Ну дык, я про индекс исходя из расшифровки этого кода ошибки ляпнул: «index out of bounds».
0
а можно тогда «ту самую версию» без «неправильного переписывания» увидеть?
0
Да, конечно. Вот полный скрипт:



native printi( v1, v2 = -1, v3 = -1 );
native print( const stri1[] );

invStep1( a[], b[] )
{
    b[0] = a[4]*a[8]-a[5]*a[7];
    b[1] = a[2]*a[7]-a[1]*a[8];
    b[2] = a[1]*a[5]-a[2]*a[4];
    b[3] = a[5]*a[6]-a[3]*a[8];
    b[4] = a[0]*a[8]-a[2]*a[6];
    b[5] = a[2]*a[3]-a[0]*a[5];
    b[6] = a[3]*a[7]-a[4]*a[6];
    b[7] = a[1]*a[6]-a[0]*a[7];
    b[8] = a[0]*a[4]-a[1]*a[3];
}

product( a[], b[], c[] )
{
    for ( new i=0; i<3; i++ )
    {
        for ( new j=0; j<3; j++ )
        {
            new ind = i + 3*j;
            //printi( ind );
            c[ ind ] = 0;
            for ( new k=0; k<3; k++ )
            {
                new ia = i + 3 * k;
                //printi( ia );
                new ib = k + 3 * j;
                //printi( ib );
                c[ ind ] = c[ ind ] + a[ ia ] * b[ ib ];
            }
            c[ ind ] /= 65536;
        }
    }
}

invDisc( a[], b[] )
{
    new d;
    d = (b[0] / 65536) * a[0];
    d = (b[0] / 65536) * a[0];
    d += (b[1] / 65536) * a[3];
    d += (b[2] / 65536) * a[6];
    d = d / 65536;
    return d;
}

invResult( d, b[] )
{
    for ( new i=0; i<9; i++ )
    {
        b[i] = b[i] / d;
    }
}

invert( a[], b[] )
{
    invStep1( a, b );
    new d = invDisc( a, b );
    invResult( d, b );
}

main()
{
    //new ttt = 1;
    //printi( ttt );
    new a[] = [ 123, 3,   1, 
                12,  543, 2, 
                2,   12,  123 ];
    new b[9];
    invert( a, b );
    printi( a[0], a[3], a[6] );
    printi( a[1], a[4], a[7] );
    printi( a[2], a[5], a[8] );
    printi( b[0], b[3], b[6] );
    printi( b[1], b[4], b[7] );
    printi( b[2], b[5], b[8] );
    new c[9];
    product( a, b, c );
    printi( c[0], c[3], c[6] );
    printi( c[1], c[4], c[7] );
    printi( c[2], c[5], c[8] );    
}


Ошибка возникает во второй строке функции invDisc( a[], b[] )

    d = (b[0] / 65536) * a[0];

А если b[0] заменить на значение, которое ей присваивается в функции invStep1( a[], b[] ) в первой строке, на


    b[0] = a[4]*a[8]-a[5]*a[7];


, то работает без ошибок.


    d = ( ( a[4] * a[8] - a[5] * a[7] ) / 65536 ) * a[0];
0
Не здоровая…
0
Или он делает визуализацию милкдроповских эффектов от винампа на МК :) Там то тоже всё на скриптах и предназначины они именно для расчётов.
0
Мда. Народу нечего делать. Народ плодит сущности.
Для таких целей существует прекрастный язык Forth.
Например на Sun-ах на нем реализован BIOS, в FreeBSD — загрузчик ядра.
0
Народ плодит сущности.
… по необходимости.
Для таких целей существует прекрастный язык Forth.
Угу. Только далеко не каждый имеет столь специфичный способ мышления, что бы им пользоваться.
0
Только далеко не каждый имеет столь специфичный способ мышления, что бы им пользоваться.
Ради интерактивной разработки без перепрошивки можно немного пожертвовать своим мышлением.

стеки и обратная польская нотация — в общем случае начинающий фортер думает также и о том, чтобы сделать в форте всё как у людей. Но через некоторое время начинает уже у людей всё делать как в форте .
Луркоморье о Forth
0
Ради интерактивной разработки без перепрошивки можно немного пожертвовать своим мышлением.
Нет, нельзя. Кроме того, непонятно зачем, ведь, по большому счету, в форте ничего особенного нет.
0
Нет, нельзя.
Согласен. А главное — накуя?
0
Пришлось закоментит //#define AMX_NO_MACRO_INSTR
иначе не находил OP_SYSREQ_N.
Но вообщем результат таков. На С версии виртуальной машине.
Выполняется код
main() {
new j=0;
for(new i = 0; i < 10000000; i++)
{
if( i>j)
{
j+=1000000;
power(1,1);

}
}
return power(2,4);
}
Выполняется порядка 25 секунд. те около 400000 итераций в секунду на stm32f407 168mhz.
В си версии непонятно почему вместо case не использовали таблицу функций для ускорения. у меня keil поэтому времени переписывать asm нет пока. думаю и так результат очень хорош.
0
поигрался с опциями оптимизации O2 — выполнение стало почти в 3 раза быстрей.
0
Тоже когда то такой хренью развлекался
akb77.com/g/stm32/uc/
0
  • avatar
  • x893
  • 13 апреля 2015, 12:02
Почему такой маленький интерес к этому проекту. полезная вещь особенно для настройки.
0
Мало того, что отличнейшая, так еще и, как показало время, мегафункциональная и стабильная.
0
Рад что вы тут)
В вверху писали что ошибка с нулевыми элементами массива происходит. или это не так?
0
Компилятор без ошибок можно взять тут: code.google.com/p/pawnscript/ (ванильный со свежими допилами) или тут: github.com/darksimpson/pawncc (мой, допилы из ванильного интегрируются + периодически допиливается мной + еще некоторые допилы от дргуих замечательных людей)
0
У тебя только компилятор? А движок допиленный не выкладываешь в гитхаб?
0
Там нечего допиливать же. Машина сама по себе простая достаточно.
Ну, по крайней мере, я не нарывался на какие-то баги, кроме тех, что допилил и выложил здесь еще тогда. Да и у разраба ванильная машина на гуглкоде сейчас без этих багов лежит, стало быть рабочая вполне, только нет эски под IAR.
0
Замечательные люди в смысле эти github.com/Zeex/pawn?
язык супер и легко встраиваемый. его вообще легко на контроллере подвесить, те. как снадежностью?
0
Да, частично я брал правки у них. У них отпочковалась какая-то совсем старая кодовая база, так что не все правки актуальны и применимы. И еще хороший человек из Австрии, который интегрирует павн в коммерческие продукты (по всей видимости) тоже накидал правок для неприятных косяков с массивами.
В ванильной версии сейчас живут практически все исправления, кроме, разве что, косяка с переменными аргументами (по-моему, ЕМНИП).
С надежностью хорошо. Нагрузочного тестирования не проводил и спецом не вешал, но там, где все идет своим чередом, оно работает хорошо и давно.
0
Если теоретизировать, руководствуясь его архитектурой и реализацией, убить хост-систему или как-то сильно ей навредить при грамотном встраивании машины выглядит не особо реальным. Подвесить и убить экземпляр самой машины, наверное, можно. Но это лечится простейшим супервизором в многозадачной/многомашинной среде.
0
Вот, к стати, гляньте для затравочки как чувак заморочился: github.com/PetteriAimonen/QuadPawn
Возможности практически безграничны! :)
0
) у меня как раз этот осцил лежит)
0
Ну вот эти фиксы да порт под иар и выложи.
Алсо, гуглокод закрывается, так что неизвестно, сколько там еще эта машина пролежит…
0
А надо ли? Вот у меня, например, выложен замечательный разжеванный проект для программирования и отладки кипресовских псоков4, коих я в свое время накупил просто кучу оргомную по 30 с лишним рублей за штуку. Теперь я могу насувать их в жопу слону и она, скорее всего, треснет. А вот настоящий программатор-отладчик для них совсем не дешевый (понятно, что можно и обычным жлинком, но тогда теряется возможность работать из их студии и, следовательно, вся прелесть подхода как такового). И что, думаете, это кому-нибудь нужно все? Да фиг там.
А кто ищет, тот всегда найдет. Я сейчас работаю над компилятором, поэтому он и выложен на гитхабе, скорее больше для моего удобства. Как-то вот так.
Хотя, может и выложу потом машину, ежели руки дойдут все оформить.
0
Что то скопировал файл полностью в флеш контроллера и поэтому адресу стартую виртуалкой код amx, сбой почему-то происходит.
Может она в эту область пишет что в процессе работы?
0
Насколько я помню (так как было это все давно и смотреть щяс лень), для работы по-типу XIP нужо как-то там что-то докручивать спецом. Читайте мануалы, там ЕМНИП эта тема освещалась.
0
Прочитал из флэша опять в RAM все работает. Наверно он эту память как-то изменяет(.
Получается что RAM надо много для выполнения программы. Заметил что исходник 1килобайт а байткод в среднем 2кило.
Наверно он часть в этой области под переменные использует. Ее как-то наверно разделить надо.
0
Нашел I: Running scripts from ROM......... 127)))
0
что-то никак, вылетает(
0
Вот у меня, например, выложен замечательный разжеванный проект для программирования и отладки кипресовских псоков4
Где? На гитхабе вижу, но на «разжевывание» это не похоже.
Не уверен какой, но какой-то проект на PSoC5 я уже видел, но его главный недостаток (для меня) — нужен PSoC5, а у меня только те самые четвертые.
А кто ищет, тот всегда найдет.
Я как-то пытался поискать одну не очень старую малопопулярную программку, которой некогда пользовался. И… Мне таки пришлось искать тот DVD, на который я ее записал и выуживать оттуда. В инете я ее не нашел. Родной сайт загнулся, остальные по большей части ссылались на него или тоже протухли.

Так что лучше копировать и дублировать, хоть где-то, да выживет.
0
Ну разжевано в том плане, что я перелопатил изначальные исходники настолько, что объем их сдулся, наверное, более чем в дьва раза, читаемость увеличилась раз в 10, а граница привязанности конкретно к псок5 расплылась настолько, что потратив пару вечеров это можно портировать на stm32 и получить «программатор-отладчик псоков 4-5 за 150 рублей на коленке». Чем я, собственно, и собираюсь заняться в обозримом будущем, когда руки снова доберутся до какого-нибудь проекта на псок4.
И я уверен, что даже в портированном виде это будет нахрен никому не нужно, поэтому во всех этих гитхабах, кроме как чисто для своего удобства, никакого смысла не вижу. Оно все для мэйнстрима и для попсы, а у нас тут больно специфические темы…
0
Вот это уже интереснее.
И я уверен, что даже в портированном виде это будет нахрен никому не нужно, поэтому во всех этих гитхабах, кроме как чисто для своего удобства, никакого смысла не вижу.
Нет, ты не прав.
0
Нет, ты не прав.
:)
0
кто-нибудь знает как с ROM(FLASH) запустить выполнение.
0
Стандартным путем, как описано в гайде. А дальше, если что-то не работает — отлаживайте. Усидчивость — самый верный друг. Или нет никакого пути.
0
хэлп, как стандартными средствами приостоновить выполнение программы?
самый простой способ что видится в виртуальной машине флаг опрашивать и уходить в halt:
0
Ну приходит в голову повесить дебаг хук, хотя его применение несколько ограничено. А вообще, все это муссируется в павн имплементорс гайде. РТФМ.
0
читал про дебаг хук, но вроде не подешёл.
через входной параметр retval передаю указатель на флаг и в главном цикле проверяю его содержимое.

/* start running */
  for ( ;; ) {
      if(*retval) { ///
          /// ABORT
	  op = OP_HALT;
      }	else {
	  op=_RCODE();
      }
      switch (GETOPCODE(op)) {....
0
Может просто убивать поток (если в RTOS) или уничтожать интерперетатор и возвращаться в заранее заданное место по прерыванию таймера (хотя это подход может оказаться нетривиальным при реализации)?
0
Сделал как в коде который привел. Все ок. А то раньше пересбрасывать все приходилось.
0
подключил работу с с float. подвисать стал.
не в курсе он преобразования автоматически производит float в int или надо всякие floor round использовать?
0
Надо всякие, вроде бы. Сам компилятор имеет поддрежку вещественных чисел, но реализация такой математики под каждую платформу должна прикручиваться разработчиком самостоятельно. Там надо сначала зафигачить прагму в скрипт, которой задать тип чисел — с плавающей или прибитой гвоздем запятой, а потом реализовать встроенные функции, описанные в соответствующем хедере. Готовые модули с реализацией для них уже есть, но как они будут работать под армом мне неизвестно. amxFixed например вообще с ассемблерными вставками под x86 был, если мне не изменяет память.
А так чо, отслеживать где виснет (зацикливается или вываливается в печальное прерывание) и бэктрейсить. Или еще как. Отлаживать, в общем :)
0
запустил все работает. у меня f4 там есть поддержка float
ед не нравится преобразование типов через floor round.
0
Когда-то давно в какой-то книге по Си я видел проект интерпретатора Little C. Возможно, что-то полезное оттуда можно извлечь.
0
Вспомнил: Герберт Шилдт «Полный справочник по Си»
0
0
лет 7 назад писал С++Like компилятор. Потратил месяцев 5 синтаксис построил и построил дерево разбора и дошел до генерации кода. Даже часть проверок объявления перегрузки функций доделал и пр. В итоге сдох. сложно одному на чистом энтузиазме. В итоге Интерпретатор немного корявый прикрутил. Попадался проект home.mweb.co.za/sd/sdonovan/underc.html даже с автоором списывался. Понравился с тем что он прям из DLL экпортировал классы). Автор написал мне что когда он наткнулся на CINT. Он свой забросил.
0
Забавные исходники куча дефайнов.
Не вкурсе как он без динамической памяти и где ханить хотябы указатели на таблицы библиотек… amx_Register(amx,float_Natives,-1)…
даже определений констант не вижу.
0
я так понял он использует ту память которую я ему передал прочитав файл.
0
Язь мелкая, сорная опистархозная рыба, если она там заводится в болшом количестве то нормальной рыбы в реке скорее всего уже не будет.
В современных контроллерах всё легко настраивается под задачу. Считыватели имеют 2 стандартных интерфейса (вегант26 и ТМ).
Гораздо сложнее подобрать связку: ключ-пропускная система конторы-бумажная бюрократия-систма скд.
Бывали случаи что после того как заказчик потребовал при расширении печатать пропуска на карточках (полноценно с фото и текстом) пришлось поменять все считыватели потому, что имеющиеся карточки не в один современный принтер не лезли.
А было и так что у одного человека 3 разных ключа от разных кучков одного здания. Просто сначала при постройке здания заложили редкую и дорогую систему (с глючным софтом в нагрузку). При одном из последующих расширений заказчик сказал что по 8-12к за контролеер. Платить не будет. Поставили автономный кусок от массового отечественного производителя. Естественно системы имеют разные и не совместимые базы данных. Заказчик сказал создать обезличеный комплект пропусков. Выдаст по второму кому надо. Так меньше счёт за пусконаладку. При третьем расширении потребовал ещё более дешовый контроллер и ключи. Он увидел такое у домофонщиков. Так на обьекте появилась зона с 3м комплектом обезличенных ключей.
А ещё там часто можно встретить человека с пропуском одна сторона которого наглухо закрашена чёрным маркером — повторная выдача пропуска (75р за новую карточку это дорого). И часто этот человек в системе скд перекликается с придыдущим хозяеном карточки. Зачастую сам пользователь карточки очень удевляется тому в какие места его неожиданно пускает. Отделу кадров лень забить гового сотрудника, они редактируют старого. А права доступа назначают в охране. Они часто даже не знают что пользователь карточки изменён. Да и права может менять один человек из всех (только у него мозгов хватает).

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

По поводу скриптов ставить надо тот движок, который в ходу. Чаще всего это луа или питон. И дело тут не в их навороченности а в распространённости. Только под такие движки есть удобные инструменты и квалифицированные программисты за недорого. И именно стоимость их работы будет определять стоимость конечного решения. Их доступность будет играть решающую роль при выборе данных железок в пректе. Никто не заложет то железо, которое потом не смогут настроить или быстро починить далеко от офиса разработчика.
Ещё пример: есть маршрутизаторы циско. Есть такие же по возможностям микротик. Но специалист по циске есть в каждом мухосранске (часто его можно дёрнуть подхалтурить с постоянной работы в крупной конторе) а вот найти специалиста по микротику проблема, дёшево найти такого тоже проблема.
В итоге микротик удел фанатов, применяют их редко и покупают тоже редко. Потому что нет смысла купить железку которую потом или не настроешь или каждый раз платитьбольшие деньги за настройку.
Вот как-то так и живём.
0
Если певое предложение было сарказмом, то защитываю. Если всерьез, то ознакомьтесь — www.youtube.com/watch?v=bFVh4OZRaU8

Вообще, вы далеко не первый, кто об этом всем говорит в таком ключе. И знаете, что для меня всегда было самым удивительным — наш опыт работы (а другой работы у нас, собственно, и нет) в этих областях говорит об обратном в большинстве приведенных вами или кем либо еще случаев. И железки наши со всеми этими «недостатками» уходят, да и те же микротики устанавливаем валом (насколько это слово можно применить к нашей не особо массовой, но нишевой деятельности).
Значит, исходя из ваших слов, получается, что нам все это время тупо везет :) Ну да пускай будет так ;)
+1
Фигня твой язь.


Вот это нормальная рыба. На фото Чавыча. Не самый большой экземпляр.

Есть там ещё Кета. Тоже вкусная.


Есть ещё Корюшка рыба не сильно крупная но очень вкусная.

На неё ходят в море.

Фотки как сам понимаешь не мои я их в основном копчёными видел :) Вкуснятина.

Как уйдёт от вас админ по микротикам долго будете нового искать или ждать пока разберётся тот кто не знает их.

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

Был случай в настройках комплекса фотофиксации накосячили на заводе. как раз та самая ошибка в скриптах.
Мы им не работает.
Они почему мы не можем подключится через встроенный модем?
А какая у вас симка?
МТС.
Отлично там есть только мегафон и ростелеком. Как поменять симку?
Никак там пломбы.

После этого туда поехал техник с завода. В сопровождении меня. 50км от Радужного. На улице -41. 3 часа работ на улице и с проводом в машину. Сколько всё это стоило даже посчитать сложно. Такая вот ошибочка.

Тут конечно другая ситуация но очень похоже.
+1
Вряд ли я уйду от себя сам :) Малое предприятие — такое малое…

По поводу отладки и поддержки вопрос решается двумя путями: а) нормальной разработкой и отладкой при выполнении заказа б) удаленным администрированием. Как и у всех. В таком случае остается только два типа возможных ощибок: 1. накосячили мы, и тогда едем и делаем без вопросов; 2. накосячил заказчик, но тогда, обычно, заказчики сами все понимают (т.к. им заранее весь расклад объясняется).
У знакомых был случай, когда надо было переконфигурировать систему где-то далеко и без возможности удаленного доступа, т.к. что-то там понаменяли по актуации, а сами не разобрались. Обошлись фотками и каляками ихнего техника с описанием что-как должно работать и отсылкой конфигурации взад. Все решается.

А вообще, мы тут развели оффтопик и, пожалуй, хватит.
0
не могу запустить и собрать. в один рабочий проект.
pawncc_d.exe просит MSVCR100D.DLL (с этим я справлюсь).
как собрать проект в камне.
в какой среде собирать.? подскажите.
а главное как этим пользоваться.?
как должен выглядить main.c?
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.