[MrYuran 16]

Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает ;)

Приклеить на компаунд или липучку

[AlanDrakes 1]

Помнится мне, что вся работа с секторами происходит в файле ff.c, а работа с низкоуровнемыми командами записи - в diskio.c, где уже Вы, по желанию, можете делать запись мультисекторно, или посекторно.

 

При наличии больших буферов ФС - драйвер технически может вызывать функцию disk_write с параметром "Количество секторов", отличным от единицы.

Фактически, единственный такой вызов я нашёл в функции f_write() в том случае, если ЕСТЬ свободные сектора, куда это поместится, и размер данных больше чем на один сектор.

 

Так что, весь разбор что и куда писать, находится выше. Драйверу же карты передаются только команды "Пиши вот это, вот сюда, в таком-то количестве".

[GenaSPB 11]

"Пиши вот это, вот сюда, в таком-то количестве".

Пиши вот это, вот сюда, в таком-то количестве, подряд с указанного места. Я пользуюсь - работяет.

Кстати, очень понравилось extFAT, там как раз нужно 64 битное смещение в seek

Изменено 3 сентября, 2018 пользователем Genadi Zawidowski

[haker_fox 60]

Пиши вот это, вот сюда, в таком-то количестве, подряд с указанного места. Я пользуюсь - работяет.

Кстати, очень понравилось extFAT, там как раз нужно 64 битное смещение в seek

Отлично! Значит библиотека ФС всё сама разруливает. Кстати, я не делал мультисекторную запись пока, но даже посекторная запись идёт со скоростью до 200 кбайт/сек. Что довольно шустро для моих задач)

[AlanDrakes 1]

Пилил я как-то свой тест скорости карточек. Не оптимальный до ужаса. Тем не менее, результат был таким:

File created.
Write test...
[0000000030.080] File write done. Total bytes written: 5242880 bytes. Time: 27684 ms. Avg: ~189 kBps
Read test...
[0000000036.114] File read done. Total bytes read: 5242880 bytes. Time: 6033 ms. Avg: ~869 kBps

 

Здесь кристалл работал на ~96МГц, возможно, меньше. SDIO тактировалось от PLL на 48МГц.

Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно.

 

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

[haker_fox 60]

Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно.

Эх... SDIO это совершенно другой полёт. Как правило, все неприятные нюансы (таймауты, ожидание откликов (R1, R2...)) оно на себя берёт. Да ещё + DMA. С SPI, конечно, тоже можно DMA включить на передачу чисто блоков, но драйвер уж сильно замороченный выходит...

[jcxz 182]

С SPI, конечно, тоже можно DMA включить на передачу чисто блоков, но драйвер уж сильно замороченный выходит...

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

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

[klen 1]

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

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

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал!

нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого :laughing:

как я говорил, теперь попробую eMMC микросхемку запустить вместо сокет+карта. так выглядеть поприличнее будет, как мне кажется.

 

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

[aaarrr 62]

Почему оно одинаково работает, и зачем тогда два отдельных отдельных метода?

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

[mantech 33]

Да держится прекрасно :laughing: И тряску прошла...

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

[jcxz 182]

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал!

У Вас как-то видимо неправильно составлено ТЗ. Заказчик должен заказывать функционал, а не способы его реализации. А уж способы реализации должен выбирать инженер исходя из требований ТЗ и здравого смысла. И как подключено некое ЗУ или его тип, объём - это однозначно должен определять инженер, а не заказчик. Заказчик в ТЗ должен только указать: необходима фиксация данных телеметрии в энергонезависимой памяти в течение не менее чем такого-то времени и такие-то и такие-то параметры (как то так). А уж как это делать и куда сохранять - забота инженера (программиста).

 

нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого

Вполне нормально писали текущую телеметрию во FRAM+FLASH по SPI без каких-то проблем.

А писать это дело в FatFS, внутренние операции которой Вы не контролируете - это стрелять себе в ногу. Или заказчику, который не умеет грамотно составить ТЗ. И разработчик занимается натягиванием FatFS, вместо обеспечения хранения потока телеметрии, устойчивого к авариям питания (без всяких FS).

[Arlleex 131]

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

Они феном паялись :rolleyes:

А о каком "фирмварь" идет речь?

[mantech 33]

Они феном паялись :rolleyes:

А о каком "фирмварь" идет речь?

Как-то читал атмеловский даташит по пайке, так там очень не советовали паять в печи запрограммированные МК по причине того, что может произойти искажение в флеш-памяти программы. Тут как-раз такой случай, в каждой карточке есть МК с программой, которая, как правило, находится в первых секторах нанда, и разметка бэд-блоков и пр. тоже там, она и может испортится, по крайне мере на 1 смартбае такое было, после пайки карта работала нестабильно и через непродолжительное время ушла в "рид-онли"...

 

Конечно есть другое дело - е-ммс - там должно быть предусмотрена печная пайка, но х.з. может там и техпроцесс какой-то другой...

[Axel 1]

...Заказчик должен заказывать функционал, а не способы его реализации. А уж способы реализации должен выбирать инженер исходя из требований ТЗ и здравого смысла...

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

[jcxz 182]

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

А каким образом SDIO выигрывает у SPI в плане "защиты информации"? Защиты от чего/кого? :wacko:

Или выигрывает FatFS? Так если под "защитой" иметь в виду защиту от несанкционированного доступа, так FatFS наоборот проигрывает самопальному формату хранения.