7i73 LCD shows rubisch
03 Mar 2018 21:22 #106888
by andypugh
Can you paste the exact format string?
Replied by andypugh on topic 7i73 LCD shows rubisch
One more strange observation
I have switch that can choose between four pages ( separated by the pip sign)
A|B|C|D
On 1. screen I see A but also jumping B .
Can you paste the exact format string?
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
04 Mar 2018 10:50 - 04 Mar 2018 10:51 #106896
by Mike_Eitel
Replied by Mike_Eitel on topic 7i73 LCD shows rubisch
Here is the actual running part.
(Just for completeness I attach the work in progress file also )
..........................
loadrt lcd fmt_strings="a\n|b\n|c\n|d\n"
addf lcd servo-thread
addf lcdselector servo-thread
addf lcdconv servo-thread
setp lcdselector.in0 0
setp lcdselector.in1 1
setp lcdselector.in2 2
setp lcdselector.in3 3
net lcdhw1 lcdselector.sel0 <= hm2_7i76e.0.7i73.0.1.input-16-not
net lcdhw2 lcdselector.sel1 <= hm2_7i76e.0.7i73.0.1.input-17-not
net convsel lcdconv.in <= lcdselector.out
net usepage lcd.00.page_num <= lcdconv.out
net display lcd.00.out => hm2_7i76e.0.7i73.0.1.display
THX Mike
(Just for completeness I attach the work in progress file also )
..........................
loadrt lcd fmt_strings="a\n|b\n|c\n|d\n"
addf lcd servo-thread
addf lcdselector servo-thread
addf lcdconv servo-thread
setp lcdselector.in0 0
setp lcdselector.in1 1
setp lcdselector.in2 2
setp lcdselector.in3 3
net lcdhw1 lcdselector.sel0 <= hm2_7i76e.0.7i73.0.1.input-16-not
net lcdhw2 lcdselector.sel1 <= hm2_7i76e.0.7i73.0.1.input-17-not
net convsel lcdconv.in <= lcdselector.out
net usepage lcd.00.page_num <= lcdconv.out
net display lcd.00.out => hm2_7i76e.0.7i73.0.1.display
THX Mike
Last edit: 04 Mar 2018 10:51 by Mike_Eitel. Reason: attachment missing
Please Log in or Create an account to join the conversation.
04 Mar 2018 11:25 #106898
by andypugh
Replied by andypugh on topic 7i73 LCD shows rubisch
I made a big improvement to the display stability last night with changes to the lcd component.
One problem I have found is that it was always showing one character from the next page at the end of each page. And there just happened to be an "f" (or a decimal 102) off the end of the format array.
I also found that the "cursor home" command was not always completing, and replacing it with an absolute positioning command helps a lot.
I am struggling to combine those changes with the ability to use the very last character on the display.
(the display tends to accumulate stray characters if you don't erase-to-end-of line at the end of each line, but if the last character of the format is the last character on the display then the erase-to-end happens on the first line of the display. Unfortunately the LCD component has no way to tell if the display is 4x20, 2x20, 4x16 or whatever.
The answer may be to document that each line needs to have a "\n" if it is shorter than a full page width, and not have that if it isn't.
The modified version of the lcd component currently does not properly clear the display at boot, it needs a page-change to do that. Fixing that is todays job.
I have also (I think) fixed a race condition in the sserial driver. I don't know if that has ever been a problem, but it was certainly bug with potentially bad effects.
One problem I have found is that it was always showing one character from the next page at the end of each page. And there just happened to be an "f" (or a decimal 102) off the end of the format array.
I also found that the "cursor home" command was not always completing, and replacing it with an absolute positioning command helps a lot.
I am struggling to combine those changes with the ability to use the very last character on the display.
(the display tends to accumulate stray characters if you don't erase-to-end-of line at the end of each line, but if the last character of the format is the last character on the display then the erase-to-end happens on the first line of the display. Unfortunately the LCD component has no way to tell if the display is 4x20, 2x20, 4x16 or whatever.
The answer may be to document that each line needs to have a "\n" if it is shorter than a full page width, and not have that if it isn't.
The modified version of the lcd component currently does not properly clear the display at boot, it needs a page-change to do that. Fixing that is todays job.
I have also (I think) fixed a race condition in the sserial driver. I don't know if that has ever been a problem, but it was certainly bug with potentially bad effects.
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
04 Mar 2018 12:10 #106900
by Mike_Eitel
Replied by Mike_Eitel on topic 7i73 LCD shows rubisch
In my avr programming ( compiler msc bascom) i never saw the problem of the last character. And yes, i know that wrapping around thing. If there comes one additional character it wraps everything. Sow if i had a to long array, you get a 'wandering' text. With is not the case here.
In my eyes a demand end of line by /n is absolutely ok.
What I'm absolutely sure is that it worked before absolutely in the way i expected. Norberts screen was shown perfect.
In my eyes a demand end of line by /n is absolutely ok.
What I'm absolutely sure is that it worked before absolutely in the way i expected. Norberts screen was shown perfect.
Please Log in or Create an account to join the conversation.
04 Mar 2018 13:54 #106904
by PCW
Replied by PCW on topic 7i73 LCD shows rubisch
One suspicion I have is that absolute addressing works better only because it takes more time
(more characters = more ms). erase to EOL uses absolute addressing in the low level 7I73 code
so does the same thing but takes 1 ms to send not 4 ms
I think that by printing a single letter and then doing 2 cursor movements (which are slow)
you are possibly overflowing the character buffer
So do longer strings (longer that 1 Char) work better?
Also you can get the display size (nvdisplayformat?)
(more characters = more ms). erase to EOL uses absolute addressing in the low level 7I73 code
so does the same thing but takes 1 ms to send not 4 ms
I think that by printing a single letter and then doing 2 cursor movements (which are slow)
you are possibly overflowing the character buffer
So do longer strings (longer that 1 Char) work better?
Also you can get the display size (nvdisplayformat?)
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
04 Mar 2018 14:12 #106905
by Mike_Eitel
Replied by Mike_Eitel on topic 7i73 LCD shows rubisch
Longer do not really work better. See in above attached file the original from Norbert. Could make a video but you only see more text hopping.
Yes, i believe more and more that it is an timing issue.
But has timing become faster since the update where it starts scrambling?
And isn't the real addressing of the lcd done in the 7i73 firmware? Do you have to send all lcd command via the 7i76 and sserial yourself?
Yes, i believe more and more that it is an timing issue.
But has timing become faster since the update where it starts scrambling?
And isn't the real addressing of the lcd done in the 7i73 firmware? Do you have to send all lcd command via the 7i76 and sserial yourself?
Please Log in or Create an account to join the conversation.
04 Mar 2018 14:27 #106906
by PCW
Replied by PCW on topic 7i73 LCD shows rubisch
OK so if longer strings dont fix things its probably not a buffer overflow
All addressing is done in the 7I73, the 7I73 LCD behaves like a terminal
(except it does not scroll if you write to the last character of the last line, it wraps)
I wonder if erase to EOL is not an issue because it will move the cursor to the end of the line
I also wonder why this is the first time we have seen this issue, but Andy sees the same problem with 2.7
All addressing is done in the 7I73, the 7I73 LCD behaves like a terminal
(except it does not scroll if you write to the last character of the last line, it wraps)
I wonder if erase to EOL is not an issue because it will move the cursor to the end of the line
I also wonder why this is the first time we have seen this issue, but Andy sees the same problem with 2.7
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
04 Mar 2018 14:40 #106907
by Mike_Eitel
Replied by Mike_Eitel on topic 7i73 LCD shows rubisch
Just by stepping back ( A thing that helps me a lot in professional work) i wonder:
1.
If I understood correct this does not happen with 5i25 but with 7i76e.
Conclusion: it is probably not in the 7i73.
2.
Difference between both cards is the driver. And as fare as I understood the Ethernet protocol shows something...
I would deduct it is the other behavior.. My question: Is Ethernet addressing the cards faster then pci ?
3.
Or is ethernet even slower. I know of situations where you do not having a good semaphore handling and writing into a buffer that is not yet completely transfered. Could something like this be the reason?
1.
If I understood correct this does not happen with 5i25 but with 7i76e.
Conclusion: it is probably not in the 7i73.
2.
Difference between both cards is the driver. And as fare as I understood the Ethernet protocol shows something...
I would deduct it is the other behavior.. My question: Is Ethernet addressing the cards faster then pci ?
3.
Or is ethernet even slower. I know of situations where you do not having a good semaphore handling and writing into a buffer that is not yet completely transfered. Could something like this be the reason?
Please Log in or Create an account to join the conversation.
04 Mar 2018 15:00 #106908
by PCW
Replied by PCW on topic 7i73 LCD shows rubisch
At the low level register write level, Ethernet access to the FPGA registers is faster,
so this might make a difference with the recently discovered race bug in the LinuxCNC sserial
driver code.
This bug exists for all card types but since its a race condition that depends on write times
(times between one 32 bit hm2 write and the next)
it will likely manifest it self differently (or not show up at all) on different hardware.
AFAIK Andy has fixed the race bug but I dont think that by itself fixed the display issue for him
its also strange that Andy has the display issues with both 2.8 and 2.7 and you do not
When I see problems like this its often multiple overlapping issues.
so this might make a difference with the recently discovered race bug in the LinuxCNC sserial
driver code.
This bug exists for all card types but since its a race condition that depends on write times
(times between one 32 bit hm2 write and the next)
it will likely manifest it self differently (or not show up at all) on different hardware.
AFAIK Andy has fixed the race bug but I dont think that by itself fixed the display issue for him
its also strange that Andy has the display issues with both 2.8 and 2.7 and you do not
When I see problems like this its often multiple overlapping issues.
Please Log in or Create an account to join the conversation.
- Mike_Eitel
-
Topic Author
- Offline
- Platinum Member
-
Less
More
- Posts: 1150
- Thank you received: 184
04 Mar 2018 15:06 #106909
by Mike_Eitel
Replied by Mike_Eitel on topic 7i73 LCD shows rubisch
Maybe a misunderstanding.
I never used 2.7 I went, ca November, directly with 2.8 = master.
Got from Norbert a code for gmoccapy and my 7i76e/7i73 combo.
And saw a good display.
Started to do my development from there on, saw the bug only mid January.
( Made over Christmas mechanical modifications on my mil )
I never used 2.7 I went, ca November, directly with 2.8 = master.
Got from Norbert a code for gmoccapy and my 7i76e/7i73 combo.
And saw a good display.
Started to do my development from there on, saw the bug only mid January.
( Made over Christmas mechanical modifications on my mil )
Please Log in or Create an account to join the conversation.
Time to create page: 0.098 seconds