Get best of the week

Doom Boy ESP32

Doom prefix for ESP32 do-it-yourself on the MCP23017 driver for buttons from UncleRus



In anticipation of Doom hours , the board of a long-standing project came. The external MCP23017 and CS4344 and a lot of other things are divorced on the board.

The buttons use the MCP23017 port expander connected via I2C. For him there is a driver that you can get from UncleRus .

An attempt was made to launch an external ADC CS4344.

Doom by Espressif


Having downloaded the port, Doom had to tinker a bit to collect it. In the end, everything got together and flooded into ESP32 but ... I caught a crash at the start. On the githab Issue of the project I saw a similar discussion of the problem:



The author of the port suggested making
You probably need to use the malloc () option as well as reserve some memory for DMA. I'll see if I can get this compiling on master and update the sdkconfig when I have time.
In general, I “without thinking twice” replaced all ported memory allocation functions with malloc (). The
demo started. Ahead of me was connecting buttons

MCP23017 GPIO extender




MCP23017

With big plans for expanding the functionality through the controller ports, I decided to save a little on the input / output ports of the microcontroller itself by installing MCP23017. It is a simple expander with access to input / output signals via the I2C interface. I did not invent the driver, but simply took it from UncleRus .

Five buttons uses the joystick to navigate. A couple of buttons on the shot and menu selection. In fact, this is not enough, you still have to open the doors and move left and right without turning, that is, like a crab. The findings are pulled inside the MCP23017 to VDD. The contact closes to ground. It is very cool that there are pull-up resistors inside the microcircuit. One could still be confused with interruptions from the MCP23017. It has two pins for each port, INTA and INTB, but somehow another time.

Full list of teams
static const JsKeyMap keymap[]={
	{0x10, &key_up},
	{0x40, &key_down},
	{0x80, &key_left},
	{0x20, &key_right},
	
	{0x4000, &key_use},				//cross
	{0x2000, &key_fire},			//circle
	{0x2000, &key_menu_enter},		//circle
	{0x8000, &key_pause},			//square
	{0x1000, &key_weapontoggle},	//triangle

	{0x8, &key_escape},				//start
	{0x1, &key_map},				//select
	
	{0x400, &key_strafeleft},		//L1
	{0x100, &key_speed},			//L2
	{0x800, &key_straferight},		//R1
	{0x200, &key_strafe},			//R2

	{0, NULL},
};


It was easier to cut through the processing of buttons than I thought. I lowered the frequency of I2C to improve stability. In any case, the declared 1MHz did not go. The frequency of 100kHz was quite enough for polling in a cycle with a delay of 20ms.

CMake


I killed a lot of time on adding CMakeList.txt for components. Something did not work with make. And I wanted to take a fresher SDK. The original port was not going even to 3.2.x. Took esp-idf-v3.3.1 it will probably work on esp-idf-4.0

Sound through the DAC


Actually there is another fork . It features a connected SD-CARD and sound through the built-in DAC. The original port from Espressif allows you to load a wad file only into the internal Flash memory of programs, and then you need to use a cut file in which there is no sound!

The scheme here.

The idea of ​​connecting an external DAC instead of the built-in DAC captured me. At least the penny from Cirrus Logic.



Next I set up the DAC on CS4344 and then I was disappointed. The sound worked with interruptions. When I saw the file i_sound.c in my projectI noticed that one dma.h file is not used. As if there is a link to him, and he himself is, but everything is commented on. Maybe I watched inattentively? But I think the author also noticed that something was wrong with the sound and tried to eliminate it. Perhaps eliminated and did not post the last commit. Or maybe everything works as it should on the internal DAC. However, to output sound through the built-in DAC and to a tiny speaker, distortion-interruptions can also be neglected. I played around with bitrate and overall code change. It brought nothing.

And yes, regarding the connection of SD-CARD. Initially, I hung it in parallel with the display on the SPI bus, separating separately the CS chip selection signal. The idea failed. By ventilating the question Support SD-SPI bus sharingcame to the conclusion that not all SD-CARD are made the same or my hands are not so straight. I had to unsolder it through the adapter to the board instead of the microphone. It was wound up without pull-ups by external resistors to VDD.
Internal Resistors Handled

    gpio_set_pull_mode(PIN_NUM_MOSI, GPIO_PULLUP_ONLY);
    gpio_set_pull_mode(PIN_NUM_MISO, GPIO_PULLUP_ONLY);
    gpio_set_pull_mode(PIN_NUM_CLK, GPIO_PULLUP_ONLY);
    gpio_set_pull_mode(PIN_NUM_CS, GPIO_PULLUP_ONLY);


On this I quit this lesson and posted the source code on GitHub .

It would be necessary to make another edition of the printed circuit board. This one is no good!


There is no sound on the video.

And I also had a joystick contact for turning when I soldered. In general, the first pancake is lumpy

UPD

I managed to establish a sound. Jerks are present, but not critical. Code Changes:

spi_lcd.c
dmamem[x]=heap_caps_malloc(MEM_PER_TRANS*2, MALLOC_CAP_DMA);

i_sound.c
void IRAM_ATTR updateTask(void *arg)
{
// size_t bytesWritten;
while(1)
{
I_UpdateSound();
i2s_write(I2S_NUM_0, mixbuffer, SAMPLECOUNT*SAMPLESIZE, &bytesWritten, portMAX_DELAY);
}
}

.dma_buf_count = 2,
.dma_buf_len = 512,

xTaskCreatePinnedToCore(&updateTask, "updateTask", 1000, NULL, 7, NULL, 0);

More articles:


All Articles