M
Mario
Is there a matching equivalent for REG32 type in C#?
Thanks.
Thanks.
P
Paul G. Tobey [eMVP]
That's not a type, as far as I know. It appears to me to be a macro in C,
but it's defined differently depending on the context (one driver likes it
this way; another a different way). How are you expecting to use it and why
do you think you need it?
Paul T.
but it's defined differently depending on the context (one driver likes it
this way; another a different way). How are you expecting to use it and why
do you think you need it?
Paul T.
M
Mario
Hi Paul,
I am going through the driver source code to see how can I create an
IST for GPIO from a managed project. There are few places in the
driver where varibles are defined using REG32, for example there is a
structure for the port registers where all elements of the structure
are defined by using REG32(for pin direction it has REG32 DDIR). I was
thinking that I might need to translate the structure to C# and need to
know what is the appropriate type for it. Thanks.
-- mario
I am going through the driver source code to see how can I create an
IST for GPIO from a managed project. There are few places in the
driver where varibles are defined using REG32, for example there is a
structure for the port registers where all elements of the structure
are defined by using REG32(for pin direction it has REG32 DDIR). I was
thinking that I might need to translate the structure to C# and need to
know what is the appropriate type for it. Thanks.
-- mario
P
Paul G. Tobey [eMVP]
It's *not* a structure, but a macro. You'll have to figure out how it's
defined by the driver you're trying to replace and do the same in C#.
There's no right answer to your question, but different answers for every
driver.
Now, on to the real question: how are you going to get the event handle to
wait on so that you can implement the IST in managed code?
Paul T.
defined by the driver you're trying to replace and do the same in C#.
There's no right answer to your question, but different answers for every
driver.
Now, on to the real question: how are you going to get the event handle to
wait on so that you can implement the IST in managed code?
Paul T.
M
Mario
Hi,
I am lost here too, however I was thinking that it might be possible to
implement a call back from the IST in the driver to managed code. The
complete sequence would be something like this:
1. Hardware generates an interrupt.
2. Triggers ISR, and kernel (scheduler) services IST in the driver.
3. IST makes a call back to maged code(IST2).
4. IST2 does what it does and return to IST.
5. IST ends by calling InterruptDone().
The normal sequence of interrupt events are described in
http://www.windowsfordevices.com/articles/AT8134605131.html.
The thing that I am concerned about is that this might be possible, but
it takes too long to service all the way to the managed code. Then
again, I might be off track. Any inputs are appreciated.
For those who have done this kind of stuff, are ISTs ever done at the
managed code level or just in the driver level? If it has not bee
done, what schemes are being used so that a push of a button can
trigger my application to send information to my managed code app?
Thanks.
- mario
I am lost here too, however I was thinking that it might be possible to
implement a call back from the IST in the driver to managed code. The
complete sequence would be something like this:
1. Hardware generates an interrupt.
2. Triggers ISR, and kernel (scheduler) services IST in the driver.
3. IST makes a call back to maged code(IST2).
4. IST2 does what it does and return to IST.
5. IST ends by calling InterruptDone().
The normal sequence of interrupt events are described in
http://www.windowsfordevices.com/articles/AT8134605131.html.
The thing that I am concerned about is that this might be possible, but
it takes too long to service all the way to the managed code. Then
again, I might be off track. Any inputs are appreciated.
For those who have done this kind of stuff, are ISTs ever done at the
managed code level or just in the driver level? If it has not bee
done, what schemes are being used so that a push of a button can
trigger my application to send information to my managed code app?
Thanks.
- mario
P
Paul G. Tobey [eMVP]
Why do you want to do this? What possible advantage would you have in
handling interrupts in managed code?
Paul T.
handling interrupts in managed code?
Paul T.
Mario said:
G
Guest
You're going to have some problems with latency and especially determinism.
If you simply need the interrupt to cause some evet in managed code set a
named event in the IST and have a thread in managed code waiting on that
event. For more you might look at these:
http://blog.opennetcf.org/ctacke/PermaLink,guid,e806d34b-a8d8-45e8-9de8-bec58818fafe.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,3b82a255-dd39-4151-bc18-5691c27f6cec.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,656921ed-1eeb-4773-86f0-fe50c84e5d12.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,7dd6d988-5edb-4f5f-afe1-46f2d6b148c9.aspx
As you may have guessed, I've been down this road.
--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--
If you simply need the interrupt to cause some evet in managed code set a
named event in the IST and have a thread in managed code waiting on that
event. For more you might look at these:
http://blog.opennetcf.org/ctacke/PermaLink,guid,e806d34b-a8d8-45e8-9de8-bec58818fafe.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,3b82a255-dd39-4151-bc18-5691c27f6cec.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,656921ed-1eeb-4773-86f0-fe50c84e5d12.aspx
http://blog.opennetcf.org/ctacke/PermaLink,guid,7dd6d988-5edb-4f5f-afe1-46f2d6b148c9.aspx
As you may have guessed, I've been down this road.
--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--
Mario said:
M
Mario
Hi,
This is the first thing that I could think of
. The application that
I am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out. Thanks.
-- mario
This is the first thing that I could think of
. The application thatI am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out.
Thanks.-- mario
P
Paul G. Tobey [eMVP]
Who wrote the driver? You could have an IOCTL value that you pass to the
driver to add or remove an 'interested party'. The structure you pass or
the value might contain a handle to an event that you make yourself by
calling P/Invoke which indicates the event that the IST will set when it's
found new data or whatever. The application would then fork a thread to
wait on that event and, when it fires, call the driver to get the latest
data. Or, if you want to roll everything into one, you could have the
application create a point-to-point message queue (there's a wrapper in
OpenNETCF), and have an IOCTL to send *that* to the driver. The driver
could then dump the data into the queue directly and the application would
have a thread waiting on that queue. Each time the queue was non-empty, the
thread would awaken, read the last data from the queue then go back to
sleep.
Without really knowing what you're trying to do and how often things happen,
we're shooting in the dark, though.
Paul T.
driver to add or remove an 'interested party'. The structure you pass or
the value might contain a handle to an event that you make yourself by
calling P/Invoke which indicates the event that the IST will set when it's
found new data or whatever. The application would then fork a thread to
wait on that event and, when it fires, call the driver to get the latest
data. Or, if you want to roll everything into one, you could have the
application create a point-to-point message queue (there's a wrapper in
OpenNETCF), and have an IOCTL to send *that* to the driver. The driver
could then dump the data into the queue directly and the application would
have a thread waiting on that queue. Each time the queue was non-empty, the
thread would awaken, read the last data from the queue then go back to
sleep.
Without really knowing what you're trying to do and how often things happen,
we're shooting in the dark, though.
Paul T.
Mario said:Hi,
This is the first thing that I could think of
I am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out.
-- mario
M
Mario
Hi,
I think B-Square did it for Freescale for their i.MX21 ADS board. For
the point-to-point messsage queue example, I could not find such
example through a search in OpenNETCF.org web site. Is the example
included in the 1.4 source code? Now I just need to figure out how to
do what you suggested. Thanks.
-- mario
I think B-Square did it for Freescale for their i.MX21 ADS board. For
the point-to-point messsage queue example, I could not find such
example through a search in OpenNETCF.org web site. Is the example
included in the 1.4 source code? Now I just need to figure out how to
do what you suggested. Thanks.
-- mario
Who wrote the driver? You could have an IOCTL value that you pass to the
driver to add or remove an 'interested party'. The structure you pass or
the value might contain a handle to an event that you make yourself by
calling P/Invoke which indicates the event that the IST will set when it's
found new data or whatever. The application would then fork a thread to
wait on that event and, when it fires, call the driver to get the latest
data. Or, if you want to roll everything into one, you could have the
application create a point-to-point message queue (there's a wrapper in
OpenNETCF), and have an IOCTL to send *that* to the driver. The driver
could then dump the data into the queue directly and the application would
have a thread waiting on that queue. Each time the queue was non-empty, the
thread would awaken, read the last data from the queue then go back to
sleep.
Without really knowing what you're trying to do and how often things happen,
we're shooting in the dark, though.
Paul T.
Mario said:Hi,
This is the first thing that I could think of
I am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out.
-- mario
P
Paul G. Tobey [eMVP]
Yes, it's wrapped in the network code for SDF 1.x, as I used it to receive
network notifications. It's called, oddly enough PointToPointMsgQueue.cs.
The AdapterStatusMonitor class uses it to receive notifications about
changes in network adapter status. That should show you how to be a reader
of the queue. You'll have to find the docs for the API calls to see how to
be a writer, but you'll be doing that from the driver, in unmanaged code,
anyway, so it shouldn't be a problem.
Paul T.
network notifications. It's called, oddly enough PointToPointMsgQueue.cs.
The AdapterStatusMonitor class uses it to receive notifications about
changes in network adapter status. That should show you how to be a reader
of the queue. You'll have to find the docs for the API calls to see how to
be a writer, but you'll be doing that from the driver, in unmanaged code,
anyway, so it shouldn't be a problem.
Paul T.
Mario said:Hi,
I think B-Square did it for Freescale for their i.MX21 ADS board. For
the point-to-point messsage queue example, I could not find such
example through a search in OpenNETCF.org web site. Is the example
included in the 1.4 source code? Now I just need to figure out how to
do what you suggested. Thanks.
-- mario
Who wrote the driver? You could have an IOCTL value that you pass to the
driver to add or remove an 'interested party'. The structure you pass or
the value might contain a handle to an event that you make yourself by
calling P/Invoke which indicates the event that the IST will set when
it's
found new data or whatever. The application would then fork a thread to
wait on that event and, when it fires, call the driver to get the latest
data. Or, if you want to roll everything into one, you could have the
application create a point-to-point message queue (there's a wrapper in
OpenNETCF), and have an IOCTL to send *that* to the driver. The driver
could then dump the data into the queue directly and the application
would
have a thread waiting on that queue. Each time the queue was non-empty,
the
thread would awaken, read the last data from the queue then go back to
sleep.
Without really knowing what you're trying to do and how often things
happen,
we're shooting in the dark, though.
Paul T.
Mario said:Hi,
This is the first thing that I could think of
I am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out.
-- mario
Paul G. Tobey [eMVP] wrote:
Why do you want to do this? What possible advantage would you have in
handling interrupts in managed code?
Paul T.
Hi,
I am lost here too, however I was thinking that it might be possible
to
implement a call back from the IST in the driver to managed code.
The
complete sequence would be something like this:
1. Hardware generates an interrupt.
2. Triggers ISR, and kernel (scheduler) services IST in the driver.
3. IST makes a call back to maged code(IST2).
4. IST2 does what it does and return to IST.
5. IST ends by calling InterruptDone().
The normal sequence of interrupt events are described in
http://www.windowsfordevices.com/articles/AT8134605131.html.
The thing that I am concerned about is that this might be possible,
but
it takes too long to service all the way to the managed code. Then
again, I might be off track. Any inputs are appreciated.
For those who have done this kind of stuff, are ISTs ever done at
the
managed code level or just in the driver level? If it has not bee
done, what schemes are being used so that a push of a button can
trigger my application to send information to my managed code app?
Thanks.
- mario
Paul G. Tobey [eMVP] wrote:
It's *not* a structure, but a macro. You'll have to figure out how
it's
defined by the driver you're trying to replace and do the same in
C#.
There's no right answer to your question, but different answers for
every
driver.
Now, on to the real question: how are you going to get the event
handle
to
wait on so that you can implement the IST in managed code?
Paul T.
Hi Paul,
I am going through the driver source code to see how can I create
an
IST for GPIO from a managed project. There are few places in the
driver where varibles are defined using REG32, for example there
is
a
structure for the port registers where all elements of the
structure
are defined by using REG32(for pin direction it has REG32 DDIR).
I
was
thinking that I might need to translate the structure to C# and
need
to
know what is the appropriate type for it. Thanks.
-- mario
Paul G. Tobey [eMVP] wrote:
That's not a type, as far as I know. It appears to me to be a
macro
in
C,
but it's defined differently depending on the context (one
driver
likes
it
this way; another a different way). How are you expecting to
use
it
and
why
do you think you need it?
Paul T.
Is there a matching equivalent for REG32 type in C#?
Thanks.
M
Mario
Thank you.
Yes, it's wrapped in the network code for SDF 1.x, as I used it to receive
network notifications. It's called, oddly enough PointToPointMsgQueue.cs.
The AdapterStatusMonitor class uses it to receive notifications about
changes in network adapter status. That should show you how to be a reader
of the queue. You'll have to find the docs for the API calls to see how to
be a writer, but you'll be doing that from the driver, in unmanaged code,
anyway, so it shouldn't be a problem.
Paul T.
Mario said:Hi,
I think B-Square did it for Freescale for their i.MX21 ADS board. For
the point-to-point messsage queue example, I could not find such
example through a search in OpenNETCF.org web site. Is the example
included in the 1.4 source code? Now I just need to figure out how to
do what you suggested. Thanks.
-- mario
Who wrote the driver? You could have an IOCTL value that you pass to the
driver to add or remove an 'interested party'. The structure you pass or
the value might contain a handle to an event that you make yourself by
calling P/Invoke which indicates the event that the IST will set when
it's
found new data or whatever. The application would then fork a thread to
wait on that event and, when it fires, call the driver to get the latest
data. Or, if you want to roll everything into one, you could have the
application create a point-to-point message queue (there's a wrapper in
OpenNETCF), and have an IOCTL to send *that* to the driver. The driver
could then dump the data into the queue directly and the application
would
have a thread waiting on that queue. Each time the queue was non-empty,
the
thread would awaken, read the last data from the queue then go back to
sleep.
Without really knowing what you're trying to do and how often things
happen,
we're shooting in the dark, though.
Paul T.
Hi,
This is the first thing that I could think of
I am working on is a C# managed app and the device has inputs that
would trigger some events. I need to gather and display the new
information on my application. If you could point me to some easier
ways of doing what I need to do, I would be more than happy to try it
out.
-- mario
Paul G. Tobey [eMVP] wrote:
Why do you want to do this? What possible advantage would you have in
handling interrupts in managed code?
Paul T.
Hi,
I am lost here too, however I was thinking that it might be possible
to
implement a call back from the IST in the driver to managed code.
The
complete sequence would be something like this:
1. Hardware generates an interrupt.
2. Triggers ISR, and kernel (scheduler) services IST in the driver.
3. IST makes a call back to maged code(IST2).
4. IST2 does what it does and return to IST.
5. IST ends by calling InterruptDone().
The normal sequence of interrupt events are described in
http://www.windowsfordevices.com/articles/AT8134605131.html.
The thing that I am concerned about is that this might be possible,
but
it takes too long to service all the way to the managed code. Then
again, I might be off track. Any inputs are appreciated.
For those who have done this kind of stuff, are ISTs ever done at
the
managed code level or just in the driver level? If it has not bee
done, what schemes are being used so that a push of a button can
trigger my application to send information to my managed code app?
Thanks.
- mario
Paul G. Tobey [eMVP] wrote:
It's *not* a structure, but a macro. You'll have to figure out how
it's
defined by the driver you're trying to replace and do the same in
C#.
There's no right answer to your question, but different answers for
every
driver.
Now, on to the real question: how are you going to get the event
handle
to
wait on so that you can implement the IST in managed code?
Paul T.
Hi Paul,
I am going through the driver source code to see how can I create
an
IST for GPIO from a managed project. There are few places in the
driver where varibles are defined using REG32, for example there
is
a
structure for the port registers where all elements of the
structure
are defined by using REG32(for pin direction it has REG32 DDIR).
I
was
thinking that I might need to translate the structure to C# and
need
to
know what is the appropriate type for it. Thanks.
-- mario
Paul G. Tobey [eMVP] wrote:
That's not a type, as far as I know. It appears to me to be a
macro
in
C,
but it's defined differently depending on the context (one
driver
likes
it
this way; another a different way). How are you expecting to
use
it
and
why
do you think you need it?
Paul T.
Is there a matching equivalent for REG32 type in C#?
Thanks.