ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
23 ноября
841759
Adept (18.05.2018 14:08 - 17:32, просмотров: 550)
или лыжи не едут или.... проясните, плз, кто понял по ДШ, по поводу RN4677/78 совершенно непонятное описание состояний BT-модуля RN4678 в обеих ДШ - противоречивые данные RN4677 стр.7 табл.1.4 RN4678 стр.8 таб.2.4 по факту, на обеих модулях: включение питания: p0_4=L; p1_5=H сопряжение по BT (данные при этом ходят в терминале в обе стороны): p0_4=L; p1_5=L ?????? :(( растолкуйте, плз термины из таблицы. Никак не вкурю, как их понимать Не было бы надобности вникать, да вот как-то странно ведёт себя модуль RN47678 Раньше использовал 4677, но данные ходили только из девайса (из модуля) на хост, и изредка - короткие посылки в него. всё работало теперь сценарий поменялся, - в модуль надо засылать побольше данных (посылки по 50-100 байт). Так он, собака глючит при этом (4677 в наличии нет, на нём уже и не проверить. У меня сделан аппаратный контроль состояния по этим самым ногам(p0_4; p1_5) и забабахана индикация состояния БТ (сопряжено или нет), но самое главное - на этом построена процедура реанимации модуля. У 4677 была фича, если нет БТ-конекта, и пытаешься впихнуть ему в УАРТ данные, то на 5-10 байте он "встаёт колом" и помогает только ресет. Собственно на отслеживании статуса и построена защита (мониторим состояние и текущий статус устройства: если находимся в режиме передачи данных и вдруг теряется коннект, то перестаём слать данные и делаем ресет). Так вот 4678, собака, иногда (когда начинаешь бомбить его данными), теряет коннект (т.е. на p0_4 проскакивает на 10-20mS единичка, ну и я ессно, при этом ресечу модуль (при этом коннект естественно теряется, если ресет не делать, то коннект не рвётся, просто через пару секунд статус модуля опять p0_4=L; p1_5=L :(( вот такая бЯда :((( хочется разобраться с этими сигналами статуса, но ДШ написан идиотами (или я идиот??) ------------------- Немного подразобрался: Эмпирическим путём (с помощью осцилла и терминала :) было установлено, что на время приёма пакета сигнал "P04/STATUS_IND_2 (ST1)" принимает значение "1" (время равно длине пакета +1..5mS) И где про это, скажите в мануале написано, а???? :P (негодую!!) т.о. на время приёма данных модулем от хоста, его состояние устанавливается как "BlueTooth_Access (2)" (по документации на RN4677) теперь понятно, как скорректировать монитор состояний, чтобы не ресетился модуль :)) Но , однако описание состояний вгоняет меня в ступор - никак не пойму, что же сказано в таблицах для 4677 и 4678 :( ну кто так пишет мануалы, дебилы индусы, бля! ----------------------- В итоге вот так подкорректировал дефайны: ;сигналы аппаратных ног индикации состояния (взято из фирменной документации на модуль RN4677) ;" TABLE 1-4: STATUS INDICATION ;P04/STATUS_IND_2 (ST1) P15/STATUS_IND_1 (ST0) ; H H ;(3) Power default/Shutdown state ; H L ;(2) Access state ; L H ;(1) Link state (no UART data being transmitted) ; L L ;(0) Link state (UART data being transmitted) #define RN4677_ST1 bit1 ;P04/STATUS_IND_2 (ST1) #define RN4677_ST1_bit 1 #define RN4677_ST0 bit0 ;P15/STATUS_IND_1 (ST0) #define RN4677_ST0_bit 0 #define BlueTooth_ShutDown 3 ;Power default/Shutdown state #define BlueTooth_Access 2 ;Access state //есть сопряжение, принимается пакет данных по BT #define BlueTooth_LinkNoPair 1 ;Link state (no UART data being transmitted) //нет сопряжения (готовность к сопряжению) #define BlueTooth_LinkPair 0 ;Link state (UART data being transmitted) //есть сопряжение, готовность к трансферу данных ??? вот кто мне объяснит, как это коррелирует с описанием состояний для 4678,в ДШ которого написано:
image
...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)