dxp

Ну и сколько это байт оверхеда на фоне всего проекта? Сравнивайте весь проект (или хотя бы более-менее значимую часть), скомпиленные одним компиятором и другим. Переменным не обязательно быть подряд. Им достаточно быть в пределах досягаемости указателя - 64 байта. Для того, чтобы они были вместе, достаточно их объявить вместе и включить оптимизацию clustering variables, которая, afair, включена по умолчанию.

Это до тех пор, пока у Вас единственное обращение к однобайтовой переменной. Сделайте эту переменную интом, выигрыш не замедлит проявиться. Или, к примеру, если там не к одной переменной обращение, а к нескольким, лежащим в пределах досягаемости указателя (для этого их надо объявлять вместе). Или к структуре обращение. Словом, когда ситуация уходить от первого простейшего случая, результат меняется Не стОит так переживать из-за этой мелочи. Она погоду не делает совершенно. Наоборот, способность IAR'а приводить обращения к косвенным дает очень приличный выигрыш на деле. AVR-GCC имеет весьма неплохой кодогенератор, но он проигрывает IAR'у именно на этом моменте - AVR-GCC злоупотребляет lds/sts, из-за чего размер кода там получается больше. Не знаю, как сегодня обстоит дело, но некоторое время назад остальные компляторы - CodeVision, ImageCraft уступали по качеству кодогенерации обоим - и IAR'у, и AVR-GCC. Может сейчас что-то изменилось, но сомневаюсь. Сравнивать надо не на коде из трех строк, а на реальных проектах. Попробуйте, увидите, что IAR рулит. :)

В блоке initial, вестимо. reg [15:0] Array[262143:0]; initial for(i = 0; i <262144; i = i + 1) Array[i] = i;

Я не спец по VHDL, но, имхо, этот код неполный. На Верилоге про код: if(rst) begin ... // end else begin ... // end нельзя сказать, синхронный тут сброс или асинхронный. Все зависит от списка чувствительностей. Если там always @(posedge clk), то сброс будет синхронный, если always @(posedge clk, posedge rst), то сброс будет асинхронный. А код внутри один и тот же.

А как Вы его используете? Там ведь на ожидание можно встать только если мутекс захвачен другим процессом.

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

Что-то я в конце дня плохо соображаю... Можно поподробнее? <{POST_SNAPBACK}> Имелось в виду следующее: есть некая логика, которая служит для реализации требуемой функциональности. Сама логика, ессно, реализуется в LUT'ах. Чем она сложнее - больше сигналов входных - тем дленнее получаются цепочки - в одну LUT не влезло - начинает каскдировать, времяка ухудшается. Если туда же еще заводить сигнал начального сброса/преустановки, то это еще один вход, еще доп. "нагрузка". А ведь он используется-то только один раз при старте. Поэтому логично этот начальный сброс/предустановку завести на свободные ноги set/reset триггеров. Сегодня некоторые современные ПЛИС имеют триггеры с отдельными синхронными входами сброса/установки, но это уже отдельная история.

Я бы Вам рекомендовал пользоваться синхронным ВСЕМ (не только ресет). Даже в случаях когда это занимает больше места. Если весь модуль синхронен - невероятное благо, т.к. достаточно только одного констрейна. В противном случае прийдется затягивать все асинхронные пути, чтобы быть увереным в том что после PAR "родилось" то что надо. Асинхронный сброс я пользую только для инициализации автоматов, причем беру его от DLL (сигнал LOCK). <{POST_SNAPBACK}> Совершенно согласен. Поступаю аналогично - асинхронный сброс использую только для начальной установки - чтобы не нагружать этой функцией "боевую" логику.

А что если сделать небольшой подогрев? :) <{POST_SNAPBACK}> С этим понятно. Но это уже весьма альтернативные пути решения. :) Конструкция и потребление могут оказаться весьма неподходящими. Про вторые циклоны писали прямо в доке: Cyclone II PLLs are designed to operate in the commercial temperature range (0° to 85° C). The industrial junction temperature range specifications will be available upon completion of the PLL characterization across the industrial temperature range from -40 to 100° C. Т.е. чуваки работают и можно ожидать, что через некоторое время появятся и нормальные чипы с ФАПЧ, работающим во всем диапазоне. А пока приходится принимать вот такие полумеры.

У Стратикса то же самое.

А кто этим в Росси торгует?

Посоветуйте сабж. :) Исходные данные: чип - Cyclone, диапазон температур - индустриальный. Возникла потребность в сдвинутых по фазе клоках. Это можно сделать с помощью циклоновского встроенного ФАПЧ. Беда в том, что ФАПЧ этот неполноценен при температурах ниже -20 - имеет право не захватывать опорный клок, если тот ниже 200 МГц. Поэтому возникла необходимость во внешнем генераторе на означенную частоту. Собственно вопрос: посоветуйте доставабельный SMD генератор, работающий в индустриальном диапазоне температур (-40..+85), на частоту 200 МГц? Кто поставляет и т.д. Цена волнует почти в последнюю очередь, во всяком случае несколько баксов ничего не значат.

Что с живой - это понятно :) А через USBбластер это возможно? Последовательность действий такая же? <{POST_SNAPBACK}> Хм, ну пробовать не пробовал за неимением оного усббластера, но вообще-то сам СигналТап - вещь ортогональная бластеру. Она просто общается с микрухой через JTAG. Нужно только указать адаптер. Я указываю ByteBlasterMV, который у меня используется. Вам, очевидно, придется указать ваш девайс. Там, в частности, кнопа для этого есть в сигналтаповом окошке. Актив и Синплифай тут непричем. Это Вам надо в Квартусе запустить СигналТап, в нем задать, во-первых, клок для захвата (лучше всего системый клок), во-вторых, сигналы, которые хотите посмотреть. Очень похоже как в симуляторе квартусовском. После этого Квартус захочет перекомпилить проект - он добавит сам нужную логику, которая и будет захватывать сигналы для показа. Т.е. СигналТап - это встраиваемый в ПЛИС небольшой логический анализатор, имплементированный на свободной (не задействованной в проекте) логике. Т.е., например, Вы и сами можете для отладки какой-нить регистр поставить и выводить его на ножки свободные и смотреть. Только это неудобно и геморроя много. А тут за вас эту работу делает Квартус, который, во-первых, не ошибается, во-вторых, делает это быстрее, в-третьих, имеет специальный интерфейс для показа сграбленного. Только и всего. Я пользуюсь, временами очень помогает. Когда что-то не работает, можно сразу отследить ключевые точки и пойти по верному пути поиска. Хотя, конечно, не панацея это. Сначала нужно все на симуляторе отладить, а уже потом в железе смотреть, если что не работает. Это все так, спору нет. Только бывают ситуации, которые на симуляторе не отмоделируешь - нельзя ведь объять необъятное. :) Особенно подлые грабли возникают на взаимодействии модулей - по отдельности все отмоделировано, все проверено, все работает. Вместе тоже, вроде, все работает, как задумано. По времянкам тоже все ок. Заливаешь в микруху - и появляются "нюансы": в таком-то режиме, если сделать такое-то действие, появляется труднообъяснимый глюк. Бычишься, бычишься в текст, глаз замылен, не видит ничего криминального. Пытаешься смоделировать ситуацию на симуляторе, вроде работает - оно и в железе проявляется не каждый раз. А прогнать все на симуляторе тоже возможности нет. Вот тут СигналТап в самый раз! Вывел критичные места на монитор и контролируй. И тут оно отлавивается - где-то, например, флажок встает не так, как надо. А когда уже место более-менее локализовано, бороться уже несравненно проще. Т.ч. к месту очень полезная тулза.

Попробуйте! Особенно интересно будет посмотреть, как Вы на С будете реализовывать инкапсуляцию, наследование и, особенно, шаблоны. И главное, смысла никакого в этом нет. Реализация на С++ имеет недостаток в силу меньшего распростанения этого языка, но и дает одно из главных преимуществ - простоту и безопасность использования. Использование действительно очень простое, проще некуда - я знаю несколько человек, которые в ++ почти ничего не понимают, однако безо всяких проблем используют scmRTOS, освоив буквально за пару дней. Думаю, что ничего они не "прощелкали", а пошли на это сознательно. Лябрусс сразу сориентировался на 16 (и более) разядные процы с возможностью подключения внешней памяти (у него встречается недвусмысленное замечание о том, что на однокристаллках использование вытеснящей ОС очень затруднительно). Отсюда и количество задач до 64-х, отсюда и соответствующий механизм поиска активной задачи с наибольшим приоритетом, отсюда и таблица на 256 байт, объявленная как const - не жалко ему 256 байт, которые в Гарвардских процах размещаются в ОЗУ (хотя этого объема хватает для стеков двух-трех процессов). Потому что не ориентирована эта ОС на МК с малым количеством ОЗУ, и не ставилась никогда задача оптимизировать ОС под мелкие МК. Ну, если Вы так круты, что фактически переписали uCOS, то добавить в scmRTOS простой бинарный семафор Вам ничего не должно стОить! Ведь там работы-то на полчаса - взять за основу TEventFlag, изменить пару строчек внутри его функций-членов да прописать новый тип внутри пространства имен OS. Во всяком случае, уже на эту дискуссию Вы потратили времени несравенно больше. :) Э-э, пардон, а в uCOS что, не так, что-ли? Как Вы себе представляете переход из прерывания в другой процесс/задачу, если на входе не сохранили конекст текущей задачи? Есть стройное и элегантное решение, состоящее в том, чтобы иметь в МК отдельное софтовое прерывание, которое и будет переключать конктексты, а все остальные прерывания сделать обычными, где при необходимости взводятся сервисы и выставляется запрос на софтовое прерывание - при выходе из обычного прерывания вызывается софтовое, которое и производит переключение контекстов. Но ни в AVR, ни в MSP430 такого прерывания нет, можно использовать какое-нибудь свободное, но тут уже все это получается проектнозависимое - в одном проекте так, в другом эдак... Скажу по секрету, что такая возможность в настоящее время серьезно рассматривается и в одной из будущих версий scmRTOS этот механизм появится. Ага, особенно uCOS. Или embOS. Или Salvo. Или jacOS. :laugh: Для начала дайте четкое определение термину "Система". Потом термину "Операционная система". Потом сделаем выводы. Подумайте над такой вещью. Мерседес - это автомбиль? А Вольво? А Фольксваген-жук? А Тойота Королла? А Хаммер? А Зил-130? А Камаз? А БелАЗ? А Ока? А Ту-154 - самолет? А Боинг-747? А Су-27? А Антей? А Сесна? Или Сесна - это фанера с моторчиком? Мысль, думаю, ясна - объект относится к той или иной категории по функциональному назначению, минимально необходимому составу и способности выполнять основную функцию. Теперь о системах. Система - это совокупность разнокачественных объектов, подчиненных решению определенной задачи (или круга задач). Таким образом, в нашем контексте, система по минимуму - это ядро и набор сервисов. Без сервисов ядро - это ядро и не более. Т.е. тот самый Kernel. Само по себе оно достаточно бесполезно. И наличие дополнительных, качественно отличающихся от него объектов, органично с ним взаимодействующих, дополняет ядро до целостной сущности - до системы. А уж размер системы, ее насыщенность и обвешенность дополнительными фичами - это следущий вопрос. Все эти дополнительные фичи, идущие в составе ОС, должны иметь мотивацию, т.е. то, зачем они. Например, если некая ОС имеет в своем составе поддержку TCP/IP, то это указывает на то, что данная ОС ориентирована на телекоммуникационные приложения. Но сам по себе этот протокол к ОС отношение имеет весьма опосредованное и может вообще идти просто как библиотека (и это, имхо, правильный путь). Таким образом, любая OS, RTOS, Kernel и т.д. на деле являются именно системами и ничем иным. А конкретное название - это не более, чем маркетинговый ход, имеющий целью выделить свое поделие из общего количества аналогичных и/или подчеркнуть ключевую особенность - как в случае с uCOS, где сказано, что она The Real-Time Kernel, что понимай как: "У нас тут не хрен в сметане, а ядро реального времени!". :) Совершенно не так! Kernel там есть и представлен в виде class Kernel. А все вместе именно система, хоть и маленькая, можно сказать крошечная. Это не потом, а сразу. Только это не дописка, а нечто вроде расшифровки - дескать, ОС с ядром реального времени. P.S. Ответ пришлось разбить на три сообщения, потому что в одном большом не работает квотинг, а без него читабельность, имхо, неудовлетворительная. :)

А что, разве не понятно? Там ведь прямо сказано и не в одном месте, что ОС очень маленькая, что используются очень простые, можно сказать, тривиальные механизмы, что ориентировано и заточено все это под мелкие однокристалки с объемом ОЗУ от полкилобайта до двух. Неужели Вы это пропустили? Описание-то там совсем небольшое, страниц на 90 вместе с оглавлением, предметным указателем и приложениями. "Типовой API" - понятие непонятное. Для Вас типовой - это одно, для меня - другое. Реально есть работающий код и мне очень интересно посмотреть на ситуацию, где Вам действительно чего-то не хватит по функциональности, особенно в теперешей версии с шаблонными сервисами, где можно легко и безопасно создавать очереди сообщений произвольного типа. Ну давайте, покажите уже реальную ситуацию, где Вам не хватает имеющегося. А неужели непонятно?! Плохого то, что такой планировщик получится заметно сложнее имеющегося тривиального и быстрого, что добавит просто тормозов на переключених контекстов. При очень сомнительных преимуществах в конктесте мелких процов. Она никогда не станет конкурентом uCOS! Она: во-первых, ориентирована на другую нишу - uCOS туда не лезет; во-вторых, она не займет нишу, где расположилась uCOS, потому, что те, кто используют uCOS не будут переходить на новый, неизвестный им инстумент, если их устраивает имеющийся; в-третьих, несоизмеримо менее распространена и имеет порты только под два семейства однокристаллок. Учитывая некоммерческий характер распространения, она вряд ли получит интесивное развитие - ей занимется один человек и только время от времени, когда есть свободное от текущих проектов время, в то время как uCOS - коммерческий успешный проект, его авторы зарабатывают себе на жизнь развитием и распростанением uCOS Список можно продолжить, но этих основных причин более чем достаточно.

А к чему тогда рассуждения про академичность? Есть реальная задача, есть потребность в интрументе для ее решения, есть адекватный инструмент. Найдите другое, такое же по характеристикам и лишенное указанных Вами недостатков?! Очень интересно посмотреть. Основной вопрос - почему в scmRTOS нет простого бинарного семафора (что и тема отражает). А остальная дискуссия развернулась по поводу Ваших замечаний насчет состава, реализации, документации, кривизны архитектуры AVR, которые имеют, извините, не очень много общего с действительностью. Да, только спать придется недолго. На MSP430 при 5 МГц тактовой (не самая скорость, прямо скажем) проверка признака активности процесса занимает 1.2 мкс. 8-й процесс будет обслужен на 8* 1.2=9.6 мкс позже первого, самого приоритетного, 15-й - на 18 мкс. Учитывая, что низкоприоритетные процессы, мягко говоря, не требуют мгновенной реакции, то добавка в несколько микросекунд для них совершенно ничего не решает. А для приоритетных, которым надо побыстрее, все получаестя максимально шустро. Что и надо. Еще раз повторю, что данный тривиальный механизм тут канает только благодаря исходной ориентированности на малое количество процессов. В этом ключевая фишка. ??? А сколько бит должен быть EventFlag? Это бинарный семафор. Сколько событий в системе, нуждающихся в синхронизации, столько и флагов. Все логично. Что не так? Что с ними не так? За исключением отсутствия горячо любимого Вами простого бинарного семафора. Кстати, не приведете ли реальную задачу, где он реально нужен? Очень интересно рассмотреть ситуацию, которую нельзя обойти в scmRTOS за неимением оного семафора. Каких всех функций? Функций сервисов? Если Вы имеете в виду возвращаемый код ошибки в сервисах uCOS, то, имхо, это как раз слабое место этой ОС! Ведь это рантаймные проверки, и тут два принципиальных недостатка. Первое - это оврехед. Но это полбеды. Второе и главное - это то, что проверять/обрабатывать эти ошибки в ембеддед системе некому. Вот представьте, что функция pend вернула код ошибки - например, тип объекта не соответствует функции. Кто проверяет и обрабатывает код ошибки? Писать специальный код? Ну хорошо, написали. Что дальше? В лог его занести? Занесли. Что дальше? Программа-то от этого работоспособной не станет - все это годится только как средство отладки. Я специально спрашивал знакомых, кто пользуется uCOS, как они обходят эту ситуацию. Отвечают, что никак - не обрабатывают коды ошибок (только при отладке). Так не более ли правильно все, что можно проверить на этапе компиляции, проверить на этапе компияции. Возложить эту работу на компилятор - статическая проверка типов - одна из ключевых концепций С++ (да и С, в общем-то, тоже). И тогда ни оверхеда, ни ошибок, делающих программу неработоспособной. Что и реализовано в scmRTOS: все сервисные объекты - отдельные типы, их нельзя использовать неправильно (и пользователь имеет доступ только к интерфейсу, но не к представлению) в смысле случайной ошибки (понятно, что от преднамеренного взлома ни язык, ни компилятор не защитят, но этого и не требуется). Не понял, что имеется в виду. Что не так с таймаутами? Какие состояния? Если упомнинаете что-то, то уж пожалуйста объясните по-подробнее, что имеется в виду, чтобы не гадать. Ну, если запорожец ездит быстрее мерса, если пользоваться им проще и комфортнее, то да.

Internal error есть ошибка по определению, тут даже обсуждать нечего. Пошлите им багрепорт, они будут Вам благодарны. :) А Вам придется какой-то workaround временно применить. Если хотите, чтобы в следующей версии этого трапа не было, шлите репорт.

С живой микрухой, подключенной к компу через Байтбластер, например. Спрашивайте конкретнее?!

И в чем "не в пользу"? Кроме (пока) бОльшей распространенности cvs.

А что значит "по-честному"? В чем состоит "честность"? Весь этот учет нужен для реализации инверсии приоритетов. Может они где и нужны, но не на MSP430 и не на AVR. scmRTOS ориентирована на эти МК - и вообще на однокристальные МК, где мало ОЗУ. Не нужна там эта ИП - небесплатно она дается. Если uCOS претендует на толстые процы с толстыми задачами, где это надо, то пожалуйста, я не оспариваю необходимости этого свойства в той нише. Но в этой нише сия фича выполняет роль грузила. Называйте, как Вам угодно - от этого абсолютно ничего не меняется. scmRTOS очень похожа на uCOS - та же идеология, те же принципы. Реализация другая, оптимизированная под свою нишу. Что касается "академичности", то вот возьмите-ка да и примените-ка uCOS на своей меге8. И расскажите после этого, как оно там легло. И для сравнения проделайте то же самое с scmRTOS. И сравните. По размеру кода, по требованиям к ОЗУ, по временам передачи управления/реакции на события. Интересно будет узнать, как Вам понравилось остутствие поддержки раздельных стеков для данных и адресов возвратов в uCOS. Может после этого у Вас возникнут мысли и о практичности. Мега8, кстати, уже не такой скудный МК - там целый килобайт ОЗУ!

Насчет freeRTOS не скажу, давно уже не смотел в ее сторону. А про uCOS, конечно, знаю. Две итерации по таблице. При количестве процессов менее 8 это ДОЛЬШЕ, чем в scmRTOS, где просто тупой перебор-поиск признака активного процесса. В scmRTOS всего максимум может быть 15 пользовательских процессов, реально их бывает не более 8 (я не знаю никого, кто бы использовал больше на мелких МК с килобайтом-двумя ОЗУ). Поэтому в ее случае можно позволить себе максимально простой и легкий алгоритм поиска. С 64-мя задачами такого делать уже нельзя. В этом и состоит их главное отличие - бОльшая масса обладает бОльшей инерцией. Насчет реальных времен переключения процессов: я проводил такой эксперимент: один процесс, более приоритетный, встает на ожидание флага. Другой процесс устанавливает ножку МК в 1 и сигналит флаг. Когда после этого ожидающий процесс получает управление, он сбрасывает ножку МК в 0. По длительности импульса и определяется время передачи уплавения между процессами. На MSP430F149 при тактовой частоте ~5 МГц на scmRTOS время было порядка 26-27 мкс, на uCOS - около 50 мкс (или около того, могу уже точные цифры наврать, давно было, но запомнилось, что где-то порядка двух раз). Комплятор в случае scmRTOS был IAR v2.0x, в случае uCOS - 1.26. Качество кодогенерации смотрел, никаких нареканий к 1.26 не помню. Причина, по которой использовалсь разные компиляторы - для scmRTOS нужны ++, для uCOS был порт под 1.26. Т.ч. Ваши заявления про 10 раз - извините, бред с любой стороны (ни одна из ОС не имеет такого преимущества перед другой - максимум раза в три), и uCOS медленее. Не верите - возмите и проверьте сами.

Из какого макроса? О чем Вы говорите?? А сколько пройдет времени? Какого времени? С какого момента? О чем Вы говорите, не понимаю. "Здесь" при возникновении прерывания вызывается его обработчик, в котором на входе сохраняется контекст текущего процесса. Далее пользовательские действия, в т.ч. сигналится, например, флаг (и ожидающие процессы переводятся в готовые к выполнению). На выходе управление передается самому приоритетному из готовых к выполнению. Точно так же, как и в uCOS. С++ ничего там не "наворочает". Совершенно! Возьмите хотя бы и посмотрите на кодогенерацию прежде чем такие выводы делать. Открою для Вас тайну - uCOS толще и тяжелее (и по размеру кода, и по требованиям к ОЗУ, и по быстродействию). Причем очень заметно - как бы не в два раза, если не больше. Из коммерческих ОСей тут гораздо лучше embOS - она близка по быстродействию к scmRTOS, хотя тоже уступает (я сравнивал их демо пример, где количество задач ограничено тремя). Тормоза и жручесть uCOS вполне объяснимы - там 64 задачи надо уметь обслуживать да еще и с возможностью инверсии приоритетов. Это бесплатно не дается. И что это за стандарт такой, на основании которого сделана uCOS? Как называется? Насколько я понял из откровений Лябрусса, свою ОС он писал для себя, для своих целей, т.к. продолжительное время не мог найти готового, удовлетворяющего его по цене и качеству. А потом опубликовал результат своей работы, который оказался востребованным. Успех uCOS в значительной мере обусловнен двумя обстоятельсвами: 1. работоспособное решение, основанное на реальных требованиях и реальных возможностях; 2. отличная книжка-введение в ОС РВ. Нонсенс. Тяжеловесность ОС определяется не количеством сервисов, а базовыми механизмами ядра, организацией и менеджментом задач. На мелочи 8/16-битной время, требуемое для реализации инверсии приоритетов, обычно соизмеримо (или даже больше), чем время занимаемое низкоприоритетным процессом при обращении его к совместному ресурсу. Т.е. инверсия приоритетов тут - это только лишние килобайты кода, лишнее (остродефицитное) ОЗУ и куча времени, проведенного внутри критических секций. Только и всего. И спросите у народа, кто пользуется uCOS, много ли они пользуются инверсией приоритетов в своих реальных проектах, и много ли прироста производительности (и смысла) в ней они там находят. А вот это завсегда правильно - чем сотрясать воздух, взять да проверить на практике. Практика, как известно, - критерий истины.

Десяток - не десяток, а реально чем проще использование, тем лучше. Сравните, что проще, наглядее и удобнее - создать флаг в этой ОС или семафор в uCOS. Там для этого вызывается отдельная функция с кучей параметров - попробуй еще ошибись, проверки все, afair, на рантайме (а кто их на рантайме чекает?). И pend там тоже тяжелее, замороченнее - надо адрес руками передавать. А тут не надо - this компилятор автоматом мечет. Вот и преимущество. Мелочь, а удобно. И чем это uCOS "посолидней"? Наличием поддержки инверсии приоритетов? Инверсия приоритетов на той мелочи, куда оно ориентировано - от лукавого. Имхо. В остальном все очень похоже - идеология та же самая. Только uCOS поддерживает больше задач (что тоже реально на мелочи не нужно, да и 15 процессов - не мало), поэтому имеет более сложный, тяжелый и медленный планировщик. На мегу8 uCOS не ложится, а эта - пожалуйста. ++ совершенно не мешают, только помогают. К тому же шаблоны очень даже кстати.

Вот вдогонку: http://forum.electronix.ru/index.php?showtopic=4607

В симуляторе у IAR периферия не симулируется, только ядро. Для симуляции периферии можно использовать макропроцессор, встроенный в симулятор. На деле это даже более удобное и мощное средство моделирования. Тема уже обсуждалась.