+1
А с учетом того что STM32 клепают все кому не лень - то шансов нарваться на такое весьма велики на малых партиях.
Реальная ситуация, которая недавно произошла. Разработано устройство , которое работает отлично и как задумывалось. Пробная партия из 15 устройств работает стабильно. Встал вопрос о производстве мелкой партии 150 шт, отдали на производство стороннему производителю. Он закупил в Китае партию микросхем по выгодной цене. В итоге RS232 - совсем не заработал , RS485 работает - но глючит. Часы реального времени и датчик температуры по I2C глючат при понижении температуры. Вот такая невеселая история.
Как исправили - закупили другую партию МС , распаяли , проверили, заменили на объекте глючные, и по сей день работают без проблем. так что реально получилось и производитель и заказчик заплатили дважды, не учитывая потраченных нервов и времени.
Выпустили другую партию устройств в количестве 200шт (другие поставщики) - вопросов нет , все работает четко .
на мелких партиях в 100-500шт очень легко попасть на отбраковку с входного контроля какого нибудь завода. а ситуацию товарищ выше красиво описал.
Если производители со стажем , то обычно под рукой всегда имеется список проверенных поставщиков.
И проблема решается запросом о стоимости и сроках поставок.
Если начинающие - то можно попросить набросать сюда список поставщиков
Пример может быть на пару переменных сделают.
А потом: Сколько переменных будет всего?(вдруг больше 500) Каков объем ВЕБ интерфейса? (вдруг 2-3М) Частота обновления информации , раз упомянули АЦП?(вдруг 2-4 раза в секунду) Будет ли использоваться SVG для красивой анимации? Нужно ли рисовать шкалы , фейдеры и т.д. и т.п.?
Чтобы реализовать хотя бы часть из вопросов - на этой связке упретесь в стену. Свое решение предложил , ваше дело отказаться.
Есть такое понятие как масштабирование решения. К примеру, Стабилизатор на транзисторе. Решение простое . В базу стабилитрон на нужное напряжение , транзистор по схеме эмитерного повторителя прекрасно справляется с задачей стабилизации напряжения. Но если потребуется увеличить ток - ставим более мощный транзистор . Но так работает не до бесконечности. Начиная с какого то момента придется пересматривать схемотехническое решение , так как дальше уже не масштабируется данное решение. Так и у вас , при управление через ESP парой реле , считать значения с датчика температуры - это решение работает. Но дальше его невозможно масштабировать. И если вам дадут пример на две переменные - то вы не сможете масштабировать этот пример , когда у вас будет 100,200,300 переменных и еще столько же настраиваемых параметров.
Я думал что уже все закончилось...
Я этим с преподом в 1986 занимался. А датчики судя по фото совсем не изменились. Точно такие делали. Только наверное сейчас больше цифровой индикации добавили и запоминания измерений. А так не изменилось ничего. Только стрелочный показометр более нагляден при поиске точек.
Прием ДМХ512 данных, динамическая индикация - довольно легко получить описаннный вами эффект из за неправильного подхода к организации вывода на индикатор , не умелого использования прерываний и других особенностей, так как ДМХ512 работает на скорости 250000 - то прерывания по UART идут очень часто, и могут влиять на индикацию. Но это будет проявляться в плавающей яркости индикации. Но никак как вы пишите "Каждая цифра имела свою яркость (1 светилась ярче чем 8)."
Что то темните.
D vjtv
Скорее всего схемотехническая проблема с неодинаковой яркостью цифр индикатора.
В моем представлении качественный код = это код оформленный по принятым нормам в организации заказчика. есть определенные правила на количество отступов , использование только "пробел" вместо табуляции, как ставить {} скобки, как писать комментарии, как оформлять подпрограммы, ну и еще кучу всего что часто пишут про написание программ на С.
Прием ДМХ512 данных для нужного канала занимает не более 20 строчек вместе с инициализацией UARTа на нужный режим.
Основная работа это программирование меню для двух индикаторов и немного логики управления яркостью СД в зависимости от настроек и поступивших данных.
Эта фраза сильно отталкивает. в 99.999% будет проблемно сдать проект.
Это по каким критериям "качественный" ?
И чем готовый ДМХ драйвер для СД не устроил?
Для такой задачи , и пол малинны много. Здесь достаточно МК например PIC18F67J60 . Принимать ИК команды с пульта и слать коды в ТСП - проблем нет. Отправлять команды на привод по RS485(RS232) также не проблема. И ВЕБ управление под это дело сделать можно. А если хотите красоту ВЕБ интерфейса и разные варианты настроек и т.д. и т.п. - то лучше взять PIC32.
В начале 2000-х делали свои мини АТС 6х2, http://www.yakorev.com.ru/ats.shtml когда Панасоник стоил как крыло самолета. Так это было когда пошли офисы, сотовой вообще не было , а ТЛФ линий от города было ограниченно. Вот и садились на одну городскую линию по несколько человек. А сейчас есть и сотовая, и IP телефония, да и город уже любому желающему телефон пробросит.
По работе с линиями идущими от АТС можно нарваться на кучу стандартов , и это чревато.
Уже писали , проще готовое взять.
