Перейти к содержанию
    

Успеет. Он просто не сможет опоздать :) - достаточно держать SCL в 0 все время, когда слейв занят чем то другим, а не мониторингом шины.

1. Вы так сами пробовали? (при реализации софт слэйва)

2. Вот считал слэйв состояние линий, что дальше прикажете делать? сразу SCL опускать? Или на второе чтение сразу-же выходить? А если между этими двумя чтениями прерывание выскочит? Ну не ориентировался I2C на софтовую реализацию слэйва исключительно мастер.

Ваш вариант с возвратом такта имеет точно такой же недостаток.

Это не недостаток это достоинство, когда скорость получается максимально возможной из "возможностей" двух сторон.

 

в протоколе abd квант времени, нужный для обработки протокола можно выделять абсолютно в любой удобный момент времени (как на мастере так и на слэйве), не надо на этот квант запрещать прерывания, его можно вызывать и в IDLE. И ни одного пропущенного бита не будет. И скорость получится максимально возможной без искусственных ограничений. может и 10Мбит получиться может и больше. Он разрабытывался для межмикроконтроллерного GPIO-обмена все другие протоколы не обладают такой особенностью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В качестве инструмента предлагаю известный клон аврисп на меге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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

видимо мы говорим о разном. я говорил про полный двунаправленный flow control.

Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал.

передать импульс легко, согласен. а вот его софтово поймать - сложнее.

Если мы опять-же, говорим о терминале, то ловить придется терминальной стороне, а там все ресурсы отдаются только обслуживанию интерфейса, да и аппаратная поддержка может присутствовать. Ну а передача в сторону отлаживаемого устройства может быть уже по другому протоколу, с много меньшей скоростью, с квитированием каждого бита.....

разжевать почему?

Пока получается наоборот :).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал.

Согласен. Если ограничиться только терминалом, то да. Может подойти и 1wire и i2c при наличии аппаратной поддержки со стороны теминала. Однако стоит вспомнить предысторию вопроса, то есть много уже готорых программаторов, в которой это поддержки уже нет =(. Большой популярностью обладают компьюnерные gpio программаторы (LPT, ftdichip bitbang и подобные).

Если конструктивно, то кто поделится с общественностью своим 1wire или i2c решением? Согласен даже провести тесты, что окажется быстрее/проще/надёжнее/удобнее.

Если мы опять-же, говорим о терминале, то ловить придется терминальной стороне, а там все ресурсы отдаются только обслуживанию интерфейса, да и аппаратная поддержка может присутствовать. Ну а передача в сторону отлаживаемого устройства может быть уже по другому протоколу, с много меньшей скоростью, с квитированием каждого бита.....

 

Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать... Дамп памяти скинуть, калибровочные константы получить, серийник, в тестовый режим перевестись.... Я закладывался и на такое тоже. А вам есть что предложить для этого? =)

 

Пока получается наоборот :).

тоже полезно =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать...

Получайте, только с меньшей (если делать простейшие реализации) скоростью, в основном определяемой вашим-же отлаживаемым устройством.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Получайте, только с меньшей (если делать простейшие реализации) скоростью, в основном определяемой вашим-же отлаживаемым устройством.

1-wire отпадает т.к. надо задействовать таймер.

До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1-wire отпадает т.к. надо задействовать таймер.

До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером?

Я хоть слово говорил, что надо эмулировать 1-wire или i2с? Это просто примеры решения определенного класса задач.

Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства. При этом сложность программно-аппаратных решений на стороне терминала значения не имеет, а на стороне отлаживаемого устройства достаточно ногомахания и работы по опросу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

...

Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства.

ПодЕлитесь решением?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ПодЕлитесь решением?

Одним из многих? Легко.

Про передачу в сторону терминала уже писал. Про передачу в сторону устройства:

Устройство либо по запросу ввиде очень длинного засаживания линии терминалом, либо вообще все время, передает поминаемые ранее максимально короткие импульсы. В ответ на эти импульсы терминал может затянуть или не затянуть этот импульс на линии. Соответственно, передавая таким образом В ТЕМПЕ ДИКТУЕМОМ устройством свои нолики и единички. В случае, если используется непрерывный поток импульсов, фрейм передаваемый с терминала должен начинаться с затягивания импульса. Для работы по запросу, логично использовать запрос не для передачи 7/8 бит, а для передачи фрейма, концом которого является, например, комбинация из восьми незатянутых импульсов.

Вот такой один из первых пришедших у голову вариантов не требующих, вопреки Вашему утверждению, таймеров, прерываний и прочего на стороне устройства.

Думаю, что если объявите конкурс, то получите еще много работоспособных идей и для однопроводки. А уж для двухпроводки, когда можно использовать явное тактирование, и говорить нечего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Одним из многих? Легко.

.....

сразу возникает первый вопрос:

устройство задавило линию: как "терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

сразу возникает первый вопрос:

устройство задавило линию:

Устойство НЕ давит линию, оно передает, когда хочет и может.

"терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит?

Если речь идет о выдаче устройством строба, то терминал должен знать, идет сейчас фрейм от устройства или он уже закончился (передан байт и после них не было длинного импульса начала нового байта, или при многобайтнно-битной передаче получен, например, нулевой байт )

и это готовность устройства к считыванию бита.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если речь идет о выдаче устройством строба, то терминал должен знать, идет сейчас фрейм от устройства или он уже закончился (передан байт и после них не было длинного импульса начала нового байта, или при многобайтнно-битной передаче получен, например, нулевой байт )

и это готовность устройства к считыванию бита.

Хорошо. Фрэйм закончился. Терминал получает "строб". Так это новый бит от устройства или предложение начать передачу для терминала?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так это новый бит от устройства или предложение начать передачу для терминала?

Мне казалось,что я все разжевал :(. Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Мне казалось,что я все разжевал :(. Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт.

Видимо не всё. Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс". Что делать терминалу дальше? У терминала есть данные, для отсылки. Что делать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс".

Он может это узнать. Длительность короткого импульса определяемого быстродействием контроллера устройства ему известна, она-же соответствует времени через которое устройство просканирует наличие затягивания импульса терминалом. Значит у него есть этот интервал времени для разборок с длинной импульса. Можно наложить и протокольные ограничения, например, после передачи фрейма устройством, оно должно выдать не менее одного короткого строба в качестве разрешения передавать терминалу.

 

Кроме того, подобные конфликты легко разрешаются, ибо длинный длинный импульс от устройства это действительно длинный гарантированно превышающий два-три такта контроллера, а длинный импульс от терминала, это всего 2-3 такта контроллера устройства. Посему, терминал может смело засаживать своей передачей линию при ловле переднего фронта - если со стороны устройства будет строб, то терминал сняв свой 2-3 тактовый импульс увидит снятие и сможет продолжить передачу. Если сняв через 2-3 такта свой импульс терминал увидит продолжающийся встречный импульс от устройства, то должен уступить и заняться приемом.

Видимо не всё.

Достаточно вариантов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...