Нужен оптимальный алгоритм RTC

[Мастер Ломастер]

Вот, тупо в лоб. Говорю - не оптимально будет

не надо оптимально, надо, чтобы работало. допустим, с секундами понятно, допишите кусочек для минут, ибо что дальше делать - не очень понятно...

[МитяРа]

ибо что дальше делать - не очень понятно...

А у мя, хоть понятно получилось?

[ploop]

Дык у нас он одинаковый почти
Я тоже не всё понял, но суть та же.

В моём коде 11 команд ровно по 1 такту получилось, это на секунды/минуты,часы. На дни/месяцы больше будет - там грузить кол-во дней, учитывать високосный год и т.д.

Может, кто еще что придумает?

[ploop]

Мастер Ломастер, там аналогично. Ща напишу.

Код: Выделить всё

clr r17                    ; r17 <- 0
lds r16,clk_ss             ; грузим секунды
cpi r16,60                 ; сравниваем
rol r17                    ; r17 <- C
bst r17,0                  ; T <- C
ror r17                    ; Восстановим С 
adc r16,null               ; Если не перевалило - r16 увеличится на 1
bld r17,0                  ; r17 <- T
neg r17                    ; r17 = 0-r17
and r16,r17                ; Маску на r16
sts clk_ss,r16             ; Пишем его

clr r17                    ; r17 <- 0
lds r16,clk_mm             ; грузим минуты 
cpi r16,60                 ; сравниваем
rol r17                    ; r17 <- C
bst r17,0                  ; T <- C
ror r17                    ; Восстановим С 
adc r16,null               ; Если не перевалило - r16 увеличится на 1
bld r17,0                  ; r17 <- T
neg r17                    ; r17 = 0-r17
and r16,r17                ; Маску на r16
sts clk_mm,r16             ; Пишем его

clr r17                    ; r17 <- 0
lds r16,clk_hh             ; грузим часы 
cpi r16,24                 ; сравниваем
rol r17                    ; r17 <- C
bst r17,0                  ; T <- C
ror r17                    ; Восстановим С 
adc r16,null               ; Если не перевалило - r16 увеличится на 1
bld r17,0                  ; r17 <- T
neg r17                    ; r17 = 0-r17
and r16,r17                ; Маску на r16
sts clk_hh,r16             ; Пишем его

[O-LED]

Может, кто еще что придумает?

все ради интереса. и только на сях.
одно время.

Код: Выделить всё

iong int x;
**********
x++;
x=x%86400;
**********
sek=x%60;
min=(x-(x/3600*3600))/60;
hour=x/3600;

время+календарь.

Код: Выделить всё

sec++;

min=min+(sec/59);

hour=hour+(min/59)

sec=sec%60;
min=min%60;
hour=hour%24

[ploop]

время+календарь.

А как количество дней в месяце, високосный год?

[Мастер Ломастер]

ибо что дальше делать - не очень понятно...

А у мя, хоть понятно получилось?

то пусто, то густо пока я вникал в код ploop-a, страничка перекрутилась и я не увидел вашего поглядел, вроде все понятно. но скажите мне: оно того стоит? как этюд - достойно, но на практике?

я вижу в этом подходе только одно преимущество: строго фиксированное число тактов на обсчет независимо от значений счетчиков. в некоторых случаях это может быть решающим, но в бОльшем числе случаев... гемор однако и что-то мне подсказывает, итог будет не компактней "тупого" подсчета с ветвлениями...

[Мастер Ломастер]

все ради интереса. и только на сях.

ради интереса - принимается. а в практических целях это, имхо, худший вариант деление и вычисление остатка от деления - вещи весьма накладные...

[O-LED]

время+календарь.

А как количество дней в месяце, високосный год?

ну наверное можно завести массив mass с количеством дней в месяц.

Код: Выделить всё

Number=Number%mass[Month];

все ради интереса. и только на сях.

ради интереса - принимается. а в практических целях это, имхо, худший вариант деление и вычисление остатка от деления - вещи весьма накладные...

ну слава богу.

[ploop]

и что-то мне подсказывает, итог будет не компактней "тупого" подсчета с ветвлениями...

Тут дело вот в чём... Формально переход к подпрограмме + возврат из неё = 4+4=8 тактов, т.е.линейный алгоритм в этом случае короче почти в два раза. Но он пробегает весь цикл вычисления, соответственно чисто для секунд получается намного дольше.

Огромный выигрыш получится только 31 января в 23:59:59

[ploop]

Мой код упрощается до этого:

Код: Выделить всё

clr r17                    ; r17 <- 0
lds r16,clk_ss             ; грузим секунды
cpi r16,59                 ; сравниваем
rol r17                    ; r17 <- C
add r16,r17                ; Если не перевалило - r16 увеличится на 1
neg r17                    ; r17 = 0-r17
and r16,r17                ; Маску на r16
sts clk_ss,r16             ; Пишем его

clr r17                    ; r17 <- 0
lds r16,clk_mm             ; грузим минуты
. . . . . . . .

С инкрементом

Код: Выделить всё

clr r17                    ; r17 <- 0
lds r16,clk_ss             ; грузим секунды
inc r16                    ; увеличиваем их
cpi r16,60                 ; сравниваем. Если r16<60 устанавливается флаг C
rol r17                    ; r17 <- C (C двинется в младший бит r17)
neg r17                    ; r17=0-r17 (Если C был 1 результат будет 0 иначе FF)
and r16,r17                ; маску на r16 (Если C был 0 то и r16 обнулится)
sts clk_ss,r16             ; сохраняем его

[МитяРа]

Мяу всем..

оно того стоит? как этюд - достойно, но на практике?

Это и был пример решения выдернутого из контекста куска программы, без учёта самой программы и общей задачи..
А что касается практики, то всё зависит от конкретной задачи..
У мя были два проекта, которые получилось реализовать на полностью линейном алгоритме..
В других случаях оптимальнее - комбинировать оба метода..

Линейную реализацию мя применяю для управления устройствами, где есть на входе некоторые входные воздействия и необходимо в реальном времени управлять выходными сигналами..
Но не по принципу ПЗУ, когда адрес сменился и сменился выход, а на основании обработки текущего состояния системы, предыдущего состояния, пред-предыдущего и почти любой степени вложенности..

[МитяРа]

Мой код упрощается до этого:

С инкрементом

Приветствую, пушистый..

Мя чую те понравилось "разминать мозги" линейными алгоритмами..

[ploop]

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

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

[МитяРа]

частые переделки алгоритма и прочее, наверное Си равных нет.

По части "написать на Си кривой алгоритм, а потом часто переделывать"? Наверной - да..

Мя тоже ассемблера хватает и алгоритм единожды написанный не переделываю..

[Jack_A]

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

Не могу полностью согласиться. На Си, конечно, пис`ать быстрее, но и на нем можно сгородить такую конструкцию, что восемь мудрецов не разберутся. А если на ассемблере не лениться и хорошо, а не скупо комментировать как весь алгоритм в целом, так и каждый значимый кусок ( я по возможности, работая на заказ, старался себя к этому принуждать ), то вопросов по сопровождению не будет, если профи. А еще в сопроводиловке к проге давать схемы алгоритмов. Занятие нудное, но полезное.
Иногда меня посещала "гениальная", но может быть, неочевидная идея, давашая ощутимый эффект, я не ленился подробно расписывать, что мы тут достигаем и каким путем. Очень полезно бывало после отпуска и самому : "И какой идиот такую хрень накорячил ?! ... А, ну тогда -- совсем другое дело !"
Так что "понимабельность" программ -- это не совсем вопрос выбранной среды, а скорее культуры программирования.

[ploop]

Я практически всегда комментирую свои исходники как в примере выше, опуская лишь самые очевидные моменты (типа inc r16 ; увеличиваем r16). Во-первых, во время комментирования собираешься с мыслями, и иногда приходят в голову новые идеи, во-вторых самому приятно читать код через некоторое время, в третьих - не задумываясь можно скопипастить кусок на форум или дать кому-то целиком, знаешь, что он в порядке.

Асма это особенно касается, там даже над элементарным алгоритмом придётся задумываться, если код чужой и без комментов.

[Engineer_Keen]

Нравятся мне такие задачки
Чуть короче и без использования бита T

Код: Выделить всё

	CLR	r17		;r17=0
	MOV	r16,TS	;load SEC
	INC	R16		;+SEC
	CPI	r16,60	;<60 ?
	SBC	R17,ZERO	;IF LESS ->MASK=0xFF
	AND	R16,R17	;AND MASK
	MOV	TS, r16	;Save SEC

	COM	R17		;1) IF MASK=0 ->MASK=1
	ANDI	R17,0x01	;2) IF MASK=FF -> MASK=0
	MOV	R16,TM	;load MIN
	ADD	R16,R17	;MIN=MIN+MASK
	CLR	R17		;R17=0
	CPI	r16,60	;<60
	SBC	R17,ZERO	;
	AND	R16,R17
	MOV	TM, r16

	COM	R17		
	ANDI	R17,0x01	
	MOV	R16,TH
	ADD	R16,R17
	CLR	R17
	CPI	r16,24
	SBC	R17,ZERO
	AND	R16,R17
	MOV	TH, r16

PS: а каменты всегда пишу на на английском, т.к. в процессе творчества влом переключать раскладку

[МитяРа]

Нравятся мне такие задачки

Во.. нашего полку "прямоалгоритмикоффф" - прибыло..

[Мастер Ломастер]

я сразу отметил достоинство этого "прямого" алгоритма - фиксированная длительность исполнения, не зависящая от текущего состояния счетчиков. однако, требуется такая особенность довольно редко, т.е. это скорее экзотика. для часов - однозначно экзотика. а вот для понимания - это уже усложнение. если сложность понимания не компенсируется суровой необходимостью - я такого не понимаю.