Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Успеет. Он просто не сможет опоздать :) - достаточно держать SCL в 0 все время, когда слейв занят чем то другим, а не мониторингом шины. 1. Вы так сами пробовали? (при реализации софт слэйва) 2. Вот считал слэйв состояние линий, что дальше прикажете делать? сразу SCL опускать? Или на второе чтение сразу-же выходить? А если между этими двумя чтениями прерывание выскочит? Ну не ориентировался I2C на софтовую реализацию слэйва исключительно мастер. Ваш вариант с возвратом такта имеет точно такой же недостаток. Это не недостаток это достоинство, когда скорость получается максимально возможной из "возможностей" двух сторон. в протоколе abd квант времени, нужный для обработки протокола можно выделять абсолютно в любой удобный момент времени (как на мастере так и на слэйве), не надо на этот квант запрещать прерывания, его можно вызывать и в IDLE. И ни одного пропущенного бита не будет. И скорость получится максимально возможной без искусственных ограничений. может и 10Мбит получиться может и больше. Он разрабытывался для межмикроконтроллерного GPIO-обмена все другие протоколы не обладают такой особенностью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vesago 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба В качестве инструмента предлагаю известный клон аврисп на меге8 + подрихтованную Гудвином прошивку. После прошивки подключаем терминалку на скорости 115200 и смотрим отладочный вывод из target Функции в target: void init_debug(void) { PORTB=0x00; DDRB=0x38; PORTB.3=1; // сигнал MOSI программатора - используется как SS delay_ms(1); PORTB.3=0; delay_ms(1); } void putchar( char c) { unsigned char n; for (n=0;n<8;n++) { if (c & 1) PORTB.4=1; // сигнал MISO программатора - данные else PORTB.4=0; PORTB.5 =0; // сигнал SCK программатора - clock delay_us(100); PORTB.5 =1; delay_us(100); c=c>>1; } } Пардон, посмотрел выше уже есть аналогичное решение.. avrusb500_1.5_debugout.rar Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба видимо мы говорим о разном. я говорил про полный двунаправленный flow control. Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал. передать импульс легко, согласен. а вот его софтово поймать - сложнее. Если мы опять-же, говорим о терминале, то ловить придется терминальной стороне, а там все ресурсы отдаются только обслуживанию интерфейса, да и аппаратная поддержка может присутствовать. Ну а передача в сторону отлаживаемого устройства может быть уже по другому протоколу, с много меньшей скоростью, с квитированием каждого бита..... разжевать почему? Пока получается наоборот :). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал. Согласен. Если ограничиться только терминалом, то да. Может подойти и 1wire и i2c при наличии аппаратной поддержки со стороны теминала. Однако стоит вспомнить предысторию вопроса, то есть много уже готорых программаторов, в которой это поддержки уже нет =(. Большой популярностью обладают компьюnерные gpio программаторы (LPT, ftdichip bitbang и подобные). Если конструктивно, то кто поделится с общественностью своим 1wire или i2c решением? Согласен даже провести тесты, что окажется быстрее/проще/надёжнее/удобнее. Если мы опять-же, говорим о терминале, то ловить придется терминальной стороне, а там все ресурсы отдаются только обслуживанию интерфейса, да и аппаратная поддержка может присутствовать. Ну а передача в сторону отлаживаемого устройства может быть уже по другому протоколу, с много меньшей скоростью, с квитированием каждого бита..... Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать... Дамп памяти скинуть, калибровочные константы получить, серийник, в тестовый режим перевестись.... Я закладывался и на такое тоже. А вам есть что предложить для этого? =) Пока получается наоборот :). тоже полезно =) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать... Получайте, только с меньшей (если делать простейшие реализации) скоростью, в основном определяемой вашим-же отлаживаемым устройством. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Получайте, только с меньшей (если делать простейшие реализации) скоростью, в основном определяемой вашим-же отлаживаемым устройством. 1-wire отпадает т.к. надо задействовать таймер. До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба 1-wire отпадает т.к. надо задействовать таймер. До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером? Я хоть слово говорил, что надо эмулировать 1-wire или i2с? Это просто примеры решения определенного класса задач. Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства. При этом сложность программно-аппаратных решений на стороне терминала значения не имеет, а на стороне отлаживаемого устройства достаточно ногомахания и работы по опросу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба ... Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства. ПодЕлитесь решением? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба ПодЕлитесь решением? Одним из многих? Легко. Про передачу в сторону терминала уже писал. Про передачу в сторону устройства: Устройство либо по запросу ввиде очень длинного засаживания линии терминалом, либо вообще все время, передает поминаемые ранее максимально короткие импульсы. В ответ на эти импульсы терминал может затянуть или не затянуть этот импульс на линии. Соответственно, передавая таким образом В ТЕМПЕ ДИКТУЕМОМ устройством свои нолики и единички. В случае, если используется непрерывный поток импульсов, фрейм передаваемый с терминала должен начинаться с затягивания импульса. Для работы по запросу, логично использовать запрос не для передачи 7/8 бит, а для передачи фрейма, концом которого является, например, комбинация из восьми незатянутых импульсов. Вот такой один из первых пришедших у голову вариантов не требующих, вопреки Вашему утверждению, таймеров, прерываний и прочего на стороне устройства. Думаю, что если объявите конкурс, то получите еще много работоспособных идей и для однопроводки. А уж для двухпроводки, когда можно использовать явное тактирование, и говорить нечего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Одним из многих? Легко. ..... сразу возникает первый вопрос: устройство задавило линию: как "терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба сразу возникает первый вопрос: устройство задавило линию: Устойство НЕ давит линию, оно передает, когда хочет и может. "терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит? Если речь идет о выдаче устройством строба, то терминал должен знать, идет сейчас фрейм от устройства или он уже закончился (передан байт и после них не было длинного импульса начала нового байта, или при многобайтнно-битной передаче получен, например, нулевой байт ) и это готовность устройства к считыванию бита. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Если речь идет о выдаче устройством строба, то терминал должен знать, идет сейчас фрейм от устройства или он уже закончился (передан байт и после них не было длинного импульса начала нового байта, или при многобайтнно-битной передаче получен, например, нулевой байт ) и это готовность устройства к считыванию бита. Хорошо. Фрэйм закончился. Терминал получает "строб". Так это новый бит от устройства или предложение начать передачу для терминала? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Так это новый бит от устройства или предложение начать передачу для терминала? Мне казалось,что я все разжевал :(. Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Мне казалось,что я все разжевал :(. Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт. Видимо не всё. Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс". Что делать терминалу дальше? У терминала есть данные, для отсылки. Что делать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 24 февраля, 2010 Опубликовано 24 февраля, 2010 · Жалоба Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс". Он может это узнать. Длительность короткого импульса определяемого быстродействием контроллера устройства ему известна, она-же соответствует времени через которое устройство просканирует наличие затягивания импульса терминалом. Значит у него есть этот интервал времени для разборок с длинной импульса. Можно наложить и протокольные ограничения, например, после передачи фрейма устройством, оно должно выдать не менее одного короткого строба в качестве разрешения передавать терминалу. Кроме того, подобные конфликты легко разрешаются, ибо длинный длинный импульс от устройства это действительно длинный гарантированно превышающий два-три такта контроллера, а длинный импульс от терминала, это всего 2-3 такта контроллера устройства. Посему, терминал может смело засаживать своей передачей линию при ловле переднего фронта - если со стороны устройства будет строб, то терминал сняв свой 2-3 тактовый импульс увидит снятие и сможет продолжить передачу. Если сняв через 2-3 такта свой импульс терминал увидит продолжающийся встречный импульс от устройства, то должен уступить и заняться приемом. Видимо не всё. Достаточно вариантов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться