[Ugene 0]

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

Если проект для Вас интересен - пишите в личку. Скину подробное ТЗ, схему и табличные данные для реализации проекта для оценки сроков и стоимости написания прошивки.

[C2000 2]

Пришлите ТЗ на [email protected]

[smart_pic 7]

13 hours ago, Ugene said:

Нужен качественный код для устройства.

Эта фраза сильно отталкивает. в 99.999% будет проблемно сдать проект.

Это по каким критериям "качественный" ?

И чем готовый ДМХ драйвер для СД не устроил?

[s_gary 0]

ТЗ на

[email protected]

[s_gary 0]

6 часов назад, smart_pic сказал:

Эта фраза сильно отталкивает

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

[jcxz 187]

13 минут назад, s_gary сказал:

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

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

Как докажете, что код "качественный"? Сможете?  

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

[s_gary 0]

5 минут назад, jcxz сказал:

показатель "качественности"

Если без шуток, то этот показатель как и применение TM1638 вместо TM1637 нужно обсудить с ТС перед окончательным оформлением ТЗ.

[smart_pic 7]

Прием ДМХ512 данных для нужного канала занимает не более 20 строчек вместе с инициализацией UARTа на нужный режим.

Основная работа это программирование меню для двух индикаторов и немного логики управления яркостью СД в зависимости от настроек и поступивших данных.

 

[C2000 2]

Вопрос не в том что есть работа (мы любой достойной работы не боимся), а как она оценивается и оплачивается!

[Ugene 0]

Всем привет!
Большое спасибо всем, кто откликнулся на проект. Исполнитель выбран.

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

[jcxz 187]

1 час назад, Ugene сказал:

яркость цифр была различной. Каждая цифра имела свою яркость (1 светилась ярче чем 8).

А почему думаете что проблема была в программе, а не в схеме?

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

Либо источник питания просаживается при большом числе включенных сегментов.

[C2000 2]

57 minutes ago, jcxz said:

А почему думаете что проблема была в программе, а не в схеме?

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

Либо источник питания просаживается при большом числе включенных сегментов.

100% верно, если есть закономерность количество сегментов/яркость то проблема с железом а не с ПО.

Другое дело если яркость разная "хаотично". Это указывает что функция выполняющая переключение выполняется не детерминированно, т.е. время между переключениями плавает.

Такое возможно к примеру если это переключение выполняется не из прерывания а из потока ОС. Либо из прерывания, но есть другие прерывания более приоритетные или того же приоритета котоые выполняются "долго" по отношению к периоду переключения цифр.

[smart_pic 7]

D vjtv

56 minutes ago, jcxz said:

А почему думаете что проблема была в программе, а не в схеме?

Скорее всего схемотехническая проблема с неодинаковой яркостью цифр индикатора.

В моем представлении качественный код = это код оформленный по принятым нормам в организации заказчика. есть определенные правила на количество отступов , использование только "пробел" вместо табуляции, как ставить {} скобки, как писать комментарии, как оформлять подпрограммы, ну и еще кучу всего что часто пишут про написание программ на С.

 

[C2000 2]

Ну форматирование кода и его качество слабо связаны.

Вопрос скорее в стиле кодирования (не форматирования). Например запрет на использование extern  (вместо этого доступ к переменным из другого модуля исключителтьно через методы). И тут все конечно неодназначго, то что есть "правильный" код под ПК с "неограниченными" ресурсами вряд ли будет правилтным для 8 битного МК.

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

[Ugene 0]

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

Изменено 7 марта, 2021 пользователем Ugene