smoerk wrote: A multi port wire speed switch would probably set you back about $20. In a remote recording environment, you probably would not be doing anything else on the lan. The pc is going to be hella busy dumping frames onto disks. -- Bob Knight [-w] the work option bk(a)minusw.com 925-449-9163

Bob Knight wrote: Fair enough, and an interesting project, though personally I'm more interested in doing a firewire device. Cirrus do some ARM 9 based SoCs with built-in Ethernet MAC. They run linux given enough flash & RAM, but eCos would probably be a better fit RTOS for this application IMO. They've got on-chip AC'97 interface too if someone wants to do a 2-in 2-out design, or to start with one whilst prototyping. I was thinking of clocking the data into and out of some D/As and A/Ds, ie solving the problem rather than moving it to the other end of a cable and putting a different connector on it. In case it wasn't clear the Converter Interface Engine on my block diagram is intended to clock data into and out of audio converters. The Dig Audio Interface header takes these signals off the prototyping board to make development cheaper and easier. I see now why you ask for something "GPIO like": You want to be able to put, say, 4 * 8-channel input modules on it to get exactly the I/O - or just the "I" in this case - that you require. OK. I'm employee & minority shareholder in a small company doing industrial embedded control h/w and s/w development. I've also worked on multi-channel audio I/O hardware in the past. So I could let myself into work on Sunday and start laying out a board if I wanted to, then I could get it built, then I could get it running. If it was worth the time and money. And if I could spare the time and money. I'm not claiming to know it all though and some help would be required. My FPGA experience is limited and out of date, I've never worked with firewire, I don't do analog circuit design (I can copy them though, and I can do mixed-signal PCB layout) and I've never worked on linux drivers. Part of my motivation here is to get some development experience in some of these areas. I've got relatively little time or money to spare which is why I'm looking for ways to make the initial development phase as quick and as cheap as possible without compromising a finished design. Some cheap early prototypes would also be essential for bringing other people into the s/w and ip development. Hopefully a running prototype would then attract the resources to be developed further. If not then the prototypes would still be pretty neat little FPGA dev & prototyping boards in their own right. Nice to own and possibly even sellable for that purpose. But like I said, I'm more interested in doing it over firewire. Cheers Simon

Marcus Andersson wrote: I think it would have to be a prototype card each. The development bottleneck would be making sure the first, physical prototype was basically correct. Someone would have to sit down at a bench with it and make sure the power supply was OK, get the dsPIC going, get it programming the FPGA, get some communication with the 1394 link going and get some basic end-to-end dsPIC to host over 1394 transfer going. Anyone wishing to collaborate at this stage would probably want to arrange to be in the same room while it was happening although crude telepresence (webcam/irc/voice) might be worthwhile if things got really stuck. Before the first prototype all collaboration would be electronic. Its just as easy to share a schematic across oceans as it is a body of code. After the first prototype a small batch could be made up and posted to interested developers and then its back to electronic collaboration again. The developer prototypes would probably have to be self-funded although it might also be a good time to see if a bit of money could be sourced from somewhere. Another per-developer expense here would be a debugger/programmer for the dsPIC, probably the MPLAB ICD2, currently @ 125UKP. The IDE is free but there's a question mark over the s/w toolchain. (Compiler/assembler/linker are gnu with source available, but the toolchain as a whole costs money. AFAIK its something to do with the C library being commercial). Oh, and there's A/Ds and D/As to consider. Probably ignore them at first and just stick a scope on the audio interface header, but sooner or later will have to get some sound out of the thing. <thinks for a while/>. Its probably worth putting a couple of mid-price converters on the proto board. Yes, this would cost money to develop. Hardware does. But remember, the early prototypes are useful little dev boards in their own right. I wouldn't mind paying to own one and I guess there are others who wouldn't mind either, including maybe people who aren't involved in linux and/or aren't involved in audio. Anyway, the "lets reverse engineer a driver for product X" approach also requires developers to actually buy the hardware. In both cases, I'd expect the people involved to be people who also had other reasons to want to own the hardware. Yes, and there's lots of additional costs involved in a production model, eg packaging, production engineering, CE marking etc. It would require the involvement of a business, or the developers would have to put on business hats. I'd be surprised to find anything combining dsPIC, FPGA and firewire. Buy a dev board for one and you'd still have to lay out the others. Might as well just lay out all three. This thing *is* a dev board which can be hooked up to audio converters. Cheers Simon