Форум РадиоКот

А кто его знает?
Один говорит, что пришел в тему троллить, другой, что развлекается.
В МЯУ перенес. Пусть здесь троллят и развлекаются.
aen

Мурато Мяуконни писал(а):Работа с интерфейсами или АЦП тоже заставляет активно переключать банки. А уж коль потребление ОЗУ выходит за пределы первого банка, то и подавно.

Работа с относительно большими объемами ОЗУ В ОСНОВНОМ связана с косвенной адресацией. Косвенная адресация не делит ОЗУ на банки. Отдельные переменные размещают в области перекрестной видимости или просто в нулевом банке.
Работа с периферией требует МИНИМАЛЬНОГО обращения к ненулевым банкам. Проверка разрешений в семафоре обработчика требуется лишь для определенных прерываний и при определенных условиях.

Мурато Мяуконни писал(а):Гдеее?? Каких ресурсов? В ПИК10 - каких ресурсов, какие потоки?

Именно ограниченность интерфейсов и приводит к необходимости их разделять. А множество потоков определяется ЗАДАЧЕЙ. Одни для этого хватают сразу M4, а другие делают ту же задачу на PIC10F322.

Мурато Мяуконни писал(а): А что там сложного??? Нарисуйте на бумажке схематично связи - и настраивайте, делов то!

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

Добавлено after 4 minutes:

BOB51 писал(а):"ПОНЕСЛОСЬ!"

Не, никуда ничего не понеслось. Просто затрахали апологеты СТМ32, наивно полагающие, что их труды по освоению этой (весьма и весьма неплохой) платформы могут их кормить долгие годы. Тоже самое наблюдалось и с ПИКами, и с АВР ранее.
Я пытаюсь донести до них очевидную мысль о том, что нет приоритетных решений. Есть лишь целесообразность. И это требует ДИВЕРСИФИКАЦИИ своих умений, знаний, применяемой элементной базы и прочая...

КРАМ писал(а):А Вы попробуйте что нибудь сделать на dsPIC33EP512GM304 за 4 доллара и мы посмотрим куда пригоден M3...

А вы попробуйте STM32F205 за ту же цену.

КРАМ писал(а):Косвенная адресация не делит ОЗУ на банки.

Да ну, вы серьезно? А как же бит IRP, переключающий 1, 2 и 3, 4 банки? На одной косвенной адресации всего не сделаешь. Инструмент косвенной адресации то один, и он может быть занят.

КРАМ писал(а): Работа с периферией требует МИНИМАЛЬНОГО обращения к ненулевым банкам. .

Окей. Попробуйте прочитать АЦП только в одном банке. Попробуйте прочитать/записать ЕЕПРОМ менее чем в двух банках. И это я всего еще не помню за давностью лет.
Конечно, если с периферией не работать, то можно и одним банком обойтись.

Добавлено after 4 minutes 3 seconds:

Vano79 писал(а):. А КРАМу отдельный респект за содержательные ответы.

КРАМ просто всеми силами пытается убедить работать только в нулевом банке Но как?? Не используя периферию, не используя ОЗУ более половины там, где она есть. Для начальных мигалок конечно пойдет.
Но я в пятый раз повторяю - как проверить прерывание, если флаги и разрешения находятся в разных банках?? PIR и PIE

К вопросу о банковой организации...
Весьма удобный способ разделения данных при переключении между задачами/подпрограммами без применения операций со стеком.
Кроме прочего у ПИКовых еще некоторые "нюёнсы" в организации ОЗУ имеются (область РОН, "отображенная на банк0").
Каждому СБИСу - свое конкретно место!
А АРМ - это отнюдь не только STM32.

Мурато Мяуконни писал(а):

КРАМ писал(а):А Вы попробуйте что нибудь сделать на dsPIC33EP512GM304 за 4 доллара и мы посмотрим куда пригоден M3...

А вы попробуйте STM32F205 за ту же цену.

А чего там пробовать, если тупо не хватает УВХ для синхронного преобразования. В dsPI33 их по 4 на каждый АЦП итого 8, а в F205 только 3. Мне нужно 6. И таймеров недостаточно для синхронной работы с низким джиттером. В упомянутом мной dsPIC33 8 таймеров в OutputCompare, 8 таймеров в InputCapture, 9 таймеров общего применения, 3 таймера высокоскоростного 6 канального ШИМ и два таймера в модуле PTG, который и реализует тот самый независимый от ядра синхронизм ВСЕЙ ПЕРИФЕРИИ, которого нет в CTM32. Я делал эскизный проект на СТМ, но он оказался хуже, нежели на dsPIC по вышеуказанным критериям.
И даже скорость фильтрации оказалась выше у ПИКа, хотя формально его системная частота ниже. Впрочем, на АСМе я СТМ32 не писал, поэтому в этом пункте сравнение не вполне корректно.

Мурато Мяуконни писал(а):

КРАМ писал(а):Косвенная адресация не делит ОЗУ на банки.

Да ну, вы серьезно? А как же бит IRP, переключающий 1, 2 и 3, 4 банки? На одной косвенной адресации всего не сделаешь. Инструмент косвенной адресации то один, и он может быть занят.

А Вас не смущает ограниченное количество РОН в АВР или СТМ32? Совсем не обязательно использовать FSR под единственный указатель. Можно его загружать текущим. Тем более, что ровно так делается НА ВСЕХ платформах.
Платформ МК с косвенным указателем из ОЗУ мне не известно. Повторю, биты переключения банков не используются при косвенной адресации. Вся история с банками рождена ограниченной длиной команды, а косвенная адресация не зависит от команды и определяется разрядностью регистра-УКАЗАТЕЛЯ, который 16-разрядный.

Мурато Мяуконни писал(а): КРАМ просто всеми силами пытается убедить работать только (вранье!!!) в нулевом банке Но как??

Учить матчасть и не судить о вещах с уровня своей квалификации. Да и не перевирать мои утверждения, заодно...

Мурато Мяуконни писал(а):КРАМ просто всеми силами пытается убедить работать только в нулевом банке Но как??

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

Vano79 писал(а):на кодинге на Си начинающему вообще забыть про банки и положиться на компоновщик.

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

Матчасть древних ПИКов учить - зачем мне оно, это давно пройденный для меня этап. Наверно даже раньше, чем для вас., раз вы до сих пор с банками тыкаетесь.

Платформ МК с косвенным указателем из ОЗУ мне не известно.

Да ну, вы что. Да хотябы обсуждаемые нами ПИК16/12/10 имеют как раз такой указатель на ОЗУ. Вон тот список регистров после 0х20 - это как раз статическое ОЗУ микроконтроллера. А вы под ОЗУ понимаете что-то другое??? Ну не знаю, вам матчасть надо тогда подучить.

А Вас не смущает ограниченное количество РОН в АВР или СТМ32?

Это регистры ядра и они не имеют отношения к ОЗУ микроконтроллера. Посмотрите, что в них хранится - и сразу поймете. А в старших Кортексах под нужды ядра выделена часть ОЗУ в несколько десятков килобайт, соединенная с ядром отдельной скоростной шиной.

(вранье!!!)

Где??? не бросайтесь словами, чтобы потом не оправдываться. Ибо:

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

"Практически никогда" - это и есть "только". А на практике вы задолбаетесь переключать банки - я пять раз повторил пример. Вы не сможете прочитать АЦП, не переключая банки. Это ли "практически никогда"?.

Именно ограниченность интерфейсов и приводит к необходимости их разделять. А множество потоков определяется ЗАДАЧЕЙ. Одни для этого хватают сразу M4, а другие делают ту же задачу на PIC10F322

Хватит фантазировать! Вы не понимаете, о чем пишете. Как вы на три ножки повесите совершенно разные интерфейсы, соединенные с совершенно разными устройствами? Поставите расширитель портов? Нельзя уже до такого абсурда доводить спор - Кортекс М4 в 144-выводном корпусе против ПИК10 с тремя-четырьмя ножками. Вы уже зарапортовались, чесслово.

Просто затрахали апологеты СТМ32

затрахали? Да ну, а что, только СТМ32 имеет ядро Кортекс? Есть NXP например. Сейчас Кортексы вставляют очень-очень многие производители..
Кому-то термометр собрать, а кому-то и сбор показаний трех десятков термометров и передача их в космос

Мурато Мяуконни писал(а):А на практике вы задолбаетесь переключать банки - я пять раз повторил пример. Вы не сможете прочитать АЦП, не переключая банки.

Использовать младшие/средние пики и не быть готовым к переключению банков - вы о чем? К тому же "на практике" часто встречаются неэффективные алгоритмы, неоптимальное расположение переменных в банках, не говоря уже о коде в целом.

Я слава богу давно не использую младшие/средние пики и с радостью принял линейное адресное пространство на других платформах.
А алгоритм хоть какой эффективный построй, полноценно прочесть 12 битов АЦП или изменить вход/выход без переключения банка вам не удастся. И это не только в АЦП. Попробуйте ЕЕПРОМ прочесть. Попробуйте интерфейсы последовательные без переключения банков. Ха!

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

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

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

Мне кажется, что я достаточно сказал, чтобы понять мое отношение к 16-м ПИКам. В основном я применяю dsPIC33, иногда PIC24 и STM32, еще реже PIC18 и совсем редко 10-ые...16-ые ПИКи. Проблем возникающих у Вас с банками я как то не ощущаю. Переводить 8-битки на STM я не планирую по чисто практическим соображениям, где логистика поставок комплектации для серийной продукции дает больший профит, нежели незначительный выигрыш в цене на сам чип, да и то далеко не всегда. По соображениям логистики ранее мы отказались от MSP430 и TMS320.

Мурато Мяуконни писал(а):

Платформ МК с косвенным указателем из ОЗУ мне не известно.

Да ну, вы что. Да хотябы обсуждаемые нами ПИК16/12/10 имеют как раз такой указатель на ОЗУ. Вон тот список регистров после 0х20 - это как раз статическое ОЗУ микроконтроллера. А вы под ОЗУ понимаете что-то другое??? Ну не знаю, вам матчасть надо тогда подучить.

Если Вы не поняли сказанного мной, то причем тут мои знания? Указатель НА ОЗУ не может быть расположен в самом ОЗУ и всегда использует для этого РОНы. Ровно так, как это сделано в ПИКах. С той лишь разницей, что в ПИКах обсуждаемой платформы такойрегистр один, в 18-х этих регистров 3, а в 16 разрядной платформе 24/30/33 их 14 или 15 (1 или 2 из 16 используются под нужды стека).
Учите матчасть...

Мурато Мяуконни писал(а):

Код: Выделить всё

А Вас не смущает ограниченное количество РОН в АВР или СТМ32?

Это регистры ядра и они не имеют отношения к ОЗУ микроконтроллера.

"И эти люди учат нас не ковырять в носу..." (С)

Мурато Мяуконни писал(а): Хватит фантазировать! Вы не понимаете, о чем пишете. Как вы на три ножки повесите совершенно разные интерфейсы, соединенные с совершенно разными устройствами? Нельзя уже до такого абсурда доводить спор - Кортекс М4 в 144-выводном корпусе против ПИК10 с тремя-четырьмя ножками. Вы уже зарапортовались.

Это не абсурд, а стеб и сарказм. Над Вами. Но необходимость разделять ресурсы при их ограниченности - это ОСНОВНАЯ задача РТОС. И практически единственная.

Мурато Мяуконни писал(а): Кому-то термометр собрать, а кому-то и сбор показаний трех десятков термометров и передача их в космос

Ключевое в Вашей фразе - ТЕРМОМЕТР, что и определяет для Вас сложность задачи. Интерфейсы передачи данных Вам предоставляет производитель МК. А что собственно тут разрабатывать Вам?
Термометр - он и в Африке термометр....

BOB51 писал(а):- а про интерес того Пока_без_кота
(и иных начинающих) саапсем "фигвам"/флудням...

А тот самый Пока_без_кота вообще пока тихо офигел и упал в ступор от количества букв в теме Хотел ведь только про банки спросить.

Мурато Мяуконни писал(а):полноценно прочесть 12 битов АЦП или изменить вход/выход без переключения банка вам не удастся.

Удается с переключением банков, без проблем. Надеюсь вы не будете утверждать, что при этом мы теряем в производительности, "раздувание" кода и т.д.

КРАМ писал(а):Это не абсурд, а стеб и сарказм. Над Вами. Но необходимость разделять ресурсы при их ограниченности - это ОСНОВНАЯ задача РТОС. И практически единственная.

Сарказм? Надо мной? Да ну что вы. Тут над вами уже потешка - с вашими предположениями, что РТОС нужен там, где ресурсов не хватает. РТОС - RTOS - операционная система реального времени. Надеюсь, вы в курсе, сколько на себя ресурсов отнимает нормальная РТОС? Где вы будете хранить стек РТОС, сколько времени будет занимать работа РТОС, если у вам и так ресурсов не хватает. Вы думаете, РТОС ставят на Кортекс М7 только потому, что там ресурсов не хватает? Нормальная, полноценная РТОС - это всегда накладные расходы. Полноценная РТОС, а не затычка в виде тряпки с узелком.
Так что лучше сами изучите вопрос, пержде чем писать что-то.

Удается с переключением банков, без проблем. Надеюсь вы не будете утверждать, что при этом мы теряем в производительности, "раздувание" кода и т.д.

Как-как-как? А что, для переключения банков разве не нужны отдельные инструкции? Да вы шутите. Да, с переключением банков можно прочесть 12 бит АЦП. А КРАМ утверждал, что переключать банки "практически никогда не нужно".

Мурато Мяуконни писал(а):Вы думаете, РТОС ставят на Кортекс М7 только потому, что там ресурсов не хватает?

Если сублимировать до простой истины, то да - именно поэтому. Только с тем лишь замечанием, что разделение ресурсов производится для разных потоков, которых больше, чем ресурсов. Применять РТОС для единственного потока - бессмысленно.

Мурато Мяуконни писал(а):А КРАМ утверждал, что переключать банки "практически никогда не нужно".

Практически никогда и никогда - это РАЗНЫЕ вещи. Если на переключение банков тратится 0,01% времени исполнения кода - это означает "почти никогда". Нащщет указателей я Вам объяснил ранее. Ваши странные представления о РОНах и указателях наводят на грустные мысли относительно Вашей квалификации...

КРАМ писал(а):Платформ МК с косвенным указателем из ОЗУ мне не известно.

ИЗ? Окей, "из" так "из". Тот же ПИК16. Возьмите указатель ИЗ ОЗУ.
А на АРМ-платформах так вообще исполнение программы может быть запущено в ОЗУ микроконтроллера, без обращения к флешу. Вообще всё. И вектора прерываний находятся в ОЗУ, и инструкции извлекаются из ОЗУ.

КРАМ писал(а): Ваши странные представления о РОНах и указателях наводят на грустные мысли относительно Вашей квалификации...

Хорошо, а как вы представляете регистры ядра Кортекс? И какое вообще они имеют отношение к теме? Так, для общего словца?
Мы тут мою квалификацию не обсуждаем. Слава богу, у меня ее достаточно, для того чтобы не обращать внимание на мнение о моей квалификации от форумных посетителей

КРАМ писал(а):Практически никогда и никогда - это РАЗНЫЕ вещи. Если на переключение банков тратится 0,01% времени исполнения кода - это означает "почти никогда"

Соскок не засчитан: время исполнения кода != частоте переключения банков в коде. Хотя, для проекта "привет мир" таких переключений действительно можно свести к 0,01% от размера кода.

Мурато Мяуконни писал(а):
Хорошо, а как вы представляете регистры ядра Кортекс? И какое вообще они имеют отношение к теме? Так, для общего словца?

Регистры ядра Кортексов используются В ТОМ ЧИСЛЕ и для КОСВЕННОЙ АДРЕСАЦИИ. Когда Вы используете указатели в Си, на самом деле переменная указатель выгружается сначала в РОН, а затем посредством команд КОСВЕННОЙ адресации происходит обращение собственно к ОЗУ.
Ничего другого быть и не может. Потому что команда не может одновременно выбирать из ОЗУ и указатель и саму переменную по указателю, поскольку шина адреса/данных у АЛУ единственная. Можно конечно построить конвейерную выборку в разных циклах обращения к ОЗУ (как это сделано в DSP тех х ПИКов33), но все равно там используются те же самые РОНы.

Добавлено after 4 minutes 46 seconds:

Vano79 писал(а):время исполнения кода != частоте переключения банков в коде.

Если тупо дергать при каждом обращении banksel и ничего не слышать про косвенную адресацию, то потери времени на переключение могут составить очень значительную часть времени. Например при циклах обработки массивов. Снятие данных из АЦП построенное в прерывании не потребует возврата из 1-го банка, поскольку восстановление контекста это сделает автоматически. То есть проблема банков изрядно надумана.
ЗЫ. К слову, можно постебать M0 за отсутствие bit banding, ведь замена битового доступа на маску дает изрядные потери при битовом управлении. Но реально на время исполнения это не влияет...

Дабы закончить этот спор, подведём итоги сказанного.
АСМ знать желательно, но совсем не обязательно. В нынешних условиях профита от него аж никакого. Только в целях знакомства с архитектурой, не более.
РТОС сам себе никто писать не будет.
Применение АСМ на ПИК24/33 может где-то и оправдано, но там на АСМе как на СИ, а на СИ как на АСМе. В других же случаях необходимость АСМа явный показатель неправильного выбора МК или кривого алгоритма.
Все Гуру ПИКа, которые ещё лет 7-8 назад его юзали, давно уже перешли на другую платформу. Неверующие могут пройтись на микрочип(точка)су. И АСМ, увы, никто из них не юзает, разве что изредка в критических секциях.

Добавлено after 19 minutes 9 seconds:

КРАМ писал(а): А чего там пробовать, если тупо не хватает УВХ для синхронного преобразования. В dsPI33 их по 4 на каждый АЦП итого 8, а в F205 только 3. Мне нужно 6. И таймеров недостаточно для синхронной работы с низким джиттером. В упомянутом мной dsPIC33 8 таймеров в OutputCompare, 8 таймеров в InputCapture, 9 таймеров общего применения, 3 таймера высокоскоростного 6 канального ШИМ и два таймера в модуле PTG, который и реализует тот самый независимый от ядра синхронизм ВСЕЙ ПЕРИФЕРИИ, которого нет в CTM32. Я делал эскизный проект на СТМ, но он оказался хуже, нежели на dsPIC по вышеуказанным критериям.
И даже скорость фильтрации оказалась выше у ПИКа, хотя формально его системная частота ниже. Впрочем, на АСМе я СТМ32 не писал, поэтому в этом пункте сравнение не вполне корректно.

Это частный случай и наверное единственный в своём роде. К тому же PTG это костыль, по сути, к тому же слегка кривоватый.
С точки зрения новичка dsPIC33 сложнее СТМ32, а учитывая малую распространённость dsPIC33 и невозможность получить по нему внятные ответы даже на простые вопросы, то его изучение новичками, на сегодня, вообще гиблое дело.

scorpi_0n писал(а): Это частный случай и наверное единственный в своём роде. К тому же PTG это костыль, по сути, к тому же слегка кривоватый.

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

КРАМ писал(а): Этот "единственный" случай является типовым для сигнальной обработки.

Единственный случай ну никак не может быть типовым. Задача, по любому, не для новичка. Да и вы её не на АСМе решали.

А вот насчет кривоватости PTG хотелось бы услышать поподробнее. В чем она состоит и в чем состоит "костыльность" этого модуля?

Костыль - потому что не во всех МК ПИК24-33 он есть. Этим костылём пытались выравнять кривизну таймеров и отсутствие вменяемой синхронизации. Кривизна этого костыля в том, что даже он не может запустить несколько таймеров на внешний счёт одновременно. Что делает dsPIC33 своего рода обычным генератором сигналов с математической обработкой и контуженной возможностью управления извне, т.е. с эфемерной попыткой решать некоторые задачи на уровне АСМа, со всеми вытекающими.