PIC32MZ2064DAH176定位问题

嗨，这是最近在这里发现的，我们正在调查它。我会尽快把结果和可能的修复更新给你，谢谢！



      以下为原文

    Hi,
 
This was discovered here recently and we are currently investigating it.  I will update you on the result and a possible fix, as soon as possible.
 
Thanks!

我要指出的是，我已经尝试了2.03B的安装和在另一个岗位上提交的HFXUTIL.C和GFXY层C。都不管用。无论如何，谢谢你的回复！在此期间，我将着手处理这个问题。



      以下为原文

    I would point out that I have tried both the gfx_util.c and gfx_layer.c from the install of 2.03b and the ones submitted by MHGC in another post. Neither works.
 
In any case, thank you for the reply! I'll work on the touch part of this in the meantime.

你可能想看看我的触摸屏上的90度。我想我在H2.03B ARIL LIB中找到并出错了。http://www. McCux.com……；m＝1003778和m；



      以下为原文

    You may want to look at my post on touch for 90deg.
I think I found and error in the H2.03B Aria Lib.
http://www.microchip.com/...;m=1003778&mpage=1

谢谢，谢谢！事实上，我很感兴趣地阅读你的文章，它们会帮助我。不幸的是，我不能让屏幕正确定位，所以我无法测试90°模式下的触摸。实际上，我已经在项目中删除了所有其他子系统（DAC，Flash等）。这应该给微芯片一些时间，而我可以生产。非阻塞工作：-）。



      以下为原文

    jtzeng,
 
    Thanks! I have actually read your posts with interest and they will help me as I go along. Unfortunately, I can't get the screen to orient properly so I can't test the touch in 90° mode. I've actually been knocking out all of the other subsystems in my project (DAC, Flash, etc) in the meantime. This should give Microchip some time while I can be productive. Non-blocking work :-).

在V2.03B中，有两个补丁。请验证您的问题的这些更新。LabRiaAuUTIL.C：/ /输入定向静态GFXPoT OrthEnt90（confgfxPox*pNT，const gfxl RECT*RET）{GFX}点RES；RES.Y＝RECT-＆GT；宽度-1 pTN-gt；x；R.x＝pNT & gt；y；//RES.x＝pNT-＆g；x返回RES；} GFXUTIL.C//像素输出T帧缓冲器补丁gfxz点定向1（const gfxPox*pnt，const gfxl RECT*RET）{gfxl点RES；RES.Y＝pNT & gt；x；RES.x＝RECT-＆GT；宽度-pTN-gt；y；返回RES；}



      以下为原文

     
In v2.03b, there are two patches. Please verify these updates for your issue.
 
libaria_utils.c:   //  input orientation patch
static GFX_Point orient_90(const GFX_Point* pnt, const GFX_Rect* rect)
{
    GFX_Point res;

    res.y = rect->width - 1 - pnt->x;
    res.x = pnt->y;      // not res.x = pnt->x
    
    return res;
}
 
gfx_util.c  // pixel output to framebuffer patch
static GFX_Point orient_90(const GFX_Point* pnt, const GFX_Rect* rect)
{
    GFX_Point res;

    res.y = pnt->x;
    res.x = rect->width - 1 - pnt->y;
    
    return res;
}
 
 

“自动化”，恐怕这不起作用。这是我如何验证的。我在0°模式下覆盖了整个层，只有一层，这给了我通常所见即所得的视觉。我把屏幕模式切换到90°。从这里我必须取消设置，然后设置Layel0的“锁定屏幕大小”选项，以使它正确地进入屏幕。然后我简单地调整梯度。结果是一个空白，但没有重置，我可以告诉，屏幕。



      以下为原文

    @automate,
 
    I'm afraid this didn't work. Here is how I verified it. I put a gradient covering the entire, and only, layer in 0° mode and this gave me the usual WYSIWYG visual. I switched the screen mode to 90°. From here I have to unset and then set the "Locked to Screen Size" option for Layer0 to get it to snap to the screen correctly. I then simply resized the gradient. The result was a blank, but not resetting as far as I could tell, screen.

好的，所以我有一些更新，他们不容易追踪。我使用的是GFXUTIL.C和GFXXLeal.C文件，MHC链接到我的文章中，标题是“显示方向”。另外，我已经对上面列出的LIABARAYUTIL.C进行了更改。就是这样。在这个过程中，我在我的显示器上安装了两个按钮。在0°模式下，一切都很好。走到90°，我们发现自己处于系统异常的雷雨中。很多时候，我可以查看调用栈，知道发生了什么，但在这种情况下不是这样。因此，我开始了整个过程，发现在没有抛出异常的情况下，无法完成gfxj-RutcRT。深入钻探时，CPUDRAWStReult在第二百七十二次迭代时调用CPUDRAWLYNE HORZ是罪魁祸首（没有，在断点时我没有按下F5 272次）。考虑到我的分辨率是480x222，这是一个有趣的数字。进一步在这一点上，我得到了OrgEnt90在GFXUTU.L.给出了一个具有以下元素的RECt指针：x= 0y= 02Geule= 280Lead＝480，pNT为：x= 0y= 227，最后以RES为点（-1,0）。当然，当负数偏移到像素缓冲区时，这会导致DfPixLeSt的出现。Orruty9090列在上面。我假设当我们看到一个0°模式的屏幕时，如果我们想要它到90°，它是顺时针旋转的。由于OrtheTy90函数之前的（x，y）值与90°旋转有关，它们需要映射到0°。上面的等式就是这样。不幸的是，Rect & Gt的宽度已经被旋转并且对应于90°旋转。因此，上面的等式如果使用Rect & Gt；HOLT & GT；这会阻止异常发生，但是看看它们看起来不正确的按钮。偶尔有轻微的“抽搐”，边框处于错误的位置。这让我怀疑我对90°的假设是错误的，实际上它是逆时针的。不管怎样，例外都停止了。有什么想法吗？



      以下为原文

    Ok, so I have some updates and they weren't easy to track down. I'm using the gfx_util.c and gfx_layer.c files that MHGC linked to in my post titled "Display Orientation" on these fora. Additionally, I have the change to libaria_utils.c listed above. That is it.
 
During this process, I put up two buttons on my display. In 0° mode everything works just fine. Go to 90° and we find ourselves in the thunderdome of system exceptions. Many times I can look at the call stack and get an idea of what happened, but not in this case. So I started stepping through the whole thing and found that GFX_DrawRect couldn't complete without throwing an exception. Drilling down deeper, cpuDrawRectFill turned out to be the culprit when it would call cpuDrawLine_Horz on its 272nd iteration (no I didn't press F5 272 times at that breakpoint). That's an interesting number to blow things up given that my resolution is 480x272. Stepping further at this point got me to orient_90 in gfx_util.
 
Given a rect pointer with the following elements:
 
x = 0
y = 0
width = 272
height = 480
 
and a pnt with:
 
x = 0
y = 272
 
we end up with res becoming the point (-1,0). This of course blows up defPixelSet when the offset to the pixel buffer walks the plank due to the negative number.
 
So how to fix this. orient_90 is listed above. I'm assuming that when we're looking at a screen in 0° mode that if we want it to go to 90° it is rotated clockwise. Since the (x,y) values prior to the orient_90 function are relative to the 90° rotation, they need to be mapped back to 0°. The equation above does just that. Unfortunately rect->width has already been rotated and corresponds to the 90° rotation. Therefore, the equation above holds if rect->height is used.
 
This stops the exceptions from occurring, but looking at the buttons they don't seem to look right. Occasionally there is a slight "twitch" and the bezel is in the wrong position. It makes me wonder if my assumption regarding what was 90° was wrong and that it's actually counterclockwise. Either way the exceptions have stopped. Any thoughts?

我想好消息是180°模式很好。这意味着，我可以跟踪在下面的文件中如何映射所有的东西：gfxpLay.c，gfxpU.L.c和LabiaLaUTIL.c。这应该给我一个关于如何修复90°定位模式的想法。



      以下为原文

    I guess the good news is that 180° mode works just fine. This implies that I can trace out how everything is mapped in the following files: gfx_layer.c, gfx_util.c, and libaria_utils.c. This should give me an idea as to how to proceed with fixing the 90° orientation mode.

@自动化，MHGC，或其他微芯片大师，任何运气与90°取向模式与PIC32 MZ DA芯片？我仍在试图解决这个问题，但是如果你已经有了一些东西，我会很乐意拥有它的。



      以下为原文

    @automate, MHGC, or other Microchip gurus,
 
    Any luck with the 90° orientation mode with a PIC32MZ DA chip? I'm still trying to solve the problem, but if you have something already I would be more than happy to have it :-).

我注意到的一件事是在gfxpLead .c中，特别是gfxxLaytoTooRealDead空间函数。对于180°，这将为所有层初始，上下文-gt；层。用户的0°立场实际上是180°旋转的起源。此外，方向颠倒，在LiRiaAiUTLS和GFXUTIL文件中找到的Orrunt180函数中得到正确的反映。这可能解释了为什么180°模式工作。好吧，那么，90°，如果我们把旋转按顺时针方向处理，意味着新的起源是AT（479, 0）。我真的把最后一个位子拧错了。然后，我期望上面的值是：对于RcT.Studio:x= 49y= 02.52Health= 480Rec.Posi:x= 0y= 0Gule= 22Health= 480i，猜测大小（宽度和高度）是相同的，因为描述GFSH层中的显示和局部的语句。在这些REST之间冗余，但是它使得调用gfxl ReCt的函数作为参数GFxReCt显示；/ /表示显示空间gfxl Rct局部的区域；//表示局部空间中的位置}；由于我在180°模式中发现的，显示WOW是有意义的。LD表示实际的像素位置，而局部则是更为逻辑的东西，即您已经在该空间内旋转了。不幸的是，这是调试器中弹出的东西：Rect。显示：x= 0y= 080Leave=对我来说没什么意义。为什么显示器完全不变？为什么要改变本地，但是基于旋转的改变？无论如何，有些东西在分层中是错误的，因为我删除了除了Leal0以外的所有东西。为了显示一些东西，我使用不同的方案使背景蓝。不用说，出来的是垃圾。我会得到像屏幕蓝色一半（更像条纹），另一半是白色，就像没有画它。



      以下为原文

    One thing that I've noticed is in gfx_layer.c, specifically the GFX_LayerToOrientedSpace function. For 180° this will leave, for all layers initially, context->layer.layers.rect.display and context->layer.layers.rect.local to two different settings:
 
for rect.display:
 
x = 479
y = 271
width = 480
height = 272
 
for rect.local:
 
x = 0
y = 0
width = 480
height = 272
 
This makes sense because (479,271) from a user's 0° standpoint is actually the origin for 180° rotation. Additionally the directions are reversed, which is reflected correctly in the orient_180 functions found in the libaria_utils and gfx_util files. This probably explains why 180° mode works.
 
Ok then, so 90°, if we're treating the rotation as clockwise, implies that the new origin is at (479, 0). I actually screwed that last bit up rotating the wrong way. I would then expect the values from above to be:
 
for rect.display:
 
x = 479
y = 0
width = 272
height = 480
 
for rect.local:
 
x = 0
y = 0
width = 272
height = 480
 
I'm guessing that the sizes (width and height) are the same because of the statement describing display and local in gfx_layer.h:
 
struct
    {
        // sizes are redundant between these rects but it makes for cleaner code
        // when calling functions that take GFX_Rect as arguments
        GFX_Rect display; // represents area in display space
        GFX_Rect local;   // represents position in local space
    } rect;
 
Due to what I found in 180° mode, it makes sense that display would represent the actual pixel locations, while local is more of a logical thing, i.e. you're already rotated so within that space.
 
Unfortunately, this is now what pops out in the debugger:
 
for rect.display:
 
x =0
y = 0
width = 480
height = 272
 
for rect.local:
 
x = 0
y = 0
width = 272
height = 480
 
This doesn't make any sense to me. Why is rect.display completely unchanged? Why change local, but _GFX_LayerSizeSet display is changed based on the rotation?
 
At any rate, something is just plain wrong with the layering as I've removed everything except Layer0. In order to show something I'm using a different scheme to make the background blue. Needless to say, what comes out is garbage. I'll get what appears like half of the screen blue (more like striped) and the other half is white like nothing painted it.

另一个奇怪的ODIDIT.GFXpPixelBuffReStGETGETUnFunt在90°模式下出错。在0°模式下，我可以看到它的返回值从0开始，以4的增量递增，这与RGBA88 8一致。这是有意义的，因为我们是从左到右，从上到下。在90°模式下执行此操作，目标指针应该增加1920（480×4）；这是因为旋转产生如下：（0，0）实际上是（47，0），（1，0）实际上是（47 9，1）等。它绝对不增加1920，并且似乎正在改变它的参数，这两者都是测试设置是简单地看到90°模式下的Leal0绘画。我使用了MgGC在一个不同的职位上提供的GFX.UTL.C和GFXY层C文件：这是GFXOUTI.C Orruty90:静态GFXPoT Orthon S90（confgfxPox*PNT，const gfxl RECT*RET）{GFXPosi-Res；RES.Y＝pNT & gt；x；RES.x＝RECT-＆GT；高度- 1 pTN-gt；y；返回RES；}



      以下为原文

    One other strange oddity. GFX_PixelBufferOffsetGet_Unsafe goes haywire in 90° mode. In 0° mode I can watch its return value start from 0 and go up in increments of 4, which is consistent with RGBA888. This makes sense as we're going left to right, top to bottom. Do this in 90° mode and the destination pointer should increment by 1920 (480 x 4); this is because the rotation yields the following: (0,0) is actually (479,0), (1,0) is actually (479,1), etc. It most definitely does not increment by 1920 and it appears to be changing its arguments, both of which are passed in as const pointers to const data.
 
The test setup was to simply see Layer0 paint in 90° mode. I used the gfx_util.c and gfx_layer.c files that MHGC provided in a different post with ONE change: this is the gfx_util.c orient_90:
 
static GFX_Point orient_90(const GFX_Point* pnt, const GFX_Rect* rect)
{
    GFX_Point res;

    res.y = pnt->x;
    res.x = rect->height - 1 - pnt->y;
    
    return res;
}

嗨，我对定位问题做了一些研究。我首先验证了我们的LCC驱动的所有方向设置，它们都看起来是功能性的，包括触摸。这意味着它无疑是一个GLCD驱动程序的问题。一个问题是，当驱动程序总是引用物理层矩形坐标时，它试图使用逻辑层矩形坐标。一个例子是：~第230行：这需要改变为：如果你改变本地的每一个实例来显示在驱动程序中，那么方向坐标就会正确地显示出来。例如，当使用90度时，坐标0，0应该转换为47，0。这应该在第0层缓冲器0的情况下计算，以解决0xA800 077 C。0x77 C是479×4bpp。不幸的是，这并不能完全解决这个问题。我可以跟踪使用调试器一直到像素写入帧缓冲区。颜色是正确的，坐标是正确的，但显示器仍然出来乱码。这是我能得到的，不能花更多的时间在上面。



      以下为原文

    Hi,
 
I did some research into the orientation issue.  I first verified all orientation settings on our LCC driver and they all appear to be functional, touch included.  This means it's definitely a GLCD driver issue.
 
One problem is that the driver is attempting to use the logical layer rectangle coordinates when it should always be referencing the physical ones.  One example is:
 
~line 230:
GFX_PixelBufferCreate(layer->rect.local.width,
                  layer->rect.local.height,
                  context->colorMode,
                  drvLayer[layer->id].baseaddr,
                  &layer->buffers.pb);
 
This needs to be changed to:
GFX_PixelBufferCreate(layer->rect.display.width,
                  layer->rect.display.height,
                  context->colorMode,
                  drvLayer[layer->id].baseaddr,
                  &layer->buffers.pb);
 
If you change every instance of local to display in the driver then the orientation coordinates come out correctly.  For instance, when using 90 degrees, the coordinate 0,0 should translate to 479,0.  This should calculate, in the case of layer 0, buffer 0, to address 0xA800077C.  0x77C is 479 * 4bpp. 
 
Unfortunately this didn't fully solve the problem.  I could track using the debugger all the way to the pixel write to the frame buffer.  The color was correct, the coordinate was correct, but the display still came out garbled.  That's as far as I was able to get and was unable to spend more time on it.
 
 
 

嗨，B祝福，我们现在正处于最后的危机中，准备V2.04准备好了，我们不能花太多的时间来解决这个问题。我们在内部跟踪这个问题，并计划重访这个，希望在下周晚些时候，一旦V2.04发布的大部分工作结束了。这意味着修复，当我们拥有它时，将不是V2.04的一部分。我们可能需要通过论坛和其他的修复程序来释放你。谢谢你持续的耐心。



      以下为原文

    Hi bblessing,
 
We are currently in the final crunch to get v2.04 ready and have not be able to spend as much time as we would like to resolve this matter.
 
We have this problem tracked internally and plan to revisit this, hopefully sometime late next week, once the bulk of v2.04 release work is out of the way.
 
This means the fix, when we have it, will not be part of v2.04.  We may have to release this to you via the forum as with the other fixes.
 
Thank you for your continuing patience.

谢谢你这个帖子，因为它节省了我很多时间。我正要看这个，因为我的安装没有看到一个90度的绘图问题。我正在使用LCC，所以这就是为什么。我希望我的触摸只是我的ADC设置，因为它缝在快速启动演示。他释放了2.04？？



      以下为原文

    Thank you for this post as it has saved me a lot of time.
I was just about to look at this as my setup does not see an issue with 90deg on drawing.
I am using LCC, so that is why.
 
I am hoping my touch is is just my ADC setup as it seams to be working on the quickstart demo.
 
Can anyone speculate as to the release of 2.04??
 
 

UIG和MHGC，那太糟糕了。不过，谢谢你们的关注！MZ DA芯片的性能超过补偿这一小挫折。我只会设计0个方向的屏幕，虽然它可能是一个轻微的痛苦看着所有东西侧向：-）。我会继续研究它。通过和谐的图形堆栈是谦卑的。那里有一些非常先进的技术。伟大的学习机会。



      以下为原文

    UIG and MHGC,

Well, that's too bad. However thank you guys for looking into it! The performance of the MZ DA chip more than compensates for this minor setback. I'll just design the screens in 0 orientation mode, though it may be a slight pain looking at everything sideways :-).

I'll continue to look into it on the side. Going through the Harmony graphics stack is humbling. There are some very advanced techniques in there. Great learning opportunity.

现在正在进行最后的测试。我不能给出一个很难发布的日期，因为肯定有一些事情会使它右移（与图形无关）。



      以下为原文

   


It's in final testing now.  I can't give a hard release date since there are definitely things that could cause it to shift right (unrelated to graphics).

嗨，赖安是正确的，但我可以添加更多的颜色。和声V2.04基本上是完整的，并在最终测试。我们仍然打算在8月份发布。这是一个大型版本的更新和一些新设备。一些设备的硬件支持是一个变量，因此可能会影响精确的发布日期。我们现在正在工作。



      以下为原文

    Hi all,
 
Ryan is correct, but I can add some more color.
 
Harmony v2.04 is essentially complete and in final testing.  We still intend to release in August.  It is a large release with updates and a number of new devices.  The hardware support of some of those devices is a variable, so may impact the exact release date.  We are working this now.
 

我试着让它起作用。很好的一点是电阻触摸工作在90°模式，一举一举。这就是我所做的。UIG让我走在正确的路径上，追踪到GLCD驱动程序。我仍然感到恼火的是，我的调试器显示的数字与实际情况不匹配，让我大发雷霆，但这是另一天的讨论。如果你想要的话，你肯定想在DrviGfxGLCDySt.c或DrvugfxGLCDSista.C.FTL中改变“局部”到“显示”的所有实例。任何来自和谐的再生停止骚扰你。从这里，在下面的函数中更改两个PLIB调用：Layer-StsieSePlbIIGlcdLayer-StaseXSET（GldCdIdIO0，IDX，x，y）；toIF（（gfxOrthOrthOntIs909=＝GFxActhixEngEngTeX）（-G.；方向））（gfxOrthOrthix270=＝GFxActhixEngEngTeX（）；另一个PlbIIGlCDGlayListSistySet（GldCdIdIO0，IDX，x，y）；ANPLPLIGGLCDALIERSIZEXYSET（GLCDSIDID0，IDX，宽度，高度）；toIF（（gfxOrthOrthix90=＝GFxActhixEngEngTeX））-g*（gfxO-OrthoTrime270=＝GFxActhixEngTeX（））-Plbsi-GldgLayelsixEXySet（GfxxOrthEngultEngestEngEnter）内皮细胞GLCDSIDID0，IDX，高度，宽度）；否则PLBIGLCDGLIELIESIZEXYSET（GLCDSIDID0，IDX，宽度，高度）；关于这一点的简洁部分，它也工作在0°、180°和270°。这对我来说是非常令人鼓舞的，我希望这最终证明是解决的办法。希望这也适用于其他人。



      以下为原文

    I have tentatively gotten this to work. The nice part is that resistive touch works in 90° mode as well; all in one fell swoop. Here is what I did. UIG got me on the right path tracing it down to the GLCD driver. I am still annoyed that the numbers displayed by my debugger didn't match reality and threw me on a wild goose chase, but that is a discussion for another day.
 
You will definitely want to change all instances of "local" to "display" in drv_gfx_glcd_static.c, or drv_gfx_glcd_static.c.ftl if you want any regeneration from Harmony to stop annoying you. From there, change two PLIB calls in the following functions: layerPositionSet and layerSizeSet
 
PLIB_GLCD_LayerStartXYSet( GLCD_ID_0, idx, x, y );
 
to
 
if ((GFX_ORIENTATION_90 == GFX_ActiveContext()->orientation) || (GFX_ORIENTATION_270 == GFX_ActiveContext()->orientation))
        PLIB_GLCD_LayerStartXYSet( GLCD_ID_0, idx, y, x );
    else
        PLIB_GLCD_LayerStartXYSet( GLCD_ID_0, idx, x, y );
 
and
 
PLIB_GLCD_LayerSizeXYSet( GLCD_ID_0, idx, width, height);
 
to
 
if ((GFX_ORIENTATION_90 == GFX_ActiveContext()->orientation) || (GFX_ORIENTATION_270 == GFX_ActiveContext()->orientation))
        PLIB_GLCD_LayerSizeXYSet( GLCD_ID_0, idx, height, width);
    else
        PLIB_GLCD_LayerSizeXYSet( GLCD_ID_0, idx, width, height);
 
The neat part about this is that it works at 0°, 180° and 270° as well. This is very encouraging to me and I hope that this proves to ultimately be the solution. Hopefully this works for others as well.

我会给你一个机会，看看我能否锁定一个解决方案。谢谢你提供的额外信息。



      以下为原文

    I'll give this a shot and see if I can lock down a solution. 
 
Thanks for the additional information.