Hi,
There is a ref in this lib_display_controller users guide, which one refers to an Application Note
• AN00169 - Using the display controller library
Ok. Where is it? :) I had an old project for previous versions of libraries, which can not be compiled w the latest libs... Therefore I would like to take a look to some examples for usage of the new interface. As far as I understand, I have to fill the display controllers buffer with a movable pointer. But how ? :) Actually I spent a whole day for read documentations. What I found relating to movable ptrs, but:
display_controller_write(app2cmd, move(buffers[p]), 0, line, LCD_ROW_WORDS, woffs);
after this point, move() overwrite my movable pointer to zero, because of the ownership takes by display controller... But afterwards, It would be nice to get back somehow? If I check the lib_sdram interface, there is a blocking function to get the last pointer back. But in lib_display_controller I did not find similar methode any way... How can we use this lib officially?
thx
LCD, lib_display_controller examples?
I added a project for this here:
lcd3 example project
and the source is on the github too:
lcd3 github repo
I would appreciate any observations, comments or ideas.
Thanks!
lcd3 example project
and the source is on the github too:
lcd3 github repo
I would appreciate any observations, comments or ideas.
Thanks!
Hi mon2,
thanks for the quick answer. I guess, we get this memory exception on server side of the interface call. Display_controller emits some of the interface push / pop function. Then, response_buffer still able to handle the request, but fails on tx.ready() call. (or command_buffer on a.ready() does it the same way).
So, the notification could not work some reason...
Probably, my code did not handle all of the notifications right. I tried to write my code based on the library codes. (There are no array or stack overrun possibilities here, as far as I understand.)
Theres another tx.ready() on the line 136, which one works as expected. So, the client side of the tx.ready() was called already (at first time) well.
thanks for the quick answer. I guess, we get this memory exception on server side of the interface call. Display_controller emits some of the interface push / pop function. Then, response_buffer still able to handle the request, but fails on tx.ready() call. (or command_buffer on a.ready() does it the same way).
So, the notification could not work some reason...
Probably, my code did not handle all of the notifications right. I tried to write my code based on the library codes. (There are no array or stack overrun possibilities here, as far as I understand.)
Code: Select all
148: tx.ready();
00011176: ldw (ru6) r0, sp[0xd]
00011178: ldw (2rus) r0, r0[0x5]
0001117a: ldaw (l2rus) r2, r0[0x4]
0001117e: ldw (2rus) r3, r0[0x4] <-- ET_LOAD_STORE signal received
...Code: Select all
xrun: Program received signal ET_LOAD_STORE, Memory access exception.
_i.res_buf_to_app_i._Sresponse_buffer_0.1.pop (p=0x1fc30 "\001", last_notification_input=1) at C:/src/plans/lcd3/lib_display_controller/src/display_controller.xc:148
148 tx.ready();Solution: I had used xtime composer v14.0.1 , and it gives me ET_LOAD_STORE signals.
After I was installed the latest v14.0.3, its gone. No problem with the notification... :)
So, thanks. I can go forward right now.
Sorry.
After I was installed the latest v14.0.3, its gone. No problem with the notification... :)
So, thanks. I can go forward right now.
Sorry.
Hi Folks,
actually my gui started to working... In order to design (multiple) layouts, I use ultimate++ editor and its .lay file. So it can be edited there wyswyg, and can used by desktop app too... Have a lot of todo. But some widgets/controlls are realized, and can be just added to layouts now. There can be multiple pages (state machines behind the layouts). There is a message dispatcher between keyboard, touchscreen, midi, eth services and the view/controller...
I have several ideas to refactoring on the original lib_sdram and lib_display modules, to be able to move a rectangle on the framebuffer, like a bitblt fn in vesa cards... And from other side, I would like to use SDRAM to hibernate runtime objectes (or a separate member area). I am actually close to full with the 64k ram but lot of thins just declared as member, so allocated by default.
actually my gui started to working... In order to design (multiple) layouts, I use ultimate++ editor and its .lay file. So it can be edited there wyswyg, and can used by desktop app too... Have a lot of todo. But some widgets/controlls are realized, and can be just added to layouts now. There can be multiple pages (state machines behind the layouts). There is a message dispatcher between keyboard, touchscreen, midi, eth services and the view/controller...
I have several ideas to refactoring on the original lib_sdram and lib_display modules, to be able to move a rectangle on the framebuffer, like a bitblt fn in vesa cards... And from other side, I would like to use SDRAM to hibernate runtime objectes (or a separate member area). I am actually close to full with the 64k ram but lot of thins just declared as member, so allocated by default.
In the past month, I have some progression. But I was freezed on some sdram issue... SDRAM slice is connected to star connector. Each cold reset was good, but after a random delay the screen disappeard, and only green stripes could be seen there (even if the rest of the system was fine).
I was able to catch this issue some times, and I measured only 200mV on the CAS.
Iam using lib_slicekit_support modul, which sets the D042 and D043 correctly on each reboot. So I tested the SPI switch and rs flip-flop logic only at reset. It was ok. Therefore I tought there is some strange issue somewhere else in sdram/pinblock/etc... But not. :)
Right now I just test it again, and I could measure the CAS signal on the SPI CS pin... How?
So the 74lv74 gets reseted somehow.
Is it an errata for this behavior ? This is a general Slicekit XP-SKC-L2 1V1 + XA-SK-XTAG2 1V1 + XMOS XTAG2 1V0 ?
There is a high level on U6 pin1. (before this random failure, this is on low level of course).
NReset couldn't be the problem, because the system still running / we dont get a reset, Iam sure.
Is it some known limitation?
I was able to catch this issue some times, and I measured only 200mV on the CAS.
Iam using lib_slicekit_support modul, which sets the D042 and D043 correctly on each reboot. So I tested the SPI switch and rs flip-flop logic only at reset. It was ok. Therefore I tought there is some strange issue somewhere else in sdram/pinblock/etc... But not. :)
Right now I just test it again, and I could measure the CAS signal on the SPI CS pin... How?
So the 74lv74 gets reseted somehow.
Is it an errata for this behavior ? This is a general Slicekit XP-SKC-L2 1V1 + XA-SK-XTAG2 1V1 + XMOS XTAG2 1V0 ?
There is a high level on U6 pin1. (before this random failure, this is on low level of course).
NReset couldn't be the problem, because the system still running / we dont get a reset, Iam sure.
Is it some known limitation?
Hello myndideal. I think that we have seen this issue on our SliceKit XP-SKC-L2 1V1. However, of course confirm the issue is the same. We wasted 3 days in tracking down the issue.
Review the PCB connection to EACH pin on the U18 flip flop. We found that there is a PCB via (from bottom to top) that was over etched and not making a connection to this flip flop. This caused the flip flop to not operate as expected. On Monday we can share the specific pin details from our lab unit.
Please do a continuity test for each pin on this component from source to this device and you may find the same fault.
Summary - our PCB had a blown trace due to poor PCB quality for this same flip flop (U18). This may be the root cause of your problem.
See my post here on this topic:
http://www.xcore.com/forum/viewtopic.ph ... hilit=mon2
Hope this helps.
Kumar
Review the PCB connection to EACH pin on the U18 flip flop. We found that there is a PCB via (from bottom to top) that was over etched and not making a connection to this flip flop. This caused the flip flop to not operate as expected. On Monday we can share the specific pin details from our lab unit.
Please do a continuity test for each pin on this component from source to this device and you may find the same fault.
Summary - our PCB had a blown trace due to poor PCB quality for this same flip flop (U18). This may be the root cause of your problem.
See my post here on this topic:
http://www.xcore.com/forum/viewtopic.ph ... hilit=mon2
Hope this helps.
Kumar
Hi mon2,
Oh! Thanks a lot! I can confirm, there is a missing via. :) Gosh. The rst_n signal is not going to pin13, only to pin 1 of the U18... Hm. So, this clear input is hovering in the breeze, yeah deffinitely this is the reason...
(Ok, I have to try this with the 1V2 panel too, it have to be working fine with the new one, I hope. )
Oh! Thanks a lot! I can confirm, there is a missing via. :) Gosh. The rst_n signal is not going to pin13, only to pin 1 of the U18... Hm. So, this clear input is hovering in the breeze, yeah deffinitely this is the reason...
(Ok, I have to try this with the 1V2 panel too, it have to be working fine with the new one, I hope. )
Excellent :) Hope it saved you a bit of time. For our company, we only use PCB vendors that 100% E-test the PCBs to avoid pitfalls like this. Based on the common fault in the kits, sounds like this PCB vendor has process issues.