UDB移位输出未获得正确的值

您好!
我不确定您的数据路径配置是什么，但是移位器配置应该是简单的。
请从8位移位器开始，示例配置如下所示：
如果您正在寻找24位，我建议您参考已经存在的SHIFT ReG组件。
请导入BShift 32的组件，它是移位寄存器组件的基本Verilog文件，您可以找到对于8、24、16和4位移位寄存器的示例引用。
当使用三个数据路径时，请使用中间数据链和最后一个数据路径（基于您的方向）的链配置，用于数据路径中的移位SELA、B配置。
数据路径输出是基于方向的寄存器配置中的最后一个/第一个触发器的输出，因此如果没有更多的移位，它将保持其值，SOSORG也是输出的延迟版本。



     以下为原文
  Hi
I'm not sure what your datapath configuration is but the shifter configuration should be simple.
 
Please start with a 8 bit shifter , an example configuration is as shown below :

 
If you are looking for 24 bit , I would suggest you to refer to the already existing Shift reg component.
Please import the B_ShiftReg_V2_30 component , which is the base verilog file for the shift register component, you can find the example reference for 32, 24,16 and 8 bit shift registers .
When using three datpaths ,please use chain config for middle datapath and the last datapath (based on your direction) for Shift SELA ,B configurations in datapath .
The datapath output is the output of the last/first flipflop in the register configuration based on the direction ,so it will retain its value if there is no more shifts ,also So_reg is a delayed version of the output .

我试图用在创建者V4.1中找到的UDB编辑器来配置它。一
移位输出是为24位寄存器配置的，而我是肯定的。
看到价值的变化，除了时钟上升沿以外的时间
UDB时钟。通过编辑器完成的状态机本身
工作完美，我看到它走过的步骤适当。（i
把状态位输出到引脚，这样我就可以监视状态机了。
工作正常。
我也改变了24位寄存器到一个8位寄存器，看看是否
会更好的工作。（注：所有这些都是左移位寄存器，
不正确的移位寄存器。即使宽度为8位或单个
UDB FIFO，我看到一个噪声信号作为移位输出。看起来几乎像
移位输出根本没有被驱动，所以它只是在内部浮动。
部分。
星期二我打算试着从左边变成右移。
转移看看是否有更好的输出。当使用UDB编辑器时，
用SHIFTTY输出作为数据输出填充数据路径的输出部分
转变的然后我使用SHIVETHY输出并发送信号到PIN
这是可以观察到的。是否有其他必要的步骤来“启用”
移位输出信号比将其添加到输出部分？我也有
对UDB时钟信号进行探测，所以我知道信号正在改变。
除了时钟的上升边缘以外的时间。



     以下为原文
  I'm trying to configure it using the UDB Editor found in Creator v4.1.  A
shift output is configured for the 24 bit register, and I am definitely
seeing that value change at times other than the rising clock edge of the
UDB clock.  The state machine itself which was done through the Editor
works perfectly, and I see it walking through the steps appropriately.  (I
outputted the state bits to pins, so I can monitor that the state machine
works properly).
 
I have also changed the 24 bit register to an 8 bit register to see if that
would work better.  (Note:  all of these are left shifting the register,
not right shifting the register).  Even with a width of 8 bits or a single
UDB FIFO, I see a noisy signal as the shift output.  It almost looks as if
the shift output is not being driven at all, so it is just floating within
the part.
 
On Tuesday I'm planning to try and change to a right shift from a left
shift to see if that gives a better output.  When using the UDB Editor, I
fill out the output section of the datapath with Shift_Output as the output
of the shift.  I then use Shift_Output and send that signal to a pin so
that it can be observed.  Are any other steps necessary to "enable" the
shift output signal than adding it to the output section?  I also have
probes on the UDB clock signal, so I know that the signal is changing at
times other than the rising edge of the clock.

你能附上你的项目吗？



     以下为原文
  Can you attach your project ?

我试图删除所有额外的东西，所以只有NeopixelLoo/Stand
机器包括在这个项目中。我已经包含了存档文件
应该拥有一切。
我还包括了我在逻辑分析仪上得到的一个跟踪。最后
信号（标记为Shift）是UDB中移位器的移位输出。
当我放大时，我可以看到它看起来不像一个锁存的信号，而是
似乎随机变化。跟踪来自发送2个字节（0xA5，0xFF）。
进入FIFO。查看Serut的输出（输出到Neopixel.）
数据线）它正在发送0x4A 0xFE。（最后一位在图像中被切断）
以下）
将数据从FIFO转移的唯一状态是状态010。如果
移位输出是一个注册信号，它不应该几乎改变为
我经常看到。
Gy2.CyWrk.CaseV01.Zip
3.8兆字节
逻辑分析仪
90.3 K



     以下为原文
  I tried to remove all the extra stuff so only the NeoPixel library/state
machine is included in this project.  I've included the archive file which
should have everything.
 
I've also included a trace that I get on the logic analyzer.  The last
signal (labeled as Shift) is the shift output from the shifter in the UDB.
When I zoom in, I can see that it doesn't look like a latched signal, but
appears to change randomly.  The trace is from sending 2 bytes (0xa5, 0xff)
into the FIFO.  Looking at the output of SerOut (output going to neopixel
data line) the it is sending 0x4a 0xfe.  (Last bit is cut off in image
below)
 
The only state that shifts the data from the FIFO is state 010.  If the
shift output is a registered signal, it should not be changing nearly as
frequently as I'm seeing.
 
 
 
 
 

•   Gen2.cywrk.Archive01.zip 3.8 MB  
  
  
•   LogicAnalyzer.png 90.3 K
  
  

忘了提到上面的项目只是使用一个8位FIFO，而不是试图把3个UDB链接在一起，形成一个24位FIFO。如果我不能得到一个单独的UDB来正确地移出数据，就没有理由尝试将多个UDB链接在一起。一旦8位工作，我将移动到24位FIFO，这将减少处理器需要处理的中断量。



     以下为原文
  Forgot to mention that the above project is simply using an 8 bit FIFO and not trying to chain 3 UDB together to form a 24 bit FIFO.  If I can't get a single UDB to shift out data properly, there is little reason to try and chain multiple UDBs together.  Once the 8 bit works, I will move back to the 24 bit FIFO which will reduce the amount of interrupts the processor will need to handle.

我现在开始工作了。我发现了几个问题。
首先，我用SHIFTTY输出的引脚是由其他信号驱动的。我最初把它放在P2〔4〕上，它显示了逻辑分析仪跟踪中所看到的争用。最后我把它移到Pin P1（0），信号开始变得更有意义了。这可能只是我使用的先锋板有其他的信号，但我懒得看图表。使用UDB编辑器，似乎当F0 FIFO移动到A0时，它总是移位和填充移位输出位，而不管是否HIF。T在该指令中设置。这可能是UDB编辑器中的一个bug，但如果UDB数据路径用于创建串行协议，则效果良好。如果UDB DATAPATH被用作FIFO来改变PWM的宽度，这将导致问题。要真正了解这一点，需要进行更多的调查，但它对我来说足够好。移位输出被进位输出ALU操作覆盖。我错误地相信从移位器输出的移位和从ALU输出的输出是单独的比特，并且在单独的时间更新。似乎它们在硬件中共享相同的寄存器，或者运行ALU操作，不管移位是否被配置，重写移位输出的最后值。如果稍后需要移位输出值，则必须将其保存在单独的变量中。UDB编辑器在尝试配置指令时会遇到无限的意外异常。不知道我是如何把创建者V4.1变成这个状态的，但是它找不到出路。在按下OK之后对指令进行的每一次更改都会导致意外的异常，并且新的配置未被保存。我想出的笨拙的解决方案是删除整个数据路径并从头开始重新创建。
在我把所有东西打包后，我将发布完整的NeopixEL库。
！！！！警告：技术术语和计时即将来临。！！！！
基本上，每一个NIPOXIL都有一个24位的值来设置颜色值，而一个中断/状态位用来表示FIFO在中点。当FIFO变空时，它假设链完成，并且适当地通过保持线路低来结束循环。它是由更高级别的固件来保证在周期结束时50秒的死区时间。（我倾向于使用更长的计时器来开始处理每20毫秒）。定时器的基频为2.4MHz，所以每1.25比特传送一个比特，所以每24个字节就有24×1.25个US＝30个。如果每1毫秒更新一次，（1000个US - 50个）/30个US＝31个新Popixels.如果每10毫秒更新一次，（10000个US - 50个US）/30个US＝331个Neopixels等。因为使用FIFO的中点，一个中断应该在大约60个美国来请求FIFO被重新填充。如果使用RGBW LED，每个NIPOXIL的计时将是40美圆。
当我花时间完成并发布代码时，我将把这个帖子标记为正确答案。



     以下为原文
  I have it working now.  There were a couple of issues that I found.

• First, the pin that I was using for shift_output is being driven internally by some other signal.  I originally put it on P2[4], and that showed the contention as seen in the logic analyzer trace.  I ended up moving it to pin P1[0] and the signal started making a lot more sense.  This could simply be that the pioneer board that I'm using has something else hanging off that signal, but I've been too lazy to look at the schematics.
  
• Using the UDB editor, it seems that when F0 FIFO is moved to A0, it always shifts and fills out the shift output bit regardless of whether the shift is set in that instruction.    This is probably a bug in the UDB editor but works well if the UDB datapath is being used to create a serial protocol.  If the UDB datapath is used as a FIFO to change the width of a PWM, this would cause problems.  It would take more investigation to really understand this, but it works good enough for me.
  
• Shift output is overwritten by a carry output ALU operation.  I incorrectly believed that the shift output from the shifter and carry output from the ALU were separate bits and updated at separate times.  It seems like they share the same register somewhere in the hardware or running an ALU operation overwrites the last value of the shift output regardless of if a shift is configured.  If the shift output value is needed later, it must be saved in a separate variable.
  
• UDB editor gets into endless unexpected exception when trying to configure instructions.  Don't know how I get Creator v4.1 into this state, but it couldn't find its way out.  Every change to an instruction after pressing OK resulted in an unexpected exception and the new configuration not being saved.  The kludgy fix that I came up with was to delete the whole datapath and recreate it from scratch.
  

 
After I wrap everything up, I will post the completed NeoPixel library.
 
!!! Warning:  Technical Jargon and timings coming up.  !!!
 
Basically a 24 bit value is handed in for each Neopixel to set the color value, and an interrupt/status bit is used to say when the FIFO is at the midpoint.  When the FIFO becomes empty, it assumes the chain is completed, and properly ends the cycle by keeping the line low.  It is up to higher level firmware to guarantee the 50 us dead time at the end of the cycle.  (I tend to use a longer timer to start processing every 20 ms).  The base frequency of the timer is 2.4MHz so each bit is transferred every 1.25 us, so 24 * 1.25 us = 30 us per Neopixel.  If updating every 1 ms, (1000 us - 50 us)/30 us = 31 Neopixels.  If updating every 10 ms, (10000 us - 50 us)/30 us = 331 Neopixels, etc.  Since using the mid point of the FIFO, an interrupt should come in approximately every 60 us to request that the FIFO be refilled.  If RGBW LEDs are used, the timings per Neopixel will be 40 us.
 
I will mark this post as the correct answer when I take the time to finish it up and post the code.

非常有趣的方法来驱动Neopixels，期待检查你最终使用的UDBS。



     以下为原文
  Very interesting approach to drive the NeoPixels, looking forward to check your final use of the UDBs.

通过示例项目更新/清理库。这是我可以想象的PSoC4上的最小CPU利用率。该示例使用轮询来填充FIFO或中断，这取决于代码中的单个定义。使用中断是更有效的，因为在处理过程中没有轮询发生。到FIFO中的DMA会使这更好，但是唉，PSoC4没有任何DMAS。（几乎让我想购买一个PSoC5来添加DMA）。
示例项目以每500毫秒更新的旋转颜色方案驱动8个Neopixels。在实际生活中，像素更新功能将简单地静态分配RAM的像素缓冲器，并且只是连续使用该列表来更新Neopixels。然后，主程序将更新RAM像素缓冲器中的各个像素，因为它们希望改变它们的颜色。没有比这更简单的了。
NeopixelEngulp.CyWrk.CaseVo.01.Zip
723.6 K



     以下为原文
  Updated/cleaned up the library with an example project.  This is the minimal CPU utilization on the PSoC4 that I can imagine.  The example uses either polling to fill the FIFO or interrupts depending on a single define in the code.  Using interrupts is more efficient since no polling when processing isn't occurring.  A DMA into the FIFO would make this even better, but alas, the PSoC4 doesn't haven any DMAs.  (Almost makes me want to purchase a PSoC5 just to add the DMA.
 
The example project drives 8 NeoPixels with a rotating color scheme with an update every 500 ms.  In real life, the pixel update function would simply statically allocate the RAM for a pixel buffer, and just continuously use that list to update the NeoPixels.  The main program would then update the individual pixels in the RAM pixel buffer as it wanted their colors to change.  Doesn't get much simpler than that.

•   NeoPixelExample.cywrk.Archive01.zip 723.6 K  
  
  

有PSOC 4M和4L族的DMA，但DMA配置不同于5LP DMA。



     以下为原文
  There's PSoC 4M and 4L families with DMA, but the DMA configuration is different from the 5LP DMA.

我使用的是CY8CKIT 049×42xx，它没有任何DMAS可用。我一直告诉人们，在过去3年或4年里，我为运行的开源项目购买这些板。虽然它们没有DMA，但是它们对于项目中如何使用来说是绰绰有余的。



     以下为原文
  I'm using the Cy8ckit‑049‑42xx which does not have any DMAs available.  I've been telling people to buy those boards for the last 3 or 4 years for the open source project I run.  While they don't have a DMA, they are more than sufficient for how they are used in the project.

有机会调试您的项目（设置断点，检查或设置变量）和获得DMA资源是值得的钱CY8CKIT-043 PSoC M原型工具包的成本。
鲍勃



     以下为原文
  Having the opportunity to debug your project (setting breakpoins, inspecting or setting variables) and getting DMA resources is worth the money a CY8CKIT-043 PSoC M prototyping kit costs.
 
Bob

我实际上使用先锋CycKIT-042工具箱进行调试。（是四年前唯一可用的调试工具包）。在我看来，新的“棒”套装更便宜，甚至更好。为了调试目的，我今天肯定会这样做。CY8CKIT 049×42xx用于最终构建，因为价格和大小。我使用大约四的每一个弹球机来驱动电子设备，并且使它们很小，允许他们生活在游戏场下面并被分配以最小化布线。他们为我工作得很好。谢谢你的建议。



     以下为原文
  I actually use the Pioneer CYCKIT-042 kit to debug.  (Was the only available debugging kit back four years ago).  The new "stick" kits are cheaper and even nicer in my opinion.  I would certainly go that way today for debug purposes.  The Cy8ckit‑049‑42xx is used for the final build because of price and size.  I use approximately four of those per pinball machine to drive the electronics, and having them so small allows them to live under the playfield and be distributed to minimize wiring.  They work well for me.  Thanks for the suggestions.