Перейти к содержанию
    

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

Поверю! :rolleyes:

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

SPI это только 25 МГц максимум

50, hi-speed применим и для режима SPI.

 

И SD, конечно, а никак не SDIO. Почему-то постоянно встречаю эту ошибку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

50, hi-speed применим и для режима SPI.

Я ориентировался только на содержимое регистра, а там для любой из имеющихся у меня карт (в том числе SDXC) стоит 25 МГц. Можно подробнее, видимо я чего-то не знаю.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Скажем: чтение конфига-файла и старт устройства по SPI выполнялся за 2 секунды, а та же задача, но по SDIO - 1 секунда?

Могу Вас разочаровать, но при таких скоростях обмена, значительную величину начинает занимать остальная обработка (не собственно задержка связанная с передачей) и низкоуровневого драйвера SD и всего что выше него. Тем более там ещё FatFS болтается. И увеличение в скорости передачи карты даст выигрыш общей производительности прикладной задачи всего несколько % в большинстве embedded-задач.

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да хотябы циклически ждать (до 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-битные данные - ерунда.

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

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

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

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

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

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно подробнее, видимо я чего-то не знаю.

См. Switch Function Command (CMD6). Описание есть в т.ч. в Physical Layer Simplified Specification Version 2.00.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Ну да - это время потом понадобится. Когда ног не хватит и придётся всё переделывать. :biggrin:

Да и какая разница по затраченному времени - SPI или SD?

 

Нет, слишком много буков. Не осилю, после тренировки то. :rolleyes:

Да и вообще - там похоже что-то странное, вычурное, нетипичное использование периферии. Делать такое нужно или при реальной нужде или как хобби.

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

 

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

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

Опять-же - нигде в спецификации USB нет ни слова о реализации через UART. А для SD - SPI есть. :laughing:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

При прочих равных требованиях - всегда предпочитаю использовать тот интерфейс, который требует меньше ресурсов. Так как их всегда не хватает. Чтоб потом не переделывать всё. Сколько тут на форуме уже слышал воплей от новичков "девайс уже сделан, и когда делали не подумали что нужно будет ещё и это и то, а теперь ног/интерфейсов/памяти/... не хватает. И как мне прикостылить ещё и эту плюшку ведь заказчику очень нуно?".

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Понятно, я как-то не понял из спецификации, что на карту можно гнать 0xff, и она это нормально пережуёт) Хотя из того, что есть стартовый и стоповый биты в посылке, это как бы следует)

А цена при этом - значительно бОльший расход пинов.

Чтож, я чувствую, что у вас бОльший опыт работы с SD, чем у меня :rolleyes: Приму к сведению. Доселе был уверен в обратном (не про опыт, про преимущества SDIO))))))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чтож, я чувствую, что у вас бОльший опыт работы с SD, чем у меня :rolleyes: Приму к сведению. Доселе был уверен в обратном (не про опыт, про преимущества SDIO))))))

Не особо большой. Просто года 3-4 назад делал девайс с SD, писал lowlevel-драйвер (LPC17xx), накатывал поверх него FatFS, тестил скорости. И что-то ещё помню :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Единственный плюс SDIO в сравнении с SPI - бОльшая низкоуровневая скорость. А как я говорил выше - для embedded это редко реально нужно.

 

Вы не правы . Например: автономная система сбора информации с сохранением на SD. 400 раз в секунду измерить напряжение (3 канала по 16 бит) накопить в буфер и переписать в SD. Процессор STM32L476 просыпается на время измерения и записи в SD. Применение SDIO в два раза увеличивает продолжительность автономной работы при заданном источнике питания.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...