PORUS: an open-source embedded USB stack

I looked at the web site, browsed the code a bit.

I admire your effort. What are your goals? It looks like you did a project and then just pushed it into an open source project.

Possible goals could be:

1) Do something that would be easily usable by a good programmer. 2) Do a package that is configurable to either minimize resource consumption or memory or .... 3) Make something easily portable to new hardware. 4) Make something that is easily portable to an embedded RTOS. 5) Get free work from others to use on your own project. (I am not criticising this goal - having others do drivers would be great).

I guess I am saying that your web site should describe your goals and give an overview of how to use the package and why it is better than the various semi companies' free device apis.

Regards, Steve

Thanks very much!

To make an embedded USB stack which is free, complete, easily portable, as easy to use as possible, and easy to learn where needed.

Yes, that's basically it -- I did it for work, but they had no interest in selling or keeping it, so they gave me permission to open-source it. This suits me, as I find it useful, and thought someone else might as well. No sense hiding it.

Well -- perhaps I should post these on the website somewhere then!

Yes.

Yes -- I avoid dynamic allocation whenever possible.

Most definitely.

Not necessarily. I want it to be useful without an RTOS.

Certainly -- why not?

That said, I would feel a bit bad about fishing for free labour for my employer this way -- that's not my intent at all. But since anyone can use it, including our competitors, I hope it won't be taken like this.

An excellent suggestion.

Thanks for having a look and for your comments! --mpa

May I make a few comments and suggestions, both technical and non-technical?

First off, you will have to figure out exactly what license you want to use, and make it perfectly clear on the website what the license is, and how you interpret it. You also have to make it clear who owns the copyrights (you or your employer), and get it all up front so that people can quickly see if it is something they can use or not. Typical licenses would be GPL/LGPL (in the embedded world, this effectively limits the code to test, evaluation and research status, unless you have a dual license), Mozilla Public License (any changes made to your code files must be open under the MPL, but any other files added by the user are unaffected - very similar to the various "modified GPL" licenses around), or BSD-style license (users can do anything with your code except claim they wrote it).

Secondly, there is no shame in fishing for free labour for your company

- explain to them that this is one of the benefits of releasing open source software, and that will encourage them to support the project directly (of course, it all depends on where you want to go with it). For some open source projects, the free labour is a side effect of the release, and for many others, it is a major reason for releasing the code. Everyone benefits.

On the technical side, python works perfectly well natively on windows - it is normally a better idea to use native python than cygwin python (though I haven't tried your code at all).

Also, what about drivers on the PC side? When I want USB on a card, I use FTDI's devices because they provide good, free, flexible drivers and supporting DLL's on the PC (windows and linux support). When you are doing things yourself with a USB device, as far as I understand it, you need to write the windows drivers. If your project encompassed that side of the USB equation as well, then it would be much more complete.

Best regards,

David

Of course!

It's Common Public License. I should probably put that in a more prominent place on the website, but it's all over the source distribution.

They've already approved it. That's why it's out there.

I haven't got round to making a Windows install, and I do run on Cygwin, but there's no reason that the compiler won't run natively on Windows; it's text only.

You get to write them! :) (or use libusb)

Drivers are outside of the scope of this project. You can make the stack do anything, so there can't be one driver for it. (Except for libusb.)

That said, I use libusb, for my stuff (in case you couldn't tell). And if you want something higher-level, you can look at cstyx.berlios.de and estyx.berlios.de.

It's occurred to me that I might combine these all to make a complete USB comms package, which is how I use it anyway. But I like to keep things as modular as possible, to start with.

Yes, but you can only do so much with FTDI's chips. That's rather a lot, of course, but sometimes you want more.

For instance, can you do an audio device with FTDIs? Probably, but I think it would be difficult. Can you make it class-compliant? That may be impossible ...

Not any more. God has given us libusb. :)

So it would be -- also much less flexible.

I don't expect it to conquer the universe, or even to get used :) -- but it's there if anybody wants it.

--mpa

Any idea where to get a Virtual Serial Port driver? I know there are commercial offerings, but maybe there is a 'libVSP' somewhere?

--Rocky

Sadly, and stupidly, there is no USB class spec for USB-to-serial-port adapters. So all USB-serial adapters use different protocols, and require matching drivers.

So the answer is that it depends on what chip and / or firmware you've got. There can't really be a "libVSP" that works for any serial adapter (well, not practically).

Most companies that have USB-serial chips also offer virtual COM port drivers.

(By the way: PORUS can help you if you want to make a new serial port adapter, but it doesn't do the work or protocol for you. It doesn't speak any particular protocol -- it's just a stack.)

--mpa

Yes, it's when you want to use the virtual COM port for your own (commercial) ends that this becomes a bit if a problem. TINSTAAFL I guess.

--Rocky

Fair enough license.

I was just thinking about going beyond approval, and actively supporting you (of course, I have no idea how much they support you at the moment - these things vary enormously from company to company). The typical company thinking is that employees should do work that is of advantage to the company (understandably enough), and thus should not spend company time working on an open source project unless the results are useful to the company. If they view your work on the project as being beneficial to them (through more external contributions that they can re-use), then they'll pay you to work on it beyond the requirements of your company's current use. Of course, it depends on your company, it's requirements, your interests, and a hundred other things.

A USB device on its own is useless without drivers. On windows, the device driver development far outweighs the embedded device development for many projects. You might want to develop using linux (I gather usb device drivers are much easier to write for linux than windows), and support linux for the product, but most products will also need windows support in the market. That's why I see it as two parts of the same system.

I see there is also a port of libusb to windows - perhaps that's the way to go for a consistent cross-platform development that can be done without the need for low-level driver development on either windows or linux? I must have a closer read of this stuff some time.

Indeed - FTDI chips do a specific job, but do it well. So far, it's been enough for me in real projects, but it is easy to imagine projects for which the chips are too limited.

Then I'd hate to think who ported it to win32 !

I don't know whether I will ever use it or not - but thank you anyway.

mvh.,

David

Not at all -- FTDI and TI will both let you redistribute their COM port drivers. They like this -- it helps them sell chips. :)

--mpa

Don't worry about that -- the project is definitely useful to the company.

If I were selling this thing, I'd probably do something like that, but I'm not. And there are already commercial USB stacks out there anyway.

That's what I use on Windows -- libusb-win32.

It may look rough, but there are commercial products that use it. It's been rock-solid for me.

You're not so easy to please, are you? :)

cheers --mpa

you

Hi Data, I actually want to use the VCP drivers with hardware / software other than FTDI. e.g. VCP to ethernet, or VCP to other hardware.

--Rocky

By "virtual" do you mean "a UART attached by a bus other than ISA or PCI", or do you really mean virtual (as in there isn't actually a hardware serial port at all)? There's no reason you couldn't write one driver that would handle both cases, but historically they've always been treated separately.

The Linux tty driver is the standard virtual serial port driver.

Drivers for non-ISA/PCI-attached serial ports all tend to be product-specific. You can generally get source code for them, but from what I've seen, converting them for use with other products isn't going to be easy/fun.

Not that I know of, and I've spent a fair bit of time working on such things.

What the world needs (among other things) is for the pty driver to be fixed up so that it supports a larger subset of the "real" serial port API. Right now it throws away some of the termios bits and doesn't implement any of the TIOCM* ioctls at all. If it were fixed to fully support termios and TIOCM* ioctl stuff, then you could implement a serial port in user-space fairly easily using the pty devices.

--
Grant Edwards                   grante             Yow!  TATTOOED MIDGETS
                                  at               are using ALFREDO in their
                               visi.com            SALAMI FACTORY!

^^^ pty

--
Grant Edwards                   grante             Yow!  Let's climb to the
                                  at               TOP of that MOUNTAIN and
                               visi.com            think about STRIP MINING!!