JavaLaurence Geschrieben June 19, 2013 at 17:08 Share Geschrieben June 19, 2013 at 17:08 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). Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Equinox Geschrieben June 20, 2013 at 14:06 Share Geschrieben June 20, 2013 at 14:06 Great idea! I would really like to have such simulator! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
FabianB Geschrieben June 20, 2013 at 14:35 Share Geschrieben June 20, 2013 at 14:35 +10 Great idea. This would be a great feature. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
rifmetroid Geschrieben June 20, 2013 at 15:44 Share Geschrieben June 20, 2013 at 15:44 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben June 20, 2013 at 17:59 Share Geschrieben June 20, 2013 at 17:59 @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? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
JavaLaurence Geschrieben June 20, 2013 at 20:09 Autor Share Geschrieben June 20, 2013 at 20:09 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? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben June 21, 2013 at 11:02 Share Geschrieben June 21, 2013 at 11:02 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
JavaLaurence Geschrieben June 21, 2013 at 18:30 Autor Share Geschrieben June 21, 2013 at 18:30 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? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben June 21, 2013 at 22:21 Share Geschrieben June 21, 2013 at 22:21 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
The_Real_Black Geschrieben June 22, 2013 at 11:47 Share Geschrieben June 22, 2013 at 11:47 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. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
JavaLaurence Geschrieben June 23, 2013 at 09:45 Autor Share Geschrieben June 23, 2013 at 09:45 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 Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben June 23, 2013 at 09:52 Share Geschrieben June 23, 2013 at 09:52 Uh that looks darn pretty! very nice! Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
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.