Уроки СИ для AVR микроконроллеров

[tempora]

Вообще-то, подобные пенки возникают чаще всего именно из-за несовпадения раскладки элементов структур в интерпретации разных компиляторов, поэтому прежде всего нужно проверить фактические смещения внутри структуры.
Проц, я так понял, мега32, а чем компилите? Карту памяти с раскладкой бут-сектора сравнивали? Наконец, всегда можно проверить истинное содержание структуры, пролистав её побайтно - Вы так проверяли?

Вы, кстати, как-то забыли включить в цитату ту часть исходника, где объявлена проблемная структура...

++ : А хотя бы sizeof(*bpb) равна 512?

[С.М.С]

Да, МК Mega32, пишу и компилирую в студии от Атмел с доустановленной GCC. Сверяю с SD картой при помощи WinHex и сравниваю со значениями в терминале, Boot выводится верно. В структуре данные совпадают со значениями карты. Всё это работает если использовать локальные переменные. Но, так как данные boot сектора и производные от них используются в разных процедурах, нужны глобальные переменные, вот с ними и проблемы. Хотя у автора нигде и нет директивы extern, часть переменных объявленных во внешнем хидере работают нормально, а часть не работают. К примеру массив буфера из 512 байт всё нормально хранит и вызывается из любого места программы. Ниже объявление структуры для работы с boot, хотя думаю мало чем поможет:

//Structure to access boot sector data
struct BS_Structure{
unsigned char jumpBoot[3]; //default: 0x009000EB
unsigned char OEMName[8];
unsigned int bytesPerSector; //deafault: 512
unsigned char sectorPerCluster;
unsigned int reservedSectorCount;
unsigned char numberofFATs;
unsigned int rootEntryCount;
unsigned int totalSectors_F16; //must be 0 for FAT32
unsigned char mediaType;
unsigned int FATsize_F16; //must be 0 for FAT32
unsigned int sectorsPerTrack;
unsigned int numberofHeads;
unsigned long hiddenSectors;
unsigned long totalSectors_F32;
unsigned long FATsize_F32; //count of sectors occupied by one FAT
unsigned int extFlags;
unsigned int FSversion; //0x0000 (defines version 0.0)
unsigned long rootCluster; //first cluster of root directory (=2)
unsigned int FSinfo; //sector number of FSinfo structure (=1)
unsigned int BackupBootSector;
unsigned char reserved[12];
unsigned char driveNumber;
unsigned char reserved1;
unsigned char bootSignature;
unsigned long volumeID;
unsigned char volumeLabel[11]; //"NO NAME "
unsigned char fileSystemType[8]; //"FAT32"
unsigned char bootData[420];
unsigned int bootEndSignature; //0xaa55
};

[tempora]

Я что-то не уловил, как вяжется одно с другим - сначала Вы пишете, что не работает, потом, что-таки работает:

вместо sectorPerCluster =0x08 получается = 0x09 при присваивание этой переменной, типа sectorPerCluster = 0x00; считывается 0x01.

сравниваю со значениями в терминале, Boot выводится верно.

Всё это работает если использовать локальные переменные.

Бог с ним, с тем, что работает; Вы с глобальными переменными (где не работает) проверки делали? Что толку сокрушаться, что данные читаются неверно; нужно же локализовать ошибку, а Вы сообщаете только детали о том, что работает ("массив буфера из 512 байт всё нормально хранит"), что ситуацию прояснить никак не может.
Установите для начала по какому адресу в действительности читаются данные - это наиболее вероятный источник ошибки в таких случаях. В объявлении, которое Вы привели, опций выравнивания вообще нет - это кусок инклуда? Если да, то в разных модулях, имеющих разные опции выравнивания, он и скомпилится по-разному!

[С.М.С]

Начали же с того, что скорее всего ошибка в структурах, их уже проверял и не однократно, ну раз люди говорят, значит перепроверил ещё раз. И раньше и сейчас значения из бута читаются и хранятся в структуре нормально. Проблема с глобальными переменными их объявление с начала и приводил. В отладчеке всё работает и присваевается. В железе нет, т.е.
имеем
bytesPerSector =0x0200
sectorPerCluster =0x09
reservedSectorCount =0x9DDF
rootCluster =0x00000002

а должно быть:
bytesPerSector =0x0200
sectorPerCluster =0x08
reservedSectorCount =0x10DE
rootCluster =0x00000002

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

[tempora]

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

Постойте, вот тут: "sectorPerCluster = bpb-›sectorPerCluster;" слева и справа от оператора присвоения должные быть одинаковые значения? а не 9 и 8, так?

[С.М.С]

после присвоения да. Т.е имеется значение в переменной структуры = 8, его нам надо присвоить глобальной переменной, чтобы можно с ней было работать в других процедурах. А оно не хочет, после оператора "sectorPerCluster = bpb-›sectorPerCluster;" в глобальную переменную записывается 9, а не 8. Вот в этом и вопрос. Хотя в структуре хранится 8, это проверяется если объявить локальную переменную и с её помощью высте содержимое структурной переменной, что не однократно проверялось.

[tempora]

Если я правильно понимаю описание, то вот в этом коде:

        bytesPerSector = bpb-›bytesPerSector;
        transmitString_F (PSTR("bytesPerSector ="));
        transmitHex(INT, bytesPerSector); transmitByte(' ');

bpb-›bytesPerSector имеет правильное значение, а bytesPerSector (после присвоения) - неправильное? А чем проверяете - transmitHex'ом, или как-то понадежнее?

Просто, в листинге стоят вполне верные инструкции (без ошибок по адресам), может transmitHex глючит?

Вот что в листинге и мапе:

sectorPerCluster = bpb-›sectorPerCluster;
    1e2e:	80 91 a7 00 	lds	r24, 0x00A7 ; 9a +13, смещение верное
    1e32:	90 e0       	ldi	r25, 0x00	; 0
    1e34:	90 93 9b 02 	sts	0x029B, r25
    1e38:	80 93 9a 02 	sts	0x029A, r24
...
transmitHex(CHAR, sectorPerCluster); transmitByte(' ');//
    1e44:	40 91 9a 02 	lds	r20, 0x029A
    1e48:	50 91 9b 02 	lds	r21, 0x029B

    0x0080009a                buffer
    0x0080029a                sectorPerCluster

Так чем содержимое переменных проверяете?
_______________________________________________
Вот этой фразы я не понял:

Хотя в структуре хранится 8, это проверяется если объявить локальную переменную и с её помощью высте содержимое структурной переменной, что не однократно проверялось.

[С.М.С]

всё верно, проверяю transmitHex'ом. Да можно было бы грешить на него, но делаем к примеру так:

unsigned long temp;


temp = bpb-›bytesPerSector;
transmitString_F (PSTR("bytesPerSector ="));
transmitHex(LONG, temp); transmitByte(' ');//

temp = bpb-›sectorPerCluster;
transmitString_F (PSTR("sectorPerCluster ="));
transmitHex(LONG, temp); transmitByte(' ');//

и всё выводит правильно, т.е. transmitHex работает исправно, что не скажешь о глобальной переменной, которая не хочет работать, даже внутри процедуры. Опять же в отладчике присваивание работает правильно, а вот в железе нет.

[tempora]

Ну так, выходит, кто-то в неё пишет. Что если попробовать проверить, что записалось:

        bytesPerSector = bpb-›bytesPerSector;
        if ( bytesPerSector - bpb-›bytesPerSector )
        {
            // ...
        } else {
            // ...
        }

По идее, должна сработать вторая ветка if'а...
Прерывания, насколько я заметил, только от кнопки?
bytesPerSector стоит сразу после буфера, попробуйте увеличить размер buffer - если кто-то пишет в неё больше положенного, то картина изменится.

[С.М.С]

Думал над этим, прерывания запрещал, делал цикл пока не появится одинаковое значение, глухо программа зависала в цикле, так и не присвоив глобальной переменной нужное значение. Прерывание, внешнее только от сенсорного экрана, точнее от его драйвера. Да кстати bytesPerSector работает, не работают две следующих переменных, т.е sectorPerCluster и reservedSectorCount