尝试通过DMA实现共享内存时的奇怪行为

我从Pocket PC文档中注意到的另一件事是，OD（输出禁用）线在写入低之前变高。文档并不十分清楚，但听起来这是为了禁止其他设备写入总线，这样CPU就可以准备数据写入。我想我会试着在我的GPIO数据总线上挂上（反转）到输出使能，而不是使用R/W。我没有一个很好的理论来解释这将导致我看到的问题，但是，如果我正确地解释这个信号的使用，这应该是正确的方式来做这件事，不管…也许这也会有助于解决1000个问题。



     以下为原文
  One other thing I noticed from the Pocket PC documentation is that there is an OD (output disable) line, that goes high before write goes low. The documentation isn't very clear, but it sounds like this is to disable other devices from writing to the bus so the CPU can prepare its data to write. I think I'll try hooking that up (inverted) to output enable on my GPIO data bus instead of using R/W. I don't have a great theory on how this would cause the issue I'm seeing, but, if I'm interpreting the use of this signal correctly, this should be the right way to do this piece, regardless... and maybe it will help with the 1000 issue, too.

好。。。切换到OD来控制数据总线和以前一样工作。阅读1000个值没有改进。



     以下为原文
  Well... switching to OD to control the data bus works just as well as before... no improvement for reading the 1000 values.

另一个尝试理解这一点的实验：
我添加了一个第二个数据TD，指向一个固定的地址。因此，第一TD将数据总线值写入缓冲器偏移地址，第二个写入固定地址。这里，如果我写129，它是由固定地址拾取的，而不是缓冲器。如果我写12，它是由缓冲器拾取的，而不是固定地址。
所以，我猜一定是一个定时问题，并且某些值需要更长或更少的时间来写CPU…似乎仍然很奇怪。还有其他想法吗？某种数据锁存器，可以被边缘触发，以更快地抓取数据总线上的写入和保持它的DMA？



     以下为原文
  Another experiment to try to understand this:
 
I added a second data TD, pointing it to a fixed address. So, the, first TD writes the data bus value to the buffer offset address, and the second one writes to the fixed address. Here, if I write 129, it's picked up by the fixed address, but not the buffer. If I write 12, it's picked up by the buffer but not the fixed address.
 
So, I guess is must be a timing issue and certain values take longer or less time for the CPU to write... Still seems weird. Any other ideas? Some sort of data latch that could be edge triggered to more quickly grab the data bus on write and hold it for the DMA?

六羟甲基三聚氰胺六甲醚。。。当Google试图找到更多的答案时，我发现：
“
2。R: DMA控制寄存器问题
USER131388 2015年8月4日上午7:35（响应USER 47 50506624）
欢迎来到G.论坛
你的问题是为什么大多数例子都是用数组来处理的：很容易回答：“仅仅”一个字节的传输是一个很大的开销，所以一个简单的任务就可以打败DMA，即使是一个中断驱动的解决方案也会更快。
总是建议发布工作区包，以便我们都可以查看所有的设置。要做到这一点，使用eCurror & gt；file & gt；创建工作区束（最小）并附加结果文件。
鲍勃
“
所以，我回去并重新编写了我的非基于DMA的（基于）循环的接口，当然，这似乎足够快。敲木头…



     以下为原文
  Hmmm... while Googling trying to find more answers, I found this:
 
"
2. Re: DMA to Control Register Question


[size=0.9em]user_1377889 Aug 4, 2015 7:35 AM (in response to user_475068624)
Welcome in the forum, G.
  
Your question why most of the examples are working with arrays is quite easily answered: The setup for "just" a single byte transfer is a large overhead, so a simple assignment would beat the DMA, even an interrupt driven solution would be faster.
  
It is always advisable to post a workspace bundle so that we all can have a look at all of your settings. To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
  
 
  
Bob
"
 
So, I went back and re-wrote my non-DMA for(;;) loop based interface, and, sure enough, that seems fast enough. Knock on wood...

好啊。因此，要清楚的是，正确的答案是DMA花了足够长的时间来设置，它远不及将一个字节作为CPU驱动的循环传输快。一个带有PSoC 4的for循环对于我想做的不够快，但是在PSoC 5上有一个用于页面解码的状态寄存器，其速度足够快，能够可靠地模拟1.3MHz的8位处理器的SRAM。



     以下为原文
  OK. So, to be clear, the correct answer is that DMA takes long enough to set up that it is nowhere near as fast to transfer a single byte as a CPU-driven for loop. A for loop with PSoC 4 wasn't fast enough for what I wanted to do, but the same one on PSoC 5 with a status register for page decoding, is fast enough to reliably emulate SRAM for a 1.3Mhz 8-bit processor.

你好，
如果我可以添加我的两分钱，这或多或少（不同的复古事物，不同的故事）我想做的一件事，实际上我的是轻微的不同，但同样得出的结论是，PSCO5也不够快，因为这种工作需要太多的周期，尤其是对于老年人来说。能够在1个时钟周期中进行MEM访问的CPU。
最后，我求助于“ExtMeMe界面”和双端口RAM，但这有缺点，它需要很多引脚，加上需要外部（昂贵）的芯片，对于这种应用来说，“几乎需要一个专门为它设计的芯片”，我太“太乐观”了，肯定是瘦了。对于这么多兆赫的G可以采取中断，并呈现一个字节的端口“…结果是“不，你不能，它仍然是太多的时钟周期”，甚至匹配1MHz的CPU，甚至比我不确定的还要多。
说，我知道“有些人这样做”（但我不知道细节）如何使用“其他一些CPU”，因为我不知道的原因似乎能够做到“更容易”，但我的“看PSoC5”给我的印象是，“事实上，看起来你不可能真的做到这一点”，除非有。我做不到的一些“非常聪明的把戏”。



     以下为原文
  Hi,
if I may add my two cents this is more or less ( different retro thing, different story ) one of the things I wanted to do, actually mine was lightly different but likewise got to the conclusion  that PSCO5 as well it's not fast enough for this kind of work takes too many cycles especially for older CPUs that were able to do a mem access in 1 clock cycle.
 
In the end I resorted to "ExtMemInterface" and a dual port ram, but this has the drawback it requires lot of pins plus you need external ( expensive ) chips, thing is for this kind of application you'd "almost need a chip specifically designed for that", I was too "too optimistic" that 'sure a thing for so many MHZ can take an interrupt and present a byte to a port" .. and turns out "no you can't, it's still too many clock cycles" to even match a 1MHz cpu, even more than that I am not sure.
 
Said that, I know "some people did it" ( but I do NOT know the details of how ) using "some other CPUs" that for reasons I don't know seems to be able to do that 'easier', but yeah my "look at PSOC5" give me the impression that "as it is, does not look like you can actually do that" unless there is some "extremely clever trick" for doing it I don't know.

这可能没什么帮助，但你尝试分配一个更高的优先权的DMA通道？



     以下为原文
  This might not help at all, but did you tried assigning a higher priority to the DMA Channels?

对。没有帮助。



     以下为原文
  Yes. Didn't help.

对我来说，它在起作用。我做的最后一次测试是在我的PSoC SRAM中编码一个机器语言（主机口袋PC）例程，它将内存块从源地址复制到目的地址。我用它从Pocket PC ROM复制512字节到我的PSoC接口的R/W区域。这在48兆赫有点闪亮，但已经证明是72MHz的实心。我用它做了32遍，把整个16K的ROM写入到SD卡上的一个文件中。
读取机器语言操作码，同时，将字节写入到PSoC仿真“RAM”中，每个字节传输都是用一个单一的操作码调用完成的，它告诉我，在这个设备中，我能做的任何事情都应该足够快。但是，必须从48 MHz到72MHz，使这项工作可靠地告诉我，我非常接近可以在PSoC 5上进行RAM仿真所能达到的极限。双端口存储器是我正在寻找的下一个选项。
我不认为这会用中断来工作，而且肯定不会用DMA工作。这都是在for循环中完成的，该循环首先写入数据（由输出禁用控制的数据输出和从Pocket PC中解码的地址芯片选择），然后在R/W变低的情况下阻止位等待写入。



     以下为原文
  For mine, it is working. The last test I did was encoding a machine language (of the host Pocket PC) routine in my PSoC SRAM which copies blocks of memory from source to destination addresses. I used this to copy 512 bytes from Pocket PC ROM to the R/W area of my PSoC interface. This was a bit glitchy at 48MHz, but has proven to be solid at 72MHz. I used it to make 32 passes and write out the whole 16K of ROM to a file on the SD card via EMFile.
 
Reading the machine language opcodes out of, and, at the same time, writing bytes back in to the PSoC emulation "RAM", with each byte transfer being done with a single opcode call, tells that this should be fast enough for anything I can do in this device. But, having to go from 48MHz to 72MHz to make this work reliably tells me that I'm pretty close to the limit of what can be done with RAM emulation on a PSoC 5. Dual-port memory was the next option I was looking at.
 
I don't think this would work with interrupts, and it certainly didn't work with DMA. This is all done in a for loop that first writes data (with the data output controlled by output-disable and a decoded address chip select from the Pocket PC) and then will block a bit waiting in case R/W goes low to write.

你好，
为了让你知道“我的第一次尝试”，我假设我可以做这样的事情，使用两个端口的“地址”和一个“数据”，并有一些位/CE/RW。
其思想是在/CE引脚（高到低）上设置中断转换，并具有这样的中断例程：
中断：
读取端口A
读取端口B
Read＝Read（RW）；
地址= BasyMeM+a＆lt；lt；8 +b；
如果（读）
{
字节= *地址；
写入字节（端口C）
}其他
{
字节＝读字节（端口C）
*地址＝字节；
}
结束中断
结果…太慢了，你仍然在消耗大量的PIN，加上MEM可不是那么多。
我不认为有一种简单的方法来使用PSoC，也不是真的与其他MCU，我看到的唯一的一件事“或多或少就像我刚刚在这里做的”，在ASM，是一个完全不同的100 MHz CPU（这里我不会提到，因为它是“竞争”）。
现在，双端口RAM芯片比PSOC5还要昂贵得多，如果这是你真正需要的，可能没有其他更简单的解决方案，到了最后，这一切都归结为“时钟周期和速度有多快”，我试图为“6809/6502 CPU A”做一些类似但更复杂的事情。然而，即使旧的CPU工作在1 MHz，“数学不增加”也不能足够快地做到这一点。
如果你想“我对PSoC4／5的总体印象，我到目前为止”是这样的，对于价格来说，这对很多事情都很好，但不是所有人都能想到的，“我认为它更适合于模拟处理”，对于这种“有点专业化应用”的东西。
在PSOC5中，我仍然发现有一点是有限的，即程序/ RAM的数量，特别是用C编译器进行的，而且，是的，它是好的/不好的，但是当你开始这样的事情时，可用的I/O引脚的数量很少。



     以下为原文
  Hi,
 
just to let you know "my first attempt" I assumed I could have done a thing of this kind, use two ports for "address" and one for "data" and have some bits for /CE /RW.
 
The idea was to set an interrupt transition on the /CE pin ( high to low ) and have an interrupt routine of the kind :
 
INTERRUPT :
read port A
read port B
read = Read(RW);
address = base_mem + a << 8 + b;
if ( read )
{
  byte = *address;
  write_byte ( port C)
}
else
{
byte = read_byte ( port C)
*address = byte;
}
END INTERRUPT
 
Turns out .. "too slow" and you are still consuming lot of pins, plus the mem available is not that much.
 
I don't think there's an easy way to do this with the PSOC, nor really with others MCUs, the only one that I've seen doing something 'more or less as I just done it here', in ASM, was on a totally different 100 Mhz CPU ( which I won't mention here because it's 'competition'  ).
 
Now a dual port RAM chip costs lot more than the PSOC5 still, if that's what you really need probably there's no other simpler solution, in the end of the day it's all down to 'clock cycles and how fast you can be', I was trying to do 'something similar but a bit more complex' for a 6809/6502 CPU and yet turns out 'math does not add'/'can't be fast enough for doing it that way' even if the old CPU works at 1 Mhz.
 
If you want 'my overall impression about PSOC4/5 I got so far' is that 'for the price and such it's pretty good for MANY things BUT NOT for ALL the things one could think about' I see it 'more suited for analog processing' that for this sort of stuff that 'is a bit a specialized app'.
 
One thing I still find quite a bit limited on the PSOC5 is the amount of program/ram inside especially going with a C compiler and such, also yes it's good/no good but the number of available I/O pins - when you start doing 'this kind of stuff' - is little.

我也尝试了一种基于中断的方法。是的，这也太慢了。像DMA一样，有几个时钟周期来推动电流寄存器并开始为中断服务。只有连续循环方法对我起了作用。我不需要MCU做任何其他事情时，CPU需要它的行为像RAM，所以没关系。
在伪代码中，我正在做这样的事情：
（；）
{
LoTe= PixAddiSrsLoWip；/ / 8低地址位
Page＝StasuSpPage状态，//解码页面从8个高位地址位和状态寄存器
DATAYDR =缓冲器[PAGE ] [LCONT]；//用于数据引脚的输出使能由CS和CPU的输出禁用控制。
（…）/一堆东西等待R/W去写，而地址是相同的，CE是高的。
如果（…）/写入数据条件满足
{
缓冲器[页] [地址]＝DATAPEPS；
如果（…）/数据写入是MCU的命令
{
DATAYDR＝BuyyStasuSUX代码；
//选择所选命令，例如打开SD文件或发送一些BLE数据
DATAYDR =结果状态代码…
}
}
}
对于我的项目来说，64K的RAM已经足够了。我计划用62256把24K的扩展RAM添加到Pocket PC中，让PSoC 5进行CS解码（扩展是我已经与62256和专用的7HC解码逻辑一起工作的设备），但是我想我会尝试使用剩下的PSOC RAM中的一些。我目前只使用4K内存映射缓冲区，总共少于16K。如果在添加扩展RAM仿真时，环路仍然足够快，那么问题将成为PSoC RAM与62256的功耗和数据持久性物流之一。



     以下为原文
  I tried an interrupt-based approach, too. And, yes, that was also too slow. Like DMA, there are several clock cycles to push current registers and start servicing an interrupt. Only the continuous for loop approach has worked for me. I don't need the MCU to be doing anything else when the CPU needs it to be acting like RAM, so that's OK.
 
In psedocode, I'm doing something like this:
 
for (;;)
{
     laddress = pin_address_low_PS; //8 low address bits
     page = status_page_status;  //decoded page from 8 high address bits and a status register
     data_DR = buffer[laddress]; //output enable for data pins is controlled by CS and CPU's output disable
     while (... ) //a bunch of stuff to wait to see whether R/W goes to write while the address is the same and CE is high
          if(...) //write data conditions met
               {
                    buffer[laddress]=data_PS;
                    if(...) //data write was command for the MCU  
                    {
                         data_DR = BUSY_STATUS_CODE;
                         //do selected command, e.g. open an SD file or send some BLE data
                         data_DR = result status code...
                    }
               }
}
 
For my project, the 64K of RAM has so far been plenty. I was planning to add 24K of expansion RAM to the pocket PC using a 62256 and having the PSoC 5 do the CS decoding (that expansion is a device I already have working with the 62256 and dedicated 74HC decode logic), but I think I'm going to try using some of the remaining PSoC RAM instead. I'm currently only using 4K for the memory mapped buffer, and less than 16K total. If the loop is still fast enough once I add the expansion RAM emulation, then the question will become one of power consumption and data persistence logistics with the PSoC RAM vs the 62256.

实际上，我刚刚想到，到目前为止，我还没有在MCU提供的“ROM”中实现任何东西，这就要求CPU等待MCU完成一个长时间运行的任务。不过，我想添加一些类似的命令，用MCU的扩展来完成更复杂的事情。这将是一个问题，如果MCU不能服务ROM在繁忙的时候。
我可以想出几个选择来实现这一目标。一个是将等待完成的状态循环复制到Pocket PC RAM的一个小区域，并在CPU中循环，直到MCU更新到非繁忙状态。另一种方法是使用扩展RAM的62256，并将“ROM”数据复制到一个未使用的部分（8K没有映射到CPU的空间），然后在MCU中切换地址解码，这样这个空间显示ROM需要的地方。这可以在启动或第一次使用命令时完成。启动似乎更容易，但我不确定CPU停机和INT线，我需要MCU接管巴士是在我计划使用的扩展槽。



     以下为原文
  Actually, it just occurred to me that, so far, I have not implemented anything in the "ROM" that's served up by the MCU that would require the CPU to wait for the MCU to finish a long-running task. I want to add some commands like that, though, to do more complex things entirely with extensions from the MCU. That will be a problem if the MCU can't serve up ROM while it's busy.
 
I can think of a couple of options to accomplish this. One would be to copy the wait-for-done-status loop over to a small area of pocket PC RAM and have the CPU loop in that until the MCU updates to a non-busy status. Another would be to stick with the 62256 for expansion RAM and copy the "ROM" data to an unused section in it (there's 8K that doesn't get mapped into the CPU's space), then switch address decoding in the MCU so this space shows up where the ROM needs to be. This could be done at startup or at first use of a command. Startup seems like it would be easier, but I'm not sure that the CPU HALT and INT lines I would need for the MCU to take over the bus are available on the expansion slot I'm planning to use.