Good point on the distance, PJ. I'll have to more seriously consider an Ethernet port. As with all projects, new ideas will replace or supplement old ones.

In this case, it will partially depend upon how I mount the HD. If I choose to semi-perm mount it (screw it down to rails), I'll need a reasonably fast connection, but potentially a long one as well (I can see people all over the world running CAT-5 out of their windows to the car for uploads ;) ). If I choose more of a plug-n-play solution, such as a docking station, the distance issue becomes less of a concern.

However, the installation of a USB hub on the board would allow me to distribute smaller modules with USB ports around the car for various functions, as I hinted to in previous posts. Whether that extended functionality will be needed has yet to be seen. I could put both in with a reasonably small increase in cost, but why do both if they're mostly stepping on each other's toes...time will tell.

Even if you can't help with the design itself, the ideas and comments you guys are sending my way are extremely helpful in defining what the system should and should not be. Keep it up...

[QUOTE]Originally posted by MacGyver
[B]Good point on the distance, PJ.

I could certainly buy an SDK and use someone else's development work and time, but then I run into issues of licensing, etc. There's enough source code on the net, including the spec, to work out an interface, including the drivers. Since the datastream is very specific and spelled out in the spec, any compliant hardware should work with compliant software. The issue is spending the time and energy to create those drivers. If anyone comes across some freebie or GPL licensed drivers for the windows side of things, let me know. Open source is preferred, but I'll take black boxes if I have to.

i'll definately keep my eyes open for them... i often end up wandering the web looking for unusual drivers, while trying to fix some friend's fubar box.... :freak1:

what about linux based drivers? they are more apt to be open source... would they be adequate?

I'm pretty sure I have USB2.0 C code somewhere around here, so am open-source driver for Linux wouldn't provide any more detail. I would like to use a Windows driver to start off with, then I could port to Linux later if there was enough demand for it.

hrm. well, i know what you mean... but i wasn't clear. wouldn't the driver interface have to be on the USB side of the equation and not the ethernet side? i may not really understand the driver implementantion, but if you were to use the USB NIC w/ only USB ports on your device... wouldn't you need USB to NIC drivers on your device? b/c the PC would already see it as a standard ethernet connection?

sorry, i'm not trying to make any kind of point w/ this, but i don't know what other ways i could assist you w/ developing this sort of item. :(

Ah, I gotcha now...I think running a USB port emulating a NIC would be like going around your elbow to get to your ass ;) If both are supported, then the software must be there for both, so why not include both connector types and simplify the setup? Considering the disadvantages/advantages discussed above, the sensible choice would probably be an ethernet port if the HD is hardmounted, and a USB port if the drive will have a docking bay near the PC, although these are not hard and fast rules.

I think I have decided upon a Flash memory...I'm going to go with a 5V boot flash from Atmel. It's a 1M chip (64k x 16) at 55ns. The boot code will be programmed once and locked into memory. With the flip of a switch (or jumper), the boot code will either load the code currently residing in the chip into the DSP (normal operation) or will replace the code with a new set of instructions sent down by a PC link (I haven't yet decided what this link will be...serial, parallel, USB). As always, the trick with these is programming them for the first time ;) I'll have to rummage through my box o' stuff and see if I have any programmers that will do Flash (I have PIC and EPROM programmers...wonder if those can be configured for the job). Anyway, once the initial program is in there, I can make modifications and download them without worrying about mistakes...if I screw up, the boot code is never touched since it's locked.

I haven't yet determined how much memory I will use up with all of this functionality. In an ideal world it would all fit into on-chip memory, but the embedded world is never so kind. This means I need to find some sort of SBSRAM with reasonably fast access times and a low price.

I have done a bit of research on USB controller chips. I found a few that are reasonably priced ($5-$10), but I don't know if they will fit the bill. They include an embedded micro on them, so there is potential to write a bit of software to write directly to the HD instead of running through the DSP. Maybe I'll get really lucky and there will be some free SDKs (yeah, right) or source code out there (possibly).

lol... good analogy. (i think. ;) )

Been fighting with the schedules of my professors trying to get a defense date set up for my Master's, and looking for a job has taken up a serious chunk of time, so there hasn't been much progress lately.

I'm changing the Flash RAM to a 3.3V type instead of the 5V type. I'm so used to working with simple systems that have 5V processors, it seemed like the logical thing at the time. Upon closer inspection, though, the DSP is 3.3V, and a lot of the USB controllers are low voltage, as well, so I'm making the change. It's just as well since the 5V Flash chips are becoming harder and harder to come by.

The NEED for In-system programability has been a necessity and a requirement from the beginning, but HOW to accomplish that goal hasn't been so clear cut. JTAG is a simple connector to add to the board, but the emulators that attach to the connector start around $1500 and go up from there ;( A serial port is an inexpensive option, but terribly slow for programming, can't be used for debugging, and won't have much purpose on a finished product. A USB port is somewhat inexpensive to add ($10-20) and would prove quite useful in a finished product, but the learning curve is significant. Decisions, decisions...

Any accomplished PCB designers (or anyone know a friend of a friend) that would be willing to check out my board routes for EMI compliance once they're done? I'm positive the board will go through several revisions for modification of the component list and signal integrity, so any help between revisions is much appreciated.

I will be leaving for Purdue Sunday morning to defend my thesis...should be back by Wednesday. This project has taken a temporary backseat to the lighted windscreen project () since the windscreen project means money in my pocket in the short term. Working on something else has given my mind a break and allowed me to play with a few ideas in my head.

For one, I needed a way to install the DSP onto the prototype boards, but since it's a BGA package, soldering by hand isn't really an option. Also, I could use a boot block Flash RAM on the board which would allow subsequent downloading of updated programs...but the issue THEN was how do I get the boot block programmed to begin with. As I've found recently, many of the PCB houses will not only install parts (I knew that), but they will also program parts. So, if I have them install a few of the more difficult parts, such as the DSP and Flash, I can also have them program the Flash and make it ready to play with directly from the factory. Two problems solved in one shot with a minimum (hopefully) of extra expense.