How are they managed? This kind of goes along with the question about
watchdog timers. Are they typically handled by vendors and not really
visible?
I could likely mimic the alarm functionality using the ACPI subsystem
and custom hardware and wake up a computer, but how do I provide an
interface that interacts with waitable timers and provides a system
time?
How are they managed? This kind of goes along with the question about
watchdog timers. Are they typically handled by vendors and not really
visible?
There are only a few standard implementations for system timers on
Windows-based motherboards. The exact locations are identified in the
ACPI DSDT and exposed with a standard PnP identifier. The HAL knows how
to use these standard identifiers, and hooks them up to the kernel
functions. In the IoT world, this is provided by the board support
package (BSP).
I could likely mimic the alarm functionality using the ACPI subsystem
and custom hardware and wake up a computer, but how do I provide an
interface that interacts with waitable timers and provides a system
time?
What’s the real situation here? Do you have a new motherboard that
isn’t supported by the existing Windows HALs and drivers? You may need
to create a board support package. That probably requires you to work
with someone within Microsoft.
On Fri, Jul 7, 2017 at 1:26 PM, Tim Roberts wrote: > R0b0t1 wrote: >> How are they managed? This kind of goes along with the question about >> watchdog timers. Are they typically handled by vendors and not really >> visible? > > There are only a few standard implementations for system timers on > Windows-based motherboards. The exact locations are identified in the > ACPI DSDT and exposed with a standard PnP identifier. The HAL knows how > to use these standard identifiers, and hooks them up to the kernel > functions. In the IoT world, this is provided by the board support > package (BSP). >
Thanks, it seems like that answers my question.
> >> I could likely mimic the alarm functionality using the ACPI subsystem >> and custom hardware and wake up a computer, but how do I provide an >> interface that interacts with waitable timers and provides a system >> time? > > What’s the real situation here? Do you have a new motherboard that > isn’t supported by the existing Windows HALs and drivers? You may need > to create a board support package. That probably requires you to work > with someone within Microsoft. > > https://developer.microsoft.com/en-us/windows/iot/docs/bsp >
The closest I can get to describing a reasonable situation which might happen is: I want to run Windows 10 IoT Core on a Raspberry Pi, but I want to add in a real time clock via either the I2C or SPI bus. How do I make sure it is visible to the system?
I think your link to the description of BSPs gives most of what is publicly available, but what if I am not a hardware or silicon vendor but I have access to the hardware and documentation at such a level to provide what is in a BSP?
Another example would be HardKernel’s ODROID-XU4 or other devices. An open ended bootloader signed by a valid key is provided as well as all hardware description necessary for compiling a Linux kernel. Ostensibly a third party could create a BSP if the information needed to do so is available.
I think your link to the description of BSPs gives most of what is
publicly available, but what if I am not a hardware or silicon vendor
but I have access to the hardware and documentation at such a level to
provide what is in a BSP?
The Windows IoT team at Microsoft has been extremely interested in
reaching out to the hardware development community – not surprising,
since they’re trying to build an installed base. I suggest you start
here, and try some of the contact links. I suspect you’ll quickly find
someone who can point you to the right resources.
On Fri, Jul 7, 2017 at 3:10 PM, Tim Roberts wrote: > R0b0t1 wrote: >> >> I think your link to the description of BSPs gives most of what is >> publicly available, but what if I am not a hardware or silicon vendor >> but I have access to the hardware and documentation at such a level to >> provide what is in a BSP? > > The Windows IoT team at Microsoft has been extremely interested in > reaching out to the hardware development community – not surprising, > since they’re trying to build an installed base. I suggest you start > here, and try some of the contact links. I suspect you’ll quickly find > someone who can point you to the right resources. > > https://developer.microsoft.com/en-us/windows/iot/community >
More searching I did related to RTC drivers (perhaps they are given a driver class?) didn’t turn up anything but very, very old results related to WinCE. Having tried the MSDN Forum and the Windows Feedback Tool and found them to have poor response times, I suspect social media may be the best way to follow up. The WindowsIoT account is defunct, so I will be asking IoTDan about BSPs and the RTC subsystem soon. Please wish me luck in my use of social media.
I’ll reply with any useful information I might find so it’s archived on the list.
IoT Enterprise is just Windows Embedded by another name, and thus generically useful.
Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you’re concerned with pushing collected data up to the cloud.
Drivers on IoT are just Windows drivers… and, yes, there’s the whole UWP thing, but in terms of that… well… that’s whole other thread.
On Sun, Jul 9, 2017 at 7:19 AM, xxxxx@fastmail.fm wrote: > R0b0t1 wrote: >> Please wish me luck in my use of social media. > > Gladly. Even more - good luck with the MS IoT for anything useful at all.
Well, I mostly hold the same opinion, but it could very well speed up development time and make my employer more comfortable with embedded development. There are, after all, more Windows, and specifically C# programmers, available than most other demographics.
However my experience has been that Windows programs (and programmers?) are generally of a lesser quality overall than Linux or POSIX programs (or programmers). I continue to explore Windows due to its pervasive workplace presence and to keep my skills up to date across the board* but am still not finding any counterexamples. As a consequence I don’t think
* I had to spend a little over a month relearning Windows after using Linux for multiple years in a row. It wasn’t pleasant and most of what I did was make Windows more like my Linux installation.
On Sun, Jul 9, 2017 at 8:53 AM, xxxxx@osr.com wrote: >>good luck with the MS IoT for >>anything us full at all. > > Now, why would you say that? > > IoT Enterprise is just Windows Embedded by another name, and thus generically useful. >
I have to agree with this sentiment because I wouldn’t be bothering to learn about Windows IoT if it seemed devoid of all value.
> Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you’re concerned with pushing collected data up to the cloud. >
My experience with Microsoft software indicates that - despite a few moments of truly inspired and comprehensive design - the majority of the APIs and software that is available is lacking in some way or another. I recently had a conversation about this and I think the best way to explain it is that the APIs and software seem like they were never actually used for their intended purpose by someone within Microsoft, and as a consequence nobody ever found out how they were deficient. But I have no doubt they passed all of their test cases.
In this case Microsoft’s take on IoT seems to revolve around things like “Big Data” and “the cloud” which, while I could agree are actual terms, are far more limited and probably not what is applicable to most people.
> Drivers on IoT are just Windows drivers… and, yes, there’s the whole UWP thing, but in terms of that… well… that’s whole other thread. >
As far as I can like Windows I rather like the idea of a unified platform, but I’m having a problem figuring out what kind of promises it actually makes - a quick reading about it indicates it’s not much different than what Linux already has. The most applications that do not interact with hardware directly will run without modification, but for everything else, you are designing for a specific hardware product.
As for my question to IoTDan, I have received no response. His Twitter account seems work oriented so I hope to receive a reply this coming week. If I don’t receive a reply I’m rather concerned I will not obtain the information I need in a timely manner. I will keep looking, as I’ve found some better results using terminology introduced to me on the list before, but ultimately I don’t seem to be having great luck with low level Windows development.
I believe I’ve complained about the state of Microsoft provided documentation before on the list. If Microsoft is taking their IoT initiative seriously like Peter suggested, hopefully that will produce some documentation effort that spills over onto other low level windows subsystems.
> There are, after all, more Windows, and specifically C# programmers, available than
most other demographics.
Developers, developers, developers,developers…(N more time)…developers. Yes!!!
However my experience has been that Windows programs (and programmers?) are
generally of a lesser quality overall than Linux or POSIX programs (or programmers).
Don’t you even start…
In this case Microsoft’s take on IoT seems to revolve around things like “Big Data”
and “the cloud” which, while I could agree are actual terms, are far more limited
and probably not what is applicable to most people.
Ironically, the workable concept of IoT in itself seems to be tightly related to “Big Data”. All “futuristic projections” (like,for example, a “smart fridge” that may automatically order items over the Internet, a house with self-adjusting heating et al) don’t seem to be coming true not because of some technical challenges but simply because all these “fancy” things seem to be of zero interest to the average end user.
At the same time it may be, indeed, interesting for the corporate customers who have to collect and analyze data and may want to automate this process. For example, consider a utility company that reads “smart” electricity/water meters over the Internet - unlike above mentioned “projections”
this is,indeed, a useful thing that offers convenience and cost reduction. Therefore,MSFT is probably looking in the right direction
The problem with Windows IOT is more the way Microsoft presents it
to customers. I have several customers who have used Windows embedded and
after talking to Microsoft about IOT got the impression, that the system
would not work if it was not connected to an Azure cloud. I tried to
explain otherwise, but the impression the Microsoft field people give, is
enough that several have said we are not going there.
The other problem with IOT is the moving target problem of supported
platforms. I had a customer start coding for IOT (I was not involved with
the effort) since their embedded board was going to be supported according
to Redmond. A few months later there is a revised list of platforms sent
to them, and their system is not supported.
>good luck with the MS IoT for >anything us full at all.
Now, why would you say that?
IoT Enterprise is just Windows Embedded by another name, and thus generically useful.
Other variants of IoT work on a wide variety of hardware and have some pretty cool features, especially if you’re concerned with pushing collected data up to the cloud.
Drivers on IoT are just Windows drivers… and, yes, there’s the whole UWP thing, but in terms of that… well… that’s whole other thread.
In terms of IoT “issues”… I agree with BOTH of Mr Burn’s statements. IoT is marketed very clumsily by MSFT(if I’m invited to one more talk about IoT that turns out to be mostly focused on Azure I’m going to scream). Conflating embedded with IoT is folly. There are IoT uses for embedded; there are many other non-IoT uses for embedded… so why call “embedded” IoT? Argh!
The hardware support story is also more than a little chaotic. Had a client that was beeegggggiiiinnnngg for support of a specific platform, for many months, that was repeatedly told “no way”… they even offered to do the bsp themselves… just a few weeks later, they discovered the board would be officially supported by IoT after all. Yay!? Now, the fact that IoT supports the desired platform isn’t a BAD thing. It’s just… frustrating when you’re over on this end trying to, you know, build products to sell to people.
I really don’t know how you fix the platform issue when so many folks need to come together, by a wide variety of possible paths, to realize support for a given platform. Anybody can create a BSP for a given platform today… assuming you have all the data you need from the silicon vendor, and a lot of Windows OS expertise.
On Mon, Jul 10, 2017 at 1:06 PM, xxxxx@osr.com wrote: > In terms of IoT “issues”… I agree with BOTH of Mr Burn’s statements. IoT is marketed very clumsily by MSFT(if I’m invited to one more talk about IoT that turns out to be mostly focused on Azure I’m going to scream). Conflating embedded with IoT is folly. There are IoT uses for embedded; there are many other non-IoT uses for embedded… so why call “embedded” IoT? Argh! > > The hardware support story is also more than a little chaotic. Had a client that was beeegggggiiiinnnngg for support of a specific platform, for many months, that was repeatedly told “no way”… they even offered to do the bsp themselves… just a few weeks later, they discovered the board would be officially supported by IoT after all. Yay!? Now, the fact that IoT supports the desired platform isn’t a BAD thing. It’s just… frustrating when you’re over on this end trying to, you know, build products to sell to people. >
This is essentially my experience with driver development, and looking into adding support to IoT Core to 3rd party devices. I want to do it and might have the time to do it but I don’t have the information to do it.
> I really don’t know how you fix the platform issue when so many folks need to come together, by a wide variety of possible paths, to realize support for a given platform. Anybody can create a BSP for a given platform today… assuming you have all the data you need from the silicon vendor, and a lot of Windows OS expertise. >
I didn’t join this list to evangelize about open source, but I think you have come across one of the reasons why open source is so successful: there are no artificial barriers to development. If I have a problem I can address it directly by reading the program to find the information I need, and if it makes sense, modify the behavior of that program.
>This is essentially my experience with driver development…
I think we’ve tangled on this before. All the data you need to write a Windows driver is available in MSDN. The less said reviving this topic, the better…
I didn’t join this list to evangelize about open source
Super good choice, that.
The problem with adding support for a platform isn’t much related to “How do I write a Windows BSP?” It’s more related to having access to the silicon vendor’ magic juju.
The sources for the RPI BSP (or some BSP, anyhow) are on GitHub… and, though I have not done it myself, I’m told by people who HAVE personally done it that they really are sufficient to allow you to create your own BSP for a platform of your choice, ASSUMING you have the requisite info from the silicon provider.
Because the churn rate of their technologies is disturbing. I wanted to write something about opensource vs “shared source” and so on - but yesterday watched Guardians of the Galaxy 2 … that final scene where Chris Pratt gets Zune player for his lost Walkman? It says all. That scene made me weep. So, it’s Zune.
Their idea of IoT platform itself is very appealing. Small versatile devices connected to cloud backend, supported by powerful cloud services, device management, patches, updates - all this is great. But… this all is available from others. Why to take the high risk of investing in technology that may vanish in any moment?
On Mon, Jul 10, 2017 at 2:40 PM, xxxxx@osr.com wrote: >>This is essentially my experience with driver development… > > I think we’ve tangled on this before. All the data you need to write a Windows driver is available in MSDN. The less said reviving this topic, the better… >
I’m not going to bring it up again in length, but the only useful examples I found were not provided by Microsoft or OSR. They were simply people, and one of them cited paid development experience with Microsoft products.
Based from most postings on this list it seems the majority of people have a huge support infrastructure of private code, documentation, and expertise to back them up.
>>I didn’t join this list to evangelize about open source > > Super good choice, that. > > The problem with adding support for a platform isn’t much related to “How do I write a Windows BSP?” It’s more related to having access to the silicon vendor’ magic juju. >
Per the original question it’s not necessarily how to write the BSP, but how to create a driver that interacts with what is, to my knowledge, a fairly undocumented portion of the Windows kernel.
If the Windows alternative does not offer appreciable perceived advantages over other platforms, then MSFT is probably screwed.
That’s not even a MSFT-specific statement, it’s a given for any technology: If Technology A does not offer appreciable benefits over Technology B, then technology A is probably screwed. The benefit doesn’t need to even be a technical bnefit… it doesn’t need to be a real benefit… it just needs to be a perceived benefit.
I dunno… I admit that the entire space is very confusing. And I don’t see MSFT bringing a laser-like focus to guide us.
But if your goal is to change the source the OS uses as it’s clock… isn’t that part of the BSP?
I dunno… I readily admit to not having looked into what you’re trying to do. I’ll also read I,y admit that adding an RTC to the RPI would seem a reasonable thing to want to do. If you just want to query it for your own app, that’s not a hard driver to write. If you want to integrate it into the OS as the time source used by the OS in place of whatever it already uses, that is by necessity a different and much larger task.
On Mon, Jul 10, 2017 at 2:58 PM, xxxxx@osr.com wrote: > But if your goal is to change the source the OS uses as it’s clock… isn’t that part of the BSP? >
Right, and the guidance and verbiage you gave specifically to BSPs made me feel stupid for not finding better answers sooner.
> I dunno… I readily admit to not having looked into what you’re trying to do. I’ll also read I,y admit that adding an RTC to the RPI would seem a reasonable thing to want to do. If you just want to query it for your own app, that’s not a hard driver to write. If you want to integrate it into the OS as the time source used by the OS in place of whatever it already uses, that is by necessity a different and much larger task. >
Well - if you could give me some words or do a few quick searches yourself I’ve still not found anything on how to actually plumb a driver to the time subsystem.
What you say is true, I could just communicate with my device directly, but I’m wondering how I get it to store the system time and provide interrupts to wake up the machine that can, presumably, be accessed with already available WinAPI (waitable timers, but I am guessing).
In other news Dan hasn’t chosen to reply this Monday so it’s possible he doesn’t care to answer, but I’ll keep an eye on it throughout the week. I might try some other forums.
This is a UM API that will allow you to provide time samples into Windows built in time provider service that ultimately controls the clock and tries to prevent skew versus wall clock time
If you are trying to control the clock used by the kernel to control thread scheduling, this used to be the domain of the HAL but I have not looked into this in more than a decade so much may have changed.
If you are looking to provide your code with a periodic interrupt, then that is the easiest of all ? just as long as your period and granularity aren?t too tight or missing a few doesn?t cause the nuclear missiles to launch.
From: R0b0t1mailto:xxxxx Sent: July 10, 2017 8:25 PM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: Re: [ntdev] Real Time Clock Devices
On Mon, Jul 10, 2017 at 2:58 PM, xxxxx@osr.com wrote: > But if your goal is to change the source the OS uses as it’s clock… isn’t that part of the BSP? >
Right, and the guidance and verbiage you gave specifically to BSPs made me feel stupid for not finding better answers sooner.
> I dunno… I readily admit to not having looked into what you’re trying to do. I’ll also read I,y admit that adding an RTC to the RPI would seem a reasonable thing to want to do. If you just want to query it for your own app, that’s not a hard driver to write. If you want to integrate it into the OS as the time source used by the OS in place of whatever it already uses, that is by necessity a different and much larger task. >
Well - if you could give me some words or do a few quick searches yourself I’ve still not found anything on how to actually plumb a driver to the time subsystem.
What you say is true, I could just communicate with my device directly, but I’m wondering how I get it to store the system time and provide interrupts to wake up the machine that can, presumably, be accessed with already available WinAPI (waitable timers, but I am guessing).
In other news Dan hasn’t chosen to reply this Monday so it’s possible he doesn’t care to answer, but I’ll keep an eye on it throughout the week. I might try some other forums.