Yahoo Groups archive

Emax

Index last updated: 2026-04-28 23:23 UTC

Thread

Re[2]: [emax] OT: Re: RS422 fun

Re[2]: [emax] OT: Re: RS422 fun

2008-11-28 by tu@...

There are actually two interfaces being built. One is a custom built one piece USB-RS422 converter and the other is a two piece solution using an off the 
shelf USB-RS232 (or RS422) converter and a custom built RS232-RS422 synchronous/asynchronous baud rate translator. They are different 
implementation approaches but the outcome should be more or less the same.

I am looking into the second approach and plan to use the same UART that is used in the Emax/Emax II. The Emax side of the RS232-RS422 converter 
will use the external 500kHz clock from the Emax to generate both the x1 synchronous clock and the x16 asynchronous clock. The the exact same 
synchronous mode is not available on all UARTs so you need to read the product documentation carefully. It is essential that the clock to data 
relationship is correct when sending synchronous data to the Emax in this mode or you are up the creek without a paddle!

/Tristan 

Thursday, November 27, 2008, 7:51:37 AM, you 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
Show quoted textHide quoted text
> >the Emulator II, and that would be a shame...
> >
> >But I guess it will all be software-driven, right ?
> >
> >///E-Synthesist
> >
> >
> >
> >
> >
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.