Читайте спецификации языка. Непереносим только тип int, размеры остальных детерминированы.
Это не совсем так. Но... вероятность того, что char не будет 8 бит, да и что будет перенос кода, да ещё с неудачным попаданием на разный размер int, исчезающе мала.
Мне нравится использовать без переопределения, потому что тогда они красиво подсвечиваются в редакторе
tonyk писал(а):
Вопрос был про FAT, а в нём порядок байт определён.
Зато структура пишется на микроконтроллере, а в нём как повезёт. Мне вот не повезло.
tonyk писал(а):
Зачем весь этот геморрой, когда есть FATFS от Чана? Много лишнего времени?
Обучение, улучшение/оптимизация, лицензионные соглашения... причин может быть множество. У меня своя реализация, оптимизированная и в размере и по времени обращения к SD-карте (она много жрёт энергии).
Зачем весь этот геморрой, когда есть FATFS от Чана? Много лишнего времени?
Обучение, улучшение/оптимизация, лицензионные соглашения... причин может быть множество. У меня своя реализация, оптимизированная и в размере и по времени обращения к SD-карте (она много жрёт энергии).[/uquote]
Да. Оптимизация это очень важно. Надеюсь мне моего ATSAM7S256 на 50 MHz хватит чтобы воспроизводить солосовые сообщения и обрабатывать некоторые аппаратные прерывания(перерисовка дисплея на светодиодной матрице, Прерывание от ИК-пульта и ещё что-то будет точно.)
Вы уже упёрлись в нехватку быстродействия вашего МК, коли занялись оптимизацией?
Юрий1239 писал(а):
Надеюсь мне моего ATSAM7S256
Вы даже не оценили потребности, не протестировали, не сняли профили, зато лезете в низкоуровневую оптимизацию. С вашими познаниями языка С считать, что Чен, автор библиотеки FATFS, написал что-то мало пригодное для практического использования, как-то глупо. Поверьте, быстрей, чем у Чена, вы не напишите. У него весьма простой и быстрый код. Меняйте свой подход к разработке.
Юрий1239 писал(а):
Долго разбираться, не знаю как она работает, много лишнего кода. А там есть поддержка длинных имён ?
Вы даже не посмотрели, и сразу утверждаете, что долго разбираться. Про лишний код это вообще показатель вашей безграмотности и не владения вопросом. И да, поддержка длинных имён, ессно, есть. Изучите то, что сделали до вас, не считайте себя гением, а других тупыми неумехами.
У меня чтение документации и портирование fatfs на мой контроллер заняло один вечер. Доки внятные, всё расписано, объяснено, так что адаптация библиотеки достаточно проста.
Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Вы даже не оценили потребности, не протестировали, не сняли профили, зато лезете в низкоуровневую оптимизацию. С вашими познаниями языка С считать, что Чен, автор библиотеки FATFS, написал что-то мало пригодное для практического использования, как-то глупо. Поверьте, быстрей, чем у Чена, вы не напишите. У него весьма простой и быстрый код. Меняйте свой подход к разработке.
Долго разбираться, не знаю как она работает, много лишнего кода. А там есть поддержка длинных имён ?
Вы даже не посмотрели, и сразу утверждаете, что долго разбираться. Про лишний код это вообще показатель вашей безграмотности и не владения вопросом. И да, поддержка длинных имён, ессно, есть. Изучите то, что сделали до вас, не считайте себя гением, а других тупыми неумехами.
У меня чтение документации и портирование fatfs на мой контроллер заняло один вечер. Доки внятные, всё расписано, объяснено, так что адаптация библиотеки достаточно проста.
Полностью согласен насчёт совета снять корону и использовать библиотеку Чана. Чтобы так написать, как написана она, ТСу нужно расти ещё минимум ...дцать лет (судя по его постам). ТСу лишь бы хоть хватило умения грамотно написать middle-level для Чановской библиотеки. Даже это будет для него серьёзной задачей. Куда там свой лисапед колхозить! Думать о чём то серьёзном, даже не владея основами языка программирования - просто смешно...
PS: Заодно - параллельное изучение исходников чановской библиотеки весьма полезно для начинающих. Можно чему-то научиться, если уметь думать и анализировать.
PPS: Чановскую FatFS использовал неоднократно в разных проектах на разных МК. Написана она качественно. Что нынче - весьма редкое явление.
Ну, с нуля самостоятельно пройти этот путь тоже хорошо. И интересно притом. А потом пройти ещё раз, но уже с FATFS. Я так и делал, в результате стал понимать устройство FAT и работу FATFS, что всё-таки немного лучше, чем использование её без понимания. Хотя и необязательно.
Как же много тут лишних слов не по теме. От них нет никакой пользы.
И не будет. У вас не правильный подход, так не делают, ибо это пустая трата времени с около нулевым результатом. Повторю: меняйте подход к разработке и снимите корону.
Не через #define, а через явное указание адреса (смещения) в данных. #define - это всего лишь удобный способ, всего лишь директива для компилятора (препроцессора). Надеюсь, Вы в курсе, как эта кухня работает.
Не через #define, а через явное указание адреса (смещения) в данных. #define - это всего лишь удобный способ, всего лишь директива для компилятора (препроцессора). Надеюсь, Вы в курсе, как эта кухня работает.
Размер структуры не всегда равен сумме размеров входящих в неё полей. Иногда для оптимизации компилятор производит разные выравнивания, оставляет пропуски. Особенно когда контроллер 32-битный, а поля структуры 16- или 8-битные. Для того, чтобы компилятор не оставлял пропуски между полями структуры, используйте директиву упаковки #pragma pack:
Код:
#pragma pack(push, 1) typedef union { struct { unsigned char JmpBoot[3]; // JMP на загрузчик (0xEB5890) unsigned char OEMName[8]; // Строка форматера ОС ("MSDOS5.0") unsigned short BytePerSec; // Количество байт в секторе ............ 0x00B: 512 unsigned char SecPerClus; // Количество секторов к кластере ....... 0x00D: 8 unsigned short RsvdSecCnt; // Всего резервных секторов (ВРВ + копия) ................. 0x00E: 2 186 unsigned char NumFATs; // Сколько копий FAT-таблицы 0x010: 2 unsigned short RootEntCnt; // Объектов в корневом каталоге (нуль для FAT-32) unsigned short TotSec16; // Всего секторов на диске (нуль для FAT-32) unsigned char Media; // Тип диска (F8) unsigned short FATSz16; // Размер таблицы FAT-16 в секторах (нуль для FAT-32) unsigned short SecPerTrk; // Секторов в дорожке (63) unsigned short NumHeads; // Всего головок Head (255) unsigned int HiddSec; // Cекторов перед началом раздела ....... 0x01C: 2 048 unsigned int TotSec32; // Всего секторов на диске .............. 0x020: 15 689 728 unsigned int FATSz32; // Размер таблицы FAT-32 в секторах ..... 0x024: 15 291 unsigned short ExtFlags; // Флаги unsigned short FSVer; // Версия файловой системы unsigned int RootClus; // Кластер корневого каталога (смещение в блоке данных) ... 0x02C: 2 unsigned short FSInfo; // Сектор структуры FSINFO .............. 0x030: 1 unsigned short BkBootSec; // Сектор копии этой записи (6) unsigned char Reserved[12]; // unsigned char DrvNum; // Номер диска для INT-13h (00 или 80h) unsigned char Reserved1; // unsigned char BootSig; // Сигнатура 29h, если имеются сл.три поля unsigned int VolID; // Серийник тома unsigned char VolLabel[11]; // Строка с меткой тома по умолчанию ("NO NAME "). unsigned char FilSysType[8]; // Строка "FAT32 ". unsigned char Reserved2[420]; // unsigned short Signature; // Сигнатура 55AAh }; unsigned char raw[512]; }FAT32_type; #pragma pack (pop)
Попробуйте оценить размер структуры после использования упаковки. Не знаю насчёт всех компиляторов, но Keil и GCC эту директиву поддерживают.
З.Ы. Я тут посчитал сумму размеров полей Вашей структуры - эта сумма равна 512 байт. Скорее всего, проблема в упаковке данных компилятором.
_________________ Если я где-то ошибаюсь, прошу от меня этого не скрывать. Заранее очень признателен
Размер структуры не всегда равен сумме размеров входящих в неё полей. Иногда для оптимизации компилятор производит разные выравнивания, оставляет пропуски. Особенно когда контроллер 32-битный
Не "иногда", а "всегда" (если только явно не задана упаковка). И не "для оптимизации", а "следуя правилам языка си/си++". И "32-битность контроллера" тоже не имеет никакого значения - си-компиляторы 16-битных контроллеров поступают точно так же. И 64-битные компиляторы - аналогично.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
