Микроконтроллеры

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Микроконтроллеры » Всё остальное » Трассировка без схемы


Трассировка без схемы

Сообщений 1 страница 30 из 63

1

Стадии разработки платы: схема, трассировка, изготовление, отладка, но в принципе, можно и без схемы [и я сам иногда так делаю, схема в голове, детали в даташитах]
Проводя аналогию между разработкой платы и софта, эмбеддерское программирование - трассировка без схемы [кодирование, компиляция, отладка]
Что такое "схема" для софта - сложный вопрос, нет однозначного ответа, но определённо не архаичные нарисованные блок-схемы

2

До недавнего момента тоже делал плату без схемы. И лишь с течением времени понял что правильнее (и даже дешевле) делать вначале схему и только после этого разводить плату. Пользуюсь Diptrace и очень нравится. даже если в готовой плате что-то меняю, то всегда могу при помощи программы проверить плату и сравнить со схемой. Единственный минус - это чуточку дольше времени занимает, но оно окупается с лихвой. Ну естественно я говорю не о самых элементарных схемах в которых минимум элементов. Элементарные можно и так рисовать.  Опять же - я пришел к этому в процессе работы.

С софтом в принципе все примерно также. Раньше все лепил в main.c , потом пришло понимание что отдельные куски кода удобнее держать в разных файлах. инициализацию в одном, работу с дисплеев в другом, работу по сети с другими устройствами в третьем и т.д.  Чуть позже пришло понимание и о структуре самой программы, в которой отдельная часть является настроечной(инициализация), ну думаю как у всех, другая часть является расчетной, в которой производится работа с данными, третья часть является частью работы с внешними факторами (сигналы от устройств, нажатие кнопок, сигналы от датчиков). там же порой происходит обмен с другими устройствами. Есть еще независимая часть интерфейсная или лучше сказать часть "отображение", т.е. то что именно служит информации для пользователя, для другого устройства. она ничего не анализирует, а просто выкидывает на какую то линию данные.
Трудно назвать такую конструкцию схемой, но на данный момент для меня это является некий скелет программы, который я держу в голове и с которого все начинается. Так же обычно я прикидываю основную задачу устройства и для начала программирую именно эту часть, иногда эмулирую входные данные, смотрю на результат. смотрю через отладчик. и когда основная модель работы работает, я перехожу к интерфейсной часть и внешним коммуникациям. Если внешняя часть работает с модельной частью, то я уже заморачиваюсь с частью "отображения" - к примеру вывод на дисплей. Понял что с дисплеем заморачиватся надо ближе к концу, так как работа с дисплеем не столько программирование , сколько удобство визуализации и зачастую программист не делает красиво, а делает как удобнее. Поэтому в моем случае я попросил другого человека нарисовать интерфейс и подобрать шрифт. (шрифт кстати он сам потом в hex переводил) и когда "дизайнер" доволен и доволен еще кто-то , я просто беру и воплощаю это на экране.

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

3

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

4

Янь... Инь... Сунь... Вынь... "... и умерли в один день."(с)...
А не надо путать.. блок-схему и принципиальную... и алгоритм с текстом проги...

5

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

6

Atomic-dm написал(а):

Кстати еще на счет схем. Не имея схемы не получится проконсультироваться с другими специалистами и узнать их мнение

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

dosikus написал(а):

затрудняются связать все в единое.
И зачастую кидаются на оси , протосреды и прочую хрень .

+1
А в эмбеде всё еще осложняется, что ещё и железо надо в единое целое с софтом увязывать

HHIMERA написал(а):

не надо путать.. блок-схему и принципиальную... и алгоритм с текстом проги...

Что такое алгоритм программы для мк? Как его описать? Как его обсуждать?
Словами литературного языка?
Это долго, нудно и неоднозначно [слова обычно каждый понимает по своему]

7

Потому что всё это херня... Первична сама идея... всё остальное вторично... и не принципиально... по сути...
Мне и литературного хватит... чтобы ухватить саму идею... многа букафф кода я и сам напишу... пусть даже и не сразу... зато как я хочу... Всё зависит от уровня "в теме"... и от умения работать с документацией МК... Чужой говнокод мне вообще не интересен... там всё равно практически всё не так... его как на глобус натягивать... так проще переписать заново...

8

HHIMERA написал(а):

Потому что всё это херня... Первична сама идея... всё остальное вторично... и не принципиально... по сути...
Мне и литературного хватит... чтобы ухватить саму идею... многа букафф кода я и сам напишу... пусть даже и не сразу... зато как я хочу... Всё зависит от уровня "в теме"... и от умения работать с документацией МК... Чужой говнокод мне вообще не интересен... там всё равно практически всё не так... его как на глобус натягивать... так проще переписать заново...

а потом этот код попадет к другому специалисту и он в этом коде погрязнет или наоборот тебе на новом проекте попадет такой код и ты будешь все переписывать по пол года. короче такое мнение совершенно не конструктивно.

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

9

Ващета... МК первоначально и разрабатывался под разработку проекта одним человеком...
С чего меня должно интересовать... кто там и как будет разбираться в моём коде??? А нефиг туда ваще лезть...
В чужом коде... как-нибудь разберусь... если надо будет...
Да и ваще... колхозно-групповой отстой на МК мне просто не понятен... А если АСМ и без коментов???

10

Atomic-dm написал(а):

но команда сделает всегда быстрее и лучше чем один человек....а именно работе (любой)

а вот тут Вы не правЫ. И один может сделать быстрей и качественней чем команда. Если командой не кем управлять или управление как у "Вована" (В.В.П.). где то сильно, а где то одни фантазии и амбиции.
выводы на основе сказок - сказочны.
а если пересчитать в деньги через человеко час, то эффективней всегда работа одного человека, а группа всегда ведет падению эффективности. и чем больше группа тем сильнее падение. это не теория это практика. есть исключение, грамотная мотивация каждого члена группы - но это уже фантазии.

Отредактировано RA (2018-07-12 22:34:59)

11

RA написал(а):

а вот тут Вы не правЫ. И один может сделать быстрей и качественней чем команда. Если командой не кем управлять или управление как у "Вована" (В.В.П.).

Отредактировано RA (Сегодня 22:29:20)

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

HHIMERA, лесть в чужой код надо когда там находятся ошибки или нужно что-то добавить, а разработчика нет ( уволился, запил, умер, вариантов масса)

12

RA написал(а):

а если пересчитать в деньги через человеко час, то эффективней всегда работа одного человека, а группа всегда ведет падению эффективности. и чем больше группа тем сильнее падение.

совершенно не согласен.
я вот например недавно переезжал и один я физически не мог перетащить большой шкаф с пятого этажа до грузовой машины. эффективность ноль. мой друг в одиночку тоже это сделать не смог бы, а если бы и смог то пришлось бы делать это весь день, аккуратно и медленно скользя по ступенькам , отбивая куски шкафа. а когда мы вместе, мы просто взяли и за 5 минут отнесли его в машину. Эффективность системы всегда больше чем сумма эффективностей отдельных элементов.  Опять же - если система работает. Именно поэтому существуют бригады ремонтников, бригады врачей, бригады лесорубов и т.д.

P.S. есть конечно и нюансы которые могут срубить эффективность всей системы. например двое работают очень хорошо и появляется третий и подбивает этих двоих "сообразить на троих" .Вот тогда да, эффективность упадет в нол. но это скорее частный случай

Отредактировано Atomic-dm (2018-07-12 23:15:36)

13

Atomic-dm написал(а):

большой шкаф

можно разобрать. быстро и эффективно и перетащить одному...
я излагаю свое видение... и не претендую на всеобщемирогалактиковсеобъемлеющую истину и правду последней инстанции.

Отредактировано RA (2018-07-12 23:47:55)

14

МК становятся всё более мощными и сложными, ещё недавно даже процессоры компов были слабее нынешних мк
Эмбеддеры, как программисты, делают, по сути, системы для мк, аналогично тому, как системные программисты делают операционные системы для компов
Но эмбеддеры это нифига не системные программисты [системные программисты делают RTOS-ы, HAL-ы и т.п. штуки для мк], и всё прокатывало только пока мк были маленькими

Во времена i386 никому не приходило в голову шарашить ему свой софт с нуля [хотя отдельным гикам приходило, конечно]
А собственно почему? i386 слабее нынешних arm v7 и RM на него не сложнее
Времена изменились, железо сильно изменилось, а сильно ли изменилась прослойка между стулом и клавиатурой? )

15

Мне кажется что эта "прослойка" приходит к МК с двух совершенно разных сторон. Первая это электронщики которые решили что МК это хорошее дополнение в их системах построенных на аналоговых компонентах. Другая часть это программисты софта со знанием языков высокого уровня и привыкшие писать приложения для desktop'а. Первые мыслят регистрами и сигналами, вторые мыслят объектами и ООП. и где-то посередине они встречаются в программировании МК. Мне кажется в разных ситуация оправдан и тот и другой подход.

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

16

То есть ты считаешь, что нынешние электроники [и особенно российские] во времена i386 были бы способны делать то, что тогда делали системные программисты?
Не смеши меня, они были бы неспособны делать даже то, что делали тогдашние электроники )

17

Нет, я не считаю, я просто говорю как есть на данный момент :)

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

Если что , во времена i386 я был средней школе и на уроках программирования мы рисовали исключительно блок-схемы, потому что компьютеров было мало и нас к ним особо не подпускали :)

Отредактировано Atomic-dm (2018-07-13 15:14:35)

18

Нет, я не про то, что небо было голубее
Я про то, что железо развивается по экспоненте, а мозги по логарифму, и рано или поздно "схемы в голове" неминуемо приведут к разрыву мозга )

19

vt написал(а):

Не смеши меня)

Вот сам и не смеши...
Пик12 это МК... Тини это МК... СТМ8С001  тоже МК...
Так вот... Железячник на что угодно прогу напишет... если надо... РС-братан не сможет... потому что пробивая дно собственных познаний... он упрется в грунт отсутствия поддержки таковых в ардуине... Да и в СТМ32Н он сядет в лужу с пузырьками... если ему либы на блюдечке не поднести... а к чтению даташитов он попросту не приучен...

20

vt написал(а):

Нет, я не про то, что небо было голубее
Я про то, что железо развивается по экспоненте, а мозги по логарифму, и рано или поздно "схемы в голове" неминуемо приведут к разрыву мозга )

А стоит по этому поводу переживать????

21

Atomic-dm написал(а):

Если что , во времена i386 я был средней школе и на уроках программирования мы рисовали исключительно блок-схемы, потому что компьютеров было мало и нас к ним особо не подпускали


И мацали на нарисованной на доске клавиатуре?

22

dosikus написал(а):

И мацали на нарисованной на доске клавиатуре?

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

потом правда всех этих учителей уволили(10-11 класс школы) и пришли молодые (только только закончившие вуз) и вот они нам начали нам давать основы ...DOS, Паскаль, а чуть позже(на немногочисленных i486) windows 3.1 и  Netscape Navigator.  (а так же Doom , Duke Nukem 3D и подобное)

23

HHIMERA написал(а):

Вот сам и не смеши...
Пик12 это МК... Тини это МК... СТМ8С001  тоже МК...
Так вот... Железячник на что угодно прогу напишет... если надо... РС-братан не сможет... потому что пробивая дно собственных познаний... он упрется в грунт отсутствия поддержки таковых в ардуине... Да и в СТМ32Н он сядет в лужу с пузырьками... если ему либы на блюдечке не поднести... а к чтению даташитов он попросту не приучен...

все от человека зависит. я вот до МК даташиты тож не читал и начал увлекаться МК с ардуины, потом HAL, потом SPL.  сейчас уже мой код 50 на 50 состоит из CMSIS и SPL, да и даташиты читаюся уже гораздо легче.
Думаю все зависит от человека и от его желания развиваться и учиться новому. Если желание мало то от ардуины далеко не уйти. А если желание есть, то ардуино это первый шаг , за который стоит бесконечно длинный и интересный путь :)

24

HHIMERA написал(а):

РС-братан не сможет...

PC-братаны разные бывают )
https://www.cambus.net/emulators-written-in-javascript/
http://www.godevtool.com/
Это навскидку, из закладок, а если повспоминать и поискать, то большой список будет )

25

Да в теме какбэ не первый год... на большинстве форумов знаю... кому поверить... кого послушать...
Сейчас повылазили "новые" ХАЛ-черти из табакерки... На изыйди и казусе срачи периодические... А за ними ничего... ни идеи... ни решений... ни мысли... пустота кромешная... одни понты типа "на ХАЛе подключил ТФТ и ЮСБ"... Ну РС-неудачники... они такие...
На ардуино... Вот вроде крестанутые... ну что гвоздями прибитые... им нужно 3 ардуины... 5 ардуин...  10 ардуин... чтобы что-то слепить... Они их ЮАРТами... СПИями закочегарят... ага... высокие технологии... мля... на высоком уровне...
Такшта... удачные примеры из жизни програмеров это быстрее исключение... если говорим об эмбедде... а не о крупных компаниях...

26

Я думаю, что армовые мк, а особенно вендоры армовых мк - могильщики того лампового эмбеда который дорог моему сердцу )
И думаю с этим уже ничего не сделать - эмбеддеры будут писать только прикладной софт поверх системного софта вендора
Ну были у меня намерения вылезти и поссать против этого ветра, но для этого нужна сильная струя - против системы может быть только другая система, а не слова и идеи
Так что х51 - наше всё

Отредактировано vt (2018-07-13 20:03:44)

27

vt написал(а):

Я думаю, что армовые мк, а особенно вендоры армовых мк - могильщики того лампового эмбеда который дорог моему сердцу )
И думаю с этим уже ничего не сделать - эмбеддеры будут писать только прикладной софт поверх системного софта вендора

А да пофигу... меня это совсем не печалит... Пока понтарей от ХАЛа больше чем соображающих в этой кухне... Печалит меня ардуина??? Тануна... два-три писаки... остальные - стадо баранов...

28

Ладно, если без лирики, то я этот топик заводил, чтоб попробовать разобраться, что это за софтовые "схемы", которые в голове, и возможно ли их как-то формализовать
Насколько я понимаю [в самом общем виде, простыми человеческими словами]:
* есть некая однократно выполняющаяся инициализация и потом бесконечно повторяющийся цикл основной программы
* на фоне этого фунциклируют аппаратные прерывания и подпрограммы обработчиков прерываний, кратковременно вклинивающиеся в основную программу в случайном месте
* если основная программа и обработчики прерываний используют какие-то общие данные, то для синхронизации доступа к этим данным используются флажки

29

Мне тоже кажется что это основная концепция.

30

Я сейчас в познавательных целях и не только делаю что-то типа ПЛК, где ядро будет перебирать какие-то функциональные блоки в определенном порядке, а между блоками будут гибкие связи (на этапе построения логики). В принципе даже самую сложную задачу можно разбить на кусочки и соединить их нужным образом. Пробую такой подход для укрепления переносимости кода между проектами, даже понимая что скорость выполнения сильно упадет, но все-равно это самое интересное что я делал в жизни. В итоге будет диспетчер задач + загрузчик + перебиратор функций. Например "5ИЛИ" "5И" заняли по 46 байт, чтение и запись ноги по 14 байт. Подход признаю Ардуиновский, но возможно будет работать быстрее HAL.


Вы здесь » Микроконтроллеры » Всё остальное » Трассировка без схемы