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

[r_teixeir]

Hi Ben and team,
I hope you are well.
I am writing to ask for a little help with this component, as I am currently stuck on this issue and unable to get a simple "Hello World" to display on my hardware after flashing the HEX file.
I’m using Flowcode v11 (Professional Version) and trying to get the LCD Mini Click to work. Based on the generated C code, it looks like there might be a register address mismatch (BANK 0 vs BANK 1) for the MCP23517 expander, which prevents the characters from showing up on the physical screen.
Could you please help me understand what might be causing this compatibility issue or how I can bypass it? If anyone has a working workaround or could take a look at the attached .fcfx file, I would truly appreciate it.
Thank you so much for your time and continuous support!
Best regards,
Rod

[BenR]

Hi Rod,

Thanks for the details analysis and explanation and also bearing with us. I'm looking into it now and hopefully will have a solution for you ASAP.

Just so you're aware the component source files are available in the wiki so if you ever need to make a change to a component you can do so but obviously we also need to know about problems so we can do an official fix for everyone. Any changes you do make can simply be reverted if required by using the library updates.

Looking at the problem it appears that we are correctly addressing for Bank0 already, 14 and 15 are the output latch registers used to write values to Port A and B. Writes to the GPIO registers 12 and 13 forward the write to the LAT register so it's effectively the same thing.

Screenshot 2026-06-18 095336.png (77.99 KiB) Viewed 401 times

I'll have a dig and see if I have one of these displays somewhere to do some testing.

[BenR]

Looking at your project you have a C code icon near the top of your program, this is not required and could be causing issues.

You could also maybe try disabling the call to the other SPI while you are debugging the screen to see if that can help as it's sharing pins with the display component.

I've compared the display SPI settings with the IO expander component settings and they seem to match up and so should be working fine but if you like you can try altering these and see if that helps.

To do this click on View -> Component Debugger and check the Expose full component tree option.

Using the drop down menu at the top of the properties window, In the LCD display find the cal_spi component as shown here.

Screenshot 2026-06-18 100735.png (10.09 KiB) Viewed 396 times

Then try adjusting the properties in the Options section.

Maybe try Clock Phase -> Leading edge

Idle low for the clock already looks to be correct and sample point is for read back.

Let us know if this makes a difference and if it does I'll update the components so this is the default.

[r_teixeir]

Hi Benj,
Thank you for your guidance. Following your instructions exactly, I completely removed any custom C code blocks from my program to eliminate any potential interference. The flowchart now relies 100% on the native component macros (Start, Clear, PrintString) in a clean, purely visual structure.

I also went into the Component Debugger, exposed the full tree, and selected the underlying cal_spi1 sub-component as you shown. I adjusted the properties in the Options section to change the Clock Phase to Leading edge, while keeping Clock Idle Low, Sample Point for read back, and the CS Polarity set to Active Low (as required by the physical hardware layout).
Unfortunately, even after applying these exact configuration adjustments and using the native macro path, the physical screen on the dsPIC33EP setup still remains completely blank. I also experimented with all the other available channels in the component properties (Channel 1, Channel 2, etc.) to see if a hardware peripheral routing would make a difference, but none of them worked either.

To completely isolate the hardware, I tested this same LCD Mini Click board on a Clicker 2 for PIC18FJ development board. I flashed the official C example program available on the MikroElektronika website using MikroC PRO for PIC, and the "Hello World" works flawlessly there.
This test confirms that the display hardware, the expander, and the contrast chips are 100% functional. The communication failure only occurs when compiling the project through Flowcode 11 for the 16-bit dsPIC33EP architecture on this slot layout. Please let me know if you can look into this behavior, or if there is an official update or test build I could try to make the native macros work.

On a side note, since Flowcode already provides excellent standalone components for the MCP23S17 (IO Expander), the MCP41XX (Digital Potentiometer), and the Generic Alphanumeric LCD, would it be possible for the development team to consider adding a native way to interface them together within the properties window?

Currently, these components cannot "talk" to each other visually. For instance, the generic LCD component only allows mapping its data and control lines directly to the microcontroller's physical pins, with no API or drop-down option to route them through the virtual ports of an active MCP23S17 component. Having this native interoperability or an official backpack/bus mapping API would be an amazing feature for custom hardware layouts and a great fallback option when integrated drivers hit target-specific limitations.
Best regards,
Rodrigo

[BenR]

Hello Rodrigo,

I'll get one of the displays on order and do some testing here. hopefully we can get you up and running ASAP.

As for the IO expander yes we have wanted to add a feature called virtual pins for some time now where you would get more port pins you can connect other components to and it would seamlessly work via the IO expander. It's very much on our list and I'll see if I can get it bumped up again.