Emax

what you want is probably doable. It's definately do-able with the AVR,
but my issue is the PC driver side, and modifying or creating a driver
to send all the extra configuration instructions.

How about we try and see what we can do with a hard coded emax version,
and then see what we can do for the EII later?

that would be a great excuse for me to get an Eii......
:-P




On Mon, 24 Nov 2008 22:12:14 -0000, "esynthesist"
<esynthesist@...> said:
> I hope you can create a device which is not restricted to the Emax ! 
> If we could use the same device with the EII that would be awesome.
> 
> From a software developer's point of view, it would be really nice to 
> have a device which can be instructed by software to:
> - run with any supported internal clock rate (at least 31.25 kbaud 
> which we really need)
> - run with external clocking
> - use X databits, Y stopbits and Z parity.
> - (perhaps) use some timing parameters, like "max time between two 
> bytes" (but I'm not sure we really need this)
> 
> That's all I want :-) and it would be the most flexible solution, 
> capable of communicating with any Emu sampler supporting the RS422 
> interface.
> 
> I hope I'm not dreaming ?
> Crossing my fingers...
> Good luck !
> 
> ///E-Synthesist 
> 
> --- In emax@yahoogroups.com, mr julian <jujulilianan@...> wrote:
> >
> > 
> > 
> > tu@... wrote:
> > 
> > >Thanks, this protocol makes sense. No doubt Emu did it this way so 
> they could reuse the SDS sample dump code. Can you confirm that the 
> Emax 
> > >always waits for an Ack/Nak before sending the next packet? This 
> is important to know, as the buffering requirement is much lower if 
> we can be sure a 
> > >new packet will not arrive until after the last packet has been 
> handled.
> > >  
> > >
> > yeah..... that would make things really simple.
> > :-)
> > 
> > >A side effect of this is that when operating at 31.25k baud the 
> Emax UART is actually working in asynchronous mode. Synchronous 
> operation 
> > >only happens when the x1 clock divider is used. Therefore the Mac 
> is presumably doing the same thing at its end when switching between 
> the baud 
> > >rates.
> > >  
> > >
> > I'm pretty sure the mac would have to have it's own clock for 
> > asynchronous communication.
> > 
> > in asynchronous mode, the UART runs at much faster than baudrate 
> speeds 
> > (say 500k for 31.25k data ??which is why the emax works fine at 
> asynch 
> > 31.25k with this as it's clock, still... ;-) and continually 
> samples the 
> > serial data for the start bit. then when it's got a valid start 
> bit, 
> > having detected the falling edge at the beginning,  it samples the 
> rest 
> > of the bits in the middle, and confirms the final edge of the stop 
> bit. 
> > all being good, the received byte is latched to the output.
> > 
> > 
> > >The easiest solution from your software perspective would be if 
> you could have a USB serial port that supports synchronous RS422 
> connection to the 
> > >Emax (or other Emu sampler). Then you handle the protocol, baud 
> rate switching etc and you can use standard Windows drivers. This is 
> presumably 
> > >what the expensive commercial interfaces are offering and I 
> presume this is what Julian is working on a low cost alternative to. 
> > >
> > yep!
> > :-)
> > 
> > basic solution if this works will be one $30 dev board, wired to a 
> > separate board with a couple of ICs. I will just veroboard the 
> custom 
> > stuff for now, but if it works and a few people want one, can 
> always get 
> > a batch of small PCBs made up for a few $.
> > 
> > if I can get away with a simple unchanged serial adapter, that 
> would be 
> > amazing - otherwise I might have to put some smarts into my buffer 
> that 
> > will make it only work with the emax (ie look for header info and 
> > deliberately hold off a packet retransmission to the emax until it 
> has a 
> > whole one, etc etc - basically make it run off the actual data that 
> > comes through it...)
> > 
> > >Another option would be 
> > >to have a microcontroller with a large buffer memory that the PC 
> can read from and write to using whatever protocol and the 
> microcontroller would 
> > >handle the Emu sampler synchronous RS422 interface and protocols. 
> Obviously this would be more work to develop the software for the 
> microcontroller 
> > >and possibly the drivers. 
> > >  
> > >
> > yeah - would be best not to have to do that if at all possible.
> > also, half a MB of fast access RAM for buffering would be annoying 
> to 
> > deal with hooking up on an 8 bit micro.
> > 
> > >Another possibility would be to have a micro controller with two 
> serial interfaces, one to the PC (asynchronous RS422 or RS232) and 
> one to the Emu 
> > >sampler (synchronous RS422). The micro controller would just 
> buffer and pass data between the two UARTs and switch baud rates 
> (31.25k/500k) 
> > >toward the Emu sampler if required. The PC host could connect via 
> any off the shelf USB to RS232/RS422 adapter or use a built in or PCI 
> serial port. 
> > >Because of the flow control provided by the Ack/Nak messages, the 
> PC serial connection could also use any baud rate the PC port 
> supports. Although 
> > >dumps would be slower at PC baud rates lower than 500kHz, this 
> would make it widely compatible with any old PC you might happen to 
> have lying 
> > >around. Both the microcontroller software and hardware would be 
> fairly simple for this option and no special drivers would be 
> required. The Emax serial 
> > >port even provides +5V that could be used to power the small 
> interface board.
> > >  
> > >
> > 
> > A serial rate converter would be even simpler, but it would be nice 
> to 
> > be able to have PC side running fast enough that there was no gaps 
> > between bytes in a packet, as seen by the emax.....
> >
> 
> 
> 
> ------------------------------------
> 
> Emax and Emax II User's Group Website
> 
> http://www.silveriafamily.comYahoo! Groups Links
> 
> 
> 
-- 
http://bleepin.com

-- 
http://www.fastmail.fm - Same, same, but different...