STM8L152, LCD, halt mode..., запутался... Опции

[rx3apf]

Поскольку до конца картина не утряслась, объясняю сумбурно (за что прошу извинения).

Итак, устройство ради минимального потребления все время в active halt, просыпаясь, обновляет значения на индикаторе и вновь засыпает. Все обновляло, пока реально в halt не вгонял, а с halt - перестало. Как я понимаю, содержимое регистров LCD в состоянии halt вообще не желает переписываться в регистры драйверов (регистры обновляю, а на экране стоит как вкопанное), так что полез глубже, переписывая саму работу с LCD. И стали открываться совсем уже мрачные чудеса:

1. Несмотря на то, что в даташите написано, что прерывания LCD из halt не поднимают, по крайней мере из active halt все же работает. Это радует. Но ! Просто тупо раскрыл прерывания для только LCD, в обработчике дергаю ногой, в основном цикле просто halt и цикл. Работает. Секунды две-три-пять. Потом встает (прерываний нет, нога не дергается). Ладно - вычитал, что подъем из halt может некорректно работать при тактовой больше 8 MHz +5% (а у меня, между прочим, изначально делитель на два, т.е. тактовая как раз 8 и не больше). Стал ставить /4 перед halt, меняя его на /2 после - вроде зависать перестало, прерывания идут не срываясь. Хотя явное несоответствие даже errata уже напрягает...

2. Прерывания-то идут, только не одиночно, а пачкой (12 шт) - выходит из halt и тут же опять, основной цикл (в котором тоже ножкой помахиваю) до этой ножки не доходит, 12 прерываний в течении ~60 us (вероятно, чуть меньше 2/32768). Естественно, в обработчике бит SOF я сбрасываю (установкой SOFC). Вот только и это (сброс SOF) работает более чем странно - если выставить SOFC и реально попробовать дождаться деактивации SOF в самом обработчике, сброс не происходит вообще, из цикла проверки никогда не выходит ! А вот если обработчик копирует состояние SOF на ногу и выходит - все ж сбрасывается (но через те самые 60 us).

Потихоньку занимаюсь шаманством (и, надеюсь, что-нибудь все ж придумаю), но гложет вопрос - наверняка ведь на эти грабли кто-то и раньше наступал, как их правильно обходят ? Т.е. как правильно выполнить обновление показаний на LCD и при этом оставаясь в максимально экономичном состоянии ?


upd:

Все чудесатее и чудесатее ! Оказывается, в обработчике прерывания LCD я не могу не только сбросить SOF, но даже и обнулить SOFIE !!! т.е. я его перевожу в 0 - а все равно десяток с лишним прерываний происходит с одного SOF. Решил зациклить проверку SOFIE после сброса (т.е. циклюсь, пока после сброса SOFIE в "0" он реально не станет нулем) - и все, так в этом цикле в обработчике прерывания и остаюсь ! И как прикажете сделать однократный вызов обработчика SOF ? Сейчас попробую - если заполнение LCD_RAMx займет те же 60 или больше us, возможно, что и проблемы не будет. Но все равно коряво до ужаса... Более корявого ядра я пока вообще не встречал, идиотизм на идиотизме плюс компилятор неземной кривизны...

upd2:

Как я понимаю, SOF и SOFIE реально сбрасываются только (и сразу) после выхода из обработчика прерываний, но при этом должно пройти не менее 60 us (иначе все равно будет повторный вызов обработчика). Когда основная программа получила управления, эти биты уже заведомо сброшены.

Если в обработчике прерываний что-то делать в течении 60 us, и сбросить SOF перед выходом(!), повторного входа в обработчик уже не будет. Но в LCD_RAMx в эти 60 us писать бесполезно - на экране ничего не изменится (!!!). Реальное изменение произойдет только если (в обработчике) что-то делать 60 us, а потом записать в LCD_RAMx. Мда, квест тот еще...

Еще забавно - в момент вызова обработчика прерывания LCD не только содержимое LCD_CR3 не хочет корректироваться, но даже и содержимое LCD_RAMx. Т.е. если что-то в LCD_RAMx там (в обработчике) записать, и потом вычитать - вычитается вовсе не то, что записано только что. А вычитается состояние, попавшее в этот регистр тогда, когда это можно было сделать (и что вызывает изменения на экране), т.е. после 60 us от появления SOF !!! Хм... Может, в каких-нибудь ANxxx описано ? В эрратах нет...

Сообщение отредактировал rx3apf - Feb 22 2018, 19:22