=AK=

Не вижу оснований для введения новой "эпохи". Во-первых, "жесткая логика" принципиально не отличается от реле. Недаром же в ходу термин "твердотельное реле", хоть это формально и не то же самое, что "жесткая логика", но мысль, надеюсь, понятна. Во-вторых, 70-е были началом эпохи PLC, которые появились в конце 60-х - начале 70-х. Системы управления на "жеской логике" были "последей отрыжкой" релейных шкафов управления. Более чем спорное утверждение. В теории кажется что так. Практика же показывает, что на каждом этапе развития техники синхронные схемы всегда обеспечивали большую производительность, чем асинхронные. Это будет не языком С/С++, а неким принципиально иным языком с синтаксисом, похожим на С/C++. Тогда как убрав требование "слева направо, сверху вниз" мы никак не изменим сущность языков МЭК, но просто уберем "заморочку" конкретной реализации. - в корне не правы! В чем, если не секрет? Это всего лишь цитата с малым комментарием.

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

Не позволяет. http://iram.cs.berkeley.edu/serialio/cs254/enc_dec/ The IBM 8B/10B encoding scheme exhibits all the desired behaviors. It guarantees a maximum run length of 5 bits; the lowest transition density that can be indefinitely maintained under the encoding scheme is 30 transitions per 100 bits; it can detect all single-bit and many other errors; it contains three different comma characters. The encoding scheme also exhibits some interesting characteristics that are not especially useful in this application. These include the dc-balanced property: the coding scheme generates a bit stream with a balanced number of '1' and '0' bits.

Тогда посмотрите nesC http://nescc.sourceforge.net/papers/nesc-pldi-2003.pdf

По стандарту RS485 допускается передавать 1 Мбит/сек на расстоянии до 100м, или 100 кбит/сек на расстоянии до 1 км. При этом линия должна быть, конечно, согласована с обоих концов. Проблемы с RS485 есть, особенно с самопальными протоколами. Дело в том, что, поскольку это шина, то значительную часть времени она проводит в 3-м состоянии. При этом все приемники отлично ловят помехи, что вызывает ложный запуск UART-ов. Если не предусмотреть в протоколе преамбулу, когда передатчик, перед тем как начать пересылку, достаточно долго держит шину в пассивном состянии, чтобы UARTы про...чистились , то будут глюки. Соответственно, протокол должен предусматривать жесткие тайм-ауты, и т.п. Если шина не нужна, а нужно просто гнать данные из одной точки в другую, то лучше работать в режиме RS422. При этом передатчик вообще никогда не переходит в 3-е состояние, и своим выходом эффективно гасит помехи. Линию при этом надо согласовывать только на приемном конце, и с протоколом никаких забот нет. :)

Я всего лишь сказал, что железа, встроенного в FX2, более чем достаточно для большинства практических задач. С чем Вы, как я понял, изволили не согласиться, сославшись на то, что потребуется двойная буферезация. Что я воспринял так, что, по Вашему мнению, средств буферизации FX2 недостаточно, и ему нужен дополнительный внешний буфер. С чем, в свою очередь, уже я соблаговолил не согласиться, приведя свои резоны... Короче, испорченный телефон какой-то :cheers:

Не вижу в ней необходимости. И в этом случае буфер (и не двойной, а ФИФО) нужен только затем, чтобы временно накапливать данный пришедшие в те интервалы времени, когда USB занят "служебными" делами и не может гнать данные: передает SOFы, пингует, и т.п. На это 4-х кил достаточно. Дополнительная буферизация может понадобиться только если большой поток данных в РС идет не равномерно, а "рывками". Что довольно трудно себе представить, т.к. каждый такой "рывок" должен намного превосходить пропускную способность USB2, т.е. иметь "плотность" в несколько десятков (существенно более 20) мегабайт в секунду. Это что ж за задачи такие? Дык, буфера назначаются трубам при конфигурировании. Зачем переключаться-то?

Зюбин - единственный, кто утверждает, что IL произошел от STEP5. При этом не приводит никаких оснований для такого утверждения. Поскольку практически любое самостоятельное утверждение Зюбина является тяжким бредом, то это, очевидно, следует отнести туда же. Первым языком ПЛК, разработанным в 70-х, был "ладдер диаграм", из которого впоследствии произошел LD. Это графический язык, который инструментальной системой транслировался в промежуточный код. Промежуточный код затем исполнялся (интерпретировался) в PLC. Вот этот промежуточный код и был предтечей IL. Первыми производителями ПЛК были Модикон и Аллен-Брэдли, Сименс стал делать ПЛК на несколько лет позже (когда точно - не знаю, но позже, это точно). Поэтому еще до того как появился Step5, контроллеры Модикон и Аллен-Брэдли использовали нечто подобное IL. Пусть они в отличие от Step5 не оформляли свой промежуточный код как язык, на котором пользователь мог бы писать программы, но он был. PLC появились в конце 60-х, т.е. когда еще не было даже ни С ни Паскаля. МЭК только к началу 90-х свел воедино и оформил то, что к моменту выхода стандарта существовало более двух десятков лет. Сама работа над МЭК-овским стандартом заняла 15 лет. Так что загадкой должно быть другое, почему современные скриптовые языки не использовали богатый опыт PLC...

Это не статья, а бред. ST происходит от благородной Модулы. Паскалем его еще можно назвать с большой натяжкой, но уж Бэйсиком, С или Фортраном ST обзывать могут только люди совсем несведущие. Не надо повторять зюбинские бредни.

"Излашается технология алгоритмизации и программирования задач логического управления на основе теории автоматов." Ладно, пускай "излашается" Угу. "Мы наш, мы новый мир построим..." (с) Не разбираясь, навесим на реально работающую технологию "правильные" ярлыки, выкинем на помойку, а потом будем изобретать свой велосипед, пусть изначально кривой, но зато за отдельные деньги. Это и есть стиль мелкомягких, истинная правда... :cranky:

Дык, Цыклон супротив FX2 как плотник супротив столяра (с) FX2 покрывает USB как никто другой. Это, по сути, просто могучий насос для данных, к которому сбоку прикручен 51-й. На FX с USB1 мы получали 1 Мбайт/сек, а на FX2LP и USB2 планируем поиметь пару десятков Мбайт/сек. И ограничений пока не видать, на что USB способна, то из нее FX2 и выжмет.

Чтобы лучше понять суть МЭК-овских языков, настоятельно рекомендую ознакомиться с историей создания ПЛК. Лучше всего читать первоисточник, http://www.barn.org/FILES/historyofplc.html Я бы выделил следующие существенные моменты: -- ПЛК изначально создавался как средство замены релейных шкафов автоматики. Первые языки программирования ПЛК "имитировали" релейные схемы. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Языки ST и SFR - это более поздние добавки. -- Языки создавались на сравнительно бедной базе вычислительной техники 70-х ... 80-х годов, как аппаратной, так и программной. "Если нет гербовой бумаги - пишем на простой" (с) Поэтому имитация релейных схем изначально была достаточно условной. Элементы настоящих релейных схем работают параллельно и одновременно. Для полноценной их имитации был бы необходим язык наподобие VHDL, или что-то вроде функционального языка, где последовательность написания операторов (в VHDL - процессов) не играет роли. А МЭК-овские языки реализованы намного проще, они несут в себе "родимые пятна" императивного программирования, где последовательность написания операторов все-таки играет роль. Вернее, сам МЭК-стандарт не требует этой "императивности", но из прагматических соображений допускает ее. Поэтому критика МЭК-овских языков с позиций императивного программирования в сущности не имеет под собой оснований. Программы на МЭК-овских языках надежны прежде всего потому, что представляют пользователю очень простую и понятную модель поведения: все операторы в идеале исполняются "одновременно". А заморочки неодновременного исполнения - это уже нюансы реализации, исторические "родимые пятна". В конечном счете, надежность программ зависит прежде всего от человека, а именно - от того, насколько он хорошо представляет, что делается, и насколько он "держит в голове" что происходит в его программе. То есть, насколько хорошо он моделирует систему. Если порядок исполнения операторов неважен (пусть даже условно), это сильно упрощает моделирование и, соответственно, повышает надежность программы. Средства программирования ПЛК являются тому подтверждением.

Можно спросить, нафиг вам такое чудо? При пересылке в РС, пока вы в него пихаете свои данные, то что уже запихано раньше - успевает усвистеть по USB.

PS: Посмотрел 8b/10b. Замысловатый код, однако эффективность использования полосы канала такая же, как у стартстопных, т.е. хуже чем у битстаффинга. В отличие от старт-стопных, 8b/10b позволяет обнаруживать одиночные ошибки, а также дает сбалансированное кол-во 0 и 1, что важно для транформаторной развязки. В общем, эзернетовский прикол, там ему и место, имхо.

Дык, смотря какие счетчики. Если 32-разрядные, то ессно не хватит.

Наиболее впечатляющая Жаба для встроенных применений из всех, которые мне встречались: http://www.rtjcom.com/main.php?p=home In contrast to other embedded implementations of the virtual machine the simpleRTJ requires on average about 18-24KB of code memory to run. The simpleRTJ has been primarily designed to run on the small 8/16 bit systems with a small amount of memory. However, the simpleRTJ can also be used on the more powerful devices based on the 32 bit microcontrollers as it supports linear memory addressing of up to 16MB. Porting the simpleRTJ is quite straightforward and in some cases the compilation for the target device may not require any changes at all to the generic VM sources. The simpleRTJ has been ported to a number of target processors including MC68302, MC68376/332, 68HC11, 68HC16, 8051XA, various ARM7/9 derivatives, H8S/2241, STi5512, embedded x86, ZSP200/400/neo, and many others. The simpleRTJ includes all of the core features expected from any virtual machine like multi threading, exception handling, interfaces and the garbage collection. On top of this the simpleRTJ doesn't require any support from the underlying RTOS. In fact, it can be considered as a mini Java OS that can run on it's own as it has built in support for the memory allocation, heap management, multi-threading, software timers, etc. The simpleRTJ is provided free of charge under the RTJ Computing non-commercial source code license agreement to everyone for evaluation, educational and private use.

Очень может быть. Я имел ввиду аппаратные сердесы, где к 10 бит данных привешивается старт-бит в начале и стоп-бит в конце. С какого бодуна я их обозвал 8/10? Сработала ассоциация с UART-ом, где обычно к 8 бит данных привешивается старт-бит в начале и стоп-бит в конце.

Поправка, не NRZ, а NRZI. Вообще же битстаффинг заметно более эффективен, чем старт-стоппные кодировки (типа 8/10): он "сжирает" меньше полосы канала, при этом создает лучшие условия для PLL. Восстановление клока после битстаффинка в принципе не отличается от 8/10. Не-а. Реализовать в FPGA восстановление клока можно. Термин для гугления CDR - Clock and Data Recovery. Есть FPGA со встроенными serdes, способные на это, например, у Алтеры - Меркурий. Однако они стоят хрен знает сколько. Есть и другой путь. У Алтеры на эту тему есть пара аппликух и референс дизайн на Верилоге, где при помощи Стратикса или Циклона делается CDR из видеопотока SDI (270 Mbps) или HD-SDI (почти полтора гига), с полным декодированием. Фокус состоит в том, что используется оверсамплинг 3/2 или 5/4. Однако как это реализовать на практике - не так уж очевидно, для этого надо выходить на уровень фиттера и логических элементов, чего я лично, например, пока не умею.

Да Знать индуктивность - это еще не значит "выбрать катушку". При расчете ИИП на начальных этапах используются идеальные (абстрактные) элементы. При этом предполагается, что дроссели не насыщаются, транзисторы не пробиваются, электролиты не взрываются, потери в элементах учитываются грубыми "интегральными" поправочными коэффициентами, и т.п. Когда из расчетов становятся видны требуемые характеристики идеальных компонентов, тогда и выбираются реальные компоненты: -- катушки нужной индуктивности, выдерживающие расчетный ток без насыщения и излишнего нагрева, и пр. -- конденсаторы нужной емкости, имеющие требуемое внутреннее сопротивление, рабочее напряжение, и пр. -- транзисторы, способные коммутировать нужные токи и напряжения, и пр. -- и так далее.

Угу. Считая ("оставляя") ее постоянной на коротких интервалах времени. Тем не менее, на больших интервалах величину тока можно менять. Не только (вернее - не столько), скважность будет сильно зависеть от нагрузки. При малых нагрузках система перейдет в прерывистый режим. Угу. Когда в схеме наступит баланс мощностей, токов и напряжений. При нормальных нагрузках желательно, чтобы баланс наступил в непрерывном режиме. ... и попробуйте сдвинуть бесконечную индуктивность с нулевого тока ... Бесконечная индуктивность, через которую уже течёт ток, называется вечным двигателем. Бесконечная индуктивность есть абстракция. Правильно оперировать абстрактными понятиями помогает образование и навык, а практическая сметка (типа "смекалка темной головы") в этом отношении частенько подводит. Неверно. Система перестаёт функционировать, если она дурно расчитана и/или сделана тяп-ляп. Если больше пиковый ток, то надо выбрать такую катушку, сердечник которой (если он есть) не будет входить в насыщение при этом токе. Увеличение или уменьшение индуктивности как таковой на "вероятность насыщения" никак не влияет. Эта самая "вероятность насыщения" возрастает только и исключительно из-за того, что разработчик что-то не учел, забыл, или вообще не понимает, как должно работать его устройство и какова причинно-следственная связь происходящих в нем явлений.

В пределе, когда индуктивность стремится к бесконечности, ток через нее постоянный, а от отношения времен (т.е. скважности) зависит величина этого тока. Меняя скважность, можно регулировать величину тока, и тем самым регулировать напряжение в нагрузке. При конечной индуктивности ток в катушке может заметно меняться. Тем не менее, в режиме непрерывных токов, если изменения тока в катушке сравнительно невелики (процентов 10-20), можно для упрощения расчетов полагать, что ток постоянный. Тогда все что нужно - это уравнения баланса токов и напряжений, а погрешность расчетов все же будет невелика. В режиме прерывистых токов, чтобы соблюсти баланс, приходится закачивать в индуктивность большой пиковый ток. Из-за этого будут больше потери в проводах, в ключе, в диоде, и пр. "прелести", а расчет существенно усложняется, т.к. пренебречь изменениями тока уже никак нельзя. Неверно. Из этой формулы следует, что при бесконечной индуктивности изменения тока не будет, и ничего более. Постоянный же ток может быть каким угодно. А вот насыщение катушки с ее индуктивностью никак не связано. Вообще никак. Насыщение связано со свойствами сердечника, если он есть. Катушки без сердечника не насыщаются, какую бы индуктивность они ни имели.

Непрерывность связана с тем, успевает ли вся накопленная в катушке энергия уйти в нагрузку пока ключ закрыт. Если успевает - это режим прерывистых токов, т.к. есть периоды времени, когда ток в катушке равен нулю, форма тока - треугольная с паузами. Если не успевает - это режим непрерывных токов, ток в катушке никогда не падает до нуля, форма тока треугольная без пауз, с "подставкой". Граничный режим между непрерывным и прерывистым - это когда форма тока в катушке треугольная, но "подставка" нулевая. Тогда лучше увеличить, чтобы перейти в режим непрерывных токов. Как buck так и boost идеальный вариант - бесконечно большая индуктивность, тогда через нее течет один и тот же ток, и когда ключ включен, и когда выключен.

Пока через катушку течет ток, напряжение на одном конце Uвх, а на другом Uвых. Когда энергия, запасенная индуктором, иссякнет, то ток прекратится, и (если не учитывать паразитные емкости) напряжение на одном конце будет Uвх, и на другом тоже Uвх. И так до тех пор, пока ключ не будет снова замкнут. Паразитные емкости есть везде, и в ключе, и в диоде, а уж в самой катушке - вообще до фига. :) В данной схеме сумму всех этих паразитных можно заменить одной эквивалентной, соединенной параллельно ключу. После того как индуктивность израсходует всю свою запасенную энергию на заряд нагрузки, ток через индуктивность прекратится, диод закроется. Однако чтобы схема пришла в состояние равновесия, необходимо еще каким-то образом рассеять энергию, запасенную в паразитной емкости. Ведь в момент когда ток через катушку прекратился, на этой емкости Uвых, а в состоянии равновеся должно быть Uвх. Разность Uc=Uвых-Uвх, запасенная энергия E=C*(Uc^2)/2 И ключ закрыт, и диод тоже закрыт, деваться этой энергии некуда, и она начинает циркулировать по LC-контуру, образованному индуктивностью катушки и паразитной емкостью. Это обычное дело в импульсных БП. Как правило никакого особого вреда этот звон не приносит, хоть на осциллограмме и выглядит страшновато с непривычки. Видно, что звон постепенно затухает, но не успевает закончиться до начала следующего цикла. Чтоб побыстрее придушить этот звон, можно параллельно ключу поставить демпфер, состоящий из последовательно включенных конденсатора и резистора. Этот резистор оказывается включен паралелльно паразитному LC-контуру, на нем будет рассеиваться паразитная энергия. Правда, полезная энергия на нем тоже будет рассеиваться зазря, так что обычно никто не заморачивается этот звон гасить. Нет, этот звон сравнительно безвредный. Самый большой от него вред состоит в том, что в момент замыкания ключа напряжение на ключе может оказаться больше, чем Uвх, поэтому получится чуть больше ВЧ помех, больше динамические потери в ключе, и т.п. Там, где это становится критично, ставят демпфер, несмотря на дополнительные потери от него. На обратную связь этот звон влиять не должен, т.к. ОС берется не с ключа, а с нагрузки (после диода), где этого звона и в помине нет. Левый конец индуктивности подключен к Uвх, нижний конец эквивалентной паразитной индуктивности подключен к земле (в нюансы для простоты вдаваться не буду). LC-контур, в котором циркулирует звон, оказывается замкнут через (нулевое) выходное сопротивление источника питания. На практике - через ближайшую к этому контуру емкость на входном питании. Если эта ближайшая емкость стоит далеко от катушки и ключа, то контур, по которому циркулирует звон, будет большим. Геометрические размеры любых таких контуров с токами надо стремиться делать минимальными. Циркулирующие в них токи создают падение напряжения на земляных проводниках. Если их не учитывать при разводке, то эти вредные напряжения могут пролезать в ОС.

Гуглить по ключевому слову latch-up. Вот, например, первая попавшаяся аппликуха от Фэрчайлда http://www.web-ee.com/primers/files/WebEE/AN-600.pdf

В качестве усилителя - unbuffered инвертор, например, Fairchild NC7SPU04, за ним триггер Шмитта. Плюс соответствующая разводка земель.