Real Time Clock Devices

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?

R0b0t1.

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

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


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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.

R0b0t1.

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


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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
>

I was able to find
https://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/create-a-new-bsp
which is about modifying the RPi3 BSP. Unfortunately there doesn’t
seem to be much in the way of nontrivial examples.

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.

R0b0t1.

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.

– pa

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

Peter
OSR
@OSRDrivers

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

Anton Bassov

Peter,

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.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
xxxxx@lists.osr.com
Sent: Sunday, July 09, 2017 9:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Real Time Clock Devices

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

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

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.

Peter
OSR
@OSRDrivers

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.

R0b0t1.

>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. :wink:

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.

Peter
OSR
@OSRDrivers

> Now, why would you say that?

Peter,

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?

– pa

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. :wink:
>
> 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.

R0b0t1.

>this all is available from others.

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.

Peter
OSR
@OSRDrivers

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.

Peter
OSR
@OSRDrivers

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.

R0b0t1.

Do you really want to control the system time from your device or just provide yourself with a reliable ?call me every X? facility?

If you want to control the system clock, then you want to look at Windows Time Providers (https://msdn.microsoft.com/en-us/library/windows/desktop/ms725475(v=vs.85).aspx)

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.

Sent from Mailhttps: for Windows 10

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.

R0b0t1.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>