О том, что написал.

Я понял Вашу мысль и достаточно четко на мой взгляд написал, почему меня такая правка НЕ устраивает. Подправленный код тоже привел. Ознакомьтесь для начала.

Я немного опоздал с ответом - в общем это очередная индусятина - собственно то что вы ставили во главу сначала (а это перебрать и найти ЛЮБОЙ адрес даже если ошибка в физике) вдруг отошло на второй план и появился костыль который гробит всю идею на корню

бла, бла, бла....

Было и есть на переднем плане. Во главе угла нормально без лишних рассылок ресетов и прочих ЛИШНИХ телодвижений инициализировать PHY. Если вдруг PHY не нашелся на том адресе, на котором должен быть, то тогда искать. Это НЕ штатный режим и время не имеет значения. Значение-же, для той-же демки имеет понятность и минимально-достаточное количество действий при инициализации. Дивная посылка кучи НЕНУЖНЫХ ресетов может в демке разве только сбить с толку читающего и замаскировать ту самую необходимо-достаточную процедуру инициализации PHY. Кстати, о времени, vSmartDelay_ms() это при работающем шедулере и не при вызове из Idle не задержка, а переключение на другую задачу. До кучи у меня нет зависимости от наличия в функции write_PHY() ожидания окончания транзакции. Отсутствие такого ожидания тоже встречалось в халявных демках .

Честно говоря - мне нечего добавить. Учить Вас с таким самомнением бесполезно и поздно, тем более что-то доказывать - я даже не расчитывал что вы согласитесь что код у вас говенный

Возможно со временем Вам дано будет его понять.

Ваше "исправление" смотрится гораздо более убого "очередной индусятины", ибо не предполагает удобную смену дефолтного адреса, коли уж на то пошло.

Еще один. Для нервнодышащих, вот исходное сообщение
http://electronix.ru/forum/index.php?showt...st&p=947034
покажите мне - какой там дефолтный адрес. Если он так нужен - пожалуйста, смысл ведь не в этом.

Я разве сказал, что мне нравится исходный код? Спешу разуверить: отнюдь не нравится. Например, я не вижу причины без нужды дергать software reset.
Но ситуацию это не меняет - ваше исправление менее убого исходного варианта, но явно хуже аналогичного от автора. Индусятина-с.

Не знаю - я ответил на конкретное предложение про дефолтный адрес невесть откуда взявшийся.



Ну и не дергайте



Собственно исправление автора еще более убого чем начальный вариант - он теряет смысл, потому что весь диапазон адресов не будет проверен. А вы если делаете громкие заявления - не поленитесь привести свой код, иначе они звучат как пшик индуса

А как бэ посмотреть это самое исправление внимательно не имеете желания? Пшикнуть нетерпится?

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

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


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

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



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



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



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

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.