Driving an 8-bit parallel 8080 bus using I2S
Posted: Wed Nov 07, 2018 4:49 am
I'd like to first excuse myself for the undertones of frustration throughout this post, but I ran out of steam.
This is supposed to be a simple question with plenty of references between the "har-in-air" Github repo (based upon @ESP_igrr code I reckon), the "pixelmatix" repo (which shares the same "DNA" I think), the esp-iot-solution LCD examples and the camera samples (also by @ESP_igrr on his repo).
But I can't for the life of me drive an 8-bit 8080 bus peripheral (which happens to be a LCD). I'm using a regular ILI9341 mcufriend-like Arduino-ish shield which works just peachy with TFT_eSPI in parallel mode (which bit-bangs the GPIOs). Every attempt I made of porting it to a esp-iot-solution component using I2S was a wreck. And I suspect it has to do with the code there always expecting 16 bit commands/register selections or equivalently that high data lines D[23:8] are not-cares for command parameters (see ILI9341 datasheet v1.11, page 110 for an example; also https://github.com/espressif/esp-iot-solution/issues/19).
After messing with the i2s_lcd_com code and attempting to send only 8 bits instead of what is clearly a two step write with byte swapping on iot_i2s_lcd_write_cmd (and rewriting iot_i2s_lcd_write_data to look similar to the cmd version, identical to the 16 bit version as a matter of fact except for masking data with & 0xFF; I wonder if this could work like the SPI master driver where you define a length in bits and use a byte swapping macro?). I currently have the LCD showing a very corrupt image with severe "banding" and every hint of garbage-in-garbage-out, not to mention colour inversion; but I can recognise some thin strips of the original image (which is just the demo from esp-iot-solution).
I read the TRM. I read all the above code. I'm getting pretty much nowhere in my attempts to grafting working parts together. And the fact that I have no logic analyser is making my working hours something less of a pleasure as I find myself stuck in a loop of trials and errors. My reading of the TRM v3.9, pages 306 to 312, lead me to believe the I2S peripheral just can't cope with the fact that some data simply can't be organised as 16 bit packets. In addition, for the data that can be thusly organised, the Data Frames Form 1 and 2 happen to be so esoteric that most gains from DMA are lost in attempts to re-layout memory, and that should have been instead a straightforward bitblt operation.
So allow me to frame my request in very straightforward terms.
If there is a solution to the 8-bit parallel 8080 bus problem, what exactly has to be done to configure the I2S peripheral in order for it to output a stream of 8-bit packets of data, some of which can't be packed in pairs to form 16 bit words, with the eventual need to flip a GPIO that represents the Command/Data (RS) signal, with the bus sampled by strobing the WR (WS) signal, with a maximum clock defined as an integer divisor of the APB clock, with DMA enabled to offload the CPU during larger transfers (and let's ignore reading the bus just for the sake of making things easier), and possibly not necessitating a wasteful memory relayout procedure for large transfers?
A working port of ILI9341 connected via 8 bit parallel would be the perfect demonstration, since it's such a common shield, but I'm happily settling for a clear, focused and authoritative explanation of that needs to be done to make the I2S LCD mode work for any bus width.
Thanks in advance for any help!
Regards,
CG
This is supposed to be a simple question with plenty of references between the "har-in-air" Github repo (based upon @ESP_igrr code I reckon), the "pixelmatix" repo (which shares the same "DNA" I think), the esp-iot-solution LCD examples and the camera samples (also by @ESP_igrr on his repo).
But I can't for the life of me drive an 8-bit 8080 bus peripheral (which happens to be a LCD). I'm using a regular ILI9341 mcufriend-like Arduino-ish shield which works just peachy with TFT_eSPI in parallel mode (which bit-bangs the GPIOs). Every attempt I made of porting it to a esp-iot-solution component using I2S was a wreck. And I suspect it has to do with the code there always expecting 16 bit commands/register selections or equivalently that high data lines D[23:8] are not-cares for command parameters (see ILI9341 datasheet v1.11, page 110 for an example; also https://github.com/espressif/esp-iot-solution/issues/19).
After messing with the i2s_lcd_com code and attempting to send only 8 bits instead of what is clearly a two step write with byte swapping on iot_i2s_lcd_write_cmd (and rewriting iot_i2s_lcd_write_data to look similar to the cmd version, identical to the 16 bit version as a matter of fact except for masking data with & 0xFF; I wonder if this could work like the SPI master driver where you define a length in bits and use a byte swapping macro?). I currently have the LCD showing a very corrupt image with severe "banding" and every hint of garbage-in-garbage-out, not to mention colour inversion; but I can recognise some thin strips of the original image (which is just the demo from esp-iot-solution).
I read the TRM. I read all the above code. I'm getting pretty much nowhere in my attempts to grafting working parts together. And the fact that I have no logic analyser is making my working hours something less of a pleasure as I find myself stuck in a loop of trials and errors. My reading of the TRM v3.9, pages 306 to 312, lead me to believe the I2S peripheral just can't cope with the fact that some data simply can't be organised as 16 bit packets. In addition, for the data that can be thusly organised, the Data Frames Form 1 and 2 happen to be so esoteric that most gains from DMA are lost in attempts to re-layout memory, and that should have been instead a straightforward bitblt operation.
So allow me to frame my request in very straightforward terms.
If there is a solution to the 8-bit parallel 8080 bus problem, what exactly has to be done to configure the I2S peripheral in order for it to output a stream of 8-bit packets of data, some of which can't be packed in pairs to form 16 bit words, with the eventual need to flip a GPIO that represents the Command/Data (RS) signal, with the bus sampled by strobing the WR (WS) signal, with a maximum clock defined as an integer divisor of the APB clock, with DMA enabled to offload the CPU during larger transfers (and let's ignore reading the bus just for the sake of making things easier), and possibly not necessitating a wasteful memory relayout procedure for large transfers?
A working port of ILI9341 connected via 8 bit parallel would be the perfect demonstration, since it's such a common shield, but I'm happily settling for a clear, focused and authoritative explanation of that needs to be done to make the I2S LCD mode work for any bus width.
Thanks in advance for any help!
Regards,
CG