[haker_fox 60]

Не особо большой.

Кстати! Стоп :rolleyes: Отклик R мы ещё можем через DMA "ждать", т.к. оверхед будет не более 8 байт. А вот как тогда ждать Data Response Token Start Block Token и т.п., да ещё и следовать логике их обработке. Честно говоря, у меня в голове уже не укладывается, как тут DMA использовать. Тем более эти "токкены" не приходят в течение 8 байт. Значит издержки будут уже больше.

Процессор STM32L476 просыпается на время измерения и записи в SD.

Возможно всё это зависит от SDIO, а следовательно - от модели микроконтроллера.

И да, всё-таки не процессор :rolleyes:

[jcxz 184]

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

Да ладно! Так уж и в два раза? Как измеряли? :rolleyes:

А сколько из всего этого времени что нужно на измерение, обработку, запись (особенно через ФС) составляет собственно пересылка? Сколько %? Я собственно об этом и писал - читайте внимательнее.

А сколько нужно времени на включение и стабилизацию питания карты?

А после записи нужно ещё дождаться статуса "завершение записи", время появления которого вообще никак не связано со скоростью пересылки, а только со скоростью карты. Ну сэкономите целых 10мкс на пересылке, а карта писать/стирать будет ещё 200мс. :biggrin:

И сколько процентов прироста скорости даёт SDIO vs SPI? 1% или целых 2%? Боюсь что даже 1% выигрыша не будет от SDIO.

[aaarrr 63]

И сколько процентов прироста скорости даёт SDIO vs SPI? 1% или целых 2%? Боюсь что даже 1% выигрыша не будет от SDIO.

На чтении внезапно дает примерно столько, во сколько раз больше линий передачи.

 

Просто полный набор штампов:

SD - плохо, лучше SPI

FS - плохо, будем колхозить свой велосипед

Скорость больше 1Мбайт/с в эмбеддед не бывает и не нужна

 

Это для PIC16 актуально, а не для STM32F4.

 

P.S. SD, не SDIO

[jcxz 184]

На чтении внезапно дает примерно столько, во сколько раз больше линий передачи.

На чтении чего? Какая прикладная задача? В синтетическом тесте? И кто бы сомневался.

И вообще-то отвечаете Вы на пост о системе сбора информации. На кой там чтение???

 

Просто полный набор штампов:

SD - плохо, лучше SPI

Вы похоже не умеете читать... Где я писал что "плохо" или "хорошо"? Ещё раз- я писал: в большинстве прикладных задач время передачи данных по интерфейсу карты - не принципиально, так как вносит очень малый вклад в общее быстродействие задачи.

Если есть что сказать по теме - расскажите в каких таких задачах бОльшая скорость чтения по SDIO принесёт заметный плюс?

 

Это для PIC16 актуально, а не для STM32F4.

Это актуально для чего угодно, пока не изобрели МК с бесконечно большим числом ног.

[aaarrr 63]

И вообще-то отвечаете Вы на пост о системе сбора информации. На кой там чтение???

Думаете, запись не ускорится? Ускорится, просто не так показательно.

 

Вы похоже не умеете читать... Где я писал что "плохо" или "хорошо"? Ещё раз- я писал: в большинстве прикладных задач время передачи данных по интерфейсу карты - не принципиально, так как вносит очень малый вклад в общее быстродействие задачи.

Вы писали буквльно следущее:

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

А это, уж извините, бред. Не вносит FS заметного оверхеда, как раз таки единицы процентов.

 

Это актуально для чего угодно, пока не изобрели МК с бесконечно большим числом ног.

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

Да, а ручной подсчет CRC не напрягает?

[haker_fox 60]

Так используйте однобитный SD для экономии.

Кстати, а это идея!

В проекте, над которым работаю, хоть и получил масштабный опыт руления через один SPI низкоскоростными (сигма-дельта АЦП) и высокоскоростными (NAND, SD) устройствами, переключениями на одни и те же ножки SPIFI прямо по ходу работы, всё же лишний раз такое насильно бы повторять не стал))))

[jcxz 184]

Думаете, запись не ускорится? Ускорится, просто не так показательно.

Ага, не на 2%, а на 1% :biggrin:

Какой процент времени при записи на карту составляет время пересылки по интерфейсу в общем времени включения карты+пересылки+ожидания_завершения+выключении?

 

Вы писали буквльно следущее:

А это, уж извините, бред. Не вносит FS заметного оверхеда, как раз таки единицы процентов.

Да ладно - единицы процента? :biggrin:

Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим что при каждом просыпании система пишет один сектор данных в файл, после чего засыпает. Перед засыпанием закрывает файл, получается - обновляется запись каталога (дата/время файла+размер) и FAT-таблица (размещение). Итого - получаем запись до 3-х секторов вместо одного если бы делали просто на кольцевой цепочке секторов.

И не надо выдёргивать мои слова из контекста. Главный смысл их был в том, что выигрыш по скорости обмена по интерфейсу карты незначителен для большинства прикладных embedded-задач.

"Прикладная задача" к Вашему сведению - это не запись или чтение файла. Или может Вы в руководствах по эксплуатации своих устройств пишете "оно пишет и читает файлы со встроенной SD". :biggrin:

Если карта внутренняя, то заказчику фиолетово - пишет оно файлы или что-то другое, ему важна функция, которую оно реализует.

А вот решение этой функции через ФС очень часто приводит к увеличению оверхеда по чтениям/записям. Поэтому я и говорю, что работа с SD наиболее оптимальным для задачи способом, а не обязательно через ФС, может даст гораздо бОльший выигрыш в плане общей скорости работы.

 

Да, а ручной подсчет CRC не напрягает?

Вы вообще о чём? Где я писал про ручной CRC? :wacko:

[aaarrr 63]

Ага, не на 2%, а на 1% :biggrin:

На 50%, например.

 

Да ладно - единицы процента? :biggrin:

Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим...

Предположим, спит, предположим, выключает при этом питание, предположим, закрывает и не кэширует. Что еще предположим?

 

"Прикладная задача" к Вашему сведению - это не запись или чтение файла. Или может Вы в руководствах по эксплуатации своих устройств пишете "оно пишет и читает файлы со встроенной SD". :biggrin:

Вы, надо полагать, в руководствах пишете: "для извлечения информации со встроенной SD-карты воспользуйтесь утилитой XXX (протестировано на Windows 7, требует прав администратора)".

 

Если карта внутренняя, то заказчику фиолетово - пишет оно файлы или что-то другое, ему важна функция, которую оно реализует.

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

 

Вы вообще о чём? Где я писал про ручной CRC? :wacko:

А где я писал про включение-выключение питания?

[jcxz 184]

Вы, надо полагать, в руководствах пишете: "для извлечения информации со встроенной SD-карты воспользуйтесь утилитой XXX (протестировано на Windows 7, требует прав администратора)".

Я ничего не пишу, так как встроенная карта == неизвлекаемая карта.

 

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

Может объясните это Micron-у, что его e.MMC чипов не должно быть? Оне же намертво припаиваются! как можна! :biggrin:

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

 

А где я писал про включение-выключение питания?

Вы даже не соизволили обратить внимание к чему относился мой пост на который Вы изначально решили ответить? Если бы соизволили, то увидели бы что это был ответ на сообщение системе сбора данных на SD с режимом энергосбережения.

И изначально я спрашивал: приведите реальные примеры где высокая скорость обмена по интерфейсу даст реальный выигрыш. На что и был приведён тот пример.

Стоит хоть немного читать то, на что отвечаешь....

[Aner 3]

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

Намертво припаянные регулярно встречаю в серийных изделиях. Далеко ходить не нужно берем DJI и его дроны, Фантомы 3, 4, Мавики ... ; катры 16Gb, 32Gb micro SD внутренние запаяны намертво, + наружные в разъеме. Нехило так, внутри до 4 ARM процов сидит в одном изделии.

[Vasil_Riabko 11]

Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим что при каждом просыпании система пишет один сектор данных в файл, после чего засыпает. Перед засыпанием закрывает файл, получается - обновляется запись каталога (дата/время файла+размер) и FAT-таблица (размещение). Итого - получаем запись до 3-х секторов вместо одного если бы делали просто на кольцевой цепочке секторов.

Файл не закрывается, питание с карты не снимается, дописывется 16 кбайт в конец файла( каждые пол часа проводится закрытие файла ). Частота ЦП скорость SDIO оптимизированы с целью увеличения времени непрырывной работы . Конкретно в этом примере переход отSPI к SDIO даловозможность увеличить время автономной работы .

[aaarrr 63]

Может объясните это Micron-у, что его e.MMC чипов не должно быть? Оне же намертво припаиваются! как можна! :biggrin:

Стесняюсь спросить, а почему, например, не Samsung'у или Toshib'е?

 

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

Карты превращаются в eMMC, а потом снова в карты. Но в ящике.

 

Вы даже не соизволили обратить внимание к чему относился мой пост на который Вы изначально решили ответить? Если бы соизволили, то увидели бы что это был ответ на сообщение системе сбора данных на SD с режимом энергосбережения.

Почему же, обратил. И именно в вашем ответе внезапно возникло включение и выключение питания карты.

Но и до этого много прекрасного, не мог пройти мимо:

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

А писать это дело в FatFS, внутренние операции которой Вы не контролируете - это стрелять себе в ногу.

25МГц - это всего-лишь SCLK. При этом получается скорость передачи около 1МБ/сек.

Очень сильно постараться надо, чтобы получилось настолько плохо.

значительно бОльший расход пинов

В 1-битном режиме он таки меньше

[jcxz 184]

Файл не закрывается, питание с карты не снимается,

Тогда о чём разговор? Зачем тогда процессор усыплять если невыключенная карта сожрёт в разы больше энергии?

И если файл не закрывается, то что с этим файлом будет если карту возьмут и выдернут когда этот файл не закрыт?

Или у Вас она - встроенная и её нельзя внезапно выдернуть? Так ув. aaarrr запретил так делать! :biggrin:

И если Вы не послушались aaarrr и она всё-таки встроенная, то зачем тогда там вообще ФС?

 

Конкретно в этом примере переход отSPI к SDIO даловозможность увеличить время автономной работы .

Ну да - а невыключение карты сократило это время в разы больше чем получили выигрыш от SDIO. Опять экономия на пуговицах.

 

В 1-битном режиме он таки меньше

И можно обойтись всего одним пином??? Нет? А с SPI - можно (дополнительным CS), так как это - шина, и на неё можно повесить несколько слэйвов.

[aaarrr 63]

И можно обойтись всего одним пином??? Нет?

Забыли посчитать тот пин, которым выключаете питание :biggrin:

 

А с SPI - можно, так как это - шина, и на неё можно повесить несколько слэйвов.

Можно. Но если карта не припаяна к плате (а я ведь запретил :) ), то придется раскошелиться еще и на буфер.

[jcxz 184]

Забыли посчитать тот пин, которым выключаете питание :biggrin:

Хммм... а SDIO позволяет выключать без пина? :05:

 

Можно. Но если карта не припаяна к плате (а я ведь запретил :) ), то придется раскошелиться еще и на буфер.

Зачем буфер? И что за буфер?

 

ЗЫ: При большой необходимости, питание можно CS-ом отключать (транзисторный ключ или LDO с фильтром на питание карты). И доп. пин не нужен.