Ugene

Добрый день!Необходимо припаять компоненты на 3 платы. Платы скоро приедут из Китая, комплектация закуплена. Сборочный чертеж есть. Нужна только пайка. Перечень компонентов с указанием корпусов прилагается. Уточните пожалуйста сколько стоит такая работа и какой срок сборки, а также в какой локации Вы находитесь? Интересует Москва и МО. Идеальная локация - Мытищи. Нацелен на долгосрочное сотрудничество. Есть периодическая необходимость в напайке компонентов на плате или работа связанная с пайкой. Bill of Materials-DRIVER PCB V3 05.10.2021.rar

Схема подключения RC чепочки и расчет делать как в этой статье? https://www.meandr.ru/rc-tsep

Уточните пожалуйста для чего диод подключать последовательно? Больше конденсаторов и ЛДО думаю имеет смысл поставить. Варистор есть - R23. Или имеется в виду варистор нужен на силовых контактах реле? Реле включает люминисцентные лампы. Возможно наводка действительно лезет от ламп. Подскажите пожалуйста как можно защитить силовую часть реле от наводок или дуговых разрядов?

Всем привет! Есть таймер. Схема прилагается. На столе и в большинстве регионов работает стабильно. Но у некоторых потребителей из регионов на таймере слетает прошивка при включении или во время работы. После чего таймер нужно только перепрошивать. Есть предположение что на схему могут влиять наводки и некачественное напряжение в сети. Поделитесь пожалуйста опытом, может кто-то сталкивался с подобной проблемой? И какое решение может избавить от данной проблемы? Заранее благодарю за ответы. Timer PCB.PDF

Хоть какой-то ответ по теме. Логика в формулировании требований к ПО - думаю правильная. При этом далеко не каждый заказчик знает, что такое динамическая индикация, как происходит опрос кнопок и т.д. Соответственно он в ТЗ это не может корректно указать. При этом как пользователь он четко сможет увидеть, что например кнопки подтормаживают, потому-что у него есть опыт работы с устройствами у которых есть кнопки. Поделитесь пожалуйста опытом, в ТЗ по которым Вы работали указывались:

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

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

При чем тут DMX512? В схеме, которую обсуждаем его нет, UART использовался только для отладки. В готовом устройстве по UART ничего не передавалось. В схеме были только кнопки, светодиоды, семисегментники и реле. Как писал выше - проблема чисто программная, т.к. мой код не имел таких эффектов. Проверялась прошивка на плате изготовленной на заводе. Транзистор был установлен BSS138 и с ним не было проблем.

Не вижу грубости. Я за конструктивное обсуждение. В моем коде я использовал таймер каждую миллисекунду, и по прерыванию делал вывод на дисплей. В итоге частота скорее всего была 250 герц для каждой цифры. (правда не проверял). У исполнителя тоже не было делеев, но вывод был просто в теле программы, в результате чего интервалы между выводом на экран были различные. Транзисторы нельзя убирать, они обеспечивают суммарный ток цифры. Пин атмеги органичен 20мА, если не ошибаюсь. U3 тоже нельзя убрать, я показал не всю схему, а только вывод на дисплей. На оставшихся пинах сидет светодиоды и другая периферия. Согласен, что можно использовать OE. На первом образце без ОЕ проверил яркость, ее оказалось достаточно, так и оставил.

Насколько рационально переписывать загрузчик, отлаживать код этого загрузчика, чтобы заменить конденсатор на резистор?

То есть DTR должен напрямую подключаться к ресету?

Когда загружается прошивка в атмегу, то ее необходимо перед этим сбросить, DTR тянет ногу вниз и через конденсатор на короткое время просаживает ресет на землю, после чего идет прошивка меги. Это копия ардуино.

Это стандартная схема для подключения внешнего преобразователя USB-UART. Уточните что именно неправильно?

Уточните пожалуйста, в чем ошибка?

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

Длительность не измерял. А вот визуально этот эффект заметен, даже для не вооруженного глаза.

Да, действительно исполнитель использовал стороннюю либу и предлагал сначала заплатить за проект. А потом он будет разбираться с библиотекой и возможно поправит ее. Я не гонюсь за дешевизной, но и оплачивать пожелания исполнителя намного выше рынка не собираюсь. Поэтому пишу ТЗ, исполнитель его оценивает, и если цена устраивает исполнителя и вписывается в мой бюджет, а также меня устраивают сроки то начинаем взаимовыгодное сотрудничество. Исполнитель был не из дешевых, и очень разрекламирован на другом сайте. И судя по всему пользуется большой популярностью. В принципе я считаю его адекватным исполнителем, но дисплей неожиданно для меня, стал камнем преткновения. Согласен, что необходима адекватность с обеих сторон. Я за баланс. Адекватность исполнителя при обсуждении первого проекта не всегда можно правильно оценить, да и при втором проекте как показывает практика не все однозначно. У каждого есть свои болевые точки, и если ранее на них не попал, то есть вероятность наскочить на них позднее. Поэтому и начал обсуждение этой проблемы. Хотел понять как коллеги смотрят на этот вопрос.

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

Кусок схемы устройства в приложенном файле. Sheet1.pdf

Проблема была программная. Токозадающие резисторы стояли на плате. Более того, для этой платы я также писал код с выводом на дисплей и таких проблем не было. Просто некоторые функции не знал как реализовать, и так как было мало времени на реализацию прошивки, то пришлось искать исполнителя. Мой вариант вывода на дисплей мне нравится больше и лишен указанных выше недостатков. При этом разная яркость сегментов в моем понимании = некачественный код, т.к. пользователь видит проблему с выводом. А со стороны исполнителя код качественный, с чем категорически не согласен. Никаких требований по форматированию кода не предъявлялось. Если код будет красиво оформлен, но сегменты будут иметь различную яркость, то для меня это некачественный код. Качество кода - комплексный показатель. Но хотелось бы услышать мнение опытных программистов, стоит ли считать различную яркость сегментов индикатора качественным кодом или все-таки одинаковая яркость должна быть по умолчанию. Знаю, что многие работают с различными ТЗ от заказчиков. Интересно кто-нибудь указывает в ТЗ что дисплей должен иметь одинаковую яркость каждого сегмента? Поделитесь опытом пожалуйста. Хочется понять что необходимо указывать в ТЗ, чтобы избегать подобных проблем с исполнителем.

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

Всем привет! Нужен качественный код для устройства.Схема состоит из:- atmega328,- 2 семисегментных индикатора по 4 цифры каждый, которые управляются TM1638,- 9 кнопок, которые настраивают режим работы устройства и опрашиваются TM1638,- драйвер RS-485, работать должен по протоколу DMX512, в режиме приемника.- 2 светодиодных драйвера, которые управляют яркостью светодиодов в зависимости от настроек или от данных по DMX512.Если проект для Вас интересен - пишите в личку. Скину подробное ТЗ, схему и табличные данные для реализации проекта для оценки сроков и стоимости написания прошивки.

Спасибо за ответ. Да, я знаю что есть встроенная опора. Просто хотел подключить более точную опору и выбрать устраивающий вариант опоры внешней или встроенной по факту. В принципе точность встроенной опоры ±0.05%. Как считаете стоит заморачиваться с внешней опорой? Схемы подключения на картинках 117 и 119 - это использование встроенной опоры, а по подключения внешней опоры при биполярном питании не нашел схему. То есть необходимо относительно -2,5В подключить опору величиной 2,5В, что равносильно 0В относительно источника питания аналоговой части, я правильно полнял? Если для питания аналоговой части использовать изолированный ДС-ДС преобразователь 5 на ±5В с понижением до ±2,5В, то подача напряжения на пины REFN0 и REFP0 для внешней опоры -2,5В и виртуальную землю источника питания ±5В, то это будет равносильно опоре?

Всем привет. Подскажите пожалуйста, как правильно подать внешнее опорное напряжение на АЦП ADS124S06, если аналоговая часть АЦП имеет двуполярное питание ±2,5В. При однополярном питании проблем нет, все логично и понятно. А вот при двуполярном питании не могу понять как правильно подать опорное напряжение. Если например подавать опорное напряжение (2,5В) относительно -2,5В, то это эквивалентно 0В. Как в этом случае будет работать АЦП не понимаю. Поделитесь пожалуйста опытом, как работает АЦП при двуполярном питании. Интересует сам процесс работы АЦП с опорным напряжением при двуполярном питании. Заранее благодарен.