Benchmarks

S

starlon

New member
I'm using the time it takes to read LCD memory as a benchmark since speed has been an issue for me. Anyone want to run a similar benchmark and compare? You have to follow the instructions under "Handshaking" in the programming manual, especially where it says to wait for a response before sending the next command. And you have to read from the full 20 8byte memory addresses.

Here's my best, without any resent commands. I expect to be blown out of the water is why I'm bringing this up. Note that I'm using a rather large resend timeout. I'm still playing with it, but I really need that big of a timeout, or close to it.

Edit: Oh it doesn't show it, but this is a CFA635. I don't know if that matters.
Crystalfontz LCD Blog
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

Attachments

Last edited:
CF Tech

CF Tech

Administrator
You can probably get away with having two outstanding packets. It is not part of the official interface standard, but the way the interface is buffered in the module it will probably work. If you "can't" get away with it, you will know because responses will go missing.
 
S

starlon

New member
There was a bug where multiple commands were getting through. For some reason some of those would be lost all together. I'll try out two though. Maybe I'll figure out why command/response pairs were being lost.
 
S

starlon

New member
Here's the results allowing two commands to pass through, 250mS a part, before blocking for responses. Note that the commands resent value doesn't reset between benchmarks. I ran it 3 times before the screenshot, so it's resending on average 3 commands per 20 commands at 1.8 second timeout. I don't think I'll be doing any animations though. Maybe I can make an animation mode where commands are sent at 250mS with no response waiting. Think that would work for animations?
 

Attachments

S

starlon

New member
I suppose fan and DOW reporting can be factored in. With just the 4 fans reporting I'm getting varied results. One was around 70 seconds, while the next came in at 23 seconds. I can't imagine what it's like with 4 fans and 32 DOW sensors reporting. I still have 3-4 sensors I can turn on. (I can't find the 4th. It's still packaged somewhere around here.)

Edit: Oh wow. I was only checking for packets every 250mS. lol. I changed that to every 20mS and now it's fast. 5.25 seconds with no fan packets. And for some reason 5.02 with fan packets. The big difference is there are no resent commands. I think I can start pulling back on the timeout value. I've attached a screenie. That's with fan reporting on.
 

Attachments

Last edited:
CF Tech

CF Tech

Administrator
Hey, you are getting it


I wrote some (windows) command line code that hammered the heck out of the CFA-631 interface (while following all the rules, of course) and we could update that screen several times a second while keys, temperatures and fans were all coming in.

So you should still be able to make some improvement.

It is possible that the environment you are using is getting in the way. Even in C (the "high performance" language) if you do a single write for each character, that is much slower than doing one 20-character block write. I do not know if your development environment has the same kind of issues, but it might be worth looking at.

In theory, you should be able to approach the simplex (only Rx or Tx channel used at a time) data rate. For instance, at 115200 baud a read screen transaction should approach:

Send time = (command,length,address,crc,crc=5 bytes) @ 87uS per byte = 434uS
Receive time = (command,length,address,8bytes,crc,crc-13 bytes) @ 87uS per byte =1128uS

Give the module say 2mS to process:

0.434mS + 1.128mS + 3mS = ~5mS

So to do that 8 times it should be about 40mS or 1/25 of a second.
 
S

starlon

New member
Ah thanks! I was wanting to do that math, but wasn't sure how just yet.

I have to be careful that I'm not creating more threads than gtk/gobject can handle. I'm not sure how to tell that without trial and error.
 
S

starlon

New member
Well, sending two commands at a time introduces a race condition I can't squish. It only effects you when you read a lot of data with the same command (Like Read8ByteMemory), so there can be two modes, one for fast updates and one for reading data. I was just using an accumulator when updating my progress bar. Sometimes that value would end up being 21 or higher. So anyways, I can't figure out a way to fix the bug, so for now sending two commands back to back sometimes breaks the benchmark. I tried fixing this by filtering the packet data to match addresses, but it didn't work. Maybe I misunderstand the bug.

One other solution is to stay in fast updates mode and simply have a timeout clause in filling the data -- an extra insurance you'll get your payload.

Edit: Well, that wasn't the reason after all. It has problems with single commands. It's related to resending commands. I've asked for some help with it over at Stackoverflow. http://stackoverflow.com/questions/845064/help-with-some-debugging-python-and-lcd-module

Edit 2: I fixed it. It works fine sending commands two at a time.
 
Last edited:
S

starlon

New member
First test running multiple displays concurrently, in this case 2, and I'm really pleased with the benchmark numbers.

Code: 
-----Memory done----- Time taken 0.70 Command rate 1mS
-----Memory done----- Time taken 0.99 Command rate 1mS
One thing that I improved is that I figured out threading in GTK, and now every activity such as reading, checking for packets, etc... has its own thread, instead of spawning a new thread at every interval, which is what I was doing, otherwise the GUI would lock up.

I've come along with the project. I used LCD4Linux as a design template, and rewrote some of the code in Python, like the evaluator and some plugins, for use in my project. Here's a sample config. It's a Config Object config file. I didn't feel like writing a config system. The thing about Config Object is that it supports nested layers, which is useful in configuring which row and column the widget is placed. It's the same concept LCD4Linux uses in its own configuration setup. Without the nesting, it's just a basic ini file.

Code: 
[plugins]
i2c_sensors-path = "/sys/bus/i2c/devices/1-0028/"

[display_cfa6351]
driver = "Crystalfontz"
rows = 4
cols = 20
model = '635'
port = '/dev/ttyUSB0'
speed = 115200
contrast = 120
backlight = 100
default_timeout = 5000
layout = "layout_1"

[display_cfa6352]
driver = "Crystalfontz"
model = '635'
port = '/dev/ttyUSB1'
speed = 115200
contrast = 120
backlight = 100
default_timeout = 5000
layout = "layout_2"

[widget_memory]
type="text"
length=11
expression = "meminfo('MemTotal')/1024 . ' MB Total'"

[widget_busy]
type="text"
expression = "proc_stat::cpu('busy', 500)"

[layout_1]
[[row1]]
col1 = "widget_memory"
[[row2]]
col1 = "widget_busy"

[layout_2]
[[row1]]
col1 = "widget_busy"
[[row2]]
col1 = "widget_memory"
 
Last edited:
CF Tech

CF Tech

Administrator
Awesome that your times are down / speed is up where you want them to be. You will have to post some pictures or a video so we can get a better idea of how it all goes together.
 
S

starlon

New member
Right now it only displays text. No histograms, bars, big numbers, etc... Those are in the plans though. :) I'm just excited to finally be writing something to the display.
 
S

starlon

New member
Here you go. The display's being abused a bit, so I'll file this under benchmarks. There are 3 "layouts" or screens in CC2 terms. Each has its own transition. Notice Ambient on one of the layouts. That's coming from another CFA635's SCAB information. I said it was being abused a bit, and I'm referring to one layout of nothing but icons. It takes a moment to render. :) Believe it or not there's only 8 timers controlling the special character changes. So far it's supporting bars, histograms, text marquees, icons, basic layout transitions, and a lot of Linux information mainly from the /proc file system. You can write your own Python scripts without having to mess with the main code. It's coming along. :)

http://www.youtube.com/watch?v=L6ACx9TuwBM
 
S

starlon

New member
How about some big numbers? I'm not much of an artist so the fonts are kinda ugly.

http://www.youtube.com/watch?v=vReiWbRaJQ4

Edit: Here's an example of the ugliness. How about that 3?

Code: 
WidgetBigNumbers ['            ..   .....  ']
WidgetBigNumbers ['          ...   ....... ']
WidgetBigNumbers ['         ..     ..   .. ']
WidgetBigNumbers ['        ..           .. ']
WidgetBigNumbers ['        ..           .. ']
WidgetBigNumbers ['        ..          ... ']
WidgetBigNumbers ['        .....      ...  ']
WidgetBigNumbers ['        ......    ...   ']
WidgetBigNumbers ['        ..   ..    ...  ']
WidgetBigNumbers ['        ..   ..     ... ']
WidgetBigNumbers ['        ..   ..      .. ']
WidgetBigNumbers ['        ..   ..      .. ']
WidgetBigNumbers ['        ....... ..   .. ']
WidgetBigNumbers ['         .....  ....... ']
WidgetBigNumbers ['          ...    .....  ']
WidgetBigNumbers ['                        ']
 
Last edited:
You must log in or register to reply here.
Top