测试固件
接下来是一些其他 问题（但我认为我已经更好地完善了我的问题）。
我想在安装设备之前测试我的固件代码。
我意识到很多人编写代码、上传、测试等。但我真的想在上传之前编写和测试（主要是因为我想自动化许多场景）。
那么，这样做的最佳方法是什么。 如果我正在编写纯软件，例如根本没有固件，我会使用 cppunit （例如）。 但我对这个固件有点迷失。
有任何想法吗？
谢谢
This follows a couple of other questions (but I think I have refined my question better).
I want to test out my firmware code before I put on the device.
I realize that a lot of people write their code, upload, test, etc. But I really want to write and test before upload (mainly because I want to automate the many scenarios).
So, what is the best way of doing this. If I were writing pure software, as in, no firmware at all, I would go about it by using cppunit (for example). But I'm a little lost with this firmware thing.
Any ideas?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为标记为“正确”的答案根本不正确或完整。
对于固件代码，您确实必须进行两方面的严格测试。
使用模拟器完成初始测试。 这是理想的情况，但前提是您可以获得适合目标平台的良好模拟器。
在实际硬件上进行测试，但在测试床框架中进行。 也就是说，您在实际设备上进行测试，但使用附加硬件（即示波器、探头）和其他连接来允许对正在发生的情况进行正确的跟踪/调试。
对于固件，最困难的错误通常与时序相关，并且只有在实际硬件上时才会出现。 在最坏的情况下，实际的探测行为可能会改变时间，这样错误就不会出现——仅在“生产”版本中出现。 然后你就会真正享受到乐趣。
干杯，
-理查德
I don't think the answer marked as "correct" is at all correct or complete.
For firmware code, you really MUST conduct a two-pronged test to be rigorous.
Initial tests done using an emulator. This is ideal but presumes you can get a good emulator for the target platform.
Test on the actual hardware, but in a test bed framework. That is, you test on the actual device, but with additional hardware (i.e. oscilloscope, probes) and other connections to allow proper trace/debug on what's happening.
With firmware, often the most difficult bugs are timing related, and only show up once you are on the actual hardware. In the worst cases, the actual act of probing can alter timings such that the bugs won't appear - only in the "production" version. Then you have real fun.
Cheers,
-Richard
好吧，如果不知道您的代码是如何构建的，就很难说，但基本上您可以像其他软件一样在类/功能级别测试软件。 与设备交互的任何代码很可能都需要通过仿真进行测试。
Well it is hard to say without knowing how your code is architected, but basically you could test the software at the class/function level just like other software. Any code that interfaces with the device would most likely need to be tested via emmulation.
许多嵌入式设备都有可用的软件模拟器，但它确实取决于设备。
Many embedded devices have software simulators available, but it does depend on the device.
您应该尽可能多地对您的类进行单元测试，但最终，您必须运行它并在硬件中进行测试。
要在设备中测试固件，请编写一个调试接口，以便您可以使用终端仿真器，例如 procomm与您的设备交谈。 然后，当您编写功能时，有一种方法可以让您的调试接口调用类中的方法，这样您就可以在设备本身中专门测试您的代码。
完成后，您可以在终端模拟器中编写脚本来自动执行测试。
You should unit test your classes as much as you can, but at the end of the day, you must run it and test it in the hardware.
To test your firmware in a device write a debugging interface so that you can use a terminal emulator like procomm to talk to your device. Then, when you are writing a feature, have a way for your debugging interface to call methods in your class, that way you can specifically test your code in the device itself.
Once you have that done, you can write scripts in your terminal emulator to do the tests automatically.