 |
|
Thanks for the insight. I just asked Microchip what to do.
|
|
|
|
|
Please note the PID/VID combination they give you is only, according to Microchip, "legally" "valid" for use with their PIC Microcontrollers.
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
i'm making a disk(volume) backup/restore system.
i would unmount volume before backup,
but the system volume can not be unmounted.
so the change or access of system volume is worry for me while that system volume is backup.
is it possible that detect which disk sector or ntfs cluster was changed realtime?
that can be filter driver, can it be possible?
|
|
|
|
|
Cross-posting is annoying. 
stick to one forum with a question.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
So I have a driver that does a child enum on the ACPI PDO. It gets back the methods, and then does an evaluate. There are two ways of doing this, evaluateex and evaluate. Oddly for exactly the same methods they return different data, not different in value, but the ex evaluation data has a 4 byte padding after each package, the eval method doesent. This is for _PSS data.
What is also odd that if the eval is called during IRP_MJ_START_DEVICE the _PCT data is also different to that obtained later on so I assume even then the device hasnt completely started. The _PCT at IRP_MJ_START_DEVICE shows IO port access, but later shows FFHW as the acces.
What is also interesting is that attaching to the PDO outside of AddDevice causes enum children to returns STATUS_NOT_SUPPORTED, which is odd, since the only interface to the PDO is the PDO pointer and the Irp, how DOES the PDO know the Irp is being sent from a DO attached outside of AddDevice? Odd stuff indeed.
Anyway it doesnt affect the functioning of the driver, it controls COU speed OK, but this variability of what the PDO is returning is odd and I cant exmplain it. Anyone have any idea why this is?
==============================
Nothing to say.
modified 30 Mar '13 - 12:55.
|
|
|
|
|
Hi,
Just a guess... but I believe the extended PSS ACPI specification known as XPSS supports a 64 bit mask rather than the 32 bit. Perhaps this is the discrepancy.
Best Wishes,
-David Delaune
|
|
|
|
|
THis is _PSS data though, being enumerated through the two methods available, which should give the same results.
==============================
Nothing to say.
|
|
|
|
|
Hi everyone i want to know who are the different manufacturer of USB LON DONGLE devices and which is more efficient in terms of cost for simulation
|
|
|
|
|
Internationally Tenda, TP LInk, Huawei are providing Dongles for connectivity.
|
|
|
|
|
D-Link is also a big and reliable vendor of USB Dongles..
|
|
|
|
|
Can I get some of the USB protocol description from the viewpoint of the software developer.
Specifically, what byte goes where, in what order; that sort of thing.
I'm implementing the module on a PIC24F embedded system.
Sample code would help a lot.
|
|
|
|
|
Have you read the USB spec?
==============================
Nothing to say.
|
|
|
|
|
Yes, I'm reading the spec right now.
So far, the most lucid explanations of the topics which I've found at this moment are HERE[^]
|
|
|
|
|
Yeah, that looks good for an overview. You need the spec in order to get the guts of the protocol. It is a fiddly thing, and often needs debugging, particularly when a new OS comes out.
==============================
Nothing to say.
|
|
|
|
|
Is that spec free for download ?
Is it a click away ?
|
|
|
|
|
yep, USB org or some such.
==============================
Nothing to say.
|
|
|
|
|
|
I cant really help you out with this loss of info.
Maybe you need to glance into firmware/driver programming to get a solution.
Just my 2 cents.
|
|
|
|
|
First thing, Has you PIC got built in USB hardware or are you trying to do this from basics with I/O lines? If it's the latter, go for the first. If you can't consider finding a USB chip and connecting it to your PIC. Its much much easier to get these things done in hardware than try to do them your self. If you can't do that, consider a PIC with Rs232 and get a USB to Rs232 converter.
Unless you're on the real cutting edge others will have done this before you. It's just a matter of finding them. I remember there are quite a few PIC code sites, though be wary of taking code at face value. I remember seeing a book on coding for USB in my local bookshop a few years ago, which takes, as you request, the developers perspective rather than a protocol specifier's perspective. so have a look.
Obviously you can do this yourself, Its just harder as you already know and you need time, information and patience.
|
|
|
|
|
I'm using the PIC24
PIC24FJ256GB210 if you like long strings of letters and digits.
It has a USB port already built in.
I believe it already has its SIE (Serial Interface "Engine" (eyes roll, etc.)) already built into the module.
Microchip (purportedly) has working source code on their site. I have looked at that code. There is a good chance that the person who wrote it knows what some of the statements are doing, and quite possibly why they are doing it.
What I'm really trying to figure out is: Who gives What byte to Whom in What order to make What action occur on What part of What machine ?
|
|
|
|
|
I see the spec you linked to is called 'usb made simple' and I think as far as it goes that's fine.
But from what I saw at a glance you need to find the PIC Serial Engine interface, and depending on its level, probably get into the detail of loading registers and setting bits etc. Nothing I can really advise here part from reading the detailed PIC Serial Engine docs. Its possible that the USB Enginer interface is similar to, say, the PIC Rs232 Engine interface etc so it may help to look at code for other Engine types.
|
|
|
|
|
No way is it that easy.
In fact, I wrote my own serial port handlers; individual interrupts and circular buffers and foreground and background signals and everything.
The Microchip PIC Serial Interface Engine is extensive, and I must learn a good deal about it. It had a descriptor table and data buffers and some sort of interrupt signaling scheme and so on.
I have homework !
|
|
|
|
|
I never said it would be easy, though I did avoid saying how difficult it might be 
|
|
|
|
|
Actually, I've been wanting to learn this stuff for years, so I'm actually having a "good" time, in that weird way.
|
|
|
|
|
Found THIS PAGE[^] with documents. It looks like 31 individual manuals, zipped into a 27 MB file.
Is that what you were suggesting ?
This was supposed to be a two week project.
The site that I'm reading, USB Made Simple[^] started becoming not so simple around chapter 3 or 4.
Suggestions are welcome on sites that provide explanations; particularly of the protocol and packet structure, of the software side of USB with respect to embedded systems.
(Thanks to anybody who can provide such link.)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
