Поклонники продукции Microchip Technology Inc тусуются тут.
Ответить

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 05:58:36

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

PIC24 не сложнее с точки зрения понимания. Более того, он во многом наследует идеологию 18-х. У меня ушло не более пары дней для написания первого проекта на PIC24 после PIC18.
Вы пытаетесь рассуждать о вкусе устриц, НИ РАЗУ НЕ ВЗЯВ ИХ В РОТ.
Все что требуется для старта - создать проект с необходимым для старта минимальным синтаксисом. Причем даже не на железе, а в симуляторе среды. Поиграть в дебаге и сразу все станет ясным. И команды и синтаксис и вообще все.

вот тут и чтение таблиц пригодилось. таблица создавалась в эксель. сразу как ДАТА и 16 бит число. и напрямую грузилось в пик18. можно сразу читать 16 битные числа. чего в пик16 гораздо сложнее реализовать.

Во первых, копировать таблицы из Эксель можно куда угодно. И в 24/33-и, и в 18-е, и в 12/16-е. Причем тут Эксель?
Во вторых, СРАЗУ читать 16-разрядные числа в ЛЮБОМ 8 разрядном контроллере ПРИНЦИПИАЛЬНО невозможно. Только в 2 приема.
Разница между 12/16 и 18 состоит лишь в длине командного слова. Поэтому в 12/16 всегда будут пропадать 6 бит на слово в таблицах. Так я и в 24/33-их редко когда использую 24 разряда команды целиком в таблицы. Они плотно упаковываются только в байтных таблицах. Чего там экономить флеш? Один хрен он на АСМе всегда пустой на чуть менее, чем на 99%.

Ну и снова повторюсь. Если лень освоить новое В КАЧЕСТВЕ ХОББИ, то не стоит этим хобби вообще заниматься. Ну а Вы пытаетесь ПРОФЕССИОНАЛЬНО применять матчасть. Стыдно ссылаться на время. Голова инженера всегда занята профессиональными проблемами. Даже на отдыхе. Это часть самой профессии.

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 10:06:37

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

что касается таблиц. ну и как можно сразу послать в МК пик16 16 битное число с экселя? вот именно что слово 16 разрядной поэтому и можно записать 16 битное число. а как быть с пик16?
делить побайтно? :o мне такой гемор не нужен.
я же объяснил что куча таблиц и часто приходилось их подбирать. попробуйте ручками править несколько таблиц длиной 1024 16 битных числа.

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 13:32:42

Так ежли есть комп... и эксель... Может проще вычисления оставить там, а МК использовать только как источник простейшего потока данных и исполнительного порт-расширителя?
:dont_know:
А насчет "мультяшек" для дисплея...
Почему бы не использовать внешнее ОЗУ/ЕЕПРОМку с типовыми заготовками?
:roll:

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 14:21:33

Скажем, построение софтового приемника (SDR) на несущих, начиная с десятка мегагерц, неизбежно потребует FPGA, хотя бы на входных операциях с данными АЦП (квадратурный смеситель, квадратурные фильтры, возможно демодуляция).

Согласен, ближайшие несколько дней лично я с любопытством шерстил в интернетах тему SDR.
Весьма любопытная тема.
Есть рекомендации для прочтения, чисто из любопытства ?
Хотя с другой стороны (с учётом религии ДИП-корпусов) - лично мне доступно лишь мечтать подключить модуль с алишечки на AD9959 к мозгам на Пик-18 для получения удобного/маленького гетеродина для синхронного детектора на быстродействующих ключах/диодах.
Это вообще бред сивой кобылы. Есть задачи и под эти задачи следует выбирать контроллер.

Это конечно да, но:
1. как именно выбирать, какой алгоритм выбора ?
2. Если один выбрал и решил задачу на 32 бит контролёре/мегабайте ОЗУ/мегабайте ПЗУ, а второй решил ТУ ЖЕ задачу НЕ хуже на 4 битах проце/сотне байт ОЗУ/килобайтах ПЗУ - то кто из них умнее ?
Или лично я именно про такой подход недавно говорил что микроскопом гвоздь забить любой дурак сможет ?
А кроме того, копаясь в примитивной старой рухляди

Высокомерненько и недальновидно.
Выше был вопрос про НЕ документированную командочку в RsBug. Что она делает - есть ответ или признаем что "в своё время" изучение той рухляди было поспешно-неполным ?
Ну примерно как у собаки прошёл утиный тест курицы на съедобность ?
Вы упускаете возможность получить удовольствие от разного рода новых возможностей, не связанных в прямую с разрядностью ядра.

Способов получения удовольствия - их много, но именно по этой причине (тщётности попыток отстоять/обосновать позицию/мнение что именно мой способ - самый правильный и лучший) воспитанные люди давно постулировали "об вкусах - не спорят" ?
Если у человека нет минимальных знаний настолько, что он не в состоянии сформулировать для себя достойную задачу, то хобби не поможет в борьбе с Альцгеймером.
Для того, кто осваивает МК системно, а не как черный ящик, (НА ЛЮБОМ УРОВНЕ, даже самом примитивном), вопрос запоминания мнемоники ассемблера ДАЖЕ НЕ СТОИТ. В смысле освоения системы команд все контроллеры БЕЗ ИСКЛЮЧЕНИЯ одинаковы. Как близнецы. И не только контроллеры, но и процессоры.

Напомню про собаку курицу и утку, которые как братья-близнецы, согласен.
А человек, который разрабатывал/собирал/отлаживал на дискретной логике например 155 серии (не те которые говорили что "было время когда вся электроника начиналась на 6", а примерно следующие) любое чуть более сложное чем мыргалка СД нечто - ну в любом случае под словом "регистр" в асме будет видеть именно набор D триггеров, согласен.
Для этого нужно начинать не с копания в таблице команд, а с ПРОГРАММНОЙ МОДЕЛИ ЯДРА. Структура РОНов, стек, типы адресаций, векторизация прерываний, специальные фичи типа шадоу-регистров (локальные стеки) и прочая, прочая, прочая.

Ну посторюсь - некоторые - говоря "АСМ" - и думать не могут что на асме можно что-то писать без хотяб поверхностного знания блок-схемы проца.
Именно по этой причине микрочипы в каждом даташите структуру мелкопроца описывают в самом начале, после общих свойств проца ?
И говоря "целых 120 команд" АСМа для Пик-30 - лично я подразумеваю именно существенно более богатое устройство проца, отрабатывающего эти команды ?
Сама форма Вашей аргументации за консервативность говорит о том. что Вы вообще не понимаете о чем говорите.

Опять 25.
А если мы не понимаем язык китообразных - то означает ли это что они глупее чем мы ?
ЗЫ. Смешно говорить о подобном объеме информации как о чем то серьезном. Радиотехническое образование требует на несколько десятичных порядков больший объем усвоения.

К слову - лично я в реальной жизни не встречал человека, способного запомнить хотяб примерно на двоичный порядок больше в живой беседе чем лично я.
И да - среди собеседников был действующий академик РАН несколько раз.
А долговременная память/зубрёжка таблиц Брадиса - ну, лично я их в школе тоже помнил достаточно полнотело. Ибо листать - задалбывало, проще было подзубрить.
У меня ушло не более пары дней для написания первого проекта на PIC24 после PIC18.

Похвальная скорость, согласен. Как бы лично мне себя заставить хотяб запаять в макетку 30F2010 ?
Разница между 12/16 и 18 состоит лишь в длине командного слова. Поэтому в 12/16 всегда будут пропадать 6 бит на слово в таблицах.

Кстати - самохвалки ради - был у лично меня прожект голоса на Пик-16 без внешних ПЗУ.
Кодер на писюке на бэйсике, записанный с микрофона Wav-8 или Wav-16 конвертил в самостоятельно разработанный/отлаженный формат, далее это компилилось в Пик-16, который декодировал звук/голос и выводил его через ШИМ в качестве ЦАП. Поганенько - но работало, запись лично моего голоса шпарила из ПИКа вполне.
Каждый сэмпл - 2 бита, в слове Пик-16 помещалось 7 сэмплов, ни единого бита потерь в таблицах на Пик-16.
Ну это к вопросу об методах решения задач.
Чего там экономить флеш?

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

Ну если это занятие головы примерно "какой проц поновее попробовать" и "зачем думать как сэкономить флешь/мипсы - если их как грязи" - то согласен, какие инженеры - таковы и результаты их деятельности.
А насчет "мультяшек" для дисплея...
Почему бы не использовать внешнее ОЗУ/ЕЕПРОМку с типовыми заготовками?

Воооот, согласен, лично я недавно узнал что существуют ОЗУ/ПЗУ в ДИП корпусах с 4 бита шиной, которые можно пробовать смультиплексировать с лично моей заготовкой - и за цену 1 ноги например поиметь внешний флеш с голосом 16 мегабайт типа 25Q128 и/или ОЗУ типа 23LC1024 для каких-либо накоплений измерений ?

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 15:54:17

Есть рекомендации для прочтения, чисто из любопытства ?

Могу предложить только теоретическую радиотехнику. Ибо разрабатываю изделия исключительно на ее базе.
SDR реализует математику обычного приемника. Теория цифровой фильтрации в интернете в избытке. даже постесняюсь что либо рекомендовать.
Я нынче коэффициенты оконных функций формирую в Экселе и копирую в проекты.
Не так давно собрал проект на симуляторе МПЛАБа, где реализовал софтовый DDS как формирователь входного массива (вместо АЦП), модуль КИХ фильтра и общий цикл сканирования по частоте и вывода АЧХ. Все наблюдаю в окнах DMCI. Вставил оконную функцию - запустил код - получил АЧХ.
Можно вставить рекурсивный БИХ и посмотреть его АЧХ.
Готовый модуль фильтра копируется в реальный проект.
Хотя с другой стороны (с учётом религии ДИП-корпусов)

Оставим эту смешную тему. Быстрых 14 и выше разрядов АЦП (даже с 0,25 msps) в дипах не бывает. Там выходной последовательный поток имеет рейт минимум 10 Mbit/s. А требования к высокоразрядным АЦП по аналогу слишком высоки для петель образуемых ДИПом.
Паять soic или TQFP особого умения не надо. Как и особого зрения. Есть монтажные очки и недорогие паяльники.
И есть монтажные платы с штырями по периметру для макетирования.
Пустой и никчемный аргумент с вашей стороны.
1. как именно выбирать, какой алгоритм выбора ?
2. Если один выбрал и решил задачу на 32 бит контролёре/мегабайте ОЗУ/мегабайте ПЗУ, а второй решил ТУ ЖЕ задачу НЕ хуже на 4 битах проце/сотне байт ОЗУ/килобайтах ПЗУ - то кто из них умнее ?

Вы за ум полагаете копание с примитивной системой команд неприспособленной для класса задачи?
Помилосердствуйте, отец родной! Я писал SDR с внешним смесителем на PIC18F25K20 примерно 9 лет назад.
Через три года я понял, что реализовать функционал требуемый ОБЪЕКТИВНО рынком в этом изделии невозможно ПРИНЦИПИАЛЬНО. Тупо не хватает скорости и возможности внешнего смесителя по обработке сигнала.
И я срочно переделал проект на dsPIC33FJ128MC802.
С тех пор я горя не знаю с любыми апгрейдами изделия. Последняя версия была выпущена на том же МК, но с бОльшим числом выводов (804-ый).
Там и алгоритм приемника стал на голову совершеннее. У меня на 18-м памяти даже на 1/4 не хватило бы... Я уже не говорю о потребностях обмена с ПО на компьютере через мост HID USB-UART, который, кстати, сделан на PIC18F14K50 и написан на Си. Это обмен на фоне штатной работы изделия В ПРИНЦИПЕ невозможен без ДМА.
Так что тут выбирать?
Это не гвоздь микроскопом, а микроскоп кувалдой...
:tea:
Выше был вопрос про НЕ документированную командочку в RsBug. Что она делает - есть ответ или признаем что "в своё время" изучение той рухляди было поспешно-неполным ?

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

Это Вы СЕБЕ объясняйте. А мне не нужно. Это Вы пытаетесь всех убедить, что возня с деревянными кубиками в попытке найти в них решение серьезной задачи медицины - это единственно верное решение. Я же пытаюсь Вас натолкнуть на мысль, что есть более серьезные методы...
А человек, который разрабатывал/собирал/отлаживал на дискретной логике например 155 серии

Милейший, мне 59. Я начинал радиолюбительство в 72-м, а в 81-м закончил радиоинститут. Вы мне про что пытаетесь втереть? :))) :))) :)))
Ну посторюсь - некоторые - говоря "АСМ" - и думать не могут что на асме можно что-то писать без хотяб поверхностного знания блок-схемы проца.
Именно по этой причине микрочипы в каждом даташите структуру мелкопроца описывают в самом начале, после общих свойств проца ?
И говоря "целых 120 команд" АСМа для Пик-30 - лично я подразумеваю именно существенно более богатое устройство проца, отрабатывающего эти команды ?

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

Могу Вас расстроить. Изучение радиотехники не требует зубрежки и запоминания на лету. Это совсем из другой оперы.
Видимо Вы "институтов не кончали..."

ЗЫ Предлагаю Вам почитать открытую мной тему про 16 разрядные МК Микрочипа. Я ее пишу чисто по памяти. Просто описывая свои знания и опыт в этой области. Могу про 10-18-ые написать. Так же с лету. :tea:

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 17:51:36

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

А не будет наглостью попросить ссылку или название/автора хотяб ?
SDR реализует математику обычного приемника. Теория цифровой фильтрации в интернете в избытке. даже постесняюсь что либо рекомендовать.
Я нынче коэффициенты оконных функций формирую в Экселе и копирую в проекты.
Не так давно собрал проект на симуляторе МПЛАБа, где реализовал софтовый DDS как формирователь входного массива (вместо АЦП), модуль КИХ фильтра и общий цикл сканирования по частоте и вывода АЧХ. Все наблюдаю в окнах DMCI. Вставил оконную функцию - запустил код - получил АЧХ.
Можно вставить рекурсивный БИХ и посмотреть его АЧХ.
Готовый модуль фильтра копируется в реальный проект.

Из текста выше лично я понял чуть менее чем ничего, согласен.
Но чисто для галочки - совершенно недавно какой-то дядя написал статейку про открытую реализацию целочисленного БПФ/ОПФ на FPGA Xilinx.
Я писал SDR с внешним смесителем на PIC18F25K20 примерно 9 лет назад.
Через три года я понял, что

У лично меня уровень знаний про SDR - "пару недель читал интернеты в свободное от работы время".
Это совершенно иной уровень чем "9 лет назад написал первый SDR"
Это может быть софтовый бряк, например. Что в нем интересного для пользователя?

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

Не-Не-Не, лично я пытаюсь сказать - что до решения серьёзных задач медицины лично я ещё не дорос, уровень не тот.
А сообразно задачам - и инструменты. Так что - кому скальпель - а кому и кубики деревянные.
"Каждому - своё", согласен.
Предлагаю Вам почитать открытую мной тему про 16 разрядные МК Микрочипа. Я ее пишу чисто по памяти. Просто описывая свои знания и опыт в этой области. Могу про 10-18-ые написать. Так же с лету.

А где ссылка или это моветон и лично я должен глядеть все сообщения пользователя для поиска темы в которой он чаще пишет ?

Re: Вычисляемый переход - проблема

Пн янв 07, 2019 18:14:26

А не будет наглостью попросить ссылку

Не наглость, конечно, но поиск всем доступен. Вы полагаете, что я помню кто из авторов разных учебников более доступен?
Однако вот первое что попало в поиске: http://bsuir-helper.ru/sites/default/fi ... olskij.pdf
Но чисто для галочки - ... статейку про открытую реализацию целочисленного БПФ/ОПФ на FPGA Xilinx.

И что? :dont_know: БПФ - это правда несколько другая задача, нежели потоковая фильтрация сигнала. Но тема близкая к обсуждаемой про SDR.
Я ранее говорил, что скорости могут быть высокими, разрядности большими, поэтому не всякий FPGA справится, не то что МК. Даже уровня SHARK от Аналог девайс. Хотя серьезные измерительные приборы не зря стоят десятки тысяч долларов.
В том коде (где каждый байт длинны на счету), который писали профи микрочипа для своего изделия, внезапно нарисовался "софтовый бряк" ?

Для информации. При использовании ICD3 в качестве дебаггера, помимо аппаратных (хардварных) брекпойнтов, количество которых ограничено 1...5 штуками (зависит от модели МК), софтовые брекпойнты не имеют ограничений по количеству. Однако, они требуют при их установке перепрошить МК, поскольку расположены прямо в коде. Полагаю, что Вы "обнаружили" именно его... А может и не его, а что либо подобное. Все равно нет спецификации. А даже если бы она и была... Что в этом интересного для решения задач на МК? Я Вам предлагаю кучу самых разнообразных команд и превосходную архитектуру, а Вы крутите носом. Так зачем Вам эта лишняя инструкция?

А где ссылка или это моветон и лично я должен глядеть все сообщения пользователя?

:facepalm: :dont_know:
Я просто в шоке... Тема находится прямо рядом с этой в ветке PIC:
https://radiokot.ru/forum/viewforum.php?f=58
Но вот Вам прямая ссылка: https://radiokot.ru/forum/viewtopic.php?f=58&t=159905

Re: Вычисляемый переход - проблема

Вт янв 08, 2019 13:34:00

Но вот Вам прямая ссылка: https://radiokot.ru/forum/viewtopic.php?f=58&t=159905

Спасибо, с таким подспорьем - надо заказывать себе с алишечки 30F4011 в тёплых ламповых ДИП-40, согласен. Ибо в 30F2010 - маловато ног с учётом накладных потерь 30F серии.
2. Длина команды - 24 бита, в которых 8 бит занимает код операции, а остальное связано с адресацией операндов.
3. Счетчик команд - 23 бита. Это значит, что возможна адресация программной памяти размером 4М*24 (4М инструкций). Естественно, что физически реализована лишь малая часть этого адресного пространства. Счетчик команд всегда четный (0, 2, 4 ...). Нечетные адреса занимают старшие байты команд. Нечетная адресация возможна лишь при байтном чтении программной памяти. Попытка чтения 16 битного слова из нечетного адреса программного флеша вызывает ошибку

А это как ? Машинное слово 3 байта, указатель команд побайтной грануляции, но при этом он всегда чётный с всегда нулевым младшим битом ?
Как это вяжется с традиционной арифметикой чёт/нечёт ?

Re: Вычисляемый переход - проблема

Вт янв 08, 2019 13:59:39

Как это вяжется с традиционной арифметикой чёт/нечёт ?

Очень просто вяжется. Старший (третий) байт команды дополняется виртуальным (фантомным) ЧЕТВЕРТЫМ байтом равным НУЛЮ.
При табличном чтении мы это и наблюдаем по нечетным адресам.
А счетчик команд имеет 16-разрядную, а не байтную "грануляцию". Это данные побайтны, а не команды.
Я невнятно (по сути ошибочно) выше объяснил этот момент. Тут ошибка адреса произойдет при попытке не табличного, а PSV чтения нечетного адреса флеша и при загрузке нечетным значением инструкции call Wn.
Скрин из даташита:

Изображение

Re: Вычисляемый переход - проблема

Вт янв 08, 2019 17:20:08

Как это вяжется с традиционной арифметикой чёт/нечёт ?

Очень просто вяжется. Старший (третий) байт команды дополняется виртуальным (фантомным) ЧЕТВЕРТЫМ байтом равным НУЛЮ.

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

Прощу прощения, но как ещё одним словом удачно обозвать минимальный аппаратно адресуемый элемент памяти/ширину шины памяти ? ЗУ с 16 бит организацией - это длинно, а как короче и правильнее ?
Последний раз редактировалось psw2.ru Вт янв 08, 2019 20:31:16, всего редактировалось 1 раз.

Re: Вычисляемый переход - проблема

Вт янв 08, 2019 18:24:37

Микрочипы похоже изначально заложились на 32 бита машинное слово

Они ни на что не закладывались. Это решение естественное для 1,5 кратной разрядности инструкции относительно разрядности данных. А само название PIC24, кагбэ намекаэ на реальные планы.
:)

Re: Вычисляемый переход - проблема

Чт янв 24, 2019 20:21:36

Кстати есть тактический предметный вопрос по АСМ Пик-18.
Я писал SDR с внешним смесителем на PIC18F25K20 примерно 9 лет назад.
Через три года я понял, что реализовать функционал требуемый ..... Могу про 10-18-ые написать. Так же с лету.

Как сделать короче используемую сейчас последовательность команд, вот кусок листинга:
Код:
000434 C117 F11A   movff   Angle_1,Angle_2      ; Младший
000438 C118 F11B   movff   Angle_1+1,Angle_2+1   ;
00043C C119 F11C   movff   Angle_1+2,Angle_2+2   ; Старший
000440 0E55         movlw   low(0x555555)      ;
000442 271A         addwf   Angle_2,F,BANKED   ; А + В, результат  В=B+A
000444 0E55         movlw   high(0x555555)      ;
000446 231B         addwfc   Angle_2+1,F,BANKED   ; и сложим старшие байты - результат в В
000448 0E55         movlw   upper(0x555555)   ;
00044A 231C         addwfc   Angle_2+2,F,BANKED   ; и сложим старшие байты - результат в В

Надо прибавить к источнику 24 бита константу (можно не константу-литерал а значение в ОЗУ) 24 бита и переслать это в приёмник 24 бита.
Сейчас это 12 циклов как видно из листинга, можно сделать короче ? Источник портить нельзя.

Re: Вычисляемый переход - проблема

Пт янв 25, 2019 08:00:12

А зачем короче? Это находится в цикле и повторяется много раз? Многобайтная сумма - это тривиальная операция со следующими подряд командами суммы и суммы с переносом. Чего тут копать, кроме адресации, да и то если речь идет о массивах?
Вы занимаетесь фигней...
:dont_know:

Re: Вычисляемый переход - проблема

Пт янв 25, 2019 21:58:03

Вы занимаетесь фигней...

С этим - заранее согласен.
А зачем короче?

А если это просто абстрактная задача ?
Это находится в цикле и повторяется много раз?

А если это находится в участке кода, где каждый цикл мелкопроца = 1% быстродействия ? А курочка - она по зёрнышку.
Многобайтная сумма - это тривиальная операция со следующими подряд командами суммы и суммы с переносом.

Тем более - если это тривиально - то где ответ на вопрос в задаче ?
Чего тут копать, кроме адресации, да и то если речь идет о массивах?

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

Когда коту делать нечего - он йайсы лижет глюкало полирует, согласен.
Но тем не менее - лично я только что получил первые результаты измерений быстродействия кода 12 бит:
1 - переход от 8 бит к 12 битам точности представления синуса&амплитуды&угла суммарно удлиннил вычислители 3х фаз на ~12 циклов - от ~210 до ~222.
2 - запас до тормозов фонового вывода на экран в прерывании АЦП+обработчик фаз ~250 циклов или ~4.7 МИПСа - достаточен для доп вычислений в фоне (деление отожрёт ~1 МИПС).
3 - после оптимизации копирования буферов АЦП - пропуски обработчика будут практически исключены (с учётом импульсов нагрузки от загрузки коэфф масштабирования/частоты ШИМ) и можно будет отключить контроль для повышения быстродействия.
4 - из приколов - заработал 1-Варе совокупно с 12 бит частотником, но: 16588 out of 16664 program addresses used, program memory utilization is 99% - заставит отказаться от нескольких таблиц 256*3 байта простых чисел для фиксированных частот. Ибо всё затевалось ради арифметического регулируемого компенсатора напряжения DC шины, в котором будет и деление тоже.

Re: Вычисляемый переход - проблема

Сб янв 26, 2019 07:52:22

Тем более - если это тривиально - то где ответ на вопрос в задаче ?

А нет никакой задачи.
Вы сами написали это тривиальное решение.
Его можно написать иначе, если аргументы будут массивом (то есть общая задача потребует перемножать элементы одного массива на элементы другого и размещать их в третьем).
Если же речь идет об однократном вызове функции до следующей смены значения этого же аргумента, то приведенный код и есть решение.
А вообще, в продолжение моей мысли о пустопорожней постановке вопроса, сама мысль о манипуляциях с кодом с целью выиграть одну строку является, как минимум, бестолковой. Оптимизация в компиляторе носит совершенно другую природу. Неоптимизированный код преследует цель доступности ОТЛАДКИ АЛГОРИТМА. А лишь потом выбирается критерий оптимизации - самый короткий код, самый быстрый код, компромисс между ними.
В неоптимизированном коде "лишние" строки будут обеспечивать видимость переменных при пошаговой отладке.
Интеллектуальность в экономии одной-двух строк при фиксировании АЛГОРИТМА равна нулю.
Вы реализуйте лучше весь свой умственный резерв в ОБЩЕМ схемотехническом и связанном с ним алгоритмическом решении.
А то копания в какой то ерунде, как правило сопровождаются совершенно тупым перебором там, где есть аналитическое решение...
ЗЫ. Я не вникал в приведенный Вами листинг - лениво и бессмысленно. Однако, очевидно, что высокая разрядность обработки - первый аргумент за увеличение разрядности АЛУ в МК. Даже с точки зрения ПОТРЕБЛЕНИЯ.
С другой стороны, очень часто выбранная разрядность никак не подтверждена расчетом. В цифровой петле регулирования ошибка регулирования не определяется разрядностью вычислений. :wink: :tea:

Re: Вычисляемый переход - проблема

Сб янв 26, 2019 18:01:49

Тем более - если это тривиально - то где ответ на вопрос в задаче ?

А нет никакой задачи..... Я не вникал в приведенный Вами листинг - лениво и бессмысленно.

Спасибо, я заметил.
А вот ещё возник вопрос - двух скоростной старт Pic18F2431 внезапно (после всяких там разных манипуляций с кодом в тч) стал работать неустойчиво - не видит тактовую 50 МГц на входе (на 1/4 выше штатной).
Собака пока отключена (отладка), иначе бы она кусала каждые 4 мСек до появления тактовой выше ~40 МГц.
В чём могет быть причина - китайский генератор стал "выдавать" или Pic-18 обиделся на разгон или код (в тч двухскоростного старта и перехода на резервную тактовую) виновен ?
Из дополнительных фактов - кроме неустойчивости старта по тактовой - сразу после включения была неустойчивость всего.

Re: Вычисляемый переход - проблема

Сб янв 26, 2019 18:41:21

на 1/4 выше штатной

:facepalm:
Это тоже интеллектуальный прорыв?
А собственно почему МК должен работать с превышением скоростных параметров даташита? :dont_know:

Re: Вычисляемый переход - проблема

Сб янв 26, 2019 20:07:32

на 1/4 выше штатной

Это тоже интеллектуальный прорыв?

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

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

Re: Вычисляемый переход - проблема

Вс янв 27, 2019 05:59:51

это спокойная жадность и трезвый расчёт

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

Это один транзистор можно отобрать. А когда их миллион, даже на одном кристалле, и когда дело совсем не в транзисторах, а в паразитных связях многослойной разводки поверх этих самых транзисторов, а так же миллионах разнообразных режимов взаимодействия этих самых паразитных параметров, тогда разгон становится источником совершенно необъяснимых багов. Задавать вопросы про причины этих багов как то странно. Вы не находите?
Скажем, у меня в свое время на PIC18F45K22 неустойчиво работал дебаг на частоте осциллятора 64 МГц. А релиз при этом прекрасно функционировал.
Какой уж тут разгон?

Спасибо, я заметил.

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

Re: Вычисляемый переход - проблема

Вс янв 27, 2019 08:07:21

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

Жадность состоит в том, чтобы взять один из самых дорогих МК семейства

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

Ну так-то согласен. Но - "лень" как причина/демотиватор - только ли лично мне свойственна ?
Или лично мне слышать "лень читать/вникать" в листинг 12 штук машинных слов от человека, который "за 2 дня освоил переход на Пик-24" - волшебно и удивительно ?
И "вместо тысячи слов" обоснования этой "лени вникать" с объяснениями "не читабельности алгоритма" но "тривиального алгоритма многобайтного сложения чисел" - не проще ли и быстрее ли было дать ответ на заданный вопрос ? Ибо вместо процитированных 4 циклов на байт - есть надежда сократить до 3 в системе команд Пик-18, а до 2 циклов на байт полагаю что надежды нет.
А про "устаревшую" систему команд - ну даже поговорить не с кем после "портянки из 12 слов".
А почему, собственно, нет ?
Или технологи научились уже выпускать транзисторы без разброса параметров?

Это один транзистор можно отобрать. А когда их миллион, даже на одном кристалле, и когда дело совсем не в транзисторах, а в паразитных связях многослойной разводки поверх этих самых транзисторов, а так же миллионах разнообразных режимов взаимодействия этих самых паразитных параметров, тогда разгон становится источником совершенно необъяснимых багов.

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

Не нахожу.
Задавать вопросы - вообще полезно. Даже если информация от ответов - не всегда ожидаемая, однако не значит что нулевая или бесполезная.
И доложу - разгадка того вопроса про 2 скорости старт/разгон - была мной найдена в процессе написания той мессаги, но убрана из мессаги.
И вижу сейчас - что не зря стёр разгадку, наблюдать за предположениями внешнего разума - любопытно.
А разве не решение абстрактных задач является одной из форм соревнования интеллектов ?
Скажем, у меня в свое время на PIC18F45K22 неустойчиво работал дебаг на частоте осциллятора 64 МГц. А релиз при этом прекрасно функционировал.
Какой уж тут разгон?

И у меня на Pic18 & ICD-2 такая же хрень - отладчики и эмуляторы не работают, а в натуре - всё Ок. Протеуса на него нет, согласен.
Но повторюсь - чья это жадность или тупость, моя или микрочипов ?
И второй момент - лично у меня спаяна/написана/чутка отлажена заготовка на Пик18Ф4431 которая вместо главного кварца использует LC контур с варикапом.
А на основе второго кварца она измеряет и выводит на экран собственную тактовую частоту, от которой имеем ШИМ с точной/плавной подстройкой на частоту резонанса силового модуля.
Менять её самостоятельно и поддерживать заданной - не дописал, однако - в ходе тех экспериментов - верхний предел умножителя частоты х4 ~15.2:15.5 МГц в Пик-18Ф4431 был обозначен весьма явно на нескольких имеющихся у меня экземплярах при питании 5.05 вольта от близко расположенного вторичного стаба и нормальной керамики шунтирующей питание максимально близко к кристаллу.
А без умножителя - полагаю что ещё выше тактовую можно поднимать. Хотя лично не пробовал.
А та затея (с точной подстройкой частоты ШИМ под резонанс силы) - ну дополнилась сейчас эксельным генератором коэффициентов для программного 4х октавного переключателя PTPER/PDC частоты ШИМ на лету.
Спасибо, я заметил.

К вопросу о ленивости чтения чужих пустопорожних портянок.

"Портянкой" мы называем листинг 12 машинных слов для обработки 3 байт ? Так-то характеризует объём буферов и навыки скорочтения, согласен.
Чего же тогда говорить "просто" про 500 страниц мануал на Пик-24 ? Или 5 страниц перечень его команд, ну для "освоения за 2 дня" ?
300+ вариаций его команд с нюансами использования - запомнить оказалось легче ?
А с тех пор буфера внезапно подусохли, лично я правильно понял разительное уменьшение глубины и скорости восприятия ?
Или это был разговор про людей с разными головами ? Или допинх/мильдоний ?
Во первых, совершенно непонятно зачем нужно приводить вместо исходника дизасм-листинг?

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

Ну текст макросов тоже когда-то выдумывался, писался и отлаживался. И да, в макросах тоже есть каменты, которые асм опускает до листинга.
Часть я поудалял перед публикацией, сокращая "портянку" до уровня "можно прочитать за 10 секунд".
Вижу что не помогло.
Комментарии понятны только автору, а чаще отражают то, что и так очевидно из комментируемой инструкции.

Если всё так очевидно - то где ответ на заданный тривиальный вопрос ?
Ну вместо тысячи слов - три команды/три цикла на байт ? Вместо имеющихся в листинге 4х ?
Мне это напомнило комментарии кода незабвенного Коробейникова...

Должен ли я чуйствовать себя как-то иначе от того, что некие люди в интернетах испытывают некие ассоциации от прочтения листинга из 12 слов ?
Особо после того, как эти люди лично мне рассказали про лень блуждания в пустопорожней портянке из 9 строк/12 слов, и алгоритм кривой, и каменты не те, и оформление не такое ?
Но вот когда "освоить за 2 дня" переход на Пик-24 - тогда да, это можно.
Глаза не режут противоречия в уровне интеллекта "инженера, мозг которого работает всегда и даже ночью, ибо это профи" ?
Или с одного аккаунта пишут иногда инженер и в основном его неумелая тёща ?
Последний раз редактировалось psw2.ru Вс янв 27, 2019 08:44:02, всего редактировалось 1 раз.
Ответить