Так работает любое контрольное устройство - независимо от содержания пакета результат контрольного отсчета и прилагаемого ключа-подписи всегда одинаков. А ежли имелась ошибка - будет и изменение результата.
Доброго времени суток. Внутри кода находится строка символов (массив вида db 'Hello',0). Необходимо поместить первый символ строки в буфер приемопередатчика UART, "обойти" этот массив и продолжить выполнение кода за ним + оставить в DPTR адрес второго символа строки для продолжения передачи всей строки из обработчика UART. Помещаю в DPTR адрес первого символа строки. Затем написал 2 варианта обхода, оба рабочие, но 1-й требует лишнюю ячейку ОЗУ, а 2-й чуть длиннее. Может кто увидит более элегантное решение:
А если передачу вести самостоятельной подпрограммой?
Т.е. основная программа идет сама по себе, а при необходимости пересылки запускаем подпрограмму обслуживания передатчика, которую привязываем к прервыанию и начальному адресу массива символов... А подпрограммка UARTа крутится самостоятельно пока не исчерпает содержимое массива...
Инженеры КОМПЭЛ провели сравнительное тестирование аккумуляторов EVE и Samsung популярного для бытовых и индустриальных применений типоразмера 18650.
Для теста были выбраны аккумуляторы литий-никельмарганцевой системы: по два образца одного наименования каждого производителя – и протестированы на двух значениях тока разряда: 0,5 А и 2,5 А. Испытания проводились в нормальных условиях на электронной нагрузке EBD-USB от ZKEtech, а зарядка осуществлялась от лабораторного источника питания в режиме CC+CV в соответствии с рекомендациями в даташите на определенную модель.
Это я знаю как сделать. Хочется именно "обходить" строку в коде, дабы иметь возможность ее объявление прямо на месте, в макросе, а не объявлять ее где-то на отшибе.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Так макрос может включать в себя строку и вызов подпрограммы обслуживания передатчика... Там просто вставляем текущий адрес начала строки равноценно таковому для любой области памяти.
Это вызов подпрограммы с передачей параметров через стек или через регистры ОЗУ. А в макросе остается только добавить переход для обхода участка символов строки. Примерно код.... вызов подпрограммы обслуживания передатчика с заданием параметра "начало строки" переход на метку "конец строки+1" начало строки: конец строки+1: продолжение кода...
Не понял. Можно увидеть код/псевдокод ? Под обработчиком UART имею ввиду прерывание UART с соответвующим кодом выборки и отправки строки (в текущей реализации все кроме первого символа, который отправляется из основного кода).
МММ... В принципе есть регистровая пара в которую помещается целевой адрес начала строки перед вызовом программы передачи. А программа передачи работает с данной регистровой парой как с текущим указателем чего отсылать. Чего мы в ту регистровую пару поместим - адрес из текущего кода или из отдельной области - значения не имеет - будет выполняться одинаково. Такой вариант у меня в КОТУИНКО биосе. Разбирать/вспоминать долго (ибо таки поднаворочено). Вот кусманчик передатчика:
и собственно весь тот проект: https://yadi.sk/d/o-Jf3fADfDtsEQ там поднакручено из-за особенностей вызова обработчика передатчика - сначала идет вызов как подпрограммы из кода, а затем дальнейшая обработка как прерывания до конца массива символов.
На первый взгляд... Разве что... Как элемент сравнения помимо вычитания попробовать cjne или xrl ... Да и в ОЗУ у 51-й не так уж много места для строк произвольного размера. Посему можно и прямой адрес задавать (не через косвенную адресацию) но при некоторой потере объема в ПЗУ. Есть смысл выделения буфера определенного размера в косвенноадресуемой области для 52-х (128+128 байт) там уже вариант работы через стек... Однако переносимость кода будет иметь ограничения. В принципе то уже подгонять под конкретную потребность надо.
И еще... Для единичного символа это подойдет (ловим первый встретившийся и далее, если совпадает последовательность). А вот для строки, содержащей пару одно/двух(и более) символьных повторов... Вида : контрстрока поймать в ней рок или более сложный двойной/многократный повтор одинакового фрагмента чуток поменьше контрольного фрагмента...
... Для единичного символа это подойдет (ловим первый встретившийся и далее, если совпадает последовательность). А вот для строки, содержащей пару одно/двух(и более) символьных повторов... Вида : контрстрока поймать в ней рок или более сложный двойной/многократный повтор одинакового фрагмента чуток поменьше контрольного фрагмента...
Скорее так: контрстрока поймать в ней тро Ну я для этого как раз флаг symbol_ok и ввел. Без него код был попроще, но например последовательность '123' в массиве '1121121123ХХХ' уже не ловилась, ибо первый сивол настоящей последовательности разпозначался как неправильный второй символ преполагаемой последовательности, и пропускался. Мне ответы на АТ-команды надо парсить, а там частенько такое встречается, что ответы началом похожи.
А почему бы не сходу и "парсить" ? Без предварительного буферного ввода. (Ессно буфер - накопитель полезной составляющей будет необходим). Единственно скорость обмена делать соответствующей. Я поток данных из *.hex файла получаемого из терминалки ПК в бинарник внешнего ОЗУ перегоняю без особых проблем. Правда на скорости 9600 (при кварце 11,0592МГц)... Но там дополнительная обработка содержимого добавляется - из-за того и "некоторые излишества". Собственно в бутлоадере КОТУИНКИ этим mason_2.txt занимается.
Поскольку простая обработка символа не требует таких "наворотов" вроде свертки двух символов в один байт или получения адресной информации для позиционного размещения фрагмента по конкретному адресу ОЗУ/ПЗУ, решение может быть гораздо проще, без излишних добавок.
А почему бы не сходу и "парсить" ? Без предварительного буферного ввода ... решение может быть гораздо проще, без излишних добавок.
Это уже реализовано. Есть 2 режима: парсинг данных из UART на лету, и "просто положи в буфер, как будет время - выгребу". Успешное окончания парсинга в обработчике автоматом включает режим "положи в буфер". А уже из него выгребаю и анализирую "параметры", например уровень сигнала сети. Просто иногда параметров у одного ответа много, и чтобы после получения первого параметра опять не переключатся в режим парсинга в обработчике, проще продолжить прием в буфер, и потом найти там нужную последовательность.
Тогда в принципе особо чего добавить... остается в силе вариант сравнение-переход (cjne, xrl) да еще вариант загрузки DPTR и temp_dph:temp_dpl... Может есть смысл в макросе грузить не в DPTR, а в temp_dph:temp_dpl... а затем использовать внутреннюю перегрузку уже в подпрограмме. Тем более, что предыдущий DPTR все равно предпочтительно в стеке хранить при входе (как АСС и PSW)... А затем восстанавливать при выходе из подпрограммки. Или старт-адрес через стек передавать - но тогда сложнее содержимое стека при разных вариантах выхода отслеживать.
И почти упустил... При относительно небольшом "ассортименте" блоков сравнения можно попробовать movc a,@a+pc вместо movc a,@a+dptr с передачей начального смещения...
и не выходит каменный цветок. В UART шлется 'B', а не 'A'. Адрес регистра AUXR1, отвечающего за выбор DPTR, на карте памяти AT89S52 составляет 0A2h. За переключение отвечает младший (0) бит, который и переключаю (остальные биты не имеют значения, и всегда читаются как 1). Выводил в UART значение AUXR1 (0A2h) до, и после переключения - так оно меняется (либо 0FEh, либо 0FFh), но на выбор DPTR никак не влияет
а где вы используете DPTR? в коде этого нет! вы пишите в регистр DPTR данные, затем из этого регистра данные назад берете - что у вас должно выбраться?! что положили, то и взяли.
альтернатива из двух вариантов DPTR используется в командах типа mov a, @a+dptr - вот тут, в зависимости от выбранного DPTR, будет взяты данные по одному или другому адресу.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется... скушно, бабоньки!
а где вы используете DPTR? в коде этого нет! вы пишите в регистр DPTR данные, затем из этого регистра данные назад берете - что у вас должно выбраться?! что положили, то и взяли.
альтернатива из двух вариантов DPTR используется в командах типа mov a, @a+dptr - вот тут, в зависимости от выбранного DPTR, будет взяты данные по одному или другому адресу.
В приведенном коде этого действительно нет, но это я упрощал условия для проверки кода, который у меня не работает. Предистория. Подцепил я к AT89S52 внешнюю ОЗУ, и решил запилить библиотеку для работы с ней. Одной из функций библиотеки является копировании произвольного количества байт из одной области внешней ОЗУ в другую область внешнего ОЗУ. И вот тут мне понадобился второй DPTR (до этого как-то не приходилось его использовать). "Функция" имеет вид макроса с передачей параметров:
Согласно моей первоначальной логике, селектор DPTR должен был влиять на то, куда именно (в какую пару DPL/DPH) я буду писать значение при записи указателя в DPTR.
П.С. Благодарю. Переделал присвоение параметров-указателей следующий образом, и все заработало:
Получается, что команда mov всегда пишет в первый DPTR, а вот команда inc уже знает, с каким DPTR производить действие, в зависимости от состояния селектора.
Последний раз редактировалось Пока_без_кота Пн июн 29, 2020 10:57:07, всего редактировалось 4 раз(а).
а вот команда inc уже знает, с каким DPTR производить действие, в зависимости от состояния селектора.
даже не так: все команды, работающие с DPTR (не частями, а целиком с 16-битным), учитывают заданный селектором регистр.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется... скушно, бабоньки!
А вот когда загрузку указателей (содержимого) делаем в соответствующие регистры РСФ, там селектор ни при делах.
Почему в макросе не сработало mov dptr,#d16 надо повнимательнее посмотреть... Как вариант - что-то не так с управлением селектором или ограничения по командам. Вечерком чего гляну... Хотя... описание команд дает однозначность: MOV (DPTR)<--#DATA 15-0 DPH<-DPL<- #data 15-8 <- #data 7-0 т.е. можно предположить, что загрузка будет выполнена в DPH:DPL Даташитку на МК только вечером просмотрю...
Прошу прощения за дезинформацию. Все дело оказалось в задержках при работе с памятью. Использую тормозную советскую КР537РУ10, и просто когда переделывал передачу параметров под раздельное присваивание DPH/DPL - вставил отладочный вывод в UART, который и создал задержку, благодаря которой все заработало. Так что первоначальный вариант оказался тоже правильным, просто перед каждой записью в память добавил задержку по 80 мкс, и все взлетело.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения