zltigo 1 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба .... for (phy_addr = 1; phy_addr <= 31; phy_addr++) // Put PHY in reset mode write_PHY(PHY_REG_BMCR, BMCR_RESET); 1. Нет сброса по 0 адресу. 2. Тратится время на бездумную передачу 30(31) команды сброса по последовательному интерфейсу все зависимости потребуются они в последствии или нет. Соответственно эти пустые действия непонятны для изучающего вольного предположить в их наличии какой-то смысл. 3. Если в функции write_PHY() нет ожидания окончания транзакции будет облом. for (phy_addr = 1; phy_addr <= 31; phy_addr++) { if ((phy_addr != DEFAULT_PHY_ADDR) && (!(read_PHY(PHY_REG_BMCR) & BMCR_RESET))) goto phy_found; } 1. Опять нет контроля по 0 адресу. 2. (phy_addr != DEFAULT_PHY_ADDR) && лишнее украшение. Собственно исправление автора еще более убого чем начальный вариант - он теряет смысл, потому что весь диапазон адресов не будет проверен. Как оказалось, чукча не только не "писатель", но и не "читатель" :( - типа чисто "критик". Диапазон адресов проверяется весь начиная DEFAULT_PHY_ADDR. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 1 5 июля, 2011 Опубликовано 5 июля, 2011 (изменено) · Жалоба for (phy_addr = 1; phy_addr <= 31; phy_addr++) // Put PHY in reset mode write_PHY(PHY_REG_BMCR, BMCR_RESET); 1. Нет сброса по 0 адресу. Вообще-то это была копипаста с вашего кода, так что претензии не ко мне :) 2. Тратится время на бездумную передачу 30(31) команды сброса по последовательному интерфейсу все зависимости потребуются они в последствии или нет. Вы их точно так же делаете, только в некоторых случаях меньше. На этом последовательном интерфейсе 25 МГц, а у вас первая же задержка 1 мс - о чем вообще может быть речь, эти команды пролетят когда она еще не закончится. 3. Если в функции write_PHY() нет ожидания окончания транзакции будет облом. Пожалуй на этом хватит - это ваш немного исправленый код - к вам претензии, я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания, конечно немного в грубоватой форме сказано, но в принципе это был ваш тон. (phy_addr != DEFAULT_PHY_ADDR) && лишнее украшение. Ну с этим согласен - прочитать лишний раз регистр - раз плюнуть. Изменено 5 июля, 2011 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба На этом последовательном интерфейсе 25 МГц, а у вас первая же задержка 1 мс - о чем вообще может быть речь, эти команды пролетят когда она еще не закончится. 2.5МГц, а не 25, так что 30 последовательных передач займут как раз чуть меньше 1мс :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 1 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба 2.5МГц, а не 25, так что 30 последовательных передач займут как раз чуть меньше 1мс :) Да - ошибка, но она на смысл не влияет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба Вообще-то это была копипаста с вашего кода, так что претензии не ко мне :) Кто-то взялся править, причем после публикации моего подчищенного, но не сумел. Вы их точно так же делаете, только в некоторых случаях меньше. При штатном течении инициализации ровно один необходимо-достаточный сброс вместо 32. На этом последовательном интерфейсе 25 МГц Вы не знаете и типичных скоростей MDIO интерфейсов в PHY :(. Ошибка на порядок. я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания только в случае НЕШТАТНОЙ ситуации с PHY. Вместо этого Вы добавили те самые ненужные действия требующие времени и для случая штатной инициализации. Затраты времени меня особо не смущают, но порожден еще и тот самый говнокод ( делающий что-то зачем-то ) :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба что-то зачем-то Вот заодно и спрошу: зачем сброс? Вопрос без всякой подковырки, просто интересно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 1 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба Вы не знаете и типичных скоростей MDIO интерфейсов в PHY :(. Ошибка на порядок. Можете считать я пропустил запятую, хотя честно говоря - это не таблица умножения чтобы все помнить наизусть, достаточно открыть любой даташит. только в случае НЕШТАТНОЙ ситуации с PHY. Вместо этого Вы добавили те самые ненужные действия требующие времени и для случая штатной инициализации. Затраты времени меня особо не смущают, Естественно - какие затраты времени, если у вас _всегда_ до чтения регистра задержка 1 мс а у меня ее нет, в ее качестве посылки сброса по всем адресам. но порожден еще и тот самый говнокод ( делающий что-то зачем-то ) :(. ликвидирующий задержку в 3,5 сек в случае внештатной ситуации и не вносящий никаких задержек и усложнений и без того кривого кода. Вообще достаточно было читать PHYID без всяких левых сбросов и задержек. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба Вот заодно и спрошу: зачем сброс? Вопрос без всякой подковырки, просто интересно. Для порядка, дабы функция инициализации всегда делала все возможное включая инициализацию PHY и после софтового сброса контроллера, если нет аппаратного сброса. Но прежде всего это ведь тест на наличие любого PHY - бит должен самосброситься по окончанию инициализации PHY. Другое дело, что время ожидания очистки в 128ms скорее всего великовато, но с другой стороны оно обычно никак не нормируется производителем PHY :(. Далее еще, после чтения идентификатора, но перед инициализацией, производятся чтения default значений из регистров PHY. Это тоже диагностика PHY. Порядка 10 лет работы в качестве разработчика диагностических комплексов на VEF-е оставили хорошую привычку, в том числе при POST, делать всю диагностику по максимуму. ...достаточно открыть любой даташит. Открыть, почитать, подумать...., допустить мысль, что кто-то тоже обладает разумом. Только очевидно это не всем дано - лучше сразу писать первое, что придет в голову :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 6 июля, 2011 Опубликовано 6 июля, 2011 · Жалоба Удалил лишнее. Прошу придерживаться рамок темы, хотя бы приблизительно. Модератор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lotor 0 7 июля, 2011 Опубликовано 7 июля, 2011 · Жалоба Не про RMII KS8721BL, зато про Olimex/Startetkit LPC23/4. :) Кто-нибудь переопределял приоритеты на шине AHB1? При записи на sd-карточку начинает срываться изображение на TFT. Работа с sd через DMA - кейловский драйвер (MCI_LPC24xx.c). И DMA и LCD подключены к AHB1. В регистре AHBCFG1 настроил приоритеты так - LCD, CPU, DMA, AHB1, USB. После чего в процедуре записи на SD-карту вылетаю в Data-Abort. Если приоритет DMA выше LCD - то все хорошо, но изображение срывается. Проблему решил уменьшением частоты тактирования LCD, но если кто вдруг в курсе настройки AHB1 буду признателен совету. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 июля, 2011 Опубликовано 7 июля, 2011 · Жалоба Проблему решил уменьшением частоты тактирования LCD, но если кто вдруг в курсе настройки AHB1 буду признателен совету. :) В этом случае следовало бы разобраться, что именно вызывает Data Abort при работе с SD. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lotor 0 8 июля, 2011 Опубликовано 8 июля, 2011 · Жалоба В этом случае следовало бы разобраться, что именно вызывает Data Abort при работе с SD. В Data Abort вылетает в функции fwrite - кейловская библиотека Flash File System. Исходников нет, дизассемблирование показывает, что проблемная инструкция STR R0, [R4, #0x0C], в R4 нули. Получается пытается что-то сохранить по адресу в памяти программ... В общем или таки кейловская библиотека чудит, или я не знаю тонкостей настройки приоритетов AHB. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FinaC 0 10 августа, 2011 Опубликовано 10 августа, 2011 · Жалоба Не про RMII KS8721BL, зато про Olimex/Startetkit LPC23/4. :) Кто-нибудь переопределял приоритеты на шине AHB1? При записи на sd-карточку начинает срываться изображение на TFT. Работа с sd через DMA - кейловский драйвер (MCI_LPC24xx.c). И DMA и LCD подключены к AHB1. В регистре AHBCFG1 настроил приоритеты так - LCD, CPU, DMA, AHB1, USB. После чего в процедуре записи на SD-карту вылетаю в Data-Abort. Если приоритет DMA выше LCD - то все хорошо, но изображение срывается. Проблему решил уменьшением частоты тактирования LCD, но если кто вдруг в курсе настройки AHB1 буду признателен совету. :) Тоже много времени потратил на то, чтобы разобраться с приоритетами DMA и LCD. В итоге где-то на иностранном форуме раздобыл следующую настройку приоритетов: AHBCFG1 = 0x10000144; До этого тоже изображение дёргалось при использовании DMA. Сейчас всё идеально ) SD не использую, так что не смогу подсказать, как тут быть. Но думаю, что это поможет тем, кто также не использует SD. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться