Одначе... на этот раз было решено максимально выжать возможное из АВРки — сделать программу исключительно аппаратнозависимой от конкретного кристалла. Вроде попытки "покошернее приготовить" ту АВРку - чего еще кроме программного примитива прикошмарить можно... Да и любителям АВРкина семейства "капелька бальзамчика на душу" Вот собственно архивчик с исходником:
В результате имеем мультиплексирование сегментного кода на четыре анода и каждый анод, в свою очередь, обрабатывается аппаратным ШИМ ом в диапазоне 3990-200=3790 условных градационных уровней. Тестовая вставка весьма примитивна — всего лишь «яркостной клин» от максимального уровня к минимальному с шагом 10 уровней примерно в 0.64 секунды «по кольцу» с одновременным выводом значения уровня на индикатор. Вот с такой основой уже можно будет и каналом передачи заняться.
После некоторых мудрствованей была скомпонована схема из уже ранее проверенных автономного демотермометра и светодиодного 4-позицирнного дисплея. http://img.radiokot.ru/files/20529/n92a9fb6n.GIF На сей раз добавились две коммуникационные платки для варианта RS232 при сохранении возможностей термометру работать как автономно, так и в комплекте с внешним выносным дисплейчиком. Предусмотрено также «горячее подключение" в любое время и в любой последовательности. Дисплейчик по отключении от термометра сохраняет последние принятые показания. Вобщем неплохой результат для «некварцованных» МК с последовательной передачей данных. Как всегда исходники в полупричесанном виде:
там же все промежуточные схемки в лейоуте и описание прицарапанного протокола синхронизации/обмена передачи пакета от термометра к диспею и обратно. Чего там еще «нагородить» можно — то для следующего раза пока оставлю. Пы.Сы. Кабло между блоками стандартное "перекрестное" (2->>3 и 3->>2 / RxD->>TxD/) с сигнальным "земляным" (5->>5).
Одначе при установке этой платки в качестве адаптера у дисплейного блочка всплыли несколько проигнорированные при первой пробе требования к защите от некорректного пакета данных. Пришлось несколько доработать оба устройства в плане защиты передаваемого по RS232 пакета данных CRC7 по аналогии с далласовским uLAN.
По крайней мере теперь при приеме некорректного мусора просто высвечивается заставка ECRC, которая самоубирается со следующим правильно принятым от термометра пакетом данных. Да и хвост со второго выхода репитера, всунутый в комп на терминальной программе данные обмена перехватывает.
Потихоньку попробуемсс на зуб ассемблер для STM8... К сожалению, только в теоретическом режиме - то, что можно прокрутить с использованием штатной IDE и встроенного симулятора (на пргораммер денюшки зелене жаабко). В принципе, штука съедобная, как дополнительный "кирпичек" сгодится. В качестве основной IDE предусматривается использование базовой ST Visual Develop (STVD) отсюда: http://www.st.com/web/catalog/tools/FM1 ... 7/PF210567 и встроенный там инструмент вида ST Assembler-Linker. А далее - по мере настроения/вдохновения и халтурофинансирования.
Вставлю 5 коп: я сделал всего лишь 1 проект на STM8L151. По настоянию заказчика он был именно для этой модели и разрабатывался на АСМе в среде IAR, что мне было на руку поскольку имею опыт работы с этой средой. Бесплатная версия ее не имеет ограничения для ассемблера. У меня была недорогая демо-плата STM8S-Discovery, и я использовал программатор на этой плате для программирования и внутрисхемной отладки внешнего чипа STM8L. Будут вопросы по АСМу STM8 или по настройке IAR для него - помогу чем смогу.
Относительно IAR вряд-ли применять буду, пока ограничусь тем,что изготовитель предлагает. Насчет системы команд... У CALLR заявлена относительная адресация... но вот смещение там, по описанию РМ0044, почему-то как знаковое не заявлено... В то же время у JRA четко оговорено как signed. Или просто недопечатка или реально адресная часть у CALLR беззнаковая 0-255 вместо логически правильного +127/-128 ?
В таблице 4 на стр. 53 документа PM0044 в описании callr указано, что PC = PC + гг, где rr согласно обозначениям перед таблицей, знаковое в диапазоне (-128..127), как и должно быть. Однако, да - в детальном описании callr на стр 73 этот факт oпущен. Должно быть опечатка.
Подправил в конспекте после тест-пробы и читки листинга. Там реально +127/-128. Там кстати в rev3 (в отличии от более ранних) затесалась команда INT extmem, которая в моей версии IDE в упор не воспринимается - отметил как "ограниченное применение" в зависимости от версии компилятора.
Есть еще одна "бяка" в том же PM0044 rev3 (p.53): "... 6.11 Long Pointer Indirect Extended Indexed addressing mode The pointer address is a word, the pointer size is an extended word, thus allowing 16-Mbyte addressing space, and requires 2 bytes after the op-code. Example: 1089 180000 ptr dc.b page(table), high(table), low(table) 180000 10203040 table dc.b $10,$20,$30,$40 1690 AE03 LD X,#3 1692 72A71089 LDF A,([longptr.e],X) X = 3 A = ([longptr.e],X) = ((longptr.e), X) = (($1089.e), 3) = ($180000,3) = ($180003) = $40 ..." Хотя там по идее должен стоять нечто типа low ({seg table}) по аналогии с "... In the STM8, symbols .H and .L are not available. Use low and high primitives instead for example: lab1 equ $112233 ld A,#{low{seg lab1}}; load A with $11 ld A,#{high lab1} ; load A with $22 ld A,#{low lab1} ; load A with $33 ..." из UM0144 на p.17...
Поскольку STM решил делать компилятор под "большие проекты" мутнячка с разметкой памяти весьма много. Ежли учитывать аналогию с компилятором для INTEL8086 и выше по отношению к сегментам и префикс-суффиксам видимости меток. Пока жую через давлюсь. Память то у МК жестко сегментирована в блоках от 65536 килобайт. Пока программа будет использовать нулевой сегмент вопросов особо не получится, а вот ежли полезет повыше - там и подарки почуствуются. Особо относительно разметки и команд с short операндами. Ибо физически ограничено 0х0000-0х00FF. Имеем правда непонятную директиву .setdp ... одначе она касается исключительно препроцессора компилятора, а все "короткие" варианты делаются исключительно по базе 0х0000+метка (метка 0х00-0хFF) т.е. 0х000000-0х0000FF. Или может варьироваться как младшая зона каждого сегмента? В самом МК такового физического указателя вроде нетути... Ну и разнотолки имен в разметке при "взгляде сверху" - т.е. при работе с одними и теми же ячейками ОЗУ из программного кода в сташих сегментах. Под такую канитель видимо и задумана весьма накрученная (по отношению к компиляторам mcs51/avr/pic) система объявления имен и сегментов плюс "сшивка" отдельных самостоятельных *.asm файлов проекта в единый файл выходного объектного кода. Надо еще покрутить разметку и подстановку имен...
Внес правку в конспект-распечатку. Пока не определился с оптимальными обозначениями типов адресации для рисования шпоры по командам. Шапкозаготовка для проекта пыток по командам в стадии нашкрябывания. Распечатка референсе мануал пока ждет внебюджетного финансирования листочков - так что обгладывание аппаратной части оставлено "на лучшие времена".
Вопрос к обращавшимся с "живым"МК...
в карте адресов РСФ имеется область CPU/SWIM/debug module/interrupt controller registers в частности область CPU 0x00 7F00 A Accumulator 0x00 0x00 7F01 PCE Program counter extended 0x00 0x00 7F02 PCH Program counter high 0x00 0x00 7F03 PCL Program counter low 0x00 0x00 7F04 XH X index register high 0x00 0x00 7F05 XL X index register low 0x00 0x00 7F06 YH Y index register high 0x00 0x00 7F07 YL Y index register low 0x00 0x00 7F08 SPH Stack pointer high 0x03 0x00 7F09 SPL Stack pointer low 0xFF 0x00 7F0A CCR Condition code register 0x28
которая почему-то отмечена как "Accessible by debug module only"...
интересует - является ли эта область реально работающим для программного доступа полем отображения РСФ в области памяти (аналогия у ПИК по счетчику команд и акумулятору/статус-регистру и MCS51 - акумулятор как регистр РСФ) у реального кристалла или же означенная группа доступна только спецсредствами отладчика? Иными словами может ли обычная программа пользователя иметь доступ на разумное чтение/запись в области вышеуказанных регистров или такая возможность предоставляется только после ряда специальных подготовительных мер (только спецсредствами внешнего дебаггер/отладчика и IDE)?
Мммм...ннять... Судя по количеству очепяток ту РМ0044 (Doc ID 13590 Rev3) наследники Сусанина составляли/набирали... Ну да и сие преодолимо. Пробный наборчик команд из-за наворотов и особенностей адресации вылился в два листа сыроваренной шпоргалки.
К сожалению, придется несколько попозже распечатать и еще разок протестить на матюки от компилятора. Возможно и мнеуу очепятаться "повезло" - чистовой набросок к следующей недельке промудрю - пересортировать сырец надоть. Кроме прочего проект-заготовку "подчистить" для публикашки.... Но то ужо "в рабочем порядке" - форсаж для моднофанатизму неоправдан. Пока ждемс замечаний/дополнений/вопросов от спецов по ассемблеру для STM8 - все ж может чего и упустил.
может ли обычная программа пользователя иметь доступ на разумное чтение/запись в области вышеуказанных регистров
В документации явно написано, что доступ к этой области памяти доступен только модулю отладки. Для подтверждения я попробовал считать эту область памяти "живьём" внутрисхемным отладчиком на STМ8L152 следующим фрагментом кода программы пользователя Как видно, содержимое регистра А равно нулю, в то время как IAR IDE показывает в области памяти правильные значения величин Дальнейшие эксперименты показали, что при считывании из всего этого сегмента 7Fxx всегда возвращается 0. Может эту область памяти и можно считать косвенно через регистры модуля отладки, я с этим не разбирался поскольку не было нужды.
Тем самым можно предположить, что имеется "защелка содержимого" из регистров CPU в буфер видимый как область регистров ... А стробом являются команды отладчика. Ладныть... оставлю пока "на будущее".
Можно б "в реалжелезе" тест протащить для окончательного приговора - настроить порты на вывод, загрузить в X $fffe и через каждые пол секунды делать mov port_a,cpu_xl mov port_b,cpu_xh rlcw x - ежли сигнал на выводах побежит - значит доступ имеется, ежли нет - имеем досадный обломс... То уж когды может к железу перейду - протестю. Пока вот выкладываю подготовительную процедуру по изготовлению шапки проекта под ассемблером
Нет, Коллега, природу не обманешь используя другие команды процессора или режимы адресации. При тестировании следующего кода по шагам "живьём" на МК в отладчике
Код:
ldw X, #0xFFFE ld A, 0x7F04 ; A = XH? ld A, 0x7F05 ; A = XL?
ld A, #0xFF ld PA_DDR, A ; configure PortA for output ld PA_CR1, A ; push-pull mode for all pins mov PA_ODR, 0x7F04 ; PortA = XH? mov PA_ODR, 0x7F05 ; PortA = XL?
во всех битах А нули в первом фрагменте, также как на выходах порта и в отладчике и в железе во втором.
Ууууу... ДОСАДКО... А весьма ценные возможности упущены... Ну да и на том пока спасибки. Седня распечатку по "сырцам" сделаю для дальнейшей обработки/вычитывания.
... Весьма напоминает видоизмененное ядро Z80. Несколько удачнее, чем сегментированное ОЗУ Z8. Все ж технология объединенной полномасштабной ОЗУ и ПЗУ когда-то да должна была использоваться и в МК. (Прототип mcs51 с внешней памятью программ/данных). Математика с упором на акумулятор и два аналога DE/HL (ибо используются также в полном варианте под математику) индекс-базовые (IX и IY по аналогии Z80) сброшены в ОЗУ, одновременно вся область ОЗУ доступна логике, инкремент/декременту и операциям с битами. Основной козырь в данной конфигурации "программный стек"/переключение между блоками задач. Пока дальнейшее продвижение в сторону деталировке по железу временно приостановлено - лишних финансов не предвидится. Чего относительно "голой теории" возможно будет появляться. Однако это только по отношентию к STM8 - запасов сих железяк и программера увы в наличии нету.
BOB51, весьма сомнительные потуги считать себя умнее Сишных компиляторов. И самое смешное что, главное не это.... В STM прекрасная периферия . Нет тем вы занялись дедушко, НЕ ТЕМ , подсчет тактов и разжевывание мнемокода -напрасная трата времени . Знать асм и понимать архитектуру это прекрасно, но кодить на асме на STM - это сродни распиливания дров не заправленной бензопилой или любви в резинке - движения есть, прогресса НОЛЬ.
Периферия имеется в любом МК и в любой комбинации. "Подсчитывать такты" в системе с конвеерной предвыборкой - абсолютная глупость. Насчет "кодить" на ассемблере под STM8 - не сложнее, чем под Z80 или MCS51. Просто продолжение работ по данному семейству на данный момент не входит в финансовые планы. Ну а Ваша, уважаемый dosikus, сторчка "BOB51, весьма сомнительные потуги считать себя умнее Сишных компиляторов." простое хамство при отсутствии "чего по теме сказать".
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
