=AK=

Не согласен. Hикакой особой разницы между форматами нет. Это ни на что не повлияет. Потому что PCAD - до сих пор самый популярный пакет EDA в России. Если бы TopoR изначально ориентировался на мировой рынок, тогда имело бы смысл делать импорт-экспорт в формате Specctra.

Там наверняка есть еще куча подводных камней. Например, связанных с "владением" тем или иным файлом. Если пакет "следит за своим добром", то все может хорошенько грохнуться во время правки. И еще проблемы связанные с "проверкой достоверности" данных. Если формат внутренний, то можно ограничиться простейшей проверкой, например, контрольной суммой. А если он открытый, и кто угодно мог в файл влезть и сикось-накось его отредактировать, значит, придется его долго и нудно парсить и проверять на ошибки. Вся реактивность пойдет коту под хвост, да и сам ТопоР раздуется неимоверно. Нет, это ложный путь.

Знакомо, ессно. До боли. Только то, что Вы предлагаете - это беспардонная партизанщина. Такие вещи принято решать другими способами. Например, плагинами, для чего пакет должен их поддерживать. Или хорошим встроенным скриптовым языком (предел мечтаний - что-то наподобие Автокада с его АвтоЛИСП-ом) ЗЫ: Никогда не пробовали смотреть результат после ТопоР-а? Имхо, с таким обилием дуг простыми методами не справиться. Нужен доступ не к "мертвому" формату данных, какой бы он ни был, а к самим внутренним объектам, включая их методы. Поэтому плагины или скрипты предпочтительнее.

О какой работе одет речь? Я не улавливаю. Пока что упоминались только конверторы форматов. Получается мартышкин труд какой-то: откройте нам еще один формат, мы (может быть) бросимся писать для него конверторы, иначе - вы сдерживаете развитие. А если вы уже общаетесь в уже известном и хорошо описанном формате - это нам не подходит, потому что... (тут я затрудняюсь даже сказать почему, я так и не понял). Странная какая-то логика. Не нравится Вам PCAD ASCII - напишите для него конвертер и работайте дальше в любом удобном Вам формате, кто ж мешает? И с чего Вы решили, что внутренний формат ТопоР-а облегчит Вам жизнь хоть в на йоту? Тем более, зачем тогда еще один язык? Только для того, чтобы потом переводить на него/с него всю мировую литературу? Не понимаю.

Ни подо что он не заточен. Все эти форматы похожи друг на друга как близнецы-братья. То что проект нуждается в доработке, это проблема не формата, а экспорта. Например, Протел в этом формате бывает выдает такую хрень, что потом назад свое же г... отказывается импортировать, или импортирует с дикими ошибками. Что ж касается потери части данных, то не вижу проблем. Ну будут дуги погрубее, например, вместо разрешения в одну миллионную градуса останется "всего" одна десятая, на что это повлияет? Ни на что.

"В серийном применении" встречал транзисторы в качестве стабилитронов. Коллекторный переход древних германиевых транзисторов пробивался примерно при 70В. Помнится, в телефонных розетках спаренных телефонов стояли какие-то из них, что-то вроде П40. Это было нужно чтобы звонок мог звонить (после выпрямителя). Даже в те времена такое решение выглядело как беспризорный самопал. Что эмиттерный переход в качестве стабилитрона, что самодельный bandgap reference, нынче с этим ковыряться совершенно бессмысленно. TL431 заткнет за пояс самоделки и обойдется дешевле. Кстати, в TL431 используется как раз bandgap reference, но параметры транзисторов правильно подобраны, они находятся на одной подложке, и т.п. Чтобы на отдельных транзисторах получить похожие хар-ки их надо подбирать, ухищряться чтоб температуры были одинаковые, и пр. Овчинка выделки не стоит.

Чем, интересно, не нравится формат PCAD ASCII, который понимает ТороР? Зачем надо изобретать велосипед?

Мне эта схема не нравится: неоправданно сложна, вряд ли хорошо работает. Шипеть должна как гадюка, возбуждаться будет и хрипеть.

supressor - это расплывчатый общий термин. И варистор так можно назвать, и зенер, и газоразрядник, и т.д. Например, для одной только частной задачи подавления выбросов в high-speed USB встречаются такие: -- диодная сборка со встроенным зенером -- варисторы -- SuregeX и иже с ним От задачи зависит. В общем случае это никому не нужно.

Cпасибо. Плата уже разведена и изготовлена под LM2940.

Устpойство питается от 9V...18V. Надо поставить "ограничитель", чтобы могло питаться и от 24V бортовой сети грузовика. C LDO диапазон питающих будет 10V...26V (если LM2940), хотелось получить 10V...30V.

Че-то не могу найти подходящего окромя L4940V12, да и то... Он работает при 30V входного, но это его максимум. Хотелось бы автомобильный, что-то вроде LM2940CT-15, только чтоб защита срабатывала не при 26V, а при 30...32V. Никому не встречался? PS: Fairchild KA78R15C (Vin=35V) имеет 4 ноги, а мне надобно 3 :(

В квартусе вводишь в свой проект PLL мегафункцию, настроив ее визардом на 20 МГц входной частоты и 100 МГц выходной.

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

Совершенно верно, хорошо сказано :a14: Описанная задача (помеха 50В с медленными фронтами) без проблем решается хотя бы так: -- на входе - просто резистор величиной не менее 100к (т.к. собственные защитные диоды AVR слабоваты по сравнени. с другими мк, и входной ток придется ограничить на уровне всего лишь 0.5 мА) -- на выходе - транзисторный буфер, например, на BC846, который безболезненно выдерживает такие напряжения; желательно - с ограничением макс. тока. Имхо, бездумно оптроны ставят куда ни попадя только "продвинутые" радиолюбители. Инженеру такое не пристало делать. :)

Читайте, думайте: http://www.microprocessor.sscc.ru/great/ Еще посмотрите описание Нейрон чипа (LON) и задумайтесь, действительно ли в нем три процессора, или все-таки один стековый процессор, способный мгновенно переключать контекст, три раза за полный 6-тактный цикл. Отвечать не требуется, извините, мне Ваше мнение не интересно. http://www.microprocessor.sscc.ru/great/app.html "The technical term RISC has been swamped by the marketing term RISC to the point that it's lost almost all meaning as a technical term. Almost everything now is described as RISC, even when it isn't"

Это будет уже не SRAM, а регистровая память. Что Вы подразумеваете под словами "регистровая память"? Вот это: http://www.whatis.ru/hard/mem11.shtml "Регистровая память Registered Memory это память с регистрами, которые служат буфером между контроллером памяти и чипами модуля. Регистры уменьшают нагрузку на систему синхронизации и позволяют набирать очень большое количество памяти (16 или 24 гигабайт) не перегружая цепи контроллера. Но данная схема имеет недостаток - регистры вносят задержку в 1 такт на каждую операцию, а значит - регистровая память медленнее обычной при прочих равных условиях. То есть - оверклокеру неинтересна (да и стОит она очень дорого)" или же вот это: http://www.intuit.ru/department/hardware/archhard2/5/ "На нижнем уровне иерархии находится регистровая память - набор регистров, входящих непосредственно в состав микропроцессора (центрального процессора - CPU)." Если последнее, то почему обычные процики (AVR, PIC, Z8, и т.д) могут использовать такую память (на кристалле, непосредственно в составе проца), а мне в моем "супер-пупер CISC-е" в этом отказано? Если Вы скажете, что тот же AVR не может делать никаких арифметических и т.п. операций с операндами в памяти, я возражу, что он RISC, поэтому и не может. Разработчики пожалели железа, потому и не сделали. Мне железа не жалко, и я сделаю проц примерно такой же, как ранние ЭВМ 50-х и 60-х годов, которые называть RISC-ами смешно. Возьму за основу, например, трехадресную БЭСМ-4м, снятую с производства в 1963 г., в которой, как я помню, регистров не было вообще, а все операции выполнялись непосредственно на памяти. Главное что изменю - поставлю быструю память и сделаю все операции однотактными. Без конвеера, ессно, т.к. в оригинале конвеера не было. Не придумали еще. Поскольку регистров в моем CISC-е нет, то при прерываниях сохранять ничего не надо. Померявшись скоростью реакции на прерывания (которых, впрочем, в БЭСМ-4 может и не было, не буду врать, не знаю, но к своему процу я их прикручу, уж будьте покойны) , RISC-и со своими регистрами и конвеерами нервно покурят в сторонке :) Если Вы и такую реинкарнацию БЭСМ-4 вопреки здравому смыслу и очевидности назовете RISC-ом, то далее убеждать Вас в чем бы то ни было я отказываюсь. :(

Угу. Еще искровый разрядник и грозоотвод с рубильником :)

За что такая немилость? Это нечестно! Разве тот же 51-й или AVR используют DRAM? Я думаю, никто из нас толком не знает, какова встроенная память в любом проце, но уж наверняка не DRAM, и очень может быть что не SRAM в обычном понимании. Какова кэш-память в том же пентюхе? Ну ладно, пусть будет SRAM. Скажем, для 50МГц проца возьмем SRAM или даже PSRAM с 10 нс циклом, чтобы иллюзий не было. Однако пристроим ее прямо на чип , протянем шины от каждой ячейки по надобности, и вообще добавим к каждой ячейке железа не скупясь. Не RISC же делаем :) Ну никаким боком он не RISC. Потому что сумма целей моих при этом была прямо противоположна целям RISC-а. Я не стремился уменьшить кол-во железа и переложить исполнение сложных команд на компилятор ЯВУ. Наоборот, я стремился выполнить сложные команды в железе, не считаясь с расходом кремния. Типичный CISC подход. Это была всего лишь иллюстрация утверждения, что сколь угодно сложную команду можно выполнить за 1 такт. Расточительно, неизящно, но роли это не играет, главное - можно Поэтому ничто не мешает построить CISC, в котором все команды будут выполняться за 1 такт. Что и требовалось доказать. Где скрижали, на которых написано, что CISC не имеет права делать эти действия (все или часть) за один такт? Чтобы он не имел права выполнять все команды за один такт? Чтобы было прямо сказано, что RISC-у это можно, а CISC-у - ни-ни, ни в коем случае, иначе это и не CISC, а невесть что, то ли (внеклассовый?) "спец-процессор", то ли "крутой RISC". Почему это спец-процессор не может быть CISC-ом? A RISС-ом он может быть, или тоже "низзя-а-а-а" (с) ?

Два последовательно соединенных резистора, к средней точке которых подключены два диода: один на питание, второй на землю.

Начинать всегда надо с Гугла :) http://www.lirc.org/ LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls. http://irstudio.chat.ru/ Программа для считывания ИК-пультов бытовой теле/видео/аудиоаппаратуры и их воспроизведения

Конечно. Хотя бы тем, что операция чтения из памяти как минимум требует одного такта (хотя в действительности может быть больше). В то время как регистры могут быть непосредственно подключены к входам и выходу АЛУ. Для выполнения такой команды потребуется на мой взгляд как минимум 4 цикла обращения к памяти (хотя может быть и больше). Не согласен. Регистры принципиально ничем от памяти не отличаются. Память - это просто регулярный массив регистров. Из экономических соображений "обычная" память делается как можно проще, поэтому ее возможности более ограничены по сравнению с регистрами. По условию задачи у меня этого ограничения нет, я могу прокладывать сколько угодно шин и подключать память к АЛУ как мне заблагорассудится. Без конвейера, который ставится опять-таки только лишь из экономии, чтобы можно было использовать более медленную (по сравнению с регистрами) память. Представляю еще один вариант воплощения, в котором используется строго 128-битная шина данных. Каждая 128-битная ячейка памяти имеет ассоциированный с ней умножитель 128х128. Например, старшее 128-битное слово результата с выхода умножителя прописывается назад в саму ячейку, младшее 128-битное слово прописываеется в соседнюю с ней ячейку. Для чего между всеми соседними парами ячеек проложен свой специальный 128-битный пук проводов, и к каждой ячейке добавлен еще мультиплексор. То есть, под эту конкретную команду у меня кусочек АЛУ встроен прямо в каждую ячейку памяти, но при этом память осталась регулярным массивом, как ей дОлжно быть. Расточительно? Конечно. Однако технически реализуемо? Несомненно. За 1 такт. Безо всяких конвейеров.

Распишите (хотя бы для себя на листочке) по шагам как должно быть построено железо, чтобы сделать за 1 такт команду: например, чтение (пусть будет 128-битного, хотя здесь неважно пусть разрядность будет равна разрядности шины данных) слова из памяти, умножение на слово в регистре и запись удвоенного по разрядности результата обратно в память. (для CISC такая команда вполне возможна). Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти? Так же точно и сделаю за один такт, как делается на регистрах. Гарвардская архитектура, слова в памяти данных 256-разрядные, шина данных тоже, обращение возможно к половине слова (128 разрядов) или к целому слову. Для чистоты мысленного эксперимента при этом регистров как таковых вообще не буду иметь, и при этом пусть любая ячейка памяти может использоваться так же, как в привычных нам процах используется аккумулятор. Чтоб совсем не было сомнений, что это CISC, вместо умножения предлагаю сделать команду извлечения квадратного корня. Для простоты и устрашения, делать буду табличным методом, для 256-разрядных операндов. Раззудись плечо, размахнись рука, ресурсы-то по условию задачи даны немеряные! :)

Сложные команды нельзя выполнять за один такт? Обоснование не представите? За один такт можно выполнять сколь угодно сложные команды, это не вопрос. Вопрос состоит только и исключительно в том, что неэкономно тратить железо на то, чтобы воплотить все сложные команды за один такт. Поскольку в средней программе они встречаются относительно редко, а кремния требуют относительно много. Экономнее выполнить их за несколько тактов (что часто делается в CISC, а также в некоторых недо-RISC-ах), или вообще их не иметь в системе команд (что характерно не только для RISC, но и для таких "экономических" CISC-ов, как, например, 51-й) . Конвеер равно фиолетово относится как к CISC-ам, так и к RISC-ам. То есть, и там и там он может быть или не быть. В RISC-ах конвеер встречается чаще. Неплохая статья: http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html 1. RISC was not a specific technology as much as it was a design strategy that developed in reaction to a particular school of thought in computer design. It was a rebellion against prevailing norms--norms that no longer prevail in today's world. 2. "CISC" was invented retroactively as a catch-all term for the type of thinking against which RISC was a reaction. 3. We now live in a "post-RISC" world, where the terms RISC and CISC have lost their relevance (except to marketing departments and platform advocates). In a post-RISC world, each architecture and implementation must be judged on its own merits, and not in terms of a narrow, bipolar, compartmentalized worldview that tries to cram all designs into one of two "camps."

Неубедительно. CISC не обязан иметь длинные команды в системе команд. Некоторые CISC-и имеют такие команды, другие - нет. CISC, выполняющий любые команды за 1 такт, не станет от этого RISC-ом. Это не решение. Оно годится только для очень простых приложений, где количество задач у уровней вложения прерывания ограничено каким-то смешным минимумом, обязательно статическим. Для динамически создаваемых задач этот довод вообще не в кассу. В общем случае решение есть только одно - сливать регистры в стек. И здесь RISC-и ковыляют далеко позади многих других.