Ошибки легко исправляются, мыслю я спокойно, а печатать что-то типа "MOV A,@R1" мне лень, E7 гораздо короче. Но это всё дело вкуса. Вот постигать интерфейс I2C таким методом уже будет сложно, так как большинство современных вещей имеют именно этот интерфейс, как те же часы реального времени.
Жестковато было так 10кб строчить для другого проекта, но там всё писалось на лету, ибо система команд удобнее, ибо PDP.
Я эту стадию давно прошел... Где-то в начале 90х. (до того 580й был с коробейкой под названием УМК да поделки на Z80). Средний проект на такой основе уже будет сложно написать, не говоря уже о чем-то более-менее крупном. Знакомство с компиляторами началось с подаренного ассемблера для 51й (AD2500)... Далее уже пошли и АВРки и ПИКушки - там уже без работы с IDE под ассемблером не пройти. Если интересно - можете глянуть viewtopic.php?f=62&t=94201 и viewtopic.php?f=62&t=156720 относительно ассемблера и mcs51 (там все "в перемешку" - от 51й, АВРок и ПИКов под ассемблером до ардуинки под Си/С++ с открытыми схемками и исходниками макетов).
Только вот я не делаю крупных проектов на МК, там уже в ход идёт что-то тяжелее. Пока это только пара часов, индикатор шины для Э60 и управление панелькой ВЛИ. Каждый "проект - сотня-другая байт, и писать на ассемблере это дольше, чем набрать сразу в машкодах. Но это личные причуды каждого.
Эта табличка смещений у меня есть, но так как смещения небольшие (в пределах 10h) - то они и так считаются)
Сейчас более интересно было бы посмотреть реализацию I2C, у меня сходу не получилось. И, судя по осциллограмме, всё начинается со второго байта. Если во время передачи первого байта (D1h), ack - низкий уровень, то передача адреса - ack уже высокий.
А, всё нормально, проблема в неправильном чтении даташита. I2C работает
У I2Cесть нюанс при передаче команды "чтение по заданному адресу" - это если первый считываемый байт имеет лидирующий нулик... И то - в случае , если контроль ACK этого не учитывает. Вот мои стародавние материалы по применению(без последних коррекций):
Я пропустил два нюанса - первое, что адрес заносится только при команде записи, а при чтении - идёт чтение сразу, и второе - последний принятый байт должен иметь высокий ack. SPI в этом мне понравился больше.
Так, позадаю ещё глупых вопросов. При тактовой частоте 12МГц у нас получается 1мкс на команду. Двухбайтовая, какая-нибудь MOV R0,#d, будет 2мкс? А сколько по времени занимают команды ACALL, DJNZ, RET? Просто осваиваю 1-wire, точнее, освоил, работает, но там всё довольно жёстко по таймингам, отсчёт времени подпрограммами, вот и хочется всё поточнее подогнать к времянкам 18b20.
Ну и ещё - получение прямого кода из дополняющего. Для этого, нужно байт вычесть из 100h, ну, либо два байта (слово) из 10000h. Можно вычитать и из FFh и потом прибавить единицу, но это мне не нравится. Поэтому начирикал такой код преобразования из дополняющего в прямой. Только насколько он правильный? Вроде работает, но что-то смущает.
Код:
MOV R0,#d ; загрузка адреса МЛБ CLR A ; очистка А CLR C ; очистка С SUBB A,@R0 ; вычитание MOV @R0,A ; сохранение полученного значения INC R0 ; получение адреса СТБ MOV A,#d 00h ; очистка А (вроде CLR A не трогает флаги, но сделал так) SUBB A,@R0 ; вычитание MOV @R0,A ; сохранение полученного значения RET ; возврат
вопросам длительности команд смотрим соответствующий документ
О, такого в даташитах мне не попадалось, посмотрю.
BOB51 писал(а):
относительно "дополнения до 2", то для 51й это
Этот код хорош, когда надо один байт преобразовать. А я преобразую сразу два связанных байта. Побайтово их так не дополнить. Вроде оно у меня работает, но мало ли я всё же ошибся, подставлять кучу раз значения и проверять преобразование не хочется.
Так двухбайтовый точно так же - инвертируем оба байта по отдельности и затем сложение с 1 младшего байта и сложение с 1 с учетом переноса для старшего байта. (многобайтовое сложение/вычитание). Спойлер
Код:
r7 high byte r6 low byte
xch a,r7 cpl a xch a,r7 xch a,r6 cpl a add a,#1 xch a,r6 xch a,r7 addc a,#0 xch a,r7
Не помню уже - если инкремент выполняется как сложение с единицей то допустимо и такое (надо смотреть выполнение команд). Вроде как inc dptr можно попробовать...
Подскажите пожалуйста. Как организовать динамическую индикацию на светодиодных индикаторах. МК P89LPC915 и регистры 74HC595. Хочу применить для блока питания в качестве ампервольтметра. Правда, не разу не писал программ, а хотелось бы. И на ассемблере. Спасибо !
А у Вас есть чем в этот МК программу загрузить("прошить")? И собственно среда разработки для mcs51(компилятор ассемблера)? Или только желание чего-то сделать? Про ту динамическую индикацию в сети тырнета полно информации.
Доброе утро! Спасибо за ответ. Не нашел в инете для mcs51 контроллера, хоть и говорят полно. Да, для АВР и ПИК очень много. Есть MCU8051IDE. Программировать контроллер выручат знакомые, которые весам занимаются. Есть желание сделать это. Так как этих контроллеров 5шт, и лежат без дела Спасибо
Так алгоритм работы динамической индикации всюду одинаков. Меняются только команды и (возможно) аппаратные ресурсы в зависимости от семейства МК. Помимо того в имеющейся к Вас IDE и симулятор внешней обвязки с примерами вроде есть... Так что берём алгоритм динамической индикации (возможно есть и чего специально под те 595тые регистры) и адаптируем под систему команд Вашего МК. МК довольно редкий, в моих краях как то не попадался. Так что по конкретике "отличий от стандартного ядра" надо ещё документацию искать да вычитывать. В стандартном описании аппаратной начинки mcs51 АЦП нет, следовательно при отсутствии такового в перечне МК, поддерживаемых IDE придётся самому дополнительные регистры РСФ в исходника прописывать. А это без изучения даташита не получится. Да и правила таких дополнений надо в документации на IDE прочитать на всякий случай... Бегло глянул даташитину...
Начинка вроде впечатляющая, но... SMD корпус о 14 лапках и всего 2 килобайта ПЗУ... как то "тесновато" для использования всей начинки... так что вычитывание даташита гарантировано. (Да еще NXP "подссакционные" в перспективе...) По ресурсам китайские STC15F204EA к аналогии чуток "поближе" (4к ПЗУ и АЦП на борту + простота прошивки)...
Или адуринка - там вообще проблем как таковых нету для "простоначинающего". Так что выбор за Вами - учить основательно ассемблер, документацию МК, IDE и сопровождающие сие освоение дополнительные затраты делать или таки те МК кому продать да купить готовенькое (адуринку освоить)...
Спасибо! Ардуино не хочу.Про ктайские STC, это дальше, после P89LPC915FN. У меня они в DIP-14 корпусе. Может у кого есть листинг или ссылки, дайте про эту связку. HC595+MCS51-даже классический. Вот. Спасибо
Вообще-то начинают изучение или с интеловских (8031, 8052 наши КР1816ВЕ31 КР1816ВЕ51) или с атмелевских AT89C2051-24PI, AT89S51-24Р..., AT89S52-24P... ... Далее - зачем динамика там, где один регистр 595й на одно знакоместо поставить можно?? Или взять ардуиновскую платку с 8 семисегментниками на микросхеме MAX7219... https://img.radiokot.ru/files/20529/1st7ni12lm.jpg https://img.radiokot.ru/files/20529/1st7nh5zvs.jpg
В обоих случаях только последовательная пересылка байт по SPI. Касательно динамики - смотрим темы с часами со светодиодными индикаторами к примеру viewtopic.php?f=25&t=50199
туда же показометры-термометры и прочие со светиками.
BOB51 В обоих случаях только последовательная пересылка байт по SPI. вот про нее и хочу узнать, как переслать из озу контроллера в два регистра HC595 - ых. Один регистр рисует цифири, второй разряды включает. тоже готовая плата с алиекспресса
Так и пересылайте - или программный "ногодрыг" или использование модуля SPI (там читать даташит надо долго). Но в отношении расхода памяти программ на обработку данных лучше по регистру на знакоместо ставить. кристалл то не слишком великим ПЗУ оснащен - неизвестно сколько основная программа занимать будет. Математика с умножением/делением многобайтовых чисел штука весьма громоздкая. Да и уровень шумов от той динамики с работой АЦП совместить надо (опять же даташит читать) - динамика ведь непрерывно вертится как основная часть (или независимая на прерываниях от таймера при усложнении обмена данными между программным контроллером дисплея и обработчиком АЦП). это уж на любителя. Похоже Ваш уровень освоения МК пока еще недостаточен для задуманного проекта... Тут проще подать заявку в "напишите мне программу"...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 30
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Вот постигать интерфейс I2C таким методом уже будет сложно, так как большинство современных вещей имеют именно этот интерфейс, как те же часы реального времени.
