@ dapug - We’ve been waiting for you! ;D
1 Like
This is great news! Very exciting! Of course the obvious question, if no-one has asked already… WHEN? Likely ballpark timescale for a release of the HAT @ gus ?
(Always impressed by how GHI and Microsoft have made hardware easy for us software guys, great job!)
1 Like
No dates just yet.
The only release we’ve (Microsoft) committed to for Windows for IoT for small devices is “this summer”.
However, it’s quite possible earlier interim bits will be released. There’s some risk to offering a beta HAT along side earlier bits (something may change in Windows rendering that revision of the HAT useless later), but if folks want to play along, I imagine GHI will accommodate, assuming anyone who purchased it understood that.
Pete
1 Like
This is awesome - thanks GHI & Microsoft ! And by the way : this is why I feel so home on planet Windows / Microsoft. Or to say it with other words: this is one great example of an “innovative & taking care of the existing things & residents” Ecosystem, designed & found by one, used & driven & pushed forward by many … and what’s really remarkable : it’s useful and reliable for (very) small companies.
Why? Because it’s predictable : if something that could be build on “existing things” that might be useful in the future and “this one” is logic & has a market, one could bet on it (at least at quite high probability) that it will happen to come to life … that it will be done. And so does Gadgeteer @ Rapsberry Pi 2 @ Windows IoT!
One does not need a “magic crystal ball” to see what might come up in the future, that will enhance one business - THANKS for the continuation and improvement of Gadgeteer and bringing it to the Windows 10 IoT space !
But what about discussing a “real life project”, what might even affect some of the design & driver implementation decisions of the Gadgeteer HAT?
@ Petet Brown : I am really looking forward for your build session and see your “raspPi rollin’ on Windows 10 IoT” and rocking on the next Version of “your” MIDI Library (?) … dancing to a song played by a MIDI Synth - feeded by a MIDI file? By the Way : I am already have the way on a MIDI App, currently on Windows 8.1, but I still see the preview namespace (WindowsPreview.Devices.Midi) in there … that’s just a step aside, but if you could post a link to a forum, where one could participate & discuss “things around MIDI” @ Windows 8.1/10 I really would appreciate that. Although I guess it will transform to the namespace Windows.Devices.Midi in Windows 10 and get it’s final bits there (as I saw some video from WinHEC regarding I2C Bus).
So what I would like to think & discuss about is a project that has to do with the transition to that what was named “Industry 4.0”. One challenge there is to build a bridge (or call it a gateway - something like Steve Teixeira mentioned in his session Shows | Microsoft Learn) to the “present time - industrial device”, which talk a various kinds of “bus languages”.
How to get the “existing / old device” talking and running together with new devive of the age of industry 4.0.
The reason for that : I got to do this in my “first half business identity/job” (which feeds my life), so this is a “real world” problem and no theoretical thing ;-). [In my second business life I build up an app forge / little software company that will develop App-Systems around mobile device that are connected to the cloud and local servers … currently not yet in the market]
To talk about a concrete example: Modbus RTU over RS-485 … for which a Gadgeteer Module already exists (https://www.ghielectronics.com/catalog/product/479) and I got one on my side.
The real challenge is Modbus RTU and its “time based” specification : the end of a Modbus RTU frame is defined by “hearing” 3.5 bits nothing on the line (sorry, I am no native English speaker nor writer, but I hope you know what I mean ;-). A second “time based” specification - told from the perspective of a Modbus RTU device that’s currently reading a Modbus RTU from the “serial buffer” : if for 1.5 bits there are no “informations on the line”, the transmission or frame has to be seen as “broken” and has to be rejected.
This “bit time” (also depended on the BAUD rate) dependency makes it impossible to use .NET MF (at least if I did not miss anything - I got a rule inside my head that says : you can count on .NET MF, but don’t bet on anything that has to happen in 5ms) AND it will cause trouble in the Windows 10 universal app platform as well.
BUT there is a solution and that is : universal driver @ Windows 10 … so with Windows 10 not only we got 1 universal app platform, we also got 1 universal driver platform as well !!! And this guys is really great … 1 driver, even in kernel mode, that can be used in all flavors of Windows 10 : from the smallest to the biggest and the holographic “amazing kind of thing”.
So projecting this to the Gadgeteer HAT (that is already on the top of my shopping list !) : I think this is something that GHI should bear in mind. I am no electronic or micro-controller geek-guy (that’s why I love .NET MF and Gadgeeter), but as I read the specification of the Raspberry Pi 2 and its Pin-Header and see the amount of sockets on the Gadgeteer HAT, the chip in the middle (or another one on hidden/bottom side) seems to do some more work than only dispatching the lines (I/O’s) from the Raspberry Pi 2 Pin’s to the Gadgeteer sockets.
So to say respectively guess - this chip in the middle (or underneath) “is the real magic” and for this chip GHI will develop a “kernel driver” as “universal driver” for Windows 10. Please correct me if I am wrong.
And taking this the next step towards a solution for Modbus RTU over RS-485 @ Windows 10 IoT challenge : as I assume that a “universal drive” in kernel mode is needed for get Modbus RTU going - because only in kernel mode I can prevent the OS from talking me / my code off the processor, because I have to measure this tiny bit-times !!! - the great question is : how can this be made possible.
Even if GHI would make the “universal driver” for the “magic HAT chip” open source, I assume that this is no easy stuff and it would be a “much to huge” thing & effort (the wrong way to the solution) if one has to substitute or at least take into account all the other stuff that the “HAT chip” has to manage (the other sockets and what ever he has also has to do).
The second and maybe easier question : as RS-485 has only 1 data-line (in comparison to RS-232, which has 1 Rx and 1 Tx) - how does (and will in the future) this module switch the dataline so that the internal serial buffers read and write only on the right time (when the data-line is in their mode)?
That’s from me - looking forward for your comments … thanks
gebco
3 Likes
@ gebco - Dude, I have to schedule time to read your post!
3 Likes
You might need to change that rule as Colin Miller mentioned that .NetMF in the future might use AOT compilation, so the processor might be able to handle your task and wonder what you want to do with the other 4.95 ms.
@ Mr. John Smith : but maybe it’s worth it ;-). Quick & dirty is easy but writing “no nonsense” for some more line of text is more difficult … which is also true for writing code 
And by the way : I forced myself to write it the short way … and as you got me on the keys again I take the chance to fulfill my “misson - no more quick & dirty” ;-).
If one would go the quick & dirty way as implementing a Modbus RTU over RS-485 device by saying : “5 seconds are longer than 3.5 bits on the slowest BAUD rate known in the universe” (maybe it’s different in the matrix when you got the slow-mode enhanced feature pack … “so what the hell should I measure, I just wait long enough and read all the input buffer at once and I am good to go”.
Maybe, but only one way.
The real problem is “the other side” which in industrial automation scenarios are often SPS, like the S7 von Siemens (but there a lot of other vendors, too). These system (SPS or other Micro-Controller based Modbus RTU Slaves or Masters) have a more rigid (precise) Modbus RTU implementation on board and they pay attention for every “bit time”.
So you run into the same problem when you send a Modbus RTU frame to the “other machine” and if your OS or the .NET MF garbage collector pulls you off the processor meanwhile you are sending the frame, the other one will throw away your corrupted frame (Modbus request or response, depends which Modbus role you are implementing : slave versus master), because your bytes did not travel the line in continuous stream of bit-time, but was interrupted for some “bits of time” (… if it’s more than 1.5 bit time = game over ;-).
cheers
gebco
@ gebco - Sound like you should switch to CAN bus.
@ Duke Nukem: this is a great hint, thanks! It’s some time ago that I did my last .NET MF codings and following the news around NETMF… so gave me a helpful flash-light / spot into “things that are on the way”.
After some digging around the Internet I think I found the post you are referring to : it was a comment underneath the “NETMF 4.3 QFE2 released” Blog-Post of Colin Miller from 28.01.2015 (http://blogs.msdn.com/b/netmfteam/archive/2015/01/28/netmf-4-3-qfe2-released.aspx). Or do you got some “even more fresh news”.
But even this one is really great - having ahead of time compilation is really cool & opens up new possibilities.
And you are right - If the AOT compiler will produce code that runs as fast as “c compiled” code on the processor, one challenge should be solved … then measuring the “bit times” (BAUD rate depended) for a Modbus RTU device communication should be accurate enough with .Net MF.
So that would be a pure NETMF Solution which is great and I got a scenario in my mind where this would perfectly matches.
Or in other words: although I am really happy about Windows 10 IoT and the opportunities that arise from a “full fledge & modern OS” on a small device, e.g. Cloud connectivity built-in when the board uses a Qualcomm Snapdragon … but also the possibilities empowering Windows store app developers with a learning curve that’s “so small” to build software for industrial devices, is amazing
… I also see a broad range of uses for the NETMF stack and hardware, no doubt.
What makes .NETMF potentially better than Windows 10 IoT for xyz? From an abstract point of view towards quality: it consist of less code and thereby chances for bugs are smaller - I know that’s pure theoretical! Or to say it with other words: what is the cause for an app crash : failures in source-code … so : less code = potentially fewer bugs ;-).
But let’s switch back towards the first challenge : how to get a RS-485 Gadgeteer Module working with Gadgeteer HAT on Rapsberry Pi 2 @ Windows 10 IoT for small device … using it for Modbus RTU communication in industrial automation scenarios.
@ Mr. John Smith : you find devices in industrial field installations, that talk over CAN bus, but you find them not so often as devices talking Modbus RTU (at least in the projects I was involved).
And you cannot change the communication protocol of “device in the field” by wish - this is even more true, when its from a 3rd party … then the “bus language” is fix as a law.
Just to give you some inspirations why I really & absolutely want to use a Windows 10 IoT device for the job … because I want to “lovingly push” GHI to a decision or announcement that they will produce and sell "Windows 10 IoT "-Boards in the future as well [still proving the NETMF boards and existing installations in the field as well] ;-).
Having the development boards announced by Micorosoft already is cool, but not sufficient ;-). What makes GHI ideal for that job: you got the experience and were in deep contact with the “small devices” using & developing community, so you know a lot about what’s needed in the “field out there”. So come on guys, gives us the next generation IoT boards 
… but please don’t stop supporting the old ones - they are reasonable & usefull!
… that’s just aside.
But turning back again to the concrete: why Windows 10 IoT for what I want to do? I got a scenario where I have to integrate “present time industrial devices” which talk Modbus RTU and even more “sophisticated industrial bus languages” … and it’s not an option to let the others devices change their “bus language” IT’S THE JOB to let them “be as they are” (because they do a good job! … and you know: never touch a running system, right and building a bridge for them into the new age of industry 4.0.
And what is the most visible and imaginable reason : this bridge should have a sophisticated User-Interface for some installation (not every device will have it), but some of them will have a touch display or display and “external touch device” … and that’s a job for XAML, no doubt! (I know there is a UI Framework that GHI made even available at no cost and it’s cool for NETFM, but does not have the power & flexibility of XAML).
A second reason is a broad set of other ways of communication that should be possible in the future and chances are best, when building on Windows 10 IoT - although I read the statetment of Colin Miller that the NETMF team is working on AllJoyn and WinRT API Integration … that sounds good and will add rich value to the NETMF platform.
The communication needs ranges from Azure Integration to local & customer specific protocol’s in a LAN environment … and now there comes “the argument” (of no reject ;-): for this “LAN protocol” there is already a .NET Implementations existent and it will be ported to WinRT (or to the new term: universal app platform) … and this one is set - the customer demands the use of it. It’s quite reasonable, because the customer want’s to know what information travels through its LAN (network infrastructure) and ensure security, by providing the communication libraries … this is even more true as at current time there is no “standard industrial automation protocol” for Industry 4.0 - things are in progress, but not finished.
cheers
gebco
CANbus is even more timing intensive than ModbusRTU.
Oh.
@ mtylerjr : as you seemed to be touched by (respectively in touch with) the mystery of time … any ideas regarding the possible solutions mentioned below?
First Solution based on what Duke Nukem mentioned : when ahead of time compilation comes to .NET MF we should have a way. But sadly there are no real roadmaps or timelines … so by now it’s a only a light in the future ;-).
Second solution : the Gadgeteer HAT maybe has a socket for the existing RS-485 Gadgeteer Module AND a way that we can get direct access to the Data-Pins of the RS-485 in order to write a universal driver for Windows 10 in kernel mode.
@ GHI: do you think, at your current stage of prototyping the HAT, this might be possible, or can you already exclude this kind of solution, because of e.g. the “magic translater chip” (that sits on or underneath the Gadgeteer HAT board) and the driver you will write for that in order to bring the Gadgeteer Modules (via sockets) to the Windows 10 universal app platform (not at driver level).
From my instincts I guess chances are not good, that this will be possible, because the “RS-485 Pins” might most probably be NOT routed through (direct and 1:1) into the “Rapsberrry Pi 2” basic I/O System … but I am no electronic guy, so my guesses may be far away from reality ;-).
Third Solution : wasn’t there are a away to do something like P/invoke in .NET MF … a special feature of GHI (for their premium boards)? Or is this code also in the “time scheduling hands” of the .NET MF runtime and GC in the sense of : it can be pulled of the processor anytime and it’s NOT a substitute for some kind of “kernel mode driver” approach.
cheers
gebco
I use Modbus RTU too with a G120, where the G120 is the Master.
So far I had no issues with Timing.
When you send the whole telegram with a single SeriealPort.Write command it is verry unlikely thet the sending gets interrupted (I would guess that its made sure internally that the qhole telegram is always sent at once).
You can find my implementation of Modbus RTU/TCP Master and Client in CodeShare:
https://www.ghielectronics.com/community/codeshare/entry/880
1 Like
@ Reinhard Ostermeier : thanks for your „real life report" with Modbus RTU on .NET MF - it’s really helpful to know that you get it running with the G120! Sadly I don’t have a G120 at my hands, only a FEZ Cobra (1st version) and a Fez Cerbuino-Bee.
And much more bigger thanks for sharing your Modbus - Library!!! I already grabbed it AND did a “quick port” to Windows 10 … yes it works!
I already can compile your ported library (I comment out the Modbus TCP and Gateway - but to port this will follow the same principles as for porting the SerialPort to SerialDevice), but currently I cannot test it, because of a deployment issue I am facing with the Windows 10 universal app that will uses this.
I build a minimalistic Windows 10 universal app that will have 2 Pages (2 User-Interfaces) : the first Page (Main-Page) is just for a “ping & pong” (echo) of Text-Messages and that one is just for figuring out if everything is okay with the SerialDevice Implementation and the Serial-Port Implementation on the other side, whereby this will be a FEZ Cerbuino Bee first and an Arduino later on.
But deploying this app (on the same Windows 10 machine … start debugging it) I get a strange deployment error (it has something to do with the declaration of so called capabilities for using the serial device with the app, which is in the end for requesting the permissions from user), but this should be only because of the “beta bit’s” in Windows 10 technical preview (I use build 10041) or of Visual Studio 2015 CTP6. I am already on the way to clear this mysteria in another forum and as soon I got the solution or the next evolution of the “beta bits” solving that issue, I will move on.
To complete the picture : the second page (Octolight-Page) of the Windows 10 universal app will have a ViewModel at its’ back that will use the ported Modbus-Library of yours to communicate with the FEZ Cerbuino Bee. In this scenario the FEZ Cerbuino Bee will be the Modbus Slave (simulating an “low end” industrial device) with 8 process-data (holding / input register), which will be visualized on the FEZ with the 8x8 LED Matrix Module (the discontinued one).
The Octolight-Page will also show a “8 by 8” Matrix to make comparison of the values as easy as possible for human eyes. Watching on “pure numbers” that changing their values often drives you crazy after a short while and then you nothing any more So I came up with this LED bar approach (like seen in Equalizer e.g.).
With that I will tune up the BAUD rates and evaluate how far the Modbus RTU “bit-timing” will work on Windows 10 (aiming Windows 10 IoT for small devices). If I am lucky I maybe get this working with 9.600 Baud … because it did so with a Python project on Linux and an ARM based board.
This will be not sufficient, but a first step. If I get this working I will think about a “special Serial-Device universal driver in kernel mode” for Windows 10 - there is a whole example, which is well documented, of a “serial port driver - universal driver” (Windows-driver-samples/serial/serial at main · microsoft/Windows-driver-samples · GitHub) … but I did no driver coding by now - so there will be quite learning curve and I fear I do not have the time for digging into the world of “windows driver development” … but maybe there is someone around who says : hey man this is so easy, just ad 100+ lines of code to the example and you are good to go.
Just to give a taste about what was needed for the port - I think its interesting, because Colin Miller mentioned that WinRT API will be ported to .NET MF.
In a nutshell it’s about the following:
• SerialDevice is Stream based : it has not an integrated buffer as SerialPort, but an InputStream and OutputStream which you can operate with DataReader and DataWriter on
• Streams and “their things” (classes, methods) that operate on them are Task based - that means they are ready for asynchronous implementations … to be precise : you do not have an option, you have to go with the “async & await” and Task based programming paradigm … which I think is a great benefit.
In my personal opinion beside LINQ, “async & await + TPL” is the hugest innovation in software development that I could use & enjoy (I know: also evolution is a matter of time - each steps appears and shines in the context of its time & place ;-).
A great place to get some deeper know-how is the PFX Team-Blog which is driven (mostly written) by Stephen Toub : .NET Parallel Programming
• And when it comes to coordination primitives (async enabled lock for example), which are needed too, the PFX-Team and Stephen Toub is there with more than helpful, well explained implementations - e.g. the “asnyc lock” : http://blogs.msdn.com/b/pfxteam/archive/2012/02/12/10266988.aspx . He wrote a series of 7 blog-posts which explains and shows how the implementation for the most needed coordination primitives are done. Grab the code, build a library of it and you are ready to go async & await ;-). And the blog post are really great : the explanations give are easy to understand and worth reading !
• using async methods implies that you cannot use “ref” or “out” parameters and instead you have ot use “complex return-code” (classes or structs), which results in some modifications of the method signatures.
So all together is was not difficult, if one knows about the WinRT API’s of streams and the “async & await + TPL” way of coding. And extending the library port to Modbus TCP will be quite easy, because “Stream Sockets” (that’s what TCP-Sockets are called in WinRT API and so in Windows 10) are also based on Streams … so their inner workings are the same as with SerialDevices (thanks to the designers of .NET … did I say, that I love that language … okay it’s a framework, but with C# it feels like a language).
@ Reinhard Ostermeier : if you are interested in the ported code, of course I would hand it over to you … at the core it’s your “intellectual property” so it’s more than naturally that you should “get it back” (sorry I don’t find the right words in English), should benefit from the little evolution I did with it. So if you are interested in the “ported bits” let me know how I could hand it over to you - the simplest way that comes in my mind would be through dropbox. It’s up to you to decide if it should be public available or not - for me it’s a matter of respect and not of a license (licenses and legal papers are very important in our world, no doubt … but I am no lawyer and I did not grew up with a legal/juristically language … but I got to a natural feeling what is right or wrong and respect of others and their stuff is one road to it ;-).
And to take a look at the future of this library port : I think (no, I know - I am sure) that this port can be done better … for me it was just a quick shot, to see if the port is possible in a reasonable time … and it was, because you did a precise and compact implementation (praise & thumbs up) !!!
But when it comes to the world of the WinRT API of streams e.g. it makes sense to change code that operates on “byte arrays” and user Buffer instead … and some other stuff as well (e.g. the return-code classes I used are just stuffed together and not well designed).
It’s a comparable to a situation when you move a vehicle from rails to roads - you can go and try to put tires underneath and see how it’s going, but thinking in a long term use, it is a better approach to redesign some core aspects like the body of the vehicle and then try to use as much of the inner equipment as possible, to get it work best on roads.
So what I am thinking of : it’s a good idea to do a redesign for the “universal app platform - class library” and then adapt the “core code” as much as possible … because reinventing a good wheel might be fun, but is practical a waste of time ;-). AND I think I will go this way, if you permit me do use your code.
One possible approach would be to host this redesigned Library, based on your codings, on Git-Hub and make it open-source that way. The only thing I am concerned about: my time, respectively the time I could spent for maintaining the library and code. Normally I am not a friend of just “throwing out” some code and say “use it as it is, but be aware I do not have the time to fix bugs - take it as it is or leave it”. My personal experience is that a lot of developer “skip” or ignore (often pushed by their bosses decisions) the second part (the warning) and afterwards the issue tracker is filled up and bad reputation is the consequence … this is definitively not what I want.
Or to say it with other words: chance are good that I can use it for a project in which I am involved, so that the “investment of time” for a “first good version” makes senses. And when I or someone else in that project stumbles upon a problem I will fix them, but I do not have the time to do an appropriate maintenance of an open source project - in a way it should be: keep an eye on the issue tracker and so on.
@ Reinhard Ostermeier: maybe we could switch to an email based conversion & discussion about this? As I don’t want to be caught up by spam bots and a flood in my inbox (;-), if you like to email about this please send me a direct message through this forum - thanks and have a good time
cheers
gebco
The posts have gotten longer than I can process. If there are actions for me here, please LMK. 
Otherwise see some of you at Build and maybe at the Build Tour!
https://www.build15.com/
Pete
@ gebco - By a quick glance through your 1734 words I have realized that you might have some really valid and relevant points. I must say that I dont expect anyone to read your post. If you want ignite some dialogue, you should probably spread your points into relevant short comments and direct messages in the proper topics of the forum. Just saying… :whistle:
1 Like
Gary… I need to place an order… but I can wait two weeks if it will be worth it. Tell me that waiting until May 1st will be worth it, that there will be something I’ll wan’t to order, and that I should postpone my current order so I dont have to pay shipping twice? Can you tell me that?
@ mtylerjr - NDA ;D
Garyified
: ɐpu - ɹظɹǝןʎʇɯ@
I like that, from now on things are “Garyified”