[zltigo 1]

....

 

    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]

    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]

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

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

[sasamy 1]

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

 

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

[zltigo 1]

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

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

Вы их точно так же делаете, только в некоторых случаях меньше.

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

На этом последовательном интерфейсе 25 МГц

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

я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания

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

 

[aaarrr 69]

что-то зачем-то

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

[sasamy 1]

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

 

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

 

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

 

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

 

но порожден еще и тот самый говнокод ( делающий что-то зачем-то ) :(.

 

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

[zltigo 1]

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

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

...достаточно открыть любой даташит.

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

[IgorKossak 0]

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

Модератор.

[lotor 0]

Не про 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]

Проблему решил уменьшением частоты тактирования LCD, но если кто вдруг в курсе настройки AHB1 буду признателен совету. :)

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

[lotor 0]

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

 

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

[FinaC 0]

Не про 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.