Перейти к содержанию
    

i-mir

Свой
  • Постов

    192
  • Зарегистрирован

  • Посещение

Весь контент i-mir


  1. Нельзя не насладится столь широкой дискуссией. Познавательная способность человеческого мозга воистину достойна похвал. Однако сам по себе инструмент познания - "человек" довольно ограниченное и эмоционально не устойчивое образование, которое еще далеко от понимания собственно самого инструментария - т.е. самого себя. Все что может человек по своей природе - это однозначно отсекать гипотезы, которые прямо противоречат его опыту. И собственно говоря все. Ничего однозначного человек постулировать не может. В любом утвердительном высказывании при детальном рассмотрении можно найти ложь, а точнее неполноту знаний об области высказывания. Возьмите параллельность прямых по Евклиду - сегодня не секрет что это лишь весьма ограниченный взгляд на природу вещей. Ряды Фурье сюда же. Однако мы (люди), как нечто принадлежащее этой же природе вещей, на сегодня можем лишь шаг за шагом познавать отсекая более грубые модели и усложняя наше (человеческое) представление о мире. Ну а насчет вопроса что такое сигнал в линии - это сложно. Давайте сначала ответим на детский вопрос а что такое "электрический ток". :)
  2. Возникла идея модернизировать домофон "Цифрал", для того чтобы была возможность заходить в подъезд без ключа. В инете нашел много противоречивой информации, скорее всего из-за различных версий домофонов. У меня трубка "Цифрал КЛ-2" 2007 года выпуска. С помощью одного переменного резистора снял характеристику. Характеристика устройства "автооткрывалки" на рисунке. По сути эмулируем активное сопротивление абонентской трубки. 1-я точка: трубка на базе, R=50 Ом - выдается сигнал вызова 2-я точка: трубку сняли, R=250 Ом - выдается сигнал "Say" 3-я точка: нажали кнопку, R=2200 Ом - открытие дверей 4-я точка: трубка на базе, R=50 Ом - завершение сеанса PS. Простейший девайс размером с пол-спичечной коробки вешаем на номер несуществующей квартиры в любом доступном месте ...
  3. Повторить "у нас" можно - но главное найти слабые места "у них". Ведь проблема не в сложности системы, быстродействии элементов и т.д. - а в "слабостях". Аналог - малярийный комар, размеры мизер - а целого человека нету. Не пойму чего вы так переживаете о прошлом - ведь его у же нету ?
  4. Регулируемое технологическое отставание? Вы думаете оно еще актуально? В прошлом веке - несомненно, хотя шпионов никто не отменял и по сути этот КОКОМ был чисто пиаровской технологией для американской толпы. Реально и Союз и Штаты были в курсе чего там у кого творится и шли параллельно немного различными дорогами. В наш век об этом можно смело забыть - современное оружие информация и новости. Когда твиттер решает президентские выборы - то микросхемы на ракетах это дорого и малоэффективно. Вот слетать на Марс на каникулах было бы прикольно, не находите?
  5. Вот видите - все равно термин используете. Зачем вам 10% от того что было? Сделайте 100% от того что уже наработано сегодня. Тем более информации море в инете. Вам нужны радио-компоненты отечественные? А вы уверенны? Какая разница что будет на микросхеме - иероглиф или кириллица - если устройство работает?
  6. Не понимаю как можно ненавидеть слово или термин, ну это уже выходит за рамки обсуждения. А если по сути, то у вас повышенный интерес только к одной из очень многих проблем в производстве - а именно возможные КЗ на корпус. Если остальные проблемы уже для вас не столь существенны, то это говорит об очень высоком уровне производства.
  7. Разговор начался с проблемы - почему не контролируется изоляция цепей содержащих ИС, т.к. этот тип проверок помог бы исключить множество возможных ошибок при монтаже прибора. ГОСТ интересует безопасность приборов, а не их исправность. В критических приложениях (авионика, химия ...) где важно обеспечить функциональную безопасность - вводится ряд испытаний для ее подтверждения (тест алгоритма, возможные КЗ, пробои и т.д.). Никого не интересует просто так КЗ какой-нибудь ноги микросхемы на землю, если это не приведет к нарушению требований НД относительно безопасности. Да, работоспособность возможно нарушится. Но даже при этом, если нет требований к контролю параметров - то все ок. Возьмите для примера стиралки или кофемолки которые "бьются" током. Рассчитывается что на входе есть УЗО. Следовательно устройство будет включено безопасно, вопрос закрыт. Я считаю что нужно разграничить проблему: на внутренний контроль сборки на предприятии и выполнение требований ГОСТ. На данный момент вы пытаетесь проблемы монтажа переложить на испытания по электробезопасности. Это неверно, это разные задачи.
  8. Варианты включения действительно зависят от конкретных условий работы оборудования. В таком случае необходимо понять о какой схеме здесь идет речь.
  9. Если есть проблема утечек на корпус то следует разбить вашу проблему на части к отдельным компонентам и гарантировать соответствие требованиям по изоляции для каждого такого компонента. Такой подход поможет вам уйти от неэффективного совкового принципа тотального контроля собранного изделия к более эффективному контролю за технологией сборки, где пост-контроль уже не нужен. Относительно снижения безопасности - не согласен, защитное заземление и прибор УЗО обязательны и успешно справляются с возможными утечками.
  10. Все правильно вы думаете Обычно речь идет относительно портов (питания, ввода-вывода и т.д.) где не важно что стоит за этим портом в приборе. см. ГОСТ Р 51317.х.х Согласен с тем что мы обсуждаем здесь электрическую безопасность изделия а не проблемы проектирования/монтажа. см. ГОСТ 12.2.006
  11. Не желаете поделиться описанием проекта в части протокола, средств разработки, наличием аппаратных средств... Нет уверенности если кто-то возьмет любой кусок кода, назовет его СРС-6, и он у вас заработает.
  12. 1. Какой тип НКУ ? 2. Как в ТТ описана проверка Rиз, ГОСТ ? 3. Как вы разграничиваете "цепи содержащие микросхемы" ? 4. Есть ли требования к ЭМС и какие ? 5. Какие схемные решения цепей ввода/вывода ? Без этих уточнений, обосновано ответить вам не представляется возможным.
  13. Вот интересен например сам факт задачи, где топикстартер утверждает, что у него ресурсов хватает на одно деление и там пару умножений, но никак не на два деления. Но если уж из железа вытянули все что можно - то это признак некорректной имплементации и такой проект может не иметь будущего даже если вы засунете два последних умножения в кристалл как предлагается. Когда в свое время было мало ПЗУ и еще меньше ОЗУ на борту 8-ми битного железа, то все делали на целочисленной арифметике подогнанной под границы 2^n ... заменяли все что можно сдвигами - и получали неплохие результаты. Будьте корректны с коллегами, поделитесь спецификацией на часть данного приложения. ради спорта, ибо ради другого просто не интересно.
  14. Совершенно верно, и только благодаря этому, я вынудил топикстартера самому ответить на свой вопрос - нельзя одним длением получить искомые три переменные (по крайней мере в рамках кристалла).
  15. Вопрос как обычно звучит так - чего хочет топикстартер? :) Я понял исходные данные вот так: X=(a mod k1) mod k2 - частное от деления а на k1*k2 Y = (a mod k1) div k2 - остаток от деления а на k1*k2 Но судя по тому что автор дал взаимоисключающие толкования переменных x и y- то вопрос остается открытым
  16. Не совсем понятно что у вас за проблема. Не укладываетесь в максимальное время цикла? И эти два деления являются самыми проблемными из всей цепочки? Тогда: 1. Напишите свою простенькую процедуру деления одновременно двух делимых - задача тривиальная 2. Или в начале умножьте k1*k2, а потом делите штатной функцией - получите два искомых значения Но честно - я бы просмотрел все остальное и попробовал оптимизировать там. Не верится что ресурсы кристалла уже вами использованы на 95% и все уперлось здесь. Посмотрите тайм-ауты и другие цепочки использующие время. Если критичным осталось именно деление, то это вершина оптимального кодирования под заданный кристалл.
  17. На сколько я понимаю, сейчас имеются три подхода к оценке ПО: 1. Чистая комбинаторика, где анализируется возможность написания кода с ошибками, которые могут быть логическими, синтаксическими. Как результат получаем эффективность различных языков в области допущения ошибок. 2. Статистический подход, где принимается например нормальный закон наличия ошибок в ПО и анализируется динамика работы над ошибками. 3. Технологический подход, где анализируются методы и инструменты создания ПО. Он в большей степени основан на том, что качественная организация процесса в результате приведет к качественному ПО. Наверняка есть что-либо еще. В свое время теория надежности пошла по пути выявления фактов несоответствия требуемому КД, привлекла на свою сторону статистику и теперь у нас общая основа расчетов есть экспоненциальный закон не привязанный к железу. А могло быть и другое развитие - на принципе потерь энергии в системе. Например не оптимальные узлы схемы потребляют излишнюю энергию - нужно задуматься и уменьшить надежность такого узла и т.д. ... Аналогично с ПО - например каждая ветка имеет свои тайминги - сравниваем с общепринятыми значениями (этого пока нет но будет), анализируем ... - в общем глобально смотрим куда тратится процессорное время. Нашли баг, сделали коррекцию алгоритма, время выполнения увеличилось - это сигнал к анализу и поиску внесенной "ненадежности".
  18. 8B/10B больше актуален для оптики в качестве выравнивателя потока 0/1 и имеет слабую помехозащищенность, в среднем улучшение в 4 раза. Если особых требований нет, то конечно CRC32 + несложная доп. защита наиболее ответственных блоков данных (поле адреса, поле управления и т.д.) с помощью CRC8.
  19. Как ни банально звучит, в чистом виде ответов ни в инете ни в книгах нет. Теорий и формул много, но на практике, с приемлемой точностью можно использовать простую комбинаторику. Здесь принимается модель последовательного канала связи с простейшим потоком ошибок (пуассонов). Для работы например с ПЛИС, следует использовать другую модель, где равновероятны любые сочетания и т.д. После этого CRC тестируется на помехозащищенность заданного блока данных используя как метод прямого перебора, так и Монте-Карло. Корректируются теоретические модели (например разные полиномы CRC8 показывают помехозащищенность отличающуюся на порядки). Относительно вероятностей - нужно понимать опять-же что вам нужно. Если задача привести ваш канал связи к уровню стандартов в системах с повышенной безопасностью (интенсивность 10е-15 1/час), то это одно, а вот просто сказать - что все ок, это другое. В последнем случае не заморачиваясь, принимайте CRC32 на базе IEEE 802.3 - это общепринято, правда для блоков до 1500 байт. Остальные вопросы заданы в общем виде и слишком объемны для рамок форума. Чтобы понять какой вам нужен уровень защищенности ответьте на вопрос: достоточна ли защита блока данных от всех ошибок нечетных кратностей (1х, 3х, 5х ...), защита от всех ошибок 2х кратности и защита от 129 ошибок из 130 кратности 4х, 6х ... ? Это уровень обеспечивается CRC8. Под ошибками понимаем инверсию битов в блоке данных. Пока не понятны ваши критерии оценки, как только они определятся, можно решить задачу о требуемом протоколе канала связи.
  20. Проблема как раз в другом, и заключается в вопросе - чего вы собственно хотите? Если у вас есть требования предъявляемые заказчиком - давайте обсудим. Ели требований нет - тогда можно взять из ГОСТа любые понравившиеся. Отсюда проблемы в трактовке и анализе уровня помехозащищенности. На рис. приведены относительные уровни - для того чтобы показать лишь принцип. Выводов может быть несколько: 1. Нет смысла дробить защиту на заголовок и тело в предложеном виде 2. Если уровня защиты хватит - можно остановиться лишь на общем CRC16 3. Для случая "обычного канала связи" где p=10е-4, P=7.4е-8 (для 2304 бит) и вы попадаете в 3-ю колонку изделий по ГОСТ 26.205-88 , табл.3 4. Если уровня защиты не хватит - это предмет для обсуждения, но тогда укажите подробнее о задаче. 5. Если у вас есть желание привести цифры к интенсивностям отказов (1/час) и т.д. - тема отдельного разговора 6. Здесь все то что не вошло в предыдущие пять пунктов ... :) PS. Прошу прощения - не увидел что речь идет именно о 2048 байтах данных, это уж слишком большой блок для CRC16 по определению.... Вам нужно обратиться к стандарту Ethernet IEEE 802.3 (CRC32) в любом случае.
  21. Все равно нужно от чего-то оттолкнуться если нет экспериментальных данных. Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2. Укажите согласно ГОСТу требования к вашему устройству на каналы связи. Если это устройства "критического использования" - то нужно использовать другие отраслевые документы. После этого можно будет прикинуть помехозащищенность вашего протокола и его соответствие требованием. Если уровень защиты CRC "в лоб" будет не высоким, тогда рассматриваются другие типы кодирования. Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ? В качестве примера, для очень зашумленного канала (р=10е-3) вероятности необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что заголовок у вас защищен в три раза лучше чем поле данных. Абсолютные значения вероятностей будут зависить от исходных данных и выбранных вами требований. _____26_205_88.pdf
  22. Проблема в том, что приведенные примеры не дадут вам "динамики" работы СRC, для этого пишется свой код и проводятся испытания, порой длительные. Если будет хоть немного конкретики - можно ответить на вопрос, предложить хороший полином, проанализировать помехоустойчиовсть и т.д. Что передается, в каком объеме, в каких условиях, требования к надежности/безопасности и т.д. ?
  23. В свое время писал об этом. http://electronix.ru/forum/index.php?s=&am...st&p=898290 ПС. Википедия не дает и не может давать глубоких ответов - только стартовую точку ...
  24. Хотя ТС говорил об этом давно, но идея стоит того. Не совсем так правда, но вариант сравнительного анализа ПО существует. Можно и на количественные цифры выйти при оценке надежности ПО, но для этого прийдется писать "парсер-анализатор" исходника, и время вычислений зависит от размера исходника в степени. Интересно кто-либо сталкивался еще с таким?
  25. Испытания в любом случае должны быть - неважно как вы собрались рождаться. Теория - это прекрасно, выбранные вами мат. модели отказов, надежности + закон Ома дадут требуемый результат на бумаге. Но это может нивелироваться практикой. Ваши знания о сопротивлении контактов реле не дадут ответ - пробьет 24В его или нет. Потому что, вы полностью положились на закон Ома, но при этом упускаются ряд других факторов, которые "всплывут" при тестах в поле. Тогда модель процесса придется усложнить, например добавить параметры длинной линии и т.д. Испытания в данном случае не означают покупку новой АСУ, а например, всего лишь точечные пробы существующих реле на напряжение 24В. Если и после этого в вашей схеме не останется места для испытаний - значит вы знаете о токе на порядок больше чем все мы здесь вместе.
×
×
  • Создать...