Блог

Недавно я использовал плату uALFAT microSD от GHI Electronics для ведения журнала данных, но у меня возникли проблемы с ее надежностью; некоторые вызовы ее функций иногда занимают гораздо больше времени, чем я могу обработать. В настоящее время я использую микроконтроллер MSP430 для взаимодействия с uALFAT.

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

или

Какое было бы наиболее выгодным OEM-решением, если бы мне понадобилось разработать собственную интерфейсную плату для работы с MSP430?

Я бы подумал об этом немного по-другому. Любое запоминающее устройство на основе флэш-памяти, вероятно, будет иметь переменную синхронизацию при записи. Особенно с файловой системой, выравниванием износа и подобными функциями. Как правило, это характерно для flash, поскольку вам приходится стирать целые блоки и перемещать предметы. Если вы не можете смириться с переменным временем, то, что я делал в прошлом, — это убрать этот фрагмент из критичной по времени части кода.

Обычно я добавляю очередь, в которую записывается критичный по времени код, а затем в фоновом режиме извлекаю из очереди и записываю на SD-карту. В RTOS это было бы задачей с более низким приоритетом. В цикле опроса это была бы функция, вызываемая, когда система находится в режиме ожидания.

Это изменяет ограничение с наихудшего времени для вызова функции на простое соответствие средним требованиям к пропускной способности для ведения журнала. Наихудшая задержка и пропускная способность определяют, насколько большой должна быть очередь; обычно она может быть небольшой.

Это, вероятно, сложнее, чем это, и лучшим решением является то, что посоветовал @sbass, даже если вы решите изменить файловую систему. Вам нужно точно определить, где и почему возникает задержка, прежде чем обвинять uALFAT.

Однако для справки, я успешно использовал ELM FatFs и его урезанные ELM Petit FatFs, а также EFSL.

Что касается задержки, то, хотя, например, с ELM я достиг скорости записи до 300 кбит / с с использованием SPI (скорость в значительной степени зависит от карты и может варьироваться от 30 кбит / с до 1 Мбит / с), я не смог успешно использовать его для регистрации потока данных 96 кбит / с в течение какого-либо длительного периода времени, даже при оптимизированных размерах буфера (кратных размеру сектора) и очереди 50 кбит из секторов по 512 байт. Это было связано не с библиотекой, а скорее с характером SD-карты, которая, по-видимому, на границах 1 Мбит зависала до 128 миллисекунд, чего было достаточно для исчерпания буферизации, обеспечиваемой очередью. Решение, конечно, заключается в увеличении буферизации, как сказал @sbas, но в этом случае общий объем системной оперативной памяти составлял всего 64 кбит, так что это было невозможно.

Если вы можете использовать память и задачу RTOS (возможно, в вашем случае собственную SYS / BIOS TI) для решения проблемы, вы должны быть в состоянии заставить ее работать с имеющейся у вас библиотекой. Необходимый объем оперативной памяти зависит от скорости передачи данных и от того, является ли она прерывистой или непрерывной.

Спасибо, ребята, в итоге я внедрил своего рода циклический буфер с дополнительной памятью, и это, похоже, сделало свое дело. Спасибо за хороший вклад!