Периферия имеется в любом МК и в любой комбинации.
Вот так вот с ходу, не читая и не думая... Есть да не та.
BOB51 писал(а):
Ну а Ваша, уважаемый dosikus, сторчка "BOB51, весьма сомнительные потуги считать себя умнее Сишных компиляторов." простое хамство при отсутствии "чего по теме сказать".
Ваше многолетнее топтание на месте гарант моих слов, и отрицать их все равно что, утверждать что земля имеет форму чемодана . А обижаться или нет это ваше право, будь вы умней не окрысились бы а прислушались. Но видно не судьба ...
Вот уж настырный "профлудист-dosikus", снова прицепился. Как в прошлый раз, когда доказывать начали "хайль АРМ!" и "STM юбер аллес!" с более чем в три раза превышающим исходный материал флудом. Это вместо своих вариантов разбора прикладных возможностей указанных МК с соответствующим приложением. Так вот и сейчас - всего-то только один из мелконачальных вариантов "ответных действий" весьма бурную реакцию вызвал - я здесь ассемблер разбираю, а не СИ (при всем уважении к знатокам данного языка). Есть замечания/наработки по материалам изложенным в теме - милости просим, а флуд плодить... Я ж в Ваш срач на viewtopic.php?f=62&t=35768 не вмешиваюсь. Да и ассемблер даже для STM8 вычитывать не заставляю - просьба не флудить для "выпуска пара" после очередного тамошнего (viewtopic.php?f=62&t=35768) поцарапца.
Теперь к конкретным вопросам по мере ознакомления с документацией на систему команд.
Покопался еще немного в системе команд и немножко в части аппаратной поддержки CPU. Вылез на повестку дня вопросец – как будет исполняться загрузка стека (и будет ли таковая вообще) если внешнее прерывание будет обслуживаться после команд HALT/WFI при условии, что CFG_GCR AL=1? Согласно того же PM0044 стр.15 такой статус CFG_GCR AL=1 дает указание для IRET не возвращать содержимое стека при выходе из прерывания при предваряющей прерыванию команде WFI/HALT. НО… Тут весьма странная «ловушка» имеет место: Если, как предполагать по документации, внешнее прерывание всегда обеспечивает сохранность контента (Y, X, A, CC) в стек, то при возврате мы можем иметь проблемы с содержимым стека. Далее о какой части контента стека идет речь – ведь адрес возврата будет в любом случае отработан? Если о кусочке из Y, X, A, CC то там должна быть коррекция содержимого указателя стека как минимум… Плюс лишние операции по загрузке стека на входе в прерывание, от которых данная фишка собственно и должна избавлять по замыслам изготовителя... Можно лишь предположить, что в вышеуказанной ситуации прерывание в любом случае выполнит начальную загрузку стека по общим правилам, а вот IRET должна скорректировать указатель стека на адрес возврата и выскочить на нужное место без восстановления Y, X, A, CC. При том, что машина должна знать что такое действие для IRET выполняется только в случае с предшествующим прерыванию WFI/HALT и не касается нормального режима работы. Однако это только моё предположение… В описании команд WFI/HALT о такой ситуации информации не имеется. В описании системы прерываний также нишыша не нашел… Второй вопросец – о каких линиях прерывания идет речь в командах JRIH и JRIL – статус состояния «какой-то» линии, но какой конкретно?
Такая-же feature реализована в ARM-ax. Именно, имеется возможность не возвращаться назад из прерывания. Об этом написано во многих книгах, а здесь на форуме также упомянуто, например, в моей статье. Прочитайте абзац в ней, начинающийся словами "В программе приняты меры по минимизации нагрузки на стек.".
BOB51 писал(а):
Второй вопросец – о каких линиях прерывания идет речь в командах JRIH и JRIL – статус состояния «какой-то» линии, но какой конкретно?
По стеку... и сонным режимам - цель то понятна... Вот только механизм "по умолчанию" скрыт. Вход в прерывание - обязательное хранение всех данных или вход с заранее урезанным комплектом - только адрес возврата. Выход явно по укороченному варианту - следовательно аппаратно скорректировано содержимое указателя стека. В принципе ничего сверхестественного, учитывая порядковость загрузки стека при прерывании. Но при входе обязательная загрузка должна быть - ибо возможно и изменение условий возврата по состоянию исполнения программы. Экономия в шесть обращений к стеку... Ну да и ладно... А вот обязательное наличие "теневого заголовка" при входе из прерывания необходимо учесть при любимых мною условных возвратах с подстановкой адреса возврата. Интересно, а в обычном режиме без WFI/HALT этот механизм "урезанного возврата" работать будет или исключительно режим сна ему привержен? Для рутинных процедур с упором на бит-манипуляции непосредственно с регистрами ОЗУ/РСФ излишнее содержимое стека без особой надобности... Некоторая аналогия по скоростному теневому стеку при работе с 18-й серией ПИКа - одначе у ПИКа та информация "глухопрограммнонедоступна" в отличии от стандартного размещения в STM и может быть применена для обычных CALL, а не только прерываний. Зато право использования того "теневого стека" в ПИК18 полностью под контролем программиста - RETURN 1 /RETFIE 1 с испольлзованием шустростека или RETURN 0 /RETFIE 0 (по умолчанию) без него. У энхансед среднемладшей ПИКушки "шустрик" хош и не может быть отключен и всего одноуровневый (используется также как и в STM только системой прерываний) - зато программно доступен для чтения/записи. Насчет пина INT... Подождемс до распечатки/прочитания референс мануала... Чую там мнооогоо еще "всячческой мелочевки" для приставучего изучения...
Уммррр... Наконец закончил изготовление РТМ (референс ноте) к тому STM8S/AF http://img.radiokot.ru/files/20529/ors7a3rl3.jpg теперь хош можно беглое знакомство с аппаратно/периферийными примочками сделать. Бум почитамс биллетристику... Но сие только для "вступительного знакомства" сгодится ибо там еще два раздела пр программированию флеша и протоколу swim да по каждой микрухе свой даташит с дополнением по обнаруженным ерратам -то уже конкретика под программу и схемотехнику.
Просто интерес к истинному положению дел, скрытому для пользователей высокоуровневых компиляторов. А вобщем-то верно деньги и время частично "на ветер" - ибо вряд-ли далее теоретических изысков я с тем stm8 заниматься буду.
Просто интерес к истинному положению дел, скрытому для пользователей высокоуровневых компиляторов.
Представляете, дедуля, это только вам так кажется . Нам же видно все и все анализируем. да и вы попробуйте листинг просмотреть. Но вот приверженцам асма очень многое скрыто и не доступно , попробуйте угадать что ... Да и ограничены они во всем ...
BOB51 писал(а):
А вобщем-то верно деньги и время частично "на ветер" - ибо вряд-ли далее теоретических изысков я с тем stm8 заниматься буду.
Чем больше читаю-тем больше вопросов... Или изделие сырое - так пользователи высокоуровневых языков вполне поведением изделий довольны... Или имеем дело с своеобразным "трояном" от храдварных приложений от самой STM... Иначе объяснить такое количество опечаток в описании системы команд на ассемблере как-то затруднительно (разве что изготовитель на основу составляющей того же компилятора Си "забил" ). Из всех уже изученных - самое наплевательское отношение к базовой документации... Второй минус - при наличии развитой периферии отсутствует вариант псевдографического конфигуратора аналогично применяемому у Силабса.
for dosikus анализ созданной программы по листингу машинных команд/мнемоник асссемблера даавненько не пользовался... ну в дремучие времена начала изучения асма как-то был атавизм... одначе на то попозже симулятор-отладчики понавыдумывали. Можно конешно изредка глянуть по нюансам - но брать такой анализ за основу работы... для специалиста по СИ... ну Вы и загнули... это вроде декомпиляции с высокоуровневого только с предварительной машинной обработкой для распечатки... УВЫ ТОЛЬКО МОЖНО ПОСОЧУСТВОВАТЬ...
Внимательно смотрим, изучаем, завидуем ... И никаких ваших страшилок... Вам, дедуля, пора пересматривать свои догмы и менять свое мировоззрение. Не понятно где вы набрались этой чуши, напел что ли кто-то ...
А чему завидовать? Обычная рутина. Только подход "шиворот-навыворот" - не изучение документации вначале с последующим применением, а "научный тык" с приведением результата к недоработанной документации (или та документация имеет часть "сознательного сокрытия"). Кстати именно по работе компилятора пришлось в РМ0044 исправления вносить при работе со шпорами. Да и такой метод - не панацея, при критической некорректности компилятор просто выбросит код ошибки (верный только для первой из имеющихся в списке -остальные могут поменяться после устранения лидирующей и последующей попытки обработки) но листинга в результате не выдаст. Так что ничегошшеньки существенного к уже известному не добавлено. Вот только не слишком понятно - КАКИМ БОКОМ К STM8 ПОСЛЕДНИЙ СКРИН С МНЕМОНИКАМИ ОТ ПИКа?
Обычная рутина. Только подход "шиворот-навыворот" - не изучение документации вначале с последующим применением, а "научный тык" с приведением результата к недоработанной документации (или та документация имеет часть "сознательного сокрытия").
Гы... А вот зачем вы перевернули все с ног на голову? Кто вам сказал что это для изучения действия команд или изучения ассемблера ? Я выше уже озвучил - знание ассемблера крайне желательно, причем осознав действие команд единожды -легко въехать в архитектуру любого камня. Но только не фанатам асма .
Милай, это для контроля самой программы . Контроля эффективности и раздутости.
Садитесь 2 !!!
Кстати не увиливайте от своих же слов - вы только что необдуманно заявили что придется вручную декомпилировать !!! И ваши же слова - что приверженцам высокоуровневых языков не доступны ресурсы камня . Вы только вдумайтесь - какую чушь вы постоянно несете ...
BOB51 писал(а):
Вот только не слишком понятно - КАКИМ БОКОМ К STM8 ПОСЛЕДНИЙ СКРИН С МНЕМОНИКАМИ ОТ ПИКа?
А то что предыдущий от STM32 - это нормально? Я привожу сие скрины чтобы показать вам что это прерогатива не только STM или какой-то одной архитектуры .
PS. Когда же до вас дойдет - что со своим раздутым фанатизмом вы теряете очень многое ????????????? Тем более ища блох там где их нет, и ища какими-то странными методами - на своей волне....
dosikus в своем репертуаре - флуда много, личностных наездов еще больше - а пользы НИКАКОЙ - от скуки с кем-бы поцапаться. Ибо изучение системы команд по листингам хош и с помощью машинной обработки (того же дизассемблера) как вынужденная мера при отсутствии необходимой информации в документации изготовителя есть показатель качества того изготовителя. Архитектура МК в каждом отдельном семействе "в общих чертах" всегда одинакова, а вот, чтоб эффективно использовать то или иное семейство надо или знать тонкости конкретного кристалла (для самостоятельной работы) или пользоваться вариантом высокоуровневых сред в качестве простого/продвинутого пользователя, причем учитывая особенности начинки вполне перспективны и средства визуальной разработки.
Дык пока вы не начнете слушать и продолжите нести свой беллетристический бред , толку действительно не будет.
Озвучу что от вас ускользает : 1) в STM8 и STM32 вкусны не только ядро а больше ПЕРИФЕРИЯ . 2) На асме вы не сможете эффективно использовать ни ядро ни периферию . Потонете на этапе изучения...
Видимо по этой причине Вы (в отличии от Ser60) и не в состоянии ответить на те вопросы, которые я ранее задавал. Не нравится такой подход - просто не участвуйте в обсуждении и не захламляйте тему флудом. При нормальной документации - изучение периферии дело вполне приемлемое по мере надобности работы с определенным набором устройств (все сразу всеравно никогда не применяется).
Странно... Мне обычно за однократное беспочвенное цитирование модераторы замечания вшкваривали...
ГЫ-ГЫ! Каждый занимается тем, что считает для себя интересным. Кому еще интересно - тот прочитает, кому не интересно - не будет встрявать в не интересующее его обсуждение. Неужто Вы возомнили себя исключительным лицом с правами определять чего мне (или кому другому) можно думать, изучать, делать, а чего нельзя?
Неужто Вы возомнили себя исключительным лицом с правами определять чего мне (или кому другому) можно думать, изучать, делать, а чего нельзя?
Отнюдь , мне совершенно фиолетово чем вы страдаете. Занимайтесь и далее . Мои посты будут в противовес вашим , дабы новички не приняли вас за истину в первой инстанции и не пошли за вами . Сусанин блин...
Рекомендую ветку переименовать - "Как я пытался нестандартно изучать архитектуру и асм, или записки ***сшедшего"
Ну это уважаемый dosikus и есть позиция "просто подосрать не имея чего по делу сказать"
А пока вернёмся к "нашим баранам"... и размышлениям по прочитанному из даташитов:
Есть достаточно критичные «разночтения» по вопросам обработки стека,прерываний… RM0016 стр.24: «The WFI/HALT instructions save the context in advance. If an interrupt occurs while the CPU is in one of these modes, the latency is reduced.» Т.е. дословно: «WFI/HALT инструкции сохраняют контекст заранее. Если прерывание происходит пока CPU - в одном из этих состояний, время реакции уменьшено.»
Однако ни в описании WFI ни в описании HALT нет никакого намека на работу со стеком… Возможно авторами руководства имелось ввиду, что требуется предусмотреть сохранение контекста программным методом до выполнения WFI/HALT – однако в таком случае фраза звучала бы соответствующим образом.
В то же время, учитывая описание п.6.4 (RM0016 стр.62-63) можно прийти к заключению, что установленный перед исполнением команды бит AL=1 в CFG_GCR вызовет сохранение в стек контента для пробуждающего прерывания только при его первом исполнении. Далее пробуждающее прерывание будет исполняться с автовозвратом в точку ожидания до тех пор, пока при его исполнении не будет установлен AL=0. После чего IRET выполнит возврат в основную программу с полным восстановлением контента.
Мндяаа… Хош сонный режим и есть относительная экзотика, но вывод весьма интересный – реально WFI/HALT ничего таки в стек не грузят. Мое предположение: Если перед их выполнением был установлен AL=1, то ассоциированное с режимом пробуждения контрольно-дежурное прерывание при первом исполнении выполнит полную загрузку стека и вернет программу в точку ожидания (на тот же адрес где выполняется WFI/HALT ?) . Так будет продолжаться до тех пор, пока при исполнении фрагмента контрольно-дежурного прерывания не будет произведен сброс AL=0. После чего завершающая фрагмент контрольно-дежурного прерывания команда IRET выполнит полный возврат к основной программе. Дополнительная задачка – можно или нельзя пользоваться таковым режимом при нескольких возможных источниках прерываний пробуждения ? Интересно может кому больше про тот режим известно...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
