Jump to content

    

Ugene

Участник
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Ugene

  • Rank
    Участник
  • Birthday 04/30/1983

Recent Profile Visitors

247 profile views
  1. Хоть какой-то ответ по теме. Логика в формулировании требований к ПО - думаю правильная. При этом далеко не каждый заказчик знает, что такое динамическая индикация, как происходит опрос кнопок и т.д. Соответственно он в ТЗ это не может корректно указать. При этом как пользователь он четко сможет увидеть, что например кнопки подтормаживают, потому-что у него есть опыт работы с устройствами у которых есть кнопки. Поделитесь пожалуйста опытом, в ТЗ по которым Вы работали указывались:
  2. Я не прокурор и не выдвигал обвинения исполнителю. У меня не было цели найти виновного. По проекту с дисплеем уже давно сделал выводы и считаю тот случай - просто полученным опытом. Если бы я хотел найти виновного, то просто подал бы в суд на исполнителя. У меня была цель найти ответ на вопросы: существуют ли неписанные правила и как переформулировать пункт "Нужен качественный код для устройства". Привел свой печальный опыт с дисплеем в качестве примера, чтобы было понятно о каких неписаных правилах идет речь и тут понеслось. Почему-то вместо конструктивного ответа на вопросы, начали очень подробно разбирать пример. Более развернутые пояснения по примеру, только уводили от самой цели. Вопросы довольно комплексные и непростые. И скорее всего на них нет простого и однозначного ответа. Вместо того, чтобы обсуждать слона, начали обсуждать муху на слоне. Прошу Вас, не тратьте свое драгоценное время на обсуждение мухи (примера). При этом заданные вопросы считаю полезными как для заказчика так и для исполнителя, и если бы получилось их конструктивно обсудить, то был бы очень всем признателен.
  3. Согласен, что схема не идеальна, как и все в этом мире. Но при качественном техническом решении, а именно качественном коде, этих эффектов не будет. Схему переделать для меня - было самое простое решение, но профита от этого не будет при той прошивке, которую представил исполнитель. Исполнитель даже не предлагал внести изменения в схему, т.к. понимал, что это не поможет устранить эффекты, из-за того, что проблема именно программная. А вот почему он не захотел устранить этот эффект для меня остается загадкой.
  4. При чем тут DMX512? В схеме, которую обсуждаем его нет, UART использовался только для отладки. В готовом устройстве по UART ничего не передавалось. В схеме были только кнопки, светодиоды, семисегментники и реле. Как писал выше - проблема чисто программная, т.к. мой код не имел таких эффектов. Проверялась прошивка на плате изготовленной на заводе. Транзистор был установлен BSS138 и с ним не было проблем.
  5. Не вижу грубости. Я за конструктивное обсуждение. В моем коде я использовал таймер каждую миллисекунду, и по прерыванию делал вывод на дисплей. В итоге частота скорее всего была 250 герц для каждой цифры. (правда не проверял). У исполнителя тоже не было делеев, но вывод был просто в теле программы, в результате чего интервалы между выводом на экран были различные. Транзисторы нельзя убирать, они обеспечивают суммарный ток цифры. Пин атмеги органичен 20мА, если не ошибаюсь. U3 тоже нельзя убрать, я показал не всю схему, а только вывод на дисплей. На оставшихся пинах сидет светодиоды и другая периферия. Согласен, что можно использовать OE. На первом образце без ОЕ проверил яркость, ее оказалось достаточно, так и оставил.
  6. Насколько рационально переписывать загрузчик, отлаживать код этого загрузчика, чтобы заменить конденсатор на резистор?
  7. То есть DTR должен напрямую подключаться к ресету?
  8. Когда загружается прошивка в атмегу, то ее необходимо перед этим сбросить, DTR тянет ногу вниз и через конденсатор на короткое время просаживает ресет на землю, после чего идет прошивка меги. Это копия ардуино.
  9. Это стандартная схема для подключения внешнего преобразователя USB-UART. Уточните что именно неправильно?
  10. Уточните пожалуйста, в чем ошибка?
  11. Длительность не проверялась, но как указывал Выше мой код для этой платы выводил информацию без мерцаний и все сегменты имели одинаковую яркость. Поэтому в данном конкретном случае схема не влияла на яркость, проблема именно программная. Я думаю, что здесь общаются профессионалы своего дела, которые с уважением относятся друг к другу и подобный сленг недопустим в общении. Сообщения в подобном стиле буду игнорировать. Исполнитель был со мной согласен, что яркость различная, но не признавал, что это необходимо исправить.
  12. Длительность не измерял. А вот визуально этот эффект заметен, даже для не вооруженного глаза.
  13. Да, действительно исполнитель использовал стороннюю либу и предлагал сначала заплатить за проект. А потом он будет разбираться с библиотекой и возможно поправит ее. Я не гонюсь за дешевизной, но и оплачивать пожелания исполнителя намного выше рынка не собираюсь. Поэтому пишу ТЗ, исполнитель его оценивает, и если цена устраивает исполнителя и вписывается в мой бюджет, а также меня устраивают сроки то начинаем взаимовыгодное сотрудничество. Исполнитель был не из дешевых, и очень разрекламирован на другом сайте. И судя по всему пользуется большой популярностью. В принципе я считаю его адекватным исполнителем, но дисплей неожиданно для меня, стал камнем преткновения. Согласен, что необходима адекватность с обеих сторон. Я за баланс. Адекватность исполнителя при обсуждении первого проекта не всегда можно правильно оценить, да и при втором проекте как показывает практика не все однозначно. У каждого есть свои болевые точки, и если ранее на них не попал, то есть вероятность наскочить на них позднее. Поэтому и начал обсуждение этой проблемы. Хотел понять как коллеги смотрят на этот вопрос.
  14. Качество реализации скорее всего более корректная формулировка. Но опять же, указав в ТЗ, что необходима качественная реализация, исполнители начнут опасаться, что такая формулировка, также как и качественный код может быть использована как причина для отказа от оплаты. Не совсем понятны критерия качества реализации и т.д. Нужно как-то соблюсти баланс между тем, чтобы исполнитель не опасался расплывчатых формулировок со словом качество, и чтобы заказчик получил качественное итоговое решение. А так как каждый по-своему понимает что такое качественное решение, то конфликты интересов возможны. По поводу адекватности исполнителя - это вообще темный лес. Если исполнитель нанимается первый раз, то вообще неизвестно что можно от него ожидать. Может повезет, может нет. Соответственно не понятно как заказчику себя подстраховать при первом заказе и что указывать для этого в ТЗ? Исполнитель который писал код для дисплея был мне знаком, до этого я заказывал у него код и код работал так как надо, но в первых прошивках не было дисплея :-). И только когда появился проект с семисегментным индикатором, получился конфликт. Понятно, что методом проб и ошибок заказчик найдет исполнителя, который его устроит и после нескольких проектов будет понятно как под конкретного исполнителя писать ТЗ. Но вопрос как правильно в ТЗ описать требуемое качество решения, чтобы все были довольны (и заказчик и исполнитель) остается открытым.
  15. Кусок схемы устройства в приложенном файле. Sheet1.pdf