robertlipe commented on issue #5810:
URL:
https://github.com/apache/incubator-nuttx/issues/5810#issuecomment-1077289054
If it helps, I got lost in the layering, too. I wasn't sure what was
supposed to be in kernel/"user" space and who was supposed to be able to
fondle each others' bits from any given layer in the abstraction. That's
why I called in for design guidance from those above with familiarity with
multiple subsystems.
Though I saw that ESP32-C3 got one case "more right" than BL602, I wasn't
really convinced it was the ideal role model, either. That was the point I
started chasing both ends of the candle, one up and over into
well-exercised ARM boards and generic vs. chip vs board vs any given bit
being remapped as a normal GPIO or a specialized SPIO-type pin - and if the
inversion was done within the chip itself AND learning the other end and
getting tripped up in LVGL vs. NX and a framebuffer vs. a framework and so
on as those didn't seem to have crisp edges to me. Your code had the MISO
swap and trunk didn't, so I wasn't sure it had been done in some other way,
but that was also the time I was working with your branch and not nuttx
master, so I couldn't tell if that was a design decision or just a.
dropped/unneeded/unwanted PR.
I got quite confused and had to mentally context switch away from it
for other reasons; I've not made it back since then. I hope to get back to
it in the next couple of days.
Good luck!
On Wed, Mar 23, 2022 at 9:23 PM Lee Lup Yuen ***@***.***>
wrote:
> ST7789 Driver runs in Kernel Space so I don't think it can access
> /dev/gpio*?
>
> There is a generic LCD Driver that wraps up the ST7789 Driver as /dev/lcd*
> :
>
>
>
https://github.com/lupyuen/incubator-nuttx/blob/st7789/drivers/lcd/lcd_dev.c#L342-L343
>
> I suppose LVGL runs in User Mode to access /dev/lcd*? I'm still
> deciphering the code.
>
> There's another GPIO quirk inside the SPI Driver for ESP32: To control the
> ST7789 Data/Command Pin, the SPI Driver flips the MISO Pin as though it was
> a GPIO: esp32c3_board_spi.c
>
<https://github.com/lupyuen/incubator-nuttx/blob/st7789/boards/risc-v/esp32c3/esp32c3-devkit/src/esp32c3_board_spi.c#L64-L84>
>
> int esp32c3_spi2_cmddata(FAR struct spi_dev_s *dev, uint32_t devid, bool
cmd) {
> ...
> /* This is the Data/Command control pad which determines whether
the * data bits are data or a command. */
> esp32c3_gpiowrite(CONFIG_ESP32C3_SPI2_MISOPIN, !cmd);
>
> To implement this on BL602 I'm trying to reconfigure MISO as GPIO on the
> fly: bl602_spi.c
>
<https://github.com/lupyuen/incubator-nuttx/blob/st7789/arch/risc-v/src/bl602/bl602_spi.c#L709-L735>
>
> static int bl602_spi_cmddata(struct spi_dev_s *dev, uint32_t devid, bool
cmd) {
> // MISO is now configured as SPI Pin. We reconfigure MISO as GPIO Pin.
> gpio_pinset_t gpio =
> (BOARD_SPI_MISO & GPIO_PIN_MASK) // Get the pin number
> | GPIO_OUTPUT | GPIO_PULLUP | GPIO_FUNC_SWGPIO; // Change to GPIO
Output
> int ret = bl602_configgpio(gpio);
> ...
> // Set MISO to High (data) or Low (command)
> bl602_gpiowrite(gpio, !cmd);
>
> // After this the caller will transmit data or command.
> // Then bl602_spi_select() will revert MISO back from GPIO to SPI Pin.
> // We must revert because the SPI Bus may be used by other drivers.
> return OK;
> }
>
> I'm now testing this with a Logic Analyser. I'm hitting another problem
> with SPI Receive Timeout but I'll explain later:
>
> https://github.com/lupyuen/incubator-nuttx/pull/39/files
>
> —
> Reply to this email directly, view it on GitHub
>
<https://github.com/apache/incubator-nuttx/issues/5810#issuecomment-1077001344>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/ACCSD3Y4BTCE5JJRNNQSFGDVBPG2BANCNFSM5RGMP4IQ>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
