Jump to content

    

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

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

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

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

Share this post


Link to post
Share on other sites
Это если у Вас скорость порта заведомо выше скорости поступления данных, но у нас как раз наоборот(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.

 

 

 

Share this post


Link to post
Share on other sites
На 115200 - прекрасно, ошибка менее двух процентов. И на 230400 тоже.

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

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

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

 

Share this post


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

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

 

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

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

Share this post


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

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

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

 

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

 

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

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

Share this post


Link to post
Share on other sites
Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу.

 

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

Edited by kovigor

Share this post


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

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

Share this post


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

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

 

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

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

Share this post


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

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

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

 

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

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

Edited by rx3apf

Share this post


Link to post
Share on other sites

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

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

Длительность 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 по МК

 

Share this post


Link to post
Share on other sites
Ну что-то типа:

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 тактов должно хватить.

 

Share this post


Link to post
Share on other sites
Или я ни че не понял или надо вот так:

ldi acc1,0

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

 

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

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

Share this post


Link to post
Share on other sites
Начальное обнуление необходимо, это как бы самоочевидно...

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

 

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

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

    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

Share this post


Link to post
Share on other sites
А что, кроме начального обнуления других изменений нет?

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

Edited by rx3apf

Share this post


Link to post
Share on other sites
Кстати начальное обнуление вообще не нужно

    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 тактов

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this