Вид для печати
Да, я думал и об этом тоже. Большая проблема в том, что если повысить частоту, то слетают все временные интервалы в софтовом USB стеке. Там часть подогнана с помощью высчитанных заранее машинных тактов, кое-где goto $+D'1', кое-где таймер с константой и тд. Повышаем частоту - PIC перестает распознаваться. Если гнать, нужно полностью вкурить как работает USB на низком уровне, а я чего-то очкую.Цитата:
Сообщение от ALS
А, да, что-то я не подумал...
Вообщем, оптимизировал как мог код записи байта в PIC:
Ну, играет вроде:Код:DIO_WriteByte:
;Put value in RB3-RB7
movlw B'00000111'
andwf PORTB,W
movwf TMP
movlw B'11111000'
andwf RXDATA_BUFFER+4,W ;wIndex Lo
iorwf TMP,W
movwf PORTB
;Put the last bits values in RA0-RA2
movlw B'11111000'
andwf PORTA,W
movwf TMP
movlw B'00000111'
andwf RXDATA_BUFFER+4,W ;wIndex Lo
iorwf TMP,W
movwf PORTA
iorlw B'00011000' ;set bc1=1, bdir=1
btfsc ODDEVEN,0 ;skip next intruction if first byte
andlw B'11110111' ;set bc1=0, bdir=1 if second byte
movwf PORTA
andlw B'11100111' ; set bc1=0, bdir=0 (inactive)
movwf PORTA
movlw B'00000001' ; toggle ODDEVEN flag
xorwf ODDEVEN,F
return
https://soundcloud.com/tronix286/hig0dzhmm-nik-0tl99
Но мне кажется, что медленно. Или это меня уже глючит, не знаю. Или реально медленно. Дальше еще можно попробовать буферизировать в самом ПИКе паттерн из 28 байт, одновременно принимая байты во второй буфер (двойная буферизация), но это как-то сложно, да и вряд-ли выгорит по времени выполнения. Если только еще сжимать предварительно LZW или что там быстрое. Но это уже больше костыли какие-то. Уперся уже совсем в предел, мне кажется.
Либо так, либо менять на ПИК с хардварным USB.:v2_dizzy_christmas:
---------- Post added at 14:29 ---------- Previous post was at 14:16 ----------
Ну вот выкинул еще одну команду
Так тоже работает. Но это все.Код:;Put the last bits values in RA0-RA2
movlw B'11111000'
andwf PORTA,W
movwf TMP
movlw B'00000111'
andwf RXDATA_BUFFER+4,W ;wIndex Lo
iorwf TMP,W
;movwf PORTA
iorlw B'00011000' ;set bc1=1, bdir=1
прпробуй две одинаковых мелодии на разных устройствах одновременно запустить и сравнишь.Цитата:
Сообщение от Tronix
Короче прикрутил еще кольцевой буффер на 28 байт, теперь в декодере складываю туда байты, а иногда, в основном цикле, вывожу их на YM.. Это позволило в библиотеке USB-lib откатится назад на время ожидания в тиках 1000. Раньше стояло 5 и работало только на моей машине, на нетбуке - уже глючило. Щаз полет и там и там нормальный.
Скорость воспроизведения - такая же как и в прошлый раз, имхо. Ну, все, больше я не знаю что делать. Оставляю как есть.
На всякий случай выкладываю схему устройства, исходники прошивки, исходники DLL-заглушки для ZX Tune.
Плюс уже скомпилированная прошивка для записи в микроконтроллер PIC16F628A и длл-ки для x86 и x64. Драйвера брать здесь: http://16fusb.googlecode.com/files/1...32-1.2.6.0.zip
Прошивка базируется на оригинале библиотеки 16FUSB, но многое подогнано "под себя":
- выкинуто все, что связано с чтением сигналов из PIC в хост (компьютер) для увеличения быстродействия обработки реквестов USB;
- состояние направлений портов ввода-вывода жёстко задано при инициализации МК и не изменяется в процедурах выдачи байта на ноги.
- организован кольцевой буфер на 28 байт. При декодировании запроса от хоста байты складываются в буффер. Когда есть свободное время, данные из буфера выдаются на YM.
- дичайше оптимизирована скорость выдачи байта на ноги МК. Частично за счет жестко указанных направлений ввода-вывода, частично из-за известности предыдущего состояния управляющих бит.
- что-то еще по мелочи.
По схеме - для тактирования PIC применен кварцевый генератор, а не кварц, тем самым высвобождая одну ногу МК (RA6), необходимую для управления сигналом RESET. Нога RA5, торчащая в воздухе, в данном семействе работает только на вход и не может быть использована для управления выходным сигналом. Можно было бы попробовать ее (ногу RA5) использовать как входной сигнал U+ или U- USB, но в обработчике прерывания тогда бы увеличилась задержка из-за разбросанности на разных портах (порт A и порт B) сигналов, что скорее всего привело бы к неработоспособности USB стека. Хотя не отрицаю, что возможно бы и получилось перенести с ноги RB2 функционал на RA5, а RB2 использовать для управления RESET, а МК тактовать просто от кварца. Но, как получилось. С другой стороны, для тактирования YM2149F собран генератор на микросхеме 74HC02 и кварце 3.579545 MHz. Можно было бы попробовать использовать вторую свободную половину микросхемы для сборки аналогичного генератора и для PIC, но остановило два момента: 1) у меня нету кварца на 24МГц (а кварцевый генератор был, с какой-то древней мамки) 2) я не знаю, как поведет себя 74HC02, если с "разных боков" у нее будут разные частоты, причем одна из них довольно высокая (24МГц все таки большая частота).
Дальше, нога RA4, которая управляет сигналом BDIR, с открытым коллектором, поэтому ее обязательно нужно подтянуть к питанию - на схеме это 10K резистор R5.
Tronix, если ZXTune будет общаться с библиотекой в пакетном режиме (2 байта маски и 0..14/14 (по желанию) байт данных), тебе это поможет?
[04.01 00:35:42] <deathsoft> TSL, скинь в болото линк http://dlcorp.nedopc.com/viewtopic.php?f=21&t=732
Не совсем понял мысль? Сейчас и так я шлю только байты данных, без управляющих сигналов. Пропускаю каждый второй байт. Может просто попробовать убрать любые задержки при выводе..Цитата:
Сообщение от Vitamin
Еще посетила безумная мысль - как только обработали принятый байт в ПИКе, все, выходим в начало суперцикла, не отвечая ничего хосту (компу). Ни NAK, ни ACK, просто ничего. По идее, функция usb_control_msg(..) должна тогда отвалится по таймауту. Таймаут можно минимальный поставить в 1 такт.
Ну вот чтоб тебе не приходилось делать эту логику по пропуску байтов и еще чего, твоя лично-персональная длл будет получать на входе сразу массив регистров (сжатый или несжатый, по желанию) и 16-битную маску с закодированными индексами регистров.Цитата:
Сообщение от Tronix