Котуинко

[oleg110592]

изначально про Z80 было...
запамятовал - а у АВРки есть типа:

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

and A, ([$1000],X)

[BOB51]

От Z80 там организация ядра - единственный аккумулятор и индекс-регистры.
Да и немного аббревиатура команд.
Можно вспомнить подлист обработки битов (префикс 0xCB) в котором проверяются, устанавливаются или сбрасываются битвы ячеек , адрес которых указан или в HL или в индексных регистрах IX/IY
полный код
0xDD 0xCB байт смещения код операции - это максимально навороченное
или попроще
0xCB код операции - там все 256 вариантов работают.
Да блочно-модульные пересылки массивов с возможностью поиска совпадения данных.
Кстати и косвенные пересылки у Z80 имели место
0xDD/0xFD LD REG,(ii+rel) где REG - любой из A-L

[dosikus]

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

Затравка первая -помигать ледом аппаратно при помощи таймера... Ну , соберись с силами...

И это, насчет z80 , ты не тупи -там ядро другое. Знаток асм, мля, похоже ты и ни асм не знаешь и ге архитектуру...

[BOB51]

Да неуж- то "не та"?
Может стоит вспомнить получше?

Единственно добавлен механизм переключения регистровых блоков (правда без индексации какой из них конкретно в данный момент используется).
Не шипи досикус - Z80 таки имел весьма мощную систему команд. Да и неплохо воспринимаемую.
Касательно " замигайки" на пилюльке - я уже говорил "надкушу" - т.е. проверка предположений, а не конкретный проект.
Что и было сделано.
Честно говоря - Х/З куда ту пилюльку с пользой за...пихнуть...

Мне и старых МК с избытком хватает, а сетевые приложения на повестке дня не стоят...
Было ещё в планах чего сравнительного для нанки и пилюльки набросать... Да там надо конструкцию под 3.3 вольтовое питание подгонять для обеих вариантов - а те индикаторы, что мне удобнее у большинства отсутствуют.
Пихать общедоступные мне не интересно.
Воть и отложено до лучших времён.

[Eddy_Em]

Первое, на чем я что-то пробовал писать, и был "советский эмулятор Z80". Только у меня там места для ассемблера не было, приходилось на встроенном бейсике писать + добавлять машкоды. Которые писались вручную. Сначала нужный код писался псевдоассемблером (в 12 лет я еще понятия не имел об ассемблере, честно говоря), а дальше все по табличкам (то ли из "техника-молодежи", то ли из "радио") переводилось в машкоды...
Какое счастье, что сейчас не нужно так над собой издеваться. И можно писать на нормальном человеческом С!

[ARV]

Затравка первая -помигать ледом аппаратно при помощи таймера...

аргумент на 100% такой же, как и у поклонников айфонов: раз новый айфон вышел, его надо брать и пробовать! у него пикселы круглее, гигагерцы быстрее и вообще крутизна круче!

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

все твои потуги рассказать о том, что движение вперед равносильно изучению ARM разбиваются о реальность: посмотри на нынешний конкурс. не спасают новые способы мигания светодиодом... чем дальше в лес, тем скуднее разнообразие. спустя 3-4 года все проекты за рамки даташитов и code sample не будут выходить вообще.

[oleg110592]

[uquote="BOB51",url="/forum/viewtopic.php?p=3712874#p3712874"]От Z80 там организация ядра - единственный аккумулятор и индекс-регистры.[/uquote]
еще дальше от STM8:
Z80 регистры

Спойлер

8-битные регистры:
А также называется «аккумулятор». Это основной регистр для арифметических операций и доступа к памяти.
B обычно используется как 8-битный счетчик.
C используется, когда вы хотите взаимодействовать с аппаратными портами.
D обычно не используется в его 8-битной форме. Вместо этого он используется в сочетании с E.
E , опять же, не используется в своей 8-битной форме.
F известен как флаги. Это тот регистр, с которым вы не можете связываться на байтовом уровне. Его использование будет обсуждаться позже в разделе « Флаги и инструкции уровня битов» .
H - другой регистр, обычно не используемый в 8-битной форме.
L - еще один регистр, обычно не используемый в 8-битной форме.
ярегистр вектора прерывания. Используется калькулятором в режиме прерывания 2.
R - это регистр обновления. Хотя он не имеет конкретной цели для ОС, он может использоваться для генерации случайных чисел.
IXH Старший (первый) байт регистра IX. Обратите внимание , что я это не тем выше байт IX. Объединяется с IXL, чтобы сделать регистр IX.
IXL Нижний (второй) байт регистра IX. В сочетании с IXH эти два регистра составляют регистр IX.
IYH Опять же, это старший байт регистра IY. Обратите внимание, что IYH отличается от I и IXH . Объединяется с IYL, чтобы сделать регистр IY.
IYLМладший байт регистра IX. Объединяется с IYH для создания регистра IY.

16-битные регистры:
AF обычно не используется из-за F, который используется для хранения флагов.
BC используется инструкциями и разделами кода, которые работают с потоками байтов в качестве счетчика байтов. Также используется как 16-битный счетчик.
DE содержит адрес ячейки памяти, которая является пунктом назначения.
HL Общий 16-битный регистр, он используется почти везде, где вы используете 16-битные регистры. Это наиболее распространенное использование для 16-битной арифметики и хранения адресов вещей (строк, изображений, меток и т. Д.). Обратите внимание, что HL обычно содержит исходный адрес, а DE - адрес назначения.
PC Счетчик программ. Он содержит точку памяти, из которой процессор выполняет код. Никакая функция не может изменить компьютер, кроме как на самом деле перейти в другое место в памяти.
SP Указатель стека. Он содержит текущий адрес вершины стека.
IX называется индексным регистром. Его использование аналогично HL, но его использование должно быть ограничено, так как оно имеет другие цели, а также работает медленнее, чем HL.
IY - еще один индексный регистр. Он содержит расположение системных флагов и используется, когда вы хотите изменить определенный флаг.

вот STM8 на MOS Technology 6502 похож да - один 8-разрядный аккумулятор A, два 8-разрядных индексных регистра X и Y, 8-разрядный указатель стека S, 8-разрядный регистр флажков P, 16-разрядный указатель команды PC и всё!

[BOB51]

"...вот STM8 на MOS Technology 6502 похож да - один 8-разрядный аккумулятор A, два 8-разрядных индексных регистра X и Y, 8-разрядный указатель стека S, 8-разрядный регистр флажков P, 16-разрядный указатель команды PC и всё!..."

А у Z80 нету 8-разрядного акумулятора, двух 16- разрядных индексных регистров (даже трех, с учетом применения HL) и указателя стека с флаг-регистром?
Ну да, еще и пара блокомв РОН в придачу - это же совсем не в пользу подобия!

Речь не о полном совпадении, а о подобии.
Ничего особо нового у STM8 в том плане не добавилось (а кое чего и нету).
Кстати... При работе с АВРками весьма удобно их файл СОЗУ R0-R31 приравнивать к какой-либо из иных моделей -
или раскидывать как Z80/i8086/88 или приводить к аналогии с mcs51 или свое распределение делать.
Весьма удобно. Правда такой подход только под чистым ассемблером возможен. Си сразу "лапы отобьёт" свободному планированию/распределению ресурсов.

Самый интересный с моей точки зрения МК - PIC24 ... однако ни в ближнем окружении такового нету, ни в отношении цен и диапазона питающих напряжений он ... УВЫ... пока "в зоне помечтать"...
Отложено "до лучших времен"...

Насчет "замигайки" - там смысл был не в том, чтоб "помигать", а в том, чтоб разобраться в чужой ошибке и указать на ее устранение.
Плохо, когда начинающим попадает заведомо неработоспособный пример, результатом которого может стать отказ от применения элементной базы.
Заодно и по "особенностям" применения UART пилюльки под адуринкой прошелся - это же первое средство контроля, а тут не с того стартовал и ... ответа в терминал НЕТУ.
Так что "надкус" прошел с пользой.
Относительно "ассемблера с листочком и карандашиком" - штука вполне на уровне.
Правда там несколько табличек держать перед глазами надо, да еще приемы корректировки/правки ошибок специфичны...
Единственно МК, поддерживающих такой подход не так много - I8080, Z80, mcs48, mcs51...
В плюсе - не требуется никаких ПК и операционок.
Устройство создается при условии наличия простейшей рассыпухи и терпения буквально "с нуля".
С иными МК уже без наличия ПК и софта разработки НЕ СПРАВИТЬСЯ.


И... раз уж пошел разговор о подобии...
На AVR - на основе ее базового блока регистр-аккумуляторов СОЗУ R0-R31 в принципе можно смоделировать любой из 8-разрядных МК/МП...
А вот смоделировать AVR ку разве что на PIC24 удастся...
Или кто из МАТЕРЫХ КОТОВ чего иного мяучить может?

[oleg110592]

ну если подобие, то AVR даже похоже более :
R26 и R27 – сдвоенный регистр “Х”
R28 и R29 – сдвоенный регистр “Y”
R16 - используем как A
з.ы. по PIC24 лучше на Сахаре поспрашивать - таи есть мощные дяди, делающие мощные вещи на PIC24/DSPIC.. на ассемблере

[BOB51]

Так и говорится - ПОДОБИЕ.
Кстати... при моделировании используем не только "верхнюю половину", но и "урезанные" по функционалу R0-R15
Правда их назначение - это уже творчество...
Можно и как "теневой стек" и как системные регистры определить.

За 24-й пока все же "на будущее" - ибо ни области бытового применения, ни наличия в ближнее время не предвидится.

Сегодня даже пилюльку с надлежащей пользой задействовать особо некуда.

[arkhnchul]

[uquote="BOB51",url="/forum/viewtopic.php?p=3713057#p3713057"]На AVR - на основе ее базового блока регистр-аккумуляторов СОЗУ R0-R31 в принципе можно смоделировать любой из 8-разрядных МК/МП[/uquote]совсем не то, но напомнило - http://dmitry.gr/?r=05.Projects&proj=07 ... 0on%208bit
для Ъ: софтовая эмуляция ARM на AVR и успешный запуск linux-а на получившейся черепахе.

[oleg110592]

[uquote="BOB51",url="/forum/viewtopic.php?p=3713149#p3713149"]Так и говорится - ПОДОБИЕ[/uquote]
ну раз подобие, значит "для ассемблера в чистом виде - НЕ избыточны" - все команды врядли в простом проекте понадобятся - можно использовать только подобные
[uquote="BOB51",url="/forum/viewtopic.php?p=3713149#p3713149"]Сегодня даже пилюльку с надлежащей пользой задействовать особо некуда.[/uquote]
так елка ж на носу - пора иллюминацию делать на "пилюльке" - как раз для заядлых ардуинщиков, заодно и DMA подучить можно:
https://www.rogerclark.net/arduino-stm3 ... g-spi-dma/

[BOB51]

ФЕЕЕ....
Это насчет иллюминации...
Я со светодинамикой столько наморочился в стары времена под 51-ми, пиками да аврками...
Чего нового там за последнее время появилось - так только WS2812, но те больше для графических дисплеев...
И то... тиньки 45й с избытком хватает.
Была в планах идейка ночничка с зависимой от..."чегой-то" цветовой картинкой...
Да так пока и лежит... Одно решение черезмерно наворочено, другое примитивно, третье еще чем не устраивает...
Когда нет четко определенной задачи обычно так и бывает...
Вобщем... МУХ ОСЕННИЙ...



arkhnchul
Речь шла о имитационной модели 8-разрядных МК, а не об имитации 32-разрядного АРМ 8- разрядным АВР.
В то же время вряд-ли АРМ сумеет заместить 32 рагистр-акумулятора.
Это разве что в случае, когда подавляющее большинство команд источником и/или приемником результата операции может использовать ОЗУ... А в отношении полного аналога действует условие "и источник и приемник в ОЗУ".
Поскольку наличие такого количества регистр-акумуляторов нигде не наблюдается.
Хотя... в любом случае одновременно может выполняться только одна команда (один блок АЛУ в кристалле, параллельные аппаратные процессы не в счет - ибо к работе ядра не относятся). Но тогда именно требование "и источник и приемник данных в ОЗУ" является наиболее полным эквивалентом. Можно конечно такое набрать микропрограммами при кратном повышении частоты имитирующего кристалла - но то уже значительно понавороченнее, чем на той же АВРке имитация иных 8-разрядников.

[dosikus]

Боб , периферию смотри а не ядро...
Аббревиатура, как мигать и чем - большая разница.
В данном случае леды как простой пример для осознания а не самоцель.
Выдыхай...

[ARV]

как мигать и чем - большая разница

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

[BOB51]

Зачем спешить денюжку, время и нерву тратить на то, чего на данном этапе не требуется?
Мне спешить некудаа...

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

[dosikus]

Боб, что чего куда тратить?
У тебя уже все есть -голубая пилюля и прошиватель.

Аббревиатура, ты могешь мигать только ногодрыгом и выдыхай.
Еще раз, для особо любознательных, мигание не цель но средство, средство для изучения...

[BOB51]

Да нафиг мне сейчас та пилюлька?

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

ЛЕЕЕНЬ!!!

ПОСПАТКИ заметно приятнее!

[oleg110592]

[uquote="BOB51",url="/forum/viewtopic.php?p=3713822#p3713822"]Да нафиг мне сейчас та пилюлька?[/uquote]
не понятно - на позапрошлой странице blink на "пилюльке" то заинтересовал да и

Тихо готовим "пилюльку" к тестам...

а как с иллюминацией по ссылке разобраться - так "ПОСПАТКИ". А там самая что ни на есть ардуиинистая проблема:

Но одна вещь все еще беспокоила меня, так как, хотя я использовал DMA для отправки данных SPI, существующая функция Arduino STM32 (LibMaple) SPI dmaSend () «блокирует» (или синхронно). Таким образом, выполнение кода фактически должно ждать, пока DMA не будет завершен, прежде чем может быть создан следующий набор данных светодиодов.
Чтобы преодолеть это, я изменил dmaSend (), чтобы сделать новую функцию dmaSendAsync (), которая возвращает сразу после начала передачи данных DMA, и в случае, если код для создания следующего набора данных LED завершается до текущей асинхронной передачи После завершения я взял код блокировки с конца dmaSend и поместил его в начало dmaSendAsync и добавил статический флаг к функции, чтобы код блокировки (который ожидает завершения DMA) выполнялся, только если передача DMA имеет был ранее начат.

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

[BOB51]

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

Легче чего от себя с нуля написать!
(или обычну нанку поставить)

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

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

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

Разве что к светлячку-ночничку вернуться...