DM-1701 screen clipping

[HA5DS]

I'm talking about rendering, not drawing.

Sorry, I don't quite understand what are you trying to say.

Displaying the RSSI bar is working fine for me after modifying the code.

[VK3KYY]

I'm talking about rendering, not drawing.

Sorry, I don't quite understand what are you trying to say.

Displaying the RSSI bar is working fine for me after modifying the code.

Showing items on the screen is a 2 stage process

First the elements are drawn into the RAM buffer and then they are "rendered" (transferred to the LCD panel)

The render transfer is not super fast and can't be run in the background because the same hardware signals are shared with the keypad. So use of rendering has to be optimised and considered, i.e don't render things on the screen which have not changed as this will make the firmware run slow and ultimately stop things like DMR working

[F1RMB]

Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.

Correction, it's 24 pixels rendering on MD-UV380/DM-1701.

[VK3KYY]

A while ago, I did briefly investigate changing

Code: Select all

void displayRenderRows(int16_t startRow, int16_t endRow)

to render the entire screen 8 lines lower, but for some reason this crashed the firmware

i.e before each render the display is sent the start and end lines of the data transfer

Code: Select all

uint8_t opts[] = { 0x00, startRow, 0x00, endRow };
displayWriteCmds(HX8583_CMD_RASET, sizeof(opts), opts);

So I figured perhaps if this was changed so that

Code: Select all

int fakeStartRow =  startRow + 8;// actually start line
int fakeEndRow =endRow + 8;// actually end line
if (fakeEndRow >DISPLAY_SIZE_Y)
{
fakeEndRow = DISPLAY_SIZE_Y;
endRow = DISPLAY_SIZE_Y; 
}
uint8_t opts[] = { 0x00, fakestartRow , 0x00, fakeEndRow };
displayWriteCmds(HX8583_CMD_RASET, sizeof(opts), opts);

Then perhaps everything would be rendered 8 lines lower, and anything on the last 8 lines would initially be clipped.

Of course the top 8 lines would be full of uninitialised data, but some code could be added to make sure these lines were filled with black, so it looked like they are not part of the display

However like I said, this seemed to crash the firmware, and I didn't have time to investigate why.

I think there is probably a mistake in the transfer length etc, but its strange this would crash the firmware

[HA5DS]

Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.

Correction, it's 24 pixels rendering on MD-UV380/DM-1701.

As far as I can tell the displayRenderRows(0,2) only renders two rows, thus 16 pixels, not 3 rows, right?
Because with this code displayRenderRows(0,2) will became startRow=0, endRow=16, so 16 pixels, right?

Code: Select all

void displayRenderRows(int16_t startRow, int16_t endRow)
{
	GPIO_InitTypeDef GPIO_InitStruct = {0};

	// GD77 display controller has 8 lines per row.
	startRow *= 8;
	endRow *= 8;

[HA5DS]

A while ago, I did briefly investigate changing

Code: Select all

void displayRenderRows(int16_t startRow, int16_t endRow)

to render the entire screen 8 lines lower, but for some reason this crashed the firmware

I think what I did, changing the x,y positions of the header, RSSI bar and some other thing is easier, and since it's done with defines, like many other things, it won't affect any other radio platform.

The modifications are working well on my DM-1701.

Where should I send you the modified code? I cannot send you a PM here.

[VK3KYY]

zip you files and email them to me VK3KYY, my emial is on QRZ.com

However, it sounds like you just basically did a hack that only works on the DM1701 so I'm not sure if it would be practical for us to use your version as it probably affects the other radios

Anyway. Zip the application folder and I will diff your files with the release files and see what you changed

[F1RMB]

Just moving down the header offset is not enough, you will get visual problem, as the header has 16 pixel height, past this it won't really work (like RSSI rendering).
Changing the screen scheme is not an easy task, because you should not break all other supported platform, and also don't harrass the MCU/BUS too much.

Correction, it's 24 pixels rendering on MD-UV380/DM-1701.

As far as I can tell the displayRenderRows(0,2) only renders two rows, thus 16 pixels, not 3 rows, right?
Because with this code displayRenderRows(0,2) will became startRow=0, endRow=16, so 16 pixels, right?

Code: Select all

void displayRenderRows(int16_t startRow, int16_t endRow)
{
	GPIO_InitTypeDef GPIO_InitStruct = {0};

	// GD77 display controller has 8 lines per row.
	startRow *= 8;
	endRow *= 8;

Re-reading the code, yes, 16 pixels. Hence the RSSI bar is not updated each 200ms, which is bad.
Also, as Roger wrote, this is a hack, and will break a lot of things, like scanning/VFO sweep and so on.

[HA5DS]

Re-reading the code, yes, 16 pixels. Hence the RSSI bar is not updated each 200ms, which is bad.

Why wouldn't the RSSI bar update? You assume I did not modify the display rendering parts of the code according to the changed position of the header.
But I did that (and no, not for every platfrom, ONLY for the DM-1701 platform).

Also, as Roger wrote, this is a hack

Can you explain, how doing this:

Code: Select all

#if defined(PLATFORM_MD9600)
	const int FILTER_TEXT_X_CENTER = 32;
	const int POWER_X_CENTER = 60;
	const int COLOR_CODE_X_CENTER = 89;
#elif defined(PLATFORM_DM1701)
	const int FILTER_TEXT_X_CENTER = 40;
	const int POWER_X_CENTER = 70;
	const int COLOR_CODE_X_CENTER = 100;
#else
	const int FILTER_TEXT_X_CENTER = 34;
	const int POWER_X_CENTER = 63;
	const int COLOR_CODE_X_CENTER = 92;
#endif

instead of this:

Code: Select all

#if defined(PLATFORM_MD9600)
	const int FILTER_TEXT_X_CENTER = 32;
	const int POWER_X_CENTER = 60;
	const int COLOR_CODE_X_CENTER = 89;
#else
	const int FILTER_TEXT_X_CENTER = 34;
	const int POWER_X_CENTER = 63;
	const int COLOR_CODE_X_CENTER = 92;
#endif

is a hack??

will break a lot of things, like scanning/VFO sweep and so on.

Why do you think that? Why would it break the VFO sweep, if I modified the VFO sweep area according to the modified header?

Code: Select all

#if defined(PLATFORM_RD5R)
#define VFO_SWEEP_GRAPH_START_Y     8
#define VFO_SWEEP_GRAPH_HEIGHT_Y   30
#elif defined(PLATFORM_MD380) || defined(PLATFORM_MDUV380) || defined(PLATFORM_MD2017)
#define VFO_SWEEP_GRAPH_START_Y    10
#define VFO_SWEEP_GRAPH_HEIGHT_Y   86
#elif defined(PLATFORM_DM1701)
#define VFO_SWEEP_GRAPH_START_Y    22
#define VFO_SWEEP_GRAPH_HEIGHT_Y   74
#else
#define VFO_SWEEP_GRAPH_START_Y    10
#define VFO_SWEEP_GRAPH_HEIGHT_Y   38
#endif

I'm not exactly sure why you assume the worst, and insist that it cannot be done.

At the beginning I wasn't planning to share the code or wanting to commit this to the official firmware, I was just glad, that the source code is available and I could do this for my and my friend's radios, and wanted to share that it can be done.
But after that I was asked if I could do it in a way so it can be part of the official firmware, and I said yes, and I did it.
But now you are saying that it must be a hack, and it won't work, etc. I don't understand where is this coming from...

[F1RMB]

Why that won't work as expected ?
Because you RSSI bar is below the 16th pixel line, hence the 200ms update for that part won't be correctly rendered when the RSSI bar moves up and down quickly, and in some occasion some stuff will overlap on screen (in a pretty ugly way )..

This is why I told you that drawing is one thing, rendering is another one, and have some impacts. So just moving X/Y offsets is not enough, and such vertical stretching is not an easy/quick task.
I don't even mention how the rest of the UI would displays, e.g some frames won't be V-centered, etc.


Cheers.
---
Daniel