Поздравляю всех с майскими праздниками!
Тема для тех, кто даже по праздникам не забывает об электронике

По Т.З. девайс должен собирать информацию с датчика...и когда собранный лог достигнет размера в 32 Мб - нужно это все передать на ПК, и так далее по циклу.

Для решения задачи в качестве накопителя был выбран Samsung K9F1G08U0C.
Ну а в качестве контроллера - stm32f103vct6. Поскольку у него имеется встроенный fsmc интерфейс. Передавать данные на ПК планируется через USB интерфейс (пока не знаю в каком режиме / было бы идеально, если бы доступ к данным осуществлялся, как у обычной usb флэшке).

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

по поводу выбора накопителя: у stm32f103 sdio же есть, не?
за те же 5$ microSD карточка на 8ГБайт.

В первую очередь стОит обратить внимание на количество циклов записи на флешь.
Если Вы хотите делать FAT на флеше, то это очень быстро убъет ее (наверно можно эмулировать FS в ОЗУ).
Можно использовать специальные FS, но тогда появляются проблемы с виндой.
А SD медленнее чем отдельная микросхема, современные карты большого объема имеют еще меньше циклов записи, а встроенный контроллер может делать выравнивание износа, а может и не делать, как дядюшка Ляо запилит...
Если есть возможность поставить отдельную микросхему, я бы не использовал SD.

Я делал логер, и флешь использовал просто как кольцевой буфер (равномерный износ). Связь с PC по Bluetooth (UART), так что насчет USB не подскажу.

К тому же "+" в пользу паянного соединения для микросхемы памяти по отношению к разъемному соединению на SD.
Т.е. городит FS нет смысла? Просто использовать как массив байт? Тогда остается вопрос, как в ПК передать по USB (виртуальный com - не хотелось бы \ в идеале было бы средствами самой операционки собирать данные в файл)?

З.Ы. Только сейчас заметил, что тема-то = ... да простят меня админы и перенесут тему в раздел (ARM) ... каюсь

Какая у вас скорость поступления данных с датчика? Может достаточно будет SPI-флешки?

Для USB, в качестве отправной точки, можно взять пример Mass Storage, который идет с библиотекой. И либо общаться с устройством как с RAW диском, тогда приложению потребуются админские привилегии (в win7) и система при подключении устройства будет предлагать отформатировать диск. Последнее обходится созданием фиктивной файловой системы - в начале диска, на десяток килобайт, лишь бы система увидела что раздел есть и не паниковала. Либо заюзать libusb.

Подумайте о eMMC , вроде MTFC2GMVEA-0M
Их используют в смартфонах.
Поверх можно поставить даже FAT без последствий.
Даташиты и спецификации открыты.

Вариант интересный конечно, но надо учитывать, что при этом возрастают требования к самой печатной плате устройства (у eMMC BGA-корпус).

Скорость ... около 64 байт в секунду



Мне этот вариант нравится. А в Lin будет сие чудо работать?

to AlexandrY = и таки-да ... BGA не хотелось бы.

Звбавно. И куда Вы этот Lin прилепите? Ну USB и FS вроде бы понятно зачем. А Lin то тут каким боком вылез.
Максимальная скорость Lin 38400 bod. плюс накладные расходы на протокол. И максимум что Вы получите 1 кбайт в сек, Вас устроит такая скорость ?

Как Flexz и предложил, можно использовать Mass Storage Class в рамках библиотеки поддержки USB для STM32F. При этом PC "видит" устройство как обычный сменяемый носитель ("флэшку"). STM32F пишет через встроенную файловую систему (например, fatfs, на которой построены многие примеры для STM32F) на SD карту или eMMC файл протокола, и его можно будет считать в PC. Есть, однако, одна загвоздка. Не знаю, как Linux, но Windows кэширует FAT сменяемого носителя, в результате она не видит изменения на диске, если STM32F модифицирует его дальше. По крайней мере, мне не удалось еще заставить Windows понять, что носитель изменен "изнутри".

Единственная возможность - сделать reconnect: как только STM32F заполнит очередной протокол (Ваши 32МБ), он делает connect (фактически - подает там 3V через 1.5К на D+ линию USB), Windows обнаружит USB устройство, смонтирует носитель, считает файл и должно затем размонтировать ("выбросить") устройство. STM32F это дело поймет (вроде поддержка Mass Storage Class это сообщит) и снова возьмет носитель под свою опеку. Конечно, на время, пока PC считывает диск, STM32F не следует на него писать, поэтому надо кэшировать Ваши 64 байта/сек. в ОЗУ, которое потом скинуть в файл, как только PC "отдаст" диск.

Модификация варианта: STM32F создает ДВА виртуальных диска на одном носителе. Mass Storage Class монтирует один диск, а STM32F пишет через fatfs другой, и наоборот.

Берете eye wi карту и идти курить пиво. Работать китайцы должны

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

Внутри файла писал по кольцу через все тело файла это давало равномерный износ флэшки. Флэшку можно было читать обычным карт ридером, но если было бы усб, можно было спокойно сделать картридер-масторадже.

А еще мы в качестве ОЗУ часто SPI - FRAM используем, но они 1 мегабайт макс... Но если поставить 32 штуки.... %)

Тем более что если флешка смонтирована, то писать на нее другим нельзя.

Может это попробовать?
http://ru.wikipedia.org/wiki/Media_Transfer_Protocol

Хотя я думаю что наиболее простой метод - написать свой софт под винду или там линух чтобы данные вычитывать. Можно даже подумать над какой экзотикой, типа USB 2 UART и сбрасывать данные через Xmodem к примеру.

Это конечно шутка, но есть доля смысла.

Зачем делать из USB mass storage если можно сделать RNDIS.
И использовать для скачивания файлов либо внутренний FTP сервер дивайса либо HTTP сервер.
Тогда не имеет значение какая файловая система в дивайсе хоть YAFFS, хоть SFFS или вообще без файловой системы.

Сложнее наверное трудно придумать.

Самая большая сложность тут это NAND Samsung K9F1G08U0C.
К примеру YAFFS2 по объему будет больше чем весть стек lwIP с WEB сервером и USB RNDIS.

"По Т.З. девайс должен собирать информацию с датчика...и когда собранный лог достигнет размера в 32 Мб - нужно это все передать на ПК, и так далее по циклу."
"Скорость ... около 64 байт в секунду"

Раз в 6 суток, скидывать инфу на комп. Можно хоть и через COM порт, можно через LAN. Но предпочтительней USB, так как COM уже на 98% ноутбуков умер как класс.
Вопрос напрашивается про работу компа, все 6 суток он будет включен? Ежели нет, и придёт кто то его включить, то уже не трудно будет нажать кнопку на устройстве (запустить утилитку) для активации процесса передачи данных. Память выбранна достаточная, поэтому если писать по кругу, её хватит на долго.
Но я бы предпочел совсем по другому делать.
Применил бы microSD.
Как советует Golikov A. отформатировал бы её, создал бы уйму 32 мегобайтных файла. Затем уже "удалив " их с файловой системы, (а удаление это всего лиш затирание первого указателя на цепочку), и уже своими средствами без участия ФАТ писал бы по цепочкам встёртый файл, а при его заполнении, востанавливал бы первый указатель, тем самым востанавливал бы файл в ФАТ. Ну а дальше по USB прикинулся бы масстораджем и скачивать этот файл.

Я бы QSPI подходящего объема взял. И кроме всего прочего, с Т.З. не совсем ясно, но может можно обойтись просто SD карточкой, которую физически вытаскивать из девайса и вставлять в PC. Ну или два гнезда для карточек и переключатель, куда писать.

А чего тут сложного то ?

Стек USB + стек TCP/IP + FAT. Плюс сложности для пользователя - воткнул, прописал IP, зашел через http или FTP...

Извиняюсь...я имел в виду ОС Linux.

to Golikov A. интересный вариант... но я , наверное, сделаю, чтобы файл создавался по правилам файловой системы с нуля, чтобы, если его удалят из операционки - stm32 сама бы его записала на nand.
Кстати, а как решалась проблема битых секторов? Насколько я знаю, в ядре Linux, например, проверяется nand и помечаются битые сектора, а потом операционка их обходит как-то... Или это в example от ST уже учтено как-то?

Принто.
А на счет китайцев - отличная идея. Покупаете тиббу, подпаивете флешку, пару дней потратите на бэйсик и все готово. Готовая сетевая хрень за 30 баксов с веб сервером ftp,udp,tcp,dhcp, а при желании у них же и wi fi имеется. Взгляните туда. мож и делать то ничего не надо www.tibbo.com Или взять популярную разбери пи (не помню точно название) ее еще малинкой называют.
PS: Я с этими игрушками уже играл, так что если заинтересует могу ответить на вопросы по тиббе.

А почему именно раз в 6 дней собирать? Связь с PC появляется раз в 6 дней?
Или связь постоянная, но возможно её пропадание и при этом надо обеспечить возможность накопления без связи до 6 дней?
Если связь с PC периодическая, то кто инициирует сеансы связи?
И почему FLASH? Возможны отключения питания? Как в таком случае планируете бороться с отключениями питания в момент записи на FLASH? Не боитесь порушить файловую систему, если таковая у вас будет использоваться?
Если нет каких-то религиозных причин обязательности FS, то имхо - она избыточна.
Храните как массив записей в ОЗУ (или, если необходима стойкость к отключениям, во FLASH). При хранении во FLASH за счёт формата хранения надо будет защититься от сбоев питания.
По USB (можете хоть через CDC хоть напрямую - через эндпоинты) пускаете свой протокол связи (и синхронизации) с PC. Всё равно у вас на PC есть какое-то ПО, которое собирает эти данные, так что писать на PC всё равно придётся. А уж протокол будет зависеть от частоты сеансов связи с PC, от того, кто инициирует сеанс связи и т.п.

У вас похоже обычная система сбора и передачи данных. Только требования к ней Вы изложили весьма поверхностно. И спрашиваете как её построить....

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

У нас стояла 1 мегобитная ФРАМКА в нее писали данные, когда накапливался размер нескольких кластеров СД карты, она включалась и данные туда заливались. После подтверждения записи, стирались из ФРАМки.

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


Флэшку используют потому что это самый дешевый и удобный способ добавить в систему памяти. В оперативку уже ДДР2 не найдешь, а уж про старые СРАМы уже и не вспомнить....

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

В любом случае было очень интересно выслушать разные мнения...спасибо за ответы!
Благодаря вашим замечаниям появилось много вопросов для уточнения...в общем картину я представил, а далее буду уточнять реализацию с заказчиком и работать над реализацией.

SD-карта есть просто память с контроллером. Какая часть этой памяти будет использована и под что, зависит от того драйвера, который направляет запросы чтения и записи блоков памяти в карту. Таким образом, можно создать две равные независимые области памяти на карте. В каждый момент времени для внешней программы/PC будет виден только один носитель, который будет иметь половинный размер карты. Получится, что если PC смонтирует носитель, фактически это будет означать, что запросы от PC будут перенаправляться лишь в ей доступную область карты: PC будет "владеть" областью монопольно. В это же время программа на STM32F будет общаться с другой половинкой карты. Нужно лишь обеспечить своего рода очередь к драйверу карты, если на STM32F используется какая-то ОС с вытеснением. Иначе все запросы могут обрабатываться синхронно (ну типа как в prototheads Адама Дункельса), и тема коллизий разрешится сама собой.
Но тема connect USB, монтирования и последующего выброса носителя программой на PC остается: STM32F заполнил файл протокола, переключил области в драйвере карты, дал connect на USB, а сам продолжил писать в другую область карты. PC увидела носитель, смонтирована его, прочитала файл и размонтировала. И т.д.