stm32f4 + Chan's FatFS, работа с большими SD картами Опции

[klen]

Здравсвуйте!
с флехами размером 4 гигабайта работает все хорошою с большими 16/32 и тд начинаются глюки.
при отладке выловил в функции clst2sect что индекс сектора становится выше диапазона и FatFS вываливается с ошибкой FR_INT_ERR
это я что то не так делаю или это не только у меня?

[haker_fox]

Вы не поверите, но и на приём - тоже можно!

Поверю!

SDIO мало где реально нужно в embedded области.

Как я понимаю, SDIO даёт более высокую скорость, ведь SPI это только 25 МГц максимум + полупрограммные издержки.
Мне пришлось делать на SPI, т.к. дали такое железо. Если бы я имел право выбирать, то настоял бы на SDIO, т.к. придерживаюсь принципа: аппаратный блок справится с задачей лучше, чем софтварная реализация. Хотя, есть исключения.

[jcxz]

Как я понимаю, SDIO даёт более высокую скорость, ведь SPI это только 25 МГц максимум + полупрограммные издержки.

О каких издержках речь?
25МГц - это всего-лишь SCLK. При этом получается скорость передачи около 1МБ/сек. Можете привести пример в каких именно embedded-задачах (на МК из заголовка темы) дальнейшее увеличение скорости передачи выше означенного 1МБ/сек приведёт к заметному увеличению скорости работы прикладной задачи с картой? Не тест скорости, не высосанную из пальца задачу - сферического коня в вакууме, а реальную задачу?
Скажем: чтение конфига-файла и старт устройства по SPI выполнялся за 2 секунды, а та же задача, но по SDIO - 1 секунда?
Могу Вас разочаровать, но при таких скоростях обмена, значительную величину начинает занимать остальная обработка (не собственно задержка связанная с передачей) и низкоуровневого драйвера SD и всего что выше него. Тем более там ещё FatFS болтается. И увеличение в скорости передачи карты даст выигрыш общей производительности прикладной задачи всего несколько % в большинстве embedded-задач.
Если уж есть нужда в увеличении скорости обмена с картой, то первым делом нужно от FS избавляться.

Мне пришлось делать на SPI, т.к. дали такое железо. Если бы я имел право выбирать, то настоял бы на SDIO, т.к. придерживаюсь принципа: аппаратный блок справится с задачей лучше, чем софтварная реализация.

Так SPI-контроллеры обычно тоже в МК аппаратные, не надо ногодрыгать.
Да и правильно что Вам дали, так как "аппаратный блок справится с задачей лучше" - не аргумент. Не блок справляется с задачей, а программист. А при выборе способа решения исходят из того сколько то или иное решение займёт ресурсов (времени МК, количества ног или интерфейсов). И какие из этих ресурсов наиболее важные/дефицитные в данной задаче. А какой-то блок там справится или нет - не аргумент, не справиться может только программист.

[haker_fox]

О каких издержках речь?

Да хотябы циклически ждать (до 64 циклов SCLK) отклик от карты (R0, R1...). Это же надо отправлять по шине 0xff, читать данные, и проверять MSB. По любому нужно либо прерывание каждый принятый байт дёргать (и там проверять), либо в основном цикле. Я не знаю иного способа. Считаю, что это издержки.

Можете привести пример в каких именно embedded-задачах (на МК из заголовка темы) дальнейшее увеличение скорости передачи выше означенного 1МБ/сек приведёт к заметному увеличению скорости работы прикладной задачи с картой? Не тест скорости, не высосанную из пальца задачу - сферического коня в вакууме, а реальную задачу?

К сожалению, нет. Всё вышесказанное является лишь моим мнением.

Так SPI-контроллеры обычно тоже в МК аппаратные, не надо ногодрыгать.

Да, но SPI, на мой взгляд, является "побочным" интерфейсом для SD-карты, идущим из далёкого прошлого. Поэтому, если есть SDIO в МК, его лучше использовать.

Да и правильно что Вам дали

Ну дали не потому, что это правильно. А банально не осталось свободных пинов у МК. Вот на SPI и навесили "остатки". А мне потом ещё пришлось доводить систему на макетке - добавить буфер (т.к. внутреннюю шину просто вывели на улицу, что вносило сбой в работу при установке карты, а также давало возможность подпитывать её паразитным питанием) и сделать некоторые другие доработки.

А какой-то блок там справится или нет - не аргумент, не справиться может только программист.

Ну как посмотреть. Где-то на форуме уважаемый Rst7 лет 10 назад приводил код, который отправляет, и (не очень стабильно) принимает манчестер для 10 Мбит Ethernet. Для этого использовался аппаратный UART. Ну если он справился да ещё и на 8-битной AVR'ке, почему бы в современных "толстых" армах не использовать подобное решение. Не везде ведь нужно 100 или более Мбит. А UART'ов даже в маленьком МК Cortex-M0 как правило не менее двух. И если будет работать неправильно, то - программист плохой. Не смог(((

[jcxz]

Да хотябы циклически ждать (до 64 циклов SCLK) отклик от карты (R0, R1...). Это же надо отправлять по шине 0xff, читать данные, и проверять MSB. По любому нужно либо прерывание каждый принятый байт дёргать (и там проверять), либо в основном цикле. Я не знаю иного способа. Считаю, что это издержки.

Не надо. Драйвер естественно должен использовать DMA. По завершению блока DMA анализировать полученные данные с SD и искать там первый не 0xFF. Программно это очень незначительно по времени, так как в цикл-е про-AND-ить 32-битные данные - ерунда.

Ну дали не потому, что это правильно. А банально не осталось свободных пинов у МК. Вот на SPI и навесили "остатки".

Вот я об этом и говорю: свободные ноги - это как правило очень ценный ресурс в МК и его дефицит был во всех моих проектах. Тем более - на SPI легко можно объединить несколько устройств на одной шине. А с SDIO - придётся пины только под SD отдать. И зачем?
А какое-то там "удобство" - это вопрос больше в компетентности программиста - ну будет немного больше строчек кода и всего-то.

Ну как посмотреть. Где-то на форуме уважаемый Rst7 лет 10 назад приводил код, который отправляет, и (не очень стабильно) принимает манчестер для 10 Мбит Ethernet. Для этого использовался аппаратный UART. Ну если он справился да ещё и на 8-битной AVR'ке, почему бы в современных "толстых" армах не использовать подобное решение. Не везде ведь нужно 100 или более Мбит. А UART'ов даже в маленьком МК Cortex-M0 как правило не менее двух. И если будет работать неправильно, то - программист плохой. Не смог(((

Ну вообще-то - не могу знать о каком Ethernet идёт речь. Есть множество внешних Ethernet-чипов с логикой Ethernet внутри. И если такой Ethernet предполагает подключение по UART - то так и следует подключать. О чём разговор? Мы в каких-то из своих проектов использовали внешний чип Ethernet с подключением по SPI и что? Хотя при этом в МК был аппаратный Ethernet и даже со встроенной физикой. Но по требованиям ТЗ он не походил. Поставили внешний.

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

Не надо. Драйвер естественно должен использовать DMA. По завершению блока DMA анализировать полученные данные с SD и искать там первый не 0xFF. Программно это очень незначительно по времени, так как в цикл-е про-AND-ить 32-битные данные - ерунда.

Я мимо проходил, протокола не знаю, просто смотреть последний байт блока недостаточно?

[jcxz]

Я мимо проходил, протокола не знаю, просто смотреть последний байт блока недостаточно?

Я тонкостей уже не помню, но насколько помню байт статуса там передаётся только один раз. По смещению от 0-го до некоторого N-го клока SCLK от конца фрейма. Да и вроде он имеет смещение кратное 8 клокам.

Вернее не просто CLK, а 0xff передавать на карту?!

Естественно. Команды должны отсутствовать.

Я вас понял, из двух разрешённых интерфейсов вы просто предпочитаете использовать тот, который наиболее удобен.

При прочих равных требованиях - всегда предпочитаю использовать тот интерфейс, который требует меньше ресурсов. Так как их всегда не хватает. Чтоб потом не переделывать всё. Сколько тут на форуме уже слышал воплей от новичков "девайс уже сделан, и когда делали не подумали что нужно будет ещё и это и то, а теперь ног/интерфейсов/памяти/... не хватает. И как мне прикостылить ещё и эту плюшку ведь заказчику очень нуно?".
Единственный плюс SDIO в сравнении с SPI - бОльшая низкоуровневая скорость. А как я говорил выше - для embedded это редко реально нужно. Да и низкоуровневая скорость, при использовании кучи довесок сверху в виде ФС и пользовательского кода, в результате скорей всего будет очень мало влиять на общее быстродействие системы. Увеличите low level скорость в 2 раза, а общее быстродействие вырастет на пару %. А цена при этом - значительно бОльший расход пинов.