Title: Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 05:59:26
Hi all, as long as I started reconstruct display module I wrote benchmark to see progress. I strongly believe that we can more then double performance of SPI displays.
I compiled only for F4. Could you test and post your results here in the next format... ( for now only SPI displays interested by me )
V.0.0
FullRect ->
ColorPoint ->
LineWithGrad ->
TextSmall ->
TextLarge ->
TextRight ->
TextCentered ->
Text8Bit ->
Type of display ->
|
Title: Re:Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 06:04:23
BTW: my result is with recent code from repo is
with SPI_BAUDRATEPRESCALER_4 |
Title: Re:Benchmark for LCD.
Post by: DF8OE on 04. December 2018, 06:27:43
Hi Maksim,
this is the result from my last SPI driven device (SPI is very rare used and is replaced by parallel in most devices - OVI40 does not support SPI at all):
FullRect -> 11748
ColorPoint -> 6088
LineWithGrad -> 3026
TextSmall -> 1049
TextLarge -> 4526
TextRight -> 4526
TextCentered -> 7000
Text8Bit -> 9608
Type of display -> 3.2" SPI
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 04. December 2018, 06:51:57
Hi Maksim,
how do you plan to double the performance, if the SPI clock is not being changed? Waiting for the SPI to finish the previous transfer is probably the largest influence. You can't be faster than back to back transfer?
There is potential for speeding up, but only the waterfall could benefit from that really: Drawing in the "background", i.e. the SPI DMA interrupt nows what to draw next without the CPU waiting. But this "autonomous drawing" would have to be synchronized with other lcd operations.
So, please share your idea. More than happy to test these, since I do own a SPI mcHF.
73
Danilo
|
Title: Re:Benchmark for LCD.
Post by: DF8OE on 04. December 2018, 07:14:14
Just for information two other results:
FullRect -> 1258
ColorPoint -> 397
LineWithGrad -> 499
TextSmall -> 168
TextLarge -> 956
TextRight -> 956
TextCentered -> 1211
Text8Bit -> 2235
Type of display -> HY28B parallel
FullRect -> 1006
ColorPoint -> 187
LineWithGrad -> 429
TextSmall -> 132
TextLarge -> 857
TextRight -> 857
TextCentered -> 1059
Text8Bit -> 2030
Type of display ->3.5" parallel @480x320
I think lower values are better performance... If so: this shows in an impressive way the difference between the LCD types and operating modes. 3.5" LCD whith higher resolution has better performance (at same resolution) than HY28B so performance with full resolution is only a bit slower than "original LCD". All tests done with F429 MCU.
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: SP9BSL on 04. December 2018, 17:34:07
Hi Maksim,
One thing from me: simple speedup of the SPI by changing the prescaler will cause the crash of some LCDs. We had this a year ago with RPI3.5" SPI lcd and F7...
Like Danilo said, the main bootleneck is with waterfall update. The real possibility we have in new RA8875 driver, we can use some of its hardware features to lower the data amount, but this is future.
As usual: I will gladly learn something new if you show us... |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 21:05:49
Hi all. Yes the numbers in ms, so less number is better...
this is the result from my last SPI driven device:
FullRect -> 11748
ColorPoint -> 6088
LineWithGrad -> 3026
TextSmall -> 1049
TextLarge -> 4526
TextRight -> 4526
TextCentered -> 7000
Text8Bit -> 9608
Type of display -> 3.2" SPI
|
|
Interesting, do you see on my display (It's 2.4" 240x320 ILI9341) to draw ColorPoints took less (2087ms) then on yours display (3026ms)...
I do mention that 8bit font is not print properly on my display, is it the same on yours? (The last print before result.)
|
Title: Re:Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 21:07:09
Just for information two other results:
FullRect -> 1258
ColorPoint -> 397
LineWithGrad -> 499
TextSmall -> 168
TextLarge -> 956
TextRight -> 956
TextCentered -> 1211
Text8Bit -> 2235
Type of display -> HY28B parallel
FullRect -> 1006
ColorPoint -> 187
LineWithGrad -> 429
TextSmall -> 132
TextLarge -> 857
TextRight -> 857
TextCentered -> 1059
Text8Bit -> 2030
Type of display ->3.5" @ 480x320
|
|
All of them are also SPI? |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 21:13:48
Hi Maksim,
One thing from me: simple speedup of the SPI by changing the prescaler will cause the crash of some LCDs. We had this a year ago with RPI3.5" SPI lcd and F7...
|
|
Thank you for heads-up. That's why I started by posted benchmark FW before making PR to be sure that's it's still working.
|
Title: Re:Benchmark for LCD.
Post by: RV9YW on 04. December 2018, 21:20:00
Hi Maksim,
how do you plan to double the performance, if the SPI clock is not being changed? Waiting for the SPI to finish the previous transfer is probably the largest influence. You can't be faster than back to back transfer?
There is potential for speeding up, but only the waterfall could benefit from that really: Drawing in the "background", i.e. the SPI DMA interrupt nows what to draw next without the CPU waiting. But this "autonomous drawing" would have to be synchronized with other lcd operations.
So, please share your idea. More than happy to test these, since I do own a SPI mcHF.
73
Danilo
|
|
We do not use some features of STM SPI hardware, such cycle mode and 16bit transfers...
We can improve DrawFullRect by 10 times I believe, some others two times.
I'll post later the next benchmark, we will see.
PS, Danilo could you share your results, please. |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 05. December 2018, 02:07:27
Hi,
We do not use some features of STM SPI hardware, such cycle mode and 16bit transfers...
We can improve DrawFullRect by 10 times I believe, some others two times.
I'll post later the next benchmark, we will see.
PS, Danilo could you share your results, please.
|
|
The main screen activity is the waterfall, everything else is even on the SPI display decent (not that it cannot get better or that you could make use of the added speed). Doubling speed of functions not really contributing to the overall load is nice, but what would be the point of this? And should we pay the price in terms of more complex software for it? Nothing comes for free.
For waterfall the SPI transfers we use should ensure back to back transfers, even in 8bit mode, and I don't how much you can save with 16bit vs. 2x8 bit. Its is surely some percentage but not like two times faster.
That should not stop you, but I would really urge everyone (including myself!) to consider making things not too complex for just a little gain. Synthetic benchmarks are good and important but they often tell you little about the real world.
I cannot share my results at the moment, because I can't run the benchmark. BTW, if the benchmark is based on the UHSDR software which runs under GPLv3 , you have to give everyone who asks for it access to the source code used to compile the benchmark binary.
Consider yourself ask. I just want to see how you are measuring the performance.
73
Danilo |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 05. December 2018, 03:32:40
For waterfall the SPI transfers we use should ensure back to back transfers, even in 8bit mode, and I don't how much you can save with 16bit vs. 2x8 bit. Its is surely some percentage but not like two times faster.
|
|
Yes, you are right it's not two times, but we can buy some time for another tasks. And my main purpose to rewrite this to make it easy later to adopt with rtos... We would just need to change couple lines by take and give semaphore... No it's more complex.
Even if we get 1..5 % it's worth
Synthetic benchmarks are good and important but they often tell you little about the real world.
|
|
I would not call it pure synthetic because I call it from main loop instead of calling UI. So, all interrupts are up and triggering. Only I2c parts are missed. Nothing connected...
BTW, if the benchmark is based on the UHSDR software which runs under GPLv3 , you have to give everyone who asks for it access to the source code used to compile the benchmark binary.
Consider yourself ask. I just want to see how you are measuring the performance.
|
|
Sure, there is nothing fancy....
I know it's not good to use HAL tick timer because PendSV has higher priority and eat CPU cycles, but it's OK for relative measurements.
I've attached, take a look please... and I call UiLcdHy28_DoBenchmark() instead of UiDriver_TaskHandler_MainTasks()
BTW, does any one see that 8bitFont is not working properly? Or it's only on my side?
|
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 05. December 2018, 04:28:33
Hi Maksim,
you are running this with the audio interrupt active?
Then your benchmark is not comparable between machines. Comment it out, since depending on the user's last settings we have different load in the audio interrupt, which affects the produced numbers more a lot.
And, no I don't think 1.5% performance improvement on a function which may be responsible for 10% of the total load (which makes it an improvement of 0.15% with respect to full system load) alone is worth much more complex code or difficult code. I am not saying that your idea has any of this. It is just my general opinion.
The main improvement in terms of freeing time for other stuff (not for making the graphics as such faster) would be to make the waterfall code running the screen update in parallel to other activities (right now we wait most of the time for the previous spi transfer to be finished...).
But this is all theory without seeing what you are to achieve and how, so go ahead and let us see.
73
Danilo
|
Title: Re:Benchmark for LCD.
Post by: RV9YW on 05. December 2018, 04:54:35
you are running this with the audio interrupt active?
|
|
Could you suggest easiest way to disable them? Thank you |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 05. December 2018, 05:21:54
Hi Maksim,
Comment out AudioDriver_Init()
https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/src/uhsdr_main.c#L572 (https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/src/uhsdr_main.c#L572)
73
Danilo
|
Title: Re:Benchmark for LCD.
Post by: DF8OE on 05. December 2018, 05:29:30
My two benchmarks in one post are for parallel use. The single benchmark is for SPI - but I think I will revert this device to parallel back because of RF interference and speed args some times...
I have done the maths ~ a year ago and I think we are near at the edge regarding theoretical maximum speed of SPI at the real usage in UHSDR (button boxes, waterfall, scope). It is not possible to blow up the speed by simply changing the prescaler because a reasonable amount of LCDs does not work with higher clock. I bymyself do think that an improvement of x2 is recognizeable - but swapping to parallel will do the job much better. Because of OVI40 only works in parallel mode anything regarding SPI speed does not affect anything there.
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: SP9BSL on 05. December 2018, 07:55:07
BTW, does any one see that 8bitFont is not working properly? Or it's only on my side?
|
|
Hi Maksim,
the 8 bit font was defined only for digits and a dot. That's because 8bit bitmap needs memory, and currently we don't need them for other purposes than freq display. You may see the fonts working looking for pictures here in the forum, or on Aliexpress with RS928 ;) |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 22. December 2018, 18:44:49
Hi Danilo, could you help.
In UiLcdHy28_ReadDisplayId_ILI9486() there is a comment such - "// we can't read the id from SPI if it is the dumb RPi SPI"
What's the problem? because this type of displays do use the shift registers to implement SPI interface over normal 8080? or because ILI9486 and ILI9486L are using SPI in half-duplex mode (one pin SDA for sending and receiving data )?
thank's
Max
73 |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 22. December 2018, 21:15:31
Hi Max,
the reason is that these displays are connected using simple shiftregisters (i.e. it is a unidirectional, write-only SPI).
It is impossible to test for existence of this particular display controller configuration. That is way it needs to be last in the list.
The main reason to support it is the availability (search for 3.5 RPI SPI touchscreen display)
73
Danilo
|
Title: Re:Benchmark for LCD.
Post by: DF8OE on 23. December 2018, 11:35:39
Hi Max,
additional info:
I have got a LCD panel where we do have access to complete pins of ILI9486 controller. My idea was to configure SPI or parallel use on LCD PCB. So this panel is "standard panel" for OVI40 actual (but only in parallel mode). Hardware implementation may be usable now - but if you look at the controllers datasheet you will see a very strange data and handshaking protocol which is not supported by anc MCU. You have to write bit banging code and transform data before shifting it to LCD. This would slow down complete process much and would result in not-usable speed...
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 23. December 2018, 11:44:01
Hi,
the weird SPI protocol is the main reason (IMHO) why the chinese manufacturers added extra components on the pcb to implement a simple SPI to PARALLEL converter instead of just exposing the controllers "SPI". They would never do this unless there is a good reason for it (it costs extra money).
73
Danilo |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 23. December 2018, 17:39:21
Hi Max,
...
but if you look at the controllers datasheet you will see a very strange data and handshaking protocol which is not supported by anc MCU...
vy 73
Andreas
|
|
Sorry, did not get what do you mean exactly!? |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 23. December 2018, 17:50:09
I take a look one more times, looks the same as for ili9341. I found only one incompatible thing with STM32 SPI is that they are required different number of dummy clocks for different read sequences.
Did I miss something more?
BTW, guys what kind of displays do you have handy to help me with tests?
I wrote driver for ILI9341 and test with it, I'm waiting EVO40 kit for testing with display from it, but looks like it stuck in Frankfurt am Main... |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 23. December 2018, 17:54:25
In my code I removed reverse like this
// for (uint32_t i = 0; i < len; i++)
// {
// pixel = __REV16(pixel); // reverse byte order;
// }
because I'm using SPI in 16bit mode, so no need to do it. Andreas, did you mean this?
Max, 73
|
Title: Re:Benchmark for LCD.
Post by: DF8OE on 23. December 2018, 18:29:44
Pse take a look at page 32 of ILI9486 datasheet. There you can find strange data line assignment and data format under 7.1.3. This has nothing to do with SPI as we know and is used on STM.
EDIT:
Parcel has left Germany ~14 days ago. Unfortunately I cannot get tracking informations outside Germany. This is not uncommon - I do have many shipments where tracking was lost but parvel arrives in spite of this.
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 23. December 2018, 18:40:03
Pse take a look at page 32 of ILI9486 datasheet. There you can find strange data line assignment and data format under 7.1.3. This has nothing to do with SPI as we know and is used on STM.
vy 73
Andreas
|
|
Do you mean one line SDA for bidirectional communication? If so, the stm SPI can do it also, it calls half-duplex in STM datasheet, as I remember. |
Title: Re:Benchmark for LCD.
Post by: DF8OE on 23. December 2018, 18:43:00
No - I am talking about *9bit* for 3 line SPI which is an approach to standard SPI. I do not know 4 line SPI with a "command switching line" which can work with 8/16 bit.
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: SP9BSL on 23. December 2018, 18:44:44
Hi Maksim,
please be aware of touchscreen communication which uses the same SPI port as we have for display. If using bidirectional data we must continously reconfigure the SPI (if possible at all).
Edit: if you have any idea, and prove it works then why not? We spent some time on it (well Danilo tried) without success... |
Title: Re:Benchmark for LCD.
Post by: DF8OE on 23. December 2018, 18:48:20
Problems are:
1) ILI9486's electrical pin assignment is not SPI at all but very strange serial communication
2) used data format is completely different to ILI9341 SPI
vy 73
Andreas |
Title: Re:Benchmark for LCD.
Post by: DB4PLE on 23. December 2018, 20:35:11
Hi Max,
I don't think it is worth your and our time to provide a direct serial connection to the ILI9486. But since this is a hobby and you can do what you want, let's think this through.
- As Andreas said, due to the shared SPI between touchscreen and display, we need to reprogram the SPI controller for the different modes. We already do this in a very limited fashion, needs to be checked if this is not eating too much time. Just work.
- I don't exactly remember why I decided to stop working on it, I knew about the 9bit capability and tried to figure out how to use it. But at some point could not bring the things together in my head. But I may just not have been smart enough to see the solution. I am very sure, the reprogramming was not the reason, that is solvable.
73
Danilo
|
Title: Re:Benchmark for LCD.
Post by: RV9YW on 23. December 2018, 22:34:22
Thank you all. I'm slowly doing changes in manner as I think it should be... Do not know how better to represent such this big change, maybe to put it in different branch for a while? I'm sure some of displayse will stop work, and I will need some time and your help to fix it all...
and I got Kit today, nice presence before X'mas. Marry X'mas
|
Title: Re:Benchmark for LCD.
Post by: DF8OE on 24. December 2018, 09:11:31
Hi Max,
the best way is you open a new local branch for your work. You do all tests and changes there and you rebase continuously to our active-devel. So you do not loose merge capability. I will think about I fetch this brach and provide it at our "official" GitHub or not - it is not mandatory. If you want we can test your work without having it on our official GitHub.
Regarding "3.5" LCD":
You can find schematics in this thread (https://www.amateurfunk-sulingen.de/forum/index.php?board=18;action=display;threadid=929).
Important information:
There is a hardware error in ILI9486 SPI controller. Data output line stays active even when ILI is in parallel mode. That impavts working of touchscreen controller because its output cannot work "alone" on bus. We never tested if this behaviour remains in ILI SPI mode. If so we would need an additional logic to switch SDO correspondent to state. At your LCD PCB SDO line of ILI is cut and wiring is set to "parallel" (small IC is replaced by a direct connection). Because there is absolutely no need for SPI use at OVI40 this is final state. Of course some mcHF (with RTC mod) may need SPI LCD - but it is not our main goal and struggle to support this on mcHF...
vy73
Andreas |
Title: Re:Benchmark for LCD.
Post by: RV9YW on 26. December 2018, 02:08:52
Have put everything together, did not turn on yet, will do tomorrow... Looks nice!
[url=https://hostingkartinok.com/show-image.php?id=7729cc3caed7d04dbcfe8ab7f8a17ac0] |
Title: Re:Benchmark for LCD.
Post by: DF8OE on 26. December 2018, 09:19:49
Hi Maks,
you can start it using only 5V on Header pin 28. If everything is working you should be able to access MCU via STLink and debug header and/or DFU via USB (with jumper P6 set).
vy 73 and good luck
Andreas |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|