Тут для разнообразия задумал сделать MP3 плеер на ATMega128 и внешнем кодеке. Для начала решил покорить Sd карту.. Долго мучался с встроенной в CVAVR библиотекой в итоге чуть погуглив наткнулся http://my-avr.at.ua/forum/3-74-2 на библиотеку для SD написанную под cvavr (исходники там тоже есть). Чуток помучавшись все заработало, но остался один момент, как считать имеющиеся в корне флешки файлы в массив, чтобы занать какие файлы присутвуют на флешке.
В Hex редакторе открываю образ флешки и вижу все имена файлов хранятся в одном месте оно начинается с метки тома TEST_FAT искать файлы например по расширению до конца записи..
, по идее все можно считать, но как указать что читать надо с N -ного адреса непойму.. Может кто-то имел уже дело с флешками Исходник + схему в Proteus для симуляции прилагаю.
Еще момент, если кому-то захочется закинуть в образ флешки свои файлы или вытащить уже имеющиеся на ней файлы то понадобится прога WinImage. Просто перетягиваете файлы в окно программы с открытым образом флешки
как считать имеющиеся в корне флешки файлы в массив, чтобы занать какие файлы присутвуют на флешке.
Судя по ответу с вышекуказанного форума - никак, нет функции поиска файлов в той библиотеке. Надо ее ручками дописывать.
servo писал(а):
по идее все можно считать, но как указать что читать надо с N -ного адреса непойму..
FAT16, если я не ошибаюсь, позволяет иметь всего 512 записей(файлов и каталогов) в каждой дирректории. При использовании только корневой дирректории задача упрощается т.к. не надо при поиске заглядывать в подкаталоги. Так вот, стартовый адрес корневой дирректории всегда известен, длина одной записи фиксирована(для имени формата 8.3), максимальное кол-во записей = 512. Поэтому вам надо считать аттрибут файла/каталога, затем, если файл нас не устроил, увеличить адрес следующего чтения на размер записи.
Обратите внимание на функцию:
Код:
byte fat_findfile(flash byte *name,byte mattrib,fff *info) { //Поиск записи в корневой директории
Там есть все необходимые элементы для реализации вашей задачи(нужно только чуток переписать:).
В одном из своих проектов я тоже писал ФАТ с поиском фалов по маске в имени и/или расширении. Выглядело примерно так:
Код:
flash char all_files[11]={'?','?','?','?','?','?','?','?','I','L','D'};//искать все файлы с маской ILD
entry_number=0; while(entry_number<512)//play all *.ILD files on SDC { open_result=open_file(all_files,entry_number);//пытаемся открыть файл с начальным номером текущей записи [i]entry_number[/i] и указанным именем [i]all_files[/i] entry_number=(open_result->entry_number)+1;//увеличим счетчик записи if(open_result->file_status)//если файл успешно открыт, то приступим к его чтению { //здесь работаем с самим файлом }; };
Я вообще подумал что можно например напрямую читать флешку без Fat размещения, просто побайтно и тупо найти название тома а за ним по расширению найти файлы и скопировать их имена.
Что-то я не понял, как это возможно корректно без разбора записей FAT сделать. Если речь о том, что не надо вычитывать адреса файлов, то да. Ещё надо помнить, что удалённые файлы там отмечаются какой-то меткой в первом символе - их выводить не надо.
_________________ Сделать хотел грозу, а получил КоЗу
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Что-то я не понял, как это возможно корректно без разбора записей FAT сделать. Если речь о том, что не надо вычитывать адреса файлов, то да. Ещё надо помнить, что удалённые файлы там отмечаются какой-то меткой в первом символе - их выводить не надо.
Да я уже поэксперементировал с hex редактором , получается когда файл удаляеш то первый байт его имени метится байтом 0xE5, этот файл весит в списке до тех пор пока на флешку не будет записан новый файл, после этого я как понял происходит обновление списка и то что было помечено 0xE5 удаляется из списка.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Да я уже поэксперементировал с hex редактором , получается когда файл удаляеш то первый байт его имени метится байтом 0xE5, этот файл весит в списке до тех пор пока на
Лучше бы почитали спецификацию на FAT. Помойму на электрониксе ( electronix.ru ) была даж переведенная на русский язык версия. Все или по крйней мере большинство вопросов сами отпадут. Конкретно в вашем случае надо посчитать всего-то 5 - 6 смещений.
Up: вот спецификация, правда на английском. Всего 30 страниц...
Честно говоря я сам не реализовывал вывод имен файлов, мне нужно было просто подряд читать данные из существующих файлов на флешке. Поэтому в здесь готовый код показать не могу.
См. стр.23 из спецификации. Там показана структура одной записи. Памяти в М128 достаточно поэтому можно не парится и сразу организовать структуру в ОЗУ и заполнять ее байтами из дирректории.
Вот мой исходник, может чем поможет. См. ф-цию
Код:
struct FILE_PARAM *find_file(flash unsigned char *name,unsigned int entry_number)
Она ищет файл в корневой дирректории по имени и возвращает номер записи и параметры файла. А вот здесь происходит сравнение текущего имени файла с искомым:
вообще думаю нужна просто функция типаchar sd_readbyte(адрес){
Это не совсем правильная позиция. Наверное вы уже слышали, что SD(MMC, SDHC?) имеют внутреннюю организацию сектора 512 байт(или 1024, 2048). Так вот, вы можете только начать чтение с нулевого смещения байта внутри одного сектора и закончить либо перечитав все 512 байт, либо использовать инструкции чтения блока неопределенной длины. Допустим желаемые байты находятся по смещению +100, надо прочитать 10 байт. Тогда: 1.Выставляем адрес сектора(+0, +512, +1024 и т.д.). 2.Считываем 100 байт, но на них внимание не обращаем т.к. они не нужны. 3.Считываем нужный +101-й байт. 4.Заверщаем операцию чтения. 5.Повторяем все почти тоже самое но для смещения +102. Чувствуете разницу? Вместо 10+100 байт вам придется прочитать примерно 1 килобайт. Т.к. нужные поля данных почти всегда имеют длину >1 и <256 байт, то либо сразу буферизуют весь сектор в ОЗУ контроллера, либо считывают всю цепочку.
Дам, посмотрел сейчас в тот код , конкретнее файл _sd.c. Нет четкого разделения уровня драйвера ввода-вывода карты памяти и уровня фат... Вот функция, кот я когда-то писал для доступа к данным по опр. адресу:
Код:
// Read number bytes from sector // void read_partial_sector( unsigned long adress, //sector adress unsigned char *destination,//destination object - char array unsigned int offset,//offset in bytes from current sector position; 0=no offset unsigned char len)//for faster perfomance size reduced to 'char' { unsigned int i;
end_read();//stop read if required send_CMD(CMD18,adress);//send adress of new sector for multiple read wait_data_ready(); _SRF=1;//serial read opened while(offset) { --offset; //spi(0xFF);//go to the required byte position in sector spi_tx_ff; }; for(i=0;i<len;i++) { /////Read byte from SPI///// SPDR = 0xFF;//start while(!(SPSR & (1<<SPIF)));//wait until byte will be read destination[i]=SPDR; //destination[i]=spi(0xFF);//fill destination object } }
Она получает адрес сектора и смещение байтов от начала сектора. Затем она заполняет массив указанной длины.
Подскажите,вот задумал попробывать читать ММС и выводить на динамик.Поскольку с ФАТ ксожалению еще неразобрался(думаю PETIT или FS изучить библеотеки что лучше?),поэтому читаю непрерывными блоками.Скинул на флеху .wav файл начал выводить с MMC на ШИМ и динамик- тупо трещание,иногда смена тонов( Как подсчитать задержку между выводом звука на ШИМ? Частота 8МГц,и при разных качествах музыки нужно другую задержку(красным цветом в коде)? 30 Кбит в сек задежка равна = 3750(пиревод в байты) /8000000 =468 микро сек. так?
считываем с mmc; цикл(1) выводим цифру в ШИМ ; задержка; возвращаемся в ЦИКЛ;
Что за глупости?Нужно сделать задержку таймером и менять значение шим в прерывании по переполнению таймера. Задержка считается очень просто- смотрим частоту дискретизации звука например "20кГц ,стерео, 128кбит/сек " Тут 20кГц это и есть частота дискретизации так вот нужно каждую секунду выводить 20тыс чисел.Соответственно шим должен успевать менять свое значение и как следствие как минимум на величину разрядности звука нужно умножить частоту дискретизации.Пусть это будет 8 бит, значит 256 ступеней.Нужно умножить 256 на 20кГц и вот с такой скоростью нужно чтобы были прерывания по переполнению.
Звук в общем то можно с любым качеством записать.Даже стандартный инструмент Хр звукозапись позволяет изменять качество. Ну или в других редакторах можно изменить готовые звуки.
Разрядность определяется 128000бит/сек качества делим на 20000 Гц дискретизации получаем где то 6,4 бит. Цифры взяты из головы, в конкретном случае звуков самостоятельно можно посчитать.
Что за глупости?Нужно сделать задержку таймером и менять значение шим в прерывании по переполнению таймера. Задержка считается очень просто- смотрим частоту дискретизации звука например "20кГц ,стерео, 128кбит/сек " Тут 20кГц это и есть частота дискретизации так вот нужно каждую секунду выводить 20тыс чисел.
ну это я имел виду
vitalik_1984 писал(а):
Соответственно шим должен успевать менять свое значение и как следствие как минимум на величину разрядности звука нужно умножить частоту дискретизации.Пусть это будет 8 бит, значит 256 ступеней.Нужно умножить 256 на 20кГц и вот с такой скоростью нужно чтобы были прерывания по переполнению.
вот тут я вообще непонял. Разрядность это изменение звука с 0 до 256,тоесть может быть любым числом,зачем умножать разряд на частоту?Я еще пойму чтобы сделать типа синусойды,сравнивать это значение со слудующим чтобы сделать плавный переход i++ если больше или i-- если меньше.
вот тут я вообще непонял. Разрядность это изменение звука с 0 до 256,тоесть может быть любым числом,зачем умножать разряд на частоту?Я еще пойму чтобы сделать типа синусойды,сравнивать это значение со слудующим чтобы сделать плавный переход i++ если больше или i-- если меньше.
В коде не надо ничего умножать, это нужно чтобы выяснить какое значение установить в OCRn таймера задающего дискретность и этот же таймер по прерыванию совпадения будет обновлять значение OCRa ШИМ таймера, шаг таймера задающего дискретность не должен быть меньше 256-ти машинных циклов, чтобы успевал обновляться OCR ШИМ таймера. По-этому максимальная частота дискретизации для 8МГц при 8 бит качества звука будет: 8000000/2**8=31250Гц, в принципе для звука 22050Гц 8 бит вполне приемлемо.
А воту меня непрограммируется контроллер с флехой микроСД,надо добавлять сопротивления последовательно с картой? на счет воспроизведения звука сейчас осмыслю(почитаю и задам фопрос))),а качество звука и дискетизация не зависят друг от друга? чет мне кажется одно и тоже)
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 14
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения