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 и даже со встроенной физикой. Но по требованиям ТЗ он не походил. Поставили внешний.

[haker_fox]

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

Т.е. вы предлагаете при ожидании отклика просто вычитать априори 8 байт (64 цикла). Затем, по завершению посылки, найти первый с MSB=0? Я просто не предполагал, что так можно. Я думал, что как только мы встретили первый не 0xff, то следует сразу остановиться, и перевести cs в 1. Гм... если это так, то просто супер!!!

А какое-то там "удобство" - это вопрос больше в компетентности программиста - ну будет немного больше строчек кода и всего-то.

Пока остаюсь при своём мнении. Ведь время программиста тоже денег стоит. И проект ещё сопровождать надо. И исправлять ошибки. И добавлять функции. А так - бухнул сразу чип, подходящий по периферии, и всё.

Ну вообще-то - не могу знать о каком Ethernet идёт речь.

Вот, самый первый пост. Буквально несколько первых предложений. Хотя, давно это было. И при более внимательном чтении вспомнил, что у Rst7 всё-таки не получилось полностью реализовать программно-аппаратный PHY.


Помню, давным давно, на AVR'ках делали программный USB device, HID. Вот мне тут подумалось, что такое можно сделать в одной из недорогих поделок на STM32F051. Правда я хочу 2 CDC (композит). Но, наверно, ничего не получится. Но пока прицениваюсь. Это как раз тот случай, когда аппаратный модуль просто отсутствует.

[jcxz]

Т.е. вы предлагаете при ожидании отклика просто вычитать априори 8 байт (64 цикла). Затем, по завершению посылки, найти первый с MSB=0? Я просто не предполагал, что так можно. Я думал, что как только мы встретили первый не 0xff, то следует сразу остановиться, и перевести cs в 1. Гм... если это так, то просто супер!!!

Нет. Почитайте спецификацию внимательнее - CLK можно гнать сколько угодно. Мой драйвер так и работал. Только не помню - 64 или больше, пока не найдётся !=0xFF.

Пока остаюсь при своём мнении. Ведь время программиста тоже денег стоит. И проект ещё сопровождать надо. И исправлять ошибки. И добавлять функции. А так - бухнул сразу чип, подходящий по периферии, и всё.

Ну да - это время потом понадобится. Когда ног не хватит и придётся всё переделывать.
Да и какая разница по затраченному времени - SPI или SD?

Вот, самый первый пост.

Нет, слишком много буков. Не осилю, после тренировки то.
Да и вообще - там похоже что-то странное, вычурное, нетипичное использование периферии. Делать такое нужно или при реальной нужде или как хобби.
А подключение SD на SPI - это вполне себе штатный способ подключения, прописанный в спецификации. Так что это совсем из другой оперы.

Помню, давным давно, на AVR'ках делали программный USB device, HID. Вот мне тут подумалось, что такое можно сделать в одной из недорогих поделок на STM32F051.

Читал про такое. Тоже имхо - бессмыслица. Ибо - никакого профита на ARM7 в которых как правило есть USB. Во-вторых - там вроде даже не FullSpeed, а LowSpeed да ещё с какими-то ограничениями и косяками (вроде грузит процессор сильно). Т.е. - опять для практического использования бесполезная вещь.
Опять-же - нигде в спецификации USB нет ни слова о реализации через UART. А для SD - SPI есть.

[haker_fox]

Почитайте спецификацию внимательнее - CLK можно гнать сколько угодно.

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

А для SD - SPI есть.

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

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

Вроде как нет, отклик на команду появляется однократно в течение 8 байт.