Опитвам се да накарам Rasberry Pi да говори по RS485 (Raspi-то е мастер). Проблема е че не мога да го накарам да превключва приемане/предаване - _RE и DE входовете на SN75176.
Опитах следните неща
1. софтуерно щракам GPIO пин. В случая не знам кога буферите ще са празни за да изключа предавателя.
1а. опитах tcdrain(fd); което на теория flush-ва буферите. Прблема е че след изпратените 4-5 байта (които отнемат < 400us) тази функция закъснява от 13 до 20 ms. отсреща предаването ще е почнало и свършило 10 пъти за това време.
1б. опитах да изчакам определено време в микрсекунди - usleep(400); работи, но трябва всеки път да броя символите и да правя закъснение. Плюс това понякога се получават непредвидени закъснения. А бе, не е елегантно решение.
2. Опитах да включа hardware flow control. Изкарах RTS на пин P1-11/GPIO17, ALT функция 3. Проблема е че 1. сигнала който излиза от тоя пин не прилича на RTS и 2. CTS пина не е изведен на никое краче - не знам как се държи чипа.

На прикачения файл: жълтия сигнал - TX, синия - RTS. Би трябвало RTS да се вдига само когато има данни. Обаче не става така. Когато отворя порта се бълва едно 0xF8 дето още не знам защо е там - не съм го писал аз. Тогава RTS изглежда да работи. След това има някакъв кратък пик и после RTS въобще го няма. Това, че TX си праща байтовете (а те са 0x04 0x04 '1' 0x05 '2' 0x05 ) говори, че вътрешно CTS си подава нужния сигнал. Защо обаче RTS изведнъж спря да работи?

Търсих в гугъл картинка как трябва да изглеждат контролните сигнали на UART с TTL нива, но не можах да намеря. Ако някой има линк или снимка на сигналите нека я постне.

RTS не беше ли изход. който указва дали приемника е готов да приема? В такъв случай, това което се опитваш да направиш няма голям шанс да стане.... Състоянието му няма да има нищо общо с предаването на данните.

Да, функция на приемащото FIFO е.

Вариант е да сложиш един FTDI с RS485 подръжка на USB-to...

Или хардуерно да управляваш DE от TX с някаква схема тип чакащ мулти вибратор, или с думи прости при падащ фронт по TX, DE да се вдига за колкото се предава един байт, а междувременно, тук обаче следващия който ще предава трябва да изчака поне един байт време, щото DE все още ще е високо... абе куца работа

опа. така е. приемащия сигнал е clear to send. значи като свалиш RTS казваш на другия "пращай". на USB-то на РасПи не искам да разчитам. Като кача мишка пропуска половината кликове когато ЦПУ-то е натоварено. Все едно е софтуерно УСБ-то.
Значи няма да стане това дето го мисля с автоматичния сигнал. Или трябва да броя времето или трябва да сложа някакъв външен чип дето да прави комуникацията.

@t_i_t_o добра идея. Може и да проработи. Ако сложа два стоп бита, а чакащия мултивибратор брои 10 бита (1 старт, 8 дата, 1 стоп) все едно слагам 1 бит закъснение след всеки байт, че да види мултивибратора падащия фронт. Трябва само да измисля самия мултивибратор от какво да го направя. С 555 нямам много опит, но ми се струва че няма да стане защото всяко ниско ниво ще ресетва времето.

оф. изнерви ме. ще му сложа един пик12 с няколко реда програма - при падащ фронт -> прекъсване -> забранявам INT прекъсванията (тези по фронт), пускам таймер и вдигам DE. В прекъсването на таймера пускам external interrupt отново.

Задължително ли ти е да е 485? Що не пуснеш фул дуплекс 422? По принцип фтди-то си го оправя енейбъла автоматично.

То е.

Все пак е по-лесно да пробва УСБ<->РС485 конвертор. И чак ако пак имащ проблеми да си мислиш за пикове. Вариянта с таймер/мултивибратор си има недостатък. Ако предаваш 0ь40 по серийният порт то за този байт ще тригерира два пъти. Веднъж в началото на байта и веднъж на последният бит. От там времето за което драйвера е разрешен ще продължи още около 8 бита след като реално предаването е завършило. И от там вече зависи от избраният протокол. В рамките на тези 8 бита друг не може да започне предаване.

Това е доста добър вариант при който не ти се налага да се управлява от процесора.
http://serwis.avt.pl/manuals/AVT530.pdf

https://www.olimex.com/Products/Modules/Interface/MOD-RS485-ISO/
which cost EURO 16.95 and allow Raspberry Pi to talk to instruments or DMX network

Егати чудото - уж кърти мифки пък един елементарен сериен интерфейс да не може да оправи. И като ще се дават 17 евра за решение, май ще е по-добре да си го направи с пикчето.

пи-то е малко прехвалено. Може би ще пробвам други устройства - от олимекс гледах разни АРМ-та. Иначе ще ми трябва само заради нет-а (ethernet + може би USB WiFi когато се наложи, но съм резервиран към USB-то).

Иначе това дето dumfree предложи (същото като t_i_t_o) е най-разумното решение за сега. 555 взема ниско ниво и прави импулс с поне 70us (една идея повече от 8 бита). Вярно е че за да работи във всички ситуации трябва да държи DE поне 8 бода след края на стоп бита (9 бода от началото на стоп бита).

Пика е пълен провал. при 4 MHz има 16us лаг на прекъсването. Ако обърна на асемблер и взема пик дето има авто-сейв на регистрите при прекъсване и е на по-голяма честота може и да го намаля, но дали ще е достатъчно - прекалено много са усилията за да проверя. Ако ползвам някой CCP модул или подобен дето автоматично вдига някой пин при сигнал на друг пин може и да стане, но май ще ползвам 555.

Прикачил съм картинка - маркерите показват времето (грубо) от началото на стоп бита (жълтия сигнал) до края на DE импулса от 555 (синия). Много шуми щото е на бредборд, а и тези подскачания над 5-те волта в 555 не знам т какво са, но едва ли ще са проблем. Приличат на макс един диоден преход. За диода съм ползвал BAT54 шотки.

А този 555 го намерих "платка" от картон. Едно време (1995-та) си играех с него и понеже нямах бредборд или универсална платка надупчих един картон и вързах кабелите отзад. Още работи гадинката

Има и още един вариат. ДЕ на трансмитера го управляваш от ТХ сигнала. На ТХ на трансмитера подаваш "0". А със съпротивления осигуряваш айдъл състоянието на буса да е 1-ца. Тогава изобщо няма да имаш пролеми с конфликтите на бъса.