Ахтунг! Bray Terminal похоже глючит!

дружусь сейчас с памятью AT24xxx по i2c. i2c потрогал тоже первый раз в жизни, так что дебага хватило с головой(третий день вот идет):-) Наткнулся на такие грабли — когда из Брая выстреливаешь достаточно длинный кусок байт(больше 20ти например) или запуливаешь через него из файла — в половине случаев куда-то кушается начальный кусок посылки, причем не байт-два, а добрая половина. Эта хня убила у меня наверное часа полтора лишнего дебага. Подключился через легальный COMPort Toolkit — все вроде бы ОК. Юзаю Брай всю сознательную электронную жизнь, но более ранние проекты не требовали такого объема трафика, несколько байт туда-сюда и все. И ведь вполне возможно, что из-за его глюков я так и недораскурил SD CARD на асме:-) Если кто-то может подтвердить инфу о небезгрешности Брая — дайте знать, буду искать терминалку получше, ибо КомПортТулкитом пользоваться в качестве терминала мерзковато.

Комментарии (10)

RSS свернуть / развернуть
У меня наблюдался тот-же глюк, только в другую сторону.
При отправке контроллером кучи байт, хвост терялся. Но такое наблюдалось только когда посылал подряд несколько килобайт. Наверное у него буфер приема маленький — не успевает все вывести на экран.
0
дык в том и прикол, что дело не в выводе на экран. Я шлю в контроллер от 2 до 64 байт, контроллер пишет это в AT24c256. И оно пишется именно так, с обрезанным началом, т.е. в контроллер ФАКТИЧЕСКИ уходит кастрированный наполовину пакет.
0
Хм… ясно. буду знать. Спасибо за инфу.
Мой глюк с отправкой тоже можно в пост приписать :)
Вообще можно сделать несколько постов по программам (АВР студия, протеус, т.д) и вести список багов.
0
мне что-то подсказывает, что трабл может крыться где-то на уровне драйверов и кусков Винды, поэтому у кого-то может нормально работать. Но поскольку до Марка Руссиновича еще очень далеко(да и не надо, наверное:-) — это так и останется предположением. Добавлю просто, что COM-порт на ft232rl
0
А на железном ком-порте нет возможности проверить?
0
Стоит отметить, что у фт-шки свои буферы. Например, если не открыть ее ком-порт на компе, то в демке пинборда (прога регулярно отсылает в уарт результат ацп) через несколько секунд после включения питания Tx диод перестает мигать — т.е. наевшаяся фт-шка перестает принимать данные.
0
Может ты их просто прожевать на таргете не успеваешь? У меня брэй нормально отправляет крупный кекс уартом, при том, что обрабатывается он довольно медленно (в тесте специально слоупочил 50мс после каждой строки) — юзаю буферизованный прием с XON/XOFF управлением.
Как вариант — может ты забыл включить в брее нужный режим управления потоком?
0
  • avatar
  • Vga
  • 14 марта 2011, 16:42
неа. У меня без управления потоком, но тоже буферизовано. Не «жуется» ничего вовсе — просто кладется в буфер. Да и объем всего-то 64 байта(страница AT24c256). Плюс происходит это не через раз даже, а через несколько раз что ли, бессистемно. КомпортТулкит же четко отрабатывает.
0
Ну, если буфер кольцевой и не успевает прожеваться — то при переполнении как раз будет теряться начало. Я правда бреем мало пользовался, но проблем особых не замечал. Разве что подвисает он, если ком-порт не спешить сжевать отосланные данные (скажем, когда передача выключена flow control'ом). И, что хуже, попытка отослать данные в отключенную FTDI иногда вешает комп насмерть. Но это уже не терминалки вина.
Если глючный — жаль, он удобный. Хотя терминалок до черта. Только у меня стоят Bray, wTerm, HyperTerm, PuTTY, mikroElectronica USART Terminal и возможно еще какие-то в составе других сред)
0
буфер линейный, прога на асме с чистого листа, никаких стандартных конструкций:-)
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.