Вид для печати
К сожалению из говна и палок не получилось, хоть и очень хотелось... Прям почти чуть-чуть, но не совсем. Придется все-таки юзать либо контролер с хардварным юсб-стеком, либо фтди какой-нибуть, как нам советуют из болота. На ARM бы поднял за вечер, там и поднимать нечего, но хотелось чтоб люди смогли дома повторить, но не удалось, потому что арм всем хорош, кроме корпуса. Все равно благодарен всем тем, кто нечаянно следил за темой -)
Тут провел небольшой тестик - в цикле писал 1000 байт и засек время выполнения: 1.085690 секунд. То есть скорость ~ 1000 байт/сек.....
https://soundcloud.com/tronix286/jok...-surgeon-final
Короче, пришлось таки вкурить немного манов на тему USB протокола, как я ни сопротивлялся -) Поснифал USB-трафик, разобрался. Хотел сначала в след за контрол-пакетом слать дата пакет 8 байт данных, а потом просто запилил в ubr-пакет OUT передачу сразу 3 байт, вместо 1, как было раньше. Тем самым скорость передачи сразу возросла в три раза. Короче, заработало как и хотелось :) Все-таки удалось из говна и палок. Ура!
Да! Все работает стабильно. Еще пока тестю, попробую сейчас на всякий случай на WinXP на другом стареньком ноуте. Потом скоро постараюсь оформить в первом посте всю инфу, выложу все прошивки и исходники.Цитата:
Сообщение от creator
Я не думаю. Нужна точная частота 24MHz.Цитата:
Сообщение от creator
Все равно какие-то призвуки есть. Это фиксится?Цитата:
Сообщение от Tronix
Не знаю, я в наушниках слушаю - нормально. Возможно как и раньше, плеер перегружает и так записывает.Цитата:
Сообщение от Vitamin
Тут вчерась все-таки сделал посылку дата-блоков по 8 байт, буфер на 64 байта - короче скорость получилась вообще быстрая, может даже потом нужно будет по таймеру синхронизировать, хотя как по мне - так норм:
https://soundcloud.com/tronix286/vis...n-98-r-e-m-i-x
Но, обнаружилась другая достаточно неприятная проблема: через несколько тысяч фреймов ПЫК перестает реагировать на пакеты, перестает слать ACK хосту и как будто завис. Где, что зависает, как отдебажить - неведомо. Поэтому читал вчера вечером долго вслух сорцы. Пришел к выводу, что скорее всего зацикливается цикл приема бит в isr.asm:
Если смареть на оригинальную схему (у меня впрочем так же):PHP код:#define USB_DPLUS PORTB,0
#define USB_DMINUS PORTB,1
#define USB_EOPCHK PORTB,2
RxLoop:
btfsc USB_DPLUS
bsf INDF,4
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,5
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,6
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,7
incf FSR,F
clrf INDF
btfsc USB_DPLUS
bsf INDF,0
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,1
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,2
btfss USB_EOPCHK
goto Eop
btfsc USB_DPLUS
bsf INDF,3
goto RxLoop
http://hsto.org/files/7e2/96d/010/7e...efcb1eb44a.PNG
То видно, что RB2 - это есть D- и D+. Так как в один момент времени не может быть оба сигнала (D- и D+) в одинаковом логическом состоянии, кроме случая, когда это конец пакета. Тогда D- и D+ оба в нуле.
Но видимо так иногда складываются биты, что конец пакета пропускается. И тогда цикл зацикливается навечно. После того, как ПЫК перестал отвечать, если коротнуть RB2 на земелюшку, то он чудным образом начинает снова отвечать на мои ответы.
В цикле конечно нельзя добавлять никаких новых команд, потому что он и так оптимизирован по тактам (4 команды на каждый бит), частота пыка 24МГц. Поэтому счетчик по переполнению не добавить. Думал насчет WDT, но чет вроде не нашел команд как его остановить и включить - похоже он всегда работает в данном пик, а это плохо. Я бы по входу в isr включил его, а по выходу из цикла выключил. Но полный резет девайса - это не круто, слетят все настройки USB и он по любому отвалится от шины. То есть это не решение.
Решение мне видится только с хардварной стороны - когда там (на RB2) получился ноль, подержать его чуть-чуть. Или я не знаю. Впаял кстати вместо R2 15Kом на вышеприведенной схеме 3 Ком - немного отлегло, но не до конца. Может два часа работать, а потом возьми да и зависни.
WDT включается на постоянку только в конфиге и во время работы его включить/отключить нельзя.
Но можно при входе в прерывание сбрасывать вачдог (clrwdt), а в начальную инициализацию добавить проверку бита POR в регистре PCON : если он установлен, значит был сброс по питанию (тогда уходим в инициализацию), если обнулен - значит был сброс по вачдогу (тогда уходим в основной цикл программы).
А сейчас вообще мистику наблюдаю, поменял в посылке wValue с 0x01 на 0x10 и уже час полет нормальный, даже на тех модулях, что стабильно висли... Здорово и интересно, но непонятно. Ладно, работает - не будем трогать.
https://soundcloud.com/tronix286/hyp...posed-by-d-n-k
https://soundcloud.com/tronix286/com...f-ggvg-ym2149f