Это и ежу понятно, что разные. Но я переписывал код с 8080 на mcs48, а это тоже разные архитектуры. Проблем пока не вижу, разве что старт/стоп таймера не особо удобный, зато аппаратный и шустрый последовательный вывод. На ве39 он программный, и там была битва за каждый байт, и то, до 18мгц пришлось разгонять.

Насчет аппаратного UART не все так однозначно - там при включении питания "глючек" линии TxD на короткое время имеется.
Его следует учитывать при работе с программами на других "внешних устройствах" (включая ПК).
Это свойственно практически всем 51м.
В принципе отсеивается или аппаратно или программно.
Насчет пуска/останова таймеров там все абсолютно ясно и удобно - хоть программно, хоть аппаратно запуск/останов счета выполнять.
Единственно как перестраиваемый генератор меандра/ШИМ требуется больше настроек и манипуляций.
Кстати... Чем Вы его прошивать то собрались? АТ89С2051(4051) требует только параллельного высоковольтного режима доступного не на всех программаторах.
Или по случаю обладателем AT89S2051(4051) стали??

Мне не UART нужен, а именно режим 0 - стробируемый последовательный вывод.


Ну, кому как - на 48 пуск/останов 1 байт, а тут целых 2 - SETB 8C/CLRB 8C для таймера 0. Но этот МК шустрее, так что просто непривычно.


Дык, самодельным программатором. Он, как раз таки и может шить/стирать/читать 10/20/4051. А с полными 89с51/52 пока запара, не смог их победить.

Кстати, переходы типа JZ и тому подобные - только в сторону увеличения адреса?

Похоже таки надо плотненько с системой команд познакомиться - в сундуке книжи есть на данную тему.

там, где стоит
КОП чего-то,rel собственно rel рассматривается как 8бит со знаком (-128 +127)
табличка для "ассемблера с карандашиком на бумажном листочке":

собственно карта команд с "заметками" как шпора, так и основа "ассемблирования с карандашиком":

доки от сожранной мелкощипом АТМЕЛ:



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

Собственно, это и хотел услышать. Если со знаком - то это большой плюс.

За доки спасибо, но я так себе знаю английский, поэтому вожусь по книжке "проектирование цифровых устройств на ОМК", там как раз 48 и 51 семейства с примерами описаны.


Программный вывод - это зло, особенно когда надо 20 байт выводить больше 1к раз в секунду, и ещё на другое оставить время.

Ещё бы разобраться со всякими последовательными интерфейсами, типа как у DS3231 или AD7714, точнее с их времянками, стартами и остановами.

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

В последнее время похоже еще и китвйские иероглифы осваивать придется...

"...надо 20 байт выводить больше 1к раз в секунду..." это или некорректно сделанная схема или неправильно выбранный алгоритм (скорее и то и другое вместе). Характерно для "беглых строк".
В любом случае программный вариант не тормозит основную программу более, чем обработчики других имеющихся в основной программе подпрограмм.
Единственно жесткие по условиям "запрета разрыва потока" протоколы - это uLan (микро-лан для Далласовских "умных таблеток") и загрузчик шустрых светиков семейства WS2812.
И то вполне себе с DS18B20 и светодиодной динамической индикацией терморегуляторы делались.
А вот WS2812 уже простые 51е не потянут - там быстродействие повыше необходимо.

Это не беглая строка, а панель 4 на 20, итого 80 знакомест 5*7. И схему можно переделать если только выводить по 4 байта параллельно, что МК не сможет. И других алгоритмов тут быть не может.

Насчет дисплея - это уже отдельная тема.
При желании обсудить варианты - перебирайтесь сюда (в конец темы):
viewtopic.php?f=62&t=156720&start=1960
Только с конкретной исходной схемкой и документацией на сами матрицы.

Друзья! А вот возник у меня такой теоретический вопрос. Не то чтоб очень нужно, но интересно.
Представим условный 8051, к порту которого подключено 8 неких 1-проводных датчиков. Датчики типа "умные" - требуют инициализации, но к сожалению, безадресные. И каждый по очереди надо опросить. И тут ты понимаешь, что на каждый датчик надо писать свою отдельную подпрограмму. Громоздко. Одну общую сделать нельзя, у МК нет ничего похожего на косвенную адресацию бит. Подумал что сдвигами аккумулятора можно подставлять бит к нужному выводу порта, или снимать его с вывода. Но получается все равно громоздко и не очень понятно. А если датчиков не 8 а 24....
В общем, скрипел мозгами, и ничего не придумал. Может есть какой-то тривиальный способ, а я просто не знаю?

Как вариант - использовать "скользящую маску" и результат от ее наложения на порт.
(аналогия АВРкиных SBR/CBR с регистром маски вместо константы и учитывая "особенности ЧМЗ" для портов 51й)
Плюс указатель текущей позиции маски(адреса) датчика, который определяет "кому принадлежат" текущая линия порта и результаты единого обработчика датчика.
Но тут все зависит от требований быстродействия протокола.
Для типовых 51х кристалл на 24МГц при 0,0000005 мкс/цикл не так уж шустро...

Пы.Сы.
Есть еще один весьма извратный способ...
Если МК имеет совмещенную ВПД/ВПП (котуинка к примеру) то с прожкой в ОЗУ можно все чего пожелаешь делать - в том числе и предварительную подмену второго байта в команде (адрес бита) для всего обработчика перед его использованием.
Но там и навороты с общей ВПД/ВПП на основе ОЗУ (в том числе понижение тактовой).

Может и отдельная, но вопросы у меня таки по самому МК.
Таки 2051 потянула поставленные задачи с запасом... С шестикратным запасом. Ну а попутно почти полностью разобрался с mcs51. Написанный код заработал почти сразу (пару команд упустил), разве что запускается 2051 не всегда, сброс надо долго дёргать. Но всё работает сразу как хотелось.

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

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

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


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

Возможности зависят от решаемой задачи. Где кнопы уместны, а где и нет.
Регистры также должны быть охвачены линией сброса (если конечно их исходное состояние не безразлично).
Ведь Вы судите о "подвисании" по видимому эфекту на матрице индикатора, а не по фиксированным контрльным точкам, статус и данные в которых заведомо определены автором программы и тестов.
Возможен и некорректный ход программы (ошибки в подпрограммах, циклах, приоритетах прерываний).
Это если про "волшебный диод" не забыли.
Как вариант - используем прогон на симуляторе (FD51 под DOS в вин ХР х32) или вывод данных из контрольных точек ПК по СОМ порту. Можно и "пошаговый прогон" устроить - но там нужны изменения /добавки в схеме устройства.

Да, конечно. Более того: иногда выбор архитектуры обусловлен необходимостью поддержки старых проектов, разработанных кем-нибудь 100 лет назад на давно уже устаревшей, но всё ещё нормально функционирующей базе. И если к ней возможно программным путём прикошачить новые (вполне современные) функции, то почему нет?
Не единственный.

Добавлено after 5 minutes 32 seconds:
Вот как раз на С это сделать невозможно от слова никак. Ибо С не предоставляет информации о количестве тактов, затрачиваемых на выполнение перехода и сохранения контекста. Приходится лезть в ассемблер, а прежде того — в дизассемблер.
Все задачи можно условно разделить на вычислительные и управляющие. Мне по роду своей работы чаще приходится работать с управляющими, а вот им-то как раз и нужно время с точностью до такта. Вычислительным время, как правило, вообще не нужно.
С чего бы это вдруг? В машине времени совершенно спокойно можно остановить время и/или даже отмотать его назад, что я и реализую. При остановленном времени можно произвести необходимые расчёты (благо их мало в сравнении с вычислительными задачами) и построить прогнозы, после чего снова запустить время и продолжить мотать с того же витка, на котором остановились.

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


С ошибками оно бы не работало, приоритетов прерывания нет, оно одно, от таймера.


Диод со сброса на общий провод, для разрядки конденсатора сброса? Он есть, но и когда его не было - ничего не менялось.

Ну уж "отлов жуков" без схем и без исходников это не моё.
Тут только гадалки помочь могут.

Для разборов нужна КОНКРЕТИКА (схема, платка с расположением деталюшек, исходный текст прожки и описание чего от устройства надобно).

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

Ассемблерный листинг могу накатать, если интересно.

Данный поиск ошибок не мне интересен то...

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

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