Anyone got any bright ideas for putting multiple serial ports into the empeg? I have a feeling that I'm going to run out as soon as my bgmicro.com order arrives. Ideally (for me), It'd be nice to be able to add 2 more serial ports. That would give me 2 ports for projects, and still allow one for shell access. But I'd settle for one more.

The only real idea that I have at the moment is to use one of the ethernet-based serial multiplexers that are sold for remote console access - but I'm not aware of any cheap options here.

I too will have this problem soon but was thinking DIY. I was considering multiplexing the inbuilt serial port ala terminal server. Then it would be a case of special device drivers and some brains in the external unit.

The main problem is a micro with enough serial ports. To have 3 ports in total (including the original which gets used) you'd need a micro with 4 serial ports.

Ethernet based ones are probably a little overkill but would be quite easy to use from custom software. i.e. instead of opening a tty, you open a socket instead.

I wonder whether it would be possible to run the usb protocol over serial and simply have some hardware solution that converts the serial level signals into usb signals. Will probably still require some controller to get rid of the start and stop bits etc. But it should allow more things besides additional serial ports. (mouse/keyboard/really slow mass storage device)

If you're thinking [empeg usb] -> [usb<->serial mulitplexer] then the following may have a bearing:

The empeg USB port is not a USB host, only a device. I'm not a USB expert, but I believe that means it cannot initiate communication. That'd mean that we'd need a hijack hack to implement a new device type for the mulitplexer to speak to, and the multiplexer would have to handle intiation etc.
It would also require a physical sled hack to add a USB connector. (But so would an ethernet device).

If you're thinking:
[empeg-serial] -> [serial <-> USB multiplexer]
then we'd then need serial-usb converters for all serial devices. There would also be a bandwidth issue.

But if we're talking about implementing an external hardware device to do this, maybe we should consider a system on chip board. Overkill for just serial ports, but it would open up a lot of possibilities for e.g. additional display - broadcast the current display via UDP.

I was thinking [empeg serial] -> [serial <> USB multiplexer].

Considering the fact that most serial applications for in the car run at moderate speeds (4800-9600) and the empeg's serial can push up to 230Kbps without any special hacks, the bandwidth issue shouldn't be that bad. Timing issues maybe, but that is what the usb host controller cpu should solve.

I was mostly hoping there was some cheap embedded CPU with an USB host controller, but it looks like most embedded CPU's with USB only have a device controller.

But the fact that serial -> serial mux would require special kernel hacks anyways, and then we're still limited to the fixed number of serial ports that the hardware supports, with usb it can scale moderately. Also considering the fact that a max233 is between $5-10, so a usb dongle is not that much more expensive.

Ok... I just did a browse of linux-friendly System-On-Chips, and yes you can get some that have host USB. But the problem then becomes one of manufacture. Most are BPGA - ie machine solder only...well, I suppose we could try a toaster oven That'd leave pre-manufactured development boards - but $300-$400 is more than I think most people would stomache. Unless of course, Patrick, Mark, Peter and others got on board and it turned into a committed effort to build an Offical Unoffical Empeg Extender with an aim to make a return on the investment. (ie use the capabilities to drive other displays etc.)

The other drawback of that is the development time. My guess is that with a committed effort by such a group, we'd be highly unlikely to get anything usable within 12 months. Getting that kind of committment would probably take 6 months alone. (And then Mark's nearly back into climbing season!).

Hmm, do any of the PICs have USB host capabilities?

I googled for embedded USB host controllers and there are a bunch, one of which actually has linux drivers and costs ~$9 on digikey, the Cypress SL811HS.

It doesn't have it's own CPU, so it would still need some $5-10 CPU that we could control over the serial port to twiddle it's lines and such. Or write the host controller directly into the system, but that's more hacking than I prefer to do with my (quickly becoming) irreplacable empeg.

The StrongARM already has three serial ports. Not entirely sure how you'd get them off-chip to D-9 connectors, though.

The StrongARM already has three serial ports. Not entirely sure how you'd get them off-chip to D-9 connectors, though.

One of them is used to talk to the tuner module. And isn't the third one used for IrDA?

Peter

I guess one is already going to the tuner, the other is used by the existing serial port so that leaves one free. However, I really don't want to do any potentially damaging hardware hacks to the inside of the empeg.

Just saw peter's reply. Yeah, IRDA would definitely need a serial port as well, so I guess all three are already accounted for.

Which reminds me...

Whenever I slide my empeg into the sled it scrapes past the dimples/bulges, and I noticed the other day that fine metal scrapings were collecting on top of the connector. My guess is that this could wreak havoc when it actually gets anywhere inside of the player.

Has anyone ever noticed something similar, and what did you do. For now I'm wiping it off whenever I pull the player out of the sled, just to be 'safe'.

The inverse dimples (or whatever you want to call them) certainly mar the finish of the empeg's case, but the only time I've ever seen anything that could lead to actually removing metal from the case was when I had taken out the sled and reinstalled it, but the triple-flexing of the tabs had caused one or two of them to stick further into the case than they should (that is, at all). bending them further out solved that problem. Is it possible that that's the problem you're having?

It is actually the sled whose metal is slowly being removed, the empeg probably was made of a higher quality steel I guess it could be because of the head unit that is mounted above my empeg sled which might be blocking the dimples from flexing upwards.

I've got a Subaru, so getting the sled in there involved some reasonably heavy handed fitting and dremeling of various parts. The empeg sled is about 5-8mm wider than both the head unit above it and the stuff below it. Initially I wanted to put the empeg in the top position, but that didn't work out at all, as the frame wouldn't even fit in the dashboard.

I remember somone posting a few months ago a serial hub of sorts. I would search for it, but my searching skills on this bbs are not to great. I think it allowed between 6-12 additional serial ports. I forget how exactly it worked, but it would connect to the main serial port, and allow many other devices to connect to the serial hub.

The player should slide in and out of the sled very gently, without scraping. If it is scraping and there are metal shavings being generated, you need to look closely at the installation and find out why the sled is bent, then correct that problem.

Yes, I know the scooby installs are tough. You might have to knucle down and do more dremeling.

Hmmm. I did the installation in a WRX and while it wasn't the easiest thing to do, it worked out perfectly. Frankly, I followed the directions posed by a couple of members on this board and made a few modifications along the way. I started by doing a search on "WRX" and read and reread everything. Thought about it for about 3 weeks and then jumped in. Look around and you might get some tips that will enable you to tackle it again.

My first choice is still a networked terminal server. For people who don't already have a hub in their car, just a crossover cable would do. But it still means modifying the sled so that the ethernet port is available when docked.

The part that I couldn't get past (ok, it's been >6 mo since I checked) is that none of the terminal servers come with driver source code or linux binaries. The way I'd want to use one is to have it plug in to the network and have special device files that map over the net to the serial ports on the terminal server. The huge advantage of doing it this way is that you don't need different software for people with a terminal server than for people using the built-in serial port (just a config option to specify which /dev/tty file to use). But without drivers, it's a bit more difficult.

Quite some time ago, someone posted a link to a mini terminal server that came with instructions on writing your own TCP code to access it over the network. If someone (or a team) wanted to write code for that, then we could all buy the same unit and have a working solution.

I don't (yet) have need for another serial port, but with the progress of the GPS project and the news about the upcoming release of OBD-II codes, I'm sure I'll want more serial ports eventually.

In reply to:

---

...The way I'd want to use one is to have it plug in to the network and have special device files that map over the net to the serial ports on the terminal server. The huge advantage of doing it this way is that you don't need different software for people with a terminal server than for people using the built-in serial port (just a config option to specify which /dev/tty file to use). But without drivers, it's a bit more difficult.

---

Yeah, this approach would be desirable - regardless of hardware type.

In reply to:

---

Quite some time ago, someone posted a link to a mini terminal server that came with instructions on writing your own TCP code to access it over the network. If someone (or a team) wanted to write code for that, then we could all buy the same unit and have a working solution.

---

Don't remember seeing that. Can you find the link and post it here? What was the pricing? My feeling is that if there is an OTS terminal server of 3+ ports that is under ~$75 then it's almost a no-brainer.

Quite some time ago, someone posted a link to a mini terminal server that came with instructions on writing your own TCP code to access it over the network. If someone (or a team) wanted to write code for that, then we could all buy the same unit and have a working solution.

I remember a discussion from March... smu referred to a unit with sources, but I'm not sure which one he was referring to.

Most of the term servers are expensive. For DIY types, I wonder about the feasibility of combining a multi-serial flash SBC like this
with term server code like this gen't's

Don't remember seeing that. Can you find the link and post it here?

Maybe I just don't know how to search... all my posts have "--The Amigo" at bottom. Searching for "amigo terminal" results in zero matches, yet searching for "terminal server" shows a few hits that also have my .sig... does the search not include .sigs?

Anyway, here's what I've found:

A thread about making smart serial devices that could daisy chain.

The one I was really looking for is the thread about TINI. I couldn't remember what it was called so it took me a while to find it.

There's also this very promising thread that links to a product which says they offer source code so you can compile the drivers on Linux. But the thread also says its expensive. I didn't see prices on their web page so I don't know if it's changed.

In reply to:

---

Net Link for UNIX (EDAS-1003S-5)

* Source code provided
* Can be ported to any variant of UNIX, including Linux

---

In reply to:

---

There's also this very promising thread that links to a product which says they offer source code so you can compile the drivers on Linux. But the thread also says its expensive. I didn't see prices on their web page so I don't know if it's changed.

---

Yeah, I just pseudo-registered....$400 and up....Not going to happen.

It occurs to me that we probably don't need the full-on industrial solutions that support hardware flow control. I'm guessing that just about anything we'd want to connect to our empegs would only require 3 wires - TxD, RxD and Gnd. (GPS, laptop, handheld, OBD etc..)

Could we do something fairly simple with a couple of UARTs, a MAX238 and a PIC ?