Simulator for development

[kinfkong]

Do you have a simulator for development,

I want to test my program without a real device (Motion Detector Bricket).

 

Thanks

[remotecontrol]

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

 

[JavaLaurence]

@kinfkong: which language do you intend to work with? If Java, I may have some simulator-esque material which may be useful to you.

[theo]

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

[JavaLaurence]

@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.

[theo]

@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

 

[JavaLaurence]

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).

[theo]

Sorry for being unclear: the code generator is written in python, the emulator is written in java.