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

andrewg

Участник
  • Постов

    9
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Контакты

  • ICQ
    Array

Информация

  • Город
    Array
  1. Да, во всех случаях при всех экспериментах имело место 170 нс. между нарастающим и спадающим фронтом -CS. Различным программированием разных регистров предсказуемо меняется длительность -CS, положение data/address valid внутри (и даже снаружи ! при некорректном программировании), гуляют фронты -WR и -RW... и т.д. Но пауза между нарастающим и спадающим фронтами -CS стоит железно - 170 нс... Ещё появилась мысль, для благородного общества. С большой вероятностью можно ожидать, что весь код цикла ядром процессора будет выполняться во время цикла шины (40, 30 и даже 20нс) и вообще отсутствие паузы между соседними циклами шины на данном процессоре вполне возможная вещь. Меня бы и это устроило - фронтов -WR / -RD хватит. Но мы упорно видим 170... ----------------------------- Да простят меня модераторы за оффтоп. Не могу удержаться от всяких улыбок... Господа, вы будете смеяться, но я пишу из кардиологической реанимации, где чувствую себя уже превосходно :) :) :)
  2. SFx, zhevak Тесты, которые Вы предлагаете, мы пробовали (в числе большого числа прочих). Свой уровень я бы оценил как достаточно компетентный (за 25 лет работы). Время на обработку всяких переменных в этих циклах совершенно не существенно. Это абсолютно точно. CORTEX-А-8 на 800 МНz с оптимизацией кода делает все промежуточные операции за (от балды) 5-15 тактов ядра, что даст 7-20 нс. если подходить тупо. Никак не 170. Но ведь работает конвеер, всё берётся из кэша и т.д. Проведённые осциллографом оценки на разных тестах дают оценку ожидаемого проядка непроизводительной задержки 2-5 нс, что, если грубо, не очень намного превосходит нашу погрешность измерения. _3m Сейчас, к сожалению, многого уточнить строго не могу, попозже. Ядро на 800 МГц, кэши включены, мму тоже включено. Программа выполняется из DDR2 (коих установлено 512 МБ) на 200 МГц. Конечно, понятно, что реально при таком объёме всё берётся из кэша. Проблема НЕ в том, что накладные расходы на фетч отъедают много. Проблема в том, что именно процессор добавляет 170 нс. между различными циклами обращения. Это должно задаваться в какой-то из "CPU engine" (типа задержка - 17 тактов (скорее 16)), только не понятно где именно даже смотреть. Устройство висит, разумеется, не на DDR шине. Используется отдельная шина, на которую у DiGi вешается, например, ethernet 100 MBit (в другом исполнении тестовых плат).
  3. Имеем плату от Digi i.MX51. К ней у нас вешается Альтера как 16 бит асинхронная статическая память с временем доступа записи 30 нс. и чтения 40 нс. Из управления нужны только CS, RD, WR и 8 проводов адреса. Всё это удалось настроить и для первых раз терпимо работает. Но есть проблема. Между циклами доступа (неважно, RD или WR) процессор вставляет паузы по 170нс. Т.е., CS в нуле 30 нс, в единице 170 нс, в нуле 30 нс ... и т.д. Соответственно, время периода выполнения учебного цикла: for (i=0;i<XXXX,i++) { data16= INREG16(pPORT); } 200 нс а не 30нс. где pPORT - отмапленное на нужный адрес значение ... (и всё такое правильное, CS то дёргается и данные правильные...). Так же не важно, цикл RD или WR, 8 бит или 16 - разумеется надо инициализировать по разному для конкретного набора. Все равно, пауза 170 нс. между двумя последовательными циклами обращения железно держится. Однако, изучение даташитов НЕ показывает, что пауза между (да ещё такая) циклами должна быть. Замучались искать засаду. Даташиты огромные. Есть ли у кого какие идеи в какую область посмотреть?
  4. I2C - это со значительной вероятностью какой-то "свой" протокол. Свой - это в смысле пишется самостоятельно под конкретный девайс. Ethernet - это с большой вероятностью TCP-IP. Этот не протокол, а стек протоколов. Конечно, его возможно написать, и даже самостоятельно, но практика показывает, что не надо. Особенно, если задаются такие вопросы... Поэтому, его (стек TCP-IP для ethernet) надо взять готовым, вместе с какой то RTOS, где он есть. Вот вам и ответ...
  5. 640х480, качество на мой взгляд - уже терпимое. Хотя, это, конечно, не мне судить. Основные недостатки произведения я перечислил, но в оправдание замечу, что вообще весь фильм получился стихийно. Ничего такого близко не планировалось буквально минут за 30 до того как "урок" начался. Может, даже за 5 минут - сейчас уже не помню. Несмотря ни на что, я уверен, что для тех кому актуально, в фильме уже есть полезная информация. Осознание того, что всё можно улучшить и получить ещё более полезный продукт пришло потом. Паяние, как процесс, кроме паяльника так же может производиться феном, инфракрасное, ультразвуковое и т.д.
  6. Русскоязычное обучалово про паяние паяльником корпусов QFP- 0.5 мм и резисторных матриц 0.5 мм. Файл- огрызок, "как есть". Увы, насчёт размера, наврал - 372 м. Файл действительно "как есть" фрагмент рабочего процесса, и огрызок без начала и без концовки; хватает и не нужной воды. Но если тема актуальная, в нём есть хорошая порция полезной информации . Файл Паяние паяльником.zip [68.3 мб] http://www.onlinedisk.ru/file/535399/ Файл Паяние паяльником.z01 [94.7 мб] http://www.onlinedisk.ru/file/535404/ Файл Паяние паяльником.z02 [94.7 мб] http://www.onlinedisk.ru/file/535409/ Файл Паяние паяльником.z03 [94.7 мб] http://www.onlinedisk.ru/file/535417/ Файл годен до (Valid till) : 2010-12-18 filename=Паяние паяльником.avi size=371858906 crc32=1B3172B3 Грамотный обучающий файл про паялово по уму в начале должен содержать краткое описалово темы, описалово собственно паяльника и соображения про паяльники, подготовку жала, описалово флюсов и припоев и причины всякого-разного, и не должен содержать бессодержательной воды. Его надо делать с нуля, ~30-40 мин. с чуть лучшим качеством, но вроде всё для того есть. Если местный народ на основе представленной демо-версии сочтет тему методологически интересной и предложит сделать полноценную версию, я постараюсь сделать это.
  7. Есть обучающий фильм (мой) про паяние паяльником корпусов QFP с шагом выводов 0.5 мм - устранение залипух. По опыту знаю, у многих начинающих это серьёзная проблема. Как-то на работе молодёжь заинтересовалась, каким "правильным" паяльником это надо делать, и я им "запротоколировал урок как есть". Паяльник как раз самый дешёвый. Могу заложить, если Вам понравится идея и если укажете куда и как. Если же фильм понравится, давно уже была мысль сделать не "как получилось" (хотя и не так плохо получилось, но очевидный огрызок), а правильно. Т.е., если общество потребует, это будет хороший толчок мне закончить эту задачку. Размер огрызка точно не помню, уже года два как было дело. Если не ошибаюсь, около пары сотен метров, 640х480. Так же, давно уже хотел сделать фильм (с нуля) про графическое рисование - решение задач на МАХ-II и Quartus для Альтеры для начинающих. Хорошо, тем, кому эту тему преподавали в институте. Но многие этого были лишены. Помню себя (очень много лет назад), те вопросы, которые меня пугали и решительно останавливали, сейчас вызывают только улыбку. Идею такого фильма тоже уже давно продумывал, примерно на 30-50 минут, именно для начинающих "как начать", без больших заумствований, но с упором на критические моменты.
  8. На вход ЕР2С5 (причем тактовый) однажды подал 5 В через 68 Ом, тоже внешняя шина от 3V3. В сумме, наверное, раз 5 примерно от 1 до 5 минут. Микруха весьма грелась (>>60C), но осталась в итоге жива, уже с полгода никаких замечаний. На третий же Циклон даже 3V3 надо подавать как-то аккуратно из за этих диодов (3V0 - без ограничений). Но насколько я помню, проблема только в момент запуска, до загрузки того, что нагенерил Квартус. Кто вам мешает поставить резисторный делитель, если и так 2К уже есть?
  9. Имеется очень большой проект на С++ и частично на Ассемблере х86 реализованный в среде Paradigm C++ Pro V6.0.008 (2001г). Режим адресации - реальный х86. К сожалению, проект не лезет (настолько, насколько хотелось бы) в имеющуюся память. Возможность увеличить память отсутствует. Все мыслимые оптимизации "подбором ключей" давно уже перебраны. Посоветуйте (из реального пожалуйста) что можно вообще в таких случаях сделать. Есть ли какой другой компилятор С++ для реального х86 генерящий более компактный код? Вопрос знатокам Парадигмы. За Парадигмой замечена высокая неоптимальность генеримого кода во многих конструкциях на С++ с указателями. Иногда просто чудовищная неэффективность, вплоть до подозрения на баги "движка" компилятора. Переписывать код, выделяя локальные указатели с какого то момента стало не очень эффективно. Имеет ли смысл заниматься поиском более свежих версий той же Парадигмы?
×
×
  • Создать...