Simulated Tinkerforge stack

[JavaLaurence]

I'm wondering what level of interest there is for a 100% software equivalent of the Tinkerforge Bricklets.

 

For example, using simulated components, you could write stack control logic using components you don't yet physically own. Or you could do exploratory "what if" development, without actually purchasing hardware.

 

The software-simulated components would have on-screen visualizations so that you can feed simulated sensors fake input values (e.g. with a slider), or see the output of non-input Bricklets (e.g. to see the output state of a Dual Relay).

 

 

[Equinox]

Great idea! I would really like to have such simulator!

[FabianB]

+10 

 

Great idea. This would be a great feature.

 

 

[rifmetroid]

Hey,

 

in the german forum is a thread about that topic. AuronX and The_Real_Black are writing a software like this. It's written in C# and not all is implemented yet, but it is a nice beginning.

 

http://www.tinkerunity.org/forum/index.php/topic,1574.msg10415.html#msg10415

[AuronX]

@rifmetroid/Fabian: Thanks for cross-posting that... I nearly didn't see it.

 

Indeed I lay some foundations for that in C#, my Thread also links to the corresponding github-page. I think my current design is quite okay... I really tried to reduce the amount of duplicated code as much as possible (especially for the Brick(let)-implementations).

 

@JavaLaurence: Have you already written some code that you like to share?

[JavaLaurence]

I have got quite a bit of code. But don't know if it's worth spending more time on.

 

Quick description of what I have:

 

First of all, I'm afraid I took an approach which is not language-neutral: it builds on the Java bindings.

 

Given this caveat, I reasoned that the Tinkerforge APIs need to be maintained as much as possible, so my system produces (using code generation) Java interfaces and non-public classes for all bricklets. Most Java programmers are aware of "programming against interfaces" (cfr Joshua Bloch's arguments in relation to his Collection Framework), so in my Tinkerforge world, I write stuff like

 

DistanceIR distanceIR = TinkerFactory.createDistanceIR(..);

 

instead of

 

BrickletDistanceIR distanceIR = new BrickletDistanceIR(..);

 

(DistanceIR is an interface, not a class).

 

TinkerFactory can produce real (bound to hardware) bricklets, or it can produce emulated (pure software) bricklets.

 

So far, I've mainly spent time on emulating the components that I needed to get my cellar water pump system implemented: DistanceIR, DualRelay, LCD20x4 (also have Temperature, Barometer, AmbientLight).

 

My cellar system polls all sensors every second, so I'm not using the callback mechanisms at all. So that's not currently supported in the emulated stuff.. (should be easy to add though).

 

If a large proportion of Tinkerforge customers are using Java, then I wouldn't mind spending a few more weekends plugging the most obvious holes in what I've done (and releasing the source).. that's why I asked in another thread whether anyone knows what kind of language split exists in TF land?

[AuronX]

In contrast my approach is on the TCP/IP-side, so it works with all languages. However it is written in C#.

 

On the other hand I did not currently implement hardware-backing, though that would be a nice option

 

My rough estimate would be that Java is one of the more popular languages here, only based on my feeling about forum posts.

[JavaLaurence]

Yep, I'm aware of the protocol barrier to approach simulation in a language-neutral way. It's definitely much more powerful.. I've got some holidays coming up, so maybe I'll look at the protocol and see if I can't hide my Java stuff behind a protocol facade.

 

Just out of interest, do you have the LCD emulated, and if so, what features do you support?

[AuronX]

Nope... I currently only have "random value" bricklets for the basic gettable devices (Temperature, Ambi, Barometer). I think I don't support threshold callbacks, but I don't remember surely (I started implementing that once...)...

 

There is currently no UI or anything involved, thatswhy I did not implement any "settable" device (like a DC Brick or an LCD).

 

What would you need from an emulated LCD? Output on the screen? Console or GUI? only responding via API?

 

Best regards

Jan

[The_Real_Black]

There is currently no UI or anything involved, thatswhy I did not implement any "settable" device (like a DC Brick or an LCD).

 

What would you need from an emulated LCD? Output on the screen? Console or GUI? only responding via API?

I want a LCD with API some like:

char[,] getScreen(); // C# get all chars from the screen

char[][] getScreen(); // C++, Java

char getScreen(int x, int y); // for loops

 

CallbackDisplayChanged; // raised if the screen was set by source

 

So i am able to create my own UI on the api

-> if the CallbackDisplayChanged is raised i update the elements on the UI -> and redraw them.

[JavaLaurence]

AuronX: for the LCD, I have a reasonably authentic-looking emulation, including the programmable characters and buttons.

 

Also, I beefed up the LCD API to be a bit more high-level than TF's (see attached interface definition).

 

For the LCD API, I want to beef it up even further to allow the display of a 20-sample bar chart (using the custom chars).

LCDCharacterDisplay.java

[AuronX]

Uh that looks darn pretty! very nice!