|
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.)
|
|
|
|
|
Having worked on interfaces to several bus systems, but not USB, I've found the relevant specs essential. I'm not saying you have to read the whole thing but when the software gets tough its good to be able to look at the spec and compare with what your code is doing, or not doing. I found someone had coded to cope with the situation when everything happened ideally, no bus conflicts, no unresolved addresses, no planning for when a thread to receive wasn't available etc. At times it was only by reading the bus spec I could find out what should have been coded for. For instance I found an unreliable bus system on the test rig was due to no pull up resistors on the data lines, something I found in the spec, and something somebody had spent a long time trying to resolve with a debugger.
|
|
|
|
|
EDIT - Thanks to everyone that replied.  I have found a better solution than an INF file.
My company has an existing software-only driver. The 32-bit version is being installed using InstallShield. Unfortunately for me, the company wants to get away from InstallShield as the product in question is going to be part of a customer's own installation. The build system here produces the 64-bit signed driver, and I am tasked with creating a .inf file to install this driver. I've been reading Microsoft documents about .inf files (until my eyes are bleeding) and all of this documentation seems to be centered around the Windows Driver Development Kit. I believe that this kit generates a .inx file which is really the .inf file. However, all I need to do is create a .inf file that will do the job.
When right-clicking on the .inf file and selecting Install, the install process is spectacularly silent about anything that is happening (right or wrong). So it is very difficult to determine what is happening.
Some of my problems include the following:
1. The driver is already signed, so I find it unlikely that I will need a CatalogFile. Will the .inf file work without a defined CatalogFile?
2. It seems that a software-only driver needs to have some dummy device installed, and (from the InstallShield results) I see this dummy device in HKLM\CurrentControlSet\Enum\Root\LEGACY_DRIVER_NAME. This is somehow linked to service entry in HKLM\CurrentControlSet\services\driver_name which points to the actual driver executable in \Windows\System32\drivers. I'm getting lost trying to define this dummy device.
3. I am successful installing the service, and I find it in the registry, but the install process never copies my driver into the drivers directory, so it appears to die before it gets that far.
4. I keep reading about a CoInstaller, but I get the feeling that it is not exactly necessary. Is this correct?
What I need is a clue. I haven't defined the dummy driver entry which is where I need the help. I've also made the assumption that the install directory where the .inf file is executed from is the root of the SourceDisk. Here's what I have in my .inf file so far:
This was edited to include a missing quote.
[Version]
Signature = "$CHICAGO$"
Class = LegacyDriver
ClassGuid = {8ECC055D-047F-11D1-A537-0000F8753ED1}
Privider = %US%
DriverVer = 12/16/2012, 5.1.0.126
[vstor2-mntapi20-sharedCopyFiles]
%DriverExeName%
[SourceDiskNames.amd64]
1 = %DiskDesc%,,,\AMD64
[SourceDiskFiles.amd64]
%DriverExeName% = 1
[DestinationDirs]
DefaultDestDir = 12
[vstor2-mntapi20-sharedInstall.NTamd64]
CopyFiles = vstor2-mntapi20-sharedCopyFiles
[vstor2-mntapi20-shared.NTamd64.Services]
AddService = vstor2-mntapi20-shared,, vstor2-mntapi20-sharedServiceInst
[DefaultInstall.NTamd64]
CopyFiles = vstor2-shared-sharedCopyFiles
[DefaultInstall.NTamd64.Services]
AddService = vstor2-mntapi20-shared,, vstor2-mntapi20-sharedServiceInst
[vstor2-mntapi20-sharedServiceInst]
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 2 ; SERVICE_AUTO_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
DisplayName = vstor2-mntapi20-shared
ServiceBinary = %12%\%DriverExeName%
[Strings]
US = "Company Name"
DiskDesc = "Install Directory"
DriverExeName = "vstor2-mntapi20-shared.sys"
Fletcher Glenn
modified 20-Mar-13 13:10pm.
|
|
|
|
|
What about a silent install? Could you do a silent installshield install that does what you want? The customer's own install could then launch it silently.
That might be easier than doing what you are trying to do....
|
|
|
|
|
That's a very good suggestion. However, since I posted my question I have become aware of the sc.exe command that can be used to directly install a software-only driver. This solves my problem. Thanks for your help.
Fletcher Glenn
|
|
|
|
|
fglenn wrote: (until my eyes are bleeding)
You should have tried writing an inf file for NT4......
fglenn wrote: generates a .inx file
No, YOU write an inf file.
fglenn wrote: he install process is spectacularly silent
Taka a look at the system file setupapi.log, there you will see al the output.
fglenn wrote: . The driver is already signed, so I find it unlikely that I will need a CatalogFile. Will the .inf file work without a defined CatalogFile?
You can sign just the driver binary (normlly done for boot start devices) or you can sign the binary inf cat file combo.
You have a few isues with the inf file, vstor2-mntapi20-shared isnt declared for example. Run Chkinf on it (in the WDK tools\chkinf dir), it will check the file for you and report any errors.
==============================
Nothing to say.
|
|
|
|
|
Does anyone know a converter with this capability. I am looking for a USB to serial converter or chip (like FTDI, Prolific, Microchip) that is capable of doing 5 Baud.
thanks
PKNT
|
|
|
|
|
5 baud? Thats very slow. Do the standard USN to serial cables go this low?
==============================
Nothing to say.
|
|
|
|
|
Why are you trying to go that slow? ...you can simply oversample a slow incoming signal btw (turn it into a high rate signal), but you have to make sure you have DC coupling wherever the slow signal is coming into, not sure if USB is AC or DC coupled. If it happens to be AC coupled, the slow DC rates are going to get filtered out by the coupling capacitor.
|
|
|
|
|
Hi Kiran,
I ran into the same problem some time back, a communication link had a 5-baud initialization sequence where communication parameters were negotiated. Unfortunately we did not find any UART that supported this reliably. So our solution was to use a GPIO pin combined with a UART, implement the 5-baud initialization by sampling the GPIO input and after the negotiation switched the GPIO to high-Z and enabled the UART, now with a supported, high baud rate.
Hope this helps.
|
|
|
|
|
I'm building a PIC24 project.
I'm putting some C routines into an ASM project.
I'm getting seven errors.
The first six are all apparently interrput handler conflicts. Here they are (condensed and abbreviated for clarity)...
multiple definition of `_U1RXInterrupt'
multiple definition of `_U2RXInterrupt'
multiple definition of `_U3RXInterrupt'
multiple definition of `_OscillatorFail'
multiple definition of `_AddressError'
multiple definition of `_StackError'
multiple definition of `_MathError'
I'm getting one last error that is totally new to me, this one...
Link Error: Could not allocate section .nbss, size = 20004 bytes, attributes = bss near
Link Error: Could not allocate data memory
I really need
U1RXInterrupt and
U3RXInterrupt for my assembly language routines.
Can someone tell me how to get the C compliler and MpASM to cooperate and let me have those two ?
I can take out the other interrupts from my assembly language with some text editing.
Your advice and guidance will be greately appreciated.
|
|
|
|
|
I reckon the problem stems from your program's design - that is to say, I've heard of mixing asm and C code for decades. I don't recall ever seeing someone put c code into an asm project - it's always the other way around. Regardless of compiler/system, gcc/tc/vs and mips/x86/arm/sparc etc, etc
I'll have another play with it when it's finished installing again.
Make it work. Then do it better - Andrei Straut
|
|
|
|
|
If You figure this one out you have my endorsement !
I'm still studying the PDF file that explains the design
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
