Component: LCD SPI (MiniClick) (Alphanumeric)

[r_teixeir]

Hi Ben,Thank you for the component update! Looking at the newly generated C code from this version, I can confirm that the hardcoded parallel PORTB bit-banging conflict from the base LCD library is now completely gone. The new RawSend routine correctly routes everything through the expander logic via the SendPinsToExpander macro.However, the physical hardware is still not displaying any characters because of an IOCON register addressing mismatch inside the component's WritePort macro.In the updated C output (pages 43-44), the component is hardcoded to write to registers 0x14 and 0x15:

if (FCL_PORT == 1) {
FCD_0c261_LCDMiniClick1__WriteRegister(1, ~FCL_MASK);
FCD_0c261_LCDMiniClick1__WriteRegister(0x15, FCL_VALUE); // Hardcoded to 0x15
}

This configuration implies that the MCP23S17 expander is operating in BANK = 1 mode. However, standard MCP23S17 silicons (including the ones populated on MikroE's official LCD Mini Click boards) always boot up in BANK = 0 by default after a hardware reset.To prove this context, the official working example library from MikroElektronika (mikroC PRO) uses the standard SPI_Lcd_Config(0) routine. Under the hood, MikroE communicates with the MCP23S17 using BANK = 0, which targets register 0x12 for PORTA and 0x13 for PORTB.Since the current Flowcode compilation generates hardcoded writes to 0x14 and 0x15 (which are BANK 1 output latch addresses), the expander completely misinterprets the initialization sequence when it is in its native BANK 0 state, causing the display to remain blank.Could you please update the component's Start macro to explicitly force IOCON = 0x80 at the very beginning to configure the device into BANK 1 address mapping? Alternatively, updating the macro to target the standard native BANK 0 addresses (0x12 and 0x13) should resolve this hardware incompatibility instantly.I have attached this latest generated .c file along with my updated .fcfx project file for your review.

Best regards

Rod