Making use of a 7 segment LCD

We have done that and you got gibberish.
My first 3 numbers were to set character 4, 3 and 2 respectively using a 4x8bit unsigned long.

Did you try 64 first?

I wonder if LedSetCcontrast is related to the matrix display or the notification LED? If it is the matrix, then it shoots down the idea that it is waiting for command headers.

How do you mean try 64 first exactly? My apologies

Could you link us the forum thread you found? Perhaps that will help to further shed a light on things.

e.g.

Of course!
Here it is: https://www.mikrocontroller.net/topic/210759?page=single#2345506 (towards the end of the post)
It's all German, but using Google Translate to translate the page should work well, and if we need to get a more precise translation I can do it

Any change with 64?

I gave this a try, but it just returned the same gibberish as before when calling 4294967295

Which makes sense as the function is sending a long, but I was hoping that digit 4 would be different that time.

The control codes are:

64 set to write mode with incremental addressing

128 turn the display off

136 turn back on

137 - 143 should change the dimming

They should be 1 byte though, not 4.

I'll have a think in the morning, heading off now. Night.

I assume that you tried your experiment sending in a byte array to the function and that it crashed? Are there any overloaded versions of the function, can you get the full function definition out of the tool?

What usually happens with these matrix displays is that you have to process the matrix controller through a series of state changes in order to change a value, but your function dump is not showing anything like that.

Usually a typical data flow would be:
Set the command pin to low
Send the receive data write command (64)
Set the command pin to high
Set the command pin to low
Send each byte to the matrix with the data values
Set the command pin to high

After sending FFFFFFFF failed, I was hoping that it just needed to be prefixed with the command instruction, but evidently not.

I did try sending an array to it, but that just resulted in more random characters
There's an executable belonging to the system that writes to the display as part of its functioning which I've tried to disassemble to see how it calls the DLL, but sadly my knowledge of MIPS assembly isn't good enough to understand what's truly going on

Do you perhaps know how I could figure out how it's calling the DLL?

Edited by I dunk for bananas 2023-06-19 2:09 PM

The fact that it hasn't been caught as a runtime exception when passed an array or a long uint suggests that it's overloaded or a bizarrely typed generic.

Did you send in an array of uint or array of bytes?
_int8 arr[0] = 255;
_int8 arr[1] = 255;
_int8 arr[2] = 255;
_int8 arr[3] = 255;

Not without having symbols and a watcher on the debug executable, no. My ASM is non-existent.

It doesn't have an overload for
_int8 data = 255;
ledSetDigits(data,data,data,data)
Does it? That has to force a crash now, surely?

Apologies for the silence, life threw me a curveball!



I think this is a bingo. The display now reads 8.8.8.8.

Attachments
----------------
hpcf.jpg (45KB - 0 downloads)

Congratulations!