[SapegoAL 0]

On 3/27/2024 at 5:03 PM, HardWareMan said:

А у него что, нет какого-то флага готовности? Тупая задержка не всегда хорошее решение.

Ну и преимущества будут небольшие. Задержка установлена в 0,5 сек. 
То есть при рестарте на 0,5 сек потенциально раньше начнёт работать Ethernet....
На таких девайсах это не принципиально

[Сергей Борщ 119]

25 минут назад, SapegoAL сказал:

Задержка установлена в 0,5 сек. 

Мне кажется, это немножно перебор:

[jcxz 184]

38 минут назад, Сергей Борщ сказал:

Мне кажется, это немножно перебор:

Или недобор? max ведь не указано. А значит и 0.5с может не хватить. И почему 0.5с, а не 5с или не 50с?

ЗЫ: Вобщем, как уже сказали - решение с задержкой кривое. Сегодня работает, завтра - нет. Но ТСу лень читать документацию, чтобы сделать правильно.  

[SapegoAL 0]

Ну по своей сути, что мы имеем?
У нас есть ОС. Есть задача.
Правильным является написание что-то вроде
while(!Ready) osDelay(wtms);
Правильно?
Соответственно, в зависимости от значения wtms мы будем иметь две граничных ситуации...
1. Чем меньше мы сделаем задержку, тем больше будет загружен процессор и ему меньше времени остаётся на выполнение других задач по инициализации и т.п.

2. Чем больше мы сделаем задержку, тем больше будет задержка старта обслуживания ETH.
Оптимизировать функцию выполняющуюся 1 раз при старте прибора нет смысла. При значении wtms > Max проверка флага не имеет смысла и всё вырождается в одну задержку.
В этом случае иногда используют значение задержки значительно больше ожидаемого времени установления рабочего режима.
Что я и сделал.
 

[jcxz 184]

18 минут назад, SapegoAL сказал:

В этом случае иногда используют значение задержки значительно больше ожидаемого времени установления рабочего режима.
Что я и сделал.

Вы в вышеприведённую таблицу смотрели? Поняли что там написано?

[SapegoAL 0]

On 4/3/2024 at 3:49 PM, jcxz said:

Вы в вышеприведённую таблицу смотрели? Поняли что там написано?

А что там написано? Там написано, что после подачи питания и стабилизации частоты тактирования (X1) должно пройти минимум 167мс.
Поэтому верхняя планка и не указана.
Кроме того, нет регистра готовности...
Есть достаточно сложная процедура power down/ power up. С контролем питания и контролем его нарастания. 

[Сергей Борщ 119]

56 минут назад, SapegoAL сказал:

Кроме того, нет регистра готовности...

Можно считывать PHYIDR2 и проверять в нем поле VNDR_MDL. Как только совпадет с ожидаемым - считать, что он готов отвечать. Ну то есть напрягаться, вместо того, чтобы просто поспать.

[jcxz 184]

В 05.04.2024 в 14:32, SapegoAL сказал:

А что там написано? Там написано, что после подачи питания и стабилизации частоты тактирования (X1) должно пройти минимум 167мс.
Поэтому верхняя планка и не указана.

Там написано, что от момента подачи питания до первого доступа к регистрам должно пройти не менее 167мсек. А верхняя граница не указана. Это значит, что её нет. Значит и после ваших 0.5 сек задержки и даже после 5 сек задержки, чип может быть ещё не готов к обращению к регистрам. А значит ваш код работать не будет.

В 05.04.2024 в 14:32, SapegoAL сказал:

Кроме того, нет регистра готовности...

Там есть куча разных регистров. Значения которых вам (как разработчику) должны быть известны. А значит нет никаких проблем не тупо ждать неизвестно сколько времени, а ждать читая такой регистр.

[Сергей Борщ 119]

11 часов назад, jcxz сказал:

Там написано, что от момента подачи питания до первого доступа к регистрам должно пройти не менее 167мсек.

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

[SapegoAL 0]

On 4/8/2024 at 1:34 AM, Сергей Борщ said:

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

Ну я это и писал. Только как-то криво получилось. Именно поэтому и нет верхней границы...