Jump to content

    

kons

Свой
  • Content Count

    105
  • Joined

  • Last visited

Community Reputation

0 Обычный

About kons

  • Rank
    Частый гость
  1. Цитата(Mikle Klinkovsky @ Oct 7 2017, 01:08) .... Спасибо - в понедельник сделаю подход к снаряду, попробую что-нить из предложенного. А то я плотно копался с DRAM последний раз в конце 80-х... Радио-86РК, 565РУ5...ностальгия. После этого как-то все работало, даже DDR3 - бо разводка была правильной.
  2. Цитата(AlexandrY @ Oct 6 2017, 17:38) В DDR3 контроллерах штатно применяется Dynamic On Die Termination (ODT), внешних резисторов не надо. Может, я чего-то не понял, но ODT - это вроде как только для линий данных, не? Все рефдизайны и даташиты в один голос твердят о необходимости нагружать линии адреса, управления и CLK. Одно исключение - техасовцы в описании одной из своих маленьких отладочных платок хвалятся, что таки развели без нагрузок. Но там у них DDR3-800 и топология T (по типу DDR2). Еще гипотетическое исключение - разводка единственной 16-битной микросхемы. Для нее последовательного согласования, обеспечиваемого выходными резисторами контроллера, по идее может хватить. А диэлектрик не покатит, увы - разводка во внутренних слоях, снаружи земли. Но все равно, спасибо за идею на будущее. Цитата(EvilWrecker @ Oct 6 2017, 17:12) На словах оно может быть вполне ничего, но я лично ожидаю увидеть весомый довесок к уже озвученной кривизне . В понедельник обязательно - заранее благодарен за замечания.
  3. Цитата(EvilWrecker @ Oct 6 2017, 15:03) Расстрелять. На целевой частоте(и что-либо близкое) не заведете, на медленной тоже не очень вероятно. Имеется в виду стабильная работа с хорошей формой сигнала. Покажите разводку послойно и таблицу с длинами проводников. 1.Жалко. А вот насчет автора прототипа у многих руки чешутся... 2.Да хоть как-нить - на пока. И ведь прототип же впрямь работает, причем в серии (!!!). Правда, в нем стоит память DDR3-1600. 3.Сейчас не могу разводку взять, но я ее видел - все линии 35-40 мм от проца до дальней DDR-ки, разработчик их даже выравнивал. Что положено дифференциальной парой разводить, то так и разведено. Т.е. все хорошо, только терминаторов нет...
  4. Имеется плата с DDR3 (проц от TI семейства SITARA, DDR - 2 шт 256Mx16 от Micron, версия на 1866 МГц, реальная удвоенная целевая частота 1600 МГц). Память разведена по последовательной (не T-образной) топологии БЕЗ ТЕРМИНАТОРОВ. Вообще нет, даже на CLK. Аргументы разработчика - автор прототипа данной платы (другой человек) все так делает, и как-то работает. Конечно, разработчик озадачен и уже делает следующую версию как надо. Но "на пока" очень хочется запустить и эту плату. Сделал: - Поставил тайминги в соответствии с даташитом на память. - Поиграл временами нарастания сигналов (контроллер в проце позволяет). Оптимальный вариант - для CLK максимально короткие, для адреса/управления - несколько сглаженные. - Нагрузил CLK (не как положено, а дифференциально одним резистором 75 Ом). В итоге при оптимальных настройках наблюдается следующее: - При некоторых тактовых частотах (400 МГц) контроллер DDR вообще завешивает проц. На 700 МГц вроде не завешивает. - Младший байт старшей микросхемы (по разводке - последняя от проца) читается нечетко. - Последние 2 32-битных слова каждого 8-словного пакета не читаются в обоих половинках (а может, и не пишутся - хз). - А в остальном все OK Вопросы: - Насколько вообще реально завести DDR3 с такой разводкой? - Может, кто-то сталкивался с аналогичными глюками? Заранее благодарен всем ответившим.
  5. Неоднократно делал. Оценивал, правда, фактически С/(С + Ш), но при хорошем точности вычислений и C/Ш до 30-40 дБ точность получаемого С/Ш вполне нормальная. Сигнал находим как мощность на выходе узкополосного фильтра (удобно реализовать в виде: перенос сигнала на 0 частоту IN*e^(-j*Wсигн*t) ->комплексный ФНЧ или просто интегратор -> OUT*OUT"), сигнал+шум - как просто мощность (IN^2 при действительном входе или IN*IN" при комплексном). Обе мощности интегрируем по достаточно длинному окну, после чего делаем вычисляем оценку. Sorry, если какой-нить масштабный множитель забыл.
  6. Цитата(jcxz @ Jul 18 2011, 22:47) ...Еще, для уменьшения размера, перекомпилил rts55.lib, выбросив оттуда все ненужные функции. Однако. Неужели линькер сам этого не делает? Завтра гляну.
  7. Опция "-cr" вместо "-с" позволяет не пускать инициализацию из startup. Линькер, вроде, честно ее отрабатывает. И загрузчик в ROM на кристалле грузит как память программ так и данных - ему вообще пофиг, что грузить. Но между ними - hex55, от которого я не могу добиться толку. Уже дошел до мысли состряпать собственный вариант hex55 - формат выходного файла линькера в документации вроде расписан, таблиц cinit и загрузочных тоже. Глупо, конечно, велосипед изобретать, а что делать? Хотя, как вариант развития вашей идеи, на месте cinit можно потом heap разместить...
  8. Спасибо огромное. Завтра с утра на работе буду тщательно изучать детали вашего файла - у меня все там. Наверняка, что-нибудь полезное выцеплю. Но, на память, линьковка у вас с "-c" - значит, .cinit грузится в процессор, и в рантайме инициализирует переменные в .bss. Т.е. ОЗУ расходуется дважды. У меня, увы, с RAM напряги, а инициализаций много. С константами ясно - они пишутся в другую секцию (вроде, .data), которая грузится абсолютно нормально - также, как и код (.text) программы. Офигеваю над Техасом: по опыту с ADSP самое элементарное дело - загрузить из флешки память программ и данных. А тут такой гемор, будто я хочу странного.
  9. Да...видимо, техасовский 55 процессор - штука редкостная, про которую никто ничего не слышал... А между тем еще вопросик появился. hex55 упорно не желает видеть и грузить в .bss секцию .cinit. Линькуется все, естественно, с опцией -cr (инициализация переменных на этапе загрузки). Если линьковать с опцией -c (инициализация в рантайме), то памяти не хватит. Да и не солидно как-то - инициализизировать RAM из RAM... Может, кто-нибудь посоветует варианты? Заранее благодарен. P.S. Документация TI и CCS - песня та еще. Насколько же у всяких ADов, Атмелов, Кейлов и Иаров все человечнее!
  10. Здравствуйте. Впервые сделал проект на 55 процессоре. Система простая: программа загружается из внешней флешовки встроеннным в проц бутлоадером, и дальше работает из ОЗУ. Дошло дело до пуска, и вылез вопрос - как выставить нужную конфигурацию возврата (fast == use RETA)? - Бутлоадер по описанию использует конфигурацию с медленным возвратом. - Компилятор генерит код под быстрый возврат, и это правильно. - Конфигурация задается в ресетном векторе, дефолтовая таблица векторов - у бутлоадера в ROM. - Бутлоадер передаст управление куда ему скажут, но конфигурацию-то поменять уже, вроде как, нельзя? Если перегрузить IVPD указателем на свою таблицу с правильным вектором и повторить ресет, то в IVPD при этом опять запишутся дефолтовые FFFF, и пустится опять бутлоадер? А если выполнить TRAP #0/INTR #0, то переключится ли конфигурация? Понимаю, что все элементарно, но как? Заранее благодарен за ответы.
  11. Важно ! uC-TCPIP bug @ SAM7X port

    Интересная тема. Я тут тоже на днях написал драйвер EMAC (еще не проверял). Вначале тоже думал над прерываниями, а потом обошелся без них - все сделал, вообще не дотрагиваясь до регистров EMAC после инициализации. Проверяю только состояния дескрипторов в памяти. Причем опрос может быть не слишком частым (при достойной длине буфера) - раз в 5-10 мс вполне нормально. Почитал и засомневался - может, так не пойдет? И еще вопрос: автонегоциацией кто-нибудь заморачивался? Если правильно понял, это надо время от времени опрашивать PHY и приводить скорость и дуплекс в EMAC в соответствие со считанными из PHY значениями?
  12. ARM Ассемблер

    Да, хорошая штука RVCT. Мой IAR так не умеет - проверял. Однако такой код на c выходит длиннее ассемблерного. А для того, чтобы написать его и заценить понятливость компилятора, все равно надо знать asm...
  13. ARM Ассемблер

    to KRS. Вы правы, кол-во обращений к данным не уменьшает, но (для ARM7TDMI, у Cortex и особенно ARM9 разница не столь существенна) LDR - 3 такта/слово, LDMIA - 2+1*кол-во слов. Т.е. при загрузке, скажем, 8 регистров LDRx8 = 24 такта, LDMIA - 10 тактов. Да, забыл сказать - это при выполнении из RAM. При выполнении из флэша на AT91SAM7 добавьте к каждому LDR еще по такту - флеш медленнее, однако. Простенький пример - цикл вычисления FIR. Данные берутся из циркулярного буфера (DL_PTR, DL_BASE, DL_SIZE). Обрабатываются 4 отвода за раз. Напишите на c, скомпилируйте, посчитайте такты, сравните. А стоит или не стоит это делать на ASM - зависит от потребной частоты вычисления и длины фильтра. В моем случае (Fд=48 кГц, L=20 отводов, и кроме этого еще куча дел) - стоило однозначно. Была бы Fд 8 кГц - не стал бы заморачиваться. Что же касается реакции на прерывания - на то DMA есть. FIR_DELAY_LOOP MACRO LOCAL FDL_LP FDL_LP: LDMDB DL_PTR!,{R_SMP3-R_SMP0} ;8 CMP DL_PTR,DL_BASE ADDLS DL_PTR,DL_PTR,DL_SIZE LDMIA SUFF_PTR!,{R_SUFF0-R_SUFF3} ;6 MLA R_ACC,R_SUFF0,R_SMP0,R_ACC ;16 MLA R_ACC,R_SUFF1,R_SMP1,R_ACC MLA R_ACC,R_SUFF2,R_SMP2,R_ACC MLA R_ACC,R_SUFF3,R_SMP3,R_ACC SUBS SUFF_CNT,SUFF_CNT,#4 ;4 BNE FDL_LP ENDM P.S. А как тут код нормальный вставлять? Что с цитатой, что без - все одно каша... to Pasha: ЦитатаЭто квадратные советы. Они не учитывают задачи портирования, коих большинство, когда об алгоритме уже известно почти все, надо чтобы оно красиво влезло и не мешало жить наращиваемой функциональности. В таких случаях я лично начинаю с проверки и оптимизации именно узких мест. +500. Особенно для DSP, и особенно на этапе выбора процессора.
  14. ARM Ассемблер

    ЦитатаЭтот принцип для досужей потехи хорош, а для профессиональной деятельности крайне вреден. Если так ковыряться в инструкциях, то времени на работу не останется :-) Немного не так. Если неохота ковыряться в инструкциях, надо пользоваться C. Например, обсуждаемая здесь инициализация периферии - уж точно не задача для asm. На таких задачах (как и на большинстве прочих), как верно отметил KRS, ЦитатаСовременный ARM компилер трудно обогнать используя ассемблер А вот написать какой-нибудь внутренний короткий цикл на asm (фильтр какой-нибудь или демодулятор) - это часто очень даже имеет смысл. И тут уж все средства хороши. Но (по опыту) максимальный эффект в asm-модуле достигается не жонглированияем битами, а оптимизацией доступа к памяти - использованием вместо кучи LDR/STR одной LDMIA/STMIA. Компилятор так не умеет (ну, кроме входа/выхода в процедуру есс-но). Для ядра ARM7TDMI на задачах типа свертки результат подобного подхода очень даже радует.
  15. Цитата(andrex @ Feb 28 2009, 16:12) Спасибо, в общем-то так и делаю. А в чем проблема? Что может быть быстрее таблицы, особенно если избавиться от добавочных проверок? Как вариант - храните элементы в логарифмическом представлении. Но тогда складывать по таблицам придется - шило на мыло...