The car player, for example, is definitely The [censored].

And all sorts of rap-inspired variations, such as "Tha Shiznit", "Tha Shizzle" and, my personal favorite, "Tha Shiz-nizzle."

Back on topic...

The ideal solution would (of course?) be that the empeg player has both an ethernet "emulation" and a storage device "emulation", that way, it could be mounted as a "harddisk" on quite a lot of OS platforms.

Wouldn't this require writing two win drivers. To have the camera appear as two different devices windoze loads two sets of drivers and they appear in teh system properties as such. Although it would be cool, it's a bit out of the scope of this project.
Having a set of drivers loaded on the empeg itself would be great. plug the player in and it gets recognised as a riocar audio player, USB ethernet device and an external hard disk. Where are the drivers for the hard disk device stored? On the player itself which is accessed in the setup process through the TCP/IP address which was loaded earlier!

Now that's the Da Pantsshizzlenit!

Yes... as seen from windows, the still-picture camera and the video camera are two separate "devices".

For the empeg, we won't write any windows drivers, we'll use the generic mass storage for "disc emulation", we'll use an existing ethernet driver for "ethernet emulation" and we'll use the emplude-supplied drivers for empeg-USB.

*Windows will then "think" that there are three separate devices connected.

(A conditional "will, if this project is implemented the way I think is the best way to implement it")

Marius (Escort Cab + Mark II)

I saw this Movie last week.

I tried to watch it in English but I couldn't understand most of Brad Pitt's sentences....

Anyway this movie isi very very good and funny !!!!

I tried to watch it in English but I couldn't understand most of Brad Pitt's sentences

That's alright, neither could us Brits !

Perhaps, but it certainly existed and was fairly widespread, and is vastly more interesting than anything we Americans ever came up with.

Though a USB device can have multiple profiles, only one can be active at any one time (as far as I'm aware, anyway!). So you'd have to choose which one you wanted (maybe with a hijack menu).

The mk2 has softconnect, which means in software we can simulate a bus disconnection/reconnect, which should mean you wouldn't have to unplug the cable when switching profile.

The disk profile is going to be the easiest to start with. You won't need to mess with a lot of the usb driver - the enumeration should be fine, for starters.

Hugo

I think it's so cool to see Hugo here offering tips. This is a really cool idea for a project and I'd like to see it work. One thing, though:

The mk2 has softconnect,

Which is nice, but it's the Mk1 owners who would benefit the most greatly from this project.

Somebody else suggested that if we emulate a USB Hub, then we might also be able to emulate (simultaneously) all three "devices" attached to it: (1) Empeg/RioCar, (2) Mass Storage Adaptor, and (3) USB-Ethernet.

I'd leave the hub thing for later, though. Get something simple working first, like the Mass Storage emulation. But then, {b]I am not working on this particular project.

-ml

Emulating a hub and downstream devices would be hard; the USB controller only responds to one device ID programmed into the address register.

I don't think changing the ID on the fly is possible. You're going to have to pick one and just be that device I suspect.

Hugo

With the three options of what it shows up on the USB as:
1 - Empeg custom device (as normal)
2 - Ethernet adapter
3 - Mass storage device
I can see where it might be helpful to have 2 & 3 at the same time, but it seems like it would be a very minor inconvenience to have to reboot to change between the two. With a reboot time of <10s, it's on par with Windows normal USB detection times for a device that's already on

If option 2 were implimented, would there be any advantage to switching back to the default (1)? I only ask since someone posted the desire and I can't figure out why.

Since I've got a Mk2a, I'm not as interested in option 2 as I am in option 3. But I think there's more Mk1 owners who would rather have option 2 than there are Mk2[a] owners who would want option 3. I probably wouldn't even use option 3 since that would mean physically close proximity of my empeg to my PC (and crawing around behind to plug in the USB cable).

This may be way off base with what is trying to be acheived, and not as neat... But how about a USB<>Ethernet converter?

Something like an SMC
:-
http://www.smc.com/index.cfm?action=products_show_datasheet&productCode=SMC2206USB/ETH

http://www.smc.com/index.cfm?action=products_show_datasheet&productCode=SMC2208USB/ETH

http://www.smc.com/drivers_downloads/library/SMC2208_DS.pdf

They are getting small and compact... US$30 from outpost.com

http://shop1.outpost.com/product/3237311

SMC do win and linux drivers for it. Not totally platform independant, but not too shabby...

I use a older larger version for my ADSL, and it works well...

I know some are also using a combo wireless media converter (into the empeg/rio ethernet port whilst in the car sled), 802.11 card and wireless gateway , to synch while the player is still in the garage, and also optionally scare the crap out of someone walking by the office when it's in the carpark, and you turn it on and blast an appropriate tune - as I do works well... similar idea....

Thoughts ?

Cheers,

Kieran
OZ

The empeg USB port is a slave port, not a master USB port, which a USB->Ethernet adapter requires. This device would not work on the empeg.

It's in the faq here

Even if one of the adapters were able to work... It would defeat part of the purpose of this thread. Not everyone has a network. Not everyone has any form of ethernet at home to connect to.

The idea behind the thread is to be able to use the networking protocols over a USB connection. That means not changing that USB connection to something else.

Bruno

Sorry gents... Should have been clearer. Other way around.

The USB end plugs into the USB port on your PC. + a quick driver install on your PC. The ethernet end is a jack which you plug a small patch lead straight into the network port on your empeg/rio. The USB<>Ethernet adapter simply shows up like a LAN connection.

Normally I guess you would think of it, as a portable LAN card for your USB only PC, but since they've got so small cheap and portable, for this purpose, it is more like - take it around with your peg and plug it into someones USB port, and you then have all the LAN connectivity you want (at USB speed).

Not as nice as doing it without the little piece of hardware, but once connected and the quick driver install (it is really quick and easy), functionally it like your peg is connected directly to a LAN card as far as the PC is concerned.

You could even blat out a little auto-execute 8cm minicd, yu can leave in your case that installs the driver, and set's the local lmhost and IP or whatever. And you have a quick easy plugin. Good if you are at a party and their music is pants, but you don't want to frig with their network setup (or they may well not have a card).

From there you have your streaming XML playlists, your webserver, install seeds for java and java emplode - your hot to trot

Anyway, just a thought. it may be off thread as far as cool programming, but the result would be much the same.

Cheers

Hi.

The result would only partly be the same. One of the goals of this project (has anyone actually started programming it?) is to get IP-only functionality (esp. FTP/HTTP) to a MkI. The MkI does not have any Ethernet port, so the only way to get IP to it is via PPP (wether over serial or USB is only a matter of speed) or through the emulation of a USB-to-Ethernet adapter on the empeg's side.
In other words, the goal is to get Windows (and possibly even Linux) to think that the empeg is actually a USB-to-Ethernet adapter that is in turn connected to the ethernet port of an empeg (even though the MkI doesn't actually have an Ethernet port).
A more complex, but even better solution would be to have the empeg emulate a USB hub which is connected to an empeg (for "classic" emptool/emplode USB connections) as well as to a USB-to-Ethernet adapter (for pseudo-Ethernet connections to the empeg). Using ASCII graphics to illustrate it, it would basically look like this:

                             +----------------------+       

                             | +-----+  +---------+ |       

                             | |     |--| USB2Net |*|

 +----+                      | | USB |  +---------+ |

 | PC |--- USB connection ---+-| HUB |              |       

 +----+                      | |     |  +---------+ |       

                             | |     |  | empeg   | |       

                             | |     |--| USB     |*|       

                             | +-----+  +---------+ |       

                             +----------------------+       

                                                            

where the big right box depicts the empeg, the boxes        

inside it only show "virtual" devices the PC sees. The

"*" characters stand for Linux device nodes (one serial

device, one ethernet device).

Yes, that would be my ideal solution for this project, but it is well beyond my abilities to implement that.

cu,
sven

Yeah, sure, if you don't have a Mk1 then you will get an ethernet connection on a machine that doesn't have an ethernet card this way. The beauty of this software solution though is that:
1) you don't need to drag yet another bit of hardware around with you
2) if it works the way most people thing you won't need to install *any* software or drivers on the host PC
3) it won't cost anything except a little of our time
4) it will give Mk1 owner s access to a lot of the really cool features in Hijack and Jemplode, and at a much higher speed! Do you know how slow the serial connection is?!

And once someone has cracked the tcp/ip over USB stuff it is not so much harder to start getting things like disk mode working. A nice easy to use file taxi! Again without need for extra drivers/software. You won't even have to learn any FTP commands if you are illiterate. Now that is cool :-)

(And I'm sure someone else can thing of some other good reasons to go with this!)

Not much point in that. a real ethernet interface is cheaper, and better in most respects.

Hmm, has the code been done already?

We've got a sharp zaurus here. It's a StrongARM PDA running linux that does Ethernet over USB.

On my desktop i run either a patched CDCEther driver that gives me an eth1 interface, or with newer zaurus software you use the usbdnet driver which give me a usb0 ethernet interface.
(Not sure if the usbdnet driver is in the stock kernel tree, but mandrake 8.2 ships with it)

Now the source for the linux kernel on the zaurus is at http://more.sbc.co.jp/slj/source/source_dl.asp (may require registration)
Perhaps you can just grab the ethernet over usb driver from there?

I don't think anything s being done, no...
Does the Sharp have a slave or a master USB?
When you connect it to a PC, what does it show up as?

Marius (Escort Cab + Mark II)

I presume it is a slave.

When i plug it into my linux box it goes:
hub.c: USB new device connect on bus1/2, assigned device number 51
CDCEther.c: detected BULK OUT packets of size 64
usb.c: ignoring set_interface for dev 51, iface 0, alt 0
CDCEther.c: eth1: SL Series 40:00:02:00:00:01Apr 5 17:41:39 ou119028 kernel: usb.c: USB device 51 (vend/prod 0x4dd/0x8004) is not claimed by any active driver.
/etc/hotplug/net.agent: invoke ifup eth1
/etc/hotplug/usb.agent: Setup acm CDCEther.o.gz.bak CDCEther for USB product 4dd/8004/0
/etc/hotplug/usb.agent: missing kernel or user mode driver acm
/etc/hotplug/usb.agent: missing kernel or user mode driver CDCEther.o.gz.bak
/etc/hotplug/usb.agent: Module setup CDCEther for USB product 4dd/8004/0
CDCEther.c: eth1: set multicast filters
CDCEther.c: eth1: set too many MC filters, using allmulti

The newer firmware builds cause my linux box to load the usbdnet driver instead of the CDCEther driver.

Here's the lsusb output for it:

Bus 001 Device 051: ID 04dd:8004 Sharp Corp.

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               2.00

  bDeviceClass            2 Communications

  bDeviceSubClass         0

  bDeviceProtocol         0

  bMaxPacketSize0         8

  idVendor           0x04dd Sharp Corp.

  idProduct          0x8004

  bcdDevice            0.00

  iManufacturer           1 Sharp

  iProduct                2 SL Series

  iSerial                 0

  bNumConfigurations      2

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           73

    bNumInterfaces          2

    bConfigurationValue     1

    iConfiguration          3

    bmAttributes         0xc0

      Self Powered

    MaxPower                0mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           0

      bInterfaceClass         2 Communications

      bInterfaceSubClass      6 Ethernet Networking

      bInterfaceProtocol      0

      iInterface              4 CDC Ethernet Comm Interface

  unknown descriptor type: 05 24 00 10 01

  unknown descriptor type: 0d 24 0f 05 00 00 00 00 ea 05 00 00 00

  unknown descriptor type: 05 24 06 00 01

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        1

      bAlternateSetting       0

      bNumEndpoints           0

      bInterfaceClass        10

      bInterfaceSubClass      0

      bInterfaceProtocol      0

      iInterface              6 CDC Ethernet Data Interface - Disabled mode

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        1

      bAlternateSetting       1

      bNumEndpoints           2

      bInterfaceClass        10

      bInterfaceSubClass      0

      bInterfaceProtocol      0

      iInterface              7 CDC Ethernet Data Interface - Bulk mode

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x01  EP 1 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x82  EP 2 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           32

    bNumInterfaces          1

    bConfigurationValue     2

    iConfiguration          8

    bmAttributes         0xc0

      Self Powered

    MaxPower                0mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           2

      bInterfaceClass       255 Vendor Specific Class

      bInterfaceSubClass      1

      bInterfaceProtocol      1

      iInterface              9 Simple Ethernet Data Interface - Bulk mode

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x01  EP 1 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x82  EP 2 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Language IDs: (length=4)

     0009 English(English)

This looks promising... But just to be sure...
Can you connect the Sharp via USB to anything other
than a PC? I suppose they don't use the standard plugs, so that's nothing to go by...

My real question is wether the Sharp->PC cable may contain electroncs, like those USB-laplink-cables that are available.

I'll download the sources and hava a look.

Marius (Escort Cab + Mark II)

[email protected] wrote:


This looks promising... But just to be sure...
Can you connect the Sharp via USB to anything other
than a PC? I suppose they don't use the standard plugs, so that's nothing to go by...


Hmm, what else would you connect it to?

The zaurus plugs into a cradle, and the cradle plugs into the PC with a USB cable.

I think you can get cable to go straight from the zaurus to the computers USB port.

My real question is wether the Sharp-&gt;PC cable may contain electroncs, like those USB-laplink-cables that are available.

Could do, there might be something in the cradle...

But the fact that a firmware upgrade changes the type of device it appears as counts against that i think (but then i'm no expert)

OK.. totally off topic, and I hate myself for it, but does the Zaurus kick a$$? I'm thinking about getting one ...

I don't think anything s being done, no...

Actually, I've been working on this, and I've gotten pretty far along, but not anything near useful ... yet.

It's very cool

I wouldn't get the developers version, SL5000, that only has 32Mb. Get the newer retail version SL5500 it has 64Mb. With 32Mb its partitioned as either 20Mb application heap and 12 Mb storage, or 26Mb heap and 6 Mb storage. So either you run of heap or you have no space for files.

You can get around the storages space with a SD or CF card. The zaurus if good cause it has both a SD and CF slot built in. It's about the size of the ipaq, a little smaller i think, but with the ipaq you have to add bulky sleaves if you want to add a CF card.

Having both a SD and CF card means you can pop more RAM into the SD slot and still have the CF card free for a wireless network card or other expansions. I heard a wireless network card sucks allot of battery juice though.

I think it's a shame that it doesn't have a proper speaker, it's got a buzzer for alarms, but if you want to play mp3s or have sound effects in games then you have to plug headphones in.

That's about all the complaints i have... not as many apps as for palm or wince of course, but they seem to be appearing pretty quick, and if you need any of the usual linux tools you can just grab them from the debain arm distro...

The zaurus is basically binary compatible with the familiar/qtopia setup that people run on ipaqs so hopefully that will stimulate more apps with a common bigger market.

The screen is very good,64K colours i think, and im getting pretty good at the handwriting recognition, i can't decide if it's quicker to use handwriting or the pullout keyboard.

rc5 client doesn't pause itself when running on battery power like it does on my x86 laptop

We got it for developing Java stuff on and the Jeode java runtime looks pretty good. Basic AWT apps take about 4-5Mb not much more than native QT apps.

Thanks for the review.... I'm really interested for the Java support also -- To see a PDA that comes stock with a nice VM is great. I tried Jeode out back when it first came out (before they had AWT support). How is it now? What's performance like? I have a couple master plans (non-Empeg-related) that I'd love to execute if I got one Mike

Well we haven't actually programmed for it yet, still playing with it

It ships with a couple of basic demos, of the drawing circles all over the screen variety. The seem to perform OK, but i've yet to see the performance of a "real" app.

There are some Java apps people have released for the zaurus, a few board games and the like, so it's definately useable.

Here a couple of java app screen shots:

It looks like it is a slave device according to the zaurus FAQ
After scanning the zaurus kernel source, it seems the Zaurus is using the internal SA1100 USB slave-port.

Not sure if this is useful but lineo have released their USB *device* stack for linux (as used by the zaurus). Wouldn't the mark2 have one of those already?

http://www.linuxdevices.com/articles/AT5124708001.html

They include implementation of a USB network function driver.