Atmega 16 И 4 Линии Прерывания.

[NA1S]

Может кто-нибудь сталкивался с такой проблемой? ВОзможно ли использование Atmegi 16 для работы с 4 мышками(клавиатурами) на ps/2. Там есть 2 провода один Clock, другой Data. Протокол: стартовый, дата, стоповый. Я в программе обработки прерывания лишь считываю и записываю в буфер. Успеет ли мк на частоте 8 mhz? И если не успеет, то что мне посоветуете?

[nml]

ВОзможно ли использование Atmegi 16 для работы с 4 мышками(клавиатурами) на ps/2. Там есть 2 провода один Clock, другой Data. Протокол: стартовый, дата, стоповый. Я в программе обработки прерывания лишь считываю и записываю в буфер. Успеет ли мк на частоте 8 mhz?

Не знаю как у мышки, а у клавиатуры, насколько я помню, передавалось не кратное 8-ми количество бит. То есть SPI не задействуешь, хотя, казалось бы, самое то. Остается программное. Линии DATA завести куда удобно, линии CLOCK - на INT. Но INTов всего три. Значит, надо извращаться - а это вполне можно, периферии всякой предостаточно.

Вариант 1. таймер1 в режим capture - само capture пофигу - но прерывание будет

Вариант 2. Используем аналоговый компаратор. AIN0 у нас INT2 - но компаратор можно настроить так что вместо AIN0 будет фиксированное напряжение (см. бит ACBG)

Вариант 3. Таймер 0 в режим CTC - OCR0=1 - строб на T0, спад или фронт - выбирается.

Наверняка можно и еще чего придумать, но уже лениво.

[NA1S]

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

[nml]

Проблема не в том, что не хватит, а в том что успеет ли она обработать все сигналы с мышек.

Ну давайте прикинем. тактовая у клавиатуры, если я не ошибаюсь, порядка 30 мкс. То есть, в идеале, обработчик прерывания должен быть порядка 7-8 мкс - это если все 4 байта принимаются одновременно, что, вообще-то, маловероятно. Но возможно, потому считаем самый плохой вариант.

Пишу такой вот кусок - в [] такты. для каждого канала в ОЗУ переменные - cntr - счет бит, lbr,hbr - буфер приема, flag - понятно, hiresult, loresult - тоже понятно - результат, чтоб прием след. байта не портил.

			; [6] interrupt+rjmp

	push TMP	;[2] save
	in TMP,SREG	;[1]
	push TMP	;[2]
	;-----------------
	in TMP,PINx	;[1]
	bst TMP,y	;[1] T=input bit

	lds TMP,lbr	;[2]
	rol TMP		;[1]
	bld TMP,0	;[1] lo result
	sts lbr,TMP	;[2]

	lds TMP,hbr	;[2]
	rol TMP		;[1]
	sts hbr,TMP	;[2] hi result

	lds TMP,cntr	;[2] counter
	dec TMP		;[1]
	breq finita	;[1]

	;-----------------
	pop	TMP	;[2] restore
	out SREG,TMP	;[1]
	pop	TMP	;[2]

	reti		;[3] [36] 4,5us
;------------------------
finita: ; +[1] breq

	lds TMP,lbr	;[2] buf -› variable
	sts lorezult,TMP;[2]
	clr TMP		;[1]
	sts lbr,TMP	;[2]
	lds TMP,hbr	;[2]
	sts hirezult,TMP;[2]
	;

	ldi TMP,1	;[1] flag
	sts flag,TMP	;[2]
	ldi TMP,11? 	;[1] init counter
	sts cntr,TMP	;[2]
	rjmp exit	;[2] [+20] [all = 7 us]

и вижу, что даже обработка последнего бита (где добавляется finita) в общем укладываетя в наше время, прием же бит - и того короче. И это все "по простому" то есть все переменные в ОЗУ. Если же есть место и возможности сложить их в регистрах - будет еще на четверть короче.

Мораль - успеет запросто. Да, написано с лету, проверять особо не проверял, может где и ошибся, тогда прошу не пинать