如何正确使用SPI

3MHz的传输速度和60MHz的CPU没有留下太多的空间来执行代码。因此，您必须使用一个相当大的缓冲区（由已优化的）源处理，并使用适当的API。当使用缓冲器（128到256是一个很好的大小，使你在正确的大小）为RX和Tx，你将不得不忘记FIFO，只是检查，因为你已经怀疑的数据使用“XXXXGETRXBuffelSsize”（这实际上不是缓冲区大小，但字节计数）和“XXXA RealRxDATA”。
你有一种方法来控制成功传输，通过比较你的传输字节数（你通常知道），所以当你开始松散字节时，一定是可疑的。
只要一次传输不清空FIFO，SS线就可以正常工作，因此当发送寄存器号和寄存器值时，可能会有一个短的SS线故障，一些设备往往会产生HICKUPS。所以转移都与_putarray()检查一个完整的转移继续前一个电话。即使所需的虚拟字节读取结果可以/应该发送同一_putarray()当设备需要一个单一的SS低相。
不要触摸（读）在缓冲模式任何SPI状态寄存器！有位“粘”（重置时红色）这可以推断与内部中断处理程序。
问候下！（我女儿住在那里）
鲍勃



     以下为原文
  A 3MHz transfer speed and a 60MHz CPU does not leave very much room for executing code. So you will have to use a fairly large buffer handled by the (already optimized) generated sources and use the appropiate APIs. When using buffers (128 to 256 is a good size for you to be on the right size) for both Rx and Tx you will have to forget about the FIFOs and just inspect as you already suspected the data using "xxx_GetRxBufferSize" (which is actually not a buffer size but a byte count)  and "xxx_ReadRxData".
    You have a means to control the successful transmission by comparing _GetRxBufferSize() to the number of bytes you transmitted (which you normally know), so when you start to loose bytes something must be fishy.

    The ss-line works well as long as a single transfer does not empty the FIFO, so when transmitting the register number and then the register value there might be a short ss-line glitch from which some devices tend to get hickups. So transfer both with a single call to _PutArray() and check for a complete transfer before continuing. Even the requred dummy bytes for reading results can / should be sent with the same _PutArray() when the device needs a single ss-low phase.
    Do not touch (read) any SPI-status registers in the buffered mode! Some bits are "sticky" (reset when red) and this could infer with the internal interrupt handler.
     
    Greetings to Down Under! (My daughter lives there)
    Bob

你好，鲍伯
（我希望你的女儿住在澳大利亚北部的某个地方，因为现在墨尔本的天气有点冷。）
谢谢你提供的信息。看来缓冲的选择是走的路。（事实上，我发现，我在这个问题上遇到的一个问题是，我没有打开全球中断——但即使这样做也会导致一些问题。）
是的，我使用XXX-PUTARSART函数进行所有的传输，从芯片似乎响应正确，所以SS 线看起来应该被控制。
然而，我一点你的两个评论疑惑：首先，我要等到在继续之前，二是不在缓冲模式因为阅读粘位将妨碍缓冲ISR读取状态寄存器传输完成（至少这是我的方式说出你说的话。
因此，我怎么知道发送的数据通过xxx_putarray功能实际上已经把如果我不使用xxx_readtxstatus寻找（说）的xxx_sts_spi_idle？这是看xxx_getrxbuffersize等到得到的字节数或是有一个“更好”的方式可靠吗？
苏珊



     以下为原文
   Hello Bob
    (I hope your daughter lives up north somewhere in Australia as it is getting a bit cold down here in Melbourne at the moment!)
    Thank you for the information. It would seem that the buffered option is the way to go. (Actually I found that part of the problem I had with that approach was that I had NOT turned on the global interrupts - but even doing that still leads to some problems.)
    And yes, I am using the xxx_PutArray function for all of the transfers and the slave chip seems to be responding correctly so the SS line appears to be controlled as it should.
    However, I'm a bit puzzled by two of your comments: the first is that I should wait until the transfer is complete before continuing and the second is not to read the status registers in buffered mode beause reading the sticky bits will interfere with the buffering ISR (at least that is the way I read what you said).
    Therefore, how can I tell that the values sent via the xxx_PutArray function have actually been sent if I don't use the xxx_ReadTxStatus and look for (say) the xxx_STS_SPI_IDLE? Is it reliable to look at the xxx_GetRxBufferSize and wait until that gets to the byte count or is there a "better" way?
    Susan

你好，
鲍伯指出，不建议直接读粘登记。你可以读取的字节数左理解传输完成或没有。但不得不说的是，我还用conditionwhile测试（0U = =（spim_readtxstatus() &；spim_sts_spi_done））情况spi-dma也和它的工作很好。看来这将取决于这个项目。
干杯！！！！



     以下为原文
   [size=11.9999990463257px] Hi,
    [size=11.9999990463257px] 
    [size=11.9999990463257px]As Bob pointed out it is not recommended to directly read the sticky register. You can read the number of bytes left to understand that transmission is done or not.But having said that, I have also tested using the condition while (0u == (SPIM_ReadTxStatus() & SPIM_STS_SPI_DONE)) in case of SPI-DMA also and it had worked fine. Seems it will depend on the project.
    [size=11.9999990463257px]Cheers!!!

对不起，苏珊
我真的忽略了你的回复，我再看看HIZ触发该线程。
重置的状态标志会干扰中断驱动的环形缓冲组件提供的。
所以使用GeTrxBuffSersie（）的想法会有所帮助。您可能总是使用像
而processdata()（getrxbuffersize()）；//清空接收缓冲区
此外，你可以在你所期望的相关数据清空缓冲区重新开始使用clearrxbuffer()。
鲍勃
树开了，春天来了！



     以下为原文
  Sorry, Susan
    I really overlooked your reply and HiZ triggered me to look at this thread again.
    The resetting of the status flags will interfere with the interrupt driven circular buffer provided by the component.
    So the Idea of using GetRxBufferSize() will help. You may always use constructs like
    while(GetRxBufferSize()) ProcessData(); // Empty the recieve buffer
    Moreover you may use a ClearRxBuffer() before you are expecting relevant data to empty the buffer and start anew.
     
    Bob
    Here: Trees are in blossom, we have got spring!

谢谢你们的帮助-非常感谢。
然而我已经搬东西有点和我搬到一个DMA的方法，给我更多的灵活性。（我不想为什么现在但这似乎是最灵活的方式，我需要做什么。）但我有问题ISR触发接收DMA完成时。
我相信，中断设置正确，我可以使用一个API调用来触发和ISR被称为。我相信TX的DMA设置正确，我可以发送一个字节的数目可变的SPI和我看到的值被发送到的值被发送到MOSI线。
RX DMA设置几乎完全一样，但是，尽管可以看到值传递回的MISO线（和SPI工作以前没有DMA）从未有任何数据放入接收缓冲区。
代码是：
[代码]
UTIN RX通道；
UITN8 RXTD；
UTIN8 RXPASH〔65〕；
UTI8TX通道；
UTIN TXTD；
UTIN TXBuff[ 65 ]；
UIT8 8DMAGLAG；
CysISR（DMAI ISR）
{
DMAGLAG＝1；
}
静态max3421_setuptransfer（uint8计数，uint8 src，uint8 * DST）
{
细胞状态结果；
UIT8状态；
UTIN 16 XFECOUNT；
UNITT8 NEXTTD；
UIT8配置；
结果：cydmachsetextendedaddress（txchannel，hi16（（uint32）（（SRC），hi16 UInt32）max3421spi_txdata_ptr））；
结果：cydmatdsetaddress（泰翔通达，lo16（（uint32）SRC），lo16（（uint32）max3421spi_txdata_ptr））；
结果：cydmatdsetconfiguration（泰翔通达，计数，dma_disable_td，td_inc_src_adr）；
结果：cydmachsetextendedaddress（rxchannel，hi16（（max3421spi_rxdata_ptr UInt32）），（（hi16 UInt32）rxbuffer））；
结果：cydmatdsetaddress（rxtd，lo16（（uint32）max3421spi_rxdata_ptr），lo16（（uint32）rxbuffer））；
结果：cydmatdsetconfiguration（rxtd，计数，dma_disable_td，td_inc_dst_adr）；
DMAGLAG＝0；
结果＝CydMaun启用（Rx通道，1U）；
结果= CydMaun启用（TxChank，1U）；
//结果＝CyDmaChSetRequest（TxChanp，CPU-Req）；
（；）
{
如果（DMAGLAG）
{断裂；}
结果= CydMcReRelor（）；
结果：cydmatdgetconfiguration（rxtd，&；xfercount，&；nexttd，&；配置）；
结果：cydmatdgetconfiguration（泰翔通达，&；xfercount，&；nexttd，&；配置）；
结果＝CyDmaChGetRequest（TxChank）；
结果＝CyDmaChGetRequest（RxChank）；
}
}
[代码]
（所有的垃圾在函数的末尾是我验证了DMA传输完成，没有错误的报道。）
以前我有分配DMA通道和增加TDS等。
我不知道我在接收DMA设置错误，但是我不知道为什么我没有得到值为RxBuffer Tx侧工作时完全。
苏珊



     以下为原文
  Thanks for the assistance guys - it is much appreciated.
    However I have moved things along a bit and I've moved to a DMA approach which gives me a bit more flexibility. (I won't go into why now but this seems to be the most flexible approach that does what I need.) But I'm having problems getting an ISR triggered when the Rx DMA completes.
    I am sure that the interrupt is correctly set up as I can use an API call to trigger it and the ISR is called. I am sure that the Tx DMA is correctly set up as I can send a variable number of bytes to the SPI and I can see the values being sent to the values being sent to the MOSI line.
    The Rx DMA is set up almost exactly the same but, despite the fact  can see values being passed back on the MISO line (and the SPI worked previously without the DMA) there is never any data put into the Rx buffer.
    The code is:
    [code] 
    uint8 rxChannel;
    uint8 rxTD;
    uint8 rxBuffer[65];
    uint8 txChannel;
    uint8 txTD;
    uint8 txBuffer[65];
    uint8 dmaFlag;
     
    CY_ISR( DMA_ISR)
    {
     dmaFlag = 1;
    }
     
    static void MAX3421_SetupTransfer( uint8 count, uint8* src, uint8* dst)
    {
     cystatus result;
     uint8 state;
      
     uint16 xferCount;
     uint8 nextTD;
     uint8 config;
     
     result = CyDmaChSetExtendedAddress( txChannel, HI16( (uint32)src), HI16( (uint32)MAX3421SPI_TXDATA_PTR));
     result = CyDmaTdSetAddress( txTD, LO16((uint32)src), LO16((uint32)MAX3421SPI_TXDATA_PTR));
     result = CyDmaTdSetConfiguration( txTD, count, DMA_DISABLE_TD, TD_INC_SRC_ADR);
      
     result = CyDmaChSetExtendedAddress( rxChannel, HI16((uint32)MAX3421SPI_RXDATA_PTR), HI16((uint32)rxBuffer));
     result = CyDmaTdSetAddress( rxTD, LO16((uint32)MAX3421SPI_RXDATA_PTR), LO16((uint32)rxBuffer));
     result = CyDmaTdSetConfiguration( rxTD, count, DMA_DISABLE_TD, TD_INC_DST_ADR);
      
     dmaFlag = 0;
      
     result = CyDmaChEnable( rxChannel, 1u);
     result = CyDmaChEnable( txChannel, 1u);
      
    // result = CyDmaChSetRequest( txChannel, CPU_REQ);
      
     for(;;)
     {
     if( dmaFlag)
     { break; }
      
     result = CyDmacError();
     result = CyDmaTdGetConfiguration( rxTD, &xferCount, &nextTD, &config);
     result = CyDmaTdGetConfiguration( txTD, &xferCount, &nextTD, &config);
     result = CyDmaChGetRequest( txChannel);
     result = CyDmaChGetRequest( rxChannel);
     }
    }
    [code]
    (All of the junk at the end of the function is me verifying that the DMA transfers have completed and there are no errors reported.)
    Previously I have allocated the DMA channels and added the TDs etc.
    I can't see my mistake in the Rx DMA setup but I can't see why I don't get values into the RxBuffer when the Tx side works perfectly.
    Susan
            

你的代码片段中有一个讨厌的隐藏错误，（大概）还没有发生。
作为一般规则：
在中断处理程序中更改的每个全局变量都必须声明为“易失性”。
原因是：“易失性”是C优化步骤中的一个信息，说明变量可能从当前上下文的“外部”改变。一个例子：
而（MyFLAG）；
上面的线显然是一个等待MyFLAG变为假的循环（0）。优化器“看到”循环内的变量“MyFLAG”没有改变，所以代码可以通过提取变量而改变，只测试一次，留下无限循环为真（！）！= 0）“MyFLAG”的情况。
在创建者中编译步骤的默认优化设置非常薄弱，但这可能会发生变化。至少当你的项目中有一个针对Flash大小限制或太耗时的时候，一个带有“释放”设置的编译将启动DeStase:Project不运行，但是不能被调试以找到原因。
这里还有一些解释
所以，在你的例子中，使用
易失性UTIN 8DMAGLAG；
快乐编码
鲍勃



     以下为原文
  There is a nasty hidden bug in your code-snippet that (presumably) had not occured yet.
    As a general rule:
    Every global variable that gets altered in an interrupt handler must be declared as "volatile"
    The reason is: "volatile" is an information for the C-optimization step telling that the variable might be changed from "outsides" of the current context. An example:
    while(MyFlag);
    The above line is obviously a loop waiting for MyFlag becoming FALSE (0). The optimizer "sees" that within the loop the variable "MyFlag" is not altered, so the code can be changed by extracting the variable out of the loop and testing it only once leaving an infinite loop as the TRUE (!=0) case for "MyFlag".
    The default optimization settings for the compile step in Creator are very weak, but this may change unannounced. At least when one of your project runs against flash size limits or is too time-consuming a compilation with "Release" settings will start the desaster: Project does not run, but cannot be debugged to find the cause.
    Some more explanations here
     
    So in your case, use
    volatile uint8 dmaFlag;
     
    Happy coding
    Bob

“脸谱”有笑脸吗？这是我经常拉！别人在其他论坛，谢谢指点一下。
我已经尝试了一些其他的事情：不保留TD我可以看到的RX和TX边去零和地址指针字节数（内存）的增值应。
因此看来，DMA操作发生的正确，但我还是没有打电话也没有得到ISR值投入目标内存。
鉴于我以前的“愚蠢的错误”，这可能是一些非常明显的但我必须承认，我现在看不到。
（顺便说一句，我应该解释一下，我所具有的功能最终将使用传递的参数。但是当我有问题的数据接收，我转而引用全局缓冲区直接。这似乎为Tx侧，也当我切换回使用参数工作。但是我已经离开了直接参考接收缓冲区在那里，我把事情整理出来。）
苏珊



     以下为原文
   Is there a 'smiley' for a 'facepalm'?! That is something I often pull others up for in other forums and thanks for pointing it out.
    I have tried a couple of other things: by not preserving the TD I can see that the byte count for both the rx and tx sides go to zero and the address pointers (to memory) increment as they should. 
    Therefore it would appear that the DMA operations are occurring correctly, but I'm still not getting the ISR called and stil not getting values put into the destination memory.
    Given my previous 'silly mistake' it is probably something very obvious but I must admit I can't see it right now.
    (By the way, I should explain that the function I have shown will ultimately use the passed parameters. However when I was having the issue with receiving the data, I switched over to referencing the global buffers directly. That seemed to work for the Tx side and also when I switched back to using the parameter. However I've left the direct reference to the receive buffer in there while I get things sorted out.)
    Susan

苏珊
从代码片段中看不到从DMA错误中接收不到的原因。此外，我错过了IDE的帮助，告诉我对变量的基本定义等等。
我甚至看不清您是否启用了全局中断。你能把你的整个项目发布出来，这样我们就可以看看你的所有设置了吗？要做到这一点，使用C造饰者和GT；文件-GT；创建工作区束（最小）并附加结果文件。鲍勃



     以下为原文
  Susan,
    I cannot see from your code-snippet what the cause of the not-receiving-from-DMA-error might be. Furthermore I miss the help of the IDE telling me the underlying definitions for variables etc just by hoovering with the mos over an identifier.
    I even cannot see whether you enabled global interrupts. Can you please post your complete project, 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
 

ISR的ISRSARTEXTEX发布了吗？
Cysi-ISrrPro（MyTunFunc）；//原型声明
然后
CysISR（MyTunFunc）/中断函数定义
{
/ /此处放置代码
}
程序初始化部分
iSrSARTEX（MyTunFunc）；//用我的处理器开始中断
CYSISR宏有一个查看“系统参考指南”下的帮助&文档；
问候，Dana。



     以下为原文
  Did you issue the isr_StartEX for the ISR ?
     
        
              
    CY_ISR_PROTO(MyIntFunc);      // Prototype declaration
    then
    CY_ISR(MyIntFunc)                         // Interrupt function definition
    {
    // Place code here
    }
     
    In  initialization part of the program
     
    isr_StartEX(MyIntFunc);               // Start Interrupt with my handler
     
    CY_ISR-macro have a look into the "System Reference Guide" under Help -> Documentation..
     
    Regards, Dana.

你好Dana，是我，正如我以上所说的（在所有的字的地方）我叫xxx_setpending函数和ISR被称为。我的理解是，这是一个为硬件软件的方式做同样的事情会在适当的登记待位设置等都表明，中断设置正确。如果我错了请纠正我。
你好鲍伯，我真的有一份项目但我真的需要去做我要求别人做我其他的论坛，是创建一个最小的项目出问题。现在有很多其他的代码是针对这一现状噪声和可能会挑剔别人的代码有点困难。当我晚上回到家，我将创建最小的项目后。
我打开全局中断（至少我现在-如前所述，我错过了这一步开始）但是我认为我可能没有表现出来，我需要的一切。
（编辑：几个小时后就看到另一篇文章中提到的TD的dma__td_termout_en选择点。我没有把这一点，可能的原因是没有触发中断。我会尝试这个选项，但今晚我错过了这个选项点完全的要求。这样的“清”线读取描述暗示，无论是脉冲清。然而，需要的是在cydmatdsetconfiguration提到但是我错过了。）
苏珊



     以下为原文
  Hi Dana - yes I have and, as I've said above (somewhere in all of the words) I have called the xxx_SetPending function and the ISR is called. My understanding is that this is a software way of doing the same thing as the hardware would do to set the pending bit in the appropriate register and so would show that the interrupt was correctly set up. Please correct me if I'm wrong.       

    Hi Bob - I actually have a copy of the project with me but I really need to do what I ask others to do i other forums and that is to create a minimal project that exhibits the problem. Right now there is a lot of other code that is noise with respect to this situation and is possibly going to make fault finding a bit harder in someone else’s code. When I get home tonight, I'll create the minimal project and post that.       

    I have turned on the global interrupts (at least I have now - as mentioned before I had missed out that step at the start) but I agree that I have probably not shown everything that I need to.       

    (Edit: Some hours later - just seen another post that mentions the DMA__TD_TERMOUT_EN option bit for the TD. I have NOT set this bit and that could be the reason why the interrupt was not triggered. I'll try this option tonight but I missed the requirement for this option bit entirely. The way the description for the 'nrq' line reads implies that the nrq is pulsed regardless. However the need is mentioned in the CyDmaTdSetConfiguration but I missed it before now.)
    Susan       

我附上了一个“极小”项目来展示这个问题。
正如我之前提到的，我现在已经解决了ISR不被调用的问题，剩下的就是RX侧的DMA不填充内存缓冲区。
您应该能够模拟我的外部硬件，通过简单地将MOSI连接到MISO引脚，您将返回什么是发送-这是“0x8A 0x14”。
“主”调用“DMA321UBSITIIT”，它设置DMA、中断控制，然后调用MAX32121StRealStEdBIT。该函数被设计为取寄存器ID（第一参数），并通过“写”位集（比特1）将其传递（左移3位）作为控制值；接着是要发送的位。（这max3421与'粘'位一些寄存器，但功能的工作是分离者必须知道哪些寄存器有粘位设置和设置/清除利益位这一点）。
一旦TxBuffer建立的max3421_setuptransfer函数被调用来执行操作DMA。在这种情况下我有功能设置为阻塞的测试程序。
谢谢你的支持和帮助。
苏珊
编辑：我忘了说，这是一个运行在cy8ckit-050完全补丁/更新IDE。
USB主机.CyWrk.SaveV03.Zip
502.7 K



     以下为原文
  I have attached a "minimal" project that exhibits the problem.
    As I mentioned before, I have now solved the problem with the ISR not being called; all that remains is the fact that the DMA on the Rx side does not fill the memory buffer.
    You should be able to simulate my external hardware by simply linking the MOSI to the MISO pins and you will get back what is sent - which is "0x8A 0x14".
    the 'main' calls "MAX3421USB_Init' which sets up the DMA, the Interrupt control and then calls MAX3421_SetRegisterBits. This function is designed to take the register ID (1st parameter) and pass it (shifted left by 3 bits) with the "write" bit set (bit 1) to be a control value; this is followed by the bits to be sent. (The MAX3421 has some registers with 'sticky' bits but the job of the function is to isolate the caller from having to know which registers have which sticky bits set and only set/clear the bits of interest at that point).
    Once the TxBuffer is set up, the MAX3421_SetupTransfer function is called to perform the operation via DMA. In this case I have the function set as a blocking routine for testing purposes.
    Thanks for the on-going support and assistance.
    Susan
    Edit: I forgot to mention that this is running on a CY8CKIT-050 with a fully patched/updated IDE.

•   USB Host.cywrk.Archive03.zip 502.7 K  
  
  

苏珊
我为CyPress制作了附加项目，在16位模式下与SPI显示了不同的问题。这是一个修改的CyPress示例项目，所以我深感遗憾的编码风格，这不是我的。
该项目将SPI数据（保持8位宽度！！！！）并通过DMA存储所有接收到的数据。
明显的差异在第101行。
cydmachenable（rxchannel，store_td_cfg_oncmplt）；在渠道建议保持（增量）地址值为下次使用。
因为在这个程序的DMA完成只有一次，我相信你会有建立TD重新启动传输。
鲍勃
SydMa.CyWrk.CaseV04.Zip
151.7 K



     以下为原文
  Susan,
    I made the attached project ready for Cypress to show a different issue with the SPI in 16-bit mode. This is a modified Cypress example project, so I deeply regret the coding style which is not mine at all.
    The project transfers data over SPI (Keep it to 8 bits width !!!) and stores received data all done by DMA.
    The obvious difference is in line 101
        CyDmaChEnable(rxChannel, STORE_TD_CFG_ONCMPLT);
where the channel is advised to keep (the incremented) address values for the next use.
    Since in this program the DMA completes only once, I presume you will have to set up the TD anew to restart a transmission.
     
    Bob

•   SPIDMA.cywrk.Archive04.zip 151.7 K  
  
  

你好，鲍伯，
在关系到你所指出的差异，其实我开始与设定的“1u”（这是thestore_td_cfg_oncmplt常数相同）和TDS肯定回到初始配置。
但是我改变了这个“0”（在我的样本项目）以便我能检查地址和计数的值被正确地更新（他们）。
其他不同的是，我使用“hi16宏观上的变量名，而你（和实例代码）一般采用cydev_sram_base。但是我没有发现差异时，我试着用这个符号。
苏珊



     以下为原文
  Hello Bob,
    In relation to the difference you have pointed out, I actually started with the setting of '1u' (which is the same as the STORE_TD_CFG_ONCMPLT constant) and the TDs were certainly returned to the initial configuration. 
    However I changed this to '0' (as in my sample project) so that I could check that the address and count values were being updated correctly (which they were).
    The other difference is that I'm using the 'HI16' macro on the variable name whereas you (and the example code) generally uses CYDEV_SRAM_BASE. However I found no difference when I tried using this symbol.
    Susan

我的代码和你的代码没有别的区别吗？我认为我的代码工作，而你的
CyDevsSrRMyBASE的使用仅与PSOC3兼容，其中HIS16（）将提供错误的值。
我建议使用我的工作实例，并逐步修改它，以满足您的需要，直到您打破它。
请随时通知我！
鲍勃



     以下为原文
  Well, isn't there another difference between my code and yours? I think my code works  and yours doesn't
    The use of CYDEV_SRAM_BASE has only to do with compatibilities to PSoC3 on which a Hi16() would deliver wrong values.
    I would suggest to use my working example and start modifying it step-by-step to suit your needs until you break it
    Please keep me informed!
     
    Bob

生活中有很多时候你都在想摇摇你的头！
我从头开始创建一个新的项目，把所有的组件（诚然，一些和不同的名字，如果原来的问题有一个更大的问题在这里！）然后把它编码起来……这一切都有效！
在这个阶段，这是所有的1个代码文件，但至少我有一个基本的成长。
我不知道什么是不同的（我甚至不得不回到旧的源文件来看到我在一些地方做几乎复制代码）所以我很抱歉，我无法登录故障或向他人提供任何警告或指导。
感谢鲍伯和其他人的帮助。
苏珊



     以下为原文
  There are times in life when you simply have to shake your head in wonder!
    I created a new project from scratch, placed all of the components (admittedly with different names for some - and if that turns out to be the problem then there are bigger issues here!) and coded it up.....and it all works!
    At this stage it is all in 1 code file but at least I have a base to grow from.
    I have no idea what is different (I even had to go back to the old source file to see what I'd done in a couple of places and virtually copied the code) so I'm sorry that I cannot either log a fault or provide any warnings or guidance to others.
    Thanks to Bob and others for your help.
    Susan

很高兴能帮上忙！
我所看到的问题（两倍，非常罕见）与销组件不稳定，成分显然不工作。当删除和重新创建时，一切都很好，正如预期的那样。也许你见过这样幽灵般的成分。
鲍勃



     以下为原文
  Glad to have been of some help!
    I have seen issues (two times, very rare) with the pin-component which were not reproducable, the component plainly did not work. When deleted and re-created all was fine, as expected. Maybe you met such a ghostly component.
     
    Bob