Well, as I said in an earlier thread, it looks like I will need to do things the hard way with my USB adventures. As such, I finished a pretty big milestone.

I converted the required Import files for MASM32 to support the HID.DLL that comes with your OS. Im sure its not complete, but i would guess its 75% or better. For my uses its got all I need.

Im posting this for anyone who wants it.

While im confident its in good shape, I have not yet tested it with a software application. If you find a bug please let me know of it.

Regards,
:alright:
:NaN:
Posted on 2004-04-15 22:34:49 by NaN
NaN, Thanks! :alright:

Well, this will get us some joystick support and other goodies for sure, without DX.

Regards, P1 :cool:
Posted on 2004-04-16 10:58:30 by Pone
Well, I still havent tested out the import library. But I can offer some lean & mean source to work the USB HID driver from Visual Basic.

I made a very small and to the point VB class. I tested it with the PicCalc USB device. This is a project posted publically on the web here. I bread boarded the USB hardware and programmed my PIC with the provided firmware for the chip.

The front end software was tested with this class. I send six bytes, all .50 values, and it returns the values sent, and appends a two byte sum, making 8 bytes returned in all. The sum is shown in byte values, so the correct answer of 300 (6*50) is 01 44 (256 + 44 = 300).

For anyone who can use this, enjoy!
Tomorrow, i will translate the VB source to MASM. (VB is a nice proto typing language for this). However, I plan to use multiple threads to properly trap for returning interrupts from the hardware. There is an interesting article on the MSDN discussing this here.

Regards,
:NaN:
Posted on 2004-04-16 23:32:13 by NaN
Well, as promised, here is the MASM equivalent to the small visual basic version posted above.

The MASM version works 100% identically, and requires the same Hardware and running firmware in the USB device.

I have translated the VB class into an ObjAsm32 OOP class and it is as well included in the zip.

Note: The import library I posted above had two mistakes in it that were identified finaly from this example in Masm32. As such, you can find the most up to date import definitions in the zip below (Version 1.0.2).

Any questions? I hope you find this as useful as I do. Next step is writing new USB firmware and a new Windows application to demonstrate Interupts, and hopefully a message dispatched, or a call back.

Regards,
:NaN:

PS: You *need* to have the installed ObjAsm32 to run the example, as like Vkim's debug, there is a similar OOP debug window being used to show the data exhange. I did this for simplicity as you do not need to design a windows inteface. However the source itself is sound ;)
Posted on 2004-04-17 18:30:10 by NaN
Well because I like to share so much, here is another usefull bit of source. (Took me all day to work out the bugs).

This version handles IRQ like operations by running a separate thread. I took care to ensure that proper Event objects and WaitForSingleObject actions are taken such that the thread isn't spinning its wheels needlessly. I have to say it works very well and my CPU doesnt show any slowing down from it.

My windows 98SE doesnt have a taskmonitor that im aware of (didnt look to hard), so i cant really give you any stats on CPU loading. But as I said, all process running in the background are not hindered by this thread. So I feel quite confident it is to spec.

In addition to all this, i went the extra mile and built in a ring-queue into this thread. It will store up to 32 usb *reports* before event dispatching the first to your window application. I have no handling if you overrun the queue at this moment. Only a Debug output. It would be very easy to issue a separate message however.

The ring-queue is not sized in bytes, but rather the Input Report length as returned by the USB device when enumerated. My prototyping device sends 9 bytes at a time, so the buffer is sized as follows:

QueueSize = [ [ ( ReportLength + 16 ) and (0xFFFFFFFC) ] * NumberOfQueues ] + 16

NumberOfQueues is set to 32, but can be adjusted to 16, 8, 4,2, or 1. As you can see im a big fan of oversizing buffers, just to be safe ;) . These values are not by accident. I have two status register that does thread intelocking and tracking of the Queue data, such that nothing is accidently missed. When a message is received by your window app, you mush pass the wParam to an Acknowledge method which will reset the bit flags for that queue location. There is a InFronUsb pointer filling the queue with its own tracking register, and a PostedMessage tracking pointer. The Acknowledge will reset both for more data to be stored in this location. The posting pointer will follow the in from usb pointer in an endless ring.

Beyond even this, I added management into the thread. You can tell the thread to start its IRQ monitoring, or stop it. As well, upon closing the device, or destroying the class, the thread will be properly notified and synchronized such that heap data is freed befor the process exits.

There is one extra message that can be generated to your window app as well, for when the USB device is disconnected. I have yet to program the detection in an automatic sense, but I have some sample source to work off of, so It may come in a later revision.

The source posted below is again desinged to work with ObjAsm32's debug window and the PicCalc usb device programmed with the PIC firmware.

Its becoming a powerful class file. I hope you think so too ;)
Enjoy!
:alright:
:NaN:
Posted on 2004-04-18 23:27:19 by NaN
Oh ya, because Im lazy I reworked DemoApp03 from the ObjAsm32 package. When you run the program, it will connect right away to the device if its connected to the USB. From here, hitting the CUT tool bar button will issue 16 Write packets to the device.

The USB device will then return 16 interrupt like replies. They will be Queued and dispatched by the worker thread. To stop the thread, hit the PASTE tool bar button. To resume the thread hit the COPY tool bar button.

Again, this is only usefull if you have the USB device wired up to the bus. Otherwire you will get nothing out of these buttons, since there is no connection established.

Regards,
:NaN:
Posted on 2004-04-18 23:36:37 by NaN
Not only the technology but making in work it actual application. Do you mind if I ask your age and who if any you might work for? You never cease to amaze me. By the way did you do anything more with that voice actuated Autocad? I would think that would would be marketable.
Posted on 2004-04-20 14:47:42 by mrgone
Glad you like my work.

I'm 28.. and work for a Civil Engineering firm. This is my high-tech hobby, since I can't afford my own IC lab ;) . I work as an Electrical Engineer for the firm, mainly automating water and waste water treatment facilities. I basically make plants work like Homer Simpson's console, so all the operators have to do is sit around, eat donuts, and press little red buttons ;)

I would love to do electronics related work full time, but unfortunately the tech sector went south just as I finished my 7 year school-a-thon between college and university (college was far more useful, university only gave me a "book list" for other topics I might want to know :rolleyes: ) . So I found my self a somewhat over skilled electrician.... but hearing replies like your helps boost your moral that its paying off in some respect.

Back to USB. I'm very impressed with the technology. It was a bit of a pain in the arse to get the windows side of it working, but now that its done, its a very usefully tool. Far more practical than the parallel port or serial port IMO.

I'm already laying plans to build a robust *anything* programmer, with an interface to the CPU via USB. My thoughts is to use three main hardware layers: 1) the USB com's no functions here, just data in/out; 2) the main algorithmic CPU to which will perform chip programming; 3) Ram chip that will buffer environment variables as well as the program to be burned into a chip.

The design is to keep the USB IO out of the loop from an upgrade point of view. USB Pic's are one time programmable. So if I off load the programming algorithms onto a Flashable chip I can add additional firmware to the chip in the future. Using a buffered ram to hold the program is advantageous since once the device has it in memory, I don't need the PC any more. As well, I can have things like ID's automated so each chip I burn has a unique ID number in its firmware. This is a big feature for a project I'm also working on. (Each RF processor needs a unique ID to identify itself from others ~ 50 or more). To do this by hand would be painful :rolleyes:

Anywho, if you get my software going for you, let me know how you find it, and if you have additional discoveries/suggestions.

Regards,
:alright:
:NaN:
Posted on 2004-04-20 21:24:12 by NaN
I'll tell you I am impressed! Yeah the economy did take a huge dip especially in the manufacturing sector. That would be electronics new product developement, you know, what we do :) . Anyway keep doing what your doing and you'll do just fine or much better. I like your approach of putting things into actual application that other can use. I'm 47 by the way and have been in electronics all of my adult life. Let me tell you in this bizz you must always be learning, so your schooling was just the beggining but you appear to have a strong foothold on things so I would say just keep doing what you are doing and good work!
Posted on 2004-04-22 11:21:24 by mrgone
I found a small bug in the source code i provided. Specifically in the thread routine where it dispatches the windows message that a USB report was received. The code below is the passage, and the line in red is the fix that needs to be added.
      ; No, so send a message about this memory queue, and move to the next location.         

or [esi].qStsR, ebx

mov eax, IndexOut
inc eax
and eax, CHID_MAX_REPORT_BUFFER-1
mov IndexOut, eax

[color=red] dec eax[/color]
mov edx, pQMem
imul eax, QueueSize
add edx, eax
mov lpBufOut, edx

mov edx, lpBufOut

invoke PostMessage, [esi].m_hWnd, WM_HID_REPORT_AVAILABLE, ebx, edx

As well, for your information, I have successfully used this source in a full interrupt at random hardware application, and it passed with flying colors.

Regards,
:NaN:
Posted on 2004-04-25 20:02:19 by NaN