писать и читать данные из pic16F876 при помощи LPT

[MaxChip]

стоит задача помогите разобраться
может сталкивался кто-нибудь и подкинет примерчик
как прицепится пиком к лпт порту, требуется выжать максимальную скорость, вроде LPT позволяет побольше выжать чем USB и уж тем более чем COM
или может я не прав?

[DK]

да прям просто и цепляй. Напрямую. Целиком порт пика на LPT. Сигнал готовности с другого порта. Только вот LPT тормозной. Старые порты, насколько я помню, обмен позволяли порядка 300 кб/с. Новые не намного быстрее. Лучше уж тогда УСБ делать.

[walrus]

Для Пика можно попробовать параллельный слэйв порт , прямо по документации , а для компа поищи такую штуку inpout32.dll если не найдёш сообщи мне [email protected], я тебе вышлю работает , как говорят до ХР. а вот про скорость я и сам не знал. Да и не мерил.

да прям просто и цепляй. Напрямую. Целиком порт пика на LPT. Сигнал готовности с другого порта. Только вот LPT тормозной. Старые порты, насколько я помню, обмен позволяли порядка 300 кб/с. Новые не намного быстрее. Лучше уж тогда УСБ делать.

и использовать не пик т.к. все ресурсы пика уйдут на пересылку

и использовать не пик т.к. все ресурсы пика уйдут на пересылку

но вот с другой стороны, что можно в пике такого забацать, шоб не хватало скорости в 100 КИЛОБАЙТ в секунду
Если только генерацию тестовой последовательности, или циклическая передача чего-либо.

[MaxChip]

работаю с LPT впервые поэтому и спросил примеров
как не верти точку зрения я не изменил: LPT в соотношении быстрее*проще выигрывает у всех других интерфейсов.
информации у меня достаточно не хватает только примеров готовых проектов, очень помогли в этом вопросе такие вот ссылки
http://www.beyondlogic.org
http://www.codeproject.com/csharp/cspplcds.asp

работаю с LPT впервые поэтому и спросил примеров
как не верти точку зрения я не изменил: LPT в соотношении быстрее*проще выигрывает у всех других интерфейсов.

про быстрее*проще сказано впервые Вопрос стоял, может ли лпт сделать усб в общем случае не может, в частном запросто.

[DK]

но вот с другой стороны, что можно в пике такого забацать, шоб не хватало скорости в 100 КИЛОБАЙТ в секунду
Если только генерацию тестовой последовательности, или циклическая передача чего-либо.

Не так давно на микрочиповской конфе кто-то говорил, что делает проект. Не суть важно, но там несколько каналов АЦП и выборки с приличной скоростью... Вот для такого, пожалуй, большая скорость пригодится. В этом отношении по ЛПТ действительно проще и быстрее передать. Что быстрее - передать через RS232 два байта, или вытолкнуть их через параллельный 8-бит интерфейс?

Сейчас посчитаю.

пусть имеется пик 16, три канала по 8 бит 100 кГц.
От проца требуются данные синхронно, сплошным потоком, передавать в порт. Поток 300 килобайт в секунду. пусть АЦП встроенное, т.е. считывание за один такт процессора. сколько надо пику времени на то, что бы обработать один канал.
пусть данные принимаются по прерываниям.
Такты проца на одну выборку:
3+3=6 возникновение/окончание прерывания;
6 сохранение восстановление контекста проца (можно убрать);
4 переписывание данных в буфер порта из буфера ацп и т.п.
1 запуск буфера.
2 выбор канала АЦП

Итого 13..19 тактов.
если 300 кГц, то на одну выборку должно уйти максимум 1/3E5=0.3E-5=3E-6 т.е. 3 мкс.

Пусть среднее, 16 тактов 3мкс/16тактов=190 нс на шаг.
Ну в притык, на 21 МГц.
Задача конечно излишне абстрактная, но расчеты показали, что для нее возможно я как раз имел ввиду, что передача возможна, но пик не успеет. Для данной задачи успел, я был не прав Интересно, какова реальная задача

А как насчет передачи (запись/чтение) по протоколу ECP?
Это возможно реализовать?
Если да, то как?