Нет ADuC8xxx, и что, нет идей, как промоделировать? для 812/831, а, впрочем, и для 824/845 можно прикрутить на чём-нибудь типа 74xx165 модель идеального АЦП, чтобы читать данные, занимая при этом минимум ног. С ЦАП аналогично на 74хх595. Не хватает ног у МК для подключения к АЦП/ЦАП? Сделай несколько моделей. На одних отладь цифровую часть, протоколы обмена, на другой- аналоговую и математику. В программе можно ставить заглушки на этапе чтения данных из регистров того же АЦП, и ввод данных в переменные при срабатывании точки останова. При таком подходе на реальном "железе" тебе останется проверять и отлаживать совместную работу уже отлаженных частей программы, что, обычно, идёт намного быстрей, чем ведение всей отладки полностью в "железе". У меня написание программы и её отладка на моделях занимала около месяца, а испытания "железа" в реальных начинались через 1-2 дня после переноса ПО на реальный МК.

Каждый раз переставлять заглушки в разных кусках программы совсем неудобное дело, даже если через макросы и дефайны, да и собирать модель контроллера из 8052+периферия тоже не катит. Благо есть реальная железка с UART и несколькими свободными выводами. Я во всех более-менее серьезных программах обязательно ввожу в систему команд чтение и запись памяти и регистров, так что с отладкой в железе обычно проблем нет, но ведь железка есть не всегда. Просто думал, может у кого был опыт с такой проблемой. Конечно удобно написать и отладить 90% кода пока плата в сборке (а у нас это может быть и месяц и три ) и после получения просто залить код и увидеть, что почти все работает как надо...

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

Зачем каждый раз? Ты просто не сможешь на том же ADuC831 отладить и работу с АЦП, и протокольные дела одновременно, когда у тебя не хватает ног у МК. А если не получается, то со структурой программы не всё в порядке, коли не можешь изолированно проверять работу частей программы.

В АДюКи прога заливается по UART, что само по себе не быстро, плюс нет внутрисхемного отладчика, поэтому время, потраченное на отладку на модели с лихвой окупается. Это вам не STM32F769, где в 512К ОЗУ влезут и все данные, и программа, и влетит туда это всё за пяток секунд.

Может быть очень дурацкий вопрос, но как выводить на 51ом семействе данные в порт? Логика подсказывает MOV @R0, A, где в регистре адрес порта, но оно не работает. Литературу изучаю, но пока ответа не нашёл.

Upd. Нашёл в "Радио", команда MOV #ad, A работает. Странно что косвенная адресация не сработала, ну да ладно.

Смотрим карту памяти МК -
резидентная память данных (РПД) 0х00-0х7F доступна как для косвенной так и для прямой адресации
регистры специальных функций (РСФ) 0х80-0хFF доступны только для прямой адресации
дополнительная РПД (у 52й) 0х80-0хFF доступна только для косвенной адресации

Вот нормальную карту я нашёл только в даташите на 87С251, и там указано, что SFR - direct. Но это случилось ещё позже.
Конечно, 51 будет посложнее 48, но уже вполне понятно. Осталось разобраться с прерываниями и можно будет не мучать 1816ВЕ39 частотой 18МГц.

MCS48 ближе к ПИКовым по жесткости в обращении.
Документации на MCS51 весьма много - как от интела, так и от атмела и SST.
Да и в "Сундуке Кота" несколько книжек имеется на русском.

Аппаратные регистры (SFR) типа портов не адресуются косвенной адресацией. Первая половина адресов памяти адресуются прямо и косвенно, вторая половина адресов совпадает с адресами SFR, и адресуется прямо - SFR, косвенно - память. Соттветственно, @R0 не может указывать на SFR.
Мое субъективное мнение, что посложнее это как раз MCS-48. Сегментирования (постраничная) память программ, нет автоинкремента 11 бита программного счетчика, нет битовых инструкций, надо приделывать внешнюю ПЗУ памяти программ, которая занимает почти все порты, и становится нужен расширитель КР580ВР43, и прочие "удобства" из 70-х. 51 - наоборот, весьма удобен.

48я Сложнее (жестче) в отношении пользователя при работы с программой.
Но по набору команд и схемотехнике более сложный 51й.
Тут все относительно - как воспринимается пользователем.

Ну, мне 48ое семейство быстро поддалось. Видимо сработала краткость описания в двухтомнике Шахнова. Даже несколько обидно, что освоил я МК всего пару месяцев назад, когда с 8080 я вожусь уже почти 10 лет. 8080 тоже довольно быстро освоил, опять таки благодаря краткому описанию в "Радио" за 82г.
Как бы ограниченность функций 48 мне не помешала получить доступ к любому размеру информации в ПЗУ. Та же собранная панелька 20*4 имеет 2кб ПЗУ, в котором находится и управляющая программа, и 1.5кб знакогенератора. И всё оно работает на 18МГц (да, 1816ВЕ39 показала потенциал для разгона).

А вот mcs51 - та книжка, что у меня есть - несколько пространно всё описывает. Тут помог тот же журнал "Радио", который, в принципе, идентичен книжке, но немного отличается в подаче информации. Именно там я почерпнул про прямую адресацию PSR, а удобную табличку с адресациями нашёл в даташите на 87с251. 51ое семейство меня привлекает даже не сколько "безграничным" ОЗУ и ПЗУ или какими-то недостающими командами (да, команды SUB на 48 мне не хватало), сколько наличием флэша, который я таки могу записать.

Народ, а что вы всё про регистры да адресацию. Неужели 51-е на С не программируете? Если так, то почему?

SDCC осваивать ЛЕЕНЬ...
(хотя примеров на нем для STC в каждом даташите)

Это кстати равноценно вопросу "почему в ардуиноIDE нет платформы на основе MCS51 ?"
(Z-UNO не в счет).

Я как-то написал на SDCC мигалку. Дизассемблировал ее, посмотрел, и чуть не поседел. "Сложный способ нарисовать сову". SDCC сделал наименее очевидным, и похоже, наиболее громоздким способом.
А вот AVR почти только на C. Не зашел мне их ассемблер.

Осваивайте Keil тогда. Впрочем, не знаю насколько велика разница.
Опять Вы про эту .... Ну нет и ладно. Кроме ардуины много чего ещё есть.
Да, я читал Ваш пост выше. С SDCC никогда дел не имел, только с Keil для х51. А что-то более сложное, чем мигалку на нём пробовали? Может тогда накладные расходы на унификацию будут не так заметны на фоне остального кода приложения.

Keil штука платно-лицензионная да еще и "подссакционная" в ближнем времени.
Второе - в Си нужнл делать запускающие Makefile с учетом всех входящих в состав проекта файлов...
В принципе и для "чистокровного" ассемблера многофайловик аналогичен (*.bat файл с перечнем проекта и опциями с командной строки). Но тут для ассемблера мой "слэнг" чуток положение подправил, а адуринка данный вопрос относительно Си вообще убрала.
Так что... Для тех, кто любитель "ЛЕНЬ - ДВИГАТЕЛЬ ПРОГРЕССА".

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

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

А не всё на С можно написать из того, что можно на ассемблере. Вот, к примеру, надо мне по прерыванию узнать время, в которое случилось это прерывание. На ассемблере я в начале прерывания первым делом останавливаю 16-разрядный таймер и читаю его регистры данных, таким образом примерно точно знаю системное время (с точностью до синхронизации момента возникновения прерывания с тактовой частотой таймера). А что мне понакодирует С? А он в начало прерывания вставляет вот что:

Вот на кой оно мне? Время идёт, счётчик тикает, младший регистр таймера того и гляди переполнится, а С знай себе регистры в стек прячет один за другим. Что, в прерывании больше заняться нечем? С остальными прерываниями точно та же самая ерунда, он их начинает с перехода даже в том случае, если код занимает не более 8 байт, то есть может разместиться прямо в области векторов. Кстати, на последнее (5-е) прерывание от УАРТа это ограничение в 8 байт не накладывается, и его всегда можно размещать в области векторов, но С и этого не делает.
Это, конечно, не значит, что я не пишу на С. Нет, я пишу на нём, иначе как бы я узнал о результатах его работы?! Но ответ я дал на вопрос "что вы всё про регистры да адресацию". Вот в AVRках 16-разрядный таймер считывается за одну команду, поэтому там этой проблемы нет. А в 51-м приходится хитрить, а С пытается этого не дозволить.

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