完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
嗨，伙计们，我正在搞一个项目，用PIC32MX695F512L uP与外部ADC（I2C）进行气体传感，用几个UARTS进行无线通讯，用SPI总线进行外部闪存，用几个PWM运行水泵等等。C方法。它从来没有很好地工作，因为我只有128K的RAM用于帧缓冲区，我没有使用和谐，所以我手动编码了所有的显示例程，填充框，绘图线，显示基本（主要是单色）图形等。为了将帧缓冲器复制到显示器，我将每个像素的8位转换为16位，这意味着刷新率会受到影响。我只能得到高达35Hz的刷新率，不幸的是，你看到显示器上闪烁着一些低强度的颜色，因为显示器要求60Hz的刷新率最小。硬件上的解决方案是发送8个像素，但是将一些颜色线绑在一起以获得刷新率。但是这会牺牲我的调色板。但是，由于PIC32MZ的价格似乎已经降到与PIC32MX相匹配的水平，我正在考虑用256KB的RAM插入一个MZ，这意味着我可以有一个16bpp的帧缓冲区，并解决我的刷新率问题。看起来我必须对我们的设计进行大约10-15次引脚更改，因为一些引脚分配已经移动了，这不算太糟糕，令人头疼。我主要关心的是这些更改对固件的影响？我知道Microchip试图让每一代人都像以前的设计一样，有人做过这样的改变吗？我从来没有走上和谐之路，当我第一次开始这个项目时，它似乎不够成熟，但在过去的6个月里情况有所改善吗？我会考虑如果改变我的设计，但可能会发现学习曲线有点太陡峭了吗？这意味着我可以不用自己编写框架就可以开始使用更复杂的图形特性，这很有趣但是很费力。目前，我的字体没有任何抗锯齿，我的UI组件没有任何阴影，看起来不错，但考虑到项目的成本，可能还不够好。
以上来自于百度翻译 以下为原文 Hi Guys, I'm currently working on a project with a PIC32MX695F512L uP, used for gas sensing with an external ADC (I2C), using a few UARTS for wireless comms, SPI bus for external Flash and a couple of PWMs for running pumps etc. But, the main problem is that I'm running a 320x240 display using the LCC method. It's never worked very well as I only have 128K RAM for the frame buffer and I'm not using HARMony so I've hand coded all my display routines, filling boxes, drawing lines, displaying basic (mainly monochrome) graphics etc. With the limited RAM the frame buffer is 8bits per pixel and in my DMA routine to copy the frame buffer to the display I'm converting those 8bits to 16bits for every pixel which means the refresh rate takes a hit. I can only get the refresh rate up to 35Hz and unfortunately you see some flickering on the display with some lower intensity colours as the display wants a 60Hz refresh rate minimum. A solution in hardware would be to send the 8pixels but to tie some colour lines together to get the refresh rate up but this would sacrifice my colour palette. But, as the prices of the PIC32MZ have seemingly come down to match the PIC32MX I'm considering dropping in an MZ with 256KB RAM which would mean I could have a 16bpp frame buffer and solve my refresh rate issue. It looks as if I would have to make about 10-15 pin changes to our design as some pin assignments have moved which isn't too bad a headache. My main concern would be the firmware impact of the change? I know microchip try and keep every new generation as similar to the previous design as possible, has anyone done such a change? I have never gone down the Harmony path as when I first started the project it didn't seem mature enough but has the situation improved in the last 6 months? As I would consider it if changing my design but might find the learning curve a bit too steep? It would mean I could start using more intricate graphic features without writing the framework myself, which has been fun but laborious. I currently don't have any anti-aliasing on my fonts or any shading on my UI components which don't look bad but probably not good enough considering the cost of the project thus far. Any advice/anecdotes/help appreciated Thank you 
0
|
|
相关推荐
18个回答
|
|
|
是的，和谐比6个月前好多了。它还有很长的路要走。它是可以使用的。LCC工作。我不确定你是否需要使用UART和PWMS的和声。它增加了复杂性，而不增加更多的价值。您的当前代码对于这些区域最有可能工作。
以上来自于百度翻译 以下为原文 Yes harmony is a lot better than 6 months ago. It still has a long way to go. It is usable. The LCC works. I am not sure that you need to use harmony for the UARTs and PWMs. It adds complexity without out adding much value. Your current code for those S areas will most likely work. |
|
|
|
|
|
是否为当前MX项目启用了编译器优化？在帕莱特模式下，只有35Hz的刷新率对我来说似乎很低。
以上来自于百度翻译 以下为原文 Do you have compiler optimizations turned on for your current MX project? A refresh rate of only 35Hz in pallette mode seems low to me. |
|
|
|
|
|
嗨，是的，正在进行优化，问题是我在DMA中断处理程序中使用查找表手动将8bpp转换为16bpp。我没有使用MLA LCC代码，我编写了自己的代码，所以没有使用任何微芯片调色板填充物。有没有一种存储8bpp和输出为16bpp的更简单的方法？
以上来自于百度翻译 以下为原文 Hi, Yes optimisations are on, the problem is my manual translation from 8bpp to 16bpp using a lookup table in my DMA interrupt handler. I'm not using the MLA LCC code, I wrote my own so am not using any of the microchip palette stuff Is there an easier way of storing 8bpp and outputting as 16bpp? |
|
|
|
|
|
注意MX和MZ之间的PIN可比性。不总是一对一的。
以上来自于百度翻译 以下为原文 be careful about pin comparability between MX and MZ. Not always one to one and onto. |
|
|
|
|
|
您有一个无符号int的256条目查找表吗？那应该很快
以上来自于百度翻译 以下为原文 you have a 256 entry lookup table of unsigned ints? That should be fast |
|
|
|
|
|
在MLA LCC代码中应该有一个例子，说明如何在DMA ISR内部使用有效的调色板。
以上来自于百度翻译 以下为原文 There should be an example in the MLA LCC code for how to use an effecient palette inside the DMA ISR. |
|
|
|
|
|
是的，在我的DMA ISRESC中使用查找表，然后在DMA ISR中：
以上来自于百度翻译 以下为原文 Yes using a lookup table in my DMA ISR const uint16_t COLOR_TABLE [COLORS_N] = // colour look up table { RGBBlack, // 0x00 RGBBlue, // 0x01 RGBRed, // 0x02 RGBGreen, // 0x03 RGBCyan, // 0x04 RGBMagenta, // 0x05 RGBYellow, // 0x06 RGBWhite, // 0x07 RGBKaneGreen, // 0x08 RGBSilver, // 0x09 RGBOrchid, // 0x0A ...... }; //These RGB colours are defines: #define RGBBlack 0x0000 #define RGBBlue 0x021F // 0x001F #define RGBRed 0xF800 #define RGBGreen 0x0790 #define RGBCyan 0x07FF #define RGBMagenta 0xF81F #define RGBYellow 0xFFE0 #define RGBWhite 0xFFFF etc.. Then in the DMA ISR: void __ISR(_DMA1_VECTOR, ipl7SRS) DmaHandler1(void) { static short int line = 0; int i, j; pbTP60 = 1; switch(GraphicsState) { case LineData: // Line Data - colour table look up if(line==0) pbLcdVSYNC=1; // can get rid of VSYNC toggle, just useful for debug - frame rate #ifdef GraphicsLookUp if(line<(FRAME_HEIGHT)) { for( i=LINE_LENGTH,j=0; i>0; i-- ) // 320 pixels at a lineBuffer[j++] = COLOR_TABLE[(GraphicsFrame[(FRAME_HEIGHT-1)-line])]; } #endif if(line DCH1SSIZ = (WORD)LINE_LENGTH*2; GraphicsState=HorizFrontPorch; if(line==10) // reset after ten frames so big enough signal to see on scope - debug only pbLcdVSYNC=0; break; case HorizFrontPorch: // Horizontal front porch timing 20 tDOTCLKs if(++line>BLANKING_PERIOD) line=0; pbLcdDataEnable = 1; DCH1SSIZ = HORIZ_PORCH*2; // Front porch (20) double as 16-bit GraphicsState = LineData; break; default: break; } // exit interrupt handler DCH1CONSET = 0x80; //CHEN = 1; // DMA Channel 1 Control Register CHEN Channel Enable DCH1INTCLR = 0x08; //CHBCIF = 0; // DMA Channel 1 Interrupt Control Register CHBCIF: Channel Block Transfer Complete Interrupt Flag bit IFS1CLR = 0x20000; //DMA1IF =0; // clear interrupt 1 flag pbTP60 = 0; } |
|
|
|
|
|
您尝试过双线/三重缓冲线缓冲区吗？
以上来自于百度翻译 以下为原文 Have you tried double/triplebuffering the line buffer? |
|
|
|
|
|
嗨，不，我还没有。你认为一次缓冲几行，然后踢DMA是值得的吗？
以上来自于百度翻译 以下为原文 Hi, No, I haven't...do you think it would be worth buffering a few lines at a time and then kicking off the DMA? |
|
|
|
|
|
它将减少中断开销，但随后您希望将实际转换从ISR中移出。不管怎样，这可能是个好主意。但是如果您的应用程序只是在等待当前传输完成，那么最好将时间花在准备下一次传输上。当然，如果你的CPU使用率很高，那就没什么大不了的了。
以上来自于百度翻译 以下为原文 It'll reduce the interrupt overhead, but then you'd want to move the actual conversion out of the ISR. That would probably be a good idea anyway. But if your application is just waiting for the current transfer to be completed, then that time could be better spent preparing the next transfer. Of course, if you're at full CPU utilization then it won't make much difference. |
|
|
|
|
|
我认为，如果我把缓冲线从ISR中移开，时机会变得很棘手吗？如果我的正常操作代码（只是一个超级循环类型的OS）需要更长的时间来做一些事情，那么显示器可能会掉线/掉帧。这取决于设备在做什么（它是一个手持气体分析器，它定期读取ADC，处理测量，显示到屏幕，保存到EEPROM并通过无线模块发送数据）。我需要大约20mS来完成所有的显示工作（许多绘图线，sprintf来处理测量字符串等等）在ISR中需要大约56uS来完成行转换（320像素转换8bpp到16bpp），所以我必须找到一种每次预处理几行的方法。将DMA ISR发送过来。我可以用另一个交织器来触发这个预处理吗？独立于我的主超环
以上来自于百度翻译 以下为原文 I think getting the timing right if I move the line buffering out of the ISR could be tricky? If my normal operating code (just a superloop type OS) takes a bit longer to do something then the display could drop lines/frames. This could happen depending on what the unit is doing (it's a handheld gas analyser which is reading ADC regularly, processing measurements, displaying to screen, saving to EEPROM and sending data via wireless module). I'm writing to the display frame buffer five times a second to keep it snappy but it takes me about 20mS to do all the display stuff (lots of drawing lines, sprintf to process measurement strings etc) It's taking approximately 56uS in the ISR to do the line conversion (320 pixel conversions 8bpp to 16bpp) so I have to find a way of pre-processing a few lines at a time in time for the DMA ISR to send it across. I could use another interrup timer to trigger this pre-processing maybe? Independent of my main superloop |
|
|
|
|
|
以上来自于百度翻译 以下为原文 Instead of wasting time filing the lineBuffer and then transmitting the data using DMA, it is easier if you just send the data directly out over the PMP and not use the DMA. You don't have to waste time waiting until the PMP isn't busy either anymore since the data will be read by the LCD before the next data is transferred. The internal LCD clock is much fast than the PIC. |
|
|
|
|
|
但是，一旦你开始转移，DMA不是在后台为你工作吗？仅仅使用PMP将需要相当多的中断驱动处理，以便让数据准备好发送给它，不是吗？除非我误解了
以上来自于百度翻译 以下为原文 But isn't the DMA doing the work for you in the background, once you kick off the transfer? Solely using the PMP would need quite a lot of interrupt driven processing to get the data ready for it to send too wouldn't it? Unless I've misunderstood |
|
|
|
|
|
但是，一旦你开始转移，DMA不是在后台为你工作吗？仅仅使用PMP将需要相当多的中断驱动处理，以便让数据准备好发送给它，不是吗？除非我误解了，否则你没有误解。ADAMFLATS有。
以上来自于百度翻译 以下为原文 But isn't the DMA doing the work for you in the background, once you kick off the transfer? Solely using the PMP would need quite a lot of interrupt driven processing to get the data ready for it to send too wouldn't it? Unless I've misunderstood No, you haven't misunderstood. adamfolts has. |
|
|
|
|
|
他的观点是，PMP比CPU能更快地消耗数据，即，PMP写缓冲器永远不会填满。
以上来自于百度翻译 以下为原文 His point was that the PMP can to consume data faster than the CPU can produce it, ie. the PMP write buffer will never fill up. |
|
|
|
|
|
我不是那样读的。但是再考虑一下，你的解释可能是正确的。如果PMPhas没有等待状态，那么PMP将比从调色板读取的速度更快地传输。因此，取消行缓冲区/DMA，并将调色板查找结果直接写入PMP，而不必等待PMP状态。实际上，来自我的一个项目（IL9341）的代码：-在MZ上运行正常在96MHz。
以上来自于百度翻译 以下为原文 I didn't read it that way. But thinking about it again, your interpretation is probably right. If the PMPhas no wait states, the PMP will transmit faster than you can do the read from the palette. So scrapping the line buffer/DMA and writing the palette lookup result directly to the PMP, without waiting on PMP status. In fact, code from one of my projects (IL9341):- unsigned npix=LCD_XRES*LCD_YRES; for(;npix;npix--) { #if defined LCD_COLOUR_16BIT #ifdef USE_16BIT PMDIN=pctr->wval; #else PMDIN=pctr->hi; PMDIN=pctr->lo; #endif #elif defined LCD_COLOUR_INDEXED #ifdef USE_16BIT PMDIN=Palette[*pctr]; #else PMDIN=Palette[*pctr]>>8; PMDIN=Palette[*pctr]&0xff; #endif #endif pctr++; } This was running ok on an MZ at 96MHz. |
|
|
|
|
|
好吧，那么你会定期地为这个例行公事服务吗？通过中断还是在主循环中？会给出这样的尝试并汇报
以上来自于百度翻译 以下为原文 Ok, so you'd service this routine how regularly? And via interrupt or in your main loop? Will give something like this a try and report back |
|
|
|
|
|
每当我想要一个全屏更新。我设置了一个标志来表示缓冲区已经被修改，然后如果已经设置了标志，则从主循环周期性地调用更新函数。应用程序并不真正关心fps，只是在更新屏幕时没有明显的闪烁。我还有一个窗口更新函数f。或更新屏幕的一部分。
以上来自于百度翻译 以下为原文 Whenever I wanted a full screen update. I set a flag to denote that the buffer had been modified, then called the update function from the main loop periodically if the flag had been set. The application didn't really care about fps, just that there was no noticeable flicker when updating the screen. I also had a windowed update function for updating part of the screen. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5250 浏览 9 评论
2037 浏览 8 评论
1958 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3218 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2266 浏览 5 评论
788浏览 1评论
680浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
609浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
685浏览 0评论
582浏览 0评论
/7 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
994
评论
淘帖
1990
