设计实时采集和“控制”的系统架构；
需求简要描述
（这里有很多好的答案，感谢大家，如果我能实现这个飞行，我会更新）。
探测器沿着轨道运行，测量几个实时不同的物理参数（确定性），作为曲线距离的函数。 在此过程中，用户可以单击按钮来“标记”航路点，然后使用 GUI 输入每个航路点的详细信息（以人工时间，但在数据采集继续的同时）。
此后，系统对获取的数据执行一系列计算/过滤/修改，同时考虑为每个航路点输入的约束。 该过程的输出是一系列校正，也是曲线距离的函数。
该过程的第三部分涉及再次沿着轨道运行，但这一次将校正写入物理系统，以校正轨道（仍然是曲线距离的函数）。
我目前对您的意见/评论/警告的想法
我想确定的是我是否可以使用 PC + FPGA 来完成此操作。 FPGA 负责“数据采集”，我会在 PC 上使用 C# 从缓冲区读取数据。 航路点信息可以通过 WPF/Winforms 应用程序输入，并存储在数据库/平面文件/任何待处理的“处理”中。
对于处理，我将使用 F#。
FPGA 将用于将信息“写”回物理机。
我目前可以预见的一个问题是处理算法是否需要采样频率，这使得缓冲的数据量太大。 这意味着将一些处理任务转移到 FPGA - 至少是不需要用户输入的部分。 不幸的是，唯一的预处理算法是卡尔曼滤波器，根据我的谷歌搜索，很难用 FPGA 实现。
如果您愿意提供任何反馈，我将不胜感激。
更新（随时在此处添加额外信息）
在卡尔曼滤波器的入口处，我们每 1 毫秒查看一次。 但在卡尔曼滤波器的另一侧，我们将每 1m 采样一次，以我们所说的速度约为每秒 2 次。
所以我想更精确的问题是：
在 FPGA 上实现 卡尔曼滤波器 - 似乎 那个 这是可能的，但是我对这两个主题都没有足够的了解，无法弄清楚它有多大可能。
我也不确定卡尔曼的 FPGA 实现是否能够每 1ms 循环一次 - 尽管我认为这应该没有问题。
如果我没理解错的话，FPGA 没有大量内存。 对于该过程的第三部分，我将发送一个（大约）4 x 400 双精度数组用作查找表，这可行吗？
此外，两个进程之间的交换（读/写数据）是否意味着每次都需要重新编程 FPGA，或者是否可以指示它在两个进程之间进行切换？ （也许可以并行运行并忽略其中一个）。
另一个 选项 我看到的是使用 Avalda FPGA 开发人员，我想我很快就会尝试。
Brief description of requirements
(Lots of good answers here, thanks to all, I'll update if I ever get this flying).
A detector runs along a track, measuring several different physical parameters in real-time (determinist), as a function of curvilinear distance. The user can click on a button to 'mark' waypoints during this process, then uses the GUI to enter the details for each waypoint (in human-time, but while the data acquisition continues).
Following this, the system performs a series of calculations/filters/modifications on the acquired data, taking into account the constraints entered for each waypoint. The output of this process is a series of corrections, also as a function of curvilinear distance.
The third part of the process involves running along the track again, but this time writing the corrections to a physical system which corrects the track (still as a function of curvilinear distance).
My current idea for your input/comments/warnings
What I want to determine is if I can do this with a PC + FPGA. The FPGA would do the 'data acquisition', I would use C# on the PC to read the data from a buffer. The waypoint information could be entered via a WPF/Winforms application, and stocked in a database/flatfile/anything pending 'processing'.
For the processing, I would use F#.
The the FPGA would be used for 'writing' the information back to the physical machine.
The one problem that I can foresee currently is if processing algorithms require a sampling frequency which makes the quantity of data to buffer too big. This would imply offloading some of the processing to the FPGA - at least the bits that don't require user input. Unfortunately, the only pre-processing algorithm is a Kalman filter, which is difficult to implement with an FPGA, from what I have googled.
I'd be very greatful for any feedback you care to give.
UPDATES (extra info added here as and when)
At the entrance to the Kalman filter we're looking at once every 1ms. But on the other side of the Kalman filter, we would be sampling every 1m, which at the speeds we're talking about would be about 2 a second.
So I guess more precise questions would be:
implementing a Kalman filter on an FPGA - seems that it's possible, but I don't understand enough about either subject to be able to work out just HOW possible it is.
I'm also not sure whether an FPGA implementation of a Kalman will be able to cycle every 1ms - though I imagine that it should be no problem.
If I've understood correctly, FPGAs don't have hod-loads of memory. For the third part of the process, where I would be sending a (approximately) 4 x 400 array of doubles to use as a lookup table, is this feasible?
Also, would swapping between the two processes (reading/writing data) imply re-programming the FPGA each time, or could it be instructed to switch between the two? (Maybe possible just to run both in parallel and ignore one or the other).
Another option I've seen is compiling F# to VHDL using Avalda FPGA Developer, I'll be trying that soon, I think.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您没有提及您的目标、客户、预算、可靠性或截止日期，因此这很难回答，但是......
忘记 FPGA。 简化您的设计、开发环境和界面，除非您知道其他解决方案会超出您的实时要求。
如果你有预算，我会首先看一下LabView。
http://www.ni.com/labview/
http://www.ni.com/dataacquisition/
LabView 将在一台 PC 上为您提供数据采集系统和用户 GUI。 根据我的经验，开发人员不会选择 LabView，因为它感觉不像一个“真正的”编程环境，但我绝对会推荐它来解决您所描述的问题。
如果您决定使用编译语言，那么我会将实时数据采集组件隔离到具有 RTOS 的嵌入式目标，并且最好是利用 MMU 进行调度和线程隔离并允许您用 C 编写的组件。当你得到一个真正的 RTOS 时，你应该能够真正地调度需要运行的进程，并且还能够在需要时调试它们！ 通过定义的接口使这个偏离目标的系统尽可能简单。 使其足以获取您需要的数据。
然后，我将使用通用接口文件将接口实现回 PC GUI 以进行维护。 使用标准接口将数据传输到 PC，例如 USB2 或以太网。 FTDI 芯片非常适合这个东西。
You don't mention your goals, customers, budget, reliability or deadlines, so this is hard to answer, but...
Forget the FPGA. Simplify your design, development environment and interfaces unless you know you are going to blow your real-time requirements with another solution.
If you have the budget, I'd first take look at LabView.
http://www.ni.com/labview/
http://www.ni.com/dataacquisition/
LabView would give you the data acquisition system and user GUI all on a single PC. In my experience, developers don't choose LabView because it doesn't feel like a 'real' programming environment, but I'd definitely recommend it for the problem you described.
If you are determined to use compiled languages, then I'd isolate the real time data acquisition component to an embedded target with an RTOS, and preferably one that takes advantage of the MMU for scheduling and thread isolation and lets you write in C. If you get a real RTOS, you should be able to realiably schedule the processes that need to run, and also be able to debug them if need be! Keep this off-target system as simple as possible with defined interfaces. Make it do just enough to get the data you need.
I'd then implement the interfaces back to the PC GUI using a common interface file for maintenance. Use standard interfaces for data transfer to the PC, something like USB2 or Ethernet. The FTDI chips are great for this stuff.
由于您沿着轨道移动，我必须假设采样频率不超过 10 kHz。 您可以轻松地将数据以该速率卸载到 PC，甚至是 12 Mb USB（全速）。
对于数学数据的认真处理，Matlab 是最佳选择。 但由于我没有听说过 F#，所以无法发表评论。
4 x 400 双打没问题。 即使是低端 FPGA 也有数百 kb 的内存。
您无需更改图像即可在读取和写入之间切换。 FPGA 中一直都是这样做的。
Since you are moving along a track, I have to assume the sampling frequency isn't more than 10 kHz. You can offload the data to PC at that rate easily, even 12 Mb USB (full-speed).
For serious processing of math data, Matlab is the way to go. But since I haven't heard of F#, I can't comment.
4 x 400 doubles is no problem. Even low-end FPGAs have 100's of kb of memory.
You don't have to change images to swap between reading and writing. That is done all the time in FPGAs.
这是一个建议。
抛弃 FPGA 概念。
获取 TI 的 DSP 评估板
选择一个具有足够千兆浮点运算能力的处理器，让您满意。
足够的 RAM 来存储您的工作集。
用 C 语言对其进行编程。TI 提供了一个小型 RT 内核。
它通过串行端口或以太网等方式与 PC 进行通信。
它通过握手发送 PC 熟数据，这样数据就不会丢失。
当 PC 处于高级时刻时，DPS 中有足够的内存来存储您的数据。
DSP 没有性能问题。
实时位通过 RAM 的 MP 实现实时。
处理速度很快，而且 GUI 对时间要求不严格。
Here is a suggestion.
Dump the FPGA concept.
Get a DSP evaluation board from TI
Pick one with enough gigaflops to make you happy.
Enough RAM to store your working set.
Program it in C. TI supply a small RT kernel.
It talks to the PC over, say a serial port or ethernet, whatever.
It sends the PC cooked data with a handshake so the data doesn't get lost.
There is enough ram in the DPS to store your data while the PC has senior moments.
No performance problems with the DSP.
Realtime bit does the realtime, with MP's of ram.
Processing is fast, and the GUI is not time-critical.
您与 PC 的连接是什么？ 如果是基于网络的连接，.Net 将是一个很好的选择，因为您可以使用流来处理数据输入。
关于 F# 或任何涉及大型数据集的函数式编程语言，我对您的唯一警告是内存使用情况。 它们很棒并且在数学上是可证明的，但是当您在多次递归中遇到堆栈溢出异常时，这意味着您的程序将无法工作并且您会浪费时间和精力。
如果您需要开发 GUI，C# 会很棒，winforms 和 GDI+ 应该让您无需付出巨大的努力即可获得可用的东西。
请给我们提供一些有关数据速率和连接的更多信息，也许我们可以提供更多帮助？
What is your connection to the PC? .Net will be a good fit if it is a network based connection, as you can use streams to deal with the data input.
My only warning to you regarding F# or any functional programming language involving large data sets is memory usage. They are wonderful and mathematically provable but when you are getting a stack overflow exception from to many recursions it means that your program won't work and you lose time and effort.
C# will be great if you need to develop a GUI, winforms and GDI+ should get you to something usable without a monumental effort.
Give us some more information regarding data rates and connection and maybe we can offer some more help?
Microsoft Robotics Studio 中可能有一些有用的内容：尤其是链接文本对于实时方面。 CCR - 并发协调运行时已经对此进行了很多思考，并且模拟工具可能会帮助您构建有助于分析的模型。
There might be something useful in the Microsoft Robotics Studio: link text especially for the real time aspect. The CCR - Concurrency Coordination Runtime has a lot of this thought out already and the simulation tools might help you build a model that would help your analysis.
在我看来，你可以离线完成所有处理。 如果是这种情况，那么离线就是最佳选择。 换句话说，该过程分为 3 个步骤：
数据采集
如果您无法使用标准接口收集数据，那么您可能必须使用自定义接口。 如果不了解更多关于接口的信息，很难说您是否应该使用 FPGA。 构建自定义接口的成本很高，因此您应该进行权衡研究来选择方法。 无论如何，如果这是基于 FPGA 的，那么请保持 FPGA 简单并将其用于原始数据采集。 利用当前的硬盘技术，您可以轻松存储 100 GB 的数据以进行后处理，因此将原始数据存储在磁盘驱动器上。 如果没有必要，您根本不可能在 FPGA 中实现一维卡尔曼滤波器。
数据分析
一旦您将数据存储在硬盘上，您就有很多数据分析选项。 如果您已经了解 F#，请使用 F#。 Python 和 Matlab 都有大量可用的数据分析库。
与必须实时进行所有处理的解决方案相比，这种方法还使测试数据分析软件变得更加容易。 如果结果看起来不正确，您可以轻松地重新运行分析，而无需再次收集数据。
物理系统校正
获取数据分析结果并沿着轨道运行探测器，再次通过接口卡为其提供适当的输入。
Sounds to me like you can do all the processing off line. If this is the case, then offline is the way to go. In other words divide the process into 3 steps:
Data Acquisition
If you can't collect the data using a standard interface, then you probably have to go with a custom interface. Hard to say if you should be using an FPGA without knowing more about your interface. Building custom interfaces is expensive, so you should do a tradeoff study to select the approach. Anyway, if this is FPGA based then keep the FPGA simple and use it for raw data acquisition. With current hard drive technology you can easily store 100's of Gigabytes of data for post-processing, so store the raw data on a disk drive. There's no way you want to be implementing even a 1 dimensional Kalman filter in an FPGA if you don't have to.
Data Analysis
Once you've got the data on a hard drive, then you have lots of options for data analysis. If you already know F#, then go with F#. Python and Matlab both have lots of data analysis libraries available.
This approach also makes it much easier to test your data analysis software than a solution where you have to do all the processing in real time. If the results don't seem right, you can easily rerun the analysis without having to go and collect the data again.
Physical System Corrections
Take the results of the data analysis and run the detector along the track again feeding it the appropriate inputs through the interface card.
我做过很多嵌入式工程，包括混合系统，例如您所描述的系统。 按照您需要处理的数据速率和大小，我怀疑您是否需要 FPGA……只需找到一个现成的数据采集系统插入您的 PC 即可。
我认为您将遇到的最大问题更多地与硬件 API 的语言绑定相关。 过去，我不得不用 C 和汇编语言（甚至一些 Forth）开发很多软件，因为这是从硬件获取数据的最简单方法。
I've done a lot of embedded engineering including hybrid systems such as the one you've described. At the data rates and sizes you need to process, I doubt that you need an FPGA ... simply find an off the shelf data acquisition system to plug into your PC.
I think the biggest issue you're going to run into is more related to language bindings for your hardware APIs. In the past, I've had to develop a lot of my software in C and assembly (and even some Forth) simply because that was the easiest way to get the data from the hardware.