возврат из подпрограмм

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 10 Jun

GS>>>> Тут важна не мода, а тираж устройств. Сэкономишь на миллионном GS>>>> тираже по доллару - набежит прибыли миллион баксов. Это не GS>>>> деньги, говоришь? ;)

MZ>>> Ты пробовал делать милионный тираж?

DO>> Жора пробовал об этом рассуждать, а делать даже 10-тысячный не DO>> пробовал.

MZ> Да и рассуждает криво. при переходе с десятков штук к сотням тысяч MZ> все производство меняется в корне начиная с идеологии. И экономить MZ> надо будет на тех поддержке, ремонте, качестве документации, что MZ> сразу переводит разработку в другой класс. В моей прошлой жизни был MZ> разовый тираж в 200к экземпляров, на тестировании мы чуть не MZ> рехнулись, потом разработали технологию автоматического MZ> тестирования...

Именно. Причем тестировать надо все промежуточные этапы, я последнее время почти исключительно этим (автоматическим тестированием) занимаюсь.

DO>> У наших разработок тираж в десятки тысяч в год, программы для DO>> PIC16 _только_ DO>> на С. Hичто другое всерьез вообще не рассматривается, никому не DO>> нужен несопровождаемый и немодифицируемый ассемблерный код. Тем DO>> более, что

MZ> Эт точно, щас на работе остался только один древний дозатор с кодом MZ> на ассемблере. Hа 80с517 камне, у него есть сопроцессор и заменить MZ> нынче нечем.

Я не знаю такого кристалла, а что у него за сопроцессор?

MZ> Исходник на асме просто ужас, все константы числами, вменяемых имен MZ> нет.

Даже когда есть, разбираться в этом - себе дороже. Я кстати когда уже более

MZ> Придется выкинуть этот бред не глядя, посколько переход на другую MZ> платформу. MZ> А вообще, нынче семейство x51 еще смысл имеет, если считать что MZ> наработок под него нет?

Только ради наработок я бы не держался. Но на этой архитектуре столько всего понаделали, что может что-то и сейчас быть очень актуально.

DO>> экономия в разы - это бывает только на мелких или специально DO>> подобранных алгоритмах, обычно разница куда меньше и уменьшение DO>> просто так не дает

MZ> Угу. Я однажды искал тяжелый глюк в сишной проге под c164 камень, и MZ> внимательно просматривал сгенеренный асм. Глюк нашелся быстро. Hо MZ> впечтлило меня качество кейловского комайлера сильно - путем MZ> дичайшей оптимизации полученого асма я смог бы выиграть отсилы 5-10 MZ> процентов.

На асме часто выигрыш в том, что можно гибче арифметикой малоразрядной пользоваться, без сишного приведения к старшему типу. Использование, к примеру, 24 разрядов вместо 32 может в теории много сэкономить. Но опять же тут есть место компромиссам.

DO>> просто нет. Это любитель, которому ценен сам процесс может DO>> позволить себе вылизывать ассемблерный код. Когда нужен и важен DO>> результат (а нужен он обычно вчера) нужно применять максимально DO>> ускоряющие разработку инструменты.

MZ> Я нынче асм использую только для правки стартапов под c16x. Для AVR MZ> только чистый си, никаких проблем. За 2 года так и не удалось MZ> обнаружить хоть сколько нибудь заметный глюк у Иара и Кейла.

Глюки у компиляторов есть, но обычно их всегда можно обойти.

dima

Hello, Michael! wrote to Michael Zaichenko:

GS>>>> Тут важна не мода, а тираж устройств. Сэкономишь на миллионном GS>>>> тираже по доллару - набежит прибыли миллион баксов. Это не GS>>>> деньги, говоришь? ;)

MZ>>> Ты пробовал делать милионный тираж?

DO>> Жора пробовал об этом рассуждать, а делать даже 10-тысячный не DO>> пробовал. MZ> Да и рассуждает криво. при переходе с десятков штук к сотням тысяч MZ> все производство меняется в корне начиная с идеологии. И экономить MZ> надо будет на тех поддержке, ремонте, качестве документации, что MZ> сразу переводит разработку в другой класс. В моей прошлой жизни был MZ> разовый тираж в 200к экземпляров, на тестировании мы чуть не MZ> рехнулись, потом разработали технологию автоматического MZ> тестирования...

Вот мы с последнее время больше занимаемся не столько разработкой новой продукции, сколько аппаратурой автоматического тестирования уже разработанного...

With best regards, Alexandr Torres.

2:461/28, E-mail: snipped-for-privacy@yahoo.com

Hello Aleksandr!

AM>> Hеочевидно. Если проверка на 0 в целевой архитектуре AM>> эффективнее, хороший компилятор сам реверсирует цикл.

AK> Есть чипы, где инкремент/декрмент/сложение/вычитание *не* модифицируют AK> флаг нуля ? Ж%{} Это какие же, из "ширпотреба" ?

Были. 8080, команды INX/DCX (RP) вообще не влияли на признак результата.

Всего доброго!

А. Забайрацкий.

Sun Jun 11 2006 01:29, Alexandr Torres wrote to Michael Zaichenko:

AT> Вот мы с последнее время больше занимаемся не столько разработкой новой AT> продукции, сколько аппаратурой автоматического тестирования уже AT> разработанного...

Кстати, интересно, как вы подходите к этой проблеме. Т.е. используется ли что-то полностью свое или чей-то тестстенд, что представляет собой софт, как адаптируется под разные изделия/версии. Какова общая идеология.

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Sat, 10 Jun 2006 12:03:05 +0400:

GS>>>>> И всё? А не маловато ли опыта, для столь глобальных обобщений? JA>>>> Я считаю, что более чем достаточно. GS>>> Hапрасно считаешь. JA>> (Вкратчиво) А обосновать это утверждение сумеещь?

GS> Уже обосновывал. Практическим опытом программирования для GS> PIC-контроллеров. GS> Hа сях многие делали (причём умеющие делать это хорошо), а GS> получалось всегда заметно хуже, чем у меня на асме...

Дело не в том, чтобы написать на асме лучше, чем на С, дело в том, чтобы написать на С работающее. Задача получить работающий результат, а не наиболее компактный код. И С его позволяет получить.

GS>>>>> Ты с PIC12/16 попробуй поработать... JA>>>> С пиками я не работал. GS>>> А ты сперва поработай, тогда и пытайся "глобальные обобщения" GS>>> выдумывать! JA>> Hа твоих пиках свет клином сошелся?

GS> Для довольно большого ряда задач - да. Подтверждается объективной GS> статистикой выпуска контроллеров разных семейств.

Сегодня - ни для каких задач нет. PIC'и часто по совокупности параметров лучше, но свет на них клином не сошелся.

GS> При чём тут вредность? Ты завёл разговор в духе "ЯВУ - панацея", а GS> это абсолютно ошибочное высказывание! Точка.

Абсолютно верное высказывание состоит в том, что сегодня можно все или почти все писать как минимум на С. И нужно.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Sat, 10 Jun 2006 12:09:07 +0400:

JA>> Спору нет, если младшие пики крайне просты - значит и не нужно их JA>> программировать на ЯВУ. Hо ведь не меньшая, а скорее бОльшая, часть JA>> микроконтроллеров как раз превосходно программируются на ЯВУ :-)

GS> Голословное утверждение. Существует множество систем, где на один GS> мощный "центральный" контроллер приходятся десятки, сотни, а то и GS> тысячи простейших "периферийных" контроллеров. Обычно решающих GS> отличающиеся задачи, потому имеющие разные прошивки. GS> Результат - бОльшая часть софта будет написана не на ЯВУ.

Именно на ЯВУ и будет все написано.

GS> Крайне маленький стек, существенно ограничивающий GS> вложенность подпрограмм.

Что никак не ограничивает применение С, ограничивает лишь вложенность функций.

GS> Широкий набор очень удобных "битовых" и ниббловых операций, GS> которые довольно криво описываются в "классическом" C.

Чушь.

GS> Крайняя убогость работы с указателями, которые весьма GS> широко используются в конструкциях "классического" C.

Не используй указатели без нужды. С не вынуждает это делать.

GS> Память данных в виде "банков", в противовес сишной GS> концепции "линейной памяти".

Приходится банки описывать вручную, но компилятор хотя бы сам следит за их использованием.

GS> Очень эффективная реализация алгоритмов с "аккумулятором" и GS> "флагами состояний" контроллера, если такие возможности не учитывать GS> при написании программ - код получается крайне неэффективным.

Компилятор учитывает.

GS> "Кривая" реализация выборки значения из таблицы - через GS> вызов команды retlw, причём адресация к таблице не должна GS> выходить за 256 значений.

Компилятор учитывает.

GS> Если эту особенность не учитывать при написании программ - GS> опять получается крайне неэффективный код.

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

Чушь собачья. В С вообще нет никаких портов.

GS> По сути единственный вектор прерывания контроллера GS> существенно меняет концепции программирования при поддержке GS> широкого набора "внутренней периферии", которой так богаты GS> современные PIC'и.

К С не имеет никакого отношения.

GS> Это так, навскидку...

Выдает лишь твое незнание предмета.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Alexandr Torres on Sat, 10 Jun

AT>> Вот мы с последнее время больше занимаемся не столько разработкой AT>> новой продукции, сколько аппаратурой автоматического тестирования AT>> уже разработанного...

VV> Кстати, интересно, как вы подходите к этой проблеме. VV> Т.е. используется ли что-то полностью свое или чей-то тестстенд,

Свое, делающее функциональное тестирование блоков и всего изделия целиком. Применение стандартного ICT у нас затруднено.

VV> что представляет собой софт, как адаптируется под разные

Программу для PIC18. Со стороны PC - минимум терминал, или что-то более навороченное.

VV> изделия/версии.

Под разные изделия - командой тестеру. Под новые версии - новая версия софта тестера. Заливается через ICP

VV> Какова общая идеология.

Где-то так.

dima

Sun Jun 11 2006 10:42, Dmitry Orlov wrote to Vladimir Vassilevsky:

AT>>> Вот мы с последнее время больше занимаемся не столько разработкой AT>>> новой продукции, сколько аппаратурой автоматического тестирования AT>>> уже разработанного...

VV>> Кстати, интересно, как вы подходите к этой проблеме. VV>> Т.е. используется ли что-то полностью свое или чей-то тестстенд,

DO> Свое, делающее функциональное тестирование блоков и всего изделия DO> целиком. Применение стандартного ICT у нас затруднено.

Хм. Похоже, что никто, кроме Очень Крупных Фирм, не любит стандартного ICT. Вообще его удобство и применимость для чего угодно выглядит довольно сомнительно, но у больших фирм другие приоритеты. VV>> что представляет собой софт, как адаптируется под разные DO> Программу для PIC18. Со стороны PC - минимум терминал, или что-то более DO> навороченное.

Интересно, на PC выполняется какой-то свой скрипт/псевдоязык или просто аппликуха на стандартном языке.

DO> Под новые версии - новая версия DO> софта тестера. Заливается через ICP

То есть поддержка - на уровне инженеров, а не на уровне техников?

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 11 Jun 2006 09:39:32

AT>>>> Вот мы с последнее время больше занимаемся не столько AT>>>> разработкой новой продукции, сколько аппаратурой AT>>>> автоматического тестирования уже разработанного...

VV>>> Кстати, интересно, как вы подходите к этой проблеме. VV>>> Т.е. используется ли что-то полностью свое или чей-то VV>>> тестстенд,

DO>> Свое, делающее функциональное тестирование блоков и всего DO>> изделия целиком. Применение стандартного ICT у нас DO>> затруднено.

VV> Хм. Похоже, что никто, кроме Очень Крупных Фирм, не любит VV> стандартного ICT.

Я бы не сказал. У нас просто банально нет места на плате под иголки.

VV> Вообще его удобство и применимость для чего угодно выглядит довольно VV> сомнительно, но у больших фирм другие приоритеты.

У нас для ряда изделий с финальным функциональным тестированием совмещена кастомизация/подстройка.

VV>>> что представляет собой софт, как адаптируется под разные

DO>> Программу для PIC18. Со стороны PC - минимум терминал, или DO>> что-то более навороченное.

VV> Интересно, на PC выполняется какой-то свой скрипт/псевдоязык VV> или просто аппликуха на стандартном языке.

Нет, просто программа на С. Все тестеры узкоспецифичны, им универсальность ни к чему.

DO>> Под новые версии - новая версия софта тестера. Заливается DO>> через ICP

VV> То есть поддержка - на уровне инженеров, а не на уровне VV> техников?

Ну программу тестирования пишет инженер (в моем лице), а залить ее может кто угодно. Весь инструментарий на производственной линии уже есть.

dima

Привет Andrey!

AB>>> Это все понятно. Речь шла о том, что компилятор все может AB>>> предусмотреть. AM>> Hо он не может расставить приоритеты. AB> Значик все-таки компилятор не все знает на этапе компиляции. :-)

Hедостающее я объясняю ему опциями в командной строке.

AB>>> Если компилятор выполняет программу в соответствием со AB>>> стандартом, то по идее, оптимизация не должна оказывать влияния. AM>> По идее, программа не должна содержать ошибок. :) AB> Стало-быть дело только в кодере, а не в компиляторе.

Да, я имел в виду ошибку в программе, а не компиляторе. Хотя компилятор - тоже программа, и тоже может содержать ошибки.

AM>> Ты никогда не встречал ситуацию, когда после смены компилятора AM>> программа перестает работать? AB> Да, да, да, это получается, что твой пример выше (про свертку цикла AB> компилятором) справедлив только для конкретной версии, конкретного AB> компилятора.

Конечно. И я в том примере указал и компилятор, и его версию.

AM>> Допустим, не выполняет: функция возвращает 45, а по моему AM>> мнению, должна возвращать 54. Как под отладчиком трассировать AM>> процесс вычисления, если весь код выродился в mov r1,#45; ret ?

AB> Hу ты же пишешь программу, значит не правильно написал. :-)

Блин, ясный пень, что не так наисал. Третий раз говорю: речь идет о поиске ошибки в программе. Ты что, никогда не слышал о таком способе поиска ошибок как пошаговая трассировка под отладчиком?

AB> Т.е. если хочешь от программы другого - пиши по другому.

Как говорил один начальник военного вычислительного центра своим подчинённым по поводу отладки: "а почему вы сразу не пишете программы правильно?!" :)

AB>>> Если бы переменные в этом цикле определены были как надо, то AB>>> компилятор их не выкинул бы. AM>> Они определены как надо. AB> По моему если некое объявление переменных сделано как volatile или AB> static, то это не случайно. :-)

Ты прав. Там не было ни volatile, ни static, и это не случайно. :)

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Если ты коп, почему я весь взмок?

Hello, Vladimir! You wrote to Alexandr Torres on Sat, 10 Jun 2006 23:28:24 +0000 (UTC):

AT>> Вот мы с последнее время больше занимаемся не столько разработкой AT>> новой продукции, сколько аппаратурой автоматического тестирования уже AT>> разработанного...

VV> Кстати, интересно, как вы подходите к этой проблеме. VV> Т.е. используется ли что-то полностью свое или чей-то тестстенд, VV> что представляет собой софт, как адаптируется под разные VV> изделия/версии.Какова общая идеология.

Общаяя идеология такая - под каждый вид железа, совмстимого в плане тестирования между собой, делается свое хардваре тестера. Оно представляет собой источник питания нужных напряжений, нагрузки и измерительные цепи, коммутируемые реле. Управляется это все стоящим в тестере микрокотроллером, индицируется - светодиодами (например 4 стадии теста, красный и зеленый на каждую). Две кнопки - "Старт", "Стоп". В таком виде - может работать автономно, без компа. С компом - общается через терминал (Гипертерм, ТераТерм и .п.). С компа возможно изменение сетапа - переключение на разные устройства, измеение граничных параметров и отображение измеренных параметров. При использованиее на компе не простого терминала а специальной програмы - возможно автоматическая диагностика и протоколирование.

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

Так работают наши "функциональные тестеры", которые проверяют устройство в максимально приближенных к рабочим условиям. Я лично - постоянно наставиваю на проведении промежуточных тестов, отдельных узлов, и желательно _не_ в реальных условиях, т..е бз подачи штатного напряжения. Ибо даже при его токоограничении - при некоторых видах неисправностей, после подачи высокго напряжения оно сорает, и чинить там уже нечего (нецелесообразно). Проверка при низком напряжении (с токоограничением, разумеется), пусть и не 100% всего проверит, зато выявит критические неисправности. Вот таким мы сейчас и занимаемся.

В общем, самое дорогое в таких тестерах, в плане железа - это узел подключения испытываемого устройства к тестеру. "Иголки" как в ICT, специальне коннекторы, расчитанные на многократное и главное - быстрое и надежное подключение, стоят дорого (например используемые а функциональных тестерах 2-х контактные коннектры, стоят в Фарнелле 25 фунтов, а стоимость джига с иголками, креплением платы ит.п. - до тысячи долларов за не первый экземпляр, и несколько тысяч а первый).

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com

Hello, Vladimir!

VV>>> что представляет собой софт, как адаптируется под разные DO>> Программу для PIC18. Со стороны PC - минимум терминал, или что-то DO>> более навороченное.

VV> Интересно, на PC выполняется какой-то свой скрипт/псевдоязык или VV> простоаппликуха на стандартном языке.

В простом виде обычный терминал. В простейшем - вообще тестер без компа работает, автономно.

DO>> Под новые версии - новая версия DO>> софта тестера. Заливается через ICP

VV> То есть поддержка - на уровне инженеров, а не на уровне техников?

Ну смотря что считать "техником" а что "инжерером". Уровень инженера, типа мастера участка (а именно он, или его помошник, обычно занимается сетапом тестеров) на среднестатистическом китайском заводе - не сильно выше того чтоты считаешь "уровнем техника". Разобраться с парамтерами и сетапами тестеров - ума у них хватает. А вот перепрошивка фирмваре самого тестера - обычно этим занимается наш представитель. Собственно, пока все разы на заводе это делал я :) Хотя в принципе - не вижу препятствий чтобы в дальнейшем они это делали сами. Прошивать фирмваре в изделя ведь у них ума хватает, чем тестер хуже? :)

With best regards, Alexandr Torres. E-mail: snipped-for-privacy@yahoo.com

Привет Jurgis!

JA> Понимаешь... Я как эмбеддед программист обладаю одним очень вредным JA> качеством: люблю, чтобы исходящий от меня продукт был еще и красивым. JA> А также, обращаю очень большое внимание на лёгкость сопровождения JA> моих программ.

Ах, как приятно это слышать!!! Повтори это еще раз! :)))

JA> Поэтому, кстати, я негативно отнесся к тому выражению, JA> которое под if'ом пробегало недавно. Hу не люблю я, когда круто, но JA> непонятно...

Как бы ты написал?

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Если ты коп, почему я весь взмок?

Привет Vladimir!

VV> Hа ассемблере все очень просто, очевидно и понятно. Освоение языка VV> требует усилий. Hо самое противное в ЯВУ - это необходимость VV> разбираться со стартапом

:) Разве он написан не на ассемблере, где все так просто, очевидно и понятно? :)

VV> и линкерным файлом.

:) А когда пишешь на ассемблере, эта необходимость уже не так противна? :)

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Если долго думать одни и те же мысли, они становятся грязными.

Hello Jurgis Armanavichius!

RM>> Hе напрягайся, это разговор с глухим. Hе пробовал и не собирается RM>> пробовать. Просто не трать время.

JA> Я достаточно терпим к собеседнику :-) Причем, если собеседник JA> нормальный, как в данном случае, то я с ним спорю спокойно, без JA> напряга, и, думаю, к нашей обоюдной пользе. В конце концов, в споре JA> рождается истина! А это совсем неплохо ;-)

Лично я не понимаю сути "религиозных войн", кои некоторые пытаются вести с тем же Шепелевым. Положим, некто увлёкся выделкой старинного оружия и доспехов по старинным же технологиям, добился определённого успеха и веса в обществе - славно, "у всякого портного - свой взгляд на искусство" (С) Зачем изготовителю автомата Калашникова "бодаться" с изготовителем тех же мизерикордов ? ЖB}}}}}}}}}}}}

Sun Jun 11 2006 15:14, Alexandr Torres wrote to Vladimir Vassilevsky:

AT> Уровень инженера, типа мастера участка (а именно он, или его помошник, AT> обычно занимается сетапом тестеров) на среднестатистическом китайском AT> заводе - не сильно выше того чтоты считаешь "уровнем техника". AT> Разобраться с парамтерами и сетапами тестеров - ума у них хватает. Способности юзеров подложить грабли самим себе удивительны и неисчерпаемы. Чем больше у них простора для проявления интеллекта - тем хуже. AT> А вот перепрошивка фирмваре самого тестера - обычно этим занимается наш AT> представитель. Собственно, пока все разы на заводе это делал я :) AT> Хотя в принципе - не вижу препятствий чтобы в дальнейшем они это делали AT> сами. Прошивать фирмваре в изделя ведь у них ума хватает, чем тестер AT> хуже? :)

Тем, что из-за одного навернувшегося тестера будет навернуто много изделий. И, что хуже всего, это может выясниться с большим опозданием...

VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Sun Jun 11 2006 15:07, Alexandr Torres wrote to Vladimir Vassilevsky:

AT> Общаяя идеология такая - под каждый вид железа, совмстимого в плане AT> тестирования между собой, делается свое хардваре тестера. AT> Оно представляет собой источник питания нужных напряжений, нагрузки и AT> измерительные цепи, коммутируемые реле. AT> Управляется это все стоящим в тестере микрокотроллером, индицируется - AT> светодиодами (например 4 стадии теста, красный и зеленый на каждую). Две AT> кнопки - "Старт", "Стоп".

Какова дальнейшая процедура, если тест не проходит? VLV

"Клянусь всем тем, во что когда-либо верили дураки" (c) Вальтер Скотт

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Alexandr Torres on Sun, 11 Jun

AT>> Уровень инженера, типа мастера участка (а именно он, или его AT>> помошник, обычно занимается сетапом тестеров) на AT>> среднестатистическом китайском заводе - не сильно выше того чтоты AT>> считаешь "уровнем техника". AT>> Разобраться с парамтерами и сетапами тестеров - ума у них хватает.

VV> Способности юзеров подложить грабли самим себе удивительны и VV> неисчерпаемы. VV> Чем больше у них простора для проявления интеллекта - тем хуже.

К сожалению, совсем без интеллекта получается еще хуже.

AT>> А вот перепрошивка фирмваре самого тестера - обычно этим занимается AT>> наш представитель. Собственно, пока все разы на заводе это делал я :) AT>> Хотя в принципе - не вижу препятствий чтобы в дальнейшем они это AT>> делали сами. Прошивать фирмваре в изделя ведь у них ума хватает, AT>> чем тестер хуже? :)

VV> Тем, что из-за одного навернувшегося тестера будет навернуто много VV> изделий. И, что хуже всего, это может выясниться с большим VV> опозданием...

По идее, в начале каждой смены через тестер должен прогоняться заведомо исправное устройство и проверяться что он намерял и прошло ли оно тест. В принципе, этого достаточно при отсутствии злонамеренной порчи оборудования.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Alexandr Torres on Sun, 11 Jun

AT>> светодиодами (например 4 стадии теста, красный и зеленый на AT>> каждую). Две кнопки - "Старт", "Стоп".

VV> Какова дальнейшая процедура, если тест не проходит?

Повторная визуальная проверка, ремонт. Если все равно нет - в печку.

dima