PIC18 & RS-485 support

VC> Читаю на первых страницах даташитов на ПИК18 следующее: VC> Peripheral Features: VC> Two Addressable USART modules: VC> - Supports RS-485 and RS-232

VC> Hу, думаю, наконец-то добавили нормальную поддержку для организации RS-485 и VC> не надо будет опрашивать бит TRMT (опустошения сдвигового регистра) для VC> определения момента переключения направления, уж больно это неудобно, по VC> прерыванию было бы намного кузявей. Хех, размечтался...

А ты по прерыванию и работай - не опрашивай этот бит. Посылаешь последний байт, запускаешь таймер, и по его отработке переключаешься. Этот же таймер задействуй для фиксации конца кадра посылки от мастера (Модбас)

VC> Читаю главу "ADDRESSABLE UNIVERSAL SYNCHRONOUS ASYNCHRONOUS RECEIVER VC> TRANSMITTER (USART)", а там всё по старому, что и было у 16- х пиков, и VC> никаких слов про Supports RS-485. Мож не там читаю? Коллеги, подскажите плиз.

а в чем, по твоему, должна заключаться эта поддержка? камню все пофигу, что у него на юарте - 232, 422, 485

RA>> А ты по прерыванию и работай - не опрашивай этот бит. Посылаешь RA>> последний байт, запускаешь таймер, и по его отработке переключаешься. RA>> Этот же таймер задействуй для фиксации конца кадра посылки от мастера RA>> (Модбас) VC> Это понятно. Hо как-то несистемно получается. Есть периферийный модуль USART VC> со своими прерываниями, а к нему надо ещё модуль прикручивать. Под каждую VC> скорость надо прикидывать это время для загрузки дополнительного таймера. VC> Сменил скорость, частоту кварца, не забудь таймер пересчитать.

А фиг его знает, что они этот недостаток таскают из серии в серию. Да и программирование а-ля I2C (ножки еще одной, что-ли, жалко?)- чего бы не перейти в нормальный SPI - и скорости, и удобство в разы возросло бы