интересует мнение опытных писателей кода относительно #pragma once
давно интересовался вопросом повторного включения модуля в многомодульном проэкте
тоесть
в главном модуле main усть #include <avr/io.h>
но он также нужен и в lcd.h и в ds18b20.h
что можете посоветовать ?
- Не использовать #pragma once
- Просто включать <avr/io.h> в каждом файле
- В своих многократно включаемых хидерах (myfile.h) оборачивать их содержимое в "скобки" препроцессора
Zhuk72 писал(а):так же, как и рекомендуемая там форма записи
Собственно, обе записи ничем не отличаются.
Надеюсь, у Вас не во всех файлах именно "FILENAME_INCLUDED". У каждого хидера должно быть своё уникальное имя для макроса. Я обычно предпочитаю для файла типа FileName.h выбирать имя FILENAME_H.
И про keil - точно что-то не так делаете. Потому что та же STDPERIPH библиотека для STM32 точно с такими же макросами реализована.
typedef struct{
char chunkId[4];
char format[4];
char subchunk1Id[4];
unsigned short audioFormat;
unsigned short numChannels;
unsigned long sampleRate;
unsigned long byteRate;
unsigned short blockAlign;
unsigned short bitsPerSample;
char subchunk2Id[4];
unsigned long subchunk2Size;
}HEADER;
HEADER wav_header;
как обратится, считать данные, к примеру, с 0 или 5 или 30 байта данной структуры ?
WiseLord, насколько я понимаю то wav_header является сам по себе указателем на нулевой байт структуры ?
как правильно понимать (uint8_t*)&wav_header) ?
wav_header - структура
&wav_header - указатель на неё
(uint8_t*)&wav_header - приводим указатель к типу (uint8_t*)
*(uint8_t*)&wav_header - читаем по этому указателю число типа uint8_t
*((uint8_t*)&wav_header + 5 ) - читаем по (этому указателю + 5 байтов смещение) число типа uint8_t
FreshMan писал(а):как обратится, считать данные, к примеру, с 0 или 5 или 30 байта данной структуры ?
нахрена иметь структуру, чтобы потом обращаться к ее данным мимо поименованных полей?! ну берите тогда сырой массив, и обращайтесь, если с указателями траблы
или при помощи union совместите массив со структурой и ковыряйтесь там хоть так, хоть эдак
typedef struct{
char chunkId[4];
char format[4];
char subchunk1Id[4];
unsigned short audioFormat;
unsigned short numChannels;
unsigned long sampleRate;
unsigned long byteRate;
unsigned short blockAlign;
unsigned short bitsPerSample;
char subchunk2Id[4];
unsigned long subchunk2Size;
}HEADER;
typedef union{
unsigned char raw_bytes[sizeof(HEADER)];
HEADER struct_data;
} COMMON_HEADER;
COMMON_HEADER wav_header;
wav_hader.raw_bytes[15] = 0; // обнуляем 15-й байт в структуре, наплевав на ее поля
wav_header.struc_data.audioFormat = 12; // а теперь делаем бяку через поле
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
ARV писал(а):нахрена иметь структуру, чтобы потом обращаться к ее данным мимо поименованных полей?!
требуется значение полей структуры вывести на LCD 16х2
как я понимаю надо последовательно байт за байтом превращать в строку и выводить на экран
если знаете что-то попроще - поправте
FreshMan писал(а):компилятор начинает ругатся что тип массива str не соответствует выводимому полю структуры
str - это массив символов, т.е. строка. тип выводимого поля должен соответствовать формату вывода, но и только! компилятор не будет ругаться.
главное - в str должно быть достаточно места, чтобы влезло полное представление соответствующего числа в виде символов, т.е. для unsigned long не менее 11 байтов.
FreshMan писал(а):под кажое поле надо свою выводную строку создавать ?
я понятия не имею, как вы планируете выводить на ЖКИ 2х16 кучу полей из заголовка WAV-файла... и зачем это вообще делать... вы правы в одном: каждое поле придется выводить отдельным форматом, соответствующим этому полю, а вот строка-результат, которая будет хранить символьное представление полей, может быть одна и та же.
чтобы меньше ломать голову с выводом на ЖКИ, раз уж вы решили это делать при помощи стандартных функций вывода, я рекомендую воспользоваться моими рекомендациями и работать примерно так:
