-
- Если не склероз, эхо на LIN необходимо, чтобы определять коллизии. Щетаю, что вам надо не подавлять его, а всячески пользовать. И ориентироваться на RXNE/IDLE вместо TXE/TC. Ну и камень конкретный указать, да еще и номера USART на нем, они часто разные. - LightElf(03.07.2020 10:12)
- Любое эхо можно отсечь. На то оно и эхо. il-2(635 знак., 03.07.2020 07:55)
- В общем случае от эха принципиально не избавиться. Такая же
проблема как с модемом (когда ATE1). Ты должен понимать протокол и
игноровать эхо. Трюки с запретом приёма сомнительные, т.к. требуют
исключительно точного соблюдения таймингов (на МК можно
извернуться, но и то с ньюансами), а если предположить "резиновый"
fifo-буфер на передачу и приём (как это происходит с типовой
операционкой), то никак. - fk0(02.07.2020 23:39)
- девайс работает в качестве
шлюхашлюза, в идеале пришел байт тутже его в фифо на на выход в сопредельный интерфейс! Вот в чем гимор - Aleksey_75(02.07.2020 23:45)- Алгоритм работы: fk0(1070 знак., 03.07.2020 00:18)
- ха! Ха! а вы лин хорошо знаете ?? мастер выставляет break, sinc,
id, а дальше или сквозняк либо подсовываем свои данные! фифо идет в
жо! передача вся побайтовая - Aleksey_75(03.07.2020 00:25)
- в тот то и дело когда байт уходит в "другой интерфейс" приходит
эхо, и тот же байт уходит в исходный интерфейс! Вот и вопрос как с
этим бороться - Aleksey_75(03.07.2020 00:28)
- Когда работает передача в LIN -- это состояние 3, где "отбрасывание
принятых из LIN данных". Разумеется я подразумеваю буфера
приёма-передачи у каждого интерфейса. От десятков до тысяч байт, в
зависимости от особенностей ОС и МК. Конечный автомат с 4-мя
состояниями работает в userspace. - fk0(03.07.2020 00:32)
- какое 3 состояние, девайс в режиме шлюза, зашло с одной стороны
выплюнь с другой и наоборот. Вопрос не алгоритме работы , вопрос
как с эхом бороться!? ибо когда выдал данные , пришло эхо, и какбе
девайс его должен перебросить, но так низя, в бесконечный
отсылаемый мусор все уйдет - Aleksey_75(03.07.2020 00:49)
- Хватит тупить. Я тебе алгоритм расписал. Полудуплексный. С ним эха
не будет. Будет потеря данных, когда приём натыкается на передачу.
Но ведь LIN и так полудуплексный. Ещё раз, ключевое слово
ПОЛУДУПЛЕКС. Или приём, или передача. Не на уровне байтов, на
уровне пакетов. На уровне байтов не получится. - fk0(03.07.2020 00:58)
- что бухой чтоль ? эхо придет всегда, при любой моей отправке...
Видос с терминала показать ??? Я спрашиваю как с эхо похерить , ты
мне за алгоритм - Aleksey_75(03.07.2020 01:10)
- Алгоритм примет символы с эхом и выкинет их. - fk0(03.07.2020 01:41)
- что бухой чтоль ? эхо придет всегда, при любой моей отправке...
Видос с терминала показать ??? Я спрашиваю как с эхо похерить , ты
мне за алгоритм - Aleksey_75(03.07.2020 01:10)
- Хватит тупить. Я тебе алгоритм расписал. Полудуплексный. С ним эха
не будет. Будет потеря данных, когда приём натыкается на передачу.
Но ведь LIN и так полудуплексный. Ещё раз, ключевое слово
ПОЛУДУПЛЕКС. Или приём, или передача. Не на уровне байтов, на
уровне пакетов. На уровне байтов не получится. - fk0(03.07.2020 00:58)
- какое 3 состояние, девайс в режиме шлюза, зашло с одной стороны
выплюнь с другой и наоборот. Вопрос не алгоритме работы , вопрос
как с эхом бороться!? ибо когда выдал данные , пришло эхо, и какбе
девайс его должен перебросить, но так низя, в бесконечный
отсылаемый мусор все уйдет - Aleksey_75(03.07.2020 00:49)
- Когда работает передача в LIN -- это состояние 3, где "отбрасывание
принятых из LIN данных". Разумеется я подразумеваю буфера
приёма-передачи у каждого интерфейса. От десятков до тысяч байт, в
зависимости от особенностей ОС и МК. Конечный автомат с 4-мя
состояниями работает в userspace. - fk0(03.07.2020 00:32)
- в тот то и дело когда байт уходит в "другой интерфейс" приходит
эхо, и тот же байт уходит в исходный интерфейс! Вот и вопрос как с
этим бороться - Aleksey_75(03.07.2020 00:28)
- ха! Ха! а вы лин хорошо знаете ?? мастер выставляет break, sinc,
id, а дальше или сквозняк либо подсовываем свои данные! фифо идет в
жо! передача вся побайтовая - Aleksey_75(03.07.2020 00:25)
- Алгоритм работы: fk0(1070 знак., 03.07.2020 00:18)
- девайс работает в качестве
- 1. Сталкивался еще на токовой петле. Нет красивого решения, эхо в
шлюзе может быть подавлено только для пакетного обмена, если
предусмотрен тайм-аут с запасом. 2. Сталкивался недавно в
оптическом канале см ссылку, но проект заглох, и хз как придется
выпутываться. - VLLV(02.07.2020 20:44)
- Если сделать аккуратно, то наверняка можно достаточно точно ловить
временные метки отправки и приёма байтов и вычислять по ним, кто
кому эхо или нет. - SciFi(02.07.2020 23:17)
- ну да, или тайминги или "левые заходы" в RXNE Aleksey_75(589 знак., 02.07.2020 23:35)
- Ну вот, есть кусок кода, и сразу видно где косяк :-) il-2(377 знак., 03.07.2020 08:11)
- ну да, или тайминги или "левые заходы" в RXNE Aleksey_75(589 знак., 02.07.2020 23:35)
- Ндя ((( драйверосотворители уроды )) Здесь похоже красивым решением
будет только аппаратное, рубить линию rx на время передачи - Aleksey_75(02.07.2020 20:59)
- TXE и TC нельзя трактовать как "отправка последнего байта" BlackMorda(730 знак., 02.07.2020 21:16)
- "TC (в типовом случае) устанавливается в середине стоп бита
"последнего" байта." - тогда бы были проблемы с RS485 без растяжки
линии, поскольку очень часто направление переключают именно по TC - Andreas(02.07.2020 22:21)
- ТС все тоже самое , после сработки вываливаются данные в приемный
регистр! Там все правильно два "виртуальных регистра" с одного
данные задвигаются с RX с другого выдвигаются в TX, вопрос как
получить доступ к этим регистрам, тогдаб все было просто, пиши
0x1FF выходной и игнорь его ибо данные 8 бит - Aleksey_75(02.07.2020 22:30)
- Я просто к тому, что очень врядли ТС срабатывает в середине
стопбита, иначе у RS485 обрезался бы стопбит при передаче. А по
теме почему бы просто не выкидывать первый байт после окончания
передачи. Это если стабильно идет прерывание RXC уже после ТС. - Andreas(02.07.2020 23:22)
- а оно прям стабильно идет! там дело немного в другом, насколько я
понял из доков , сначала выставляется TXE если на него не было
реакции в течении 10 тактов выставляется TC, но смысл в том что в
сдвиговый регистр данные вдвигаются с задержкой tbr, так что RXNE
будет в любом случае с отставанием в tbr от TXE... В общем в одно
стороны хорошо что так четко можно реагировать на приходы данных, а
вот драйверостроители лютые редиски! - Aleksey_75(02.07.2020 23:30)
- Индусские говнокодеры, конечно, заслуживают критику, но не в этот
раз. - SciFi(02.07.2020 23:34)
- ))) жги!!! Aleksey_75(3 знак., 02.07.2020 23:36, ссылка)
- Индусские говнокодеры, конечно, заслуживают критику, но не в этот
раз. - SciFi(02.07.2020 23:34)
- а оно прям стабильно идет! там дело немного в другом, насколько я
понял из доков , сначала выставляется TXE если на него не было
реакции в течении 10 тактов выставляется TC, но смысл в том что в
сдвиговый регистр данные вдвигаются с задержкой tbr, так что RXNE
будет в любом случае с отставанием в tbr от TXE... В общем в одно
стороны хорошо что так четко можно реагировать на приходы данных, а
вот драйверостроители лютые редиски! - Aleksey_75(02.07.2020 23:30)
- Я просто к тому, что очень врядли ТС срабатывает в середине
стопбита, иначе у RS485 обрезался бы стопбит при передаче. А по
теме почему бы просто не выкидывать первый байт после окончания
передачи. Это если стабильно идет прерывание RXC уже после ТС. - Andreas(02.07.2020 23:22)
- ТС все тоже самое , после сработки вываливаются данные в приемный
регистр! Там все правильно два "виртуальных регистра" с одного
данные задвигаются с RX с другого выдвигаются в TX, вопрос как
получить доступ к этим регистрам, тогдаб все было просто, пиши
0x1FF выходной и игнорь его ибо данные 8 бит - Aleksey_75(02.07.2020 22:30)
- USART_RQR_RXFRQ это где его искать ? в RM о нем ни слова ! Касаемо
чтения DR я уже говорил не помогает, два раза после чтения и
влетаем в RNE - Aleksey_75(02.07.2020 21:25)
- USART_RQR_RXFRQ есть и в IAR и в Keil. BlackMorda(275 знак., 02.07.2020 21:41)
- Я конечно люто извиняюсь! Но ни IAR ни Keil без библиотек вообще не
знают ни об одном регистре! В доках на МК нет ни слова о
USART_RQR_RXFRQ. Aleksey_75(208 знак., 02.07.2020 21:58)
- Нет нужды извиняться. Все регистры живут в референсном мануале. Вы
не потрудились указать марку своего МК, поэтому извольте
заслушивать от доброжелателей не относящиеся к делу советы про
другие МК. - SciFi(02.07.2020 23:07)
- тут все из рефренса Aleksey_75(3 знак., 02.07.2020 23:08, ссылка)
- Для STM32L072 BlackMorda(1879 знак., 02.07.2020 22:50)
- у мну нет регистра USART_RQR от слова совсем Aleksey_75(1 знак., 02.07.2020 23:07, картинка)
- Нет нужды извиняться. Все регистры живут в референсном мануале. Вы
не потрудились указать марку своего МК, поэтому извольте
заслушивать от доброжелателей не относящиеся к делу советы про
другие МК. - SciFi(02.07.2020 23:07)
- Я конечно люто извиняюсь! Но ни IAR ни Keil без библиотек вообще не
знают ни об одном регистре! В доках на МК нет ни слова о
USART_RQR_RXFRQ. Aleksey_75(208 знак., 02.07.2020 21:58)
- USART_RQR_RXFRQ есть и в IAR и в Keil. BlackMorda(275 знак., 02.07.2020 21:41)
- "TC (в типовом случае) устанавливается в середине стоп бита
"последнего" байта." - тогда бы были проблемы с RS485 без растяжки
линии, поскольку очень часто направление переключают именно по TC - Andreas(02.07.2020 22:21)
- TXE и TC нельзя трактовать как "отправка последнего байта" BlackMorda(730 знак., 02.07.2020 21:16)
- Если сделать аккуратно, то наверняка можно достаточно точно ловить
временные метки отправки и приёма байтов и вычислять по ним, кто
кому эхо или нет. - SciFi(02.07.2020 23:17)