Jump to content

    
Sign in to follow this  
demiurg_spb

debug console over AVR-ISP

Recommended Posts

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
видимо мы говорим о разном. я говорил про полный двунаправленный flow control.

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

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

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

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

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

Share this post


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

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

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

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

 

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

 

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

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

Share this post


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

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
1-wire отпадает т.к. надо задействовать таймер.

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

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

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

Share this post


Link to post
Share on other sites
...

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

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

Share this post


Link to post
Share on other sites
ПодЕлитесь решением?

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

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

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

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

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

Share this post


Link to post
Share on other sites
Одним из многих? Легко.

.....

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

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

Share this post


Link to post
Share on other sites
сразу возникает первый вопрос:

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

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

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

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

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
Так это новый бит от устройства или предложение начать передачу для терминала?

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

Share this post


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

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

Share this post


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

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

 

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this