[NEMOOMEN- RE 0]

Я живу не в Москве. Есть не мелкая дистанционная работа (написание ПО) - частный заказ (не фирма). Не для массового производства. т.е. переписывания Т.З. соответствующего установленным ГОСТам, для работы на предприятии не требуется. Работа не срочная, т.е. если кто-то может, но не сейчас, а потом, то я подожду. Но тянуть, месяцами тоже не устроит.

Имеется такая электроника (см. рис.1) и ПО (управление по USB), которая является прототипом элемента управления для сложного электровакуумного прибора, почти готового. Увлекаюсь квантовой физикой, но слаб в программировании. Это информация для предварительного ознакомления.

На 1-м рисунке предмет управления (блок-схема). Все программируемые модули в наличие (шесть одинаковых и два разных + датчики). Количество и тип плат соответствует исходя из функционального и конструктивного их применения. Для большинства программируемых модулей (mastrer и slave) и датчиков имеется ПО. Ссылки: к master (здесь, master) и к slave (slave-1 slave-2) имеются примеры готового софта, которое надо адаптировать, для данной задачи или использовать своё, если это не устроит.

 

На 2-м рисунке, то, что хотелось бы получить (в идеале) → способ управления (планшет-d10÷12"). Возможен другой вид и другие способы: ПК (?), мини ПК+ тв+ мышь, мини ПК+TFT сенсорный экран. До конца ещё не определился (зависит от исполнителя). Больше хочется с планшетом. Пока нет, но приобретение не проблема (какой: на Windows или Андроиде), т.к. это вариант двойного назначения. Но сомневаюсь в возможности установки на планшете виртуальной динамичной сенсорной панели, а не просто набора статичных андроидовских иконок. Хотя вот интересный пример организации виртуальной панели, для планшета. Рис.2 составлял эмпирически в среде LabView 8.6. (если можно по-другому не против). Кстати, LabWiev не единственный вариант с виртуальной панелью управления. Просто более распространённый.

Если трудности с окном видео, т.е. не хватает ресурса МК (master) или варианта управления, или другие не технические причины, то это можно обсудить отдельно. Хотя, на мой взгляд, это не проблема. Видео представляет собой: бескорпусную широкоугольную камеру, передающую в ИК изображение слабосветящегося и статичного объекта. Т.е. поток данных с него минимален. Думаю, вообще изображение сделать анимационным, чтобы отражало только динамику геометрии объекта (в реальном времени) и его наблюдаемость. Хотя, если с этим трудности, то можно вообще вывести на отдельный монитор и исключить из задания, как элемент программирования. Но хочется, чтобы всё было на одном экране.

И о динамике изменения параметров. После загрузки системы и выставления заданных параметров, всё довольно статично. Никаких быстроменяющихся параметров (процессов), в массовом количестве, не предвидится.

 

Если, в общих чертах, внимательно изучив эти рисунки (там указано что входит и что выходит), понятен смысл задания, то опытный исполнитель должен представлять примерный объём работы и сделать вывод о стоимости данной работы, которая не должна сильно отличаться (в «+») от конечной стоимости. Т.к. написание ПО более конкретное задание, чем создание «с нуля» некого устройства, да и мой бюджет ограничен.

Если кто-то заинтересовался данным предложением, то (т.к. личка не доступна) пишите, пожалуйста на мой E:mai: [email protected] (тема Прибор-ПО), c указанием суммы, за которую вы готовы взяться, какие ваши условия, способы общения (контактные данные) и по возможности краткое резюме. Если предварительная оценка будет меня устраивать (мои возможности), то я высылаю на ваш E:mail (с кем договорюсь), подробное Т.З. в котором указаны алгоритмы работы всех программируемых модулей, датчиков и т.д. Если после рассмотрения полного Т.З. намерения исполнителя не изменились, то согласовываются все технические и прочие вопросы взаимодействия, оплаты и т.п.

Изменено 29 июля, 2017 пользователем NEMOOMEN- RE

[smart_pic 7]

Приятно видеть неплохо проработанное ТЗ. Хотя вопросов по устройству еще будет достаточно много.

Подобную систему можно сделать на HTML5 и AJAX технологии . Это дает независимость от платформы т примененных средств контроля и управления и также ОС. Получится распределенная система работающая в локалке. Каждое устройство имеет свой ВЕБ интерфейс настроек и можно настраивать просто переключаясь между страницами. Данные измерения через AJAX отображаются на страничке. Видео можно отображать встроенными средствами в браузер, для этого нужно сформировать видео поток. В таком случае получится распределенная система , более отказоустойчивая , чем в вашем случае. Питать модули можно по РОЕ, что даст гальваническую развязку, которая нужна при наличии нескольких управляемых БП.

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

 

[Eddy_Em 1]

EasyCap — гадость, натыкался уже. Купил один на попробовать — взлетело моментально. С радостью взял еще 4 таких — коту под хвост: оказывается, они уже на другом чипе были, для которого модуля ядра нет и не будет, т.к. никому они не нужны.

Я так понял, совершенно все железки уже есть? Печально. Зря устаревший авр используете, лучше бы все на ARM'ах делали. Тем паче, их цена совсем невелика.

[linuxbergi 0]

Бросается в глаза необоснованная неоднородность системы. Шина I2C не совсем подходит, ограничена пропускная способность, да и помехозащищённость не очень, в лабораторных условиях нужна промышленная сеть, может CAN. Остановиться на каком-нибудь современном контроллере, сделать типовую плату(или лучше купить), наваять типовую библиотеку для коммуникаций. Ну и внешние схемы для съёма сигналов с датчиков. Такую как представлена, затратно реализовывать, отлаживать и развивать.

[jcxz 184]

Бросается в глаза необоснованная неоднородность системы.

Да, я тоже сразу хотел об этом сказать. Полностью с Вами согласен.

Сразу видно, что строил схему человек далёкий от разработки МК-систем. Сочувствую тому несчастному, кто возьмётся сиё реализовывать (если вдруг таковой найдётся ;)

Яркий пример того, что получается, когда кухарка пытается управлять государством. :laughing:

Первым делом нужно конечно выкинуть весь этот зоопарк из макетных плат. А блок-схему делать специалисту. Заказчик должен делать не блок-схему, а функциональную схему.

[_pv 52]

ну и до кучи ещё бы вместо мастера взять любой одноплатный ПК для работы с видео, связи с внешним миром и пользовательским интерфейсом, а то что на нём сейчас висит вроде датчиков тока передать слэйвам.

а в качестве слэйвов куча avrов на i2c, для того чтобы сделать несколько десятков каналов ШИМа, тоже не самый лучший выбор.

тем более что раз они на I2c висят, значит не особо раскиданы в пространстве, соответственно можно было бы и одним слэйвом пожирнее обойтись.

 

просто в качестве примера, хоть и тоже собрано на "макетках" Rasberry PI + вроде бы DE0:

https://indico.esrf.fr/indico/event/4/sessi...al/slides/1.pdf

 

[jcxz 184]

а в качестве слэйвов куча avrов на i2c, для того чтобы сделать несколько десятков каналов ШИМа, тоже не самый лучший выбор.

тем более что раз они на I2c висят, значит не особо раскиданы в пространстве, соответственно можно было бы и одним слэйвом пожирнее обойтись.

Пограммист требуется один. Значит он один должен изучить и эти оба этих AVR (их там 2 разных вроде) и SAM7X. И ПО и для того и для другого и третьего написать и отладить для всего этого зоопарка.

И это всё ради одного устройства??? Время (и цена) всего этого изучения/разработки будет неизмеримо выше покупки одного мощного контроллера со всей необходимой периферией и достаточным кол-вом ног, чтобы вывести все эти сигналы. Ну если ног не хватает по любому - то покупкой нескольких одинаковых МК. Так как гораздо эффективнее в данном случае сократить время на разработку, ведь именно она будет главной в цене, а не разница в цене между AVR и ARM.

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

И отладка сетевого взаимодействия между несколькими устройствами (да ещё на разных МК) будет тем ещё делом ;)

[Eddy_Em 1]

Если там еще и на компе мастдайка, то совсем уж будет уныло бедняге-программисту...

[AlexandrY 3]

Если после рассмотрения полного Т.З. намерения исполнителя не изменились, то согласовываются все технические и прочие вопросы взаимодействия, оплаты и т.п.

Как раз у меня сейчас на столе контроллер со всеми необходимыми функциями.

Имеет 12 ШИМ каналов.

Выведен интерфейс I2C.

2-а буфферизированных интерфейса SPI, 20 МГц до 1 метра

Интерфейс CAN до 1 Мбит

Несколько каналов 16-и битных дифференциальных ADC.

Встроен приемопередатчик Bluetooth LE 4.1, NV RTC, NV RAM, micro SD, Li-on charger, USB HS 480 Мбит и т.д.

Цена комлекта около 100 евро в розницу.

[jcxz 184]

Как раз у меня сейчас на столе контроллер со всеми необходимыми функциями.

...

Цена комлекта около 100 евро в розницу.

Осталось Вам только продать его ТСу ;)

[Kosta 0]

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

[linuxbergi 0]

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

 

В самом подходе к реализации чувствуется непрофессионализм. Задача раскладывается на 2 уровня, уровень системы и уровень блоков. Один специалист работает на уровне системы и формирует задания для специалистов блоков. Задача специалистам блоков должна ставиться так, что бы они могли выполнять работу не вникая в особенности реализации всей системы. Конечно управляющее ядро должно разрабатываться специалистом, знающим задачи системы целиком. Первое, нужно позаботиться о создании стендовых заглушек, подключая к которым можно было бы в живую отлаживать блоки, независимо и параллельно. Да и разаработчику управляющей программы нужен имитатор объекта управления. Хотя всё зависит от сложности объекта управления. Физик должен сформулировать задачу в технических терминах не затрагивая вопросов реализации.

[Kosta 0]

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

...

Физик должен сформулировать задачу в технических терминах не затрагивая вопросов реализации.

 

Сильно зависит от уровня абстракции применяемой RTOS, а стандарты это также - стиль написания, тесты и хорошее документирование, а не только транспортные протоколы.

А в целом ваша мысль верная, да и никто, ещё, не отменял ошибок в самих МК.

 

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

[smart_pic 7]

Изучил ТЗ на разработку.

Возник вопрос как всегда про метрологические характеристики прибора и соответствующие возможности железа. Сразу возникает ряд нестыковок.

1. Необходимо формировать напряжение в диапазоне 0-400В с шагом 5В. Получается , что нужно 80 шагов. Для этого нужен 7битный управляющий код. Добавим сюда нелинейную зависимость напряжения от ШИМ сигнала на входе и то что в запасе всегда надо иметь 2младших бита. Приходим к необходимости иметь 10битный ШИМ. В процессоре всего 4 канала ШИМ (аппаратных). поэтому нарываем на неприятности

2. Автор предлагает программный ШИМ. Частота ШИМ должна быть более 10кГц. ,а это значит что частота прерываний должна быть (учитывая предыдущие выкладки) в 1000раз больше . Примерно 10МГц, что нереально для данного процессора .

3. Использую шину I2C нарываемся на массу неприятностей, которые обязательно вылезут.

 

и это еще не все .

 

Вывод: демонстратор работы на предложенном ТС железе собрать можно. Характеристики будут на один два порядка хуже относительно ТЗ, но это будет работать. Это можно использовать для формирования ТЗ (что видимо ТС и сделал). А дальше нужно аппаратную и программную базу делать с 0 , опираясь на опыт разработки.

 

 

[jcxz 184]

В процессоре всего 4 канала ШИМ (аппаратных). поэтому нарываем на неприятности

В каком именно процессоре? Они разные бывают. Бывают и с количеством каналов ШИМ много больше 4.

Да и сам ШИМ бывает разный :laughing:

Или по Вашему всё что не PIC - не процессор?

 

Частота ШИМ должна быть более 10кГц. ,а это значит что частота прерываний должна быть (учитывая предыдущие выкладки) в 1000раз больше . Примерно 10МГц, что нереально для данного процессора .

Под "частотой ШИМ" обычно понимают частоту работы таймера ШИМ (точнее - частота обновления регистров сравнения таймера ШИМ).

А сигнал который формирует ШИМ - это "частота сигнала формируемого ШИМ".

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

Где нужно 1000раз - не очень понятно.

И тем более не понятно при чём тут какая-то "частота прерываний"? Что это такое и зачем она для ШИМа вообще?