Средства и методы разработки

Так так, кажись fk0 ни разу не ошибся, сказав, что смерть текущему мироустройству в мире MCU прийдет из мира WEB. Кажись, я вкурил, отчего все так резко ломанулись делать embedded на разновидностях JS. Спасибо amusin --> За наводку.  http://caxapa.ru/420543.html
http://caxapa.ru/420315.html
Возьмем типовой современный топовый контроллер : 1M FLASH 128K SRAM. Казалось бы память дофига. Кода так точно. Но MCU = RT. Значит, вытесняющая RTOS. И эти 128к очень быстро кончатся. Да еще и куча проблем при ювелирном нарезании стека под задачи - если "байты" экономить. Ну ладно, MPU точно определит место, где у нас стек кончился - но толку ту? MMU есть только в PowerPC FLASH контроллерах, и хотя они весьма недороги, http://caxapa.ru/419165.html , это все же экзотика. А без MMU MPU полезен, по большому счету, только для отладки в поле. Однако, мы не одиноки в этом мире проблем. Стоит MCU заменить на web server, а RT задачи на запросы 100500 юзеров, как встанет та же проблема. Ну ладно, памяти на современных серваках дохрена, и кончится она не скоро, а вот ресурсы проца с переключением между 100500 тредами, кончатся гораздо быстрее памяти. jsconf.pdf на стр 9 и 10 хорошо показана разница в ресурсоемкости Apache и NGINX. Апач - 1 поток на один коннект. NGINX - 1 поток. scalable-networking.pdf - хорошо показано на примере масштабирования WEB серверов. JS зело стандартен в мире WEB программизма, ибо открытый межднародный стандарт. И, как утверждается, в силу этого типа очень переносим. Тут народ родил идею node.js: http://ru.wikipedia.org/wiki/Nodejs http://habrahabr.ru/post/182628/ http://nodejs.org/about/ * событийное управление * event loop * любые конструкции языка не блокируют управление Идею понесли на бигльбоард http://beagleboard …org/Support/BoneScript BoneScript is a node.js-based language specifically optimized for the Beagle family and featuring familiar Arduino function calls, exported to the browser JavaScript Timing Events http://www.w3schoo …s.com/js/js_timing.asp А вот пример проектика - робот https://sites.goog …e/beaglebonerobot/home "SnrDes_Final Presentation.pptx" - преза по проекту "FINAL-Report_Senior Design.docx" - описание, включая js код, вставленный в Word (бр....) Поробую еще раз описать идею своими словами. Пусть будет простая RTOS, которая управляет простыми RT процессами, суть обработчики прерываний и простые драйвера. Такое может написать каждый (С) Есть FLASH, пусть он будет большой и однотактовый (мечты :) ) И совсем скоро в main stream будет 256к ОЗУ. Процессор ОДНОВРЕМЕННО не будет работать с 256 к ОЗУ. Можно наплодить 100500 потоков, который будут курить бамбук в ожидании своих евентов или тайм слота шедулера, а можно поступить умнее. Разбиваем код на небольшие кусочки. И некая VM после каждого кусочка планирует - а что делать дальше. И идет туда, и делает этот кусочек, и все это без вытеснения контекста. У нас будут потери времени на это планирование, и это вроде как будет сильно медленее, чем plain C. Однако, если для кода нет ОЗУ - вопрос о скорости не актуален. А с учетом обмена с более медленной внешней памятью, особенно в варианте MCU, проигрыш по скорости будет далеко не так фатален. В варианте MCU у нас нет двухканального 64 бита каждый канал контроллера DRAM, мегабайтов кеша и проч. У нас есть, как правило, 16 бит DRAM шина и отсутствие кеша как класс. Что у нас есть на кристалле в топовых MCU? Правильно, там есть второй процессор :) LPC43xx, PowerPC за $12 http://caxapa.ru/419165.html - можно разлочить ядра и пустить их независимо. И тогда нам нужна всего одна мелочь - быстрый однотактовый механизм обмена сообщениями между ядрами - чтобы получилась песня: * одно ядро молотит VM * второе ядро суть RTOS с простыми задачами и тот самый "планировщик что делать дальше" + сборщик мусора - менеджер объектов :) VM ничего не зает про адреса в памяти, она, например, получает в стек ссылки на адреса объектов, который суть линейный кусок в памяти. А служебное ядро перед вызовом "куска кода" склеивает объект из кусочков в один кусок памяти. Счетчик ссылок и т.д. Кто-то скажет: "Классная идея! Давайте такую штуку на C++ сделаем!" Тут есть своим тонкости. Чтобы программирование VM доставляло удовольствие, в синтаксисе языка должна быть поддержана вся эта событийная ориентированность и проч. И С++, несмотря на весь свой "синтаксический сахар", все равно по удобству проиграет "заточенному" DSL (http://ru.wikipedi …0%B0%D0%BD%D0%B8%D1%8F) VM, несмотря на свои процессорные оверхеды, очень удобны тем, что позволяют простым способом (по сравнению с "расширением" GCC) сделать собственный язык программирования. Или диалект какого-то языка. Чем создатели node.js и asm.js (http://caxapa.ru/420383.html) воспользовались. Строго говоря, для embedded мира надо еще сделать еще некий "планировщик задач по памяти". Чтобы вызывать те куски кода|наборы кусков кода, для который скопилось больше всего данных в памяти, и которые имеют шанс сожрать эти данные и осовободить память :) Что касается конкретного языка - тут я в отношении JS и node.js настроен несколько пессимистично. http://comments.gm …avascript.nodejs/30200 как тут написано, REPL http://nodejs.org/api/repl.html занимает REPL is ~7.5MiB resident and ~45MiB virtual. With a light load of 5 http clients making back-to-back requests it uses 12MiB resident, 50MiB virtual. Для embedded крайне привлекательно было бы сделать DSL, который можно было бы компилить в некое подмножество C, который, в свою очередь, переводился бы в бинарник стандартным способом. В процессе этого преобразования можно было бы автоматически генерить код, который занимается всем этим "менеджментом виртуальной машины". Пусть в нашем "супер языке" будут сишные типы данных, массивы и "кросс-сегментные структуры". Последнее - это когда в одну структуру объединены переменные (ОЗУ) и константы (FLASH), синтаксис - как у обычной структуры. Каждый объект - это связанный список областей памяти. И под всю эту "работу с памятью" С код пусть генерится автоматически. В принципе, можно рассмотреть вариант автоматической генерации кода под кооперативную ОСь. Т.е. "супер-язык" не сильно отличается от С, но в нужном месте автоматически включаются нужные проверки и вызовы, чтобы не выносить моск программисту. Резюме: * с учетом одновременного роста скорости ядра и объема набортного FLASH при скромном росте набортной RAM идея VM, особенно если камень двухядерный, имеет смысл * в очередной раз убеждаемся, что если С|С++ - большой рынок в развитии микроконтроллерного дела, но тупое копирование подходов, которые применяются при С|C++ программизме в мире больших машин, далеко не всегла приносит пользу. Особенно это касается массового увлечения многопоточностью. * язык и виртуальную машину (или транслятор) для FLASH MCU придется разрабатывать с нуля. Слишком все другое в мире "больших машин" * наконец-то есть идея, как извлечь пользу из многоядерных контроллеров :)