Программирование Мк Требует Знаний Железа?

[tcoder]

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

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[forever_student]

...Не по существу. Нечего ответить чтоле?...

Не-а, нечего. Что тут ответишь, если Вы и про С в фирмах, и про меня итак знаете?

...Все 400 страниц читать небыло необходимости...

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

...В целочисленном? Т.е. возвращаемся к тем же сложностям, с каких начали - пытаться целочисленное число представлять, как дробную часть. А иначе опять - плавающая точка)...

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

Открою знатоку "азм с ПС" секрет - есть ещё такая штука -Apnotes называется. Там обычно всё это (и не только это) дело подробно расписывается...

...Во-вторых, касательно RGB-контроллера: табличный подход не годится...

Всё, end-ец, 400 страниц не читаем, всё и так знаем...

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

Не любых, а ограниченных размерами EEPROM.

Не зная ТЗ, не могу копать глубже, но плавные переходы для RGB делал (на Attiny13A), ничего страшного не увидел

...А это тут причём? Я говорю про плавную смену цвета, а Вы мне про "ты знаешь что такое ШИМ"... и межу 3 и 192 разницы нет...

При том, что между аппаратным 3-канальным ШИМ и программным 192-канальным есть разница.

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

Вот и попробуйте придумать, да не на asm реализовать такой алгоритм, да ещё чтобы "скорости хватило".

...*ps Если техника ломается по программной части (да и вообще) - либо Вам не везёт...

В раздел "Ремонт" на этом же самом форуме зайдите и полюбопытствуйте...

...либо у Вас руки простите... хехе...

Ну точно, самый осведомлённый (или телепат?)

Изменено 3 июня, 2014 пользователем forever_student

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[tcoder]

если Вы и про С в фирмах, и про меня итак знаете?

Про С в фирмах - это ни для кого не секрет. Про Вас я сужу по тому, что Вы пишете.

...Все 400 страниц читать небыло необходимости...

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

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

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

Да, для лифта можно напрямую было бы сделать. Но не для RGB.

...Во-вторых, касательно RGB-контроллера: табличный подход не годится...

Всё, end-ец, 400 страниц не читаем, всё и так знаем...

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

Не любых, а ограниченных размерами EEPROM.

Не зная ТЗ, не могу копать глубже, но плавные переходы для RGB делал (на Attiny13A), ничего страшного не увидел

Ну это уже придирки. Ограничено число цветов. Всё остальное ограничено разрядностью чисел а не размерами EEPROM.

При том, что между аппаратным 3-канальным ШИМ и программным 192-канальным есть разница.

Аппаратный шим у 628ого 1-канальный. Для лифта был применён. Для RGB был применён программный ШИМ.

Вот и попробуйте придумать, да не на asm реализовать такой алгоритм.

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

Ну точно, самый осведомлённый (или телепат?)

Не, это я так шучу.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[forever_student]

Про С в фирмах - это ни для кого не секрет...

Хотя бы "imho" писали, что ли.

...А в датащите нет информации "закатать таблицу в память", там всего лишь retlw. Сразу не допетришь...

А в голове должно быть вещество серое

И я там ещё про Apnotes что-то писал.

...Да, для лифта можно напрямую было бы сделать...

Ну где уж нам, неопытным .

Ещё один секрет открою: у кабины лифта такая масса, что 8-бит ШИМ (с целочисленными вычислениями!) выше головы...

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

Пытаемся включить то, что между ушами и догадаться:

- сколько переходов внутри одного цвета,

- что для разных цветов таблицы будут абсолютно одинаковыми,

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

...Аппаратный шим у 628ого 1-канальный...

Хорошо, 3 и 192 канала программного ШИМ - это не одно и то же.

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

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

Всё заканчиваю. Разбирайтесь с таблицами.

[hardbar]

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

А по сути, автору: Если умеешь программировать , то учи архитектуру микроконтролеров ( без знания железа далеко не уедешь).

Наличие всех водительских категорий не означает что вы с легкостью поедете на танке.

[COKPOWEHEU]

"как закатать и использовать таблицу в память программ" и " Во вторых в каком виде хранить эту таблицу?"

Видимо, спецы по "азм - ПК" не знают про "замовскую" же директиву .db/.dw, позволяющую разместить любые данные в любой области памяти. Те же спецы по Си не знают PROGMEM const char, или как там это в ваших пиках.

Можно применить школьную формулу, отталкиваясь от 1сек., потом делить, умножать, возводить в степень и приводить результат к целочисленным значениям... А сразу это сделать (поработать с целочисленными) нельзя?

Имелись в виду вычисления с фиксированной точкой?

Матрица LED 8х24 (т.е. квадрат 8х8 RGB)

С расширителями портов, получается. А максимальная яркость не пострадала? И что-то мне казалось, что при таком количестве каналов может не хватать скорости - мерцать начнет. Не было таких проблем?

[tcoder]

Хотя бы "imho" писали, что ли.

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

Пытаемся включить то, что между ушами и догадаться:

- сколько переходов внутри одного цвета,

- что для разных цветов таблицы будут абсолютно одинаковыми,

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

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

R G B

255,32,150

10,210,130

255,255,255

30,160,200

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

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

Я уже всё сказал. Всё различие только в скорости. Использование Си не накладывает ограничение на использование возможностей МК.

Разбирайтесь с таблицами.

Неактуально.

Изменено 3 июня, 2014 пользователем tcoder

[forever_student]

...С расширителями портов, получается...

373+ключи

...А максимальная яркость не пострадала?...

Нет, не пострадала. Конечно, она была ниже, чем в статике на номинальном токе.

...И что-то мне казалось, что при таком количестве каналов может не хватать скорости - мерцать начнет. Не было таких проблем?

Точно уже не помню, но частота обновления была выше 60 Гц.

[tcoder]

Видимо, спецы по "азм - ПК" не знают про "замовскую" же директиву .db/.dw

Видимо другие спецы не в курсе, что у PC вся память 8-разрядная и к тому же единственная, и израсходовать её всю даже при большом желании не получается. А также другие спецы не в курсе, что у pic16f628a и вероятно у большинства других PIC 14-разрядные ячейки в памяти программ, доступ к которым осуществить программно невозможно. Хотя бы потому, что они 14-разрядные. Единственный способ достать данные из флеши - это прописать в неё команду retlw c константой, соответствующей сохраняемому байту и потом вызывать её, как подпрограмму.

Ещё не забываем учесть, что ассемблер AVR и IBM-совместимых - весьма дутые, чего о PIC-овском не скажешь.

Изменено 3 июня, 2014 пользователем tcoder

[COKPOWEHEU]

Видимо другие спецы не в курсе, что у PC вся память 8-разрядная и к тому же единственная

Что имеется в виду под 8-разрядностью? Да, в PC память программ и данных объединены, в отличие от контроллеров. Это добавляет проблем программистам на Си, но не на ассемблере, где можно явно указать в каком сегмента расположить данные - cseg, dseg.

Единственный способ достать данные из флеши

С пиками дела не имел, может так и есть. Но в любом случае, согласно даташиту, там есть еще 128 байт EEPROM. Опять же можно посмотреть во что дизассемблируется преинициализация (const char str[]="string"; например) и сделать по аналогии. Надеюсь, там что-то поприличнее списка MOVLV.

ассемблер AVR и IBM-совместимых- весьма дутые

Что имеется в виду?

[tcoder]

Что имеется в виду под 8-разрядностью?

Имеется ввиду разрядность ячеек (на фоне 14-разрядных из памяти программ). Какое отношение к делу имеет размер "переменной" (db,dw,dd и т.п.) - не совсем понятно. Остальное Вы и сами написали. Только какой смысл вмешиваться в сегмент кода (за исключением всяких экспериментов с динамическим формированием кода), когда блоки памяти на ПК можно выделять сколько влезет.

там есть еще 128 байт EEPROM.

Так не влезет - если тупо в неё записать цветовые трёшки, которые друг друга должны сменять - получится всего по 7 "семплов" на каждый переход - грубовато. (128 байт / 3 = 42 семпла всего. 42 возможных семпла / 6 заказанных цветов = 7 "семплов на переход", и ещё нужно учесть, что ключевые цвета должны удерживаться с определённой длительностью).

Опять же можно посмотреть во что дизассемблируется преинициализация (const char str[]="string"; например) и сделать по аналогии. Надеюсь, там что-то поприличнее списка MOVLV.

Интересный вопрос - куда же и каким образом он это дело сделает. И вообще интересно, как работает тема с буферами в таких стеснённых условиях.

весьма дутые

Что имеется в виду?

Имеется ввиду общее число инструкций.

[COKPOWEHEU]

получится всего по 7 "семплов" на каждый переход

Так сам переход можно рассчитывать динамически, без таблиц. Или там что-то намного более сложное, чем линейный переход?

Интересный вопрос - куда же и каким образом он это дело сделает. И вообще интересно, как работает тема с буферами в таких стеснённых условиях.

Это вполне корректная операция для Си и, надеюсь, разработчики компилятора сумели ее корректно реализовать.

Согласно даташиту, в PIC16F628A аж 2048 слов флеша, 224 байта ОЗУ и 128 байт EEPROM, где ж тут стесненность? Для сравнения, в ATtiny11 всего 512 слов флеша и полностью отсутствуют ОЗУ и EEPROM, только 3-уровневый аппаратный стек. А ведь под них тоже можно программировать на Си. Объемы памяти PIC16F628 скорее похожи на ATtiny44, а это по описанию вполне мощный контроллер.

Имеется ввиду общее число инструкций.

У AVR для всех команд, кроме работы с ОЗУ и переходами (где нужно указывать двух- и более -байтный адрес) - ровно 16 бит. Включая операнды, разумеется. На счет х86 не уверен, но там CISC архитектура, куча похожих команд с разными типами операндов. Скорее всего да, х86 сильно избыточна. В AVR на самом деле не столько команд много, сколько их обозначений: CLC, CLH, CLI, CLN, CLS, CLT, CLV, CLZ - вариации команды BSET. Опять-таки, в ряде случаев отсутствует необходимость (а в некоторых - и возможность) использования ОЗУ, когда хватает РОНов, конвейер, обеспечивающий выполнения большинства команд за 1 такт, отсутствие извращений с записью/чтением флеш (кроме, может быть, совсем уж мелочи, типа 6-ногой ATtiny10, зато в ATtiny13 уже никаких проблем), линейная организация памяти.

[tcoder]

Так сам переход можно рассчитывать динамически, без таблиц.

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

в PIC16F628A аж 2048 слов флеша, 224 байта ОЗУ и 128 байт EEPROM, где ж тут стесненность?

В 224 байтах ОЗУ (на мой взгляд). Про флешку спору нет.

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

АВР-овский подробно не изучал, но он чем то отдалённо напомнает x86, есть РОНы (а у PIC вместо них ОЗУ за исключением аккума) и у команд по работе с памятью возможностей наверно всё же побольше в сравнении с PIC.

[COKPOWEHEU]

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

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

АВР-овский подробно не изучал, но он чем то отдалённо напомнает x86, есть РОНы (а у PIC вместо них ОЗУ за исключением аккума) и у команд по работе с памятью возможностей наверно всё же побольше в сравнении с PIC.

Я бы сказал наоборот, в х86 немного регистров и они специализированы. Он принципиально должен работать с памятью. В отличие от AVR, где 16 универсальных независимых регистров (и еще 16 ограниченных), на которых одних можно строить довольно сложные алгоритмы. В этом же заключается и недостаток AVR при использовании RTOS: надо сохранить, а потом загрузить аж 32 РОН и примерно 3 системных регистра.

[tcoder]

"Втирают" именно то, что числа с плавающей точкой нужны достаточно редко, поскольку их обработка достаточно накладна для процессора.

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

Например от цвета 0,10,255 сделать переход к цвету 1,100,0. Из этого следует:

R изменится от 0 к 1

G изменится от 10 к 50

B изменится от 255 к 0

Эталон времени возьмем 10 секунд (по ТЗ строго не регламентировалось, устанавливалось через программу методом тыка)

Из этого следует что канал R должен измениться на +1, канал G на +40, канал B на -255 ровно за 10 секунд (или любой другой отрезок времени). Интересно было бы посмотреть целочисленное решение (действительно интересно, никакого стёба или намёков)

АВР-овский подробно не изучал, но он чем то отдалённо напомнает x86

Я бы сказал наоборот, в х86 немного регистров и они специализированы. Он принципиально должен работать с памятью. В отличие от AVR, где 16 универсальных независимых регистров (и еще 16 ограниченных)...

Я имел ввиду принципиальную схожесть:

Память отдельно, регистры отдельно:

AVR,x86,Z80,8031/51 и т.п. - да

PIC - из регистров только аккум. Остальное на уровне инструкций - память, включая и управляющие регистры. кроме того разделённые на банки.

Условные переходы на адрес:

AVR,x86,Z80,8031/51 и т.п. - есть

PIC - нет, делается по другому

Относительные переходы:

AVR,x86,Z80,8031/51 и т.п. - есть

PIC - нет

Выбор, в какой операнд сохранить результат операции:

AVR,x86,Z80,8031/51 и т.п. - нет

PIC - есть

Разновидности команд работы с памятью, предусматривающие использование смещения:

AVR,x86,Z80,8031/51 и т.п. - есть

PIC - нет, делается через специальный механизм

На мой взгляд различия заметные у основной массы и PIC. Наверняка ещё что-то более мелкое есть у АВРки IN, OUT, как и у x86, Z80 и т.п. и даже смысл схож, у PIC нет.

===

Ну и по регистрам X86. Их немного, если не учитывать их разрядности. Во первых регистры x86 не особо специализированы - есть 4 РОН - (E)AX,(E)BX,(E)CX,(E)DX - если использовать части по 8 бит, их уже получается (8)16. Соглашусь что доступ к старшим 16 битам в 32-разрядных версиях осуществляется не очень удобно, то к младшим - вполне. Кроме этих четырех также в общих целях можно использовать (E)SI,(E)DI,(E)BP. (64-разрядные варианты ЦП опустим). Ряд этих регистров конечно может использоваться для задания режима работы некоторых команд, но это делу не особо мешает.

Изменено 4 июня, 2014 пользователем tcoder

[COKPOWEHEU]

Насчет х86 судить не буду, на ассемблере писал под него мало и давно, Z80, 8031/8051 в глаза не видел, обсуждать не буду. По PIC сужу по даташиту, только AVR по опыту.

Память отдельно, регистры отдельно:

Регистры (не только РОН) AVR являются частью памяти и, хотя допускают прямой доступ, доступны и из памяти. В х86 и PIC память является таким же аргументом команд, как РОН.

Относительные переходы:

А как тогда в Си для пиков реализованы указатели на функции? Правда любопытно.

Выбор, в какой операнд сохранить результат операции:

Имеется в виду, что команда может обрабатывать ячейку памяти плюс W и записать результат во что-нибудь из них? Вроде, х86 тоже умеет напрямую общаться с памятью, хотя писать туда результаты команд вряд ли. В AVR любая команда яда (модуль умножения не в счет) общается с любыми РОН, как для чтения, так и для записи. Например, AND r20,r30 записывает результат в r20. А команда AND r30,r20 наоборот. Для общения с ОЗУ там отдельные команды.

Ну и по регистрам X86. Их немного, если не учитывать их разрядности.

В том-то и дело, что РОНов там всего 4. С ходу не припомню команд, обращающихся к старшим байтам, кроме, может, копирования и тому подобного.

[tcoder]

В х86 и PIC память является таким же аргументом команд, как РОН.

Дело в том, что у пика нет РОН. Все команды, связанные с данными работают только с участием аккума(w) и других вариантов вместо аккума нет. Фактически все операции с данными в PIC - работа с памятью. Правда в датащите РОН-ом считается вся пользовательская оперативная память.

Относительные переходы

А как тогда в Си для пиков реализованы указатели на функции? Правда любопытно.

А абсолютными указателями запретили пользоваться? Команде goto (как и call) указывается абсолютный адрес в памяти программ (и тот неполный, часть его в сторонних регистрах - ещё одна фича). Перехода относительно текущего PC не предусмотрено. (стр 123 - команда goto, стр 121 - команда call). Хотя надо глянуть, можно ли напрямую на PC воздействовать - если да, то можно искусственно относительный переход создать, но он будет бессмысленнен - экономия места для данной архитектуры невозможна, т.к. все инструкции занимают 14-битное слово, и двигать код тоже смысла нет.

Выбор, в какой операнд сохранить результат операции:

Имеется в виду, что команда может обрабатывать ячейку памяти плюс W и записать результат во что-нибудь из них?

Вроде, х86 тоже умеет напрямую общаться с памятью, хотя писать туда результаты команд вряд ли.

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

в мнемонике:

addwf myreg,W - сложит содержимое w(аккум) и содержимое ячейки myreg, результат будет в аккуме, ячейка myreg без изменений

addwf myreg,F - сложит содержимое w(аккум) и содержимое ячейки myreg, но результат будет в ячейке myreg, а аккум будет без изменений

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

С ходу не припомню команд, обращающихся к старшим байтам, кроме, может, копирования и тому подобного.

На примере А - младшие 16 бит доступны как АХ, или индивидуально по частям они же - АН и AL (по 8 бит) - это наследие 16-разрядного 8086. В 32-битных версиях старшие 16 бит недоступны для изменений в регистре, и чтобы их достать, нужно сдвиг на 16 выполнить по EAX, тогда старшая половина в доступную область встанет - обрабатывать и затем на место откручивать. Возможно ещё был обмен 16-битными половинами (не припомню точно). Но в память они чётко переносятся как есть - без всяких проблем и оттуда в регистр также замечательно - по 4 байта.

Изменено 4 июня, 2014 пользователем tcoder

[COKPOWEHEU]

Относительные переходы

Я потому указатель на функцию и упомянул, что ее адрес должен храниться в памяти, а переход по адресу, сохраненному в памяти я в даташите не нашел.

Что-то в этом роде:

char func1(char x){return x+1;}

char func2(char x){return x-1;}

int main(){

char (*func)(char);

char res;

func=func1;

res=func(1);

func=func2;

res=func(2);

return 0;

}

Дело в том, что у пика нет РОН

РОН - регистр(ы) общего назначения. Аккумулятор не подходит под это определение?

x86 вроде и с ячейкой памяти может работать, также как с регистром

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

в мнемонике:

Да, это я уже в даташите прочитал. В том-то и дело, что в х86 также обращаются к ОЗУ в команде (хоть и вернуть туда результат невозможно), а в AVR ОЗУ - отдельный блок, доступ к которому осуществляется специальными командами и никто кроме них общаться с ОЗУ не умеет. Зато любая команда может получать и возвращать данные в любой регистр (большинство - r16-r31, некоторые - r0-r31, умножение - r0 и r1).

На примере А - младшие 16 бит доступны как АХ, или индивидуально по частям они же - АН и AL

Да, про AH, AL забыл. На все равно, если ядро 32-разрядное, то и регистры стоит считать такими же. И, насколько я помню, только на регистрах под х86 много не накодишь, он заточен под операции с памятью, как и PIC. В отличие от AVR: как я уже упоминал, ОЗУ там не всегда присутствует и доступно только через специальные команды.

[tcoder]

а переход по адресу, сохраненному в памяти я в даташите не нашел.

Команды нет, но выход имеется - там всё же есть доступ к указателю команды (PC), разбитый на два регистра. Т.е. теоретически можно взять значение и посредством w загнать его в PC. Только решение походу ограниченным получается, потому что PC на две половины разбит и в два этапа загрузить полный адрес не получается. Хотя возможно там есть специальный механизм (не вникал) имеются регистры PCLATCH. Название наводит на определённые размышления... А вот с вызовом подпрограммы по адресу сложнее получается или совсем не получается... стек то аппаратный и срабатывает походу только с применением call

РОН - регистр(ы) общего назначения. Аккумулятор не подходит под это определение?

Подходит как нельзя лучше, но тут как то уже все смазано относительно классической схемы... В датащите РОН-ами названы свободные от управляющих регистров ячейки памяти (General Purpose Registers) - по чуть чуть в каждом банке. Равняясь на классическую схему можно сказать, что РОН у пика один, а всё остальное - память. Потому все команды однооперандовые получились.

x86 вроде и с ячейкой памяти может работать, также как с регистром

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

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

add [addr],AL - прибавить содержимое регистра к содержимому ячейки и сохранить в ячейке

add [addr],30 - и даже так: прибавть к содержимому ячейки число и сохранить в ячейке

add [addr],[addr] - а вот так уже нельзя сделать, тут как раз и нужно использование регистра (ну оно и логично, если учесть что проц и память - разные устройства).

разумеется такие же правила действуют касательно остальных арифметических и логических операций, а также касается MOV. Кроме того есть вариации команд, которые позволяют указывать адрес относительно регистров то ли EBX, то ли EBP - не могу вспомнить. Запись в мнемонике была типа [EBX+смещение] или вроде того. Возможно, где то есть исключения. Что-то такое на памяти есть. **походу вместо адреса можно любой из РОНов подставлять, но для всех ли допускается ещё дополнительное смещение на константу, непонятно.

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

все равно, если ядро 32-разрядное, то и регистры стоит считать такими же. И, насколько я помню, только на регистрах под х86 много не накодишь, он заточен под операции с памятью, как и PIC. В отличие от AVR: как я уже упоминал, ОЗУ там не всегда присутствует и доступно только через специальные команды.

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

На 6 регистрах конечно не накодишь.

Изменено 4 июня, 2014 пользователем tcoder

[COKPOWEHEU]

Если не сложно, не могли бы вы проверить во что переводятся сишные команды создания переменной со значением (char str[]="string") и указатели на функции (примерный код в 68 посте приводил)?

Ради интереса проверю тоже самое для ATtiny11, в которой нет ОЗУ.

UPD: а вот не судьба, оно для ATtiny11 умеет только с ассемблером работать.

Изменено 4 июня, 2014 пользователем COKPOWEHEU

[tcoder]

Я бы с удовольствием проверил, но как я уже печатал в этой теме - на Си 8-ми битные контроллеры не программировал, а потому пришлось вкусить все прелести целочисленных решений на ассемблерах, убив кучу времени. Так что придётся кого нибудь ещё привлечь. Хотя когда до дома доберусь, могу попробовать поставить си микрочиповский, и что нито скомпилить. Отпишу вечером.

[tcoder]

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

Результат вполне ожидаемый, на который я ссылался:

#include <pic16f628a.h>
void main(){
char str[]="123";
str[0]=0x55;
str[1]=0x66;
str[2]=0x77;
}

И что вышло:

0000 2FE1 GOTO 0x7E1

..... пустой кусок

//Далее тут пошаговый перенос данных из флеши в оперативку, причём данные сохранены в виде возврата с параметром, как я и говорил.
// строка str[]="123";
07E1 27DD CALL 0x7DD ----> 07DD 3431 RETLW 0x31
07E2 00F5 MOVWF 0x75 //Исходный str[0]
07E3 27DE CALL 0x7DE ----> 07DE 3432 RETLW 0x32
07E4 00F6 MOVWF 0x76 //Исходный str[1]
07E5 27DF CALL 0x7DF ----> 07DF 3433 RETLW 0x33
07E6 00F7 MOVWF 0x77 //Исходный str[2]
07E7 27E0 CALL 0x7E0 ---> 07E0 3400 RETLW 0x00
07E8 00F8 MOVWF 0x78 //Исходный str[3] (терминирующий ноль)

//Бесполезная махинация, наверно компилятору так нужно
07E9 0183 CLRF STATUS
07EA 2FEB GOTO 0x7EB

//Далее делается копия этого блока в другой участок оперативки, видимо тот, который будет фактическим массивом, а тот что выше, видимо как исходный.
07EB 0878 MOVF 0x78,W //Из 78 в 74 - фактический str[3]
07EC 00F4 MOVWF 0x74

07ED 0877 MOVF 0x77,W //Из 77 в 73 - фактический str[2]
07EE 00F3 MOVWF 0x73
07EF 0876 MOVF 0x76,W //Из 76 в 72 - фактический str[1]
07F0 00F2 MOVWF 0x72
07F1 0875 MOVF 0x75,W //Из 75 в 71 - фактический str[0]
07F2 00F1 MOVWF 0x71

//Теперь заполнение другими данными - убойный по организации кусман, но действует
// строка str[0]=0x55;
07F3 3055 MOVLW 0x55 //Заносим 55 в видимо промежуточную ячейку 70
07F4 00F0 MOVWF 0x70
07F5 0870 MOVF 0x70,W //Снова читаем и переносим в ячейку 71 (str[0])
07F6 00F1 MOVWF 0x71
// строка str[1]=0x66;
07F7 3066 MOVLW 0x66 //Заносим 66 опять в промежуточную ячейку 70
07F8 00F0 MOVWF 0x70
07F9 0870 MOVF 0x70,W //Опять оттуда же читаем и пишем в 72 (str[1])
07FA 00F2 MOVWF 0x72
// строка str[2]=0x77;
07FB 3077 MOVLW 0x77 // И снова пишем в промежуточную 77
07FC 00F0 MOVWF 0x70
07FD 0870 MOVF 0x70,W //и оттуда в 73 (str[2])
07FE 00F3 MOVWF 0x73

//И всё. Функция закольцована автоматом
07FF 2800 GOTO 0x000

Т.е. в целом:

1) Достаёт данные, сохранённые в виде retlw из флеша и закидывает их в исходный буфер в ОЗУ

2) Исходный буфер ОЗУ копирует в другое место, которое по факту будет содержать значения массива

3) При попытке записать что-то в массив закидывает значение в промежуточную ячейку, и оттуда куда надо.

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

Изменено 4 июня, 2014 пользователем tcoder

[tcoder]

====

Касательно ссылок на функции - скопировал код, как есть, Ваш. Компилится. Вникать неохота, но суть понятно - он проводит прямые махинации с PCL - указателем команды. Т.е. вызов подпрограммы идёт на один и тот же адрес, и в её начале сразу же следует воздействие на PCLATH и PCL, которое судя по всему и передаёт управление на нужный участок.

0000 2F2B GOTO 0x72B
.... пусто ...
0700 00FF MOVWF 0x7F     //Штука, отвечающая за вызов функции
0701 3007 MOVLW 0x07    //Тут пододвигается на нужную величину указатель команд
0702 008A MOVWF PCLATH
0703 087F MOVF 0x7F,W
0704 0782 ADDWF PCL,F   
0705 2F05 GOTO 0x705

//Развилка - какая функция вызывается
0706 2F27 GOTO 0x727 //после инструкции в адресе 704 попадает или сюда, или чуть ниже 
0707 2F23 GOTO 0x723

//точка входа
0708 3002 MOVLW 0x02
0709 00F1 MOVWF 0x71
070A 0871 MOVF 0x71,W
070B 00F4 MOVWF 0x74
070C 01F0 CLRF 0x70
070D 1403 BSF STATUS,C
070E 0DF0 RLF 0x70,F
070F 0874 MOVF 0x74,W
0710 2700 CALL 0x700 //первый вызов
0711 00F1 MOVWF 0x71
0712 0871 MOVF 0x71,W
0713 00F3 MOVWF 0x73
0714 3001 MOVLW 0x01
0715 00F1 MOVWF 0x71
0716 0871 MOVF 0x71,W
0717 00F4 MOVWF 0x74
0718 3002 MOVLW 0x02
0719 00F1 MOVWF 0x71
071A 0871 MOVF 0x71,W
071B 00F0 MOVWF 0x70
071C 0874 MOVF 0x74,W
071D 2700 CALL 0x700 //второй вызов
071E 00F2 MOVWF 0x72
071F 0872 MOVF 0x72,W
0720 00F3 MOVWF 0x73
0721 2F22 GOTO 0x722
0722 2800 GOTO 0x000

//Видимо функции - в 70 ячейке передаваемый параметр

0723 0870 MOVF 0x70,W //Вот видимо код функции с x+1 (func1)
0724 3E01 ADDLW 0x01
0725 2F26 GOTO 0x726
0726 0008 RETURN

0727 0870 MOVF 0x70,W //Вот видимо код функции c x-1 (func2),
0728 3EFF ADDLW 0xFF
0729 2F2A GOTO 0x72A
072A 0008 RETURN

072B 0183 CLRF STATUS
072C 2F08 GOTO 0x708

Изменено 4 июня, 2014 пользователем tcoder

[Геннадий]

Не скажу как у вас в Пиках, а у АВР такие "//Бесполезная махинация, наверно компилятору так нужно..." как раз и могут являются адресом перехода или набором данных в памяти программ. Поэтому кажется что дизассемблер их как-то "неадекватно" вписывает в листинг (несколько бессмысленных команд, вырванных из общей цепочки алгоритма). Далее эти значения считываются (LPM) в индексные регистры (Z) и вызывается косвенный переход (IJMP). Снова оговорюсь, это для АВР.

Изменено 4 июня, 2014 пользователем Геннадий

[COKPOWEHEU]

В AVR преинициализация может компилироваться в команды загрузки чисел сразу в нужные регистры или память, либо побайтным копированием массива из флеш в ОЗУ в цикле, зависит от режима оптимизации и размера массива (5 чисел он скорее будет читать непосредственно, а сотню - через копирование.

Указатель на функцию - через команду ICALL, которая значит то же самое - вызов функции по адресу, расположенному в r31:r30.

Для архитектуры PIC расположение в флеш в каждого байта в виде машинного слова вполне оптимально: два байта в машинном слове все равно не разместить.

Геннадий, нет: предзагруженные значения он хранит после кода, в выдаваемом ассемблерном листинге (*.lss) их вообще нет, надо дизассемблировать прошивку. А "бесполезные махинации" могут быть бесполезны в конкретном коде, но необходимы для каких-то библиотек. Тот же AVR-Си записывает в r0 значение 0, даже если потом не использует.

Кстати, это во всех PIC такое шаманство приходится городить с флеш и переходами по переменной, или только с этой серией?

Изменено 4 июня, 2014 пользователем COKPOWEHEU