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

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

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


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


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

Сообщений 31 страница 60 из 63

31

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

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

Это древнючая концепция для преподавания в институтах... времён царя гороха... для старючих МК типа ПИК и Мега... где на кристалле ничего и нет... Ещё это типа "универсальная" концепция... для "любых" МК... Типа "делай как я" и будет работать "всегда и везде"... т.е. типа аля ногодрыг... заложеная в концепт ардуины...
Сегодня эта концепция уже устарела настолько... что применять её стоит только в исключительных случаях...
Эта концепция не ложится на СТМ... на ПСОК... на новые МК от Микрочип, с их логическими ячейками и аналоговыми фронтэндами... не говоря о дсПИК и прочих новоделах...

32

Мне кажется, или разговор об алгоритме работы программы?

33

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

* есть некая однократно выполняющаяся инициализация и потом бесконечно повторяющийся цикл основной программы

цикл основной программы может быть и ваще пустым... Если задача позволяет... всё можно растолкать по прерываниям и каналам ДМА...

* на фоне этого фунциклируют аппаратные прерывания и подпрограммы обработчиков прерываний, кратковременно вклинивающиеся в основную программу в случайном месте

почему сразу "кратковременно"??? Так "в уставе написано"??? С приоритетами прерываний и ДМА это уже теряет актуальность...

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

могут и не использоваться... в отдельных случаях... если синхронность не нужна... Просто сногие лепят эту "синхронность" где она нужна... и где она не нужна...

34

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

Мне кажется, или разговор об алгоритме работы программы?

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

35

У меня все это выглядит следующим образом :
1-ое и самое важное ИДЕЯ
2) попытка организовать все в лоб ногодрыгом. отдельные участки идеи получаются...
3) начинаются листочки бумажки, прикидки, отдельные алгоритмы, схемы алгоритмов.
4) во всем этом многообразии безобразия выстраивается логика, но она уже никуда не записывается, а реализуется...
как то так. мне кажется что, мои алгоритмы будут понятны только мне, да и то не всегда...
а донести их до кого то... зачем? кому надо тот сам зацепится за 1-ое самое важное, а остальное у каждого свое.

36

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

1-ое и самое важное ИДЕЯ

+

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

+

Только не зря... в журналах и статьях не приводят сам алгоритм... а подробно расписывают сам принцип работы...
На производстве... видели тома подробнейшей документации??? Наверное не зря...

кому надо тот сам зацепится за 1-ое самое важное, а остальное у каждого свое.

+

37

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

Только не зря... в журналах и статьях не приводят сам алгоритм... а подробно расписывают сам принцип работы...
На производстве... видели тома подробнейшей документации??? Наверное не зря...

нет не видел. с удовольствием посмотрел бы. может после осилил бы "...подробно расписать сам принцип работы..."

Отредактировано RA (2018-07-16 20:22:37)

38

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

Это древнючая концепция

Древнючая, да, вместе с мк наверно и родилась
DMA, кстати, тоже древнючая фича, и отлично вписывается в этот концепт, т.к. ничем не отличается от любых других протяжённых по времени операций [таймерных, например, однократных или циклических]
Тем не менее, насколько я понимаю, именно этот концепт в эмбеде везде и всеми подразумевается как само собой разумеющийся, причём до такой степени, что это даже не проговаривается специально
Приоритеты прерываний добавляют только, что обработчики прерываний могут вклиниваться не только в основную программу, но и в менее приоритетные обработчики прерваний, и тоже в случайном месте

39

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

Тем не менее, насколько я понимаю, именно этот концепт в эмбеде везде и всеми подразумевается как само собой разумеющийся, причём до такой степени, что это даже не проговаривается специально

Потому что... думать головой уже стало не модно... чтобы рассмотреть различные варианты...
ПСОК не в моде... новые МК от Микрочипа не в моде... даже у заклятых ПИКоводов... Так чему удивляться???
Пугает??? Меня нет... подобное и раньше было... тут уж кто на что учился...

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

Асинхронность... и это очень хорошо...

40

Еще кортексы прям созданы для многозадачности со своими двумя стеками, т.е. еще кроме прерываний и пользовательская программа может быть разбита на несколько абсолютно независимых участков со своими стеками, что позволит выполняться им в параллельном режиме. Так что на кортексах проще реализовывать то, что делалось на очень сложном автомате состояний на других МК.
   У меня даже появилась идея написать диспетчер задач + загрузчик и выделить ему первую секцию флеша и все он будет полностью независим от программы пользователя. А для пользовательской программы будет API для взаимодействия с диспетчером задач. Такую систему не нужно вклинивать в проект подключать библиотеки и т.д. нужно просто записать загрузчик и все. а дальше по идее отдельно писать свою программу не думая как работает диспетчер задач.

41

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

Потому что... думать головой уже стало не модно... чтобы рассмотреть различные варианты...

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

42

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

У меня даже появилась идея написать диспетчер задач + загрузчик и выделить ему первую секцию флеша и все он будет полностью независим от программы пользователя. А для пользовательской программы будет API для взаимодействия с диспетчером задач. Такую систему не нужно вклинивать в проект подключать библиотеки и т.д. нужно просто записать загрузчик и все. а дальше по идее отдельно писать свою программу не думая как работает диспетчер задач.

MasterElectric, проблема в том, что тем кто тебя поймёт, это не нужно рассказывать, а те, кому это нужно рассказывать, тебя не поймут

43

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

MasterElectric, проблема в том, что тем кто тебя поймёт, это не нужно рассказывать, а те, кому это нужно рассказывать, тебя не поймут

и MasterElectric
:) Я третий вариант. Где почитать об этой фиче?

Отредактировано RA (2018-07-16 22:27:10)

44

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

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

Где-то так оно и есть... После Бэйсика и АСМа плохо воспринимается Си... после Кодэвижэна - Студия... после ПЫХвасика и прочих тыкалок - вообще всё... после ПИКа и Атмэла - СТМ с его железом... Так что... СТМовские Куб и ХАЛ тут не исключение... и к ним кто-то привыкнет...

45

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

MasterElectric, проблема в том, что тем кто тебя поймёт, это не нужно рассказывать, а те, кому это нужно рассказывать, тебя не поймут

"Каждому своё."(с)...
А всем ли это надо...

46

Я читаю Joseph Yiu Ядро Cortex-M3 компании ARM Полное руководство. С английским плохо, но книга очень хорошо переведна.

47

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

Код:
struct {int f; ...} data1;
struct {int f; ...} data2;
...
void isr1 (void) {
    ...
    if (data1.f) isr1a; else {isr1b; data1.f = 1;}
    ...
}
void isr2 (void) {
    ...
    if (data2.f) {isr2a; data2.f = 0;} else isr2b;
    ...
}
...
void init (void) {
    data1.f = 0;
    data2.f = 1;
    ...
}
void main (void) {
    init;
    for (;;) {
        ...
        if (data1.f) {psr1a; data1.f = 0;} else psr1b;
        ...
        if (data2.f) psr2a; else {psr2b; data2.f = 1;}
        ...
    }
}

"Флажки" вообще могут быть более сложными, чем битовые [например, как в случае кольцевых буферов], но в любом случае вся флажковая логика должна быть явно расписана
И я сознательно не употребляю тут нигде слово mutex, потому что эмбеддерские флажки это нечто большее, чем мьютексы )

48

А сама мысль где... в чём прикол???

49

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

А сама мысль где... в чём прикол???

См на первой странице

50

Ходить по кругу... Не интересно...

51

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

Я читаю Joseph Yiu Ядро Cortex-M3 компании ARM Полное руководство.

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

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

HHIMERA, при всем уважении, я вот не могу уловить концепцию или философию ... Держать в голове какую то свою идею и ее воплощать без предварительного плана или подхода?  у меня в проекте 55кб текста и даже если прикинуть что это по моей глупости, то можно наверно скинуть 15кб. но останется еще 40кб . и держать в голове все функции, их взаимосвязи, да даже банально структуры с данными у меня не получится, я через пол года уже буду путаться в том какая идея у меня тогда то была и о чем я думал. поэтому чтобы в будущем не иметь каких то сильных заморок и легко врубаться в свой же код и самую идею, мне нужна система. ну или хотя бы подход к программированию МК.

52

оффтоп: программировать хорошо... А я вот сегодня 4 часа решал как можно малой кровью убрать косяк в плате который совершил разработчик схемы. все бы ничего если бы первая партия опытных плат уже не была на 95% запаяна комплектующими. :)

Отредактировано Atomic-dm (2018-07-18 00:47:03)

53

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

HHIMERA, при всем уважении, я вот не могу уловить концепцию или философию ...

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

54

Это все кончится ртос :)

55

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

vt, у меня примерно так все и устроено.

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

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

тема-провокация...

Нет, это моя последняя попытка найти какие-то формы какого-то конструктивного взаимодействия перед тем как оставить уже этот форум в покое и дать ему спокойно умереть

56

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

это моя последняя попытка найти какие-то формы какого-то конструктивного взаимодействия перед тем как оставить уже этот форум в покое и дать ему спокойно умереть

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

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

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

Есть ли смысл... говорить ни о чём???

==========
Ну и когда похороны??? Надо будет пару баянов прикупить...

57

А... да... пока венки не понесли...

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

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

Здесь немножко путаете понятия... С чего начинать разработку... не столь важно... но общий концепт уже всегда в голове... даже если он не на бумаге... и даже если он поменяется ещё не раз...

58

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

59

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

А по поводу взаимодействия... это как десять художников заставить рисовать одну и ту же картину... Всё равно всё будет по разному... потому что мы люди... и мы все разные... поэтому ещё и не вымерли...

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

60

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

Нет, это моя последняя попытка найти какие-то формы какого-то конструктивного взаимодействия перед тем как оставить уже этот форум в покое и дать ему спокойно умереть

мне кажется главному админу не стоит так говорить(даже если так он думает) :)


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