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

Программная реализация интерфейса

Последовательный интерфейс. По 1 проводу идут данные, по 2 проводу - синхросигнал (Частота 1,25 МГЦ).

Слово данных состоит из 22 разрядов -> 1...6 - адрес (1-младший бит адреса, 6 - старший бит адреса) + 7...22 - данные (7 - младший, 22 - старший).

А почему бы не использовать для этого SPI? И что с этим словом делать дальше?

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


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

Это если у Вас скорость порта заведомо выше скорости поступления данных, но у нас как раз наоборот(1.25Mbit ! против даже 1Мbit c FT-232). Прийдется организовывать FIFO, и по прерываниям с UART забирать данные, либо полингом смотреть статус UART в основном цикле, а это несколько больше одного out :)

Про конкретную скорость UART пока речи не было. Никто не мешает, например, отдавать байт в UART на каждый второй собранный входной байт. Главное, чтобы успевал уходить.

 

На 20 MHz отправить в UART нереально. Т.е. отправить реально, а принять без ошибок, на 115200 - не выйдет.

На 115200 - прекрасно, ошибка менее двух процентов. И на 230400 тоже.

Сейчас у мамок com-порты отвратительные, с подстройкой фазы все очень плохо (особенно "радуют" мамки на nForce - чуть в сторону и приехали). Потери - гарантированы.

Ой, ну да ладно страсти-то какие-то рассказывать, а ? Какие-такие "подстройки фазы" ?

К тому же - ну какие тут 115200 (входные по порядок шустрее), когда и 230400 мало. Значит, никаких аппаратных COM, а только USB.

 

 

 

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


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

На 115200 - прекрасно, ошибка менее двух процентов. И на 230400 тоже.

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

Ой, ну да ладно страсти-то какие-то рассказывать, а ? Какие-такие "подстройки фазы" ?

Вот благодаря таким знаниям, мы имеем неработающие com-порты.

 

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


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

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

А если достаточно, то и тем более нет никаких поводов для беспокойства. В 9-ms паузу такая посылка не уложится, будучи "размазана" на весь принимаемый поток - вполне.

 

Вот благодаря таким знаниям, мы имеем неработающие com-порты.

Я не знаю, какие там неработающие порты _Вы_ имеете, но больше пока никто не жаловался. Вы занимаетесь натуральным сочинительством на ровном месте.

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


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

Я не знаю, какие там неработающие порты _Вы_ имеете, но больше пока никто не жаловался. Вы занимаетесь натуральным сочинительством на ровном месте.

Прошу прощения, за резкие слова, день, мля, тяжеловатый выдался :cranky:

По теме: Я выше писал про FIFO и параллельную обработку итд итп. Если правильно реализовать, то общего времени приема "пачки" данных + время паузы достаточно, для выпихивания всего блока на 115200. FIFO потребуется не менее размера одной "пачки". Если все реализовать тщательно, то должно получится.

 

С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы.

 

По качеству портов. У меня есть проект, где через com в устройство нужно загрузить firmware порядка 3.5МБ. Там протокольчик дуплексный вопрос-ответ, не я делал.

Так вот у меня, на 2-х компах (чипсет nVidia), это получается через раз. Причина - в этих самых 1-2% отличия скорости (кварц 4МГц). Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу. Единственный комп, в котором стоит Intel-овская мама, работает без проблем. Вот такая вечная молодость.

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


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

Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу.

 

Не сочтите за издевательство, но все-таки осмелюсь спросить, включено-ли у вас управление потоком ? Хотя-бы XON/XOFF ? Описанного вами эффекта лично я не видел никогда. Думаю, что он едва ли возможен, поскольку при получении каждого нового байта (!) приемник пересинхронизируется ...

Изменено пользователем kovigor

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


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

С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы.

Это почему? А Вы в Sram разве не байтами будете писать?! И разве SPI не может работать как slave? А уж передовать тем более

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


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

115200 вполне достаточно, если правильно организовать обмен. Вот благодаря таким знаниям, мы имеем неработающие com-порты

115200 недостаточно, немного не хватает.

 

С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы

Не придумывайте, и с аппаратным SPI , и программно получится принимать на скорости 1.25 Мбод.

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


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

Так вот у меня, на 2-х компах (чипсет nVidia), это получается через раз. Причина - в этих самых 1-2% отличия скорости (кварц 4МГц). Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу. Единственный комп, в котором стоит Intel-овская мама, работает без проблем. Вот такая вечная молодость.

Это, простите, ошибка в ДНК. Самая что ни на есть натуральная. Чтобы рассуждать о "качестве" портов и связи этого "качества" с чипсетом, надо иметь хоть минимальные представления о устройстве этих портов (с этим у Вас совсем плохо). А в данном случае у меня лично никаких сомнений, что имела место банальнейшая потеря данных при отсутствии управления потоком. Дуплекс тут вообще не при чем (прием и передача функционально разные части), а вот косвенно влияет (из-за влияния на загрузку процессора при обработке прерываний).

Я-то думал, что Вы нас порадуете какими-то откровениями на предмет PLL и тактировки MIO-чипа, а тут такая банальщина. "У меня не работает, значит и у других не работает". Но Вы первый додумались до влияния чипсета, с чем и поздравляю ;)

 

Это почему? А Вы в Sram разве не байтами будете писать?! И разве SPI не может работать как slave? А уж передовать тем более

Изначально разговор был про программную реализацию. SPI slave тоже можно, благо что приемник имеет двойную буферизацию. Байтовую синхронизацию, правда, придется обеспечивать ручками. И границы слов тоже. Но чтобы быстренько все это дело скушать и куда-то отдать - вполне, и 22 бита вместо 24 тут нисколько не помеха. Накладные расходы на сборку-отправку резко сокращаются. А синхронизацией пускай PC занимается. Я так понимаю, что речь о каком-то сниффере протокола, и задача засосать в PC этот самый входной поток. Вариантов реализации по крайней мере два-три...

Изменено пользователем rx3apf

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


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

Здравствуйте товарищи!!!!

Докладываю голосом!

Длительность 1 разряда = 0,800 мкс

Длительность слова = 22р*0,800мкс=17,6 мкс

Пауза между словами в пачке =11.2 мкс

Количество слов в пачке 33

Длина пачки ==33сл*17.6+32паузы*11.2=580.8мкс+358,6мкс=939,2мкс ну короче 940мкс (по осциллографу)

 

Далее сам протокол для МАСТЕРА ...ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс....

В пачке передачи на СЛАВЕ передаются слова с адресами с 0 по 32 + информация

В пачке приема на СЛАВ идут адреса с 33 по 63, 33, 34 для синхронизации СЛАЙВА , а по другой паре проводов (D и С) поступают данные от СЛАЙВА

для слайва ...ПАУЗА 6*1,28мс \ПАЧКА ПРИЕМА\ пауза 300мкс \ПАЧКА ПЕРЕДАЧИ\ ПАУЗА 6*1,28мс \ПАЧКА ПЕРДАЧИ\ пауза 300мкс \ПАЧКА ПРИЕМА\ ПАУЗА 6*1,28мс....

 

ЦЕЛЬ УСТРОЙСТВА

надо сделать СЛАЙВ и МАСТЕР на 2 контроллерах.

Складывать информацию надо в SRAM МК и потом ее оттуда передавать по UARTу в ПК, ну и наоборот от ПК по UARTу в SRAM по МК

 

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


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

Ну что-то типа:

b7_0:

sbis port,synch

rjmp b7_0

ori acc1,$80

b7_1:

sbic port,synch

rjmp b7_1

b6_0:

sbis port,synch

rjmp b6_0

ori acc1,$40

b6_1:

sbic port,synch

rjmp b6_1

.....

Ни че не понял! кроме ORI нет ниче!? т.е. всегда будет 0xFF?

Или я ни че не понял или надо вот так:

  ldi acc1,0
b7_0:
sbis port,synch
rjmp b7_0
sbic port,bit_IN
ori acc1,$80
b7_1:
sbic port,synch
rjmp b7_1

 

А если частота проца 20MHz что в 16 раз больше сихро то мне кажется можно цикл и не разворачивать. 16 тактов должно хватить.

 

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


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

Или я ни че не понял или надо вот так:

ldi acc1,0

Начальное обнуление необходимо, это как бы самоочевидно...

 

А если частота проца 20MHz что в 16 раз больше сихро то мне кажется можно цикл и не разворачивать. 16 тактов должно хватить.

Двигать маску, проверять счетчик цикла, переход в цикле... Может быть и хватит, но смысла в этом практического нет, все и так на грани, а будет еще хуже. Зачем ? Ради спортивного интереса съэкономить память кода ?

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


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

Начальное обнуление необходимо, это как бы самоочевидно...

А что, кроме начального обнуления других изменений нет?

 

А если всетаки цикл понадобиться то может быть вот так:

Кстати начальное обнуление вообще не нужно

    ldi  count,8
cc0:sbic port,synch
    rjmp cc0
    lsl  acc1
cc1:sbis port,synch
    rjmp cc1
    sbic port,bit_IN
    ori  acc1,$01
    dec     count
    brne cc0

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


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

А что, кроме начального обнуления других изменений нет?

А, ну да, это я как-то невнимательно писал, синхра синхрой, но и входной бит проверить не мешает ;)

Изменено пользователем rx3apf

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


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

Кстати начальное обнуление вообще не нужно

    ldi  count,8
cc0:sbic port,synch
    rjmp cc0
    lsl  acc1
cc1:sbis port,synch
    rjmp cc1
    sbic port,bit_IN
    ori  acc1,$01
    dec     count
    brne cc0

кстати, этот Ваш кусочек кода в худшем случае на 20 тактов

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


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

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

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

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

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

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

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

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

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

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