|
Hi,
A driver is a program that communictes with the peripheral device (it isn't actually on the device, but on the computer).
A plug and play device doesn't remember the computer it connects to... the computer remembers the device that has connected to it.
(Usually peripheral devices don't have any memory).
To send information through the USB port an a PC you will need to find a method of using an existing (default) driver that is 'pre-installed'... or finding a driver (a .dll or similar) that you can 'take along with the program'.
Either way... Google will help.
As for the PICs... I used to use the 16 series but after going to 18s, they are much more powerful... I would use these.
The 'red disc shaped thing' is only a programmer (not a compiler)... It will probably say Microchip on it... This connects to your computer via USB and to the PIC via another method (not USB).
Once you have programmed the PIC... you can completely disconnect the programmer... you no longer need this to run the program (if you didn't already know this).
The PIC USB pins are seperate from the programming pins.
You will need to read the datasheet of the PIC you choose to use... there will be examples on how to both connect and use the USB 'port'.
Matthew Butler
|
|
|
|
|
Thanks Matthew, that link u provided was very useful,do u know of any links which have example circuits
using the PIC184550(are there any new versions )with the C code. I plan to use the PIC184550 chip(i
think its the latest).
|
|
|
|
|
There are loads of example circuits about.
Here's one (the 'Vusb' pin (connected to ground via a small capacitor) is important).
http://www.electronics-lab.com/blog/wp-content/uploads/2007/10/schematic.gif[^]
The PIC18F4550 is one of the newest versions in the 18 series (bearing in mind there are also PIC24, PIC30, PIC33 series).
Look at section 17.0 in this[^] datasheet (for the PIC18F4552)... there is also a small circuit example and the relevent code to use the USB port.
The PIC18F4550 is 'well known' so there is loads of examples (including C code) available after a few Google searches. (I prefer Assembler to C so I can't help with any sources).
Hope this helps.
Matthew Butler
modified on Friday, March 14, 2008 12:29 PM
|
|
|
|
|
I came across this while looking for something else on the internet. It probably qualifies as that support kit containing a generic driver I mentioned in my earlier reply (I haven't looked into it in detail to see how you can use it with a self-built device).
LibUSB-Win32[^]
Judy
|
|
|
|
|
|
Huh? 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
Hi
I Edit this for my friend question;my purpose is not for all;
Thanks
|
|
|
|
|
Hi there,
i am new to driver-programming and right now im trying to get into it, especially filter drivers, which turns out to be pretty hard for a newbie.
I try to discover if a file system filter driver or a minifilter in windows provides the possibility of returning more files than actually exist. As i found out, the IRP_MJ_CREATE request gets called whenever i try to open a folder, a file or a device. What i couldnt discover by now is, how i can detect to what type this request refers to(file/folder). What i also didnt get is: if a folder is requested, how and when does windows enumerate the files under the folder?
My approach for the "virtual elements" would be to set a filter, which detects when folder "A" wants to enumerate its children and just adds one that isnt actually there but i cant perceive how to hook into this request. Maybe someone can help me?
Some of you might wonder why i try to do this by a filter, if there already is such a thing as a shell namespace extension: I think that this could give me the possibility not even to have a virtual drive in the windows explorer but to have it actually inside my file system, so i can approch elements beneath it by file-paths. All in all it seems to be more powerful than the extension and i want to estimate if this desired benefit justifies the additional expenses that i expect in development.
I would be deeply grateful to any comment, that helps me understanding this technology or that discusses my intention.
|
|
|
|
|
gn0tto wrote: Hi there,
i am new to driver-programming and right now im trying to get into it, especially filter drivers, which turns out to be pretty hard for a newbie.
I try to discover if a file system filter driver or a minifilter in windows provides the possibility of returning more files than actually exist.
It would be easier to accomplish this by hooking ZwQueryDirectoryFile. If you look at the declaration of ZwQueryDirectoryFile you will see it is passed a constant named FileInformationClass. The return buffer may contain one of various structs depending on the FileInformationClass that was passed. Which can be one of the following values:
FileBothDirectoryInformation Return a FILE_BOTH_DIR_INFORMATION structure for each file.
FileDirectoryInformation Return a FILE_DIRECTORY_INFORMATION structure for each file.
FileFullDirectoryInformation Return a FILE_FULL_DIR_INFORMATION structure for each file.
FileIdBothDirectoryInformation Return a FILE_ID_BOTH_DIR_INFORMATION structure for each file.
FileIdFullDirectoryInformation Return a FILE_ID_FULL_DIR_INFORMATION structure for each file.
FileNamesInformation Return a FILE_NAMES_INFORMATION structure for each file.
FileObjectIdInformation Return a FILE_OBJECTID_INFORMATION structure for each file. This information class is valid only for NTFS volumes on Microsoft Windows 2000 and later.
FileReparsePointInformation Return a single FILE_REPARSE_POINT_INFORMATION structure for the directory.
More information here:
http://msdn2.microsoft.com/en-us/library/ms801001.aspx[^]
If you look at the declaration of each struct you will see they all contain a field named:
ULONG NextEntryOffset;
So essentially in your ZwQueryDirectoryFile hook if the FileInformationClass was 'FileFullDirectoryInformation' you would simply need to allocate a new FILE_FULL_DIR_INFORMATION struct and then walk the existing linked list. Once you have reached the end you could simply set the NextEntryOffset to the address of your newly allocated and populated struct.
gn0tto wrote: What i also didnt get is: if a folder is requested, how and when does windows enumerate the files under the folder?
if you wish to implement a filter driver you will need to implement:
pYourDriver->MajorFunction[IRP_MJ_DIRECTORY_CONTROL]=YourFilterDirectoryControl;
And within your control function you will need to set the I/O completion routine with IoSetCompletionRoutineEx. Thats where you can filter the FILE_INFORMATION_CLASS determined return values.
http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/File/FILE_INFORMATION_CLASS.html[^]
gn0tto wrote: My approach for the "virtual elements" would be to set a filter, which detects when folder "A" wants to enumerate its children and just adds one that isnt actually there but i cant perceive how to hook into this request.
Hooking ZwQueryDirectoryFile is a much easier approach if this was the only goal. The filter driver requires much more knowledge of driver implementation and internals.
gn0tto wrote: I think that this could give me the possibility not even to have a virtual drive in the windows explorer but to have it actually inside my file system, so i can approch elements beneath it by file-paths. All in all it seems to be more powerful than the extension and i want to estimate if this desired benefit justifies the additional expenses that i expect in development
Interesting idea... however it sounds to me like you want to take a hammer and smash a square block of wood into a round hole. Rather than implmenting a filter driver for an existing disk. What you are describing would be better implemented as a virtual disk driver.
You should begin by downloading the Microsoft IFS Kit.
http://www.microsoft.com/whdc/DevTools/IFSKit/default.mspx[^]
Good Luck,
-David Delaune
|
|
|
|
|
You're not supposed to hook kernel APIs, doing so has a strong risk of affecting system stability, and these APIs are subject to change without notice, leading to probable incompatibility with future service packs and operating systems.
File system filter drivers are the only supported way of doing this.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Yes, you are of course correct. 
Neither proposal should be used in a commercial product. He should also not add non-existing objects to the return buffer within a filter driver. Filter drivers are generally there to filter-out, I have never seen or heard of an implementation which added.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi again,
at first i want to thank you for participating in that discussion. I think you are both right and it might be daring to try to do this by a filter driver. I have already thought so too, before even knowing anything about this stuff. Now that i have had at least a few days to get an overview, i still wonder if it is possible at all, though.
From my current understanding there is a request in IRP form, that gets passed across the highest filter driver down to the lowest device driver and back. So when i open a folder in windows-explorer for example, the request goes down, then a file system driver recognizes the request to be for a folder and THEN initiates requests for the underlying elements, which subsequently again get passed down the whole driver stack and back. Am i right with this?
If this was so, there wouldn't be any possibility for me to get in between the enumeration within the higher level filter, so i wouldn't even be able to expand the enumeration but only to filter (which explained the name  ) out elements i don't want.
As you said, Randor, i could hook into ZwQueryDirectoryFile somehow, which i think, is also the routine that gets called from the low-level file system driver to enumerate the contents of a folder. Is that correct? (Just for my understanding. I think, you're both right that this would be too careless to actually do, so i dont even consider that being a possible solution)
The idea of a virtual disk driver sounds pretty interesting for my case. I guess ill get an overview about that, even though this sounds disgustingly like "writing your own file system driver" which might take a little bit of time to learn.
Thanks again for any comment on this topic
|
|
|
|
|
Thinking about it, you could take a leaf out of the Hierarchical Storage Manager's book and implement your own namespace under your own driver in the Object Manager. Then, you place a reparse point in the file system which causes the file system to return a REPARSE status code to the Object Manager, with the name of your driver object (IIRC). The object manager then passes the remainder of the path to your driver object in IRP_MJ_CREATE (I think).
Please take what I say with a pinch of salt as I'm an application developer who has a passing interest in kernel matters. I read about the reparse mechanism in "Windows Internals, 4th Edition".
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
I am posting this on the device driver forum because I think that this a Windows internal question and this about as a close of an area that I am going get
In Windows 32 bit were pointers are 32 bits there can conceptually be 2 process with the same address pointer e.g.
NorePad and outlook can both reference an address/pointer 12345678 and Windows/The OS would know to which process this pointer/address belongs
I was just wondering how this done is there some kind of selector/register (for lack of a better term) which qualfies an address/pointer
thankx
|
|
|
|
|
ForNow wrote: I was just wondering how this done is there some kind of selector/register (for lack of a better term) which qualfies an address/pointer
In the sense that you mean, given your questions in the other forum, the answer is NO.
In general terms, the OS internally maintains a set of page table mappings for each process that translate from the process's virtual address space to an actual physical address space. When a given process is scheduled for execution, the "current" page table pointers are adjusted to reference the page tables for that process. A virtual address goes in and a physical address comes out.
All the gory details (are there are lots of them!) can be found in Microsoft Windows Internals, 4th edition by Russinovich and Solomon
Judy
|
|
|
|
|
I have the book must be chapter 7 memory mangement
Any to way to access these page table pointer ??
Anyway thankx I read up
Thankx again
|
|
|
|
|
ForNow wrote: I have the book must be chapter 7 memory mangement
That's the one - longest chapter in the entire book
ForNow wrote: Any to way to access these page table pointer ??
Not in any documented way. There are few things scarier than someone messing with the internals of the memory manager - the potential for wreaking havoc is immense.
Have fun!
Judy
|
|
|
|
|
Just an FYI
I worked as contractor for IBM in poughkeepise on IOS (Input Output Supervisor)component of MVS for a couple of years that deals a lot with Hardware of the MainFrame
Guess I am used getting to the heart of the matter
P.S.
I thought I could load some value (selector) in a register and have it qualify the 32 bit address I was looking at
Anyway thankx
|
|
|
|
|
Hi,
the virtual-to-physical address translation is handled by the operating system, and is
not accessible by a user app; I trust you will need a driver for whatever it is you are
trying to do, hence also a DDK (Driver Development Kit), and that will offer you functions
to do all kinds of translations, effectively keeping the details out of your reach.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
|
On XP SP1 and XP SP2 if the virtual address is (addr < 0x80000000 || addr >= 0xA0000000) then you can attempt to mask the address with 0x1FFFF000 like this:
PHYSICAL_ADDRESS addr;
addr.QuadPart = (ULONGLONG)addr.QuadPart & 0x1FFFF000;
The problem is if the virtual address is (0x80000000 <= addr && addr < 0xA0000000) then you cannot reliably calculate the physical address from ring-3 and must use a driver and call MmGetPhysicalAddress() its possible although with a probability of error.
And it gets worse with Vista and Windows 2003 SP1, because access to \Device\PhysicalMemory is disabled!
-David Delaune
|
|
|
|
|
Hi, you may want to repost that in such a way that the OP gets a notification...
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
In normal execution, the processor handles translation from virtual to physical addresses completely automatically. The processor has a Translation Look-aside Buffer (TLB) which performs this operation. This is often described as an array of mappings that the processor 'searches' in one cycle, but is really a circuit in which the virtual address goes in the top and the physical address pops out of the bottom, if present.
If the required mapping is not in the TLB, the processor searches the page table. The control register CR3 points to the base of the page directory for the process. The Page Directory consists of Page Directory Entries which point to Page Tables. The Page Table Entries point to physical memory. If a valid Page Table Entry is found, the TLB is automatically updated and execution continues; otherwise, a Page Fault exception is raised to the OS which either fixes up the TLB directly and continues, fixes up the page table and continues (this might be the case where the data is already in RAM), reads in the code or data from disk (Windows is demand-paged, it doesn't read code from executables until it's actually called), or generates an Access Violation software exception.
Each process has its own Page Directory. When the OS switches from one thread to another, if the new thread is from a different process, it reloads the CR3 register with the address of the page directory for the new process. That automatically clears the TLB. (Page Table Entries can be marked Global; those are not cleared from the TLB.) Windows keeps the page directory base address information for each process in a data structure about that process.
The page table entry can be marked valid or invalid. A Valid page table entry is handled by the processor. If marked invalid (bit 0 = 0), the OS can (and does) store anything it likes in the other 31 bits. (To simplify things I'm talking about how 32-bit Windows worked on most machines before XP SP2!)
In some cases, particularly when memory has just been allocated, the PTE might not yet contain the necessary information. In addition to the page tables, Windows also stores information about all the virtual addresses that a process has allocated in a tree structure of Virtual Address Descriptors. It tracks what physical memory location belongs to which page table entry through the Page Frame Number Database, to update page tables appropriately when it has to reuse physical memory locations for something else.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thankx for the Info
A couple of quick questions in 32 bit Windows is the concept of segment offset still valid ?? however the offset is 32 bits
Anyway to access the CRs ??? or it all strictly hardware ???
Thankx
|
|
|
|
|
In 32-bit protected mode the segment registers still work. The segment registers themselves are 16 bits wide and point to segment descriptors which have 32-bit base and limit fields. The base and limit fields are interpreted as virtual addresses. The segment registers are really only for aliasing and setting protection information.
Windows doesn't bother with segmented addressing, bar one case: it uses the FS segment register to point to the thread's Thread Information Block. This means code can use FS:[0] to point to the TIB throughout, without having to perform another lookup to find out where the TIB is. All the other segment registers point to segments (of the correct type) which have a base of 0 and a limit of 0xFFFFFFFF, that is, they can reference any address in the system. SS, DS, ES and GS are all set to the same value, while CS points to a different selector as selectors differentiate between code and data.
For exception handling, 32-bit Windows uses the TIB to carry a chain of exception handlers, so if you look at disassembly of a function which has an exception handler, you'll see instructions referring to FS:[0].
In 64-bit long mode (x64), AMD decided to effectively remove the legacy segment registers apart from FS and GS. (Some operating systems used GS, I think.) The legacy segment registers still have to be set to point to segment descriptors but the base and limit aren't checked. The instructions that used to manipulate some of these registers (e.g. PUSH CS) have been removed. (Currently the opcodes do nothing but are reserved for future use.) The MOV CS,rnn instructions are now the only way of loading these registers.
The processor includes MOV CRn,rr and MOV rr,CRn instructions but they can only be executed at privilege level ('ring') 0, which means in kernel mode. I'd strongly recommend not trying to change them as the OS will get very confused. There are device driver APIs documented for mapping a user-mode buffer into the system address space if necessary. If you want to share some address space between processes, use a file mapping object (CreateFileMapping).
For a reference on all this information, you can try volume 3 of the Intel Architecture Software Developer's Manuals[^]. It's hard going but this really is the master reference.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
