Как начать разрабатывать сложные устройства

Если вы - начинающий в электронике, то задайте ваш вопрос тут. Расскажите что вы уже сделали чтобы найти ответ на свой вопрос, опишите свои рассуждения.
wxthplvl65
Сообщения: 10

Сообщение wxthplvl65 » 12 апр 2017, 18:26

Электронщики, здравствуйте! Поделись пожалуйста, кто как разрабатывает сложные электронные устройства? Я так понимаю, сперва нужно нарисовать блок-схему из крупных прямоугольников, в которых надо написать основные функции устройства. Потом каждый прямоугольник разбить на более мелкие узлы и уточнить функции. Потом собрать каждый из узлов блок-схемы в железе, нагрузить имитаторами нагрузки и имитаторами входных сигналов и отладить каждый поотдельности. Потом соединить все узлы вместе. Как-то так делается?

Qic
Сообщения: 985

Сообщение Qic » 12 апр 2017, 20:03

Смотря что. Не всё так делается. Например СВЧ конвертер просто так не смакетируешь.
Прежде чем появился тот "ПЛК" которым Я поделился, ушло не мало времени и целых 3 итерации на макетных платах. Ну точнее не совсем итерации но пробы пера.
Узлы собираются отдельно, макетируются, проверяются, потом уже объединяется и снова проверяется.
Макет - прототип - мелкая серия - партия. Разве что после крупной партии которая уже производится на автоматизме можно сказать что устройство готово. (Ну это если производство).

wxthplvl65
Сообщения: 10

Сообщение wxthplvl65 » 14 апр 2017, 14:36

Про итерации и пробы пера я и не подумал ))

Qic
Сообщения: 985

Сообщение Qic » 14 апр 2017, 16:00

Даже при всех итерациях и пробах пера - сейчас Я программирую то что нарисовал в соседней теме, и узнаю много "нового" об элементной базе.
Для того что там опубликовано уже требуется вторая версия. А с увеличением функционала и 3..4..5...

wxthplvl65
Сообщения: 10

Сообщение wxthplvl65 » 14 апр 2017, 19:48

А что Вы программируете? ПЛК? СВЧ? Я просто здесь первый раз, дайте ссылочку на статью ))


Аватара пользователя
iEugene0x7CA
Адепт
Сообщения: 1570
Откуда: Киев

Сообщение iEugene0x7CA » 16 апр 2017, 00:47

Уууу, я могу многое рассказать о том, как делаются сложные устройства. :)

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

2. Никакого "я начну, а после как-то доделается", перед началом реальной разработки уже должно быть 100% понимание, как будет работать и как сделать.
Если это не заказ, а свой проект — можно около полугода ходить и вынашивать идею, экспериментировать с отдельными блоками, дабы в будущем считать таковые строительными...
Фактически, реальная разработка начинается тогда, когда в теории и много где на практике проектик уже готов. Разработка — это в основном допил конструкции, дабы ту можно было отдать неподготовленному юзеру.

3. Однако, упомянутая выше подготовка — это не фигня на палочке.
В реале, практически 70% работы — это дебаг/доработка и добавление защит от дурака. При этом на протяжении всего периода разработки будет казаться, что проектик уже вот-вот и готов.
Кстати, если бы не это чувство — думаю многие проектики даже не начали бы разрабатываться, ибо сознательно выделить год на то, что изначально фиг знает, будет продаваться или нет — адекватному человеку непосильно.

4. В крупной и длительной разработке однажды наступает момент, когда понимаешь, что уже потрачено слишком дофига сил и времени, релиз далеко за горизонтом, и не понятно нафига оно вообще нужно.
Такие моменты нужно нещадно давить, иначе могут перерасти в очень жесткий депресняк. Сами по себе они редко наваливают, практически всегда есть целая куча сторонних неудач, которые подвели к таким мыслям.
Лично мне, если на душе хреново — помогает сесть с блокнотом и составить список, чего конкретно плохого произошло. Вплоть до мелочей, вроде нахамившей продавщицы в магазине или сгоревшей где-нибудь лампочки.
У меня обычно под 20 пунктов набирается. Не удивительно, что после такого хреновые мысли лезут. :D
После отмечаю карандашом, какие проблемы совершенно не стоят волнения, в каких был виновен сам, какие можно исправить и на какие уже никак не повлияешь. В итоге, что разрешимо — решается, что не разрешимо — там все равно уже ничего не сделать и можно не беспокоится, а на какие можно забить болт — на те забивается болт. :)
Смысл этого пункта в том, что психика — препятствие намного более сложное в достижении целей, нежели реальные физические проблемы.
Обычно 80% препятствий человек себе создает сам, только 20% — реальные обстоятельства.

5. Офигенно важный момент — большие проектики нельзя делать одному, никогда.
Жизнь такая штука, что кроме мега-проектика всегда будет что-то еще, в этом чем-то можно утонуть на недели и даже месяцы, пока не одумаешься и не поймешь, что уже пол года проектик в долгом ящике.
Но когда работа ведется в команде — участники имеют негласные обязательства перед друг другом, все что-то делают и ожидают от остальных, чтобы те делали.
Итого, правильные разработчики — как полицейские, следят друг за другом в замкнутом круге. Да и ты сам, если нифига не делаешь — становится стыдно, что твоя работа на ком-то другом лежит. :D
Правда, магия эта работает только когда каждый из разработчиков считает проектик своим. Финальные прибыли от такового в идеале делить ровно поровну, даже если кто-то делал больше, а кто-то меньше.
Об упомянутом выше, одна из больших фич командной разработки — динамическое разделение труда. Если кто-то делает меньше — другой будет делать больше, и если чередовать это дело — получится условие, при котором без колоссальных напрягов неделями и даже месяцами можно будет пилить проектики в довольно приличном темпе.

6. Если же одному работать на 100%, особенно без возможности снизить темп(в случае заказа с дедлайном) — это гарантированно приводит к очень фиговому состоянию.
Будет болеть бошка, появится простуда, будет болеть желудок... И спустя несколько недель в таком состоянии — ты пожалеешь, что вообще взялся за проектик. А с упавшей продуктивностью можно и дедлайн завалить.
Кстати о них, называя время человек всегда учитывает безгемморную разработку и выкладку со своей стороны на 100%. Итого, таковые всегда рекомендуется умножать на 2.
Так уж устроена человеческая психика: если пообещаешь сделать за 5 дней, но сделаешь за неделю — тебя будут считать сволочью.
Если пообещаешь за 2 недели и сделаешь за 2 недели — тобой будут довольны, пожмут руку и все такое. А если пообещаешь за две, но сделаешь за неделю — тебя будут считать богом. :)
Ну, это касается короткосрочных периодов разработки. Если разработка займет несколько месяцев — просто запросить 6 месяцев вместо 3-х нельзя.
Популярной в таком случае считается формула x*(π/2)+2 недели, где x — предполагаемое время разработки, π/2 — половина окружности, а 2 недели нужны затем, что если все 3 месяца сидел и пинал буи — любой проект делается на коленке за 2 недели. :)

Ладно, и так уже простыню настрочил. :)

wxthplvl65
Сообщения: 10

Сообщение wxthplvl65 » 16 апр 2017, 03:41

Спасибо, ребята, столько всего порассказали!

Кстати, а длинные программы для микроконтроллеров так же пишутся?
Нас учили писать программы так: Сперва составить список всех входных параметров, потом список всех выходных параметров, потом составить блок-диаграмму (ромбики, прямоугольники). Естественно сперва из крупных блоков-подпрограмм, потом каждую подпрограмму на отдельном листочке расписать подробно, со своими локальными входными и выходными переменными.

Мне блок-диаграммы не нравятся, жутко неудобно. Услышал, есть метод графов (стрелочки и узлы). Попробовал - понравилось больше. Блок-диаграммы громоздко вырисовывать надо, а графы - чисто полет кисти.

Не знаете, есть ли книги по построению программ на графах?
Вложения
Блок диаграмма.JPG

Qic
Сообщения: 985

Сообщение Qic » 16 апр 2017, 11:25

Наш Кодер вертел на причинном месте блок диаграммы. К томуже специфика программ такая что они сильно модульные, это будет пачка несвязанных диаграмм.
Да и смысла нет делать длинные нечитаемые куски. Чем проще выглядит тем надёжнее работает.

wxthplvl65
Сообщения: 10

Сообщение wxthplvl65 » 16 апр 2017, 16:47

То есть лучше использовать словесное описание программы, как это делали в советских школах?
Вложения
прог.jpg

Аватара пользователя
iEugene0x7CA
Адепт
Сообщения: 1570
Откуда: Киев

Сообщение iEugene0x7CA » 16 апр 2017, 17:07

Ух, мне как-то довелось разбирать графовую диаграмму, в даташите на nRF24L01+.
https://www.sparkfun.com/datasheets/Com ... n_v1_0.pdf
Страница 21, зацените как интуитивно отображены все состояния транссивера. :)

wxthplvl65 писал(а):Не знаете, есть ли книги по построению программ на графах?

У нас на форумчике как-то проходил товарищ, требовавший книги по правильному откручиванию и закручиванию болтов. :)
ИМХО — делай как тебе удобно, можешь даже свою методику придумать...
А что старпёры в универах преподают — так они сами это из книжки вычитали, это не настоящие программисты и за авторитет их мнение держать не стоит.

Qic
Сообщения: 985

Сообщение Qic » 16 апр 2017, 19:57

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

Аватара пользователя
Fernanda
Сообщения: 16

Сообщение Fernanda » 18 июн 2017, 14:32

Спасибо за информацию. Тоже было интересно

Вернуться в «Для начинающих»



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя