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

Valentinus

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

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

  • Посещение

Репутация

1 Обычный
  1. оказалось проблема в CPU Frequency Scaling и Dynamic Bus Frequencies. Эти фичи меняют частоту М4, более подробно почитать в I.MX Reference Manual главы 2.3.3 и 2.3.4. запретить Dynamic Bus Frequencies можно прям из командной строки: echo 0 > /sys/devices/platform/busfreq/enable Проблема решена. Оставил комментарий для тех кто с эти столкнется.
  2. еще раз повторюсь - диаграмма пропорционально растягивается , из 12 мкс до 70мкс. если бы задержка была из-за "разгона", то была бы просто задержка в начале.
  3. если бы причина была в таких конфликтах, то замедление было бы разным (т.е. в какой-то момент конкуренция за шину больше, в какие-то меньше), но я наблюдаю фактически два состояния: нормальное выполнение и замедленное в несколько раз. и как я писал в изначальном сообщении, для исключения вероятности таких вот конфликтов мы взяли простейший пример от производителя проца, и вставили туда только измерение времени выполнения прерывания. т.е. конкуренции за доступ к внешним устройствам нет. более того, если запустить например копирование большого файла , то скорость М4 становится нормальной (на время копирования). то есть дело не в конкуренции за шину или память. у меня есть подозрение что после загрузки , до командной строки, ОС как бы понимает что наступил режим простоя и снижает тактовую частоту основных ядер, и М4 заодно. но как проверить эту теорию и как этому помешать я не знаю. в несколько раз. т.е. при нормальной "скорости" диаграмма занимает примерно 12мкс, при замедленной - порядка 70мкс Время входа в ISR очень стабильное, к нему нет абсолютно никаких вопросов ))) вопрос к времени выполнения самого ISR по осциллографу я вижу что прерывание вызывается четко и стабильно, т.е. начальные фронты "пачек" временных диаграмм относительно друг друга стоят стабильно, не плавают
  4. скажу проще: у нас был проект на i.MX6, там все работает на GPIO , отлажено, он рабочий, но эту плату больше не продают, и нам надо его перенести на другую плату с i.MX8 с минимальными доработками. и уже почти все сделали, но вот столкнулись с описанной проблемой. это просто одна из версий, я не знаю как еще обьяснить что один и тот же кусок кода (неважно - выдача диаграммы или просто цикл загружающий вычислениями) исполняется раз от разу или нормально, или медленно. у меня были версии, что прерывание таймера прерывается каким-то еще более приоритетным, но временная диаграмма у нас растягивается ровно. то есть просто код в М4 вдруг начинает выполняться медленнее.
  5. это в данном случае не важно, переферия нестандартная, она не может по DMA и ее устраивает скорость М4. но нас не устраивает то что М4 меняет свою частоту работы, и не можем понять - из-за чего?
  6. коллеги, прошу помощи. используем платку SOM-TLIMX8 от китайцев (ф. Тронлонг) на процессоре I.MX8 столкнулись с проблемой - сопроцессор М4 периодически начинает работать медленнее. изначально нам нужно было чтоб периодически (по таймеру) М4 выдавал некоторую диаграмму по GPIO (вся диаграмма выдается за одно прерывание, т.е. ее длина зависит только от быстродействия М4) И мы увидели что диаграмма меняет длительность: то нормальная, то в несколько раз шире, то есть как будто М4 меняет частоту на которой работает. мы подумали , что может где-то ошиблись, что-то неправильно задали в DTS, и тогда вместо работы с GPIO вставили просто цикл загружающий М4 работой (в цикле складывали числа от 0 до 1000) и замеряли его время (по тикам таймера). и обнаружили что время выполнения этого цикла заметно меняется, то быстро выполняется, то на порядок медленнее. то есть дело не в настройках GPIO в DTS. и тогда взяли для пример с сайта NXP, который показывает работы с GPT таймером. пример там простой, он раз в секунду выдает сообщение в консоль и в начало обработчика мы поставили тот же цикл и замером времени его работы, типа такого: int summ = 0 , t1 , t2 ; / ********** Code ***** / void EXAMPLE_GPT_IRQHandler ( void ) { / * Clear interrupt flag . * / GPT_ClearStatusFlags ( EXAMPLE_GPT , KGPT_Output Compare1Flag ) ; t1 = GPT_GetCurrentTimerCount ( EXAMPLE_GPT ) ; for ( int i = 0 ; i < 1; i ++ ) { summ + = i ; } // dummy loop t2 = GPT GetCurrentTimerCount ( EXAMPLE_GPT ) ; PRINTF ( " time = % d \ n \ r " , t2 - t1 ) ; / **************** / и после запуска получили ту же картину, значение time в консоли скачет. То есть, проблема не из-за наших кривых рук. вот тут видео: https://drive.google.com/file/d/1PUPp5DT9KaArDjHAgyDeLWuTQpQiRJXo/view?usp=sharing (для наглядности тут увеличено количество итераций и частота таймера) причем заметили что в начале загрузки ядра linux сопроцессор работает нормально, быстро. потом на каком-то этапе он начинает тормозиться, примерно когда загрузка доходит до монтирования носителей, а после окончания загрузки тормозит почти постоянно. если запустить копирование с sd на emmc то во время копирования скорость М4 снова нормальная. если остановить ОС (halt) то все снова норм. Подскажите , плиз, в чем может быть проблема, куда копать? уже всю голову сломали 😞
  7. добрый день! Кто-нибудь может поделиться примером (исходниками) прикрутки uIP или lwIP на ARM ? У меня проблема с пониманием как это сделать. имеется плата с AT91SAM9XE512, к нему приделан PHY KB8721, под линухом все работает, но мне нужно написать standalone-программу, которая будет связываться с ПК (отправка прием данных). выбрал стек попроще - uIP , пытаюсь подружить я взял рабочий helloworld для этого проца, вставил в него код из helloworld от uIP, обозначил через define "функцию приложения", как они ее называют, т.е. та в которой будут обрабатываться сетевые события, и вроде как по мануалу она должна периодически вызываться. все скомпилировалось, запускается, но "функция приложения" не вызывается. собственно говоря, я особо и не ожидал, т.к. не понимаю каким образом uIP должен узнать о физической реализации сетевого контроллера, т.е. какие порты опрашивать, откуда получать/отправлять данные и т.п.. поэтому прошу поделиться рабочим примером uIP или lwIP . заранее благодарю.
  8. действительно, дело было в этом. ну чтож урок мне на будущее- не доверять, а проверять самые свежие редакции документации он Атмела ДМИТРИЙ! ОГРОМНОЕ ВАМ СПАСИБО!!!! не представляете сколько дней и нервов у меня ушло на поиск решения этой проблемы. для тех кто имеет новые ревизии AT91SAM9XE и сидит на старых и непатченых ядрах можно просто вставить в начало файла rtc-at91sam9.c поправку: #define AT91_GPBR (0xfffffd60 - AT91_BASE_SYS)
  9. странно!!! я смотрю в datasheet на AT91SAM9XE512 и AT91SAM9260 - там в обоих GPBR начинается с 0xFFFFFD50 !!!! где-то я встречал что для 9263 адрес GPBR начинается с 0xFFFFFD60, но это не мой случай! ах вон оно что: вот зараза!!!! пойду пробовать.
  10. я проследил работу hwclock до вызова функции at91_rtc_readtime из rtc-at91sam9.c из нее идет возврат по ошибке вот тут: /* read current time offset */ offset = gpbr_readl(rtc); if (offset == 0) return -EILSEQ; gpbr_readl , как я понимаю, должна возвращать "0" только если RTC еще не инициализирован, при загрузке оси. Из-за этого ось при загузке сообщает "rtc-at91sam9 at91_rtt.0: rtc0: SET TIME!" и "rtc-at91sam9 at91_rtt.0: hctosys: unable to read the hardware clock" - мол, "хардварное время не установлено, установи его!". Инициализацию можно либо сделать в функции at91_rtc_probe или отдельной программкой - ссылки на эти оба способа я давал в первом сообщении. После этого gpbr_readl будет возвращать не "0", а значение хардварного времени и все будет ок. но проблема в том, что у меня gpbr_writel не может записать в регистры никакого значения - оттуда все равно читается "0". gpbr_readl и gpbr_writel это просто макросы: #define gpbr_readl(rtc) \ at91_sys_read(AT91_GPBR + 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR) #define gpbr_writel(rtc, val) \ at91_sys_write(AT91_GPBR + 4 * CONFIG_RTC_DRV_AT91SAM9_GPBR, (val)) аналогично я и пробовал "вручную" - отобразил адрес этих регистров через mmap и писал/читал. но все рано не записывается ничего.
  11. проблема с RTC на AT91SAM9XE512

    использую отладочные платы с AT91SAM9XE512 (SK-AT91SAM9XE512-S3E и SK-AT91SAM9XE512-SIM300) возникла проблема с использованием RTC под Linux (пробовал ядра 2.6.28 и 2.6.35.1) - не устанавливается значение в hwclock, и все тут! пробовал и так, и сяк - не работают. начал копать - оказалась проблема в том что не записывается значение в Battery Backup Registers, то бишь туда, где времечко хардварное должно храниться (4 General-Purpose Backup Registers). даже пробовал "вручную" туда писать: что бы ни писал - читается "0". помогите плз, мудрым советом. а то уже не знаю, что придумать!!! :crying: :crying: :crying:
  12. написано же четко: "ищу специалиста", тем более в теме "Предлагаю работу" размер оплаты не пишу, т.к. программист из Москвы или Тамбова оценят работу по-разному; также играет роль срок исполнения, квалификация и пр..
  13. ищу специалиста по ARM9 для разовой работы (программиста) !!!!!! задача: написать библиотечку функций для работы с USB-флешдисками в файловой системе FAT без ОС (для использования stand-alone программах). Платформа: платы SK-AT91SAM9XE512-S3E и SK-AT91SAM9XE512-SIM300 Особых наворотов не нужно, по минимуму только чтение/запись файлов; хотя хотелось бы получить функциональность FatFS. Грубо говоря - портировать USBHostLite или драйвер из U-Boot, но желательно еще прикрутить что-нибудь типа FatFS, потому что USBHostLite изначально очень кастрирован и не может работать с директориями и искать файлы. вопросы по размеру оплаты и прочее лучше писать мне сразу на мыло: hanbekov САБАКА gmail.com
×
×
  • Создать...