aronfelipe/monophonic-music

monophonic-music's Issues

Criar um define para cada prioridade

monophonic-music/SAME70-OLED-BUZZER-MUSICAL/src/main.c

Lines 145 to 155 in 284496c

	// Configure interruption button PIO 1
	NVIC_EnableIRQ(BUT_PIO_ID_1);
	NVIC_SetPriority(BUT_PIO_ID_1, 4); // Prioridade 4
	// Configure interruption button PIO 2
	NVIC_EnableIRQ(BUT_PIO_ID_2);
	NVIC_SetPriority(BUT_PIO_ID_2, 4); // Prioridade 4
	// Configure interruption button PIO 3
	NVIC_EnableIRQ(BUT_PIO_ID_3);
	NVIC_SetPriority(BUT_PIO_ID_3, 4); // Prioridade 4

Exemplo

// (Colocar este define junto com os outros do botão)
#define BUT2_PRIORITY 6

NVIC_SetPriority(BUT2_PIO_ID, BUT2_PRIORITY);

Vantagens:

• Fica explicito junto com as demais configurações do botão, permitindo fácil alteração da prioridade se necessário.
• Evita número "mágico" no meio do código, ficando bem óbvio o que se trata (código se auto documenta).

Grandes vetores constantes de dados

monophonic-music/SAME70-OLED-BUZZER-MUSICAL/src/musics.h

Lines 4 to 12 in 284496c

	int mario_melody[] = {
	NOTE_E7, NOTE_E7, 0, NOTE_E7,
	0, NOTE_C7, NOTE_E7, 0,
	NOTE_G7, 0, 0, 0,
	NOTE_G6, 0, 0, 0,
	NOTE_C7, 0, 0, NOTE_G6,
	0, 0, NOTE_E6, 0,
	0, NOTE_A6, 0, NOTE_B6,

No arquivo musicas.h existem diversos vetores com informações constantes (uma vez definido, nunca é alterado).

Uma grande recomendação de quando trabalhamos com sistemas embarcados, e também acaba sendo uma excelente prática de programação, sempre que tivermos dados constantes que não alteram (imutáveis), declarar eles com a propriedade const.

Exemplo:

const int pirate_tempo[] = ...

Quais as vantagens para um sistema embarcado?
Bom, o nosso SAME70, é uma CPU com 2048KB de ROM e 384KB de RAM (fonte) Quando você não utiliza a propriedade const, o compilador assume, que o vetor pode ser alterado a qualquer instante, por este motivo, ele é armazenado na RAM do processador. Agora, com o const, estes dados serão armazenados na ROM! Já que eles não se alteram! Dando uma enorme economia de memória RAM.

Lembre-se que geralmente em sistemas embarcados, um dos maiores gargalos é a quantidade de memória RAM disponível (RAM = custo = aumenta preço).

Poderia ter uma função draw_music_title

monophonic-music/SAME70-OLED-BUZZER-MUSICAL/src/main.c

Lines 209 to 210 in 284496c

	gfx_mono_draw_string(" ", 10,16, &sysfont);
	gfx_mono_draw_string("Mario", 10,16, &sysfont);

Que tal?

void draw_music_title(char* title) {
     gfx_mono_draw_string("           ", 10, 10, &sysfont);
    gfx_mono_draw_string(title, 10, 10, &sysfont);
}

Vantagens:

• Separa lógica de processamento da lógica de exibição.
• Para alterar a interface visual no OLED, basta alterar uma função, ficando bem claro, o seu uso. Evitando ter código repetido espalhado.

Defines para números mágicos ou comentário mais elaborado

monophonic-music/SAME70-OLED-BUZZER-MUSICAL/src/main.c

Lines 160 to 161 in 284496c

	long delayNote = 1000000 / (frequency / 2);
	long numCycles = (frequency * length) / 1000;

O que representa o valor 100000? e o 2?

Assim, sei que representa a conta de uma nota musical, provavelmente em tempo. No entanto, ao bater o olho, fica dificil saber, estes 1000000 seria o que 100 segundos? 100 milissegundos?

Enfim, deixar o código mais comentado ou usar defines para dizer o que são essas variáveis tem suas vantagens:

• Fica mais fácil para entender o que está sendo feito
• Permite ajuste fino pelo usuário fácil apenas alterando um define

Números mágicos nos flags de botão

monophonic-music/SAME70-OLED-BUZZER-MUSICAL/src/main.c

Lines 72 to 88 in 284496c

	if (but_flag != 10){
	but_flag = 10;
	}
	else {
	but_flag = currentSong;
	}
	}
	void but_callback_2(void)
	{
	but_flag = 2;
	}
	void but_callback_3(void)
	{
	but_flag = 9;
	}

Algum motivo por usar 2, 10, 9?

Porque não 1, 2, 3. Batendo respectivamente com cada botão.