Electronics > Projects, Designs, and Technical Stuff
Critique my first PCB
<< < (13/17) > >>
carl0s:
Oh, actually, it has been a year. About 1yr and 2 weeks :-)
TiN:
Differential pairs are not routed differentially, as they should be. Good idea to calculate impedance to your stackup so you can maintain correct trace width/spacing to have good SI.
Avoid 90 bends, use 45 degree or arcs. All power connect by wide trace or better yet copper pour shape.
Do not use thermal connection for GND vias, you just introducing more inductance/impedance without any good reason.
All parts with GND connections should have just via next to pad right next to pad, no traces. Nice touch to have evenly distributed GND vias around GND pads of that Mictor connector.
carl0s:

--- Quote from: TiN on August 03, 2019, 04:05:39 pm ---Differential pairs are not routed differentially, as they should be. Good idea to calculate impedance to your stackup so you can maintain correct trace width/spacing to have good SI.
Avoid 90 bends, use 45 degree or arcs. All power connect by wide trace or better yet copper pour shape.
Do not use thermal connection for GND vias, you just introducing more inductance/impedance without any good reason.
All parts with GND connections should have just via next to pad right next to pad, no traces. Nice touch to have evenly distributed GND vias around GND pads of that Mictor connector.

--- End quote ---

Thank you. I'll take this on board for next time. The differential pairs are length-matched. Is that not what you mean?
luiHS:

--- Quote from: carl0s on August 03, 2019, 03:42:34 pm ---You will be surprised. It looks like, apart from one command, I simply removed all the rest.

I was working with the BSP Example / Demo. I.e. the board support package demo - that's what you can see in my photos before, with the ST logo etc.

My changed version of that sequence looks like this :

--- Code: ---    /*************************/
    /* LCD POWER ON SEQUENCE */
    /*************************/


// very minimal init code for panasys round octagonal tft
// this is 0x36 for MADCTL, with parameter 0x48 for xmirror, top left to bottom-right, bgr
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x48);
    //HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3A, 0x55);



    /* Sleep out */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

    HAL_Delay(120);

--- End code ---

Essentially I replaced all the LCD init code with a simple MATCTL 0x48 (that is cmd 0x36, data 0x48).

--- End quote ---


Perfect, thanks for your information, very useful for me.

However, there is a signal, the TE (Tearing effect), I don't know if you are using it. For pictures, it is perhaps not important, but to play videos may be essential, it is a synchronization signal that sends the screen to the program, to avoid an effect that would cause half of the upper image not to be synchronized with the other half, let's say half of the screen would show the current frame and the other half still the previous frame.

This octagonal screen does have the TE signal, but I have other screens that do not. I suppose that the screens that do not have the TE signal would not serve to play video, just to see images.

In the list of commands sent to me by the seller of the screen, there is command 35, data 00, related to the activation of the TE signal.



--- Quote from: carl0s on August 03, 2019, 03:42:34 pm ---I created a rough GFXMMU_LUT, but this is just to save memory by, erm, not allocating the bits of pixel space that would be outside of the circle. I think you can work without it..

--- End quote ---

I also have the same kit you used to do your tests with round screens. I read something about specific routines to save space in RAM, eliminating all the pixels that are outside the circular area of ​​the screen. As soon as I get my screen to work, I will see if setting up that routine correctly, I can optimize the performance of the program. Notwithstanding the example sources for the STM32F769, they are for rectancular screens such as the one included in Discovery, these routines of the STM32L4R9I-DISCOVERY kit should be added.



--- Quote from: carl0s on August 03, 2019, 03:42:34 pm ---Obviously I disabled all touchscreen stuff in the demo code

I made other modifications for the width, height, etc
essentially, all the modifications I made to the BSP LCD drivers, are in the files here:
http://internetsomething.com/lcd/bsp-example/

I'll see if I can get the screen to do anything useful on the STM32F769I Disco board, although I only have about an hour, and I haven't been near C or STM32 in what feels like a year, and I was only just starting to learn it then too, so it's not very clear to me really ;)

--- End quote ---

I will also check all the parameters, in the Cube for the F769, there is also the Drivers / BSP directory with the sources for the lcd that define all those parameters. The sources in the Cube for Discovery with the F769 are for visualizing images. The source for playing videos is for the EVAL board.

Both, Discovery and EVAL evaluation boards, use the same microcontroller, the differences in practice to be able to use the EVAL example source code in Discovery are these.

1.- The EVAL has two SD cardholders, the Discovery only one. In the EVAL sources the cardholder that does not have the Discovery is used, I think the SD1. It would be necessary to edit the sources and change it, it seems simple.

2.- The EVAL Card Detect is connected through an I2c expander, while in the Discovery it goes directly to a GPIO port. It also seems a simple change to make.

3.- The SDRAM in the EVAL is double, 256 Megabytes, in the Discovery we have 128 Megabytes. I don't know if this can be a problem to be able to run the program that plays videos. If 256 megabytes of SDRAM were necessary for the video player, then I will make my own board, with the F769, the SDRAM and an SD card holder, in addition to the backlight voltage booster.


For the voltage booster, for the backlight, I use this scheme with several jumpers, to select several voltages, for the different display models I have, each one requires a different voltage.
carl0s:
I've been trying to do something with the STM32F769I-DISCO. Firstly trying to build an empty StemWin 'hello world'. I previously compiled the example projects, and they all work fine, but I couldn't get anything to display on the board that CubeMX/STM32CubeIDE had created. The plan was to get that working, seeing as though it's the kit exactly as chosen in the CubeMX 'board selector (including screen)', and then once working, see if I could get the round/octagonal screen to do something useful.

Anyway I've had to 'work from home' today due to sleep deprivation trying to figure out why STM32CubeIDE would not do a Hello World even with the original screen. It's because the LCD_LL_Reset() isn't implemented - seems CubeMX (which is now not really called CubeMX as it's integrated into the IDE that used to be called TrueStudio but is now STM32CubeIDE) just doesn't use the BSP stuff at all. That's why in the Graphics 'Platform Settings' it says 'BSP API: Unknown':


So I just copied the BSP reset function (which is used by the examples) into the empty LCD_LL_Reset() function that CubeMX generated.

--- Code: --- /* Configures the LCD reset pin. */

     /* USER CODE BEGIN Config_LCD_Reset_Pin */
        static void LCD_LL_Reset(void) {
            GPIO_InitTypeDef  gpio_init_structure;

              __HAL_RCC_GPIOJ_CLK_ENABLE();

                /* Configure the GPIO on PJ15 */
                gpio_init_structure.Pin   = GPIO_PIN_15;
                gpio_init_structure.Mode  = GPIO_MODE_OUTPUT_PP;
                gpio_init_structure.Pull  = GPIO_PULLUP;
                gpio_init_structure.Speed = GPIO_SPEED_HIGH;

                HAL_GPIO_Init(GPIOJ, &gpio_init_structure);

                /* Activate XRES active low */
                HAL_GPIO_WritePin(GPIOJ, GPIO_PIN_15, GPIO_PIN_RESET);

                HAL_Delay(20); /* wait 20 ms */

                /* Desactivate XRES */
                HAL_GPIO_WritePin(GPIOJ, GPIO_PIN_15, GPIO_PIN_SET);

                /* Wait for 10ms after releasing XRES before sending commands */
                HAL_Delay(10);
        }
      /* USER CODE END Config_LCD_Reset_Pin */

--- End code ---

That then worked - I had a working Hello World on the original screen.

Moving onto the octagonal screen, I still told CubeMX that I was using the OTM8009A screen, just so I could see where they usually put the DSI commands and stuff. Selecting 'Other screen' left me a bit in the dark about that.

It was in HW_Init.c at line 370 in this case (will be different depending what HW peripherials CubeMX is setting up I suppose)
I obviously changed to One Data Lane in the DSIHOST -> Data and Clock lanes configuration

and you can see I've put those same DSI init commands here as what I did before.

--- Code: ---  /* Initialize the OTM8009A LCD Display IC Driver (KoD LCD IC Driver)
   *  depending on configuration set in 'hdsivideo_handle'.
   */

  /* Send Display off DCS Command to display */
//  HAL_DSI_ShortWrite(&(hdsi),
//                     0,
//                     DSI_DCS_SHORT_PKT_WRITE_P1,
//                     OTM8009A_CMD_DISPOFF,
//                     0x00);

//  OTM8009A_Init(OTM8009A_FORMAT, OTM8009A_ORIENTATION_LANDSCAPE);
  HAL_DSI_ShortWrite(&hdsi, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x48);
  HAL_DSI_ShortWrite(&hdsi, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

--- End code ---

Anyway at least it's doing something finally :)



I don't have any video stuff to try though I'm afraid.

Got to admit, this had made me even more eager to focus on Python and MicroPython as much as possible. It's freakin' horrible. Well, trying to get TouchGFX & STM32CubeIDE to play nicely together was anyway. I was probably screwing around with that 'til 2am :(
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod