Сопряжение Атмеги с ЛПТ

[PB_EXPERT]

нужно для начала набросать схемку и спаять примерчик

Подключи вывод RxD к выводу 2 порта, а вывод TxD к выводу 10 (он инвертирует сигнал) порта.
И пиши программу....

[YS]

Сделайте так, как PB_EXPERT сказал. И все.

Только я еще рекомендую выделить ножку на МК для тактирования. А то без явной аппаратной синхронизации в Windows будет сложно по причине невозможности отмерять четкие интервалы времени менее 1мс.

Не пугайтесь, ассемблера там много не надо. Все на уровне mov/out/in.

В C++ Builder я делал так (с использованием GiveIO):

Код: Выделить всё

  Вывод:

  asm{
    mov DX,0x378
    mov AL,<имя_переменной типа unsigned char>
    out DX,AL
  }

  Ввод:

  asm{
    mov DX,0x378
    in AL,DX
    mov <имя_переменной типа unsigned char>,AL
  }

Ну или поглядите на тот же inpout32.dll.

Прочитайте наконец статьи про LPT - http://www.pcports.ru/Articles.php .

[rapaks]

Подключи вывод RxD к выводу 2 порта, а вывод TxD к выводу 10 (он инвертирует сигнал) порта.
И пиши программу....

Ну вот уже кое что дельное с учетом выше сказнного от YS.

Что нибудь на эти 2 провдка вешать нужно? Резисторы, диоды или еще чего для защиты ?

YS, а куда мне подключать 3й проводок ? Какие это будут ножки в ЛПТ и МК ? И что еще потребуется на них вешать дполнительно ?
Я так понимаю вы это делали раньше, занчит у вас есть схемки и программки какието, скиньте пожалуйста если не сложно.

Статьи про ЛПТ я читал уже очень давно, еще до того как надумал делать этот проект. Естественно почитаю, но чуток попозже щас надо со схемой разобраться.

А ассемблер использовать не хочется даже не потому что я его ооочень плохо знаю, а потому что хочется кросплтаформенности!
ПОэтому писать софт будут на QT и C++. Ну под виндой можно заюзать сторонний драйвер (не родной), а как быть с другими ОС - я пока хз.

[YS]

Что нибудь на эти 2 провдка вешать нужно? Резисторы, диоды или еще чего для защиты ?

Защиты от чего? Ничего не надо, естесственно. Просто кусок провода.

Какие это будут ножки в ЛПТ и МК ?

Ну е-мое, ЛЮБЫЕ ПОДХОДЯЩИЕ СВОБОДНЫЕ, ибо в любом случае протокол будет софтверный. Я же не знаю, какие у Вас ножки МК свободны?

Ну нету, нету у LPT порта каких-то стандартных схем родключения, стандартного протокола (тем более, что в Вашем случае его использовать не получится по-любому), как, например, у RS-232 (RX-TX)! Как УДОБНО ВАМ, так и подключайте. Какие ноги свободны, такие и соединяйте. Куском провода, напрямую! Да, именно так. Просто и брутально. Да, Вы не ослышались. Могу и еще раз повторить.

Определитесь, кто у Вас будет генерировать синхросигнал передачи (МК или ПК), и исходя из этого выбирайте ножку LPT. У МК-то ножки все двунаправленные...

[rapaks]

Нашел это

Тут получается что сигналы передаются всего по 2м ножкам от ЛПТ вот тока не понятно в 1 сторону или в 2 стороны ?

А если эту схему передать так

easyI2Cbus_000.JPG

(28.19 КБ) 776 скачиваний

будет ли она работать и к каким ножкам подключать на МК ?

[PB_EXPERT]

будет ли она работать и к каким ножкам подключать на МК ?

Подключай к выводам аппаратного модуля I2C.
Комп будет хозяином, а МК рабом на шине I2C.

[rapaks]

Мозг пухнет от инфы

Для ATmega 8 это ножки
27 PC5 (SDA)
28 PC4 (SCL)

Для ATmega 16 это ножки
22 PC0 (SCL)
23 PC1 (SDA)

А может можно эти SCL и SDA с ЛПТ порта просто подстоединить к RxD TxD ? Только что к чему, если можно ?
SCL - RxD и SDA - TxD или SCL - TxD и SDA - RxD ?

Так я чего -то не понял, при таком соединении по этим 2м проводкам будет общение в 1 сторону или в 2 ?

То что ЛПТ будет отправлять а МК принмать по этим 2м проводкам я уверен, а вот наоборот будет пахать ? Мне ведь нужно именно общение туда <-> сюда получить.

[PB_EXPERT]

Для ATmega 8 это ножки
27 PC5 (SDA)
28 PC4 (SCL)

Вот это правда, но второе нет.

может можно эти SCL и SDA с ЛПТ порта просто подстоединить к RxD TxD ?

Я думал что ты знаешь в чём разница между RS232 и I2C, но похоже даже не то что не видишь разницы, но и не знаешь какой принцип обмена инфой используется.
Как тогда собираешься программно реализовывать обмен со стороны компа и МК (если будет софтовая реализация протокола)?
А вообще, лучше используй SPI, как наиболее простой и подходящий вариант в данном случае.
Понадобится 3 вывода.

То что ЛПТ будет отправлять а МК принмать по этим 2м проводкам я уверен, а вот наоборот будет пахать ? Мне ведь нужно именно общение туда <-> сюда получить.

Знаешь как производится обмен инфой по шине I2C?

[rapaks]

Выше просто опечатка была, исправил на ATmega16.

Да новичек я новичек, писал уже выше. Тока начинаю приобщаться к миру электроники.


У меня уже есть схемы для COM и USB которые общаются с МК через RxD и TxD вот нужно было и LPT заставить общаться также.
Но видимо не получится.

Тогда остаеются такие варианты:
1) 3 проводка от ЛПТ для 2х стороннего общения МОСИ МИСО и СЦК.
2) 2 проводка от ЛПТ SDA SCL тока не понял возможен при этом 2х сторонний обмен или нет. Не пинайте, скажи толком, пожалуйста.


А про программирование со стороны ЛПТ буду читать доки которые упоминалеись ранее.
Хотя там наверное тупо передают байты в ДАТА порт а мне ведь понадобится отправить байт последовательно по 2м ножкам и както синхоронизироваться по 3й я хз пока как это сделать.

А программирование МК для работы с ЛПТ в этих случаях я тоже в недоумении.



Эхх сделал бы 1 раз такаю вещь и потмо не пареться а просто МК менять и все они ведь все одинаковые AVRовские.

[YS]

Хотя там наверное тупо передают байты в ДАТА порт а мне ведь понадобится отправить байт последовательно по 2м ножкам и както синхоронизироваться по 3й я хз пока как это сделать.

rapaks, запомните: в LPT НЕТ ни SDA, ни SCL, ни MOSI, ни MISO, ни RXD, ни TXD, ни D+, ни D-, ни чего либо еще - только пины DATA, STATUS и CONTROL. Все остальное - по другому названные эти же пины, результат программной реализации разных протоколов поверх стандартного вывода в регистр DATA. Поэтому "тупо передавать данные в DATA порт" придется в любом случае. Проблему последовательной отправки данных придется решать ВАМ, для этого в LPT для этого НЕТ стандартных средств. Все общение с ним ограничивается записью в регистр данных и контроля и чтением из регистров статуса - это ВСЕ, что дает LPT. Все остальные протоколы - ПРОГРАММНАЯ ЭМУЛЯЦИЯ.

В Вашем случае я сделал бы так:

во-первых, отказался бы от какого-либо стандартного протокола (т.е., сконфигурировал бы RXD и TXD на МК как обычные ножки ввода-вывода). Сделал бы свой, простой, трехпроводной.

Пусть синхронизацию генерит компьютер. Тогда я бы сделал три линии: PCO, PC Out, данные от компьютера (от ПК любой пин DATA, от МК пин настроенный на вход), MCO, MCU Out, данные от МК (от ПК любой пин STATUS, от МК пин, настроенный на выход), CLK, синхронизация от ПК (от ПК любой свободный пин DATA, от МК пин настроенный на вход; целесообразно повесить на это прерывание).

Тогда протокол принимает следующий вид:

Со стороны ПК:

Хотим передать байт?
Выводим очередной бит передаваемого байта в PCO, устанавливаем CLK. Повторяем 8 раз.

Хотим принять байт?
Устанавливаем CLK, очищаем CLK, читаем линию MCO.

Со стороны МК:

Высокий уровень на линии CLK? Читаем линию PCO, записываем очередной бит в принимаемый байт, выводим на ножку MCO очередной бит передаваемого байта. Все вышесказанное очень удобо делать по прерываению, так что, если есть возможность, стоит CLK подключить к какому-нибудь входу внешнего прерывания.

Т.е., в целом получается полный дуплекс:

ПК устанавливает бит данных на выходе, устанавливает высокий уровень на CLK; устанавливает низкий уровень на CLK; читает входную линию - за один период тактовой частоты передано два бита, один от ПК к МК, другой от МК к ПК.

ВСЕ ОПИСАННЫЕ СИГНАЛЫ ГЕНЕРИРУЮТСЯ ПРОГРАММНО, В LPT НЕТ СТАНДАРТНЫХ СРЕДСТВ ПОСЛЕДОВАТЕЛЬНОГО ОБМЕНА.

Вот, в общих чертах так.

[YS]

Программа, работающая на третьем кольце безопасности

Я говорил про прерывание в МК. А ПК не нужны прерываения - в моей модели он сам генерит синхронизацию.

[PB_EXPERT]

Я говорил про прерывание в МК

Я понял, поэтому удалил пост, как неактуальный.

[rapaks]

YS и PB_EXPERT, очень хорошо все объясняете. 75-90% инфы усваиваю, а 10-25% мои тараканы съедают

Да понял что нет стандартного протокала, еще тогда когда только собирался работаь с ЛПТ. Я просто имел ввиду что народ сипользует обычно схему работы с ЛПТ как и программатора "5 проводков" а там эти самы моси мисо, естественно что в лпт их нет поэтому я назваю эти проводки по названию ножек на мк, лан не об этом речь.


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

Зачем переконфигурировать ножки RxD TxD ? У меня по этим ножкам может быть общение с COM или USB.

Может сделать так:

МК:
оставить ножки RxD TxD и через них вести общение по всем этим портам, только для ЛПТ задействовать дополнительно 1 ножку. Тут как я понял с ваших слов это может любая нога настроенная на вход, поэтому для компактности возьму ближайшую к RxD TxD ногу и насрою ее на вход.
А что бы МК мог отличать по какому порту он общается видимо прийдется задействоать еще 1 ногу, ну и для компактности ественно ближайшую. На это ногу я буду подавать логическую единицу (типа +5В) если работаю с ЛПТ, а если нет, то она будет просто висеть в воздухе и МК будет считать что на ней нет +1 а значит она будет общаться по COM или USB.

Таким образом для ATmega8 это будет так:
2 PD0 (RxD) \
для собственно общения по всем портам
3 PD1 (TxD) /
4 PD2 (INT0) - синхронизация с LPT
5 PD3 (INT1) - утанавливается в логическую единицу при работе с LPT


Таким образом для ATmega16 это будет так:
14 PD0 (RxD) \
для собственно общения по всем портам
15 PD1 (TxD) /
16 PD2 (INT0) - синхронизация с LPT
17 PD3 (INT1) - утанавливается в логическую единицу при работе с LPT


LPT:
Задействую ножку 2 для синхронизации и ножку 3 для отправки данных на МК, а ножку 10 для приема данных с МК.

Правильно ли я сформулировал все? можно схему собирать и паять уже, а ?

[YS]

Зачем переконфигурировать ножки RxD TxD ?

Затем, что аппаратный RS-232 протокол не прокатит из-за многозадачности Windows, мешающей отмерять четкие временные интервалы. Надо свой изобретать (по вышеуказанной причине обязательно с синхронизацией), хотя бы такой, как я сказал. И реализовывать его целиком программно.

Переконфигурировать ножки можно непосредственно перед обменом. Нужен нам USB (через USB-RS232 мост, естесственно; на всякий пожарный, RX-TX для USB тоже не прокатит! Нужен либо USB-RS232 мост, либо что-то типа V-USB. Во втором случае ноги тоже конфигурируются не для UART) или COM - настраиваем UART, ноги конфигурируем как RX-TX. Нужен LPT - конфигурируем ноги как GPIO, разрешаем свой обработчик, и вперед...

то она будет просто висеть в воздухе

ВАРНИНГ! Ни в коем случае не оставляйте ее висеть в воздухе, ибо уровень будет неопределен из-за того, что на нее будут садиться помехи (ибо это CMOS-вход с высоким импедансом)! Обязательно подтяните ее резистором (~10k) к нужному уровню! В Вашем случае, видимо, к земле.

И все же, если это не военная тайна, что за такое чудо-устройство Вы делаете, которому нужны сразу три интерфейса?

[rapaks]

Если тупо соединить USB с МК (RxD TxD) то нужено спец прошивку для МК по работе с USB, так? И тогда МК будет только работаь с USB но не сможет работать по этим ногам с COM и тем более с ЛПТ или можно будет както перед началом работы с ЮСБ указать МК что сейчас оан будет работать с этим портом ? Т.е. по умолчанию всегда будет достпна работа с COM, и при желании можно будет укзать МК явно что ей нужно перенастроитсья на порт USB или LPT.


А если USB соединть с МК (RxD TxD) через микруху FT232 то ничего менять не прийдется ? Т.е. МК будет считать что она работат с с обычнм COM портом, так ?


Я правильно рассуждаю ?



Проверьте пожалуйста схемки, которые я набросал.
Для COM порта на микрухе MAX не стал делать развязку на конденсаторы (пока лень, т.к. это всего лишь примерная схемка). Также не стал делать обвесы к микрхе FT232.

[YS]

Если тупо соединить USB с МК (RxD TxD) то нужено спец прошивку для МК по работе с USB, так? И тогда МК будет только работаь с USB но не сможет работать по этим ногам с COM и тем более с ЛПТ или можно будет както перед началом работы с ЮСБ указать МК что сейчас оан будет работать с этим портом ?

Да, не сможет. И это уже не будут RXD и TXD. Названия RXD и TXD относятся только к линиям RS-232 (одним из воплощений которого является COM-порт). Да, для USB нужна спецпрошивка.

Если не нужны сверхскорости, я НЕ рекомендую чистый USB - он слишком сложен в программировании и ресурсоемок для МК, в то время как почти у всех МК есть аппаратная поддержка RS-232. Для большинства задач хватает USB-RS232 мостов на FT232R.

А если USB соединть с МК (RxD TxD) через микруху FT232 то ничего менять не прийдется ?

Да, не придется, см. выше. Но для работы с LPT все равно придется перенастраиваться. Ибо, как мы выяснили, нормальный RS-232 на LPT реализовать не удастся. Хотя, если включить в схему вспомогательный контроллер, который будет принимать данные с LPT по всем линиям DATA и отправлять по линиям STATUS (тактирование можно вести по линиям CONTROL), а с основным МК общаться по тому-же RS-232, можно совершенно унифицировать общение с внешним миром для основного МК. Такой вариант не рассматривается? Какой-нибудь TINY2313/TINY24 вполне пойдет...

P.S.

Для рисования схем есть замечательная программа sPlan...

[rapaks]

Если не нужны сверхскорости, я НЕ рекомендую чистый USB - он слишком сложен в программировании и ресурсоемок для МК, в то время как почти у всех МК есть аппаратная поддержка RS-232. Для большинства задач хватает USB-RS232 мостов на FT232R

Вообще то сверх скорости между ПК и МК не нужны.
А вообще, подскажие пожалуйста: какие скорости можно получить на портах COM, LPT и USB (2 варианта, т.е. низкий и полноценный) при общении ПК с МК (на тех же мегах) ?

Хотя, если включить в схему вспомогательный контроллер, который будет принимать данные с LPT по всем линиям DATA и отправлять по линиям STATUS (тактирование можно вести по линиям CONTROL), а с основным МК общаться по тому-же RS-232, можно совершенно унифицировать общение с внешним миром для основного МК.

Это 2е что пришло мне в голову когда я только начинал это дело. Вообще не хотелось бы задействовать еще 1 МК, меги дороговатые (тут вопрос финансовый и сложно решаемый), хотя тини вроде мелкие и дешевле мег, хмм... Никогда прежде с тини не работал.
Сейчас порылся в инете, нашел это и это, может тогда сделать общение по ЛПТ и ЮСБ через эти тини ?
Т.е. для USB общения не использовать FT232 а использовать TINY как-нибуь, тут надо схемы, у вас есть?

А LPT через TINY это как? Схемка есть?

В принцыпе если ужь пошло так, что для общения по COM использую Max232, для USB - FT232 или возможно TINY, так почему бы и для LPT не задействовать какую-нибудь мелкую промежуточную МК - думаю такой вариант возможен, тока надо не переборщить.

[YS]

какие скорости можно получить на портах COM, LPT и USB (2 варианта, т.е. низкий и полноценный) при общении ПК с МК (на тех же мегах) ?

СОМ-порт стандартный: 128Кбод/с max (поглядел в диспетчере устройств панели управления);

USB-RS232 мост: зависит от микросхемы, на FT232R спокойно можно выжать 1МБод/с, больше не пробовал;

"true"-USB 2.0: low-speed - 1500Кбит/с max.; full-speed - 12Мбит/с max.; hi-speed - 480Мбит/с max.

Однако, уже при применении USB-RS232 мостов начинают сказываться скоростные ограничения самих МК семейства ATmega. Скаежем, для ATmega48 при тактировании 20МГц максимальная скорость UART составляет 2.5MBps (из даташита). Но ведь мы же, наверное, хотим не только принять данные, но и что-то с ними сделать? На это тоже нужно время. Так что, эффективная скорость будет зависить еще и от сложности алгоритма обработки.

Программная реализация USB в МК ATmega очень ресурсоемка и сложна в программировании (даже с применением готовых библиотек это большая проблема). Кроме того, "настоящий" USB сложен в программировании и со стороны ПК.

Мой выбор - USB-RS232 мост. Это оптимальное сочетание скорости и простоты разработки.

может тогда сделать общение по ЛПТ и ЮСБ через эти тини ?

Честно, не вижу в этом смысла. Зачем, когда есть специализированные микросхемы?

А LPT через TINY это как?

Да очень просто. Берем любую тиньку подешевле. Главное, чтобы в ней был UART, внешние прерывания и как минимум два свободных порта. Один порт подключаем к линиям DATA LPT, и конфигурируем его на вход. Четыре ножки другого порта подключаем к линиям STATUS LPT, конфигурируем их как выход. Ножку внешнего прерываения подключаем к удобной линии CONTROL. UART соединяем с UART'ом целевого МК.

Тогда все это будет работать так (ведущим, как и в прошлый раз, пусть будет ПК; он будет генерировать синхронизацию по линии CONTROL):

В прервании по приему UART запоминаем байт из UDR.

Во внешнем прерывании (которое у нас висит на синхронизации от ПК) перекидываем данные из порта, подключенного к линиям DATA, в UDR и запихиваем очередной полубайт ранее запомненного передаваемого байта в половину порта, подключенного к линиям STATUS.

Вот и вся логика. Возможно, при более детальной проработке протокола потребуются еще какие-то управляющие сигналы/команды, может быть, Вы решите организовать буферизацию передачи/приема, но основной алгоритм я вижу таким.

Если удешевление очень важно, то можно сэкономить на ножках МК, расширив порты регистрами 74HC595/74HC165. Но это все несущественно и влияет только на мелочи реализации.

[PB_EXPERT]

Кроме того, "настоящий" USB сложен в программировании и со стороны ПК.

Смотря что за USB устройство.
Например, работа с классами CDC и HID довольно проста.

[rapaks]

У ATtiny24 нет ножек RxD TxD, может вы (YS) ошиблись или я опять чего-то недопнял?
Что не нашел я tiny с uart-ом кроме ATtint2313 (у ней есть ноги эти ноги)?

Почему вы (YS) указали что нужно задействовать только 4 ноги на вывод с ATtiny в LPT ? у LPT же 5 ножек на вход (STATUS) ?Или вы имели ввиду что лучше зайдествовать только 4 ноги и передавать 1 байт за 2 раза четко?


Вот набросал схему (без развязок на питание, типа конденсаторы и т.п.) как и заказывали в sPlan, но мне он чегото не очень нравится, может просто еще не привык.
В схеме указал какие ноги с каким буду соединять напрямую на эти линии как я понял ничего не нужно вешать, т.е. просто тупо соединяем провдками и все.

Сомнение вызывает только ножка у ATtiny2313 PA2 она еще и RESET - можно ли ее трогать на вывод или нет ?
И еще, а обязательно ли для этой ATtiny2313 в моем случае (как переходника между LPT и МК) ставить ей внешний резонатор ?

По цене эта tiny не такая ужь и дешевая чуток меньше mega8 может тогда ее иуспользовать? Хотя mega8 побольше в размерах, т.е. будут лишние ножки да и расположение портов у нее нейдобное. У ATtiny2313 можно задействовать целиком порт B на прием, но к сожалению по частям порты на вывод в LPT, а у ATmega8 вообще все по частям получится. Как лучше то?

В общем проверьте пожалуста эту схему и если не сложно, то подправьте ее как следует.