1. Нет сброса по 0 адресу.
2. Тратится время на бездумную передачу 30(31) команды сброса по последовательному интерфейсу все зависимости потребуются они в последствии или нет. Соответственно эти пустые действия непонятны для изучающего вольного предположить в их наличии
какой-то смысл.
3. Если в функции write_PHY() нет ожидания окончания транзакции будет облом.

1. Опять нет контроля по 0 адресу.
2. (phy_addr != DEFAULT_PHY_ADDR) && лишнее украшение.


Как оказалось, чукча не только не "писатель", но и не "читатель" - типа чисто "критик". Диапазон адресов проверяется весь начиная DEFAULT_PHY_ADDR.

Вообще-то это была копипаста с вашего кода, так что претензии не ко мне



Вы их точно так же делаете, только в некоторых случаях меньше. На этом последовательном интерфейсе 25 МГц, а у вас первая же задержка 1 мс - о чем вообще может быть речь, эти команды пролетят когда она еще не закончится.



Пожалуй на этом хватит - это ваш немного исправленый код - к вам претензии, я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания, конечно немного в грубоватой форме сказано, но в принципе это был ваш тон.



Ну с этим согласен - прочитать лишний раз регистр - раз плюнуть.

Сообщение отредактировал sasamy - Jul 5 2011, 22:20

2.5МГц, а не 25, так что 30 последовательных передач займут как раз чуть меньше 1мс

Да - ошибка, но она на смысл не влияет.

Кто-то взялся править, причем после публикации моего подчищенного, но не сумел.

При штатном течении инициализации ровно один необходимо-достаточный сброс вместо 32.

Вы не знаете и типичных скоростей MDIO интерфейсов в PHY . Ошибка на порядок.

только в случае НЕШТАТНОЙ ситуации с PHY. Вместо этого Вы добавили те самые ненужные действия требующие времени и для случая штатной инициализации. Затраты времени меня особо не смущают, но порожден еще и тот самый говнокод ( делающий что-то зачем-то ) .

Вот заодно и спрошу: зачем сброс? Вопрос без всякой подковырки, просто интересно.

Можете считать я пропустил запятую, хотя честно говоря - это не таблица умножения чтобы все помнить наизусть, достаточно открыть любой даташит.



Естественно - какие затраты времени, если у вас _всегда_ до чтения регистра задержка 1 мс а у меня ее нет, в ее качестве посылки сброса по всем адресам.



ликвидирующий задержку в 3,5 сек в случае внештатной ситуации и не вносящий никаких задержек и усложнений и без того кривого кода. Вообще достаточно было читать PHYID без всяких левых сбросов и задержек.

Для порядка, дабы функция инициализации всегда делала все возможное включая инициализацию PHY и после софтового сброса контроллера, если нет аппаратного сброса. Но прежде всего это ведь тест на наличие любого PHY - бит должен самосброситься по окончанию инициализации PHY. Другое дело, что время ожидания очистки в 128ms скорее всего великовато, но с другой стороны оно обычно никак не нормируется производителем PHY . Далее еще, после чтения идентификатора, но перед инициализацией, производятся чтения default значений из регистров PHY. Это тоже диагностика PHY. Порядка 10 лет работы в качестве разработчика диагностических комплексов на VEF-е оставили хорошую привычку, в том числе при POST, делать всю диагностику по максимуму.

Открыть, почитать, подумать...., допустить мысль, что кто-то тоже обладает разумом. Только очевидно это не всем дано - лучше сразу писать первое, что придет в голову .

Удалил лишнее. Прошу придерживаться рамок темы, хотя бы приблизительно.
Модератор.

Не про 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 буду признателен совету.

В этом случае следовало бы разобраться, что именно вызывает Data Abort при работе с SD.

В Data Abort вылетает в функции fwrite - кейловская библиотека Flash File System. Исходников нет, дизассемблирование показывает, что проблемная инструкция STR R0, [R4, #0x0C], в R4 нули. Получается пытается что-то сохранить по адресу в памяти программ... В общем или таки кейловская библиотека чудит, или я не знаю тонкостей настройки приоритетов AHB.

Тоже много времени потратил на то, чтобы разобраться с приоритетами DMA и LCD. В итоге где-то на иностранном форуме раздобыл следующую настройку приоритетов:

AHBCFG1 = 0x10000144;

До этого тоже изображение дёргалось при использовании DMA. Сейчас всё идеально )
SD не использую, так что не смогу подсказать, как тут быть. Но думаю, что это поможет тем, кто также не использует SD.