PIC18F2455 based USB MIDI module

[rlang]

I have developed a PIC18F2455 based USB MIDI interface and am currently in the testing of the software written in BOOSTC.  I like the chip because it does not require a software download like the cypress chip and has a PDIP form factor for easy soldering.  I was interested in your USB module software because of the problems you found with the MICROSOFT driver.  The software currently enumerates correctly at full speed as an audio device.  Any advice you have would be appreciated.

http://www2.netdoor.com/~rlang/usbmidi.jpg for photo

[TK.]

Hi,

great to hear that I'm not the only one who is working on a PIC based USB-MIDI solution - do you plan to publish the source code to the public domain? It would be a big help for people who want to do extensions (like USB-Audio, IO control, etc)

To the descriptors: the old MBHP_USB firmware package contains the source code (-> http://www.ucapps.de/mbhp_usb.html), the descriptors can be found in "dscr.a51". Small changes can bring your windows installation to a blue screen. E.g., WinME and Win2k are crashing when you are defining an empty Audio Control device (like suggested in the USB-MIDI spec), therefore it is left out

And now the fun begins: the released version doesn't work on all WinXP systems, some installations require a modified one which will be regognized correctly, but causes a crash under Win2k - due to this mess I'm thinking about a selfwritten Windows driver based on the Microchip framework - does anybody have experiences with Win driver programming?

Best Regards, Thorsten.

[rlang]

To the descriptors: the old MBHP_USB firmware package contains the source code (-> http://www.ucapps.de/mbhp_usb.html), the descriptors can be found in "dscr.a51". Small changes can bring your windows installation to a blue screen. E.g., WinME and Win2k are crashing when you are defining an empty Audio Control device (like suggested in the USB-MIDI spec), therefore it is left out

Like you I also had problems with the audio control device so I used your descriptors as a guide and just reduced the number of serial ports.  My problem now is trying to squeze everything I need into one serial port.  I may have to implement an additional serial port as a "bit blaster" since I really think I need a serial port for debugging at this stage.  Currrently I am trying to use one port for debugging and midi output, but sometimes a character is displayed out of sequence.  Of course I can't use the serial port for debugging once a real midi device is plugged in.  The out of character sequence  probably has something to do with the way I manage the serial buffer.  Note the following output

USB MIDI Interface V2.1

Full speed USB

I

D>H

GD

device

12 01 08

d8 04 08

H>D

SA

01

D>H

GD

device

12 01 08

d8 04 08

00 01 02

D>H

GD

config

09 02 08

32 02 01

D>H

GD

config

09 02 08

32 09 08

00 00 08

00 06 08

24 02 08

01 03 08

03 02 08

05 01 08

05 25 08

02 04 08

01 01 03

D>H

GD

stall IN

Unstall

D>H

GD

string

04 03 04

D>H

GD

string

2a 03 08

31 00 08 

34 00 08

4d 0008

20 00 08

30 00 02

D>rH  <= note the out of place r from string below

GD

sting

04 03 04

...

Do es anyone have any thoughts on what takes priority in the interrupts - serial or usb? ;)

Thanks,

Rob

[TK.]

Hi Rob,

just send me your code and I can have a look whats going wrong. I haven't started with my own USB firmware yet (planned for easter holidays), but if your project is doing the same, then there is no need for reinventing the wheel and I can concentrate on other things. :)

Priority: the USART receiver should have the highest priority, since MIDI doesn't provide a handshaking mechanism. Thereafter the MIDI transmitter to prevent MIDI Out buffer overruns. USB can get the lowest priority

Best Regards, Thorsten.

[rlang]

I will send you the coding, probably around week's end after I have another stab at it.

On the writing your own WDM driver, that was my original thought.  After reading Walter Oney's 600 page opus called Programming the Microsoft Windows Driver Model, I was discouraged.  Edition 1 of this book had over 24 pages of errata, which says to me that even if you are an expert, it is easy to make mistakes building a windows driver.  Even so, I ordered the Windows Server 2003 Driver development kit from Microsoft.  There are some USB examples and it also includes the following audio driver examples:

ac97 - A sample audio driver that runs on an Intel motherboard with an integrated AC97 controller. This sample shows how to write a WDM audio adapter driver that implements WavePci support for a PCI add-in card with scatter/gather DMA capabilities. Included with this sample driver are additional subdirectories containing sample code that works in conjunction with the driver. ddksynth - Kernel-mode DLS synthesizer. This sample can be adapted for a MIDI output device as well.

dmusuart - MPU-401 miniport driver for processing DirectMusic and MIDI input and output streams. This is the source code for the built-in DMusUART miniport driver in portcls.sys. Hardware vendors can adapt this sample to write their own custom miniport drivers.

fmsynth - FM-synth miniport driver for MIDI. This sample driver provides an interface to a device that implements OPL3-style synthesis. This is the source code for the built-in FMSynth miniport driver in portcls.sys. Hardware vendors can adapt this sample to write their own custom miniport drivers.

gfx - The two GFX samples appear in the DDK for Windows XP SP1, Windows Server 2003, and later. These samples implement support for a simple GFX (global effects) filter:

mpu401 - Stand-alone sample adapter driver. This adapter driver implements standard functionality for an MPU-401 MIDI interface device. The source code for this sample is quite small because it uses only the system-supplied miniport drivers that are implemented in portcls.sys.

msvad - Microsoft Virtual Audio Device. This is a collection of samples that all use the same "virtual audio device" in lieu of an actual hardware-based adapter driver. Each of these samples highlights a different facet of the WDM audio driver architecture:

  ac3 - Demonstrates support for a non-PCM audio data format.

  drmmult - Demonstrates support for multiple-stream audio with SAP-protected content. For information about SAP (secure audio path), see the Platform SDK documentation.

  drmsimp - Demonstrates support for a single audio stream with SAP-protected content.

ds2dhw - Demonstrates support for hardware-accelerated two-dimensional mixing for DirectSound.

multstr - Demonstrates support for playback of multiple streams of PCM audio data.

pcmex - Demonstrates support for a PCM audio format that is defined by the WAVEFORMATEXTENSIBLE structure.

simple - A skeleton reference implementation of an audio adapter driver upon which the other msvad sample drivers are built.

sb16 - Sound Blaster 16 sample. This sample implements an audio adapter driver for an SB-compatible adapter card on an ISA bus.

I have not had a chance to look at or compile any of these examples.

Rob

[TK.]

Hi Rob,

it looks like a nice text adventure ;-)

"dmusuart" could contain all informations which are required to create a MIDI device, if this can be linked to the MPUSAPI DLL, then an adaption should be easy - everything is there, it only has to be combined correctly. Does Microsoft allow the re-use of examples if somebody hasn't purchased the DDK, or is this prohibited by the license?

Alternative possibilities: we could ask for help from Hubert Winkler (he made "Hubis Loopback Device" and published the source code, unfortunately it's written in Pascal: http://members.nextra.at/hubwin//midi.html), or Jamie O'Connell who made MIDI-Yoke (http://www.midiox.com/index.htm?http://www.midiox.com/myoke.htm).

Both drivers are multiclient capable

Best Regards, Thorsten.

[AndrewMartens]

Looks good!  Once one of these designs is finished and stable, I look forward to building something - then my secondary PC will finally have MIDI capabilities!

[to-pse]

Hi,

have you guys ever thought about building a small ethernet/wireless lan <> midi device?

I have written a network-midi driver for windows, which you can currently use to connect

multiple computers via (virtual) midi over the local network.

It would be nice to have a real backend to connect synthesizers etc.  With wireless you

could even have the added benefit to work cableless (though wifi is a power-hog ;-)

Tobias

PS.: I'll release the driver publically a couple of weeks after the CeBIT is done, as soon

as I have time to finish a couple of small open topics...

[TK.]

Hi Tobias,

sounds interesting! Due to lack of drivers I never thought of this - from the uC side the implementation isn't that difficult. Microchip provides the source code for a TCP/IP stack (-> application note AN833) and the schematics for adapting a RTL8019 to the PIC18F452 (-> PICdem.net user guide).

On the other hand: when I look at my ToDo list, I know that I won't have the time for such experiements till end of this year ;-)

Since you've knowledge in writing drivers: are you interested in writing a reliable MIDI-USB driver for Windows? I can give you all the details (also a USB driver framework) and I would send you one prebuild MBHP_USB_PIC module for free! :)

Best Regards, Thorsten.

[to-pse]

I thought that Windows autodetects your usb-device and uses the generic USB-midi-driver...

What is the problem with that?

Tobias

[TK.]

The windows based driver doesn't work under win98/se and win95, and sometimes not under win2k and win XP. For WinXP I've an alternative descriptor table which is 100% spec compliant, but which crashes win2k and winME

Another drawback: it isn't multiclient capable.

I'm not the only one who noticed this problems, the lack of support from Microsoft has been complained in the usb.org forum many times, and companies were forced to develop their own drivers (last example: Behringer - they offer a selfwritten driver in the meantime)

Best Regards, Thorsten.