[aaarrr 69]

12 minutes ago, Freibier said:

Т.е. читаем в буфер N Мбайт и отправляем "кусочками" равными сектору на первую карту пока она BUSY не выставит.

Затем также отправляем следующей карте опять же до выставления ею BUSY.

И так по кругу.

Только не по кругу, а всем одновременно.

[Freibier 3]

3 минуты назад, Longiel сказал:

Требуется пояснить: запись флешек на физическом уровне идёт параллельно?

На первом такте защелкиваю DAT0-3 источника в триггере плис, на следующем выставляю на линии всех приёмников.

Даже с CRC16 заморачиваться не пришлось. )

[_4afc_ 25]

9 minutes ago, Freibier said:

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

Если у всех карт размер стирания одинаковый, например 64МБ, то можно попробовать стереть все карты, а потом записывать посекторно.

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

И при стёртых - это должно происходить одновременно тогда (если размеры одинаковые).

[Freibier 3]

1 минуту назад, aaarrr сказал:

Только не по кругу, а всем одновременно.

Ну так я и сейчас всем одновременно отправляю, пока какая либо BUSY не выставит.

1 минуту назад, _4afc_ сказал:

а потом записывать посекторно.

Боюсь что при посекторной записи всё будет еще хуже. 

[aaarrr 69]

Just now, Freibier said:

Ну так я и сейчас всем одновременно отправляю, пока какая либо BUSY не выставит.

Да, а нужно одновременно, но индивидуально обрабатывая BUSY. То есть в каждую отдельную карту пишется её текущий блок, а не общий для всех.

[Freibier 3]

1 минуту назад, aaarrr сказал:

Да, а нужно одновременно, но индивидуально обрабатывая BUSY. То есть в каждую отдельную карту пишется её текущий блок, а не общий для всех.

Ясно. Но тут уже надо и жирный проц ставить с кучей памяти и т.д и т.п.

[aaarrr 69]

1 minute ago, Freibier said:

Ясно. Но тут уже надо и жирный проц ставить с кучей памяти и т.д и т.п.

Зачем? Та же логика, только с памятью.

[Freibier 3]

2 минуты назад, aaarrr сказал:

Зачем? Та же логика, только с памятью.

Всю логику на плис реализовать, и память к плис подключить?

Нее, мне до такого еще слишком далеко.

У меня в плис только аля DMA транзакция, а всем остальным малюсенький МК занимается.

Он переводит все карты в нужное состояние и формирует плису строб для запуска процесса копирования одного сектора и ждёт окончания.)

[Ruslan1 17]

1 hour ago, Freibier said:

А это как-то побороть можно?

BUSY не одновременно? нет, побороть невозможно: карты разные, каждая работает со своим флешем, и у каждого флеша свои заморочки (с момента изготовления и накопившиеся во время использования).

 

Quote

А если все карты приемники будут абсолютно одинаковые и одного производителя, то такой эффект тоже возможен?

Даже теоретически, этот эффект просто обязан быть, а не только "возможен". Стратегически неправильно надеяться, что карты поведут себя одинаково.

 

Quote

Или готовности абсолютно не предсказуемы?

Именно так. Абсолютно непредсказуемы. И меняются со временем.

 

Для развлечения можете попробовать программы типа "DiskGenius" - он умеет проверить карту на bad blocks, и одновременно можно получить табличку, сколько времени к какому блоку шло обращение. Это время разное по карте, и оно меняется во время эксплуатации: у вполне рабочих карт время доступа может составлять единицы секунд к некоторым (часто используемым) блокам. И это я про чтение, а не про запись!! :)

Так что Вы должны быть готовы к ожиданию, причем рандомному и большому.

 

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

 

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

 

Кстати, убедитесь что используете не CMD24 (WRITE_SINGLE_BLOCK), а именно CMD25 ("WRITE_MULT_BLOCK").

 

41 minutes ago, Freibier said:

Ну так я и сейчас всем одновременно отправляю, пока какая либо BUSY не выставит.

Не, так у Вас быстро не будет. Каждая карта должна иметь свой буфер (ну или свой указатель чтения  в общем буфере), и работать со своей порцией данных.

[Freibier 3]

7 минут назад, Ruslan1 сказал:

Кстати, убедитесь что используете не CMD24 (WRITE_SINGLE_BLOCK), а именно CMD25 ("WRITE_MULT_BLOCK").

Ну конечно же CMD25 приемникам, CMD18 источнику.

Спасибо за информацию, но бегать по кругу уже наверно буду как нибудь в другой раз. )

16 минут назад, Ruslan1 сказал:

у вполне рабочих карт время доступа может составлять единицы секунд к некоторым (часто используемым) блокам. И это я про чтение, а не про запись!! :)

А вот это новость для меня!

Вроде же в спецификации где-то проскакивало про всякие тайм ауты не больше 100 мс.

А Вы про секундные задержки и при чтении!?

Такие огромные задержки точно допускаются спецификацией?

[Longiel 2]

10 минут назад, Freibier сказал:

На первом такте защелкиваю DAT0-3 источника в триггере плис, на следующем выставляю на линии всех приёмников.

...

тут уже надо и жирный проц ставить с кучей памяти... Всю логику на плис реализовать, и память к плис подключить?

Можно обойтись одной логикой в ПЛИС. Ввиду незнания аппаратной реализации не буду претендовать на корректность решения, опишу просто идею\архитектуру.

По команде ПЛИС должен получать кусок данных с сохранять в свой буфер (не внешняя память, отдельной микросхемой, а реализация блочной или распределённой памяти внутри ПЛИС - всего несколько строк кода). После загрузки буфера стартует алгоритм выгрузки. Выставили данные всем флешкам и ждёте когда кто освободится. Как только какая-то флешка освободилась - из памяти запросили очередные данные, запомнили адрес памяти для этой флешки. Ждёте дальше. И так - пока все данные не будут переданы. Разные флешки будут тормозить передачу в разные моменты времени. В вашей первой реализации все эти задержки суммировались, поэтому время неприлично вырастало. В этой реализации пока тормозит одна флешка данные выгружаются на другие, когда начнёт тормозить вторая флешка, то всё повторится, но так как на вторую флешку поток данных "ушёл вперёд" относительно первой, то теперь для первой флешки поток будет "нагонять", выравниваться с переданным объёмом данных на вторую флешку. Таким образом к финишу - опустошению буфера - флешки придут как-то +/- ровно по времени передачи на них данных - объём данных и сам алгоритм выгрузки сглаживает торможение потоков отдельных флешек вплоть до его полного нивелирования этих тормозов. Можно поставить буферы на каждый поток данных, убрав арбитраж в алгоритме выгрузки и, в какой-то мере, упростив его.

[Freibier 3]

 

7 минут назад, Longiel сказал:

Можно обойтись одной логикой в ПЛИС.

Спасибо. Надо будет как-то попробовать.

[Longiel 2]

Я не знаю какой у вас ПЛИС, наверное не очень мощный под такие задачи, но возможно и не нужен буфер на мегабайты - может быть хватит несколько блоков BRAM и этих десятков килобайт хватит для получения приемлемого результата.

[Freibier 3]

10M02SCE144 у него всего 109 Kb (

Ни какой вменяемый буфер не организуешь.

[iiv 19]

2 hours ago, Freibier said:

109 Kb

если посчитать, что 64К - это примерно так, что k=64К/512(сектор), 512*k*k=1GB, то исходя из распределения Гаусса, уже с буфером в 64К вы ускоритесь примерно на треть. Конечно мороки будет ммного.