Jump to content

Simulated Tinkerforge stack


Recommended Posts

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



Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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





Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...