Emax

have you considered utulizing the printer port on a pc to make the data transfer into the rs-422 port on the emaxII?
I've got a cord with a male printer port plug on one side and a female serial port plug on the other.

--- In emax@yahoogroups.com, Ted Summers <djtbs1@...> wrote:
>
> Well, for the person who is going to build the interface board- what  
> about using the clock out from the emax as input into the clock  
> circuit of the UART on the interface board to be built?
> 
> Would that make it synchronized?
> 
> Regards,
> Ted
> 
> 
> On Nov 26, 2008, at 1:41 PM, esynthesist wrote:
> 
>  >>>>One thing - you already have EII comms working with a standard
> off the shelf USB connector, don't you???
> <<<<
> Yes I have, but it works only for sending banks from the EII to the
> PC, not the other way around, due to the synchronization loss...
> which was the reason why I posted this RS422 questions to Emu
> groups :-)
> 
> I you'd like to have the example C code I used for this and/or for
> the Emax bank unload, I can send them to you.
> The Emax code "works" but as I mentoned before the communication gets
> out of sync after receiving about 40 datapackets, due to the lack of
> sync comm.
> The code contains basically the port configurations (baudrate,
> parity, ...) and the open/read/write/close instructions to perform
> the actual communication. It uses the standard serial communication
> library of Microsoft (Visual C), based on things like DCB
> configuration. In these communication libraries I haven't found any
> structure/function yet which allows to set the baudrate to "external
> clocking" instead of a "number" (internal clocking).
> But perhaps the provided software with your device can be driven in
> another way, allowing for other parameters sent accross the USB
> serial class.
> 
> ...So we stay "on" topic in this board with the Q&A about RS422 and
> the experiments to get the thing working for Emax ?
> 
> ///E-Synthesist
> 
> --- In emax@yahoogroups.com, mr julian <jujulilianan@> wrote:
>  >
>  > first up, I know NOTHING about the windows driver side of this... I
> just
>  > installed a driver that was supplied with the firmware, and I can
> see
>  > that in windows system, it's come up as a generic serial port, with
>  > settings for:
>  >
>  > Bits per second: (75-128000)
>  > data bits: (4-8)
>  > parity: (odd, even, none, mark, space)
>  > stop bits: (1, 1.5, 2)
>  > flow control: (Xon/Xoff, hardware, none)
>  >
>  > Also, I can open and close this port in hyperterminal, and adjust
> the
>  > settings in hyperterminal....
>  >
>  > Now, I imagine that wheen it is connected to my PC, this port gets
>  > listed somewhere inside windows in an appropriate place, and
>  > applications looking for serial ports find its information, and can
> then
>  > request to connect/disconnect, and and send config information -
> just
>  > like any other serial port.... but if I needed to add extra
>  > functionality, like a synchronous BPS setting, I have no idea where
> to
>  > put that... but maybe I could find out?
>  >
>  > I'm still waiting for the 422 chips, so will start seeing what I
> can
>  > find out about the driver, and the application-driver interface,
> plus
>  > the driver-board interface. and see what would need to be modified
> to
>  > make this do exactly what we want.
>  >
>  > But yeah. my ideal finished product would be a USB connected board
> that
>  > connects to a PC, and windows sees it as a standard serial
> interface
>  > with standard interface parameters including synch/asynch control
>  > (whatever standard for that is!) and your program could therefore
>  > connect to it just like it would connect to any other serial
> interface,
>  > and work with it the same way for any sampler....
>  >
>  > Also, I'm not interested in holding any kind of IP here - I'm
> really
>  > just mucking about with configuration and possibly making small
>  > adjustments to existing open-source code...... if I create a
> solution,
>  > I'll provide all assembly instructions/code completely open for
> anyone
>  > who wants to use it however they wat.
>  >
>  > One thing - you already have EII comms working with a standard off
> the
>  > shelf USB connector, don't you???
>  >
>  >
>  >
>  > anyway - we should probably take this discussion off-list. it's
> getting
>  > a bit OT for the emax community in general I think.
>  > :-)
>  >
>  >
>  >
>  > esynthesist wrote:
>  >
>  > >OK :-)
>  > >What are the parameters that *can* be changed with the standard
>  > >driver ? Nothing ??? Isn't it possible to define parity, or
> clocking
>  > >by software? If this is true, how can you change these parameters
>  > >then ? I'm not sure I understand.
>  > >
>  > >I mean: as soon as I can write a piece of C-code (based on sample
>  > >code provided by you of course ;-), which uses the standard USB
>  > >driver library, but which contains specific Emax code, that's fine
>  > >for me; then it's just a matter of writing another piece of code
> for
>  > >each Emu sampler we want to support. I was not hoping for more.
>  > >But if the *hardware itself* is built in such a way that it only
>  > >supports the Emax, then we would need another piece of hardware
> for
>  > >the Emulator II, and that would be a shame...
>  > >
>  > >But I guess it will all be software-driven, right ?
>  > >
>  > >///E-Synthesist
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
> 
> 
> 
> 
> 
> [Non-text portions of this message have been removed]
>