Emax

I agree, your USB to RS422 adapter is probably the best option here. It has the specific 
advantages that the PC software can command the baud rate and parity detection to change in 
accordance with the protocol and it is a once piece solution. 

Still, I might put together a serial baud rate converter just to try it out. I will of course have to get 
the microcontroller to monitor the comms and modify the RS422 UART baud rate and parity as 
required. I looked around and it seems most UARTs do not support the synchronous mode. That is 
probably why most USB to RSXXX adapters don't support it either. I will probably just use the 
microcontroller's internal UART to talk to the PC and a 6850 UART to talk to the RS422 interface. At 
least I know it will be compatible with the Emax!

By my calculation, if the PC UART runs at 460.8k baud (4 x 115.2k) with no parity then the data 
rate will be extremely close to that of the Emax UART with odd parity. 460.8k/10 = 46.08kB/s vs 
500k/11 = 45.454kB/s. I think this is probably the optimal rate to minimise the load on the buffers. 

I think I already have all the parts needed to build it except for the 6850. But I do not have much 
time right now so it might have to wait until the Christmas break. Maybe you will have the USB 
solution working by then anyway.

/Tristan

Tuesday, November 25, 2008, 5:12:51 AM, you 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.....