 Разработка, производство и продажа радиоэлектронной аппаратуры  |
Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс. e-mail:jobsmp@pochta.ru |
Нашел на http://www.punbb-hosting.com/forums/piclist/viewtopic.php?pid=4#p4
Цитирую -
Поскольку VDrive2 поставлялся с прошивкой VDAP 2.08, мы основательно прошли по всем граблям, по которым, судя по зарубежным форумам, ещё зимой этого года проходили другие разработчики. Это и неработающие команды в разных режимах, и какой-то бредовый формат команды записи файла, и неприятные баги в самом даташите на VDAP (такое впечатление что у FTDI все даташиты сделаны не для людей а для каких-то техноманьяков и телепатов).
Ну, баги в даташите мы с грехом пополам обнаружили и поправили.
Потом обнаружилось, что FTDI выпустила новую прошивку v.3.50. Плюсы: исчезли все обнаруженные нами баги, а также команда WRF приведена к более человеческому виду (из конца команды выкинут символ $0D). Небольшой минус: вместе с прошивкой поставляется не новый исправленный даташит, а скромный TXT-файлик с нововведениями и фиксами (вернее с прошивкой вообще ничего не поставляется, а о существовании этого файлика нужно догадаться самостоятельно и потом где-то его найти). В совокупности с кривым даташитом на старую версию, это ещё больше путает и так жутко запутанную и глючную доку.... Надеемся, FTDI уже работает над новым даташитом, ну а мы будем следить за ними и работать над переводом на русский язык.
1. Поигравшись с командами, мы начали отправлять тестовый файл размером 70Кб на флэшку, и тут выяснилось: как бы нам не хотелось избавиться от хэндшейка VNCL (он же handshake или handshaking), всё-таки для нормальной работы даже на смехотворно низких скоростях (9600 бод) он необходим!! Без хэндшейка в 100% случаев успешно работают все информационные команды (DIR, IDD, смена режимов, открытие файла, чтение и тп), но в 20% глючит команда отправки файла на Flash-диск. Этот баг происходит в самом конце отправки массива данных. Видимо, это такая особенность текущей прошивки + небольшой приёмный буфер ОЗУ в VNC1L.
Всё это говорит о том что всё-таки придётся пожертвовать 2мя ногами контроллера, чтобы спокойно работать с VNC1L через UART (USART).
2. Режим работы через SPI неисследован (у VNC1L такой мудрёный SPI это просто кошмар какой-то - чего только стоят бит "старые данные\новые данные" и засекреченные биты в недокументированном статусном регистре). Пока я вообще не понимаю, как можно с таким SPI нормально работать даже в теории (неспроста с VNC1L все работают либо через параллельный FIFO, либо через UART, либо вообще никак). Хоть у Vinculum-а на сайте и лежит пример работы на Си через SPI, но после его просмотра мне стало ещё хуже - генерить такты switch-ами это полный бред ИМХО.
По результатам экспериментов будут написаны подробные статьи с исходниками....
--------
Саппорт FTDI прислал документ, который описывает работу VNC1L в режиме SPI: http://piclist.by.ru/pub/VNC1L_SPI_Interface.pdf
Собственно, это развёрнутое описание ихнего примера с блок-схемой конечного автомата. Учитывая то, что в официальных даташитах этой информации пока нигде не видно, в целом дока полезная
