kinfkong Posted August 16, 2015 at 08:28 AM Posted August 16, 2015 at 08:28 AM Do you have a simulator for development, I want to test my program without a real device (Motion Detector Bricket). Thanks Quote
remotecontrol Posted August 16, 2015 at 09:52 AM Posted August 16, 2015 at 09:52 AM You might try this: https://github.com/PlayWithIt/TFStubserver (without user interface) https://github.com/PlayWithIt/TFStubViz (a simple user interface) Not all devices are supported yet ... (MotionDetector is supported (also in UI). There is a german description for it with an example: http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Stackemulator_%28stubserver%29 Quote
JavaLaurence Posted August 21, 2015 at 06:07 PM Posted August 21, 2015 at 06:07 PM @kinfkong: which language do you intend to work with? If Java, I may have some simulator-esque material which may be useful to you. Quote
theo Posted August 21, 2015 at 07:13 PM Posted August 21, 2015 at 07:13 PM Hi JavaLaurence, Hi kinfkong, some weeks ago I started to develop a simulator written in Java. It is primary meant for writing unit tests. As soon the dev has beta status I will publish it to github. @JavaLaurence I'm interested in your simulator-esque material, may be we could join the forces. Regards, Theo Quote
JavaLaurence Posted August 22, 2015 at 09:01 AM Posted August 22, 2015 at 09:01 AM @Theo: I'll describe what I've done.. First of all, I wanted all concrete TF classes for bricklets to become interfaces. Chiefly so that I could have multiple implementations (e.g. one bound to the real hardware, another bound to an emulated bricklet, a unit test mock, etc.) To obtain those interfaces, I wrote a code generator that parses the official TF JAR, and generates the interfaces, and a bunch of other things (like concrete classes wrapping the TF bricklet classes, and implementing the interfaces). I also wrote a few (not many) emulated bricklets. E.g. the LCD bricklet, various sensors. The end result is that I can write TF applications that are interface-based, and which can trivially switch execution between emulated and real hardware. By the way, it's kind of ironic that my approach is code generation-based, because Tinkerforge also uses a code generator as their foundation for language-neutral description of all their devices. Quote
theo Posted August 26, 2015 at 05:03 PM Posted August 26, 2015 at 05:03 PM @JavaLaurence, first of all sorry for the delay. I used a different approach, I think it's more like TFStubserver does it: I wrote a replacement for the brickd. It's a TCP Server which behaves like the original brickd but with data from emulated hardware devices. The emulator device classes are generated with a python generator like the other TF language bindings. The generator uses the device descriptions of the TF generator stack. I started the development by rewriting the TF java bindings generator. Writing over 65 device classes by hand is just to time consuming, boring and error-prone. But writing the generator is also a challenge ;-(. The core TCP server and helper classes are hand coded. The emulator is still not ready and has a lot of rough edges but I'm preparing a github project to provide some insights. Hopefully I can finish this before going on holidays for 2 weeks. Regards, Theo Quote
JavaLaurence Posted August 27, 2015 at 11:11 AM Posted August 27, 2015 at 11:11 AM So your generator is written in Python? If so, then I think we've got a language barrier blocking any merging of efforts.. Long live the Babel tower of languages (somewhere I read there's even a programming language that has to be typed in Arabic.. it clearly is never going to stop). Quote
theo Posted August 27, 2015 at 12:00 PM Posted August 27, 2015 at 12:00 PM Sorry for being unclear: the code generator is written in python, the emulator is written in java. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.