怎么从Harmony PMP驱动程序切换到Bit Banging

我很难完全理解你的设置和问题。是不是有一个LCD通过共享PMP接口的PIN连接到PIC上，它一直工作到添加一个引导加载程序，在哪一点它停止工作？在概念中，为了获得GPIO函数来控制接口，您只需确保没有更高的优先级使用PIN，所以对于一个示例引脚，如“EBID14/RPD2/PMD14/RD2”，如果您想控制RD2，则必须确保外部总线接口被禁用。EBID14），没有任何分配通过RPD2R或各种外围输出寄存器使用RPD2，并确保PMP模块（PMD14）被禁用。因此，如果PMP和LCD共享引脚，只需确保PMP总线空闲，那么所有的奴隶都被取消选择，然后通过清除ON位来禁用PMP模块（然后等待几个周期来实际释放PIN）。请检查您的应用程序代码是否正在运行，因为存在一些与协调引导程序配置一起出现的持久性问题。试着用一个闪烁的LED来代替你的应用程序的启动，当它试图做一个屏幕更新的步骤并在它的范围内观察时，我猜它不是在运行。但愿我错了：祝你好运。



      以下为原文

    I'm having difficulty fully understanding your setup and the problem.  Is it the case that you have an LCD connected to the PIC via the pins that share the PMP interface and it is working until you add a bootloader at which point it stops working?
 
In concept to get the GPIO functions to take control of the interface, you just have to make sure that nothing higher priority is using the pin - so for an example pin such as "EBID14/RPD2/PMD14/RD2" if you want RD2 to be in control you have to make sure that the external bus interface is disabled(EBID14), that there is nothing assigned to use RPD2 via either RPD2R or various peripheral output registers, and make sure the PMP module(PMD14) is disabled.  So if the PMP and the LCD are sharing the pins just make sure the PMP bus is idle, that all the slaves are de-selected and then disable the PMP module by clearing the ON bit (then wait a few cycles for it to actually release the pins?)
 
Please check that your application code is actually running too as there are some persistent problems that seem to pop up with the Harmony bootloader configuration.  Try replacing the start of your application with something that blinks an LED when it tries to do a screen update step and watch it on the scope - my guess is it's not actually running.
 
Hopefully I'm wrong :)  Good luck.
 
 

让我再试一次。我有一个非常好的工作引导加载程序（与微芯片的加载程序无关），它使用PMP接口使用LAMP PMP驱动程序与LCD显示器通信。MHC配置PMP的PIN，并且工作很好，而用户使用引导加载程序来选择他们想要闪现到PIC的应用程序。在闪动应用程序之后，PIC被重置，引导加载程序再次运行，看到没有任何东西插入USB，但是有SOM。Effice在应用程序空间中闪烁，因此它跳转到应用程序。这里没有什么新的。应用程序需要比PMP驱动程序提供的LCD面板更快的响应。与其说PMP驱动程序驱动线路不正确（因为当应用程序被配置为使用PMP驱动程序时，LCD显示正确的数据）时，它还不够快，因为它没有对LCD时序要求进行优化。用逻辑分析仪看PMP线，它们不会被液晶面板的时序图所驱动。这就是为什么我用PMP接口写相同的PIN驱动程序，只配置为GPIOU-OUT。我测试了用一个真正的ICE程序员直接加载应用程序的BIT BUG代码，而不是引导加载程序。现在我需要引导加载程序（或者应用程序，不管它是什么）关闭PMP，并且当引导加载程序跳转到应用程序时，开始使用GPIO来驱动LCD。你的评论，我只需要关闭它的控制寄存器中的PMP是我明天要做的第一件事。



      以下为原文

    Let me try this again.  I have a wonderfully working boot loader (not in anyway related to Microchip's loader) that communicates with the LCD display using the PMP interface using the Harmony PMP driver.  MHC configures the pins for the PMP and is works great - while the user is using the boot loader to select the application they want to flash to the PIC.
 
After flashing the application, the PIC is reset, the boot loader runs again, see that there isn't anything plugged into the USB, but there is something flashed in the application space, so it jumps to the application.  Nothing new here.
 
The application needs faster response on the LCD panel than the PMP driver can provide.  It isn't so much that the PMP driver is driving the lines incorrectly (because when the application is configured to use the PMP driver, the LCD displays the correct data), it's just not fast enough because it is not optimized for the LCDs timing requirements.  Looking at the PMP lines with a logic analyzer, they are not driven the way the timing diagram for the LCD panel shows.  That is why I wrote the Bit Banged driver, using the same pins as the PMP interface, only configured as GPIO_OUTs.  I tested the Bit Banging code loading the application directly with a Real ICE programmer, not the boot loader.
 
Now I need the boot loader (or the application, it doesn't matter which) to shut down the PMP and start using GPIO to drive the LCD when the boot loader jumps to the application.  Your comment that I just need to turn off the PMP in its control register is the first thing I will try - tomorrow.

为什么在Bootloader中使用一种方法，而在主程序中使用不同的方法呢？如果您和Orthor在引导加载程序中设置了PMP，那么您必须将其设置回主应用程序中的禁用状态，或者引导引导程序的结束。可选地，不要在引导加载程序中设置PMP，除非您要引导加载。



      以下为原文

    Why are you using one Method in the Bootloader, and a Different in the Main Program?
If you and Harmony Set up the PMP in the Bootloader, then you must set it back to the Disabled state in the Main App , or and the End of the Bootloader.
Optionally do not setup the PMP in the Bootloader, unless you are going to Bootload.
 

您好，LCD显示器有4行，有1.52毫秒和37 USEC的定时要求？除了使用日立HD44 780控制器或兼容的字母数字字符显示器之外，这些数据几乎都是用8条数据线和3条控制信号或4条数据线和3条控制信号进行比特敲击。如果所有的定时都减慢，则只使用2个控制信号是可能的。降低到显示器所需的最大时间，并在微控制器中处理所有的时间。通过BITBUG控制这样的显示，是一种典型的使用8位微控制器的运动。使用和声来连接这样的显示器，而可能的运动，听起来像是对GMP的过度渲染。BI信号不能在MZ设备上重新映射。当PMP被禁用时，那些I/O线应该作为GPIO可用，只要没有其他外围设备控制，如Aiden Morrison所解释的。我用另一种方式做了，240x320px图形显示。BITBUG 8位GPIO端口，用于验证显示控制器的设备ID，在启用16位并行数据的PMP驱动程序之前。但是在PIC32 MX上，如果PMP或EBI可能需要其他目的，我会将4行字符显示连接到不同的引脚，并在Bootloader和应用程序中使用相同的源代码进行字符显示。你真的能看到超过1000个字符的更新/秒吗？除复位后的前4次传输外，显示控制器所需的实际时间短于数据表中指定的最大时间。如果所有3个控制信号连接，并且驱动程序被正确编码，则可以在运行时检查显示控制器的实际状态。加德，Mysil



      以下为原文

    Hi,
A LCD display with 4 lines that have timing requirements of 1.52 ms and 37 usec ?
Cannot be anything other than a Alphanumeric Character display with Hitachi HD44780 controller or Compatible.
 
Those are almost always bitbanged using either 8 data lines and 3 control signals,
or 4 data lines and 3 control signals.
It is possible to use only 2 control signals, if all timing is slowed down to maximum time needed by the display, and all timing taken care of in the microcontroller.
 
Controlling such a display by bitbanging, is a typical exercise using a 8 bit microcontroller.
Interfacing such a display using Harmony, while a possible exercise, sounds like gross overkill to me.
 
PMP or EBI signals cannot be remapped on MZ devices.
When PMP is disabled, those I/O lines should be available as GPIO, as long as no other peripheral take control,
as explained by Aiden Morrison.
 
I have done it the other way around, with a 240x320 px graphic display. Bitbanging 8 bit GPIO port to verify the device ID of the display controller, before enabling PMP driver for 16 bit parallel data. But that is on PIC32MX. 
 
If PMP or EBI might be needed for any other purpose, I would connect the 4 line Character Display to different pins,
and use the same source code for Character Display both in Bootloader and in Application.
 
Fast update of a Character LCD display?
Are you really able to see more than 1000 character updates/s?
 
Except for the first 4 transfers after a Reset, the actual timing needed by the display controller, is shorter than maximum times specified in the datasheet.
Actual state of the display controller may be checked in runtime, if all 3 control signals are connected, and the driver is correctly coded.
 
Regards,
   Mysil
 
   

如果Bootloader正在设置显示，那么主应用程序也会这么做吗？这可能需要额外的照顾。



      以下为原文

    If the Bootloader is setting up the Display.
Then the Main App is doing it too?
That may need extra care.

我怀疑这只是OP离硬件太远，不知道要写什么寄存器来禁用PMP外设。



      以下为原文

    I suspect this is just the OP being too far removed from the hardware, and not knowing what register to write to disable the PMP peripheral.
 

On＝0；OrpMCon＝0；PMAN＝0；Mysil



      以下为原文

    PMCONbits.ON = 0;
or
PMCON = 0;
PMAEN = 0;
 
   Mysil

谢谢大家的评论。是的，Bootloader被编写为使用Hyg PMP驱动程序。是的，应用程序被编写为使用PMP位敲击。是的，这是不一致的，但是我希望不必返回到其他工作的引导加载程序中。是的，我可能不需要每秒25K字符u。但我确实需要800（在10赫兹的屏幕上更新80个字符）。我无法得到和谐的PMP驱动程序，以支持这一速率-因此有点砰砰。所以，最后，我添加了“PMCONBITS ON＝0”，直到Bootloader跳转到应用程序，它工作！



      以下为原文

    Thanks for everyone's comments.  They were very helpful.
Yes, the bootloader is written to use the Harmony PMP driver.
Yes, the applications are written to use PMP bit banging.
Yes, this is inconsistent - but my hope was to not have to go back into the otherwise working bootloader.
Yes, I can't possibly need 25k character per second updates, but I do need 800 (updating the full 80 characters on the screen at 10 Hz).  I couldn't get the Harmony PMP driver to support that rate - hence the bit banging.
 
So, in the end, I added "PMCONbits.ON = 0;" to just before the bootloader jumps to the application and it works!

很高兴它正在工作…今天我了解到，使用PMP的和谐LCD驱动器比比特敲击慢。我需要一杯饮料。



      以下为原文

    Glad it's working...  Today I learned that the Harmony LCD driver that uses PMP is slower than bit banging.  I need a drink.